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
1.7k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
470
Custom Prometheus Exporterによる オブザーバビリティ拡張 / Extending observability with Custom Prometheus Exporter
kohbis
1
130
SREコミュニティイベントとわたし / Me and SRE community events
kohbis
2
230
サクッと試すNew Relic Kubernetes APM auto-attach / New Relic Kubernetes APM auto-attach
kohbis
0
390
悩ましきインシデント管理 みてねのケース / 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.2k
Other Decks in Technology
See All in Technology
MCP とマネージド PaaS で実現する大規模 AI アプリケーションの高速開発
nahokoxxx
1
1.4k
P2P ではじめる WebRTC のつまづきどころ
tnoho
1
170
低レイヤソフトウェア技術者が YouTuberとして食っていこうとした話
sat
PRO
7
5.8k
Recoil脱却の現状と挑戦
kirik
2
200
[SRE NEXT 2025] すみずみまで暖かく照らすあなたの太陽でありたい
carnappopper
2
880
Building GoReleaser - from shell script to paid product
caarlos0
0
260
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
120
Data Engineering Study#30 LT資料
tetsuroito
1
550
なぜAI時代に 「イベント」を中心に考えるのか? / Why focus on "events" in the age of AI?
ytake
2
260
SREを知らずに SREマネージャーになった話 / How I Became an SRE Manager Without Knowing What SRE Is
moneyforward
0
280
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
6
210
20150719_Amazon Nova Canvas Virtual try-onアプリ 作成裏話
riz3f7
0
130
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
173
14k
Documentation Writing (for coders)
carmenintech
72
4.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
RailsConf 2023
tenderlove
30
1.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
A Tale of Four Properties
chriscoyier
160
23k
4 Signs Your Business is Dying
shpigford
184
22k
Writing Fast Ruby
sferik
628
62k
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.