データベースで見る『家族アルバム みてね』の変遷 / The Evolution of Family Album Through the Lens of Databases

春のSREまつり 〜 大規模サービス "あるある" との戦い事例 〜
https://mixi.connpass.com/event/347532/

1. ©MIXI データベースで見る 『家族アルバム みてね』の変遷 春のSREまつり 〜 大規模サービス "あるある" との戦い事例 〜 2025/04/03
2. ©MIXI About Me Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE X / mixi2 : @kohbis
3. ©MIXI Contents 『家族アルバム みてね』の • データベースにおけるAWSマネージドサービス活用 • 過去に発生した障害 • 現在直面している課題 主にメインデータベースとなるRDBのお話
4. ©MIXI データベースにおける AWSマネージドサービス活用
5. ©MIXI データベースにおけるAWSマネージドサービス活用（1/5）- 概要 • データベースは基本しんどい（ですよね？） • 「2,500万人利用している大規模サービス」と言いつつサービスとしては成長途中 • クラウドインフラを見ているSREの人的・時間的リソースも限られる • サービス負荷の行き着くところがデータベース（なことが多い） 『家族アルバム みてね』においてはAWSマネージドサービスを積極活用 サービス成長やアーキテクチャ変更に伴う、適切なサービス移行や選定
6. ©MIXI データベースにおけるAWSマネージドサービス活用（2/5） • 2015年4月 ◦ サービスリリース ◦ Amazon RDS for MySQL • 2018年4月 ◦ Amazon Aurora MySQL 移行 • 2022年3月 ◦ Amazon RDS Proxy 導入 • 2022年10月 ◦ AWSマルチリージョン化 ◦ Amazon Aurora Global Database 採用 ※ iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計
7. ©MIXI データベースにおけるAWSマネージドサービス活用（3/5） 2018年4月 Amazon Aurora MySQL 移行 （AWSサービス提供開始は2014年10月） • 高コストパフォーマンス • ストレージ管理からの開放 2022年3月 Amazon RDS Proxy 導入 • ユーザー数 ≒ DB接続数増加に対応 • （のちに解除） ※ iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計
8. ©MIXI データベースにおけるAWSマネージドサービス活用（4/5）- Multi-Region 2022年10月 AWSマルチリージョン化 Amazon Aurora Global Database 採用 （リージョン間レプリケーション） • ユーザーに近いリージョンのレプリカから データ読み取り • APIによってプライマリリージョンと同等の レスポンスタイムを実現
9. ©MIXI データベースにおけるAWSマネージドサービス活用（5/5）- Multi-Region Amazon DynamoDB Global Tables • Multi-Writerなセッション管理など ピンポイント利用 Amazon ElastiCache for Memcached • 毎回必要なデータをキャッシュして高速化 ※詳細は『AWSマルチリージョン構成におけるデータベース運用』 https://speakerdeck.com/kohbis/familyalbum-database-in-aws-multi-region
10. ©MIXI データベースにおけるAWSマネージドサービス活用 - Appendix • マネージドサービスだからこそ、新しい機能等には積極的にEarly Adopt ◦ Aurora I/O-Optimizedを有効化し、Write-heavyなワークロードだからこそ コスト削減＆パフォーマンス向上 ※1 ▪ 『DBのコストを半額に！〜Amazon Aurora I/O-Optimizedの活用〜』 https://team-blog.mitene.us/amazon-aurora-i-o-optimized-891130ca63cd ◦ Graviton3ベースのR7gインスタンスに変更し、DBパフォーマンスが改善 ※2 ※1 ワークロードや構成によっては必ずしもコストおよびパフォーマンスが改善しない可能性あり（前述ブログ参照） ※2 最新はGraviton4ベースのR8gインスタンスだが、2025/03時点でReserved Instances購入不可
11. ©MIXI 過去に発生した障害 （ひとつだけ）
12. ©MIXI 過去に発生した障害（1/3） 構成（当時） • Aurora MySQL Writer * 1台 / Reader * 1台 概要 • DB負荷によりサービス接続性が悪化 • 緊急メンテナンスを実施
13. ©MIXI 過去に発生した障害（2/3） 事象 • 休日ピークタイムに近づくにつれてReaderインスタンスのCPU使用率が高騰 Readerインスタンスが再起動し、すべてのクエリがWriterインスタンスに雪崩れ込む Writerインスタンスの負荷も高騰 ReaderインスタンスにFailoverするも...（以下略）
14. ©MIXI 過去に発生した障害（3/3） 対応 • Readerインスタンスを複数台構成にすることで負荷分散 ◦ 障害発生まで問題なかったがサービス成長に伴い、データベースでは最低限以上の冗長構成 • スロークエリ改善 ◦ サービス成長とともにいつのまにか負荷をかけるようになっていたクエリ ◦ いつのまにかIN句に大量の値が入るようになっていたクエリ ▪ Rails（ActiveRecord）では Model.where(column: array) でいつのまにかarrayが肥大化することがある ◦ Performance InsightsやNew Relicでスロークエリを継続的に発見＆解決する運用
15. ©MIXI 現在直面している課題
16. ©MIXI 現在直面している課題（1/2） サイズ（レコード数）が大きすぎてマイグレーションできないテーブル • 通常のALTERでは終わらない • pt-online-schema-changes ※1 も終わらない • Aurora Blue/Green Deployments ※2 では要件がアンマッチ • gh-ost ※3 はどうだろう 　　イマココ ※1 https://docs.percona.com/percona-toolkit/pt-online-schema-change.html ※2 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html ※3 https://github.com/github/gh-ost
17. ©MIXI 現在直面している課題（2/2） 将来的なAuroraの性能＆スケール限界 • インスタンスサイズには上限がある ◦ すでに大きめのサイズを利用している ◦ ストレージは自動プロビジョニングだが、一応サイズ上限はある • 一部のテーブルをAuroraクラスター単位で分割はしている • サービス成長に伴うスケール限界がすぐにではないが確実にやってくる • Amazon Aurora Limitless DatabaseやAmazon Aurora DSQLにも期待
18. ©MIXI まとめ そういえばテーマ ”あるある” だった
19. ©MIXI まとめ あるある • まずはAmazon RDS（いまだとAurora）から始める サービス成長やアーキテクチャ変更に伴う、適切なサービス移行や選定 • サービス当初は問題なかった構成が、ある日火をふく 「何か起きてから」でもどうにかなるが、可能ならば適切なキャパシティ計画 • いつのまにか “ただのクエリ” が “スロークエリ” になりうる コード変更がなくとも、時間経過とともに障害や体験悪化の起点になるかも 定期的なスロークエリの棚卸しが理想 データベースはボトルネックになりやすい だからこそご利用は計画的に（言うは易し）
20. MIXI, Inc.