AWS共有責任モデルとCloudWatch
AWSでは「共有責任モデル」によりユーザが対処すべき範囲とAWSが対処すべき範囲が規定されている。
http://media.amazonwebservices.com/AWS_Security_Best_Practices.pdf
http://www.slideshare.net/c95029/awsshared-responsibility-model-16612378
この範囲はサービスによっても異なりEC2のようなインフラ型サービスでは、AWSの責任範囲は仮想化基盤までであり、上位のOS内部はユーザの責任範囲である。
またRDSのようなマネージメント型サービスでは、DB処理能力を提供するRDBMSの稼働までがAWSの責任範囲である。その上で動作するSQLはユーザの責任である。
この分界点の考え方はCloudWatchによるメトリクスにも現れている。
EC2では仮想化基盤からインスタンスに割り当てられたCPU使用率やネットワークトラフィック、ディスクIOなど仮想化基盤側にて確認可能なものが取得される。
しかし仮想化基盤からは把握できないOS上のプロセスごとのCPU使用状況やディスク使用率、ソフトウェアVPN等による仮想NICごとのネットワークトラフィックやMemory使用量などは内部監視としてOS内部から、ユーザ自身が把握する必要がある。
RDSのようなマネージメント型サービスでは、EC2とは分界点が異なるため、EC2のCloudWatchメトリクスには含まれていないMemory使用率やDisk使用率などについてもCloudWatchにより取得されるが内部のSQLのオペレーション数などはユーザ責任領域であるためRDSのCloudWatchメトリクスには含まれない。
AWSにおける内部監視・監視ツールの意義
共有責任モデルにおいて、ユーザ範囲となっているリソースの利用状況把握は通常のCloudWatchメトリクスでは実現出来ないため、カスタムメトリクスの利用やサードパーティー製の監視ツールの利用が必要となる。
AWSは契約に基づきインスタンスの計算能力やIO性能、ネットワーク性能を提供するがその性能をアプリケーションが有効に利用できているかどうか、OS内部で競合が発生していないかを確認するのはユーザの責任となる。
たとえば、CPU性能が契約（インスタンスタイプの性能値）通りに提供されているかどうかはCloudWatchメトリクスにより確認することが出来る。
しかし、OS内部でCPU性能が目的とするアプリケーションに割り当てられているか、IOwaitや暴走したプロセスにより浪費されていないかといった確認はユーザが行う必要がある。
近年ではハードウェアの性能向上に伴い、そのままCPUを割り当てたのでは、インスタンスタイプで提示されているCPU性能を上回ってしまう場合がある。
こういった場合、EC2やその他の仮想化基盤ではハイパーバイザがインスタンスに対して実CPUを割り当てないという動作を行い、OS上でのCPU処理能力をインスタンスタイプに規定された処理性能に抑える場合がある。
この動作はOS上ではCPUStealとして観測される。
ギャランティー（帯域保証）型のネットワーク回線で、契約性能より高性能なNICや回線を利用している場合に、トラフィックシェーピングが行われる様子を考えると想像しやすい。
IOwaitやCPUSteal 等のOS内部での実際のCPU負荷状態はCloudWatchからは参照されないため、ユーザが内部監視によりOS上のCPU使用率監視を行っていない場合具体的なCPUの状態を把握することはできない。
内部監視を行っていた場合、監視データとCloudWatchメトリクスとの値のズレとして認識される場合がある。
これは責任範囲の違いによる見え方・見せ方の違いであり、いずれかの値が不正確であると言うことを意味しないことに注意が必要である。
CloudWatchの値は、サービス提供サイドからの割り当てに対する消費状況を意味しユーザによる内部監視はOS上でアプリケーションなどに割り当てできる処理能力を意味するためである。
株式会社サーバーワークス 伊藤 覚宏
