#475 RDBはACIDだからって本当に安心して良いのか？

この番組は「エンジニアの成長は楽しい、学びから」をモットーに、昨日より少し成長できる学びをわいわいお届けするエンタメ系テックラジオです。

よっこいしょー。

はい、というわけで今日はですね。

はい。

「データ思考アプリケーションデザイン」という書籍の第七章、トランザクションという章からですね。

おおー。

えー、一部を取ってきて。

はい。

アシッドの弱点。

弱点？

アシッドの穴？

アシッドの穴？

お。

うん。

はい。についてちょっとお話ししていこうかなと思います。

なるほど。てっきり分離レベルとかが来るのかと思った。

あー、いや、似たような話ですよ。

似たような話なんだ。

はい、似たような話ですよ。

そうなんだ。

はい。でーね、ほんとはね、ちょっとね、順平に問題出しながらやりたかったところなんですけど。

はい。

えー、ちょっと探りながらいきますね。

お、はい。

Eコマースのサイトまず思い浮かべていただいて。

はいはいはい。

で、まあなんか購入しますと。

うん。

で、購入する処理をやるときに、えー、なんか在庫を1つ減らすような処理をすると思います。

うん。

えー、データベースを直接叩く場所。

はい。

アプリケーションで言うと、もうSQL直叩きするというふうなことを想像したときに。

うん。

なんかどんなコードにするでしょうかというところで。

ん？

普通に購入するから在庫を1個減らすっていう処理。

はい。

SQLでどう書くかなというところで。

うん。

ちょっと1個じゃあ例を出してみましょうか。

はい。

本当に多分無難に、もう何も考えずに書くとですね。

うん。

多分セレクト文で在庫を見ますと。

見ました。

で、取得した数が。

うん。

えー、注文数より。

うん。

多かったら。

うん。

えー、アップデートとかで。

うん。

在庫数を減らしますと。

注文、ああはい。在庫のほうが多かったらってことですね？

はい。

うん。

そうです、在庫のほうが多かったら。在庫のほうが少なかったらエラー出して終わりますと。

はい。

はい。今コード思い浮かべましたかね？

思い浮かべました。

はい。ま、こういう書き方をしてるアプリケーション、全然世の中いっぱいあるかなと思うんですけど。

はい。

絶対こんなことしちゃだめです。

わかりました。

はい。絶対だめです。

わかりました。

で、なんで絶対だめなのかということを。

うん。

今日の話聞くと。理解することができると。で、あとどうしたらいいかがわかると。

はい。

えーいう話になります。

なるほど。

えー、じゃあまず最初ですね。

はい。

さっき言ったこのセレクトして、で、数どうかなって見て、アップデートかける。

うん。

これ何がいけないんだというところなんですけど。

はい。いいじゃないですか、個数足りてるんだから。

本当ですよね。

はい。

これがですね、えー、まあEコマースのサイトとかだとね。

うん。

ただなんだろうね、えー、Amazonプライムセールとかがあったとしましょう。

はい。

めっちゃ注文来ますと。

うん。

めっちゃ注文来るとですね。

うん。

この、ま、セレクト、読み込んで判断して書き直す。

うん。

っていうこの3ステップが平行に走りますと。平行に走る可能性があります。

平行に、だからAさんBさんのが両方同時に走るよっていうことですか。

そうですね。

うん。

かいちが読み込んで。

うん。

で、判断、あー在庫いっぱいあるわ。で、減らすって書き込みをする前にのりさんが読み込んで。

うん。

のりさんのほうもOK出て。

うん。

で、のりさんと僕で在庫10個しかないのに。

うん。

8個ずつ買うみたいな。

なるほど。

そんな処理が起きてしまいます。

はい。

で、これ恐ろしいのがですね。

はい。

テストじゃわかんないんですよ。

あー、確かに。

ソフトウェアテストでこれをテストするときって。

うん。

多分在庫が、いやちょっとデータベースモックにする気がするんですけど、まあ例えばE2Eだとして。

うんうんうん。

えー、データが、まあ在庫が10個あって、5個購入したら残り5個になるみたいな。

うん。

ま、テストを書くわけですよ。

はい。

これは成功します。

しますね。

C。

はい。

今回この平行で実行したときバグるよねみたいな、そんなテスト書かないっす。

確かに。

はい。それゆえ。

はい。

まあ実装されうるし。これなんならAIは平気で実装してくると思います。

マジっすか。

はい、注意しないと。

うんうんうん。

で、このテストの、テストじゃないや、すいません。この書籍の中で。

はい。

このバグですね。

うん。

実際に世の中にある。

うん。

あー、世の中のアプリでいっぱいあるぞっていう話をしてて。

うんうん。

えー、まあEコマースのサイトとかでも、まあこれちょっといろいろぼかされてたんですけど、まあ人気ECサイト12個で、えー、この平行したときに在庫以上のものを買えるような攻撃が成立したとか。

うんうんうん。

あとは2014年にあるビットコインの取引所の出金リクエスト。

うん。

の同時多重送信でビットコインを通常よりも盗まれ、盗むことができてしまったと。

うーん。

ま、結構大事件なんですけど、これも。

確かに。

はい。このさっきのSQL、セレクトして、えー、条件確認してアップデートするっていうふうな書き方をすると。

うん。

こういうやべえことが起きますと。

うんうんうん。

なので、まあかなり注意する必要があるんですね。

うん。

で、まあ正直、その僕もなんでしょうね、めちゃくちゃリクエストが来る、スパイクでめっちゃリクエストが来るようなアプリケーションってあんまり開発したことがなくて。

うんうんうん。

ま、幸いそんなにこういう被害を、被害というかなんだ、なんかやらかしをしたことはないんですけど。

はい。

おそらくこういうスパイク的にリクエストが来るようなアプリケーションにおいて、このデータベースの触り方っていうのは非常に注意する必要が。

うん。

あるんですね。で、ここまででなんかちょっと無難に実装するとやべえぞっていうところをちょっとお話ししたんですけども。

はい。

えー、ここから、まあアシッドってなんだっけというところ。

うん。

なんだっけというのと、あとは穴があるって言ったのってなんだっけというところをちょっとお話に移っていきます。

はい。

えー、リレーショナルデータベースにはアシッドの特性が、性質があるよっていうふうに、まあ言われるんですけど。

うん。

えー、これがですね、A、アトミシティ、原始性。

うんうん。

これは、まあなんかなんて言うんでしょうね、えー、中途半端な処理で終わらないよっていうんですか。ま、全部変更が終わるか、何も変更されないかというような。

全か無かの法則ってことですか。

そうですね。

うん。

全か無かの法則、うん。がA。で、Cはデータが正しい状態を保ち続けることができるという一貫性。

コンシステンシー？

コンシステンシー。Iはアイソレーション。同時実行でも干渉しないよ。

うん。

っていう。分離されてるよっていう分離性。Dがデュラレビリティ、D。デュラ、デュラビリティ、えー、永続性。コミットしたら消えないよ。

うん。

というものが、まあアシッドと呼ばれる性質になります。

はい。

えー、ただですね、このデータ思考アプリケーションデザインの中では、このアシッド特性。

うん。

別にそんなないよって言ってます。

別にそんなないの？

はい。

ちょっとそれは結構天地ひっくり返るレベルの新事実なんですけど。

で、え、ただなんて言うんでしょうね、これで別にそんなないよって言ってんのは、まあちょっと一部ほんとにないんですけど。

うん。

ま、大体データベース単体というよりはアプリケーションってデータベースだけで成立してるものではないので。

うんうんうん。

本当にアプリケーションデザインの文脈で言うと、えー、RDB使ったとてアシッドは別に保証されるものじゃないよということを言ってるんですけど、ちょっと詳しく見ていきます。

え、えっとすいません、それは機能はあるけど使わなきゃそれは動かないよってそういう意味でもない？

でもない。

でもない？

でもない。

なるほど。

ま、一部そう。一部そうなんですけど、そうでもないです。はい。

じゃあちょっと続きをお願いします。

続きいきます。

はい。

で、えー、まあAからいくんですけど、Aは、まあある程度ある。原始性はある程度ありますと。

うん。あ、そっか、1個ずつにあるないがあんの？

あ、そうです。

ああ、なるほど。

はい。

まず原始性はある。

ある。

つまり、えーっと、中途半端に成功することはないと。

えー、ない。

うん。

うーん、いや、あー、うーん、あー。

え？

え？ あー、なんて言えばいいんだろう。

これちょっとご質問いいですか。

はい。

この中途半端っていうのは、例えばトランザクションで、えー、データベース更新する処理が例えば3つぐらい並んでたとして。

はい。

それが、えー、基本的には、えー、1個も成功しないか3つ成功するかのどっちかですよっていう認識でまず合ってます？

えー、アシッド性、アシッドの中のAの。

はい。

概念というか定義としてはそれで合ってます。

うんうんうん。

ん、うん。で、この書籍の中では。

はい。

そこまでではないと言ってると思います。

そこまでではない。

なんかその、なんでしょうね、複数のテーブルにまたがった修正があったりとか。

うん。

で、あとはそのアプリケーションの中で。

うんうん。

本当に保証したい原始性。

うん。

はすべて、えー、保証できないって言うんですか、なんて言えばいいんでしょうね、えーっと、1回で1つのテーブルの1レコードに関しては原始性あると思うんですよ。

うん。

本当に中途半端に書き込まれたものとかはない。

はい。

けど、1個の処理の中で、なんか複数回データベースに書き込みをしたりとかする場合に関しては。

うん。

アプリケーション側でどうにかしないと中途半端なものができる可能性はある。

ああ。

ですね。

なるほど。

はい。ま、なのでデータベース自体には原始性はあるんですけど。

うん。

なんかアプリケーションデザインとしては、ま、ちょっと注意は必要ではあるし。

うん。

あとはDB外の副作用とかも、まああると思うので。

うん。

例えばさっきのEコマースの購入で言うと、なんか買ったら、まあAmazonとかだと購入しましたよメール来るじゃないですか。

はい。

で、あれもまあ副作用の1つですね、メール送信。

うんうんうん。

ま、この辺は中断できないので、中断じゃないや、えーっと、やり直せないというか。

はい。

メール送られたけどアプリの画面上は失敗って出てるみたいなのはあり得ると思うんで。

うんうんうん。

その辺はあの処理順とかを気にしながら、原始性を、データベースの原始性を生かせるように設計する必要がありますね。

うん。

ま、なんでデータベースに書き込む前にメール送ったりしないってことですね。

なるほどね。一旦コミットされてから送れよっていう。

あ、そうですそうです。

うん。

はい。

うん。

まあAはまあ置いといて。

うん。

まあある程度あるんで。

ある程度。

まあほぼある。

はい、ほぼある。

ほ、ほぼある。

Aはほぼある。

はい。続いてC。

はい。

Cは、まあ一部あるんですけど。すべて、えー、DBの責任ではないと言ってます。

ん？

Cはあの。

一貫性？

えー、はい、一貫性ですね。このデータが、なんだろうな、その、データ固有のルールを守り続けるかみたいなところなんですけど。なんか例えば。

はい。

なんかユニーク制約とかってDBで設定できるじゃないですか。

はいはいはい。

あの辺はDBがやれるんですよ。

うん。

一方でなんかドメイン知識的な感じで。

うん。

えー、そうだな。例えばじゃあ銀行口座で言うと。

はい。

のりさんと僕がそれぞれ口座を持っていて。

はい。

えー、僕からのりさんに1万円送るとします。

うん。

で、そのとき僕からのりさんに1万円送ったあとの。

うん。

のりさんと僕の口座残高の合計って合ってるはずじゃないですか。

そうっすね。

ただ、その、のりさんと僕の口座残高が合ってることはDBは保証してくれないです。

ほー。えーと、それは検証できないっていう意味で？

DBのエンジンが。

うん。

ここが合ってないから処理失敗っていうふうにはできない。

あー、チェック制約的なものが働いてないよってこと？

はい。

うんうんうん。

ま、もちろんね、その数字がマイナスにならないみたいなのはすごい大事で、これはDBでできるんですけど。

うん。

なのでさっきのEコマースで言う、僕とのりさんが過剰にものを買ったときに。

うん。

エラーにするっていうところで言うとDBもやれるんですけど。

うんうん。

えー、DBのそのデータ型とかで、ま、定義しきれないような。

うん。

なんか細かーい制約みたいなところについては。

うんうん。

アプリ側で、えー、正しく検証するように書いて。

うん。

やらないと、このCっていうのは守りきれないよねっていうふうなことを言ってました。

あー。なんか、ゆうちょの番号とかさ、決まったルールあるじゃないですか、なんか。

はい。えー、こ、口座番号っすか？

はい。

はい。

そういうのってデータベースでチェックできないよねみたいな、なんか、な、なんて言うんだろうな、プログラム的なチェックができないってことなのかな？

あー、はい。それも1つですね。そうですね。

チェックサムみたいな。

適当な言葉をつけれないみたいな、はい。

ん、でもそれって一貫性なのか？

はい。アプリケーションレイヤーで言うと。

うん。

その、常に真であるべきルール。

うんうんうん。

っていう意味では一貫性であると理解しています。

なるほど。

本当にだからなんて言うんでしょうね、データベースができる範囲でのCはあるんですけど。

うんうん。

アプリケーションに求められるCをすべてDBに押し付けることはできない。

うん。うんうんうん。

っていう感じですね。

なるほど。

で、ちょっとAとC来て、次Iなんですけど。

はい。

Iが1番重いんで、一旦Dに行くんですが。

一旦、はい。

はい。D、これ永続性ですね。

うん。

これも言うてね、障害起きたらデータ吹っ飛びますよということを言ってます。

あー。まあ。まあまあまあ、確かに。

まあまあまあっていう。

え、これどの規模のことまで言ってんだろうね。

えーっと。

例えばさ。

停電とか。

例えば地球が爆発してなくなったらなくなりますよねみたいな、なんか、そんなヘリ、ヘリクスみたいなこと言ってるのかな。

えっと、例えば、なんかSSDとかだと、あのー、ほんとに内部電源も全部吹っ飛ぶと。

うん。

もうデータが化けちゃうらしいんですよ。

うーん。

とか、あとは過電流とかが流れると、ま、ハードディスクとか故障しますし。

はい。

っていう、なんかハードウェア故障の話をしてますね。

うーん。

ま、なのでアプリケーションデザインっていうレイヤーでは、ま、適切に、なんかレプリケーションとかバックアップとか。

うん。

っていうのをちゃんとやりましょうねっていうのを書いてます。

なるほど。だから、まあそれも機能単体で及ばないところは、えー、アーキテクチャを設計することによって、えー、守っていくべきところですよっていう。

そうですね。

そういうことですね。

はい。

うんうん。

で、まあちょっと重いI。

重いI。

重いI。なんか。

I、あ、重いIっていうとね、ちょっと。

なんかちょっとメンヘラっぽい感じするけど。

アイソレーションです。

はい、アイソレーションね。

はい。

で、これアイソレーション何かというと、えー、並行のトランザクションが互いに干渉しないようにする、なってるよっていうのが、まあ分離性。

うん。

になっていて。で、さっきのその最初のEコマースの例で言ってた。

うん。

のりさんと僕が同時に書き込んだときに、過剰に在庫吐き出しちゃうことあるよねみたいな。

うんうん。

ところが、まあ分離性になるんですけど。

うん。

さっき言ったとおり、SQLのデフォルトの設定でさっきの書き方をすると、アイソレーションないんですよ。

デフォルトの設定でやるとアイソレーションがない？

はい。なんかデータベースごとにアイソレーションレベルの設定ができるんですけど。

はい。

ただデフォルトで設定すると、さっきののりさんと僕の例のように。

うん。

過剰に在庫を吐き出すような設定になってしまいます。

ほー。え、それトランザクションを使ってもってこと？

そうですね、はい。トランザクションを使っても。えーっと、トランザクションを使うと、すいません、どっからどこまでをトランザクションを使うって言ってます？

えー、スタートトランザクションからコミットまでの間。

セレクトからってことですよね？

うん。

はい。あ、それやると直列というか、アイソレーションができるんですけど。

うん。

それはそれでいいのかなっていうところがあります。

やって、含みがすごいぞ、はい。

ちょっとあとで話すんで。

はい。

ふわっとさせとくんですけど。

わかりました。

はい。あ、いや、そんなことないか。

ん？

あ、し、ちょ、話しちゃいます。

はい。

早速。

ああ、早速、はい。

はい。さっきののりさんが言ってた、じゃあそのトランザクションに1つ、ま、ひとまとまりにしちゃうのどうなんのっていう。

うん。

ところなんですけど。

うん。

これあの、ほんとに、なんだ、真正面の直列実行。

うん。

っていう解決策になりますね。

うんうん。

で、これ、まあやろうと思うとどうなるかというと、さっきの例で言うと、えー、Eコマースのサイトで僕が購入ボタンを押しました。

はい。

で、セレクトを押します。

うん。

セレクトが実行されます。

うん。

で、そのタイミングで多分のりさんが購入してセレクトを実行しようとします。

はい。

ただ、えー、かいちのトランザクションが実行中なので。

うん。

のりさんのほうは待ちます。

はい。

で、かいちのやつが終わったあとに、のりさんの処理が始まって。

うんうん。

えー、処理がされて、あ、もう在庫ないよって言ってエラーが出るみたいな。

うん。

ま、そんな動きになると思いますけど。

はい。

ま、これも解決策の1つではあるんですが。

うん。

これってクエリの処理が重くなるんですね。

そうっすね。

トランザクション処理か、はい。

待ちが長くなっちゃう。

そうです。で、待ちが長くなると。

うん。

まあ、ほんとにユーザー数が多いようなサービスにおいては。

うん。

ま、タイムアウトが発生したりだとか、あとDBの負荷も上がんのかな、上がんねえか。DBの負荷上がんないと思うんですけど、パフォーマンスにちょっと問題が出てくる。

うんうんうん。

ですね。なので、まあサービスもスケールしないし、あとはなんか、それこそね、さっきは在庫10個しかないからブロックできて良かったなんですけど。

うんうん。

じゃあ在庫が1万個あって、えー、200人が殺到しますみたいな。そういう大セールな場合に、まああんまり、なんだろうな、ユーザーが熱狂してるうちに購入してくんないというか。

うんうんうん。

それはそれでちょっとビジネス的な課題がありそうだなとは、いうのがまあ順次実行の強みと弱みの部分になりますね。

なるほどね。整合性は保てるけどもみたいな。

そうです。

うん。

っていうので、じゃあそれをまあ解決しつつ別のトレードオフもあるよみたいなのがあと2つ手法としてあるんですけど。

えー、ミスったら謝る。

あー、1つ、それも。

おお。

ん？いや、ちょっと待ってください。ミスったら謝るってどういうことだ？

えーっと、整合性が崩壊したときに関係者各位に謝る。

あ、違う違う違う違う。

違う。

違う違う違う。違います違います。