大規模ゲームタイトルのIaaSコストマネジメントへの技術アプローチについて / A technical approach to IaaS cost management for large-scale game titles

by Builders Box

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 天野知樹  自己紹介  全世界向けゲームを運用する  IaaS インフラチームのリーダー    メンバー数7人 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. スポットインスタンスの活用 5 南場「まず、ステートレスサーバーとしてスポットインスタンスを徹底的に活用するということです。このステートレスとステートフルを分けてスポットインスタンスを使うというのは他の会社でもやっているかもしれませんが、当社の場合はエグいほどそれを徹底しました。    　もちろんオンデマンド注文が入ると2分前の告知で落ちてしまうわけで、だからこそ安いのですが「2分あれば対応できるよ」という我々の技術陣、エンジニアのオンプレ時代から培ってきた高い技術力、対応力と相まってそれが実現できたということです。」    弊社フルスイング記事より抜粋  https://fullswing.dena.com/archives/7425 

Slide 6

Slide 6 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. スポット技術の中身 6 「2分あれば対応できるよ」    とは言ったものの、実際に2分で対応するのは無理です。    サーバが立ち上がってサービス可能な状態にするには約3〜5分かかる  (インスタンス起動 > ssh 可能確認 > chef > 設定ファイルのrsync > Rails の bundle install > サービスの正常性確認 > サービスに入れる)    つまり、  2分前のスポット中断通知を受け取ってから、オンデマンドを立ち上げ始めたのでは、間に合わない     

Slide 7

Slide 7 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. スポット技術の中身（理論） 7 解決のポイントは以下3つ    スポットプールを多数使用して、落ちるタイミングを分散  ○ プールは AZ とインスタンスタイプの組み合わせ  ○ たくさんプールを使えば、それが落ちたときの影響は極小化  ○ 多数のプールが同時に落ちなければサービスは維持される    プールのインスタンスの性能は揃える  ○ CPU使用率は常に均一にする (c5 と c4 を混ぜるのはNG)  ○ 性能が低いインスタンスが混じると、それがボトルネックになる    スポットが立たないプールはオンデマンドを立てる  ○ プールの細分化を維持    その結果、サイバーマンデーやニューイヤーセール等のスポットが全滅するようなときでも、サービスは正常に維持  平常時のステートレスサーバのスポット率は、ほぼ 100%  

Slide 8

Slide 8 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. スポット技術の中身（実装） 8 AZ 数 IP 数 c5.2xlarge 5 1 c5.4xlarge 5 2 c5.9xlarge 5 4 c5d.9xlarge 5 4 合計 20 - Proxy c5.2xlarge c5.4xlarge c5.9xlarge ● ファミリー統一、タイプをバラバラに  ○ セカンダリ IP を活用し、コア数に応じた負荷分散    4xlarge と 9xlarge ではコア数は 2 倍ではないが、性能比は 2 倍になった 

Slide 9

Slide 9 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. 独自実装の AutoScale 9 南場「サービス単位で何時がピークとかそういうことに加えて、各サービスいろんな施策を打つわけなんですね。たとえばゲームの施策やイベント。ゲームのイベントを開始する時は相当なトラフィックが集中します。そしてイベントにおいてもゲームの中にいくつもヤマ場をつくっていくわけです。かつイベントの終盤では、ものすごい駆け込みのトラフィックが集中するわけです。    　そういったことをきめ細かく把握して、なるべく正確に予測をして、絶対にピークは落とさない。落とさないけれどもきめ細かくスケーリングするということで相当なコスト削減を実現しました。」    弊社フルスイング記事より抜粋  https://fullswing.dena.com/archives/7425 

Slide 10

Slide 10 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. 独自 AutoScaling 技術の中身 10 ● 1秒単位でCPU使用率を取得し、DBに記録、autosacler は常にその DBを参照して、急激な負荷増加に対しては即座に autoscale を発動させる    ● 増加させるサーバは先ほどのスポットインスタンスと統合しており、リソース不足のプールではオンデマンドを立てるし、リソースがあればスポットを立てる    ● 各種サーバを自動的にs-in させるまでの、ワークフローやエラーハンドリング(Step Function的な機能をEC2の中で実行)    ● 時間指定による増設、タイミングはプロダクトチームと連携    ● 台数増設失敗時の監視 

Slide 11

Slide 11 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. 南場「シャーディングではもちろんデータを分割して対応するわけですけれども、サービスをローンチした時にはユーザーが殺到します。サービスの種類にもよりますけれど、多くのサービスにおいて最初に入ったユーザーがすべてずっとアクティブで居続けることはなく、一部のユーザーはアクティブでなくなります。そのため、少し時間が経過して落ち着いたときに分割したデータを統合していくということを行いました。    　サービスを全く止めずにデータを統合するというのは極めて高い技術力を要することで、サービスをローンチしてから3ヶ月後に落ち着いた時、半年後、1年後という単位でかなりきめ細かく調整をし、台数にして75％も削減できたということです。」    弊社フルスイング記事より抜粋  https://fullswing.dena.com/archives/7425    Sharding の調整で、データベース台数を削減 11

Slide 12

Slide 12 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. Sharding 調整の中身 12 ● ゲームをメンテナンスに入れずに shard 統合を実施    ● i3/i3en インスタンスの圧倒的なIOPS性能を生かして、高い集約率を達成                NVMe の IOPS はAWS の公称値を掲載   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html   vCPUs Memory NVMe IOPS r/w Cost i3.2xlarge 8 61GiB 1.9TB 41万/18万 $456/月 r5.2xlarge 8 64GiB - - $368/月

Slide 13

Slide 13 text

Slide 14

Slide 14 text

　　　　　　　　　　　　　　　　　　　　　　 © DeNA Co., Ltd. まとめ 14 IaaS は柔軟性とコストマネジメントに優れる    AWS Summit 南場登壇動画（Amazon Web Service Japan 公式 Youtubeチャネルより） https://youtu.be/AIoItC51iac?t=25m16s    スポットインスタンスでサービス中断を起こさないための方法 https://engineer.dena.com/posts/2020.01/spot-instances-availability/ 停止メンテ無しに MySQL を Shard 統合をする方法 https://engineer.dena.com/posts/2019.12/multi-instance/