コンピューティングアーキテクチャを改善する

複数のEC2インスタンスで並列計算する既存システムがある。CPUとメモリには十分な余裕があるが、計算ノード間で大量のデータを交換する時間が処理時間の大部分を占めている。ノード間の低レイテンシーと高いネットワーク性能を優先する場合、最も直接的な改善はどれですか。

ステートレスなWebワークロードをAmazon EC2 Auto Scalingで運用している。必要なvCPU・メモリ・ネットワーク条件を満たせば、複数のインスタンスタイプを利用できる。現在は1種類だけを指定しており、一部アベイラビリティーゾーンで必要台数を確保できないことがある。最も適切な改善はどれですか。

一時的な大規模バッチ処理のため、複数のインスタンスタイプと複数のアベイラビリティーゾーンから大量のEC2キャパシティをまとめて取得したい。処理システム側でインスタンスのライフサイクルを管理するため、継続的なAuto Scalingグループによる管理は必要ない。最も適切な選択肢はどれですか。

Amazon EC2 Auto Scalingで属性ベースのインスタンスタイプ選択を利用し、候補となるインスタンスタイプを増やしたい。CPU性能を一定水準以上に維持するためパフォーマンス保護も使用するが、ワークロードには最低32GiBのメモリも必要である。最も適切な設計はどれですか。

分析サービスでは1回の要求を単一ワーカー内で処理し、処理中に最低72 GiBのメモリが必要である。現在のワーカーは64 GiBで、要求実行中にスワップが発生してレイテンシーKPIを外れている。要求内の処理は複数ワーカーへ分割できず、待ち行列による総処理能力不足もない。最も直接的な改善軸はどれですか。

密結合の並列処理を行うEC2ワークロードがある。ノード間通信のレイテンシーを下げる必要がある一方で、システム全体にはアベイラビリティーゾーン障害を考慮した可用性要件もある。この状況を設計するときの考え方として適切なものを2つ選択してください。

ステートレスなWebワーカーをAmazon EC2 Auto Scalingで運用しており、Mixed Instances Policyと属性ベースのインスタンスタイプ選択を利用している。現在は候補となる各インスタンスに最低32GiBのメモリを要求している。アプリケーション更新後、各ワーカーが正常に処理するための最低メモリ要件が64GiBへ増加した。需要変動へのAuto Scalingと、複数インスタンスタイプからキャパシティを確保する構成は維持したい。最も適切な変更はどれですか。