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

by Ojima Hikaru

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 ©MIXI ⾃⼰紹介⽣島光 @ojima_h 2019年から『家族アルバムみてね』のSREチームで活動しています。海が好きです。⽇々感謝の気持ちで⽣きています。３児の⽗です。ありがとうございます。

Slide 3

Slide 3 text

3 ©MIXI 『家族アルバムみてね』について家族アルバムみてねはスマホで撮った⼦どもの写真や動画を家族と共有し、コミュニケーションして楽しむ家族アルバムサービスです。

Slide 4

Slide 4 text

4 ©MIXI 『家族アルバムみてね』について 2015年4⽉にリリースして、ことし10周年 ● 7⾔語‧175の国と地域でサービスを提供 ● 2025年1⽉に利⽤者数が2,500万⼈を突破

Slide 5

Slide 5 text

5 ©MIXI 『家族アルバムみてね』の技術スタック Kubernetes S3 Aurora MySQL メディア解析パイプライン

Slide 6

Slide 6 text

6 ©MIXI 今⽇のテーマみてねの画像‧動画のアップロードにまつわるアーキテクチャの変遷を紹介します。どんな課題を解決したかったのか？そこにはどのようなトレードオフがあったのか？その当時における意思決定の経緯を振り返っていきたいと思います。

Slide 7

Slide 7 text

7 ©MIXI アジェンダ 1. Railsの限界とマネージドサービスの活⽤ 2. 多様な技術スタックをサポートし続ける難しさ 3. スケール速度の限界と、メディア活⽤の多様化

Slide 8

Slide 8 text

8 ©MIXI Railsの限界とマネージドサービスの活⽤

Slide 9

Slide 9 text

9 ©MIXI メディアアップロードに関する最初期の構成 ● Railsサーバーが⼀度メディアファイルを受信 ● その後、S3にファイルを書き込み ● サムネイル画像の⽣成などを⾮同期に実⾏課題 ● 海外から⽇本のRailsサーバーに対して⼤容量のファイルをアップロードするのは⾮常に不安定。海外に進出します！！

Slide 10

Slide 10 text

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のエンドポイントは全世界に分散

Slide 11

Slide 11 text

11 ©MIXI トレードオフ ● S3の無限のスケーラビリティ ● 地理的な最適化海外進出という事業⽅針こそが最重要開発や運⽤の困難は受け⼊れるという判断をしました ● アップロード処理がRailsだけでは完結できなくなった ● → 開発環境の構築が困難になり、開発の難易度が上がった ● → システム全体の複雑性が増し、運⽤の難易度も上がった

Slide 12

Slide 12 text

12 ©MIXI 多様な技術スタックをサポートし続ける難しさ

Slide 13

Slide 13 text

13 ©MIXI S3直接アップロードの導⼊から４年… ● Lambda関数は、メインのRailsアプリケーションから分離されたため、開発から取り残されていました。課題 ● コア機能であるにも関わらず、開発の⼿を⼊れづらい状態 ● Lambda関数を今後もメンテすべきか Lambdaランタイム EOLの到来

Slide 14

Slide 14 text

14 ©MIXI 再びRailsに統合 ● クライアントからS3へのアップロードが完了すると、Lambda関数の代わりに、SQSにイベントを通知する。 ● Shoryuken (SQSワーカー) がイベントを検知し、サムネイル画像の⽣成を⾏う。 ● Shoryuken はRailsアプリケーションに統合されており、通常の開発‧運⽤フローに乗る。解決策 ● Lambda関数の処理を再びRailsに統合しました

Slide 15

Slide 15 text

15 ©MIXI トレードオフ Rails統合によるメリット ● アップロードにまつわる処理が全てRailsアプリケーションに統合され、スムーズに開発できるようになった。 ● スポットインスタンスを始めとする、EC2インスタンスによるコスト最適化が可能となった Kubernetesの導⼊が進⾏中だったこともあり、スケーラビリティに対する不安は受容することができました。 Rails統合によるデメリット ● Lambda関数のスケーラビリティを放棄するということ技術スタックが統⼀されているメリットを認識しました。

Slide 16

Slide 16 text

16 ©MIXI スケール速度の限界と、メディア活⽤の多様化

Slide 17

Slide 17 text

17 ©MIXI OpsWorksの限界 ● その当時インフラのオーケストレーションは OpsWorks を利⽤していました。課題 ● スケールアウトが遅い ● 運⽤の⾃動化が困難 ● スポットインスタンスの利⽤が困難 OpsWorksの限界 https://speakerdeck.com/isaoshimizu/cnbf-202001?slide=17

Slide 18

Slide 18 text

18 ©MIXI Kubernetesの導⼊ ● コンテナベースの⾼速なスケールアウトを期待 ● エコシステムの充実 ● スポットインスタンスの活⽤事例も沢⼭あった解決策 ● Kubernetesの導⼊

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 ©MIXI 未知の技術 Kubernetes に⽴ち向かうために PoC として、みてねの全ての機能を Kubernetes 上に実装してみることにしました。この PoC は１年以上に及びました。 https://gihyo.jp/article/2022/11/mitene-02eks この判断が正しかったのか、今もわかりません。今思えばもっと良い⽅法があったと思います。でもそれは今だから⾔えること。

Slide 21

Slide 21 text

21 ©MIXI Kubernetes導⼊の実現何はともあれ、Kubernetesの導⼊は無事に完了しました！！ Kubernetesの導⼊により、当初の期待通りOpsWorksの課題は全て解消されました。そして当初の期待を超えて、インフラに⼤きな進化をもたらしました。

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 ©MIXI トレードオフ Kubernetesのメリット ● ⾼速なスケールアウト ● 各種オペレーションの⾃動化 ● インフラ構成のセルフサービス化による開発速度の向上 Kubernetesのデメリット ● インフラ管理の⾼度化‧複雑化 ● 増え続けるワークロード ● アプリ開発者のキャッチアップが困難にみてねの魅⼒の１つである多様なフォトアイテム‧デジタルコンテンツを、⾼速かつ安定して開発することが可能になりました。⼀⽅で、開発チームの認知負荷に対処するための取り組みが必要になっています。

Slide 24

Slide 24 text

24 ©MIXI おわり

Slide 25

Slide 25 text

25 ©MIXI おわり ● アーキテクチャの選択に正解はありません。 ● 既存のシステム構成や事業フェーズによって、正解は変わります。 ● 課題を１つ解決すると、新しい課題が⽣まれます。終わりはありません。 ● Best より Better な選択を！