Cloudflare Workersを使用した、記事投稿Webアプリケーションのバックエンドサーバー移行事例

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社Gemcook / soso

バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 10名以下

最終更新日2024/09/13投稿日2024/08/13

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2024年1月	B to B

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

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

元々の構成ではAmazon ECSとAWS Fargateを用いてバックエンドGraphQLサーバーを構築していました。

今回のアーキテクチャではバックエンドサーバーをCloudflare Workersに構築しなおしました。同時にバックエンドの構成やDBも置き換えており、ランニングコストが低くなるようにしています。

導入の背景・解決したかった問題

導入背景

前提として、記事投稿Webアプリケーションのバックエンドサーバーの事例となります。

ツール導入前の課題

導入前のバックエンドサーバーはAWS ECS&Fargateを用いてコンテナ形式でデプロイしていました。このソリューションは豊富なスケーリング設定とコンテナによる柔軟性を持ち便利ではあるのですが、PoC開発や小規模アプリケーションではオーバースペックと感じることが多々ありました。そのためよりコストが低く開発速度を出せる構成を求めていました。

比較検討したサービス

AWS Lambda
Cloud Run
AWS ECS&Fargate
Supabase

比較した軸

小〜中規模なWebアプリケーションのバックエンドサーバーとして耐えられる拡張性・可用性があるか
開発者体験
- デプロイ時間の短さ
- デバッグログ機能
サーバーレスであること
- マネージド
- 人的管理コストの低さ
- 従量課金

選定理由

Cloudflare Workersをバックエンドサーバーとして採用するにあたり決め手になったポイントは以下のとおりです。

R2やD1及びQueueといった周辺Cloudflareサービスのサポートがあること
デプロイ時間の短さ
環境構築の簡単さ
最低コスト及びリクエストが増えた場合の全体的なコストの低さ

主に開発速度とコストの低さを重視しています。

導入の成果

デプロイ時間の短縮や、日常的なコストの削減などの成果がありました。

導入時の苦労・悩み

これは事前に分かっていたことですが、Cloudflare WorkersはNode.js互換ではないため使用できるNode.js APIには制限がかかります。そのためNode.js向けのライブラリが動かないことを覚悟して導入する必要がありました。（設定で一部polyfillを有効にすることは可能）後は苦労した点として、まだ世の中に知見が少ないため参考にできるプラクティスが少なく、色々なライブラリのIssueやコードを読みながら自分たちに最適な構成を組み上げていくのはなかなか大変でした。