トップ > テクノロジー > 新入社員が新しいSkyWayのサービス監視機能を構築した話

新入社員が新しいSkyWayのサービス監視機能を構築した話

テクノロジー

はじめに

はじめまして。イノベーションセンター所属の @sublimer です。 2021年4月に新卒として入社し、現在はWebRTCプラットフォーム「SkyWay」の開発・運用の業務に取り組んでいます。 また、個人開発としてWebアプリケーションを作ったり、TURNサーバー(RFC5766)をC#で実装したりしています。 他にも、自宅サーバを運用したり、ネットワーク機器を触ってみたりもしています。 ちなみに推しRFCはRFC1149です。

今回は、現在SkyWay Betaとして提供中の新しいSkyWayのサービス監視機能を構築した話を紹介します。

SkyWayのサービス監視における課題

まずはじめに、現行のSkyWayが抱えていたサービス監視の課題について説明します。 現在のサービス監視には、以下の3つの課題がありました。

  1. VMを管理するコスト
  2. 障害発生時の架電
  3. ログ調査の手間

1. VMを管理するコスト

現行のSkyWayでは、管理用のVM上でZabbixを動かしてサービス監視を行っています。 Zabbixは非常に優れた監視用ソフトウェアですが、VMを管理する手間がかかるほか、監視サーバーのメンテナンスをしている間はサービスの監視ができないという課題がありました。

2. 障害発生時の架電

現行のSkyWayでは、社内の監視チームが障害時の状況把握や関係者への連絡といった一次対応などを行っていました。 新しいSkyWayでは、人に頼らず電話をかける仕組みを導入し、障害発生時の対応を自動化・省力化することとなりました。 Zabbixには、障害発生時に電話をかけるような機能は無いため、何らかのSaaSと連携させる必要がありました。

3. ログ調査の手間

SkyWayのアクセスログ・アプリケーションログは、Fluentdを用いてGoogle Cloud Storage(GCS)にアップロードされる仕組みとなっています。 ログ調査を行う際は、GCSから該当のログをダウンロードし、手元のマシンでgrepして調査しています。 調査の際は複数のVMのログを横断的に調査したい場合もあり、その都度ログをダウンロードして調査するのはかなり手間がかかっていました。

以上の課題を踏まえ、いくつかのSaaSやOSSを比較検討した結果、Datadog、PagerDuty、Google Cloud Loggingを用いて、新しいSkyWayのサービス監視を行うことにしました。

使用した各SaaSの役割

今回使用した各SaaSについて、その役割を簡単に説明します。

Datadog

VMのCPU使用率やメモリ使用量といった時系列の数値データ、「メトリクス」を収集します。 また、事前に設定した条件を満たした場合はアラートとして通知します。 メトリクスは、VMにインストールしたDatadog Agentから定期的に送信されるほか、Web APIを呼び出すことで、任意のデータを記録することもできます。

PagerDuty

DatadogやGoogle Cloud Loggingと連携させ、アラートの内容をモバイルアプリや電話で通知します。 予めオンコールシフトやエスカレーションポリシーを設定することで、柔軟な通知が実現できます。 また、誰が障害対応したのか、どういった対応をしたのかといった情報を記録でき、障害対応の振り返りに役立てることもできます。

Google Cloud Logging

ログを集約・転送するソフトウェアであるFluentdから送られたアプリケーションログやアクセスログを記録します。 ログを構造化しておくことで、Google Cloud Loggingで柔軟にフィルタリング・検索ができます。 また、複数のVMのログを一箇所に集約できるため、横断的にログを検索できます。

構築したサービス監視の全体像

アラート通知のフローは、以下の図のように設定しています。

もし、メトリクスやログの内容に異常があれば、PagerDutyにアラートの情報が送られ、モバイルアプリや電話経由で通知が行われます。 基本的には、まずアプリ経由で通知し、一定時間アクションがない場合に電話をかけるようにしています。 一方で、サービスの運用に致命的な影響を与えるアラートに関しては、即座に電話をかけるように設定しています。 これにより、DevOpsチームが即座に障害の対応ができるようになりました。

また、メトリクスのグラフを共有するために、DatadogからSlackへの通知も設定しています。 以前はZabbixのスクリーンショットを手動で撮影してSlackに共有していましたが、DatadogとSlackの連携設定により、スラッシュコマンドなどで手軽にグラフ画像の共有ができるようになりました。 さらに、メトリクスとアラートの情報を紐付けて表示するダッシュボードを作ることで、障害時の各種メトリクスの状態を確認しやすくなりました。

DatadogのカスタムAgentチェックを効率的に開発する

今回Datadogを導入した際に得られたtipsを共有します。 Datadogでは、デフォルトでCPU使用率やメモリ使用量などのメトリクスを送信できますが、実際のサービス監視を行う際は、これらのメトリクスだけではカバーしきれない場合があります。 その場合は、カスタムAgentチェックのスクリプトを作成することで、任意の値をメトリクスとして送信できます。 カスタムAgentチェック用のスクリプトの動作確認にはDatadog Agentをインストールする必要があるのですが、このインストールの手間を減らすため、 Docker Composeを用いて動作確認ができる仕組みを作りました。

以下のコマンドでPythonの仮想環境を作成し、カスタムAgentチェックのスクリプトを ./src/custom_example.py に、設定ファイルを ./conf.d/custom_example.yml 記述します。

$ python -m venv venv
$ . ./venv/bin/activate
$ pip install datadog-checks-base
  • ./src/custom_example.py
import random

from datadog_checks.base import AgentCheck

__version__ = "1.0.0"

class CustomExample(AgentCheck):
    def check(self, instance):
        self.gauge(
            "custom_example.value",
            random.randint(0, 10),
            tags=["env:dev"],
        )
  • ./conf.d/custom_example.yml
instances: [{}]

その後、以下の docker-compose.yml を用いてDockerコンテナを起動します。

version: '3'

services:
  agent:
    image: datadog/agent
    volumes:
      - ./src:/etc/datadog-agent/checks.d
      - ./conf.d:/etc/datadog-agent/conf.d
    environment:
      - DD_API_KEY=dummy-api-key

DD_API_KEY の環境変数を設定しないとDatadog Agentが起動しないため、ダミーの文字列を入れています。

Dockerコンテナが起動した後、ホスト側で以下のコマンドを実行することで、容易にスクリプトの動作確認ができます。

$ docker-compose exec agent agent check custom_example --table

=== Series ===
  METRIC                TYPE   TIMESTAMP   VALUE  TAGS
  custom_example.value  gauge  1646983404  5      env:dev

=========
Collector
=========

  Running Checks
  ==============

    custom_example (1.0.0)
    ----------------------
      Instance ID: custom_example:d884b5186b651429 [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/custom_example.yml
      Total Runs: 1
      Metric Samples: Last Run: 1, Total: 1
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 0, Total: 0
      Average Execution Time : 0s
      Last Execution Date : 2022-03-11 07:23:24 UTC (1646983404000)
      Last Successful Execution Date : 2022-03-11 07:23:24 UTC (1646983404000)

おわりに

新しいSkyWayでのサービス監視の概要とtipsを紹介しました。

元々学生時代からインフラの監視技術に興味があり、自宅サーバーなどでZabbixやPrometheusを使っていましたが、商用サービスの監視に関わる機会は無く、入社前から商用サービスの監視に挑戦してみたいと思っていました。 そのことを上長との1on1で話したところ、SkyWayのサービス監視について検証や構築を任せていただけました。新入社員であってもいろいろなことに挑戦できるSkyWayのチームは、とても居心地が良いなと思っています。

今回、一からサービス監視の仕組みを作りましたが、新しいSkyWayのサービス監視は始まったばかりです。 最強で最高のサービス監視体制を目指して、引き続き改善に取り組んでいきたいと思います。

最後に少しだけ宣伝です。 現在提供中のSkyWay Betaは、アカウント登録をするだけで、個人・法人問わずどなたでも使うことができます。 これまでのSkyWayには無かった機能も今後実装される予定ですので、ぜひ一足早く体験してみてください! フィードバックなどもお待ちしています!!

参考サイト

© NTT Communications Corporation 2014