S3が私のお気に入りのAWSサービスであることは周知の事実です。2006年に（SQSベータに次いで）2番目にローンチされたAWSサービスです。今日、S3は他の多くのAWSサービスとインターネットの大部分を支え、何百万ものドライブに4兆ものオブジェクトを保存しています。Momentoでは、S3がどのように構築されたか、そしてS3が果たす基礎的な役割からインスピレーションを得ています。

AWSの重要な設計哲学の1つは、ゴールと一緒に非ゴールを明示的にリストアップすることです。S3は、耐久性、コスト、持続的なスループットのために最適化されているため、非常に成功しています。しかし、これらの目標を非常にうまく最適化するには、テールレイテンシ、少し高いエラーレートに対する耐性、特定のプレフィックスに対する1秒あたりの最大リクエスト数など、非目標の形でトレードオフが必要です。

S3はほとんどの問題を解決するが、すべてを解決することはできない。ある次元で秀でるためには、別の次元を軽視しなければならない。

明らかに、これらのトレードオフは、S3が当初設計された目的には良い決定であったが、常に異なるトレードオフを必要とするユースケースが存在します。例えば、S3はOLTPデータベースとしては適していません。DynamoDBは、ストレージとスループットのギガバイトあたり少なくとも10倍のコストがかかるが、テールレイテンシとエラーレートが低いので、より良い選択です。

S3の上に構築できることはたくさんあるが、おそらく構築すべきではないでしょう。今日は、なぜライブイベント用のメディアオリジネーションがこのカテゴリーに当てはまるのかを掘り下げてみます。

ライブ・オリジン・サーバーとは何ですか？

ライブメディアオリジンは、ライブメディアストリームを構成するデータの基礎となるストレージシステムおよびサーバーです。通常、エンコーダーまたはパッケージャーとCDNの間に位置し、HTTPリクエストを介してオリジンと通信を行います。

HLS (HTTP ライブストリーム) ストリームでは、典型的なライブエンコーダは、ビデオとオーディオのセグメントをオリジンに常にプッシュし、マニフェストファイルを更新します。ライブイベントのセグメントサイズのゴールドスタンダードは ~2 秒で、様々なエンコーディングとビットレートで複数回再生されます。同時に、各CDN PoPは、視聴者のために次のセグメントをフェッチするためにオリジンを叩きまうｓ。このすべてが、読み取りと書き込みのレイテンシに高い感度を持つリアルタイム操作のファイアホースを作成します。

このパーフェクト・ストームは、数十ミリ秒（！）の小さな不具合でさえも、視聴者の体験を悪化させます。遅延が少しずつ増えるたびに、プレーヤーの短いデータ・バッファは削られていきます。ウェブブラウジングや分析ワークフローのような、より緩やかなシナリオとは異なり、ライブメディアにおけるエラーのマージンはカミソリのように薄いのです。

SLAの計算

S3の単一領域のエラー率SLAは99.9%、つまり1000リクエスト中1エラーという非常に立派なものです。しかし、サッカーワールドカップのようなライブイベントの間、ビデオマニフェストとセグメントファイルは何万回も更新されるので、何十回もの書き込みエラーが予想されます。読み取りエラーを見積もるには、100倍を計算します。

現在、各エラーによって再試行が行われ、おそらく成功するが、再試行やタイムアウトなどによって数百ミリ秒の遅延が発生します。この遅延はCDNを通じて伝播し、何万、何十万というプレーヤーが必死に最新のセグメントをフェッチしようとしているところに影響を与えます。このような遅延が蓄積され、プレーヤーがストリームデータに飢えるようになると、恐ろしい「バッファリング」が発生します。☠️

ハンマーしかないときは…

先に述べたように、S3は耐久性、コスト、持続的なスループットを追求するため、意図的なトレードオフを行っています。これらはライブ・ストリーミングにとって最も重要な次元ではないが、視聴者の体験に影響を与える次元を犠牲にしています。

ライブ・ストリーミングの要件に照らし合わせて、S3の基本性能を評価：

１．耐久性 – 4時間のライブ・イベントで年間9点満点が11回、9点満点が14回。SLAが9の3つしかないリアルタイム・アプリケーションにとって、本当に意味があるのでしょうか？

２．コスト – GBあたりの価格は、コンテンツの持続可能な長期保存にとって極めて重要である。しかし、「ライブ」データは必然的に直近のN時間にサイズが制限されます。

３．持続的なスループット – スループットは重要だが、S3は多くの小さなオブジェクトで構成されるライブストリームには不適切なスループットです。本当に重要なのはリクエストスループットです。

では、上記の次元がライブ・メディアのオリジンにとってそれほど重要でないとすれば、どのような次元が重要なのだろうか？知っていることから逆算してみよう：

１．Time-to-first-byte – ライブ・ストリームは多数の小さなオブジェクトで構成されているため、総スループットはTime-To-First-Byte（TTFB）と密接な相関関係があります。
２．ゼロに近いエラー・レート – 低いエラー・レートは、再試行によるレイテンシの壊滅的な影響を避けるために極めて重要です。ライブ・オリジンでは、少なくとも5 9sのエラー率SLAが必要です。
３．タイトなテールレイテンシー – 99.99%のレイテンシーは、CDNを通じてプレイヤーにレイテンシーが蓄積され、増幅されるため重要です。各プレーヤーが次のデータセグメントを正常に取得できる時間は2秒未満です！
４．ホット・シャーディングの緩和 – 同じような名前のキーに対して一貫したパフォーマンスを実現することは、馬鹿げたことのように聞こえます。最大手の放送局では、イベントの前にS3バケットを事前にシャーディングするチケットを提出しています！

S3は素晴らしく、基盤となるストレージサービスだが、ライブストリーミングのシナリオには明らかにミスマッチです。はっきり言って、それはS3の問題ではありません。私たちがネジではなく釘にハンマーを使うように、S3はそれが最も得意とする多くのことに使うべきです。

より良いライブの原点を築く

理想的なライブ・オリジンは、TTFB、低エラー・レート、タイト・テール・レイテンシー、ホット・シャードを最適化する必要があることがわかっています。よく知られたクラウドコンポーネントが、インメモリーキャッシュという、ほぼまさにこれを実現しています！

もちろん、完璧にフィットするわけではありません。RedisやElasticacheクラスタをスピンアップするだけなら、クラスタ・キャパシティの管理、シャーディングやフェイルオーバーの設定、アクセス制御やホットキー緩和のような機能の構築、HTTPリクエストを処理するためのゲートウェイやLambda関数の配線など、S3と比較して運用の複雑さにがっかりするでしょう。最後に、最も重要なことだが、サービスの堅牢性と可用性を確保するために、しっかりとした専任の運用チームが必要になります。

Momentoは、世界で最も堅牢なキャッシング・プラットフォームです！Rustでゼロから書かれたMomentoは、AWSや他のトップクラスのハイテク企業向けに高性能なハイパースケールシステムを提供した実績を持つメディアエンジニアによって構築されました。Momentoの2階層アーキテクチャは、キャッシングエンジンとHTTP API、きめ細かなアクセス制御、ホットキーを緩和するセカンダリファンアウトキャッシュを統合しています。

Momentoは、Paramount、DIRECTV、Proseibenといった世界的なメディアブランドのミッションクリティカルなワークフローを、毎秒数百万リクエスト（RPS）の規模で提供しています。当社の主な差別化ポイントは、堅牢なアーキテクチャ、豊富な専門知識、お客様のプラットフォーム・チームの延長として機能する卓越した運用性です。Momentoがどのように究極の視聴者体験を提供するのに役立つかについては、gomomento.comをご覧ください。

Khawaja Shams

Author

Khawaja is the CEO and Co-Founder of Momento. He is passionate about investing in people, setting a bold vision, and team execution. Khawaja has experience at AWS where he owned DynamoDB, and subsequently owned product and engineering for all 7 of the AWS Media Services. He was awarded the prestigious NASA Early Career Medal for his contributions to the Mars Rovers.