cat-a-log

ログのつらなり

Tandem や Stratus の目指した世界は今に引き継がれてるのか?

(ベンダーの公式サイト以外での) 日本語によるメインフレーム技術情報は非常に貴重なので、以下の記事は大変興味深く読ませていただいた。
qiita.com

で、この記事に付いたコメントで気になる問題提議があったので、連休のヒマに任せて参戦してみる。
Masanori Kusunoki / 楠 正憲 on Twitter: "汎用機の信頼性が今以てスゴい仕組みであることは間違いない。「他のノードから回復処理を行うべき」という後続はTandem/HimalayaとかStratusあたりと推察するんだけど、あの手の技術って今に引き継がれてるんだろうか? / “メインフレームの異常処理 - Qiita” https://t.co/VQtR6lTVuH"

メインフレームの強味は、元記事にあるようなノウハウがしっかりと技術者間で継承されているところにあると思う。それは、書籍『進化する銀行システム』を読んだ後にも強く抱いた感想でもある。とはいえ、出口ルーチンによるハンドリングは (元記事にもあるとおり) どちらかというと証跡の保全とリソースの開放に力点が置かれていて、処理が継続できるかどうかは実装者の力量によるところもあるし、そもそも構成的に処理系が多重化されている保証もないため、H/W レベルの故障 (形ある物はいつか壊れるというリスク) に対して弱含みのところがある。一方、Tandem (hp NonStop Server)Stratus の ftServer が提供している信頼性は全然異なる。

まず、Stratus も Tandem も H/W レベルで全てが必ず二重化されているのがメインフレームと最も違うところ。Stratus はロックステップといって同じ処理を複数のプロセッサが実施して、故障したらダメなプロセッサを切り離して処理を継続する。クロックレベルで同期しているので性能がイマイチ上がらないのが欠点。ただし WindowsRHEL など汎用 OS がそのまま使えて、開発者が何か特別な配慮をしなくても恩恵にあずかれるのは美点。
フォールト・トレラント・アーキテクチャ | Stratus

Tandem も構成要素は全て二重化されているのだが、それぞれは疎結合になっており、メッセージベースで同期している(いわゆるシェアードナッシング)。独自の OS (Guardian) に checkpoint という API があり、プロセスペアと呼ばれる2つのプロセスが任意のタイミングで同期しながら障害の発生に備えている。Primary の H/W で故障が起こると、別の H/W で稼働している Backup が前回の checkpoint から処理を引き継ぐ(やり直す)。クロックレベルで同期していない分、性能が稼げるのだが、あくまでも API なので開発者が上手くコーディングする必要がある。
HPE Integrity NonStop Xの主な特長
ちなみに Tandem の処理の仕組みについては、オライリーの『ビューティフルアーキテクチャ』の8章で詳しく述べられている。書籍の記載は随分と昔のものだが、Guardian は基本的に後方互換性が保たれているので、今でも考え方は一緒だと思う。

元ツイートの『あの手の技術って今に引き継がれてるんだろうか?』は、個人的には No だと思う。もちろん hp NonStop Server や Stratus ftServer は全然現役で、大事なところでは使われ続けている技術ではあるけれども、オープン系や Web の世界において http のようなステートレスなプロトコルが中心になった昨今では、Tandem や Stratus が目指した『仕掛り中の処理をも救う』ポリシーは少々重たく、一般的に普及したとは言いがたい。
これに代わって、クラスタリングやロードバランサによる複数のマシンでの可用性維持、つまり『仕掛り中のトランザクションはエラーになってしまうけど、リトライしている間に系切り替えをして救えれば OK』という世界がデファクトになったと言えるだろう。クラウドの世界における『design for failure』の思想や、MicroProfile の仕様である Fault Tolerance もこの流れに従っている。実は NonStop も、Pathway(=TS/MP) という TP モニタが出来てからは面倒な NonStop コーディングは流行せず、少なくともアプリケーションレベルではこちらの考え方にかなり寄せられているのが実情だと認識している (その代わり、ミドルウェアである Pathway 自体は NonStop コーディングがなされているので、仕掛中のトランザクションはエラーになってしまうものの、系切り替え自体は瞬時に完結する。クラスタリングやロードバランサによる系切り替えは、ポーリングやヘルスチェック用トランザクションのリトライオーバが基本なので、それと比べるとどうしても時間がかかる)。

そこへいくと、OracleTransparent Application Continuity 機能は結構イイなと思う。DBレイヤだけだけれども、RACの1ノードが落ちてもアプリで特別に意識せず、処理を継続させることができる。これは久しぶりに "Tandem や Stratus が目指した世界" に近い、『仕掛り中の処理を救う』機能だ。しかも "Transparent" と銘打たれているように、基本的にはノンコーディングで恩恵にあずかることができるため、これはもっと流行ってもいいと思う。
builder.japan.zdnet.com

なおこの議論については、同じように触発されて書かれた記事があがっており、こちらも大変興味深い。
koduki.hatenablog.com