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