新卒2年目インフラエンジニアが社内 AWS GameDay で優勝した話 [DeNA インフラ SRE]

はじめに

こんにちは。IT本部IT基盤部第一グループの oden です。 2021年に新卒エンジニアとして入社し、現在2年目です。普段の業務では Pococha をはじめとしたライブストリーミングサービスやその他エンタメ領域のサービスのインフラ運用や改善を行っています。

さて、早速本題に入りますが、皆さんは AWS GameDay というイベントをご存知でしょうか？今回は新卒2年目のインフラエンジニアである私が社内の AWS GameDay で優勝した体験談とこの1年間IT基盤部でどう成長できたかについて書いていきます。

AWS GameDay について

そもそも AWS GameDay とは？

AWS GameDay とは AWS が開催するコンペティション要素を含んだトレーニングイベントです。 AWS のリソースに対する理解や実際に構築していく中でのトラブルシューティング力などが求められます。実際にアプリケーションをデプロイし、各種設定などを正しく行うことで、ポイントがもらえます。素早く多くの課題やトラブルを解決し、最終的にポイントを最も多く稼いだチームが勝ち、というルールです。ちょっと ISUCON チックなイベントを想像していただくと良いです。

弊社では毎年、新卒研修生と社内で募集したエンジニアたちが集まって、社内 AWS GameDay が開催されています。今年は12チーム、計47名が参加しました。新卒/中途や在籍年数など関係なく、みんなでワイワイとイベント気分でやっています。

今年のお題「Unicorn Polo League」

今年の AWS GameDay では私たち参加者が「Unicorn Polo League」という架空のイベントにオーナーとして参加するというものでした。

イベントの流れは以下のような感じです。

ユニコーンを格納するための「厩舎」を構築する
ユニコーンを育成するための「ジム」を構築する
ユニコーンを購入する
購入したユニコーンをジムで育成する
ポロリーグに参加させて勝利することで「ユニコイン」を得る

厩舎やジムの構築を行うには README を読み解きながら、払い出された AWS アカウント上にアプリケーションをデプロイしていく必要があります。

またこれらの構築以外にも「クエスト」というものがあります。クエストについても README が用意されていて、AWS リソースを駆使してお題となっている構成のアプリケーションを作成していく必要があります。クエストをクリアすることで厩舎やジムのアップグレードが可能となり、より多くのユニコーンを所持できたり育成効率が上がったりします。

戦略的な要素として、自分が育てたユニコーンはマーケットプレイスで他のチームに売り飛ばすこともできます。最終的に多くのユニコインを保持していたチームが優勝となります。

どうゲームを進めていったか

私のチームは4人チームで、そのうち私を含めた3人(同期なので2年目)がIT基盤部のインフラエンジニアでした。当初は21卒のIT基盤部のメンバーだけということで「21_kiban_boys」というチーム名で参加したのですが、1人で参加していた別部署で普段開発をやっている中途入社のメンバーも合流してくれました。

まずはユニコーンを購入して育てるために、厩舎と3種類のジムの構築を急ぐことになりました。全部で4つの構築タスクがあるので、ちょうど良いということで1人が1つの構築をそれぞれ担当しましょうという話でまとまりました。

その中でやってよかったことは作業ログを残しておいたことです。自分の構築に手こずってしまい、他のメンバーにヘルプを求める際にこの作業ログのおかげでコミュニケーションがスムーズになりました。

最初の4つの構築タスクが比較的スムーズに進んだので、すぐにユニコーンを仕入れ、文字通り、馬車馬？馬車ユニコーン？のようにジムで育成を行いました。この時点で厩舎とジムの構築が済んでいるチームはまだ少なかったようで、トップに躍り出ることができました。

その後もメンバー同士でワイワイと連携しながら、クエストをこなしていき、効率よくユニコーンを育てることに成功しました。ポロリーグでの勝率も高い水準をキープでき、ユニコインをコンスタントに獲得することができました。

最終的には2位に10,000点以上の差を付けて優勝することができました！

1年前に参加して惨敗

実は私は去年(新卒1年目の時)一度 AWS GameDay に参加したことがありました。その時の成績は20チーム中11位くらいで、個人的には手も足も出なかったのを覚えています。

当時を振り返ってみると、いくつかの敗因がありました。

「点」は一定理解しているが、それらが「線」になっていない

新卒研修では座学だけでなく、VPCやサブネットを構築したり、その中にEC2 インスタンスを立てたり、実際に手を動かすワークもあったので、 AWS のリソースに対する理解はある程度できているつもりでした。ただ、これはあくまでも「点」に過ぎず、実際の業務ではこれらの「点」を組み合わせて、「線」としてサービスを構築します。

GameDay で課されるタスクについても見たことや聞いたことのあるサービスは多いのですが、どのサービスと組み合わせて使うべきなのか、またその繋ぎこみはどうやるのか、というところがまだまだ理解できていませんでした。こうした「線」としての理解度が低かったのが敗因の1つだと感じました。

実践的なトラブルシューティング力が足りていない

これは研修だけしか受けていなかったので、当然といえば当然なのですが、圧倒的に実践的なトラブルシューティング力が足りていませんでした。

例えば EC2 インスタンスを立ててみたはいいが ssh できないというトラブルがあった時に、当時は「なぜそのような事象が起こるのか」「その原因は何か」「具体的には設定やコンソールのどこを見ると良いか」などが、瞬時には判断できず、対応が後手後手になってしまっていました。 AWS GameDay では制限時間内に多くのタスクをこなす必要があるのに、ズルズルと1つの問題にハマってしまい時間切れ、というパターンに陥ってしまっていました。

IT 基盤部での1年間でどう成長できたか

惨敗を喫した私ですが、紆余曲折あって社内のインフラ専門部隊である IT 基盤部に配属されることになりました。 Pococha をはじめとした高トラフィックなサービスのインフラ運用 / 改善に携わる中で、いくつかの力が培われたと感じています。

実際のサービスを運用する中で AWS のサービスを「線」で理解できるようになった

実際のサービス運用をやっていると、サービス同士の繋ぎこみの部分や依存関係のようなものが理解できるようになりました。

例えば EC2 をサービスで使う場合、Amazon EC2 Auto Scaling や Elastic Load Balancing などと組み合わせて使うことが多いです。 1年前の私だったらそれぞれ何をするために使うサービスなのかは理解できていましたが、これらを一緒に配置してアプリケーションをデプロイする場合に必要な設定や構成までは理解できていませんでした。それがこの１年間の実際のサービス構築や改善業務の中で、ドキュメントや既存のサービスの構成などを参考にしながら、少しずつ解像度高く、サービス同士の関係を理解できるようになってきました。

毎日の業務の中でこうした引き出しがどんどん増えていき、「点」が繋がって「線」になっていく感覚を日々感じています。