SAA-C02の模試を受け55%ほどしか点数が取れませんでした。
勉強に使用していた資料はSAA-C01用のものだったので、不足分を補うためにBlack Beltを試聴しました。
#参考にした資料
AWS Black Beltの資料をまとめました
YouTubeでBlack Beltをみると資料の一部訂正なども入っていたので、pdfのみではなく動画で一度視聴していただいた方がいいかもしれません
https://d1.awsstatic.com/webinars/jp/pdf/services/20191029_AWS-Blackbelt_ELB.pdf
#ELB概要
###ELBを導入するメリット
負荷分散してスケーラブルなシステム構築が可能
ELB自体も負荷の増減に応じて自動的にスケールする
###ELBの種類
Aoolication Load Balancer(ALB)
Network Load Balancer(NLB)
Classic Load Balancer(CLB)
※この記事ではカッコ内の略称で記述します
#ELBの基本性能
ELBの種類によって使用できない設定もあるので注意
使用できるELBの種類をタイトルの横に記述してあります
###複数のアバイラビリティーゾーン（AZ）に分散【ALB/NLB/CLB】
ELBは正確には二段階で負荷分散を行っています
1.DNSラウンドロビンで各AZ内のELBに振り分ける
2.負荷が均等になるようにEC2に振り分けを行う（ELBの種類により振り分けを行うアルゴリズむが異なる）
アルゴリズムの種類
| ALB | NLB | CLB |
|---|---|---|
| ラウンドロビンルーティング | フローハッシュアルゴリズム | TCP：ラウンドロビン,HTTP/HTTPS:hte least outstanding requests routing algorithm |
###クロスゾーン負荷分散【ALB/NLB/CLB】
リージョン内の複数AZ内に負荷分散可能
複数リージョンへの分散にはRoute53を併用
AZごとのEC2インスタンス数が異なってもクロスゾーン負荷分散によりすべての負荷分散を均等にできる
クロスゾーン負荷分散のデフォルト設定
| ALB | NLB | CLB |
|---|---|---|
| デフォルトで有効 | デフォルトで無効 | デフォルトで有効 |
###同一インスタンスへの複数ポートに負荷分散【ALB/NLB】
・EC2インスタンスをターゲットに割り当てる際に複数のポートを個別のターゲットとして登録することが可能
・一つのインスタンスに対して複数ポートで負荷分散することが可能
・コンテナ用いる際には、同一インスタンス上で複数のコンテナをを運用する必要があるので有効
・ECSを利用の場合には動的ポートマッピング機能を利用できる
###IPアドレスをターゲットに指定【ALB/NLB】
オンプレミス のサーバーにも負荷分散を行う場合、Direct Connectなどでオンプレサーバーと接続を行いIP指定で負荷を分散することが可能。
##ELBのモニタリング・ログ
###ヘルスチェック【ALB/NLB/CLB】
ELBは正常なターゲットのみにトラフィックをルーティングする
ELBは設定値に基づき、ターゲットに対してヘルスチェックを定期的に行い正常なターゲットかを判定する
正常判定が厳しすぎるとインスタンスが使えるまでに時間がかかり、逆に異常との判定が厳しすぎても、過負荷時に処理できるインスタンスを減らしてしまうことにもなる
| 設定 | 説明 | 設定例 |
|---|---|---|
| プロトコル(HealthCheckProtocol) | ターゲットにヘルステェックをジックするときにロードバランサーが使用するプロトコル | HTTPで200が返るのを確認 |
| ポート(HealthCheckPort) | ターゲットでヘルスチェックを実行するときにロードバランサーが実行するポート。デフォルトは各ターゲットがロードバランサーからトラフィックを受信するポート | トラフィックポート |
| パス(HealthCheckPath) | ヘルチェックのターゲット送信先であるpingパス。デフォルトは/ | /index.html |
| タイムアウト時間 | ヘルスチェックを失敗とみなす、ターゲットからレスポンスのない時間範囲は2~120秒 | 5秒 |
| 正常のしきい値(HealthyThresholdCount) | 異常なターゲットが正常とみなされるまでに必要なヘルスチェックの回数 | 5 |
| 非正常なしきい値(UnhealthyThresholdConut) | ターゲットが異常とみなされるまでに必要なヘルスチェックの回数 | 2 |
| 間隔 | 個々のターゲットのヘルスチェックの概算期間 | 30秒 |
| 成功コード | ターゲットから正常なレスポンスを確認するために使用するHTTPコード | 200 |
###運用のモニタリング【ALB/NLB/CLB】
cloudWatchによりELBのメトリクスを60秒間隔で監視可能
統計情報として平均（average）、合計（sum）、最大値(max)、最小値(min)などを表示できるが各メトリクスによってどの統計で監視するかが適切かはことなるので注意
| 設定 | 説明 | 設定例 |
|---|---|---|
| HealthHostCount | 正常なバックエンドホスト数 | |
| UnHealthHostCount | 異常なバックエンドホスト数 | |
| RequestCount | リクエスト数 | |
| Latency | 遅延時間 | |
| HTTPCode_ELB4XX、HTTPCode_ELB5XX | ELBが返した4XX,5XXのレスポンス数 | |
| HTTPCode_Backend_2XX,HTTPCode_Backed_3XX,HTTPCode_Backed_4XX,HTTPCode_5XX | バックエンドが返した2XX,3XX4XX,5XXレスポンス数 | |
| BackendConnectionErrors | バックエンドへの接続エラーの回数 | |
| SurgeQueueLength | バックエンドへの保留中の件数 | |
| SpilloverCount | キュー溢れのため拒否した件数 |
###アクセスログの記録【ALB/NLB/CLB】
最短５分間隔でELBのアクセスログを取得可能
指定したS3バケットに簡単にログを自動保管
ELBの種類によってアクセスログの出力フィールドも異なる
##コネクション
###コネクションタイムアウト【ALB/NLB/CLB】
無通信状態が続くとコネクションが自動で切断する
| ALB | NLB | CLB |
|---|---|---|
| デフォルト:60秒 | 350秒固定 | デフォルト:60秒 |
ALB/CLBのコネクションタイムアウト値は変更が可能
1~4000秒の間で自由に設定可能
###Connection Draining(登録解除の遅延)【ALB/NLB/CLB】
バックエンドからEC2インスタンスをELBから登録解除したり、ヘルスチェックが失敗した際に新規リクエストの割り振りは中止して、処理中のリクエストは終わるまで一定期間待つ
・全てのELBでデフォルトで有効、タイムアウト300秒
・タイムアウト最大3600秒
###スティッキーセッション【ALB/CLB】
######同じユーザーからきたリクエストをすべて同じEC2インスタンスに送信
・アプロケーションでのsession情報、一時ファイルなどをEC2インスタンスに保持する構成の場合に必要
・デフォルトでは無効、利用するためには有効にする
・HTTP/HTTPSでのみ利用可能
スティッキーセッションを使わない設計が理想
EC2インスタンスの増減を柔軟に対応できるように、session情報などは別のDBサーバーやキャッシュサーバーに持たせる設計が望ましいため。
この場合スティッキーセッションは不要。
######ロードバランサーによって生成されるクッキーを使用したスティッキーセッション【ALB/CLB】
・session開始からの有効期間を指定してELBで制御
・無制限にすることも可能（無制限でもブラウザを閉じれば終了）
######アプリケーション生成のクッキーを使用したスティッキーセッション【CLB】
・アプリケーションが作成したcookieに合わせる
・アプリケーションが作成するcookie名を指定
##セキュリティ関連
######SSL/TLS Termination
ELB側でSSL/TLS認証ができる
通信パターン
1.ELBでSSL Terminationし、バックエンドとはSSLなし
2.ELBでSSL Terminationし、バックエンドとは別SSL
3.SSLをバイパスしてバックエンドTCPで送信
| ユーザー→ELB | ELB→バックエンド |
|---|---|
| HTTPS | HTTP |
| HTTP/SSL | HTTPS/SSL |
| TCP | TCP |
##HTTPS/SSL利用時のTLSサーバー証明書【ALB/NLB/CLB】
AWS Certificate Manager(ACM)を使用すれば証明書のリクエスト、管理更新、プロビジョニングが容易に実行可能
・無料で証明書を利用可能（ACMと統合されているELB、Amazon cloud front,Amazon API Gateway）に対してのみ
・証明書は自動更新されるので失効の心配がない
・ACMで発行される証明書はドメイン認証タイプの証明書なのでより上位の証明書（OV,EV）を利用する場合にはサードパーティ製の証明書を取得してインポートして利用
##SNIでの複数TLS証明書のスマートセクション【ALB/NLB】
複数の証明書を一つのALB/NLBのListenerに設定可能
・SNIをサポートするクライアントには、適正な証明書を選択してTLSで通信をできる
ALB毎に最大25 証明書まで（デフォルトを除く）
・ACMまたはIAMの全ての証明書が利用可能