こんにちは、たかぎわ (@shun_tak) と申します。エンジニアブログ執筆は4年ぶり2回目ですね。

発表会後の集合写真。男ばっかり…
発表会後の集合写真。男ばっかり…

本記事では、オンプレミス環境で育ったエンジニア向けに実施したクラウド勉強会について報告したいと思います。参加者にもマネージャー陣にも好評だったので、読者の皆様にとっても参考になれば幸いです。

要約

  • 社内でパブリッククラウド (AWS/GCP) の勉強会を実施した
  • 期間:3ヶ月弱(営業時間外で取り組んだ)
  • 対象:オンプレ環境で開発してきた新卒1年目〜3年目くらいのサーバーサイドエンジニア
  • 参加人数:4名
  • 講師・サポートスタッフ:3名(筆者含む)
  • 内容:ハンズオン5回+最終課題(AWSソリューションアーキテクトレビュー&社内で発表会実施)
  • 結果:参加者それぞれは独力で、AWSのベストプラクティスに従ったアーキテクチャを設計し、実際に実装するところまで出来るようになった

イントロダクション

先日、QualiArtsにてパブリッククラウドの勉強会を実施しました。対象はオンプレミス環境で育った新卒入社のエンジニアで、期間は3ヶ月ほどかけました。

前半は毎週月曜に会議室に集まって、ハンズオン形式の勉強会を実施しました。後半では最終課題を課し、AWSソリューションアーキテクトの方にレビューを受け、成果発表会を実施しました。

いきなり詳細を報告してもいいのですが、勉強会を実施した理由も書かせてください。

組織的な背景

おかげさまでガールフレンド(仮)は10月29日でリリース4周年を迎えますが、QualiArtsにはリリース後3年以上運用しているタイトルが多数あります。過去にリリースされたタイトルはオンプレで運用されることが多いのですが、QualiArtsが運営する9タイトルのうち、5タイトルがオンプレミス環境やプライベートクラウド環境で運用されています。オンプレミス環境では36コア持ったアプリケーションサーバが数十台の規模で運用されてたり、FusionIOを3枚差ししたDB(これは本当に少ないけど)が運用されていたりと、これはこれで楽しいです(^q^)

一方、QualiArtsでのパブリッククラウドとの関わりとしては、2013年リリースのタイトルからAWSを本格的に利用し始めました。その後GCPも利用するようになりましたが、2015年リリースのタイトルではまだプライベートクラウド利用のタイトルが優勢でした。2016年リリースのタイトルでは、全タイトルがパブリッククラウドだけで提供されるようになりました。現在開発中のタイトルもAWSまたはGCPで開発されています。

勉強会実施の背景と目的

オンプレもパブリッククラウドもどちらも使ってます!という組織ですと、エンジニアによってはオンプレしかやったことがないという偏りが出てきてしまいます。また、サイバーエージェントに属する一部署に過ぎないため(現在では分社化して株式会社QualiArts)、クラウドに習熟したエンジニアが他の部署に異動してしまうということもよくあることです。もちろん逆もあるのですが、ここ最近ではクラウド技術に精通した人材が少ないと感じることが増えてきました。

こうした課題を解決するためにいくつか活動していますが、少しでもクラウドやったことある層を増やすために社内勉強会を開催しました。

また今回の参加者は若手エンジニアで集めたのですが、若手には技術力が上がれば市場価値も上がるよ〜というインセンティブを与えつつ、若手の成長を見た中堅以上のエンジニアにも刺激を与える(焦らせる)という裏目的もありました。自分もまだまだ若手ですが、教えることで学びを深めたいというのもありました。

具体的にやったこと

具体的にやったこととしては、冒頭でも触れましたが、前半はハンズオン形式の勉強会、後半は最終課題を提示してそれぞれ課題を進めるという形式で実施しました。

特に後半の課題は、勉強会というにはかなり難易度が高く、密度の濃い取り組みになったのではないかと思います。

ハンズオン

ハンズオンのカリキュラムは次のような感じで進めました:

  • 第1〜2回
    • 基本的なインスタンス・マネージドDBサービスを利用しよう(第1回がAWSで第2回がGCP)
    • EC2 + RDS, GCE + Cloud SQL
  • 第3回
    • アプリケーション層にもマネージドサービスを利用しよう
    • Google App Engine + Cloud Datastore
    • Autoscalingも利用
  • 第4回
    • LambdaでAPIを提供してみよう
    • Amazon API Gateway + Lambda + DynamoDB
  • 第5回
    • terraformでInfrastructure as Codeを実践しよう

第1〜4回ではそれぞれ異なるサービスを利用し、異なるアーキテクチャを構築しましたが、簡単なAPIサーバを作るという目的は共通にしました。これにより、サービスやアーキテクチャの違いにフォーカスしやすくなったと思います。

第5回ではterraformを利用しましたが、第4回まではコンソールでぽちぽちサービスを起動していたのに対し、コードからインフラを構築し、それぞれのリソースを結合しサービスを起動するという体験をしました。terraformはQualiArtsの運用でも利用することになるので取り上げました。

ハンズオンは毎週月曜の定時後に集まって実施していたのですが、筆者もクラウドに習熟しているというほどのレベルではないので、毎週準備に必死でしたw

レジュメは社内wikiで共有していたのですが、アーキテクチャ図とかは手書きをスキャンして掲載していました。こんな感じです。

時短のため手書き。
時短のため手書き。

最終課題

最終課題ではゲームAPIを開発し、スケールするアーキテクチャの設計・実装に挑戦しました。

課題には、参加者それぞれが全体設計からAPIの実装まで独力で取り組んだので、かなりハードになったんじゃないかなと思います。また、AWSソリューションアーキテクトの方にも中間レビューと発表会での総評をいただき、大変学びの多い課題になりました。

以下詳細です。

仕様

  • スマホネイティブゲームアプリを想定
  • 6つのゲームAPIを実装すること
    • ユーザ登録
    • ユーザ情報取得
    • クエスト一覧取得
    • クエスト開始
    • クエスト終了
    • ランキング取得
  • 受け入れテストをパスすること
  • AWSプラットフォーム上に構築すること
  • 言語・利用サービスは問わない
  • terraform apply/destroyによってインフラの構築/削除ができること

APIについてはより詳しいAPI仕様書も配布しました。例えばユーザ情報取得APIはこんな感じです。

Google Spreadsheetsで共有
Google Spreadsheetsで共有

仕様の受け入れテストをパスすることという箇所は、APIが正しく実装されているかを判定します。JavaScriptのテスティングフレームワークmochaから課題を実装したサーバへHTTPリクエストを投げて、レスポンスに対してアサーションが通るかどうかで判定します。テストを走らせるとこんな感じの結果を得られます。

  ユーザ登録テスト
    ✓ リクエストボディにnameがないと登録できないこと
    ✓ 正常なデータをPOSTしたらトークンを取得できること
    ✓ 一度登録したユーザ名ではエラーになること

  ユーザ情報取得テスト
    ✓ トークンがないと取得できないこと
    ✓ 登録時に取得したトークンを使用してユーザ情報が取得できること

  クエスト一覧取得テスト
    ✓ トークンがないと取得できないこと
    ✓ 登録時に取得したトークンを使用してクエスト一覧が取得できること

  クエスト開始・終了テスト
    ✓ トークンがないと取得できないこと
    ✓ リクエストボディにquest_idがないと登録できないこと
    ✓ クエストが開始できること
    ✓ クエストを勝利で終了できること
    ✓ 新たな未クリアのクエストが開始できること
    ✓ クエストを敗北で終了できること
    ✓ エネルギーが足りない状態でクエストを開始しようとするとエラーになること
    ✓ 挑戦中でないクエストを開始しようとするとエラーになること
    ✓ 挑戦中でないクエストを終了しようとするとエラーになること

  ランキング取得テスト
    ✓ トークンがないと取得できないこと
    ✓ 登録時に取得したトークンを使用してランキング情報が取得できること

  18 passing (253ms)

AWSプラットフォーム上に構築することという箇所は、AWSソリューションアーキテクトレビューを受けるにあたってプラットフォームを統一しました。

性能要件

  • 平均1000rps/最大5000rps
  • 50万DAUを想定

ヒットしてるネイティブゲームアプリを想定しました。

コスト要件

  • 1ヶ月運用した時の請求額500万円(転送料を除く)

極端な構成を防ぐために上限を設けました。参考に、EC2にアプリケーションサーバを立てるなら最大c4.xlargeくらいを目安にと伝えました。

求める成果物

  • API, terraformのソースコード一式
  • アーキテクチャを説明する資料
  • 負荷試験結果のレポート
  • 1ヶ月運用したときの請求額の見積もり

フォーマットは特に指定しません。論理的に説明されていればOKとしました。例えばオートスケーリング等を使う場合、平均1000rps/最大5000rpsの時間別内訳を自ら仮定して計算してもいいし、実際の運用データを参考にして計算しても良いとしました。

サイバーエージェントの2016年度新卒エンジニア向け技術研修でやった課題ではアーキテクチャの説明までが求められていましたが、今回は負荷試験によるファクトの提出も求めました。また運用コストも意識してほしいので、請求額の見積もりも出してもらいました。さらに新卒研修は3人1チームでしたが、勉強会参加者は2~4年目のエンジニアですから、それぞれ独力でやってもらいました。

負荷試験について

  • システム全体で試験するとコストが莫大になる
  • 1台あたりの性能を測定
    • 台数に応じてクラスタの性能が線形比例すると仮定してよい

ここも前項で触れたように、論理的に説明されていればOKの範囲です。

例としては、以下のような手順で負荷試験する感じになります。

  • 負荷試験の結果、1台のEC2で500rpsさばけます
  • このときElastiCacheには2000rps, RDSには1000qpsアクセスしてました
  • ピーク時ElastiCacheには20,000rpsになるので、負荷試験でこれに耐えられるインスタンスタイプを求めます
  • RDSも同様に、ピーク時10,000qpsをさばけるインスタンスタイプを負荷試験で確かめます

必須ではない評価項目

  • さらに大きな負荷が来た時の対応が考慮されているか
  • 運用しやすいアーキテクチャになっているか

営業時間外にやる課題としてはかなりボリュームが大きくなってしまったので、リリースフローやロギング、モニタリング、ステージング環境、社内限定公開などの運用周りについては求めませんでした。

最終課題の結果

まずAPI実装ですが、6つとはいえ厳密な受け入れテストもあるので簡単ではなかったようです。もちろん最終的には全員受け入れテストをパスしました。

アーキテクチャはEC2, ElastiCache, Auroraを使うパターンが3人、Lambda, ElastiCache, DynamoDBを使うパターンが1人でした。耐障害性については問題ありませんでした。

EC2, ElastiCache, Auroraを使うパターン by 参加者Sさん
EC2, ElastiCache, Auroraを使うパターン by 参加者Sさん
Lambda, ElastiCache, DynamoDBを使うパターン by 参加者Iさん
Lambda, ElastiCache, DynamoDBを使うパターン by 参加者Iさん

1リクエストあたりのレスポンス速度を見てみると、EC2パターンでは20~30msecでさばいてる人もいれば150~170msec程度の人もいました。Lambdaの場合は30~90msecに収まっていました。いずれも要求していた平均1000rps/最大5000rpsをさばくアーキテクチャは構成できました。

参加者4人が出してくれた1ヶ月の請求額見積もりはそれぞれ、約16万円、約18万円、約27万円、約36万円となりました。予算は500万円/月だったので、少なすぎて間違ってるんじゃないか?って思ったんですが、間違ってはなさそうでした。また、ここに転送料や運用の諸費用が上乗せされることを考えると、実際にはもっと増えることも想像できます。

発表会もやりました!

緊張した面持ちのSさん。
緊張した面持ちのSさん。

社内の多くの方々に見に来ていただき、発表会は大盛況で終わりました。

勉強会を終えてみて

今回の勉強会は、参加者からだけでなく技術マネージャーや経営陣からも良かったと言ってもらえて、大変好評でした。参加者の途中脱落もなく、その点も良かったと思います。

うまくいった理由は色々あると思いますが、最大の要因は、参加者もサポートメンバーも自ら「やりたい」と言って参加したメンバーだったことだと思います。営業時間外にやるということもあり、そういった前向きな自主性がないと成立しなかったと思います。

ハンズオンの準備も、事前に2回はハンズオンの内容を実際にやっておく等、かなり念入りに用意していたので、参加者には分かりやすかったと評価いただきました。難易度としても難しい印象はなかったようです。

全5回x4人のアンケート結果をまとめました。
全5回x4人のアンケート結果をまとめました。

一方で最終課題はかなり重かったようですが、現場で使えるレベルとなるとこれくらいは要求されるので勘弁してください。

とにかく実際に触ってみると意外と簡単なのですが、実際にやるまでのハードルを今回の勉強会で一緒に乗り越えることができたのも良かったなと思います。

中堅以上を焦らせる刺激を与える方についても、実際に2名のエンジニアから参加したいとの問い合わせがあり、効果アリでした。その2人には、別日程で勉強会をやりました。

最後に、勉強会全体の感想もいただいたので紹介します。

普段プロジェクトで使用できていなかったAWSの様々なサービスの検証や実装が出来てとても有意義でした!最終課題もハンズオンも実用的でかつ難しかったのでとてもやりがいがありました!(参加者Iさん)
今まであまりクラウドインフラを実際に使用する機会がなかったため、AGE-TECH(筆者注:今回の勉強会の社内での呼称)でのハンズオン研修はとても有意義でした。
これをキッカケにしっかりと自分の知識として利用できるよう引き続き勉強します!(参加者Yさん)
ハンズオン形式だったためとても理解しやすかったです。
最終課題は短期間でかなり濃密な時間が過ごせたので、より高いレベルで実用できるようにこれからも学んでいきます!(参加者Sさん)
所属しているプロジェクトでは使用しない技術なのでクラウドを触る機会があまりなかったのですが、AGE-TECH勉強会がAWSなどのクラウドを触る良いきっかけになりました。
勉強会だけで終わらずに、クラウド周りの勉強を引き続き行っていきたいです。(参加者Tさん)
色々勉強になりました。負けないようにもっと精進しようと思いました。(サポートEさん)
若手に限らず、全てのCAエンジニアが受けるべき講座だと思うほどにレベルの高い勉強会でした。いい試みなので今後の展開に期待したいです。(サポートKさん)

将来

組織の課題と向き合う取り組みはますます重要になってきます。こういった勉強会は引き続きやっていこうと思います。

また、課題があるからやるという勉強会だけでなく、「やりたいからやる!」という勉強会もやっていきたく、11月くらいから実施していくつもりなので社内の皆様にはご協力をお願いします。

もう少し先の将来では、QualiArtsがゲーム業界のクラウド技術推進を担えるようになれればと考えています。ゲーム業界は厳しいスケジュールに追われるなどの理由により、新たな技術への挑戦が制限されることがあります。QualiArtsから実績を情報発信していくことで、新たな挑戦を後押しできれば幸いです。クラウドベンダー各社の皆様にも、引き続きどうぞよろしくお願い申し上げます。

2013年新卒入社。(株)QualiArtsシステムエンジニア。入社以来、旧Amebaゲーム事業本部に所属し、一貫してゲーム開発をしている。専門はサーバーサイドで、開発・運用のシンプル化・効率化が得意。旧Amebaゲーム事業本部は2016年10月3日に子会社化し、株式会社QualiArts設立。