平成26年秋期試験午後問題 問6
問6 データベース
⇱問題PDF
分散トランザクションに関する次の記述を読んで，設問1～4に答えよ。
分散トランザクションに関する次の記述を読んで，設問1～4に答えよ。
広告
L社は事務用品を扱う商社であり，顧客からの注文に基づき，商品を発送している。販売管理システム，在庫管理システムの二つのシステムを使って受注処理，在庫管理，発送処理を行っている。二つのシステム間で受注データと在庫データの整合性をとるために，昼間に登録した受注データを基に夜間バッチ処理で在庫データの管理を行っている。しかし，在庫の引当てがリアルタイムでないので，在庫量の適正化ができないという問題がある。そこで，リアルタイムに在庫管理を行うことができる統合販売管理システム(以下，本システムという)を構築することになった。
〔本システムの概要〕
本システムは，現在の販売管理システムと在庫管理システムで，それぞれ異なるDBMSを使って運用している受注データベースと在庫データベースをそのまま活用し，受注処理，在庫引当てをリアルタイムで行う受注処理及び在庫管理の機能を提供する。本システムのシステム構成を図1に示す。
〔受注処理の概要〕
L社の情報システム部のM君が本システムによる受注処理について検討を行い図2に示す本システムにおける受注処理のシーケンス図を作成した。
M君の上司のN主任が，図2のシーケンス図をレビューし，ACID特性の観点から次の二つの指摘をした。
〔2相コミット〕
M君はN主任の指摘1に対応するために，2相コミットの考え方を利用し，二つのデータベースの内容を更新するトランザクション内で矛盾が発生しないよう整合性の確保を行った。
本システムは，販売管理サブシステム及び在庫管理サブシステムに対して，更新準備，コミット，ロールバックの3種類の2相コミットインタフェースを使ってデータベースの更新を行う。2相コミットインタフェースの処理概要を表1に示す。
図3は，図2の⑤以降の処理で，2相コミットインタフェースを使った場合のシーケンス図である。
M君はN主任に図3のシーケンス図について再レビューを受けたところ，次の助言をもらった。
前回の指摘1について2相コミットを適用しても完全に解決することはできない。例えば，本システムは，コミット要求又はロールバック要求に対して在庫管理サブシステムと販売管理サブシステムの両方からOK回答を受け取らなかった場合には，①自動的に回復できない状態が発生しているおそれがある。そのときは，アラームを発してその対処をオペレータに促すよう，運用上の対処が必要となる。
さらに，N主任からの助言を基に，M君は，トランザクションの整合性を確認するために，受注処理の流れについて机上検証を行った。その結果，②図3の※1の時点で，本システムに障害が発生した場合に，トランザクション上の問題が起きることを発見した。
〔本システムの概要〕
本システムは，現在の販売管理システムと在庫管理システムで，それぞれ異なるDBMSを使って運用している受注データベースと在庫データベースをそのまま活用し，受注処理，在庫引当てをリアルタイムで行う受注処理及び在庫管理の機能を提供する。本システムのシステム構成を図1に示す。
- 営業担当者は，顧客から受けた注文を基に，受注予定の商品の引当可能在庫数を本システムに問い合わせる。
- 本システムは，受注予定の商品の引当可能在庫数を在庫管理サブシステムに問い合わせ，営業担当者に回答する。
- 営業担当者は，注文数が引当可能在庫数以下であることを確認し，受注登録を本システムに依頼する。
- 本システムは，在庫管理サブシステムの在庫引当処理を実行し，対象商品の引当可能在庫数から注文数を減算する。
- 本システムは，販売管理サブシステムの受注登録処理を実行し，受注データを登録する。
L社の情報システム部のM君が本システムによる受注処理について検討を行い図2に示す本システムにおける受注処理のシーケンス図を作成した。
- 指摘1：
- 図2の⑧が失敗した場合，受注データとひも付かない在庫引当処理が行われたことになる。この場合，トランザクションのaが保証されない。
- 指摘2：
- 営業担当者が受注処理を行っている途中で，別の営業担当者が在庫データを照会すると，在庫引当処理が行われる前の時点の引当可能在庫数が参照されることがある。この場合，トランザクションのbが保証されない。
〔2相コミット〕
M君はN主任の指摘1に対応するために，2相コミットの考え方を利用し，二つのデータベースの内容を更新するトランザクション内で矛盾が発生しないよう整合性の確保を行った。
本システムは，販売管理サブシステム及び在庫管理サブシステムに対して，更新準備，コミット，ロールバックの3種類の2相コミットインタフェースを使ってデータベースの更新を行う。2相コミットインタフェースの処理概要を表1に示す。
前回の指摘1について2相コミットを適用しても完全に解決することはできない。例えば，本システムは，コミット要求又はロールバック要求に対して在庫管理サブシステムと販売管理サブシステムの両方からOK回答を受け取らなかった場合には，①自動的に回復できない状態が発生しているおそれがある。そのときは，アラームを発してその対処をオペレータに促すよう，運用上の対処が必要となる。
さらに，N主任からの助言を基に，M君は，トランザクションの整合性を確認するために，受注処理の流れについて机上検証を行った。その結果，②図3の※1の時点で，本システムに障害が発生した場合に，トランザクション上の問題が起きることを発見した。
広告
設問1
本文中のa，bに入れる最も適切な字句を解答群の中から選び，記号で答えよ。
a，b に関する解答群
- 隔離性
- 可用性
- 原子性
- 信頼性
- 耐久性
- 保守性
解答例・解答の要点
a：ウ
b：ア
b：ア
解説
2つの指摘はACID特性の観点から行われているので、まずはACID特性について簡単に確認します。ACID特性は、トランザクション処理を行う上で必要不可欠とされる4つの性質(Atomicity・Consistency・Isolation・Durability)をまとめたものです。
- Atomicity：原子性
- トランザクション内の処理がすべて実行されるか、または全く実行されないことを保証する性質。
- Consistency：一貫性
- トランザクションによりデータの矛盾が生じないこと。常にデータベースの整合性が保たれていることを保証する性質。
- Isolation：独立性
- 複数のトランザクションを同時に実行した場合と、順番に実行した場合の結果が等しくなることを保証する性質。一般にロックなどをかけることで直列可能性を保証する。隔離性と呼ばれる場合もある。
- Durability：永続性
- 一旦正常終了したトランザクションの結果は、以後システムに障害が発生しても失われないことを保証する性質。耐久性と呼ばれる場合もある。
選択肢のうちACID特性に該当するのは「隔離性」「原子性」「耐久性」なので、この3つから適切なものを選択することになります。
〔aについて〕
本システムでは、在庫管理サブシステムの在庫データ更新と、販売管理サブシステムの受注データ登録という一連の受注処理を行います。金融機関の口座振り込みにおける出金処理と入金処理のように、この2つの処理は一体不可分の処理ですのでトランザクションとして扱う必要があります。
図2中の⑧で受注登録が失敗すると、在庫引当処理により在庫データは更新されたのに、それに対応する受注データが存在しないことになります。トランザクションはすべての処理が正常に行われるか、全く処理されない状態のいずれかで終了しなければなりません（原子性）。在庫引当だけが行われ、受注登録が行われないとトランザクションの「原子性」を損なうことになります。
∴a＝ウ：原子性
〔bについて〕
指摘2はトランザクションが並列実行された際の弊害について説明しています。1つ1つのトランザクションを順番に実行していけば正しい在庫数が返されますが、並列実行することによりそうではなくなってしまうのでトランザクションの「隔離性」が損なわれることになります。
なお、本システムから返された引当可能在庫数がその後に別のトランザクションで減算されたとしても、在庫引当処理時の在庫データが注文数以上であれば在庫引当＆受注登録は支障なく行えます。逆に、注文数未満であれば在庫引当処理に失敗してトランザクションが終了する（図2中の⑪）ことになるので、指摘2への対処は不要と判断していると考えられます。
∴b＝ア：隔離性
広告
設問2
図3中のc～gに入れる適切な字句を答えよ。
解答例・解答の要点
c：在庫データ
d：更新準備
e：受注データ
f：コミット
g：ロールバック
d：更新準備
e：受注データ
f：コミット
g：ロールバック
解説
まず「2相コミット」の基本を確認しておきます（午前問題でも頻出です）。2相コミットは、分散データベース環境でのトランザクションの原子性・一貫性を保証する手法で、トランザクションを他のサイトに更新可能かどうかを確認する第1相と、更新を確定する第2相の2つのフェーズに分け、各サイトのトランザクションをコミットもロールバックも可能な中間状態(セキュア状態)にした後、全サイトがコミットできる場合だけトランザクションをコミットします。
具体的には、コミットの調整を行う1つのノードを「調停者（主サイト）」、ネットワーク上の他のノードを「参加者（従サイト）」として、次の手順でコミットが行われます。
[第1相（投票層）]
- 調停者となったノードはネットワーク上の他のノードにコミットの可否を問い合わせる。
- 全参加者は調停者にコミットの可否を応答する。
- 全参加者からコミットの合意を得られた場合は、全参加者にコミットの実行要求を発行する。コミットの停止を応答した参加者がいた場合、またはタイムアウトとなった場合は、全参加者にロールバックの実行要求を発行する。
- 各参加者は、コミット(またはロールバック)の完了とともに調停者に処理完了のメッセージを送る。
- 調停者が、全参加者からの処理完了メッセージを受け取り、トランザクションの完了となる。
〔c、eについて〕
表1「2相コミットインタフェースの処理概要」を見ると各要求は更新データに対して行われます。
[c]は在庫管理サブシステムで更新されるデータです。問題文中に「本システムは，在庫管理サブシステムの在庫引当処理を実行し，対象商品の引当可能在庫数から注文数を減算する。」とあるので「在庫データ」が入ります。
[e]は販売管理サブシステムに登録されるデータです。問題文中に「本システムは，販売管理サブシステムの受注登録処理を実行し，受注データを登録する。」とあるので「受注データ」が入ります。
∴c＝在庫データ
e＝受注データ
〔dについて〕
2相コミットの手順では、全サイトにコミットまたはロールバック要求をする前に、各サイトにコミットの可否を問い合わせます。表1を見ると「更新準備」要求がこの問合せに該当することがわかります。
∴d＝更新準備
〔fについて〕
[alt]の上部は、更新準備要求に対して両サブシステムから"OK"が回答されたときの流れになります。両サブシステムが更新可能状態にあることが確認できたので、「コミット」要求を送信し、トランザクションを確定させることになります。
∴f＝コミット
〔gについて〕
[alt]の下部は、更新準備要求に対して両サブシステムから"OK"が回答されなかったときの流れになります。少なくとも一方から"NG"が回答された、あるいは回答がなかった場合はこちらに遷移します。トランザクションの原子性を保証するには、1つでもコミットできないサイトがあるときには全サイトに「ロールバック」要求を送信することになります。
∴g＝ロールバック
広告
設問3
本文中の下線①について，どのような状態が発生した場合に，自動的に回復できないデータの不整合が発生するのか。解答群の中から全て選び，記号で答えよ。
解答群
- 在庫データの更新が失敗し，受注データの登録が成功した状態
- 在庫データの更新が失敗し，受注データの登録も失敗した状態
- 在庫データの更新が成功し，受注データの登録が失敗した状態
- 在庫データの更新が成功し，受注データの登録も成功した状態
解答例・解答の要点
ア，ウ
解説
コミットまたはロールバック要求に対して、サブシステムから"OK"の回答を得られなかった場合には、そのサブシステムで処理が失敗した、システム障害が発生した、通信障害が発生したなどが原因として考えられます。このとき、片方のサブシステムだけが正常に処理され、もう一方のサブシステムでは正常に処理されなかった場合には、受注データに紐付かない在庫引当処理が行われたり、在庫引当に紐付かない受注データが登録されたりといったデータの不整合が生じます。つまりデータの不整合が発生するのは、一方が成功し、他方が失敗している「ア」と「ウ」です。
なお、「イ」のケースではどちらも失敗しているのでデータの不整合はなくトランザクションのリトライにより回復可能、「エ」のケースではどちらも成功しているのでデータの不整合は生じません。
∴ア，ウ
広告
設問4
本文中の下線②の問題について，(1)，(2)に答えよ。
- この状態で在庫データと受注データにどのような問題が発生するか。15字以内で述べよ。
- この問題の対応方法のうち最も適切なものを解答群の中から選び，記号で答えよ。
解答群
- 在庫管理サブシステムが販売管理サブシステムにコミット要求を出す。
- 在庫管理サブシステムが販売管理サブシステムにロールバック要求を出す。
- 販売管理サブシステムと在庫管理サブシステムがタイムアウトを検出してロールバックする。
- 販売管理サブシステムと在庫管理サブシステムが本システムからのロールバック要求又はコミット要求を待つ。
解答例・解答の要点
- ロックされたままとなる (11文字)
- ウ
解説
- 図3中の※1は、統合販売管理システムから各サブシステムに更新準備要求が送信され、統合販売管理システムが各サブシステムからの回答を受信した時点です。
表1を見ると「更新準備要求を受け取ると，更新が可能な場合には，…当該データのロックを行う」とあるので、更新準備要求により各サブシステム上のデータはロックされていることになります。このロックは、コミットまたはロールバック要求を受け取ったときに解放することになっていますが、上記の時点で統合販売管理システムに障害が発生すると、サブシステムにコミットまたはロールバック要求を送信できなくなってしまいます。この結果、サブシステムは統合販売管理システムからの指示待ち状態となり、ロックされたデータが解放されずそのままになる不具合が生じます。
∴ロックされたままとなる - 更新データがロックされたままになるという問題への対処を問われているので、両サブシステムのデータのロックを解放できる方法を選択します。
- 在庫管理サブシステムのデータのロックは解放されないので誤りです。また図1のシステム構成を見ると、在庫管理サブシステムと販売管理サブシステムは直接接続されていないようですので、要求を送信すること自体が無理そうです。
- 「ア」と同様の理由で誤りです。
- 正しい。統合販売管理システムからの要求を一定時間受け取れない場合にロールバックする仕組みを設けることで、当該データはロック状態から回復できます。
- 統合販売管理システムは障害によりダウンしているので、要求は期待できません。待つ間、当該データはロックされたままになってしまうので、他のトランザクションからも更新不可となり業務の遂行に影響を与えます。
広告
