メインフレーム、無停止サーバ、クラウドにおける信頼性
「メインフレームの異常処理」という記事が話題になってましたがとても面白かったです。 qiita.com
せっかくなので自分が知ってる範囲で各システムの信頼性における考え方を書いてみました。特にシステムが死んでも仕掛かり中のプロセスが正常完了する事を「無停止システム」としてフォーカスしています。 詳しいわけじゃないからあまり詳しくは話せないので、指摘とか頂けると嬉しいです
- メインフレーム
- HPE NonStopサーバ
- Stratus FT Server
- オープン系: クラスタ
- オープン系: 負荷分散(シェアードナッシング)
- クラウド/仮想環境: Live Migration
- ソフトウェア: Jakarata EE/EJB
- ソフトウェア: Oracle RAC
- ソフトウェア: Erlang/OTP
- ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン
- まとめ
- 参考リンク
メインフレーム
- ホスト機/汎用機とも。国内の富士通とか日立はIBMアーキテクチャをベースにしている。独自進化部分もあるけど。NECとかユニシスはまた別アーキテクチャ。
- 金融や行政系を中心に現在もたくさん利用されている
- Fail Softに基づいたハードレベルの冗長化や障害時の切り離し
- 単独マシンで信頼性を実現。ハードウェアレベルのクラスタ機能もあるのでさらに複数マシンを使ってさらに信頼性を上げることも可能
- ハードウェアのエラー時の処理をハンドリングする仕組みを用意している
- 逆に言えばアプリケーションエンジニアがハードウェア障害を意識する必要がある
- z Systemなんかは現代でも最高スペックのマシン。DockerとかLinuxを動かすことも実はできる
- 単独メーカで全てを製造しているのでシステム全体で一貫したセキュリティモデル/信頼性モデルが構築できるのは魅力
HPE NonStopサーバ
- Tandem)とも。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
- Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え
- 複数マシンを束ねてシステムの信頼性を実現。(少なくとも現代では)ソフトウェアが中心の信頼性
- プロセスペアという仕組みを使いメインのプロセスをサブプロセスで監視し問題があれば別サーバで動かす
- CPUは非同期なので性能は出しやすい
- OSは独自。旧来からのGuardian環境だけではなく、POSIX風のOSS(Open System Services)も使えてJavaとかKVSも動く
- Java言語ライブラリやJavaEEなどの内部実装をプロセスペアを発展させたTMF やTS/MPで書き換えてより高速/高信頼な実装を実現している
- 文化的にはOSからパッケージ、アプリケーションまでプロセスペアやTS/MPを活用して無停止性をキープする事を強く意識している
- 専用ハードウェアを必要としていたが、現在はソフトウェアベースになっておりx86はもちろんVMware上でも同等の信頼性で動作する
Stratus FT Server
- Strutsじゃないよ。ストラタス。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
- NEC ftServerもあるけど違いは良く知らない
- Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え。
- 複数マシンを束ねてシステムの信頼性を実現。ハードウェアが中心の信頼性
- ロックステップ処理と呼ばれるCPUレベルで同期しながら処理を実行するので片方が死んでも処理を継続できる
- もちろんHWの交換はシステムを止めずに実施が可能。
- OSはVOS(Virtual Operation System)。Windows/Red Hat Enterprise Linuxなどをサポートしている。VOSとかだとPL/1とかCOBOLで開発
- 専用ハードウェアだが、汎用OSも動くのは魅力的なポイント
オープン系: クラスタ
- ここではOSレベルのクラスタシステム. 今でもx86系で冗長構成を組む一般的な方法の一つ
- Fail Overを基本としたマシンレベルの冗長化や障害時の切り替え
- 複数マシンを束ねてシステムの信頼性を実現
- アクティブ/スタンバイを基本として障害時にシステムを待機系に切り替える。ただしFTサーバとは違い分オーダーの時間がかかり実行中の処理もエラーになる
- OSはUnix/Linux/Windowsなどなど。
- システム構成もシンプルで費用も安いが原理的に無停止稼働ができない
オープン系: 負荷分散(シェアードナッシング)
- ここではロードバランサに繋がった負荷分散のシステム。Webサーバを中心に一般的
- システム全体でFault Tolerant/Fail Softを目指すマシン単位の冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- アクティブ/アクティブ構成なのでサーバ障害時には対象システムを切り離すだけで良いので運用が非常に楽
- WebやAPサーバなどステートレスなサーバでは無停止が実現できるが、DBなどステートフルなシステムには冗長性の観点では単純適用できない
クラウド/仮想環境: Live Migration
- クラウドインフラやVMwareで実施されるHypberviosrレベルの信頼性確保技術。クラウドを支える技術として裏で使われてる
- Hypberviosrを抽象化しているのでハードウェアレベルの個々の故障を見えなくするマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- 例えばGCPの場合は稼働中にゲストOSのメモリコピーを行いVMの停止を極小にすることでアプリレイヤーからは遅延に見える程度の無停止性を実現している
- 信頼性の責務をOSより下のHWとOSより上のアプリケーションで明確に分離できるのが特徴
ソフトウェア: Jakarata EE/EJB
- OSではなくミドルウェアレベルの信頼性。
- 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- 基本的にはEJBでの信頼性確保技術としてはフェイルオーバーとリトライがある
- フェイルオーバーはエラー時に透過的に別のサーバで実行される。ただしDBなどトランザクションは対応していない
- トランザクション処理はロールバックされるのでリトライを実行することでシステム全体としての無停止性を確保できる
- ただし、実際のアプリ実装ではシステム側でのリトライは運用課題も多いので素直にユーザにエラーを返すケースも多い。システム間接続だと場合による。
- EJBに代わり現在主流のCDIには同等機能はないがMicroProfileのFault Toleranceでエラー時の処理を記述するフレームワークが追加される
- Weblogicなどはデプロイや障害時のフェイルオーバを含めてミドルウェアレベルの無停止を標榜しているが、最近はJavaEEで頑張らずシステム全体の無停止の枠組みにパーツとして組み込むことが主流
ソフトウェア: Oracle RAC
- OSではなくミドルウェアレベルの信頼性。OracleのRAC(Real Application Cluster)を使った信頼性機能。
- DBシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- RACはシェアードエヴリシングなので障害時にマシンを切り離しても透過的に利用できる
- 特にTransparent Application FailoverはSQL実行中のサーバにて障害が発生した場合、SQL文を他のサーバへフェイルオーバー(リカバリ)を実施
- Oracle DBの専用機能なので適用範囲が限定されるがDBとしての無停止を実現している
ソフトウェア: Erlang/OTP
- OSではなく言語レベルの信頼性。類似の仕組みをAkkaなどはミドルウェア/ライブラリレベルで実現している
- 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
let it crash
と呼ばれる思想に代表される適切に落として素早く復旧させる信頼性確保の方法- Supervisorがプロセスを監視し、問題があったら自動でフェイイルオーバーやリカバリを行う
- 個人的にはNonStopのプロセスペアと少し思想が近い気がする
- 分散システム全体として無停止を担保するが利用できる言語には少し制約がある
ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン
- アーキテクチャーなんだけど具体的な名前を思いつかないのでフワッとした表題に。名前はまだない?
- クラウドでは無停止システムってどう考えて作るっけ? と思って良く使われそうな考え方を書いておく
- OSや各アプリケーションではなく分散システム上のサービス単位でFail Soft/Fault Tolerantを実現
- 複数マシンを束ねてシステムの信頼性を実現だが、マシン単位はもはやあまり気にしてない
- 基本的には止まることを前提に回復性に極振りしたデザイン
- MSAにより各サービスの障害時の影響範囲の局所化とリカバリ速度の向上と、可能な限りシェアードナッシングによるアクティブ・アクティブの冗長構成が基本
- 可能な限り非同期/結果生合成を受け入れて、とりあえず信頼性の高いキューに一時保存。失敗したらロールバックとリトライをすることで無停止性を担保
- データはインフラとしては事実上無限のリソースがある事を前提に複数のストレージに同時に書き込むと言うのが基本
- OSとかのレベルの無停止性を実質期待してないのが最大の特徴。体系化/フレームワーク化はもう少し蓄積が必要な印象
- Kafkaだったりk8sだったりIstioだったりなんとかDBだったり実装は決定版がある分けでもまだない
- まだ過渡期だけど思想的にはサービスメッシュなどを活用してアプリケーションからはいくつかの制約を満たせば透過的に無停止性が担保されるはず
まとめ
他にもたくさんある気はするのですが、メインフレーム/無停止サーバ/オープン系/クラウドにおける信頼性確保の基本的な戦略を書いてみました。
意図的にハードウェアレベル、OSレベル、システムレベル、ソフトウェアレベルをまとめて書きましたが実際はこれを混在させてシステム全体の信頼性を組み上げます。銀の弾丸はないと思うのでそれぞれを把握して適切なものを選ぶのが大事ですね。
特にNonStopやftServerといった高可用性サーバは存在自体がマイナーですが、アーキテクチャ的には結構面白いので誰かの詳細な解説があると教えて欲しいです。
クラウドでももちろん無停止サービスは実現できますが、高可用性サーバを使うと商用パッケージからOSライブラリに至るまで全て無停止を意識しているので無停止サービスの実現が容易というのも魅力ではありますね。 これはNode.jsは実行基盤だけではなくライブラリなども非同期を強く意識しているので非同期プログラミングがしやすい、という話に似ています。
この辺はクラウドでのノウハウやパッケージが揃ってくれば変わってくると思いますが、現状はクラウドでは「アーキテクトが自分たちのシステムに最適な仕組みを個別に考えて実装」というラインです。もちろんk8sをはじめ良いミドルウェアやCloud環境自体の機能も強化されてきてますけど「レールに乗って作れば無停止になる」というところにはまだ至れてません。今後のノウハウ蓄積が大事ですね。
あと、最後に書いてる「Cloudの無停止でありそうなデザイン」は具体的な名前があれば誰か教えてください。MSAは大部分はカバーするにしても無停止システムデザインという意味では要素にすぎない気がするし。
それではHappy Hacking!