「戦国炎舞 -KIZNA-」で行ったAWSのコスト最適化の話

by CyberAgent SGE Engineer

Slide 1

Slide 1 text

「戦国炎舞 -KIZNA-」で行った AWSのコスト最適化の話株式会社サムザップ SRE　山﨑弘太郎

Slide 2

Slide 2 text

自己紹介山﨑弘太郎株式会社サムザップ戦国炎舞 -KIZNA- SRE 最近はまっていること：自作キーボード 2

Slide 3

Slide 3 text

会社概要 • 株式会社サムザップ • 2009年5月CyberAgent子会社として設立 • 事業内容 • スマートフォン向けゲームアプリの企画、運営、配信 3

Slide 4

Slide 4 text

提供サービス戦国炎舞 - KIZNA - ©2019 暁なつめ・三嶋くろね／ KADOKAWA／映画このすば製作委員会 ©Sumzap, Inc. この素晴らしい世界に祝福を！ファンタスティックデイズ 2013年4月配信開始戦国時代を舞台にしたカードバトルゲーム 1日3回20人対20人のリアルタイムバトル「合戦」が行われる 2020年2月配信開始ラノベやアニメで大人気の『このすば』初のスマホゲームゲームオリジナルのキャラクターやストーリーも登場 4

Slide 5

Slide 5 text

Sumzap Engineering Blog tech.sumzap.co.jp 5

Slide 6

Slide 6 text

概要 2019年2月に戦国炎舞はAWSに移行しました。移行後にクラウドの特性を活かしたコスト最適化に取り組んだ結果、移行前と比べて月額インフラ費用を約 50%削減できました。インフラ費用を抑えたいが何をすれば良いかわからないという方向けに、サムザップで行った施策の中から導入難度が低く、コスト削減効果が高かったものを中心にお話しします 6

Slide 7

Slide 7 text

無駄なコストを省いて、そのお金を事業の成長のために必要な投資に回せるようにする。コスト最適化の目的事業成長のための投資に 7

Slide 8

Slide 8 text

コスト最適化を実施する前に 8

Slide 9

Slide 9 text

請求画面やCost Explorerなどを用いてどこでいくら費用が発生しているのかを調べるコスト調査・分析 DB Web Redis1 Redis2 cache その他 9

Slide 10

Slide 10 text

最適化前環境別AWSコスト本番環境のコストが全体の94% （devとstgのコストは僅か） →本番環境のコスト最適化を優先（devとstgは工数がかからないものを実施） 10

Slide 11

Slide 11 text

本番環境の用途別コスト特定の用途のコストが突出して多くはない Web/ DB/ Redisの３つで全体の92%のコストがかかっている。 →３つそれぞれでコスト最適化を実施。作業の優先度は施策のコスト削減効果と導入難度を基に決める。 11

Slide 12

Slide 12 text

AWSでのコスト最適化は大きく次の３種類に分けられる 1. アーキテクチャの最適化 2. 割引オプションの活用 3. リソースの無駄をなくすコスト最適化方法 12

Slide 13

Slide 13 text

1. アーキテクチャの最適化 ○ Web時限オートスケール、DB集約 2. 割引オプションの活用 ○ リザーブドインスタンス ○ スポットインスタンス 3. リソースの無駄をなくす ○ 使用していないAWSリソースの削除 ○ インスタンスタイプ/台数の最適化 ○ 休日・夜間のインスタンス停止戦国炎舞で実施したこと 13

Slide 14

Slide 14 text

戦国炎舞で実施したこと休日・夜間のインスタンス停止効果複雑 Webオートスケール不要なAWSリソース削除リザーブドインスタンス DB集約スポットインスタンスインスタンスタイプ/台数の最適化 14

Slide 15

Slide 15 text

今日話すこと休日・夜間のインスタンス停止効果複雑 Webオートスケール不要なAWSリソース削除リザーブドインスタンス DB集約スポットインスタンスインスタンスタイプ/台数の最適化 15

Slide 16

Slide 16 text

リザーブドインスタンスインスタンスタイプ/台数の最適化スポットインスタンスの活用時限オートスケール休日、深夜の開発環境インスタンス停止 16

Slide 17

Slide 17 text

リザーブドインスタンス(RI)とは • １年または３年の長期利用をコミットすることで、オンデマンドインスタンス料金に比べて大幅な割引きを受ける権利が与えられる • 期間が長く、前払い料金が多いほど割引率が高い • 常時稼働するインスタンスでの利用に適している 17

Slide 18

Slide 18 text

AWS公式の料金表からオンデマンド価格との損益分岐点を計算 RI購入の判断 18

Slide 19

Slide 19 text

オンデマンド価格との損益分岐点 1年累積額利用期間年間204日以上利用するなら、 1年RIを購入した方がお得例：db.r5.xlargeを1年RI、全額前払いで購入した場合オンデマンドスタンダード1年 19

Slide 20

Slide 20 text

• スタンダード１年間 • 一部前払い • Auroraの全インスタンス購入した主なRI 20

Slide 21

Slide 21 text

• 本番環境 • DBコスト 43％減効果 RI購入 21

Slide 22

Slide 22 text

POINT ・RI購入は組織の経営層、PJ責任者、経理と早めに相談 22

Slide 23

Slide 23 text

リザーブドインスタンスインスタンスタイプ/台数の最適化スポットインスタンスの活用時限オートスケール休日、深夜の開発環境インスタンス停止 23

Slide 24

Slide 24 text

インスタンスタイプ/台数の最適化モニタリングツールでリソース使用状況を確認しながら、インスタンスタイプ、台数を調整する。 AWS移行のタイミングでは移行前の環境に近いスペックのインスタンスを使っていたが、コストパフォーマンスの良い新しい世代のインスタンスに置き換えていった。 24

Slide 25

Slide 25 text

効果 web 25%減 redis 10%減 RI購入台数 25

Slide 26

Slide 26 text

インスタンスファミリーを跨いだ適切なインスタンスの提案および適用した場合の予想節約額を教えてくれる。さらに割引オプションを購入した場合の推定節約額も確認可能。 Cost Explorerの推奨事項を使うあなたm5.2xlarge使ってるけど、c5.xlargeの方が良さそうです。月$203 * 台数分節約できるよ。なんとー 26

Slide 27

Slide 27 text

Cost Explorerの推奨事項を使う 27 Cost Explorerの例

Slide 28

Slide 28 text

POINT • 新しい世代のインスタンスを使う • CostExplorerの推奨機能とモニタリングツールを併用する • CostExplorerの推奨はあくまで推奨 ○ インスタンスタイプを変更して問題ないかは自分たちで調べてから判断 28

Slide 29

Slide 29 text

リザーブドインスタンスインスタンスタイプ/台数の最適化スポットインスタンスの活用時限オートスケール休日、深夜の開発環境インスタンス停止 29

Slide 30

Slide 30 text

支払い方法 1. オンデマンド 2. スポットインスタンス 3. Saving Plans 4. RI 5. Dedicated Hosts Amazon EC2 インスタンス 30

Slide 31

Slide 31 text

• 未使用のEC2を入札方式で利用 ○ キャパシティが確保できない場合 ○ 稼働中インスタンスが中断される場合 • オンデマンド比で最大90%以上の割引 • EC2 Auto Scaling, ECSなどから利用できるスポットインスタンス 31

Slide 32

Slide 32 text

キャパシティの安全な確保 • プールの多様化 • 負荷見積もり ○ 性能の低いもので計算(c5.9xlarge) ○ プール2つのインスタンスがすべて落ちても問題ないインスタンス数スポットインスタンスの活用 32

Slide 33

Slide 33 text

スポットインスタンスの中断の対応 • 2分前終了通知 ○ LBからの切り離し ○ ログ収集エージェントの安全な停止 • アプリ/デプロイへの影響 ○ デプロイ中のインスタンスの増減など • デプロイ時間の短縮スポットインスタンスの活用 33

Slide 34

Slide 34 text

効果 • 約10%減 • 過剰性能のインスタンス • RIの適用範囲外 RI購入台数スポットインスタンス 34

Slide 35

Slide 35 text

• キャパシティの安全な確保 • スポットインスタンスの中断への備え • Quotaの申請が必要 POINT 忘れてた・・・ 35

Slide 36

Slide 36 text

リザーブドインスタンスインスタンスタイプ/台数の最適化スポットインスタンスの活用時限オートスケール休日、深夜の開発環境インスタンス停止 36

Slide 37

Slide 37 text

• 1日3回の定期的なwebへのリクエスト集中 ○ scheduled action • ゲームイベントによるリクエスト数の増減 ○ CloudWatch + Lambdaで増設前にゲーム情報を取得 scheduled actionのキャパシティ変更時限オートスケーリング 1日3回のリクエスト集中 37

Slide 38

Slide 38 text

webサーバーを24時間起動させつづけた場合と比べて約 43%の削減効果 38

Slide 39

Slide 39 text

POINT • キャパシティの確保 ○ 増設失敗に備え、リクエスト集中時間の前にインスタンス数をチェック 39

Slide 40

Slide 40 text

リザーブドインスタンスインスタンスタイプ/台数の最適化スポットインスタンスの活用時限オートスケール休日、深夜の開発環境インスタンス停止 40

Slide 41

Slide 41 text

• 停止期間平日　0:00〜9:00 (9h) 土日　0:00〜24:00 (24h) 55% 停止 • 対象: EC2、RDS • Slack Actionで起動・停止休日・深夜のサーバー停止(dev/stg) 41

Slide 42

Slide 42 text

効果開発環境の AWSコスト39%減 42

Slide 43

Slide 43 text

戦国炎舞のインフラコスト AWSコスト 49%減 43

Slide 44

Slide 44 text

今後検討していること • Savings Plans • DB・Redis集約 44

Slide 45

Slide 45 text

• 支払い方法と損益分岐点からRI購入 • Cost Explorer推奨事項を参考にインスタンスタイプ・台数を最適化 • 中断・キャパシティ対策を行いスポットインスタンスを活用 • CloudWatch・Lambdaでより柔軟な時限オートスケーリング • CloudWatch・Lambda・Slack Actionで開発環境の休日、夜間のインスタンス停止・再開まとめ 45

Slide 46

Slide 46 text

ご清聴ありがとうございました 46