LoginSignup
1
4

More than 1 year has passed since last update.

@A-nkt(Yuta Nakata)in株式会社ウェザーニューズ

新卒エンジニアがAWS研修に参加してきました

Last updated at Posted at 2022-07-02

新卒エンジニアAWS研修に参加してきました

2022年4月に新卒として入社しました、ウェザーニューズの中田です。本記事はAWS JumpStart for NewGrads並びにAWS JumpStartの研修における感想記事になります。

AWS JumpStart for NewGradsとは？

AWS Jumpstart for NewGrads は、AWS のサービスを用いた Web アプリケーションの開発やシステムの設計が体験できる、新卒エンジニア向けのプログラムです。 アマゾンウェブサービスジャパン株式会社により三日間にわたり行われ、参加者は様々な業種の会社から参加された新卒エンジニアが200名以上にものぼりました。
ウェザーニューズでは、AWSの利用経験やプログラミング習熟度等を鑑みて10名の新卒エンジニアが参加しました。

概要

スケジュール

研修内容は以下の通りでした。
image7.png
アーキテクティングのコツに関わる講義を受けたのち、4人前後のチーム別に別れてアーキテクチャ検討をする時間が多くある研修プログラムでした。それに加えて、２種類のハンズオン学習を通じて実際にAWSを使う経験を積むことができるプログラムもありました。

内容

今回のプログラムでは、大規模なチャットアプリを作るというものでした。具体的な要件については一般公開はNGということでしたので、ここでは割愛させていただきます。

ハンズオンでは、以下２つのプログラムがありました。

  • スケーラブルなWebサイト構築を行うハンズオン
  • サーバーレスなシステムを構築を行うハンズオン

スケーラブルなWebサイト構築を行うハンズオンでは、EC2にwordpressをインストールし、 VPC・RDS・ELBを用いたWebサイトの構築を行いました。このハンズオンの中で、マルチAZ構成やAMI、Auto Scaling機能の利点を改めて確認することができました。

サーバーレスなシステムを構築を行うハンズオンでは、Lambda・Dynamodb・API Gateway・Amazon Translateを使い、自動翻訳APIの作成を行いました。

参加者の感想

中田の感想（Team12）

僕たちのチームにおけるアーキテクチャは以下のようになりました。
image5.png

今回のアーキテクチャで工夫した点は、以下のポイントです。

  • Amazon Aurora・Dynamodb・Neptuneの3種類のDBを使用しました。他のチームでは、RDBとNo SQLのAurora（もしくはRDS）とDynamodbのみを使用したチームが多い中で、Amazon Neptuneを使用するという選択を行いました。理由としては、グラフ型のDBであるNeptuneは、友人やグループといったネットワーク構造を表現する上でRDB等と比較して、圧倒的に早いと考えたためです。
  • DAX（DynamoDB Accelerator）を採用しました。私たちのアーキテクチャでは、Dynamodbにおいてメッセージの保存・管理を行う構成として考えており、本課題における大規模チャットサービスを作成する上で、チャット流量を裁ききれるのか懸念を感じました。そこで、dynamodbに特化したインメモリキャッシュ・DAXを使用することで、この課題を解決することができると考えました。

以上のアーキテクトを踏まえて、本プログラムの感想としては、そもそも本研修以前に大学院時代からソフトウェアエンジニアとして長期インターンシップを行っており、そこでAWSサービスを利用していました。そのため、最低限の基礎知識を持って取り組むことができたため、とても学びの多い時間を過ごすことができました。今後はこの場で学んだことを契機により知識・経験を増やしていきたいと考えています。まずは、ソリューションアーキテクトアソシエイトを取りたいと思います！

高橋の感想（Team 24）

  • アーキテクチャ図
    image4.png

  • こだわったポイント
    僕達の班はスケーラビリティなシステムをどう実現するかに注目しました。例えばチャットアプリの各機能を実現するためにEC2やlambdaを使用するのではなく、fargate+ECSを用いました。EC2にもオートスケーリング機能はありますが、FargateはOSのレイヤーがないためEC２よりも立ち上がるスピードが早く、柔軟にスケールアウト・スケールインができます。またlambdaを用いてチャットの流量が増えそうなイベント(あけおめやバルスなど)を半手動で検出し、サーバーの増強をする仕組みを取り入れました。こういった通信のスパイクは捌きにくいワークロードなので、発表時のフィードバックで評価されました。

  • 感想
    AWSのサービスやクラウドのメリットについては事前学習の動画で学習し、理解した状態で挑みました。今回の課題は大規模チャットアプリのアーキテクチャの検討というお題でしたが、そもそもチャットアプリがどう作られているのかの具体的なイメージが無かったので、検討の時間が始まってもなかなか動き出しが悪かった記憶があります。本イベントではAWSに詳しい方と相談できる機会が何回か設けられており、アドバイスをもらうことができました。そこで頂いたアドバイスの中で核心的だったのは、「まずはAWSのサービスを忘れてチャットボットの要件定義、技術選定をする」というアドバイスでした。この助言を基に議論を進めることができました。そのため今回得た学びとして、システム構築の経験や知見が多いほど、アーキテクチャ検討をうまくできると感じました。また経験が多いほどAWSの利点がより理解できるのかなと思いました。
    今回の場合、僕らの班はシステム構築の初心者だったため、既存の類似システムの構築方法及びAWS構成図を調べまくるというのが一番進捗を出すことができました。
    研修中にあったハンズオンの知識も現在業務に活かせていて、本当に学びの多い研修で良かったです。また他社の新卒の方とお話できる貴重な機会だったため、良い刺激をもらうことができました。

三井の感想（Team 19）

アーキテクチャ設計図
image1.png

  • 注意した点
    • 自分の班は、なるべく簡潔にサーバレスな構築をすることを心がけていました。また、RDBMSの負荷を下げるためにCQRSを用いたり、Lambdaの同時起動を想定してRDS proxyを導入するなど、可用性についても意識しました。
  • 感想
    • AWSについては、事前学習動画やちょっとしたハンズオンを触っていたくらいで、正直まともに使ったことはない状態で臨みました。それでもチームのAWSに詳しいメンバーに色々教わりながらアーキテクチャ構築をしていき、最終的にアイディア出しなどで少し貢献できたことは素直に嬉しかったです。AWSが全くわからない人間から、ちょっと知ったけどあまりわからない人間に成長できたと思います（？）。非常に良い勉強になりました。これからAWSの経験を積んだ後に、この設計図を見て理解（さらに改善）できるようになりたいと思いました。
    • エンジニアとして会社に入ると、他社の人と関わる機会は大幅に減少するため、そのような意味でも非常に良い機会でした。メンバー全員が新入社員であったため、研修がどのような感じか、入社後の不安はどうかなどの少しセンシティブな話題を共有して語り合えて良かったです。またこのような機会があったら参加したいと思います。

青木の感想（Team 43）

  • アーキテクチャ設計図
    image10.png

  • 我々の班のこだわりポイント

    • データベースに’Amazon Aurora’を用いた点です。複数regionでまたがっていてもデータのやり取りができるのと、今回のケースならばDynamoDBと比べてもコストがさほど変わらないと判断したためです。
    • 開発者側の設計も考慮した点です。例えばログ管理・データ流量監視などを考えました。
      ・感想
    • 事前学習動画以外でAWSに触ってこなかったので、初めはとても不安で仕方なかったのが本音でした。実際に ”SNSサービスのアーキテクチャ設計図を作りなさい”と言われたときはわからなすぎて絶望を感じました。それでも班員とともにAWSサービスについて１つずつ調べあげ、各サービスの役割を少しずつ把握していくうちに、”なんとか設計図作れそう”と思えるようになってきました。これこそ、この３日間でAWSについて少しばかり成長した証なのではないかと私は思っています。
    • 他社の新卒社員との交流がとても新鮮かつ刺激的でした。班員４人それぞれがバラバラな職種だったため、合間の時間の雑談もとても盛り上がりました。作業中はAWSに詳しい班員から手取り足取り教わるような形になってしまいましたが、チームで１つのコンテンツを作る楽しさを体験することができて、本当に刺激的な３日間でやりごたえがありました。もう少しAWSに詳しくなったのちに同じような機会があればぜひ参加したいと思っています。

森下の感想（Team 5）

アーキテクチャ図

image2.png
私たちのチームは、いかにフルマネージドサービスで構築するかをモットーとして、アーキテクチャを考えました。（なにせエンジニアが4人しかいないですから😰）

特に着目すべき点は、WebSocketのリクエスト・レスポンスをさばく箇所にAPI GatewayとAppSyncを用いている点です。
この箇所はEC2やコンテナを用い、自分たちでAPIやWebSocketサーバを構築することも可能ですが、マネージドサービスであるAPI GatewayとAppSyncを用いました。
また、EC2などと違い、API GatewayとAppSyncは起動時間ではなく、リクエスト数に応じた従量課金制であるため、費用を抑えることができます。
ただし、AppSyncに関しては、クオータを読むとAppSync1つあたりの秒間リクエスト数が1000までとあるので、読み書きをAPIごとに異なるAppSyncを設置しています。
さらに、AppSyncの性能引き上げを申請することで今回の要求に耐えるようにしました。

ここまでで、要求に耐えうるアーキテクチャは構築できましたが、性能が足りなくなってきた時に、毎回新しいAppSyncを設置する必要があったり、AWSへ性能引き上げを申請する必要があったりします。
この点は少々手間であるなと感じました。
この点を踏まえると、さらに先のスケーリングも考慮するとWebSocketの部分はEC2やコンテナを用いたオートスケーリングする構成の方がいいのかなと思ったりしました。

まとめ

これまでも、学生時代にアルバイトやインターンシップでアーキテクチャを考えたりした経験はありましたが、今回取り組んだ規模のアーキテクチャを新卒かつ最初から構築するという場面は、現実ではほぼないことなので、貴重な経験でした。
特に、クオータを読み込むという経験は新鮮でした。これまでAWSを触ってきて、パフォーマンスの制約の壁にぶち当たることがなかったので、勉強になりました。
また、チームメンバーと技術談義をしたり、Twitterを交換したりと、社外のエンジニアさんとの交流もでき、有意義なイベントでした。

AWS JumpStart (2022/06開催)

AWS Jumpstart は、AWS初学者(他社サービスの開発経験は問わない)を対象とした、2日間の実践的な研修プログラムです。
AWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなコンテンツをというコンセプトで企画されているため、単なるAWSサービスの学習だけでなく、チームに分かれて要件に合った適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容でした。
アマゾンウェブサービスジャパン株式会社により主催され、参加者は80名以上にものぼりました。(参加対象が大きかったため、社会人経験10数年の方や学生も参加していました。)
弊社では、AWS Jumpstart for NewGradsに参加しなかった新卒エンジニア2名が参加しました。

概要

スケジュール

研修内容は以下の通りでした。
image8.png
アーキテクチャのコツに関わる講義を受けたのち、4人前後のチーム別に別れてアーキテクチャ検討をする時間が多くあるプログラムでした。それに加えて、実際にSAAの方にハンズオンをしていただき、AWSを使う経験値を高めるプログラムもありました。

事前学習動画

image9.png

  • はじめてのアーキテクティング (60分)
    Webアプリケーションを提供する際に、なぜ大半のケースでサーバー1台構成では不十分なのか、どのような観点を意識し、どのようなアーキテクチャを設計すべきなのかについて学びます。例えば、パフォーマンス・可用性の観点では、ロードバランサの導入やサーバーのスケールアウト、オートスケーリング、キャッシング等について説明し、構築・運用を楽に行うという観点では、マネージドサービスなどの技術を取り入れる意味についても説明します。
  • AWS基礎 (3時間にAWSの基礎的な概念やサービスの紹介をまとめたコンテンツです)
    AWSのSolution Architect Associate資格取得のための勉強会という体裁の動画になっていますので、まずは0:33:26からのAWSのグローバルインフラストラクチャからご覧頂くのが分かりやすいかと思います。

内容

for NewGradsと同様、大規模なチャットアプリを作るというものでした。具体的な要件はNGということでしたので、ここでは割愛させていただきます。

ハンズオンでは、WordPressを具体例に、

  • Amazon Elastic Compute Service(ECS)/AWS Fargate
  • Amazon Virtual Private Cloud(VPC)
  • Amazon Relational Database Service(RDS)
  • Elastic Load Balancing(ELB)
    を利用し、Webサービスの規模に合わせて、柔軟にシステムを拡張する方法を学びました。
    ​​image3.png

参加者の感想

大手の感想（Team 11）

  • アーキテクチャ図
    image6.png

  • 工夫した点

    • どのような理由でそのサービスを選んだのかを明確にすることで、コストを下げられたり、可用性を向上させたりすることができた。ここではAPIゲートウェイをWebソケットとして使うのか、REST APIとして使うのかを分けて考えることで、S3で代用できる機能を洗い出すことができた。
    • 明記を忘れがちなIAMロールをどこに付与するかを考えることでセキュリティへの意識が高まった。

  • 感想

    • 最初はAWSのサービスがどのような機能をもつかを調べることに精一杯だったが、チームのメンバーと相談しながらアーキテクチャ図を構築していく過程で、曖昧だったサービス概要の理解を深められた。
    • 一人で勉強するよりも、相手がいて、どのように説明すると共通認識が取りやすいかを考えることが刺激になった。
    • チームの中で考えていると「自分達のサービスが一番良い」という考えになってしまうが、AWSの方からのFBや他チームの方の質問が、自分の視野を広げるきっかけになった。

小島の感想（Team 11）

工夫した点は以下の通りです(アーキテクチャ図は、大手のものと同じ)。

  • 全てにサーバーレスなサービスを利用することで、高可用性やスケーラビリティを備えたシステムを構築しました。他チームからは「サーバーレスで全機能実現可能なんだ」「おしゃれだ」「短納期で仕上げる際にピッタリ」などという反応をいただきました。しかし、サーバーレスサービスは運用の手間が少ない反面、制約が多くなってしまうため、Lambda の同時実行数や実行時間に注意が必要というコメントもいただきました。
  • リアルタイム性が求められるチャット機能には、双方向通信が可能な API Gateway の WebSocket 通信を利用しました。
  • チャット検索機能には、OpenSearch という検索・分析が行えるサービスと、DyanamoDB の変更差分を捉える DynamoDB Streams を組み合わせて使用することを考えました。

異なる分野の方と議論を交わしたり、まだあまり理解していないAWSサービスに触れたりと、刺激の多い2日間でした。また、4月から学んできた内容をもとに議論に参加することができ、自分の理解度を確認できました。

おわりに

今回の研修を通じて、参加したメンバーは様々な学びを得ることができました。特に、日頃の業務においては、どうしても使用頻度の高いサービスに偏ってしまうことがあるため、色々なAWSサービスがありそれを知ることできたこと、また実際に開発する機会がないかもしれないほどの大規模なアーキテクチャ設計は、開発経験が比較的多いメンバーであっても、学びの多い時間でした。

1
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
4