はじめまして。21新卒システムエンジニアの中村です。
チームではなかむーと呼ばれています。
こちらは6/1 - 6/3に実施された21期新卒エンジニア向けオンライン研修プログラム
AWS Jumpstart for NewGrads
の参加記になります。想定読者はAWSに興味ある方や、エンジニアの皆さんです。参加してない人にも雰囲気や楽しさが伝わるように書いていこうと思います。
概要
本プログラムでは、3日間の座学・ワークショップを通じて、
- AWS上でのアーキテクティング
- ECSを活用したコンテナアプリケーションのオーケストレーションとデプロイ
- Amplifyを活用した、サーバレスモバイルアプリケーションの開発 などを学んで頂けます
とのことでした。AWS自体は、新卒研修でインフラ構築をやった時に触ったことがありました。そのため、一般的なwebアプリケーションの構成(LB+Web+DB+Cache程度)に関しては、図の読み書きが少しできるくらいの知見をもっていると考えていました。 しかし、実際に運用されている大きなサービスの構成やマネージドサービスについては、知見は愚か知識もあまりなかったので、その辺り少しでも持って帰れたらなとぼんやり考えていました。
知見というのは実際に経験して理解したこと、知識というのはある事例について知っていることを指します。これは研修最後のLTで学んだことです。
一日目
| 時間 | コンテンツ |
|---|---|
| 9:00 - 9:30 | オープニング |
| 9:30 - 11:30 | アーキテクティングのコツ |
| 11:30 - 12:00 | チーム自己紹介 |
| 13:00 - 14:00 | アーキテクチャ設計 |
| 14:00 - 18:00 | ECS ワークショップ |
この日は初日だったので、座学が中心でした。 アーキテクチャ設計の課題(下図)が発表されましたが、初日はどこからどう手をつけていいかわかりませんでした。
LINEのようなサービスといいつつ、細かい要件や設定などはチームで考えていいとのことだったので、そこを詰めるところも含めた課題でした。
二日目
| 時間 | コンテンツ |
|---|---|
| 9:00 - 9:30 | Daily Check-in |
| 9:30 - 12:00 | アーキテクチャ検討 |
| 13:00 - 14:30 | アーキテクチャ検討 |
| 14:30 - 17:30 | Amplify ワークショップ |
| 17:30 - 18:00 | SAサロン |
この日はアーキテクチャ設計のグループワークが半分、ハンズオンが半分という感じでした。 二日目なのでチームの仲間とも打ち解けてきて、いろいろ話が弾んだのを覚えています。 SAサロンではソリューションアーキテクト(SA)の皆さんの職歴や面白い話をたくさん聞けてとても楽しかったです。
三日目
| 時間 | コンテンツ |
|---|---|
| 9:00 - 9:30 | Daily Check-in |
| 9:30 - 12:00 | アーキテクチャ設計 |
| 13:00 - 15:30 | アーキテクチャ設計 |
| 15:30 - 16:30 | 成果発表会 |
| 16:30 - 17:00 | クロージング |
| 17:00 - 18:00(19:00) | 懇親会 |
最終日はほぼ丸一日、アーキテクチャ設計を詰めるのに当てることができました。 成果発表会で他のチームの設計を見てとても勉強になったり、懇親会で他のチームの人と話せたり、とても楽しい1日でした。
下に僕のチームが考えたコンセプトと構成図を貼っておきます。
ざっくり言うと、
- LINEと同じようにクライアントに情報を持たせる
- マネージドサービスを用いて難しい部分やセキュリティに対してはAWSに担保してもらう
構成にしました。
ここからは、研修全体を通して学んだこと・楽しかったことをトピック別に書いていこうと思います。
学んだこと・楽しかったこと
要件：目的が大切
アーキテクチャ設計に正解はありません。アンチパターンとベストプラクティスがあるだけです。
今回のような課題を与えられたときに大事なのは、正解を探す考え方ではなく、
「そもそも」何が課題なのか、どういう設定で何を解決したいのか
をはっきり決めることです。ここがふわっとしていると、なんとなく他人事で、ふわっと要件を満たしてはいるが最適とは言い切れない微妙な設計が出来上がってしまいます。
いわゆる課題発見、課題設定という部分ですね。
ではどうすれば良いのか。
僕たちのチームの場合は、みんなで作りたいアプリケーションやターゲットユーザー層を細かく決めるところから再スタートしました。
「どんなアプリなら需要があるだろうか？」という視点から考えたとき、ユーザーのプライベートを大事にしたいというアイデアが生まれました。 これを詰めていくと、チャットのやりとりをサーバーに保持するのではなく、各ユーザーの端末に保存しておくのが一番理想的な状態という結論になりました。 そのため、コンセプトの一つに、「サーバーではなくユーザの端末にチャット履歴を保持する」ということを入れました。 これにより、サーバー側へのデータの流れ・処理がシンプルになり、アーキテクチャとしてAWSのマネージドサービスと相性の良い構成に落ち着きました。 加えて、前提条件である「資金が潤沢」「インフラの子守はなるべくしたくない」を満たすことができたため、自信を持って採用することができました。
AWSハンズオン・講義を通した技術的知見、マネージドサービスの知識
この研修の前の印象は、AWSはドキュメントが膨大で、知りたいことを調べるのも一苦労という感じでした。
研修を終えた今では、膨大であるという印象に変わりはないものの、料金やFAQページを中心にたくさんのドキュメントを読んだおかげで抵抗感が多少薄れたように思います。調べるのが慣れてきた一つの理由が、やはり先に述べた「要件：目的が大切」というところにあると思います。
特にマネージドサービスは、
AWS側がセキュリティなどを保証してくれていて、細かい部分を気にしなくていい
という思想のもと作られているため、それを理解していないと選択肢の吟味が困難になってしまいます。逆に、一つでもちゃんとした軸があれば、優先度や相性を考えて少しずつ決めていくことができるし、他社の公開されている設計図を見て参考にすることもできるようになります。そのような調べ方自体を学ぶことができたのは、とても大きな収穫だったように思います。
具体的なサービスに関して。
ECS
- 汎用性が高い：タスク定義を一つ作れば、サービス(Amazon ECS)を増やしたいと思った時に楽にできるなと感じました。
- タスクごとのIAMロールの必要性：サービスアカウントを運営するとなった時に、細かなセキュリティまで目が届くようになるため、堅牢性が上がると思いました。
- Fargate: 「インフラの子守はなるべくしたくない」という需要にぴったりマッチしたサービスだと思いました。自分が構築するサービスにぜひ入れたいなと思いました。
Amplify
- 設計の概念が変わった：マネージドサービスによって、一個高いレイヤー(自分でも何言ってるかわからないですがw)から設計図を見れるようになりました。
- 今までは全部EC2で立てる方法しか知らなかったので.......
- amplify CLIで対話的に「やりたいこと」を答えていくと、作りたいものができていくという体験が新鮮でした。
- サーバーレス(サーバーの存在を意識しなくていい)という言葉は知っていたが、実際のアーキテクチャとの組み合わせを見ることによって、より具体的な理解が深まりました。
バックグラウンドの違うエンジニアのチームをまとめる大変さ
ここは一番苦労し、かつ学びのあったところでした。
チームは僕を含め5人でした。iOS/Androidエンジニア、バックエンド、僕、 何も知らない大泉洋 という技術スタックのバラバラなチームでした。アドウェイズの僕の所属している部署では研修でフロント、バック、インフラ全部やるため、そこは他社と違うなと思いました。
自己紹介ではみんな好きな言語とか技術の話で盛り上がっていてすごいなあと思ってました。とりあえず「静的型付き言語は正義！」などと言って話を合わせておきました。
静的型付き言語自体は普通に好みです。熱量を合わせました。
設計の話し合いフェーズに入ってからが本当に大変でした。
バックエンドの人は「俺DynamoDBしか知らないからダイナモがいい！」と言っており、フロントの人は「とりあえずLambdaでいいんじゃね？」と言っていたり、みんなが明後日の方向を向いていました。とりあえずファシリテーター(進行役)に立候補し、タイムキーパーと書記を決めてまとめる役割に回ることにしました。
こういう時は何か一つ共通の目標・認識(：スクラム開発におけるインセプションデッキ的なもの)があるとまとまり始めるんですが、いきなりそういうこと言っても誰もついてこないし、各々が好き勝手喋って好き勝手調べてという混沌が誕生していたので、とりあえず時間を区切るなどの進め方の提案をしました。
- 「10分で調べて、10分でmiroの付箋に書き出そう」
- 「じゃあ、今調べたワードをインスタンス、マネージドサービス、その他にカテゴリ分けしよう」
- 「よし、そしたらユーザーからのデータ・処理の流れを考えながらとりあえず置いて行こうか」
- 「あ、一旦具体的なサービス名は置いといて、webサーバー、DBサーバーくらいの抽象度で考えてみよう」
こんな感じで、少しずつ進め方を提案していって進みはしましたが、初日は「作りたいもの」がなかったので正直暗中模索でした。みんな別の話を別レイヤーでする状態からはなんとか脱せたかなと思います。
二日目の午前にメンバーの一人がトラブルにあったり、SAの方から一度ちゃんとフィードバックをもらって「作りたいもの」から考え始めるようになってから、チームとしてまとまりだして楽しかったです。
なんか計画停電にあったらしく、10:00~11:30までメンバーの一人が急に来られない状況になってしまったんですよね。そこから、硬い雰囲気が崩れて、面白いものから考えようという流れになりました。
チームの人の意見を聞きながら、miroで設計図や言葉に落としていく作業を担当しました。調査や発表は他のチームメンバーに振りつつ、最後は上手くまとまったんじゃないかなと思います。
他の会社の新卒同期との交流
社内の同期とは交流する機会があっても、社外の同期と交流する機会ってなかなかないですよね。
かくいう僕は同じ部署の同期としかあんまり話してませんが......
設計のグループワークや、懇親会の強制部屋替えなど、一定の制限・期限つきの出会いの機会というのが最近久しぶりだったので、とても良い刺激になりました。
まとめ
クラウドサービスはエンジニアの義務教育になりつつある気がするので、このイベントでの知見をきっかけにエンジニアとしてもJumpstartしていきたいと思います。
