呼び出し処理編
| 項目 | 備考 |
|---|---|
| 呼び出し失敗時の動作を検討したか | |
| 呼び出し失敗時に、外部から取得した値ではなくデフォルト値を保存するか | 呼び出し失敗とわかるようにする |
| 保存するデフォルト値は関係部署と合意できているか | 謎のデフォルト値で利用者が混乱することがある |
| 呼び出し失敗はトレース、検知できるか | ログ、モニタリング、trace idなど |
| ある呼び出しAが外部API側でトレースできるか | ログ、モニタリング、trace idなど |
| タイムアウト時間は検討したか。矛盾はないか | OS, DB, ライブラリといった各レイヤーにより自動的に設定されている部分もチェックする |
| 呼び出す外部APIがwrite処理の場合、呼び出し失敗時のデータ不整合は検知できるか | ログ、モニタリングなど |
| 呼び出す外部APIがwrite処理の場合、不整合をあとで修正する機能はあるか | 不整合修正バッチ、補償トランザクションなど |
| 呼び出しは非同期か、同期か。非同期ならfork joinか、完全非同期か | 同期だとウェイト時間分、リクエストの遅延が発生する。要求によっては非同期にできる。 |
| 非同期時、呼び出しキューはあふれないか | 非同期処理がたまりすぎて消えてしまわないか。特に障害時 |
| 非同期時、シャットダウンしたとき呼び出しのキューは消えないか | 消えて大丈夫ならOK |
| Circuit Breakerを導入しているか | |
| 接続先がフリーズ(L4接続可、L7応答なし)した場合は検討したか | 障害試験しよう |
| 呼び出し先の応答が遅延気味になった(常に1秒かかるとか)場合でも、呼び出し側の性能が問題ないか確認したか | 障害試験しよう |
リトライ処理編
|項目|備考|
|---|---|---|
|リトライを検討したか | いらないならOK|
|リトライは非同期か、同期か |同期だとウェイト時間分、リクエストの遅延が発生する。要求によっては非同期にできる。|
|リトライ数はトレース、検知できるか| ログ、モニタリングなど|
|非同期時、リトライのキューはあふれないか | 非同期処理がたまりすぎて消えてしまわないか。特に障害時|
|非同期時、呼び出し元がシャットダウンしたときリトライのキューは消えないか | 消えて大丈夫ならOK|
|複数回リトライする際、指数バックオフとジッターを導入しているか|http://aws.typepad.com/sajp/2015/03/backoff.html |
|リトライに優先順位をつけたい場合、リトライ番号を考慮しているか |必要あれば|