Scribble at 2022-11-09 10:40:26 Last modified: 2022-11-11 11:55:11

上のグラフは AWS の CloudWatch で測定しているメトリクスのグラフだ。或るキャンペーンでサイトを運用していて、ウェブ・サーバの前面には CloudFront という CDN サービスを展開している。このグラフは CloudFront へのリクエストを測定したメトリクスにもとづいている（CloudFront のメトリクスなので、リージョンは当然ながら us-east-1 に固定）。他のパブリック・クラウド・サービスや IaaS と同様に、AWS でも専用の語句が多々あるし、一般的なコンピュータ・サイエンスやシステム開発の言葉と同じでも意味が違っていたり狭かったり広かったりする場合もあるため、こちらが分かる範囲で注釈は加えるが、パブリック・クラウドについては個々のサービスに応じた用語があるという前提で文章を読むようにお勧めする。

上の画像では二つのグラフが表示されている。これは、「１分間の平均リクエスト」と「１分間の合計リクエスト」として定義したメトリクスのグラフであり、メトリクスとして集計されるデータの定義は、下記のページで解説されている。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html

このページの解説から、上記のグラフで使っているメトリクスは、"period" がどちらも１分間であり、合計とは「全てのデータポイントで取得した値の合計」であり、平均とは「合計/データポイントの数」であることが分かる。通常、CloudWatch というサービスでは無料の「標準メトリクス」で EC2 など幾つかのサービスのメトリクスを取得してグラフに表示できるのだが、CloudFront のようなサービスのメトリクスは有料である。ただし料金がかかるまでには測定回数の余裕もあるので、CloudFront のメトリクスを取得し始めたらすぐにお金がいくらかかかるというものでもない。また、標準メトリクスは最短でも５分間隔でしかメトリクスを取得できないのに対して、有料となる詳細メトリクスでは１分、更に料金はかかるが更に短い間隔で集計が取れるようになっている。

単純に CloudWatch というサービスを AWS のコンソール（管理画面）で扱う手順の話しかしていない未熟な技術者や物書きやブログ運営者の記事などでは、このメトリクスが何を意味しているのかということに何の疑問もなく雑な説明だけを書いていることが分かる。なぜなら、それでは「データポイント」とか「集計（statistics）」とは何なのか、上記の手順や定義だけでは分からないからだ。データポイントが CloudFront に届いた個々のリクエストのことであれば、リクエストの合計とはデータポイントの数と同じではないのかと思いたくなる人もいるだろう。

このような混乱が生じる理由は、上記のページには「データポイント」の定義も説明もないからである。データポイントがサービスやインスタンスごとのデータであるという点は動かないが、メトリクスはデータポイントの一式を意味する言葉であり、そしてデータポイントは現実に取得された記録（端的に言えばログ）から集計間隔などの条件によって割り出された値である。よって、詳細メトリクスでは「１分ごとの合計リクエスト」という条件において、もともと CloudWatch が集積している記録から１分という単位で集計を割り出し、そしてそれを表示したい期間に渡ってメトリクスとして出力し、グラフに表示するというわけである。よって、データポイントというのは「記録を集計する基準点（期間・範囲）」のことである。１分ごとのメトリクスを取得できる詳細メトリクスでは、１分という時間の間隔で「１データポイント」が定義されている。しかし、実際にはもっと細かい時間の単位でデータポイントは設定できるのだが、それはお金次第ということである。データポイントは、こうして記録されたデータからの集計つまり加工した特別なデータであるから、データポイントごとの保存期間が決められている。上記のような１分ごとの詳細なデータポイントを設定したメトリクスだと、せいぜい２週間ていどしか保存されない。よって、上記の画像では１分という間隔でデータポイントを取得するように設定してあるが、実際には２週間よりも前の期間については１分ごと（データポイントごと）の変数というのは取得できない。上記のグラフのように12時間ぶんとか何日、何週間、何か月ぶんかの、もっと長期にわたって保存できるメトリクスとしてしかグラフに反映して眺められないわけである。（実際、このサイトは昨年度も同じキャンペーンを開催したのだが、そのときのメトリクスは大半が失われているため、AWS のコンソールでは過去のメトリクスが表示できない。無償だと、そういう限界がある。）

そういうわけで、上記のグラフでデータポイントごとの値を表示するにあたっては、それがどういう期間のメトリクスとして集計されるのかによってはグラフの値が違ってくるわけである。一般的に言えば、メトリクスの範囲が広くなればグラフとして表示するための集計範囲（集計に使うデータポイントの数）が増えるため、つまりは或る期間のグラフを描くために使うデータポイントの数が増えるわけなので、その結果として「合計」のグラフなどは値がどんどん大きくなる。同じ幅の間で集計しないといけない時間の間隔が長くなると、それだけ集計の対象となるデータポイントが増えるので、グラフとして表示させる「画像の幅あたりの数」が合計としてどんどん積み重なるからだ。これに対して、集計する期間内で特別に多くのアクセスが集中したデータポイントがなければ、似たような平均値を更に平均するだけなので、「平均」のグラフは特に変化がないように見えるのである。

もし単純に１分間のリクエストの合計が「合計」であり、１分間のリクエストの合計を１分間の平均として算出しているだけなら、これら二つの値が違っている筈はない（どちらもデータポイントは「１」だから、平均は１で割っているだけの計算だからだ）。そして、合計メトリクスに連動して平均のメトリクスも上下する筈だが、グラフでお分かりのとおり平均メトリクス（濃いオレンジのグラフだが、あまりにも少ない値なので分かりにくいかと思う）は大きな変化がない。そして、これはメトリクスを集計・表示する期間が長くなればなるほど合計と平均のグラフの違いは著しくなってくる。

AWS のサービス運用を保守・管理する立場の実務として言えば、こうしたメトリクスを毎日ブラウザでアクセスして眺めるというだけでは、もちろん不十分である。よって、一定の条件を設定して閾値を超えたらメールや SMS で通知するようなアラートを設定しておくことも必要だ。そういうことをやった上で、このようなメトリクスのグラフを眺めるという作業について言えば、アラートが出ていないという前提では３日分くらいをディフォールトで表示している。これは、もちろん土日にこんなものを眺める職責などサラリーマンにはないからだ。また、リクエストの増加に備えるという事情があるなら、オート・スケーリングとかロード・バランサを配備するという必要もあろう。しかし、それは明らかに予算次第である。パブリック・クラウドは後払いであるため、どうしても実運用の前には現実のコストが分かっていない（そして AWS でも高性能な試算ツールがあるというのに使おうともせず）せいで、あれも不安だ、これもやっておきたいなどと、懸念点だけは続々と考えついて不要なサービスをてんこ盛りにしてしまい、後から巨大な金額を請求されることになったりする。いや、そういう懸念を思いつくだけ、最近のクライアントも成長したというべきであろう。もう何年も前の話になるが、某有名漫画家の描いた Flash 動画のブロブ・パーツを SAKURA インターネットのサーバで公開し、転送量だけで１ヵ月の請求金額が数百万円になって、クライアントと広告代理店で折半したなんて話もある。（もちろん、僕は全く関与していなかった案件の話だ。僕のようなキャパシティ・プランニングや情報セキュリティという非機能要件に詳しいエンジニアが関与していたら、結果はともかく「こうなりますよ」と釘を刺すことは確実にできたろう。）