老舗VODプラットフォームのモダナイゼーションへの挑戦

by abe

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Introduction

Slide 3

Slide 3 text

自己紹介山本　一貴バックエンドエンジニア videomarketサービスの基盤を統括好きなGCPプロダクトは Cloud Logging 阿部　祐二バックエンドエンジニア videomarketサービスのテックリード好きなGCPプロダクトは Cloud Run

Slide 4

Slide 4 text

会社紹介株式会社ビデオマーケットガラケー時代からTVOD（都度課金）を軸とした動画配信サービスを提供映画、アニメ、ドラマなど多彩なジャンルで配信本数は国内最大の 24 万本以上自社が開発した独自なエンコード方式で高品質な動画を提供 MISSION  快適なユーザー体験をもたらし、最適な映像流通を皆と創る 

Slide 5

Slide 5 text

サービス紹介 ● サービス事業 ○ ビデオマーケット ■ 配信本数は国内最大の 24 万本以上の動画配信サービス ■ 有料会員には毎月50作品レンタル可能なクーポンを配布中 ○ ミレール ■ D2C型の都度課金型動画配信サービス ● プラットフォーム事業 ○ music.jp、GYAOストア、DMM動画への配信システムを提供

Slide 6

Slide 6 text

agenda

Slide 7

Slide 7 text

本日はなすこと ● 弊社の動画配信はガラケー時代から続いているサービスであり、歴史を重ねる中でレガシーと化した部分が多数存在する。 ● こちらをどのような技術を使用してモダナイゼーションしようとしているか？

Slide 8

Slide 8 text

現状 ● ガラケーの仕様を踏襲しレガシー化したシステム ○ レガシー化の原因→時代の流れに対応する速度重視の開発 ■ 対応デバイスを増加させてきた ● 都度、別のWEBアプリケーションとして作成されるためバックエンドが肥大化 ● 別々のため機能追加にデバイス種別分工数がかかり非効率的 ■ 保守性の低さ ● ライブラリ等バージョン管理難しい状態で作成され、既に手が入れづらい状況 ● メンテナンスやバージョンアップすることが考慮されていない ● 指標が収集しづらく、改善点が見つけづらい

Slide 9

Slide 9 text

対応デバイスの歴史 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発売

Slide 10

Slide 10 text

課題 ● メンテナンス性 ● 可用性

Slide 11

Slide 11 text

メンテナンス性

Slide 12

Slide 12 text

現状 ● ビジネススピードに合わせてローンチを重ねた結果、メンテナンス性が薄れていった

Slide 13

Slide 13 text

同じ機能が分散されている ● 機能が共通化されていない ○ 図のようにAデバイス用機能のコピーからBデバイス用が作成され、Bを元にさらにC用が作成... ○ ほぼ同じ機能が全て独自に改修されていた A B C コピーコピーコピー

Slide 14

Slide 14 text

課題 ● 全デバイスに共通の機能を追加する場合において、全デバイスに同じ改修が必要 ● コピーが元になるため、不要な機能も踏襲されている ● 影響範囲の調査が困難なため、削除に工数がかかる ● 各デバイスで独自に改修された結果、データの捉え方がデバイスごとに異なりテストが困難モノリスでの限界→マイクロサービスへ

Slide 15

Slide 15 text

これを：’という共通機能を追加する場合 A A’ B’ B C C’ 共通機能を追加した場合、全てのデバイスに改修が必要＝３倍工数がかかる！！改修改修改修

Slide 16

Slide 16 text

こうしたい：’という共通を追加する場合 A B C 機能D 機能E 機能F A B C 機能D 機能E’ 機能F サービスをデバイスごとではなく、機能ごとへ Eの改修のみ！

Slide 17

Slide 17 text

可用性

Slide 18

Slide 18 text

可用性 ● 現状 ○ 仮想環境で常に最大数を想定してサービスが動いている ○ 各々で監視設定が必要 ○ ライブラリの更新、セキュリティパッチの適用が必要

Slide 19

Slide 19 text

可用性 ● 課題 ○ 多くを手動で管理する必要がある ■ 想定以上のスパイクが発生した際のスケールアウト時にサーバーの増設や LBの設定が必要。スケールインも同様 ■ インフラチームの負担が多く新しいサービスを追加しずらい ○ アプリケーションログが分散、パフォーマンス管理ができていない →マネージドサービスを利用し、運用の可用性を高める

Slide 20

Slide 20 text

可用性：これをいつでも一定 L B スパイク時は手動で増設、設定が必要...

Slide 21

Slide 21 text

可用性：こうしたい ● 接続数が少ない時はリソースを少なく ● 接続が多い時は多く処理できるように L B L B

Slide 22

Slide 22 text

監視：これをこれはこれで見やすいが他の情報も監視できるように

Slide 23

Slide 23 text

監視：こうしたい https://cloud.google.com/trace/docs/quickstart?hl=ja#view_the_trace_overview

Slide 24

Slide 24 text

ビジネスの幅を広げるためモノリスからマイクロサービス化へ課題を解決し、既存の強み（配信本数、作品情報）を生かした、多くの人やサービスに利用してもらえるサービスへ！

Slide 25

Slide 25 text

現状の課題 ● メンテナンス性 ● 可用性 ● 運用の改善

Slide 26

Slide 26 text

現状の課題 ● メンテナンス性 ● 可用性 ● 運用の改善で解決しよう！

Slide 27

Slide 27 text

メンテナンス性

Slide 28

Slide 28 text

課題解決へのアプローチメンテナンス性の欠如、モノリスの限界 GKEを利用してマイクロサービスアーキテクチャへ

Slide 29

Slide 29 text

全体構成図

Slide 30

Slide 30 text

全体構成図

Slide 31

Slide 31 text

なぜKubernetes Engineを選択したのかコンテナ化したい ● 軽量、高速、ポータビリティ etc… ● パブリッククラウド✕コンテナコンテナオーケストレーションツール ● デファクトスタンダードの Kubenetes フルマネジードサービス Kubernetes Engine GCPでは自然な選択か

Slide 32

Slide 32 text

BFF ● 役割はフロントからのリクエストを集約するAPI Gateway ○ クライアント側はBFFに対してのみのリクエスト、バックエンドを意識しなくてよい ● 開発言語はGo ○ 技術スタックとしてフロントエンド技術が弱い ○ 知見を活かせる ○ Goのパフォーマンスを信頼

Slide 33

Slide 33 text

BFF ● ビジネスロジックの一部はMicroService側へ委譲 ● MicroService間での通信をある程度許容 API gatewayによるBFFの複雑化

Slide 34

Slide 34 text

BFF ● 開発規模・開発要員の大きさ ● 検証、仕様調整のためのmockサーバーをあらかじめ用意バックエンド側が担当することよりフロントエンドとのコミュニケーションが疎になる？

Slide 35

Slide 35 text

MicroService ● Backend API群 ● 開発言語はKotlin ○ 技術スタックとしての知見や利用実績 ● gRPCサーバー ○ .protoファイルは個々のリポジトリで管理 ● DBは既存サービスのものを使用

Slide 36

Slide 36 text

通信方式別の通信方式でOK!

Slide 37

Slide 37 text

通信方式 ● Client <ー> BFF はgraphQL ○ １リクエストで複数リソースにアクセス可能 ○ クライアント側で欲しいデータを絞れる ○ 以前開発したiOS向けサービスと要件がほぼ一緒、ある程度流用可能 ● BFF <ー> MicroService はgRPC (一部graphQL) ○ HTTP/2で高速化 ○ protoファイルによりIFの共有を強制

Slide 38

Slide 38 text

メンテナンス性 GKEでマイクロサービスアーキテクチャ機能のマイクロサービス化高いメンテナンス性の実現

Slide 39

Slide 39 text

可用性

Slide 40

Slide 40 text

課題解決へのアプローチ GKEの自動スケール設定 Multi Cluster IngressによるHA構成可用性

Slide 41

Slide 41 text

自動スケーリング ● 施策によってはスパイクアクセスの可能性 ● 事前の予測が無理 ※ 現在Production環境のチューニング中 CA、HPA設定を行う予定拡張性のためにオートスケール設定が必須

Slide 42

Slide 42 text

Multi Cluster Ingress ● マルチクラスタ(マルチリージョン)間のHTTP(S)負荷分散するためのサービス ● フリートに登録されているクラスタに対してトラフィックをルーティング ○ フリートは論理的にグループ化して管理するリソース ○ 現時点でフリートメンバーになれるのは Kubernetesクラスタのみ ○ 本サービスは国内限定のサービスなので、東京リージョンクラスタと大阪リージョンクラスタを登録

Slide 43

Slide 43 text

Multi Clusterの導入目的 ● 分離 ○ 信頼性の向上、セキュリティの要件を満たすためサービスのコントロールプレーンとデータプレーンを分離する ● ロケーション ○ 可用性、レイテンシ、局所性のニーズに対応するため、特定のロケーションにサービスを配置する ● スケーリング ○ 特にKubernetesクラスタのコンテキストで、単一クラスタで生じる制限を超えるサービスのスケーリング cf. https://cloud.google.com/anthos/multicluster-management/use-cases

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Multi Cluster Ingressのメリット

Slide 46

Slide 46 text

Multi Cluster Ingressのメリット

Slide 47

Slide 47 text

Multi Cluster Ingressのメリット

Slide 48

Slide 48 text

Multi Cluster Ingressのメリット BCDR対策としてサービスを冗長化してくれる

Slide 49

Slide 49 text

可用性 GKEのオートスケール設定 Multi Cluster IngressによるHA構成可用性の担保と高可用性の実現

Slide 50

Slide 50 text

運用改善

Slide 51

Slide 51 text

解決へのアプローチ Operations Suiteの活用 Anthos Service Meshの導入運用改善

Slide 52

Slide 52 text

Operations Suiteの活用 ● Logging、Monitoringによるエラー検知と通知 ○ 例えばResponse500やseverity:ERROR以上の発生など ● Traceによるレイテンシ情報の集積

Slide 53

Slide 53 text

Anthos Service Meshの導入 ● GCPが提供しているサービスメッシュ機能 ● Istioベースのフルマネージドサービス ● マイクロサービスアーキテクチャにおいて導入推奨（というかほぼ必須?） ○ 可観測性、トラフィックコントロール、セキュリティなどを統合的に管理 Production環境で運用！

Slide 54

Slide 54 text

Anthos Service Meshによるサービス全体の可視化 ● 可観測性 ○ レイテンシ、リクエスト数、エラーレートの可視化

Slide 55

Slide 55 text

運用改善 Operations Suiteの活用 Anthos Service Meshの導入運用改善

Slide 56

Slide 56 text

まとめ

Slide 57

Slide 57 text

まとめ課題アプローチメンテナンス性 GKEを利用してマイクロサービスアーキテクチャの構築各機能をマイクロサービス化可用性 GKEのオートスケール設定 Multi Cluster Ingressの導入運用の改善 Operations Suiteの活用 Anthos Service Meshでサービス全体の可視化

Slide 58

Slide 58 text

まとめモダナイゼーションへの期待 Developer Experienceの向上！ MISSION  快適なユーザー体験をもたらし、最適な映像流通を皆と創る 

Slide 59

Slide 59 text

ありがとうございました