 |
≫ |
|
|
 |
 |
 |
星村商事は、1年前に合併したばかり。合併後のシステムは、なんとかうまくいっていたように見えていましたが、残念なことに先月、トラブルが発生してしまいました。部長に対策案を出すよう命じられた若手エンジニア山本くんは、なんだか浮かない顔をしています。主任の水野さんが見かねて声をかけました。
|
|
 |
2010年9月
西村 めぐみ
ページ: 1 2 | 次へ ≫ |
 |
 |
 |
 |
 |
 |
山本くん:
ダメ出しされちゃいました。キミはもう少し勉強したほうがよさそうだねってしぶーい顔で。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
先月のエラーの件だよね。山本くんは何を提案したの? |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
2フェーズコミットです。先月の騒ぎは、在庫管理のDBには記録されていたのに、請求処理側のサーバーには反映されていなかったから起きたトラブルなんです。このような複数サーバーにまたがる処理には、2フェーズコミットが有効だって部長にそう提案したんですけど……。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
なるほどねぇ。で、「山本くん、本当にそれ大丈夫なのかね」って言われた? |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
はい。まさしくそんな口調で言われました。部長って心配性ですよね。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
だからこないだHP NonStopサーバーを薦めたのに。そっちは勉強しなかったの? |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
HP NonStopサーバーって、その名の通りの止まらないサーバーってやつですよね? 正直よくわからなかったし、それよりも、今のシステムに手を加えてなんとかしたいと思ったんです。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
うーん。HP NonStopサーバーは、止まらないってだけじゃなくて、トランザクション処理においても定評があるんだけどなぁ。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
水野さん:
NonStop TMFって言うトランザクションマネージャがとにかく強力なんだ。NonStop TMFがシステム全体をしっかり見張っているから、システム全体でデータの整合性が守られている。なぜならそれはOSレベルから設計されたものだからなんだ。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
最初から考えて作られたOS、という話でしたね。それってそんなにすごいことなのかな。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
NonStop TMFの優位性を説明する前に、2フェーズコミットについて確認しておこう。「すべてのサーバーにコミットできるかどうか問い合わせて、全部からOKが帰ってきたらコミット要求を出す」というのが2フェーズコミットだよね。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
はい。まず、トランザクションを完了させたいときは、まず、各サーバーにコミットしてよいかというメッセージが送られます。これがコミット要求相(commit-request
phase)で、各サーバーがUndo/Redoログをとりながらコミットを行える状態まで処理を進めます。そして全サーバーからの返事がそろったら、次に、全サーバーにコミットせよ、あるいはロールバックせよ、という命令が出ます。これがコミット相(commit
phase)で、晴れてトランザクションが完了します。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
2つの相でコミットを行うから2フェーズコミット、だね。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
そうです。要求や応答といったやりとりは、X/Openが策定した「X/Open XA」という標準規格で行います。うちで使っているサーバーならどれもXAが使えるので、その辺は問題ないですよ。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
導入はできそうだ、と。でもね、山本くんはそもそも2フェーズコミットのデメリットってわかってる? |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
2フェーズコミットのデメリットですか? |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
例えばロックについて考えてみようよ。データベースサーバーは、1フェーズ目で準備OKを返してから、2フェーズ目のコミット命令を受け取るまでの間は、コミットすべきかロールバックすべきか判断できない。したがって、準備OKを返してからコミット命令を受け取るまでの間、データベースはロックされてしまう。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
水野さん:
データベースサーバーAとデータベースサーバーBがあったとする。A・B両方から応答がない限り、コミットもロールバックもできないよね。AがOKを返したのに、Bにトラブルが発生してフェイルオーバーしていたらどうなる?
フェイルオーバーで、きちんと応答できるようになるまでには数分かかる可能性があるよ。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
僕たちが構築しているのはEDIシステムですから、そんなに待っていられません。10秒以内に応答がなかったらどうするかを決めておく必要がありますね。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
それが「ヒューリスティック(heuristic)」というやつだ。2フェーズコミットにおけるトランザクションの結果は、COMMITとROLLBACKの他に、HEURISTICがあるんだよ。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
水野さん:
ヒューリスティックな処理というのは、要するに、確実な結果が出る前に判断してしまう、ということだ。つまり、どんなに精度を上げたところで整合性は保証されない。ミッションクリティカルな業務では使えないよね。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
クリティカルな業務では、結局のところ、アプリケーションレベルでログをとって……えー、じゃぁ今のシステムとあまり変わらないじゃないですか。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
2フェーズコミットの問題点はこれだけじゃないよ。でも、これ1つで充分に致命的だ。いくらXAで連絡を取り合っていると言っても、結局は各自バラバラのまま、トランザクション処理を「せーの」で合わせて実行しているにすぎないんだから。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
水野さん:
これはあくまでも僕個人の考えだけどね、それがオープン系OSの限界なんじゃないかな。結局のところは各サーバーにおまかせ、じゃデータの整合性は保てない。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
 |
 |
 |
山本くん:
やっぱりデータベースを統合するしかないのかなぁ。……でもそう簡単にはいかないですよ。合併だってまたあるかもしれないし、過去、データの統合でどえらい騒ぎが何度も起こっているじゃないですか。 |
 |
 |
 |
 |
|
 |
 |
 |
 |
水野さん:
そこでHP NonStopサーバーなんだ。 |
 |
 |
 |
 |
|
 |
 |
 |
1 | 2 |
|
| 本ページの内容は執筆時の情報に基づいており、異なる場合があります。 |

ご相談窓口
 |
 |
エンタープライズ向け製品の
ご購入前のご相談
03-5749-8328
09:00-19:00 (月曜−金曜)
10:00-17:00 (土曜)
※祝祭日と5月1日は除く |
|
|
|
|
※機器のお見積については、代理店、または弊社営業にご相談下さい。
ご購入後のお問い合わせ
オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。
ショールーム
|