WebRTC配信システムをAWSからオンプレミスに切り替えている話

2021年7月27日 DMM meetup #31 での発表内容です

Transcript

1. © DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31 DMM.com ITインフラ本部SRE部 松浦庸介 2021年7月27日
2. © DMM.com 自己紹介 松浦 庸介 2020年5月入社 ITインフラ本部 SRE部所属 WebRTCリアルタイム配信システムの開発運用を担当
3. © DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31
4. © DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31
5. © DMM.com AWSにオンプレミスから?
6. © DMM.com AWSからオンプレミスに であってます！
7. © DMM.com WebRTC配信システムの特徴 送信者から送られてくるストリームをリアルタイムで配信 →低遅延性が求められる 送信者と受信者は1:nの関係 →受信トラフィックより送信トラフィックが多い 1送信者あたりの受信者は10人未満が多い →CDNによるトラフィック分散が難しい
8. © DMM.com ことのはじまり 以前はFlashを使った配信システムを運用していました しかし、Flashは2020年末で完全終了・・・ →そこでWebRTCベースの配信システムへの刷新
9. © DMM.com 開発当初の懸念 WebRTCという未知の領域に開発は手探り • 使うコーデックは? • どんなソフトウェアを使う? • サーバのスペックは? • トラフィックはどれくらい発生する? • 何台くらいのサーバが必要? 不確実性が多いためオンプレは使いにくかった →サーバはEC2を選択した
10. © DMM.com 現在のWebRTCサーバ構成 2021年7月時点で通常用途サーバは下記の構成 EC2: c5.12xlarge × 8台 毎日のピーク送信トラフィック: 約750Mbps/台 ストリーム配信系だとc5aの方が強いんじゃないの? 実は使っているソフトウェアがEPYC系インスタンスではパフォーマン スが出ません
11. © DMM.com 導入が進むにつれてコストも増える
12. © DMM.com コストの分析をしてみる WebRTCサーバの稼働が増えるに従い、コストが増えていく なんとかコスト削減ができないだろうか では何がコスト要因なのか? Cost Explorerで調べてみよう ※2021年1月にコストが下がっているのは、サーバをCentOS7から CentOS8に変更した影響 CentOS7でパフォーマンスが劣化するためOSを切り替えた
13. © DMM.com コストの要因分析
14. © DMM.com 通信コストが高かった AWS費用のおよそ75%が転送量課金 転送量単価は段階的に安くなり、150TB以上で単価が最も安くなるが、 月間の転送量はその2倍以上あった EC2料金表には「1 か月間のデータ転送量が500TBを超える場合は、お 問い合わせください」とある
15. © DMM.com
16. © DMM.com オンプレネットワークの活用 DMMでは自社で対外400Gbpsのネットワークを保有している 契約帯域が大きいので、bpsあたりの単価はかなり安い このリソースを使いたい！
17. © DMM.com DMMはクラウドにすべて寄せる方針では? そんなことはありません オンプレのほうがよければ、積極的に使っていきます https://www.sbbit.jp/article/cont1/55186 「Tech Visionを受けて、すべてがパブリッククラウドに移行すると誤 解して『自分たちの仕事がなくなる』と考えるメンバーがいました。 『最適なものを選択する』というだけだったのですが、こうした誤解 を解き、しっかりとコミュニケーションをとって正しく理解してもら うことが必要でした」（大久保氏）
18. © DMM.com オンプレサーバの概要 VMware Integrated OpenStack + NSX-Tによるプライベートクラウド基盤 ベアメタルで払い出してもらう方法もあった しかし手っ取り早いので、プライベートクラウドを採用 スペックもEC2とさほど変わらない EC2(c5.12xlarge) オンプレ ハイパーバイザー nitro VMware CPU Cascade Lake Cascade Lake 1ソケットあたりのコア数（スレッド数） 24(48) 20(40) メモリ 96GB 96GB
19. © DMM.com 費用試算
20. © DMM.com 費用試算 サーバのコストはオンプレの方が高かった （Savings Planや保守的な構成見積もりなどによる影響） ただし稼働が安定してくれば、まだ下げられる余地はあり 一方ネットワークコストはオンプレの方が95%安い 合計すると半額以下になる これは移行するしかない！
21. © DMM.com もちろんクラウドのメリットはある もちろんクラウドの方が適している場合も多い クラウドで調達したときのメリット • サーバの調達が速い • 物理機材の在庫を（あまり）気にせず、APIで追加削除が簡単 稼働当初はスペック想定が難しかったため、サーバの追加削除も多く、 EC2のメリットも大きかった しかし運用が安定してくるとメリットが生かせなくなってきた
22. © DMM.com アプリ改修の道のり
23. © DMM.com 切り替えのハードル 配信サーバとAPIが同一VPC内にあることを前提とする実装 • 配信サーバがコールするAPIがInternal ALB配下にある • APIサーバがコールする配信サーバの管理APIが、プライベートIPア ドレス経由でリクエストされている 以下2種類の”API”が登場します。紛らわしいのですがご容赦ください API: 配信サーバが認証時などで使うウェブフックAPI 管理API: 配信ソフトに実装されているコントロール用API
24. © DMM.com 現在の通信構成 通信がVPC内で完結することが 前提になっている
25. © DMM.com 二つのアイデア オンプレに配信サーバを構築するにあたり、2種類の構成が考えられる A. Site-to-Site VPNやDirect ConnectでVPCを拡張する B. 配信サーバとAPIの通信をインターネット経由にする プランBを選択 • 構成がシンプルで、機材の冗⻑化などの考慮もいらない • ネットワーク定額制のベアメタルホスティングなども導入しやすい
26. © DMM.com 改修のポイント • APIをInternet ALB配下に変更する • 管理APIをnginxでHTTPS終端させ、インターネットから接続できる ようにする • 一度に切り替えるのが難しいため、切替期間中は新旧通信が混在す る
27. © DMM.com 切替途中の構成
28. © DMM.com 最終形
29. © DMM.com 配信サーバの管理API 配信サーバはすでにTCP443でWebSocketやTURN-TCP, TURN-TLS通信 を行っている 管理APIには認証機能がないので、nginxでIPアドレス制限が必要 WebSocketなど一般公開される通信はIPアドレス制限できない TURNと管理APIが同じパスだったため、管理APIのみのIPアドレス制限 ができなかった →管理APIのHTTPSポートを違うものにした
30. © DMM.com 切替期間中特有の課題 切り替え中は、API, 管理APIへのアクセスがローカルとグローバル経 由のものが混在し、それぞれ挙動も異なる 配信サーバ管理DBに登録されているIPアドレスがプライベートIPアド レスかどうかで管理APIのURLを変える • プライベートIPアドレス: http://(private_ip):3000 • グローバルIPアドレス: https://(fqdn):8443
31. © DMM.com 具体例 ID IPアドレス FQDN 1 10.20.30.40 foo001.example.com 2 192.0.2.1 foo002.example.com データベースには以下のように IPアドレスとFQDNが登録されています。 ID1のサーバはプライベートIPアドレスが、 ID2のサーバはグローバルIPアドレスが登録されています。 プライベートIPアドレスが登録されているの で、管理APIのURLは http://10.20.30.40:3000 グローバルIPアドレスが登録されているので、 管理APIのURLは https://foo002.example.com:8443
32. © DMM.com ところで・・・ あるIPアドレスがプライベートIPアドレスか判定するのは 結構めんどくさくないですか?特にクラスB(172.16.0.0/12) いくつかやり方はありますが、ロングIPアドレスを使っています
33. © DMM.com 余談（ロングIPアドレス表記） IPv4アドレスは通常203.0.113.99のように表記しますが、各オクテット を256進数とみなすと、十進数表記に変換可能です。 これがロングIPアドレスです。 先述の例だと203*2563 + 0*2562 + 113*256 + 99 = 3405803875 10.0.0.0/8は167772160(10.0.0.0)〜184549375(10.255.255.255) →CIDR判定が整数の比較演算でできる さらに余談ですがMySQLのserver-idも32bit符号なし整数なので、ロ ングIPアドレスをそのまま使うと設定が便利
34. © DMM.com 判定のコード例(PHP) /** * プライベートIPか判定してURLを作成する */ private function getServerUrl($ipv4, $fqdn): string { $iplong = ip2long($ipv4); //PHPの場合ip2longという専用の関数が存在する if (($iplong >= 167772160 && $iplong <= 184549375) || ($iplong >= 2886729728 && $iplong <= 2887778303) || ($iplong >= 3232235520 && $iplong <= 3232301055)) { return $ipv4; } else { return 'https://' . $fqdn; } }
35. © DMM.com 現在の切替状況は? 現在API改修が絶賛QAテスト中です 来月頭から切替を始めたいな
36. © DMM.com まとめ リソースが安定していて、通信が多いシステムはオンプレを使うメリ ットが出てくる 一方でAPIサーバのように起動停止しやすいシステムは積極的にクラウ ド（特にコンテナ）に寄せていきたい DMMではオンプレのリソースも潤沢なので、今後も適材適所に使い分 けていきます