2018-05-10

AWS Elemental MediaLive を使用したライブ動画配信アプリの基盤開発

AWS cookpadTV

技術部開発基盤グループの @ganmacs です。クッキング LIVE アプリ cookpadTV のライブ動画配信基盤(以下配信基盤)を AWS Elemental MediaLive を使用して開発した話を紹介します。

cookpadTV 上のライブ動画配信基盤の役割と機能

cookpadTV では配信基盤を使ってライブ動画機能を実現しています。 cookpadTV とは料理家や料理上手な有名人による料理番組のライブ配信を視聴できるアプリです。 Cookpad Tech Kitchen #15 や、すでにクックパッド開発者ブログに書かれた記事 ¹, ² を見るとどのようなアプリかをイメージがしやすいと思うのであわせてご覧ください。配信基盤は cookpadTV 用というよりも様々なサービスで使える共通基盤になっています。 cookpadTV と配信基盤との関係は以下の図のようになっています。

f:id:ganmacs:20180509160937p:plain

配信基盤の大きな機能として

ライブ動画を配信できるようにする機能
ライブ動画を保存しておき後から見られるようにする機能

があります。ライブ動画を配信するときの配信基盤の動きは次のようになります。配信基盤が番組の配信開始時間と終了時間を受け取って配信用 URL と購読用 URL を返します。配信用 URL とはライブ配信したい動画を配信する URL で、購読用 URL とは配信された動画を視聴できる URL のことです。配信プロトコルには RTMP を、購読には HLS をそれぞれ使用しています。配信基盤は受け取った配信時間と終了時間をもとにライブ動画を配信できるように準備をします。開始時間になると配信用 URL に対して動画のストリーミングが始まるので、配信基盤はその動画を様々な解像度にエンコードして配信しています。

ライブ動画を保存しておき後から見られるようにするために、ライブ動画を S3 に保存しておきます。その動画を社内の動画変換サービスを使用して HLS に変換することでライブ動画をあとから見られる形にしています。

設計方針

動画を受け取りエンコードしているサーバから視聴者に配信するのではなく、配信についてはすべて S3 のようなマネージドサービスに任せられるように設計しました。通常の動画配信の場合、コンテンツ全てを CDN で返してしまえばオリジンサーバへのアクセスをほぼ無くすことは可能です。しかし、HLS でライブ動画を配信するにはプレイリストを頻繁に更新する必要があるため長期間キャッシュできないエンドポイントが存在し、オリジンにも高頻度にアクセスされる可能性があります。そのような大量のアクセスに耐えられる必要があるため、ライブ動画やプレイリストを一度 S3 などにアップロードしてそこから配信できるように設計しました。こうすることで、急に大量のアクセスが来た場合にも配信サービスのスケールをマネージドサービスに任せられるので運用が非常に楽になります。

採用理由

配信基盤で AWS Elemental MediaLive(以下 MediaLive) を使用してライブ動画配信を実現しています。 MediaLive を採用したのは、はじめに決めた設計方針を素直に実現できるからです。また、他にも以下の採用理由もあります。

マネージドサービスに任せられる部分は任せたい
S3 / AWS Elemental MediaStore(後述) とのインテグレーション
その他 AWS サービスとのインテグレーション

MediaLive は動画の配信先を AWS Elemental MediaPackage(以下 MediaPackage), AWS Elemental MediaStore (以下 MediaStore), S3 などから選べます。 MediaPackage は今回使用していないので紹介は割愛しますが、 MediaStore はメディア向けに最適化された S3 のようなもので、動画コンテンツをより効率よく配信可能です。デフォルトで S3 や MediaStore を使用した配信をサポートしていることで、他のアプリケーションを使用した場合に比べてシンプルな実装で要求を実現可能なのが採用の最大の理由です。また、MediaLive もマネージドサービスなので管理しているサーバのリソースを気にしなくていいこと、配信中のメトリクス³が Amazon CloudWatch(以下 CloudWatch) を使用して確認できることなども採用理由の一つです。

他の方法で実現不可能だったのか

MediaLive 以外にも、Wowza Streaming Engine(以下 Wowza) や nginx-rtmp-module などを使用することでライブ動画配信を実現するアプリケーションを作ることは可能です。実は配信基盤の開発当初は MediaLive はまだ発表されていなかったため Wowza で動画配信をしようと考えており、実際にプロトタイプを作っていました。しかし、Record HLS Packet and Upload to S3 each time. にあるように S3 へのアップロードは公式でサポートがされていないことや、その他アプリケーションを自分で管理しなくてはいけないことなどもあり、MediaLive を使用したアプリケーションに作り直しました。 MediaLive が発表された当初は、MediaLive についての記事などはほとんどなく知見が溜まっていないという欠点もありましたがドキュメントがしっかりと書かれていたので特に困りませんでした。

最終的なアーキテクチャ

配信基盤の大まかな役割として、ライブ動画を流すこと、そのアーカイブ動画を後から見れるようにとっておくことがあります。それぞれについて最終的にどのように実現したかについて説明します。以下がアーキテクチャの概要図になります。

f:id:ganmacs:20180509161423p:plain

配信基盤は配信の準備のために、開始時間より少し前に MediaLive を放送可能状態に変更したり、放送開始/終了検知をするために CloudWatch のアラームを設定したりします。これらはバッチ処理によって行われています。余談ですが配信が開始されたか/終了したかを取得する API が MediaLive には存在しません。配信基盤では開始は S3 Event を、終了は CloudWatch を使用して、それぞれの情報を元に配信検知用のデーモンを起動しておき放送開始/終了を検知しています。開始時間になると配信用 URL に RTMP で動画が流れてくるので MediaLive が受け取り、設定した解像度に変換して MediaStore にアップロードします。そして MediaStore をオリジンサーバとして CDN を経由して視聴者まで配信するようにしています。

アーカイブ動画は MediaLive の Archive Output Group を使用して、S3 にアップロードしておき、それを配信可能な形に変換して配信しています。ライブ配信の終了時間になると、バッチ処理で S3 に保存されている動画をすべて集めてきて社内の動画変換サービスで変換して、アーカイブ動画として使用しています。アーカイブ動画もライブ動画と同様に S3 をオリジンサーバとして CDN を経由して視聴者に配信されるようになっています。

まとめ

cookpadTV のライブ動画配信基盤の機能と、開発するうえで気をつけたことを紹介しました。クックパッドでは AWS を利用して新たなサービスを作り出していける仲間を募集しています。

http://techlife.cookpad.com/entry/2018/04/12/180000 ↩
http://techlife.cookpad.com/entry/2018/04/26/214500 ↩
NetworkIn や NetworkOut などの配信されたバイト数など↩

2018-05-09

総合職・デザイナー向け技術基礎研修 2018

こんにちは、技術部の長（@s_osa_）です。

先日、新卒の総合職・デザイナー向けに技術基礎研修を行ないました。そこで研修をするにあたってどのようなことを考えて何をしたか、担当者の視点から書いてみようと思います。

なぜやるのか

研修を担当することになったとき、はじめに「なぜやるのか」「この研修の目的は何なのか」を考え直してみました。ぼんやりとした「技術についても少しは知っておいてほしい」という気持ちはありましたが、研修内容を考えるにあたって目的を明確にする必要がありました。

研修を受けてもらうのは総合職・デザイナーの人たちです。エンジニアに対して技術研修があるのは自然ですが、技術職ではない人たちに技術研修を受けてもらうのには然るべき理由があるはずです。

理由の言語化を試みたところ、「研修を受ける人たちは技術職ではないが、テクノロジーカンパニーの一員であることに変わりはない」というところに思い当たりました。本人が技術職であるか否かにかかわらず、我々のサービスは様々な技術によって支えられていますし、日々の仕事も様々な技術なしには成り立ちません。

そこで「テクノロジーカンパニーの一員として、日頃使っている技術や今後触れるであろう技術を知り、活かしていけるようになる」を大きな目的に設定しました。

目的

上記の目的だとまだ少しぼんやりしているので、使っている技術や将来使う技術についてブレークダウンして以下の3つを目的として置きました。

クックパッドがどのように動いているか理解する
適切なツールを用いてコミュニケーションや情報共有できるようになる
データを元に物事を考えるためのスキルを身につける

社内では「データ分析からUI改善」や「ディレクターがSQLを使えてよかった話」などのように、ディレクターやデザイナーがデータ分析をしてその結果を各種ツールを使って共有・議論しつつサービスを開発していくということが一般的になっており、その実態を反映した内容になっています。

指標

目的をもとに、研修後に受講者がどうなっていてほしいかという指標を考えます。

クックパッドがどのように動いているかイメージできる
社内で使われているツールでスムーズにコミュニケーションができる
- Groupad（Wiki+Blog のような社内ツール）や GHE（GitHub Enterprise）など
コミュニケーションや情報共有を行なう際に目的に応じて適切な方法を選択することができる
SQL を使用して簡単なデータを取得できる*1

これらの指標は定性的で厳密な評価などは難しいのですが、それでも指標を言語化しておく価値はあります。構成を考えたり資料をつくったりする途中で「何を伝えるべきだろうか」「この内容は必要だろうか」といったことを考える機会が数えきれないほどあるのですが、そのときは指標と目的に立ち返って考えることになります。

内容

本研修に割り振られた日数は3日間・各日7時間*2で計21時間程度でした。内容の分量なども考慮して検討した結果、3つある目的それぞれに1日ずつ割り振ることにしました。

各日の簡単な内容は以下のようなものです。なお、昨年まではプログラミング研修が含まれていましたが、昨年以前のフィードバックを参考にしつつ限られた時間の中での優先順位を検討した結果、泣く泣く今年の内容からは削ることにしました。

1日目「クックパッドを支える仕組み」

クックパッドを例にとりつつ、日頃何気なく使っている「インターネット」はどのように動いているかについて、「クライアントとサーバがネットワーク越しに通信している」ということを軸に以下のようなトピックについて話しました。

コンピュータ
クライアント
サーバ
リクエストとレスポンス
ネットワーク
社内のエンジニア
セキュリティ

この日に使った資料は本エントリの最後に公開・紹介します。

2日目「コミュニケーションと情報共有」

前述の Groupad や GHE で使われる Markdown の書き方について説明した上で実習した後、自己紹介を題材にして、実際に GHE の Web 画面を使って様々な操作を行なってみました（issue を立てる、PR を送る、レビューしてマージするなど）。

f:id:s_osa:20180502184359p:plain

また、社内ではコミュニケーションや情報共有のために他にも様々なツール（Slack、メール、Google Drive など）を使っているので、それぞれの特徴や使い分けるための考え方などについて話しました。

3日目「データ分析の第一歩」

日常的に行われているデータ分析の例を示した後、ハンズオン形式で実際のデータ（DWH）を触りながら SQL について学んでもらいました。 SQL の実行には社内でも広く使われている Bdash という BI ツールを使用し、適宜グラフなども描きながら進めていきました。

f:id:s_osa:20180502183205p:plain

分析が目的なので内容を select 文に絞り、select, from, where から始めて group by, having, join などひと通りの句について説明しつつ、実際にクエリを書いてもらって答え合わせをしながら進めました。

ただし、次の日から SQL をガリガリ書いてもらいたいというわけではなく、基本的なクエリを通して SQL の強力さを体感してもらい、将来必要になったときに「SQL を書く」という選択肢が視野に入るようにしてもらうにするのが主目的でした。

大切にしたこと

構成を考えたり資料をつくったりする際には、いくつかのことを常に頭に置きながら進めていました。

頭の中に地図をつくる

3日間という限られた時間の中で覚えられることには限界があります。

そこで、隅々まで覚えてもらうことはあきらめて、全体像を掴んでもらうとともに将来何かあったときに「これ研修でやったやつだ！」となってもらえるようにすることに集中しました。

また、新しく知ることをただ丸暗記するのではなく、知ったことの関係性を掴みながら頭の中に地図をつくってもらうために以下のようなことを意識していました。

全体から細部へ

繰り返しになりますが、研修を受ける人たちには全体像を掴んでほしいのであって、隅々まで知ってほしいわけではありません。

そこで、全体像をイメージできるようになってもらうことを優先するために、必要に応じて（できるだけ嘘にならない範囲で）細部を捨てて説明しました。細部の説明が必要な場合にも、一度全体を説明して全体像を掴んでもらってから細部に立ち入るようにしました。

身近なところから裏側へ

普段使っている例やこれから使う機会など、できるだけ受講者が身近に感じられるユーザー目線から話を始めて、必要に応じて裏側の仕組みなどを説明しました。

既存の知識と結びつける

新しい知識を単体で覚えるのは難しいので、具体例として普段使っているアプリの例を出したり、それまでの研修でやった内容と関連付けたりと、受講者が持っている既存の知識と結びつけながら話しました。受講者が自身の知識をもとに具体例を使って質問してくれたときは最高のチャンスなので、そのような質問には必ず具体例を活かしながら答えるようにしました。

実物を見せる

概念だけを説明されて理解するのは難しいので、ネットワーク機器やサーバールームを見てもらう、開発者ツールを使って実際の HTML や CSS を覗いてみてもらうなど、可能な限り実物を見てもらうことによって少しでもイメージしやすくなるようにしました。

手を動かして身につける

最終的に手を動かして使う類のスキルは知ることよりも使えるようになることが重要なので、実際に身につくように手を動かす時間を多く取るようにしました。

寄り道も大切にする

先述の通り、全体的には細部にはあまり触れないようにしましたが、何かを学ぶ上で知的好奇心は非常に重要です。そこで、受講者が質問をしてくれたり興味を持ってくれた点については、適宜、細部や背景も含めて説明しました。

結果

研修後、受講者に対して各指標についてどの程度達成できたかというアンケートを5段階で取ったところ、全体を通した平均が4.44という数値になりました。この数値自体には大した意味はないのですが、感想なども含めて概ね良い研修だったとのフィードバックをいただいています。

この研修にどれだけの価値があったのかは、配属後に実際に仕事をしていく中でわかっていくものだと思います。

今回の研修が少しでも役に立つことを願いつつ、実務に入ってからのフィードバックを含めて来年の研修に活かしていきたいと考えています。

資料

2日目および3日目の資料については社内固有の情報が多く含まれているため公開が難しいのですが、1日目の資料については一般的な情報なので公開しておきます。

研修では目の前の受講者に最適化するために、口頭での例示や補足、ホワイトボードを使って図示しながらの説明などを多用しましたが、スライドから概要や雰囲気だけでも感じていただければ嬉しいです。

*1:データ分析を行なうためには SQL の知識だけではなく、取得したデータをどう扱うかという知識が必要不可欠ですが、本研修のあとに統計研修が控えていたため本研修ではデータの取得に的を絞っています。

*2:就業時間は8時間ですが、朝夕に振り返りなどの時間が毎日1時間設定されていました。

2018-05-08

Service Mesh and Cookpad

こんにちは、開発基盤の Taiki です。今回は、マイクロサービスで必須のコンポーネントとなりつつあるサービスメッシュについて、クックパッドで構築・運用して得られた知見についてご紹介できればと思います。

サービスメッシュそのものについては以下の記事や発表、チュートリアルで全体感をつかめると思います:

目的

クックパッドでは主に障害対応やキャパシティプランニング、Fault Isolation に関わる設定値の管理といった、運用面での課題を解決すべくサービスメッシュを導入しました。具体的には:

サービス群の管理コストの削減
Observability*1 *2の向上
より良い Fault Isolation 機構の構築

1つ目については、どのサービスとどのサービスが通信していて、あるサービスの障害がどこに伝播するのか、ということを規模の拡大とともに把握しづらくなってるという問題がありました。どことどこが繋がっているかの情報を一元管理することでこの問題は解決できるはず、と考えました。

2つ目については (1) をさらに掘ったもので、あるサービスと別のサービスの通信の状況がわからないという課題でした。例えば RPS やレスポンスタイム、成功・失敗ステータスの数、タイムアウトやサーキットブレーカーの発動状況などなど。あるバックエンドサービスを2つ以上のサービスが参照しているケースでは、アクセス元のサービス毎のメトリクスではないため、バックエンドサービス側のプロキシーやロードバランサーのメトリクスでは解像度が不十分でした。

3つ目については、「Fault Isolation がうまく設定できていない」という課題でした。当時はそれぞれのアプリケーションでライブラリを利用して、タイムアウト・リトライ・サーキットブレーカーの設定を行っていましたが、どんな設定になっているかはアプリケーションコードを別個に見る必要があり、一覧性がなく状況把握や改善がしづらい状況でした。また Fault Isolation に関する設定は継続的に改善していくものなので、テスト可能であったほうが良く、そのような基盤を求めていました。

さらにもっと進んだ課題解決として、gRPC インフラの構築、分散トレーシング周りの処理の委譲、トラフィックコントロールによるデプロイ手法の多様化、認証認可ゲートウェイなどのような機能もスコープに入れて構築しています。このあたりについては後述します。

現状

クックパッドでのサービスメッシュは data-plane として Envoy を採用し、control-plane は自作、という構成を選択をしました。すでにサービスメッシュとして実装されている Istio を導入することも当初は検討したのですが、クックパッドではほぼ全てのアプリケーションが AWS の ECS というコンテナ管理サービスの上で動作している関係上 Kubernetes との連携メリットが得られないことと、当初実現したいことと Istio のソフトウェア自体の複雑さを考慮して、小さく始められる自作 control-plane という道を選びました。

今回実装したサービスメッシュの control-plane 部分はいくつかのコンポーネントによって構成されています。各コンポーネントの役割と動作の流れを説明します:

サービスメッシュの設定を中央管理するリポジトリ
kumonos*3 という gem を用いて上記の設定ファイルから Envoy xDS API*4 用のレスポンス JSON を生成
生成したレスポンス JSON を Amazon S3 上に配置して Envoy から xDS API として利用する

中央のリポジトリで設定を管理している理由は、

変更履歴を理由付きで管理して後から追えるようにしておきたい
設定の変更を SRE 等の組織横断的なチームもレビューできるようにしておきたい

という2点です。

ロードバランシングについては、基本的には Internal ELB に任せるという方式で設計したのですが、gRPC アプリケーション用のインフラ整備も途中から要件に入った*5ので、SDS (Service Discovery Service) API を用意して client-side load balancing できるようにしています*6。app コンテナに対するヘルスチェックを行い SDS API に接続先情報を登録する side-car コンテナを ECS タスク内にデプロイしています。

f:id:aladhi:20180501141121p:plain

メトリクス周りは次のように構成しています:

メトリクスは全て Prometheus に保存する
dog_statsd sink*7 を使用してタグ付きメトリクスを ECS コンテナホスト(EC2 インスタンス)上の statsd_exporter*8 に送信
- 固定タグ設定*9を利用してノード区別のためにアプリケーション名をタグに含めています
Prometheus からは EC2 SD*10 を利用して statsd_exporter のメトリクスを pull
- ポート管理のために exporter_proxy*11 を間に置いています
Grafana、Vizceral*12 で可視化

ECS, Docker を利用せずに EC2 インスタンス上で直接アプリケーションプロセス動かしている場合は、Envoy プロセスも直接インスタンス内のデーモンとして動かしていますが、構成としてはほぼ同じです。直接 Prometheus から Envoy に対して pull を設定していないのは理由があり、まだ Envoy の Prometheus 互換エンドポイントからは histogram メトリクスを引き出せないからです*13。これは今後改善される予定なのでその時は stasd_exporter を廃止する予定です。

f:id:aladhi:20180502132413p:plain

Grafana 上ではサービス毎に各 upstream の RPS やタイムアウト発生等の状況が見れるダッシュボードと Envoy 全体のダッシュボードを用意しています。サービス×サービスの粒度のダッシュボードも用意する予定です。

サービス毎のダッシュボード

f:id:aladhi:20180501175232p:plain

Upstream 障害時のサーキットブレーカー関連のメトリクス

f:id:aladhi:20180502144146p:plain

Envoy 全体のダッシュボード

f:id:aladhi:20180501175222p:plain

サービス構成は Netflix が開発している Vizceral を利用して可視化しています。実装には promviz*14 と promviz-front*15 を fork して開発したのもの*16を利用しています。まだ一部のサービスにのみ導入しているので現在表示されているノード数は少なめですが、次のようなダッシュボードが見れるようにしています:

リージョン毎のサービス構成図と RPS、エラーレート

f:id:aladhi:20180501175213p:plain

特定のサービスの downstream/upstream

f:id:aladhi:20180501175217p:plain

またサービスメッシュのサブシステムとして、開発者の手元から staging 環境の gRPC サーバーアプリケーションにアクセスするためのゲートウェイをデプロイしています*17。これは hako-console という社内のアプリケーションを管理しているソフトウェア*18と SDS API と Envoy を組み合わせて構築しています。

Gateway app (Envoy) が gateway controller に xDS API リクエストを送る
Gateway controller は hako-console から staging 環境かつ gRPC アプリケーションの一覧を取得して、それを基に Route Discovery Service/Cluster Discovery Service API レスポンスを返す
Gateway app はレスポンスを基に SDS API から実際の接続先を取得する
開発者の手元からは AWS ELB の Network Load Balancer を参照し Gateway app がルーティングを行う

f:id:aladhi:20180502132905p:plain

効果

サービスメッシュの導入で最も顕著だったのが一時的な障害の影響を抑えることができた点です。トラフィックの多いサービス同士の連携部分が複数あり、今までそれらでは1時間に5,6件ほどのネットワーク起因の trivial なエラーが恒常的に発生していた*19のですが、それらがサービスメッシュによる適切なリトライ設定によって1週間に1件出るか出ないか程度に下がりました。

モニタリングの面では様々なメトリクスが見れるようになってきましたが、一部のサービスのみに導入していることと導入から日が浅く本格的な活用には至ってないので今後の活用を期待しています。管理の面では、サービス同士の繋がりが可視化されると大変わかりやすくなったので、全サービスへ導入することで見落としや考慮漏れを防いでいきたいと考えています。

今後の展開

v2 API への移行、Istio への移行

設計当初の状況と、S3 を配信バックエンドに使いたいという要求から xDS API は v1 を使用してきましたが、v1 API は非推奨になっているのでこれを v2 へ移行する予定です。同時に control-plane を Istio へ移行することも検討しています。また、仮に control-plane を自作するとしたら、今のところの考えでは go-control-plane*20 を使用して LSD/RDS/CDS/EDS API*21 を作成することになると思います。

Reverse proxy の置き換え

今までクックパッドでは reverse proxy として NGINX を活用してきましたが、内部実装の知識の差や gRPC 対応、取得メトリクスの豊富さを考慮して reverse proxy や edge proxy を NGINX から Envoy に置き換えることを検討しています。

トラフィックコントロール

Client-side load balancing への置き換えと reverse proxy の置き換えを達成すると、Envoy を操作してトラフィックを自在に変更できるようになるので、canary deployment や traffic shifting、request shadowing を実現できるようになる予定です。