EC2を使用する場合のインスタンスとコア

「中規模データ」プロジェクトと呼ばれることが多いものに取り組んで、4〜32コアのどこでも単一のシステムでコードを並列化できました（主にPythonでのモデリングと予測）。現在、EC2上のクラスターへのスケールアップを検討しており（おそらくStarCluster / IPythonを使用していますが、他の提案も受け入れています）、インスタンス上のクラスターとインスタンス上のコアに分散する作業を調整する方法に困惑しています。

インスタンス間および各インスタンスのコア間で並列化することは実際的ですか？もしそうなら、誰もがコアの少ないインスタンス対コアの多いインスタンスをいくつか実行することの長所と短所を簡単に説明できますか？インスタンスごとのコアに対するインスタンスの適切な比率を選択するための経験則はありますか？

帯域幅とRAMは私のプロジェクトでは些細な問題ではありませんが、それらがボトルネックになっていて再調整するのは簡単です。繰り返しテストすることなく、コアの適切な組み合わせをインスタンスにベンチマークすることは非常に難しく、単一のテストをすべての状況に適用するにはプロジェクトがあまりにも多様です。事前に感謝します。これを適切にグーグルで検索できなかった場合は、他の場所で正しい答えを教えてください。

IPythonを使用する場合、それを心配する必要はほとんどありません（効率の低下/通信オーバーヘッドの増加を犠牲にします）。StarClusterの並列IPythonプラグインは、デフォルトで各ノードの物理コアごとに1つのエンジンを起動します（これは構成可能ですが、どこで実行されるかはわかりません）。DirectView API（map_sync、apply_sync、...）または％pxマジックコマンドを使用して、すべてのエンジンで必要なものを実行するだけです。すでに1台のマシンでIPythonを並行して使用している場合、クラスターでIPythonを使用することも同じです。

特定の質問に対処する：

「インスタンスのコアとクラスターのインスタンス間での作業の分散を調整する方法」-コアごとに少なくとも1つのエンジンを取得します。作業はすべてのコアおよびすべてのインスタンスに自動的に分散されます。

「インスタンス間および各インスタンスのコア間で並列化することは実際的ですか？」-はい:)実行しているコードが恥ずかしいほど並列（複数のデータセットでまったく同じアルゴリズム）である場合、特定のエンジンが実行されている場所はほとんど無視できます。コアがエンジン間で多くの通信を必要とする場合、もちろん、エンジンが同じ物理マシン上の他のエンジンと主に通信するようにコアを構成する必要があります。しかし、この種の問題はIPythonには理想的ではないと思います。

「もしそうなら、誰もがコア数の少ないインスタンス対コア数の多いインスタンスをそれぞれ実行することの長所と短所を簡単に説明できますか。インスタンスごとのコアに対するインスタンスの適切な比率を選択するための経験則はありますか？ 」-計算限界には最大のc3インスタンスを使用し、メモリー帯域幅限界の問題には最小のc3インスタンスを使用します。メッセージ受け渡し問題の場合も、最大のインスタンスを使用しますが、各パーティションが1つの物理マシンで実行され、ほとんどのメッセージ受け渡しが同じパーティション内に収まるように、問題をパーティション分割します。2N double c3よりもN quadruple c3インスタンスで大幅に遅くなる問題はまれです（人工的な例は、多数の画像で複数の単純なフィルターを実行する場合があります。同じ画像）。

一般的な経験則は、必要になるまで配布しないことです。通常、容量が半分の2Nサーバーよりも、特定の容量のNサーバーを使用する方が効率的です。データアクセスの多くはローカルで行われるため、ネットワーク全体の速度が遅いのに対し、メモリの速度は速くなります。

特定の時点で、追加のリソースのコストが線形よりも大きくなるため、1台のマシンをスケールアップすると不経済になります。しかし、この点はまだ驚くほど高いです。

ただし、特にAmazonでは、スポットマーケットインスタンスを使用している場合、各インスタンスタイプの経済性は大きく異なる可能性があります。デフォルトの価格設定は、インスタンスの種類に関係なく、同じ量のリソースコストがほぼ同じであることを意味します。大きなインスタンスは小さなインスタンスよりも安くなるか、N個の小さなインスタンスは同等のリソースを備えた1つの大きなマシンよりもはるかに安くなります。

ここでの大きな考慮事項の1つは、1台のマシンから複数のマシンに移動すると、計算のパラダイムが大きく変わる可能性があることです。通信オーバーヘッドが引き起こすトレードオフにより、たとえば、データ並列パラダイムを採用してスケールする必要が生じる場合があります。これは、ツールとアルゴリズムの異なる選択を意味します。たとえば、SGDのインメモリとPythonの外観は、MapReduceとは大きく異なります。そのため、並列化する前にこれを考慮する必要があります。

信頼性のために、単一ノードと非分散パラダイムが機能する場合でも、クラスター全体に作業を分散することを選択できます。単一のノードに障害が発生すると、すべての計算が失われます。分散計算は、失われた計算の一部のみを回復して完了する可能性があります。

すべてのものが等しいと見なされます（コスト、CPUパフォーマンスなど）。すべてのデータセットをメモリに保持してスケールアウトできる最小のインスタンスを選択できます。そのように

• ネットワーク通信のために不要なレイテンシーを誘発しないようにします。
• プロセスで使用可能なメモリ帯域幅全体を最大化する傾向があります。

何らかのメタパラメーターを最適化するために、ある種の相互検証スキームを実行していると仮定しますモデルの、各コアにテストする値を割り当て、必要に応じて多くのインスタンスを選択して、適切な数回のラウンドですべてのパラメータースペースをカバーします。

データが1つのシステムのメモリに収まらない場合は、当然、インスタンス間で分散する必要があります。次に、メモリレイテンシ（多くのインスタンスでより良い）とネットワークレイテンシ（より少ないインスタンスでより良い）のバランスをとることが重要ですが、EC2の性質を考えると、多くの場合、脂肪の少ないインスタンスで作業することを選ぶでしょう。