©MIXI 1 SREが導いたグローバルサービスの 信頼性向上戦略とその舞台裏 2025/07/11-12 SRE NEXT 2025 株式会社MIXI みてね事業本部 みてねプラットフォーム部 SREグループ 杉本浩平 〜『世界中の家族のこころのインフラ』を⽬指して次の10年へ〜 

2 ©MIXI About Me Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X / @kohbis 現職にはSRE NEXT 2020（初開催）をきっかけに応募 

3 ©MIXI 本⽇お話しすること • 『家族アルバム みてね』（以降、みてね）における グローバルサービスとしての段階的な信頼性向上の取り組み • グローバルなユーザー増加に伴う課題 • サービスを"次のステップ"に進めるための技術的な選択 みてねのSREについては👇のセッションもぜひご覧ください オンコール⼊⾨ 〜ページャーが鳴る前に、あなたが備えられること〜 7/12 15:50 - 16:20 @Track C 

©MIXI 4 『家族アルバム みてね』について 

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

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

7 ©MIXI 『家族アルバム みてね』について 〜ミッション〜 〜世界中の家族のこころのインフラをつくる〜 "世界中の家族" ● グローバルサービスとしてのどこにいても快適にアプリを操作できる "こころのインフラ" ● アルバムサービスとして思い出をいつでも振り返られる安定性 みてねのサービス信頼性 「いつでもどこでもアルバムを快適に閲覧できる」ユーザー体験 

©MIXI 8 グローバルサービスとしての 成⻑に伴う課題 

9 ©MIXI 『家族アルバム みてね』の海外展開 2015年4⽉ サービス提供を開始 ● AWSは東京リージョン（ap-northeast-1）のみ 2017年6⽉ 本格的な海外でのサービス展開を開始 ● 『FamilyAlbum』※1 として英語版を提供 北⽶‧欧州ユーザーの増加に伴う課題の顕在化 ※1 同⼀アプリであり、アプリ内設定で⾔語切り替えが可能 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 2019年 2020年 2021年 2022年 2023年 2024年 2025年 

10 ©MIXI 海外ユーザー増加に伴う課題 地理的な問題がユーザー体験に直結 ● みてねはサービス開始からAWSの東京リージョン（ap-northeast-1）のみで運⽤ ● クライアント（ユーザー）との距離が遠ければ遠いほど APIのレイテンシー、画⾯表⽰速度も悪化 ⽇本ユーザー 海外ユーザー 越えられない 距離の壁 

11 ©MIXI 海外ユーザーからのフィードバック（例） ● 「アルバム画⾯の表⽰がとても遅い」 ● 「写真‧動画のアップロードが遅い」 ● 「特定の画⾯の表⽰が数秒かかる」 ● 「画⾯の⼀部が若⼲遅れて表⽰されるためカクついて⾒える」 海外ユーザーの体験を損ねている≒サービス信頼性を損ねている状態 ミッションを達成できない だけでなく 海外におけるサービスの事業的なスケールも阻害する 

©MIXI 12 ユーザー体験向上に向けた 段階的な取り組み 

13 ©MIXI SREチームの発⾜ 2018年2⽉ SREチーム誕⽣ ● 障害対応やクラウドインフラの問題解決は開発者が都度対応していた ● サービススケールに伴う負債の解消＆ユーザー体験向上を⽬的として発⾜ 【SRE NEXT 2022】1,000万⼈以上が利⽤する「家族アルバム みてね」のSRE組織は4年間でどのように作ら れてきたのか ※1 海外ユーザー体験の改善について本格的な改善に着⼿ ※1 https://speakerdeck.com/isaoshimizu/sre-next-2022 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 SREチーム 発⾜ 2019年 2020年 2021年 2022年 2023年 2024年 2025年 

14 ©MIXI （再掲）海外ユーザーからのフィードバック（例） ● 「アルバム画⾯の表⽰がとても遅い」 ● 「写真‧動画のアップロードが遅い」 ● 「特定の画⾯の表⽰が数秒かかる」 ● 「画⾯の⼀部が若⼲遅れて表⽰されるためカクついて⾒える」 原因を⼤別してみると ● 画像‧動画のダウンロードが遅い ● 画像‧動画のアップロードが遅い ● API全体が遅い 

15 ©MIXI 段階的な取り組み（1/3） 画像‧動画のダウンロードが遅い （前提） ● ユーザーが安全に画像‧写真にアクセスできるように署名付きURLを発⾏ 改善前 ● リクエストのたびに都度発⾏ 遠い東京リージョンに何度もAPIリクエスト 改善後 ● 事前に⼀括で発⾏し、クライアントサイドに署名付きURL⾃体をキャッシュ 有効期限が切れたときだけ再発⾏のAPIリクエスト 【iOSDC Japan 2018】海外展開を⽬指すアプリで実装したセキュアで⾼速な画像配信の話 ※1 ※1 https://speakerdeck.com/_atsushisakai/image-distribution-for-overseas 

16 ©MIXI 段階的な取り組み（2/3） 画像‧動画のアップロードが遅い 改善前 ● US在住の場合、USリージョン（us-east-1 or us-west-1）のS3にアップロード ※1 ○ 東京リージョン（ap-northeast-1）にクロスリージョンレプリケーション（CRR） CRRのほとんどのオブジェクトが秒単位だが、99%は5分以内というSLA ※2 みてねでは遅いときには数⼗秒かかる 改善前 ● Amazon S3 Transfer Acceleration ※3 の導⼊ ○ クライアントとS3間の⻑距離転送を⾼速化（AWSで最適化された通信経路） 平均して500ms程度のアップロード速度の改善 CRRが不要になりS3バケット構成のシンプル化 ※1 US以外のユーザーは、東京リージョン（ap-northeast-1）のS3にアップロード ※2 https://aws.amazon.com/jp/blogs/aws/s3-replication-update-replication-sla-metrics-and-events/ ※3 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/transfer-acceleration.html 

17 ©MIXI 段階的な取り組み（3/3） API全体が遅い 改善前 ● ユーザーリクエストは直接ALBにルーティング 改善後 ● フロントにキャッシュポリシーが無効化されたCloudFrontを導⼊ ○ ユーザーリクエストは地理的に最も近いエッジロケーションにルーティング ■ SSL/TLSの接続確⽴の早期化 ■ AWSの最適化された通信経路で、エッジロケーションから東京リージョンへ API全体のレイテンシーを⼤幅に改善 

18 ©MIXI 段階的な取り組みの成果により次のステップへ 2018〜2021年 段階的な取り組みによって「⼀定の改善がされた」と判断 ● ほかの様々な施策にも注⼒ ○ メインデータベースをAmazon RDSからAuroraへ移⾏ ○ アプリケーションのコンテナ化、K8s（Amazon EKS）への移⾏ ※1 ○ 動画再⽣にHLSを導⼊ ※2 ※1 https://gihyo.jp/article/2022/11/mitene-02eks ※2 https://team-blog.mitene.us/hls-6b749943c0b9 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 SREチーム 発⾜ 2019年 2020年 2021年 2022年 2023年 2024年 2025年 海外ユーザー体験向上以外の施策に注⼒ 

©MIXI 19 マルチリージョン構成への 移⾏背景と概要 

20 ©MIXI マルチリージョン構成への移⾏ 2022年6⽉ さらなる海外ユーザー体験向上を⽬指すべくPJ開始 ● みてねユーザー数と海外ユーザー割合の⼤幅な増加による事業的な期待の⾼まり ○ 2018年 ユーザー数300万⼈ うち 海外ユーザー割合10%未満   ○ 2022年 ユーザー数1500万⼈ うち 海外ユーザー割合30%以上   ● 2018年以降のEKS移⾏などの取り組みによって移⾏容易になったという SREチーム内での期待の⾼まり ※1 https://speakerdeck.com/isaoshimizu/sre-next-2022 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 SREチーム 発⾜ 2019年 2020年 2021年 2022年 マルチリージョン構成 への移⾏ 2023年 2024年 2025年 海外ユーザー体験向上以外の施策に注⼒ 

21 ©MIXI レイヤーごとの検討と推進 「マルチリージョン構成」と⾔ってもレイヤーごとに対応はさまざま アプリケーション（Amazon EKS） ● ユーザーリクエストをどのように最適なリージョンに振り分けるのか ● どのアプリケーションをマルチリージョン対応するのか データベース（Amazon Aurora, ElastiCache） ● どの⽅式でリージョン間レプリケーションを実現するのか オブジェクトストレージ（Amazon S3） ● なにをマルチリージョン対応するのか ● そもそも膨⼤なある写真‧動画に対してコスト最適な⽅式があるのか 

22 ©MIXI レイヤーごとの検討と推進 レイヤーごとにタスクを分割し、担当者が⽅針検討および移⾏推進 ● 不確定要素が多い＆知⾒のない「マルチリージョンへの移⾏」について 最初に⽅針を決め切るのは⾮常に難しい ● あらかじめSREチームで、レイヤー横断 or 個別のタスクに分割 ○ 横断タスクの例 ■ マルチリージョン構成に対応したTerraformのコード設計 ● 担当者が着⼿し、⽅針検討段階で都度チーム内で議論 ● 移⾏推進中になんらか問題が発⽣した場合も、都度チーム内で議論 スコープと優先度を調整しながら柔軟に推進する体制 

23 ©MIXI 最終的なスコープ（2022年10⽉当時） セカンダリリージョンはリードレプリカとして マルチリージョン構成では「読み取り」のみを最適化する ● 『家族アルバム』サービスとしてまずは閲覧体験の改善に注⼒ ● マルチライター構成の難易度⾼ ○ オブジェクトストレージ（Amazon S3） ■ ユーザー（家族）ごとの写真‧動画を保存するリージョンの判定 ○ データベース（Amazon Aurora, ElastiCache） ■ 書き込みのグローバルな整合性とパフォーマンスのバランス etc. 

24 ©MIXI 最終的なアーキテクチャ（2022年10⽉当時）詳細は後出 

©MIXI 25 マルチリージョン構成への 移⾏プロセスと課題 

26 ©MIXI 最適なセカンダリリージョンの選定 より多くのユーザー体験向上を実現するため バージニア北部リージョン（us-east-1）を選定 ● ⽇本に次いで、ユーザー⽐率が⼤きい⽶国のリージョンであること ● ⽶国に次いで、ユーザー⽐率が⼤きい欧州をカバーできるリージョンであること 

27 ©MIXI マルチリージョン構成への移⾏プロセスと課題 〜データベースのクロスリージョンレプリケーション〜 

28 ©MIXI データベースのクロスリージョンレプリケーション Amazon Aurora Global Databaseの活⽤ ● ストレージベースの 物理レプリケーション ● どのリージョンでも 通常 1 秒未満のレプリケーション （みてねでは100ms程度） ● リージョン追加やクラスタ削除は ダウンタイムなしで実施可能 【Tech Blog】Amazon Aurora Global Databaseを導⼊するまで ※1 ※1 https://team-blog.mitene.us/mitene-multiregion-aws-aurora-global-database-c0434c60a204 

29 ©MIXI データベースのマルチリージョン構成への移⾏プロセスと課題 背⽔の陣で アプリケーションチューニング ● 当時利⽤していたRDS Proxy ※1 が Global Databaseを未サポートだった ● 代替⼿段としてバイナリログベースの Cross-region Read Replica ※2 を検証 ● 本番検証でピーク時には数時間レベルの レプリケーションラグを確認 マルチリージョン構成において データベースレイヤーの⾼速なレプリケーションは必須 ➡ どうにかしてRDS Proxy依存を外すしかない！ ※1 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-proxy.html ※2 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html 

30 ©MIXI データベースのマルチリージョン構成への移⾏プロセスと課題 ● DBコネクション数の詳細調査とチューニング ● 主にRails（Puma）の調整によってリソース効率が⼤幅に改善 ● Global Databaseによる⾼速なレプリケーションでマルチリージョン構成が可能に ● 結果的にRDS Proxyにかかるレスポンスタイム改善（10~20ms）とコスト削減も 

31 ©MIXI マルチリージョン構成への移⾏プロセスと課題 〜APIリクエストのリージョン振り分け〜 

32 ©MIXI APIリクエストのリージョン振り分け ユーザーの最適化したルーティング ● （前提）バージニア北部リージョン（セカンダリ）はリードレプリカ ○ Global Databaseに書き込みが発⽣した場合はエラー ● ユーザーリクエストは「地理的に最も近い」or「最もレイテンシーが少ない」に ルーティングされるようにしたい ● 写真‧動画の閲覧、アプリ起動に関連するAPIのみを対応 ○ 必ずしもすべてのAPIがユーザー体験に直結しない ルーティングの要件 ● 読み取り系（GET, HEAD）か書き込み系（POST, PATCH etc.）かを判定する ● ユーザーに最適なリージョンにリクエストを振り分ける ● 特定のAPIにのみルーティングルールを適⽤できる 

33 ©MIXI マルチリージョン構成初期のルーティング CloudFrontのビヘイビア + Lambda@Edgeによるプロキシ ● 特定のAPIのみLambda@Edgeでルーティングをカスタマイズ ○ ユーザーのネットワーク情報から（緯度と）経度を取得 ○ あらかじめ指定した範囲内の経度であれば バージニア北部リージョンにルーティング 初期リリースでは⼗分だが、運⽤上いくつかの課題 ● 接続しているネットワークによる精度のブレ ● マルチリージョン対応したAPIは必然的にリクエスト数が多い ○ リクエストのたびにLambda@Edgeが起動するコスト 

34 ©MIXI マルチリージョン構成の改善されたルーティング CloudFrontのビヘイビア + Lambda@Edgeによるプロキシ + Route 53 Latency-based routing ※1 ● マルチリージョン対応するAPIは routing.mitene.us にルーティング ○ AWSマネージド機能によって最もレイテンシーが低いリージョンへ ● 読み取り/書き込みを判定したいAPIは、Lambda@Edgeにルーティング ※2 ○ HTTPメソッドを判定 ■ 読み取り系は routing.mitene.us へ ■ 書き込み系は東京リージョン（プライマリ）へ ※1 https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-policy-latency.html ※2 現在はAWS側のアップデートにより置き換え可能となったCloudFront Functionsに移⾏済み。Lambda@Edgeよりレイテンシーは20ms改善、コストは80%減 

35 ©MIXI 海外からのAPIリクエストレイテンシーは半減＆⽇本と遜⾊ない速さに 

36 ©MIXI （Appendix）さらなる写真‧動画のダウンロード⾼速化 Amazon CloudFront Origin Shield ※1 によるキャッシュレイヤーの追加 ● オリジン負荷の軽減 ● キャッシュヒット率の向上 ● ネットワークパフォーマンスの向上 S3（オリジン）へのリクエストが⾼速なキャッシュアクセスに ※1 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html 

©MIXI 37 持続可能なサービス運⽤に向けた コスト最適化 

38 ©MIXI 持続可能なサービス運⽤に向けたコスト最適化 インフラコストは最も⾝近なサービススケールの阻害要因 ● マルチリージョン構成では、特定のコンポーネントで単純計算2倍のコスト ● サービススケールに伴うリソースの増強や増加によるコスト コストの「削減」にとらわれず「最適化」を⽬指す 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 SREチーム 発⾜ 2019年 2020年 2021年 2022年 マルチリージョン構成 への移⾏ 2023年 2024年 2025年 海外ユーザー体験向上以外の施策に注⼒ 継続的な改善‧コスト最適化 

39 ©MIXI 持続可能なサービス運⽤に向けたコスト最適化 マルチリージョン構成のコスト最適化 ● リージョン間転送コスト ○ イメージレジストリ（Amazon ECR）やコンパイル済みリソース（S3）など ○ セカンダリリージョンにも保存（double-write）、ダウンロードすることで リージョン内転送に変更 = AWSでは課⾦対象外 ● インスタンスコスト（Amazon EC2、Auroraなど） ○ セカンダリリージョンは「読み取り」処理に限定されるため 負荷が低く安定している ○ プライマリリージョンよりも⼩さめのインスタンスサイズや 処理に最適化されたインスタンスタイプで安価なものを選択 

40 ©MIXI 持続可能なサービス運⽤に向けたコスト最適化 ほか様々な継続的な取り組み ● ユーザーの写真‧動画へのアクセス傾向分析にもとづく S3ストレージクラスのライフサイクル最適化 ● EKS on EC2のコンピューティングコストの削減 ○ 【Tech Blog】EKS on EC2コストをGraviton導⼊で3割減した話 ○ 【Tech Blog】Karpenterを再導⼊してEC2コストを削減した話 ● 監査や調査において不要なメトリクス、ログの抑制 ● メンテナンス後には不要になったDBスナップショットの削除 ● Auroraのストレージタイプ最適化 ○ 【Tech Blog】DBのコストを半額に！〜Amazon Aurora I/O-Optimizedの活⽤〜 コスト最適化は⼀⽇にして成らず... 

©MIXI 41 まとめ＆ 

42 ©MIXI まとめ ● 「いつでもどこでもアルバムを快適に閲覧できる」ユーザー体験を 実現するために段階的な取り組みの実施 ● 現在は「マルチリージョン対応したAPI」に限り⽇本と遜⾊ない速さに 2015年 みてねリリース 2016年 2017年 海外展開 開始 2018年 SREチーム 発⾜ 2019年 2020年 2021年 2022年 マルチリージョン構成 への移⾏ 2023年 2024年 2025年 海外ユーザー体験向上以外の施策に注⼒ 継続的な改善‧コスト最適化 

43 ©MIXI みてね’s SRE NEXT 現在の構成における課題 ● 「書き込み」にかかるレイテンシー ○ 主に写真‧動画のアップロード体験 ○ 依然として⽴ちはだかるマルチライター構成の難易度 ● データベースのスケール限界 ○ データベースで⾒る『家族アルバム みてね』の変遷 ※1 ● グローバルサービスであるからこその課題 ○ 世界中のユーザーが利⽤するため「深夜」が存在しない （現在は国内ユーザーが多いためオフピークはある） ○ メンテナンスタイミング決定の難しさ ※1 https://speakerdeck.com/kohbis/the-evolution-of-family-album-through-the-lens-of-databases 

44 ©MIXI ⼀緒に「世界中の家族のこころのインフラ」をつくりませんか？ https://team.mitene.us WE ARE HIRING!!! 

©MIXI 45 ありがとうございました