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の3つで全体の92%の コストがかかっている。 →3つそれぞれでコスト最適化を実施。 作業の優先度は施策のコスト削減効果と 導入難度を基に決める。 11

Slide 12

Slide 12 text

AWSでのコスト最適化は大きく次の3種類に分けられる 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)とは • 1年または3年の長期利用をコミットすることで、 オンデマンドインスタンス料金に比べて 大幅な割引きを受ける権利が与えられる • 期間が長く、前払い料金が多いほど割引率が高い • 常時稼働するインスタンスでの利用に適している 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

• スタンダード1年間 • 一部前払い • 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