【基礎知識】

●スケールアウト：増設すること
●スケールイン：撤去すること

• 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のリクエスト送信を停止する。
  （タイムアウト値：１時間）

〇メトリクス

• レイテンシー
  ロードバランサーが配下のインスタンスへリクエストを送信〜対象インスタンスがレスポンスヘッダを送信し始めた合計経過時間(秒)。アベレージ、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グループの最小サイズと希望する容量を０にする。
②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インスタンスとして復元できる。
・元のサイトに切戻し(フェールバック)もできる。（オンプレミスのサーバーにも対応可能）

SQS（Simple Queue Service）

キュー内の(複数の)ワーカープロセスでメッセージを処理し、確実な非同期（分散並行）処理を行う。
キューの有効期限が切れるまで繰り返し処理する。

• プロデューサ
  キューにメッセージを入れる、取り出すサービス。

• エンドポイント
  URLを介して送受信する。

〇キュー

メッセージを管理する入れ物のようなもの（256KB限度）デフォルトは4日間保存する。

キューは手動で削除することが可能。

• スタンダードキュー
  順番は保証されない。一回のメッセージ配信をサポートする。
  
  ●シーケンス情報
  追加することで、順序良く受信させることができる。
  (スタンダードキュー可能）
  
  
• 先入れ先出し（FIFOキュー）
  利用料金は高め。受信時にメッセージの並び替え、最低1回のメッセージ配信をサポートする。
  
  ・S3との連携はできない
  ・1秒あたり最大3,000トランザクション
  ・1秒あたり最大300メッセージをサポートする
  
  【キューの切り替え】
  FIFOキューに切り替えるなどする際は、新しくキューを作成する必要がある。
  ※FIFOキューは「コンテンツベース重複排除」を有効化することで、データを一意にできる
  
  【その他機能】
  ●キューイング(待ち行列)
  【一時退避】
  一時的に送信するデータをデータ領域に保持し、滞留させず確実に相手へ届ける。疎結合が可能。
  
  ●デッドレターキュー (DLQ)
  【失敗処理】
  処理できないメッセージを別のキューに移動させる。
  正常に処理 (消費) できないメッセージのターゲットとする。アプリケーションやメッセージングシステムのデバッグに役立つ。
  
  ●遅延キュー
  【受信遅延】
  キューへの新しいメッセージの配信を数秒間遅延させ、そのキューに送信したすべてのメッセージは遅延期間中にコンシューマーに表示されない。
  キューのデフォルト (最小) 遅延は 0 秒。最大値は15分。

〇メッセージ

キューの中に格納される情報。

• メッセージグループ ID
  【メッセージのタグ付け】
  メッセージが特定のメッセージグループに属することを指定するタグ。
  同じメッセージグループに属するメッセージは、そのメッセージグループに関連して厳密な順序で 1つずつ処理される。

• 可視性タイムアウト
  【重複受信防止】
  メッセージの受信中に他クライアントが受信しないように防止する。(30秒～12時間まで延長可能)
  メッセージは受信しただけでは消えず、クライアント側から削除指示を受けた時のみ削除される。
  
  ●ChangeMessageVisibility
  新しいタイムアウト値を指定すると、メッセージの可視性を短縮または拡張できる。
  
  ●VisibilityTimeout
  メッセージが1回受信された後、他のクライアントから同じメッセージを受信不可にするための時間。
  (デフォルトは30秒. 値は0〜43,200(12時間) の間で設定可能)
  
  ●ReceiveMessage
  リクエストによってメッセージを取得。

• SQS Java 拡張クライアントライブラリ
  【メッセージの保存管理】
  メッセージを常に S3 に保存するか、メッセージのサイズが 256 KB を超える場合のみ保存するかを指定する。
  
  ・S3 バケットに保存されている単一のメッセージオブジェクトを参照するメッセージを送信する
  ・S3 バケットからメッセージオブジェクトを取得 / 削除する

〇ポーリング

複数のキューを呼び出して分散してメッセージを処理する。ただし、1つのキューにすべてのメッセージが入っているわけではない。
キューの中の先頭のデータが渡されるため、中の特定のメッセージを指定できない。
[参考]

• ショートポーリング
  メッセージ取得時に特定のキューをランダムに選択し、そのキューからメッセージを取得する。
  リクエストを投げると結果は直ぐに返ってくるため、メッセージ取得時の待機時間0秒。しかし、結果が0件だった場合はリトライされるため、リクエスト回数が増え、料金が増加する。

• ロングポーリング（推奨）
  すべてのキューを確認し、処理可能な(待機時間を超過した)メッセージが存在する場合と接続タイムアウトになった場合のみ結果を返す。
  結果が0件の場合は返答しないため、SQS使用時のコストを削減できるので、ショートポーリングよりも推奨される。
  
  ※ReceiveMessageAPI アクションが 0 より大きい場合ロングポーリングは実行中
  
  ・KMSを使用したサーバー側の暗号化を使用したシームレスな保存データの暗号化をサポート。一元化されたキー管理が可能になる。

〇メトリクス

[参考公式サイト]

• ApproximateNumberOfMessagesVisible
  キューから取得可能なメッセージの数。

MQ
【Apache用】

Apache用マネージド型のメッセージキューイングサービス。
AWS独自の方法ではなく業界標準APIやメッセージング用プロトコルを使ってるため、今までのアプリから接続先をMQに変えるだけで簡単に移行できる。
リージョン内の複数のAZにメッセージを冗長的に保存するため、耐障害性が高い。

・ソフトウェアをインストールして管理したりする必要はない。
・ソフトウェアのアップグレードやセキュリティの更新、障害の検出と回復などのタスクを自動的に管理する。

• メッセージブローカー
  【中間システム】
  異なるシステム間でメッセージやり取りの時、直接データのやり取りせず、中間システムとしてメッセージ格納領域を管理する機能。

冗長性

MSK
【ストレージの迅速な移動】

※MSK：Managed Streaming for Apache Kafka

耐障害性と可用性の高いストリーミングストレージ。

フルマネージド型で可用性が高い Apache Kafka サービスでデータを安全にストリーミングする。
オープンソースで安全性の高い Apache Kafka クラスターを複数のアベイラビリティーゾーン (AZ) に分散して提供。

・高度に設定可能、観察可能、かつスケーラブルで様々なユースケースに必要な柔軟性と制御する。
・既存アプリケーションで処理しているメッセージング機能をクラウドにすばやく簡単に移したい場合に最適。

★以下を処理実行する
１：サーバーのプロビジョニング
２：Apache Kafka クラスターの設定
３：障害時のサーバーの交換
４：サーバーのパッチとアップグレードのオーケストレート
５：高可用性のためのクラスターの構築
６：データの永続的な保存とセキュリティの確保
７：モニタリングとアラームの設定
８：負荷変動をサポートするためのスケーリングの実行