はじめに
TVerのSREチームでインフラ周りやサービス監視オブザーバビリティーを担当しています西尾です。 この度はサービスとしての認知が広まり、配信プラットフォームとしての社会的な重要性も高まってきたTVerサービスについて運用面からの取り組みを紹介していきたいと思います。 現在Tverに関しては、多くのユーザーから視聴していただいていますが、サービス提供に関するステークホルダーとしてはこの視聴されていますユーザー以外にも、配信を行うコンテンツを制作提供している各放送局の方々も含まれ、サービスとしてはBtoC/BtoBの両方の性質をもっています。 そのため、サービスの安定稼動についてはこれからもっと多くのユーザーに必要とされ、また信頼できる動画配信プラトフォーム業者として各放送局の方々から選ばれるように高いレベルで求められています。 安定稼働の取り組みとしては各チームで様々な施策を行なっていますが、SREチームとしてどのような事を行い、どのような姿を目指しているかを書いていきたいと思います。
動画配信サービスの構成
TVerのサービスに関しては、このサービスを提供するにあたって様々なコンポーネントで構成されています。 ここでは個々の領域に踏み込むと説明が長くなってしまうので割愛し、一般的に使われているサービス名を利用しながら紹介したいと思います。 まずTVerのサービスに関しては大部分がAWS上で稼働しています、一部のコンポーネントに関してはGCP上でも動いていますが、これはサービス（サービスを構成する個々のコンポーネント）やデータ特性などにより各種パブリッククラウドの事業者のサービスを使い分けているのでこのような構成となっています。 動画配信の部分を除けば、一般的なAPI構成で使われているAWSサービスを利用して構築されていますので、その部分はイメージがつきやすいと思います。 パブリッククラウドのサービス以外の部分ですと、CDNではJOCDNを、動画配信のメディアに関してはPLAY社のSTREAKSなどを利用しています。
CMSに関しては、TVerで配信を行なっているコンテンツを登録するために専用の画面を作ってそこで配信素材を管理しています。
運用面
SREチームが関わる非機能要件部分の運用業務としては、CI/CD周りやインフラのスケーリングなどが存在します。 CI/CD周りに関してはGitHub Actionsでコードが含まれるイメージをbuildして、それにタグ付けを行なってからECRにイメージをpushしています。 そしてそのイメージがpushされたのをトリガーとして、ECS上のサービスが更新されるようになっています。 デプロイの更新に関しては、通常はローリングアップデートを行なっていますが、重要な更新を含むリリースの場合はカナリアリリースを行うようにしています。 カナリアリリースに関しては、カナリアリリース用のECSサービスが別途稼働していますので、そのターゲットグループに対して流すトラフィックのウェイトをALB側で設定しています。 カナリアリリース後問題なければ、本番稼働していますECSサービスに全てのトラフィックを流してリリースが完了となります。 ECSサービスでカナリアリリースする場合、いくつかの方法がありますが、当初はブルーグリーン・デプロイメントも利用することができるデプロイ方式のAWS CodeDeployを検討しました。 ただこれに関してはサービスの再作成が必要になり導入の際にダウンタイムを無くす場合の準備と検証に時間がとれなかったので見送りになりました。
しかし将来的にはリリース時のサービス影響を極力無くすために、今後ブルーグリーン・デプロイメントの採用はどこかの時点でやっていきたいと思っています。
インフラ周りのスケーリングに関しては、過去の記事で取り上げていますがOmniscientという独自のシステムを利用して行なっています。 このシステムではECSサービスのタスク数やリソース、RDSのレプリカ数などをGUI上のコンソールで指定することがで、その指定した内容で最終的にはCloudFormationを通して実際の変更が行われています。 事前に具体的なスケーリング内容を設定してテンプレートを準備しておく事が出来るので、スケーリングすべき日時にそのテンプレートを適用するだけでインフラのスケーリング作業を完了する事ができます。 実際のスケーリングをどのタイミングで行うかですが、例えば多くのユーザーに注目されるコンテンツ配信については事前にどれくらいユーザーが流入するか過去の経験や別チームから提供される情報で対象を特定する事が可能ですので、そのコンテンツの配信可能となる時間に合わせて行われています。
イメージ
- XX月XX日 21:00
サッカー日本対XXX ユーザー想定同接数 XX万人 → x10倍テンプレート利用
監視面
サービスを安定稼働させるには欠かせないのが監視、最近では予防的な措置を含めて観測するオブザーバビリティーとしてシステムの安定稼働に必要な要素として再定義されています。 TVerサービスとしては、原則はNew Relicにデータを送りそこでアラート設定も含めてメトリクス、ログの監視を行なっています。 New Relicにデータを送る方法ですが、現在稼働するサービスが複数のAWSアカウントやサービスに跨っていますので下記の通り複数経路が存在します。
APM
・コード上にAPMエージェントを組み込み、New Relicに直接送信
インフラ面
- メトリクス
・ コンテナのサイドカーとしてinfra agent組み込んでNew Relicに送信
・ EC2についてはinfra agentを直接配置してNew Relicに送信
- ログ
・ コンテナのサイドカーとしてFireLensを組み込み、New Relicに直接送信 (＊FireLensでS3、CloudWatch Logs、New Relicにカスタムルーティングを行なっている)
・ EC2に関してはfluentを利用してCloudWatch Logsにエラーログのみ転送し、トリガーとしてlambdaを設定しNew Relicに送信
・ ALBのログなどAWS固有のサービスログに関しては、S3に保存し、その後Athenaを利用して集計しlambda経由でNew Relicに送信
監視アラートに関しては、設定できるポイントはいくつかありますが一元的にアラート管理を行いたいのでアラート設定を行う必要のあるメトリクスやログはNew Relicに流してそこで設定するようにしています。 New Relicに関してはAPM機能を利用するために、バックエンド、フロントエンド、ネイティブアプリにエージェントのインストールを行なっていますが、Androidアプリに関してはFirebaseやGoogle Play Consoleで補完しているものもあります。
通知アラート
アラートの閾値、通知設計は的確にサービスの問題を検知し対応するためにサービスの安定提供に重要な要素になります。 当初はあまり通知先や閾値設計ができてなかったので、どこに何のアラートが飛んでるかわからず、またこのアラートがどの程度のサービスインパクトがあるか把握しにくい部分がありました。 そのため、現在はサービスインパクト別にセベリティで分けた通知先を準備し、アラートの閾値は現在まで蓄積されたメトリクスを利用し障害時の状況から逆算的に設定できるように取り組んでいます。 まだこれに関しては、進行中の作業になりますが設定が終わる頃には以前よりは問題把握のスピードアップができエスカレショーンフローもスムーズになると信じています。
SLA/SLO
TVerでは特に現在のところSLA/SLOを公表していませんが、必要性を理解していますのでまずは内部的な指標としてその準備を現在進めています。 New Relicにデータを一元的に集めることで、エンドポイント監視、ログ監視、Syntheticモニター機能を利用して全体的なサービス、個々の機能の広く見渡せるよう定義していく予定です。 現在までにこの作業で実施している取り組みに関しては、下記のようなものがあります。
- New Relic Synthetics scripted browserを利用して実際のユーザー体験を考慮した(CUJ)監視計測
- スパイク時、障害時のメトリクスデーターの蓄積を行い問題発生時に注視すべき対象を特定
- 遅延などデグラデーションも認識できるようにポイント、コンポーネントごとの指標の定義
- WEB、アプリ、コネクテッドTVなど複数のデバイスで視聴されるので、デバイス固有の問題を特定できる指標の定義
これらはのデータはすぐに揃えることが難しくなかなかSLA/SLOの着手ができなかったので時間を要しましたが、各サービスの開発担当者と協力しながらある程度形になるものは出来ようとしてます。
目指すべき姿
残念ながら今年に入ってもTVerサービスでは一時的な接続障害を発生させてしまっています。 起因となる理由は複数ありますが、本来SREとしてカバーしていれば防げたところもありました。 特に挙げられるものとしては、TVer独特の事象としまして地上波放送からの流入により一時的に急激な流入でインフラのスケールが追いつかずにトラフィックを捌けない事があります。 前もってわかるような同接数であれば、事前にスケールする事が可能ですが、スポーツなどのリアルタイム配信に関しては試合展開によっては地上波放送時間内に収まらずにTVerに誘導される事があるかと思いますがこれがあたります。 ECS構成は管理しやすく運用も比較的に楽ではありますが、ユーザー数の増加やサービスの重要性を考えるとこのスケールが間に合わない問題に対して抜本的なインフラ構成のリファクタリングを考える時期にきていると思っています。 合わせて開発側のCI/CD周りの利便性やリリース方式の検討もできれば、今までボトルネックになっている問題に対しても解決策を提示できるのではないかと思います。
まとめ
サービスを安定稼働するためにSREとして関わることが出来る業務として複数あります。
- 各サービス開発者に対して、適切な指標の提供
- サービスの問題を素早く検知しエスカレーションが出来る体制の整備
- 運用管理しやすいインフラ構成の提供
- SLA/SLOを整備することにより、サービス関係者に現在のシステム状態の周知
これらの事はどれも重要ですので全て進めていきたいですが、時間も人も有限なので現状は優先順位をつけて取り組んでいる状況です。 そのためTVerサービスを支えていただける方(SRE業務)を幅広く求めています。 サービスとしては非常に社会的に求められるサービスであり、大規模なトラフィックを捌ける業務となりますのでやりがいはあるかと思います。
