AWS Cloud Practitioner Essentials モジュール2 受講メモ

# AWS Cloud Practitioner Essentials モジュール2まとめ

## EC2とは

- 仮想サーバー
- オンプレミスでサーバーを管理するより、圧倒的に管理コストが低い
- 実行中のインスタンスのみに課金が発生する → 必要な時に必要な分だけ稼働させることができる
- 他の複数のインスタンスとホストを共有している → 仮想マシン
- ホスト上のインスタンスを相互分離するプログラム → ハイパーバイザー
- EC2インスタンスのプロビジョニングに使うことのできるOS
    - Windows
    - Linux
- インスタンスはサイズ変更も可能
- インスタンスのスペックを増やす → 垂直スケーリング
- インスタンスの数を増やす → 水平スケーリング
- CaaS Compute as a service

## EC2のインスタンスタイプ

- 汎用
    - ネットワークやリソースのバランスが良い
    - ウェブサーバやコードリポジトリなどの一般的な用途に使える
- コンピューティング最適化
    - コンピューティング負荷の高いタスク
    - ゲームサーバーや科学技術のモデリング等
- メモリ最適化
    - メモリ負荷の高いタスク
- 高速コンピューティング
    - 不動小数点の計算、グラフィック処理、データパターンマッチング(画像処理)、ハードウェアアクセラレータの利用
- ストレージ最適化
    - ローカルに保存されたデータのハイパフォーマンス化

## EC2の料金体系

- オンデマンド
    - 時間単位秒単位の実行時間で課金が発生
    - プロトタイプの実行などに便利
- Savings Plans
    - 1年から3年の期間で、一時間あたりの使用量をあらかじめ契約して使用
    - オンデマンドと比較して最大72%ほど費用が安くなる
- リザーブドインスタンス
    - 1年から3年の期間で利用契約を結ぶ
        - 前払い
        - 一部前払い
        - 前払いなし
- スポットインスタンス
    - 予備として確保されているEC2のコンピューティング容量を格安で使用できる
    - オンデマンドと比較して最大90%安くなる
    - 空きがない場合は使えない
    - 実行中でも、他の処理に必要となった場合に強制終了される(終了2分前に通知が来る)
    - 中断可能で一時的な処理(バッチ処理等)に向く
- Dedicated Hosts
    - 割高にはなるが、物理ホストを貸切で使用することができる
    - コンプライアンス要件を満たす時等に使われる

## EC2のスケーリング

- そこが停止すると、システム全体が停止してしまうポイント=**単一障害点**がないシステムを構築できる
- 動的スケーリング
    - 変化する需要に対してリアクティブに対応する
- 予測スケーリング
    - 予測した需要に対してプロアクティブにインスタンスを増やし対応する


- Auto Scalingグループを作成するときに、インスタンスの最小数(最小キャパシティー)を設定できる。グループの作成後はこの最小キャパシティーに基づいてインスタンスが生成される
- 最大数(最大キャパシティー)も設定できる

## Elastic Load Balancing

- トラフィックの問題を解決
- トラフィックを分散する → コーヒーショップでいうどの列に並ぶかを整理する案内係
    - 高パフォーマンス
    - 優れたコスト効率
    - 効果陽性
    - 自動的にスケーラブル
- Elastic Load Balancing
    - リージョン別の構成
    - 既存のリクエストを削除することなくトラフィックを振り分けられる
        - 新しいインスタンスがAuto Scalingで生成されたら、起動完了がELBに通知される。そうすると、ELBが再度トラフィックを振り分ける
        - インスガンスがAuto Scalingにより終了されたら、終了がELBに通知される。そうすると、ELBが再度トラフィックを振り分ける
    - ELBがリクエストを送る側と受け取るインスタンス側の仲介となることで、インスタンスの起動状況等をリクエスト送る側が意識せずに良くなるために疎結合になる。

## メッセージング・キューイング

- 密結合アーキテクチャ → リクエストする側が直接受け取る側と通信をする
    - ↑だと受け取る側が応答するまでの間待っていなくてはならず、その間他の処理を行うことができないためロスが発生する
    - どちらかで障害が発生すると、もう一方のコンポーネントも止まってしまう

**↑ではいけないので…**

- 疎結合アーキテクチャ
    - メッセージキュー
        - **Amazon SQS(Amazon SImple Queu Service)**
        - **Amazon SNS(Amazon SImple NOtification Service)**

- SQS
    - メッセージの送受信、保存
    - 任意のボリューム(いくらでも)
    - **ペイロード → メッセージに含まれるデータ**
- SNS
    - エンドユーザーにも通知を送信できる
    - publish/subscribeモデル
        - トピックを用いてサブスクライバーにメッセージを発行できる
        - サブスクライバーとして設定できるエンドポイント(宛先)
            - ウェブサーバー
            - email address
            - AWS Lambda関数

## その他のサービス

- EC2は何でもできるが、少しだけ管理が面倒
    - 内部のソフトウェアのバージョンを上げるためにパッチをインスタンスに当てる必要がある
- **サーバーレスコンピューティング → 基盤となるインフラストラクチャを意識しない**
    - 煩わしいことを意識しない
        - プロビジョニング(実行環境整備)
        - スケーリング
        - 実行可用性の確保
    - AWS Lambda
- AWS Lambda
    - アプリケーションコードをアップロードして、関数として使用する
    - 実行時間が15分以内である必要がある
- コンテナオーケストレーションツール
    - Dockerコンテナが主に対象
    - Amazon ECS (Amazon Elastic Container Service)
    - Amazon EKS (Amazon Elastic kubernetes Service)
    - これらのツールを実行するのに、EC2やFargateが使える
- AWS Fargate
    - ECS or EKS用のサーバーレスコンピューティングプラットフォーム

## コンピューターリソースの使い分け

```mermaid
graph TD;
  A[短い実行時間の機能やイベント型アプリケーションのホストをしたい]-->|YES|B[AWS Lambda];
  A[短い実行時間の機能やイベント型アプリケーションのホストをしたい]-->|NO|C[Dockerコンテナ上で動くアプリケーションをホストしたい];
  C[Dockerコンテナ上で動くアプリケーションをホストしたい]-->|YES|D[自分で環境を管理したい];
  D[柔軟性を持たせて管理したい]-->|YES|E[ECS or EKSをEC2で実行];
  D[柔軟性を持たせて管理したい]-->|NO|F[ECS or EKSをAWS Fargateで実行];
  C[Dockerコンテナ上で動くアプリケーションをホストしたい]-->|NO|R[EC2];

```

## 用語の深掘り

- プロビジョニング
    - 実行環境の整備
- コンテナ
    - OS上のアプリケーションの動作環境を仮想的に区切る技術。ある物理サーバー上に動作する複数の処理を独立したサーバー環境下のように実行することができるようになる
- コンテナオーケストレーション
    - コンテナ内部の実行環境の運用管理を自動でやってくれるツール
- マルチテナンシー
    - 基盤となるハードウェアを仮想マシン間で共有すること

## 参考文献
- https://explore.skillbuilder.aws/learn/course/1875/aws-cloud-practitioner-essentials-japanese-na-ri-ben-yu-shi-xie-ban