東証「arrowhead」システム更新の話
オンプレミスで苦闘するのが当然だったころのインフラエンジニアの現場は傭兵が集う戦場のような張り詰めた雰囲気があったのを思い出しますが、クラウド全盛の時代にもなおそんな現場があるんだと感心した記事です。
arrowheadは取引参加者から注文を受け付ける参加者ゲートウエイ（GW）、注文の「付合せ（マッチング）」を担うトレーディングサーバー、相場情報を外部に配信する情報配信GWなどから成る。
刷新したシステムには富士通製のサーバー「PRIMERGY」を約400台使っている。初代arrowheadには主に大型サーバー「PRIMEQUEST」を使っていたが、1度目の刷新で全体の約9割を「PRIMERGY」に置き換えた。今回の刷新で「PRIMERGY」のみとなった。
「基本的なアーキテクチャーを変えずに性能向上を図った」（arrowheadの開発を担当した富士通の田中満第一システム事業本部デジタルビジネス事業部シニアマネージャー）。トレーディングに関わるデータ処理をサーバーのメモリー上で完結させたり、サーバーを三重化することで最新のデータを確実に保持できるようにしたりする仕組みを引き継いだ。
東証の取引所システム構築。日本で有数のミッションクリティカルシステムだと思います。日本の経済システムのコアとも言える場所で、これを設計・構築しサービスインにまでこぎつけられる技術者は私は日本でも最高峰の技術レベルの方だと思います。
サービスイン後も安定していますし、関係者はまずはほっとしているということでしょう。
冗長構成の勘所
上記記事は有料記事で私は会員になっているので先まで読めるのですが、その中に冗長構成に関する記載があります。具体的に言えば、冗長構成を組んでいる機器同士において、機器監視を実施し何らかの異常があれば、電源タップからの電源供給ごと停止し完全に機器を停止させてしまうという情報が書かれています。
ネットワーク機器でもサーバー上のソフトウェアでも、冗長構成（クラスター）を組んで可用性を担保する設計にすることはよくあることと思います。
私の経験上、この冗長構成が、障害時いざというときにちゃんと働かず、障害となることを何度も何度も経験しました。
ユーザーからは、「なぜ冗長構成にしているのに止まるのか」「冗長構成が正しく動くかテストをしていなかったのではないか」とお叱りを頂きます。特に冗長構成を組むためには、余分に機械を購入しなければいけなかったり、専用ソフトウェアを購入しなければいけなかったりと、お金をかけているのです。それにもかかわらず、いざというときに動かない。これでは冗長構成分のお金を返しなさい、ということにもつながってしまうのです。冗長構成＝安心、というより、冗長構成にしたからこそ問題を抱え込んでしまうというのは皮肉な話だといつも思います。
この、富士通の「問題があったら全部停止する」と言うのは私の経験から言ってもすばらしい知見だと思います。「半死に」と表現していますが、本当にこの「半死に」による冗長構成の不全はよくあること、なのです。
具体的に説明します。
あなたと、あなたの同僚が二人体制で仕事をしているとします。普段は同僚が仕事をしていて、あなたは同僚が倒れたときに仕事を引き継いで仕事をします。あなたは同僚に1分おきに「大丈夫？」と声をかけます。同僚は「うん」と答えます。あなたは「うん」と言う返事を5秒以内にきいたら正常だと思うようにしました。
ある日、いつものように同僚が仕事をしていて、あなたは「大丈夫？」とききました。同僚はいつも通り、「うん」と答えます。あなたはいつも通り仕事をしてくれているなと思って待機していました。「大丈夫？」「うん」「大丈夫？」「うん」・・いつも通りの風景です。しかしもうそのとき、異常は起こっていました。同僚は「うん」という返事は返せますが、白目を向いて倒れていました。でも「大丈夫？」ときいても「うん」と返事がかえってきます。そう、問いかけに答えはできるのですが、肝心の仕事はもうしていないのです。これではあなたも、仕事の引継ぎをしようとも思いません。
この場合は、「大丈夫？」「うん」という正常性監視の条件が悪いと言えます。例えば、本当に仕事をしているか確認するようにすることも、再発防止策にはなるでしょう。しかし、今度はちゃんと仕事はするけれども、仕事の内容がおかしいかもしれません。結局冗長設計における正常性監視とは、設計時のあてが外れることで、うまくいかなくなるのです。
今回の、富士通の冗長化設計は、この点に焦点を当てて、正常性監視にて異常が発見されたら機器の電源ごとダウンさせます。これにより「あなた」は確実に、「あ、こいつ倒れたな」ということがわかり引き継ぎが確実になされます。
2018年10月に起きたシステム障害の反省を活かしたとのことで、素晴らしいなと思いました。
冗長構成にはお気を付けください。
ちなみに
冗長構成でもう一つ思い出すのは、同僚はちゃんと仕事をしているのに、あなたは同僚が倒れたと思い込んであなたも仕事をしだして、結局同僚もあなたも仕事をして、システムが混乱することです。
このとき、おかしいのは同僚ではなく、あなたが同僚にコミュニケーションが取れない状態になった可能性です。ネットワークが切り離されたとか・・、機器の異常とか・・。これも、電源を止めることで、確実にシングル構成になれるので、この点の解決策にもなりますね。
ということで冗長構成って奥が深いので、いくら試験をしたところで、試験に想定していなかった異常な状態に対してちゃんと動くのかというのは保証できません。
電源を抜いたりネットワークケーブルを抜いたり、プロセスを停止してみたりといろいろ企画するのですが、現実はその上を行くと言った始末で・・。
arrowheadのような、ミッションクリティカルなシステムを作ることができる技術者を尊敬します。