分散システムにおけるフォールバックの回避

分散システムにおいて「フォールバック」（一次処理が失敗した際に代替手段に切り替える仕組み）は、一見すると信頼性を高める有効な戦略に見える。しかし本稿は、これがシステムの複雑性を急増させ、障害の根本原因を隠蔽し、結果として全体としては信頼性を低下させる危険な設計パターンであると警鐘を鳴らす。 - AWS（Amazon Web Services）は世界最大手のクラウドプロバイダー。同社の公式エンジニアリングブログはこのテーマを、内部システム（例：S3やDynamoDBといった基盤サービス）での実戦経験に基づいて論じている。 - 「フォールバック」の典型的な例：プライマリのデータベースが応答しない時にキャッシュから古いデータを返す、推奨エンジンがダウンしたら固定のデフォルト商品リストを表示する、など。 - 記事が指摘する主な欠点：(1) 障害が「サイレント」になり気付きにくくなる、(2) フォールバック先が雪崩的に過負荷になり二次障害を誘発する、(3) 状態が複数系統で分岐し、デバッグや一貫性の確保が極めて困難になる。 - 代替策として推奨されるのは、フォールバックではなく「システムを構成する各コンポーネントが明確に失敗すること（fast failure / 明確なエラー応答）」と、それを前提にした上位レイヤーでの適切なリトライやサーキットブレーカー、そして障害を外部にそのまま伝える設計である。 - この議論は、Amazonが創業初期から信奉する「分散システムの迷信を打ち破る」エンジニアリング文化（通称：AWSの"ディストリビューテッド・システムズ・マンifesto"的な考え方）の一環と理解できる。