APIへのリクエストで500番台のエラーが返却される場合の対処法は？

→ 一時的な負荷による問題の可能性が高く、リトライ処理の組み入れが有効です。それ以外のケースだと、該当のリクエスト自体が負荷の原因になっている可能性があります。

microCMSでは、サーバレスアーキテクチャの採用や、CDNによるキャッシュ機構の導入によって、大量のリクエストが発生した際も、応答ができる構成となっています。

しかしながら、高負荷なリクエストが短時間に集中した場合には、まれに500番台のエラーレスポンスが返却されることがあります。

発生原因および対策は、発生頻度によって異なります。
発生の際には、下記のご対応をお試しいただきますよう、お願いいたします。

1. エラーの発生頻度が低い場合

発生頻度が低い場合、他のご利用者さまのサービスのリクエストによる負荷の影響にて、エラーになっている可能性が高いです。

APIリクエストのリトライ処理を組み入れることで、改善する可能性があります。
JavaScript向けのSDKについては、オプションでリトライを有効化することが可能です。

2. エラーの発生頻度が高い場合

発生頻度が高い場合、該当のリクエスト自体が、負荷を引き起こしている可能性が高いです。以下の項目について、該当している項目がないかをご確認ください。

同時リクエスト数が多い

複数のAPIのリクエストが重なることで、高負荷を引き起こしている可能性があります。SSGのようなアーキテクチャを採用している場合は、並列実行されるリクエスト数を調整することで、事象が改善する可能性があります。

また、なるべくキャッシュが利用されるリクエストを行うことも有効です。

depthに指定されている数字が大きい

depthパラメータの値を大きくした場合、コンテンツ参照先のデータを取得して、レスポンスに含める挙動となります。コンテンツ参照を利用しているフィールドが多い場合、depthの値を1つ増やすだけでも、取得するコンテンツ量が非常に大きくなるケースがあります。

depthパラメータには必要となるコンテンツまでの深さを設定することで、事象が改善する可能性があります。

1回のコンテンツ取得件数が多い

1回のリクエストで取得するコンテンツ数が多い場合、レスポンスが遅くなることがあります

limitパラメータを利用して、必要なコンテンツ数のみを取得することで、改善する可能性があります。

全件取得が必要な場合は、offsetパラメータを合わせてご利用ください。

クエリに複雑な条件を組み合わせて指定している

コンテンツの絞り込み条件を[and]や[or]で複数組みわせている場合、検索の仕組み上、負荷が上昇します。

その場合、一部の絞り込みについては、取得先のフロントエンド側にて表示の際にフィルターを行うことで、事象が改善する可能性があります。

コンテンツ数、メディア数、フィールド数が多い

データを探索してレスポンスを生成する仕組みのため、CMSに登録されているデータ量の単純増加により、負荷が上昇します。

不要なデータがある場合は、削除操作を行なっていただくことで、事象が速度が改善する可能性があります。