Amazon Connectで仮想マシンの異常を電話通知してみた

こんにちは、AWS事業本部の荒平(@0Air)です。

皆様の環境では、オンプレミスの仮想マシン監視はどのように行なっていますか？
監視ソリューションは非常に多く存在し、MackerelやZabbixなど、様々なツールを利用されているかと思います。

本エントリでは、Amazon Connect + CloudWatch のネイティブ構成で、仮想マシンの異常が出たら電話通知してくれるように構築してみました。

構成図

本エントリの構成図です。
オンプレミス・VMware Cloud on AWS上の仮想マシンから、CloudWatchに情報を集約し、SNS, Lambdaを経由してAmazon Connectからユーザーへコールします。

下準備

Amazon Connectでの電話通知を設定する前に、CloudWatchへメトリクス監視を確立する必要があります。
今回はオンプレミス環境の用意が難しかったので、VMware Cloud on AWSに仮想マシンを立てて検証します。
どちらの環境でも、手順に変わりはありません。

下準備が一番肝の部分で、以下のドキュメントに沿って、オンプレミスからメトリクスを収集できるようにします。

VMware Cloud on AWSの仮想マシンについては、以前にこちらの記事を執筆しているので、ご参照ください。

オンプレミスまたは、VMware Cloud on AWSの仮想マシンからCloudWatchにメトリクスが届いている状態であれば下準備は完了です。

以下のようなイメージです。（今回はCPU使用率を例にします）

作ってみる

(1) Amazon Connectインスタンスを作成

Amazon Connectインスタンスの作成については、AWS公式ワークショップで画面付きの手順が掲載されていたので割愛します。
このとき、発信用の電話番号も取得します。

(2) 発信制限の解除

デフォルトでは、Amazon Connect から日本で利用されている携帯番号(090 / 080 / 070)へ電話を発信することができません。
AWSサポートの画面から、制限緩和を行います。

ケースの種類は「技術」を選び、サービスに「Connect (Contact Center)」、カテゴリーは「発信通話の許可リスト国登録」を選択します。

制限解除を依頼する旨の申請文を記入し、手順(1)で作成したAmazon Conenct InstanceのARN、利用する国(Japan)、利用する電話番号の接頭辞(+8170, +8180, +8190)を入力します。

窓口の混雑状況によりますが、解除までに数日掛かる場合があります。

(3) コンタクトフローの作成

Amazon Connectの画面にて、コンタクトフローを新規で作成します。
「プロンプトの再生」モジュールにて、電話口で喋らせたい内容を設定します。

(4) 電話を開始するためのLambda関数

作成したAmazon Connect コンタクトフローを呼び出すためのLambda関数を作成します。
今回は電話を掛けるだけのシンプルな作りとしました。

import boto3

source_phone_number = '+819012345678' # Amazon Connectで取得した送信元の電話番号
destination_phone_number = '+819012345678'  # 宛先の電話番号
contact_flow_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'  # コンタクトフローのID
instance_id = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'  # Amazon ConnectのインスタンスID

def lambda_handler(event, context):
    client = boto3.client('connect')

    response = client.start_outbound_voice_contact(
        SourcePhoneNumber=source_phone_number,
        DestinationPhoneNumber=destination_phone_number,
        ContactFlowId=contact_flow_id,
        InstanceId=instance_id
    )

    return response

このLambda関数には、Amazon ConnectのStartOutboundVoiceContact の許可を与えます。
今回はマネージドルールの AmazonConnect_FullAccess を付与しました。

(5) SNSトピック、CloudWatchアラームの作成

Amazon ConnectとLambdaの繋ぎ部分を作っていきます。
まず、Lambdaに通知するためのSNSトピックをスタンダードキューで作成し、Lambdaのトリガーとして設定します。

続いて、冒頭のCPU使用率をトリガーとした、CloudWatchアラームを作成します。
詳しい各設定値については省略しますが、トリガーにしたいメトリクスを呼び出し、閾値を任意で設定します。

このアラームのアクションでは、先程作成したSNSトピックを指定します。

アラートが設定できたら、AWS CloudShellやAWS CLIなどで以下コマンドを実行し、電話が掛かってくることを確認します。
※ {CloudWatch-Alert-Name} は適宜、作成したアラート名に置き換えてください。

aws cloudwatch set-alarm-state --alarm-name "{CloudWatch-Alert-Name}" --state-value OK --state-reason "Message" 
aws cloudwatch set-alarm-state --alarm-name "{CloudWatch-Alert-Name}" --state-value ALARM --state-reason "Message"

無事に自身の携帯に電話が掛かり、メッセージが再生されました。

(6) テスト

オンプレミス、またはVMware Cloud on AWS上の仮想マシンにログインして、CPU負荷率を上げてみます。
Linux系であれば、以下のコマンドで負荷テストができます。CPUコア数に応じて回数を増やします。

# 開始時
yes > /dev/null &

# 終了時
killall yes

(参考) Windows OSの場合は、Microsoft提供のCPUストレスツールがあるため、これを利用しても良いと思います。

無事に手元へ電話が掛かってきました。

おわりに

オンプレミス・VMware Cloud on AWSの仮想マシン異常もAmazon Connectで素早く反応することができます。
CloudWatchのアラームを作る際に、「欠落データを異常とみなす」設定にしておくことで、仮想マシンの電源断にも対応できます。

なお、vSphere上でもCPU Highのアラートは出ていました。

また、本文中では言及しませんでしたが、CloudWatchのメトリクスで収集できるものなら何でもトリガーにできるので、例えばDirectConnectのアラートを作ってこの架電システムを取り入れるのもいいと思います。

このエントリが誰かの助けになれば幸いです。

それでは、AWS事業本部 コンサルティング部の荒平(@0Air)がお送りしました！

参考