LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託

要件定義書やDB設計書の中に、「本システムのトランザクションはACID特性を満たすこと」といった一文を見かけることがあります。ACID（アシッド）特性とは、データベースのトランザクションが備えるべき四つの性質――原子性・一貫性・独立性・永続性の頭文字を組み合わせた言葉です。普段の打ち合わせでは当たり前の前提として扱われがちですが、その中身を正しく理解しないまま設計や発注を進めると、思わぬデータ不整合を招く恐れがあります。

本記事では、ACID特性を構成する四つの性質それぞれの意味と、それが破られた場合に起こり得る実害を整理します。排他制御の具体的な実装方式（楽観ロック・悲観ロックなど）や冪等性の設計には深入りせず、発注担当者・PM・設計者が押さえておきたい「トランザクションが保証すべき性質そのもの」に焦点を当てて解説します。

トランザクションとACID特性とは

トランザクションとは、データベースに対する一連の処理を「ひとまとまりの単位」として扱う仕組みのことです。例えば銀行振込であれば、「Aの口座から引き落とす」「Bの口座へ入金する」という二つの更新は、本来切り離せない一つの処理として扱う必要があります。どちらか片方だけが実行されてしまうと、口座の残高に矛盾が生じてしまうためです。

ACIDという頭文字が表すもの

ACID特性という言葉は、トランザクションが備えるべき四つの性質――Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）の頭文字を組み合わせたものです。もともとはデータベース理論の分野で整理された考え方ですが、現在では業務システムの要件定義や設計レビューの場面でも頻繁に登場する用語となっています。

なぜ発注担当者にとっても重要な言葉なのか

ACID特性は、開発者やDBエンジニアだけが理解していればよい概念ではありません。決済・在庫・会員情報の更新など、金銭や重要なデータを扱うシステムでは、ACID特性がどこまで担保されているかが、システムの信頼性を左右する要素になります。発注担当者やPMがこの四つの性質の意味を把握しておくことで、要件定義や設計レビューの場で「この処理はどこまでACIDを満たす必要があるか」を具体的に議論できるようになるでしょう。

ACIDの4性質：一覧表と流れの図解

ACID特性を構成する四つの性質は、それぞれ役割が異なります。まずは全体像を表で整理し、そのうえで各性質の意味を順に見ていきます。

次の図は、銀行振込を題材に、原子性によって「全て成功」か「全て取り消し」のどちらかで完了する流れを示したものです。

原子性（Atomicity）

原子性とは、トランザクション内に含まれる複数の更新が、すべて実行されるかすべて取り消されるかのどちらかになるという性質です。上の図の銀行振込の例でいえば、「Aから引き落とす」「Bへ入金する」という二つの更新は分割できない一つのまとまりとして扱われ、片方だけが反映された状態にはなりません。途中で障害が起きた場合には、それまでに行われた更新もロールバック（取り消し）され、処理開始前の状態に戻されます。

一貫性（Consistency）

一貫性とは、トランザクションの実行前後で、データが業務上のルールや制約を満たした状態に保たれるという性質です。口座の残高がマイナスにならない、在庫数が0未満にならない、外部キー制約に反した参照が発生しないといった条件は、この一貫性の考え方に含まれます。原子性が「途中で終わらない」ことを保証するのに対し、一貫性は「終わった結果がルールに沿っている」ことを保証するものと捉えると整理しやすいでしょう。

独立性（Isolation）

独立性とは、複数のトランザクションが同時に実行されても、それぞれの処理途中の状態が互いに影響し合わないという性質です。ある利用者の振込処理が完了する前の、中途半端な状態のデータを、別の利用者の処理が読み取ってしまうと、意図しない結果を招きかねません。データベースにはこの独立性を保つための仕組み（分離レベルの設定など）が用意されており、どの程度厳密に独立性を保つかは、性能とのバランスを見ながら選択されます。

永続性（Durability）

永続性とは、コミット（確定）されたトランザクションの結果が、その後にサーバー障害や電源断が発生しても失われずに保持されるという性質です。利用者から見れば、「注文が確定しました」という通知を受け取った以上、その注文記録は障害が起きても残っていることが前提になります。この性質は、データベースが更新内容をディスクなどの永続的な記憶領域へ書き込む仕組みによって支えられています。

ACIDが破られると起きること（実害の例）

ACID特性は、理論上の概念にとどまらず、破られた場合に具体的な実害として表れます。ここでは代表的な例を挙げます。

原子性が破られた場合：二重引き落としや片方だけの更新

原子性が保たれていないと、Aの口座からは引き落とされたのに、Bの口座への入金は反映されないという中途半端な状態が発生し得ます。決済処理であれば、利用者のカードからは引き落とし済みなのに、注文システム側には注文record が残らないといった不整合につながることもあるでしょう。こうした不整合は、後から手作業での突き合わせや調整が必要になり、運用負荷を押し上げる要因になります。

一貫性が破られた場合：業務ルールに反したデータの保存

一貫性が保たれないと、残高がマイナスのまま保存されたり、存在しない商品IDが注文データに紐づいたりといった、業務ルールに反する状態が生じます。こうしたデータは、後続のバッチ処理やレポート集計の段階でエラーを引き起こし、原因の特定に時間を要することも少なくありません。

独立性が破られた場合：他人の処理途中のデータを読んでしまう

独立性が十分に確保されていない環境では、ある処理が確定する前の中間状態を、別の処理が読み取ってしまう恐れがあります。例えば、残高更新の途中経過を別の振込処理が参照してしまい、実際には反映されていない残高をもとに判定してしまうと、二重引き落としや残高不足の見落としにつながりかねません。同時アクセスが多いシステムほど、この種の問題は表面化しやすいといえるでしょう。

永続性が破られた場合：確定したはずの記録が消える

永続性が確保されていないと、利用者には「確定しました」と案内した注文や入金の記録が、サーバー障害の際に失われてしまう可能性があります。会計処理や監査対応において、確定済みの記録が失われることは、信頼性に関わる重大な問題として扱われるものです。

ACIDが求められる場面とBASE・結果整合性との使い分け

ACID特性は多くの業務システムにとって重要な考え方ですが、あらゆる処理に同じ強さで求める必要があるわけではありません。

ACIDが強く求められる場面

決済・送金・在庫引き当て・会計処理など、金銭やそれに準ずる重要なデータを扱う処理では、ACID特性がしっかり担保されていることが望まれます。こうした処理で不整合が生じると、金銭的な損害や監査対応の負担に直結するため、多くのシステムではリレーショナルデータベースを用い、トランザクション管理の仕組みを活用して原子性・一貫性・独立性・永続性を確保する設計が採られています。

BASE・結果整合性という考え方

一方で、大規模かつ分散した構成のシステムでは、ACID特性を厳密に守ろうとすると、可用性（システムが止まらず応答し続けること）を犠牲にせざるを得ない場面が出てきます。こうした背景から生まれたのがBASE（Basically Available, Soft state, Eventually consistent）という考え方です。BASEでは、更新の直後は一時的にデータが不整合な状態（結果整合性が保たれる前の状態）であっても許容し、一定時間が経てば整合した状態に収束することを目指します。SNSの「いいね」の件数表示や、アクセスの多いキャッシュ更新など、多少の遅延やズレが実害につながりにくい処理では、この結果整合性の考え方が採られることもあります。

両者は優劣ではなく使い分けの関係

ACIDとBASEは、どちらか一方が優れているという関係ではなく、扱うデータの重要度や求められる可用性に応じて使い分けるものと捉えるのが実態に近いでしょう。金銭や在庫のように不整合が実害に直結する処理はACID寄りに、表示件数や統計値のように多少のずれが許容される処理はBASE寄りに設計する、という判断が一つの目安になります。

設計・発注時の確認点

システム開発を発注する場面では、次のような観点を確認しておくと、ACID特性に関する認識のずれを防ぎやすくなります。

• その処理は、金銭・在庫など不整合が実害につながるものか、それとも多少のずれが許容されるものか
• 複数の更新が一つのトランザクションとしてまとめられているか、途中で失敗した場合にロールバックされる設計になっているか
• 同時アクセスが多い処理において、独立性（分離レベル）がどう設定されているか
• 障害発生時に、確定済みのデータが失われない仕組み（永続性）が用意されているか
• 分散構成やマイクロサービス構成を採る場合、ACIDを保つ範囲とBASE・結果整合性に委ねる範囲がどこで線引きされているか

要件定義の段階で確認しておきたいこと

要件定義書に「ACID特性を満たすこと」とだけ記載されていても、それが四つの性質のどれをどの程度厳密に求めているのかまでは読み取れないことがあります。発注担当者としては、対象の処理がどこまでの整合性を必要とするのか、開発側とすり合わせておくことが望ましいでしょう。特に、複数のシステムやサービスをまたがる処理では、ACIDを厳密に適用できる範囲とできない範囲があらかじめ整理されているかを確認しておくと、後の手戻りを抑えやすくなります。

まとめ：ACID特性を踏まえたトランザクション設計

本記事では、ACID特性を構成する原子性・一貫性・独立性・永続性という四つの性質の意味と、それぞれが破られた場合に起こり得る実害について整理しました。四つの性質はいずれも、トランザクションが信頼できる形で完結するための前提条件であり、どれか一つが欠けても、二重引き落としやデータの矛盾といった問題につながりかねません。

一方で、あらゆる処理に同じ強さでACIDを求める必要はなく、可用性を優先してBASE・結果整合性の考え方を採る場面もあります。対象の処理がどこまでの整合性を必要とするかを見極め、設計・発注の段階で認識をすり合わせておくことが、無理のないシステム構成につながるでしょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）基本情報技術者試験シラバスにおけるデータベース・トランザクション制御に関する解説（https://www.ipa.go.jp/shiken/syllabus/index.html）

Tweet