翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# アクティブ/スタンバイステートフルサーバー間の HA のフローティング IP パターン
フローティング IP 設計パターンは、ハードウェアノード (メディアサーバー) のアクティブペアとスタンバイペア間の自動フェイルオーバーを実現するよく知られたメカニズムです。静的セカンダリ仮想 IP アドレスがアクティブなノードに割り当てられます。アクティブノードとスタンバイノード間の継続的なモニタリングにより、障害が検出されます。アクティブなノードに障害が発生した場合、モニタリングスクリプトは仮想 IP を準備完了スタンバイノードに割り当て、スタンバイノードがプライマリアクティブ関数を引き継ぎます。このようにして、仮想 IP はアクティブノードとスタンバイノードの間で浮動します。
## RTC ソリューションの適用性
N ノードのアクティブ/アクティブクラスターなど、同じコンポーネントの複数のアクティブインスタンスが稼働中であるとは限りません。アクティブスタンバイ設定は、HA に最適なメカニズムを提供します。例えば、メディアサーバーや会議サーバー、SBC やデータベースサーバーなど、RTC ソリューションのステートフルコンポーネントは、アクティブ/スタンバイ設定に適しています。SBC またはメディアサーバーには、一度に複数の長時間実行セッションまたはチャネルがアクティブになっており、SBC アクティブインスタンスが失敗した場合、エンドポイントはフローティング IP によるクライアント側の設定なしでスタンバイノードに再接続できます。
### での実装 AWS
このパターンは、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon EC2 API、Elastic IP アドレスのコア機能、および Amazon EC2 でのセカンダリプライベート IP アドレスのサポートを使用して AWS に実装できます。
フローティング IP パターンを実装するには AWS：
1. 2 つの EC2 インスタンスを起動して、プライマリノードとセカンダリノードのロールを引き受けます。プライマリノードはデフォルトで*アクティブ*状態であると想定されます。
1. プライマリ EC2 インスタンスに追加のセカンダリプライベート IP アドレスを割り当てます。
1. 仮想 IP (VIP) に似た Elastic IP アドレスは、セカンダリプライベートアドレスに関連付けられます。このセカンダリプライベートアドレスは、外部エンドポイントがアプリケーションにアクセスするために使用するアドレスです。
1. 一部のオペレーティングシステム (OS) 設定は、セカンダリ IP アドレスをプライマリネットワークインターフェイスにエイリアスとして追加するために必要です。
1. アプリケーションはこの Elastic IP アドレスにバインドする必要があります。アスタリスクソフトウェアの場合、高度なアスタリスク SIP 設定を使用してバインディングを設定できます。
1. 各ノードでカスタム、Linux の KeepAlive、Corosync などのモニタリングスクリプトを実行して、ピアノードの状態をモニタリングします。現在のアクティブなノードに障害が発生した場合、ピアはこの障害を検出し、Amazon EC2 API を呼び出してセカンダリプライベート IP アドレスを自身に再割り当てします。
したがって、セカンダリプライベート IP アドレスに関連付けられた VIP でリッスンしていたアプリケーションは、スタンバイノードを介してエンドポイントで使用できるようになります。
![\[Elastic IP アドレスを使用したステートフル EC2 インスタンス間のフェイルオーバーを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/images/failover-stateful.jpg)
#### 利点
このアプローチは、EC2 インスタンス、インフラストラクチャ、またはアプリケーションレベルでの障害から保護する信頼性の高い予算の少ないソリューションです。
##### 制限と拡張性
この設計パターンは通常、単一のアベイラビリティーゾーン内に限定されます。2 つのアベイラビリティーゾーンに実装できますが、バリエーションがあります。この場合、利用可能な Elastic IP アドレスの再関連付け API を介して、異なるアベイラビリティーゾーンのアクティブノードとスタンバイノード間でフローティング Elastic IP アドレスが再関連付けされます。前の図に示すフェイルオーバー実装では、進行中の呼び出しは削除され、エンドポイントは再接続する必要があります。基盤となるセッションデータのレプリケーションを使用してこの実装を拡張し、セッションのシームレスなフェイルオーバーやメディア継続性を実現することもできます。
#### WebRTC と SIP によるスケーラビリティと HA の負荷分散
ラウンドロビン、アフィニティ、レイテンシーなどの事前定義されたルールに基づくアクティブなインスタンスのクラスターの負荷分散は、HTTP リクエストのステートレスな性質によって広く普及している設計パターンです。実際、ロードバランシングは、多くの RTC アプリケーションコンポーネントの場合に実行可能なオプションです。
ロードバランサーは、目的のアプリケーションへのリクエストのリバースプロキシまたはエントリポイントとして機能し、それ自体が複数のアクティブなノードで同時に実行されるように設定されています。任意の時点で、ロードバランサーは定義されたクラスター内のアクティブなノードのいずれかにユーザーリクエストを送信します。ロードバランサーは、ターゲットクラスター内のノードに対してヘルスチェックを実行し、ヘルスチェックに失敗したノードに受信リクエストを送信しません。したがって、ロードバランシングによって、基本的なレベルの高可用性が達成されます。また、ロードバランサーはすべてのクラスターノードに対してアクティブおよびパッシブのヘルスチェックを 1 秒未満の間隔で実行するため、フェイルオーバーの時間はほぼ瞬時に行われます。
どのノードを指示するかの決定は、ロードバランサーで定義されたシステムルールに基づきます。
+ ラウンドロビン
+ セッションまたは IP アフィニティ。セッション内または同じ IP からの複数のリクエストがクラスター内の同じノードに送信されます。
+ レイテンシーベース
+ 負荷ベース
## RTC アーキテクチャの適用性
WebRTC プロトコルを使用すると、[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) (ELB)、[Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) (ALB)、Network Load Balancer (NLB) などの HTTP ベースのロードバランサーを介して WebRTC Gateway を簡単にロードバランシングできます。 [ Load Balancer](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) ほとんどの SIP 実装では、Transmission Control Protocol (TCP) と User Datagram Protocol (UDP) の両方を介したトランスポートに依存しているため、TCP および UDP ベースのトラフィックの両方をサポートするネットワークレベルまたは接続レベルの負荷分散が必要です。
## Application Load Balancer と Auto Scaling を使用した AWS for WebRTC でのロードバランシング
WebRTC ベースの通信の場合、Elastic Load Balancing は、フルマネージドで可用性が高くスケーラブルなロードバランサーを提供し、リクエストのエントリポイントとして機能します。ロードバランサーは、Elastic Load Balancing に関連付けられた EC2 インスタンスのターゲットクラスターに送信されます。WebRTC リクエストはステートレスであるため、Amazon EC2 Auto Scaling を使用して、完全に自動化され制御可能なスケーラビリティ、伸縮性、高可用性を提供できます。
Application Load Balancer は、複数のアベイラビリティーゾーンを使用して可用性が高く、スケーラブルなフルマネージド型のロードバランシングサービスを提供します。これにより、WebRTC アプリケーションのシグナリングを処理する WebSocket WebSocket リクエストのロードバランシングと、長時間実行される TCP 接続を使用したクライアントとサーバー間の双方向通信がサポートされます。Application Load Balancer は、コンテンツベースのルーティングと[スティッキーセッション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html)もサポートし、ロードバランサーが生成した Cookie を使用して、同じクライアントから同じターゲットにリクエストをルーティングします。スティッキーセッションを有効にすると、同じターゲットがリクエストを受け取り、Cookie を使用してセッションコンテキストを復元できます。
次の図は、ターゲットトポロジを示しています。
![\[WebRTC のスケーラビリティと高可用性アーキテクチャを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/images/webrtc-scalability.png)
## Network Load Balancer または 製品を使用した SIP の AWS Marketplace 実装
SIP ベースの通信の場合、接続は TCP または UDP 経由で行われ、RTC アプリケーションの大部分は UDP を使用します。SIP/TCP が最適なシグナルプロトコルである場合は、Network Load Balancer を使用して、フルマネージド、高可用性、スケーラブル、パフォーマンスの負荷分散を行うことができます。
Network Load Balancer は接続レベル (レイヤー 4) で動作し、IP プロトコルデータに基づいて Amazon EC2 インスタンス、コンテナ、IP アドレスなどのターゲットへの接続をルーティングします。TCP または UDP トラフィック負荷分散に最適です。ネットワーク負荷分散は、非常に低いレイテンシーを維持しながら、1 秒あたり数百万のリクエストを処理できます。Amazon EC2 Auto Scaling、Amazon [Elastic Container Service (Amazon ECS)、Amazon ](https://aws.amazon.com/ecs/)[Elastic Kubernetes Service (Amazon](https://aws.amazon.com/eks/) EKS)、 など、他の一般的な AWS サービスと統合されています[AWS CloudFormation](https://aws.amazon.com/cloudformation/)。
SIP 接続が開始された場合のもう 1 つのオプションは、[AWS Marketplace](https://aws.amazon.com/marketplace)市販off-the-shelfソフトウェア (COTS) を使用することです。は、UDP やその他のタイプのレイヤー 4 接続負荷分散を処理できる多くの製品 AWS Marketplace を提供します。COTS には通常、高可用性のサポートが含まれており、Amazon EC2 Auto Scaling などの機能と統合して、可用性とスケーラビリティをさらに強化します。次の図は、ターゲットトポロジを示しています。
![\[AWS Marketplace 製品を使用した SIP ベースの RTC スケーラビリティを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/images/sip-based-rtc-scalability.jpg)