　より短期間に、より多く、そしてより品質の高い製品の開発を求められる製造業にとって、解析の重要度は増す一方である。富士通は、そのようなシビアな環境で解析業務を推進するエンジニアの環境を支援するため、ユーザーが「すぐに使えて」「すぐに効果の出せる」PCクラスタ環境や、既存のワークステーションへのアドオンでPCクラスタ環境が手に入るソリューションを提供してきている。このようにPCクラスタ導入の選択肢が広がったことで、解析がどのように効率化できるのか、その具体的な情報を耳にすることも増えてきているのではないだろうか。

　しかし、その一方でこれからPCクラスタ環境を解析に適用しようという担当者にとって、「一体どのような構成でシステムを導入すればいいのか」、あるいは「自分が行う解析業務に対して本当に効果を上げることができるのか」という疑問もあるはずだ。限られた予算の中で最大限の効果を出すためにも、「自分たちの解析業務に対して最適な構成を探したい」というのは当然のニーズである。そのようなユーザーニーズに対して富士通が提供するのが「Quick Start Suite」である。

適切にインフラを増強しないと効果は出ない

　コストを掛ければ、それ相応にシステム増強が可能だ。しかし、適切な形で増強をしなければ、コストを掛けた割に、「効果があまり見られない」ということも起こり得る。富士通プラットフォーム技術本部プロダクトソリューション技術統括部の津村昌祐氏は、「解析業務のスピードアップにつながる、ソフトウェアの性能を引き出すインフラ設計をすることが成功の鍵になります」と語る。

　津村氏は、解析時間の短縮につながるインフラ設計の留意点として、下記の4つのポイントを確認することが重要だと言う。

解析時間を短縮させるためのポイント

・CPU性能（コア数、周波数）	⇒	全体の実行時間に影響
・I/O（入出力）の性能（スループット）	⇒	全体の実行時間に影響
・メモリ性能（帯域幅）	⇒	ノード内の並列効率に影響
・ネットワーク性能（レイテンシ、帯域幅）	⇒	ノード間の並列効率に影響

　「さらに解析時間を短縮したい」「効率化を図りたい」というときに、「自分の環境におけるボトルネックは何か」ということを適切に判断できれば、どのように増強すればいいのかは、それで半ば判断できたようなものである。

　では、具体的にはどうすればいいのか。これまで富士通が検証してきた実例とともに改善のポイントを見ていきたい。

ケース1：サーバを増設しクラスタ化を進めたが解析の実行時間は短縮されない

　あるケースでは、解析の規模が大きくなってきたため、サーバの増強とシステムのクラスタ化を図った。それにもかかわらず、解析の実行時間が短縮されずせっかくの投資が効果につながらないという状況になっていた。

　よくよく検証してみると、実際には「CPUが性能の20％程度しか使えていない」という状況が確認された。そのときにネックになっていたのが、実は「サーバ間のネットワーク（インターコネクト）」であった。この企業ではサーバは増強したものの、インターコネクトは既存のイーサーネット（1Gbitイーサーネット）を使用していた。

　だが、結果的には性能が不十分で、CPUの使用率の低下につながっていた。これをInfiniBandに変えたところ、通信負荷が下がり、ユーザーのCPU使用率がほぼ100％となり、解析時間の大幅な短縮へつながった（図1）。

図1 イーサネットとInfiniBandのCPU使用率比較

　このケースでは、約5倍の性能の改善が実現したことから、適切なボトルネックの発見が重要といえよう。

　解析ソフトウェア「LS-DYNA」や「ANSYS Fluent」などの事例からも、コアの並列数が大きくなればなるほど、イーサネットでは性能が低下することが見て取れる（図2）。大規模な並列環境の場合には、通信負荷の問題は決して見過ごせないということを覚えておこう。

並列数と性能向上の関係

ケース2：「目に見えづらい」メモリバンド幅が解析効率を左右する

　普段はメモリのバンド幅（帯域）というものを意識することは少ないかもしれない。しかし、バンド幅に無自覚のまま並列数を上げていくと、実はその効率はある並列数で飽和してしまう。次の例は、プリント基板の熱流体解析のベンチマークテストを実施した際に、計算実行時間を速めようと実行並列数を8コアから12コアに増やしたにもかかわらず、全く速くならないという問題に直面したケースである。

　そのような場合には、メモリのバンド幅を確認することを考えたい。特にメモリ転送が大きい場合には要チェックである。このケースでは、専用ツールでチェックしたところ、実は8コアで既にメモリのバンド幅がピーク近くにあることが分かった（図3）。つまり、これ以上コア数を増やしても解析時間の短縮は見込めないということが言える。

図3 8コアで既にメモリ帯域幅がピーク近くに

　「バンド幅一杯にメモリアクセスを行っている場合、1マシン内で並列数を増やしても性能は向上しません。むしろ、同じ並列数でも実行ノード数を増やすなど、実行条件を変えていくほうが性能改善につながります」と津村氏は語る。このようなケースは流体解析や電磁場解析などで散見されることが多いようだ。

ケース3：解析時間の大半が実はファイルI/Oの時間

　ある企業では、「構造解析の実行に1日以上かかる」という状況が常態化しており、解析時間の大幅な短縮が大きな課題となっていた。この企業では、現在「1日以上かかる解析を半日にする」という目標はあったものの、並列数は決まっているため、どこを改善すればよいのかということが不明だった。

　津村氏は、「このような場合I/O処理に時間がかかっていないか、ということを確認することが重要です」と語る。この会社の構造解析では、まさにI/Oが効率化のボトルネックとなっていたことが分かった。

　図4に5つのシステム構成による実行時間の内訳が示されているが、一番右側の時間がI/Oの時間である。

図4 12並列で測定した例

　I/Oデバイスの変更で劇的に実行時間が短縮され、最大で3分の1以上短縮されていることが分かる。ユーザー時間（User Time）やシステム時間（System Time）以外の時間が多いのであれば、I/Oデバイスの見直しは非常に大きなポイントになるかもしれない。

　逆に、もし実行時間の内訳で既にI/Oの時間が非常に少ない場合には、I/Oデバイスを高速化してもあまり効率化には寄与しないとも言える。だからこそ、最初に「自分の環境における効率化のボトルネックはどこか」ということを見極めることが重要なのだ。

ISVとの協力体制によりソフトウェアの特徴を見極めたシステム提案

富士通プラットフォーム技術本部プロダクトソリューション技術統括部津村昌祐氏

　「どのようなシステムが最適か」ということはユーザーが「どのような解析ソフトを使って、どのような解析をするのか」ということにも依存する。そこで、富士通では、富士通トラステッド・クラウド・スクエア内に「PCクラスタ性能検証センター」を開設し、解析アプリケーションベンダーとの密接な協力体制の下、解析分野を中心として、これまでに12社16件の検証が実施されている。このような協力体制の下に、富士通ではアプリケーションに対する最適な実行環境を「おすすめ構成」として提案できるのだ。

　PCクラスタ性能検証センターは、主にアプリケーションベンダーによる検証目的に使用されることも多いが、マシンのリプレイス時における事前検証目的でも活用できる。もちろんセンターの利用は解析だけにはとどまらない。

　津村氏によれば、「今後は検証センターの活用を、解析だけでなく他業界にも広げていきたいと考えています。実際、生命科学の分野や金融系でのExcelのマクロによる処理の高速化、あるいはOSS系の検証も増えてきています」ということだ。


	関連リンク：
⇒	解析アプリケーション性能検証結果
⇒	富士通トラステッド・クラウド・スクエア

Quick Start Suiteが実現する最適な実行環境

　自社の環境を最適化するために、ボトルネックをしっかりと見極めることが重要であることは、認識できたにしても、実際に検証していくことは必ずしも容易なことではない。

　そこで、富士通では、これまでのPCクラスタのユーザー環境への適用の経験や、PCクラスタ性能検証センターでの経験をベースにした、おすすめ構成「Quick Start Suite」を提供している。これを活用することで自社の解析に対する最適な環境構築が可能である。現在提供されている構成は図5の通りだ。まずは、これをベースに富士通に確認していくことで、自社に最適な環境の構築がより容易となるはずだ。