【レポート】DeNA の QCT マネジメント IaaS 利用のベストプラクティス #AWSSummit

こんにちは、望月です。

2019/6/12(水)~14(金) の期間で開催されている AWS Summit Tokyo 2019 に参加しています!

本記事は「DeNA の QCT マネジメント IaaS 利用のベストプラクティス」のレポートになります。

登壇者

  • 株式会社ディー・エヌ・エーシステム本部IT基盤部第四グループグループマネジャー
    • 土屋 圭

DeNA は 2018 年 6 月にクラウドへ全面移行する決断をし,以来クラウド環境において高品質なインフラを低コストかつ短期間で実現するための取り組みを進めてきました。本発表では,その中で最大の懸念であったコストコントロールのための施策を中心に,オートスケールやスポットインスタンス活用等の具体的な手段の検討から実際に運用中のサービスに導入するまでの流れや,直面した問題とその解決策,効果を交えつつ,高品質・低コスト・高速ローンチをどのように実現してきたかをお話しします。

レポート

アウトライン

  • 背景
  • QCTマネジメント
  • まとめ

背景

  • QCTマネジメント
    • Quality
      • 最高品質のインフラを提供する
    • Cost
      • コストをきちんとコントロールする
    • Time
      • インフラ提供までのリードタイムを短くする
  • インフラの概況
    • オンプレからクラウドへ
      • メインのシステム基盤はオンプレ
      • 2018年6月にクラウドへの前面移行を決定
  • コストコントロールの必要性
    • クラウド化の最大の懸念はコスト
      • 工夫なしにクラウド化するとコストが3倍に
    • コストコントロール施策の検討
    • QCTマネジメントの実証へ

QCTマネジメント

  • 移行対象システム構成の特徴
    • EC2メインに利用
      • オンプレのノウハウを最大限活用
      • 柔軟な構成を組むことができる
    • 複数AZに分散して配置
    • 内部通信の負荷分散はMyDNS
    • DBはMySQL on EC2
      • Master HAによるmaster高可用性
  • 対象システムのコスト分析
    • コスト全体の90%がEC2
      • ステートレスサーバに対する施策が必須
  • 施策一覧
    • コストコントロール施策
      • オートスケールの導入
        • オートスケールの導入検討
          • 台数の自動調整、突発的なトラフィック急騰にも対応できるように
        • オートスケールの導入
          • 台数が多いサーバに対して導入すると効果が高い
          • スケーリングさせる基準が明確なサーバに導入
            • CPU使用率など
        • オートスケーリングの安定化
          • 構築/撤去処理の安定化
            • リトライ、タイムアウトの設定
            • エラーハンドリング
          • 時間指定による増設
            • 予測可能なトラフィックの備え
          • 監視
          • フラッピング防止
            • 目標CPU使用率は50%
            • 40%で撤去、60%で増設
          • 必要台数計算の工夫
          • 複数インスタンスファミリ
        • オートスケーリングの高速化
          • デプロイ・プロビジョニングの高速化
            • 専用AMIの定期作成
          • サーバ構築処理の高速化
            • 構築処理は並列化、同時実行不可能な処理は複数インスタンスまとめて実行し、増設の時間端出
        • オートスケーリングのシステム概要
          • フルスクラッチで独自実装
            • 柔軟性の確保、既存資産の有効活用のため、独自実装した
        • オートスケール導入の効果
          • APIサーバの費用30%減
          • 安定稼働により運用コストは0に
      • スポットインスタンスの導入
        • スポットインスタンスの導入検討
          • 安い代わりに高頻度で故障するインスタンスと考えれば良い
          • 要件としてサービス影響はゼロにする
          • スポット中断への対策
        • 想定されるサービス影響とその対策
          • スポット中断
            • スポット中断の常時監視
            • インスタンス撤去時の処理の非同期化
          • 大量のスポット中断
            • 在庫特性を考慮したリスク削減策の導入
        • スポット中断の対策
          • スポット中断の常時監視
            • 監視daemonをスポットインスタンスに導入する
          • インスタンス撤去時の処理の非同期化
            • インスタンスシャットダウン後もEBSは残す
            • 専用のオンデマンドインスタンスにEBSをマウントし、ログの圧縮とS3への転送を行う
        • 大量のスポット中断の対策
          • 在庫特性を考慮したリスク削減策
            • プール数を増やし、スポット全滅のリスクを実質ゼロに
            • プールとはインスタンスタイプとAZの組み合わせのこと
          • 20プール以上でスポット率100%が可能
          • 20プールの確保方法
            • インスタンスファミリーだけを変えるような単純な方法ではうまくいかない
            • 異なるファミリー間の性能差が無視できない
            • m5系の不安定さ
            • 落ちやすい/枯渇しやすいインスタンスファミリーが存在
            • ファミリー統一、タイプをバラバラにすることで20プールを確保
          • 大量のスポット中断は発生しうるため、最高品質を保つためには対策は必須
        • スポットインスタンス導入の効果
          • ステートレスサーバのコストは60%減
      • サーバ集約の対象
        • ゲーム利用におけるDBサーバの特徴
          • リリース時はwriteのスケーラビリティが非常に重要、大量のシェードを用意
          • シェーディングされたDBは維持コストが非常に高い
          • スペックダウンも限界があるため、サーバの集約が必須
        • ローカルストレージの利用
          • 高IO性能で高集約率を実現
            • i3インスタンスを活用、データを四重に保持しデータロストのリストに備える
        • DBサーバの集約方法
          • 1インスタンス上で複数MySQLプロセスを動かす
            • セカンダリIPを付与し、各MySQLプロセスをbind
          • メンテなしで集約、リードタイム削減
          • DBサーバ数を75%削減
      • その他の施策
        • インスタンスタイプ最新化
          • 最新インスタンスは高機能かつ安価
        • 台数・スペックの適正化
          • オンプレと違い不要なリソースを削除すれば即座にコストメリットが得られる
        • リザーブドインスタンス適用
        • マネージドサービス活用
          • 管理工数を削減

まとめ

  • 60%以上コスト削減
  • QCTマネジメントにより、インフラ品質は最高品質維持、リードタイムも変わりなし
  • 今後の展望
    • クラウドへの本格移行
    • 継続してQCTマネジメントを実践
    • マネージドサービスを積極的に利用

最後に

DeNA様で取り組まれているQCTマネジメントのお話を聞くことができて大変勉強になりました。

オートスケーリングやスポットインスタンスについて、最高品質を維持するため非常に工夫されていると感じました。

その一方で、インスタンスタイプ最新化、台数・スペックの適正化、リザーブドインスタンス適用、マネージドサービス活用といった基本的なコスト最適化についても実施されており、こちらについては、今すぐ検討、実施できる部分かと思いますので、ぜひ、一度コストが気になっている方は確認したほうがよいかと思います。