見出し画像

プロジェクトにChatOpsを導入してみる

NISSAN NAKAME BLOG | 日産ナカメブログ

こんにちは。日産自動車の飯崎です。バックエンド&Webチームで、PoC(Proof of Concept)プロジェクトのバックエンドおよびインフラを担当しています。私が関わっているプロジェクトで効率的な開発・運用を行うために、ChatOpsの導入をしました。今回の記事では、AWSでの事例をもとにChatOpsの環境構築について、その概要をご紹介できればと思います。

ChatOpsとは？

チャット(Chat)と運用(Ops)を組み合わせた言葉で、チャットを介して様々な運用を行うことをいいます。この言葉自体そこまで新しくはないのですが、なかなか実際に採用する機会がありませんでしたので、今回のPoCプロジェクトで、実際に採用しどんな効果があるか検証してみることにしました。

どんな技術を使用するのか？

今回のプロジェクトはAWSを採用しています。また、業務の基本的なやりとりはSlackで行っていますので、この２つのサービスを利用します。AWSのChatbotと呼ばれるサービスを使用して、Slackから運用コマンドを実行できるようにします。今回のプロジェクトでは、ビルド、デプロイ、エラー通知、ログ収集、サービス再起動・停止、インフラ変更など、定常的な運用上必要になるコマンドをChatOpsで対応できるようにしました。

この記事では、そのうち、ビルドコマンドを例にとり、概要を紹介していこうと思います。

AWS Chatbotを利用する

AWSにおけるChatOpsの基本的なシステム構築は、AWS Chatbotを利用します。Chatbotに適切な権限を設定し、SlackのチャンネルとChatbotを連携させれば動作させることができます。そのセットアップ手順は、AWS内の記事 にありますので、ここでは省略したいと思います。Chatbotは、機能のひとつとしてLambda関数を呼び出すことができます。ビルドコマンドはこれを利用して実現します。

ビルドコマンドの処理の基本的な流れ

ビルドコマンドの処理の基本的な流れは、上図の通りです。Slackからのコマンドの投稿により、Chatbotを呼び出し、ChatbotはLambda関数を呼び出して、Lambda関数越しにAWSの各種サービスを呼び出します（今回はCodePipelineと呼ばれるAWSのパイプラインによってビルドを行います）。

Lambda関数は、好きな言語で記述することができます（今回はPythonを選択しました）。Lambda関数には、CodePipelineを起動するためのコードを記述します。

Lambda関数コードの例

このコードは、ビルドするブランチをパイプラインに渡し、ビルドを実行するという非常にシンプルなLambda関数の例です。Slackからコマンドを投稿すると、引数のeventにコマンドのパラメータが格納されます。これを利用してビルドするブランチを設定しています（なお、このコードは、簡素化のためにエラー処理などは一切おこなっていません）。

ここまでセットアップができたら、Slackからコマンドを投稿してみます。Chatbotと連携したチャンネルで、以下のようなコマンドを投稿します（@awsというメンションをつけると、Chatbotにコマンドを送ることになります）

Chatbotへコマンド投稿

この投稿は、payloadのパラメータを使用してtest-buildというLambda関数を実行する、というコマンドになります。この投稿がChatbotに正常に受け付けられると、実行して良いか確認が来ます。

Chatbotからの実行確認

Runボタンを押すと、しばらくして実行結果が返ってきます。

コマンドの実行結果

実行結果のPayloadのところに、Lambda関数で戻り値として設定した文字列「command accepted」が返ってきています。Slack上から、Chatbotに対してコマンドを送ることができ、その結果を受け取ることができました。

Slack Workflowを利用する

コマンドを送るために、前項では手打ちで@awsから始まるコマンドを投稿しましたが、毎回この長いコマンドを正確に打つのは大変です。ここをもう少し改善してみます。

この対応として、Slackの便利な機能であるWorkflowを利用して、コマンド入力を補助することにします。Workflowを利用すると、フォームに入力した内容をもとにして、指定したチャンネルにメッセージを投稿することができます。これを利用してコマンドを構築できるようにします。

ビルドコマンドをSlack Workflowで構成

上記のように、フォームで入力した内容をコマンド化してチャンネルに投稿するようにWorkflowを作成します。これにより、ダイアログベースでコマンドが作成できるようになります。Workflowを立ち上げると、下図のようなダイアログが現れ、必要事項を入力してSubmitを押せば、ビルドが行えるようになります。

Workflowのダイアログ

これでChatbotに対してコマンドを簡単に送ることができるようになりました。

通知の補完をする

Chatbotは、Lambda関数の結果を通知します。先程の例では「command accepted」が返ってきました。ビルドの実行者からするとビルドの結果を知りたいわけですが、このままではLambda関数の戻り値しか得ることができず、ビルドの結果は得られません。

そこで、別の仕組みを使ってビルドの通知を受け取れるようにします。ここでは、Codestar Notificationという仕組みを使ってビルドのイベントを受け取って通知するように構成します。

ビルドの通知を受け取る流れ

Codestar Notificationは、指定したCodePipelineのイベントをトリガーにしてSimple Notification Serviceにイベントを送り、Simple Notification ServiceはChatbotへそのイベントを配信する仕組みです。Codestar Notificationで対象とするイベントは、以下の４つになります。

  • codebuild-project-build-state-in-progress

  • codebuild-project-build-state-failed

  • codebuild-project-build-state-succeeded

  • codebuild-project-build-state-stopped

これらにより、ビルドの開始、および、ビルド結果（成功・失敗・停止）を受け取れるようにします。この構成をセットアップしたら再度ビルドコマンドを投稿してみます。すると、しばらくしてビルドの開始と結果の通知が届くようになります。

ビルドの開始と結果の通知

ビルド完了・失敗などの重要な通知の場合、これとは別に、Lambda関数を実行するようにして、例えば、担当者へのメンションを付加して、独自のメッセージで通知してもいいかもしれません。画面を見ていなくとも気づけるようになります（このプロジェクトでも実際にそのようにしました）

権限を管理する

運用を行うにあたって、コマンドを誰でも実行できるのは好ましくありませんので、ユーザーごとに実行権限を管理できるようにします。

Chatbotは、Chatbotに設定された権限(Chatbot Configurationに関連づけられたIAMロールの権限)で動作します。Chatbot Configurationによって、Slackチャンネルごとに権限を分けることができます。この仕組みを使ってユーザーの権限管理をします。

メンバーと許可するコマンドの対応付け

上記は権限の設定例です。開発、運用、管理といった用途に分けてプライベートチャンネルを複数作り、それぞれのチャンネルで実行できるLambda関数を制限したうえで、チャンネルのユーザーも制限します。これにより、チャンネルにいる人＝権限を持っている人、という分かりやすい管理が行えます。

効果はどうだったのか？

ここまでで、AWSを利用したChatOpsの構築について概要を紹介しました。実際にプロジェクトでChatOpsを運用したところ、以下のような効果が得られました。

  • 運用面の一部（ビルド、デプロイ、エラー対応など）は特定のメンバーに依存することなく誰でも行えるようになった。特に、エラーが発生した場合に、メンバー全員が察知・把握できるようになり、特定のメンバーへの依存を減らすことができた

  • Slack特有の利点だが、問題対応時に、直接話す必要がありそうな場合は、そのままHuddle（音声通話）に移行できる

  • 発行できるコマンドが定型化されているので、運用上ありがちな操作ミスがほぼ発生しなくなった

  • 操作手順がSlackのログに残るので、対応者以外でも状況がわかりやすくなった。メンバー間の対応引き継ぎも詳細はログで追えるので漏れがなく安心できる

  • ほぼ全ての操作がSlackだけで完結できるようになり、手間が感じられなくなった

その一方で、以下のような課題が見えてきました。

  • Slackとの連携部分（Workflowの対応、メンバー管理）は別管理になってしまう。Jenkinsなどでジョブやアカウントの一元管理をしていた場合はやや煩わしい

  • チャンネルの人数が多くなるとチャットログの見逃しが増えそう

  • ChatOpsで対応できない要素もあり、その場合は従来の対応が必要になる

  • 無駄な通知が多いと見逃しが多くなったり、通知に無関心になってしまいがち

これらに対するブラッシュアップはまだ必要そうです。

まとめ

今回のPoCプロジェクトでChatOpsを導入しました。AWS環境での構築例として、ChatbotとSlackを組み合わせることで、比較的容易にシステムを構築することができました。良い効果も多く得られた一方で課題もいくつか見えてきました。全体的には概ね利点の多い方法のように感じましたので、今後のプロジェクトでも取り入れていきたいと考えています。

私たち日産自動車中目黒オフィスでは、自由な発想から具体的に動くものを作っていく、という流れがあり、様々な面白いプロジェクトが生まれています。その中で、今回ご紹介したような試してみたい技術があればそれを取り入れて開発を進めることができ、組織や自分の成長にも繋げることができます。ご興味を持っていただけたら幸いです。