【導入文】
こんにちは。社内システムのクラウド化を支援している「僕」です。
半導体エンジニアの「妻」にAWSの仕組みを語り、ハードウェア目線で鋭いツッコミをもらうこのシリーズ。今回は、システムトラブル時に役立つ「監視機能」のアップデートと、その裏に潜む課金の罠について話した日の会話をお届けします。
1. 【プロローグ】システムが重い！犯人はサーバー？それともストレージ？
僕： 「ねえ聞いて！ システムが重い時、『サーバー（EC2）の処理が限界』なのか、『データ保存先（EBS）の読み書きが詰まってる』のか、パッと見で一発で分かる新しいメトリクス（監視指標）が出たんだ！」
妻： 「は？ パソコンが遅い時にCPUが悪いのか、ハードディスクが悪いのか切り分けるなんて基本中の基本でしょ。今までAWSではパッと見で分からなかったの？」
僕： 「そうなんだよ。これまでは、CloudWatchっていう監視画面の数値をいくつか掛け合わせて計算しないと、どっちが通信の上限に達してるか正確には分からなかったんだ。」
妻： 「なるほど。データ転送のバス幅のボトルネックが、演算ユニット側にあるのか、ストレージ側にあるのか、わざわざ波形を計算しなくても自己診断して一発で教えてくれる機能がついたってことね。それは便利じゃない。」
2. 【Tipsのタネ明かし】新機能「キャパシティ超過メトリクス」
僕： 「少し技術的に解説するね。EC2（サーバー）には、サイズごとに『EBS（ストレージ）と通信できる帯域（IOPSやスループット）の上限』が決まっているんだ。」
妻： 「配線の太さ（帯域）には物理的な限界があるから当然ね。」
僕： 「これまでは上限に達していても気づきにくかったんだけど、今回のアップデートで 『サーバー側でストレージとの通信キャパシティが超過しているか』を示す専用の指標 が追加されたんだ。これを見れば、トラブル時に複雑な計算いらずでボトルネックを特定できる！」
3. 【実践Tips】あえて「詰まらせて」犯人を炙り出す
僕： 「じゃあ、意図的にシステムを詰まらせて、この便利機能を使ってみるよ。」
-
高負荷をかける準備
EC2インスタンスを立ち上げ、負荷テストツールを使って、EBSボリュームに対して猛烈な勢いで読み書きを行う。 -
詳細モニタリングをオンにする（罠の発動）
「せっかくだから1分単位のリアルタイムで数値の変化を見たい！」と思い、EC2の設定画面から 「詳細モニタリング」 をポチッと有効化する。 -
メトリクスの観察
監視画面を見ると、新しい超過メトリクスがピコンと反応し、「現在、EC2側の帯域制限に引っかかってます！」と一目でわかるように！
僕： 「ほら！ 計算いらずで『EC2側の限界だ』って一発で分かったよ！ これでトラブルシューティングがめちゃくちゃ早くなるね」
4. 【解説と解決策】「便利」の裏にある代償
妻： 「確かに一目瞭然ね。水が出ない時に、『蛇口（EC2側の上限）』が絞られているのか、『ホース（EBS側の上限）』が細いのか、すぐ切り分けられるのは素晴らしいわ。……でも、さっきあなたが何気なくオンにした『1分単位』って設定、今まで何分だったの？」
僕： 「標準だと5分間隔でデータを取ってるよ。」
妻： 「サンプリングレートを5倍に上げたのね。……AWSがそんな高頻度のデータ収集をタダでやらせてくれるとは思えないんだけど。」
僕： 「うっ……鋭い。実は標準の5分間隔なら無料なんだけど、1分間隔の『詳細モニタリング』にすると、EC2インスタンスごとに追加料金（※月額数百円程度）がかかるんだよね。」
妻： 「ほらやっぱり！ 半導体の評価テストでも、プロービングのサンプリング周波数を上げたら、当然テスト装置の占有時間が延びてコストが跳ね上がるのよ。トラブルシューティングの時だけサンプリングを細かくするのはいいけど、便利だからって全部のサーバーを1分間隔で監視したまま放置してたら、あっという間に『ちりつも』で経費が膨れ上がるわね。」
5. 【お片付け】詳細モニタリングの切り忘れに注意
僕： 「確かに、解決した後に設定を戻し忘れて放置しちゃうのが一番怖いね……」
妻： 「原因が分かって満足したなら、検証に使ったサーバーはすぐにシャットダウンして削除（Terminate）してちょうだい。もし本番環境なら、トラブル解決後に『詳細モニタリング』のチェックを外してサンプリングレートを落とすのを、絶対に忘れないことね。」
僕： 「了解！ 我が家の家計がクラウド破産する前に、すぐお片付けしてきます！」
【結びの文】
システムのボトルネック特定が劇的に簡単になる新メトリクスですが、リアルタイムな監視を求めるあまり「詳細モニタリング」をオンにしたまま放置してしまう課金の罠には十分ご注意ください！