AWS Cloud Practitioner 学習記録２（２／２）

AWS Skill Builder における下記コンテンツの学習記録（ポイントとメモ）です
AWS Cloud Practitioner Essentials (Japanese) (日本語実写版)

モジュール２：クラウドでのコンピューティング

AWS Cloud Practitioner 学習記録２（１／２）からの続き

Elastic Load Balancing (ELB)

コーヒーショップに入ってきたお客さん（リクエスト）を、入ってきた人数（トラフィック量）と店舗スタッフ（EC2 インスタンス）の状況に応じて捌いてくれるロードバランサーのサービス

Auto Scaling と組み合わせると、EC2 インスタンスが追加されたときは、それを通知された ELB は増えたインスタンスにもトラフィックを分散しはじめる
EC2 インスタンスが削除されるときは、ELB は新しいリクエストを割り振らないようにしつつ、処理中のリクエストは中断することなく終了することができるようにしてくれる

お客さん（トラフィック） ─ ELB1 ─ 注文レイヤ（EC2） ─ ELB2 ─ 製造レイヤ（EC2）　といったように ELB を介して各レイヤを結ぶことができる。ELB はリージョン単位で稼働し、リージョン内のどのレイヤのインスタンスも、１つの URL を知っていればリクエストを送ることができる
そのため各レイヤはお互いのレイヤの状況（EC2 インスタンスの増減）を直接知らなくて済むようになる（疎結合なアーキテクチャの実現）

メッセージングとキューイング

事前知識：モノリシックアプリケーションとマイクロサービス

一般的にアプリケーションは複数のコンポーネントで構成され、コンポーネントは相互に通信して、リクエストの受信、データの送信、アプリケーションの実行を繰り返す
ここで、各コンポーネントが密結合の状態にあるとき、モノリシックアプリケーションと呼ばれるアーキテクチャになっているとされ、いずれかのコンポーネントで障害が発生すると、全体に障害の影響が及ぶことになる
いっぽうで、マイクロサービスのアプローチをとったアーキテクチャでは、各コンポーネントは疎結合の状態にあり、１つのコンポーネントで障害が起きても、そのほかのコンポーネントは引き続き機能できるようになっている
このマイクロサービスのアーキテクチャは AWS においてもベストプラクティスとされ、この状態の実現をサポートするのが Amazon SNS と Amazon SQS である

Amazon Simple Notification Service (Amazon SNS)

パブリッシュ／サブスクライブ (pub/sub)¹ のメッセージング機能を実現するサービス
定義したトピックを使用して、サブスクライバーにメッセージを発行。Amazon SNS でサブスクライバーとなるのはウェブサーバ、メールアドレスあるいは AWS Lambda 関数など
送信側のコンポーネント（サービス）は、非同期で他のコンポーネント（サービス）にメッセージをブロードキャストできる

Amazon Simple Queue Service (Amazon SQS)

キューイング機能を実現するサービス
コンポーネントの間でメッセージを送信、保存、受信できるようにする
お互いのコンポーネントの状態に依存せず、メッセージを送信／受信できる

その他のコンピューティングサービス

サーバレスコンピューティング

Amazon EC2 ではサーバをプロビジョニングしてから、アプリケーション（コード）をデプロイし、実行中のインスタンスも管理する必要があった
いっぽう、サーバレスコンピューティングは、実行するコードのみを考慮すればよい、という考え方
＃もちろん、本当にサーバが無いわけではない。気にしなくてよい、と理解
AWS においてこれを提供するのが AWS Lambda （ラムダと読む）である

AWS Lambda の仕組み

1. コードを Lambda にアップロードする
2. イベントソースからトリガーするよう設定する
   Lambda のイベントソースは他のサービス、アプリケーションや HTTP エンドポイントなど
3. トリガーされたらコードが実行される
4. 実行時に使用したコンピューティング時間で課金される

コンテナ化されたアプリケーションの実行

コンテナとは、アプリケーションのコードや依存関係などを１つのオブジェクトにパッケージングしたもの
コンテナの利便性はざっくりいえば、上記の依存関係まで含めたオブジェクトにすることで、どの環境で実行しても同じように動作することを期待するもの

Amazon Elastic Container Service (Amazon ECS)

AWS でコンテナ化されたアプリケーションを実行・スケールできるサービス
Docker コンテナをサポートしている

Amazon Elastic Kubernetes Service (Amazon EKS)

AWS で Kubernetes を実行する際に使用できるサービス

Docker はコンテナを実現・管理をするもの
Kubernetes(K8s) はコンテナ群の運用・管理をするもの

AWS Fargate

AWS でのコンテナ用のサーバレスコンピューティングエンジンで、ECS と EKS の両方と連携して動作できる
以下のような組み合わせでコンテナとインスタンスを管理できる

• ECS + EC2 ：ECS でコンテナを管理、EC2 インスタンスは自分で管理
• ECS + Fargate　：ECS でコンテナを管理、インスタンスは Fargate におまかせ
• EKS + EC2 ：EKS でコンテナ群を管理、EC2 インスタンスは自分で管理
• EKS + Fargate　：EKS でコンテナ群を管理、インスタンスは Fargate におまかせ

サーバレスコンピューティングの考え方に戻ると、
Lambda は実行するコードを考慮すればよく、
Fargate は実行するコンテナ（コード＋依存関係を含む）を考慮すればよい
どちらも実行するサーバ（インスタンス）はクラウドに任せる
（任せるのでそれぞれのサービスごとに一定の制約はある）

モジュール２の学習は以上です

1. publish：出版／subscribe：購読　送る側がpublisher、受け取る側がsubscriber ↩