![背景 ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (12)
Ähnlich wie 遊休リソースを用いた 相同性検索処理の並列化とその評価
Ähnlich wie 遊休リソースを用いた 相同性検索処理の並列化とその評価 (20)
Mehr von Satoshi Nagayasu
Mehr von Satoshi Nagayasu (12)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
遊休リソースを用いた 相同性検索処理の並列化とその評価
- 1. 遊休リソースを用いた 相同性検索処理の並列化とその評価 慶應義塾大学大学院 政策・メディア研究科 永安 悟史
- 14. NFS v.s. Local storage
- 23. p-BLAST 設計（ BLAST 処理） Command Execution Master Node Frontend Clinet Command Execution Command Execution Planner Executor Request Divider Merger Result Application Specific Routines
- 25. 実験と評価
- 27. mpiBLAST local stoarge local stoarge local stoarge local stoarge shared stoarge (2) slave start (2) slave start (2) slave start (2) slave start (3) job assign (3) job assign (3) job assign (3) job assign (5) search (5) search (5) search (5) search (4) data copy (4) data copy (4) data copy (4) data copy (1) Query (7) Result (6)Results
- 44. Physical I/O v.s. Memory cache
- 50. End
Hinweis der Redaktion
- 遊休リソースを用いた相同性検索処理の並列化とその評価ということで発表させていただきます。政策メディア研究科二年の永安悟史です。
- 最初に本研究の背景について簡単に述べさせていただきます。 近年、ＣＰＵやメモリ、ネットワークやストレージなど、ＰＣやワークステーションを構成する要素のパフォーマンス向上が目覚しく、その結果、極めて性能のよい計算資源がコモディティ化してきています。 その結果、従来はスーパーコンピュータなどを用いて計算していた自然科学や工学などにおける大規模な演算処理、こういった演算処理のことをハイパフォーマンスコンピューティング、略してＨＰＣと呼びますが、これら性能の向上したＰＣ向けのパーツや、あるいはＰＣそのものを用いたクラスタシステムを用いて行うケースが増えてきています。
- 一方、近年バイオサイエンスの分野でも特に注目を集めている、遺伝子情報解析や細胞シミュレーションなどを行うバイオインフォマティクスの分野では、データ量の増大に伴って、膨大な計算資源を必要としています。 そのため、ＰＣクラスタなど、従来と比べるとコストパフォーマンスの高いハードウェアを用いた計算を行うわけですが、特に扱うデータ量が多くなればなるほど、ストレージなどにおけるＩ／Ｏにボトルネックが集中する形となってしまいます。このことによって、ハードウェアの性能を十分に引き出せない、という状況が発生しています。これに関しては、また後ほど詳しく述べたいと思います。
- そこで、本研究におけるモチベーションですが、現在存在している計算資源、ＰＣやワークステーションなどを、もっと有効に利用できるのではないか、バイオインフォマティクスなどにおける大量データ処理などに有効に使えるのではないか、と考えました。 具体的には、ユーザーが利用していないデスクトップ PC などの CPU 時間を使って分散処理をさせる「遊休リソースコンピューティング」の手法と、 PC クラスタなど、比較的密な環境において利用されている PC クラスタ用 HPC アプリケーションをハイブリッド化することで、計算処理専用に設計された PC クラスタなどではない、デスクトップ PC から、大規模な演算処理の性能を引き出せるのではないかと考えました。 そして、実際に、そのようなシステムでどの程度のパフォーマンスを得ることができるのか、また、どのような制約があって、何を考慮する必要があるのか、といったことを明らかにしたいと考えました。
- そこで具体的な本研究の目的ですが、遊休リソースコンピューティングと、 PC クラスタなどの HPC アプリケーションをハイブリッド化したシステムを設計、実装し、パフォーマンス、スケーラビリティの評価を、既存の分散技術と比較することとしました。 利用するアプリケーションに関しては、バイオインフォマティクスで利用されているアプリケーションを用います。その理由は、処理するデータサイズが大きいこと、またアプリケーションが比較的シンプルであることが挙げられます。 これらの実証や評価を行うことによって、遊休リソースを用いたコンピューティング、つまりコモディティ化したハードウェア資源のパフォーマンスを最大限有効に利用するための、パフォーマンスやスケーラビリティについての知見が得られるものと考えております。
- 実証実験の手法ですが、今回はサンプルアプリケーションとして、バイオインフォマティクスの分野でもっともよく使われているアプリケーションのひとつである BLAST を用いることにしました。理由としましては、非常によく使われているということに加えて、比較評価することができる並列分散の実装、 mpiBLAST が存在していることが挙げられます。 BLAST および mpiBLAST につきましては、このあと説明させていただきます。 実験には、特別教室の FreeBSD マシンを使用する予定です。遊休リソースを用いる実験ですので、基本的には使っているユーザーには影響はなく、日中や夜間など、使われているマシンの数などによって、パフォーマンスがどのように変わってくるのかなどを検証したいと考えています。 実験の評価ポイントですが、スケーラビリティ、ノード数やデータ量などを増やした場合にどの程度パフォーマンスが上がるのか、レスポンスタイムやスループットなどを評価しようと考えています。
- 実際に BLAST ではどのような処理を行っているかについてですが、遺伝子データベースでは標準的な FASTA 形式、これはスライドの右側にあるようなフラットテキストのファイルですが、これを formatdb というコマンドを使って、 BLAST 形式のデータ形式に変換します。 そして、そのデータを用いて、ユーザーの検索したいクエリを検索し、ある一定以上のスコアを持つものを結果として出力します。 このデータベースは、ヒトゲノムデータの場合は 3GB 程度、さまざまな生物種のデータを統合したファイルの場合、現在のところ 10GB 程度となっています。 処理時間に関しましては、検索するクエリのサイズや数、データベースのサイズにもよりますが、バイオインフォマティシャンが網羅的な解析を行うような場合には、数時間から数日以上かかるような場合があります。ですから、この時間を何とか短縮したいというモチベーションがあるわけです。
- コンピュータシステムとして BLAST の処理内容を見てみると、検索するクエリが長い場合には、先ほどの類似度の計算などに時間がかかりますから、比較的 CPU を多く使う処理となります。 一方、検索するためのクエリの数が多い場合には、同じデータベースに何度も何度も少しずつ違うデータで検索をかけたりしますので、比較的 I/O 処理が多くなります。 このような特徴があるため、分散処理の評価サンプルとして適していると判断しました。
- 遊休リソースコンピューティング、あるいは並列化 BLAST という観点から関連研究が存在します。遊休リソースコンピューティングとしては、 [email_address] や [email_address] 、並列化 BLAST としては、 mpiBLAST や HyperBLAST といった実装が存在しています。
- 次に、既存の研究と、本研究の相違点について述べます。 インターネット上で分散して処理を行うものを、超分散遊休リソースコンピューティングとここでは呼びますが、既存のデータ解析を行うプロジェクトと比べて、 BLAST の場合にはデータベース検索ですので、反復処理、あるいは I/O 処理が非常に多く、分散化あるいは並列化した処理の独立性がさほど高くないという点が違いとなっています。 また、既存の並列化 BLAST は、すべて密に設計された PC クラスタを対象としており、 NFS などの技術を使っています。 よって、本研究では、従来広域分散で処理されていた遊休コンピューティングの手法を使い、 PC クラスタで実行されていたアプリケーションを、 LAN 内で分散して行わせ、その評価を行う、という点が、既存研究と違ってくることになります。
- 次に、このような大規模なデータ処理を要するアプリケーションの分散処理を実装するにあたって、どのような方式があるのかについて簡単に解説いたします。
- まずは、ディスク共有型です。これは、 NFS などの I/O サービスを提供するファイルサーバを設置し、各計算用のノードは、このファイルサーバを通してデータの読み書きを行います。 この方式のメリットは、比較的簡単に構築できることですが、反面、計算用ノードを増やすとファイルサーバに負荷が集中するため、より高価な機材へのリプレースや、管理コストの上昇、あるいはファイルサーバに問題が発生すれば、クラスタシステム全体の性能や信頼性の低下といった状況を招くことになります。
- 例えば、簡単なベンチマークを行ってみますと、ファイルサーバに置いてあるファイルをクライアントから一斉に読み出すといった場合、ノード数が増えるに従ってパフォーマンスが大きく低下します。この例ですと、 10 ノードを越えたあたりから急激にパフォーマンスが低下しているのが分かります。つまり、ファイルサーバの処理能力の限界まで達したため、これ以上計算用のノードを増やしたとしてもトータルとしてのパフォーマンスの向上はあまり見込めないということになります。
- お示ししているスライドは、 NFS 上で BLAST 処理を実行した場合、およびローカルディスク上で BLAST を実行した場合の、 CPU 利用率および実行時間の計測結果です。 比較すると歴然としているように、 NFS を用いた場合、ローカルディスク上で BLAST を実行するのに比べて、このケースですと 3 倍程度の時間がかかっています。 ローカルディスク上で BLAST を実行した場合と比べて、 CPU 利用率、ユーザーの利用率ですが、これが 1/3 程度となっており、 I/O 、つまり NFS が BLAST 処理に対して大きくボトルネックになっていることがうかがえます。
- これらのことから、 BLAST 処理のパフォーマンスを十分に引き出すためには、従来の PC クラスタなどにおける「 CPU 、演算処理の並列化」だけではなく、 I/O 処理を並列化し、その処理時間を低減する必要があります。 そのためには、従来の NFS に依存したアーキテクチャではなく、ローカルのストレージを活用すること、また検索処理の並列化、つまり I/O 処理の並列化によって、検索処理全体の実行時間を低減することが求められます。
- そこで考えたのが、ディスク分散型のアプローチです。 ディスク分散型の手法では、大容量のデータを細かく分割した上で、複数の計算ノード上のディスクに配置します。また、それぞれの計算ノードで必要となるデータについては、近隣のノードから peer to peer で転送する形を取ります。 このようなアーキテクチャを取ることによって、計算用のノードを増やしても、ファイルサーバに対して過大な負荷がかかるという事態を避けられ、またキャッシュの配置に冗長性を持たせることによって、同じデータに対するリクエストの負荷も分散することが可能になります。 今回は遊休リソースを用いる形になりますので、単に分割配置するだけではなく、ロードアベレージの把握、管理や、負荷の高い計算ノードから低いノードへのキャッシュの転送などといったことも考慮する必要が出てきます。
- 次に、このような大規模なデータ処理を要するアプリケーションの分散処理を実装するにあたって、どのような方式があるのかについて簡単に解説いたします。
- このディスク分散のアプローチを用いて、並列化 BLAST 、 p-BLAST を設計しました。
- p-BLAST では、フラットなネットワークにおいて、フロントエンド、マスターノード、および複数のクライアントノードから構成されます。 フロントエンドは、実際にユーザーがプログラムを操作する端末で、マスターノードへリクエストを送ります。 マスターノードは、フロントエンドからの要求を処理し、必要に応じて分割してクライアントへ渡し、その結果をマージしてフロントエンドに返します。 クライアントノードでは、マスターノードから受け取ったタスクの処理や、およびクライアントノード同士のファイルの転送、クライアントノードの状態変化をマスターノードへの通知などを行います。
- 最後に、具体的な評価項目ですが、分散処理ですので、ノード数やデータベースサイズとスケーラビリティ、またクエリ配列のサイズによるパフォーマンスの評価、ファイルサーバの I/O 処理量や、単一リクエストのレスポンスタイム、複数のリクエストの多重処理能力、スループットなどを評価ポイントとする予定です。