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
いま、あらためて考えてみるアカウント管理 with IaC / Account management with IaC
kohbis
3
790
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
3
2.8k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
630
Custom Prometheus Exporterによる オブザーバビリティ拡張 / Extending observability with Custom Prometheus Exporter
kohbis
1
150
SREコミュニティイベントとわたし / Me and SRE community events
kohbis
2
250
サクッと試すNew Relic Kubernetes APM auto-attach / New Relic Kubernetes APM auto-attach
kohbis
0
410
悩ましきインシデント管理 みてねのケース / 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
Other Decks in Technology
See All in Technology
バイブスに「型」を!Kent Beckに学ぶ、AI時代のテスト駆動開発
amixedcolor
2
580
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
110
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.5k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.8k
💡Ruby 川辺で灯すPicoRubyからの光
bash0c7
0
120
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
230
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
AI時代を生き抜くエンジニアキャリアの築き方 (AI-Native 時代、エンジニアという道は 「最大の挑戦の場」となる) / Building an Engineering Career to Thrive in the Age of AI (In the AI-Native Era, the Path of Engineering Becomes the Ultimate Arena of Challenge)
jeongjaesoon
0
230
研究開発と製品開発、両利きのロボティクス
youtalk
1
530
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
データ分析エージェント Socrates の育て方
na0
5
1k
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
270
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
173
14k
Bash Introduction
62gerente
615
210k
RailsConf 2023
tenderlove
30
1.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.1k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Gamification - CAS2011
davidbonilla
81
5.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
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.