KLab TECH Meetup #3 クラウド利用の変遷

1. クラウド利用の変遷
インフラマネジメント部 福間

2. 自己紹介
名前: 福間雅弘
前職: SIer
趣味: 釣り
好きなAWSサービス: AWS Athena

3. KLabの仲間 募集しています
● 私がSIer時代に感じていたこと
○ 何か新しい技術を触りたいなぁ…
○ 自由にシステムを触ってインフラでやりたいこと、いろいろ実現させたいなぁ…
○ やりたいことを実現するための、組織的なハードルが高いなぁ…
● こういう事を考えているあなた、ぜひKLabの仲間としてお越しください
● KLabはこういう会社です
○ 個人の裁量範囲が広く、新しい技術に積極的にチャレンジできる
○ 経営層と距離感が近いので、やりたいことを実現させやすい

4. Agenda
● KLabのインフラ
● クラウドサービスの利用変遷
● 落とし穴関連
● まとめ

5. KLabのインフラ

6. ゲームのインフラとして要求されること
● 最も重要なことは
○ 可用性：いつでも、好きな時に遊べる！
○ 低遅延：プレイ中に応答の悪さでイライラすることがない！
● 最適なインフラが準備されているのであれば
○ 最適なクライアント
○ 最適なサーバコード
● を準備してもらえばよい

7. と、いうわけにいかないのが辛いところ…
● 利用者が増えると
○ リクエスト数が増加してNW帯域が増え…
○ サーバのCPU利用率が跳ね上がり…
○ メモリが不足し…
○ ディスクのIOが悲鳴をあげ…
● そしてシステムは止まり、ゲームはメンテナンス…
● 利用者が増えても可用性/低遅延を保証するための「拡張性」が求められる。

8. KLabの答え: DSAS
● KLabの提供していたホスティングサービス
○ PC、スマートフォン向けウェブサービス・アプリサービスの基盤
○ オープンなソフトウェアの利用
○ 大規模・高負荷サイト向け
○ 低コスト
● KLabのノウハウが集約されており、様々なヒットタイトルのインフラとして
利用している。
http://www.klab.com/jp/services/others/dsas/

9. ゲームコンテンツが時代とともに変化
● DSASだけで対応できない分野が出てきた
○ ゲーム自体のリッチコンテンツ化
○ 日本語以外の言語対応を行ったグローバル化
● 上記を補うためにKLabで実際に利用しているクラウドの利用実態、特にAWS
を中心にお話ししたいと思います。
DSAS
サービス開始時
ケイタイ
近年の対象
スマートフォン

10. KLabでのクラウドの利用

11. 主なAWS利用形態
1. アセット配信関連やログ集約先など、DSASの補助的な利用
○ CloudFront を利用したアセット配信
○ S3への長期ログ集約
1. ゲームAPIのインフラとして利用
○ DSASからサブシステムを切り出して構成
○ ゲームシステム全体を受け持つ
■ 主にEC2インスタンスで構成。

12. AWS利用のフレームワーク: KLAWS
● KLabでのAWSインフラ利用を標準化したもの
KLAWS
CONTROL MONITOR
主な対象AWSサービス

13. KLAWSとは
● DSASで利用していた運用ツール/スクリプトをAWS向けカスタマイズ
○ DSAS自体がOSSを利用していたので、AWS向けの移行が容易
○ KLabのエンジニアは既存インフラの延長なので理解しやすい
KLAWS
大規模ソーシャルゲーム向け
クラウドフレームワーク
DSAS
大規模ソーシャルゲーム向け
インフラフレームワーク
AWS向け
カスタマイズ

14. DSASとKLAWSの差
● DSASは全体最適がなされている「共通インフラ」
● KLAWSはタイトル毎に構成が可変な「個別インフラ」
● タイトル毎に柔軟性を持たせて運用している
○ 利用するミドルウェアやマネージドサービスの構成を案件最適に選択できる
○ 共通インフラと異なるポイントであり、AWSを利用する理由でもある

15. 新たなクラウドの利用形態

16. KLabの事業変遷
● 自社IP / 他社IPを元に「単独」でゲーム開発を行う事が多かった
● 近年、パートナー会社と共同でゲーム開発を行う
○ KLabの強みを活かす
■ PlayGround、KG SDKなど、ゲームに関連している機能を提供
■ DSASで得たノウハウをAWS上で活用
■ AWS上で動くモバイルゲームの運用経験の蓄積

17. 共同開発したゲームを動かすインフラ
● AWSはパートナー会社と開発するゲームのインフラとして利用しやすい特徴
がある。
● 利用サービスの情報が公開されている
○ 理解している人が多く、共通認識を得やすい
● 利用する機能を指定
○ サービス構成の一般用語=AWSサービスのマッピング
● パートナー会社がすでにAWSを利用している

18. ● 一例
○ サーバ( EC2 )
○ Load Balancer( ELB )
○ KVS ( ElastiCache )
○ RDBMS ( RDS )
● AWS アーキテクチャーダイアログ
一般用語=AWSサービス例

19. 共同開発の進め方

20. KLab側インフラの目的
● パートナー会社にはゲーム開発に注力してもらいたい！
● そのため、インフラに関連する作業や設計をKLab側で受け持つ。

21. AWS上でのパートナー環境受け入れ
● 受け入れ方法決定
○ KLAWSベースAMIを利用
○ パートナーAMIを利用
○ 折衷案
● 開発環境構築
○ 構築した環境の評価し本番環境を準備
● 本番環境構築
● 負荷試験
○ 予測負荷に応じたシステム全体の構成決定
● リリース

22. 受け入れ方法決定 - ヒアリング
● 権利整理で解決する方法
○ AWSアカウントの譲渡
● 技術的な受け入れ手段
○ データの移行はマネージドサービスを活用
○ EC2イメージの受け入れ

23. EC2 受け入れ方法
● 元となるAMIをどのように作成するか決める
○ KLAWSベースのAMI上に環境を構築するパターン
○ パートナー会社提供のAMIをそのまま利用するパターン
○ 折衷案として、AMIを再構築するパターン
OSレイヤー
ミドルレイヤー
アプリケーション
KLAWS
(nginx/uwsgi/
apache/php-fpm...)
KLAWS
(linux)
パートナー
パートナー
KLAWS
(linux)
折衷案KLAWSベース
パートナー
パートナーベース

24. 構築メリットデメリット
● KLAWSベースは自由度が低いがKLabのノウハウ裏付けあり
● パートナーベースは自由度が高いがKLab側でノウハウ蓄積が必要
● 折衷案はノウハウが反映され自由度もあるが、構築内容に相互理解必要
KLabノウハウ 自由度 構築時間
KLAWSベース 高 低 短
パートナーベース 低 高 短
折衷案 中 中 長

25. 落とし穴

26. 共同開発の注意点
● 「KLabの常識」と「パートナー会社の常識」が同じとは限らない
● ここでは、その差によって起きたことを共有します。

27. 開発時の落とし穴
● KLab側で準備したAWSの開発環境でデプロイして動作テスト
● 動作確認の段階で応答が著しく悪くなる。
○ 今まで開発環境として利用していた、パートナー会社AWS環境だと、速度低下が見られない。
Web
遅い…
KLab開発環境

28. 開発時の落とし穴
● 一般的には「開発環境に費用をかけない」
○ 事例では、EC2の1インスタンスで全システム構成
● KLabでは「少々費用がかかっても本番と同じ構成の開発環境を準備」
NW通信
レイテンシー高
Web
KLab開発環境
(本番と同じ要素)
遅い…
Webサーバ
KVS
パートナー会社開発環境
(1EC2インスタンス)
メモリ間通信
レイテンシー低
異常なし

29. 費用計算の落とし穴
● パートナーからAWS利用の費用概算が出てきた。
● が、こちらが想定している費用感と比べるやけに安い…
KLab側の経験予測構成
EC2: 4コア 8台
Elasticache: 6Gメモリ
RDS: 大規模インスタンス
+ 500GB
パートナー側見積もり概算構成
EC2: 2コア 3台
Elasticache: 2Gメモリ
RDS: 中規模インスタンス
+ 100GB
＞

30. 費用計算の落とし穴
● 一般的には「システムの最小構成を費用のベースライン」で算出
● KLabでは「利用者数に耐えうる構成を費用のベースライン」で算出
一般的な費用
グラフ上の考え方
KLabの費用
グラフ上の考え方

31. まとめ

32. まとめ
● DSASの補完としてAWSを利用してきた
● 近年の事業展開から、パートナー会社とゲームの共同開発を行っている
● AWSはゲームの共同開発で利用する際にメリットが多い
● 相互に意思疎通しながら開発を行うことが重要