老舗VODプラットフォームのモダナイゼーションへの挑戦

Transcript

1. 老舗VODプラットフォームのモダ ナイゼーションへの挑戦 OpenDX 2021 2021/9/10
2. Introduction
3. 自己紹介 山本　一貴 バックエンドエンジニア videomarketサービスの基 盤を統括 好きなGCPプロダクトは Cloud Logging 阿部　祐二 バックエンドエンジニア videomarketサービスのテッ クリード 好きなGCPプロダクトは Cloud Run
4. 会社紹介 株式会社ビデオマーケット ガラケー時代からTVOD（都度課金）を軸とした動 画配信サービスを提供 映画、アニメ、ドラマなど多彩なジャンルで配信本 数は国内最大の 24 万本以上 自社が開発した独自なエンコード方式で高品質な 動画を提供 MISSION
 快適なユーザー体験をもたらし、 最適な映像流通を皆と創る

5. サービス紹介 • サービス事業 ◦ ビデオマーケット ▪ 配信本数は国内最大の 24 万本以上の動画配信サービス ▪ 有料会員には毎月50作品レンタル可能なクーポンを配布中 ◦ ミレール ▪ D2C型の都度課金型動画配信サービス • プラットフォーム事業 ◦ music.jp、GYAOストア、DMM動画への配信システムを提供
6. agenda
7. 本日はなすこと • 弊社の動画配信はガラケー時代から続いているサービスであり、歴史を重ね る中でレガシーと化した部分が多数存在する。 • こちらをどのような技術を使用してモダナイゼーションしようとしているか？
8. 現状 • ガラケーの仕様を踏襲しレガシー化したシステム ◦ レガシー化の原因→時代の流れに対応する速度重視の開発 ▪ 対応デバイスを増加させてきた • 都度、別のWEBアプリケーションとして作成されるためバックエンドが肥大化 • 別々のため機能追加にデバイス種別分工数がかかり非効率的 ▪ 保守性の低さ • ライブラリ等バージョン管理難しい状態で作成され、既に手が入れづらい状況 • メンテナンスやバージョンアップすることが考慮されていない • 指標が収集しづらく、改善点が見つけづらい
9. 対応デバイスの歴史 2006年3月 ガラケー向けVODサービス開始 2008年8月 iPhone3G発売 2009年7月 Android初上陸 2010年10月 iOS向けVODサービス開始 2010年12月 Android向けVODサービス開始 2011年11月 世界初スマホ向けHD配信サービ ス開始 2014年1月 PC向けVODサービス開始 2014年5月 Chromecast販売開始 2015年2月 AndroidTV日本販売開始 2015年2月 AndroidTV向けアプリ配信開始 2014年10月 Chromecast対応 2017年9月 「DOLBY ATMOS」に対応 2017年11月 tvOS向けアプリ配信開始 2011年10月 au初のiPhone4s販売開始 2009年6月 人気の火付け役iPhone3GS発売
10. 課題 • メンテナンス性 • 可用性
11. メンテナンス性
12. 現状 • ビジネススピードに合わせてローンチを重ねた結果、メンテナンス性が薄れて いった
13. 同じ機能が分散されている • 機能が共通化されていない ◦ 図のようにAデバイス用機能のコピーからBデバイス用が作成され、Bを 元にさらにC用が作成... ◦ ほぼ同じ機能が全て独自に改修されていた A B C コピー コピー コピー
14. 課題 • 全デバイスに共通の機能を追加する場合において、全デバイスに同じ改修が 必要 • コピーが元になるため、不要な機能も踏襲されている • 影響範囲の調査が困難なため、削除に工数がかかる • 各デバイスで独自に改修された結果、データの捉え方がデバイスごとに異な りテストが困難 モノリスでの限界→マイクロサービスへ
15. これを：’という共通機能を追加する場合 A A’ B’ B C C’ 共通機能を追加した場合、 全てのデバイスに改修が必要 ＝３倍工数がかかる！！ 改修 改修 改修
16. こうしたい：’という共通を追加する場合 A B C 機能D 機能E 機能F A B C 機能D 機能E’ 機能F サービスをデバイ スごとではなく、 機能ごとへ Eの改修のみ！
17. 可用性
18. 可用性 • 現状 ◦ 仮想環境で常に最大数を想定してサービスが動いている ◦ 各々で監視設定が必要 ◦ ライブラリの更新、セキュリティパッチの適用が必要
19. 可用性 • 課題 ◦ 多くを手動で管理する必要がある ▪ 想定以上のスパイクが発生した際のスケールアウト時にサーバーの増設や LBの設定が必 要。スケールインも同様 ▪ インフラチームの負担が多く新しいサービスを追加しずらい ◦ アプリケーションログが分散、パフォーマンス管理ができていない →マネージドサービスを利用し、運用の可用性を高める
20. 可用性：これを いつでも一定 L B スパイク時は 手動で増設、 設定が必要...
21. 可用性：こうしたい • 接続数が少ない時はリソースを少なく • 接続が多い時は多く処理できるように L B L B
22. 監視：これを これはこれで見やすいが 他の情報も監視できるように
23. 監視：こうしたい https://cloud.google.com/trace/docs/quickstart?hl=ja#view_the_trace_overview
24. ビジネスの幅を広げるためモノリスからマイクロサービス化へ 課題を解決し、既存の強み（配信本数、作品情報）を生かした、多くの人やサービスに利 用してもらえるサービスへ！
25. 現状の課題 • メンテナンス性 • 可用性 • 運用の改善
26. 現状の課題 • メンテナンス性 • 可用性 • 運用の改善 で解決しよう！
27. メンテナンス性
28. 課題解決へのアプローチ メンテナンス性の欠如、モノリスの限界 GKEを利用してマイクロサービスアーキテクチャへ
29. 全体構成図
30. 全体構成図
31. なぜKubernetes Engineを選択したのか コンテナ化したい • 軽量、高速、ポータビリティ etc… • パブリッククラウド✕コンテナ コンテナオーケストレーションツール • デファクトスタンダードの Kubenetes フルマネジードサービス Kubernetes Engine GCPでは自然な選択か
32. BFF • 役割はフロントからのリクエストを集約するAPI Gateway ◦ クライアント側はBFFに対してのみのリクエスト、バックエンドを意識しなくてよい • 開発言語はGo ◦ 技術スタックとしてフロントエンド技術が弱い ◦ 知見を活かせる ◦ Goのパフォーマンスを信頼
33. BFF • ビジネスロジックの一部はMicroService側へ委譲 • MicroService間での通信をある程度許容 API gatewayによるBFFの複雑化
34. BFF • 開発規模・開発要員の大きさ • 検証、仕様調整のためのmockサーバーをあらかじめ用意 バックエンド側が担当することより フロントエンドとのコミュニケーションが疎になる？
35. MicroService • Backend API群 • 開発言語はKotlin ◦ 技術スタックとしての知見や利用実績 • gRPCサーバー ◦ .protoファイルは個々のリポジトリで管理 • DBは既存サービスのものを使用
36. 通信方式 別の通信方式でOK!
37. 通信方式 • Client <ー> BFF はgraphQL ◦ １リクエストで複数リソースにアクセス可能 ◦ クライアント側で欲しいデータを絞れる ◦ 以前開発したiOS向けサービスと要件がほぼ一緒、ある程度流用可能 • BFF <ー> MicroService はgRPC (一部graphQL) ◦ HTTP/2で高速化 ◦ protoファイルによりIFの共有を強制
38. メンテナンス性 GKEでマイクロサービスアーキテクチャ 機能のマイクロサービス化 高いメンテナンス性の実現
39. 可用性
40. 課題解決へのアプローチ GKEの自動スケール設定 Multi Cluster IngressによるHA構成 可用性
41. 自動スケーリング • 施策によってはスパイクアクセスの可能性 • 事前の予測が無理 ※ 現在Production環境のチューニング中 CA、HPA設定を行う予定 拡張性のためにオートスケール設定が必須
42. Multi Cluster Ingress • マルチクラスタ(マルチリージョン)間のHTTP(S)負 荷分散するためのサービス • フリートに登録されているクラスタに対してトラ フィックをルーティング ◦ フリートは論理的にグループ化して管理するリソース ◦ 現時点でフリートメンバーになれるのは Kubernetesクラ スタのみ ◦ 本サービスは国内限定のサービスなので、東京リージョ ンクラスタと大阪リージョンクラスタを登録
43. Multi Clusterの導入目的 • 分離 ◦ 信頼性の向上、セキュリティの要件を満たすためサービスのコントロールプレーンとデータプレーン を分離する • ロケーション ◦ 可用性、レイテンシ、局所性のニーズに対応するため、特定のロケーションにサービスを配置する • スケーリング ◦ 特にKubernetesクラスタのコンテキストで、単一クラスタで生じる制限を超えるサービスのスケーリ ング cf. https://cloud.google.com/anthos/multicluster-management/use-cases
44. Multi Clusterの導入目的 • 分離 ◦ 信頼性の向上、セキュリティの要件を満たすためサービスのコントロールプレーンとデータプレーン を分離する • ロケーション ◦ 可用性、レイテンシ、局所性のニーズに対応するため、特定のロケーションにサービスを配置する • スケーリング ◦ 特にKubernetesクラスタのコンテキストで、単一クラスタで生じる制限を超えるサービスのスケーリ ング cf. https://cloud.google.com/anthos/multicluster-management/use-cases
45. Multi Cluster Ingressのメリット
46. Multi Cluster Ingressのメリット
47. Multi Cluster Ingressのメリット
48. Multi Cluster Ingressのメリット BCDR対策としてサービスを冗長化してくれる
49. 可用性 GKEのオートスケール設定 Multi Cluster IngressによるHA構成 可用性の担保と高可用性の実現
50. 運用改善
51. 解決へのアプローチ Operations Suiteの活用 Anthos Service Meshの導入 運用改善
52. Operations Suiteの活用 • Logging、Monitoringによるエラー検知と通知 ◦ 例えばResponse500やseverity:ERROR以上の発生など • Traceによるレイテンシ情報の集積
53. Anthos Service Meshの導入 • GCPが提供しているサービスメッシュ機能 • Istioベースのフルマネージドサービス • マイクロサービスアーキテクチャにおいて導入推奨（というかほぼ必須?） ◦ 可観測性、トラフィックコントロール、セキュリティなどを統合的に管理 Production環境で運用！
54. Anthos Service Meshによるサービス全体の可視化 • 可観測性 ◦ レイテンシ、リクエスト数、エラーレートの可視化
55. 運用改善 Operations Suiteの活用 Anthos Service Meshの導入 運用改善
56. まとめ
57. まとめ 課題 アプローチ メンテナンス性 GKEを利用してマイクロサービスアーキテクチャの構築 各機能をマイクロサービス化 可用性 GKEのオートスケール設定 Multi Cluster Ingressの導入 運用の改善 Operations Suiteの活用 Anthos Service Meshでサービス全体の可視化
58. まとめ モダナイゼーションへの期待 Developer Experienceの向上！ MISSION
 快適なユーザー体験をもたらし、最適な映像流通を皆と創る

59. ありがとうございました