AWS Elemental MediaStore

解決する課題

ライブ動画配信では、エンコーダが数秒ごとに小さなメディアセグメント（HLS や DASH のチャンク）を書き込み、視聴者側のプレイヤーがほぼ同時にそれを読み取ります。汎用ストレージでは、書いた直後のセグメントがまだ見えない、読み取りの遅延がばらつく、といった問題がライブの破綻につながりやすくなります。AWS Elemental MediaStore は、こうしたライブ配信のオリジンに求められる特性をマネージドのストレージとして提供します。

• 書き込んだセグメントが即座に読み取れる強い整合性で、ライブの取りこぼしを防ぐ
• 小さなオブジェクトに最適化した低く安定したレイテンシでプレイヤーへ供給
• ストレージ基盤やスケーリングを自前で運用しないマネージドなオリジン
• CloudFront などの CDN と組み合わせ、オリジンとしてセグメントを配る

ライブ動画のオリジン専用ストレージという位置づけで、CDN の手前に置いてセグメントを高速かつ一貫して出し入れすることが中心的な価値です。

主要概念と用語

• コンテナ（Container）: MediaStore におけるトップレベルの名前空間。S3 のバケットに相当し、オブジェクトをこの中に格納する。アクセスポリシーやメトリクスはコンテナ単位で管理する
• オブジェクト: コンテナ内に格納する個々のファイル。ライブ配信ではマニフェストやメディアセグメントが主な対象
• データエンドポイント: コンテナへの読み書きに使う HTTP のエンドポイント。オブジェクト操作はこのエンドポイントに対して行う
• コンテナポリシー: コンテナへのアクセス可否を定める JSON ポリシー。どのプリンシパルにどの操作を許すかを制御する
• オブジェクトライフサイクルポリシー: 一定時間を過ぎたオブジェクトを自動削除するルール。ライブの古いセグメントを溜め込まないために使う
• メトリクスポリシー: コンテナやパスごとのメトリクスを CloudWatch に出すかを制御する設定
• オリジン: CDN がコンテンツを取りに行く源。MediaStore はライブ配信のオリジンとして使われる

仕様・制限・クォータ

• 書き込み直後のオブジェクトを即座に読み取れる**強い整合性（read-after-write）**を提供する
• 小さなメディアセグメントの低レイテンシな読み書きに最適化されている
• オブジェクト操作はHTTP/HTTPS で行い、CDN のオリジンとして直接参照できる
• オブジェクトライフサイクルポリシーで古いセグメントを自動削除し、ストレージを膨張させない
• アクセス制御はコンテナポリシーと IAM で行い、メトリクスはコンテナ・パス単位で取得できる
• コンテナ数やリクエストレートなどにアカウント単位・リージョン単位のクォータがあり、引き上げ申請ができる

ストレージのクラスや長期保管の最適化という観点では汎用の S3 ほど多機能ではなく、あくまでライブのオリジンに焦点を当てたサービスです。具体的な上限値は更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、コンテナを作りデータエンドポイントへ HTTP でオブジェクトを出し入れするマネージドなストレージとして扱えます。

• コンテナの作成: 名前空間としてコンテナを作り、専用のデータエンドポイントが払い出される
• 書き込み: エンコーダや MediaLive などがマニフェストとセグメントをデータエンドポイントへ PUT する。書き込みは即座に読み取り可能になる
• 読み取り: CDN やプレイヤーがデータエンドポイントから GET でセグメントを取得する。低レイテンシで一貫した読み取りを返す
• ライフサイクル: ライフサイクルポリシーに従い、古いオブジェクトを自動的に削除して容量を一定に保つ

スケーリング、冗長化、ハードウェアの管理はすべて AWS 側が担い、利用者はオリジンの容量計画やサーバー運用を意識せずに済みます。ライブの突発的なリクエスト増にもマネージドに追従します。

設計パターン / ベストプラクティス

• CDN を必ず手前に置く: 視聴者に MediaStore を直接見せず、CloudFront をオリジンとして前段に置き、エッジでキャッシュして負荷とレイテンシを下げる
• エンコーダのオリジンとして使う: MediaLive などのライブエンコーダの出力先にコンテナを指定し、生成したセグメントをそのままオリジンに置く
• ライフサイクルで古いセグメントを掃除: ライブの過去セグメントは短い保持期間で自動削除し、ストレージの肥大化と無駄なコストを防ぐ
• コンテナ単位で用途を分離: チャンネルや環境ごとにコンテナを分け、ポリシーとメトリクスを独立して管理する
• 代替の検討: 新規や移行案件では S3 をオリジンにする構成や、配信パッケージングを担う MediaPackage の利用も比較する

運用・監視

• リクエスト数やレイテンシ、エラーなどの指標を CloudWatch のメトリクスで監視する。メトリクスポリシーで取得粒度を制御できる
• API 操作の監査証跡は CloudTrail に記録され、コンテナ作成やポリシー変更を追跡できる
• ライフサイクルポリシーが意図どおり動いているか、ストレージ使用量の推移で確認する
• オリジンエラーは CDN 側の指標と突き合わせ、書き込み遅延やポリシー不備を切り分ける

コスト

• 課金は基本的に保存しているデータ量と、読み書きのリクエスト数・転送量に対する従量制で構成される
• サーバーを常時起動する費用は発生せず、使った分だけの課金になる
• ライブの過去セグメントを溜め込むと保存量とリクエストが積み上がるため、ライフサイクルでの自動削除がコスト面でも重要になる
• CDN を手前に置くとオリジンへのリクエストが減り、MediaStore 側のリクエスト課金を抑えられる

具体的な単価は変動するため、料金は公式の料金ページで確認してください。配信規模と保持期間から保存量とリクエスト数を見積もるのが安全です。

セキュリティ

• アクセス制御はコンテナポリシーと IAM で行い、読み書きするプリンシパルに最小権限のみを付与する
• 転送は HTTPS（TLS） で保護し、コンテナポリシーで HTTPS のみを強制することもできる
• 有料コンテンツでは CDN 側の署名付き URL やトークン認証と組み合わせ、オリジンへの直接アクセスを制限する
• 保存データの保護や監査は IAM・CloudTrail と合わせて設計する

関連サービス・比較

汎用オブジェクトストレージの Amazon S3 と混同しやすいため比較します。MediaStore はライブオリジンに特化し、S3 は多用途の汎用ストレージという違いがあります。

ハンズオン / CLI例

# コンテナを作成
aws mediastore create-container --container-name live-origin

# コンテナのデータエンドポイントを取得（オブジェクト操作はこのURLに対して行う）
aws mediastore describe-container --container-name live-origin \
  --query "Container.Endpoint" --output text

# 取得したエンドポイントにセグメントを書き込み（mediastore-data を使用）
aws mediastore-data put-object \
  --endpoint-url https://xxxxxxxx.data.mediastore.ap-northeast-1.amazonaws.com \
  --body segment-001.ts \
  --path /live/segment-001.ts