E-MapReduce:クラスター管理に関する FAQ

EMR クラスターのアップグレード

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

EMR クラスターがサポートするサービス

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

コンソールでの Zeppelin の追加

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

EMR は Oozie とその代替手段をサポートしているか

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

HA クラスターにおける 3 台のマスターノードの理由

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

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

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

作成に失敗したクラスターのクリーンアップ方法

クラスター作成の失敗は、通常、デプロイ失敗につながる RDS の設定ミスや、一部の ECS インスタンスの在庫不足が原因です。

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

EMR のデプロイに失敗し、クラスターのステータスが「Unexpectedly Terminated」の場合は、リソースは作成されておらず、料金は発生しません。クラスターのアクション列にある 削除 をクリックして削除できます。

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

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

設定変更後のサービス再起動

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

ローリング再起動とは

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

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

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

デプロイメントセットを有効化すべきシナリオ

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

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

クラスターのスケールアウト時のデプロイメントセットの指定

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

クラスターのスケールアウト時のディスクサイズの指定

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

ディスクの拡張または縮小

拡張できるのはデータディスクのみです。データディスクを縮小したり、システムディスクのサイズを変更したりすることはできません。

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

クラスターのスケールアウトとスケールイン

はい。ただし、スケーリングのルールはノードタイプによって異なります。

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

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

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

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

エラー：スケールアウト時の「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 がプログラムへの影響を最小限に抑えるために、収集にポイントインタイムサンプリングを使用しているためです。特定のワークロードに対して、すべての推奨設定をテストおよび検証する必要があります。

エラー：スケールアウト時の「Insufficient ECS inventory」

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

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

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

エラー：クラスター作成時の「Insufficient ECS inventory」

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

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

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

不要なサービスの削除方法

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

クラスターノードへのログイン方法

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

インスタンスの vSwitch の表示方法

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

EMR クラスターの [Node Management] ページで、左側のノードグループリストからターゲットノードグループ (例：[emr-master]) を選択します。右側の詳細パネルで、[vSwitch] フィールドに vSwitch ID を表示できます。

大規模クラスターにおけるパケット損失の解決

• 症状：クラスターで頻繁にネットワークパケット損失が発生し、システムログに 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 コンソールで直接 [Redeploy] をクリックしないでください。

解決策：

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

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

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

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

     説明

     サブスクリプションの ECS インスタンスをリリースすると、ECS は返金額を計算して表示します。ご不明な点がある場合は、チケットを起票し、[Product] に [Elastic Compute Service] を選択してください。

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

クラウドディスクへのクラスター ID タグの自動追加

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

手順：

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

2. 左側メニューで、タグ > [Tag inheritance] を選択します。

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

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

4. [Enable and set rules] をクリックします。

5. タグの継承ルールを設定します。

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

   [Associated Resource Types] で [ECS Instance Disks] を選択し、その下に展開されたオプションから [All Tag Keys] を選択します。

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. 確認と操作が完了したら、クラスターの作成、スケールアウト、またはサービス設定の更新を再試行してください。

エラー：「Insufficient account balance」

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

  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 内部エンドポイントにアクセスできることを確認し、操作を再試行してください。