世の中にある全てのシステムは、障害が発生する可能性があります。障害が発生しシステムが停止すると、会社の信頼問題、利益損失に繋がる可能性もあります。そのようなトラブルからシステムを守るために、障害に強いシステム環境をAWSで構築する際のポイントをご紹介します。本記事は前編、後編に分けてAWSを使って障害に強い環境を作るポイントをご紹介する予定です。今回の前編では、システムの監視に焦点を当ててご紹介していきます。
目次
障害の発生例
システムを運用していく中で、様々な障害が想定されます。サーバダウン、ネットワークダウン、人的な操作ミス、天災、外部からの攻撃などが考えられます。また、AWSそのものに障害が発生した例もあります。過去には、AWSのデータセンター内で冷却システムの故障により多くのAmazon EC2（以降、EC2）が停止したり、人為的操作ミスによりAmazon S3コンソールに障害が発生、また原因は公表されていませんが、Amazon EBSボリューム 、AWS Lambda（以降、Lambda）等に障害が発生したことがあります。AWS内でも障害が発生することを前提に、障害を想定してAWS環境を設計する必要があります。
システムの監視
障害に備えるため、まずシステム全体を監視し異常が発生したことに気が付く事はとても重要です。そこで、AWSでシステム環境を構築した場合の監視方法についてご紹介します。
Amazon CloudWatchのご紹介
Amazon CloudWatch(以下、CloudWatch)とは、AWSリソースとAWSで実行されているアプリケーションをリアルタイムでモニタリング出来るAWSサービスです。例えば、EC2からCPU使用率、ディスクのI/O回数、ネットワークトラフィックなどのメトリクス（監視項目）を取得します。
CloudWatchアラームでは、CloudWatchメトリクスが閾値に達した際にアクションを実行できます。アクションは、Amazon Simple Notification Service（Amazon SNS）やAmazon EC2 Auto Scalingに送信することができます。さらにAmazon CloudWatchを詳しく知りたい方は、下記記事をご確認ください。
【AWS入門】Amazon CloudWatchを活用してシステム監視を自動化しよう｜AWS活用法
AWS運用管理の定番！「Amazon CloudWatch」でできること| AWS活用法
Zabbixを活用する
EC2のOSから上のレイヤーの監視にZabbixを導入するケースもあります。ZabbixはAWSの機能ではなく、サーバ、ネットワーク、アプリケーションを集中監視するための、オープンソースの統合監視ソフトウェアです。CloudWatchのカスタムメトリクスを作りこむことでOSから上のレイヤーの監視も可能ですが、Zabbixではより簡単な設定でOS、アプリケーションを監視することができます。例えばカスタムメトリクスで10台のEC2の上で動いているOS、アプリケーションの監視を行う場合、各EC2に対して設定が必要になります。例えば10台のEC2に100個の監視項目を設定したい場足、10台×100項目の設定をEC2 1台1台に設定する必要があります。これは構築、運用面を考えると現実的でないでしょう。これをZabbixで実現する場合、例えば1台のZabbixサーバを立て、10台のEC2の100個の項目を一元監視することが可能になります。
CloudWatchとZabbixを組み合わせる理由
ここまでの説明から、Zabbixだけを使ってAWS環境を監視すれば、設計、構築、運用においてシンプルなように感じるかもしれません。ここでは、CloudWatchとZabbixを組み合わせてAWS環境を監視する理由をご説明します。
それぞれに監視範囲が異なる
ZabbixはAWS内のEC2に加えて、外にある物理的なネットワーク機器も監視できます。Cloud WatchはEC2を含め、AWS内部のみを監視します。Cloud WatchではAWSの外にある物理的なネットワーク機器等を監視できません。またZabbixはAWS内のサービスのほとんどを監視できません。例えばLambda、Amazon CroudFront、Amazon RDSなど、システムを構築する際に使う多くのAWSサービスを監視できないわけです。CloudWatchでしか監視できないサービスにはClowdWatchを、Zabbixでしか監視できない機器にはZabbixを使うことになります。
CloudWatchでAuto Recoveryを活用できる
Auto Recoveryとは、メトリクス監視（アラーム）をトリガーとする EC2 インスタンスの自動復旧の仕組です。メトリクス監視で対象のEC2を監視し、障害を検知するとEC2が自動復旧します。Auto Recoveryを使うためには、CloudWatchで対象のEC2を監視しておく必要があります。他にも、Auto RecoveryやAuto Scalingなど、メトリクス監視をトリガーにEC2を自動的に調整する機能があります。
監視ツールについて
CloudWatchと組み合わせて活用できる監視ツールは、Zabbix以外にもDatadog、Nagiosなどがあります。それぞれ機能に違いがありますので、事前にシステムの運用方法を検討したうえで、どの監視ツールを活用するか決めた方が良いでしょう。
CloudWatchを活用し課題を解決した事例
仰星監査法人様は既存のAWS環境において、CloudWatchの活用方法、AWSアカウント内の構成管理などに課題がありました。TOKAIコミュニケーションズが課題解決をお手伝いし、より安心して利用できるAWS環境へと変わりました。
導入事例の中でも紹介しておりますが、TOKAIコミュニケーションズは24時間365日でAWSの障害を感知、障害の解決をお手伝いする運用管理サービスを提供しています。ぜひご活用ください。
まとめ
今回の記事では、AWSでシステム環境を構築した際の監視方法についてご紹介しました。システムの監視は、そのシステムの規模に関わらず運用していくために必ず必要となる要素です。そのため設計段階からよく検討する必要があり、経験豊富なITベンダーを活用することをお勧めします。TOKAIコミュニケーションズでは、多くのAWS環境の設計、構築を手掛けてきたAWS専任チームがお客様をサポートします。ぜひお気軽にご相談 
ください。
次回の記事では、監視以外のAWSで障害に強いシステム環境を構築するポイントをご紹介したいと思います。
