輪講資料

1. Principles of Transaction Processing
Second Edition
7章 1, 2節
筑波⼤大学
⼤大学院
ビジネス科学研究科
経営システム科学専攻
斎藤
祐⼀一郎

2. 7.1 異常発⽣生時
pp.185 188
2
Yuichiro Saito

3. 7.1 システム異常発⽣生 - 1
 ⾼高可⽤用性が求められるシステム … 24 by 7
(⽇日本だと、24-365等と⾔言います)
 可⽤用性を左右する2つの要因
 MTBF – 平均故障間隔
 MTTR – 平均回復時間
 可⽤用性の指標(稼働率) = MTBF / (MTBF+MTTR)
※これが99.9%だったら、99.999%だったら…と。
 SLA, 応答時間, スループット
を満たせば充分という
訳ではない。障害をいかに回復させるかに焦点を当
てて議論する。
3
Yuichiro Saito

4. 7.1 システム異常発⽣生 - 2
 障害の要因は、次のように分類できる。
 環境: 電⼒力力・通信・空調・⽕火災・洪⽔水などの取り巻く物理
的環境からの影響。
 システム管理: システムを運⽤用し、問題に対して予防保守
をしていくために、どのようにすべきか。
 ハードウェア: CPU, RAM, I/O, ストレージ等。
 ソストウェア: OS, 通信, DB, TPM, その他システムソフ
トウェア, およびアプリケーションソフトウェア。
 時間があったら実例を話します。
4
Yuichiro Saito

5. 7.1 物理環境 -1
 通信 – 回線の多重化で対処
 電源 – バッテリバックアップ(UPS), 発電機
 UPSにより、短時間の障害を無停⽌止で切り抜けられる。
 UPSにより、突然のシャットダウンからシステムを守り、安全な
休⽌止とその後の復帰を迅速にする。
 発電機を⽤用いれば、⻑⾧長時間の電源障害からも保護できる。なお、
発電機起動時の中継ぎとしてUPSを使⽤用する。
 おまけ: 発電機がつながっている電源で、停電時に⾃自⼒力力で中継ぎ
をしなければならない電源をB電源、そうする必要がない物をA電
源ということがあります(これらはNTT⽤用語みたいです)。
 空調 – 完全空調が前提の場合、冗⻑⾧長化が必要。
 地震 – 耐震, 犯罪 – 不正侵⼊入防⽌止, ⽴立立地 – ⾏行行き来・防衛コスト
のバランス
 ミッションクリティカルなシステム – ⾦金金融, 運送業などは、並
外れた⽔水準で適⽤用。航空会社のシステムは地下室にある(らし
い)。
5
Yuichiro Saito

6. 7.1 物理環境 - 2
 理想は、システムのレプリカを作る(Disaster
Recovery – DR)ことである。
 カリフォルニアの銀⾏行行では、サンアンドレアス断層が元
となる災害が起き、ロスかシスコのどちらかで事業継続
が出来る。
 おまけ1: ⽇日本だと、地震によるDRは30km離れていれば
ば充分なので、東京と横浜・⼩小⼭山という形にしている所
があります。ただし、電⼒力力問題は別。
 おまけ2: 業務⾃自体がDRできていないと、システムだけ
DRしても意味はありません。これがDRP。
 データレプリケーションについては、9章で詳解。
6
Yuichiro Saito

7. 7.1 システム管理
 優秀なシステム管理者であっても、システム障害をたまに起
こしてしまう。
 管理の⾃自動化。
 メンテナンスをそもそもやらなくてもよいようにする。
 予防保守が、ダウンタイム発⽣生の元となる事がある。
 保守⼿手順の簡略化も有効。
 ソフトウェアのインストールは、多くの場合失敗の元である。再
起動を要しない⼿手順は、信頼性を向上させる⼀一つの⽅方法(Windows
を使わないとか :-p)。
 多くの操作エラーは、システム再構成時に起きる。
 事前にテストシステムでテストする事で、確認する。
 元に戻せる⼿手順を作っておくこと。
 24-365である必要がない場合、停⽌止時間に作業をスケジュー
リングする。
 しかし、ダウンタイムが必要となるシステムは、ベンダーの
視点から⾒見見ると、顧客を絞ってしまう。
7
Yuichiro Saito

8. 7.1 ハードウェア
 ハード障害には、⼀一時的な物と恒久的な物がある。
 たいていは⼀一時的な物。再試⾏行行の機会があるから、
リカバリ⼿手順を作成し復帰させればよい。
 OSに起因するディスクI/Oエラー
 ネットワーク通信
 永続的な障害により、最も深刻なのがシステム全体
がダウンする事である。
 再起動で戻る場合もある。
 ダメな時は、ディスク障害の事がほとんど。
 それでもダメな時は、修理。
8
Yuichiro Saito

9. 7.1 ソフトウェア - 1
 最も深刻な物はOSのクラッシュ。
 たいていは⼀一過性だから、再起動すれば済む。再起動は
次のものも同時に再起動される。
 分散システム内の他のシステムとの通信セッションの回復
 アプリケーションプログラムの再起動
 不整合が発⽣生したディスクの修復
 こういったものは、MTTR低下をもたらす。早くできる
ようになる事がよい。
 OSベンダーは、90年代に⾼高速な回復のためにファイルシステ
ムリカバリ⼿手順を組み込んだ。
 ⼀一部のOSは⾼高速起動に慎重を期した設計をしている。
 ⾼高可⽤用性の通信システムは、最悪でも分単位で回復。
 究極的には、回復時間は0なのなら、ユーザはその事を
関知する必要は無い。
9
Yuichiro Saito

10. 7.1 ソフトウェア - 2
 ⼀一部のソフトウェアの障害は、それは問題が発⽣生し
たのではなく、性能低下を意味する事がある。
 リモートサービスへのアクセスの例。
 (雑に作れば?)通信機能は使えないが、慎重に設計してい
れば他の機能はまだ動作するかもしれない。その状態が
システムの性能低下を意味する。
 事例 - DWHのシステムがミッションクリティカルではな
かった→失敗時に、全システムがデータを利⽤用できなく
なり損失を被った。
 アプリケーションやデータベースに障害が発⽣生する
か、検出して回復できるようにしておく必要がある。
TP固有技術が関与する所である。
10
Yuichiro Saito

11. 7.2 システムリカバリのためのモデル
pp.188 194
11
Yuichiro Saito

12. 7.2 プロセス異常発⽣生を捉える - 1
 OSとアプリケーションのプロセスは分離・保護されている。
そのため、プロセス障害のみを回復すればよいので、多くの
TPシステムは多数のプロセスから成っている。
 問題が発⽣生したとき、プロセスを再作成するようにしなけれ
ばならない。それはOS, DB, またはTPMによって⾏行行われる。
 これらの多くは、プロセスが失敗した時の追跡または監視の
プロセスを持っている。これには次の3つの⼿手法がある。
 Fig7.1: 各プロセスは、監視プロセスに対し定期的に⽣生存通信を
⾏行行う(keepalive, heartbeat)。これが無いとき、可能な限り障害で
あると警告する。
 監視プロセスが、各プロセスに⽣生存確認を求めるメッセージを発
し、ポーリングする(heartbeat)。
 ロックと関連し、プロセスが失敗した時にOSの監視プロセスから
発せられるメッセージを受理し、ロックと関連したプロセスを解
放する。
 MTTRを最⼩小化する⽅方法を選択する事が重要。
12
Yuichiro Saito

13. 7.2 プロセス異常発⽣生を捉える - 2
 しかし、この検出⽅方法は実際に失敗したかの確認を
保証する物ではない。
 Keepalive の⽅方法では、単に応答が遅いだけかも。
 ロックの⽅方法では、動作可能なロックをリリースしてい
るだけかも。
 同じOS上で監視していると、誤検知しやすくなる。
が、本章ではこの件は正しいと仮定して議論する。
 監視プロセスが別のマシンで動いている分散システ
ムでは、障害現象は通信障害ではなくプロセス障害
である事が原因である事が⾼高くなる。これは8,9章
で議論する。
13
Yuichiro Saito

14. 7.2 プロセス異常発⽣生を捉える - 3
 プロセスは不正な値を返す事で失敗する事がある。
 メモリ障害
 通信障害
 アプリバグ
 今回は、このようなエラーは考慮しない。⼀一般的な
システムのメカニズムを使⽤用して、これらは排除す
る事が出来ない。ソフトウェア⼯工学に譲る。
 プロセス障害検知時、⼀一部エージェントではプロセ
ス再作成を⾏行行う必要がある。OSは基本的にそう⾔言う
事はやってくれない。
14
Yuichiro Saito

15. 7.2 クライアントのリカバリ - 1
 クラサバでは、クライアントがサーバとそれに紐づく
ネットワーク・ディスクを⽤用いてやり取りをしている
(Fig 7.2)。
 このシステムに置ける障害点
 クライアント
 通信
 サーバ
 サーバリソースの接続
 リソース
 復帰⽅方法は、たいてい再試⾏行行・再接続。復帰には次の事
項を決定する必要がある。
 失敗時、未処理だった呼び出しは何か？
 通信できなかった事によって起こる事は何か？
 新規呼び出しを⾏行行う前に、事前に何をすれば適切な状態に持っ
て⾏行行けるのか？
15
Yuichiro Saito

16. 7.2 クライアントのリカバリ - 2
 この話題は、4章で説明した「キュートランザク
ションの処理」に通づる。
 サーバ・クライアントに永続的キューがある場合、どこ
まで処理したかをシリアル番号ベースで照らし合わせ、
処理できなかった所から再開する。
 残りの問題は、次節に。
16
Yuichiro Saito

17. 7.2 サーバのリカバリ
 サーバが再作成された後、新しいコールを始める前にリ
カバリ処理を⾏行行う。初回起動なら初期化処理のみだが、
そうでない場合はどうするか。
 サーバは直列処理である…トランザクションは無い。単に要求
を受信し、結果を返す。これが失敗した時に、それはサーバの
呼び出しの途中だったとも考えられる。
 その状況を判断できるのはクライアント次第である。
 残念な事に、サーバが冪等とならない処理をしている場合があ
るため、常にうまく⾏行行くとは限らない。従って、⾮非冪等となる
処理は実⾏行行しないようにしなくてはならない。
 部分的に実⾏行行される、呼び出しの回復処理は複雑であり、
⼀一般的にトランザクションをサポートされるシステムで
は⽤用いられない。
 トランザクションが利⽤用可能である場合はとても簡単に
できるのだが、そうでない場合はどういった場合がある
か、調べてみましょう。
17
Yuichiro Saito

18. 7.2 チェックポイントを⽤用いたリカバリ
 サーバがクライアントからの呼び出しを実⾏行行し、失敗し
たと仮定。
 多重呼び出し時に冪等性が担保される操作を実⾏行行出来る
とすると、復旧時は単に最初のメッセージから全て再実
⾏行行すればよい。
 冪等性が担保されない場合、⾮非冪等となる操作まで処理
を回復させなければならない。
 こう⾔言った処理を実⾏行行する前に、状態を不揮発性記憶装置に保
存する。そうすれば、回復時に状態を再作成できる(Fig 7.3)。
これがチェックポイント。
 しかし、毎度毎度やると処理コストは安くない。それを容易に
するのがトランザクション。
 サーバ回復時、最後に成功した処理までチェックポイントを復
元(Fig 7.4)。すなわち、⾮非冪等操作が実⾏行行されているかどうか
を確認する必要がある。
18
Yuichiro Saito

19. 7.2 トランザクションベースサーバのリカバリ
 トランザクションは、サーバの復旧を簡素化する。
 トランザクションをサポートするサーバに障害が発⽣生し、
その後に回復した場合、その内容には障害発⽣生時に稼働
していた全てのトランザクションの効果(内容)が含まれ
ている。
 ⾮非トランザクションサーバ…チェックポイントとの⽐比較。
 チェックポイントを常にコミットしているような感じ。
 リカバリ⼿手順は未完のトランザクションを破棄している。
 すなわち、回復時は失敗として扱われ、回復出来ないとダメ。
 これなら、⾮非冪等である場合でも、やり直しても問題は
出ない。チェックポイントベースのリカバリ⽅方法の問題
はこれで解決可能。
19
Yuichiro Saito

20. 7.2 トランザクションベースサーバのリカバリ
 しかし、どうしても冪等性を担保できない物がある。
 ⼩小切⼿手の印刷
 お⾦金金の送⾦金金
 まあ、物理的な作業を伴うものはほとんどでしょう。
 こう⾔言った物はキューイングで処理する。4.4節の技を
うまく使ってやること。
 トランザクションのみでは復旧は簡素化しないが迅速に
はする。メモリチェックポイントは⾼高価だが、トランザ
クションは安価である。
 このトリックはメモリにバルクコピーを避けてログファイルに
蓄積している事である。
 障害時、ログを使⽤用してディスクからメモリの状態を再構築す
る。
 All or Nothing という形にはしない。⼀一時的な障害にも耐えう
る構造である。
20
Yuichiro Saito

21. 7.2 ステートレスなサーバ - 1
 トランザクションを使⽤用している場合、2タイプにサーバ
は分かれる(Fig 7.5)。
 要求を受け取る→トランザクション開始→アプリケーションプ
ロセスが処理実⾏行行→トランザクションリソースマネージャに
メッセージ送信
 直接DBは叩かない。回復可能なキュー等で共有されている。
 リソースマネージャは先節で解説したトランザクションサーバ
と同じ動きをする。
 アプリケーションプロセスはステートレスであり、復帰時には
「状態」を持っていない。従って、復帰後は「さら」から実⾏行行
する形でかまわない。復帰のためのプログラムを書く必要も無
い。
 トランザクションリソースマネージャが、状態を持つ。
 しかし、最後に実⾏行行した状態をどのように扱うかは曖昧
なままである。
 そこでキューの出番。キューとして処理すれば、解決する。
21
Yuichiro Saito

22. おわり
22
Yuichiro Saito