データ活用やDXがどんどん解る用語集   
デッドロック/ deadlock

「デッドロック/ deadlock」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、計算機科学(コンピュータサイエンス)でのコンピュータ上での処理の動作に関する基礎知識である「デッドロック」について解説をします。

デッドロック/ deadlockとは

デッドロック(deadlock)とは、複数の資源を利用する、複数の処理(スレッドやプロセスなど)において処理が進まなくなってしまう問題のことです。それぞれの処理が互いに、他の処理が排他的に利用している資源(リソース)の開放を待つ状態となってしまい、どの処理も進まなくなってしまった状態のことを言います。
コンピュータを利用していて、アプリケーションが応答しなくなって「固まってしまう」ことがありますが、デッドロックが原因であることがあります。

デッドロックはどのようにして発生するか

デッドロックは、計算機科学(コンピュータサイエンス)で使われていることが多い言葉ですが、コンピュータに限らず「何かを実行する」状況において一般的に発生する問題です。そこで、日常的なタスクでの例にして、どういう状況で発生する問題なのか紹介します。

以下のような手順で実行する「野菜を切る」タスクがあったとします。

  • まな板を確保する
  • 包丁を確保する
  • 野菜を切る
  • 包丁を元に戻す
  • まな板を元に戻す

特にどうということはない作業手順だと思います。しかしこの手順で「Aさん」と「Bさん」が同じタイミングで野菜を切ろうとしたら、このようになってしまうことがあります。

Aさん Bさん
  • 手順書:まな板を確保する
    ⇒Aさんがまな板を確保
  • 手順書:包丁を確保する
    ⇒Bさんが先に確保したので使用中になっていて利用できない

「包丁が利用可能になるまで」待ち状態

  • 手順書:まな板を確保する
    ⇒まな板はAさんが使用中なので確保できない
  • 手順書:包丁を確保する
    ⇒Bさんが包丁を確保

「まな板が利用可能になるまで」待ち状態

 

こうなってしまったら、AさんもBさんも永久に待ち状態になってしまいます。このような状態のことをデッドロックと言います。先ほどの説明との関係では、「Aさん」と「Bさん」がプロセスやスレッドなどの「処理」に、「包丁」や「まな板」が排他的に利用する「資源」に相当します。

人間のAさんとBさんなら、こんな状態のままずっと待っているなんて間抜けなことは無いのですが、コンピュータプログラムは本当に指示されたことしかしないので、このような状態になると本当に処理が進まずに固まってしまいます。

デッドロックの対策

デッドロックにはいくつか起こりにくくする対策方法があります。以下、代表的なものをいくつか紹介します。

  • 資源を確保する順番を決める:
    上記の例では、必ず「まな板」を確保してから「包丁」を確保するように確保の順番をつけて、必ずその順番で資源を確保するようにする方法があります。
  • 処理に優先順位を決める:
    たとえばAさんをBさんより優先順位が高いことにするなど、処理間に優先順位の序列をつけ、AさんはBさんから資源を奪ってでも優先的に利用するルールにする方法があります。
  • 資源をひとまとめにする:
    「まな板」と「包丁」を別の資源にしているからデッドロックの問題が生じると考え、「まな板と包丁」で一つの資源にする方法があります。
  • 一定時間待ったらリソースを開放する:
    しばらく待っても待ち状態のままなら、一度自分が確保している資源を開放するルールにする方法があります。

しかし、全てのリソースの順番をつけることは容易ではありませんし、優先順位が低い人がいつまでたっても資源を利用できなくなることも起こりえます。資源を開放するルールも、複数の処理が資源を確保したり開放したりを永久に繰り返してしまう形で「処理が実質的に進まなくなってしまう」別の問題(ライブロック)を引き起こすことがあります。つまり、対策が別の問題を発生させてしまうことがあります。

資源を一つにする取り組みも、例えば「会社の備品全部を一つのリソース」にするとデッドロックは発生しなくなりますが、同時に一人しか働けない会社になってしまって非効率になるなど難しいところがあります。

残念ながら、簡単かつ万能なデッドロック対策はないので、普通にITシステムを作ればデッドロックを防止できるような状況にはなっていません。

対処が難しく、重大な問題にもなりうるデッドロック

「デッドロックが起こりうること」が見つけにくい

厄介なことにデッドロックは問題として発見しづらいことがあります。先ほどの例では、AさんとBさんが「たまたま同じタイミングで」野菜を切ろうと思ったときにしか問題は発生しません。処理タイミング次第で発生したりしなかったりする問題なので、ITシステムがデッドロックを発生しうるような作りになっていても、発見が難しかったり、問題が発生した場合でも原因の特定や発生した問題の再現が難しいことがあります。

厄介なタイミングで問題が発生することがある

処理のタイミング次第であるためデッドロック発生には偶然の要因があり、ずっと問題なく動作しているように見えていたが、稼働開始してからかなり経ってから問題が発覚することもあります。高負荷時に処理タイミングの衝突が起こりやすいため、年末の事務処理集中時期など、システムが固まってしまって困るまさにその状況でこそシステムが応答しなくなることもあります。

社会の安全安心確実を引き受けるITシステムにとって重大問題

PCを使っていて処理が固まってしまったら、しょうがないなあとは思いながら強制終了して再起動すれば済むこともありますが、処理が止まってしまっては困るITシステムが応答しなくなってしまうと大きな問題になることがあります。

銀行のシステムが応答しなくなって銀行振り込みが止まってしまったら大変な事件ですし、飛行機の飛行を制御するプログラムが応答しなくなってしまったら事故になります。デッドロックのような問題は、問題が起こってはいけないITシステムでは発生しないようにしなければいけません。

「ITシステムをきちんと作る」ニーズと、「内製化」のニーズ

昨今、内製化の取り組みが盛んです。変化や不確実性が大きくなり、ビジネスにかつてなく速度が求められる状況になった今、業務の現場が自らITを使いこなすことは、今後ますます求められるようになるでしょう。業務の現場が自らでクラウドを活用している組織も珍しくなくなってきました。

しかし、ビジネスに用いるITを自分たちで作るということは、デッドロックが一例となるような問題の対策も自分たちで行わなければいけないことになります。なんとなく作ったITシステム、エンジニアではないけれど頑張って作ったITシステムというのは、残念ながら問題を起こしてしまうことがあります。

  • 自分たちでデッドロックなどの問題を起こさないように、きちんと実装して内製する
  • 技術力のある外部に発注する(内製化を諦める)
  • デッドロックなどの問題を起こさないように整備されている基盤を活用して内製する

あなたが本業のITエンジニアであるならデッドロックについては当然に理解し、デッドロックが起こらないような実装をし、既存の実装に対してもデッドロックの問題を抱えていないか注意を払うべきで、つまりきちんと理解をしてきちんと作るべきです。

しかし内製化になると話が難しくなります。業務の現場の人たちが「うちのメンバーはデッドロックを起こさない実装くらいできるから大丈夫」のようなスキルまで身につけることは多くの場合現実的ではないでしょう。つまり、自分たち自身で「きっちり作りこむ」ことが難しくなります。

かといって、技術力のある外部に発注するのでは内製化を諦めることになり、昔と同じ状況に逆戻りです。

現実的には「きちんと作ってあるITシステム」を基盤として整備して、それを活用して内製化をするべきなのではないかと思います。その基盤自体でデッドロックなどの注意が必要な問題への対処や配慮がなされていれば、基盤を用いて内製化することで対処や配慮がなされたITシステムを作ることができるからです。

そのノーコード/ローコード製品、大丈夫ですか?

内製化の取り組みでは自社で本格的なプログラミングが行われていることは稀で、何かしらのSaaSの利用(kintoneやSalesforceなど)など、いわゆるノーコードやローコードの製品が、内製化の手段(ないしは基盤)として用いられていることが多いと思います。

それら製品には「簡単に使えるけれども簡易なことしかできない」ものがあります。簡単に作れても、本格的な実装ができずに作る必要があるものが作れなくなる、データ量が増えてきたら処理能力が不足して処理できなくなる、デッドロックで処理が固まってしまうなどで安定稼働しない、セキュリティの問題があっては、業務を任せられるITであるとは言えません。

残念ながら、ノーコードの製品やサービスには、一見今風のデザインの最新技術を用いたものに見えても、趣味のプログラミングと大差ないようなものもあったりします。

内製化に取り組むのであれば、きちんと業務を任せられるだけの安全安心確実な実績と機能を備えた、「プロユース」に適した製品を基盤として導入する必要があります。

  •  
  •  

「iPaaS」や「つなぐ」技術に興味がありますか?

「クラウド活用」「社内でのデータ活用」「業務の自動化」、これらをうまく進めるポイントは、自社で内製できる「データ連携基盤」を整備することです。

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は、各社の業務システムを支える基盤として長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無く、GUIだけ(ノーコード)で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

しかも、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤(プロフェッショナルユース)を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください:

 

用語集 コラム一覧

英数字・記号

あ行

か行

さ行

た行

な行

は行

ま行

や行

ら行

わ行

技術コラム一覧

おすすめコンテンツ

まずは無料で「つなぐ」をご体験ください

評価版ダウンロード

DataSpider Servistaのデータ連携を、まずはお確かめください。30日間無料でお試しいただけます。

無料体験セミナーに参加する

DataSpider Servistaの「つなぐ」を体験できる製品紹介・オンラインセミナーを開催しています。

Change Location

Are you visiting HULFT.com (Japanese language) outside Japan ?
When connecting "HULFT" to Japan from overseas, please select "HULFT8".

日本国外からHULFT.com(日本語)にアクセスされようとしています。
海外から日本の「HULFT」と接続する製品をお探しの場合、「HULFT8」をお選びください。