東証システム障害の一部始終と残る疑問、NAS故障と切替設定の不備が重なる!東証と富士通、見逃した仕様変更とマニュアルの不一致

東証システム障害の一部始終と残る疑問、NAS故障と切替設定の不備が重なる

 東証の売買システム「arrowhead(アローヘッド)」で取引に支障をきたす大規模なシステム障害が発生したのは2018年10月以来。システム障害により全銘柄の売買を終日停止する事態は東証が取引を全面的にシステム化した1999年以降初めてだ。

 これにより、3兆円規模の売買機会が失われた。影響は東証だけにとどまらず、arrowheadを使用している名古屋・札幌・福岡の各証券取引所でも10月1日の取引が全銘柄で終日にわたり停止となった。

設定不備で切り替えできず

 同社が最初に異常を検知したのは、午前9時の取引開始を約2時間後に控えた午前7時4分だ。arrowheadを構成する運用系ネットワーク内で、同社が「共有ディスク装置」と呼ぶNAS(Network Attached Storage)1号機のメモリーに故障が発生した。

 NASは、arrowheadの複数のサブシステムが共通で使用する認証用のデータなどを格納している。1号機と2号機をActive-Active構成で運用しているが、1号機の障害発生時に2号機のみの運用へ自動で切り替える機能が正常に働かなかった。

 この影響で、本来はarrowheadのサブシステムの1つである「情報配信ゲートウエイ」を通じ、同日午前7時0分に送信すべき電文の送信ができなかった。別のサブシステムである「売買監視サーバー」や監視端末へのログインも不可能になるなど、NASの停止による影響はarrowheadを構成する複数のサブシステムに広がった。

 証券会社など外部に異変を通知したのは約1時間後の午前8時1分。さらに午前8時30分すぎに、午前9時からの取引を停止すると通知。午前8時54分には障害の影響が東証以外のシステムに波及しないよう、arrowheadと証券会社間の発注系経路を遮断。

 原因究明と復旧作業を進めたが、結局午前11時45分に終日売買停止を発表した。原因となったメモリーが載った基板を同日中に交換したうえでシステムを再起動し、翌10月2日午前9時から売買を再開した。

 その後の調査で、富士通が納入したNASのファームウエアの設定不備が大規模障害につながったことが判明した。2台構成のNASの1台で障害が発生しても、本来はもう1台のみの運用に自動で切り替えてarrowhead全体の運用に支障が出ない設計だった。

 しかし実際には、NASのファームウエアの切り替え用設定値に誤りがあり、メモリー故障に起因する障害パターンが発生した際はNASの冗長化が機能しなくなっていた。

東証と富士通、見逃した仕様変更とマニュアルの不一致 

東京証券取引所で10月1日に起きた大規模システム障害の真因が分かった。富士通が作成したNAS(ネットワーク接続ハードディスク)のマニュアルに不備があり、東証と富士通はそれを5年以上見逃していた。東証はこれまでシステムを停止させない「ネバーストップ」を掲げてシステムの信頼性を高めてきたが、今後はシステム障害が発生しても短時間に復旧させる「レジリエンス(障害回復力)」も重視する方針に大きくかじを切る…

株式会社東京証券取引所

10 月 1 日に株式売買システムで発生した障害について

2020 年 10 月 1 日に株式売買システム「arrowhead」で発生した障害により、投資家 の方々をはじめ、多くの市場関係者の皆様に御迷惑をお掛けしましたことを改めて深く お詫び申し上げます。

今回発生した事象に関し、経緯、原因及び再発防止措置等について御報告します。 1. 経緯

(1)事象発生から売買停止まで
10 月 1 日午前 7 時 4 分、共有ディスク装置1(以下「NAS」という)1 号機へ

のアクセス異常を示すメッセージを大量に検知しました。その後、社内で使用 する売買監理画面が使用できなくなり、また、通常 7 時以降にユーザ向けに配 信している相場情報の一部が配信できていない事象が発生しました。

開発ベンダである富士通と確認を進めたところ、メモリ故障を契機に NAS 1 号機の制御機構がダウンし、2 号機に自動的に切替えが行われないことによ り、NAS 全体が使用できない状態であることを 7 時 55 分に確認しました。

その後、継続的に切替え作業を続けていたものの、NAS2 号機への切替えの目 途が立たず、正しく情報配信できない状況であったことから、全銘柄の売買を 9 時の立会開始から停止することを 8 時 36 分に決定し、公表しました。

売買停止に際しては、通常、社内の売買監理画面を使って操作しますが、当 該機能が NAS にアクセスする処理であったことから、別の停止手段として、

1 複数サーバにおいて共通で使用される、銘柄情報やユーザ情報等のファイルを NAS(Network Attached Storage)に格納しています。

arrowhead と取引参加者をつなぐネットワーク上の接続部を遮断することと し、8 時 54 分に当該指示を行いました。

(2)再開に向けた検討から終日売買停止まで
その後、9 時 26 分に NAS 2 号機への手動での切替えが成功し、各種機能が正

常に動作する状態になりました。 当日中の売買再開に向けて、システムの復旧に向けた検討に着手しました

が、ネットワークは遮断したものの、arrowhead 内部では 8 時 54 分までの注文 をもとにした約定が発生し、取引参加者へ応答せず滞留している状況であった ことから、注文の扱いや内部で発生した約定の扱い、値段の連続性等を考慮 し、arrowhead の再立ち上げが適切であると考えました。

取引参加者やベンダの注文の再発注等の対応可否や対応時間も考慮するた め、ヒアリングを行ったところ、対応可能な取引参加者の数や属性、売買代金 シェアが限定的であり、市場における価格形成の公正性・信頼性が確保できな いおそれがあることが分かりました。

併せて、既に受け付けた注文の取引参加者側での取扱い等を考慮すると再開 した場合には混乱が生じることが予想されたため、11 時 45 分に売買を終日停 止することを決定し、その旨公表しました。

(3)翌日の取引に向けて
NAS 1 号機の故障したメモリ2を搭載したマザーボード3を当日中に交換し、翌

日は通常どおり取引を行いました。 2. 障害の原因

(1) NAS 2 号機への自動切替えが正常に動作しなかった理由
当社は、NAS 故障時でも 30 秒以内に切替えて、業務を継続できることをシステム

2 工場での調査の結果、メモリカードに対して読み書きできない部品故障と断定されました。また、製造 ロットによる不良でないことも確認されました。

3 メモリやCPU等を搭載した基盤部分です。

要件として定めています。現行 arrowhead4構築時に、富士通の製品マニュアルを参 照して NAS の設定値の妥当性を当社と富士通で共同検討しましたが、そこには切替 えに関する設定値に拠らず自動切替えが動作すると記載されていたことから、同設 定値におけるこれまでの arrowhead の稼働実績に鑑み、富士通の設定値を当社が確 認のうえ、決定しました。

しかし実際には、arrowhead に設定した値ではメモリ障害時には自動的に切り替 わらない製品仕様であることが、本障害後の調査で判明しました。マニュアルの不 備により正しい仕様が把握できませんでした5 6。

富士通では、通常、初期設定値でマニュアルどおりに動作することをテストして から製品として出荷します。今回、arrowhead に設定した値は初期設定値ではなか ったため、出荷時、机上で仕様を確認したものの、テストは行われていませんでし た。当社においても NAS の切替えテストは実施していましたが、切替え後の業務継 続に確認の重きを置き、設定値とマニュアルの整合性については富士通内の製品出 荷プロセスで検証されている前提であったことから、テスト時はネットワーク故障 を疑似的に発生させることで、切替えが正常に行われ業務継続できることを確認し ていました。

なお、NAS の手動での切替え完了まで時間を要したのは、自動的に切り替えられ る機構であることを前提として、障害対応手順を整備していたことに拠ります。

(2) 当日中の取引再開ができなかった理由 1 システム面

売買停止のためにネットワークを遮断しましたが、arrowhead 内部では約定等 の処理が動き続けました。その結果、再開に向けた手順や確認項目が多くなりま した。不測の事態に備え、複数種類の売買停止手段は用意していましたが、NAS が 使えない場合においても確実に売買を停止する手段を具備していなかったこと が問題と認識しています。

4 現行システム=2019年11月稼働
5 2015年9月に稼働した2代目のarrowhead開発時からマニュアルの不備が発生していました。 6 NAS設定値の経緯については、別紙「(補足資料)NAS設定値について」をご参照ください。

2 運用面
arrowhead を再立ち上げして売買を再開するという手順については取引参加者

との合意もなく、テストも実施していない中で、不安定な対応は市場開設者とし て採用すべきではないと判断しました。システム障害発生時の売買停止後の再開 に係る取扱いルールが整備されていなかったことが問題と認識しています。

3. 再発防止のために講じる措置

arrowhead はこれまで「Never Stop」をスローガンとして、信頼性を高める施策 に取り組んで参りましたが、今後は、迅速かつ適切な回復策を拡充すべく、「レジリ エンス(障害回復力)」も同様に重視して取り組みます。

再発防止策

内容

1 システム対応と総 点検

(2.(1)への対応)

  • ・  NAS 切替え設定値の修正(10 月 5 日完了)

  • ・  NAS 設定値の総点検(10 月末まで)

  • ・  確実に切り替える手段の確認・整備(11 月末まで)

  • ・  切替えテスト・訓練(NAS については 21 年 1 月まで:

    その後も継続)

2 確実に売買停止を するための手段の 拡充

(2.(2)1への対応)

・ 売買停止できないケースの確認(10 月末まで)
・ (該当ケースがある場合)指示方法や運用手順の整

備(11 月末まで)
・ NAS を経由しない売買停止機能の開発(11 月末まで)

3 市場停止及び再開 に係るルールの整 備等

(2.(2)2への対応)

取引参加者・投資家・システムベンダー等から構成され る「再発防止策検討協議会」を設置し、議論のうえルー ル等を整備(21 年 3 月末目途)
・ 当日中に売買を再開するために必要となるルール

・ 売買の再開に向けた手順の整備 ・ 売買停止・再開の基準の明確化 ・ 情報発信の在り方、等

以上

🍎たったひとつの真実見抜く、見た目は大人、頭脳は子供、その名は名馬鹿ヒカル!🍏

“東証を変えた男”が語る、金融業界の伝説「arrowhead」誕生の舞台裏――“決して落としてはならないシステム”ができるまで

 2005年11月から2006年にかけて、金融業界に激震が走った。東京証券取引所のシステムが数回、障害を起こし、株式取引が全面停止するという事態にまで陥ったのだ。

 世間に大バッシングの嵐が吹き荒れる中、東証のCIO(Chief Information Officer:ITとビジネスをつなぐ役割を担う情報システム部門担当役員の名称)としてシステム全面刷新の指揮を執り、高い信頼性を保ちながら、取引の応答速度を1000分の1にするという偉業を成し遂げたのが、現在、日本郵便で専務を務める鈴木義伯氏だ。同氏が率いた「arrowheadプロジェクト」は、金融業界のシステム開発者の間で「伝説のプロジェクト」として語り継がれている。

 日本を代表する重要インフラ企業のCIOとして、これまで数々の難題をクリアしてきた「国内きっての“プロCIO”」である鈴木氏は、失敗が許されない重責の中でどのように仕事に取り組み、ビジネスの課題をITで解決してきたのか。また、日本企業の情報システム部門の在り方についてどんな考えを持っているのか――。クックパッドのコーポレートエンジニアリング部で部長を務める中野仁氏が話を聞いた。

「バブル崩壊で窮地に陥った地銀を救え!」 地銀を束ねてシステムを共同化

中野: 鈴木さんといえば、金融業界伝説のプロジェクトといわれる「arrowhead」を完成させた豪腕CIOとして知られています。そもそもなぜ、ITの仕事を選んだのですか。

鈴木: 私はもともと大学で電子工学を学んでおり、自分の専門性を生かした大きなプロジェクトを運営し、社会に貢献したいと考えていました。それを実現できそうな会社として日本電信電話公社(現NTT)に入社したのです。

 最初に配属されたのが「データ通信事業本部」という、当時、できたばかりの計算機と通信を手掛ける部署で、その後、この部署を母体にしたNTTデータが設立されてからも、変わらず計算機の仕事に携わってきました。ですから、それ以外のことは実はあまり良く知らないのです(笑)。

 NTTデータにいた当時は、ITに対する投資のボリュームは金融業界が最も大きかったので、私も自ずと金融の案件に携わるようになりました。特に地方銀行の案件をメインで担当しており、銀行のIT部門の方々よりも、経営企画の方々と一緒に事業を創っていくような仕事が多かったので、自然と経営企画の方々と仲良くなりました。

 そういう方々の中から銀行経営の中枢に上っていく人たちも多いですし、頭取まで上り詰める方も少なくないので、結果として銀行の中枢の方々と懇意になることができました。そういうコネクションができて、直接、いろいろと相談できる関係になれたことは、とてもラッキーでしたね。

中野: 当時はちょうどバブル全盛期からバブル崩壊あたりの時代で、銀行では第三次オンライン真っ盛りの頃ですね。

鈴木: バブル崩壊の際、銀行が大変な状況に陥ってしまったのは、ご存じの通りです。そこで何とか地方銀行の経営を支えたいと思って、勘定系システムを複数の地方銀行で共同化する仕組みを提案しました。

 コンセプトは極めてシンプルで、「過去8年分の予算額を教えてください。その半分の予算で勘定系システムを提供します」というプロジェクトです。その上で「8年間継続利用してください」というのが条件でした。

 もう1つ、参加の条件として挙げたのが、「機能追加のために毎年10億円の投資をさせてください」ということでした。共同利用のシステムの場合、“機能追加のための予算をどこが持つか”を調整するのが難しいところなのですが、あらかじめ「毎年10億円の予算」を確保しておけば、この問題で頭を悩ませる必要がありません。

 さらにもう1つ、「預金量30兆円以上の規模の銀行数行にメンバーとして集まっていただく」という条件も挙げていました。この条件はハードルが高いかと思いましたが、それに見合う銀行が一定数以上集まらないと共同利用システムは実現しませんから、参加する銀行が自らほかの銀行に積極的に声を掛けてくれました。

 こうして複数の地方銀行で共同利用する勘定系システムの開発を始めたのですが、初回リリースは結果的には相当な予算オーバーになってしまいました。1400万ステップという膨大なプログラムを一気に開発したので、死ぬかと思いましたね(笑)。

中野: 私も実はもともと金融系のSIer(企業のIT導入支援、コンサルティングを請け負う企業)で開発の仕事をしていたので、この地方銀行の勘定系統合プロジェクトの話はたびたび耳にしました。金融業界ではとても有名な、大きなプロジェクトですよね。私は某都市銀行の合併案件に携わったことがあるのですが、下っ端の私でも死ぬかと思うくらい大変な仕事でした。鈴木さんの案件では、それぞれの銀行が異なる要件を持っているから、それをすり合わせるのはさぞや大変だったのではないでしょうか。

鈴木: 確かに大変でしたね。この課題をどう解決したかというと、集まった地方銀行の中でも熱心で、発言力や統率力がある代表の銀行さんと相談して、そこで決めた内容にほかの銀行さんにも従ってもらうという方法をとりました。

鈴木: NTTではそんな仕事を手掛けていたところ、2005年から2006年にかけて、東京証券取引所が相次いで深刻なシステム障害を起こし、社会問題にまで発展するという事態が起こったのです。当時、私はNTTデータの子会社であるNTTデータフォースの社長を務めていましたが、急きょ、東京証券取引所のCIOに就任し、システムの立て直しを指揮することになりました。

中野: 当時は断れない状況だったのですか?

鈴木: 断れないですね。当時、西室泰三さんが東証の社長に就任しており、彼がNTTに「誰か出してほしい」とリクエストを出して、結果的に私が行くことになりました。当時の東証が置かれていた状況は極めて深刻で、金融庁もIT業界全体も「早くこの状況を解決しないと、金融業界の信用を揺るがす大変なことになる」というのが共通認識でした。

 金融インフラである東証の問題でもあり、ひいては財界全体の総意でもあったわけですよ。そういう構造だったので、断るという道は残されていませんでしたね。「できるのか、できないのか」という打診ではなく、「どうやったらできるんだ」という形での要請でしたから。

Photo

危機にひんした東証にCIOとして就任。そこで見たのは……(提供:ゲッティイメージズ)

中野: 実際に東証へ行かれたときの第一印象はいかがでしたか。

鈴木: あれだけ力のあるメンバーがそろっている東証でさえ、こういう状況になってしまうんだなと驚きました。簡単に言えば、「外部への依存度が高いシステム作りをしていると、自主的にいろいろなことの判断ができなくなってしまう」ということがだんだん分かってきたんです。

 また、当時は、「ITが企業の中核である」といった状況ではなかったのも事実です。

 そんな状況下でCIOに着任したわけですが、当時は世間のバッシングがそれはもうすさまじくて、社内でもさすがに危機感が高まっていました。素早く結論を出して実行できたのは、そのためですね。危機感が高まれば高まるほど「どうにかしなければならない」と社内がまとまりやすくなりますから。あとはアイデアが出せるかどうか、だけです。

中野: 「ITが中核でない」というのは、古くからある業界や大きな会社ではよく聞く話ですね。

鈴木: 企業の中でITが、まだまだ特殊な業務だと思われているんですね。でも、「ITが特殊だ」なんて言ってる間は、まぁ、ダメですね。事業全体の中で、ITが財務や中核事業などと肩を並べるぐらいの位置付けにならなければダメですよ。

中野: 東証も銀行もほぼ装置産業で、中身はほとんどITですよね。例えばネット銀行やネット証券は店舗を持たず、社員も最小限ですが、システム周りがきちんとしていればそれだけでもビジネスが回ります。

 それぐらい、金融においてはITが重要なわけですが、そうであるにもかかわらずITが傍流というのは、本当に根深い問題だと思います。メーカーや物流、小売りなど、ビジネスにおいてITが占める割合が少ない業界ではなおさらですね。

鈴木: そうですね。そういった背景もあって、私が東証に行くときに条件として要求したのは、「CIOとして経営メンバーの一員にしてほしい」ということでした。経営層として入らないと、言いたいことも言えないし、社内で自分の考えもなかなか通りませんから。あともう1つ、NTTデータから、一緒に東証に来て変化の仕組みを考えられるスタッフを連れていくことを条件に挙げました。この人たちには、2年後にちゃんと元の職場に戻ってもらいましたが。

“決して落としてはならないシステム”をどうやって生み出したのか

鈴木: 着任して3カ月後に今後の計画を提出した際、最も重視したのが、当時、東証が抱えていた「構造的な問題」を根本から解決することでした。現在の日本郵便にも同じことが言えますが、一番の問題は「企業内のITの構造が、『システム開発を目的としているITベンダー(企業向けのサービスやシステムを提供する会社)と同じ構造』になっていること」だったからです。

 つまり、「自分たちが主体性を持って開発する」という構造になっていないんですね。本来は、技術を活用して事業を作り、お客さまにより良いサービスを提供するのがITの役割であるにもかかわらず、そうなっていない。それを可能にする構造に社内の体制を変えるために、その後、1年半ほどかけて東証用のエンタープライズアーキテクチャ(EA:企業のビジョンや目的を実現するために、組織構成や情報システムのあるべき姿、各部門の業務内容と連携の状況などといった要素を見直し、全体最適の視点で最適化する手法)を作りました。

中野: 具体的には、どのようなことを定めたのですか。

鈴木: 「何か物事を検討する際には、IT部門内だけでなく、業務部門と一緒に要件を整理する」「要求はどの時点でどうやってITベンダーに発注するかを明確にする」「その時にITベンダーとの間の契約はどうするか、業務部門とはどのように役割を分担するかをはっきりさせる」といったように、具体的な目的や目標を設定して、それらをきちんと実現できるプロセスになっているかどうかを工程の途中でしっかり評価するようにしました。

 また、工程の最初の段階で、工程の組み方からチームの作り方、システムの作り方など、さまざまな面で考え得るリスクを全て抽出して、これらをどうやってリスクヘッジするかを整理しました。正確に言うと、リスクをヘッジするというよりは、リスクをコントロールするという考え方ですね。これらの方針や考え方をEAとしてまとめたわけです。

 会社の文化はすぐには変わりませんから、まずは理想のモデルをEAとして提示して、それに基づいて社員が働けるようにしましたね。そうすると、徐々にそれにのっとった仕事の実績が積み上がっていき、何年かするうちに文化として徐々に定着していくんですよ。こうしたことを可能にするには、まずは仕掛けをちゃんと作る必要がある。

中野: そうすることで中で働く人の考え方が徐々に変わっていって、IT部門も組織全体としてやる気が出て、結果として一人ひとりが自走できる人間へと成長していけるわけですね。

鈴木: そうですね。厳しい仕事が多くなりますが、誰も文句なんか言わないですよ。こうした仕掛けを取り入れることで、自身がやるべきことがはっきり見えるし、やったことに対して会社側もきちんと評価できるようになるのだから。

中野: 「自分で問題を解決している」「自分で考えて自分で成果を出している」と実感できることが何より大事ですよね。IT部門の仕事は、どうしても“業務部門の御用聞き”になりがちですが、それでは優秀な人が伸びるわけがありませんし、そもそも優秀な人がそんなところで働きたいと思うわけがありません。

 ちなみに、そうやって東証の構造を変革していったからこそarrowheadプロジェクトを成功に導けたのだと思いますが、社外のパートナー企業との関係性はどうたったのでしょうか。やはりそこも変えていったのでしょうか。

鈴木: 主要な開発パートナーは、実はトラブルを起こす前と同じ会社だったのですが、これは入札の結果、たまたまそうなっただけでした。しかし、トラブル前とは異なり、私たちもEAに基づいてどんどんプロジェクトに介入し、どちらかというとITベンダーをコントロールするように変わっていたから、新たな関係性を基に、互いに刺激し合いながら伸びていくことができました。

 その証拠に、開発パートナーでarrowheadプロジェクトに関わっていた人の中から、その後、副社長や中枢メンバーに出世した人が何人か出ているし、それを見たパートナー企業の社内では「次のarrowheadプロジェクトには、ぜひ参加したい」という声も挙がっていたようです。

 また、東証でも、当時のIT部門にいた人たちの中から、その後役員になった人が数人います。東証では現在、IT部門の存在感は他の部署と同等になっているし、CIOは生え抜きの人が務めている。外部から招いた人材ではなく、内部の社員からCIOを選べるようになったのは、とてもいいことですよ。そういう意味では、日本郵便はまだ成長の途上なのかもしれません。

中野: IT組織の戦闘力は、会社全体の強さに直結しますよね。しっかりやるとレバレッジを効かせることができます。

鈴木: 今の時代はまさにそうですね。かつてのように、業務をITに置き換えていた時代には、ITにはさほど大きな影響力はなかったわけですが、今日のようにITで事業を創る時代には、もうITの活用力が企業の成長そのものに直接影響を及ぼすのだから。

目標値の5倍速い! 爆速「arrowhead」を生み出した富士通の技術と発想のヒミツ

 富士通が東京証券取引所に納入した株式売買システム「arrowhead(アローヘッド)」は、2010年1月4日の稼働以来、現在までの約3カ月間、トラブルなく運用されている。

 arrowheadは、注文応答時間や情報配信スピードの高速化を実現し、注文、約定、注文板などの取引情報を、異なるサーバ上で三重化して処理するなど、高速性と信頼性を兼ね備えた「世界最高水準の取引所システム」と位置づけられているものだ。

 富士通では、arrowheadについて「金融テクノロジの高度化などを背景に、個人投資家のオンライン取引の普及や、証券会社や機関投資家によるアルゴリズム取引など、新たな取引が広がりをみせている。こうした市場環境や取引形態の変化のなかで、注文レスポンスや市場情報配信の高速化のニーズが高まっており、東京証券市場の国際的な市場競争力を強化するためにも、大規模なサーバシステム上で、高性能、高信頼なミッションクリティカルシステムを実現する必要があった。新たな先進技術や機能強化を組み入れたミドルウェアの採用など、富士通の総合力を結集して構築した」と説明する。

 中でも、arrowheadに求められていたのは「10ミリ秒」(1ミリ秒は1秒の1000分の1)の高速性だったという。株式売買の発注元から注文を受け、応答保証サーバで受付通知のキューを発行し、受付通知を発注元に戻すまでの目標時間とされていたのが「10ミリ秒」だったのだ。

 これに対して、富士通では1月の稼働時点で「5ミリ秒の注文応答時間を実現する」と発表。この時点で、目標の2倍以上のスピードだが、現在の実績は、なんと「2ミリ秒」。目標の5倍にあたるレベルでの高速稼働を実現しているという。この高速性はarrowheadの最大の特徴ともいえるものだ。

ミリ秒単位のレスポンスを支えるインメモリDBMS

 この高速性を支える基幹ソフトウェアが、インメモリデータの高速データ管理ミドルウェア「Primesoft Server」である。

 「基幹IAサーバにはPRIMEQUESTを採用し、SANディスクアレイとしてETERNUSを採用している。だが、これらのハードウェアの仕様は特別なものでない。これだけの高速性を実現しているのは、Primesoft Serverによるところが大きい」と語るのは、富士通、プラットフォームソフトウェア事業本部、次世代社会基盤ミドルウェア開発統括部部長代理の橋詰保彦氏だ。

 Primesoft Serverでは、メモリ上に取引情報を配置することで、超高速データアクセスと、高いレスポンス性能、高スループットを実現している。「高速アクセスにおいて、ネックとなるのがI/O。ディスクアクセスをなくすことでI/Oのネックをなくし、メモリ上で高速アクセスするという、これまでの既存技術にとらわれない発想によって実現した」(橋詰氏)とする。

 ログ情報についてもインメモリ処理を行っており、これもPrimesoft Serverならではの特徴といえる。さらに、メモリ上に配置した取引情報を三重化。各データ処理の実行環境は、「アプリケーション層」「インスタンス層」「ノード層」の3層に切り分け、アクティブインスタンスの異常時には、わずか数秒で、スタンバイインスタンスに切り替えることができるという。

 「異常検知を含んで1.5秒程度での切り替えが可能。誤認なく異常を検知するという点で工夫を凝らしているのが、Primesoft Serverの特徴と言える」(橋詰氏)

 異常個所に応じた三層の自動切り替えも、安定したシステム運用を実現するための仕掛けだという。また、レスポンス確保に特化したフロントエンドと、データ蓄積のためのバックエンドとに処理を分離。フロントエンドでは、ディスクアクセスをなくすとともに、機能分散された各サーバを非同期メッセージングで連携する。さらに、同一機能を持つサーバを並列に配置することで、スケールアウト型の拡張性を確保している。これも高速性、信頼性に大きく寄与しているポイントだ。非同期な処理連携を行うPrimesoftキューは、高速でメッセージ送信順に通番を払い出し、連続性を保証するとともに、業務のリカバリの際にも利用されることになる。

ネットワークの問題も独自の技術と発想で解決

 高速アクセスを実現するにあたって、もうひとつのネックとなるのが「ネットワーク」である。ここではメモリアクセスのような決定的な回避策というものはないという。しかし、arrowheadはこの問題についても、これまでの考え方を打ち破る手法で解決している。

 「信頼性が高いが高速性で課題が残るTCPではなく、高速性を実現できる軽量なUDPプロトコルを採用した。ただし、信頼性を確保するため、富士通独自の送達確認技術を活用することにした。このプロトコルは、汎用的なものである必要がないため、独自の技術を採用するという判断をした。複数の受信インスタンスに対する多彩な送達確認パターンを実装し、局面に応じて使い分けるレイヤードACK技術を活用した」(橋詰氏)

 また、2系統に同一データを送信して、受信側が早く到着したデータを使用するという仕組みを使い、後からきたデータは削除するという処理も行っている。「同じデータを送信し、片方を捨てるというやり方は、一見無駄に見えるが、片方の系統に異常が発生してもデータを再送せずに業務を継続できる。ネットワーク異常時も性能劣化がない通信が実現できる」という。

 一方で、拡張性にも配慮している。arrowheadでは、安定した取引サービスを提供できるよう、常にピーク値の2倍のキャパシティを確保しているという。必要に応じての拡張は、1週間程度で実現。稼働時点でも、過去のピーク値の約4倍のキャパシティを確保できているという。

 パーティショニングによるデータの自由なノード配置を行うことで、CPUやメモリ不足時にはノードグループを追加して拡張できるようになるほか、突発的な呼量増加に対応する動的データ再配置機能によって、UAPサービスの一部資源を数分で予備UAPサービスに移動できる。例えば、1月4日のJALの取引量増加の際には、前場の動きを見て後場にはUAPサービスを独立したものに移動。4月1日の第一生命の上場の際にも、事前に独立したUAPサービスに定義しておくといった柔軟性のあるリソース配備を行っている。

 「Primesoft Serverの開発にあたっては、データベースやネットワークのエキスパートを集める一方、既存技術にとらわれない発想をコンセプトとした。メモリ上で冗長構成を実現するということ自体が既存技術にとらわれない発想といえる。専門的に深堀りしすぎると限界が生じる。既存技術にとらわれないことが、桁違いの高速性を実現することにつながった」(橋詰氏)

 arrowheadは、まさに現在におけるミッションクリティカルシステムの最高峰といえる。富士通の最先端技術が数多く注ぎ込まれていることに加え、既存の発想を越えた取り組みがあったことが、これまでにない高信頼、高可用、高速なシステムとして実を結んだのだ。

🍎たったひとつの真実見抜く、見た目は大人、頭脳は子供、その名は名馬鹿ヒカル!🍏