## 目的・動機 - PlanetScaleが世界中に数百万のAmazon EBS（Elastic Block Store）ボリュームを展開し、日々数万のボリュームを作成・破棄している経験から得たEBS障害率とメカニズムの実態を共有 - クラウドネイティブシステムにおける部分障害が完全障害として現れる問題を解明 ## 具体的な専門用語・数値データ - **EBS性能保証**: gp3ボリュームは年間99%の時間で90%以上のプロビジョニングされたIOPS性能を提供 - **障害時間**: 性能低下は1%の時間（1日14分または年間86時間）で発生 - **レイテンシ変動**: 通常の単桁ms/operationから200-500ms/operationへ急激に悪化 - **障害頻度**: 各ボリュームで月約43回の性能低下イベント（10分間継続と仮定） - **大規模システム影響**: 256シャード構成（768ボリューム）で99.65%の確率で常時少なくとも1つのノードが本番影響レベルの障害状態 - **io2ボリューム**: gp3の4～10倍のコストでも年間約33%の時間で障害状態 - **アイドル時間**: 67%から0%へ急降下 ## 得られた結論 - 「遅い」状態は「障害」と同等の影響をアプリケーションに与える - EBS障害率は恒常的、可変的で、設計上の仕様 - 十分な数のボリュームと十分な時間があれば、障害は100%保証される - ボリュームが仕様通り動作しない場合の性能保証は存在しない - オーバープロビジョニングでも問題は解決されない ## 熟練者向け重要情報 - **障害検知手法**: 読み書きレイテンシとアイドル%の監視、ファイル書き込みテストによる基本的なヘルスチェック - **自動化対策**: ゼロダウンタイムリペアレンティング（数秒で他ノードへ切り替え）と自動的な代替ボリューム起動 - **相関障害**: 単一ゾーン内でio2ボリュームでも相関した障害が頻発 - **PlanetScale Metalアーキテクチャ**: EBSのようなネットワーク接続ストレージではなくローカルストレージを使用するshared-nothingアーキテクチャで問題を回避 - **運用レベル**: 自動緩和システムが日常的に性能不良EBSボリュームをリサイクル - **検知限界**: 障害発生前の予測は不可能、検知後の対応時間最小化が重要