オンプレサーバーへCloudWatchでの監視を導入するときに考えたこと。
はじめに
皆様こんにちは、あかいけです。
オンプレサーバーのログやメトリクスを、CloudWatchで収集/監視したいと思ったことはありますか?
私はあります。
オンプレサーバーをCloudWatchで監視するためには事前に作業が必要ですが、
最低限必要な設定は「CloudWatch Agentのインストールと設定」と「IAM認証情報の設定」のみです。
ただ実際に導入を検討する際に、色々と考えるべきことがあったのでこのブログにまとめました。
なおCloudWatch Agentの具体的な導入作業は以下のブログにまとめているので、よければご参照ください。
モチベーション
しかしなぜ、
オンプレサーバーをCloudWatchで監視する必要があるのでしょうか?
これはシステムによって様々な背景があるかと思いますが、大抵は以下のような理由で「既存の監視基盤からの移行が必要になった...。」という場合が多いのではないでしょうか。
- 既存監視サービス/サーバーのサポート切れ
- 運用工数削減の検討
- コスト削減の検討
そういった場合にAWSをすでに利用しているのであれば、CloudWatchに監視を集約するというのは候補にあがりやすいでしょうし、選択肢としてかなり合理的だと思います。
またCloudWatchはマネージドサービスであり、従量課金制ですし、色々便利なのですが、導入にあたり考えるべきことがいくつかあります。
これからそれを一緒に見ていきましょう。
1.何を取得・監視する?
当たり前ですが、まずは具体的に何を取得して何を監視するかを明確にする必要があります。
まずCloudWatch Agentではメトリクス、ログ、トレースの3種類のデータを収集できます。
上記の収集対象を考慮して、
基本方針は現行で監視しているものをそのまま対象とするのがベターかと思います。
ただし、せっかくの機会なので、これを機に監視対象を整理することをオススメします。
改めて見直してみることで、以下のような意外な発見があるかもしれません。
- このメトリクスなんとなく取ってたけど、何にも使っていないな…。
- そもそも取得する必要がなかった!
- このメトリクス、なんか上手く取得できていないな…。
- 設定が誤っており取得できていなかった!ただ今まで問題になっていないので、そもそも不要だったかも??
- 改めて見るとこのメトリクスも必要だな…。
- 初期構築時に監視対象として考慮が漏れていた!CloudWatchでは対象としよう。
特にCloudWatchは従量課金制で料金がかかるため、これらの見直しはコスト削減の意味でも重要だと思います。
2.どれぐらいコストをかけれる?
CloudWatchに限った話ではないですが、コスト面の検討は避けて通れません。
特にオンプレサーバーからのメトリクスはカスタムメトリクス扱いとなるため、EC2インスタンスの標準メトリクスと比べると料金が高くなります。
ここでは初期導入費用、ランニングコストの二つに分けて考えてみましょう。
初期導入費用
初期導入費用として、CloudWatch Agentの導入作業やネットワーク設定などの工数が想定されます。
これに関しては複数の要因で決まるため、具体的な作業ボリュームを洗い出してから検討すると良いでしょう。
- 工数に関わる要因の例
- 作業対象：具体的なサーバー台数
- 作業者：社内 or 外部委託など
- CloudWatch Agent導入方法：手動 or 構成管理など
ランニングコスト
ランニングコストとして、カスタムメトリクスの料金、ログの保存料金、API実行料金などが継続的に発生します。
さらに今後サーバー台数が増える予定があるなら、その分コストも増加していくことを考慮する必要があります。
具体的にどれぐらいのコストになるか、
東京リージョンを対象にしていくつかパターンで試算してみましょう。
※ ここでは無料枠は考慮していません
※ 料金は変更される可能性があるため、最新情報については公式ドキュメントを参照してください
パターン1: メトリクスのみ収集する場合
- 条件
- 対象サーバー：100台
- 対象メトリクス：3 (CPU、メモリ、ディスク)
- メトリクス収集間隔：1分間隔
- カスタムメトリクス料金: 300メトリクス(3メトリクス × 100台) × $0.30 = $90/月
- API実行料金: 100台 × 60回/時 × 24時間 × 30日 = 4,320,000リクエスト ≒ $43.2/月
- 合計: 約 $133/月
パターン2: ログも収集する場合
- 条件
- ログ：1台あたり1GB/月
- それ以外はパターン①と同様
- メトリクス関連: 約$133/月(パターン1と同じ)
- ログ取り込み: 100GB × $0.76 = $76/月
- ログ保存: 100GB × $0.033 = $3.3/月(標準ストレージの場合)
- 合計: 約 $212/月
パターン3: アラームも設定する場合
- 条件
- アラーム：1台あたり3つ設定
- それ以外はパターン②と同様
- メトリクス関連: 約$133/月(パターン2と同じ)
- ログ関連: 約$79/月(パターン2と同じ)
- 標準アラーム: 300アラーム(3アラーム × 100台) × $0.10 = $30/月
- 合計: 約 $242/月
いかがでしょうか?
「思いのほか高いなぁ…。」そう思った方もいらっしゃるのではないでしょうか?
しかもこれらは当然サーバー台数に比例して増えていくため、
最初に「何を取得・監視するか」を検討する必要があるわけですね。
なお、メトリクスの送信間隔は設定により1秒〜300秒の範囲で調整可能です。
間隔を長くすればAPI実行料金を抑えられますが、リアルタイム性は低くなります。
これに関しては、監視要件に応じて調整すると良いでしょう。
3.CloudWatchへのアクセス権限はどう管理する?
CloudWatchへメトリクスを転送するためには、オンプレサーバーにCloudWatchへのアクセス権限を持たせる必要があります。
EC2インスタンスであればインスタンスプロファイル(IAMロール)を使えますが、オンプレサーバーの場合はそうはいきません…。
最もシンプルなのはIAMユーザーのアクセスキーを発行して配置する方法です。
公式ドキュメントでもこの方法が紹介されています。
ただ社内やシステムのセキュリティポリシーによって、長期的なアクセスキーの発行自体が禁止されている場合もあるでしょう。
そんなときは以下のような代案を検討する必要があります。
代案1. Systems Managerハイブリッドアクティベーション
この方式では事前にSSM Agentを導入し、ハイブリッドアクティベーションという仕組みでIAMロールを指定します。
アクティベーションコードを使って一度認証することで、以降はIAMロールの一時認証情報を自動で取得してくれます。
この方式の場合もプライベートキーは発行されオンプレサーバーに配置はされますが、SSM Agentには認証情報の自動ローテーション機能があります。
自動ローテーションを利用することで、プライベートキーの有効期限を最小限としてセキュリティを担保しながら、ローテーションの運用負荷を削減できます。
またSystems Managerハイブリッドアクティベーション自体の料金についてですが、スタンダードインスタンスティアでは1,000台まで無料で利用できます。
ただし1,000台を超える場合はアドバンストインスタンスティアを利用する必要があり、その場合は追加の利用料金が発生します。
以上の理由から、個人的にはIAMユーザーが利用できない場合はこの方式が最もオススメです。
代案2. IAM Roles Anywhere
証明書ベースの認証を使いたい場合は、IAM Roles Anywhereという選択肢もあります。
この方式では認証局を用意して証明書を発行し、オンプレサーバーではその証明書を使って一時的な認証情報を取得します。
また認証局の用意にあたり以下の2パターンがありますが、
それぞれメリット/デメリットがあるため、採用にあたっては考慮が必要です。
- ACMプライベートCAを利用する場合：月額$400コストが発生
- 自前の認証局を使う場合：認証局自体、および証明書の運用管理が必要
4.CloudWatch Agentの初期設定/更新方法はどうする?
CloudWatch Agentを導入した後も、設定ファイルの更新やバージョンアップといったメンテナンス作業が発生します。
サーバーが数台ならまだしも、数十台、数百台となると手動での作業は現実的ではありません。
そのため導入前に、どのように設定を管理・配布するかを決めておくことが重要です。
既存の構成管理ツールを活用する
すでにAnsibleやChef、Puppetといった構成管理ツールを使っている環境なら、それらを利用して導入することが候補に上がると思います。
また既存の運用フローに組み込めるため、新たに覚えることも少なくて済みます。
Systems Manager Run Commandを使う
構成管理ツールを使っていない環境や、これから導入を検討している場合はSystems Manager Run Commandがおすすめです。
Run Commandを使えば、AWSコンソールやCLIから複数のサーバーに対して一斉にコマンドを実行できます。
特にCloudWatch Agentについては、AWSが公式で用意しているコマンドドキュメント(AWS-ConfigureAWSPackage)を使えば、インストールから更新まで簡単に行えます。
ただし事前にSSM Agentを導入する必要があります。
とはいえSSM Agent自体はAnsibleなどで初回だけインストールしてしまえば、以降の運用ではRun Commandを活用できるので、長期的には運用が楽になるのではないでしょうか。
5.オンプレサーバーからCloudWatchへどのように通信する?
オンプレサーバーからCloudWatchへデータを送信するには、当然ながらCloudWatchと通信できる必要があります。
この通信経路をどう確保するかも、導入前に検討すべき重要なポイントです。
インターネット経由で接続する
最もシンプルなのは、インターネット経由でAWSに接続する方法です。
オンプレサーバーからインターネットに出られる環境であれば、特に追加の設定は必要ありません。
CloudWatch AgentはAWSのパブリックエンドポイントに向けてメトリクスを送信することになります。
VPN or 閉域網経由で接続する
セキュリティ要件やネットワークポリシーの関係で、AWSへの通信をVPN or 閉域網経由で行う場合があります。
その場合もちろん、CloudWatchへの通信も同様の経路を通ることになります。
しかしCloudWatchのエンドポイント(monitoring.ap-northeast-1.amazonaws.comなど)はAWSのグローバルIPで提供されているので、ローカルIPしか参照できない環境では通信ができません。
そこでVPCエンドポイント(PrivateLink)を使って、プライベートIPアドレス経由でCloudWatchにアクセスできるようにする必要があります。
このとき、DNS名前解決の方式として以下の2つの選択肢があります。
方式1: Route 53 Resolverを使う
オンプレのDNSサーバーからAWSのResolverインバウンドエンドポイントを経由して名前解決する方法です。
この方式だと、XXX.ap-northeast-1.amazonaws.comのドメインはインバウンドエンドポイント経由で名前解決できるので、結果的にVPCエンドポイントのプライベートIPアドレスへアクセスできます。
ただオンプレ側でDNS設定が必要であり、
具体的には以下のどちらかの設定をする必要があります。
-
- オンプレのホストサーバーで設定する場合
- resolve.confで設定する
-
- DNSサーバーで設定する場合
- フォワード設定をする
方式2: endpoint_overrideを使う
VPCエンドポイントのDNS名をCloudWatch Agentの設定ファイルに直接指定する方式です。
CloudWatch Agentの設定ファイルにはendpoint_overrideというパラメータがあり、ここにVPCエンドポイントのDNS名を指定できます。
{
"metrics": {
"endpoint_override": "vpce-XXXXXXXXXXXXXXXXXXXXXXXXX.monitoring.ap-northeast-1.vpce.amazonaws.com",
......
}
}
VPCエンドポイントのDNS名はパブリックDNSサーバーで名前解決した場合でもプライベートIPを返すため、オンプレ側のDNS設定変更が不要となります。
逆にオンプレ上のサーバーが外部DNSを参照できない場合は、別途オンプレ側でDNSの設定が必要になります。
6.SSM Agentも導入する?
ここまで何度か「SSM Agentを導入する前提の方法」を書いてきましたが、CloudWatch Agent導入を機に、
Systems Manager(SSM) Agentの導入も本気で検討することをおすすめします。
特に既存環境をAnsibleなど構成管理ツールで管理していない場合は、導入する価値が高いです。
SSM Agentを導入すると、オンプレサーバーをAWS Systems Managerから管理できるようになり、様々な関連サービスが使えるようになるため、サーバー運用全般の効率化が見込めます。
具体的な導入方法や利用例は以下のブログにまとめているので、よろしければご参照ください。
さいごに
以上、オンプレサーバーへCloudWatch監視を導入するときに考えることをまとめてみました。
CloudWatchは便利なサービスですが、導入にあたっては認証方式、コスト、通信経路、運用方法など、考えるべきことが意外と多いです…。
特に台数が多い場合は、初期設定や更新の自動化を見据えた設計が重要になります。
本記事が皆様のCloudWatch監視導入の参考になれば幸いです。
