大規模テーブルと高トラフィック環境で 終わらないオンラインDDLと戦った1年間

2026/04/23(木) に開催された [コドモン x MIXI] 積み重なった課題とどう向き合うか — 長期運用のSREの実践 の資料です
https://mixi.connpass.com/event/389250/

Transcript

1. ©MIXI 1 ⼤規模テーブルと⾼トラフィック環境で 終わらないオンラインDDLと戦った1年間 [コドモン x MIXI] 積み重なった課題とどう向き合うか — ⻑期運⽤のSREの実践 @HonMarkHunt #codmon_MIXI
2. 2 ©MIXI 本間 匡晃(ホンマークハント) 株式会社MIXI みてねプラットフォーム部 SREグループ マネージャー ・6歳と3歳の娘がいます ・スニーカー収集・筋トレ・キャンプ ・Netflixで「九条の大罪」をみて弁護士に憧れ中 @HonMarkHunt @honmarkhunt
3. ©MIXI 3 サービス紹介
4. 4 ©MIXI 家族アルバム みてね(以下、みてね)はスマホで撮った⼦どもの写真や動画を 家族と共有し、コミュニケーションして楽しむ家族アルバムサービスです。
5. 5 ©MIXI 2015年4⽉リリース • 7⾔語‧175の国と地域でサービスを提供 • 2026年2⽉に利⽤者数が2,900万⼈を突破 家族アルバム みてね 事業紹介 / Our Business(https://speakerdeck.com/familyalbum/our-business?slide=12)
6. 6 ©MIXI 世界中の家族のこころのインフラをつくる みてね事業のMVV | Mission
7. 7 ©MIXI みてねの組織構成 • みてね全体で100名以上、エンジニアで50名以上の組織 • 機能開発を⾏うドメインチーム(ストリームアラインドチーム) • 組織横断のプラットフォームチーム • SREがPlatform EngineeringとDBRE(?)の責任を持つ
8. 8 ©MIXI みてねのシステム構成 • Amazon EKSを⽤いたマルチクラスタ構成 • Amazon Aurora MySQL、Amazon Aurora Global Database 世界中の家族のこころのインフラ』を⽬指して”次の10年”へ (https://speakerdeck.com/kohbis/towards-the-next-decade-enhancing-global-service-reliability-through-sre?slide=24)
9. 9 ©MIXI これまでの取り組み 課題を残さないために多くの取り組みを実施しました 小さな最適化の積み重ねと、 将来のボトルネックを潰す大きな意思決定 の両方歴史があります • OpsWorksからEKSへの移行 ◦ https://gihyo.jp/article/2022/11/mitene-02eks • EKSのマルチクラスタ化 ◦ https://team-blog.mitene.us/mitene-infra-multi-region-614717f0162d 直近でも ingress-nginx から Envoy Gateway への移行を行いました *1 定常業務でも +α の改善を行って次のプロセスを改善し続けるカルチャー 例) EKSアップグレード作業の簡略化 *2 課題が深刻に滞留する状況は回避できている *1 Ingress NGINXのretirementに伴うGateway API + Envoy Gatewayへの移⾏(https://zenn.dev/mitene/articles/202604-ingress-nginx-to-envoy-gateway) *2 EKSアップグレードRTA in みてね 2025(https://zenn.dev/mitene/articles/eks-upgrade-rta-in-mitene-2025) zennの公式に ピックアップして いただきました
10. 10 ©MIXI SREは一般的な機能開発など「 0を1にする作業」に加えて アップグレード・アラート・インシデント・脆弱性・ EOLなど、 安定運用や保守改善にあたる「 -1を0にする作業 」も多い 成果としては同じ +1 ではあるが、 期待値調整・目標設定・上位レイヤーへの説明のしづらさから優先度を上げづらい傾向にある • MVVなどによるカルチャー • 経営・事業側の理解・評価制度への反映 ◦ 参考: みてね Engineering Ladder • 個々人の等級に見合った期待値調整 補⾜ : 課題を積み重ねないためにMGRができること 消化できないマイナスが貯まると「負債解消そのもの」をゴールに設定した 「負債解消プロジェクト 」が始まってしまう。できればそうなる前に対処しておきたい 「0を1にする作業」を増やしたいが「 -1を0にする作業 」も適切に給与に反映 させる そればかりだと何も生み出せないので期待値の調整は必要
11. 11 ©MIXI 再掲 : みてねのシステム構成 娘が描いた猫 サービス拡大とともに ネックになりそうなのは どこかな？
12. 12 ©MIXI 再掲 : みてねのシステム構成 ・・・ 娘が描いた猫
13. 13 ©MIXI 再掲 : みてねのシステム構成 私です 娘が描いた猫
14. 14 ©MIXI • Aurora MySQL • Global Database • Aurora I/O-Optimized • Gravitonインスタンスの活用 みてねにおけるAmazon Auroraの課題 Amazon Auroraの活⽤ • 物理的なサイズ上限 • サービスピーク時のパフォーマンス限界 • テーブル設計の陳腐化 ◦ 一部巨大テーブルの発生 Amazon Auroraの課題 https://aws.amazon.com/jp/rds/aurora/instance-types/ 今日はここ
15. 15 ©MIXI • ⼀部テーブルが 数億 ~ 数百億レコード • 通常のサービスピーク時で 数千 〜 1万数千 rows/sec のinsert ◦ 休⽇夜間がサービスピーク • 1⽇あたり 数億⾏ ~ ⼗数億 規模のinsert • 単⼀Writer 巨⼤テーブルとオンラインDDLの課題 日本時間の日曜夜
16. 16 ©MIXI ビジネス要件‧機能開発‧技術的負債解消のためにDB migrationを実施する必要がある みてねではRails標準のschema_migrationsを⽤いてversion管理を⾏っている ⼀部の⼤規模テーブルで素のALTER TABLEでは完遂できない 1. 巨⼤テーブルのコピーが現実的な時間で終わらない 2. 途中失敗で最初からやり直し（再開不可） 3. IO逼迫でサービス全体のレイテンシが悪化 4. メタデータロック しかし、migrationのたびにメンテナンスに投⼊していては可⽤性が悪化してしまう サービスも稼働させながら(オンライン)でDDLの変更を実施する必要がある DB migration実⾏し隊 オンラインDDLツールを利⽤してサービスを安定稼働させながらmigrationを完遂させる必要あり
17. 17 ©MIXI Percona Toolkit https://github.com/percona/percona-toolkit MySQL環境のオンラインマイグレーションツールならデファクト pt-online-schema-change（pt-osc） ⼤まかな流れ: 1. 新スキーマ適応された「新テーブル」を作成 2. 元テーブル → 新テーブルへ ⾏をコピー 3. コピー中の INSERT/UPDATE/DELETE をTRIGGERで同期 4. リネームでカットオーバー
18. 18 ©MIXI レコード数と書き込みがそこまで多くないテーブルでは問題なく実⾏可能 みてねでも標準ツールとして採⽤していた pt-online-schema-change（pt-osc） • DML追従のためのTRIGGERの負荷が発⽣ ◦ 元テーブルへの書き込みワークロードがそのままDB負荷 ◦ 書き込みが多いほど追従コストが膨らみ、全体のレイテンシにも影響 • 負荷が本番トラフィックに⽐例して拡⼤ ◦ ピーク時間帯はスロットリング/中断を余儀なくされる • みてねでの実績 ◦ レコード数が億を超える、もしくは書き込みの多いテーブルの場合 ◦ 負荷に耐えきれずプロセスが停⽌してしまい完遂できず TRIGGERを使わない⽅法で同期する必要がある
19. 19 ©MIXI GitHub https://github.com/github/gh-ost トリガーレス。binlogをストリーミングして変更を追従 gh-ost ⼤まかな流れ: 1. 新スキーマ適応された「新テーブル」を作成 2. 元テーブル → 新テーブルへ ⾏をコピー 3. binlogを読んで、変更イベントを新テーブルに適⽤（シングルスレッド） 4. リネームでカットオーバー
20. 20 ©MIXI binlog経由での同期となるためTRIGGERの課題は解消 gh-ost • pt-oscでは変更できなかったテーブルも変更完了 • みてねでも pt-osc から gh-ost を標準ツールへと移⾏ • 数⼗億程度のレコードであれば1⽇~数⽇程度でmigration完了 • しかし、gh-ostでも完遂できないケースが... binlogを出すことで性能⾯に影響が出るのでは？ Auroraの拡張binlogを⽤いることで解消 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Enhanced.binlog.html
21. 21 ©MIXI gh-ost gh-ostより速度の速い⽅法で同期する必要がある • レコード数が数百億を超え書き込みの多い巨⼤テーブルでは、 テーブルの変更速度にgh-ostが追いつかず、カットオーバーまで到達できない課題が発⽣ • binlog同期がシングルスレッド 実行時間が長くなるほど 完了予定時間が 長くなる事態に ...
22. 22 ©MIXI spirit https://github.com/block/spirit spirit spiritとは • MySQL 8.0+ 専⽤の次世代オンラインスキーマ変更ツール • gh-ost の思想を継承しつつ、現代的な要件に再設計 ◦ > Spirit is a reimplementation of the schema change tool gh-ost. • gh-ostとの主な違い ◦ 変更適⽤もマルチスレッド化 → ⾼書き込みワークロードに追従 ◦ チェックポイントからの再開 → 途中で落ちても続きから再開可能 ◦ MySQL 8.0 の INSTANT DDL を⾃動活⽤
23. 23 ©MIXI spirit https://github.com/block/spirit spirit ⼤まかな流れ: 1. 新スキーマ適応された「新テーブル」を作成 2. 元テーブル → 新テーブルへ ⾏をコピー 3. binlogを読んで、変更イベントを新テーブルに適⽤（マルチスレッド） 4. リネームでカットオーバー spirit \ --username=$MYSQL_USER \ --password=$MYSQL_PASSWORD \ --host=$MYSQL_HOST \ --database=$MYSQL_DATABASE \ --table="table_name" \ --alter="CHANGE hoge int NOT NULL” \ --defer-cutover \ --threads=2
24. 24 ©MIXI binlog同期がマルチスレッド化することで速度向上 spirit • マルチスレッドで並列数を増やすことでgh-ostでは⾒えなかった完了予定が⾒えるように ◦ しかし、スレッド数を増やすと当然WriteIOが悪化する • ⼀時的にAuroraをサイズアップし上げられる並列度を増やして実⾏ • サイズアップ / cutover 時には計画メンテナンスを実施 そもそも本番環境のDBであまり実績のないツール採⽤するの怖くない？ 各環境での検証に加えmigration完了後の新旧テーブルの差(check-sum)がないことを事前確認の上採⽤ 結果として...
25. 25 ©MIXI 今現在も実⾏中です spirit
26. 26 ©MIXI まとめ • 現状の運⽤ ◦ 軽量な変更 → MySQL Online DDL (INSTANT/INPLACE) ◦ 中〜⼤規模 → gh-ost（標準の⼿順に組み込み済み） ◦ 超巨⼤‧⾼書き込み → spirit • 課題 ◦ まだmigrationが実⾏中... ◦ 数百億超えのテーブルのmigrationを定期的に実⾏できる環境は作れていない • ご質問は懇親会‧パネルでぜひ！