Vertex Macro｜Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 10: Nasdaq：グローバル金融サービス向けのレジリエントなインフラストラクチャを構築する (HMC327)
NASDAQ のクラウドジャーニーとレジリエントなシステムアーキテクチャ
● 金融サービス向けに、レジリエントで高性能なシステムを構築。
● NASDAQ のクラウドジャーニー、ディザスタリカバリ戦略、ハイブリッドインフラストラクチャソリューション、アーキテクチャ上の考慮事項、今後の展望を概説。
● NASDAQ の背景：
● 電子取引所のパイオニアであり、世界で 30 を超える取引所を運営。
● 取引、清算、リスク管理、金融犯罪対策ソリューションを含むソフトウェアを 130 を超える市場へ提供。
● 従来型のマネージドソフトウェア、マネージドサービス、SaaS としてソリューションを提供。
● クラウドジャーニー：
● 15 年前に開始し、マッチングエンジンや市場システムなどの重要システムを段階的に移行。
● T+1 バックアップから、超低レイテンシートランザクションを処理するハードリアルタイムシステムへ進化。
● 重要度の低いシステムから、国家経済にとってシステム上重要なシステムへ移行。
● 課題：
● マイクロ秒およびナノ秒単位で測定される超低レイテンシートランザクション。
● 近接性とレイテンシーを考慮した、特定の物理ロケーション要件。
ディザスタリカバリ戦略とハイブリッドインフラストラクチャ
レジリエンシーと規制要件
● 顧客が 100% の稼働時間を期待する、高いレジリエンシー目標。
● 世界の複数の法域にまたがる規制監督。
● ディザスタリカバリの選択肢：
● バックアップと復元から、マルチサイト、アクティブ－アクティブ、マルチリージョンシステムまで多岐にわたる。
● RPO と RTO の目標について認識を合わせ、災害時のシステム応答を理解することが重要。
● 重要システムへの注力：
● 常時稼働し、停止が許されないシステムが中心。
● Outposts によるハイブリッドコンピューティング、障害ドメイン、静的安定性、切断時運用。
● Outposts によるハイブリッドコンピューティング：
● EC2 API と Amazon インフラストラクチャで管理しながら、Outposts を使用してデータセンターにワークロードを配置。
● リージョンとデータセンター間の接続に Direct Connect 回線を使用。
● データセンターのラック内で EC2 サーバーを使用し、サービスとして管理。
● 市場システム向けに超低レイテンシーのネットワークインターフェイスカードを追加。
● 物理的に完全分離されたデータプレーンのために、ベアメタルサーバーとネットワークを実装。
● ベアメタルサーバー
● ハイパーバイザー経由でハードウェアを共有する仮想サーバーとは異なり、すべてのハードウェアリソースへ直接かつ排他的にアクセスできる物理的なシングルテナントサーバー。この構成は、最高のパフォーマンス、一貫した I/O、ソフトウェアスタックの完全な制御を提供するため、ハイパフォーマンスコンピューティング、ゲームや AI/ML などの要求の厳しいアプリケーション、物理的な分離や特定のハードウェア構成を必要とするワークロードに最適。
障害ドメインと静的安定性
障害ドメイン
● システムコンポーネント間で運命を共有する範囲を理解するための障害ドメインという概念。
● 冗長性を確保するため、ソフトウェアを実行する複数の EC2 サーバーインスタンスとホットスペア（事前プロビジョニング済み EC2 インスタンス）を使用。
● すべてのソフトウェアコンポーネントを AB ペアにし、バックアップコンポーネントが同じインスタンスに併置されないようにする。
● ラックレベルの障害ドメイン：
● ラックレベルで起こり得る障害（例：電源喪失）を考慮。
● ラックレベルの障害：電源喪失、冷却障害、ネットワークスイッチ障害、物理的損傷によりサーバーラック全体がオフラインになり、ラック内のすべてのサーバーに影響すること。
● 複数のラックを使用し、ソフトウェアコンポーネントの AB ペアを異なるラックに分散して、両方のコンポーネントが同時に失われることを回避。
● サイトレベルの障害ドメイン：
● レジリエンシーを確保するため、データセンターに複数の物理サイトを使用。
● 米国市場向けのプライマリサイトは New Jersey、セカンダリサイトは Chicago。
● 静的安定性：
● バックアップリソースを即時に利用できるよう、ホットスペア（事前プロビジョニング済み EC2 インスタンス）を使用。
● 障害発生時にもシステムの完全性を維持するため、ソフトウェアコンポーネントの AB ペアをラックとサイトに分散。
● ホットスペア：
● AWS 上の事前プロビジョニング済み EC2 インスタンスは、主に EC2 Auto Scaling のウォームプール機能によって実装される。この機能により、アプリケーションのスケールアウトが必要になったとき、すぐに稼働させられるインスタンスのプールを維持できる。
● ディザスタリカバリ (DR) 戦略：ウォームプールは「ウォームスタンバイ」または「パイロットライト」ディザスタリカバリ戦略の重要な要素
● 高速なスケーリング：ウォームプール内のインスタンスは初期化済みであり、時間のかかるアプリケーションの起動および設定プロセスはすでに実行されている。
静的安定性と切断時運用
静的安定性
● 障害発生中のシステムレジリエンシーを確保するための静的安定性という概念。
● 障害時に EC2 コントロールプレーンへ依存しないよう、ホットスペア（事前プロビジョニング済み DC2 インスタンス）を使用。
● 事前設定済みリソースを利用し、障害発生中に変更を加えずシステム機能を維持することを目指す。
● 切断時運用：
● AWS サービスへの接続が切断される可能性があるシナリオ（例：光ケーブルの損傷）に備える。
● このような事象の間も、市場システムが外部サービスに依存せず運用を継続できるようにする。
● 切断されたシナリオでも機能を維持するため、ホットスペアと事前設定済みリソースを使用。
● 運用ランブック：
● 各レベルの障害ドメインに対して、明確に定義された運用ランブックを用意することが重要。
● サーバー、ラック、サイトレベルの障害への対応手順を綿密に調整し、運用担当者が熟知している必要がある。
● 実際の災害時の想定外を最小限に抑えるため、予測可能で十分に訓練された対応を実現することが目標。
切断時運用とテスト
切断時運用
● AWS サービスへの接続が失われるシナリオ（例：ネットワーク回線の切断）に備える。
● 外部サービスに依存せずシステムをローカルで管理するため、緊急アクセス用に Local Gateway を使用。
● 外部接続が必要となる可能性がある内部依存関係と運用を把握し、それらに対応するか回避する。
● 障害モードのテスト：
● Outposts を長時間切断し、システムの挙動を観察する徹底的なテストを実施。
● 停止中に失敗する可能性がある処理（例：SSL チェック、IAM とのやり取り）を特定して対処。
● リージョンやサービスリンクに問題がある場合でも Local Gateway にアクセスできるようにする。
● 戦略のまとめ：
● ハイブリッドコンピューティングのためにデータセンター内で Outposts を使用。
● コンポーネント間の相互依存性と運命を共有する範囲を理解するため、障害ドメインを分析。
● 障害発生中に変更を加えずシステム機能を維持するため、静的安定性を考慮して設計およびテスト。
● AWS サービスから切断された場合でもシステムをローカルで継続稼働できるよう、切断時運用に注力。
● レジリエンシーを実現し、災害時の想定外を避けるため、慎重な計画、明確に定義された運用ランブック、広範なテストを重視。
● 緊急アクセス
● 緊急アクセスは、権限を持つ担当者が通常のアクセス制御を迂回し、重要なシステム、データ、機能へ緊急にアクセスできるようにするセキュリティ対策。「break glass」という用語は、火災報知器などの緊急設備を使用するためにガラスを割るという概念に由来する。セキュリティ侵害、システム障害、パスワードのロックアウトなどにより標準的な方法が機能しない場合に使用されるフェイルセーフプロトコル。緊急アクセス用アカウントには高い権限が事前設定されているが、緊急事態が発生するまで安全かつ休眠状態に保ち、その使用を厳格に監視・記録する必要がある。
● 緊急アクセス：危機が発生し、標準のアクセス方法が利用できない場合。
● 制御の迂回：これらのアカウントは、通常のアイデンティティおよびアクセス管理 (IAM) を迂回するよう設計されている。
● 高レベルの権限：アカウントには昇格された権限が事前設定されている。
● 厳格な管理：不正使用を防ぐため、緊急アクセス認証情報は細心の注意を払って管理される。
今後の方向性と機能強化
動的デプロイ
● ルールベースのセットアップによる、より動的なデプロイを計画。
● パフォーマンスとレジリエンシーのバランスを取るため、アフィニティとアンチアフィニティのパターンを使用。
● アンチアフィニティパターンとは、特定のワークロード（VM、Pod）が同じ物理ホストまたは同じ障害ドメイン上で一緒に実行されることを防ぐ、クラウド／仮想化環境（Kubernetes、VMware、OpenStack など）のルール。パフォーマンス向上のために対象を同じ場所へ配置しようとするアフィニティとは対照的に、対象を分散することで高可用性、耐障害性、負荷分散を確保する。
● 市場がパブリッククラウドへ移行する中、ダウンタイムなしでシステムをスケールすることが目標。
● 高度なハードウェアの実験：
● Graviton 4 で良好な成果を得ており、次世代 CPU に向けて Amazon と協力。
● Graviton 向けの超低レイテンシーネットワークカードやその他の進歩をテスト。
● リアルタイムのリスク分析に向け、FPGA と GPU によるアクセラレーテッドコンピューティングを調査。
● FPGA (Field-Programmable Gate Array) は、製造後にプログラミングして幅広いデジタル論理機能を実行できる、再構成可能な集積回路。
● Outposts の機能拡張：
● より高度なコンポーネント（カスタムシリコン、FPGA、GPU）を Outposts に導入することに関心。
● システムを第三者へ販売し、より多くの機能とサービスを提供することを目指す。
● 慎重なサービス統合：
● Outposts へさらに多くのサービスを追加する際は慎重なアプローチを取り、サービスチームと詳細な分析を実施。
● 障害モードを理解し、サービスの高可用性と機能性を確保することに注力。
● まとめ：
● システムのレジリエンシー、パフォーマンス、可用性を高める取り組みを継続。
● 将来の目標達成に向け、綿密な計画、テスト、AWS との協力を重視。
● 聴講者の参加に感謝し、詳細情報を得るためフォームへの記入を案内。
超低レイテンシーの取引運用を支えるため、Nasdaq のデータセンター内に配置された AWS Outposts。主な
コンポーネントとその機能は次のとおり
● AWS Cloud と Region：分離された複数の Availability Zone (AZ) にわたってサービスを提供する標準的な AWS 環境。
● AWS Direct Connect：Nasdaq データセンターをメインの AWS Region に接続する専用プライベートネットワーク接続。Outposts を管理するためのコントロールプレーンとサービスリンク接続に使用。
● Nasdaq Data Center (オンプレミス)：AWS Outposts を設置する物理ロケーション。低レイテンシーと規制遵守のため、ワークロードをローカルで実行可能。
● AWS Outposts：Nasdaq データセンター内に配置され、AWS のインフラストラクチャ、サービス、API をオンプレミス環境へ拡張する、フルマネージドの AWS コンピューティングおよびストレージキャパシティ。
● Nitro および ULL NIC を備えた Amazon EC2 Instances：取引アプリケーションを実行するコンピューティングインスタンス。パフォーマンスとセキュリティを強化する AWS Nitro System を活用し、金融取引の厳しいレイテンシー要件を満たすため Ultra-Low Latency (ULL) Network Interface Card (NIC) を使用。
● Local Gateway：Outpost のこのコンポーネントは、オンプレミスネットワークを Outpost の VPC サブネット内のインスタンスへ接続し、既存の Nasdaq インフラストラクチャとの通信を可能にする。
Nasdaq のネットワーク
● ULL Trading Network：超低レイテンシー向けに設計された物理的に独立したネットワーク。EC2 インスタンスの ULL NIC と直接接続し、トランザクションを高速処理。