銀行振込とデッドロック_データベースのACID特性

あなたが送ってくださったデータベースに関する資料、拝見しました。 データを綺麗に整理する正規化については、以前も掘り下げましたけど、今回はその先にあるもっとこうダイナミックな世界の話になりそうですね。 ええ、整理されたデータを今度はどうやって動かすか、しかも絶対に間違いが許されない状況でですね。 はい。安全かつ確実に扱うための、まあ運用の核心部分です。 例えば資料にもあった銀行の振り込み、これすごく分かりやすいです。自分の口座から1万円が引かれて 相手の口座に1万円が足される。この一連の動作のちょうど真ん中でシステムが停電になったら なんて考えるとちょっと背筋が寒くなります。僕の1万円はどこへ消えちゃうんでしょうか。 まさに宙に浮いた状態ですよ。もちろん現実にはそうならない仕組みがあるんですよ。 ほう。その大惨事を防ぐための知恵こそが、今回のテーマの根幹なんです。 なるほど。では今回は、私たちのデジタルな生活の裏側で、その消えた1万円のような大惨事を防いでいる データベースの鉄の掟について深く探っていきましょう。そのお金を動かすというような もうこれ以上は分割できないひとまとまりの処理、それこそがトランザクションという概念です。 そしてそのトランザクションが絶対に守らなければならない4つの絶対的な性質が ACID特性と呼ばれています。ACID特性。 ええ。これはもうデータベースを語る上では避けては通れない、いわば憲法のようなものですね。 ではその憲法の条文を一つずつ紐解いていきましょうか。そもそもなんでこんな複雑な仕組みが必要になったんでしたっけ。 正規化でデータは綺麗になったはずなのに。そこが面白いところでして、 正規化はデータを整理整頓して矛盾をなくす素晴らしい手法なんですけど、副作用としてデータが複数のテーブルに分散されますよね。 ああ、そうでした。以前なら1カ所の更新ですんだものが、注文テーブルを更新して、在庫テーブルの数を減らして 顧客の購入履歴テーブルにも記録するといった具合に、複数の場所を同時に書き換える必要が出てくるんです。 あ、なるほど。先ほどの銀行の例もまさにそれですね。私の口座テーブルから1万円引く処理と 相手の口座テーブルに1万円足す処理、これらは2つの別々の操作だけど意味としては完全に一つのセット。 ええ、どちらか一方だけ実行されるなんてことは絶対にあってはならないと。その通りです。 このセットでなければ意味がないという処理の単位がトランザクション。なるほど。 そしてその侵害性を保証するのが、頭文字をとってACID（アシッド）と呼ばれる4つの特性です。 ではそのACIDの最初のA、Atomicity（原子性）から見ていきましょう。 資料には「全部やるか全くやらないか、All or Nothingの原則」とあります。潔いですね、これは。 ええ、非常に潔い考え方です。中途半端な状態をシステムとして絶対に許容しないという、まあ強い意志の現れですね。 はい。この原子性を実現するためにデータベースの裏側ではロールバックという仕組みが動いています。 ロールバック。もし処理の途中でエラーが起きたら、それまでに行ったすべての操作を取り消して トランザクションが始まる前の状態、つまり完全に何もなかった状態に巻き戻すんです。まるでタイムマシンのようですね。 失敗したらその失敗ごと過去に戻って消してしまう。そうです、そうです。でもこれってデータベースに限った話じゃないですよね。 例えば大きなプレゼンの準備でも、資料AはできたけどBは未完成、なんて中途半端な状態で本番に臨むわけにはいかない。 ああ、なるほど。完全に準備を終えるか、一旦仕切り直して計画を練り直すか、まさにAll or Nothingの発想だなと。 素晴らしい例えです、まさにその通りで品質管理の基本ともいえる考え方ですよね。 そしてこの巻き戻しができるのも、後ほどお話しするD、つまり永続性の仕組みが処理前の状態を しっかりと記録しているからこそ可能になるんです。ああ、全部つながってるんですね。ええ、すべてが連携しているわけです。 なるほど、失敗したら元に戻す原子性は分かりました。でもそもそも処理が成功したかどうかってどう判断するんでしょうか。 ただシステムエラーが出なければOKというわけでもなさそうですな。鋭い指摘ですね。そこで重要になるのが次のC、 Consistency（一貫性）です。一貫性。はい。これはトランザクションの前後でデータの辻褄が合っていることを保証するという性質です。 辻褄、ですか。はい。データベースにはあらかじめ様々なビジネス上のルールや制約が設定されています。 例えば、商品の在庫数がマイナスになってはいけない。ああ、はいはい。銀行口座の残高は負の値にはならないといった、 そのシステムの根幹をなすルールです。一貫性とは、どんなトランザクションが実行されようともこれらのルールが絶対に破られないことを保証するということなんです。 ああ、先ほどの振り込みの例でいえば、僕の口座から1万円減って相手の口座が1万円増える、 この取引の前後で銀行全体の預金の総額は変わらないはずですよね。その通りです。 もし僕の口座から1万円引かれたのに相手の口座が2万円増えていたら、システムエラーは出ていなくてもこれはもう失敗した処理だと。 正味その通りです。原子性が処理の完遂を保証するのに対し、一貫性は処理内容の正しさを保証する。 この二つが揃って初めて信頼できる処理と言えるわけです。さてここからが不思議な話です。I、Isolation（独立性）。 オンラインストアのセールの見たいに、何千何万という人が同時に同じ商品にアクセスすることってありますよね。ええ、ありますね。 それなのにシステムは混乱しない。資料には「まるで一人ずつ順番に処理したかのような同じ結果になることを保証する」とありますが、 そんな器用なことどうやって実現しているんですか。なんだか物理的に不可能に聞こえますけど。それを可能にするのが、 いわゆるロックっていう技術なんです。ロック。あるトランザクションがデータを操作している間、そのデータに一時的に鍵をかけて 他のトランザクションがアクセスできないようにするんです。鍵をかける。ええ。いわばデータベース内の交通整理ですね。交通整理。ええ。 でも、そんなに頻繁に鍵をかけていたらシステム全体がものすごく遅くなりませんか。一人通るたびに交差点が赤信号になるようなもので 大渋滞が起きそうですけど。素晴らしい懸念点です。そして、それこそがこの独立性の奥深さなんですよ。ほう。 おっしゃる通り、常に最高レベルの厳格さでロックをかけていると、安全性は高まりますが、処理速度、パフォーマンスは著しく低下します。 やっぱりそうですよね。だから実はこの独立性のレベルは、システムの目的に応じていくつか調整できるようになっているんです。 調整できると言うと？例えば一瞬の誤差も許されない銀行の勘定系システムなら、最も厳格なロックをかけて絶対にデータの不整合が起きないようにします。 パフォーマンスが多少犠牲になっても正確さが最優先です。はい。一方でSNSの「いいね」のカウンターのような場合はどうでしょうか。 あ、いいねの数。表示される数がコンマ数秒前のものであったとしても大きな問題にはなりませんよね。確かに。 誰かがいいねを押した瞬間に世界中の全員の画面でカウンターがピタッと同時に増えなくても誰も気にしないですね。 ですよね。そういったシステムではロックを少し緩めて、処理の正確さを少しだけ犠牲にする代わりに たくさんのアクセスを高速にさばくことを優先するという選択がなされるわけです。なるほど。 絶対的な安全と快適なスピード、このトレードオフをどう設計するかがエンジニアの腕の見せ所とも言えます。 なるほど、全てにおいて最強の設定がベストというわけではないんですね。サービスの性格を見極めてバランスを取っていると。 面白いですね。ええ。では最後のD、Durability（永続性）。これはシンプルですが最も心強い性質かもしれません。 一度完了、コミットした処理結果は、その後にシステムが故障しようが停電が起きようが絶対に消えない。 ええ、トランザクションが正常に完了したことをコミットすると言います。コミットされた瞬間、その処理内容はデータベースの非常に堅牢な記録領域 一般的にはディスク上のトランザクションログに書き込まれます。はい。これはメインメモリーのように電源が切れたら消えるような揮発性のものではありません。 だから、たとえその直後に停電が起きても、システムが再起動した際にそのログを読み込んで「ああ、この処理は完了していたはずだな」と復元できるのです。 つまり僕たちがオンラインショッピングで購入を確定するボタンを押した瞬間の、あの「これで大丈夫だ」という安心感は、 この永続性によって裏付けられているわけですね。まさにその通りです。こうして見るとACIDの一つ一つが 見えないところで我々のデジタル社会をガッチリと支えているのがよくわかります。まさに。しかしですね、先ほど話題に出た独立性を守るためのロックという仕組み、 この交通整理が時として最悪の事態を引き起こすことがあるんです。と言いますと、交通整理が逆に混乱を招くということですか。 ええ、それが資料にもあったデッドロックです。デッドロック。独立性を守るためのルールが逆にお互いの足かせとなって、 誰も身動きが取れなくなってしまう膠着状態のことです。具体的にはデータベースの中で何が起きているんでしょう。例えばこう考えてみてください。 トランザクションAがまず商品Xの在庫データにロックをかける。はい。で、次に顧客Yのポイントデータにロックをかけようとしています。 一方で、ほぼ同時に動いたトランザクションBが先に顧客Yのポイントデータにロックをかけ、次に商品Xの在庫データにロックをかけようとした。 さあどうなるでしょう。ええと、AはYのロックが欲しいけどそれはBが持っている。そうです。 BはXのロックが欲しいけどそれはAが持っている。あ、これお互いに相手が鍵を放すのを永遠に待ち続ける状態になりませんか。 その通りです。資料のイラストにあった二人組の人間がお互いの持っている鍵を要求しあっている状態、あれがデータベース内で起きるのです。 うわあ。これがデッドロックです。結果、両方のトランザクションが完全に停止し、関連する処理がすべて止まってしまいます。 うわ、それは怖いですね。整合性を守るための交通整理が完全な交通マヒを引き起こしてしまう。実際にそんなことが起きたら現場はパニックになりそうです。 なりますね。以前あるECサイトで、在庫更新と注文確定の処理がまさにこのデッドロックを起こして、 ブラックフライデーのセール開始5分で決済システムが完全に止まってしまったことがありました。ええ？あの時は本当に血の気が引きましたよ。 それは想像を絶しますね。では、そんな恐ろしいデッドロックが起きてしまったら、もう解決策はないんですか。ええ、もちろんあります。 多くのデータベースシステムにはこのデッドロックを自動で検知する仕組みが備わっています。ほう。そして検知するとどちらか一方のトランザクションを犠牲にして 強制的にエラー終了させるんです。犠牲、ですか。それはどういう基準で選ばれるんでしょう。 例えば僕がまさに買おうとしていた限定商品の決済処理が犠牲にされたら、購入は失敗するということですよね。そうなります。 どちらを犠牲にするかの基準はシステムによりますが、例えば処理が始まったばかりの方とか、処理が軽い方などが選ばれやすいですね。 なるほど。システム全体が停止し続けるよりははるかにマシという判断ですね。なるほど。エラーメッセージの裏側にはそんな壮絶なドラマがあったんですね。 データベースの世界も単純な白黒では語れない奥深いバランスの上に成り立っていることがよく分かりました。ええ、本当に。 完璧なルールを作ろうとすると時としてそれが自分を縛り付けてしまう。現実世界と同じようなジレンマがここにも存在しているんです。 今回はデータベースの信頼性を支えるトランザクションとその心臓部であるACID特性について深く掘り下げてきました。 原子性、一貫性、独立性、永続性。この四つの鉄の掟がいかに重要か身に染みました。 そしてそれを実現するためのロックやロールバックといった技術、さらにはその落とし穴であるデッドロックという現象まで、一連の流れとしてご理解いただけたかと思います。 ええ。ここで面白いなと思ったのは、このACIDという考え方が何もデータベースだけの専門用語ではないという点です。お、というと。 例えば外科手術なんてまさにACID特性の塊じゃないでしょうか。一連の処置は全部やるかやらないかの原子性。ああ、なるほど。 術前と術後で患者の状態に矛盾があってはならない一貫性。他の手術の影響を受けない独立性。 そして一度成功した手術の結果は永続的でなければならない。素晴らしい、その通りですね。 仕事における重要なプロジェクトや、日常生活の複雑な手続きなど、失敗の許されない作業にはこのACIDの考え方が自然と組み込まれているんです。 信頼性を確保するための普遍的なフレームワークといえるかもしれませんね。さて、最後に一つ思考を巡らせてみたい問いがあります。 先ほど独立性の話で、正確さとスピードのトレードオフについて触れました。ええ、非常に重要な設計思想の違いですね。 銀行のような絶対的な正確さが求められるシステムもあれば、SNSのいいねのように多少の曖昧さを許容してでも速度を優先するシステムもあると。 ではこのトレードオフの境界線はどこにあるのでしょう。例えばあなたが設計者だとして、リアルタイムで何百万もの票が集まるオンラインの投票システムを作るとします。はい。 完璧な一票の重みを守るために少し集計が遅れるシステムと、表示は早いけれどごく稀に最新の状態が反映されない可能性があるシステム、どちらを選びますか。 うーん、これは難しい問いですね、投票の目的にもよりますからね。ですよね。絶対的な正解はなくて、そのサービスがユーザーに何を提供したいのかという、 まあ哲学にまで踏み込む話になる。絶対的な正確さと心地よい体験速度。あなたが普段使っているサービスはこの天秤の上でどちらに重きを置いているように見えますか。 少し考えてみるのも面白いかもしれませんね。