サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
team-blog.mitene.us
おはようございます。みてねSREチームのおじまです。 SREチームでは、Amazon RDSのPerformance Insightsなどを利用して、定期的にDBの負荷状況を確認しています。時たま負荷の高いクエリが見つかるのですが、クエリの発行元が分からず、負荷対策を取りづらいことがよくあります。(特にPerformance Insightsですと、書き込み系の処理が COMMITとしか表示されないことがあり、なんの情報も得られません。) みてねのバックエンドではRailsを使っています。Rails 7からはQuery Logsという機能が組み込まれました。この機能を使うと、Active Recordから発行されるSQLに、アプリケーションに関する情報をコメントして自動で付与することができます。これにより、DBの負荷状況に関する解像度がググッと上がり、負荷対策をより素早く的確に行えるように
こんにちは、みてねプロダクト開発部 基盤開発グループ SREチームの尾関と申します。 これは MIXI DEVELOPERS Advent Calendar 2023 19日目の記事です。 今回は、「家族アルバム みてね」(以下、みてね)におけるレガシーなシステムとの向き合い方について書きます。 旧バージョンのImageMagickみてねは8年も続くプロダクトなので、これまでの運用で様々なものをバージョンアップしてきました。 特にOSやミドルウェア、フレームワークなどのバージョンを上げるのは大変で、いつも苦労しています。 ImageMagickというソフトウェアをご存知でしょうか。 主に画像の加工・操作を行うソフトウェアスイートですが、みてねは画像・動画をメインで扱うサービスということもあり、様々なところで利用しています。 今はlibvipsに置き換えた部分もありますが、過去にはアップロー
はじめに「家族アルバム みてね」(以下「みてね」)でエンジニアリングマネージャ(EM)をしているsobataroです。この記事では、みてねで作成・運用しているエンジニアリングラダーを公開します。 背景と目的エンジニアリングラダーを作成する背景と目的みてねでは、サービスのさらなる成長を目指し、組織強化に取り組んでいます。このサービスと組織の成長にあわせて、みてねの開発に携わるエンジニア個人の活躍と成長を後押しするため、みてね独自のエンジニアリングラダーを作ることとしました。このエンジニアリングラダーは、各等級のエンジニアに求められるスキル・マインド・行動を明示することで、エンジニア個人の成長に役立てるほか、直近で発生している以下のような課題の解決も目指しています。 キャリアプラン検討、育成、目標設定、人事評価の一連のサイクルが、各Engineering Manager(EM)の属人的なマネジ
こんにちは、みてねプロダクト開発部 基盤開発グループ SREチームの伊東 @hekki です。 はじめに先日、AWSよりAmazon Aurora(以下、Aurora)の料金設定として新しくAmazon Aurora I/O-Optimized(以下、Aurora I/O-Optimized)が発表されました。 AWS announces Amazon Aurora I/O-Optimized 私達のワークロードでは、Aurora I/O-Optimizedを使うことでAuroraクラスターのコストを約半額に削減することができました。 ただし、Aurora I/O-Optimizedを活用することでコストが大幅に削減できる場合もある一方で、逆にコストが増加してしまう場合もあり、正しく仕様を理解して試算をしてから利用の判断をする必要があります。 そこで本エントリーでは、有効化前のコスト削減額
こんにちは、みてねプロダクト開発部 基盤開発グループ SREチームの尾関です。 『家族アルバム みてね』(以下、みてね)ではユーザーがアップロードした大量の動画データをS3に保存していますが、非常に大きなコストがかかっています。 様々な方法でコスト削減を行ってきましたが、本記事ではその中でもユニークな、HLSを使った改善についてお話させていただきます。 みてねで動画をアップロードしてから再生できるまでの流れまず、従来(2022年3月頃まで)のみてねで動画をアップロードしてから再生するまでのフローを説明します。 アップロードした動画ファイル(original)が保存されるとともに、スマートフォンで再生するための少し解像度を調整した動画(smartphone)とサムネイル画像(small, medium, large)を保存しています。特に何の変哲もないシステムだと思います。 S3のストレージ
みてねのE2E自動テスト導入戦略こんにちは、みてね事業部 プロダクト開発グループ QAチームの森島です。 この記事では、「家族アルバム みてね」の品質において欠かせないテスト自動化プラットフォームのMagicPodの導入と定着に至る導入戦略についてご紹介します。 MagicPodを導入する前の状態について(約一年前)みてねでは二週間に一度リリースするサイクルで開発を進めており、iOS/AndroidのアプリをStoreにリリースする前に不具合がないか確かめるためのシナリオテスト(以降はリリース前テストと呼びます)を実施しています。 同じテストを繰り返し行うので簡易化できるように、E2E自動テスト(以降は自動テストと呼びます)として実機を使ってローカル環境で構築していました。 これは全てのテスト項目を自動化できておらず、約半分は手動で実施していました。 この時点の自動テストに対する課題は以下
Swift has built-in support for writing asynchronous and parallel code in a structured way. Asynchronous code can be… Swiftの言語機能に組み込まれている非同期/並行処理のための機能になります。 導入に至った背景みてねiOSでは、Swift Concurrency導入以前はRxSwiftを使って非同期処理を実装しておりました。非同期処理を実装する上で有名なOSSであることから、1度は利用したことがある人も多いと思います。 しかし、その後Appleの公式からCombineが発表され、Swift Concurrencyが発表され、Appleが提供する機能のみで非同期処理を実行できるようになってきました。 その中でもSwift Concurrencyは読みやすさと安全性が高い点が
こんにちは、みてね事業部 SREグループの伊東 @hekki です。 はじめに「家族アルバム みてね」(以下、みてね)では、アプリから日々大量の画像がアップロードされます。このアップロードされた画像をベースとしてサムネイルを生成し、ユーザーのアルバムに反映します。 このサムネイル生成にかかる時間はみてねにおいて非常に重要で、サムネイル生成を速くすることで以下のようなメリットが考えられます。 ユーザーが画像のアップロードを開始してからアルバムに反映されるまでの時間が短くなるので、アップロード時のユーザー体験が向上するサムネイル生成には多くのコンピュートリソースが必要となるため、エンコード速度が速くなれば単位時間あたりに処理できる画像枚数が増え、コスト効率が良くなるこのためサムネイル生成の高速化のチャレンジを行ったのですが、本記事では具体的な手法、結果、ハマったポイントについてご紹介させていた
こんにちは、株式会社 MIXI のみてね事業部 SRE グループに所属している尾関と申します。 みてねでは2021年2月から Kubernetes を運用していて、今回はクラスターオートスケーラーの Karpenter を導入した話をさせていただきます。 結論Karpenter では要望を満たせなかったので、Managed Node Group に戻しました。 Karpenter とは?Karpenter は AWS がオープンソースとして開発しているクラスターオートスケーラーで、2021年11月にリリースされました。 Karpenter 自身が Pod のリソースリクエストを監視し、必要なノードを適切なサイズで高速に起動・停止を行うことができます。 『家族アルバム みてね』における Karpenter の導入例ここからは、みてねで Karpenter を導入した具体的なお話をさせていただ
こんにちは!みてね事業部 SREグループの本間 @HonMarkHunt です。あだ名はポンタです。 はじめにみてねは2015年にリリースされ、現在は日本国内のみならず、海外でもサービスを展開しています。(海外での名称はFamilyAlbum) 日本国内においては少子化の影響などもあり、事業としても海外のユーザー数を伸ばすのは非常に大きな注力ポイントとなっています。 一方で注力ポイントにはなっているものの、みてねを利用した際の海外のユーザー体験というのは国内に比べるとあまり高くないのが課題でした(詳細は後述)。 今回は海外のユーザーの体験を向上させるために、みてねをマルチリージョン化するまでの経緯や苦労ポイント・これからの課題について書いていこうと思います。 これまでの海外施策実はこれまでにも海外ユーザーの体験を向上させるための施策はいくつか実施しておりました。 マルチリージョン化は海外体
この記事では、以前に別記事で「みてねを支えるプロダクト開発体制」という記事の中で説明した「みてねのプロダクト開発体制」を最近になってアップデートをしたので、その詳細をお伝えします。 プロダクト開発体制については、数多くカジュアル面談や面接を行なっている中でも多くのエンジニアの皆様にご質問をいただく部分で、特に「エンジニアがどの段階から施策に入り込んで開発できるのか?」であったり「エンジニアと他職種のメンバーとの関わり方は?」など、確かに自分自身もソフトウェアエンジニアとして事業に関わるときに気になることではあるので、ここで再度整理したいと思います。 みてね開発体制のこれまでみてねの開発チームは、これまで組織規模や事業課題に合わせて複数回の大きな体制変更を行なってきました。どのような変遷を辿ってきたかを整理してみます。詳しい時期はあまり覚えていないので、年の記載はおおよそです。 2014年~
最近は毎年恒例のことですが、targetSdkVersionをGoogle Playが指定しているバージョン以上にしておかないと、Google Play Storeにアプリのアップデートを公開できなくなります。2022年の場合は11月から、targetSdkVersionが31以上じゃないと、アプリのアップデートを配布できなくなります。 みてねでも今年の6月に targetSdkVersionを31にしました。その際開発中にどういう不具合が起こったかを紹介し、なぜそうなるのかを解説したいと思います。 11月まではあと3ヶ月ちょっとしかないので、大体の方は対応済みだとは思いますが、もしこれから対応するという方は参考にしてみてください。 Android 12での動作の変更点基本的には公式ドキュメントに注意すべき変更点が紹介されているので、必ず英語で読むことをおすすめします。日本語だと翻訳が間に
こんにちは、みてね事業部 プロダクト開発グループ QAチームの森島です。 この記事では、「家族アルバム みてね」における品質を支えるQAチームについて、その仕事や直近の取り組み、今後の課題をご紹介します。 QAチームの概要QAチームの主な取り組みは開発した機能のテスト業務です。みてねをご利用いただいているみなさまに安心・安全で、心地の良い体験を届けられるよう日々品質基準を満たしているか確認を実施しています。 QAチームは開発者と同じグループに所属しており、開発の進捗共有会議や知見共有会などの取り組みに参加して、開発者と近い位置でコミュニケーションをしていることが特徴です。 みてねは2022年4月からドメインチーム体制(※1)に移行しました。 ドメインチームは2つあり、各ドメインチームにQAメンバーを配置しています。 各ドメインチームのスクラムセレモニーに参加しますが、QAチームでも朝会を行
こんにちは、みてね事業部 開発グループ Data Engineering チームの sobataro です。 この記事では、「家族アルバム みてね」における「1秒動画」や「自動提案フォトブック」、「人物ごとのアルバム」といったコンテンツの自動生成・自動提案・自動分類機能を支える Data Engineering チームについて、その仕事や直近の取り組み、今後の課題をご紹介します。 Data Engineering チームの概要「家族アルバム みてね」では、画像認識に代表される機械学習技術を用い、コンテンツを自動生成・自動提案または自動分類する複数の機能を提供しています。 「人物ごとのアルバム」機能のイメージたとえば「人物ごとのアルバム」機能では、みてねのユーザさまにアップロードいただいた写真・動画をお子さまごとに自動分類し、また月齢ごとのコメントやメモも保存できるようにすることで、手作業に
こんにちは! みてねでアプリ開発をしている ロクネム です みてねでは開発初期からスクラムを採用して日々プロダクト開発を進めてきました みてねがリリースされてから早6年、チームや組織が移り変わる中、少しずつこのスクラム開発の運用にも改善が重ねられてきました 本記事では、スクラムをベースとして日々磨かれていった、みてねを作りあげるプロダクト開発手法について紹介させていただきます こちらは「【連載】 みてねにおけるボトムアップな開発プロセス」の最終日の記事となります 戦略ディスカッションでは施策がボトムアップに練られていき、POが中心となって各施策の優先度をつけていきました その後、各施策ごとに企画チームが結成されて、UXリサーチ・仮説検証によりプロダクトの仕様が洗練されていきました そして、企画チームに開発チームが合流し、プロダクト開発フェーズへと移行していきます 各施策におけるプロダクト開
こんにちは、みてね事業部 開発グループ SREチームの伊東 @hekki です。 家族アルバム みてね(以下みてね)では主にRuby on Rails(以下Rails)をAPIやWEBページの開発に利用しています。本記事では、Railsのアセットパイプラインを利用してアセットをCDNで配信するようにした際に工夫したポイントなどを共有します。 アセットをCDNで配信をするねらい本題の前に、そもそもアセットをCDNで配信するねらいを整理しておきます。主に3つのねらいがありますが、どれもみてね特有のものではなく一般化できるポイントだと思います。 1. UXの向上・SEOの改善予めコンパイルしたアセットをCDNで配信することで、Railsから直接アセットを配信する場合に比べてアセットのレスポンスタイムが改善します。これによりWEBページの描画がスピードアップし、UXの向上・SEOの改善が期待できま
こんにちは、みてね事業部 開発グループ SREチームの清水 @isaoshimizu です。 この記事では、「家族アルバム みてね(以下みてね)」を支えるSREチームはどんなチームで、普段どんなことをやっているのかを紹介していきたいと思います。チームの行動は頻繁にアップデートされていくので、定期的にブログ記事にできたらと思っています。 みてねのSREチームはこんなチームまずは、みてねのSREチームの紹介と毎日の仕事の流れについて紹介したいと思います。 ちなみに、SREチームは2018年2月1日に作られました。この時のチームメンバーは3名でした。 SREチーム用のSlackチャンネルが作られたときここから徐々にメンバーが増え、2021年6月時点でのSREチームメンバーは5名となっています。 SREチームが作られてから3年以上経過し、当初からスクラムというスタイルで変わらず運用していますが、1
このページを最初にブックマークしてみませんか?
『mitene / FamilyAlbum Team』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く