AWS JumpStartに参加して

Lancers（ランサーズ） Advent Calendar 2022の18日目を務めます、manamin0521mです。

今年の10/20（木）~21(金)に下記のAWS JumpStartというAWSのイベント(研修)に参加してきたのですが、今回は事前研修や当日に学んだことを記載したいと思います◎
https://awsjumpstart221020.splashthat.com/

(スライドはイベントにて共有された動画や資料より引用させていただきました。)

どんなイベント？

AWS初心者向けと対象とした、アーキテクチャを設計、検討するイベントでした。所感としては、AWSは初心者でもエンジニア歴がそこそこ長い方やインフラ自体に詳しい方などが多かった印象で、詳しい方でも十分に楽しめるイベントだったように思います。年に4回開催され、無料で参加できるので興味ある方はぜひ！（平日二日間）

AWS JumpStart はAWS初学者のエンジニアの方々を対象とした、実践的な研修プログラムです
将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します
単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております

スケジュール

事前に研修動画を見た上で当日を迎え、講義パートが半日ほどあり、残り1日半ほどは運営から割り振られたチームにて与えられたお題に対してアーキテクチャを検討しました。

学んだこと

アーキテクチャ設計とは

解決したいビジネス課題のためにWebアプリがあるので、ビジネス課題を解決するためには、機能要件(実装する機能に関する要件)以外に、非機能要件（機能以外の品質に関わる要件）やプロジェクト上の様々な制約を満たすことを考える必要がある。よってそれらの要件や制約を含めて、アーキテクチャを設計することが必要となる。

アーキテクチャ設計で意識すべき観点

1.どれほどの信頼性を求めるのか

信頼性とはあるサービスが停止することなく正常に機能し続けることができること

信頼性の解決策例

• ロードバランサで複数台のサーバーに負荷を分散する
  • AWSの場合、Application Load Balancer（ALB）などがロードバランサに該当する
    
• 複数のデータセンターを活用する
  • ひとつのデータセンターに障害が起きても別のリージョンのデータセンターに切り替え可能
  • AWSの場合、複数のAvailability Zone（AZ）からなるリージョンを複数選ぶ(Multi-AZ)
    
• DB障害時にはフェイルオーバー時にレプリケーション先に切り替えることで、短いダウンタイムでサービスを復旧できるようにする
  • AWSの場合、RDSなどがDBサーバーに該当
    

2.どれほどのスケーラビリティ・パフォーマンスを求めるのか

ユーザーの増加に伴いロードが遅くなってしまう。そのため以下の方法で解決する。

スケーラビリティ・パフォーマンスの解決策例

• 複数台のサーバーでスケールアウト可能な構成にする
  • AWSの場合、EC2などをロードバランサでスケールアウト可能に
    
• 読み込み専用のDBサーバー（リードレプリカ)を活用する
• Redis、memcashedなどのインメモリデータストア（キャッシュ）を活用する
  • AWSの場合、 ElastiCachなどがインメモリデータストアに該当
• リクエストごとに内容が変わらない、画像やCSSなどのStatic(静的)なコンテンツ配信に適した仕組みを活用する
  • AWSの場合、S3が該当
• 世界中に大量に配置されたキャッシュサーバー群であるCDNを活用し、そこにStaticなコンテンツをおく。よりユーザーに近い場所にあるので高速化可能
  • AWSの場合、CloudFrontがCDNに該当
    

3.効率よく開発や運用を行えるのか

ログを確認する際に毎回サーバーに入る必要があると障害時の復旧に時間がかかる。そのため以下の方法で解決する。

効率よく開発や運用を行うための解決策例

• メトリクスやログを収集、活用する仕組みを整備する
  • AWSの場合、CloudWatchなどが該当
    
• CI/CDの仕組みを用意し、デプロイ可能な状況かをこまめにチェックし、デプロイの準備や自動デプロイができるように。
• インフラのコード化を行う
• AWSなどのマネージドサービスを組み合わせ、より楽にシステムを運用、構築するようにする　（マネージドサービスは制約があるものの、楽に構築ができる。）

4.コストは最適化できているのか

解決策例

• コストの概算と内訳を把握する
• 適切なサイズやタイプのリソースを選択する
  
• オートスケーリングを活用する
  

5.セキュリティ観点での検討

解決策例

• リスクを洗い出し、何をどこまで守るか検討
• ガイドラインを参考にできてることか否かを確認するベースラインアプローチ
• 詳細リスク分析（情報資産、脅威、リスク、対策を分析）

Ex.信頼性が高いサービスの構成

• ロードバランサ使用で複数台のWebサーバーを使用し、負荷を分散。
• DB障害時にレプリケーション可能にしている。

Ex.大規模なサービスの場合で信頼性が高いサービスの構成

前述の構成に加え

• 頻繁に使うデータをキャッシュに入れるためにキャッシュサーバー使用
• staticなコンテンツはCDN使用し、取り出す時間を短くする
• 読み書き専用と、読み込み専用にDBサーバーを分ける
  といったことを変更している。

アーキテクチャ設計 進め方の例

1. 要素技術、アーキテクチャ設計の基礎、一般的な構成例を学ぶ
2. ビジネス要件からシステムに求められる要件を整理、仮定する
3. 抽象的な設計から始めて具体に落とす
4. 必要に応じてコアとなるシステムの検証を実施
5. 設計・実装後に負荷テストを行い、要件を満たしているか確認

アーキテクチャ設計において大切なこと

• 全ての要件や制約を満たすことが難しい場合はビジネスを成功させる上で優先させるべき点に立ち返り、トレードオフの中で判断する
• 要件を満たす中でできるだけシンプルな構成を検討する

感想

最後に発表会を行ったところどのチームも全く異なるアーキテクチャを組んでいたのが印象的でした。また、自社のアーキテクチャに引きづられずに、要件に適した選定をしていたほか、複数の選択肢の中から最適なアーキテクチャを選んでいたことから、それぞれのマネージドサービスの特性をもっと知ってみたいと思いました。