Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアー...
Search
Ojima Hikaru
July 23, 2025
Technology
5
750
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
Ojima Hikaru
July 23, 2025
Tweet
Share
More Decks by Ojima Hikaru
See All by Ojima Hikaru
家族の思い出を形にする 〜 1秒動画の生成を支えるインフラアーキテクチャ
ojima_h
3
1.8k
Podのオートスケーリングに苦戦し続けている話
ojima_h
1
340
ディメンショナルモデリングのすすめ
ojima_h
8
4.7k
モンスターストライクを支えるデータ分析基盤と準リアルタイム集計
ojima_h
7
5.7k
データ分析基盤の変遷とデータレイクの作り方
ojima_h
2
1.9k
Other Decks in Technology
See All in Technology
非同期処理実行基盤 Delayed脱出 → Solid Queue完全移行への旅路。
srockstyle
3
1.3k
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
joker1007
20
8.9k
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
170
AI×Data×SaaS×Operation
sansantech
PRO
0
100
Pythonによる契約プログラミング入門 / PyCon JP 2025
7pairs
4
2.2k
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
260
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム / 5 Years Fintech Rails Retrospective
ohbarye
9
3.3k
Function calling機能をPLaMo2に実装するには / PFN LLMセミナー
pfn
PRO
0
650
AIが書いたコードをAIが検証する!自律的なモバイルアプリ開発の実現
henteko
1
230
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
130
Go Conference 2025: GoのinterfaceとGenericsの内部構造と進化 / Go type system internals
ryokotmng
3
530
pprof vs runtime/trace (FlightRecorder)
task4233
0
140
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Making Projects Easy
brettharned
118
6.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Statistics for Hackers
jakevdp
799
220k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
How to Ace a Technical Interview
jacobian
280
23k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Transcript
©MIXI 1 Railsの限界を超えろ! 「家族アルバム みてね」の画像 ‧動画の ⼤規模アップロードを ⽀えるアーキテクチャの変遷
2 ©MIXI ⾃⼰紹介 ⽣島 光 @ojima_h 2019年から『家族アルバム みてね』のSREチームで 活動しています。 海が好きです。
⽇々感謝の気持ちで⽣きています。 3児の⽗です。 ありがとうございます。
3 ©MIXI 『家族アルバム みてね』について 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。
4 ©MIXI 『家族アルバム みてね』について 2015年4⽉にリリースして、ことし10周年 • 7⾔語‧175の国と地域でサービスを提供 • 2025年1⽉に利⽤者数が2,500万⼈を突破
5 ©MIXI 『家族アルバム みてね』の技術スタック Kubernetes S3 Aurora MySQL メディア解析パ イプライン
6 ©MIXI 今⽇のテーマ みてねの画像‧動画のアップロードにまつわるアーキテクチャ の変遷を紹介します。 どんな課題を解決したかったのか? そこにはどのようなトレードオフがあったのか? その当時における意思決定の経緯を振り返っていきたいと思います。
7 ©MIXI アジェンダ 1. Railsの限界とマネージドサービスの活⽤ 2. 多様な技術スタックをサポートし続ける難しさ 3. スケール速度の限界と、メディア活⽤の多様化
8 ©MIXI Railsの限界とマネージドサービスの活⽤
9 ©MIXI メディアアップロードに関する最初期の構成 • Railsサーバーが⼀度メディアファイルを受信 • その後、S3にファイルを書き込み • サムネイル画像の⽣成などを⾮同期に実⾏ 課題
• 海外から⽇本のRailsサーバーに対して⼤容量 のファイルをアップロードするのは⾮常に不安 定。 海外に進出します!!
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 ©MIXI トレードオフ • S3の無限のスケーラビリティ • 地理的な最適化 海外進出という事業⽅針こそが最重要 開発や運⽤の困難は受け⼊れるという判断をしました •
アップロード処理がRailsだけでは完結できなく なった • → 開発環境の構築が困難になり、開発の難易度 が上がった • → システム全体の複雑性が増し、運⽤の難易度 も上がった
12 ©MIXI 多様な技術スタックをサポートし続ける難しさ
13 ©MIXI S3直接アップロードの導⼊から4年… • Lambda関数は、メインのRailsアプリケー ションから分離されたため、開発から取り残さ れていました。 課題 • コア機能であるにも関わらず、開発の⼿を⼊れ
づらい状態 • Lambda関数を今後もメンテすべきか Lambdaランタイム EOLの到来
14 ©MIXI 再びRailsに統合 • クライアントからS3へのアップロードが完了する と、Lambda関数の代わりに、SQSにイベントを通 知する。 • Shoryuken (SQSワーカー)
がイベントを検知し、 サムネイル画像の⽣成を⾏う。 • Shoryuken はRailsアプリケーションに統合されて おり、通常の開発‧運⽤フローに乗る。 解決策 • Lambda関数の処理を再びRailsに統合しまし た
15 ©MIXI トレードオフ Rails統合によるメリット • アップロードにまつわる処理が全てRailsアプリ ケーションに統合され、スムーズに開発できる ようになった。 • スポットインスタンスを始めとする、EC2イン
スタンスによるコスト最適化が可能となった Kubernetesの導⼊が進⾏中だったこともあり、 スケーラビリティに対する不安は受容することができました。 Rails統合によるデメリット • Lambda関数のスケーラビリティを放棄すると いうこと 技術スタックが統⼀されているメリットを認識しました。
16 ©MIXI スケール速度の限界と、メディア活⽤の多様化
17 ©MIXI OpsWorksの限界 • その当時インフラのオーケストレーションは OpsWorks を利⽤していました。 課題 • スケールアウトが遅い
• 運⽤の⾃動化が困難 • スポットインスタンスの利⽤が困難 OpsWorksの限界 https://speakerdeck.com/isaoshimizu/cnbf-202001?slide=17
18 ©MIXI Kubernetesの導⼊ • コンテナベースの⾼速なスケールアウトを期待 • エコシステムの充実 • スポットインスタンスの活⽤事例も沢⼭あった 解決策
• Kubernetesの導⼊
19 ©MIXI トレードオフ Kubernetes導⼊メリット • OpsWorks の課題を解決してくれるという “期 待感” 不確定要素が多すぎる…!
Kubernetes導⼊のデメリット • 全く未知の技術。不確定要素しかない。
20 ©MIXI 未知の技術 Kubernetes に⽴ち向かうために PoC として、みてねの全ての機能を Kubernetes 上に実装して みることにしました。
この PoC は1年以上に及びました。 https://gihyo.jp/article/2022/11/mitene-02eks この判断が正しかったのか、今もわかりません。 今思えばもっと良い⽅法があったと思います。でもそれは今だ から⾔えること。
21 ©MIXI Kubernetes導⼊の実現 何はともあれ、Kubernetesの導⼊は 無事に完了しました!! Kubernetesの導⼊により、当初の期 待通りOpsWorksの課題は全て解消さ れました。 そして当初の期待を超えて、インフラ に⼤きな進化をもたらしました。
22 ©MIXI Kubernetesの期待以上の効果 〜 メディア活⽤の促進 • 多様なフォトアイテム‧デジタル コンテンツを処理する実⾏基盤 • 開発チームが、セルフサービス
で、案件ごとのニーズに合わせて ジョブを構成
23 ©MIXI トレードオフ Kubernetesのメリット • ⾼速なスケールアウト • 各種オペレーションの⾃動化 • インフラ構成のセルフサービス化による開発速
度の向上 Kubernetesのデメリット • インフラ管理の⾼度化‧複雑化 • 増え続けるワークロード • アプリ開発者のキャッチアップが困難に みてねの魅⼒の1つである多様なフォトアイテム‧デジタルコンテン ツを、⾼速かつ安定して開発することが可能になりました。 ⼀⽅で、開発チームの認知負荷に対処するための取り組みが必要に なっています。
24 ©MIXI おわり
25 ©MIXI おわり • アーキテクチャの選択に正解はありません。 • 既存のシステム構成や事業フェーズによって、正解は変わ ります。 • 課題を1つ解決すると、新しい課題が⽣まれます。終わり
はありません。 • Best より Better な選択を!
26 ©MIXI ⼀緒により良いサービスを作りましょう! https://team.mitene.us WE ARE HIRING!!!
©MIXI 27 ありがとうございました