世界のスーパーコンピュータとそれを動かす人々


1月 15, 2018

MeltdownとSpectre用のパッチ、HPCワークロードへの影響

HPCwire Japan

Rosemary Francis

KPTI(別名KAISER)パッチと呼ばれるMeltdownおよびSpectreのセキュリティ脆弱性に対する修正は、アプリケーションのパフォーマンスに10〜30%影響を与えるとの主張がある。このパッチは、ユーザースペースからオペレーティングシステムへの呼び出しをはるかに重くするので、I / O集約型アプリケーションにとっては最悪の場合がありそうだ。これはHPCワークロードにとってどういう意味だろうか?

HPCにとって最適化は常に重要であるが、この新しいパッチはこの目標を動かしてしまった。アプリケーションのプロファイリングと、ディスク上やネットワーク上のデータへのアクセス方法は、最悪の問題がどのようなものになるかを把握する上で重要である。計算のオーバーヘッドの3分の1を失うということは分かりづらく恐ろしい見通しではあるが、これは完全にすべてが失われる状況ではない。

可能な限りパフォーマンスへの被害を軽減するために、ワークロードの次の側面を考慮することだ。

1.私たちのワークフローはサードパーティのツールを使用しています。この場合、何もできないのでしょうか?

サードパーティツールと社内のツールを組み合わせて使用するのは一般的である。社内アプリケーションの最適化はリソースの問題であるが、可能だ。サードパーティのツールにパフォーマンス上の問題がある場合は、オープンソースであっても、自分自身でやらなければならないことがよくある。

しかしながら、サードパーティのワークフローのパフォーマンスの低下を調査することは、まだ価値がある。ベンダーやユーザコミュニティにデータをフィードバックできるだけでなく、I / Oに影響を与えるプログラムが実行するやり方には常に変化があるのだ。たとえば、あなたは環境変数を使用してそのアプリケーションを設定しているのではないか?長いPATH変数や同様の設定により、アプリケーションは1回の実行で、何度もopen()やstat()呼び出しを失敗するファイルシステムを引き起こすことがあるのだ。

これらの失敗したI / Oコールや分散アクセスは、KPTIパッチをインストールする前でも共有ファイルシステムに問題を引き起こす。パッチが適用されると、それらの不必要なメタデータ操作の影響は、それらを実行するプログラムと、負荷の下で四苦八苦している共有ファイルシステムのために増加する可能性があるのだ。

したがって、ラッパースクリプトだけで実行するワークフローを持っていたり、一度でも更新することのないサードパーティのバイナリを1つでも持っていたとしたら、時間を費やしている場所を解決することは非常に良い考えだ。一時ファイルを共有ストレージからローカルストレージに移動するなどの単純な処理も、あなたに勝利をもたらす可能性がある。

2.ゲノム・パイプラインおよびその他の小ファイル系

ゲノムのパイプラインは、参照ゲノムに対してDNAセグメントをマッピングするために多数の小さなファイルを使用することでよく知られている。石油・ガス、EDA、財務などの他のHPCアプリケーションでも同じことだ。その理由の1つとしては、科学的に全く新しいソフトウェアを使用している場合には結果の妥当性を証明するのが難しいかもしれないが、これらのアプリケーションで使用されるアルゴリズムの制限でもあるため、従来の作業方法を尊重する必要があるからだ。

小さなファイルは必然的に小さなI / Oと多くのメタデータを意味するが、それより悪いことに、小さなファイルが小さなチャンクでアクセスされることが多くなり、さらに問題を悪化させている。なぜこれが問題なのだろうか?小さなI / Oは、システムのアーキテクチャに応じて、32KB未満のものと仮定してみよう。4KB未満のファイルは、解決できない問題として簡単に書き留めることができるが、4KB未満のブロックでデータにアクセスすると、必要以上に悪化する可能性がある。小さな書き込みごとにファイルを閉じるか、ファイルを開く前にすべてのファイルの存在をチェックすることで、セキュリティパッチのパフォーマンスへの影響も拡大するのだ。

小規模のI / Oは、小さなファイルを使用するアプリケーションに限定されない。未だプロファイリングされていない古いライブラリやコードは、小さな読み書きを実行するシステムコールを使用することがよくある。時には、1ギガバイトのデータが一度に1バイトずつ読み書きされることもある。この動作はほぼすべてのコンピューティング環境で非常に一般的であり、ローカルのパフォーマンスだけでなく共有ファイルシステムやデータベースにも致命的なものとなる。

3.パッチによって引き起こされるパフォーマンスの低下は、ローカルまたは共有ストレージに最も影響するか?

これまでの共有ファイルシステムへのパッチの影響に関する報告は良くはなかった。時間の経過とともに、ファイルシステムを管理している者は、新しいコンピューティング環境に基づいてパフォーマンスを向上させることができるが、パフォーマンスの低下を完全に免れることはできない。共有ストレージは、ほとんどのHPCクラスタおよびクラウド・インフラストラクチャの重要な部分である。リモートでアクセスした場合、ローカルストレージよりもパフォーマンスが低下するが、KPTIのパッチは両方のパフォーマンスに影響する。

ワークロードの中には、主に独自の動作やI / Oパターンによって速度が低下するものがある。これは共有ファイルシステムにとっては良いことだ。なぜなら、アクセスを抑制するものは、ファイルシステムが追いつくのにもう少し時間がかかるからである。

残念なことに、ローカルなパフォーマンスが悪いI / O集約型ワークロードは、ファイルシステムに最も打撃を与えるものであり、ファイルシステムの速度低下の影響を最も受けやすいものだ。パッチがクラスタとワークロードに及ぼす影響を知る唯一の方法は、パッチを試して測定することである。現代のHPCシステムの複雑さは、ある資源への影響が別の資源への影響を予測できないことだ。

4.私のアプリケーションはあまりI / Oをしないが、まだ心配する必要はあるだろうか?

KPTIパッチがI / Oパフォーマンスに及ぼす影響については多くが行われているが、影響はすべてのシステムコールで確認されるだろう。これは、gettimeofday()などの呼び出しがより高価になることを意味している。厳密なタイミング制約を持つアプリケーションは、そのような呼び出しをたくさん行い、少量のデータへのアクセスにおいてでさえも新しい遅延によって、うまく構築されないタイミング制約が破壊される可能性がある。

本当にファンシーなプログレスバーが必要なのだろうか? 将来、このような機能にはもっとたくさん対価をはらうことになるかもしれない。

5. MPI I / Oは良くなるのか、悪くなるのか?

HPCアプリケーションはPOSIX I / Oだけでははない。MPIライブラリは、データを共有したり、何千もの計算のランクにわたってアプリケーションを調整する一般的な方法である。すべてのMPIライブラリはPOSIX I / Oの下で使用されていることについては、おそらく多くの人には驚きではないだろうが、それが行っていることについては驚くかもしれない。

MPIライブラリは時間の経過と共に発展しており、同様の呼び出しは、小さなシステムコールにさまざまな依存性を持たせて非常に異なる実装を持つことができる。データの表や行列などの上位レベルの構造では、頻繁に非常に小さい読み取りや書き込みのアクセスが行われるので、小さなI / Oについて議論したい。

うれしいことに、多くのMPIライブラリはほとんどの場合バイナリ互換なので、パフォーマンスの問題が確認されたらライブラリを変更することは、他のタイプのI / Oを最適化するほど困難ではないが、制御が自分できなくなるかもしれない。

MPIライブラリを比較できるようなIORなどの人工的なベンチマークは、実際の作業負荷がベンチマークで強調されている規則的なI / Oと大きく異なるため、KPTIパッチの実際の影響について多くの知見を与えることはない。繰り返すが、実際のアプリケーションのプロファイルを作成するのは、どこで時間を費やしているかを調べる唯一の方法である。

6.ワークロードをクラウドに移動することで問題を逃れることはできるか?

残念ながら、仮想化されたワークロードは引き続きこの脆弱性の影響を受け、パッチを当てる必要がある。それはコンテナ化された作業負荷でも同じだ。

アプリケーションをクラウドに移行するには、通常、共有ストレージへの依存を減らし、利用可能な高性能で低コストのストレージオプションを利用するために、何らかのアーキテクチャの再構成が必要になる。アプリケーションがどのようにストレージを使用するかについて依存関係の場所を把握することは、このプロセスの一部であるため、KPTIパッチを最適化することは、将来を取り入れる作業の一環としてほぼ無償で提供される可能性がある。あるI / Oパターンはクラウド中で悪化するし、いくつかはより良くなるだろうが、MeltdownとSpectreについて知る前からそれは真実であった。

つまり、HPCアプリケーションはさまざまなレベルでパッチの影響を受けるのだ。明るいニュースは、リソースへのアクセスが可能な最適化作業によって、パフォーマンスへの影響を軽減できることである。サードパーティのツールやライブラリを使用していても、諦めるのはまだ早い。パフォーマンスを容易に向上できる余地があるかもしれない。

HPC業界がより多くのソリューションを提供するようになっても、状況はさらに複雑にならないことを祈ろう。ほとんどのHPCワークロードとシステムはすでに複雑であるため、修正プログラムのレイヤーを追加するのではなく、システムを簡素化して最適化するために行うことができれば、今後の成長には効果的だ。

著者について

Rosemary Francis博士は、I / Oプロファイリング会社Ellexuswww.ellexus.com)のCEO兼創業者です。 Ellexusは、ライブ・コンピューティング・クラスタ上で実行可能なアプリケーション・プロファイリングおよび監視ツールを作成して、不正なジョブやノイズの多い近隣プロセスから保護し、クラウドへの移行を容易にし、クラスタを迅速に拡張できるようにしている。 システムおよびストレージに依存しないツールは、アプリケーションとユーザが何をしているかを正確に把握してエンドツーエンドの可視性を提供します。 プログラムが何をしているのかに関するデータを提供するだけではありません。 これらのツールには、何がうまくいかないか、どのように修正できるかに関する専門知識が含まれています。