DeNAのQCTマネジメント IaaS利用のベストプラクティス [AWS Summit Tokyo 2019]
•Descargar como PPTX, PDF•
10 recomendaciones•21,163 vistas
DeNA のインフラエンジニアたちが IaaS を利用するにあたってどのようにして品質，コスト，リードタイムをマネジメントしてきたか，その具体的な方法についてご紹介いたします。 なお、こちらは AWS Summit Tokyo 2019 で発表した内容です。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a DeNAのQCTマネジメント IaaS利用のベストプラクティス [AWS Summit Tokyo 2019]
Similar a DeNAのQCTマネジメント IaaS利用のベストプラクティス [AWS Summit Tokyo 2019] (20)
Más de DeNA
Más de DeNA (20)
DeNAのQCTマネジメント IaaS利用のベストプラクティス [AWS Summit Tokyo 2019]
- 1. S U M M I T Tok yo
- 2. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T DeNA の QCT マネジメント IaaS 利用のベストプラクティス 土屋 圭 株式会社ディー・エヌ・エー システム本部 IT 基盤部第四グループ
- 3. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 土屋 圭 (Kei Tsuchiya) • 所属 • システム本部 IT 基盤部第四グループ マネージャー • 経歴 • 2014年4月 大学院修士課程修了後，DeNA 新卒入社 • 2014年~ 国内向けゲームプラットフォームの運用を担当 • 2016年~ 超大規模なゲームタイトルの運用を担当 • 2017年~ チームリーダー • 2019年~ グループマネージャー (現職) • 全世界向けに展開するゲームおよびゲームプラットフォームのインフラを担当 • クラウドの全社的な利用を管理するチームのリーダーも兼任
- 4. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T アウトライン 背景 DeNA のインフラの概況とコストコントロールの必要性 QCT マネジメント コストコントロール施策の検討と実サービスへの適用 まとめ QCT マネジメントの成果と今後の展望
- 5. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 6. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T DeNA の QCT マネジメント • Quality 最高品質のインフラを提供する • Cost コストをきちんとコントロールする • Time インフラ提供までのリードタイムを短くする
- 7. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T DeNA インフラの概況 • オンプレからクラウドへ • メインのシステム基盤はオンプレ • 2013年~ クラウド利用開始，以降適材適所でクラウドを利用 • 2015年~ クラウド利用急増 • 2018年6月にクラウドへの全面移行を決定 [1], [2] • 移行プロジェクトスケジュール • 2018年~ 移行の準備期間 • クラウドに最適化したシステム基盤の実装・設計 • 既存クラウド利用サービスへのコストコントロール施策の適用 • 2019年~ 本格移行期間 • 2020年~ 完全移行，仕上げ期間 [1] オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか？ その舞台裏と今後の展望 [フルスイング] https://fullswing.dena.com/archives/2638 [2] DeNAのインフラ戦略 〜クラウドジャーニーの舞台裏〜 [DeNA TechCon 2019] https://www.slideshare.net/dena_tech/dena-dena-techcon-2019
- 8. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T コストコントロールの必要性 • クラウド化の最大の懸念はコスト • オンプレ環境では圧倒的な低コストを実現 • 工夫なしでクラウド化するとコストが 3 倍に • コストコントロール施策の検討 • クラウドならではの様々な施策を検討 • 未実施比 50% 削減が可能という試算結果に • QCT マネジメントの実証へ • 本格移行前にコストコントロール施策の効果を実証する必要があった • 大規模にクラウド利用中のサービスへ施策を適用することに
- 9. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 10. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 11. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 12. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 対象システムの構成図
- 13. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 対象システム構成の特徴 EC2 メインに利用 • オンプレのノウハウを最大限活用 • 柔軟な構成を組むことができる • マネージドサービスに比べ安価 複数 AZ に分散して配置 • 全コンポーネント均等に分散 • 1 AZ 障害時もサービス継続可能 内部通信の負荷分散は MyDNS • 負荷分散層を挟まずダイレクトに通信 • Weighted RR でのトラフィック制御 DB は MySQL on EC2 • Master HA による master 高可用性 • 高いスケーラビリティを確保 • Read: master-slave 構成 • Write: シャーディング (水平分割)
- 14. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 対象システムのコスト分析 EC2 (EBS, ELB 含む) ステートレスなサーバ群 (Proxy, Web, Cache, Daemon) ステートフルなサーバ群 (DB, Elasticsearch) 100 [%]908050 その他 その他 0 • コスト全体の 90% が EC2 • 最も支配的なステートレスサーバに対する施策は必須 • ステートフルサーバは性質上コスト削減は容易でないが，コストは大きく何らか対応が必要
- 15. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 16. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T コストコントロール施策一覧 ステートレス ステートフル オートスケーリング導入 ◎ × スポットインスタンス導入 ◎ × サーバ集約 △ ◎ インタンス最新化 ○ ○ リザーブドインスタンス適用 ○ ○ スペック・台数適正化 ○ ○ 効果の大きさ ◎: 大，○: 中，△: 小，×: なし
- 17. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 18. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリングの導入対象 台数が 非常に多い系統
- 19. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリングの導入検討 • これまで • 最大負荷を 50% の余裕を持って捌けるような台数に手動で調整 • オートスケールは入っていたが，安全弁用途 (スケールアウトしかしない) • 要件 • インフラ品質は最高水準維持 • 台数の自動調整，突発的なトラフィック急騰にも対応できるように わずか数秒の間にリクエスト数が 3 倍に リクエスト数の推移
- 20. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリングのシステム概要 • フルスクラッチで独自に開発 • マネージドサービスでは実現できない柔軟性の確保，既存資産の有効活用などの理由 API サーバ メトリクス 保管サーバ 1. メトリクス 取得 (CPU 使用率) 3. 台数増減 トリガ プロビジョニング 実行サーバ 4. 台数増減 2. メトリクス 監視 監視サーバ インスタンス起動 ping, ssh 疎通確認 アプリケーションのデプロイ Chef 適用 MyDNS へ登録 MyDNS から削除 アクセスが止まったか確認 ログ回収 インスタンス削除 アプリケーションの起動 ヘルスチェック 増設 撤去
- 21. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリングの高速化 • デプロイ・プロビジョニングの高速化 • 専用 AMI を定期作成，構築時のプロビジョニング処理やデプロイのスキップを可能にした • サーバ構築処理の高速化 • 構築処理は極限まで並列化，同時実行不可能な処理は複数インスタンスまとめて実行 同時実行可能な処理 同時実行不可能な処理 インスタンス 1 の構築処理 待ち時間 増設の時間短縮 インスタンス 2 の構築処理 インスタンス 3 の構築処理 インスタンス 1 の構築処理 インスタンス 2 の構築処理 インスタンス 3 の構築処理 一定時間，他の構築処理を待つ 3 インスタンス分の処理をまとめて実行
- 22. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリングの安定化 構築/撤去処理の安定化 • 適切なリトライ，タイムアウトの設定 • きめ細やかなエラーハンドリング 時間指定による増設 • 予測可能なトラフィック増への備え • 事前に増設して必要キャパシティ確保 監視 • オートスケール関連監視はオンコール • CPU 使用率の監視 • 台数監視 (事前増設の失敗検知) フラッピング防止 • 目標 CPU 使用率は 50% • 40% で撤去，60% で増設 必要台数計算の工夫 • 構築，撤去中のサーバ数も考慮 • 増やしすぎ，減らしすぎを防止 複数インスタンスファミリ • 特定インスタンスファミリの枯渇対策 • 例: c5 系枯渇時は c4, c3 も使う
- 23. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケーリング導入の効果 API サーバの費用 30% 減 安定稼働により運用工数ほぼゼロに インスタンス数の推移
- 24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポットインスタンスの導入対象 ステートレス サーバ
- 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポットインスタンスの導入検討 • 特徴 • オンデマンド比最大 90% の割引価格で利用できる EC2 インスタンス • ただし，いつ中断されるか分からず中断通知から 2 分後に強制シャットダウン • 安い代わりに高頻度で故障するインスタンスと考えれば良い • 要件 • インフラ品質は最高水準維持，特にストップ中断によるサービス影響はゼロにする • スポット率 100% • 導入に必要なこと • インスタンス管理の完全自動化 • インスタンスの構築/撤去，台数の維持/調整，サービス投入/切り離しなど • スポット中断への対策
- 27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 想定されるサービス影響とその対策 • スポット中断 • 何もせずにシャットダウンされれば当然 failover が完了するまでエラーが返る • シャットダウンされるまでに即座にサービスから切り離す必要がある スポット中断の常時監視 インスタンス撤去時の処理の非同期化 • 大量のスポット中断 • 残されたインスタンスの負荷が急激に上がり，エラーを返す可能性がある • オンデマンドインスタンスも一定数維持することによって， スポット全滅時も十分なキャパシティが確保されるような運用にすることで回避は可能 • しかし，こうするとスポット率を 100% にはできない 在庫特性を考慮したリスク軽減策の導入
- 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポット中断への対策 [1/2] • スポット中断通知の常時監視 • 監視 daemon をスポットインスタンス全台で稼働させる • リンクローカルアドレスを polling • 中断を検知したら即座にサービスからの切り離し処理を実行 • 例えば API サーバの場合は MyDNS から自身のレコードを削除する • DNS の TTL は 3 秒なので余裕を持って 2 分以内には切り離しが完了する スポットインスタンスMyDNS GET /meta-data/spot/instance-action 169.254.169.254 Delete DNS record
- 29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポット中断への対策 [2/2] • インスタンス撤去処理の非同期化 • 特にログ回収がネック，圧縮と s3 への転送が 2 分以内ではとても間に合わない • インスタンスシャットダウン後も EBS は残す • 別インスタンスに EBS をマウントし，ログの圧縮と s3 への転送を行う • 専用のオンデマンドインスタンスを各 AZ に配置，上記処理を実施するバッチを定期実行 PUT スポットインスタンス + EBS マウント スポット中断 ログ回収用 オンデマンドインスタンス s3
- 30. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 大量のスポット中断への対策 [1/4] • 在庫特性を考慮したリスク軽減策 • プール数を増やし，スポット全滅のリスクを実質ゼロにする • プールとはインスタンスタイプと AZ の組み合わせのこと : スポットとして利用可能な空きリソース
- 31. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 大量のスポット中断への対策 [2/4] • 20 プール以上でスポット率 100% が可能 • 過去の統計情報からサービス影響のリスクを計算 • 20 プールあれば在庫薄の時期でもキャパシティが半分以下になる確率はほぼゼロ あるプールのスポットインスタンスが全滅 しかし，全体のキャパシティに与える影響は軽微 プールごとのスポットインスタンス数
- 32. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 大量のスポット中断への対策 [3/4] • 20 プールの確保方法 • インスタンスファミリーだけを変えるような単純な方法ではうまくいかない • 異なるファミリー間の性能差が無視できない • m5 系の不安定さ (おそらくターボブーストによる) • 落ちやすい/枯渇しやすいインスタンスファミリーが存在 (c5n, r5 など) AZ 数 c5.4xlarge 5 c4.4xlarge 5 c3.4xlarge 5 m5.4xlarge 5 合計 20 ✖️ 同一ワークロードでの CPU 使用率 c5.4xlarge c4.4xlarge 25% の性能差
- 33. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 大量のスポット中断への対策 [4/4] • ファミリー統一，タイプをバラバラに • セカンダリ IP を活用し，コア数に応じた負荷分散を可能にした • セカンダリ IP も含めて MyDNS に登録する • 4xlarge と 9xlarge ではコア数は 2 倍ではないが，性能比は 2 倍になった c5.2xlarge c5.4xlarge c5.9xlarge Proxy AZ 数 IP 数 c5.2xlarge 5 1 c5.4xlarge 5 2 c5.9xlarge 5 3 c5d.9xlarge 5 3 合計 20 -
- 34. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 大量のスポット中断の実例 • Amazon Cyber Monday Sale • 2018/12/06 • 4 プールで運用 • 10分間で c5.2xlarge が全滅 • Amazon New Year Sale • 2019/01/02~04 • 9 プールで運用 • 10 分間でスポットの約 30% が中断 最高品質維持のためにプール数確保は必須 プールごとのスポットインスタンス数
- 35. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポットインスタンスを含めた台数維持 スポット オンデマンド スポットインスタンスが枯渇した場合は オンデマンドインスタンスを起動 スポットインスタンスが回復した場合は オンデマンドインスタンスを撤去 一定台数を指定されたスポット比率で維持 インスタンス数
- 36. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T オートスケール + スポットインスタンス 大部分をスポットでカバー オンデマンドも合わせて必要キャパシティを確保 インスタンス (IP Address) 数
- 37. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T スポットインスタンス導入の効果 • 試行錯誤を繰り返しスポット率 100% へ ステートレスサーバのコスト 60% 減 スポット中断によるサービス影響ゼロ スポット率
- 38. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 39. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T サーバ集約の対象 DB サーバ
- 40. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T ゲーム利用における DB サーバの特徴 • 負荷傾向 • リリース当初は IO (特に write) がボトルネック，CPU も高めに推移 • リリース後しばらく経過すると IO, disk size がボトルネック，CPU はほぼ使わない • 基本構成 • r4.2xlarge + EBS 2TB • Master HA による master 高可用性 • master-slave 構成，シャーディング (水平分割) 多用 • サーバ集約の必要性 • リリース時は write のスケーラビリティが非常に重要，大量のシャードを用意 • シャーディングされた DB は維持コストが非常に高い • スペックダウンにも限界があるため，サーバの集約が必須になる
- 41. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T ローカルストレージの利用 • 高 IO 性能で高集約率を実現 • IO がボトルネックの DB を集約するには，EBS の IO 性能では足りない • i3 インスタンスを活用，データを四重に保持しデータロストのリスクに備える 0 10,000 20,000 30,000 40,000 0 100 200 300 400 500 600 IOPS throughput [MB/s] rand read 16K rand write 16K read 16K write 16K r4.large, EBS 1TB i3.large※ 上記は当社環境での計測結果に基づいたものです。
- 42. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T DB サーバの集約方法 • 1 インスタンス上に複数 MySQL プロセスを動かす • セカンダリ IP を付与し，各 MySQL プロセスを bind • リソースを効率的に利用するための方法としてオンプレ環境で活用 • メンテなしで集約，リードタイム削減 • 各シャードの master から集約先へレプリケーションを張る • その後 Master HA によるオンライでの master 切替 • 再度スケールアウトさせることも可能 • 万一高負荷になっても即日スケールアウト可能 • DB サーバ数を 75% 削減 • 負荷傾向を見ながら段階的に集約を進めた Replication 旧 master 新 master
- 43. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T QCT マネジメント • 施策実施対象システムの概況 • 施策一覧 • オートスケーリング導入 • スポットインスタンス導入 • サーバ集約 • その他
- 44. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T その他の施策 • インスタンスタイプ最新化 • 最新のインスタンスは高性能かつ安価，例えば c3 を c5 換装するだけで 20% コスト減 • 台数・スペックの適正化 • オートスケールが入っていない系統は徹底的に性能管理，定期的にスペック見直し • オンプレと違い不要なリソースを削除すれば即座にコストメリットが得られる • リザーブドインスタンス適用 • 台数もスペックも変わらない系統には積極的に適用する • マネージドサービス活用 • 台数的に小規模なものは費用が割高でも管理工数を考えてマネージドへ • 例えば Redis は高可用性維持の手間を考え ElastiCache へ
- 45. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 46. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T コストコントロール施策の成果 EC2 ステートレスなサーバ群 ステートフルなサーバ群 100 [%]90 その他 その他 0 60% 超削減 Before After 40
- 47. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T まとめと今後の展望 • まとめ • クラウド移行の準備として，コストコントロール施策を実証 • 最終的にコストは何もしない場合と比べ 60% 以上削減 • QCT マネジメントにより，インフラ品質は最高品質維持，リードタイムも変わりなし • 今後の展望 • クラウドへの本格移行 • 本施策の仕組みを各サービスへ展開 • 継続して QCT マネジメントを実践 • まだまだ他にも実施できる施策がある • マネージドサービスの活用も積極的に検討 • DeNA は事業会社であり，インフラ運用が目的ではない
Notas del editor
- 皆さまこんにちは。 DeNA の土屋と申します。 本日は DeNA の QCT マネジメントと題しまして， 我々 DeNA のインフラエンジニアたちが IaaS を利用するにあたってどのようにして品質，コスト，リードタイムをマネジメントしてきたか，その具体的な方法についてお話をさせて頂きます。 よろしくお願いします。 ### 00:25
- まず始めに自己紹介をさせてください。 改めまして私土屋圭と申します。 現在システム本部 IT 基盤部第四グループというところに所属しています。 IT 基盤部はインフラエンジニアあるいは SRE と呼ばれるエンジニアの方々が集まる部署になります。 私自身は 2014 年に新卒で DeNA に入りまして，それ以来ずっと IT 基盤部に所属しています。 初めの 2 年間はモバゲープラットフォームを中心に，主にオンプレ環境でのインフラ運用を担当していました。 2016 年から全世界向けに提供する超大規模なゲームタイトルのインフラを担当し，この時期から本格的に AWS を触り始めました。 2017 年にそのチームのリーダ，そして今年からグループのマネージャーになり，現在は引き続き全世界向けに展開するゲームおよびゲームプラットフォームのインフラを担当しております。 本日はよろしくお願いします。 01:30
- 本日のアウトラインになります。 最初に背景として，DeNA のインフラの概況をご説明し，本日のメインの話題となるコストコントロールがなぜ必要になったか，その理由をご説明します。 続いて，そのコストコントロールを行うためにどのような方法を検討し，どのようにして運用中のサービスに適用していったかについてご説明します。 最後に，これらの施策の成果をまとめ，今後の展望についてお話しします。 02:05
- まず始めに背景についてご説明します。
- この発表のタイトルにもなっていますが， DeNA のインフラ部隊がミッションとしている QCT について，QCT という言葉に馴染みのない方もいらっしゃると思いますので，まずはインフラの文脈での QCT は何を指すかについてご説明します。 Quality は言わずもがな，インフラの品質を指しています。 オンプレもクラウドも関係なく，インフラ起因の障害はなくして、最高品質のシステム基盤を提供するという意味です。 続いて Cost について，DeNA 創業当初から 1 円でも安くというベンチャーマインドが染み付いており，これはインフラも例外ではありません。 したがって非常に高いコスト意識を持ってインフラ運用を行っています。 ただし，ただ安ければ良いという考えではありません。 必要なコストをきちんとコントロールして払うということです。 したがって，管理工数や利便性などに照らしてメリットがあるサービスや商品についてはたとえ割高であっても利用するという判断をしています。 最後に Time について，品質とコストを求めるあまり，インフラ提供までに何ヶ月もかかるような状態では DeNA 事業展開スピードにミートしません。たとえ非常識なスケジュールであっても安定してインフラを提供していくこともミッションとしています。 03:35
- 続いて DeNA のインフラの概況です。 DeNA は 2018年6月に非常に大きな決定をしました。 これまでメインに使ってきたオンプレ環境からクラウド環境へ移行するというものです。 ではこの移行プロジェクトどのように進むかと言いますと，全部で 3 年かけて大きく三つのステップを踏んで進んでいきます。 簡単にいうと準備，本格移行，仕上げという 3 つのステップです。 直近 1 年は最初のステップである準備として，システム基盤をクラウドに合わせて最適化するための設計や実装，移行スケジュールの精緻化などを行いつつ，私のグループではコストコントロールのための施策を実施してまいりました。 ではなぜこの準備のタイミングでコストコントロールが必要になったのか。 4:30
- その理由は，クラウド化の最大の懸念がコストであったからです。 オンプレ環境では圧倒的な低コストを実現していました。 これは，固定スペックのサーバを大量に購入することで，調達価格を下げたり，流動性を確保したり，さらにはサーバリソースを極限まで使い切るような工夫によるものです。 この状態からそのままクラウドに持っていくとコストが 3 倍に膨れ上がるってしまうことがわかりました。 工夫なしでクラウド化といっても，オンプレ環境のコスト圧縮ノウハウは織り込み済みで，それでもなお 3 倍になるという試算です そこでクラウドならではのさまざなコストコントロール施策の検討が必要になりました この段階ではまだ皮算用でしたが，検討の結果何もしない時に比べてなんとか 50% 程度は費用を下げられるという勝算が立ちました。 したがって，本格移行前に，検討した施策が本当に実現可能なのか， 特に Quality と Time について最高水準を維持した状態で Cost を下げられるかを実証する必要があり， すでに大規模にクラウドを利用しているサービスで実証することになりました。 05:55
- それでは実際に行ったコストコントロール施策の話に入っていきます。
- まず具体的な話を始める前に，施策を適用したシステムの構成についてご説明します。 06:15
- こちらが，施策対象となったシステムの構成図で，全世界向けに提供してるゲームサーバのものなります。 ご覧の通りで，特に複雑な構成はなく，前段にロードバランサ，プロキシサーバ，後段に API サーバ，さらにその後ろにキャッシュやデータベースサーバが存在し，非同期処理用のデーモンやキューサーバもいるという一般的なシステムになります。 あとはスペースの都合上アベイラビリティゾーンの数は 2 つになっていますが，実際には 5 つに配置しています。 06:40
- 特徴を列挙するとこのスライドのようになります。 いくつかピックアップして口頭でご説明します。 まずは EC2 メインで利用しているというところです。 これによってオンプレのノウハウを最大限活用することができます。 ほぼオンプレと同じような運用が可能になるので，インフラの運用者にとってもオンプレ，クラウドの違いをほぼ意識することなく運用することができます。 さらに柔軟な構成を組むことが可能で，例えば特定コンポーネント同士の相乗りだったり，マネージドサービスでは提供されていないミドルウェアを使ったりということも可能です。 あとはマネージドサービスに比べて安価であるという点も選択理由のひつです。 次に特筆すべきは，内部の負荷分散に MyDNS を使っている点です。 MyDNS というのは DNS レコードの保存に MySQL を用いている DNS サーバで，MySQL に対する SQL 文で DNS レコードを変更できます。 これは頻繁に DNS レコードの変更を行うようなユースケースでは非常に便利で，DeNA ではオンプレでもヘビーに使っているものです。 DNS を使うことでインターナルなサーバ同士の通信をダイレクトに行わせることができます。 無駄にホップ数を増やさないというのは，NW 品質の劣化に対して強い構成にするために重要です。 08:15
- 続いてコスト分析です。 EC2 をメインに使っているので，当然コストも 90% 程度が EC2 になります。 EC2 の中でさらに費用分析をしてみると，Proxy や Web といったステートレスなサーバの費用が半分強，DB などのステートフルなサーバの費用が半分弱というコスト構造になっています。 こういうコスト構造なので，まず最も支配的であるステートレスなサーバに対する施策の適用は必須です。 またステートフルなサーバは性質上コスト削減は非常に難しいのですが，コストは大きいので何らかの対策を取ることが必要になってきます。 09:20
- では，具体的な施策の話に入っていきます。 09:25
- 施策は大小さまざまな方法を比較検討しました。 その中で，実際に効果が大きかったものをいくつか表にまとめてみました。 本日はその中でもさらに背景を赤にしている 3 つの施策に絞って詳細をお話ししていきます。 上二つ，オートスケールとスポットインスタンス は，最もコストが支配的だったステートレスサーバに対する施策， サーバ集約はステートフルである DB サーバに対する施策になります。 09:55
- ではオートスケールから詳細をご説明していきます。 10:00
- オートスケールの対象は API サーバです。 なぜ API サーバなのか，理由は大きく 3 つあります。 1 つ目はスライドにも書いていますが，台数が非常に多い系統であることです。 そもそも台数が少ない場合は，それらの数を増減させたところで効果が小さいので，わざわざオートスケールさせる必要はありません。 2 つ目は負荷の変動が非常に大きいことです。 最大負荷と最小負荷の差が大きい系統ほど，オートスケールで得られるメリットが大きくなり，まさに API サーバはそのような傾向にあります。 3 つ目はスケーリングを行うための判断基準が明確であるためです。 API サーバは CPU ボトルネックでかつ，CPU は負荷に応じてほぼ線形に推移しますので，CPU だけ見ておけばよく，スケーリングの判断基準が極めてシンプルになります。 例えばデータベースなどはこんなに単純にいかなくて，CPU, IO, qps などなど様々な指標を観察する必要があって，かつ qps 低くても負荷は高いみたいなこともあって，スケーリングの判断が一筋縄ではいきません。 そう言う意味で，判断基準が明確な API サーバはオートスケールに適していると言えます。 11:40
- オートスケールを導入するにあたって，まずは「これまでの運用」と「求められる要件」について整理したいと思います。 これまで，API サーバは最大負荷を 50% の余裕を持って捌けるように、 つまり CPU 使用率が 50% になるように手動で台数を調整していました。 オートスケールも実は入ってはいたのですが，スケールアウトしかしないというまさに安全弁の用途でしかありませんでした。 したがって，コストもかかるし台数調整の工数もかかるというのがこれまでの現状でした。 続いて要件についてですが，まず最優先事項なのが，品質を落とさないということです。 これはいかなる理由があっても満たす必要があります。 加えて，系統全体の負荷が一定になるように台数の調整を自動で行うことが求められますが， ゲームサーバの特徴として，突発的なトラフィックの急騰にも対応できるようにする必要があります。 下のグラフは実際のゲームのリクエスト数の推移を表していますが，赤矢印の部分を見ていただくとわかる通り，リクエスト数がわずか数秒の間に 3 倍にまで跳ねるようなことが毎日起こります。 当然これに対応できなければキャパシティ不足でエラーを返してしまうので，こういうものにもきちんと対応できる必要があります。 13:00
- では，そのような要件をどのように実現していったかを説明していきますが， まずはオートスケーリング自体をどのように実現したか，そのシステム概要についてご説明します。 オートスケーリングを実現させる方法として，オートスケーリンググループなどマネージドなサービスもありますが，我々は独自でフルスクラッチで実現する方法をとりました。 この理由としては，このあとご説明するスポットインスタンス 導入でも必要になるのですが，例えば複数のインスタンスタイプ，ファミリーを混在させて使うなどの柔軟性を確保したり，先ほどご説明した通り，スケールアウトの部分はすでに作られていましたので，そこの資産を有効活用したりするためです。 内部で行なっていることを図にすると単純で， 最初にオートスケール対象のメトリクスを取得し，その情報専用サーバに保管します。 次にそのメトリクスを監視するサーバがいて，CPU 使用率が一定の閾値を超えた場合に台数を増やすあるいは減らすという指示を出します。 その指示に従って各種処理を行うサーバがいて，実際の増減がなされます。 スライド右側に実際の処理の流れを書き出していますが，サーバを足すだけ，あるいは減らすだけでも割と行うべき処理があることがわかります。 実際にはここに書き出している以上に細かい処理もあり，実際の処理のステップ数はこの倍以上はあります。 14:40
- 続いて，オートスケーリングの高速化の工夫についてご説明します。 オートスケーリングは，品質を維持する上で特に増設時の高速化が非常に重要になります。 増設が間に合わなかった場合，サービス影響に直結するためです。 そのために行ったことは大きく二つあります。 まずはデプロイやプロビジョニング処理の高速化です。 都度まっさらな OS からサーバを作っていたのでは当然時間がかかりますので，実際のアプリの最新コードや事前に実施できるプロビジョニングを適用した専用のインスタンスを構築し，そこから定期的に AMI を取得しておくことによって，これらの処理を短縮化したり，処理そのものをスキップ可能にしました。 2 つ目はサーバ構築処理自体の高速化です。 まず 1 つのサーバを構築するにあたって，並列に行って良いものは徹底的に並列で動かします。 その上で，複数のサーバに対して並列に実行できないような処理もあります。 そのような処理に対しては，下の図にもある通り，1 回の処理で複数インスタンスに対して適用できるような作りにしています。 こうすることで 1 台増設の時間は多少が長くなりますが，複数台増設する時間は大幅に短縮できます。 API サーバは非常に台数が多いので，1 台の増設時間よりも複数台の増設時間の方が重要です。 16:20
- 続いてオートスケーリングを安定して動かすために行った工夫についてお話しします。 このスライドにあるように様々なことを行なったのですが，特に重要な左側半分について口頭でご説明します。 まずは，構築撤去処理の安定化です。 先ほども少し触れましたが，構築あるいは撤去といっても，その具体的な処理内容は非常に多くのステップを含んでいます。 加えて，１日に何百台というサーバを作っては壊しということを繰り返すので，どこかしらでエラーがおきたり詰まったりということがおきます。その都度処理が止まるのではとても安定してオートスケールを動かすことはできないので， 各ステップに対して適切にリトライ，タイムアウトを設定でいるようにしたり，エラーハンドリングをかなり細かく行なったりしました。 2 つ目は時間指定による増設です。 1 つ前のスライドで高速化の話をしましたが，あのような工夫を行なっても，やはり増設には 2, 3 分は必ずかかってしまいます。 当然ながら数秒の間にトラフィックが急増するようなケースには対応できません。 そこで，そのようなトラフィックに対しては時間指定によって事前増設し対応することにしました。 急激なトラフィックというのは，例えばイベント開始のタイミングだったり，ゲーム内の日またぎの処理だったり，事前に予測できるものがほとんどなので，現時点ではこの方法で問題なく対応できています。 3 つ目は監視です。 API サーバはサービス稼働のための最重要系統であり，それの台数管理を行なっているオートスケーリングシステムは非常に重要です。万一うまく動かない場合は即サービス影響につながります。そこで，オートスケールの不具合が疑われるものは即座にインフラ担当者にオンコールで通知し，即時確認対応できるような体制を組んでいます。 18:25
- 以上で述べたような工夫により，オートスケールは安定して稼働するようになりました。 このグラフを見ていただくとわかる通り，導入前後の効果は一目瞭然で，結果的に費用は 30% 削減することができました。 また，これまで行なっていた手動による台数調整が不要になったため，API サーバの運用工数は実質ゼロになりました。 18:55
- 続いてスポットインスタンスのお話をします。 19:00
- スポットインスタンスの対象は赤枠で囲んでいる通り，ステートレスなサーバになります。 17:00
- すでにご存知の方も多くいらっしゃると思いますが，スポットインスタンス の特徴を簡単にご説明しますと， オンデマンドに比べて，非常に安価に利用できるというインスタンスです。 ただし，いつ落とされるかわからなくて，事前通知はあるのですが，その通知から 2 分で強制シャットダウンされてしまいます。 つまりは，安く使うことができるかわりに，非常に高頻度で故障するインスタンスであると捉えると運用に落とし込みやすくなります。 スポットを使うにあたっての要件について整理しますと， まずはオートスケーリングのときと同様に品質の最高水準維持というのは must な要件になります。 特に中断によるサービス影響を出すわけにはいきません。 この状態でさらにスポット率は 100% を目指すことにしました。 導入にあたって必要なことは大きく 2 つです。 1 つ目はインスタンス管理の完全自動化で，これはオートスケーリングの際に整備したシステムを少し拡張することで実現できました。 2 つ目のスポットインスタンス中断への対策というのがポイントになります。 20:25
- ではスポット中断の際，どのようなサービス影響が想定されるのかを考えてみます。 まずは普通にスポットが中断した場合ですが， いきなりシャットダウンされるわけですから，何もしなければ当然エラーを返してしまいます。 したがって，中断通知から 2 分以内にサービスから切り離すということが必要になります。 これを実現するために，2 つ対策を行いました。 スポット中断の常時監視と，インスタンス撤去処理の非同期化です。 詳細はこの後のスライドでご説明します。 次に，同時に大量のスポットが中断されたらどうなるかを考えてみます。 例えば全部で 100 台いるスポットのうち 70 台が同時に落ちたらどうなるか。 当然残りの 30 台ではトラフィックを捌ききれませんので CPU が張り付いてエラーを返してしまいます。 100 台中 50 台だけスポットにし，残りのオンデマンドは 50 台にすることでこの問題は回避できますが，そうしてしまうと当初の要件であるスポット 100% が達成できません。 そこで，スポットインスタンス は在庫であるということを考え，在庫の特性を考慮して大量に落とされる確率を実質ゼロにするという方法をとることにしました。 ではここからは，赤字で書いてあるものを説明していきます。 22:00
- まずはスポット中断の常時監視について， スポットの中断はあるエンドポイントを叩くことで判定できますので，そこを常時 polling するような daemon を作り， それをすべてのスポットインスタンス で動かすことにしました。 この daemon は中断を検知したら，そのインスタンスをサービスから切り離すための処理を実行します。 例えば API サーバであれば，自身のレコードを MyDNS から外します。 DNS の ttl は 3 秒に設定していますので，2 分以内には十分余裕をもってサービスからの切り離しが完了します。 22:55
- 次にインスタンス撤去処理の非同期化です。 我々の運用ではアクセスログやアプリのエラーログなど各種ログは EC2 インスタンス自体に残し，定期的に s3 へ put しています。 したがって，インスタンスを撤去する際はインスタンスに残っているログを s3 へ put する必要がありますが， これが 2 分以内ではとても間に合いません。 アクセスログのサイズは非常に大きくなりますので，圧縮するだけでも 2 分はかかってしまいます。 そこで，2 分以内にログを回収するのは諦め，ログ回収は非同期で行うことにしました。 具体的にはスポットインスタンス をシャットダウン後も EBS 自体は残す設定にしておき， その残った EBS からログを回収する専用のオンデマンドインスタンスを用意しました。 このインスタンスは残っている EBS を自身にマウントし，圧縮した上で s3 へ put してくれます。 こうすることで，2 分以内にインスタンスを terminate しても問題ない状態となりました。 24:05
- 続いて 2 つ目の問題である大量のスポット中断への対策です。 この問題には，使用するプール数を増やすことで対応することにしました。 ここでプール数というのはインスタンスタイプと AZ の組み合わせのことを指しています。 では在庫特性を考慮するとはどういうことかというのを下の図を用いてご説明します。 これはバージニアリージョンの 2 つの AZ にそれぞれ 3 種類のインスタンスタイプがいる様子を示しています。 すなわち，プール数は 2 * 3 で 6 個あるという状態です。 ここで赤字で書いてある c5.2xlarge について着目してみます。 あくまで一例ですが，1a では潤沢に在庫がある一方で，1b では間もなく在庫が枯渇しそうだということがわかると思います。 仮に，ここで 1b しか使っていなかった場合はどうなるでしょうか。 c5.2xlarge の需要が少しでも増えたタイミングで，1b の在庫はなくなり，結果としてスポット全滅ということになります。 一方で 1a の c5.2xlarge も用いている場合はどうなるか。 1a では在庫が潤沢にありますので，需要が増えたとしても 1b はなくなったとしても 1a は残るので全滅とはなりません。 このようにプール数を増やせば増やすほど，同時に大量のスポットが落とされるというリスクを下げられるということがわかると思います。 25:40
- では，スポットを 100% にするためにはプール数はいくつ必要になるのか。 我々の結論としては 20 プール以上です。 これくらいのプール数であれば，たとえ在庫が枯渇気味の時期であってもトータルとしてみれば十分スポットインスタンス を確保できるということがわかっています。 下のグラフは 20 プール使った場合のプールごとのインスタンスの数を表しています。 着目していただきたいのが赤枠で囲っているところで，黄色のプールのスポットがすべてなくなっています。 しかし全体の台数でみると，ほぼかわってないことがわかると思います。 このようにプール数を多く確保することで，特定プール全滅の影響を抑えることができます。 26:30
- ではどのようにして 20 プールを確保するのか。 左下の表のように，単純にコア数を揃えてインスタンスファミリーのみを変えてプール数を増やすというような単純な方法ではうまくいきまん。 それはなぜか，理由は 3 つあります。 1 つ目は異なるファミリー間の性能差が無視できないからです。 右下のグラフは c4 と c5 の同一ワークロード化の CPU 使用率を表していますが，実に 25% も差があることがわかると思います。 これでは単純に混ぜてしまうと c4 の性能に律速されてしまい，c5 のリソースは無駄となってしまいます。 2 つ目は不安定なインスタンスが存在するためです。 これは特に m5 系のインスタンスで顕著でしたが，おそらく同一ハードウェアに乗っている他のインスタンスが CPU を食うような処理を行っているタイミングで，我々が使っているインスタンスのクロック数が下がってしまうのではないかと推測しています。 3 つ目は明らかに落ちやすい，あるいは枯渇しやすいインスタンスファミリーが存在することです。 私たちが観測した範囲内では c5n あるいは r5 などのインスタンスは頻繁に中断され，プール数確保という目的の達成は困難でした。 28:00
- ではどのようにして 20 プールを確保するのか。 最終的にはファミリは統一し，タイプはバラバラにするという方法をとりました。 これでは当然コア数が異なってしまいますが，そこはセカンダリ IP を活用することで解消しました。 具体的にはコア数が多いインスタンスにより多くのセカンダリ IP を付与し，それらを MyDNS に登録することによってコア数に応じた負荷分散が可能にしました。 4x と 9x では単純にコア 2 倍にはならないのですが，9x の方はコンテキストスイッチなどのコアの管理のため CPU sys が多くなり， トータルとして性能比では 2 倍という結果になっています。 以上で大量のスポット中断への対策が整いました。 しかし、本当にこんなにたくさんのプールが必要なのかという疑問がわくとおもいます。 29:00
- このスライドでは実際にスポットインスタンス を運用している中で，大量のスポット中断があった例を 2 つあげています。 いずれの場合も，10 分間という短時間の間に大量のスポット中断がなされたことがわかると思います。 日常的には問題なくても，こういうエッジケースに備えて，やはり品質維持のためにはプール数の確保は必須であると言えます。 29:50
- 続いてスポットインスタンを実際に運用している様子をいくつかご紹介します。 まずオートスケーリングを入れていない系統での動作例です。 ちょうどグラフの真ん中あたりでスポットインスタンス が枯渇し，代わりにオンデマンドインスタンスが起動されているようすが見て取れると思います。 逆に在庫が回復してくると，今後はオンデマンドを落としスポットをインスタンスを上げている様子がわかると思います。 このようにスポット 100% になるように台数調整しつつも，スポットが足りない場合はオンデマンドを代わりに用いることで安定して運用できています。 30:10
- 続いてオートスケールと組み合わせて運用している API サーバの例です。 グラフの通りで，大部分をスポットインスタンス でカバーしつつ，特にトラフィックの跳ねのタイミングではオンデマンドインスタンスを組み合わせて必要なキャパシティを確保できている様子がわかると思います。 30:30
- 最後に，スポットインスタンス 導入の効果についてまとめます。 導入当初はスポット率は 10% ほどでしたが，そこから徐々に様子を見つつ不安要素の解消やシステムの改修を行いつつ， 3 ヶ月ほどかけて最終的にスポット率は 100% にすることができました。 これによってステートレスサーバのコストは 60% 減らすことに成功しています。 また，これまでご説明した工夫によってスポット中断によるサービスへの影響はこれまでゼロです。 31:10
- 次にサーバ集約についてご説明します。 31:15
- 集約対象は，データベースサーバです。 31:20
- まず，ゲームサーバにおけるデータベースの負荷傾向がどのようなものかについてご説明します。 データベースはリリース初日は IO, CPU ともに負荷が高く，特に IO がボトルネックになります。 一方リリースしてからしばらく時間が経ち，ユーザのアクティビティが落ち着くと CPU はほぼ使わなくなりますが，データは溜まり続けますので IO は引き続きボトルネックに，さらに disk size もボトルネックになってきます。 このような負荷傾向を持つデータベースサーバをどのような構成で運用してきたかというと， r4.2xlarge というメモリを多く持つインスタンスに，2TB という十分大きな EBS をアタッチするというのが基本的な構成でした。 Master の高可用性担保には Master HA という，DeNA で開発された自動 failover の仕組みを用いています。 また，read のスケーラビリティ確保のために master-slave 構成に， さらに write のスケーラビリティの確保のためにシャーディングを多用した構成にしています。 特にシャーディングを多用するような構成においては，運用の過程でサーバの集約を行う必要が出てきます。 なぜかというと，リリース時は write のスケーラビリティが非常に重要になりますので，大量のシャードを用意するのですが， これは維持コスが非常に高く，負荷が落ち着いてきたタイミングでシュリンクしなければならないためです。 スペックダウンにも限界があり，2xlarge から large にすることはできますが，さすがに 2 コアではちょっと心配です。 こういう理由からサーバ集約というのが必須になります。 33:05
- サーバを集約するにあたって，単純に r4 インスタンスに EBS をマウントした構成に集約することは IO がボトルネックになり不可能でした。 そこで注目したのがローカルストレージを持つインスタンスです。 下のグラフは i3 インスタンスと EBS の io 性能を比較したグラフになります。 IOPS, スループット共に i3 インスタンスは非常に高い性能を発揮していることが分かると思います。 ただし，stop/start をするとデータが消えてしまうことが大きな問題です。 この問題に対してはデータを 4 重に持つことで備えることにしました。 通常はデータは 2 重，3 重程度しか持たないのですが，4 重に持つことでデータロストのリスクを下げています。 また万一の事態に備えて，mysql のフルダンプを 1 日 1 回取得し，s3 に保管するということも行なっています。 これで集約のための準備が整いました。 34:10
- いよいよ集約を進めていくことになりますが，普通に集約するとなるとゲームをメンテナンスに入れることになります。 なぜかというと特定 shard のデータベースに他の shard のデータを流し込んむことになりますので， これをオンラインで行うのは不可能なためです。 それでは各所との調整が必要になりますし，インフラ起因でのメンテを強いてしまうことになります。 そこでとった方法が 1 インスタンス上に MySQL プロセスを複数動かすという方法です。 これは 1 インスタンスに複数 IP を付与して，それらに MySQL をバインドするというもので，オンプレ環境でも活用されてきた方法です。 この方法を用いることで，オンラインで，すなわちメンテナンスなしでの集約が可能になります。 簡単に流れをご説明しますと各シャードのマスタサーバから集約先の各 MySQL プロセスにレプリケーションをはり， その後 MHA によるオンライでの master 切り替えを実施していくだけです。 こうすることで，仮にまた負荷が上がった場合は再度バラせば良いだけなので，即日中に再度スケールアウトすることも可能になります。 このような集約を繰り返すことで，最終的にデータベースサーバの数は 75% 削減することができました。 また，データベースの集約のために必要なリードタイムを短縮することもできました。 35:40
- 最後にその他で効果があった施策を簡単にご説明します。 35：50
- まずはインスタンスタイプの最新化です。 EC2 は結構な頻度で新しいインスタンスタイプがリリースされていますが，これらは性能が良くなっているだけでなく単価自体も下がっています。例えば c3 インスタンスと c5 インスタンスを比較した時，なんと c5 の方が 20% ほどコストが安くなります。 したがって，積極的に新しいインスタンスへ換装するということを行いました。 続いて台数やスペックの適正化も随時行いました。 オートスケールが入っている系統は放置で良いのですが，そうでない系統は徹底的に性能を管理して，定期的にスペックの見直しを行いました。すでにサーバを買ってしまっているオンプレ環境とは違って，不要なリソースを削除することで即座にコストメリットが得られるクラウド環境では，こういう地道な積み重ねも非常に大きな効果となります。 また，リザーブドインスタンスも積極的に活用しました。監視サーバやメトリクス用のサーバなどは負荷がほぼ変わらないので，1 年間塩漬けにするという意味で RI を適用しています。 最後にマネージドサービスの活用ついて，安ければ良いという考え方ではないということは最初にお話したと思いますが，管理工数や利便性を考えてメリットがあるものについては多少割高でもマネージドサービスも利用しました。その一例として，例えば Redis は利用する台数の割に高可用性を維持しながら運用する手間がかさむので ElastiCache を利用しています。 時間の都合上全て載せることはできませんでしたが，このスライド以外にも様々な施策を適用し，この 1 年間試行錯誤を繰り返しました。 37:35
- 最後にまとめを行います。 37:40
- コストコントロール施策の成果としては，最終的に 60% 以上費用を削減することに成功しました。 当初は 50% 減らせると見込んでいましたので，それをさらに上回るような成果が得られたことになります。 38:00
- まとめます。 クラウド移行の準備期間であったこの 1 年間，最大の懸念であったコストを削減するため，様々なコストコのトロール施策を実証しました。 その結果，最終的に何もしない場合に比べて 60% 以上コストを減らすことに成功しました。 また，コストだけを追求するだけでなく，品質およびリードタイム，これらも高い水準を維持した状態で実施することができました。 今後の展望ですが，今年からクラウドへの本格移行が始まります。 この発表でご紹介した施策はこれからクラウドへ移行する各サービスへも展開していく予定です。 また，すでにクラウド上で稼働しているサービスに対しては継続して QCT マネジメントを行なっていきます。 まだまだ改善できることはあると考えています。 また，現時点ではまだ EC2 がメインのシステム構成ではありますが，マネージドサービスも積極的に活用していきたい考えです。 これは DeNA は事業会社であり，インフラ運用が目的ではないという考え方からです。 以上になります，ご静聴いただきありがとうございました。 39:35