本記事はネットワークウィーク 3日目の記事です。
💻 2日目 ▶▶ 本記事 ▶▶ 4日目 🌐

日中は暑く、日没後は肌寒い絶妙な塩梅の日が増えました。冬が恋しいです、西です。

昨今はシステムの状態を細やかに把握することの重要性が話題に上ることが多いです。システムの状態把握によって、提供しているサービス機能の正常性監視や、収集した情報を基にした迅速な問題解決が容易になります。 AWS ワークロードにおいては、各コンポーネントの情報を Amazon CloudWatch (CloudWatch) で収集することで実現しますね。

こういった文脈では、オブザーバビリティやモニタリングという概念がよく取り上げられます。

aws.amazon.com

モニタリングは個々のコンポーネントに関するデータを収集し、オブザーバビリティは分散システム全体を監視します。

個人的な解釈ですが、まずはモニタリングに取り組み、得られた情報を活用してオブザーバビリティが指す監視を実現するイメージをしています。

そこで、今回は Amazon CloudFront(CloudFront) をモニタリングの観点からご紹介します。ネットワークウィークのテーマとして適切か微妙な気もしましたが、CloudFront は CDN (Content Delivery Network) サービスなのでセーフです。

CloudFront のユーザ向け機能

冒頭で述べた通り CloudFront は CDN サービスです。ユーザへ配信する静的コンテンツをキャッシュ・配信するのが主な役割です。世界中に配置されている大量のエッジロケーションで構成されており、ユーザに対する低遅延のコンテンツ配信を実現します。

また、それら機能以外に、CloudFront ではエッジ関数も利用できます。エッジ関数は、リクエスト元に最も近いエッジロケーションで軽量な処理を実行する機能です。ユーザに近いエッジで実行される分、高速なレスポンスが期待できます。 CloudFront では Lambda@Edge (以下、L@E) と CloudFront Functions (以下、CF2) という 2 種類のエッジ関数が利用可能です。

少し余談です。私は以前も CloudFront の記事を執筆しました。

tech.nri-net.com

その時にエッジロケーションの数を調べたのですが、今回も同様に調べてみました。確認すると拠点数が数百単位で増加していました (参考)。

拠点種別	前回時点の拠点数 (2024/07/16)	今回時点の拠点数 (2025/10/15)
リージョン別エッジキャッシュ (REC)	13	13
Points of Presence (エッジロケーション)	600 以上	700 以上
埋め込み Points of Presence	600 以上	900 以上

相変わらず規模の大きさが想像できませんが、AWS の継続的な規模拡大を感じます。

CloudFront のユーザ向け機能におけるモニタリング

さて、本題です。CloudFront の状態や正常性はどのように確認することができるでしょうか。

メトリクス

CloudFront

システム正常性の指標として、まずはメトリクスを用いたシンプルなスタイルが思い浮かぶのではないでしょうか。 CloudFront にも他サービスと同様、メトリクスが存在します。ディストリビューションに関するものですね、今更ですが一覧化してみます (参考)。

メトリクス種別	説明	デフォルトで有効 / 追加課金で有効
BytesUploaded	ビューワーが CloudFront で POST および PUT リクエストを使用してオリジンにアップロードした合計バイト数。	デフォルトで有効
BytesDownloaded	GET、HEAD、および OPTIONS リクエストについて、ビューワーによってダウンロードされた合計バイト数。	デフォルトで有効
Requests	すべての HTTP メソッド、および HTTP リクエストと HTTPS リクエストの両方について、CloudFront によって受信されたビューワーリクエストの合計数。	デフォルトで有効
TotalErrorRate	レスポンスの HTTP ステータスコードが 4xx または 5xx であるすべてのビューワーリクエストの割合。	デフォルトで有効
4xxErrorRate	レスポンスの HTTP ステータスコードが 4xx であるすべてのビューワーリクエストの割合。	デフォルトで有効
5xxErrorRate	レスポンスの HTTP ステータスコードが 5xx であるすべてのビューワーリクエストの割合。	デフォルトで有効
キャッシュヒットレート	CloudFront がそのキャッシュからコンテンツを送信した対象のすべてのキャッシュ可能なリクエストの割合 (%)。	追加課金で有効
オリジンのレイテンシー	CloudFront キャッシュではなくオリジンから送信されたリクエストについて、CloudFront がリクエストを受信してからネットワーク (ビューワーではなく) にレスポンスを提供し始めるまでに費やした合計時間。	追加課金で有効
ステータスコード別のエラー率	レスポンスの HTTP ステータスコードが 4xx 範囲または 5xx 範囲内の特定のコードであるすべてのビューワーリクエストの割合 (%)。	追加課金で有効

各項目の説明にもありますが、多くはビューワーリクエストが正常に受け付けられ・処理されたかを確認できるメトリクスです。デフォルトではオリジンとのリクエスト・レスポンスはオリジン側の責任範囲になりそうですね。サービス提供側の目線だと、やはり 5xx が気になる要素です。

また、キャッシュヒット率やオリジンとの通知レイテンシー、エラーコードの内訳割合 (401、403、404、502、503、および 504) など、詳細なメトリクスも追加課金で有効にできます。

余談ですが、改めて眺めてみると 4xx・5xx のいずれも割合で表現するメトリクスのみであることが印象的です。 CloudFront は多くのエッジロケーションで構成され、それが地理的にも分散しています。そのため、俯瞰した状態把握が優先されているのでしょうか。あくまで想像です。

エッジ関数

CloudFront では L@E と CF2 という 2 種類のエッジ関数が利用可能と紹介しました。 L@E は AWS Lambda (Lambda) を CloudFront ディストリビューションに関連付けて実行します。一覧化すると以下の通りです。 Lambda 関数のメトリクスと比較して少ないですが、似通った情報が確認できますね。

メトリクス種別	説明
Throttles	スロットリングされた呼び出しリクエストの数です。すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda はそれ以降のリクエストを TooManyRequestsException エラーで拒否します。スロットリングされたリクエストやその他の呼び出しエラーは、Invocations または Errors とはみなされません。
Duration	関数コードがイベントの処理に費やす時間。呼び出しの請求時間は、最も近いミリ秒に切り上げられた Duration の値です。 Duration はコールドスタート時間を含みません。
Errors	関数エラーが発生した呼び出しの数。関数エラーには、コードで発生する例外と Lambda ランタイムがスローする例外が含まれます。ランタイムは、タイムアウトや設定エラーなどの問題に対してエラーを返します。エラー率を計算するには、Errors の値を Invocations の値で割ります。エラーメトリクスのタイムスタンプは、エラーが発生した日時ではなく、関数が呼び出された日時であることにご注意ください。
Invocations	関数コードが呼び出された回数 (成功した呼び出しと関数エラーが発生した呼び出しを含む) です。呼び出しリクエストが調整されたり、呼び出しエラーが発生したりした場合、呼び出しは記録されません。 Invocations の値は、請求されるリクエストの数と同じです。
ConcurrentExecutions	イベントを処理している関数インスタンスの数です。この数がリージョンの同時実行クォータまたは関数のリザーブド同時実行制限に達すると、Lambda は追加の呼び出しリクエストを制限します。

一方、CF2 はL@E と比較して低コストなエッジ関数として利用可能です。主にリダイレクトやヘッダ操作・Basic 認証など、特に軽量な処理向け機能です。 CF2 は CloudFront 特有の機能であり、CF2 特有のメトリクスがあります。一覧化してみましょう。

メトリクス種別	説明
FunctionInvocations	特定の期間において、関数が開始された (呼び出された) 回数。
FunctionComputeUtilization	関数の実行にかかった時間 (0～100) を、最大許容時間に対する割合として表したもの。例えば、35 という値は、最大許容時間の 35% で関数が完了したことを意味します。
FunctionExecutionErrors	特定の期間に発生した実行エラーの数。実行エラーは、関数が正常に完了しなかった場合に発生します。

CloudFront のサブ機能のためか、種別数は少なめです。まず目につくのはやはりエラー数 FunctionExecutionErrors でしょうか。

また、CF2 特有のメトリクスに FunctionComputeUtilization があります。先に述べた通り、CF2 は軽量処理向け機能のため、CPU やメモリにおいて厳しいリソース制約があります。ですので、この値は CF2 のリソース逼迫状況を読み取るための重要な値になります。値次第では、CF2 から L@E への移行も選択肢になります。

ログ

前節ではメトリクスについて触れました。しかし、リクエストやエッジでの詳細な情報を把握したい場合はログの収集と確認が必要です。 CloudFront とエッジ関数でログを確認する場合、出力先について注意が必要です。各要素とそのログ出力先は以下のようになっています。

要素	出力先
CloudFront アクセスログ	・Amazon S3 ・ CloudWatch Logs ロググループ (us-east-1 リージョン)
Lambda@Edge ログ	・CloudWatch Logs ロググループ (リクエスト元に最も近いリージョン) Lambda 関数の出力ログ (関数エラー含む) ・CloudWatch Logs ロググループ (us-east-1 リージョン) Lambda が CloudFront に無効なレスポンスを返した際のエラーログ (Runtime 層での問題等)
CloudFront Functions ログ	CloudWatch Logs ロググループ (us-east-1 リージョン)

要素によってリージョンの制約がある場合や、出力先を制御できない場合があるため、少し複雑です。絵にすると以下の通りです。

CloudFront に関連するログは基本的に us-east-1 リージョンに集約されます。一方、L@E の実行ログは (有名な話かもしれませんが) 各リージョンに分散されて出力されます。そのため、迅速な把握が必要な場合には各リージョンの CloudWatch Logs をトリガーとしたログ集約や検知の工夫が必要です。