🦔

AWS JumpStartに参加してきました。 2022/0616~17

2022/08/05に公開

AWS

6/16~17にかけて行われたAWS Jupstartに参加してきましたのでそのレポートです。

本イベントは完全オンラインでの実施でした。

イベント概要

AWS JumpStart はAWS初学者のエンジニアの方々を対象とした、実践的な研修プログラムです
将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します
単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております
例えば、以下のような方々にもオススメです！
・AWSの名前は知ってるが使ったことは無い
・EC2等の単体サービスは触ったことあるが、全体のアーキテクティングは経験がない
・クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい

とのことです。実際に参加してみた感じ、AWSが完全にわからない人やエンジニアリング完全未経験ではかなり厳しいイベントだと思います。軽くAWSは触ったことがあって一般的なサービスは理解できる。普段はコーディングやマネジメントばかりで、AWSはあまり良くわかっていない。くらいのエンジニアの方が多い印象でした。

事前学習内容

実施前に事前学習用の動画を頂きました。
広くAWSのサービスを理解できるとても良い動画で非常に勉強になりました。

はじめてのアーキテクティング (60分)

Webアプリケーションを提供する際に、なぜ大半のケースでサーバー1台構成では不十分なのか、どのような観点を意識し、どのようなアーキテクチャを設計すべきなのかについて学びます。例えば、パフォーマンス・可用性の観点では、ロードバランサの導入やサーバーのスケールアウト、オートスケーリング、キャッシング等について説明し、構築・運用を楽に行うという観点では、マネージドサービスなどの技術を取り入れる意味についても説明します。

AWS入門

AWS基礎 (3時間にAWSの基礎的な概念やサービスの紹介をまとめたコンテンツです)
AWSのSolution Architect Associate資格取得のための勉強会という体裁の動画になっていますので、まずは0:33:26からのAWSのグローバルインフラストラクチャからご覧頂くのが分かりやすいかと思います。

※大規模な展開はNGとのことでしたのでURLの公開は控えさせていただきます。

Day1

では、day1です。

初日は座学と、アーキテクチャ検討。午後はハンズオンというスケジュールでした。

座学の内容

ユーザーが少ない段階から複雑な構成にするのは管理・運用の観点から非推奨。フェーズに合わせた構成にしましょう。

大体こんな感じの講義が行われ、実際にAWSを利用した場合の構成などの説明を受けました。

講義の中でのQ&Aをまとめます。

Q&A

Q.構成が安価であるかどうかはどのように判断するのか。構成が適切か判断する方法。
A.まずはどこにコストがかかるか注目する。そのうえで、抑えられそうな予算（EC2の性能）を抑える。安価かどうか判断するのは予算に応じるのでビジネス的な判断になる。可用性・拡張性のバランスが重要。

Q.スタンバイとリードレプリカは別？リードレプリカにフェイルオーバーすることはない？
A.別系統になる。スタンバイはフェイルオーバー用途。スタンバイに対してクエリは投げられない。リードレプリカと入れ替わることはない。ただし、オーロラ以外の話。オーロラはリーダーとライターの概念。オーロラの場合はリーダーがリードレプリカとスタンバイの両方の役割を果たす。

Q.プロト開発段階で中長期の拡張性は意識した上でシンプル構成作るのかのか気になります！それとも中長期に直面したときに拡張性は考えるでも遅くないのか。
A.どのくらいの規模感を想定しているかにもよる。そこまでの規模でないのであればシンプルな構成で良い。

Q.AZ（アベイラビリティゾーン）レベルの障害って amazon御祭になってる時が多いから、許してくれる事が多いのかなぁって思います。( 予算感次第ですが）
A.マルチAZの構成が一般的。テストをしっかりやって切り替わるか確認する必要がある。マルチリージョンまではやる必要ない。

Q.本当のプロトタイプのときは、EC2の代わりにLambdaを使うことも考えられるんですかね？？
A.あり。慣れているならむしろ良いのかも。開発を楽にやっていくというという考えはある。

こちらは要件にも寄るかと思います！
例えばlambdaはシンプルな機能が得意だったりサーバレスで処理がスケールしやすいメリットが合ったりしますが、処理の15min制限があったり、複雑な処理の場合はEC2上の方が構築しやすい場合があります！
両方ともある意味ロジックを書けるという意味ではなんでも出来るので、制約と要件・コスト面(運用/料金)周りで総合的に見て頂く形になるかと思います！

Q.Amazon Lightsail とかもコストだけなら安くなるしALBやCloudFrontを足してもコスト感は変わらないし結構色々と論点は有りそうな気も?
A.たしかに他のプロダクト利用も検討したほうが良い。

Q.AZ間のプライマリとスタンバイのデータシンクを同期するか非同期にするかは設定でコントロールできるものですか?
A.できない。

こちらは個別に設定するというよりは、それぞれの構成によって同期、非同期が決まっているのでこちらの図を参照いただくと良いかもしれません！

Q.セッション情報を、インメモリキャッシュに格納させる場合、AZをまたいでインメモリキャッシュを参照できますか？
A.できる。AWSのAZは気軽にまたがれるというコンセプト。ただしレイテンシーが1m秒有るので考慮する必要がある。

Q.Auroraが互換性を持っている(MySQL, PostgreSQL)を使いたい場面ですと、RDS for MySQL、RDS for PostgreSQL使うよりAuroraを使う方が良いのでしょうか？
A.AWS目線ならオーロラを推奨。他の要件があるなら他を検討。

Q.Auto Scalingを有効にした際に、DDoS攻撃とか悪意あるリクエストなどで、インフラコストに対しての攻撃を心配しています。これの自衛はクラウド利用者側で頑張ることでしょうか？
A.DDoSはある程度裏で無料で対応している。また、WAFでの対応もできる。マキシマムの台数が有るので現実的な値にしておけば問題ない。

アーキテクティング課題

👇課題はこちら

会話の方向性

まずは、課題とスケジュールの確認。どのような機能をいつまでに、質問はいつできるか確認した。
それぞれどのくらいの機能が求められるか考えたが、後からでいいよねという結論になった
その後、たたき台の環境に対してどのようなことを追加で考えなくてはいけないか洗い出した。ログ収集など。
その後、どのような機能要件・非機能要件があるか洗い出し、どのようなサービスで解決できそうか考えた
一旦話がちらばりイメージできなくなってしまったので、みんなで情報収集し直すことにした。
結局、まとまりきらずアーキテクチャ図の作成はほとんど進まず終わった。
明日本当にまとまるのか？

スケーラブルハンズオン

午後はスケーラブルな構成を作成するハンズオンを行いました。
正直リクルートのハンズオンのほうが全然難しいので、私は難なくできました。

Day2

会話の方向性

Websocketを使用した相互の通信のほうがやりやすいのでは
そしたらRedis使うか
インメモリは高くないか？RDSと併用する？
ユーザー認証とかチャット機能以外のところは違うサーバーで処理したい。疎結合にしたい
DBはなにつかう？どのように安定に稼働させる？バックアップ体制など。
役割分担してそれぞれ調べてみよう

SAに対する質問タイム

Q.EC2・ECS・Lambdaのの使い分けってどうするんですか？
A.まずはLambdaは話し違うので、分ける。コンテナ使わないならEC2一択。コンテナ使いたいなら、EC2かfargateか検討することができる。fargateのほうがマネージドで管理が楽な一方で、チューニングなど細かい設定ができない。チューニングができるがマネージドではないため、EC2は管理が少し大変になってしまう。その辺のトレードオフ。そしてLambdaは簡単な機能ならすごく良い。複雑なものはサーバレスで処理するのは難しいかもしれないが必要に応じてAPIリクエストをすれば良い。基本的に、ピークが急激に登らない（オートスケールが間に合わない）場合や安定して稼働し続けるのであればサーバーを使用したほうがコストが安いことが多い。

Q.ECSでEC2使うのとfargate使うのと、違いは？
A.fargateはまずマネージド。EC2のほうがチューニングとかしやすいけど、バージョンアップとかの保守管理が面倒。

自チームのアーキテクチャ図

一番議論したのは、チャット機能をサーバレスにするのかいなか。サーバーを使うにしても、コンテナ化するのか。コンテナ化するにしてもファーゲートを使うか。はたまたEC2で運用するのか。最終的にはサーバレスにすることにした。

方針として、リアルタイム通信はWebsocketを使うことにしていたのでサーバーを使うのであればNode.jsを利用して実装。そうでなければ、APIGateWay×LambdaかAppsyncを考えていた。Appsyncはメンバーが理解できなかったので、選択肢が2択に絞られた。

今回の仕様を考えると、チャット機能の部分は複雑なコードにはならなそうなので、高いスケーラビリティがあり管理が楽なLambdaを使用することにした。

認証機能などは、複雑なコードになるのでサーバーを使用することにした。ただし、管理が楽になるようにコンテナ管理にすることにした。そのため、マルチAZでの実装となっている。

データに関して、チャットデータはシンプルであるためNoSQLを使用。マルチAZで読み書き高速＆高可用性のDynamoDBを使用することにした。Pub/Sub用のDBにはインメモリキャッシュのElastiCasheを使用することにした。認証用のDBも高速に処理できるようにElastiCasheを選択した。いずれもマルチAZの構成にして可用性を担保した。その他の情報に関しても可用性が高いAuroraを使用することにした。

コンテンツ配信に関してはCloud Frontを使用することにした。

他チームの発表

皆さん、もっと詳細な構成を作成されていたり、予算を見積もっていたり、中にはデータベースの設計まで考えているチームがありました。他チームのアーキテクチャ図を載せることはあまり良くないと思うので今回は避けさせていただきますが、イメージを掴んで頂く為に、質問されていた内容を一部記載します。

Q.すごく詳細まで詰まっているがどのように役割分担したのか。
A.自分の認識では、チャットのパターンを雑にサーベイ。Appsync使っている例がおおいのでそこは合意が早かった。その先をどの機能使うか分けて各々で調査した。原案を誰かが書く。スキーマも含めて。それをみんなで突っ込む。

Q.ECSでファーゲートにしなかった理由。
A.起動に時間がかかる場合があるから。EC2でデカめにプロビジョニングしたほうが良いのではという結論。

Q.Orpensearchの更新はどうするの？
A.同期のジョブをSQSで発行する。直接は投げない。処理がコケたときのために。新しいメッセージごとに来るごとにOrpensearchに投げる。失敗したらリトライを頑張る。

Q.ルームに入った際の情報取得に関して、年間すごい量のメッセージになるが問題ない認識？
A.リードに関しては問題ない認識

Q.ルームに入った瞬間にメッセージを送られちゃうと情報がとれない場合もあるのでは？
A.ある。API側で定期的に漏れがない確認する必要がある。

だいたいこんな感じで質問されます。「うっっっ」と思う質問もされることがありましたｗ

まとめ

大体こんな感じです。自分のチームは個性豊かなメンバーでそれぞれの経験や知識を同時に学べて非常に有意義な時間を過ごせました。

また、社外のエンジニアとコミュニケーションを取れるいい機会にもなり、とても刺激になりました。みなさんも是非参加してみては？