リソース · 18
API統合を障害に対して耐性のあるものにする
依存関係をマッピングし、再試行回数を制限し、外部障害発生時にも重要な処理が利用可能であることを維持する。
更新済み · 3 min
このガイドが達成するのに役立つこと
- APIとビジネスジャーニーの接続
- バインドされた呼び出しと再試行
- パフォーマンス低下時の計画
- 復旧状況の測定
クイックチェック
- どのジャーニーが各プロバイダに依存しているか？
- すべての呼び出しにタイムアウトが設定されているか？
- 再試行によって操作が重複する可能性はあるか？
- 障害発生時にユーザーには何が表示されるか？
- 通常サービスへの復帰を承認するのは誰か？
手順
- 1
呼び出しのマッピング
すべての統合を、交換データ、契約、所有者、ジャーニーステップに接続します。 ユーザーをブロックする同期呼び出しを特定します。
成果物：優先順位付けされた依存関係マップ
- 2
時間予算の設定
各呼び出しのタイムアウトとジャーニーごとの合計予算を定義します。 サービスチェーンによる待ち時間の重複を防ぎます。
成果物：タイムアウトとしきい値のマトリックス
- 3
再試行回数の制限
繰り返しても安全な操作のみを再試行する。 冪等性をテストし、試行回数を制限し、適切なバックオフで分散させる。
成果物：テスト済みの再試行ポリシー。
- 4
パフォーマンス低下時の計画
障害発生時に使用可能なデータ、キューに格納できるデータ、および表示される明確なメッセージを決定する。
成果物：各ジャーニーごとのフォールバック動作。
- 5
インシデントをシミュレートする
制御された環境で遅延、無効な応答、および障害を発生させる。 負荷、データ、インターフェース、および復旧状況を確認する。
成果物：障害テスト結果。
- 6
結果を監視する
実際に失われたエラー、遅延、キュー、およびビジネスアクションを追跡する。 エスカレーション担当者とサプライヤーとの調整担当者を割り当てる。
成果物：ダッシュボードと復旧手順。
管理指標
| 指標 | 測定対象 | 最初のアクション |
|---|---|---|
| マッピングされたジャーニー | 既知の依存関係を持つ必須ジャーニー | 不明な呼び出しへの担当者の割り当て |
| 時間予算 | ジャーニー期限内の呼び出し | 連鎖待機のレビュー |
| 安全な再試行 | 副作用のない繰り返し操作 | 冪等性の追加または再試行の削除 |
| テスト済みの劣化 | ユーザー結果が観測された障害シナリオ | 継続性と通信の改善 |
よくある間違い
- 過負荷状態のサービスに対する無制限の再試行
- 冪等性のない書き込みの繰り返し
- ラベル付けされていない古いデータによる障害の隠蔽
- プロバイダ応答率のみの測定
よくある質問
すべてのリクエストを再試行すべきか？
いいえ。再試行は、特定の一時的な障害に対応するのに役立ちますが、全体の期限、冪等性、およびプロバイダ負荷を遵守する必要があります。
サーキットブレーカーで十分でしょうか？
サーキットブレーカーは一部の呼び出しを保護しますが、ユーザーエクスペリエンスやキューイングされた作業の回復を保証するものではありません。
最初に測定すべき事項は何か？
重要な業務への影響：所要時間、アクションの損失または遅延、および復旧品質。
公式参照文献
参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。
