トラブルに学ぶ Direct Connect 冗長化

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。

2021年9月2日に東京リージョンで Direct Connect 接続が失われるトラブルが発生しました。

Direct Connect は AWS VPC とオンプレミスデータセンターや拠点を専用線で結ぶサービスです。
高品質低遅延ということでオンプレミス上のシステムとネットワーク的な接続を望むユーザーに多く採用されています。

今回のような障害が発生した場合、自社システムへの影響を最小限に留めるためどのような対策をしたらいいでしょうか。
トラブルから学んでみたいと思います。

事象についてのサマリー

2021年9月8日追記
AWS からこのトラブルについてのサマリーが公開されました。
数ヶ月までに導入した ”頻度の低いネットワークコンバージェンスイベントおよびファイバ切断に対するネットワークの反応時間を最適化するために導入された新しいプロトコル” が原因である可能性があるとのこと。
この新しいプロトコルを無効にしたことで収束に向かったようです。
東京リージョン(AP-NORTHEAST-1)で発生したAWS Direct Connectの事象についてのサマリー

オンプレミスとの回線冗長化

我らが Black Belt がとても参考になります。
抜粋させてもらいながら理解していきたいと思います。

[AWS Black Belt Online Seminar]オンプレミスとAWS間の冗長化接続

複数の Direct Connect による冗長化

Direct Connect を複数引き込む形式です。
Active-Active、Active-Standby 何れかの構成も可能です。
オンプレミス側のルーターでそれなりのコンフィグが必要です。

冗長性を高めるために以下を考慮します。

• 異なるロケーションに接続する
• 異なる AWS Direct Connect デリバリーパートナーと契約する
• 自動切り替え、手動切り替えの準備をしておく

手動切り替えの準備をしておくことが大切です。
Direct Connect が完全ダウンしてくれれば自動切り替えで OK だとは思いますが、
今回のように誰も想定してない事象では往々にして ”中途半端な状態” になります。
ステータスを見ると UP になっているけど、パケットロスや低パフォーマンスに陥る状態になると手動切り替えが必要になってくるはずです。

待機系に Site-to-Site VPN

通常は Direct Connect を使い、待機系をして Site-to-Site VPN を採用します。
今回のように Direct Connect 自体のトラブルに対処可能です。
また、Site-to-Site VPN は Direct Connect よりもコストが低いことが多いので待機系のコストを抑えたい場合にも有用です。

気をつけないとならないのは、Direct Connect ほどのパフォーマンスは期待できない可能性があるということです。
ここは十分な事前検証が必要です。可能であれば (可能でなくても) 机上ではなく実機検証を行ってパフォーマンスを計測します。

Site-to-Site VPN のパフォーマンスが不十分な際には、転送量を調整します。
必要最低限なオンライン転送に限定する、巨大なファイル転送は保留しておく等の処置が考えられます。

こちらも切り替え手順は自動と手動を準備しておきます。
同じ理由で ”中途半端な状態” に陥る可能性があるからです。

Site-to-Site VPN 料金

Site-to-Site VPN では以下の月額料金が発生します。

• サイト間 VPN 接続ごとに 0.048USD/時間
• データ転送料金

AWS VPN の料金
Amazon EC2 オンデマンド料金 データ転送

仮に1ヶ月稼働させ、1TB のデータ転送があったとすると(待機系に切り替わった想定)
151.66 USD になります。(計算上です。お約束するものではありません。)

AWS Pricing Calculator

Direct Connect ロケーション

さきほどから「ロケーション」と書いていますが何なの？ という疑問があるかもしれません。
ロケーションとは、AWSクラウドへの物理的な接続を提供する拠点のことです。

東京リージョンでは5つのロケーションが提供されています。(2021年9月3日時点)

• AT Tokyo CC1 Chuo Data Center, Tokyo, Japan
• Chief Telecom LY, Taipei, Taiwan
• Chunghwa Telecom, Taipei, Taiwan
• Equinix OS1, Osaka, Japan (*)
• Equinix TY2, Tokyo, Japan

(*) For purposes of the AWS Direct Connect Service Level Agreement, the Equinix OS1 location may also be considered associated with the Asia Pacific (Osaka) Region for purposes of satisfying the Minimum Configuration Requirements.

AWS Direct Connect Locations

上で示したロケーションから異なる場所を選択してください、ということになります。

AWS Direct Connect の回復性に関する推奨事項

Direct Connect 設計上の可用性

アーキテクトが可用性設計を行ううえで参考する設計上の可用性を見てみます。

この基準を持ってご自身が担当するシステムのオンプレミスとの接続構成を考えます。
コストや運用体制との兼ね合いで Direct Connect を複数契約するのか、Site-to-Site VPN を待機系とするのかなど戦略を決定します。

Appendix A: Designed-For Availability for Select AWS Services

Service Component	Availability Design	Goal
AWS Direct Connect	Control Plane	99.900%
	Single Location Data Plane	99.900%
	Multi Location Data Plane	99.990%

Direct Connect SLA

SLA を確認してみます。
以下サイトを英語でご覧ください。
AWS Direct Connect Service Level Agreement

注目すべきはページ下部 表内の Minimum Configuration Requirements の項目です。
AWS Well-Architectd な構成になっているかを問われているわけですが、やはり少なくとも2つのロケーション、
そして、ワークロード (AWS 上のリソースと読み替えても不自然はない) は Muiti-AZ にする必要があります。
99.99% は更に冗長な条件になっています。

引用します。

99.9％

• Included Resource uses virtual interfaces on Dedicated Connections at a minimum of 2 Direct Connect locations, and at least one of those Direct Connect locations uses the Associated AWS Region (described here) in which your workload is located.
• Each virtual interface provisioned on the Included Resource must be configured for full, independent access to your workload.
• You must have the Enterprise Support plan in place.
• For private endpoints, your workload must be deployed to two or more Availability Zones.

99.99％

• Included Resource uses virtual interfaces on at least 4 Dedicated Connections across a minimum of 2 Direct Connect locations (with no fewer than 2 connections in a single location), and at least one of the Direct Connect locations uses the Associated AWS Region in which your workload is located.
• Each Dedicated Connection must terminate on a unique AWS endpoint as indicated by the AWS Device ID visible in the AWS Console and Direct Connect APIs.
• Each virtual interface provisioned on the Included Resource must be configured for full, independent access to your workload.
• You must have the Enterprise Support plan in place and complete a “Well-Architected Review” with an AWS Solutions Architect.
• For private endpoints, your workload must be deployed to two or more Availability Zones.
• You must request your AWS Solutions Architect to provide AWS Enterprise Support with a list of the Included Resource IDs (e.g., AWS Virtual Private Gateway and its associated virtual interface IDs) that meet the Minimum Configuration Requirements to qualify for Service Credits.

Direct Connect 異常検知

異常を検知して早期に手を打ちたいと思います。

CloudWatch メトリクス

CloudWatch でメトリクスを取得可能です。

単純なアップ or ダウンを確認します。

• ConnectionState

ビットレートを監視し異常に低い値を計測したらアラートという手段も考えれます。
Anomaly Detection を使う方法もありだと思います。

• ConnectionBpsEgress
• ConnectionBpsIngress
• VirtualInterfaceBpsEgress
• VirtualInterfaceBpsIngress

パケットレートも同じくです。

• ConnectionPpsEgress
• ConnectionPpsIngress
• VirtualInterfacePpsEgress
• VirtualInterfacePpsIngress

Amazon CloudWatch でのモニタリング

データ転送処理での異常検知

AWS ～ オンプレミス間でデータ転送処理を実行していると思います。
その処理内で転送に失敗したらアラートを発報します。

処理時間をログに出力しておいて、ログ管理の仕組みで処理時間を拾ったり、処理時間をメトリクスに送信したりする方法も考えられます。

データ転送にジョブ管理ツールを使用していれば、ジョブ時間によりアラートも可能だと思います。

Personal Health Dashboard

AWS 内での対応状況が把握できるという意味では PHD をチェックすることは有用です。

参考

[AWS Black Belt Online Seminar]オンプレミスとAWS間の冗長化接続
AWS再入門ブログリレー AWS Direct Connect 編
AWS Direct Connect の回復性に関する推奨事項

以上、吉井 亮 がお届けしました。