このドキュメントは、Tableau や Looker などのビジネス インテリジェンス（BI）ツールを使用したデータ アナリストによる安全なデータアクセスを設定する必要がある運用者と IT 管理者を対象としています。BI ツールを使用する、または Dataproc API を操作する方法については説明しません。
このドキュメントは、データ アナリストが BI ツールを使用してデータに安全にアクセスできるようにするためのエンドツーエンドのソリューションをビルドするシリーズのパート 1 です。次のコンセプトについて説明します。
- アーキテクチャ案。
- アーキテクチャ内のコンポーネント境界、インタラクション、ネットワークの概要の確認。
- アーキテクチャ内の認証と認可に関する概要の確認。
このシリーズのパート 2 の Google Cloud 上の Hadoop に可視化ソフトウェアを接続するでは、Google Cloud 上でアーキテクチャを設定する方法を説明します。
アーキテクチャ
次の図は、このドキュメントで説明するアーキテクチャとイベントのフローを示しています。このアーキテクチャで使用されているプロダクトの詳細については、アーキテクチャ コンポーネントをご覧ください。
- クライアント アプリケーションは、Java Database Connectivity（JDBC）を介して Dataproc クラスタの単一のエントリ ポイントに接続します。エントリ ポイントは、クラスタのマスターノードにインストールされる Apache Knox によって提供されます。Apache Knox との通信は TLS で保護されます。
- Apache Knox は、認証プロバイダを使用して LDAP ディレクトリなどのシステムに認証を委任します。
- Apache Knox は認証後、ユーザーのリクエストを 1 つ以上のバックエンド クラスタにルーティングします。ルートと構成をカスタム トポロジとして定義します。
- Apache Hive などのデータ処理サービスは、選択されたバックエンド クラスタでリッスンし、リクエストを取得します。
- Apache Ranger はリクエストを傍受し、ユーザーが有効な承認を持っているかどうかに応じて処理を続行するかどうかを決定します。
- 検証に成功すると、データ処理サービスはリクエストを分析し、結果を返します。
アーキテクチャのコンポーネント
アーキテクチャは、次のコンポーネントで構成されています。
- Hadoop のマネージド プラットフォーム:
- Dataproc。 Dataproc は、オープンソースのデータツールを利用してバッチ処理、クエリ実行、ストリーミング、機械学習を行うことができる Google Cloud が管理する Apache Spark の Apache Hadoop サービスです。Dataproc は、このドキュメントで説明するソリューションの基盤となるプラットフォームです。
- ユーザーの認証と認可:
- Apache Knox.Apache Knox は、Hadoop クラスタ内のすべての基本サービスに対して単一の HTTP アクセス ポイントとして機能します。Apache Knox は、認証、認可、監査、その他のサービス用のプラグイン可能なプロバイダを備えたリバース プロキシとして設計されています。クライアントは Knox にリクエストを送信し、リクエストの URL とパラメータに基づいて、Knox がリクエストを適切な Hadoop サービスにルーティングします。Knox は、クライアント リクエストを明確に処理し、複雑さを隠すエントリ ポイントであるため、アーキテクチャの中心に位置します。
- Apache Ranger。Apache Ranger は、ユーザーが Hadoop サービスで特定のアクションを実行するための詳細に制御された権限を付与します。また、ユーザー アクセスを監査し、管理アクションを実装します。
- 処理エンジン:
- Apache Hive。Apache Hive は、SQL を使用して分散ストレージにある大規模なデータセットへのアクセスと管理を可能にするデータ ウェアハウス ソフトウェアです。Apache Hive は SQL クエリを解析し、セマンティック分析を実行して、処理エンジンが実行するステージの有向非巡回グラフ（DAG）をビルドします。このドキュメントに示されているアーキテクチャでは、Hive はユーザー リクエスト間の変換ポイントとして機能します。また、複数の処理エンジンの 1 つとしても機能できます。Apache Hive は Hadoop エコシステムにおいて普遍的であるため、標準 SQL に精通した技術者によるデータ分析を可能にします。
- Apache Tez。Apache Tez は、Hive によって準備された DAG を実行し、結果を返す処理エンジンです。
- Apache Spark。Apache Spark は、大規模なデータ処理を目的とする統合分析エンジンであり、DAG の実行に対応しています。アーキテクチャは、このドキュメントに記載されているアプローチの柔軟性を示す、Apache Spark の Spark SQL コンポーネントを示しています。ただし、Spark SQL では Ranger プラグインは正式にポートされていないという制限があります。このため、Ranger に備えられた詳細な認可を使用するのではなく、Apache Knox で大まかな ACL を使用して認可を行う必要があります。
コンポーネントの概要
以降のセクションで、各コンポーネントについて詳しく説明します。また、各コンポーネントが相互に通信する方法についても説明します。
クライアント アプリケーション
クライアント アプリケーションには、リクエストを HTTPS REST エンドポイントに送信できるツールが用意されていますが、Dataproc Jobs API は必ずしもサポートされていません。Tableau や Looker などの BI ツールは、HTTP 経由でリクエストを送信できる HiveServer2（HS2）と Spark SQL JDBC ドライバを備えています。
このドキュメントは、クライアント アプリケーションが Google Cloud の外部にあり、アナリストのワークステーション、オンプレミス、または別のクラウドなどの環境で実行されていることを前提としています。このため、クライアント アプリケーションと Apache Knox 間の通信は、CA 署名または自己署名による SSL / TLS 証明書のいずれかで保護する必要があります。
エントリ ポイントとユーザー認証
プロキシ クラスタは、Apache Knox Gateway をホストする 1 つ以上の有効期間が長い Dataproc クラスタです。
Apache Knox は、クライアント リクエストの単一のエントリ ポイントとして機能します。Knox はプロキシ クラスタのマスターノードにインストールされます。Knox は SSL 終端を実行し、ユーザー認証を委任して、リクエストをいずれかのバックエンド サービスに転送します。
Knox では、各バックエンド サービスはトポロジと呼ばれる要素として構成されますトポロジ記述子は、次のアクションと権限を定義します。
- サービスの認証を委任する方法。
- バックエンド サービスによるリクエストの転送先の URI。
- シンプルなサービス別の承認アクセス制御リスト（ACL）。
Knox を使用すると、認証を企業 ID とクラウド ID の管理システムに統合できます。トポロジごとにユーザー認証を構成するには、認証プロバイダを使用します。Knox は、デフォルトで Apache Shiro を使用してローカルデモの ApacheDS LDAP サーバーに対して認証を行います。
または、Knox を選択して Kerberos を使用することもできます。上の図は、クラスタ外部の Google Cloud でホストされている Active Directory サーバーの例を示しています。
外部 ApacheDS サーバーや Microsoft Active Directory（AD）などのエンタープライズ認証サービスに Knox を接続する方法については、Apache Knox ユーザーガイド、Google Cloud のマネージド Active Directory、フェデレーション AD の各ドキュメントをご覧ください。
このドキュメントのユースケースでは、Apache Knox がプロキシ クラスタとバックエンド クラスタに対する単一のゲートキーパーとして機能する限り、Kerberos を使用する必要はありません。
処理エンジン
バックエンド クラスタは、ユーザー リクエストを処理するサービスをホストする Dataproc クラスタです。Dataproc クラスタは、手動による再構成を必要とすることなく、分析チームからの要求を満たすためにワーカーの数を自動スケーリングできます。
バックエンドで有効期間が長い Dataproc クラスタを使用することをおすすめします。有効期間が長い Dataproc クラスタを使用すると、操作を中断することなくデータ アナリストからのリクエストを処理できます。または、クラスタが短時間においてのみリクエストを処理する必要がある場合は、ジョブ固有のクラスタ（エフェメラル クラスタとも呼ばれます）を使用できます。エフェメラル クラスタでは、有効期間が長いクラスタと比較して費用対効果も改善される場合があります。
トポロジ構成の変更を回避する目的でエフェメラル クラスタを使用する場合は、同じゾーンに、同一名のクラスタを再作成するようにしてください。同じゾーンと名前を使用することで、Knox はエフェメラル クラスタの再作成時にマスターノードの内部 DNS 名を使用してリクエストを透過的にルーティングできます。
HS2 は Apache Hive に対するユーザークエリを処理します。HS2 は、Hadoop MapReduce エンジン、Apache Tez、Apache Spark などのさまざまな実行エンジンを使用するように構成できます。このドキュメントでは、HS2 は Apache Tez エンジンを使用するように構成されています。
Spark SQL は、Apache Spark で SQL クエリを実行するための JDBC / ODBC インターフェースを備えた Apache Spark のモジュールです。上のアーキテクチャ図では、Spark SQL が、ユーザークエリを処理するための代替オプションとして示されています。
Apache Tez または Apache Spark のいずれかの処理エンジンが YARN Resource Manager を呼び出して、クラスタのワーカーマシンでエンジン DAG を実行します。最後に、クラスタのワーカーマシンがデータにアクセスします。Dataproc クラスタ内にデータを保存したりアクセスしたりするには、Hadoop 分散ファイル システム（HDFS）ではなく、Cloud Storage コネクタを使用します。Cloud Storage コネクタを使用するメリットについて詳しくは、Cloud Storage コネクタのドキュメントをご覧ください。
上記のアーキテクチャ図は、リクエストを Apache Hive に転送する 1 つの Apache Knox トポロジと、Spark SQL にリクエストを転送するもう 1 つの Apache Knox トポロジを示しています。この図は、同じまたは異なるバックエンド クラスタ内のサービスにリクエストを転送できる他のトポロジも示しています。バックエンド サービスはさまざまなデータセットを処理できます。たとえば、ある Hive インスタンスは制限された一連のユーザーの個人識別情報（PII）へのアクセス権を付与できる一方、別の Hive インスタンスはより広範な利用を目的として PII 以外のデータへのアクセス権を付与できます。
ユーザー認可
Apache Ranger をバックエンド クラスタにインストールして、Hadoop サービスに関するきめ細かな認可を行うことができます。アーキテクチャでは、Hive 用 Ranger プラグインがユーザーのリクエストを傍受し、Ranger ポリシーに基づいて Hive データに対してユーザーがアクションを実行できるかどうかを判断します。
管理者として、Ranger の管理ページを使用して Ranger ポリシーを定義します。これらのポリシーを外部の Cloud SQL データベースに保存するように Ranger を構成することを強くおすすめします。ポリシーの外部化には、次の 2 つの利点があります。
- いずれかのバックエンド クラスタが削除された場合に、ポリシーが永続的に保持されます。
- これにより、すべてのグループまたはバックエンド クラスタのカスタム グループのポリシーを一元管理できます。
正しいユーザー ID またはグループに Ranger ポリシーを割り当てるには、Knox の接続先と同じディレクトリの ID を同期するように Ranger を構成する必要があります。デフォルトでは、Ranger で使用されるユーザー ID は、オペレーティング システムから取得されます。
Apache Ranger は、監査ログを Cloud Storage に外部化して永続化することもできます。Ranger は、インデックス登録およびクエリエンジンとして Apache Solr を使用して、監査ログを検索できるようにします。
HiveServer2 とは異なり、Spark SQL は Ranger プラグインを公式にサポートしていないため、Apache Knox で使用可能な大まかな ACL を使用して認証を管理する必要があります。これらの ACL を使用するには、Spark SQL や Hive などの各サービスの使用が許可されている LDAP ID を、サービスの対応するトポロジ記述子に追加します。
詳細については、Dataproc で Apache Ranger を使用する場合のベスト プラクティスをご覧ください。
高可用性
Dataproc には高可用性（HA）モードが用意されています。このモードでは、マスターノードとして構成された複数のマシンが存在し、そのうちの 1 つがアクティブ状態です。このモードでは、単一ノードで障害が発生した、または再起動が行われた場合でも、YARN と HDFS のオペレーションの中断を回避できます。
ただし、マスターノードに障害が発生すると、単一のエントリ ポイントの外部 IP が変更されるため、BI ツールの接続を再構成する必要があります。Dataproc を HA モードで実行する場合は、エントリ ポイントとして外部 HTTP(S) ロードバランサを構成する必要があります。ロードバランサは、クラスタのマスターノードをバンドルする非マネージド インスタンス グループにリクエストをルーティングします。ロードバランサの代替手法として、ラウンドロビン DNS の手法を適用できますが、このアプローチには欠点もあります。これらの構成については、このドキュメントでは扱いません。
Cloud SQL にも高可用性モードが用意されています。これにより、異なるゾーンに配置されたマスター インスタンスとスタンバイ インスタンスの間で同期レプリケーションを実行することにより、データの冗長性を確保できます。インスタンスまたはゾーンで障害が発生した場合は、この構成によりダウンタイムが短縮されます。ただし、HA 向けに構成されたインスタンスを使用する場合は、スタンドアロン インスタンスの 2 倍の料金が発生します。
Cloud Storage はデータストアとして機能します。Cloud Storage の可用性について詳しくは、ストレージ クラスの説明をご覧ください。
ネットワーキング
階層型ネットワーク アーキテクチャでは、プロキシ クラスタは境界ネットワークに配置されています。バックエンド クラスタは、プロキシ クラスタからの受信トラフィックのみの通過を許可するファイアウォール ルールによって保護されている内部ネットワークに存在します。
プロキシ クラスタは、外部リクエストに公開されているため、他のクラスタから分離されています。ファイアウォール ルールでは、制限付きの一連のソース IP アドレスのみがプロキシ クラスタへのアクセスを許可されます。この場合、ファイアウォール ルールでは、BI ツールのアドレスから送信されたリクエストのみが許可されます。
階層化されたネットワークの構成については、このドキュメントでは説明しません。可視化ソフトウェアを Google Cloud 上の Hadoop に接続するでは、チュートリアル全体を通して default ネットワークを使用します。階層化されたネットワークの設定について詳しくは、VPC ネットワーク セキュリティのベスト プラクティスと、複数のネットワーク インターフェースの構成方法の概要と例をご覧ください。
次のステップ
- このシリーズのパート 2 可視化ソフトウェアを Google Cloud 上の Hadoop に接続するを読み、Google Cloud 上でアーキテクチャを設定する方法について確認する。
- これらの Terraform 構成ファイルを使用して Google Cloud 上でアーキテクチャを設定する。
- Dataproc で Apache Ranger を使用する場合のベスト プラクティスを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。