こんにちは、クラウドインテグレーション事業部MSP所属の岡本悠希です。
今回は、AWS主催の初学者向けイベントのAWS JumpStartに参加したイベントレポートをしていきます。

AWS JumpStartとは

「AWSってよくきくけれどサービスについていまいちわかっていない」

そんなふうに思っている新卒を含む AWS 初学者のエンジニアを対象としたイベントです！

このプログラムは事前学習コーナーと座学、実践からなっており、フルスタック人材育成の足掛かりとなる実践プログラムです。

このプログラムでのゴールは以下三つ。
・一般的なリファレンスアーキテクチャを理解すること
・AWSコアサービスの概要を理解しサービス選定基準を理解すること
・AWSのアーキテクチャ図を作成するまでの流れを知ること

AWSについて自信がないあなたにとってレベルアップにもってこいなイベントです！

1日目

さて、初日となる1日目は座学講習＋実践で構成されていました。
座学では「Webアプリケーションとは？」「S3とは？」や「VPCとは？」といった基本的なことを改めて学習する機会になります！

今回のイベントでは事前学習用の動画も用意されており、「とりあえずサービス名称は知っている」程度の知識で参加できます。

座学はZoomで、実践はDiscordにてチャットベースの会話が行われました。

余談ですが、チャットにはDiscordサーバーが必要でした。

私自身もサーバー設定と認証で戸惑った経験から、後ほど「Discordの作り方」として設定方法と認証について補足します。

 

Webアプリケーションとは何か？

座学講義の初めでは、Webアプリケーションの仕組みから紹介が始まりました。
みなさんは、普段通販サイトやブラウザゲームを利用されることはありますか？

これらはクライアントと呼ばれる私たち側のPCやスマートフォンからWebブラウザを通じてアプリを提供している企業のサーバーに「〇〇についての情報をください」とリクエストしています。
その応答結果が私たちのPCやスマートフォンに表示されています。

この場合、Google Chrome、Microsoft Edge、 Firefox、 SafariなどがWebブラウザになります。

サーバー側では、クライアントからの要求に応えるため、必要な情報を集めたり、迅速に返答するための仕組みがあります。
そのひとつがキャッシュ機能やデータベースの最適化です。

また、サーバーがより複雑な内容をクライアントに返すためには、サーバー側の構成が重要になってきます。
例えば、OSの種類やサーバーの数や物理的にあるものなのか、仮想のものなのかといった点です。
他にもデータベースの種類や量、ストレージに関する問題もあります。

オンプレミス環境を使うのかクラウド環境を使うのかでもクライアントへの応答速度が変わることがあります。

オンプレミス環境では、サーバー、データベース、ストレージの数量などを事前に予測して購入しておく必要があります。これは、クライアントからの需要が予測しやすい場合に適した選択肢です。

クラウド環境の場合は、サーバーの数量、データベースの数量、ストレージの数量などを需要に即して増減することができます。

実践編（午前の部）

続いて、VPCやEC2を実際に設定してみるといった本当の初心者向けの実践コーナー。
チームで指示役と実行役に分かれて作業しました。

実際のオンプレミス環境の構築現場でも、再確認者と操作者に分かれて作業することがあります。指示役と実行役に分かれることで、誤りのない操作を行い、お客様の環境を守るための複数回の確認を行うという意図を認識できました。

なお、作成したサービスはVPCやS3など基本的なものばかりでしたので、詳細な手順は省略させていただきます。
イメージが欲しいなという方にはアイレットの「雲勉」「第68回 雲勉【インフラエンジニア向け】 VPCから始めるネットワーク入門 」がおすすめです！

実践編（午後の部）

次はワークを使いつつ、VPC、FireWall、EC2、RDSを設定することになりました。
この段での最終目標はメモアプリ作成です。

構成そのものは参加者以外には秘密のため、ぜひ参加してチャレンジしてみてください。

ひとつだけこっそりお伝えすると、AWS Amplifyを使う機会がありました。
AWS Amplify　解説動画はこちら

その前に、座学コーナーがありました。
座学では、構成を考えるときのコツが紹介されました。

ひとつ目のコツは構成を考えるときクライアントの数を視野に入れて考えます。
たとえば、もしあなたのWebサイトを使う人がたった一人だけなら、Webサイトを動かすサーバーも、データをしまっておく場所（データベースサーバー）も、それぞれ一つずつで十分間に合います。

しかし、もしWebサイトの利用者が100人、1000人と急激に増えたらどうでしょう？
たった一つのサーバーでは、たくさんの人のリクエストを同時に処理しきれなくなり、Webサイトの動きが遅くなったり、最悪の場合は止まってしまったりするかもしれません。

このような状況を避けるために、利用者の増加が見込まれる場合は、あらかじめWebサイトを動かすサーバーの数を増やしたり、もっと性能の高いサーバーに切り替えたりして、より多くのリクエストに対応できるような仕組みを考える必要があります。

このように、Webサイトを作る際には、将来的にどれくらいの人が利用する可能性があるかを予測し、それに合わせてサーバーの数や性能を調整することで、常に快適なサービスを提供できるようになるわけです。

二つ目のコツは、アーキテクチャを考える上で構成要素が増える場合、それらを一つずつの要素に分解して考えることです。

例えば、Webアプリケーションを作るぞ！となってもいきなりではどこから手をつければ良いのかわかりません。
そこで、役立つのが「分解」するというコツです。

まずは大きくWebアプリケーションを作ることを目標にします。
次に「守りの役割を強化するには、どんなサービスや仕組みが必要か？」「Webサイトの情報を素早く届けるためには、どんな設定やサービスが最適だろう？」というように、一つ一つの役割ごとに必要なものを考えていきます。

それぞれに最適な方法やサービスを選んでいくことで、複雑なシステムも効率的に、そして抜け漏れなく作り上げることができます。

2日目

オープニング

2日目オープニングはクイズから始まりました！クイズについて出題された内容はこんな感じです。
オブジェクトストレージと言えば？

オブジェクトストレージと言えば？
A.S3

サービス名を知っていれば解答しやすい問題で、出題者もAWSクラウドプラクティショナーの知識レベルを想定していました。

1〜3問目は基本的な問題でしたが、4、5問目は記述問題でした。

「Webシステムを運用しています。運用をしていく中で、下記課題を抱えています。
どのような対策が考えられるか考えてください。」

この問題では構成に使われているサービス名と今の課題（課題例：アクセス人数が増える予想がある、レスポンスが悪い）が与えられ、どうするかの記述が求められました。

難易度はアソシエイト級です。
記述問題というところで参加者の意見は少しばらけた印象でした。

実践編（2日目午前〜午後）

2日目は、チームのメンバーと与えられたお題に対してのアーキテクチャを考える内容でした。

1日目に学習した内容をもとにアーキテクチャをチームで考え合いました。
私のチームでは普段アーキテクチャに深く関わらない業務に携わる人たちから構成されていたため、どのような構成が最適か議論白熱といった様相をしていました！

途中で追加要件も増えたりとなかなかに難しいお題だった印象があります。

最終的に、いくつかの有志グループのアーキテクチャが評価され、その後、AWSの方がこのお題に対して検討した最適なアーキテクチャが紹介されて終幕となりました。

２日間を通して

サービスだけでなくアーキテクチャも理解することの重要さを知れた2日間でした！
特に、アーキテクチャを考えることに焦点を当てた2日目は、MSP業務をより深く理解できる内容だと個人的には感じました。

なお、MSPとは弊社の24時間365日対応の保守運用サービスを提供するセクションになります！

MSPに少しでも興味をお持ちいただけたなら、ぜひこちらのページをご覧ください！

おまけ・Discordの作り方

参加者の中にも認証で困惑される方が多かったため、設定の備忘録として記しておきます。

1.メールアドレスと生年月日、ユーザ名、パスワードを設定します。

2.認証画面で「他と異なるものを選んでください」と表示されたら、丸くない（しわしわの）ボールを選択します。

3.AWSから送られてきているDiscordのアドレスへ！