(レポート) TLC301 : Always Online: Real-Time Communications on AWS #reinvent

(レポート) TLC301 : Always Online: Real-Time Communications on AWS #reinvent

Clock Icon2017.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッション「TLC301 Always Online: Real-Time Communications on AWS」を聴講しましたのでレポートします。スピーカーは

  • Shoma Chakravarty - WW Technical Leader, Telecom
  • Ahmad Khan - Sr. Solutions Architect, Amazon Web Services

です。本セッションではキャリアグレードな音声コミュニケーションシステムについてSIPとWebRTCを中心に紹介します。

Use Cases

まずはユースケースの一覧。

Typical Architecture

アーキテクチャの比較。オンプレの場合。

AWSの場合。

ソフトウェア構成は同様に、複数のリージョンやゾーン配置、それらにトラフィックを振り分ける辺りがポイント。

SIP and WebRTC on AWS

リージョンとAZを意識したインスタンスの配置、多数のセッションやPPSをさばくために、SR-IOVとDPDK、ENAが利用できる

専用線としてDirect Connectの利用。オンプレ側はMPLS網を構成例としていますね。

HAとスケーラビリティ

AsteriskサーバーにSecondary Private IPをフローティングIPとして付けて、APIやSDKスクリプトを使って監視、付け替え

Auto Scalingも有効。StatefulなアプリケーションにはLifecycle hookで対応する

SIPでのロードバランス。LBはSIP/TCPであればNLB、SIP/UDPはMarketplaceのパートナープロダクトで扱えるものがある。WebRTCも同様の構成図がありました。

GSLBとしてRoute 53を利用。LBRとフェイルオーバー

Auto ScalingのLifecycleにCW Events→Lambda→EC2 Systems Managerでアクションを実行。Route 53の動的なレコード操作もCW Events+Lambdaで対応可能。

音声コミュニケーションをよりリッチに

AWSの音声関連サービス、Alexaの活用など

ベストプラクティス

  • SIP Overlay
  • いかにSimplifyするか
  • 複数リージョン利用時のリージョン間ネットワーク障害の対応
    • オレゴン-バージニア間で障害発生、カリフォルニアを迂回するように構成
    • FreePBXでのデモ
  • インスタンス、AZ障害対応
    • IPの切り替え、ひとつはDNS。キャッシュされるのでフェイルオーバーが遅くなる。
    • DNSの設定例、SRVレコードの利用。迅速なフェイルオーバーが必要であればDNSはロードバランス用途にしておき、フローティングIPによるフェイルオーバーがオススメ。
    • SIP Trunkの活用。Twilio Trunkingのデモ。
  • AZ Affinity
    • 特定AZに偏らないようにトラフィックを制御する
  • SIPの監視
    • SIPpとiperfの組み合わせ
    • SIPpはCloudWatchに
    • 西海岸から東海岸にSIPpを実行するデモ
    • 見ておくべきメトリクスは2つ
    • Successful calls
    • SIP retransmits

所感

マルチリージョンのSIPサービスは1リージョンの日本ではなかなか難しいですが、北米の複数リージョンを活用した構成は興味深いものでした。WebRTCがほとんど出てこなかったのはちょっと残念。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.