Slide 1

Slide 1 text

© DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31 DMM.com ITインフラ本部SRE部 松浦庸介 2021年7月27日

Slide 2

Slide 2 text

© DMM.com 自己紹介 松浦 庸介 2020年5月入社 ITインフラ本部 SRE部所属 WebRTCリアルタイム配信システムの開発運用を担当

Slide 3

Slide 3 text

© DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31

Slide 4

Slide 4 text

© DMM.com WebRTC配信システムを AWSからオンプレミスに 切り替えている話 DMM meetup #31

Slide 5

Slide 5 text

© DMM.com AWSにオンプレミスから?

Slide 6

Slide 6 text

© DMM.com AWSからオンプレミスに であってます!

Slide 7

Slide 7 text

© DMM.com WebRTC配信システムの特徴 送信者から送られてくるストリームをリアルタイムで配信 →低遅延性が求められる 送信者と受信者は1:nの関係 →受信トラフィックより送信トラフィックが多い 1送信者あたりの受信者は10人未満が多い →CDNによるトラフィック分散が難しい

Slide 8

Slide 8 text

© DMM.com ことのはじまり 以前はFlashを使った配信システムを運用していました しかし、Flashは2020年末で完全終了・・・ →そこでWebRTCベースの配信システムへの刷新

Slide 9

Slide 9 text

© DMM.com 開発当初の懸念 WebRTCという未知の領域に開発は手探り • 使うコーデックは? • どんなソフトウェアを使う? • サーバのスペックは? • トラフィックはどれくらい発生する? • 何台くらいのサーバが必要? 不確実性が多いためオンプレは使いにくかった →サーバはEC2を選択した

Slide 10

Slide 10 text

© DMM.com 現在のWebRTCサーバ構成 2021年7月時点で通常用途サーバは下記の構成 EC2: c5.12xlarge × 8台 毎日のピーク送信トラフィック: 約750Mbps/台 ストリーム配信系だとc5aの方が強いんじゃないの? 実は使っているソフトウェアがEPYC系インスタンスではパフォーマン スが出ません

Slide 11

Slide 11 text

© DMM.com 導入が進むにつれてコストも増える

Slide 12

Slide 12 text

© DMM.com コストの分析をしてみる WebRTCサーバの稼働が増えるに従い、コストが増えていく なんとかコスト削減ができないだろうか では何がコスト要因なのか? Cost Explorerで調べてみよう ※2021年1月にコストが下がっているのは、サーバをCentOS7から CentOS8に変更した影響 CentOS7でパフォーマンスが劣化するためOSを切り替えた

Slide 13

Slide 13 text

© DMM.com コストの要因分析

Slide 14

Slide 14 text

© DMM.com 通信コストが高かった AWS費用のおよそ75%が転送量課金 転送量単価は段階的に安くなり、150TB以上で単価が最も安くなるが、 月間の転送量はその2倍以上あった EC2料金表には「1 か月間のデータ転送量が500TBを超える場合は、お 問い合わせください」とある

Slide 15

Slide 15 text

© DMM.com

Slide 16

Slide 16 text

© DMM.com オンプレネットワークの活用 DMMでは自社で対外400Gbpsのネットワークを保有している 契約帯域が大きいので、bpsあたりの単価はかなり安い このリソースを使いたい!

Slide 17

Slide 17 text

© DMM.com DMMはクラウドにすべて寄せる方針では? そんなことはありません オンプレのほうがよければ、積極的に使っていきます https://www.sbbit.jp/article/cont1/55186 「Tech Visionを受けて、すべてがパブリッククラウドに移行すると誤 解して『自分たちの仕事がなくなる』と考えるメンバーがいました。 『最適なものを選択する』というだけだったのですが、こうした誤解 を解き、しっかりとコミュニケーションをとって正しく理解してもら うことが必要でした」(大久保氏)

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

© DMM.com 費用試算

Slide 20

Slide 20 text

© DMM.com 費用試算 サーバのコストはオンプレの方が高かった (Savings Planや保守的な構成見積もりなどによる影響) ただし稼働が安定してくれば、まだ下げられる余地はあり 一方ネットワークコストはオンプレの方が95%安い 合計すると半額以下になる これは移行するしかない!

Slide 21

Slide 21 text

© DMM.com もちろんクラウドのメリットはある もちろんクラウドの方が適している場合も多い クラウドで調達したときのメリット • サーバの調達が速い • 物理機材の在庫を(あまり)気にせず、APIで追加削除が簡単 稼働当初はスペック想定が難しかったため、サーバの追加削除も多く、 EC2のメリットも大きかった しかし運用が安定してくるとメリットが生かせなくなってきた

Slide 22

Slide 22 text

© DMM.com アプリ改修の道のり

Slide 23

Slide 23 text

© DMM.com 切り替えのハードル 配信サーバとAPIが同一VPC内にあることを前提とする実装 • 配信サーバがコールするAPIがInternal ALB配下にある • APIサーバがコールする配信サーバの管理APIが、プライベートIPア ドレス経由でリクエストされている 以下2種類の”API”が登場します。紛らわしいのですがご容赦ください API: 配信サーバが認証時などで使うウェブフックAPI 管理API: 配信ソフトに実装されているコントロール用API

Slide 24

Slide 24 text

© DMM.com 現在の通信構成 通信がVPC内で完結することが 前提になっている

Slide 25

Slide 25 text

© DMM.com 二つのアイデア オンプレに配信サーバを構築するにあたり、2種類の構成が考えられる A. Site-to-Site VPNやDirect ConnectでVPCを拡張する B. 配信サーバとAPIの通信をインターネット経由にする プランBを選択 • 構成がシンプルで、機材の冗⻑化などの考慮もいらない • ネットワーク定額制のベアメタルホスティングなども導入しやすい

Slide 26

Slide 26 text

© DMM.com 改修のポイント • APIをInternet ALB配下に変更する • 管理APIをnginxでHTTPS終端させ、インターネットから接続できる ようにする • 一度に切り替えるのが難しいため、切替期間中は新旧通信が混在す る

Slide 27

Slide 27 text

© DMM.com 切替途中の構成

Slide 28

Slide 28 text

© DMM.com 最終形

Slide 29

Slide 29 text

© DMM.com 配信サーバの管理API 配信サーバはすでにTCP443でWebSocketやTURN-TCP, TURN-TLS通信 を行っている 管理APIには認証機能がないので、nginxでIPアドレス制限が必要 WebSocketなど一般公開される通信はIPアドレス制限できない TURNと管理APIが同じパスだったため、管理APIのみのIPアドレス制限 ができなかった →管理APIのHTTPSポートを違うものにした

Slide 30

Slide 30 text

© DMM.com 切替期間中特有の課題 切り替え中は、API, 管理APIへのアクセスがローカルとグローバル経 由のものが混在し、それぞれ挙動も異なる 配信サーバ管理DBに登録されているIPアドレスがプライベートIPアド レスかどうかで管理APIのURLを変える • プライベートIPアドレス: http://(private_ip):3000 • グローバルIPアドレス: https://(fqdn):8443

Slide 31

Slide 31 text

© 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

Slide 32

Slide 32 text

© DMM.com ところで・・・ あるIPアドレスがプライベートIPアドレスか判定するのは 結構めんどくさくないですか?特にクラスB(172.16.0.0/12) いくつかやり方はありますが、ロングIPアドレスを使っています

Slide 33

Slide 33 text

© 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アドレスをそのまま使うと設定が便利

Slide 34

Slide 34 text

© 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; } }

Slide 35

Slide 35 text

© DMM.com 現在の切替状況は? 現在API改修が絶賛QAテスト中です 来月頭から切替を始めたいな

Slide 36

Slide 36 text

© DMM.com まとめ リソースが安定していて、通信が多いシステムはオンプレを使うメリ ットが出てくる 一方でAPIサーバのように起動停止しやすいシステムは積極的にクラウ ド(特にコンテナ)に寄せていきたい DMMではオンプレのリソースも潤沢なので、今後も適材適所に使い分 けていきます