Contents
基礎知識
●可用性
システムが継続して稼働できる能力のこと。
サービスの提供が不可能になる状態に陥ることが少なく、安定して利用できる性質。
| 目標復旧時間（RTO） | いつまでに事業を復旧するかという目標時間を表す指標。 |
| 目標復旧時点（RPO） | データ損失の最大許容量。24時間であれば24時間分のデータの損失は許容される。 |
- スケールイン：撤去すること
- スケールアウト：増設すること
●TTL（Time TO Live）機能
あるデータが破棄されるまで時間や、処理の繰り返し回数の上限。DynamoDB コンソールまたは AWS CLI、存続期間を有効にできる。(キャパシティユニットを消費しない)
●SSLネゴシエーション
SSL通信の工程を意味する。
ELB
（Elastic Load Balancing）
アプリケーションへのトラフィックを、1 つまたは複数のアベイラビリティーゾーン (AZ) 内（AZを跨ぐことはできない）の複数のターゲットおよび仮想アプライアンスに自動的に分散する。データを暗号化するときは基本的に、SSL証明書をELBに付与する。
※SSLを使用したELBは IDP/IPS として機能しない
●リスナ
[接続チェック]
設定したプロトコルとポートを使用して接続リクエストをチェックするプロセス。
- リスナをセキュリティグループに設定できない。
- 優先順位により、登録済みのターゲットにリクエストをルーティングする方法が決まる。
※リスナによって想定されていないプロトコルおよびポートを使用した場合、「接続確立時エラー」発生する可能性がある。
機能性
| ヘルスチェック | 高可用性のある通信トラフィックの負荷分散。 ヘルスチェックを30秒ごとに行う。 |
| モニタリング | 【アクセスログ有効】 ロードバランサーに送信されるリクエストについて、詳細情報を収集するアクセスログを S3 に格納。 トラフィックパターンの分析や、問題のトラブルシューティングを行うことができる。 【ログ内の情報】 ・リクエストの受信時刻 ・クライアントの IP アドレス ・レイテンシー ・リクエストパス ・サーバーレスポンス……など |
| スケーリング | 負荷に応じて、自動的にクラウドサーバーの台数を増減させる機能。 ただし、緩やかにスケーリングするため、突発的な増加には対応できない。 |
| クロスゾーン 負荷分散 | 【AZ跨ぎ分散】 複数のAZを跨いで、起動するインスタンスの台数に偏りがある場合でも、均等にトラフィックを分散して振り分ける機能。 |
| スティッキー セッション | 【セッション記憶】※NLB未対応！ ユーザーのセッション情報をELBが把握できるようになり、セッション中に同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能。ELBがサーバにリクエストを振り分ける際、Cookieを確認して特定のクライアントからのリクエストを特定のサーバに連続的に紐付ける。セッションアフィニティとも呼ぶ。 |
| Connection Draining | 【異常なインスタンスを判別】 既存の接続を開いたまま、登録解除または異常なインスタンスへのCLBのリクエスト送信を停止する。 （タイムアウト値：１時間） |
| 暖気申請 | (Pre-Warming)【事前にスケール】 急激なアクセス増が予想される場合、暖気申請を行い事前にELBをスケールする。ELBは負荷に合わせてスケールする機能があるが、ある程度の時間がかかりリクエストが瞬間的に増えたときはスケールが間に合わず、HTTP 503を返す。 |
メトリクス
| レイテンシー | ロードバランサーが配下のインスタンスへリクエストを送信〜対象インスタンスがレスポンスヘッダを送信し始めた合計経過時間(秒)。アベレージ、Maxが有用。 |
| RequestCount | 指定された間隔に完了したリクエストの数。合計が有用。 |
| Healthy Host Count | ロードバランサー配下の正常なインスタンス数。統計は平均とMaxが有用。 |
| Un Healthy Host Count | ロードバランサー配下の異常なインスタンス数。統計は平均とMinが有用。 |
| HTTPCode_Backend_2XX (3XX,4XX,5XX) | ELB配下のインスタンスからのレスポンスのステータスコードの数。ロードバランサーのレスポンスのステータスコードは含まれない。なお、統計はSumで見ないと1固定になってしまうので注意。 ➡ELB配下のインスタンスでリクエストが裁けなくなってる |
| HTTPCode_ELB_5XX | ロードバランサーのレスポンスのステータスコード5XXの数。ELB配下のインスタンスからのレスポンスのステータスコードの数は含まれない。ELBに配下のインスタンスで正常なインスタンスがひとつもない場合や、リクエストレートがインスタンスやロードバランサーの容量を超える場合に発生。なお、統計はSumで見ないと1固定になるため注意。➡ELB配下のインスタンスに負荷がかかりると危険。 とうとうインスタンスのヘルスチェックOKのインスタンスが0になったのでインスタンスにリクエストすら送れなくなり、ELBがユーザーにインスタンス死んでるから無理と5XXエラー返しだす。 |
ヘッダー
●Proxy Protocolヘッダー
【接続元指定】
接続元のクライアントのIP アドレスが必要な場合は、Proxy Protocol を有効にする。Proxy Protocol ヘッダーからクライアント IP アドレスを取得できる。
- Proxy Protocol
ELBで事前に設定していたプロトコル以外の接続に対して、接続元のIPアドレスやポート番号が確認できる。
Proxy ProtocolはAWSによってサポートされている。
（HTTPで設定していたが、他のプロトコルで接続があったなど）
エラー
[HTTP503エラー]
一時的にサーバーにアクセスできない状態。原因の一つとして、サーバーへのアクセス過多があげられる。
対応として、インスタンスを停止し再起動すると、認識までに時間がかかり、瞬間的なリクエストの増加に対応が間に合わないことがある。そのため、暖気申請を実施するのが良い。
[ロードバランサーの種類]
| 機能 | Application Load Balancer | Network Load Balancer | Gateway Load Balancer | Classic Load Balancer |
|---|---|---|---|---|
| ロードバランサーの種類 | レイヤー 7 | レイヤー 4 | レイヤー 3 Gateway + レイヤー 4 | レイヤー 4/7 |
| ターゲットの種類 | IP、インスタンス、Lambda | IP、インスタンス、ALB | IP、インスタンス | IP、インスタンス |
| フロー/プロキシの動作終了 | 有 | 有 | いいえ | 有 |
| プロトコルリスナー | HTTP、HTTPS、gRPC | TCP、UDP、TLS | IP | TCP、SSL/TLS、HTTP、HTTPS |
| 到達方法 | VIP | VIP | ルートテーブルのエントリ | VIP |
[引用元サイト]
CLB
【L4/L7レイヤー対象】※Classic Load Balancer
ALBおよびNLBは通常はターゲットにはEC2のインスタンスIDを指定しているが、IPアドレスを指定できる。
| SpilloverCount | 【拒否リクエスト数】 サージキューがいっぱいなため、拒否されたリクエストの総数。 |
| SurgeQueueLength | 【リクエスト合計数】 正常なインスタンスへのルーティングを保留中のリクエスト（HTTPリスナー）または接続（TCPリスナー）の合計数。キューの最大サイズは1,024。追加のリクエストまたは接続は、キューがいっぱいになると拒否される。 |
[参考：公式サイト]
ALB
【L7レイヤー対象】
※Application Load Balancer ※マイクロサービス対応可能
アプリケーションをより小さなサービスとして構成し、URL の内容に基づいて適切なサービスにリクエストをルーティングできる。
・CLBと比較して費用対効果が高い
・WebSocket プロトコルに対応している
・動的ポートマッピングを支援
・CNAME レコードは対応していない
・静的IPアドレスを割り当てることはできない
・SQSキューをターゲットに設定できない
| ALBアクセスログ | 下記、詳細を含むアプリケーションアクセス情報を提供する。 ・クライアントIPアドレス ・接続タイプ ・ユーザーエージェント……など ※出力先は S3 固定 |
| URLベースのルーティング | URLパスに基づいてリクエストを転送するルールを持つリスナーを作成できる。 マイクロサービスを実行している場合、複数のバックエンドサービスにトラフィックをルーティングできる。 [静的IPアドレスが必要な場合] ALBをNLBの背後に登録すること。 [参考公式サイト] |
ヘルスチェック
[参考公式サイト]
●HealthCheckIntervalSeconds
個々のターゲットのヘルスチェックの概算間隔 (秒単位)。範囲は 5 ～ 300 秒。
ターゲットタイプが instance または ip の場合のデフォルトは 30 秒で、ターゲットタイプが lambda の場合のデフォルトは 35 秒。
●HealthyThresholdCount
非正常なインスタンスが正常であると見なすまでに必要なヘルスチェックの連続成功回数。
範囲は 2 ～ 10 。デフォルトは 5 。
NLB
【L4レイヤー対象】 ※Network Load Balancer
1秒あたり数百万リクエストへのスケーリングを伴う低レイテンシと高スループットのワークロードを伴うユースケースに最適。インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされる。
・静的IPアドレスを持たせることができる
・ホワイトリストに静的IPアドレスを登録して、アクセス制限できる。
・「受け取ったプロトコルをそのまま」バランシングするため、「HTTP/HTTPS プロトコル」は非対応。
・「Lambdaターゲットタイプ」は非対応である。
・「スティッキーセッション」や「加重ラウンドロビン」は対応できない
[NLBの暗号化]
NLBで終端される TLS (Transport Layer Security) 接続を利用することで、ロードバランサーと SSL あるいは TLS セッションを開始したクライアント間のトラフィックを暗号化できる。
Gateway Load Balancer
ネットワークトラフィックを(ファイアウォールやIDS/IPSなど)仮想アプライアンスに中継させるためのロードバランサー。トラフィックを通過させて検査・制御。
※仮想アプライアンス：ファイアウォール、侵入検知システム（IDS）、侵入防止システム（IPS）など、ターゲットグループに登録する
・Gateway Load Balancer は仮想アプライアンスと同じ VPCに配置される
・透過的なネットワークゲートウェイとして機能し、アプリケーションの構成を変更せずにセキュリティ機能を追加できる。
●GWLBエンドポイント
「サービスプロバイダーVPC内の仮想アプライアンス」と「サービスコンシューマVPC内のアプリケーションサーバ間」のプライベート接続を提供するVPCe。2つのVPCをGWLBとGWLBエンドポイントでつなぎ、VPCを超えてトラフィックを安全に交換する。
- GWLBは仮想アプライアンスと同じVPCにデプロイする。
- 仮想アプライアンスは、GWLBターゲットグループに登録する。
[例：通信の流れ]
①アプリケーションサーバーへの外部からの通信（受信）は：
インターネットゲートウェイ ➜ GWLB エンドポイント ➜ 宛先サブネット
②サーバーから外部への通信（送信）は：
宛先サブネット ➜ GWLB エンドポイント ➜ インターネット
Auto Scalling
リソース使用状況に伴って、EC2のインスタンスを自動でスケールアウト（追加）・スケールイン（削除）する。
・グループのサイズは手動でいつでも変更が可能
・グループポリシーで終了させるインスタンスの調整ができる
・メモリ利用率をトリガーとした設定がデフォルトで設定できないようになっている
スケーリング機能
スケーリングは異常なインスタンスを修了させた後、新しいインスタンスを追加する。
※スケジューリングされたアクションが重複する場合、エラーが通知される
| スケールイン保護 | スケールイン時にインスタンスの停止を伴わない。 |
| スケーリングプラン | 【タイミング指定】 いつどのような条件でAuto Scalingを実行するか指定する。 |
| クールダウン | 【待機期間】 スケーリングを連続して行わないようにする待機時間を指定する。アプリケーションが必要以上の起動や終了を実施しないようにすることができる。インスタンスがスケールアウトすると一定のクールダウンに入る。なおユーザーアクション中はスケールアウトは中止される。 ・デフォルトではAuto Scalingグループ全体へ適用している。 ・クールダウンを用いて、Cloud Watchとの重複起動を避けられる ・スポットインスタンスの入札が決定すると、Auto Scallingグループはクールダウンが有効になる |
| ウォームプール | 起動時間が長いインスタンスも事前に起動しておくことで、急なトラフィック増加に対応できる。Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプール。EC2インスタンスが起動する際のデータのディスクへの書き込みや起動時間の長さによって発生するアプリケーションのレイテンシー（遅延）を削減する。（レイテンシーの問題に有効）インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされる。これはウォームスタートとされる。 |
[スケーリンググループの削除方法]
- AutoScalingグループの最小サイズと希望する容量を０にする。
- CLIから「delete – auto – scaling – group」コマンドを実行。
[SQSに基づくスケーリング]
設定は 3 つの主要な部分で構成される。
- SQS キューからのメッセージを処理するために EC2 インスタンスを管理する Auto Scaling グループ。
- CloudWatch に送信するカスタムメトリクス。Auto Scaling グループの EC2 インスタンスごとにキュー内のメッセージの数を測定する。
- ターゲット追跡ポリシー。カスタムメトリクスと一連のターゲット値に基づいて Auto Scaling グループをスケールするように設定。CloudWatch アラームでスケーリングポリシーを呼び出す。
インスタンスの種類
| ステートレスなインスタンス 【手動連携】 | ユーザーが途中まで操作した段階でスケールインしサーバー数が減った場合でも、常にユーザーが全データを送信する。これにより、スケールイン・スケールアウトが発生してもスムーズなシステム運用が可能。 |
| ステートフルなインスタンス 【自動連携】 | ユーザーがどこまでの操作を行ったかをシステムが保持する。スケールアウトやスケールインでサーバーが増減した場合でも続きの処理を別のサーバーでもできるようにする。そうしないと、新しく起動されたインスタンスにリクエストしたときにデータが存在しないエラーが発生することがある。 |
| 属性ベースのインスタンス | 属性ベースのインスタンスタイプの選択では、特定のインスタンスタイプのリストの代わりに、以下のようなインスタンスに必要な属性のリストが提供される。 ・vCPU 数 ・メモリ ・ローカルストレージ ・バースト可能なパフォーマンス |
[インスタンスの状態]
「Stopped（停止中）」「Running（実行中）」「Hibernated（休止中）」のいずれかの状態で保持される。コストを最小限に抑えるには、インスタンスを停止状態で保持するのが効果的。この場合、使用したボリュームとElastic IPアドレスに対してのみ料金が発生する。
起動設定
【設定テンプレート】※既存の起動設定は変更できない
Auto Scaling グループがインスタンスを起動するために使用するインスタンス設定テンプレート。
- AWS::AutoScaling::LaunchConfiguration
起動設定の指定。AutoScalingグループがインスタンスを設定するために使用できるEC2 AutoScaling起動設定を指定する。
●起動テンプレート
【複数起動】起動設定の代わりに起動テンプレートを定義すると、複数のバージョンの起動テンプレートを使用できる。AMI の ID、インスタンスタイプ、キーペア、セキュリティグループ、その他 EC2 インスタンスを起動するために使用するパラメータが含まれている。
※インスタンス設定情報を指定する起動設定と似ている。
機能性
| ライフサイクルフック | インスタンスの起動・停止を一時的に待機させ、指定のアクションを実行。異常なインスタンスの分析などのシチュエーションなどで有効。 |
| ヘルスチェック | [EC2のヘルスチェック]：pingを定期的にインスタンスに送る。 ・正常：InService ・不健全：OutOfService [ELBのヘルスチェック] ・正常：running ・異常：stopping、stopped、terminating、terminatedの場合、またはシステムステータスがimpairedである場合。 [カスタムチェック] デフォルトのヘルスチェックは、EC2のステータスチェックのみ。ELBのヘルスチェックを設定すると、EC2のステータスチェックとELBのヘルスチェックいずれかに合格しない場合に異常となる。（つまり両方合格して、正常となる） |
| グループ別集計機能 | 【EC2統計機能】 ・Auto Scaling グループ内で EC2 の統計を集計することができる。 ・CloudWatch のメトリクス数式を使用して、複数リージョンのメトリクスを集計・変換できる。 ・クロスアカウントダッシュボードを使用すると、複数の異なるアカウントのメトリクスに対してメトリック数式を実行できる。 |
プロセス
[参考公式サイト]
| Launch 【追加】 | グループがスケールアウトするとき、またはEC2 Auto Scaling がその他の理由 (インスタンスをウォームプールに追加する場合など) でインスタンスの起動を選択するときに、インスタンスを Auto Scaling グループに追加する。 |
| Terminate 【削除】 | グループがスケールインするとき、または EC2 Auto Scaling がその他の理由 (最大有効期間を超過した、もしくはヘルスチェックに合格しなかったためにインスタンスが終了される場合など) でインスタンスの終了を選択する場合に、インスタンスを Auto Scaling グループから削除する。 |
| AddToLoadBalancer | インスタンスが起動されたときに、アタッチされたロードバランサーターゲットグループまたは Classic Load Balancer にインスタンスを追加する。 |
| AlarmNotification | 動的スケーリングポリシーに関連付けられているアラームからの CloudWatch通知を受け入れる。 |
ポリシー
[スケーリングポリシー]
| 手動スケーリング | Auto Scalingグループのサイズの希望する容量を手動で変更しスケーリングする。 |
| 動的スケーリング | トラフィックの変化に応じてスケーリングする。 |
| 簡易 | ～％の閾値を超過次第 |
| ステップ | warning , errorと段階を踏ませる |
| ターゲット追跡 | 設定値を自動的に維持する仕組み。容量が増加すると減少し、容量が減少すると増加するなど、比例的なスケーリングを実現可能。 |
| スケジュール | 特定の時間に容量を増減するスケジュールアクションを作成することで予測可能な負荷の変化に合わせてアプリケーションを事前対応的にスケーリングする。 |
| 予測 | 通常のトラフィックの日次や週次のパターンに基づいて Auto Scaling グループ内の EC2 インスタンス数を事前に増加させる。 |
[終了ポリシー]
・Oldest Instance
・Newest Instance
・Oldest Launch Configuration
・Coldest To Next Instance Hour
・Default
・Oldest Launch Template
・Allocation Strategy
・Termination Policy
スケールイン時に終了させるインスタンスの順番を定義する。デフォルトは古いインスタンスから実行。
メトリクス
- Group TotalInstance
AutoScalingグループに含まれるインスタンス（稼働中、保留中、終了処理中）の合計数を特定。 - GroupInServiceInstances
Auto Scaling グループの一部として実行するインスタンスの数。
このメトリクスには保留中もしくは終了処理中のインスタンスは含まれない。
[高可用性：インスタンス最小数1、インスタンスの最大数1]
| 特性 | 説明 |
|---|---|
| ヘルスチェックによる自動置き換え | EC2 インスタンスが異常と判定された場合、Auto Scaling グループはそのインスタンスを終了し、新しいインスタンスを自動で起動します。 |
| 希望キャパシティの維持 | 最小数・最大数が1でも、Auto Scaling グループは「常に1台稼働している状態」を維持しようとします。 |
| Launch Template による迅速な復旧 | 起動テンプレートに基づいて、同一構成のインスタンスを即座に再起動できるため、復旧時間（RTO）を短縮できます。 |
| CloudWatch アラームとの連携 | 異常検知を CloudWatch アラームで補強すれば、より早期に障害を検知・対応できます。 |
Application Auto Scaling
EC2 Auto Scaling 以外の個々の AWS サービスに対してスケーラブルなリソースを自動的にスケーリングするソリューションを必要とするデベロッパーやシステム管理者向けのウェブサービス。
●Service Auto Scaling
【拡張スケーリング機能】
複数のAWSサービスに対して、スケーリング（リソースの増減）を自動で制御。用途に応じてスケーリングポリシーを柔軟に定義することができる。
DRS
【対DRディスク】※Elastic Disaster Recovery
オンプレミスやクラウド上のサーバーをAWSにレプリケートして、障害時にすばやく復旧できるようにする。対象サーバーにエージェントをインストールし、OS・アプリケーション・データベースをステージングエリアに継続的レプリケーション。災害発生時、レプリケート済みマシンを自動的に起動して復旧可能。オンプレミスからAWSへのデータ複製を自動化する。（RPO 2分／RTO 30分）
特徴
| コスト効率が高い | 復旧サイトのリソースはアイドル状態で維持され、必要なときだけフル稼働するため、無駄なコストを削減できる。 |
| 簡単なセットアップと運用 | AWSマネジメントコンソールから操作でき、特別なスキルがなくても導入可能。エージェント方式で既存インフラへの変更も最小限。 |
| 自動化された復旧プロセス | 起動テンプレートやモニタリングツールの有効化など、復旧に必要なアクションを自動化できる。レプリケーションで取得したサーバーイメージはEC2インスタンスとして復元できる。 |
| 柔軟なユースケース対応 | オンプレミスからAWS、他クラウドからAWS、AWSリージョン間など、さまざまな構成に対応可能。 |
| テストフェイルオーバー機能 | 実際の障害を起こさずに復旧テストができるため、BCPの信頼性を定期的に検証できる。 |
| 切り戻し機能 | 元のサイトに切戻し(フェールバック)もできる。（オンプレミスのサーバーにも対応可能） |
連携サービス
| Global Accelerator | Global Acceleratorを活用して、フェイルオーバー後も低レイテンシを実現。全体として、アプリケーション層・データベース層のそれぞれに明確なRPO/RTO目標を持ち、短時間かつコスト効率の高い災害復旧を実現する設計。 |
