Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

大規模ライブ配信の苦労ポイント

129 views

Published on

「Kubernetes Meetuo Tokyo #13」で発表された資料です。

https://k8sjp.connpass.com/event/100842/

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

大規模ライブ配信の苦労ポイント

  1. 1. 大規模ライブ配信 の苦労ポイント
  2. 2. • 堀口真司 • Kubernetes半年ぐらい • インフラ7年ぐらい • ゲーム業界15年ぐらい • GAMECUBE ~ PS3 あたり • MMORPG やソシャゲ • AWS や CEDEC 系に出没 • ちかごろ → → → • GCP 全般 • ライブ動画配信担当
  3. 3. 今日のはなし • エンコーダーの負荷分散をどうやって検討~実装したか • サーバ側で動画を再エンコードしてます(してないケースもあります) • 誰でも配信できます(来月リリース予定) • 遅延は2~15秒ぐらい、用途や雰囲気でちょいちょい調整してる
  4. 4. 構成 Kubernetes cluster GAE Microservices LB RTMP Logging Cloud Storage GAE Media API GAE User API GKE Encoder GKE Chat LB RTMP GKE Encoder • Public User • Social & Streaming • Developer • Operator • Official Studio • Live streaming Cloud SQL Monitoring • Viewer EncodingLive Event Recording Internal Access Ingress / HTTPS websocket tool on IAP GKE Support Cloud SQL • PagerDuty • Slack GKE Chat GKE Redis GKE Dashboard GKE Certificate Manager GKE api GAE batch Cloud DNS *.wrightflyer.net Cloud Datastore 今日のはなし!
  5. 5. 負荷分散方法 • 新しいリクエストが来ないようにヘルスチェックを落とす • エンコードが始まったら readinessProbe を false にさせる • 念のため終わったら liveness も落として再起動させる • readiness → 新しいリクエストを受け付けたくない • liveness → 機能しなくなったので再起動したい • 実装が簡単で、概ね期待通りに動作した • Sidecar のいずれかの readiness が落ちていればオッケー • 全 Pod の readiness が落ちたままだと TCP 的にも繋がらなくなる • 503 とかそういうエラーも返せない • チャットサーバにも導入予定 • 入室すると長居するので random では先に起動した Pod に偏りすぎてしまう Pod Pod Pod Pod free free busy busy
  6. 6. ボツ案1 • Proxy-mode: ipvs 使う。 • round-robin や least-connection がある • LC 設定する • 常に Pod の数を Encoder より多く • しかし GKE では ipvs 使えず! • iptables なので random のみ • 有力案だっただけにがっかり • オンプレ環境では ipvs 多い… https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-ipvs
  7. 7. ボツ案2 • 大量の Service を作る。増減させる。 • 社内では node k8s.js | kubectl create -f - として、 yaml を使わずに json を作り出 すパターンがちょいちょいある • helm よりお手軽だったのと、自由度が高くて AWS 構成管理でもよく使ってた • なので増やしたり減らしたりは結構かんたん • 1Service (LoadBalancer) 1Pod の構成が狙い • けど流行って数千人とか来てしまったらおそらく耐えられない • IP アドレス足りなくなるよねたぶん • お金もかかりそう(かからない?)
  8. 8. 没案3 • ロードバランサーのパスルールで振り分けられるようにする • Amazon ECS + Application Load Balancer で特定のコンテナに WebSocket を振り 分けるのに使ったことがある • ただし、映像が送られてくるのは RTMP というプロトコルで HTTP ではない • RTMP にも URI のようなものはパケットの中に入っているので HTTP トンネルのよ うなもので振り分けられそうだけど、スマホからのアップロードに懸念があった Cloud Load Balancing Container Engine Container Engine Container Engine
  9. 9. 課題 • HPA と相性があんまりよくないかも • 関心対象は CPU とか Mem じゃないので、そのままの仕組みが使えなかった • Available な Pod の数を維持するような仕組みを開発・利用 • GKE で一般的な HTTP じゃない案件なので情報不足 • MMO とか MO も好きなんだけど Kubernetes では運用できる気がしない… • VTuber 関連技術エンジニア不足 • Unity, UE4, mocap, Streaming, GCP • C#, C++, swift, kotlin, gae-go, nodejs

×