ConentfulやmicroCMSなどのHeadless CMSは、APIから取得することにより、フロント側の表現の自由度をとても高くしてくれます。
これらのサービスにはAPIリクエストレート制限が設けられており、一定数のリクエストや通信量を超えるとAPIアクセスができなくなるなどの可能性を考慮して実装する必要があります。
ここで課題なのはブラウザでレンダリングするたびにAPIリクエストは非推奨であることです。
ユーザーリクエスト起因にすると、どれくらいのタイミングでリクエストがくるのか管理できないためです。
ブログなどでは、SSGを利用し、ビルドするたびにAPIリクエストする方法をとり、ユーザーリクエストからはAPIリクエストしないようにしたりします。
今回は、レート制限のあるAPIリクエストで、SSRやCSRを考慮したキャッシュ戦略を考える。
APIリクエストレート
まずはサービス制限から調査する。
料金プランによって異なるが、今回はFree Planで参照した。
Contentful API Limits
Contentfulは公開したEntry、Assets関係の参照系APIの「CMA : Content Delivery API」と、未公開のDraftなども取得できる「CPA : Content Preview API」、スケジュール公開情報などが取得できる「CMA : Content Management API」と分かれている。
それぞれ利用用途によって確認する必要がある。
Usage Limit
- APIコールの合計(CMA、CPA、CDA)
- 100万回/月
- 利用帯域
- 0.85TB/月
Technical Limits
- CDAコール数
- 55回/秒
- CMAコール数
- 7回/秒
- CPAコール数
- 14回/秒
micro CMS API Limits
- GET APIコール数
- 60回/秒
- WRITE APIコール数
- 5回/秒
キャッシュ戦略
さまざまな制限がある中で、秒間リクエスト数をキャッシュを用いて解決します。
これはサービスが大きくなればなるほど負荷が高くなり、リクエストレートを超える可能性が高くなるものです。
そのため、下記要件を満たしつつ、キャッシュを考える。
- SSGは利用しない
- ユーザーリクエストからサービスのAPIリクエストをしない
- 運用側でAPIリクエスト数を把握できる
- 運用者が意図したタイミングで更新できる
バックエンド側からだけサービスのAPIリクエストをするようにします。
秒間リクエスト制限と、更新頻度を考慮しつつ、バッチ処理でRedisキャッシュにAPIから取得したデータを保存します。
フロントからのリクエストは、RedisにアクセスするだけとしサービスのAPIリクエストは行いません。
これにより、ユーザーからAPIは叩かれることなく、バックエンドだけでAPIリクエスト数を管理することができます。
更新頻度も5分更新でバッチ実行すれば、運用面も大きな問題は出てこないと思います。
Summary
外部APIを利用するときは必ずAPI Limitに目を通して設計をしていきましょう。
開発やテスト時はAPIを叩くだけなので気づきにくく、気づいた時には大きな問題になることがあります。
