翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 自動スケーリングアプローチの選択
伸縮性は、Amazon EMR を使用する主な利点の 1 つです。リソースを自動的にスケーリングするには、主に 2 つのオプションがあります。
+ マネージドスケーリング
+ カスタムスケーリングポリシー
マネージドスケーリングまたはカスタム自動スケーリングポリシーのいずれかを使用すると、必要なリソースのみを使用するようにノードをスケールインおよびスケールアウトできます。スケールアウトは、容量を増やす必要がある場合にリソースを追加するために使用されます。スケールインすると、使用されていないリソースが削除され、コスト効率が向上します。Amazon EMR サービス内で、Amazon CloudWatch メトリクスは リソースのモニタリングを有効にして、クラスターをスケールできるようにします。CloudWatch は 5 分ごとにデータポイントを受け取ります。
自動スケーリングアプローチごとに異なる考慮事項があります。
## Amazon EMR Managed Scaling
ワークロードが次の基準を満たしている場合は、[EMR マネージドスケーリング](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-console.html)を使用します。
+ マネージドエクスペリエンスが必要です。
+ Amazon EMR 5.330 以降が使用されます。
+ 1 分の評価頻度が必要です。
+ このソリューションでは、インスタンスフリートを使用して、1～5 つのインスタンスオプションがあります。
+ アプリケーションは、Apache Spark、Apache Hive、または Apache Hadoop YARN に基づいています。
## カスタム自動スケーリング
ワークロードが次の基準を満たしている場合は、[カスタム自動スケーリングポリシー](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html)を使用します。
+ スケーリングのメトリクスを制御する必要があります。
+ Amazon EMR 4.0\+ が使用されます。
+ 高い評価頻度は必要ありません。
+ 連続するサイズ変更間のクールダウン期間を制御する必要はありません。
+ スケーリング時に追加または削除するインスタンスの数を制御することが重要です。
+ このソリューションにはカスタムスケーリングアクションが必要です。たとえば、1 つの 5 分間に複数のノードをスケーリングできます。または、クールダウン期間を調整することもできます。
+ インスタンスグループで異なるインスタントタイプを使用することに制限はありません。
## クラスターに自動スケーリングを追加する際のヒント
+ 処理するデータの量に注意してください。データのサイズが最も大きいケースを使用して予測します。
+ クラスター[のサイズを適正](capacity.md)化します。
+ ニーズに合った[ストレージタイプ](storage.md)を選択します。
+ Amazon EMR クラスターの[メトリクス](https://docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html)を理解します。
+ クラスターをスケーリングするための[適切なメトリクス](https://aws.amazon.com/blogs/big-data/best-practices-for-resizing-and-automatic-scaling-in-amazon-emr/)を決定する方法を理解します。
+ スポットインスタンス、ユニフォームインスタンスグループ、またはインスタンスフリートのどちらを使用するかを決定します。
+ 情報と制限に基づいて、Amazon EMR マネージドスケーリングまたはカスタム自動スケーリングポリシーのスケーリングアプローチのタイプを決定します。
+ マネージドスケーリングまたはカスタムポリシーを設定します。
+ カスタム自動スケーリングポリシーを選択した場合は、Amazon EMR メトリクスをモニタリングしてポリシーのしきい値を調整します。