非同期朝会ボットを作った話 / Create serverless-daily-standup-bot

2018/10/05 に社内勉強会で発表した時のスライドです。

Transcript

1. 非同期朝会ボットを作った話 @tsub FFTT 2018/10/05
2. 自己紹介 • (主に) インフラエンジニア • コンテナ大好き • 好きなエディターは NeoVim • Arch Linux たのしい @tsub (高山 翼)
3. チームでの朝会の様子
6. このやり方でかれこれ４ヶ月くらい • リモートワークの全社的な導入がきっかけ • 月〜木はオンライン、金はオフライン • 金曜日のオフライン朝会は話したいことが溜まるからか少し時間かかり気味 • 誰かがリモートワークしている日だけやり方を変える、というのは大変なので常にリモートワークを考慮したやり 方にしたかった
7. チームでの決まりごと • 朝の時点で全員書く(だいたい 10:30 までには) • 他の人の投稿は全て読んで必ずリアクションを付ける
8. オンライン朝会をやっていて良かったこと • 複数の朝会に参加している場合の共有が楽 (リモートのとき) • 遅刻・お休みしても後から見れる・書ける • 聞き逃す心配がない • リンクなども貼れる
9. 非同期朝会ボットについて
10. geekbot Misoca さんで使っているという話から気になっていた。 実際使ってみると必要十分感があってピッタリハマった。 ただ、現状朝会だけで使うことを考えると料金に見合わずやめてしまった。 これくらいなら作れるんじゃない？ということで @tsub がやる気になった。
11. 自作する前に 既存のサービスで要件を満たせるものがないか調べた。 が、どれも有料だったり表示フォーマットが合わなかったりで断念。 ・https://standuply.com ・https://standupjack.com ・https://standupbot.com ・https://tatsu.io ・https://www.standupalice.com ・https://jell.com/slack ・https://standbot.softwaredevtools.com ・https://www.stehauf.io ・https://scrumbot.sifts.io
12. tsub/serverless-daily-standup-bot geekbot を止めた翌日からひっそりと土日に作っていて月曜日にいきなり導入。リリース後は脳汁出そうだっ た。 ただ初日は動作確認が不十分でちゃんと動かなかったので運用でカバーした。 目に留まりやすいように名前に “serverless-” を付けた。
13. アーキテクチャ
14. 最初のアーキテクチャ
15. ただし微妙なところがある 直近の社内勉強会の発表を聞いて、これだ！となって最初は Step Functions を使っていた。 けど、質問の回答が来るまでループして無駄な function を実行したり、並列実行も並列数を動的に決められず StepFunctions の旨味を全然受けれてなかった。 冷静に考えてみると、サーバーレスアーキテクチャの本質はイベントドリブン (って誰かが言ってた) なので、この 場合の StepFunctions は筋が悪い。 しかも誰かが仕事を休むと、ずっとステートマシンが起動しっぱなしになる。
16. 新アーキテクチャ DynamoDB Streams を使い、質問の回答が書き込まれたら次の質問を送るようにした。 すべての回答が揃ったら特定のチャンネルにサマリを送信する。 これによって無駄なループがなくなる。
17. 新アーキテクチャ
18. 使い方
19. 初期設定 Slash コマンドと Interactive messages を組み合わせて実装。 /daily-standup-bot setting で設定できる。 ただし Slack だけでやろうとすると制限が多いし実装も複雑になるので厳しい。 素直に Web アプリ作ったほうが楽。
21. 初期設定が難しすぎる select フィールドは複数選択ができない。 textarea フィールドはユーザー名の補完が効かない。 Slack 側でユーザー名をユーザー ID に変換する API もない。ので、ユーザー ID を書いてもらうしか。 スケジュール設定は CloudWatch Events の cron 式 そのまま (これはパーサー書いてなんとかしたい )。 ちなみに Dialog はフィールドが 5 個まで。 なのでこういう設定方法にならざるを得なかった ...
22. これからやろうと思ってること
24. 特に優先順位が高めなのは • README を整備してちゃんと OSS らしくする • FF 本番環境へのデプロイ自動化 (現状ぬくもりのある手動デプロイ ) • 送信済みメッセージの編集機能 • 設定の削除機能 • ...etc
25. 無駄に頑張った ローカル実行するための仕組み
26. SAPessi/serverless-sam serverless FW は Go ランタイムのローカル実行に非対応。 sam-cli は対応しているため、YAML を変換するために使用。 まったくメンテされてないので npm audit に引っかかる。 バグもあるので正直おすすめはしない。 例えば serverless FW の ${env:HOGE} みたいな記法を解釈してくれない。 “DynamoDB” と記述するところを単純にキャメルケースにして “Dynamodb” にしてしまってる。 → sed で解決！
27. awslabs/aws-sam-cli AWS 公式ツール。 Go ランタイムのローカル実行にも対応している。 function 実行ごとに docker pull が走る。 function のコードが zip の場合は実行ごとに解凍する。 どちらも予め済ませておいて skip オプション付けて実行することで Slack の Webhook のタイムアウトをギリギリ回避できる。
28. ngrok localhost の Web サーバーを外部に公開できる。開発向け。 https でのアクセスも可能。 Web UI でリクエストの中身とかも見れる。 起動すると top コマンドみたいに全画面使われるのが地味に困る。
29. oxequa/realize Go 向けのタスクランナー。 YAML を書いておけばコードの変更を watch して再ビルドなどしてくれる。 go build だけじゃなく go run, go vet, go fmt なども実行できる。
30. 全体の流れ 1. serverless-sam プラグインで SAM の YAML を書き出す 2. serverless-sam プラグインがバグっているので sed で YAML を修正 3. zip は予め解凍 4. Docker イメージも予め pull 5. sam local でローカル実行 6. ngrok で外部に公開して Slack から叩かせる 7. realize でコードを watch して自動再ビルド
31. Tips
32. 他チャンネルにリンク貼っても展開されない件
33. シェアを使えば展開される
34. まとめ
35. サーバーレスアーキテクチャは楽しい 仕組みを考えるのは楽しい。けど難しい。 アイデア勝負的なところがあって、どのサービスを組み合わせてどういう風に設計するかがかなり自由。 ただスケーラビリティを考慮して、となると途端に難しくなる気がする。 イベントドリブンに則っていればとりあえず間違いはない。
36. アプリ公開しないの？ Web サービス化や Slack アプリ公開は今のところ厳しい。 CloudWatch Events のスケジュールを使っているためそこがボトルネック (あれ？どこかで聞いたような ...) それよりは OSS 化して使いたい人がデプロイして使えばいいかな感はある。
37. ぜひ使ってください！ /daily-standup-bot setting を叩けば社内の誰でも設定可能 Go のリファクタリングとか PR も募集！ とはいえうちのチームぐらいしか使わないだろうなぁとは思ってる。
38. そして気づいてしまった... 無料で使える Standup Alice が要件を満たしていたっぽいことを ...