アトミックコミット

コンピュータサイエンスの分野では、アトミックコミットとは、一連の個別の変更を単一の操作として適用する操作のことです。変更が適用されると、アトミックコミットは成功したとみなされます。アトミックコミットが完了する前に障害が発生した場合は、アトミックコミットで完了したすべての変更が元に戻されます。これにより、システムは常に一貫した状態になります。分離のもう 1 つの重要な特性は、アトミック操作としての性質に由来します。分離により、一度に 1 つのアトミックコミットのみが処理されます。アトミックコミットの最も一般的な用途は、データベース システムとバージョン管理システムです。

アトミックコミットの問題は、複数のシステム間の調整が必要になることです。^{[1]コンピュータネットワークは信頼性の低いサービスであるため、} 2人の将軍問題で証明されているように、すべてのシステムと調整できるアルゴリズムはありません。データベースがますます分散化されるにつれて、この調整により、真にアトミックなコミットを行うことが難しくなります。^[2]

アトミックコミットは、データの複数ステップの更新に不可欠です。これは、2つの当座預金口座間の送金という簡単な例で明確に示されます。^[3]

この例は、口座 X から Y に 100 ドルを送金するトランザクション中に口座 Y の残高を確認するトランザクションがあるため、複雑になっています。まず、口座 X から 100 ドルが削除されます。次に、口座 Y に 100 ドルが追加されます。操作全体が 1 つのアトミック コミットとして完了しない場合は、いくつかの問題が発生する可能性があります。操作の途中でシステム障害が発生すると、X から資金を削除した後、Y に追加する前に、100 ドルが消えてしまいます。もう 1 つの問題は、100 ドルが追加される前に Y の残高が確認されると、Y の間違った残高が報告されることです。

アトミック コミットでは、どちらのケースも発生しません。最初のシステム障害の場合、アトミック コミットはロールバックされ、お金は X に返されます。2 番目のケースでは、アトミック コミットが完全に完了するまで、Y の残高の要求は発生しません。

データベースシステムにおけるアトミックコミットは、ACID ^[4] の2つの重要な特性、原子性と 一貫性を満たしています。一貫性は、アトミックコミットにおける各変更が一貫している場合にのみ達成されます。

例で示されているように、アトミック コミットはデータベースのマルチステップ操作に不可欠です。データベースが存在する物理ディスクの最新のハードウェア設計により、真のアトミック コミットは存在できません。ディスクに書き込むことができる最小領域はセクターと呼ばれます。1 つのデータベース エントリは、複数の異なるセクターにまたがる場合があります。一度に書き込むことができるのは 1 つのセクターだけです。この書き込み制限のため、真のアトミック コミットは不可能です。メモリ内のデータベース エントリが変更されると、それらはディスクへの書き込み待ちになります。つまり、例で特定されたのと同じ問題が再発したことになります。この問題に対するアルゴリズムによる解決では、依然として「2 人の将軍の問題」が発生します。2フェーズ コミット プロトコルと3 フェーズ コミット プロトコルは、この問題とアトミック コミットに関連するその他の問題の解決を試みます。

2 フェーズ コミット プロトコルでは、何か問題が発生した場合にデータベースの元の状態を回復するために必要なすべての情報をコーディネータが維持する必要があります。名前が示すように、投票とコミットの2 つのフェーズがあります。

投票フェーズでは、各ノードがアトミック コミットの変更を自身のディスクに書き込みます。その後、ノードはコーディネータにステータスを報告します。いずれかのノードがコーディネータに報告しないか、ステータス メッセージが失われると、コーディネータはノードの書き込みが失敗したと見なします。すべてのノードがコーディネータに報告すると、第 2 フェーズが始まります。

コミットフェーズでは、コーディネーターは各ノードにコミットメッセージを送信し、各ノードのログに記録します。このメッセージがノードのログに追加されるまで、行われた変更は不完全として記録されます。いずれかのノードが障害を報告した場合、コーディネーターは代わりにロールバックメッセージを送信します。これにより、ノードがディスクに書き込んだ変更がすべて削除されます。^{[5] [6]}

3 フェーズ コミット プロトコルは、2 フェーズ コミット プロトコルの主な問題を解消することを目的としています。この問題は、コミット フェーズ中にコーディネータと別のノードが同時に障害を起こし、どちらのノードもどのようなアクションを実行するべきか判断できない場合に発生します。この問題を解決するために、プロトコルに 3 番目のフェーズが追加されます。コミット準備フェーズは、投票フェーズの後、コミットフェーズの前に発生します。

投票フェーズでは、2 フェーズ コミットと同様に、コーディネータは各ノードがコミットする準備ができていることを要求します。いずれかのノードが失敗した場合、コーディネータは失敗したノードを待機している間にタイムアウトします。これが発生すると、コーディネータはすべてのノードに中止メッセージを送信します。いずれかのノードが失敗メッセージを返した場合も、同じアクションが実行されます。

投票フェーズで各ノードから成功メッセージを受信すると、コミット準備フェーズが始まります。このフェーズでは、コーディネータが各ノードに準備メッセージを送信します。各ノードは準備メッセージを確認し、応答する必要があります。応答が欠落した場合、またはノードが準備ができていないことを返した場合、コーディネータは中止メッセージを送信します。タイムアウトが期限切れになる前に準備メッセージを受信しなかったノードは、コミットを中止します。

すべてのノードが準備メッセージに応答した後、コミットフェーズが始まります。このフェーズでは、コーディネーターが各ノードにコミットメッセージを送信します。各ノードがこのメッセージを受信すると、実際のコミットを実行します。コミットメッセージが紛失したためにノードに届かなかった場合、またはコーディネーターが失敗した場合は、タイムアウトが経過するとコミットが実行されます。コーディネーターが回復時に失敗した場合は、各ノードにコミットメッセージを送信します。^[7]

アトミックコミットはバージョン管理ソフトウェアの一般的な機能であり、リポジトリ内の一貫した状態を維持するために不可欠です。^[8]ほとんどのバージョン管理ソフトウェアは、失敗したコミットのどの部分も適用しません。注目すべき例外は、CVS、VSS、IBM Rational ClearCase（UCMモードの場合）です。^[9]

たとえば、バージョン管理ソフトウェアが自動的に解決できないマージ競合に遭遇した場合、変更セットのどの部分もマージされません。代わりに、開発者には変更を元に戻すか、競合を手動で解決する機会が与えられます。

これにより、コミットからの1つのファイルは正常にコミットされたが、依存する変更を含む別のファイルは失敗するなど、部分的に適用された変更セットが原因でプロジェクト全体が壊れた状態になることを防ぎます。^[10]

アトミックコミットは、モノレポと呼ばれるバージョン管理ソフトウェア開発戦略を使用して、バージョン管理ソフトウェアを使用して複数のプロジェクトに同時に変更を加える機能を1回の操作で指すこともあります。^[8]

リビジョン管理システムを使用する場合、一般的な慣習として、小さなコミットを使用します。これらは、（理想的には）システムの単一の側面にのみ影響を与えるため、アトミックコミットと呼ばれることもあります。これらのアトミックコミットにより、理解しやすくなり、変更をロールバックする手間が減り、バグの特定が容易になります。^[11]

コミットのサイズが小さく、焦点が絞られているため、理解しやすくなります。1種類の変更だけを探している場合は、変更内容と変更の理由を理解するのがはるかに簡単です。これは、ソースコードのフォーマットを変更するときに特に重要になります。フォーマットの変更と機能の変更が組み合わされている場合、有用な変更を特定するのが非常に難しくなります。ファイル内のスペースがタブから3つのスペースに変更された場合、ファイル内のすべてのタブが変更されたと表示されます。機能の変更も行われた場合は、レビュー担当者が機能の変更に気付かない可能性があるため、これは重要になります。^{[12] [13]}

アトミック コミットのみを実行すると、エラーをもたらしたコミットの特定がはるかに簡単になります。エラーの原因かどうかを確認するためにすべてのコミットを調べる必要はなく、その機能に関連するコミットのみを調べる必要があります。エラーをロールバックする場合も、アトミック コミットを使用すると作業がはるかに簡単になります。問題のあるリビジョンに戻して変更を手動で削除してから、その後の変更を統合する代わりに、開発者は特定されたコミットの変更を元に戻すことができます。これにより、開発者が同じコミットにあった無関係な変更を誤って削除してしまうリスクも軽減されます。

アトミック コミットでは、一度に 1 つのバグ修正のみがコミットされる場合、バグ修正を簡単にレビューすることもできます。関連性のない可能性のある複数のファイルをチェックする代わりに、レビュー担当者は修正されるバグに直接影響するファイルと変更のみをチェックする必要があります。これは、バグを修正する変更のみがコミットに含まれるため、バグ修正を簡単にパッケージ化してテストできることも意味します。

• 2相コミットプロトコル
• 3相コミットプロトコル
• コミット（データ管理）
• アトミック操作