11.3　リトライ時に考慮するべき点

APIクライアントから外部APIをコールする場合などに、一時的なエラーによってAPIのコールが失敗することがあります。リトライ可能なエラーが発生した場合に、一定回数リトライすることで回復性の高いアプリケーションを構築できます。実装方法ですがAWS SDK for Goのように、クラウドプロバイダーが提供しているSDKにリトライ機構が備わっている場合があり、この場合はアプリケーション開発者が自前で1からリトライ機構を実装する必要がありません。しかし、SDKを提供していないAPIや社内のサービスを利用する場合には、自前でリトライを実装する必要があるかもしれません。リトライ時に考慮しないといけないポイントと、実装方法を紹介します。

11.3.1　すべてをリトライしない

外部サービスへのHTTPリクエストが失敗したからといって、すべてをリトライする必要はありません。たとえばHTTPステータスが 400 Bad Request の場合は、エラーになった理由が呼び出し側にあるため、何度リトライしようが400エラーの結果は変わらないでしょう。通常はサーバーサイドが起因となるエラー（HTTPステータスが500番台）や、TCPレイヤーのエラーである connection reset などの場合にリトライすることを原則に考えましょう。

復帰の見込みがないリトライを入れてしまうと、オンライン画面であればユーザーの待ち時間が予想以上に長くなってしまい、エラー応答を返すよりユーザー体験が低下してしまう懸念があります。リトライ回数の設計値も大事なポイントです。次で説明するExponential backoffを利用すると設定値次第で待ち時間もぐっと増えるため、どれくらいの時間をリトライで待てるかやリトライの発生確率、救済できた場合のメリットなどのバランスをとって設計すると良いでしょう。 ...