InfoQ

News

オピニオン:マルチプロセッサ・コンピューティングの課題は、単に技術的な問題の域を越える

作者 Sadek Drobi, 翻訳者 編集部 投稿日 2008年7月10日 午後12時32分

コミュニティ
Architecture
トピック
仮想化,
クラスタリング&キャッシング
タグ
Concurrency,
Parallel Programming

Peter Van Royは2008年のコンピュータ音楽国際会議(ICMC2008)で行った意見表明の中で、マルチコア・プロセッサならびに疎結合システム(例:インターネット)の出現に関連した多数の問題を提議した。マルチコア・プロセッサと疎結合システムは、増加傾向にあるマルチプロセッサ・コンピューティングを支える2つの原動力である。各形態の同時処理コンピューティングがもたらす課題は、性質的にかなりの相違があるが、どちらの場合も単に技術的な問題を越えた域に及んでいる。

マルチコア・プロセッサ--すなわち、「残りのシステムへの相互接続を共用し、しばしばオンチップのキャッシュメモリも共有する」2つ以上の処理要素を結合したプロセッサ--のプログラミングに関しては、課題は純粋に社会学的であるとPeter Van Royは考えている。データフロー・プログラミングは「こうしたマシンをプログラムするための単純で、自然な、そして強力なアプローチ」だが、「競合条件を持たない確定的な同時処理は、逐次プログラムと同じぐらいプログラミングが容易であり、おまけとして並列プロセッサの利用までできる」。そのため、課題は新規の技術的な解決策を見つけることではなく、どちらかといえば既存の解決策を効率的に利用するべく「プログラマーを教育する」ことであり、MapReduceでデータフローの考え方を使っているGoogleの例に倣うことである。

しかし、Lambda the Ultimate上で(Peter Van Royに応答したMarijn Haverbekeは、マルチコアの同時処理向けには「利用可能な技術が多数存在し、文書化もされている」が、「特定の状況もしくはパフォーマンス要件が原因で、既存テクニックの域を越える必要が生じることが多々あり、なぜかというと、既存テクニックはどれも[…]すべての問題を解決するには普遍性やコンポーザビリティ、効率性、万能性に欠けるからだ」と強調する。

Peter Van Royは、自身がいっそう重要と考える疎結合システムのプログラミングについて、議論を続ける。「プロセッサ一式とそのプロセッサを結合するネットワーク」で構成されるこうしたシステムは、「分散型システムにつきものの次のような問題に直面する」。

- グローバル情報の欠如。すなわち、システムを全体として一つのビューに捉えているエージェントは皆無で、他のエージェントのアクションについてはメッセージングを通じてのみ情報を得ているという事実。

- 部分障害。すなわち、エージェントのひとつがシステムから抜けたり、奇妙な動作をし始めたりするという事実。

Van Royは、こうした問題は、「クロックの同期や分散スナップショット、フォルトトレランスなどといった」適切なアルゴリズムを使うことにより克服できる「低レベルの技術的問題」であると考えている。

しかし、疎結合システムはより高レベルの問題も抱えている。まず、P2Pのファイル共有で発生する矛盾する目標の問題で、「ただ乗り問題」と呼ばれることが多い。この問題を解決するには、「エージェントの目標がシステム全体の目標と重なる」ようにシステムを設計し、ただ乗りを阻止するようにしなければならない。この実現を支援するものとして、Van RoyはBitTorrentプロトコルとやツールを例として挙げている。もう一つの問題は突発的な動作、すなわち、システムのいかなる部分も共有していないのに、システム全体として表れる動作である。Van Royによれば、これはどちらかと言うと適切なツールと設計を役立てて活用できるチャンスとみなすべきである。たとえば、各Webページを真に受けていれば有用性や正当性、人気の評価は難しいが、GoogleのPageRankアルゴリズムでは複数のWebページから情報を抽出して評価に役立てている。

疎結合システムの設計に関する問題への対処としてPeter Van Royが提唱するのは、「各コンピューティングノードが他の全ノードからデフォルトで独立し、〔かつ〕アプリケーション全体を含有し、ノード間のコミュニケーションが皆無でも正常に機能する〔が〕、他ノードからの情報を利用可能な場合は利用できるような」非集中型のアーキテクチャである。Van Royは、システム分散によって発生した問題への対処として、こうした種類のアーキテクチャが有用であると考え、そのように構築されたツールを数例、提供している。

Scot JohnsonはVan Royの論文にLambda the Ultimate上で反応を示しているが、Johnsonによれば、「『疎結合』システムと『広く分散した』システムを大きく区別すべき」で、その理由は、「広く分散したシステムでは、さらに価値のある技術的パラメータ(バンド幅、待ち時間)ばかりでなく、悪意のあるエンティティや単一の管理ドメインは存在しない」とは想定できないため、「あらゆる種類の攻撃に対する防御を模索しなければならない」からである。Johnsonは続けて、システムをより多項目で分類することを提案しているが、この分類ではたとえば、決定性スケジューリング、トポロジー、マイグレーション、部分障害、グローバルコンセンサス(グローバル情報)、バンド幅、待ち時間などといった、一定の特徴を比較する。

原文はこちらです:http://www.infoq.com/news/2008/06/challenges-mulitple-processors

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。