Railsの限界を超えろ！「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷

Transcript

1. ©MIXI 1 Railsの限界を超えろ！ 「家族アルバム みてね」の画像 ‧動画の ⼤規模アップロードを ⽀えるアーキテクチャの変遷
2. 2 ©MIXI ⾃⼰紹介 ⽣島 光 @ojima_h 2019年から『家族アルバム みてね』のSREチームで 活動しています。 海が好きです。 ⽇々感謝の気持ちで⽣きています。 ３児の⽗です。 ありがとうございます。
3. 3 ©MIXI 『家族アルバム みてね』について 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。
4. 4 ©MIXI 『家族アルバム みてね』について 2015年4⽉にリリースして、ことし10周年 • 7⾔語‧175の国と地域でサービスを提供 • 2025年1⽉に利⽤者数が2,500万⼈を突破
5. 5 ©MIXI 『家族アルバム みてね』の技術スタック Kubernetes S3 Aurora MySQL メディア解析パ イプライン
6. 6 ©MIXI 今⽇のテーマ みてねの画像‧動画のアップロードにまつわるアーキテクチャ の変遷を紹介します。 どんな課題を解決したかったのか？ そこにはどのようなトレードオフがあったのか？ その当時における意思決定の経緯を振り返っていきたいと思います。
7. 7 ©MIXI アジェンダ 1. Railsの限界とマネージドサービスの活⽤ 2. 多様な技術スタックをサポートし続ける難しさ 3. スケール速度の限界と、メディア活⽤の多様化
8. 8 ©MIXI Railsの限界とマネージドサービスの活⽤
9. 9 ©MIXI メディアアップロードに関する最初期の構成 • Railsサーバーが⼀度メディアファイルを受信 • その後、S3にファイルを書き込み • サムネイル画像の⽣成などを⾮同期に実⾏ 課題 • 海外から⽇本のRailsサーバーに対して⼤容量 のファイルをアップロードするのは⾮常に不安 定。 海外に進出します！！
10. 10 ©MIXI クラウドリソースの有効活⽤ • Railsからクライアントにアップロード⽤の⼀時 URLを払い出す • クライアントは、最寄りのエンドポイントを経由 して直接S3にファイルをアップロードする ◦ https://speakerdeck.com/kohbis/towards-the-next-dec ade-enhancing-global-service-reliability-through-sre • S3へのアップロードが完了すると、S3から Lambdaにイベント通知を⾏う • Lambdaにてサムネイル画像等を⽣成し、完了し たらRailsサーバーに通知 解決策 • AWSのポテンシャルを最⼤限に活⽤する ◦ AWSのエンドポイントは全世界に分散
11. 11 ©MIXI トレードオフ • S3の無限のスケーラビリティ • 地理的な最適化 海外進出という事業⽅針こそが最重要 開発や運⽤の困難は受け⼊れるという判断をしました • アップロード処理がRailsだけでは完結できなく なった • → 開発環境の構築が困難になり、開発の難易度 が上がった • → システム全体の複雑性が増し、運⽤の難易度 も上がった
12. 12 ©MIXI 多様な技術スタックをサポートし続ける難しさ
13. 13 ©MIXI S3直接アップロードの導⼊から４年… • Lambda関数は、メインのRailsアプリケー ションから分離されたため、開発から取り残さ れていました。 課題 • コア機能であるにも関わらず、開発の⼿を⼊れ づらい状態 • Lambda関数を今後もメンテすべきか Lambdaランタイム EOLの到来
14. 14 ©MIXI 再びRailsに統合 • クライアントからS3へのアップロードが完了する と、Lambda関数の代わりに、SQSにイベントを通 知する。 • Shoryuken (SQSワーカー) がイベントを検知し、 サムネイル画像の⽣成を⾏う。 • Shoryuken はRailsアプリケーションに統合されて おり、通常の開発‧運⽤フローに乗る。 解決策 • Lambda関数の処理を再びRailsに統合しまし た
15. 15 ©MIXI トレードオフ Rails統合によるメリット • アップロードにまつわる処理が全てRailsアプリ ケーションに統合され、スムーズに開発できる ようになった。 • スポットインスタンスを始めとする、EC2イン スタンスによるコスト最適化が可能となった Kubernetesの導⼊が進⾏中だったこともあり、 スケーラビリティに対する不安は受容することができました。 Rails統合によるデメリット • Lambda関数のスケーラビリティを放棄すると いうこと 技術スタックが統⼀されているメリットを認識しました。
16. 16 ©MIXI スケール速度の限界と、メディア活⽤の多様化
17. 17 ©MIXI OpsWorksの限界 • その当時インフラのオーケストレーションは OpsWorks を利⽤していました。 課題 • スケールアウトが遅い • 運⽤の⾃動化が困難 • スポットインスタンスの利⽤が困難 OpsWorksの限界 https://speakerdeck.com/isaoshimizu/cnbf-202001?slide=17
18. 18 ©MIXI Kubernetesの導⼊ • コンテナベースの⾼速なスケールアウトを期待 • エコシステムの充実 • スポットインスタンスの活⽤事例も沢⼭あった 解決策 • Kubernetesの導⼊
19. 19 ©MIXI トレードオフ Kubernetes導⼊メリット • OpsWorks の課題を解決してくれるという “期 待感” 不確定要素が多すぎる…！ Kubernetes導⼊のデメリット • 全く未知の技術。不確定要素しかない。
20. 20 ©MIXI 未知の技術 Kubernetes に⽴ち向かうために PoC として、みてねの全ての機能を Kubernetes 上に実装して みることにしました。 この PoC は１年以上に及びました。 https://gihyo.jp/article/2022/11/mitene-02eks この判断が正しかったのか、今もわかりません。 今思えばもっと良い⽅法があったと思います。でもそれは今だ から⾔えること。
21. 21 ©MIXI Kubernetes導⼊の実現 何はともあれ、Kubernetesの導⼊は 無事に完了しました！！ Kubernetesの導⼊により、当初の期 待通りOpsWorksの課題は全て解消さ れました。 そして当初の期待を超えて、インフラ に⼤きな進化をもたらしました。
22. 22 ©MIXI Kubernetesの期待以上の効果 〜 メディア活⽤の促進 • 多様なフォトアイテム‧デジタル コンテンツを処理する実⾏基盤 • 開発チームが、セルフサービス で、案件ごとのニーズに合わせて ジョブを構成
23. 23 ©MIXI トレードオフ Kubernetesのメリット • ⾼速なスケールアウト • 各種オペレーションの⾃動化 • インフラ構成のセルフサービス化による開発速 度の向上 Kubernetesのデメリット • インフラ管理の⾼度化‧複雑化 • 増え続けるワークロード • アプリ開発者のキャッチアップが困難に みてねの魅⼒の１つである多様なフォトアイテム‧デジタルコンテン ツを、⾼速かつ安定して開発することが可能になりました。 ⼀⽅で、開発チームの認知負荷に対処するための取り組みが必要に なっています。
24. 24 ©MIXI おわり
25. 25 ©MIXI おわり • アーキテクチャの選択に正解はありません。 • 既存のシステム構成や事業フェーズによって、正解は変わ ります。 • 課題を１つ解決すると、新しい課題が⽣まれます。終わり はありません。 • Best より Better な選択を！
26. 26 ©MIXI ⼀緒により良いサービスを作りましょう！ https://team.mitene.us WE ARE HIRING!!!
27. ©MIXI 27 ありがとうございました