ELB（Elastic Load Balancing）
・インスタンス間の負荷分散を行う。
・異常なインスタンスを確認して対応する。
・パブリック、プライベートどちらでも使用可能
EC2をWebサーバーのレイヤーで使用する際に、不可分散するのためのサービス。
サーバー１台で動作させることは可用性の低い構成となり推奨されない。
複数台のインスタンスを配置することが多く、結果としてELBが必要になる。
動的にサーバーの数を増減させるAuto Scalingもコスト最適化や可用性向上になります。
単一障害点（SPOF） ある特定の部分がと間てしまうと全体が止まってしまう。
ELBの機能
・ヘルスチェック
EC2インスタンスの正常、異常を確認し、利用するEC2を被り分ける。
■UDP/TCPヘルスチェック
トランスポート層レベルで稼動状況を確認するヘルスチェック。
Web/APサーバのTCPポート（またはUDPポート）にリクエストを送信し、応答があれば稼動していると判断します。
■HTTPヘルスチェック
アプリケーション層レベルで稼動状況を確認するヘルスチェック。
Web/APサーバ上で稼動するアプリケーションにHTTPリクエストを送信し、応答が正常であれば稼動していると判断します。
・負荷分散
配下のEC2の負荷に応じて、複数のAZに跨がるEC２インスタンスの負荷分散を行う。
・SSLサポート
ELBでSSL Terminationを行える。
・スティッキーセッション
セッション中に同じユーザーからきたリクエストを全て同じEC2インスタンスに送信する。
・Connection Draining
インスタンスが登録解除されるか異常が発生した場合、
そのバックエンドインスタンスへの新規リクエスト送信を中止する。
ロードバランサーのConnection Drainingを有効にすると、
インスタンスの登録解除を報告する前に、ロードバランサーが接続を維持する最大時間を指定できます。 最大タイムアウト値は1〜3,600秒に設定できます（デフォルトは300秒です）。 最大時間制限に達すると、ロードバランサーは登録解除インスタンスへの接続を強制的に閉じます。
・S3へのログ保管
ELBのアクセスログを指定したS3に自動保管する。
ELBの種類
CLB、ALB、NLBの３つがあります。
ALBはパスルーティングによりCLBより容易にバランシング構成が可能!!
・CLB(Classic Load Balancer)
初期に提供されたELBであり、標準的なL4/L7におけるロードバランシングが可能だが、複雑な設定はできない。
ーHTTP/HTTPSとTCP/SSLプロトコルのL4とL7に対応
ーProxyプロトコルによる発信元IPアドレス識別
ーELBとバックエンドのEC2インスタンス間でHTTPS/SSL使用時にサーバ証明書認証を実施
ーCLB配下のインスタンスは、全て同一の機能を持ったインスタンスが必要
ー異なる機能に対してコンテントベースルーティングは出来ない
・ALB(Application Load Balancer)
レイヤー7の対応が強化された単一ロードバランサーで、異なるアプリケーションへリクエストをルーティングが可能。
URLパスに基づいてリクエストを転送するルールを持つリスナーを作成できます。この方式をパスルーティングと呼ばれます。複数のタスクを実施するEC２インスタンスグループを有している場合は、パスルーティングを使用して1つのALBで複数のバックエンドサービスにトラフィックをルーティングすることができます。
TCPのプロトコルはできない。TLS Terminationも利用できない。
ーL７に対応
ーパスベースルーティングが可能
ーWebSocketとHTTP/2のリクエストを受付るL７に対応
ー1インスタンスに複数ポートを登録可能
ーEC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、特定の処理を複数ポートで負荷分散することができる
ーターゲットグループでのヘルスチェックが可能
ーアクセスログの情報追加
ーEC2と同様に削除保護が可能
ーALB自体が自動的にキャパシティを増減
可能
・NLB(Network Load Balancer)
NLBは超低遅延で高スループットを維持しながら秒間何百万リクエストを捌く様に設計された新しいロードバランサ―
ー開放型システム間相互接続 (OSI) モデルの固定IPアドレスを持つL4ロードバランサ
ー揮発性ワークロードを処理し、毎秒数百万のリクエストに対応できる能力
ーVPC外のターゲットを含めたIP アドレスや静的IPアドレスでの登録可能
ー複数のポートで各インスタンスまたは IP アドレスを同ターゲットグループに登録可能
ー大規模アクセスが予測される際にCLBやALBで必要だったPre-warming申請が不要
ーALBやCLBはX-Forwarded-Forでアクセス元IPアドレスを判断していたが、NLBは送信元IPアドレスと送信元ポートの書き換えを行わないため、パケットからアクセス元が判断可能
ーNLBはフォルトトレランス機能を内蔵したコネクション処理を持ち、数カ月から数年のオープンなコネクションを処理できる
ーコンテナ化されたアプリケーションのサポート
ー各サービスの個別のヘルスステータスのモニタリングのサポート
Auto Scaling
EC2の利用状況に応じて自動的にインスタンスの台数を増減させる機能で、リソースの最適化、耐障害性の向上も行う。
・スケーリングポリシ-
動的なスケーリング・予測スケーリング・スケジュールスケーリング
動的スケーリングにはさらに３つのスケーリングがある
・簡易的なスケーリング
CPU８０％を超えたらというように、１つのメトリスクに対して設定する。非推奨
・ステップスケーリング
１つのメトリスクに複数の設定を行う、CPU７０％を超えた場合、CPU８０％を超えた場合と段階毎の設定を行う。簡易スケーリングよりこちらを推奨している。
・ターゲット追跡スケーリング
１つのメトリスクに対して目標値を設定する。CPUの利用率を７０％にという目標値を設定すると、Auto Scalingグループ全体でCPU７０％を維持できるように自動調整される。
・終了ポリシー
スケールインを行う際に、どのインスタンスから削除を行うか設定ができる。
ECS（Amazon Elastic Container Service）
Dockerコンテナ環境を提供するサービスです。EC2インスタンス上で実行されるコンテナのことをTaskと呼び、EC2インスタンスのことをClusterと呼びます。１つのCluster上で複数のTaskを実行ができる。Cluster上で動作するTaskの定義はTask Definitionで行う。
４つの分類からなる。
・クラスター・・・コンテナの配置等の管理する範囲
・サービス・・・タスクの管理
・タスク・・・コンテナの管理。１つ以上のコンテナがある。
・タスク定義・・・負荷分散などを行える。スケーリングをする。
ECS には、Fargate起動タイプとEC2起動タイプという2種類の起動モードがあります。
より管理をかけずに利用できるのがFargate起動タイプです。
・Fargate
EC2を使わずにコンテナを動かすことができる。クラスターの管理が不要になり、ECSよりもアプリケーション開発に集中ができる。各タスクに割り当てるCPUとメモリに応じて利用料金が決まる。
Fargate起動タイプではユーザーが実施する設定作業は、コンテナ内のアプリケーションのパッケージ化、CPU要件やメモリ要件の指定、ネットワーキングポリシーやIAMポリシーの定義、アプリケーションの起動のみです。
EC2のようなインスタンスの詳細な設定などは必要ありません。
・ECR
完全マネージド型のコンテナレジストリです。
このレジストリを使うと、コンテナイメージとアーティファクトをどこにでも簡単に保存、管理、共有、デプロイできます。
ECRではコンテナーオーケストレーションを利用することはできません。
・EKS
コンテナ化されたアプリケーションのデプロイ、管理、スケールをKubernetesを使ってAWSで簡単に実行できます。
補足
ースケールアップ
メモリやCPUの追加・増強
高負荷に耐えるためにEC２インスタンスのスペックをあげる対応
ースケールダウン
メモリやCPUの削減・低性能化。
ースケールイン
処理する機器・サーバー台数を低減する。
ースケールアウト
処理する機器・サーバー台数を増加する。