クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません!? データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > スポンサー広告 > クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません!?ホーム > アーキテクチャ > クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません!?

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

クラウドやマルチコアでの将来のボトルネックはきっとロック処理でしょう。コーディングが変わるかもしれません!?

「私はOSとストレージとネットワークに興味がある」という割には、そういう話題を書いていませんでした。今日はOSをテーマとして、将来のボトルネックという話を書いてみたいと思います。今回は難しい内容を簡単に説明できていないので、「分からなかった」というコメントが届いたら、丁寧に書き直したいと思います。

さて、「分散メモリー」という技術があります。いいですよね。クラウドコンピューティングは将来バラ色に見えます。

マルチコア化(クアッドだけではなく、8コアとか)も、いいですね。どんどん性能が上がるように思えます。

ここで質問です。クラウドコンピューティングやマルチコア化やグリッドやDBMSに共通する(はず)の将来のボトルネックってなんだと思いますか?
・・・それは”(厳密な)調整”機能だと私は思っています。

ここからの説明はちょっと遠回りになります。HPのコンパイラのサイトに、このような実験結果が載っています。あるDBMSにおけるCPU命令プロファイルの結果です。プロファイルから「何に時間がかかっているか」が分かります。
http://www.it-kiban.jp/hpux/developer/old/?column02/compiler_02/index.html

この結果からも分かるように、実はDBMSにおいて、CPUコアは頻繁にデータを捨てたり、ロードしたり、他のCPUと同期をとったりしなければいけません。理由は、「データベースが扱っているデータそのものは複数のCPUで同時に更新してはいけない」(図1参照)ことの他に、”DBMSの内部ロック命令そのものが、CPUのメモリ命令を使って実装されているから”(図2参照)です。

図1

図2


APサーバーを多数持つ、Webの大規模システムであっても、結局DBMSで排他制御のためのロックを実装しますよね。(参考:過去の記事「商用DBMSとオープンソースデータベースの差」)。
そのDBMSのロックは、最終的には、CPUの命令ベースのロック命令に行き着きます
#もし私の不勉強で他の実装を知らないだけの場合、教えていただけると助かります。
専門的に言うと、OSレベルではmutexなどです。それを支えるアセンブラの命令はCPUの種類によって異なりますが、CPU間でのメモリ同期と、メモリを使ったtest-and-setやcompare-and-swapなどです(詳細は内緒です)。これらの命令の特徴は成功か失敗のどちらかしかないことです(この特徴をAtomicと呼びます)。

ここまで読んで「マルチコアにおいて、DBMSは同時に処理できているではないか。」と思うかもしれませんが、CPUのメモリ処理で同期が必要なものは、メモリバリアとかメモリフェンスとか、そういうCPUの命令でCPU間で同期をとっています(図3参照)(とらないと最悪、ロックが壊れます)。これが”厳密な調整”機能の1つの例です。こういう、他のCPUコアを待たせるような処理は、コアや台数が増えれば増えるほど、ボトルネックとなっていきます。

図3


NUMA(複数CPUでメモリアクセスの速度が異なるアーキテクチャ、詳細は割愛)というアーキテクチャが出てきていますが、これは多くのCPUをまたがって、メモリアクセスの速度を保つのが困難になってきたからです。それほどCPU間やメモリの通信のレイテンシーは問題になってきています。

NUMAやマルチコアですら、通信の高速化が困難になってきているのに、理想のクラウド(※)はどう高速なロックを実装すればよいのでしょうか? 今後、マルチコアは進むはずですし、グリッドやクラウドはどんどん台数が増えていくはずです。ということで、将来、クラウド等の環境で超高速な処理をさせようとすると困るはずです。
※いつ、どこで実行されるかまで含めて自由なクラウドコンピューティングのことを、今回こう表現しています。

クラウドがダメと言っているわけではありません。クラウドは好きですし、今後も発展していくのだと思います。そこでソリューション案(予想)です。

●ソリューション案

そもそも、現実世界では、いろいろなものが自律的にバラバラに動いているわけで、それを決定論のように厳密に1つがコントロールする現状のコーディングでは、性能的に無理が出る時もあると思います。

CPUの命令レベルから、クラウドのレベルまで考えてみましたが、やはりこれ以上、コンピュータの性能を上げようと思うと、最初に書いた「厳密な調整」の能力に何らかの制限をつけるしかないと思います。ということは、「厳密な調整」が不十分であるというシステム(ひいては業務処理)というものが求められそうです

「別々にいい加減に処理する(最後につじつまあわせをする)」という「曖昧な調整」を行うコーディングがはやるかもしれません(個人的にはそうなると思っています)。例えば、在庫の管理もいい加減になり、「だいたいあと10個ね」とか、「だいたい売り切れね」というシステムが出てくるかもしれません。もしくは、あとから在庫調整(つじつま合わせ)をするDB群とか。なんだか面白そうですね。

前回の記事でも紹介した、ITアーキテクトのVOL19 のP23にグーグルのソフトウェアアーキテクトのホーペ氏の話は近い内容だと思います。
---------------------------引用ここから------------------------------
「クラウド・コンピューティングの世界は、非常に不確実性が高く、現状ではそれを解消する術はない」とホーペ氏は語る。そして、こうした状況下では、「エンジニアはソフトウェアに対する考え方を変えなければならない」というのがホーペ氏の主張だ。システムのすべてをコントロール可能だと考えるのではなく、偶発的に起こる事象に対して柔軟に対応できるように備えよというのである
---------------------------引用ここまで------------------------------

私はDBMSのCPUのロック命令から、この結論にたどり着きましたが、クラウドの専門家も同じような考えのようです。きっと、エンタープライズシステムの利用者もコンピュータに対する考えを変えなければいけなくなるんでしょう。特にバッチ処理の考え方(※)は変わらざるをえないはずです。
※:高速なCPUで処理をぶん回す発想のバッチ処理のことを指しています。

開発におけるモデリングも変わると思います。なんせ、コンピュータに「厳密」を期待できなくなる(かもしれない)のですから。

今回の内容は、突飛すぎたかもしれませんが、インフラのアーキテクトとして、自分なりの考えを書いてみました。楽しんでいただければ幸いです♪

スポンサーサイト
[ 2009/01/20 23:00 ] アーキテクチャ | TB(0) | CM(5)
図をクリックしても解像度が上がらず、読むのが少し厳しいです。。
[ 2009/01/18 22:44 ] [ 編集 ]
図の解像度の指摘、ありがとうございます。
ブログは不慣れなので、こういう指摘は助かります。
ちょっと試した結果、クリックによる拡大図の表示もできましたが、今回は大きな絵に差し替えてみました。
[ 2009/01/19 00:59 ] [ 編集 ]
こんばんわ、とても興味深く読ませて頂きました。
ロックの実装、最近だとOracleのmutex実装周りは、
私、興味があって仕方ない分野で。。。。

という話は、置いておいて、、、、


素人考えの疑問です。

今後さらにCPUのコアが増えていき、
グリッドを、ノードを増やしていくことによる
リソースプール という認識の下、
 ※↑この認識が誤ってたらごめんなさい。

 >他のCPUコアを待たせるような処理は、
 >コアや台数が増えれば増えるほど、
 >ボトルネックとなっていきます。

ここがなんとなくひっかかったんですよ。

台数(ノード数) が増えれば増えるほど、
mutexなりのCPUに近い部分のロック制御というよりは、
もっとアプリケーションに近いロック機構で
ボトルネックになりそうな
気がするんですよね。

 ※ノード間の通信が、今のInfinibandを
  もっと早く、メモリのオーバーヘッドも
  抑えるような仕組みがあったとしても。。

そう考えると、
 ● CPU間のロック処理 > ノード間のロック処理 
ってなるって、CPU間のロック処理が
ものすごいWaitにならないと、
実現しない気がするのですが、、、、、

ってのが、ちょっと疑問に思いました。
[ 2009/01/21 00:46 ] [ 編集 ]
お疲れ様です。

矢木さんの「アプリケーション」がDBMSのことも指すのであれば、そう思います。ノードをまたがって、DBMS同士の通信をする場合、ノードが増えるとロック処理と通信のレスポンスが限界になりやすいですよね。DBMSであろうが、どんな製品であろうが、結局はCPUの命令ベースのロック命令と通信のレスポンスに行きつきます。

次に、DBMSを除く、純粋なアプリケーションと仮定します。私はアプリケーション側でのボトルネックは、避けられるレベルの障壁だと思います。APサーバー同士の通信というのは、基本的にセッションオブジェクトなどに限られます。その他のデータについてはDBMSに依頼します。つまり、APサーバーは、DBサーバーにロックをかけて、APサーバー同士の排他制御をおこなうのがスマートです。(ということはDBMSで競合します)

例外は、APサーバーにインメモリDBなどを入れて、インメモリDB同士でデータのやりとりをする場合ですが、その場合は、インメモリDBとして、ロック競合が起きるので、RDBMSとほぼ同様のボトルネックとなります。

結局、DBMS同士が通信する場合にせよ、1つのDBMSが複数のノード上で動く場合にせよ、DBMSが複数のコアで動く場合にせよ、他のCPUコアをブロックするような内部の通信をしているようだと多重処理には限界があるとご理解いただければと思います。機会があれば直接説明します。

ちなみに、興味を持たれている、内部ロックというのは、いくつかのDBMSでは”ラッチ”と呼ばれています。ラッチに求められる要件は、アトミックなロックであることです(シンプルに実装すると、いくつかのCPUの命令で実装可能です)。
[ 2009/01/21 01:31 ] [ 編集 ]
小田さん、

回答ありがとうございました。

ご指摘の通り、そもそもDBMSを前提とした
疑問だったのですが、
純粋アプリケーション、グリッドという言葉を
使うならば、計算機グリッドになるでしょうか、
においてのCPUボトルネックは
記載頂いた通りかと思います。
 (高度に分散処理化されたアプリケーションで、
  かつ、コア増大によるボトルネック発生の前に、
  発熱の問題をクリアしている前提になると思いますが。)

あと、内部ロックの話ですが、
最近ではlatch実装がmutex実装に
変わってきていると認識していますが、、、、
 >(シンプルに実装すると、いくつかのCPUの命令で実装可能です)
  ↑
 こういう話、すごい好きなんですよね(^_^)
[ 2009/01/22 05:45 ] [ 編集 ]
コメントの投稿













管理者にだけ表示を許可する
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。