クラウド利用における流路依存の露出

object

Gmailで認証リダイレクトループが発生し、Cookie削除による復旧過程でブラウザ内のログイン状態が広範囲に失われた。データ消失はなかったが、Identity・認証・通知・復旧を介してサービスへ到達する利用流路への依存が露出した。

notes

• サーバーダウンとは異なり、発生時点では障害位置がローカル側なのか、認証・アカウント側なのか判別できなかった。
• パスワードマネージャは残存し、再ログイン可能だったため、恒久的な損失には至らなかった。
• Gmailはメールだけでなく、OAuth、本人確認、通知、復旧経路として他サービスの利用成立にも接続している。
• データが保存されていても、認証・通知・復旧などの流路が閉じれば利用できない状態が生じうる。
• データを移せることと、利用状態や到達経路を別系統へ移せることは一致しない。
• クラウド依存には、データ依存とは別に、利用成立流路への依存が存在する可能性がある。
• 単一障害点は保存先だけでなく、Identityや認証・復旧の経路にも形成されうる。

implications

• クラウド依存の観測では、データ所在だけでなく、サービスへ到達する認証・通知・復旧経路も観測対象になりうる。
• 可用性は「サービスが稼働しているか」だけでなく、「利用者が到達し、必要時に復旧できる経路が残っているか」にも左右される。
• データ移行可能性と利用流路の移行可能性を分けて見る必要が出てくる可能性がある。

questions

• クラウド依存の強さは、保存データ量ではなく、代替不能な利用流路の集中度によっても観測できるだろうか。
• Identity・認証・通知・復旧のどこまでが同一ベンダーへ集中すると、利用流路の単一障害点になるのだろうか。
• データが残っている状態と、利用可能性が残っている状態は、どのように分けて観測できるだろうか。