GraphQL Server on Edge

Workers Teck Tolks #1

Transcript

1. GraphQL Server on Edge
   Workers Tech Talks #1
   2023.07.19
   

   View Slide

2. 目次
   ● (GraphQL) API Server 構築
   ● サーバレスコンテナサービスの運用課題
   ● Cloudflare Workersという選択肢
   ● ユースケース
   ● まとめ
   

   View Slide

3. 今日話すことの細かい実装はこちら
   

   View Slide

4. (GraphQL) API Server
   ● APIサーバはどこにどうやって建てますか？
   ○ Amazon Web Services(Fargate, App Runner, EKS)
   ○ Google Cloud(App Engine, Cloud Run, GKE)
   ○ Azure(Container Instances, Container Apps, AKS)
   ○ オンプレ
   ● Backend for frontend(BFF)の設計になるとAPI
   Serverの管理者は誰？
   ○ バックエンド？
   ○ フロントエンド？
   

   View Slide

5. (GraphQL) API Server
   私の場合は、初手は大体Cloud Run
   ● サーバレスアーキテクチャにしてインフラコストを
   極限まで下げる
   ● 最終的にデータがBigQueryに行くことが多いの
   で、Google Cloudは結局使うことになる
   ● アプリケーションが最終的にコンテナで動けば、他
   に移行もそこまで難しくない
   

   View Slide

6. サーバレス(コンテナ)サービスの運用課題
   Cloud Runに限らず、サーバレスも銀の弾丸ではない
   ● コンテナのデプロイまでの時間がかかる
   ● コールドスタートを短く抑えないといけない
   ● コンピュータリソースあたりの単価は高め
   

   View Slide

7. さて、どうしよう？？🤔
   

   View Slide

8. Cloudflare Workersという選択肢
   パブリッククラウドのサーバレスサービスと比較して異なるところ
   ● ビルドしたファイルをデプロイする
   ● V8エンジンをランタイムとして採用
   ● 基本料金$5で、最低100万リクエストは処理できる
   

   View Slide

9. Cloudflare Workersという選択肢
   パブリッククラウドのサーバレスサービスと比較して異なるところ
   ● ビルドしたファイルをデプロイする
   → コンテナを入れ替えるより高速にデプロイが可能
   ● V8エンジンをランタイムとして採用
   → V8 isolateを使用することで高速に起動できる
   ● 基本料金$5で、最低100万リクエストは処理できる
   → 計算リソースあたりの単価が非常に安価
   

   View Slide

10. Cloudflare Workersという選択肢
    なんで今まで選択されてこなかった？
    ● Cloudflareにロックインする
    ● ランタイムがNode.jsではないのでNode.jsに依存する資産は使用できない
    ● Cloudflare WorkersからRDBMSに接続するにはhttpで接続するしかなかった
    

    View Slide

11. Cloudflare Workersという選択肢
    なんで今まで選択されてこなかった？
    ● Cloudflareにロックインする
    ● ランタイムがNode.jsではないのでNode.jsに依存する資産は使用できない
    ● Cloudflare WorkersからRDBMSに接続するにはhttpで接続するしかなかった
    許容すれば選択可
    TCPでの接続が行えるようになった
    

    View Slide

12. ※管理画面
    ユースケース
    Cloudflare Workers
    Durable Objects
    Authentication
    Cloud Messaging
    Crashlytics etc
    認証
    画像データ
    Socket通信
    GraphQL
    PUSH
    その他サービス
    サービス初期
    

    View Slide

13. ※管理画面
    ユースケース
    Cloudflare Workers
    Durable Objects
    Authentication
    Cloud Messaging
    Crashlytics etc
    認証
    画像データ
    (R2)
    Socket通信
    GraphQL
    PUSH
    Node.js処理サーバ
    GraphQL Server
    その他サービス
    現在
    

    View Slide

14. ユースケース
    ライブラリの変遷
    ● Fastify
    ● Apollo Server
    ● Prisma
    ● Pothos
    ● GraphQL Yoga
    ● Kysely (Prisma)
    ● Pothos
    2.0からWeb Standard APIで動作するように再構築されている。
    そのためCloudflare Workersでも動作する。
    Prismaは通常のモードでは Cloudflare Workersで動作しない。代替に別ライブラリを使用する必要があ
    る。自分の場合はPrismaのマイグレーション機能および Kyselyのデータベースの型生成として使用してい
    る。
    

    View Slide

15. ユースケース
    移行した効果（メリット）
    ● コンテナのデプロイまでの時間がかかる
    → デプロイ時間が8分前後が1分未満に短縮
    ● コールドスタートを短く抑えないといけない
    → 最大5秒前後が200ミリ秒程度まで高速化
    ● コンピュータリソースあたりの単価は高め
    → 数万円/月のAPIサーバ費が数千円/月に低下（約1/10）
    

    View Slide

16. ユースケース
    移行に際した注意点（デメリット）
    ● Node.jsが必要な場合は別途サーバを用意する必要がある
    ○ Cloud Runで構築した場合はリクエスト時間に影響しないようにする
    （非同期処理にする、起動時間を早くする etc）
    ● TCPの接続はリクエスト処理している間だけ接続可能である
    ○ waitUntilに接続するような処理があるとうまくいかない場合がある
    ○ DataLoaderも動作しない場合がある
    

    View Slide

17. まとめ
    ● Cloudflare WorkersでAPIサーバを構築する
    のは既に実用的な段階にある
    ○ オリジンの”味付け”ではなく、単体でサーバとして機
    能する
    ● Cloudflareにロックインはするが、それに見
    合ったメリットは十分にある
    

    View Slide

18. Thanks!
    ● name: chimame / rito
    ● job: Webエンジニア
    ● field: Cloudflare, GCP, AWS, Ruby, Node.js, TypeScript,
    React, Next.js, Remix, Docker etc
    ● company: Goens株式会社( https://about.goen-s.com )
    ● twitter: @chimame_rt
    ● GitHub: chimame
    

    View Slide