E-MapReduce:クラスター管理に関するよくある質問

EMR クラスターはアップグレードできますか？

いいえ。EMR クラスターやそのサービスをアップグレードすることはできません。新しいバージョンを使用するには、既存のクラスターをリリースし、新しいクラスターを作成してください。

EMR クラスターはどのサービスをサポートしていますか？

サポートされるサービスは、クラスターのタイプとバージョンによって異なります。詳細については、「リリースバージョン」をご参照ください。

コンソールで Zeppelin を追加できますか？

いいえ。EMR コンソールから新しいサービスとして Zeppelin を追加することはできません。Zeppelin を追加するには、いずれかのマスターノードの Elastic Compute Service (ECS) インスタンスにインストールしてください。また、他のコンポーネントを ECS インスタンスに手動でインストールして維持することもできます。さまざまなタイプのクラスターに追加できるサービスについては、「サービスの追加」をご参照ください。

EMR は Oozie とその代替サービスをサポートしていますか？

Oozie コンポーネントは、EMR V5.8.0 以降または EMR V3.42.0 以降を実行する EMR DataLake クラスターには含まれていません。ワークフロースケジューリングサービスが必要な場合は、EMR Workflow を使用できます。詳細については、「EMR Workflow とは」をご参照ください。

高可用性クラスターにマスターノードが 3 台ある理由は何ですか？

新しい EMR 高可用性クラスターでは、2 台のマスターノード構成よりも高い信頼性を実現するために、3 台のマスターノードを使用します。2 台のマスターノード構成はサポートされなくなり、マスターノードグループをスケールインすることはできません。これらのクラスターでは、EMR は障害のリスクを軽減するために、マスターノードを異なる物理ホストに分散させます。

データディスク暗号化の有効化とその効果

データディスクの暗号化を有効にすると、データは転送中および保存中の両方で暗号化されます。この機能は、セキュリティとコンプライアンスの要件を満たすのに役立ちます。データディスクの暗号化は、ECS インスタンスの OS レイヤーのアプリケーションに対して透過的であり、ジョブの実行には影響しません。

作成に失敗したクラスターをクリーンアップするにはどうすればよいですか？

クラスターの作成に失敗する主な原因は、RDS の構成が正しくないことによるデプロイメントの失敗、または一部の ECS インスタンスの在庫不足です。

一部の ECS インスタンスは作成されたものの、クラスターのステータスが「起動失敗」の場合は、ECS コンソールでインスタンスをリリースしてください。すべてのインスタンスがリリースされると、EMR クラスターは自動的にリリースされます。

EMR デプロイメントが失敗し、クラスターのステータスが「予期せず終了」になった場合、リソースは作成されず、料金は発生しません。クラスターの「操作」列で削除をクリックして、それを削除できます。

既存のクラスターへのサービスの追加

はい。クラスターの作成後にサービスを追加できます。詳細については、「サービスの追加」をご参照ください。

構成変更後のサービスの再起動

Spark、Hive、HDFS などのサービスのサーバー側の設定変更は、サービスを再起動した後にのみ反映されます。クライアント側の設定変更は、サービスを再起動する必要なく、Deploy Client Configuration をクリックした後に反映されます。詳細については、「設定項目の管理」をご参照ください。

ローリングリスタートとは何ですか？

ローリングリスタートのメカニズムでは、ECS インスタンスが 1 台ずつ再起動されます。次のインスタンスは、現在のインスタンスとそのすべてのサービスが完全に復旧した後にのみ再起動されます。各ノードの再起動には約 5 分かかります。

既存のクラスターへのパブリック IP の関連付け

EIP アドレス (EIP) をリクエストし、パブリック IP アドレスを持たない Virtual Private Cloud (VPC) 内の ECS インスタンスに関連付けることができます。これにより、ECS インスタンスはインターネット経由でアクセスできるようになります。詳細については、「EIP の関連付け」をご参照ください。

デプロイメントセットはどのような場合に有効にすべきですか？

デプロイメントセットは、ECS インスタンスの分散戦略を制御する ECS の機能です。データセキュリティを向上させるために、ローカルディスクを使用するインスタンスタイプを持つコアノードグループに対してデプロイメントセット機能を有効にすることを推奨します。デプロイメントセットは、複数の ECS インスタンスが同じ物理ホストにデプロイされるのを防ぎます。これにより、単一障害点を回避し、物理ホストに障害が発生した場合の EMR 上のローカル HDFS データの損失を防ぐのに役立ちます。

ECS デプロイメントセットの制限により、デプロイメントセットに追加できる ECS インスタンスは最大 20 台です。詳細については、「デプロイメントセットを有効にする」をご参照ください。

クラスターのスケールアウト時にデプロイメントセットを指定するにはどうすればよいですか？

デフォルトでは、デプロイメントセットはローカルディスクを持つインスタンスタイプに対して有効になり、他のインスタンスタイプに対しては無効になります。この設定は必要に応じて調整できます。デプロイメントセットを有効にする方法については、「デプロイメントセットを有効にする」をご参照ください。

クラスターのスケールアウト時にディスクサイズを指定するにはどうすればよいですか？

クラスターをスケールアウトする際、新しいノードのディスクサイズはノードグループの設定によって決まります。このサイズはスケールアウトプロセス中に変更することはできません。必要に応じて、ノードグループのディスクサイズを調整できます。ディスクを拡張する方法については、「ディスクの拡張」をご参照ください。

ディスクの拡張または縮小はできますか？

データディスクの拡張のみ可能です。データディスクの縮小やシステムディスクのサイズ変更はできません。

対象のクラスターの Nodes タブで、対象のノードグループの Expand Disk をクリックしてデータディスクを拡張します。具体的な手順については、「ディスクの拡張」をご参照ください。

クラスターの水平スケーリング

はい、できますが、スケーリングルールはノードタイプによって異なります：

• スケールアウト：コアノードグループとタスクノードグループのみスケールアウトできます。新しいノードの構成は、デフォルトで既存のノードと同じです。スケールアウトする前に、関連するすべての注文が支払われていることを確認してください。未払いの注文があると、スケールアウト操作は失敗します。具体的な手順については、「クラスターのスケールアウト」をご参照ください。

• スケールイン：マスターノードグループはスケールインをサポートしていません。他のノードグループのルールはタイプによって異なります：

  • 従量課金またはプリエンプティブルインスタンスのタスクノードグループ、および従量課金のゲートウェイノードグループについては、「クラスターのスケールイン」をご参照ください。

  • 従量課金のコアノードグループ、サブスクリプションのタスクノードグループ、およびサブスクリプションのコアノードグループについては、「ノードグループの手動スケールイン」をご参照ください。

スケールアウト時の「"AddNumber is not valid"」エラー

• 現象：クラスターのスケールアウト時に、エラーメッセージ The specified parameter AddNumber is not valid. add instances number :xxx larger than deploymentSet availableAmount: xxx deploymentSetId: ds-uf6gwfou0a13kekupt14xxxx が表示されます。

• 原因：このエラーは、クラスターでデプロイメントセット機能が有効になっており、ノードグループ内のノード数がデプロイメントセットの上限に達したことを示します。デプロイメントセットの詳細については、「デプロイメントセットを有効にする」をご参照ください。

• 解決策：ECS サポートに連絡して、アカウントのデプロイメントセットのクォータ引き上げをリクエストしてください。

サービスログの収集を停止するにはどうすればよいですか？

EMR によるデータ収集を希望しない場合は、サービス運用ログの収集を無効にできます。

手順：

1. サービス運用ログの収集を無効にします。

   • クラスター作成時: ソフトウェア構成ステップで、サービス運用ログの収集を許可する をクリックします。

   • クラスター作成後: 対象クラスターの 基本情報 ページの Software Information セクションで、サービス実行ログの収集ステータス をクリックします。

2. 収集が無効になっていることを確認します。

   /usr/local/ilogtail/user_log_config.json に namenode-log が存在するかどうかを確認します。存在しない場合、サービスログの収集は無効になっています。

   説明

   サービスログの収集を無効にした後、構成が同期されるまで約 2～3 分かかります。しばらくお待ちください。

サービス運用ログはどのような情報を収集しますか？

サービス運用ログには、クラスターの実行中のサービスコンポーネントからのログのみが含まれます。ワンクリックですべてのサービスログの収集を有効または無効にできます。ログ収集を無効にすると、クラスターのヘルスチェック機能とテクニカルサポートが制限されることにご注意ください。

どのクラスタータイプが EMR Doctor をサポートしていますか？

DataLake と Hadoop クラスタータイプのみがヘルスチェック機能をサポートしています。クラスターの作成後、EMR コンソールで対象クラスターの チェックの監視 > Health Check タブでこの機能を使用できます。

ご利用の Hadoop クラスターにこの機能がない場合は、EMR Doctor を有効にする必要があります。詳細については、「EMR Doctor を有効にする (Hadoop クラスター向け)」をご参照ください。

EMR Doctor のインストールまたはアップグレードの影響

EMR Doctor のインストールまたはアップグレードによって、サービスが再起動されたり、既存のジョブに影響が及んだりすることはありません。インストール後、EMR Doctor は既存のクラスターに必要なパラメーターを自動的に構成するため、手動で構成を行う必要はありません。

インストールまたはアップグレード中に、EMR Doctor は YARN、Spark、Tez、Hive サービスの構成をデプロイします。一部の構成を変更して保存したものの、まだデプロイしていない場合は、デプロイプロセスがサービスに影響しないことを確認してください。

EMR Doctor はどのデータを収集しますか？

EMR Doctor は、実際のデータを収集したり、ファイルやファイルの内容をスキャンしたりすることはありません。

EMR Doctor は、ジョブの開始時刻と終了時刻、メトリック、カウンターなど、必要なイベントデータのみを収集します。

EMR Doctor は無料ですか？

はい。EMR Doctor は現在無料でご利用いただけます。

データ収集はジョブの実行にどのように影響しますか？

EMR Doctor のストレージメタデータ収集は、ユーザーリソースに基づいて収集に使用されるリソースを動的に調整し、過剰なリソースを消費しません。

EMR Doctor のジョブ収集は Java プローブ技術を使用しており、モニタリングのために別の Java プロセスを開始しません。収集は非同期で実行され、メインのジョブプロセスをブロックしません。収集のオーバーヘッドが高くなりすぎた場合、EMR Doctor は自動的にデータを破棄します。収集頻度などのパラメーターを調整することもできます。

収集レポートはいつ利用可能になりますか？

EMR Doctor のインストールまたはアップグレード後、日次レポート機能は、実行したジョブとストレージメタデータが収集されたかどうかに基づいてデータを分析します。したがって、クラスターにはアクティブなワークロードが必要です。

• コンピューティングジョブ：クラスター上のコンピューティングジョブが収集された後、最新のレポートは翌日利用可能になります。レポートは、前日のジョブ実行状況の分析に基づいて、クラスターの評価と推奨事項を提供します。

• ストレージ分析：EMR Doctor はデフォルトではストレージ分析を有効にしません。手動で有効にすることができます。有効にすると、収集は通常午前 10 時頃に実行されます。収集が完了すると、分析が実行され、翌日の早朝にレポートが生成されます。午後に収集を有効にした場合、結果が表示されるまで 3 日目まで待つ必要があります。

推奨構成の具体的な値

EMR Doctor は、メモリ構成の削減や GC パラメーターの変更など、方向性を示す推奨事項を提供しますが、具体的なパラメーター値は提供しません。これは、EMR Doctor がプログラムへの影響を最小限に抑えるために、ポイントインタイムサンプリングで収集を行うためです。特定のワークロードに対して、推奨されるすべての構成をテストおよび検証する必要があります。

エラー: スケールアウト時の ECS 在庫不足

• 現象：クラスターのスケールアウトに失敗し、失敗理由が「Insufficient ECS inventory_OutofStock」または「Insufficient ECS inventory_OperationDenied.NoStock」と表示されます。

• 原因：スケールアウトしたいノードグループの ECS インスタンスタイプに、リクエストを満たすための在庫が不足しています。

• 解決策：必要な ECS インスタンスタイプの在庫が確保されるまで待ってから再度スケールアウトを試みるか、新しいノードグループを作成して別の ECS インスタンスタイプを選択してスケールアウトしてください。詳細については、「ノードグループの作成」をご参照ください。

クラスター作成時の「ECS 在庫不足」エラー

• 現象：クラスターの作成またはノードグループの追加に失敗し、失敗理由が「Insufficient ECS inventory_OutofStock」または「Insufficient ECS inventory_OperationDenied.NoStock」と表示されます。

• 原因：クラスターまたはノードグループに選択した ECS インスタンスタイプの在庫が不足しています。

• 解決策：クラスターを作成する際に、在庫が十分にあり、ビジネス要件を満たす別の ECS インスタンスタイプを選択してください。

不要なサービスを削除するにはどうすればよいですか？

クラスターから既存のサービスを削除することはできません。サービスが一度開始されると、コンソールや API を使用して削除することはできません。

クラスターノードにログインするにはどうすればよいですか？

EMR クラスターの作成後、クラスター作成時に設定したパスワードを使用してマスターノードにログインできます。他のノードへのログイン方法については、「クラスターの他のノードにログインする」をご参照ください。

インスタンスの vSwitch を表示するにはどうすればよいですか？

EMR on ECS では、vSwitch の情報はノードグループに関連付けられており、基本情報 ページで直接表示することはできません。Nodes ページに移動し、インスタンスが所属するノードグループの名前をクリックして、関連付けられた vSwitch の情報を表示します。

大規模クラスターでのパケット損失を解決するにはどうすればよいですか？

• 現象：クラスターで頻繁にネットワークパケット損失が発生し、システムログに neighbour: arp_cache: neighbor table overflow! のようなエラーメッセージが表示されることがあります。これは、アドレス解決プロトコル (ARP) キャッシュテーブルがいっぱいになり、IP アドレスと MAC アドレスのマッピングを管理できなくなり、ネットワークパフォーマンスの問題につながっていることを示します。

• 原因：大規模な分散システム、特に単一クラスターが 1,000 台以上のサーバーを超え、EMR-5.18.0 または EMR-3.52.0 (いずれも含まない) より前のバージョンを実行している場合、ネットワークの不安定性やパケット損失が発生することがあります。システムパラメーターを調整することで、ARP キャッシュ管理を最適化できます。

  ARP キャッシュは、IP アドレスと MAC アドレス間のマッピングを保存します。主要なパラメーターは次のとおりです：

  • net.ipv4.neigh.default.gc_thresh1：ARP キャッシュに保持するエントリの最小数。エントリ数がこの値を下回る場合、ガベージコレクションは実行されません。デフォルト値は 128 です。

  • net.ipv4.neigh.default.gc_thresh2：ARP キャッシュ内のエントリ数のソフトリミット。エントリ数がこの値を超えると、5 秒以内にガベージコレクションが実行されます。デフォルト値は 512 です。

  • net.ipv4.neigh.default.gc_thresh3：ARP キャッシュ内のエントリ数のハードリミット。デフォルト値は 1024 です。

  説明

  デフォルト値は、1,000 ノードを超えるクラスターには小さすぎるため、ネットワークのパケット損失や不安定性を引き起こす可能性があります。したがって、パラメーターを調整する必要があります。

• 解決策：

  1. /etc/sysctl.conf ファイルを編集し、次の内容を追加して ARP キャッシュ容量の上限を増やし、最大接続追跡値を最適化します。

     net.ipv4.neigh.default.gc_thresh1 = 512
     net.ipv4.neigh.default.gc_thresh2 = 2048
     net.ipv4.neigh.default.gc_thresh3 = 10240
     net.nf_conntrack_max = 524288

  2. sudo sysctl -p コマンドを実行して、新しい設定を適用します。

     説明

     sysctl -p コマンドを実行したときに sysctl: cannot stat /proc/sys/net/nf_conntrack_max: No such file or directory というエラーメッセージが表示された場合は、まず sudo modprobe nf_conntrack コマンドを実行して対応するモジュールをロードしてください。その後、sysctl -p コマンドを再度実行して構成を更新します。

SystemMaintenance.Redeploy イベントへの対応

ローカルディスクインスタンスで システムメンテナンスによるインスタンスの再デプロイ (SystemMaintenance.Redeploy) タイプのシステムイベントを受信した場合、Alibaba Cloud が ECS インスタンスの基盤となるホストで潜在的なソフトウェアまたはハードウェアの障害リスクを検出したことを示しています。このリスクにより、ECS インスタンスを再デプロイする必要があります。データ損失を避けるため、ECS コンソールで直接 [再デプロイ] をクリックしないでください。

解決策：

1. イベントの詳細を確認して、影響を受けるノードを特定します。

2. 障害のあるノードを含むノードグループで、スケールアウトして新しいノードを追加します。詳細については、「クラスターのスケールアウト」をご参照ください。

3. 障害のあるノードをスケールインします。

   • コアノードグループまたはサブスクリプションのタスクノードグループをスケールインするには、「ノードグループの手動スケールイン」をご参照ください。

     説明

     サブスクリプション ECS インスタンスをリリースすると、ECS が返金額を計算して表示します。 ご不明な点がある場合は、チケットを送信し、[製品] で [Elastic Compute Service] を選択します。

   • 従量課金のタスクノードグループをスケールインするには、「クラスターのスケールイン」をご参照ください。

クラウドディスクへのクラスター ID タグの自動付与

EMR クラスターの ECS インスタンスのクラウドディスクにクラスター ID を自動的にタグ付けするには、タグコンソールでタグの継承を有効にします。

手順：

1. タグコンソールにログインします。

2. 左側のナビゲーションウィンドウで、タグ > [タグの継承] を選択します。

3. 機能を有効にするための指示を読み、チェックボックスを選択してサービスリンクロールを作成します。

   タグの継承を有効にすると、システムは AliyunServiceRoleForTag という名前のサービスリンクロールを自動的に作成し、タグの継承に関連する操作を実行します。詳細については、「タグのサービスリンクロール」をご参照ください。

4. 有効にしてルールを設定 をクリックします。

5. タグの継承ルールを構成します。

   タグの継承をサポートするリソースに対して、継承するタグキーを指定します。すべてのタグキーを継承するか、特定のタグキーのみを継承するかを選択できます。

   

6. OK をクリックします。

タグ設定の詳細については、「タグの継承」をご参照ください。

エラー：IdempotentParameterMismatch

• 現象：クラスターのリリースや構成のアップグレードなどの操作を実行する際に、次のエラーメッセージが表示されることがあります。

• 原因：複数のリクエストで同じクライアントトークンが使用されました。

  The request uses the same client token as a previous, but non-identical request. Do not reuse a client token with different requests, unless the requests are identical.

• 解決策：操作がすでに進行中かどうかを確認してください。進行中の場合は、再度送信しないでください。そうでない場合は、コンソールのページをリフレッシュしてください。EMR コンソールは自動的に新しいクライアントトークンを生成します。

エラー：QuotaExceeded.PrivateIpAddress

• 現象：クラスターの作成またはスケールアウト時に、次のエラーメッセージが表示されることがあります。

  [QuotaExceeded.PrivateIpAddress] The specified VSwitch "vsw-xxxx" does not have enough IP addresses.

• 原因：選択した vSwitch に、クラスターの作成またはスケールアウトのリクエストを満たすのに十分な利用可能なプライベート IP アドレスがありません。

• 解決策：新しいノードグループを作成し、利用可能な IP アドレスが十分にある vSwitch を選択します。その後、クラスターの作成またはスケールアウト操作を再試行してください。

エラー：LostProxy

• 現象：クラスターの作成、スケールアウト、またはサービス構成の更新時に、「taihao-proxy disconnect」エラーが発生します。

• 原因：クラスターノード上の EMR 管理エージェント (プロキシ) が接続を失いました。

• 解決策：

  1. クラスターのステータスを確認し、ノードの問題を修正します。

     • 複数のノードが切断されている場合は、CPU とメモリのメトリックを確認してください。

       • CPU またはメモリ使用率が高い場合、クラスターは過負荷状態です。構成をアップグレードするか、クラスターをスケールアウトして負荷を軽減してください。

       • CPU とメモリ使用率が低い場合は、セキュリティグループの構成を確認して、ネットワーク通信が正常であることを確認してください。

     • 少数のノードのみが切断されている場合は、それらのノードの負荷を確認して、CPU またはメモリ使用率が 100% に達しているかどうかを判断します。負荷が高すぎる場合は、リソースを消費している異常なプロセスがないか確認してください。見つかった場合は、それらを終了し、ノードのステータスが正常に戻るかどうかを確認します。異常なプロセスが見つからない場合は、次の解決策を検討してください：

       • マスターノードの場合、CPU 消費量が高いプロセスを調査します。マスターノードのスペックをアップグレードするか、MASTER-EXTEND ノードを追加して負荷を分散させることができます。

       • マスターノード以外の場合、単一の ECS インスタンスが過負荷または応答しない場合は、問題のあるノードをデコミッションするか、新しいノードを追加できます。

         ノードにログインし、次のコマンドを実行してサービスを再起動します。

         service taihao-proxy restart

  2. 確認と操作が完了したら、クラスターの作成、スケールアウト、またはサービス構成の更新を再試行してください。

エラー: 「アカウント残高不足」

• 現象：クラスターの作成、スケールアウト、またはアップグレード時に、次のエラーメッセージが表示されます。

  InvalidAccountStatus.NotEnoughBalance Message: Your account does not have enough balance to order pay-as-you-go products. 

• 原因：アカウントの残高が不足しています。

• 解決策：アカウントの残高を確認し、必要なリソースのコストをカバーするのに十分であることを確認してください。残高が十分になったら、操作を再試行してください。

エラー: QuotaExceed.DiskCapacity

• 現象：クラスターのスケールアウトまたはディスクの拡張時に、次のエラーメッセージが表示されることがあります。

  [QuotaExceed.DiskCapacity] The used capacity of disk type has exceeded the quota in the zone,  quota check fail.

• 原因：インスタンスのディスククォータが上限に達しました。

• 解決策：指定されたディスクタイプの使用容量がアベイラビリティゾーンのクォータを超えました。クォータセンターに移動して、ディスク容量クォータの引き上げを照会および申請してください。

エラー: QuotaExceed.ElasticQuota

• 現象：クラスターの作成またはスケールアウト時に、次のエラーメッセージが表示されることがあります。

  QuotaExceed.ElasticQuota Message: The number of the specified ECS instances has exceeded the quota of the specified instance type. 

• 原因：ECS インスタンスのクォータに達しました。

• 解決策：別のインスタンスタイプを選択するか、インスタンスの数を減らして再試行してください。ECS コンソールまたはクォータセンターでクォータの引き上げをリクエストすることもできます。

ブートストラップアクションが失敗した場合はどうすればよいですか？

操作履歴で失敗したブートストラップアクションの実行ログを確認してください：

• ログに明確なエラーメッセージが含まれている場合は、エラーメッセージに基づいてブートストラップスクリプトを修正し、操作を再試行してください。

• ログにキーワード exitCode が含まれているが明確なエラーがない場合は、デバッグを改善するためにブートストラップスクリプトに詳細なログを追加し、操作を再試行してください。

• タスクがタイムアウトした場合、またはログに出力がない場合は、以下を確認してください：

  • ユーザーがブートストラップスクリプトが配置されている OSS バケットに対する読み取り権限を持っていることを確認してください。

  • ECS のネットワーク構成を確認して、OSS の内部エンドポイントにアクセスできることを確認し、操作を再試行してください。

EMR ゲートウェイから Spark ジョブを送信する際のエラー：SparkContext の初期化エラー