Cloludflare Workers導入でデプロイ時間を大幅改善。リリース頻度も二週に一度→毎日へ。

導入背景

※このレビューではNOT A HOTEL が提供するチャット機能（コンシェルジュプラットフォーム）での事例を紹介します。

前提として、コンシェルジュプラットフォームを実現するためにZendeskとSunshine Conversationsを利用しており、Webhookを経由してリクエストを送っています。
初期段階ではGoを使って開発をしていましたが、CI/CD経由でデプロイするとテストとビルドに15分くらい時間がかかっており、ちょっとした修正の確認がとても大変でした。

また開発環境もGCPに依存していて、コンテナのセットアップが必要だったり、berglasというGCPのシークレットマネージャーを利用したり、インフラのセットアップにTerraformとDockerを利用したりと複雑な状態でした。

Cloudflare Workers利用に至った背景・課題については、下記スライドにも記載していますのでご参照ください。
cf. https://speakerdeck.com/codehex/go-to-cloudflare-workers

比較検討したサービス

・Supabase
・Deno Deploy

選定理由

サービスを選定するに当たって重要視した主なポイントは

1. 開発環境の構築のしやすさ
   
2. デプロイにかかる時間
   
3. フルスタックで開発できる環境か
   
4. エコシステム
   

でした。 その中でも、Cloudflare WorkersはDB（D1）やQueue、AI Gatewayなど、他のプラットフォームにはないインフラ基盤を利用できた点、開発環境でDockerなどのコンテナを利用しなくても良い点に強いメリットを感じ、導入を決定しました。

導入の成果

Cloudflare Workersを導入することで、課題だった「デプロイに時間がかかる」「環境構築が煩雑」という点は解消されました。
ちょっとした検証をするために1minくらいでデプロイできるので、2週間に一回リリースしていた状態から、現在ではほぼ毎日リリース出来るまでに改善されています。

また、運用を手伝ってくれる方も環境のセットアップに迷いがなく、環境構築の楽さも実感しました。

導入時の苦労・悩み

外部との通信が発生しない限り、リクエストごとに Date.now() が固定されたり、DB（現在は GA）やQueueがベータだったこともあり不安定な部分があり苦労しました。

導入に向けた社内への説明

よく使う機能

アーキテクチャ

アーキテクチャの意図・工夫

Cloudflare Workersを使用してメインアプリケーションの開発・運用をしており、基本的にはCloudflare スタックで完結するようにしています。

またGCP上で、NOT A HOTELのデータベースから予約情報を取得するAPIを作成しているのと、LangChainを辞め、GPT-4 Turboを使用しています。

ツールの良い点

ツールの課題点

その他

NOT A HOTELでは、コンシェルジュプラットフォーム以外でもCloudflare Workersを活用しています。
ユースケースや課題を一覧でスライドで公開していますので参照いただければと思います。
cf. https://speakerdeck.com/codehex/sugushi-eru-cloudflare-workers?slide=28

ツールを検討されている方へ

導入しない理由がないくらいオススメです！
まずは気軽に導入してみてください！