[アップデート] AWS Elemental MediaPackage の入出力リクエストに関するアクセスログを取得出来るようになりました

こんにちは、大前です。

本日は AWS Elemental MediaPackage（以下 MediaPackage）に関するアップデートについてお知らせします。

AWS Elemental MediaPackage expands Monitoring and Deployment Automation capabilities

TL;DR

• MediaPacakge でライブ配信を行う際、入力・出力の各リクエストについてログが取得出来る様になった
• ログは CloudWatch Logs に保管される
• MediaPackage の前後に存在するコンポーネント（エンコーダー、CDN など）のログと組み合わせる事により、トラブルシューティングやモニタリングに役立つ

どんなアップデートか

掲題そのままですが、MediaPackage でライブ配信を行う際にログが取得できる様になりました。ログは CloudWatch Logs に保管されます。

ログの種類

取得できるログとしては 入力ログ と 出力ログ の 2種類が存在します。

• 入力ログ
  • MediaPackage チャンネルの入力 URL に送られたリクエストに関するログ
  • エンコーダーからの PUT リクエストなど
• 出力ログ
  • MediaPackage チャンネルのエンドポイントに送られたリクエストに関するログ
  • ユーザからの GET リクエストなど

ログに含まれる情報

公式ドキュメント より、2020/10/28 時点でアクセスログには以下の情報が含まれます。

項目	説明
timestamp	リクエストが受信された日の時刻。値はISO-8601の日付時間で、リクエストを処理したホストのシステムクロックに基づいています。
clientIp	リクエストするクライアントのIPアドレス。
processingTime	MediaPackageがリクエストの処理に費やした秒数。この値は、リクエストの最後のバイトが受信された時間から、レスポンスの最初のバイトが送信されるまでの時間で測定されます。
statusCode	レスポンスの HTTP ステータスコードを数値で表します。
receivedBytes	MediaPackage サーバが受信するリクエストボディのバイト数。
sentBytes	MediaPackage サーバが送信するレスポンスボディのバイト数。この値は、サーバのレスポンスに含まれる Content-Length ヘッダの値と同じであることが多い。
method	リクエストに使用された HTTP リクエストメソッド。DELETE、GET、HEAD、OPTIONS、PATCH、POST、PUT。
request	リクエストURL。
protocol	HTTP など、リクエストに使用されるプロトコルの種類。
userAgent	リクエストを送信したクライアントを識別するユーザーエージェント文字列を二重引用符で囲みます。文字列は、1 つ以上の製品識別子、product/version で構成されます。文字列が 8 KB より長い場合は切り捨てられます。
account	リクエストに使用したアカウントのAWSアカウントID。
channelId	リクエストを受信したチャンネルの ID。
channelArn	リクエストを受信したチャネルのAmazon Resource Name (ARN)。
domainName	TLS ハンドシェイク中にクライアントから提供されるサーバー名表示ドメインを二重引用符で囲みます。クライアントがSNIをサポートしていないか、ドメインが証明書と一致せず、デフォルトの証明書がクライアントに提示された場合、この値は-に設定されます。
requestId	各リクエストを一意に識別するためにMediaPackageによって生成される文字列。
endpointId	リクエストを受信したエンドポイントのID。
endpointArn	リクエストを受信したエンドポイントのAmazon Resource Name (ARN)。

料金

ログの取得を有効化しても MediaPacakge に追加費用は発生しませんが、CloudWatch Logs の費用が発生する形となります。

ライブ配信は必然的にリクエストが多く発生するサービスですので、CloudWatch Logs の費用を考慮した上で有効化しましょう。

Amazon CloudWatch の料金

やってみた

実際にログの取得機能を有効化して、ライブ配信を行ってみます。

MediaPackage でチャンネル作成画面を開くと、Configure access logging という項目が追加されている事が確認できます。

今回は両方とも有効にしてみます。

Enable 〜 access logs にチェックを入れると、CloudWatch Logs のロググループを指定できます。今回はデフォルトのまま作成します。

ちなみに、MediaPackage のログ取得設定を行うと裏でサービスロールが生成される様です。

Permissions to publish access logs to CloudWatch

When you enable access logging, MediaPackage creates an IAM service-linked role, AWSServiceRoleForMediaPackage, in your AWS account. This role allows MediaPackage to publish access logs to CloudWatch. For information about how MediaPackage uses service-linked roles, see Using Service-Linked Roles for MediaPackage. （アクセスログを有効にすると、MediaPackageはAWSアカウントにAWSServiceRoleForMediaPackageというIAMサービス連携ロールを作成します。このロールにより、MediaPackageはアクセスログをCloudWatchに公開することができます。MediaPackageがサービス連携ロールを使用する方法については、「MediaPackageのサービス連携ロールの使用」を参照してください。）

IAM を確認すると確かにロールが生成されている事も確認できました。

設定後にライブ配信を行い（MediaLive + MediaPackage の構成としました）、適当にリクエストを投げたのちに CloudWatch Logs を確認してみるとログが生成されている事が確認できます。

それぞれ、ログの中身をサンプルとして記載しておきますので参考までに。（アカウントID 等は伏せています）

IngressAccessLogs

{
    "timestamp": "2020-10-28T01:27:30.201354Z",
    "clientIp": "54.250.95.225",
    "processingTime": 0.161,
    "statusCode": "201",
    "receivedBytes": 437553,
    "sentBytes": 1009,
    "method": "PUT",
    "request": "https://6a0d7aa93e381354.mediapackage.ap-northeast-1.amazonaws.com:443/in/v2/f09a42dfa3c04407b69d781c25f3a129/f09a42dfa3c04407b69d781c25f3a129/channel_k6u43_20201028T012727_00025.ts",
    "protocol": "HTTP/1.1",
    "userAgent": "Elemental 2.18.3.705845",
    "account": "012345678910",
    "channelId": "AccessLogTest",
    "channelArn": "arn:aws:mediapackage:ap-northeast-1:012345678910:channels/f09a42dfa3c04407b69d781c25f3a129",
    "domainName": "6a0d7aa93e381354.mediapackage.ap-northeast-1.amazonaws.com",
    "requestId": "Root=1-5f98c902-452a3a6b31f440615c3c0b76"
}

EgressAccessLogs

{
    "timestamp": "2020-10-28T01:29:01.926084Z",
    "clientIp": "12.34.56.78",
    "processingTime": 0.054,
    "statusCode": "200",
    "receivedBytes": 53,
    "sentBytes": 735,
    "method": "GET",
    "request": "https://1234567801aa99.mediapackage.ap-northeast-1.amazonaws.com:443/out/v1/03abbfea963b4fdab36d0b3d43b35a27/index_1.m3u8",
    "protocol": "HTTP/2.0",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36",
    "account": "012345678910",
    "channelId": "AccessLogTest",
    "channelArn": "arn:aws:mediapackage:ap-northeast-1:012345678910:channels/f09a42dfa3c04407b69d781c25f3a129",
    "domainName": "15bcd044c531aa99.mediapackage.ap-northeast-1.amazonaws.com",
    "requestId": "Root=1-5f98c95d-206b100bb6899b55a8084085",
    "endpointId": "Endpoint1",
    "endpointArn": "arn:aws:mediapackage:ap-northeast-1:012345678910:origin_endpoints/03abbfea963b4fdab36d0b3d43b35a27"
}

おわりに

AWS MediaPackage にてログの取得が可能となりました。

CloudWatch Logs の費用と相談な部分はあるかと思いますが、ライブ配信がうまくいかない際のトラブルシューティングに用いる事が出来ると思いますので、なるべく有効にしておくと良いかと思います。

また、CloudFront と MediaPackage を併用する際のキャシュヒット率等も算出しやすくなるかと思いますので、コストの把握にも役立ちそうです。

以上、AWS 事業本部の大前でした。

参考

• AWS Elemental MediaPackage
• AWS Elemental MediaPackage expands Monitoring and Deployment Automation capabilities
• MediaPackage - Access logging
• Amazon CloudWatch の料金