

Contents
【基礎知識】
●スケールアウト:増設すること
●スケールイン:撤去すること
- 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 アドレス
・レイテンシー
・リクエストパス
・サーバーレスポンス……など
- スケーリング機能
負荷に応じて、自動的にクラウドサーバーの台数を増減させる機能。
ただし、緩やかにスケーリングするため、突発的な増加には対応できない。
●HTTP503エラー
一時的にサーバーにアクセスできない状態。
原因の一つとして、サーバーへのアクセス過多があげられる。
【対応】
インスタンスを停止し再起動すると、認識までに時間がかかり、瞬間的なリクエストの増加に対応が間に合わないことがある。
そのため、暖気申請を実施するのが良い。
- 暖気申請(Pre-Warming)
【事前にスケール】
急激なアクセス増が予想される場合、暖気申請を行い事前にELBをスケールする。
※ELBは負荷に合わせてスケールする機能があるが、ある程度の時間がかかりリクエストが瞬間的に増えたときはスケールが間に合わず、HTTP 503を返します。
- クロスゾーン負荷分散
【AZ跨ぎ分散】
複数のAZを跨いで、起動するインスタンスの台数に偏りがある場合でも、均等にトラフィックを分散して振り分ける機能。
- Proxy Protocolヘッダー
【接続元指定】
接続元のクライアントのIP アドレスが必要な場合は、Proxy Protocol を有効にする。
Proxy Protocol ヘッダーからクライアント IP アドレスを取得できる。
●Proxy Protocol
ELBで事前に設定していたプロトコル以外の接続に対して、接続元のIPアドレスやポート番号が確認できる。
Proxy ProtocolはAWSによってサポートされている。
(HTTPで設定していたが、他のプロトコルで接続があったなど)
- スティッキーセッション
【セッション記憶】
※NLB未対応!
ユーザーのセッション情報をELBが把握できるようになり、セッション中に同じユーザから来たリクエストを全て、同じEC2インスタンスに送信する機能。
ELBがサーバにリクエストを振り分ける際、Cookieを確認して特定のクライアントからのリクエストを特定のサーバに連続的に紐付ける。
セッションアフィニティとも呼ぶ。
- Connection Draining
【異常なインスタンスを判別】
既存の接続を開いたまま、登録解除または異常なインスタンスへのCLBのリクエスト送信を停止する。
(タイムアウト値:1時間)
〇メトリクス
- レイテンシー
ロードバランサーが配下のインスタンスへリクエストを送信〜対象インスタンスがレスポンスヘッダを送信し始めた合計経過時間(秒)。アベレージ、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エラー返しだす。
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アドレス
・接続タイプ
・ユーザーエージェント……など
- 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
AWS内で取り扱われたデータを(サードパーティの)仮想アプライアンスやサービスに簡単に転送できる。これにより、ファイアウォール、侵入検知システム(IDS)、侵入防止システム(IPS)など、AWSに導入した仮想アプライアンスに対して簡単にデータを転送できるようになります。
- GWLBエンドポイント
「サービスプロバイダーVPC内の仮想アプライアンス」と「サービスコンシューマVPC内のアプリケーションサーバ間」のプライベート接続を提供するVPCe。2つのVPCをGWLBとGWLBエンドポイントでつなぎ、VPCを超えてトラフィックを安全に交換する。
・GWLBは仮想アプライアンスと同じVPCにデプロイする。
・仮想アプライアンスは、GWLBターゲットグループに登録する。
※仮想アプライアンス
仮想化技術を用いて、特定の用途のアプリケーションを稼働する環境をパッケージ化したソフトウェア
Auto Scalling
リソース使用状況に伴って、EC2のインスタンスを自動でスケールアウト(追加)・スケールイン(削除)する。
・メモリ利用率をトリガーとした設定がデフォルトで設定できないようになっている
・グループポリシーで終了させるインスタンスの調整ができる
・グループのサイズは手動でいつでも変更が可能
- ライフサイクルフック
インスタンスの起動・停止を一時的に待機させ、指定のアクションを実行。
異常なインスタンスの分析などのシチュエーションなどで有効。
- グループ別集計機能
【EC2統計機能】
・Auto Scaling グループ内で EC2 の統計を集計することができる。
・CloudWatch のメトリクス数式を使用して、複数リージョンのメトリクスを集計・変換できる。
・クロスアカウントダッシュボードを使用すると、複数の異なるアカウントのメトリクスに対してメトリック数式を実行できる。
〇プロセス
[参考公式サイト]
- Launch
【追加】
グループがスケールアウトするとき、またはEC2 Auto Scaling がその他の理由 (インスタンスをウォームプールに追加する場合など) でインスタンスの起動を選択するときに、インスタンスを Auto Scaling グループに追加する。
- Terminate
【削除】
グループがスケールインするとき、または EC2 Auto Scaling がその他の理由 (最大有効期間を超過した、もしくはヘルスチェックに合格しなかったためにインスタンスが終了される場合など) でインスタンスの終了を選択する場合に、インスタンスを Auto Scaling グループから削除する。
- AddToLoadBalancer
インスタンスが起動されたときに、アタッチされたロードバランサーターゲットグループまたは Classic Load Balancer にインスタンスを追加する。
- AlarmNotification
動的スケーリングポリシーに関連付けられているアラームからの CloudWatch通知を受け入れる。
〇インスタンスの種類
- ステートレスなインスタンス
【手動連携】
ユーザーが途中まで操作した段階でスケールインしサーバー数が減った場合でも、常にユーザーが全データを送信する。これにより、スケールイン・スケールアウトが発生してもスムーズなシステム運用が可能。
- ステートフルなインスタンス
【自動連携】
ユーザーがどこまでの操作を行ったかをシステムが保持する。
ユーザーが途中まで操作した情報をサーバー間で共有する仕組みを用意しておき、スケールアウトやスケールインでサーバーが増減した場合でも続きの処理を別のサーバーでもできるようにする。そうしないと、新しく起動されたインスタンスにリクエストしたときにデータが存在しないエラーが発生することがある。
〇スケーリングポリシー
- スケーリングポリシー
●簡易
~%の閾値を超過次第
●ステップ
warning , errorと段階を踏ませる
●ターゲット追跡
設定値を自動的に維持する仕組み。
容量が増加すると減少し、容量が減少すると増加するなど、比例的なスケーリングを実現可能。
●スケジュール
特定の時間に容量を増減するスケジュールアクションを作成することで予測可能な負荷の変化に合わせてアプリケーションを事前対応的にスケーリングする。
●予測
通常のトラフィックの日次や週次のパターンに基づいて Auto Scaling グループ内の EC2 インスタンス数を事前に増加させる。
- 終了ポリシー
●OldestInstance
●NewestInstance
●OldestLaunchConfiguration
●ColdestToNextInstanceHour
●Default
●OldestLaunchTemplate
●AllocationStrategy
〇スケーリング機能
スケーリングは異常なインスタンスを修了させた後、新しいインスタンスを追加する。
※スケジューリングされたアクションが重複する場合、エラーが通知される
- スケールイン保護
スケールイン時にインスタンスの停止を伴わない。
- スケーリングプラン
【タイミング指定】
いつどのような条件でAuto Scalingを実行するか指定する。
●Termination Policy
スケールイン時に終了させるインスタンスの順番を定義する。
デフォルトは古いインスタンスから実行。
- クールダウン
【待機期間】
スケーリングを連続して行わないようにする待機時間を指定する。
アプリケーションが必要以上の起動や終了を実施しないようにすることができる。
インスタンスがスケールアウトすると一定のクールダウンに入る。
なおユーザーアクション中はスケールアウトは中止される。
・デフォルトではAuto Scalingグループ全体へ適用している。
・クールダウンを用いて、Cloud Watchとの重複起動を避けることができる
・スポットインスタンスの入札が決定すると、Auto Scallingグループはクールダウンが有効になる
- ウォームプール
起動時間が長いインスタンスも事前に起動しておくことで、急なトラフィック増加に対応できる。
Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプール。
インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされる。これは、ウォームスタートとされる。
【スケーリンググループの削除方法】
①AutoScalingグループの最小サイズと希望する容量を0にする。
②CLIから「delete – auto – scaling – group」コマンドを実行。
〇起動設定
- 起動設定
【設定テンプレート】
Auto Scaling グループがインスタンスを起動するために使用するインスタンス設定テンプレート。
●AWS::AutoScaling::LaunchConfiguration
【起動設定の指定】
AutoScalingグループがインスタンスを設定するために使用できるEC2 AutoScaling起動設定を指定する。
- 起動テンプレート
【複数起動】
起動設定の代わりに起動テンプレートを定義すると、複数のバージョンの起動テンプレートを使用できる。
AMI の ID、インスタンスタイプ、キーペア、セキュリティグループ、その他 EC2 インスタンスを起動するために使用するパラメータが含まれている。
※インスタンス設定情報を指定する起動設定と似ている。
●属性ベースのインスタンス
属性ベースのインスタンスタイプの選択では、特定のインスタンスタイプのリストの代わりに、以下のようなインスタンスに必要な属性のリストが提供される。
・vCPU 数
・メモリ
・ローカルストレージ
・バースト可能なパフォーマンス
〇ヘルスチェック
- EC2のヘルスチェック
pingを定期的にインスタンスに送る。
●正常:InService
●不健全:OutOfService
- ELBのヘルスチェック
●正常:running
●異常:stopping、stopped、terminating、terminatedの場合、またはシステムステータスがimpairedである場合。
- カスタムチェック
デフォルトのヘルスチェックは、EC2のステータスチェックのみ。
ELBのヘルスチェックを設定すると、EC2のステータスチェックとELBのヘルスチェックいずれかに合格しない場合に異常となる。(つまり両方合格して、正常となる)
〇メトリクス
- Group TotalInstance
AutoScalingグループに含まれるインスタンス(稼働中、保留中、終了処理中)の合計数を特定。
- GroupInServiceInstances
Auto Scaling グループの一部として実行するインスタンスの数。
このメトリクスには保留中もしくは終了処理中のインスタンスは含まれない。
DRS
【対DRディスク】
※Elastic Disaster Recovery
サーバーのディスクイメージ全体をレプリケーションすることで、AWS上のストレージに継続して転送保管を行う機能をもつ。
・レプリケーションで取得したサーバーイメージはEC2インスタンスとして復元できる。
・元のサイトに切戻し(フェールバック)もできる。(オンプレミスのサーバーにも対応可能)
・オンプレミス環境からAWSへのデータ複製を自動的に実施できる

No responses yet