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.

Tokyo videotech#2 nishimuta

94 views

Published on

Tokyo VideoTech#2で発表した資料です。

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Tokyo videotech#2 nishimuta

  1. 1. 肥大化するOVP、 その課題と解決へのアプローチ
  2. 2. はじめに。 私がOVP関連の運用・開発に関して 経験してきたこと、苦労したこと、 こう変えていきたいといった内容になります ネタがなかった。 2
  3. 3. 自己紹介 西牟田 健太郎 Jストリームは丸3年 エンジニア?運用が多い 3
  4. 4. “肥大化” 1.
  5. 5. 肥大(ひだい、英: hypertrophy) とは、組織あるいは器官が 通常の容積よりも大きさを 増した状態。 5 https://ja.wikipedia.org/wiki/肥大
  6. 6. Not 拡大 ▪ サービスの成長に伴い様々なものが拡大する ▪ 顧客数、コンテンツ数、容量、通信流量 ▪ 機能、対象者 ▪ システムの構成が複雑になり、全体把握等が難しくなる →“肥大” 6
  7. 7. “肥大化”するOVP 2.
  8. 8. 注意 弊社OVPとは関係あったりなかったりということでお願いします 8
  9. 9. Online Video Platform ▪ エンコードやメタ管理等複数システムが絡んだ プラットフォーム ▪ OVPの肥大化 ≒ システムの肥大化 9
  10. 10. システムの肥大化 ▪ 想定されたキャパシティを超えている ▪ 機能改修の影響範囲が拡大 ▪ ブラックボックス化 うかつに手をだせない 10
  11. 11. ありがちなこと ▪ ドキュメントの更新なし ▪ 人依存 ▪ 手動デプロイ ▪ スケールの考慮なし ▪ 改修規模、影響範囲が不透明 ▪ 謎機能 11
  12. 12. ドキュメントの更新なし ▪ 開発当時のまま。 ▪ 古いのか更新されていないのかわからないファイルが サーバおかれている 12
  13. 13. 人依存 ▪ 達人 ▪ 過去に在籍した人が作ったメンテナンスできないソース ▪ 担当者が辞めると・・・ 13
  14. 14. 手動デプロイ ▪ サーバにSSHで入ってコピペ □ dir名_bak □ ファイル名_20190220 14
  15. 15. 拡張性なし ▪ スケールアップで耐えられる間は問題なし □ スケールアウトになると・・・ ▪ 単純なサーバ追加では不可な場合も 15
  16. 16. 改修規模、影響範囲が不透明 ▪ 影響範囲の調査が複雑になる □ ドキュメント不足や知見不足により漏れが発生 ▪ 改修範囲が多岐にわたる □ 別機能の改修でソースが被るとより複雑に 16
  17. 17. 謎機能 ▪ 誰も使用していない(はずの)機能 ▪ 影響があることに気づきにくい □ バグが見つかるのに時間がかかることも 17
  18. 18. 他にも ▪ テストコード無し ▪ STG環境無し 18
  19. 19. 事例 3.
  20. 20. Flash → HTML5 ▪ HLS生成 ▪ 配信サーバの刷新 ▪ メタ管理機能の改修 ▪ (プレイヤー開発) 20
  21. 21. HLS生成 ▪ HLS未作成のコンテンツ数が約30万件 ▪ 既存エンコーダだけでは再トランスコードが間に合わない 21
  22. 22. 内容 ▪ クラウド連携機能を開発 ▪ 既存の処理に組み込み前提 ▪ 設定項目の管理テーブルの改修 ▪ キュー管理機能の改修 ▪ 進捗の手動監視 22
  23. 23. 配信サーバの刷新 ▪ 先人スクリプト ▪ ドキュメントが存在しない ▪ メンテナンスされていない 23
  24. 24. 内容 ▪ 新規でプラグイン開発 ▪ 既存の機能をもったプラグイン ▪ 機能としての見直し無し ▪ 監視スクリプトを組み込み 24
  25. 25. メタ管理機能改修 ▪ 拡張性のないテーブル設計 ▪ 追加項目に非対応 25
  26. 26. 内容 ▪ メタ管理テーブルにカラムの追加 ▪ テーブル設計の見直し無し ▪ 正規化等も考慮せず ▪ 既存機能への影響調査がほとんど 26
  27. 27. 4. “肥大化”させないための 取り組み
  28. 28. ドキュメントの更新 ▪ チケット管理 □ Trac → Redmine → GitLab? □ Gitフローでブランチ管理 ▪ Excel、PowerPointから脱却 □ Git管理 □ MarkDown + Mermaid 28
  29. 29. スケール ▪ CDN連携や一部機能はスケールする仕組みを作成 □ 自動化したい ▪ 関連システム間の結合を疎にし、 単機能としてマイクロサービス化を徐々に □ 一部機能をk8s環境に移行中 □ Dockerでコンテナ化も実施中 29
  30. 30. デプロイの自動化 ▪ 一部から徐々に ▪ CI/CD □ k8s : Jenkins → Spinnaker 30
  31. 31. テストの自動化 ▪ クラウドテスト環境 □ Dockerでffmpegの環境をパッケージ化 □ テストエンコーダとしてRTMPを指定した仕様で出力 ▪ 動画テスト □ 素材をアップロード→エンコード→視聴をテスト □ HLS→Dash、CMAFに拡張? 31
  32. 32. できていないこと ▪ 人依存 → 難しい 統一された開発プロセスの整備から:Gitフロー ▪ 改修規模、影響範囲 → 各機能の結合度が強すぎて機能分割から 32
  33. 33. まとめ 5.
  34. 34. “肥大化”は避けられない ▪ 肥大化したシステムを手動運用で続けるのは厳しい ▪ 自動化など人の手からどんどん離すべき 34
  35. 35. OVP関係ないシステムの話? ▪ プラットフォームであるからこそ影響が大きい □ 多機能 □ 環境が複雑 ▪ 動画関連の技術更新スピード □ 配信形式やプロトコルが多岐に システムとして受け入れられる土台は作っておくべき 35
  36. 36. ありがとう ございました。 36

×