Amazon CloudWatch ダッシュボードの活用について

はじめに

こんにちは、サービスイノベーション部の桑村です。
業務は「LANSCOPE エンドポイントマネージャークラウド版　デバイス検査オプション」における運用や改善のフォローを担当しています。
「デバイス検査」は、Windowsデバイスに対して検査を行い、ポリシー違反があった場合は、警告ダイアログ表示やデバイスの利用制御を行うことができます。
「デバイス検査」の詳細については、こちらをご確認ください。

www.lanscope.jp

今回は、AWS固有の話になりますが、その「デバイス検査」チーム内で共有しているダッシュボードで実現したかったことをご紹介します。

はじめに
ダッシュボードとは？
Amazon CloudWatch Syntheticsとは？
ステップをダッシュボードに登録
実現したかったことは、達成できたか？
- 今後やっていきたいこととして
さいごに

ダッシュボードとは？

システム運用の文脈で使われる「ダッシュボード」とは、可視化されたデータ（メトリクス）の集まりを指します。
ダッシュボードのメトリクスは、あれもこれも追加したくなりますが、必要な指標に厳選して登録しました。
サービスを運用する際には、しきい値を設定し、超過した場合にアラートが通知される監視設定を行います。
これは、障害や問題が起こったときに早期発見できる仕組みで、私達ももちろん設定しています。

一方、このダッシュボードで実現したかったことは、「サービスが正常に提供できている状態を可視化し、チーム全体で共有すること」です。
「アラートの発報が無い＝サービスに問題ない」ではなく、ダッシュボードで「サービスが提供できている」を表現する必要がありました。
そのため、Amazon CloudWatch ダッシュボードに以下のメトリクスを設定しています：

管理画面のトップ画面の表示までの経過時間
管理画面でログインボタンを押してから、ログインできるようになるまでの経過時間
設定を変更し、保存が完了するまでの経過時間

1～3 の値の取得は、Amazon CloudWatch Synthetics を利用しています。

Amazon CloudWatch Syntheticsとは？

Amazon CloudWatch Synthetics(以下Synthetics)は、合成モニタリングや合成監視と言われるAWSのサービスです。

合成モニタリングについては、MDNのサイトから引用します。

developer.mozilla.org

合成モニタリングでは、エンドユーザーがウェブアプリケーションを介して進む経路をシミュレートするためのスクリプトを展開し、シミュレーターが体験した性能をレポートします。

合成モニタリングは、「人がブラウザを使ってサービス動作をチェックする」ことをシミュレートできるため、ログインボタンを押す動作などの検証も実現可能です。
過去には、決まった時間に特定の監視対象URLへ接続し、ログインを行う監視業務をしていましたが、こうした処理もSyntheticsを利用すれば容易に実装できます。
スクリプトを書く必要はありますが、最初はシンプルなものから始めると良いでしょう。
スクリーンショットを取得でき、実行についてはcron 式が使えるので、柔軟な運用が可能です。

Syntheticsには、次のようなランタイムが用意されています：

Puppeteer(Node.js)
Playwright(Node.js)
Selenium(Python)

ランタイムによって対応しているブラウザが異なるため、必要とするブラウザに合わせて使いやすいプログラム言語を選定することになります。
「デバイス検査」では、Selenium(Python)を利用しています。

実際の動作を確認してみましょう。
AWSのコンソールから
CloudWatch > Synthetics Canary > [Canary を作成]
で遷移できます。

「GUIワークフロービルダー」を選んだときのテンプレートを説明します。
8行目の url = "" と 24行目の By.XPATH, "" は修正が必要です。XPATHなどの要素はブラウザのデベロッパーツールで確認できます。
手順については、他のサイトでも詳しく紹介されているため、ここでは割愛します。

import asyncio
from selenium.webdriver.common.by import By
from aws_synthetics.selenium import synthetics_webdriver as syn_webdriver
from aws_synthetics.common import synthetics_logger as logger, synthetics_configuration
TIMEOUT = 10

async def main():
    url =  ""
    browser = syn_webdriver.Chrome()
    # Set synthetics configuration
    synthetics_configuration.set_config({
       "screenshot_on_step_start" : True,
       "screenshot_on_step_success": True,
       "screenshot_on_step_failure": True
    });

    def navigate_to_page():
        browser.implicitly_wait(TIMEOUT)
        browser.get(url)
    await syn_webdriver.execute_step("navigateToUrl", navigate_to_page)

    # Execute customer steps
    def customer_actions_1():
        browser.find_element(By.XPATH, "").click()
    await syn_webdriver.execute_step('redirection', customer_actions_1)
    logger.info("Canary successfully executed.")

async def handler(event, context):
    # user defined log statements using synthetics_logger
    logger.info("Selenium Python workflow canary.")
    return await main()

ステップをダッシュボードに登録

上記テンプレートには、execute_step という関数があります。
詳しくはこちら
docs.aws.amazon.com
を見ていただくと、ステップに分けて記述し、各ステップごとに「純粋な」経過時間を取得できることがわかると思います。
ここで「純粋な」と言っているのは、9行目にある browser = syn_webdriver.Chrome() のような初期化処理の時間を除外できる、という意味です。

ダッシュボード上では、1ステップ目を「ログインページの表示」、2ステップ目を「ログインボタン～デバイス一覧表」という形で分けて表示させるようにしました。
1つのスクリプトで各ステップの経過時間が取得できるのは、とても便利です。
また、ステップ単位でスクリーンショットも取得し、S3に自動で保存されます。

実現したかったことは、達成できたか？

チームメンバーにダッシュボードを見てくださいではなく、毎朝9時に1日分のダッシュボードのスクリーンショットをSlackのチャンネルに通知をしています。(SyntheticsとLambdaで実現)
「サービスが正常に提供できている状態を可視化し、チーム全体で共有すること」は、仕掛けとしては、達成しました。

この後は、プロジェクトメンバー全員が「提供しているサービスのページ遷移時間は、だいたいこのくらいなんだね」という共通認識を持つこと。
つまり、開発したサービスとAWSのサービスを組み合わせた結果のレスポンスがこれだ、という点を共有していきたいと考えています。

今後やっていきたいこととして

改修や作業後にレスポンスがどう変わったかを把握し、「良くなったね」と互いに称え合う。
個人やプロジェクトの目標として「◯◯を30％改善する」といった指標にする。

1の例として、下のダッシュボードを見てください。あるタイミングから変化が見られます。

これは、デバイス検査のサービス開始後に大きなメンテナンスを行った際の変化です。
もともと「管理できるデバイス数をスケールさせたい」という目標があり、インフラチームとアプリチームが協力して最適化を行い、その成果がこのダッシュボードに現れています。
時間の短縮だけでなく、レスポンスのバタつきも収まり、安定するようになりました。

途切れている瞬間は、ちょうどメンテナンスのタイミングです。
この変化を見ると、「やった甲斐あったね！」と思えるほどの改善が見られますよね。