Azure HDInsight

解決する課題

Hadoop や Spark などのオープンソースのビッグデータ基盤を自前で構築すると、クラスタの設計・インストール・パッチ適用・スケーリングといった運用負荷が大きくなります。Azure HDInsight は、これらの OSS エコシステムをフルマネージドのクラスタとして提供し、インフラ運用を抑えつつ既存の Hadoop / Spark 資産を活かせるようにします。

• 既存の Hadoop / Spark / Hive エコシステム をそのままクラウドで動かしたい
• クラスタの構築・パッチ・スケーリングといった OSS 運用の手間を減らしたい
• 大規模な バッチ ETL・対話型クエリ・ストリーミング を用途別のエンジンで使い分けたい
• データを ストレージに残したまま、必要なときだけ計算クラスタを立てたい
• オンプレミスの Hadoop 資産をクラウドへ移行 したい

AWS では Amazon EMR が近い役割を担います。HDInsight も EMR と同様に、OSS のディストリビューションをマネージドで提供し、計算とストレージを分離する設計です。

主要概念と用語

• クラスタ種別（Cluster Type）: 用途ごとに用意された構成。Hadoop、Spark、HBase、Kafka、Interactive Query などがある
• ヘッドノード（Head Node）: ジョブの管理・スケジューリングを担う制御用ノード。可用性のため通常2台構成
• ワーカーノード（Worker Node）: 実際のデータ処理を分散実行するノード。台数を増減してスケールする
• ゲートウェイノード（Gateway / ZooKeeper ノード）: 認証やクラスタ調整を担う補助ノード
• Apache Ambari: クラスタの構成管理・監視・運用を行う Web UI と管理ツール
• 既定のストレージ: クラスタが基盤とするデータ保管先。ADLS Gen2 または Blob Storage を指定する
• Interactive Query（LLAP）: Hive を常駐プロセスで高速化し、対話型クエリを低レイテンシで返す構成
• スクリプトアクション（Script Action）: クラスタの各ノードにカスタムスクリプトを適用し、追加コンポーネントを導入する仕組み
• エッジノード（Edge Node）: クライアントツールやアプリを置くための、ジョブ処理を担わない追加ノード

仕様・制限・クォータ

• クラスタは ヘッドノードとワーカーノード の VM 群で構成され、コストは台数と稼働時間に比例する
• 計算とストレージが分離 されており、データは ADLS Gen2 や Blob に置かれるため、クラスタを削除してもデータは残る
• クラスタ種別はおおむね 作成時に決まり、後から種別を変更するのではなく用途別に作り直す前提で考える
• ワーカーノードは スケールアウト/スケールイン に対応するが、種別や構成によって対応範囲が異なる
• 作成できるクラスタ数やノード数は、サブスクリプションの VM コア数クォータ に依存する
• 利用できる OSS のバージョンやクラスタ種別、リージョンは提供状況により変わるため、断定せず公式情報で確認する

内部の仕組み

HDInsight のクラスタは、制御を担うヘッドノードと、処理を担うワーカーノードに分かれます。クラスタ自体は計算リソースであり、データは外部のストレージ（ADLS Gen2 / Blob）に保持されます。この分離により、計算クラスタを増減・削除してもデータは独立して保管され続けます。

• ヘッドノードのリソースマネージャがジョブを タスクへ分割 し、ワーカーノードに分散実行させる
• 中間データはワーカー間で再分配（シャッフル）され、結果は既定のストレージへ書き戻される
• Ambari がクラスタ全体の構成・サービス状態・メトリクスを集約し、運用の起点になる
• クラスタの初期化時やノード追加時に スクリプトアクション を適用し、追加ライブラリを導入できる
• 計算とストレージが分離されているため、同じデータに対して複数のクラスタや種別からアクセスできる

クラスタ種別ごとに含まれるコンポーネントが異なり、Spark 種別なら Spark、Interactive Query 種別なら Hive LLAP、Kafka 種別なら Kafka ブローカーといったように、用途に最適化された構成が初めから用意されます。

設計パターン / ベストプラクティス

• データはクラスタ内ではなく ADLS Gen2 / Blob に置き、計算とストレージを分離して扱う
• バッチ処理は ジョブ実行時にクラスタを作成し、完了後に削除 する一時クラスタ運用を基本にする
• 用途は クラスタ種別で分離 し、対話型クエリ・バッチ・ストリーミングを混在させない
• 負荷変動には オートスケール を設定し、ワーカーノード数を需要に追従させる
• カスタムコンポーネントの導入は スクリプトアクション で再現性を持たせ、手作業を避ける
• 新規のレイクハウス志向ワークロードなら、HDInsight に固執せず Databricks や Synapse との比較も検討する

運用・監視

• クラスタの構成変更・サービス再起動・ノード状態の確認は Ambari の Web UI から行う
• ログ・メトリクスを Azure Monitor / Log Analytics に送り、ジョブやノードの状態を横断的に可視化する
• ジョブの遅延や失敗は、リソース不足・データ偏り（スキュー）・小ファイル過多が典型的な原因になる
• スケールアウト/スケールインやオートスケールで、負荷に対するワーカーノード数を調整する
• OSS のバージョンには提供期間（サポート期限）があるため、計画的にクラスタを新バージョンへ移行する

コスト

コストは主に ワーカーノードとヘッドノードの VM 利用料 で構成され、ノード台数と稼働時間に比例します。計算とストレージが分離されているため、クラスタを削除すればストレージ保管料だけに抑えられます。

• バッチは 一時クラスタ（実行時に作成し完了後に削除）で常時稼働コストを排除する
• 負荷変動には オートスケール を使い、過剰なノードを抱えないようにする
• データは ストレージ側に保持 し、計算を止めても保管コストだけにする
• ノード VM サイズは用途に合わせて選び、過大なスペックを避ける

セキュリティ

• 認証は Microsoft Entra ID と統合し、Enterprise Security Package でクラスタの認可を一元管理する
• ストレージへのアクセスは マネージド ID を用い、アカウントキーの直書きを避ける
• VNet にクラスタを配置し、必要に応じてプライベートな接続で公開アクセスを制限する
• 保存データと転送データは暗号化され、ストレージ側でも暗号化が適用される
• 監査ログや診断設定を有効にし、誰がどのデータにアクセスしたかを追跡できるようにする

関連サービス・比較

新しいレイクハウス志向のワークロードでは Azure Databricks がよく比較対象になります。HDInsight は既存 OSS スタックをそのまま運用したい場合に、Databricks は Spark を中核とした最適化済みの統合基盤を使いたい場合に向きます。AWS では Amazon EMR が HDInsight に近い役割を担います。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Spark クラスタを作成（ストレージは別途用意した ADLS Gen2 / Blob を指定）
az hdinsight create \
  --name demo-hdi \
  --resource-group demo-rg \
  --location japaneast \
  --type spark \
  --storage-account demostorageacct \
  --http-user admin \
  --ssh-user sshuser

# クラスタの情報を確認
az hdinsight show \
  --name demo-hdi \
  --resource-group demo-rg \
  --output table

# 使い終えたら削除してコストを止める（データはストレージ側に残る）
az hdinsight delete \
  --name demo-hdi \
  --resource-group demo-rg \
  --yes