こんにちは、SCSKの谷です。
これまでに3大クラウドの各サービスをMackerelのクラウドインテグレーションを利用して監視を実装する記事を投稿してきました。
AWS：Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony
Azure：MackerelでAzure環境を監視してみた！ – TechHarmony
Google Cloud：MackerelでGoogle Cloudを監視してみた – TechHarmony
最後に総まとめということで、3大クラウドのMackerel監視（クラウドインテグレーション）を比較していきます！
そもそもMackerelのクラウドインテグレーションとは？
これまでの記事の中で各クラウドインテグレーションを利用して監視を実装していましたが、そもそもMackerelのクラウドインテグレーションについて説明していなかったので、簡単に説明させていただきます。
Mackerelのクラウドインテグレーションとは、AWS／Azure／Google Cloudと連携し、それぞれのクラウド環境を「Mackerel上のホスト」として一元監視できる機能です。
■基本構造
Mackerel側から各クラウドの監視サービスのAPIを利用してホストの情報及びメトリクスを取得
・ポーリング間隔：5分
■利用方法
MackerelからAPIを使用するために、それぞれのクラウドに合わせた認証方法を利用します。
AWS：IAMロールで連携 ＋ ポリシー付与
Azure：サービスプリンシパル設定 + ロール割当
Google Cloud：サービスアカウント設定 ＋ ロール割当
クラウドインテグレーションで監視可能なクラウドサービス比較
ここでは、Mackerelのクラウドインテグレーションで監視可能なサービスについて比較していきます。
合計サービス比較
現在Mackerelのクラウドインテグレーションで監視可能なクラウドサービスの合計はそれぞれ以下の通りです。
| AWS | Azure | Google Cloud | |
| 合計サービス数 | 27 | 11 | 3 |
クラウドインテグレーションで監視できるサービスの数を比べると、クラウド利用者が多い AWS が、他のクラウドを大きく引き離していることがわかります。
サービスカテゴリ比較
各クラウドサービスのカテゴリごとの監視可能サービスの対応状況は以下の通りです。
カテゴリ分けはある程度各クラウドサービスのカテゴリ分けに沿っています。よく利用されるサービスのカテゴリについては太字にしています。
| カテゴリ | AWS | Azure | Google Cloud |
| コンピューティング | ◎ | ◎ | 〇 |
| コンテナ | 〇 | × | × |
| データベース | ◎ | ◎ | 〇 |
| ネットワーク | ◎ | 〇 | × |
| ストレージ | 〇 | 〇 | × |
| 分析 | ◎ | × | × |
| アプリケーション統合 | 〇 | × | × |
| ビジネスアプリケーション | 〇 | × | × |
| セキュリティ | 〇 | × | × |
| 開発者ツール | 〇 | × | × |
| 管理 | 〇 | × | × |
| 上記以外のカテゴリ | × | × | × |
※３つ以上対応している場合は◎
AWSは監視可能なサービス数が非常に多く、ほぼすべてのカテゴリで1つ以上のサービスに対応しています。さらに、利用頻度が高いカテゴリでは3つ以上のサービスを監視できるものもあり、幅広い選択肢を提供しています。特筆すべきは、AWSのみコンテナ関連のサービス監視に対応している点です。
一方、Azureはコンピューティング系とデータベース系で3つ以上のサービスに対応しているものの、基本的にはよく利用されるサービスに限定されています。
Google Cloudはさらにシンプルで、コンピューティング系とデータベース系のみ監視可能であり、最低限のサービス対応にとどまっています。
クラウドインテグレーションで取得可能なメトリクス
ここでは、Mackerelのクラウドインテグレーションを利用して、仮想サーバー系サービスで取得できるメトリクス数と項目を比較していきます。
メトリクス数
現在Mackerelのクラウドインテグレーションで取得可能な仮想マシンサービスのメトリクス数合計はそれぞれ以下の通りです。
比較として、各クラウドの監視サービスで取得可能なメトリクス数も記載しています。
| AWS | Azure | Google Cloud | |
| Mackerel | 21 | 11 | 22 |
| クラウド監視サービス | 29 | 64 | 179 |
Mackerelでは、CloudWatchなどのクラウド監視サービスからすべてのメトリクスを取得するのではなく、利用頻度の高いメトリクスに絞って収集しているように見えます。特にGoogle CloudやAzureの場合、提供されるメトリクス数が非常に多いため、Mackerel側であらかじめ選定されたメトリクスのみが管理画面に表示されることで、ユーザーは膨大なメトリクスの中から必要なものを探す手間がなく、直感的でわかりやすい監視設定が可能になっていると感じました。
メトリクス項目
現在Mackerelのクラウドインテグレーションで取得可能な仮想マシンサービスのメトリクス項目はそれぞれ以下の通りです。
■共通するメトリクス
| AWS | Azure | Google Cloud | |
| CPU | CPUUtilization CPUCreditUsage CPUCreditBalance CPUSurplusCreditBalance CPUSurplusCreditsCharged |
Percentage CPU CPU Credits Remaining CPU Credits Consumed |
utilization |
| Disk | DiskReadOps DiskWriteOps DiskReadBytes DiskWriteBytes |
Disk Read Operations/Sec Disk Write Operations/Sec Disk Read Bytes Disk Write Bytes |
read_bytes_count write_bytes_count read_ops_count write_ops_count throttled_read_bytes_count throttled_write_bytes_count throttled_read_ops_count throttled_write_ops_count |
| Network | NetworkIn NetworkOut NetworkPacketsIn NetworkPacketsOut |
Network In Network Out Network In Total Network Out Total |
received_bytes_count sent_bytes_count received_packets_count sent_packets_count |
■クラウド個別のメトリクス
| クラウド | 分類 | メトリクス | 説明 |
| AWS | Status | StatusCheckFailed_Instance StatusCheckFailed_System StatusCheckFailed |
EC2インスタンスやシステムの正常性を監視するためのステータスチェック結果 |
| Disk (EBS) |
EBSReadOps EBSWriteOps EBSReadBytes EBSWriteBytes EBSIOBalance% EBSByteBalance% |
AWS EBS（Elastic Block Store）のI/O性能とバランスを監視するメトリクス群 | |
| Azure | VM Availability Metric | VmAvailabilityMetric | Azure VM の稼働可否を示すメトリクス |
| Google Cloud | Uptime | instance/uptime | Compute Engineが起動してからの累積稼働時間を示すメトリクス |
| ミラーリング パケット |
Mirroring bytes Mirroring packets Mirroring packets dropped |
ミラーリングされたトラフィック量とパケット数、そしてドロップされたパケット数を示すメトリクス | |
| Firewall | dropped_bytes_count dropped_packets_count |
Google Cloud の VPC ファイアウォールでドロップされたトラフィック量（バイト数）とパケット数を示すメトリクス |
■共通して取得しているカテゴリ
どのクラウドでも、CPU・Disk・Network関連のメトリクスは必ず取得しています。
どのクラウドでもクラウドインテグレーションを使用した場合メモリのメトリクスを取得することができず、仮想マシンにエージェントを入れる必要があります。Mackerelとしてはメモリのメトリクスはエージェントから取得する思想なのかなと感じました。
■クラウドごとの特色
共通メトリクス以外は、それぞれのクラウド特有の指標が追加されています。
AWS：EBSのI/O性能やステータスチェック（可用性）
Azure：VMの可用性を示す VmAvailabilityMetric
Google Cloud：ファイアウォールのドロップ数やパケットミラーリングなど、ネットワークセキュリティ関連のメトリクス
クラウドインテグレーションの設定手順
最後に各クラウドのMackerelクラウドインテグレーションの設定手順を比較していきます。
詳しい導入手順については、各ブログで紹介していますので、そちらをご覧ください。
設定手順の難易度
今回は以下の指標で導入手順の難易度を比較しています。
- 設定方法の種類
複数の設定パターン（GUI、CLI）が用意されているかどうか - 手順数（GUI）
GUIで設定する場合、完了までに必要なステップ数はどれくらいか - 設定手順の種類
複数の手順で設定可能か - 所要時間（GUI）
GUIで設定した場合、初期設定にどれくらい時間がかかるか
上記をまとめた結果は以下の通りです。
| AWS | Azure | Google Cloud | ||||
| 設定方法 | △ | GUI | 〇 | GUI、CLI | 〇 | GUI、CLI |
| 手順数(GUI) | 〇 | 13 | △ | 16 | △ | 15 |
| 設定手順の種類 | 〇 | ・IAMロール（推奨） ・Access Key IDと Secret Access Key |
〇 | ・Azure CLI 2.0 ・Azure Portal |
〇 | ・Cloud SDK ・Cloud Console |
| 所要時間(GUI) | 〇 | 3分2秒 | × | 7分2秒 | △ | 4分46秒 |
今回、AWS・Azure・Google Cloudのクラウドインテグレーション設定を実際に試してみました。その結果、設定のしやすさや所要時間に違いがあり、次のような印象を持ちました。
・AWS
最もスムーズに設定できました。手順数も少なく、公式ドキュメントを参照しながら進めても特に詰まる箇所はありませんでした。
全体的に直感的で、短時間で設定完了できる印象です。
・Azure
設定にやや時間がかかりました。公式ドキュメントで指定されている項目の場所をAzureポータル上で探すのに手間取ったことと、手順自体が多かったことです。その分、設定完了までに時間がかかる印象でした。
（慣れてないだけかもしれませんが。。。）
・Google Cloud
設定の大部分はスムーズでしたが、APIライブラリで必要なAPIを有効化する作業に少し手間取りました。公式ドキュメントに記載されて
いるAPI名と、Google Cloud Console上で表示される名前が異なる場合があり、確認に時間がかかりました。
ただ、それ以外の手順は問題なく進められました。
総じて、クラウドインテグレーションの設定は比較的簡単に行えると感じました。
AWS・Azure・Google Cloudそれぞれに特徴はありますが、公式ドキュメントを参照すれば、どのクラウドでも大きな障壁なく設定を完了できます。
おわりに
記事は以上になります。いかがでしたでしょうか？
詳細が気になった方は公式ヘルプをご確認ください。
今回は AWS、Azure、Google Cloud における Mackerelのクラウドインテグレーションを比較し、
「監視可能なサービス」、「取得できるメトリクス」、「設定手順」といったポイントを整理しました。
整理したことによりMackerelのクラウドインテグレーションでも、クラウドごとに細かな違いがあることが改めて分かりました。
Mackerelクラウドインテグレーションのメリットは、各クラウド上のリソースをMackerelのホストとして一元管理できることです。
これにより、複数クラウドを利用していても、統一された監視基盤を構築できます。
現状クラウドサービスによって利用できるレベルに差があるので、将来的にはどのクラウドサービスでも同じレベルでクラウドインテグレーションを利用できるようになると、さらに便利になると感じました。
これまで、部署内で Mackerelのクラウドインテグレーションに関する記事を投稿してきましたが、ひとまず今回の記事で一区切りとなります。最後までお読みいただき、ありがとうございました！
今後も、新しい気づきや皆さまに役立つ情報があれば、随時記事を更新していきます。
次回の投稿をぜひお楽しみに！