サービスを運用していくうえで、デプロイ作業は必要不可欠であり、時には複雑で手間がかかるものです。そんな中で、多くの企業がチャットボットを活用し、簡単かつ効率的にリリースが行えるようにしているでしょう。

2014年にサービスを開始したnoteでも、デプロイbotを用いたリリースを実施してきました。noteの成長に伴い、デプロイbotも次々とアップデートされてきました。

• Heroku + Lita

• EC2 + Lita + Jenkins

• Slack Bolt + GitHub Actions + App Runner

今回の記事では、長年noteに勤めているEMの福井烈と、デプロイbotを開発しているSREチームの中村昴にデプロイbotの歴史と運用について話をうかがいました。

デプロイbotの歴史①：Heroku + Lita

– noteに入社して約9年のれつさんと、SREチームのばるさんにデプロイbotの歴史について話を聞いていきます。よろしくお願いします。

EMの福井烈です。よろしくお願いします。

SREチームのvaru3（ばるさん）です。よろしくお願いします。

– 早速ですが、noteのデプロイbotの歴史についてうかがっていきます。noteがリリースされた2014年頃はどのような状況でしたか？

私が入社した時から、すでにデプロイはチャットボット形式で行われていました。Slackからコマンドを入力してデプロイを実行する形式ですね。基本的な使い方は変わっていません。

今とはバックエンドで動作する仕組みが違いますよね。Capistranoを使って、SSHでGitHubのリポジトリにアクセスする形だったのではないかなと。

まさにそのとおりです。

– 2014年のリリース当時はHerokuを使用していましたよね？

ですね。noteがリリースされたときはAWSではなくHerokuを使っていました。なので、チャットボットもHerokuにLitaというRuby製のチャットボットを載せて運用していました。

noteのデプロイbotの歴史②：EC2 + Lita + Jenkins

– Heroku構成のあとのデプロイbotはどのように変わったのでしょうか？

EC2上にJenkinsを立てる形でフルリニューアルをしました。その際に、デプロイbotの名前が私が飼っている犬の名前である『moco（もこ）』に変わりました。

— mocoはつい最近まで稼働していましたよね。

去年くらいまで動いていたので、7〜8年くらいかな。

私が入社した2020年のときには、SlackからJenkinsに繋いでデプロイワークフローがしっかり構築されていました。その反面で、長年運用されているこもあってJenkinsのタスクが多くあって、「これは大変だな」という印象も受けました（笑）

– チャットボットを使ってデプロイしていくこと自体は、SREチームにとって一般的なことですか？

うーん、それは企業文化によるところが大きいですね。以前いた会社でもチャットボットはありましたが、デプロイはCLIを使って手動で行う方式でした。Slack運用に厳格なルールを設ける会社もあれば、自由にコマンドを作ってデプロイする会社もあると思います。

– なるほど。「チャットボットがあるから良い」というわけではないんですね？

CLIのコマンドでもチャットボットでも、デプロイの内容自体は変わりませんからね。ただ、整備されていること自体は良いことだと思います。誰がどのようなデプロイをしているのかが可視化もされますしね。

noteのデプロイbotの歴史③：Slack Bolt + GitHub Actions + App Runner

– ここからは、現在のチャットボット「neco（ねこ）」への移行について教えてください。名前の変更理由は何ですか？

以前の「moco」は愛されていましたが、動かなくなると「死んだ」と言われることがありました。れつさんのペットがそう言われるのは気になったので、わざと固有名詞を避け、「Next gEneration moCO」を略して「neco」と名付けました。

– 移行の一番の理由は何だったのでしょうか？

Ruby製のSlackボットのフレームワークが古くなり、現在のSlackbotの仕様と合わなくなっていました。mocoは途中からモンキーパッチで維持していましたが、サーバーレス化の方針もあったので移行することにしました。

– necoはSlack Boltで運用していますよね？

そうです。Slackが提供するライブラリの中で最も一般的なものを選びました。Slackでコマンドを入力し、GitHub ActionsのAPIを叩くシンプルな実装です。

– 苦労した部分はありますか？

特に大きな問題はありませんでしたが、最初にLambdaを使用していた部分をAWS App Runnerに変更しました。LambdaではSlackのレスポンス時間の制限によりタイムアウトすることがあったためです。App Runnerへの移行により、処理時間が長くても対応可能になりました。今後はECSへの移行を検討しています。

– その他に工夫した部分はありますか？

GitHub Actionsの承認仕様が複雑だったため、承認やキャンセルを容易にするための「slack-approval」というOSSを開発しました。Slackに表示されるボタンを押すだけで操作できるようになります。公開されているので、ぜひ利用してみてください。

自動化の注意点

– チャットボットの開発は特定の人に依存する傾向があると思いますが、現在の運用はどうでしょうか？

Slack Boltは簡単に扱えるため、特定の人に依存することは少ないです。それよりも、社内で使われているZapierなどが属人化しやすいですね。

※ noteでは作業の自動化をZapierで行っている。Googleフォームへの投稿をSlackで表示したり、資料のテンプレートを自動追記したり、全社員が様々な使い方をしている。

– 「これは誰が管理しているのだろう？」ということが時々ありますね。

そうですね。多くの人が使用しているため、退職者がでたときに移行する必要が生じることがあります。その点で言えば、コードが残ってバージョン管理されるSlack Boltで作成したアプリケーションは追跡しやすいかもしれません。

– Zapierで作成したものをSlack Boltに移行する予定はありますか？

全てではありませんが、移行したいものはいくつかあります。これはZapierが悪いわけではなく、使い分けの問題です。

– noteではエンジニア以外の人もZapierを使って自動化していますが、全社員がSlack Boltを学ぶ必要はありますか？

いえ、それは全然必要ありません。Zapierを使う方針で良いと思います。Slack Boltを使うかどうかも、エンジニアの使いやすさで決めていいかなと。

チャットコマンドを作りすぎると複雑化してしまう問題

– 今日はデプロイbotについて話を進めてきましたが、チャットボットに関して社内で今後取り組みたいことはありますか？

新しいものを作るというより、チャットコマンドが複雑化しているため、もっとシンプルな方法を探していきたいなと思っています。場合によってはチャットボットを使わずに、サービス自体のWeb UIから操作する方が簡単な場合もあるので。

コマンドを覚えきれなくなってきているので、SlackワークフローでUIを構築していく方向があるかもしれません。ボタンを押してコマンドを実行するような形式です。

それだとやっぱりWebからの操作で良いのかもしれません。どうやって集約すればいいのか考えるのが難しいですね。

– チャットボットにすることで逆に複雑になっている部分もある？

ですです。デプロイするだけならいいんですけど、オプションを付けたりすると逆に覚えることが増えてしまうことがあります。それだったら、CLIから直接コマンド打ったほうがいいかもしれません。

– なるほど

あと、noteでもSlackコマンドが増えてきているので、「/」を打つといろんなコマンドが表示されるじゃないですか？昔からいる社員なら理解できると思うんですけど、最近入った人にはわかりづらいかなって。

テクノロジーが進化し、社員も増えているため、適切なソリューションを選ぶことが重要ですね。

– 使っているものが良い悪いと決めるのではなく、どうやって使っていくかを考えることが重要なんですね

▼ こちらの記事はPodcastの音声を文字起こしして再編しました。実際の音声はこちら👇

▼noteの技術記事をさらに読みたい方はこちら