分散処理とロックと、待ちが発生する仕組み
あなたが忙しいカフェのバリスタだと想像してください。カウンターにはコーヒーを待つお客さんがたくさん並んでいます。一度に一人ずつしかコーヒーを淹れられないとしたら、どうなるでしょう？お客さんは長い列を作り、待ち時間にイライラしてしまいます。しかも、列が長くなればなるほど、店が混乱して破綻してしまうかもしれません。これが、データベースやウェブサーバーでロックが発生する状況と似ています。複数の処理が同時に同じデータにアクセスしようとすると、誰かがロックを取得するまで他の人は待たなければならないのです。
分散処理
分散処理。複数のコンピューターが協力して仕事を片付ける仕組み。仕事を分担。スピードアップ。負荷分散。サーバーに優しい。
ロック
ロック。データを守るための鍵。複数の処理が同時に同じデータをいじると混乱。ロックをかけて、一度に一つの処理しかデータをいじれないようにする。データの一貫性を保つ。
SQL Server や MySQLのロックと分散処理
SQL Server や MySQLは、テーブルの更新に対してロックを発生させる。行が別なら分散処理を行うことができる。
テーブル例
| 行ID | データ |
|---|---|
| 1 | データ1 |
| 2 | データ2 |
| 3 | データ3 |
| 4 | データ4 |
| 5 | データ5 |
SQL Server や MySQLのロックと分散処理
SQL Server や MySQLは、テーブルの更新に対してロックを発生させる。行が別なら分散処理を行うことができるが、同じ行を更新しようとすると競合が発生する。
テーブル例
| 行ID | データ |
|---|---|
| 1 | データ1 |
| 2 | データ2 |
| 3 | データ3 |
| 4 | データ4 |
| 5 | データ5 |
行が別なので競合しない場合
この図では、ユーザーAが行ID 1 を更新中にロックを取得し、ユーザーBが行ID 3 を更新中にロックを取得しています。行が異なるため、同時に更新が可能です。
行が競合する場合
この図では、ユーザーAとユーザーBが同時に行ID 2 を更新しようとしています。ユーザーAがロックを取得中にユーザーBが待機しており、ユーザーAがロックを解除するまでユーザーBは更新できません。
はなしはかわります。
昔のCGIとロック
昔のCGIの時代は、ウェブサーバー上でCGIスクリプトが動いていました。これによるファイル操作などは分散処理ではなかったことが多く、例えばファイル更新処理などを行う場合は、ユーザーが増えると応答時間がどんどん伸びてしまいました。応答時間が伸びるだけならいいですが、待ちを発生させるだけでも、ウェブサーバーはリソースをたくさん消費するため、サーバーダウンにつながることもありました。
分散処理って、ユーザー数が予測できないウェブシステムにはめちゃくちゃ重要なんです。でも、社内で使うイントラのウェブアプリの場合、ユーザーが一人だけならそこまで気にしなくてもいいんですよね。家で一人で開発していると、ついつい性能とか同時接続性のことを忘れがちですよね。だから、注意してくださいね。