翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# での高可用性とスケーラビリティ AWS
リアルタイム通信のほとんどのプロバイダーは、99.9% から 99.999% までの可用性を提供するサービスレベルと一致しています。必要な高可用性 (HA) の度合いに応じて、アプリケーションのライフサイクル全体を通じて、ますます高度な対策を講じる必要があります。AWS では、堅牢な高可用性を実現するために、次のガイドラインに従うことを推奨しています。
+ 単一障害点がないようにシステムを設計します。ステートレスコンポーネントとステートフルコンポーネントの両方で、自動モニタリング、障害検出、フェイルオーバーメカニズムを使用する
+ 単一障害点 (SPOF) は、通常、N\$11 または 2N 冗長設定で排除されます。N\$11 は*アクティブ/アクティブ*ノード間の負荷分散によって実現され、2N は*アクティブ/スタンバイ*設定のノードのペアによって実現されます。
+ AWS には、スケーラブルな負荷分散されたクラスターや*アクティブスタンバイ*ペアの引き受けなど、両方のアプローチで HA を達成するための方法がいくつかあります。
+ システムの可用性を正しく計測してテストします。
+ 障害に対応、軽減、復旧する手動メカニズムの運用手順を作成します。
このセクションでは、 の機能を使用して単一障害点を達成しない方法に焦点を当てます AWS。具体的には、このセクションでは、可用性の高いリアルタイム通信アプリケーションを構築できるコア AWS 機能と設計パターンのサブセットについて説明します。
# アクティブ/スタンバイステートフルサーバー間の 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)
# クロスリージョン DNS ベースのロードバランシングとフェイルオーバー
[Amazon Route 53](https://aws.amazon.com/route53/) は、RTC クライアントがメディアアプリケーションに登録して接続するためのパブリックエンドポイントまたはプライベートエンドポイントとして使用できるグローバル DNS サービスを提供します。Amazon Route 53 では、DNS ヘルスチェックを設定して、トラフィックを正常なエンドポイントにルーティングしたり、アプリケーションのヘルスを個別にモニタリングしたりできます。
Amazon Route 53 トラフィックフロー機能を使用すると、レイテンシーベースのルーティング、地理的 DNS、地理的近接性、加重ラウンドロビンなど、さまざまなルーティングタイプを通じてトラフィックをグローバルに管理することが容易になります。これらはすべて DNS フェイルオーバーと組み合わせることで、低レイテンシーで耐障害性のあるさまざまなアーキテクチャを実現できます。Amazon Route 53 トラフィックフローのシンプルなビジュアルエディタを使用すると、エンドユーザーがアプリケーションのエンドポイントにルーティングされる方法を、単一の AWS リージョン内か世界中に分散しているかにかかわらず管理できます。
グローバルデプロイの場合、Route 53 のレイテンシーベースのルーティングポリシーは、リアルタイムメディア交換に関連するサービスの品質を向上させるために、メディアサーバーの最も近い場所に顧客を誘導するために特に役立ちます。
新しい DNS アドレスへのフェイルオーバーを適用するには、クライアントキャッシュをフラッシュする必要があることに注意してください。また、DNS 変更がグローバル DNS サーバーに伝播されるため、遅延が発生する可能性があります。Time to Live 属性を使用して、DNS ルックアップの更新間隔を管理できます。この属性は、DNS ポリシーの設定時に設定できます。
グローバルユーザーにすばやく連絡するため、または単一のパブリック IP を使用する要件を満たすために、 をクロスリージョンフェイルオーバーに使用する AWS Global Accelerator こともできます。 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/?blogs-global-accelerator.sort-by=item.additionalFields.createdDate&blogs-global-accelerator.sort-order=desc&aws-global-accelerator-wn.sort-by=item.additionalFields.postDateTime&aws-global-accelerator-wn.sort-order=desc)は、ローカルとグローバルの両方のリーチを持つアプリケーションの可用性とパフォーマンスを向上させるネットワークサービスです。 は、Application Load Balancer、Network Load Balancer、Amazon EC2 インスタンスなどのアプリケーションエンドポイントへの固定エントリポイントとして機能する静的 IP アドレスを単一または複数の AWS リージョンで AWS Global Accelerator 提供します。AWS グローバルネットワークを使用して、ユーザーからアプリケーションへのパスを最適化し、TCP および UDP トラフィックのレイテンシーなどのパフォーマンスを向上させます。
AWS Global Accelerator はアプリケーションエンドポイントの正常性を継続的にモニタリングし、現在のエンドポイントが異常になった場合にトラフィックを最も近い正常なエンドポイントに自動的にリダイレクトします。追加のセキュリティ要件として、高速 Site-to-Site VPN は AWS Global Accelerator を使用して、AWS グローバルネットワークと AWS エッジロケーションを介してトラフィックをインテリジェントにルーティングすることで、VPN 接続のパフォーマンスを向上させます。
![\[AWS Global Accelerator または Amazon Route 53 を使用したリージョン間の高可用性設計を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/images/inter-region-ha-design.png)
# 永続的ストレージによるデータの耐久性と HA
ほとんどの RTC アプリケーションは、認証、認可、アカウンティング (セッションデータ、通話詳細レコードなど）、運用モニタリング、ログ記録のためにデータを保存およびアクセスするために永続的ストレージに依存しています。従来のデータセンターでは、永続的ストレージコンポーネント (データベース、ファイルシステムなど) の高可用性と耐久性を確保するには、通常、ストレージエリアネットワーク (SAN)、独立ディスクの冗長配列 (RAID) 設計、バックアップ、復元、フェイルオーバー処理のプロセスのセットアップによる手間のかかる作業が必要です。は、データの耐久性と可用性に関する従来のデータセンターのプラクティス AWS クラウド を大幅に簡素化し、強化します。
オブジェクトストレージとファイルストレージの場合、[Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) や [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) などの AWS サービスは、マネージド型の高可用性とスケーラビリティを提供します。Amazon S3 のデータ耐久性は 99.999999999% (11 nines) です。
トランザクションデータストレージでは、高可用性デプロイで Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle、Microsoft SQL Server をサポートするフルマネージド Amazon Relational Database Service (Amazon RDS) を利用できます。 PostgreSQL MySQL MariaDB レジストラ関数、サブスクライバープロファイル、またはアカウンティングレコードストレージ (CDRs) の場合、Amazon RDS は耐障害性があり、可用性が高く、スケーラブルなオプションを提供します。
# Amazon Route 53 AWS Lambda、Amazon EC2 Auto Scaling による動的スケーリング
AWS では、機能の連鎖と、インフラストラクチャイベントに基づくサービスとしてカスタムサーバーレス関数を組み込む機能を使用できます。RTC アプリケーションで多くの汎用性がある設計パターンの 1 つは、Auto Scaling ライフサイクルフックと [Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)、Amazon Route 53、および [AWS Lambda](https://aws.amazon.com/lambda/) functions. AWS Lambda functions の組み合わせです。functions は、任意のアクションまたはロジックを埋め込むことができます。次の図は、これらの機能が連携して、自動化によってシステムの信頼性とスケーラビリティを向上させる方法を示しています。
![\[Amazon Route 53 の動的更新による自動スケーリングを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/images/auto-scaling-dynamic-updates.jpg)
# Amazon Kinesis Video Streams で高可用性 WebRTC
[Amazon Kinesis Video Streams](https://aws.amazon.com/kinesis/video-streams/?nc=sn&loc=0&amazon-kinesis-video-streams-resources-blog.sort-by=item.additionalFields.createdDate&amazon-kinesis-video-streams-resources-blog.sort-order=desc) は、WebRTC を介したリアルタイムのメディアストリーミングを提供するため、ユーザーは再生、分析、機械学習のためにメディアストリームをキャプチャ、処理、保存できます。これらのストリームは可用性が高く、スケーラブルで、WebRTC 標準に準拠しています。Amazon Kinesis Video Streams には、高速ピア検出と安全な接続確立のための WebRTC シグナリングエンドポイントが含まれています。これには、NAT (STUN) 用のマネージドセッショントラバーサルユーティリティと、ピア間でメディアをリアルタイムで交換するための NAT (TURN) エンドポイントに関するリレーを使用したトラバーサルが含まれます。また、無料のオープンソース SDK が含まれており、カメラファームウェアと直接統合して Amazon Kinesis Video Streams エンドポイントとの安全な通信を可能にし、ピア検出とメディアストリーミングを可能にします。最後に、Android、iOS、JavaScript 用のクライアントライブラリを提供します。これにより、WebRTC 準拠のモバイルおよびウェブプレーヤーは、メディアストリーミングと双方向通信のためにカメラデバイスを安全に検出して接続できます。
# Amazon Chime Voice Connector での高可用性 SIP トランキング
[ Amazon Chime Voice Connector](https://docs.aws.amazon.com/chime-sdk/latest/ag/voice-connectors.html) は、pay-as-you-go SIP トランキングサービスを提供します。これにより、企業は電話システムを使用して安全で安価な電話を発信または受信できます。Amazon Chime Voice Connector は、サービスプロバイダーの SIP トランクまたは統合サービスデジタルネットワーク (ISDN) プライマリレートインターフェイス (PRIs。お客様は、インバウンド通話、アウトバウンド通話、またはその両方を有効にすることができます。
このサービスは、 AWS ネットワークを使用して、複数の にわたって高可用性の通話エクスペリエンスを提供します AWS リージョン。SIP トランキング通話、または転送された SIP ベースのメディア録画 (SIPREC) フィードから Amazon Kinesis Video Streams に音声をストリーミングして、ビジネス通話からリアルタイムでインサイトを得ることができます。[Amazon Transcribe](https://aws.amazon.com/transcribe/) やその他の一般的な機械学習ライブラリとの統合により、オーディオ分析用のアプリケーションをすばやく構築できます。