管理画面のボタンを安心して押してもらうためにやったこと
Nota Tech Conf 2022 Spring day1 (2022/4/26) の発表資料です。
コメントはDay1 質問・雑談コーナー (2022)でも、
このページに書いてもらっても大丈夫です。
2021年３月に入社したHelpfeelエンジニアです。
最近の趣味
お絵かきアプリを作ったりしています。
「6502」の由来
はじめてのプログラミングがMOS 6502アセンブラだった。
ここ３年間くらいはハードウェアをやってないなあ……
詳しい自己紹介はHelpfeelで公開しています。
実例
HelpfeelとScrapboxの連携方法
Scrapboxに書いた記事は、１〜２時間に１回Helpfeelに自動で反映される。
Helpfeelを契約したScrapboxプロジェクトに対して、botを巡回させて実現している。
Googleのクローラーのようなもの。
しかし実務上では、なるべく早く記事を修正したい、botを待つ時間がないこともある。
たとえば
#書きかけ の記事を誤って公開してしまった！
緊急の事態が起きてしまった。
ヘルプ記事のタイトルは「アプリに緊急のアップデートを行いました」
なるべく早くユーザーにこの記事を提供して、適切な対策をしてもらいたい。
Heroku one-off dyno
話が変わって技術的な話、HelpfeelはHerokuにデプロイされている。
Herokuアプリはdynoという単位で構成されている。
> コンピューティングリソース、メモリ、OS、一時的なファイルシステムを備えた軽量の独立した環境です。
「コンテナ」という表現と似ている。
いくつか種類がある。
web dyno
ウェブサイトのserveを行うおなじみのdyno。
worker dyno
実行したいタスクが発生したとき一時的に使い、役目を終えたら開放される。
AWS LambdaやGoogle Cloud Functionsに似たイメージ。
one-off dynoでできること
Herokuのコンソールに入ってコマンドを実行する。
新しい機能をリリースして、マイグレーションやバッチ処理を実行するときなどに使う。
重いタスクも実行できる
one-off dynoは一時的に使うdynoだけど、連続最大24時間使える。
意外とめっちゃ長いですね
新しいインフラを構築せずに、Herokuの中だけでサーバーレスなことができる。
記事更新タスクの実行方法
緊急のときは、Herokuを使えるベテランがheroku runコマンドを使って、記事を更新していた。
heroku runを実行すると、one-off dynoが起動してタスクが実行される。
この方法だとコミュニケーションが発生して、実質いますぐ記事更新できない。
⇩人間を仲介していた箇所を自動化する。
いますぐ記事更新ボタンを作った。
ボタンを押すと、Heroku Platform APIによってone-off dynoを起動できる。
いますぐ記事更新ボタンの使い方
HelpfeelのDashboardにあるボタンを押すだけで記事更新できる。
※いますぐ記事更新ボタンは、ベータ版として一部のプロジェクトでのみ使えます。
ステータスが「更新中」になり、２〜３分待つと「完了」になる。
裏側でやっていること
Heroku Platform APIを叩いて、記事更新タスクを実行する。
＋安心して使うためにやっていること
dynoリソースやエラーの通知。
リアルタイムなステータス表示。
シンプルなREST API
Dyno Createエンドポイントで、新しいone-off dynoを起動できる。
Dyno Listエンドポイントで、現在起動しているdynoの情報や台数を取得できる。
one-off dynoを起動するスクリプトを書いて実験した。
zxスクリプトの話はなるべく割愛。
dynoリソースやエラーの通知
one-off dynoは最大で同時に50個まで起動できる。
これはHerokuのプラットフォームによる上限値。
ベータ版では最大10個までに制限をかけている。
これはHelpfeel側でかけている上限値。
将来のために、使えるdynoの数を予約しておきたい。
記事更新タスク以外でも、one-off dynoを使いたいタスクが生まれるかもしれない。
50個全部使ってしまうと、いざというときにheroku runコマンドを使えないかもしれない。
マイグレーションやバッチ処理を実行したいときなど、まれに使うことはある。
いまのところ、one-off dynoは同時に１〜２個使われる規模感。
しかし、
「いますぐ記事更新ボタン」は、2022年４月に一部のユーザー限定でリリースしたばかり。
ボタンを使えるユーザーは、これから増えていく予定。
現段階では、記事更新ボタンがどれくらい使われるかの予測が難しい。
one-off dynoを10個全部使われると、いますぐ記事更新ボタンを安定供給できなくなる。
サーバーリソースをSlackで通知する。
クロールが始まった通知
現在起動しているone-off-dynoの台数も通知する。
クロールが無事に完了した通知
クロールがエラーになった通知
リアルタイムなステータス表示
記事更新ボタンを押すと、ステータスが「更新中」になる。
２〜３分待つと「完了」になる。
ブラウザをリロードしないと、現在のステータスを確認できない仕様だった。
Ajax通信が使われる前の、ひとむかし前なウェブサイトなイメージ。
社内でいただいたフィードバック
💬「今どのくらい作業が完了してますといったパーセンテージなどが見れたらうれしい。」
💬「クロールの状況(ステータス)が分かりにくいところは要改善。」
💬「一度ボタンを押したらPC閉じてもいいですか？」
記事更新タスクをクライアントサイドで動かしている、と考えた方からの質問。
エンジニアだけでは気づきにくい質問でありがたかったです。
おもしろい。実装把握してると思い至らない発想ですね
待ち時間があるのってファイルのアップロードとかインポートとかがメジャーだから、その習慣かも
リロードしなくても、記事更新の状況をリアルタイムに確認できるよう修正した。
REST APIを生やして、一定時間ごとにfetchする。
ベータ版とはいえ、状況の確認しやすさは当たり前品質だなと思った。
その他
記事更新の「中止ボタン」というのも考えたけど、ベータ版では実装を見送った。
印刷中のプリンターを止めるような感覚で押せるボタンを目指していた。
幻になった「中止ボタン」
その他にも記事更新ボタンのUIを改善中。
記事更新ボタンによる変化
Before
緊急で記事更新したいときに連絡を取る必要があった。
コミュニケーションに時間がかかる。いますぐ記事更新できない。
1〜2時間待って、Helpfeelのbotが巡回するのを待ったほうが楽。
heroku run コマンドを使っていた。Herokuの権限を持つベテランしか使えない。
コマンドを間違えると危険。
After
Notaの新しいメンバーや一部の顧客も、いますぐ記事更新できるようになった。
コミュニケーション不要、ボタンを押すだけになった。
Notaの新しいメンバーや一部の顧客も、いますぐ記事更新できるようになった。
安心して記事更新できるようになった。
dynoリソースやエラーの通知、ステータスの表示、……
2022年４月18日に「いますぐ記事更新ボタン BETA」をリリースした。
正式版リリースに向けて、Slack通知を見ながらテコ入れ中。