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
データベースで見る『家族アルバム みてね』の変遷 / The Evolution of Fam...
Search
kohbis
April 03, 2025
Technology
5
1.3k
データベースで見る『家族アルバム みてね』の変遷 / The Evolution of Family Album Through the Lens of Databases
春のSREまつり 〜 大規模サービス "あるある" との戦い事例 〜
https://mixi.connpass.com/event/347532/
kohbis
April 03, 2025
Tweet
Share
More Decks by kohbis
See All by kohbis
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
3
2.1k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
540
Custom Prometheus Exporterによる オブザーバビリティ拡張 / Extending observability with Custom Prometheus Exporter
kohbis
1
140
SREコミュニティイベントとわたし / Me and SRE community events
kohbis
2
240
サクッと試すNew Relic Kubernetes APM auto-attach / New Relic Kubernetes APM auto-attach
kohbis
0
400
悩ましきインシデント管理 みてねのケース / Incident management is a tough
kohbis
2
800
サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer
kohbis
5
3.2k
そこまで大規模じゃない EKS環境を(あまり)頑張らずに 最新化し続けたい / FamilyAlbum EKS Continuous Improvement
kohbis
2
1.8k
1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure
kohbis
5
4.3k
Other Decks in Technology
See All in Technology
Foundation Model × VisionKit で実現するローカル OCR
sansantech
PRO
1
340
LLMでAI-OCR、実際どうなの? / llm_ai_ocr_layerx_bet_ai_day_lt
sbrf248
0
460
Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805
kazaneya
PRO
20
4.9k
ZOZOTOWNの大規模マーケティングメール配信を支えるアーキテクチャ
zozotech
PRO
0
200
ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lounge #18
kossykinto
0
210
Lambda management with ecspresso and Terraform
ijin
2
160
大規模イベントに向けた ABEMA アーキテクチャの遍歴 ~ Platform Strategy 詳細解説 ~
nagapad
0
220
【CEDEC2025】『Shadowverse: Worlds Beyond』二度目のDCG開発でゲームをリデザインする~遊びやすさと競技性の両立~
cygames
PRO
1
350
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
6.4k
[OCI Technical Deep Dive] OracleのAI戦略(2025年8月5日開催)
oracle4engineer
PRO
1
150
AWS DDoS攻撃防御の最前線
ryutakondo
1
150
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
740
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
880
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Gamification - CAS2011
davidbonilla
81
5.4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
RailsConf 2023
tenderlove
30
1.2k
Practical Orchestrator
shlominoach
190
11k
Statistics for Hackers
jakevdp
799
220k
Adopting Sorbet at Scale
ufuk
77
9.5k
Designing for humans not robots
tammielis
253
25k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.7k
Transcript
©MIXI データベースで見る 『家族アルバム みてね』の変遷 春のSREまつり 〜 大規模サービス "あるある" との戦い事例 〜
2025/04/03
©MIXI About Me Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE
X / mixi2 : @kohbis
©MIXI Contents 『家族アルバム みてね』の • データベースにおけるAWSマネージドサービス活用 • 過去に発生した障害 • 現在直面している課題
主にメインデータベースとなるRDBのお話
©MIXI データベースにおける AWSマネージドサービス活用
©MIXI データベースにおけるAWSマネージドサービス活用(1/5)- 概要 • データベースは基本しんどい(ですよね?) • 「2,500万人利用している大規模サービス」と言いつつサービスとしては成長途中 • クラウドインフラを見ているSREの人的・時間的リソースも限られる •
サービス負荷の行き着くところがデータベース(なことが多い) 『家族アルバム みてね』においてはAWSマネージドサービスを積極活用 サービス成長やアーキテクチャ変更に伴う、適切なサービス移行や選定
©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™ アプリ登録者数、ブラウザ版登録者数の合計
©MIXI データベースにおけるAWSマネージドサービス活用(3/5) 2018年4月 Amazon Aurora MySQL 移行 (AWSサービス提供開始は2014年10月) • 高コストパフォーマンス
• ストレージ管理からの開放 2022年3月 Amazon RDS Proxy 導入 • ユーザー数 ≒ DB接続数増加に対応 • (のちに解除) ※ iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計
©MIXI データベースにおけるAWSマネージドサービス活用(4/5)- Multi-Region 2022年10月 AWSマルチリージョン化 Amazon Aurora Global Database 採用
(リージョン間レプリケーション) • ユーザーに近いリージョンのレプリカから データ読み取り • APIによってプライマリリージョンと同等の レスポンスタイムを実現
©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
©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購入不可
©MIXI 過去に発生した障害 (ひとつだけ)
©MIXI 過去に発生した障害(1/3) 構成(当時) • Aurora MySQL Writer * 1台 /
Reader * 1台 概要 • DB負荷によりサービス接続性が悪化 • 緊急メンテナンスを実施
©MIXI 過去に発生した障害(2/3) 事象 • 休日ピークタイムに近づくにつれてReaderインスタンスのCPU使用率が高騰 Readerインスタンスが再起動し、すべてのクエリがWriterインスタンスに雪崩れ込む Writerインスタンスの負荷も高騰 ReaderインスタンスにFailoverするも...(以下略)
©MIXI 過去に発生した障害(3/3) 対応 • Readerインスタンスを複数台構成にすることで負荷分散 ◦ 障害発生まで問題なかったがサービス成長に伴い、データベースでは最低限以上の冗長構成 • スロークエリ改善 ◦
サービス成長とともにいつのまにか負荷をかけるようになっていたクエリ ◦ いつのまにかIN句に大量の値が入るようになっていたクエリ ▪ Rails(ActiveRecord)では Model.where(column: array) でいつのまにかarrayが肥大化することがある ◦ Performance InsightsやNew Relicでスロークエリを継続的に発見&解決する運用
©MIXI 現在直面している課題
©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
©MIXI 現在直面している課題(2/2) 将来的なAuroraの性能&スケール限界 • インスタンスサイズには上限がある ◦ すでに大きめのサイズを利用している ◦ ストレージは自動プロビジョニングだが、一応サイズ上限はある •
一部のテーブルをAuroraクラスター単位で分割はしている • サービス成長に伴うスケール限界がすぐにではないが確実にやってくる • Amazon Aurora Limitless DatabaseやAmazon Aurora DSQLにも期待
©MIXI まとめ そういえばテーマ ”あるある” だった
©MIXI まとめ あるある • まずはAmazon RDS(いまだとAurora)から始める サービス成長やアーキテクチャ変更に伴う、適切なサービス移行や選定 • サービス当初は問題なかった構成が、ある日火をふく 「何か起きてから」でもどうにかなるが、可能ならば適切なキャパシティ計画
• いつのまにか “ただのクエリ” が “スロークエリ” になりうる コード変更がなくとも、時間経過とともに障害や体験悪化の起点になるかも 定期的なスロークエリの棚卸しが理想 データベースはボトルネックになりやすい だからこそご利用は計画的に(言うは易し)
MIXI, Inc.