この記事は、NTTコミュニケーションズ Advent Calendar 2023 23日目の記事です。
はじめに
はじめまして。イノベーションセンター テクノロジー部門 OsecT-Ops プロジェクトの鄭(GitHub: nbhgytzheng)です。2021年度入社で、現在はオペレーショナルテクノロジー(OT)セキュリティリスク可視化サービス OsecT(オーセクト)の開発・保守運用業務に取り組んでいます。OsecTについては過去にブログで紹介していますので、ご興味がある方はご覧ください。
- 制御システムのセキュリティと対策技術OsecTのご紹介(前編)
- 制御システムのセキュリティと対策技術OsecTのご紹介(後編)
- OsecT、サービスリリースしました
- OTセキュリティリスク可視化サービス OsecT、リニューアルしました
今回は技術ブログへの2回目の投稿で、前回はOsecTで利用しているZeekとZeekのプロトコル拡張ツールであるSpicyについて紹介しました。パケット解析に興味がある方は是非【日本初紹介】Zeek・Spicyの使い方まとめをご覧になってください。
本稿では定形作業化された保守運用の作業を自動化したことについて紹介します。GCP(Google Cloud Platform)のみで実現しているため、OsecTだけでなく異なるサービス・プロダクトにも適用できます。
自動化前の保守運用
はじめに自動化前の保守運用についてお話します。なお、ここでは原因及び対処方法がマニュアルレベルで確立されている保守運用のみについて言及しています。
OsecTのシステムでは障害時などの原因分析に必要なSyslogなどログをCloud Loggingで収集しています。また、システムが特定のログを検知した場合、保守運用チームにCloud Monitoringで通知して、保守運用チームが作業をしています。
自動化後の保守運用
サービス契約数が増えるにつれて、保守運用の負担も増えていくため、すでにマニュアルレベルで対応が確立されている部分の自動化をしようと考えました。マニュアルを使って人手で対応すると、オペレーションミスの可能性もあるため、この点でも自動化は有効です。
GCPの機能を調査した結果、Cloud Pub/SubとCloud Functionsを利用すれば、自動化できることがわかりました。各機能を追加した後のイメージは以下のとおりです。
Cloud Pub/SubとCloud Functionsを追加することで、アラートの発生から対応までのプロセスが自動化できました。これにより保守運用チームの負担およびオペレーションミスの軽減につながります。 今回は「Cloud Pub/Subからtesttestというメッセージが転送されたら、GCP上のメッセージが出しているインスタンスにアクセスし、実行中の全てのコンテナを再起動する」という例で自動化のしくみを紹介します。
自動化に利用したGCPの機能紹介
本章では自動化に利用したGCPの機能を紹介します。エラー発生から復旧までの各機能間のつながりは以下のとおりです。
Cloud Logging
Cloud Loggingはストレージ、検索、分析、モニタリングをサポートするリアルタイムのログ管理システムです。Cloud Loggingを利用すると、対象リソースから自動的にログを収集できます。Opsエージェントのインストール及びコンフィグファイルの設定により利用できます。これにより、ログが収集されてGCPログエクスプローラーでログ検索などができるようになります。
ログルーター
ログルーターはCloud Logging内の特定のログを転送する機能です。以下のように設定すると、inclusion filterで設定した testtest
を含むログが指定されたCloud Pub/Subに転送されます。
Cloud Pub/Sub
Cloud Pub/Subは、メッセージを生成するサービスを、それらのメッセージを処理するサービスと切り離す、非同期のスケーラブルなメッセージング サービスです。今回の自動化では特定の文字列に対して、後述のCloud Functionsを動かすために利用しています。
Cloud Functions
Cloud Functionsはクラウドサービスの構築と接続に使用するサーバーレスのランタイム環境で、Python、Ruby、Javaなどさまざまなプログラミング言語をサポートしています。今回はCloud Pub/Subから転送されたメッセージを確認し、特定の操作をできる環境を作成しました。以下はPythonで実装したコードの一部です。転送されたメッセージはJSON形式でcloud_event.dataに保存されていおり、辞書型として中身の情報をアクセスできます。
なお、Cloud FunctionsからインスタンスへのアクセスはVPCコネクタの設定が必要です。具体的なコーディングはCloud Functionsの公式サイトを参照してください。
以上の設定により、エラーが発生すると自動で対応できるようになります。
自動化による実行結果
インスタンス上でSyslogにtesttestというメッセージを書き込むと、ログエクスプローラに以下のメッセージが表示されます。これは自動対応済みであることを意味しています。
インスタンスにアクセスしてコンテナの状態を確認すると、正しく再起動されていることがわかりました。
USER@instance-demo:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES xxx image_name "/usr/bin/testtest" 21 seconds ago Up 19 seconds test_container_name1 xxx image_name "/usr/bin/testtest" 21 seconds ago Up 18 seconds 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp test_container_name2 ... ...
まとめ
今回はGCPの機能のみを活用して、マニュアルなど手順が確立された障害対応を自動化しました。自動化のポイントであるCloud Functionsは汎用性が高く応用範囲も幅広いです。引き続き、定形作業を自動化しつつ、より障害が発生しにくい仕組みや構造に向けた取り組みを続けていきます。