GameLibインフラ運用の10年

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackC-7

Transcript

1. GameLibインフラ運用の10年 株式会社グリー リードエンジニア 野坂 知昭
2. 野坂 知昭 株式会社グリー リードエンジニア GameLibと私の関わり 2016 GameLibインフラ担当 2017 他プロダクトのインフラ担当へ異動 2019 GameLibに兼務(インフラ主務) 2026 GameLibインフラ担当のマネージャー 2
3. GameLibとは GameLibは、セキュリティ要件を満たしながら、販売商品、ID、規約の一元管 理を可能にするグリーグループの共通基盤システムです。 GameLibについて 詳しくはこちら 3
4. 共通基盤として、多くのゲーム・アプリを支える 複数のゲームから同じGameLibを利用 多くのサービスから共通して利用される ゲーム A ゲーム B ゲーム C ゲーム D GameLib (共通基盤) アクセス特性・規模・ライフサイクルはゲームごと に異なる GameLibの変更・障害は複数サービスへ影響しうる だから「安定して、長く使い続けられること」が重要 4
5. GameLibを支えるインフラ ❖ GameLibとインフラの役割分担 GameLibチーム • 機能開発 • アプリケーション運用 • ゲーム・パブリッシャーとの調整 • GameLibとしてのサービス判断 インフラチーム ⇄ • AWS・サーバー・DB・ネットワーク • キャパシティ管理 • 監視・障害対応 • コスト・運用改善 今回のスコープ GameLibそのものの開発ではなく、GameLibを10年以上支えてきたインフラ運用 5
6. GameLibインフラ運用の10年 • 2014 オンプレミス環境で運用開始 • 2016 AWS移行 & 他社パブリッシャー向け環境構築 • 2017 グローバル展開(AP/US/EU) • 2019 過去トランザクションのアーカイブ先をS3+Athenaへ • 2020 US/EU環境統合、動的スケーリング導入 • 2025 Kubernetesベースの次世代環境を構築 6
7. 2014–2017：作る・移す・広げる 7
8. 新しい技術より、確実に運用できる技術を選ぶ 2016 ― オンプレミスからAWSへ 移行の要件 DB構成の選定プロセス 採択した構成: MySQL on EC2 安全にシステムを移す サービス停止時間を最小化する 既存の運用ノウハウを最大限活かす ・ なぜ RDS / Aurora を選定しなかったか？ → 既存の「無停止メンテナンス」ノウハウの活用を最優先に 判断 その時点の制約に対して、最も現実的な選択をする 8
9. まず複製し、後から整える 2016–2017 ― 短期間で環境が拡大 実現したかったこと そのために選択したこと 短期間で確実に環境を展開 • • • 稼働実績のある構成を複製 AWS移行と並行した他社向け環境の構築 続くAP / US / EUへのグローバル展開 限られた工期・リソース • • • 新規設計より既存構成の再利用を優先 共通化・最適化は後回し 構築速度と確実性を重視 展開後に共通化・標準化 後発環境の改善を先行環境へ反映 構築・デプロイ方法、アクセス制御、ネットワーク構成を共通化 最初から完成形を目指さず、変えられる状態を残して前へ進む 9
10. 2018–2020：作ったものを見直す 10
11. 構築の課題から、長期運用の課題へ 環境を作り、広げた先で見えてきたもの キャパシティ コスト データ量 デプロイ 保守 障害 不正アクセス 増え続ける管理対象 「どう作るか」から 「どう使い続けるか」 へ 11
13. 不正アクセスへの対応を、運用としてスケールさせる ゲームごとに異なる不正アクセスへの継続的な対応 BEFORE AFTER インフラレイヤーでのアクセス制御 • インフラ側で制御 • 同じ環境の別ゲームにも影響する可能性 • 個別対応や関係者との調整が必要 継続的な取り組み GameLibでアプリ単位のアクセス制御 → ・アクセス解析してbot計測 • ゲームごとに制御 • GameLibの機能として共通化 • ゲーム側で設定・運用が可能に ・自動レポート作成 ・bot判別して自動BAN 個別対応から、継続できる運用へ 共通基盤だけで完結させず、ゲーム側と協調して対応する 13
14. 過去トランザクションの保管方法を見直す ArchiveDB BEFORE AFTER MySQL / ARCHIVE Engine on EC2 に退避 → 特徴: 大容量 / 低頻度 / CS用途 / 数分待てる 常時稼働するDBである必要があるのか？ S3 + Athena サーバレス構成へ移行し、常時稼働コストおよび保守運用負 荷を根本から解消 【 導入成果 】 コスト削減率 従来の約 3% まで縮小 月間コスト削減 1,000 USD 以上 / 月 運用保守 DBインスタンスの 保守から解放 ※対象は過去トランザクションのアーカイブ領域 14
15. 「サービス側」と「インフラ側」の両方の視点で進める ArchiveDBの移行を例に GameLibチーム（サービス側） インフラ コスト・保守負荷を減らしたい 機能・運用を維持したい • • • 「必要なデータは引き続き参照したい」 「CS業務に支障を出したくない」 「コストは下げたいが、変更の負担は抑えたい」 現状でも機能要件は満たしている 変更する積極的な理由がない • • • 「低コストなストレージへ移したい」 「常時稼働するDBを減らしたい」 「DBの保守・メンテナンスを減らしたい」 ただし、用途や許容性能が分からない インフラ側だけでは変更を判断できない 両方の視点を持ち寄る 兼務による橋渡し： 「参照頻度が低く、数分待てるなら、DBでなくても良いのでは？」 機能要件を維持しながら、S3 + Athenaへ移行 境界を越えて理解することで、選択肢が増える 15
16. 運用に合わせて仕組みを最適化する 16
17. 需要の波に合わせるキャパシティ運用 17
18. かつて分けたUS/EUを、再びまとめる 2020 ― 利用状況の変化に合わせた環境の再編 なぜ統合したのか どう実現したのか （段階的な統合） 独立環境を維持する価値が低下 インフラ側: 管理対象を集約し、運用負荷を減らしたい 01 アプリケーションを複数環境対応 02 DB名を分離して共存可能に 03 リージョン間レプリケーション 04 Webを統合し、サービス再開 05 DBも後から段階的に統合 ゲーム側: 利用規模に対して割高なサーバー費用を抑えたい EU → USへ統合 （地理的な距離を考慮して選択） 【成果】(統合直後・DB統合前) 約 $2.3k / 月 削減 管理対象の集約・運用の軽減 利用状況に合わせて環境を再編し、インフラ構成を最適化する 18
19. 分けるか、まとめるか 分ける（分散・分離） まとめる（集約・統合） • 障害影響を隔離 • リソース効率の向上 • 責任範囲と費用の明確化 • 管理対象の集約 • メンテナンス調整が容易 • 運用負荷の軽減 判断基準： 利用状況 × コスト × 障害影響 × 運用効率 分割の粒度はその時々の事業要件や利用状況などにより変化する 19
20. 次の10年へ ― 技術と体制のバトンタッチ 20
21. Kubernetes・次世代環境・体制移行 これまで • EC2中心の既存環境 • 長期運用で蓄積した知識 Kubernetes構成へリアーキテクト 「変わるもの、変わらないもの：OSSアーキ テクチャで実現する持続可能なシステム」 2025– • Kubernetesベースの次世代環境 • 体制の刷新 今後の展望 • 次世代の技術・体制への統合 21
22. 10年間、作り変え続ける GameLibインフラ運用の10年 01. 現実的な選択 02. 柔軟な前提 03. 体制の進化 その時点の制約に対して、現 実的な選択をする 一度決めた境界や前提を固定 しない システムだけでなく、作る体 制も変えていく 10年使えるシステムを最初から作ったのではなく、 10年間、作り変え続けられた。 22
23. ご清聴ありがとうございました 23