ブランチ単位で自動生成する開発環境の構築事例 〜TiDB × mirage-ecs〜

Transcript

1. ブランチ単位で自動生成する開発環境の構築事例 〜TiDB × mirage-ecs〜 株式会社ラセングル / 高倉 利明 1
2. 自己紹介 株式会社ラセングル / 高倉 利明 新規プロジェクトのゲームサーバアーキテクチャ 設計、CI/CD・インフラ整備全般を担当 TiDBは3年前から検討していたが、最近ようやく開 発環境に全面採用 「使えるようになったので使い倒す」で用途 を模索中 最近の趣味：ロードバイク／ドライブ（愛車：ND ロードスター）／スマートホーム 2
3. この発表について こんな方に、特におすすめです TiDBなどNewSQLの基本的な特徴を理解している方 ECSなどコンテナ基盤の基本的な仕組みをイメージできる方 扱うのは、開発環境を「増やす」話と、増やせる環境を土台に「広げる」話です 軸 何をしたか 増やす（2章） ブランチ／PR単位で占有環境を自動生成。DBはTiDB 1クラスタのまま 広げる（3章） 増やせる環境を土台に、API回帰・APM性能テスト・負荷試験へ用途を広げている 3
4. アジェンダ 1. 背景：環境は増やしたい、DBは増やしたくない 2. 実施したこと：PRを作ると、約5分で占有環境が生える 3. 次に取り組んでいること：増やせる環境を土台に、負荷試験まで広げる 4. まとめ 4
5. 1. 背景 環境は増やしたい、DBは増やしたくない 5
6. ゲーム開発で占有環境が欲しくなる3つの場面 場面 従来の問題 必要な状態 PRのマージ前検証 実機や管理画面の動作を実際に触って確認したい が、PRごとに環境を用意できない PRごとに、触って確 認できる環境を占有 大きめの機能開発 常設環境（dev1・dev2…）は数が固定で、大き めの機能変更の確認用に臨時で占有できない 常設とは別に、必要な 期間だけ臨時で占有 プランナーのマスタ確認 ローカルサーバでマスタデータを確認する運用 は、非エンジニアには環境差異の解決が難しい ローカル構築なしでマ スタ入り環境を占有 環境を増やすとき、DBはどうするか ✕ 環境ごとにDBインスタンスを用意 コスト・監視・バックアップが台数分増える or ✕ 強めのDBインスタンス1台を全環境で共有 誰かの重い処理が他の環境に伝搬する 「環境は増やす、DBは増やさない」の鍵は、本番候補に選んでいたTiDBにあった 6
7. PoC：ソーシャルゲームのDBに何が欲しいか TiDBを本番候補に選んだPoC。前提：イベントで負荷が急変し、ユーザー単位のJOINが多い 欲しいこと Aurora + Shardingの課題 TiDBで期待したこと 稼働中に拡張・縮小 増強にメンテナンスが必要。増強したま ま数日動く 稼働中にノードを追加・削除。収 まれば縮小 シャーディング不要 アプリに分割ロジック。運用は数十台分 自動でデータ分散。運用は1クラス タ分 ゲーム向きの性能 大規模Joinで伸び悩む 大規模Joinに強い。単純クエリは やや不利 MySQL互換 MySQL互換で水平スケールする選択肢が 少ない 知見・ツールをそのまま活用 この本番候補のTiDBを、開発環境の「増やさないDB」としても先行利用する ※製品比較はPoC実施時点。発表時点の最新仕様との比較ではありません 7
8. 2. 実施したこと PRを作ると、約5分で占有環境が生える 8
9. ECSはmirage-ecs、データはTiDBで分離 mirage-ecs：ECS上に一時的な環境を動的に起動・破棄できるOSSツール （acidlemon/mirage-ecs） 流れ ECS側の環境の増やし方 従来 ECS基盤も環境ごとの構成もAWS CDK（以下、CDK）で管理。環境は常設 （dev1・dev2…）のみ 問題 環境を1つ足すたびにCDKの設定変更とデプロイが必要で、臨時の環境を気軽に 増やせない mirage-ecs導入後 CDKで作るのは全環境共通の基盤だけ。ブランチごとのタスクはmirage-ecsが 起動・停止し、専用URLで振り分ける mirage-ecsはECSタスク、TiDBは論理Databaseを環境ごとに分離する 9
10. TiDBとmirage-ecsで開発・検証環境を分離する AWS CDKで構築した共通ECS基盤（環境追加時のCDK変更なし） ECS：占有環境 A feature-a.example.com PR・ブランチごとのタスク 利用者 開発者・プランナー 環境専用URLへ接続 mirage-ecs 占有タスクの起動・停止 URLから環境名を判定 対応するECSタスクへ ECS：占有環境 B feature-b.example.com PR・ブランチごとのタスク 動的にルーティング ECS：占有環境 C TiDB Cloud Starter 1クラスタを共有 論理Database A 論理Database B 論理Database C feature-c.example.com 必要な数だけ追加・削除 占有環境は独立して増やす ／ 開発環境用DBの運用は1クラスタに集約 10
11. PRを作ると、約5分で環境が生える ブランチ名とPRに連動して、ECSタスクとTiDB上の論理Databaseを自動生成 PR作成 ／ Gitブランチへpush GitHub Actionsが起動 ① Dockerイメージをビルド APIサーバ／管理ツールのイメージを並列ビルド ② 論理Databaseを作成し、データを準備 Migration・マスタデータ投入など、環境に必要なデータ準備 ③ ECSタスクをデプロイ mirage-ecsにデプロイ＆ルーティング 約1分 約3分 約1分 約5分で占有環境を生成 専用URLから開発・検証が可能 PRクローズ ECSタスクと論理Databaseを自動削除 ※対象は、ブランチ名の末尾に「_mirage」を付けたブランチでPRを作った場合。すべてのPRで生成されるわけではない 11
12. 実測：環境生成 約5分の内訳 1 3 2 2 1 Dockerイメージをビルド：約1分 build-image-api／master-data／admin の3イメージを並列ビルド（48〜55秒） 2 論理Databaseを作成し、データを準備：約3分 create-db 20秒 ＋ prepare-data 3分7秒（Migration・マスタデータ投入など） 3 ECSタスクをデプロイ：約1分 register-taskdef → launch-mirage（3秒）→ update-server-list TiDB上の論理Database作成は約20秒。所要時間の大半は、環境として必要なデータ 準備（prepare-data）が占める 12
13. 実績：PRと連動して環境が生える PRのマージ前検証：PRを作ると約5分で自動 生成。実機や管理画面を触って確認 TiDB Cloud Starter 1クラスタ 論理Databaseだけを増やす 大きめの機能開発・プランナーのマスタ確 認：必要なときにエンジニアがGitHub Actionsを手動実行して生成 DBは増やさない：環境ごとに論理Databaseを 作り、クラスタは1つのまま ※性能・障害ドメインは共有。リソース制限は未実装で今後検証 占有環境 占有環境 占有環境 占有環境 占有環境 論理DB 論理DB 論理DB 論理DB 論理DB 占有環境 占有環境 占有環境 占有環境 占有環境 論理DB 論理DB 論理DB 論理DB 論理DB これまでの最大は同時10環境（上限ではない） ECSタスクと論理Databaseを環境ごとに1組ずつ生成 13
14. TiDBだからできたこと：増えない・安い・そのまま 増えない：運用対象は1クラスタ 安い：Starterの従量課金 そのまま：MySQL互換 クラスタは1つ 月50ドル未満 無トラブル 監視・バックアップも1クラスタ分 10環境分のDB費用（現状の実績値） クライアント側はMySQL用のまま Starterはフルマネージドで自動スケール 環境を足してもDB側の運用作業は増えない 利用頻度が低く、RU消費も少ない 参考：Aurora db.t3.medium 1台で 月約80ドル ミドルウェア、ライブラリ、 MigrationツールはMySQL向けのまま サイズ選定やパッチ適用も不要 開発者は接続先の変更を意識しない ただし、分散DBに合わせたDB設計は最初から必須 TiDB特有ではなく分散DB共通の前提。本番投入前のため、細かな技術的知見は今後積み上げる予定 環境を増やすコストがDB側でほとんど発生しないため、「環境は増やす、DBは増やさ ない」が成立する 14
15. 余談：1年前は断念、今回は実現できた理由 1年前：導入を断念 今回：AIコーディングエージェントと実現 すでにあったもの AIを相棒にして進めたこと ・CDKによる開発環境のIaC化 ・ECSコンテナ構成 ・設計・方針の壁打ち相手 1年後 足りなかったもの ・既存の固定環境とmirage環境の共通化 ・サーバアプリケーションの実装 ・インフラIaC（CDK）の改良 ・CI/CD（GitHub Actions）の実装 ・mirage-ecs導入の経験（社内初） ・CI/CDに詳しいメンバーの数 ・独力で試行錯誤と実装を進める時間 人手不足の領域も、一人で前に進められた → 技術的な方向性はあったが、着手できず → 同じ構成案が、今回は実装まで到達 1年で変わったのは技術構成ではなく、試行錯誤と実装に着手できる速度 TiDB・mirage-ecs・CDK・GitHub Actionsという選定は1年前と同じ 15
16. 3. 次に取り組んでいること 増やせる環境を土台に、負荷試験まで広げる 16
17. 2章の環境を土台に、3つの検証を定期的に回す 検証 目的 状況 API回帰テスト APIの操作が壊れていないかを毎日確認する 毎日実行 APM性能テスト 同じ操作で、プログラム性能の推移を追う 日次レポートを追加中 大規模負荷試験 大量アクセス時の性能をローンチ前に測る 今後検証 課題：検証ごとに別のシナリオを持つと、開発が進むほどメンテナンスが重くなる → DFrameで、3つの検証が使うシナリオを1つに共通化する DFrame：APIの操作手順をシナリオとして記述し、複数の実行環境で再利用できるフレームワーク（Cysharp/DFrame） 17
18. 1つのDFrameシナリオを、日常の検証と負荷試験で共有 DFrameシナリオ 検証段階が変わってもシナリオは1つ API回帰テスト + APM性能テスト 負荷試験 mirage-ecsが生成する占有環境 前章の開発・検証環境をそのまま利用 CDKで構築する負荷試験専用基盤 mirage-ecsとは別に用意する常設テスト環境 ECSタスク + TiDB Cloud Starter PRごとに自動生成・小規模構成 API整合性を毎日確認 APMで性能推移を日次レポート 大規模ECS + TiDB Cloud Premium／Dedicated 大量アクセスを模した並列実行に対応 ローンチ前などに単発で実行 低頻度・大規模 API回帰・APM・負荷試験のシナリオを1つに共通化し、メンテナンスを一本化 TiDB Cloud StarterからPremium／Dedicatedまで同じDB技術で揃えられる 18
19. 4. まとめ 19
20. まとめ：実績とこれから 1. 本番候補のTiDBを開発環境で先行利用し、互換性と運用知見を蓄積する TiDB 1クラスタで同時に10環境を稼働、10環境分のDB費用は月50ドル未満 2. PRから約5分で環境を生成し、PRクローズ後は自動で削除する 環境が増えても、DB側の構築・運用作業は増えていない 3. 増やせる環境を土台に、同じDFrameシナリオで負荷試験まで広げる APM日次レポートは追加中、Premium／Dedicatedでの大規模負荷試験は今後検証 今後検証：本番採用判断、環境数を増やした際の性能・コスト、リソース制限 TiDBを「検討するDB」から「日常的に使って判断するDB」へ 20
21. ご清聴ありがとうございました Q&A 運用・実装の細かい話も歓迎です。お気軽にご質問ください 21