0. はじめに
2021年9月2日、AWS Direct Connect (以下DX) に障害が発生しました。
概要は東京リージョンでパケットロスが多く発生するというものでした。
完全に接続が切断されるのではなくパケットロスというのが厄介ですね。
どうすれば対策できたのでしょうか。
1. DXの基本
- 必ず２本以上の回線を接続する
- 複数のDirect Connect ロケーションへ
- 異キャリア異ルートで
- インターネットVPNへのバックアップは要注意
1.1. 必ず２本以上の回線を接続する
AWS自体がたとえ開発ワークロードであろうと２つ以上の接続を推奨しています。
これはDXがそもそも障害以前に拒否不可能な計画停止が定期的に行われますから、１本では確実にダウンタイムが発生するからです。
また、２つ以上の接続が無いとSLAも適用外となります。（後述）
AWS推奨事項は以下でおさらいを。
1.2. 複数のDirect Connect ロケーションへ
これもAWS自体の推奨事項になっており、SLA適用条件の１つです。
これはDirect Connect ロケーションに障害が発生すると、そこへ接続している接続は影響を受けるからです。
以前は日本国内にはエクイニクスの東京TY2しか無く物理的に不可能でしたが、現在はTY2,CC1,OS1と３つもDirect Connect ロケーションがあります。
「専用線接続だから絶対切れない」なんてことはありません。
単一障害点は無くしていきましょう。
1.3. 異キャリア異ルートで
同じ回線を複数調達してもあまり意味がありません。
多くの場合、それらは同時に利用不能に陥るからです。
異キャリア（通信事業者）を利用する事で、通信事業者の障害を回避できます。
異ルート（回線が通る地理的な経路）を通す事で、災害や事故などによる障害を回避できます。
災害のみならず工事や事故等でケーブルが破断し、長期間の通信障害になる事もあります。こういった場合、異キャリアであっても同じルートを通る回線は同時に障害を受けますから異ルートが重要になります。
2. SLAには条件あり
DXにもSLAがあります。99.9%或99.99%。
しかしよく読むと条件がある事がわかります。
99.9%の条件（主な内容）
- 少なくとも２つのダイレクトコネクトロケーションへ接続
- ワークロードを２以上のAZへ展開
- エンタープライズサポート加入
DXの回線自体のみならず、利用するワークロード（EC2インスタンス等のAWSサービス）も冗長化してサポートに入れということですね。
99.99%の条件は更に厳しいです。SLAの詳細は以下を参照。
そしてSLAは99.9%や99.99%の動作を保証するわけではありません。
利用者がSLAを下回った場合に 申請を行う事で 月額利用料を上限として規定額が利用料から値引きになるだけです。
自動的に値引きにはならず、利用者が申請をしないといけません。
3. どうすれば障害を回避できたのか
もう答えは出ていますが、複数のDirect Connect ロケーションへ接続する事です。
東京TY2と大阪OS1へ接続していたところ、OS1のみ利用するよう手動で経路を制御して回避できました。
これはAWS推奨構成図そのものですね。
なお前述の通り通信速度要件がさほど厳しく無い場合は、インターネットVPNによるバックアップも可能です。
ここで重要になってくるのが、今回のような完全な接続断でなくパケットロスが増えるといった不安定な状態における対処です。
4. 明確な接続断でない場合の対応の難しさ
今回のDX障害はまさにこれ。
明確な接続断の場合はBGP接続も切れる為、自動で迂回されますが今回の場合、
TY2とのDX接続は接続されています。BGP経路交換もされ通信可能です。
しかし、パケットロスが多いんですね。
これは一定の閾値を設定して監視ツールからアラートを上げる運用を行うしかありません。自動化も不可能ではありませんが経路がばたつくのはよろしくありません。
閾値を低めにして早めにアラートが上げて、人間が判断して経路を制御するか静観するか決めていく方が影響が少ないと思います。
5. まとめ
- AWS推奨事項を守っていれば障害対策が行えた
- ただし通信品質の監視体制と手動による経路制御を行える運用体制が必要
といったところでしょうか。
ベストプラクティスは守りましょうという良い教訓ですね。
（参考） AWSJの公式見解はこちら。