リアルタイム・高可用性 Windows NT ベースのソリューション： Nasdaq® Market Surveillance Delivery Real-Time (SDR) System

「Nasdaq の新しい Surveillance Delivery Real-time システムは、そのスピードと可用性において、世界中のほかのどの金融市場も太刀打ちできない警告検知・表示システムです。」Nasdaq Stock Market の親会社である NASD® (National Association of Securities Dealers, Inc.) の Executive Vice President と Chief Information Officer を兼任する Gregor S. Bailar は言います。「徹底的なテストの後、我々は、株主のための平等な場の維持と、すべての参加者のための市場の完全性を支援する、最高水準のシステムを開発しました。」

目次

概要

世界初の電子株式市場であり、ドルおよび株式量において世界最大である Nasdaq Stock Market® は、全世界の株取引開発のモデルとなりました。急成長を遂げている小企業から多くの有名大企業まで、現在およそ 5,000 社が Nasdaq® で証券取引を行っています。

先頃 Nasdaq では、ミッションクリティカルなソフトウェア アプリケーション、SDR (Surveillance Delivery Real-Time) System を開発しました。このシステムは、株式市場の活動を監視し、異変の可能性に対して警告を発します。

これまでミッションクリティカルなアプリケーションは、UNIXが動作するミッドレンジシステムやメインフレーム オペレーティング システム下のハイエンドプラットフォーム上で開発されてきました。SDR システムは、現在主流となっている Intel アーキテクチャ上で動作する Microsoft® Windows NT® 4.0 オペレーティング システムが、ミッションクリティカルな機能を問題なく実行できることを証明した、先駆的なアプリケーションです。

この文書ではまず、Nasdaq がこのアプリケーションを開発するにあたって直面した課題についてお話します。次に SDR の設計、開発、実装に寄与したチームを紹介した後、技術ソリューションについて詳細に解説します。また、アプリケーションの設計から実装までの短期スケジュールを実現するための開発サイクルについても述べます。さらに、SDR のビジネス プロセス、アプリケーション アーキテクチャ、システムの特徴、提供されるコンポーネント、および SDR の高い可用性要件を満たすハードウェア ソリューションについて説明します。最後に、運用全般にかかわる、SDR アプリケーションのシステム管理タスクについて解説します。

Windows NT 4.0 と Intel 環境で動作する SDR は、次の特徴を備えています。

• リアルタイム情報: 1 日あたり 200 万を超えるトランザクション (1 秒間に 200 トランザクション以上) を監視し、警告条件に基いてフィルタリングし、2 秒以内にアナリストに警告を発します。
• 信頼性: 99.97% の稼働時間と、幅広いフェイルオーバー方法を提供します。
• 拡張性: マルチプロセッサの利点を生かすため、4　Way以上のプロセッサがシステムに採用された場合、コードの書き直しが必要ないという設計上の特徴があります。この拡張性は、Unisys QS/2 10 プロセッサ テスト システムで実証されました。業務環境では、SDR は、現在のトランザクション レベルの 3 倍という環境で、ベンチマークテストを問題なくパスしました。
• 柔軟性: ロジック、フィルタ、ルール、その他のプログラム要素の変更を取り入れる際も、ソフトウェアの再エンジニアリングは必要ありません。
• セキュリティ: 閉じた環境で、システムを保護します。

SDR は、Windows NT 4.0 が稼動している次のコモディティ ハードウェア上で実行できます。

• Unisys Aquanta QR/2 500 MHz Intel® Pentium® III Xeon™ プロセッサを使った 4 Way CPU
• Unisys OSR 5000 RAID 10 (データベース サーバー)
• ディスク ミラーリング (データベース サーバー以外)
• 2 GB のメモリ (Alert Engine およびデータベース サーバー)
• 512 MB のメモリ (その他のサービス)

• Windows NT 4.0 が稼動しているネットワーク接続されたPC
• Intel® 266 MHz Pentium® プロセッサ
• 128 MB の RAM
• VGA ビデオ

• Microsoft SQL Server™ 6.5 (Service Pack 5A を含む) (次のフェーズの SDR は、SQL Server 7.0 で開発中です)
• Microsoft Transaction Server (MTS)
• Microsoft Message Queue Server (MSMQ)
• Microsoft Clustering Server
• Microsoft Management Console
• WBEM (Operator’s Console 上で使用される、Web-Based Enterprise Management)

トップに戻る

課題

Nasdaq の 市場監視部門は、Nasdaq Stock Market の規制監督のために作られました。市場監視の役割は、投資家のための平等な場を維持するために、市場の完全性を保護することです。市場監視のアナリストは、異常と思われる市場活動を調べ、介入が必要かどうかを決定します。市場監視部門は、株式監視課と取引監視課に分かれています。株式監視は発行者の活動をリアルタイムで監視する役割を持ち、取引監視は、売買活動をリアルタイムで監視する役割を持ちます。

介入は、誤った数値の修正から、特定の株に関する取引の停止まで、さまざまです。介入を効果的に行うためには、即時性が求められます。市場監視のアナリストがその専門性を最大限に発揮するためには、正確で有用なリアルタイムの情報と、現在の情報を正しく把握するための履歴データにアクセスできることが必要です。

SDR が開発される前は、市場監視では Tandem ベースのアプリケーションを使って市場の動向を監視していました。このレガシーアプリケーションの検出プロセスは効果的なものでしたが、各種の警告条件を再検討したり指定したりするには、時間のかかる手動操作が必要でした。今日の市場スピードに対応するためには、この手動操作が次第に重荷になってきました。NASD (National Association of Securities Dealers) の Executive Vice President と Chief Information Officer を兼任する Gregor S. Bailar によれば、現在 Nasdaq の株取引全体の 20% がインターネット取引によるものです。インターネット取引には、従来の機関投資家とは異なる特徴とパターンがあります。Nasdaq の市場監視部門では、幅広い自動警告機能があれば、市場の完全性をより効果的にタイムリーに監視できると考えました。また、市場監視にとって、履歴、取引詳細、警告などの各種データを単一の包括的な追跡システムに統合できれば便利です。Nasdaq ではさらに、市場の基準や規則、市況の変化に対応できるような、より柔軟な警告生成プロセスへの設計変更を望んでいました。

これらの目的を満たすためには、アプリケーションは次のタスクを実行する必要があります。

• 各 Nasdaq 市場を分析すること
• 警告条件を識別すること
• 市場情報の到着から 2 秒間以内に、適切な市場監視アナリストに警告を発すること
• 警告関連のすべてのデータを市場監視アナリストに供給すること
• アナリストが警告を受信したときに、警告の担当者を認識すること
• セキュリティを確保し、市場監視グループ用に収集・提供されたすべての情報を監視できること

これらの目的とニーズは、Nasdaq Stock Market の環境に固有のものです。Nasdaq の市場は電子市場です。電子市場では、複雑な金融取引が日単位でなく分単位でとり行われ、もし取引に手違いがあれば、瞬時に広範囲に影響が及んでしまいます。

さらに、技術革新、電子商取引、そして高速インターネット アクセスの増加などによって、企業環境に急速な変化がもたらされました。地球上のビジネスは、順応性と柔軟性に優れた仮想経済組織へと自らを変貌させています。最も効率的な企業とは、参加者の物理的位置にかかわらず複数のビジネス取引を同時に行える能力を持った組織です。

市場監視部門の株式監視課および取引監視課の両セクションが、公平で秩序ある市場を提供するという総合的な目的を達成するためには、Nasdaq が、投資家の要求を満たすために必要な能力を持つ必要があります。つまり、関連データに即座にアクセスし、アナリストが検討できるよう、それらのデータを直ちに処理できる能力です。

Nasdaq は、PC 環境で動作するミッションクリティカルなソフトウェア アプリケーションに対する RFP (Request For Proposal) を作り上げました。Nasdaq では、Surveillance Delivery Real-Time System が提供する機能を使用する、またはこの機能によって恩恵を受ける各種のユーザー グループを特定しました。システムの主要ユーザーは次のとおりです。

• 株式監視課および取引監視課のアナリスト
• 市場監視運用マネージャ (警告管理を含む)
• 市場監視管理部

このアプリケーションが提供する情報によって間接的に恩恵を受けるユーザー グループは次のとおりです。

• NASD Regulation, Inc.
• NASD Economic Research Department
• システム管理者
• その他の見込みユーザー

Nasdaq の IT (Information Technology) 部門は、Windows と UNIX の両方のプラットフォームに精通しています。サーバーのバックアップと復元、オンライン回復、サーバー管理といったタスクに関しては、ネットワーク管理・保守手順が明確に定義されています。この確立されたインフラストラクチャと専門知識が存在する上で、RFP は、Windows または UNIX プラットフォームを使用するオープン プラットフォームなソリューションであることと、最低 99.97% の信頼性 (年間 1 時間以内のダウンタイム) が確保されることを要求していました。

最終的には、このミッションクリティカルなアプリケーションのプラットフォームとして Windows ベースのソリューションが選択されました。これは、Microsoft の DCOM (Distributed Component Object Model)、Microsoft Transaction Server、Microsoft Message Queue といったサービスが、次のような魅力的な機能をもたらすためです。

• 99.97% の稼働時間を実現する信頼性 (1 日の稼働時間を 7.5 時間とした場合、年間 19 分間以内のダウンタイム)
• Windows NT 4.0 認証およびセキュリティ コンポーネントの利用
• Visual C++ で作成されたプログラムでの、MTS および MSMQ の相互操作性
• 拡張性の高い一連のアプリケーション コンポーネントを提供できる能力
• モジュラの柔軟性 (関数スコープや機能面で SDR に変更を加えても、プログラム コードを再エンジニアリングする必要がありません)

トップに戻る

チーム

Nasdaq 開発チームが主導する中、3 社の情報技術会社が、SDR ソフトウェアの作成に協力しました。Unisys Corporation、Micro Modeling Associates、そして Microsoft の 3 社は、PC ベースでは不可能と言われていたソリューションを、現実のものにしました。

Nasdaq はこの新しいアプリケーションの仕様と目標を決定し、また SDR の統合環境を決定しました。さらに、Nasdaq の IT 部門からは幅広い専門知識が提供され、開発パートナーのひとつとして機能しました。

Unisys は 25 年以上にわたる Nasdaq のパートナーであり、その業務環境とミッションクリティカルなエンタープライズ システムについて熟知していました。Unisys は、開発の初期の段階から SDR プロジェクトに参加していました。Unisys が定義した SDR のアーキテクチャは、2 つの目標を達成しました。最初の目標は、Windows NT が SDR に必要なパフォーマンスを実現できるようにすることでした。同時に、このアーキテクチャにより、SDR の使いやすさを証明するベンチマーク アプリケーションが作成されました。今日 Unisys は、エンタープライズクラスの Windows NT 用アプリケーションの実行には欠かせない要素となっている、Unisys サーバー プラットフォームに対する包括的なサポートを提供しています。

Micro Modeling Associates (MMA) は、eソリューションのコンサルティング会社であり、Microsoft の 1999 年度最優秀ソリューションプロバイダーパートナーでした。MMA の広く認知された専門技術と、金融サービス業界についての幅広い知識は、SDR プロジェクトの詳細な設計とカスタマイズされたコードの開発にはうってつけでした。 Unisys と MMA が協力して設計・試行した最初の SDR ベンチマークにより、SDR に必要とされるトランザクション量を Microsoft Windows NT Server が処理できることが証明されました。ベンチマーク テストの実行後、MMA が現在のアプリケーションを開発するよう選ばれました。

Microsoft は長年にわたり、Windows NT プラットフォームには、ハイエンドで信頼性の高いアプリケーション サポートを提供する能力があると主張してきました。同様に、Microsoft Windows の DCOM 開発プラットフォームおよびツールは、信頼性の高いソリューションを開発するのに十分な柔軟性と拡張性を持っています。開発とネットワークの両方に取り組んできた Microsoft は、この監視システムの完成を全面的にサポートしました。Nasdaq は社内の LAN (ローカル エリア ネットワーク) 環境を Windows NT プラットフォーム上で標準化し、Windows NT 4.0 および Windows 2000 の主要ベータ サイトとなりました。Microsoft はネットワークおよび開発サポートを提供し、Nasdaq はバグの警告や関連ソリューションといった重要なフィードバックを定期的に Microsoft に返しています。

これらパートナーどうしの専門技術と戦略的な連携により、互いに相乗効果をもたらす団結力の強いチームが結成され、強固でミッションクリティカルなアプリケーションが完成しました。

開発サイクル

図1 のタイムラインは、SDR アプリケーションの開発サイクル全体の流れです。SDR の最初の RFP が 1997 年に出され、アプリケーションの設計は 1998 年 4 月に開始しました。その年の 11 月に開発プロセスが開始し、第 1 フェーズは 1999 年 4 月に完了しました。

注: 第 1 フェーズというのは、ソフトウェアの現在の実装です。ほかの機能は今後の開発段階で追加される予定です。

SDR の品質管理テストは 1999 年 8 月に完了しました。同時に、SDR が業務環境に導入され、既存のシステムと並行して動作し始めました。1999 年 9 月、SDR は System of Record とされました。

図1: SDR タイムライン

SDR アプリケーション開発のライフ サイクルは、図 2 に示すように、段階ごとに区分されます。

図2: SDR 開発のライフ サイクル

SDR の設計段階は、プロジェクト開始フェーズとともに 1998 年 7 月に着手され、5 か月が費やされました。この時点で開発者は、上位のアプリケーション設計を決定し、詳細設計の基礎となるベンチマークを確立しました。

開発段階では、プログラム コードの最初の作成、文書化、アセンブル、およびテストが行われました。SDR の開発段階は 1998 年 11 月に開始し、1999 年 4 月まで続きました。この後、アプリケーションは品質管理段階へ進みました。

QC (品質管理) は初期テスト段階です。この段階の間、次の要素を含めたすべての側面について、SDR に厳しいテストが行われました。

• 機能性
• ユーザー認証
• フェイルオーバー手順
• 災害回復
• 論理エラー

QC 段階の間、必要に応じてバグの修正とコードの変更が行われました。この時点では機能やソフトウェア コードの追加は行われませんでした。ただし、テストの結果サブシステム全体に及ぶ重大な問題が発見された場合は、プロジェクトが開発段階に戻されます。SDR プロジェクトではこのような事態は発生しませんでした。SDR の QC 段階は 1999 年 8 月中旬まで続きました。この後 SDR アプリケーションは業務環境に導入されました。

業務環境段階では、既存のソフトウェアと新しいアプリケーションが並行して使用されました。最終テストとシステム パラメータの調整はこの段階で行われました。この段階では既存のシステムが同時に動作しているため、実務環境の警告処理に影響を与えることはありません。準備が整った後、ソフトウェアは、作業を中断させないような形で、全面的に配備されます。SDR の業務環境段階は 1999 年 8 月中旬に開始し、最初の業務履行は 9 月上旬に予定されました。

トップに戻る

ビジネス プロセス ワークフロー

SDR プログラムは 3 階層アプリケーションであり、市場を監視し、状況に応じて警告を生成し、すべてのデータを安全なリポジトリに保管するよう設計されています。

SDR は複数のソースから集めたトランザクション データをスキャンし、すべての取引が正しく行われていることを保証するため、各トランザクションを分析して、異常な市況が発生していないかどうかを確認します。このデータは絶え間なく流れ続けるため、SDR は高い信頼性を維持するよう設計されています。

SDR がパフォーマンス メトリックスを満たすのに必要な監視作業と報告作業は、複数のサーバーに分散されています。高い可用性を保証するため、SDR データベース環境内に Microsoft サーバー クラスタリングが実装されました。

図 3 は、SDR における市場監視プロセスの上位レベルの様子を示しています。

図 3: 市場監視データ フロー プロセス

警告管理プロセスは、SDR で使用される基準条件を保守・遂行します。警告管理プロセスは、市場監視グループの次の基本的な活動をサポートするよう設計されました。

既存の警告しきい値を調整したり、市況の変化に対応して新しい警告アルゴリズムを作成したりする。管理者が既存のアルゴリズムを簡単に確認・修正でき、修正によって発生する影響を、実際の業務環境で使用する前にテストできるようなシステムでなければなりません。

次のような方法で「ファーストマーケット」などの刻々と変わる市況に対応する。

• アナリストの役割を変更したり数を増やすことで、ファーストマーケットといった条件下での大量の警告を処理する。
• 警告のしきい値を調整する。
• SDR ユーザーに対して、特定の権限を与える機能を実行する。

このシステム コンポーネントは、管理者が指定したロジックを、配布サーバーから受信した情報に適用します。このようなシステムへの入力によって、SDR アプリケーションが警告生成を決定する際に使用するソース データが作成されます。

警告表示機能によって、認証を受けたすべてのユーザーに警告が発せられます。SDR のサービス レベルは、配布サーバーから情報を受信してから 2 秒以内に市場監視アナリストに警告を発するよう定義されています。

SDR システムのこのコンポーネントは、アナリストが警告を選択してからの、警告の進行状況をアナリストが追跡するための機能を提供します。

統計機能により、市場監視アナリストは、直ちに利用可能なデータに基いて、その場で統計レポートを作成することができます。このデータは SDR によって保持されますが、アナリストは、管理その他の目的に応じて、Crystal Report Writer を使ってサマリーや管理レポートの設計を行うことができます。

データ リポジトリ アーカイブには、アナリストが問題を解決する際に必要となるすべての警告データとバックグラウンド情報が含まれています。

SDR 内では、各プロセスに枢要部があります。枢要部が 1 つでも省略されると警告が発せられ、3 つ省略されるとコンポーネントのエラーを示します。この監視ツールにより、次の SDR サービスがサポートされます。これらの各サービスについては後に解説します。

• ラインハンドラーサーバー
• アラートエンジン
• アラートディスパッチャ
• アナリストサーバー

サービスおよびプロセスの組み込み冗長性により、情報フローが進行とともにサポートされ、サーバーのクラスタリングにより、万が一ハードウェアに問題が発生しても、冗長データベース サポートとサーバー ファイルオーバーが行われます。

トップに戻る

ソフトウェア アーキテクチャ

Microsoft 開発ツールは、強力で、柔軟性があり、統合されたツールです。Microsoft Transaction Server に DCOM を取り入れると、3 階層アプリケーションの開発は容易なります。3 階層アプリケーションは、サーバー中心(サーバー中心主義) とも呼ばれます。これは、プレゼンテーション インターフェイスともデータベースストレージとも独立して機能する中間層サーバーでアプリケーション コンポーネントが実行されるためです。各ユニットを必ず物理的に個別のマシン上で実行しなければならないわけではありませんが、最大限の拡張性と可用性を実現するためには、3 階層システムは次の構成で実行する必要があります。

• プレゼンテーション コンポーネント：デスクトップ クライアントまたはブラウザ
• アプリケーション ロジック： 中間層サーバー
• データ： データベース専用サーバー
• クライアント ワークステーションはデータの処理を行いません。アナリストサーバーとのインターフェイスとなり、認証を受けたアナリストに警告の詳細と履歴を表示します。

この 3 階層アーキテクチャを使用することにより、開発チームは次の機能を活用することができました。

複数のマシン上での、アプリケーション コンポーネントの同時複製

これにより、クライアントの負荷を複数のマシンに分散し、可用性、拡張性、パフォーマンスを向上させることができます。データの複製とは異なり、アプリケーション コンポーネントの複製は、2 階層のクライアント/サーバー アーキテクチャでは実行できません。これは、保管されたプロシージャが単一のデータベースで実行される必要があるためです。

共有データベース接続のサポート

これにより、データベース サーバーがサポートしなければならないセッションの合計数が削減され、パフォーマンスが向上します。

管理の単純化

共通インフラストラクチャにより、すべての中間層 (アプリケーション) コンポーネントを中央でセキュリティ管理できます。アクセスはコンポーネントごとに許可または拒否されるため、管理が単純化されます。

図4 は、Microsoft が提示する 3 階層アプリケーション モデルです。

図 4: 3 階層アプリケーション モデル

Surveillance Delivery Real-Time アーキテクチャ

図 4 を元に、図 5 では、SDR の階層化アーキテクチャを示します。この図は、アーキテクチャ上で、データベース サーバーとクライアント プレゼンテーション インターフェイスの両方から実際のソフトウェア コンポーネントが分離されている、という観点から見た SDR アプリケーションを示しています。

図 5 を参照: システム コンポーネント アーキテクチャ

今回のリリースの SDR では、Microsoft SQL Server 6.5 が使用されます。データベースの主要目的は、アラートエンジンが生成した警告情報をアーカイブすることです。パリティ付きでストライプ処理されたセット内でミラーリングしたドライブを組み合わせることにより、データベース サーバーに可用性の高いフォールト トラレンスが与えられています(RAID 10)。

RAID 10 は RAID レベル 1 と同様のフォールト トラレンスを提供し、ミラーリングのみと同じ費用でフォールト トラレンスを提供します。データベース サーバーに実装されたサーバー クラスタリングによって、ほかのすべての SDR コンポーネントと同じレベルの冗長性と可用性を実現しています。

アプリケーション層には、ラインハンドラー、アラートエンジン、アラートディスパッチャ の 3 つの主要コンポーネントがあります。図 4 に示したアナリストサーバーコンポーネントは、アラートディスパッチャサーバー上にインストールされます。

ラインハンドラーサーバーは、各種の Nasdaq配布サーバーから入力を受け取る役割を持ちます。データは共通の形式で単一のストリームにまとめられ、情報はアラートエンジンに転送されます。

ラインハンドラーサーバーは差異検知の管理も行います。市場調査部門にとって、配布サーバーからすべてのデータを正しい順序で確実に受信することが非常に大切です。差異検知機能は、最終的にアラートエンジンによって生成される情報の正確さを保証する基盤となります。

ラインハンドラーはまた、市場調査SQL データベース サーバーに相場関連データを送る役割も持ちます。相場データは、アラートディスパッチャサーバーに各種のサポートデータを提供するために使用され、1 日の終わりには破棄されます。

アラートエンジンの目的は 1 つですが、それは SDR にとって非常に重要な役割です。このコンポーネントは、ライン ハンドラから受け取ったデータを分析し、その情報を、警告管理プロセスで設定された条件と照合することによって、警告を生成して市場調査アナリストに送るべきかどうかを判断します。サーバーの冗長性のため、アラートエンジンは両方のラインハンドラーで生成されたトランザクションを処理する必要があります。重複した情報は破棄し、その後警告条件を適用して警告ステータスを決定します。アラートエンジンに与えられた処理時間は 2 秒です。このコンポーネントはこの条件を満たすため、一貫して高速で動作する必要があります。

アラートディスパッチャサーバーは、すべての警告をアナリストのワークステーションに送信する役割を持ちます。同時にこの警告情報は、アーカイブのためにSQL Server データベースにも送られます。これらのアクションの処理も多くの時間を必要としますが、アラートエンジンの厳しさからはほど遠いものです。ラインハンドラーと アラートディスパッチャサーバーとの間のトランザクション処理に対して、サービス レベル要件が設定されました。配布サーバーからのデータ受信から、アナリストワークステーションへの警告送信までに許される時間は、最大 2 秒です。

アナリストサーバーは 2 つの役割を持ちます。1 つは、SDR のネットワーク レイヤ コンポーネントとして、アナリストクライアントに警告関連情報を提供すること。もう 1 つは、将来の参考のために履歴と詳細をデータベースに送ることです。このコンポーネントは Microsoft Transaction Server に常駐し、セキュリティ施行のために MTS 機能を利用します。

アナリストクライアントソフトウェアとシステム サポート インターフェイスは、この階層内に存在します。主要機能は、市場調査アナリストのためのプレゼンテーション機能、およびシステム オペレータが使用するサポートベースのインターフェイス画面です。カスタマイズされたグラフィック警告画面その他の出力は、各コンピュータ上にローカルに常駐する SDR クライアント側アプリケーションによって維持・管理されます。SDR の効果的なパフォーマンスには、このレベルのクライアント機能が必要です。

トップに戻る

ハードウェア アーキテクチャ

ハードウェア コンポーネントは、SDR の仕様に組み込まれたすべての要件をサポートするように設計されています。

SDR は、Intel 500 MHz Pentium III Xeon を搭載した、11 機の Unisys QR/2 4 Wayサーバーを使用します。サーバーの構成は、高い可用性をサポートし、Windows NT Server 4.0 Enterprise (Service Pack 4 を含む) 上で動作するように設計されました。

ハードウェアは、次のコンポーネントの技術を最大限に利用します。

• 100 MHz System Management Bus
• Intel® 500 MHz Pentium® III Xeon™ processor (最大 2 MB L2 キャッシュ)
• 最大 8 GB の、キャッシュ可能なアドレス空間
• 最大 4 個のプロセッサに対する、グルーレスなマルチプロセッシング サポート (ほかのクラスタリング技術を使用することにより、8 Way以上のシステムをサポート)
• Intel® Extended Server Memory Architecture および拡張 36 ビット メモリ サポート (これにより、オペレーティング システムおよびアプリケーションで、4 GB 以上のメモリを使用可能)
• システムが温度条件を随時管理するための、熱センサー
• データの完全性を維持するための、ECC (Error Checking and Correction)
• 処理の完全性を確認するための、FRC (Functional Redundancy Checking)
• プロセッサ、熱センサー、プロセッサ固有の PIROM、OEM 書き込み可能な EEPROM、およびシステムのほかの部分との間の効果的な通信を実現する、SMBus (System Management Bus)
• 4 個の 500 ワット ホットスワップ電源装置 (4 個の電源装置により、冗長性を提供)

Unisys は、Nasdaq に納品する Aquanta サーバーに、多くの先進技術を組み込みました。これにより、従来はメインフレームクラスのシステムでしかもたらされなかったレベルの拡張性、可用性、管理性、そして相互運用性が実現されました。

キャッシュ メモリ: プロセッサの最大パフォーマンスを引き出すため、システムには、プロセッサ ボード上に第 3 レベル キャッシュが含まれました。

この文書の「概要」でも述べたとおり、SDR クライアントは、標準の Intel® デスクトップ上で動作します。SDR 開発チームは、次の構成を最低要件として推奨します。品質管理テストはすべてこの構成で行われました。

• 266 MHz Pentium プロセッサ
• 128 MB の RAM
• 2.1 GB の IDE ハード ドライブ
• VGA または SVGA ビデオ解像度
• イーサネット インターフェイス カード

トップに戻る

システム管理

SDR アプリケーションは、Nasdaq および市場監視部門にとってミッションクリティカルなアプリケーションであり、この組織の健全な運営に欠かせない機能を実行する役割を担っています。SDR システムは、市場監視部門の最重要目的を果たすという意味で、ミッションクリティカルです。さらに、Nasdaq で取引を行う個人や企業の利益は、SDR によって正しい監視が行われるか否かにかかっています。

現在の取引量では、1 日に約 350 MB のデータフローが監視システムを通過します。これは、1 秒間に 100 〜 500 メッセージという割合です。市場監視は、1 日に約 4 GB の警告をアーカイブします。

ミッションクリティカルなアプリケーションを正しく実行するには、システムの管理性を確保するため、適切に定義されたいくつかの基準を満たしている必要があります。SDR は、厳格な基準に基いて設計されました。

可用性は通常パーセンテージで表され、最小ダウンタイムは 99.97% です。Nasdaq では、動作時間中の SDR の最小可用性を 99.97% と定義しました。このレベルでは、ダウンタイムは最大でも年間 10 分以内です。営業日の稼働時間が 7.5 時間とすると、年間最大許容ダウンタイムは、(((7.5 × 5) × 52) – (7.5 × 8)) × 0.03= 56.7 分と計算されます。SDR システムは、15 分以内に回復することが求められています。その際のデータ損失は 30 秒以内と定められています。災害回復テストでは、これらの要求を上回る結果が出され、システムのユーザーはフェイルオーバーに気付きませんでした。

システム レベルでは、SDR アプリケーションは 3 倍の冗長性で設計されています。フォールト トラレンスは各サーバー上で採用されています。ラインハンドラー、アラートエンジン、アラートディスパッチャの各 SDR システム コンポーネントには、フェイルオーバー目的で最低 1 つの冗長サーバーがあります。SDR システム全体には、完全に機能するリモート「ホット サイト」があり、プライマリ ロケーションと常に協調して動作し、15 分以内に SDR の全機能を回復します。SDR コンポーネント グループ内には、2 つの ラインハンドラーサーバー、3 つのアラートエンジン、2 つのアラートディスパッチャ、そして 2 つのデータベース サーバーがあります。データベース サーバーでは、Microsoft Clustering サービスの利用により、ほかのすべての SDR コンポーネントと同じレベルの冗長性を提供しています。データベース サーバーはミラー化され、フォールト トラレンスのために RAID 10 が使用され、またサーバーの完全なフェイルオーバー サポートを提供するMSCS (Microsoft Clustering Service) が組み込まれています。

アプリケーションを効果的に実行するためには、負荷レベルが変化した場合でも、一貫性と信頼性を維持しつつ対応できなければなりません。次の表に、SDR の拡張性を示します。

この表のデータから、SDR の拡張性の高さが分かります。Nasdaq での 1 日あたりの平均取引株式数は 10 億、つまり 1 日あたりの電子トランザクションは約 200 万件発生しています。SDR システムは、この 2 倍の量で通常どおり動作し、また 1 日あたり 40 億株まで問題なく拡張できるようにベンチマークが定められました。Nasdaq で 10 億株が取引される場合、200 万トランザクションが SDR で処理される必要があります。1 日に 7.5 時間稼動するとして、1 秒あたりのトランザクション数は、2,000,000 ÷ ((7.5 × 60) × 60) = 75 トランザクションと計算されます。同様の計算で、500 万トランザクションの場合は、1 秒あたり 185 トランザクションとなります。どちらのレベルでも、それぞれのピーク値に収まります。

取引される株式から電子トランザクションへの変換は指数関数的なため、トランザクション処理能力の上限を定めるベンチマークも定義されました。1 秒あたり 450 という値は、取引活動の一時的な波 (頂点) を反映して最適に表されたピーク値であり、取引時間中全体にわたって適用される値ではありません。このピーク値が 7.5 時間続くと、1 日あたり 1200 万トランザクションになってしまいます。この値は、1 日に取引される株式量と、実行される電子トランザクションの両面で、SDR の上限を超えています。

SDR では、Visual C++ と DCOM が使用されているため、論理的変更も構造上の変更も、再エンジニアリングの必要なく、動作しているプログラムに組み込むことができます。この柔軟性は非常に重要です。この環境では、アプリケーションを再コード化するためにダウンタイムや付加費用を発生させることは容認されません。

ミッションクリティカルなアプリケーション実装の際に考慮すべきもう 1 つの点は、情報とリソースのセキュリティです。Nasdaq では、SDR サブネットにアクセス権を持つユーザーの認証を、Windows NT セキュリティ システムに依存しています。システムがアナリストを認識すると、内部フィルタが適用され、そのユーザーのログイン ID に基いて、どの権限や機能が実行可能かが決定されます。アナリストのネットワーク ログイン ID は、SDR システム内のユーザー データベースに対応しています。このデータベースによって、認証レベルと、ユーザーがアクセスを許可されている SDR リソースが識別されます。

SDR システム サーバーは、アナリストのいる場所から物理的に隔離されており、Nadaq データ センター内で安全に保護されています。隔離されたサブネットによって、システムは不必要なネットワーク トラフィックから保護されます。Microsoft Transaction Server は、認証を受けたユーザーだけにアクセス権が与えられるよう支援します。

トップに戻る

将来の展望

Nasdaq は、将来を見据えて、この新しいミレニアムに踏み出しました。

すでに Windows 2000 オペレーティング システムのベータ サイトであり、Windows 2000 への移行計画も作成中です。SDR 開発チームは、Windows 2000 プラットフォームへの移行を考慮にいれた SDR アプリケーションの改訂と拡張に取り組んでいます。Windows 2000 は、SDR の既存の利点を強化し、問題点を取り除きます。現在のプラットフォームは良き出発点となっており、将来に引き継ぐべき特徴を備えています。Nasdaq では現在の Microsoft SQL Server 6.5 データベースを SQL Server 7.0 へ移行する計画があり、最終的には SQL Server 7.5 をいち早く採用するユーザーとなるでしょう。

Nasdaq は、ES 5000 プラットフォーム上で、Unisys の新しい esPerformance、esUptime、および esManagement ソフトウェア スイートのテストを開始する予定です。これらの製品によって、重要なアプリケーションをサポートするための Windows NT の機能が拡張されます。Nasdaq はまた、Unisys の 高度 CMP (Cellular Multiprocessing) アーキテクチャに基いた新しいサーバーの評価を行う予定です。このサーバーは、Intel プロセッサベースのシステム上で、真のメインフレームクラスのコンピューティングを実現するために設計されました。システムは、2000 年に実用可能となる予定です。

トップに戻る

まとめ

Nasdaq Stock Market は、ハイエンドな Intel Pentium クラス サーバー上でオープンな技術を使用して、ミッションクリティカルなアプリケーションとしての Surveillance Delivery Real-Time System を開発しました。SDR のこの側面により、作成に使われた開発プラットフォーム、常駐先のネットワーク環境、そしてこのアプリケーションを完成させた開発チームにとって、SDR は興味深く、価値あるものになりました。

Nasdaq は、市場を監視し、株主にも投資家にも等しく公正な取引環境を提供する必要がありました。過去数年間で、ビジネス環境における力学は変化しました。企業の構造や活動は、変化する要求に対応するために変貌しました。それよりもはるかに速く変化する環境で、Nasdaq は、急速に変化する市場に対応する必要性を認め、これまで警告プロセスをサポートしてきたアプリケーションが、すでに戦略的に強固なものではなくなったことを認識しました。最終的に選ばれるアプリケーションであるためには、瞬時に市場トランザクションを分析し、状況を判断し、警告関連情報をアナリストに伝える能力を持っていなければなりませんでした。

SDR のように重要で強固なアプリケーションには、優秀な開発者がつきものです。また、強力なチームなしにはこのようなアプリケーションの開発は実現しません。この文書では、このアプリケーションの開発を支援したベンダ (Unisys、MMA、Microsoft) を紹介し、開発への貢献について述べました。

最新の技術を活用し、厳しい開発スケジュールが求められる中、短期間でアプリケーションを実務に利用可能な品質に仕上げるため、SDR チームは短い開発サイクルの中で作業しなければなりませんでした。この文書では、SDR の開発においてチームが実行してきたプロセスを振り返りました。また、SDR の作成において使用されたプログラミング言語とプログラミング モデルについて詳しく述べました。

アプリケーションがミッションクリティカルであるためには、いくつかの条件を満たしている必要があります。この文書では、SDR に関する信頼性、拡張性、冗長性、そして柔軟性について述べ、このアプリケーションがどのようにこれらの条件を満たしているかを解説しました。また、これらの高い可用性要求の重要性と関連性についても述べました。

トップに戻る

この文書に記載された情報は、Nasdaq Stock Market Inc. が著作権を有する情報に基いています。