Skip to main content Skip to Footer

Blog - Cloud ComputingCommentary from our cloud experts around the globeBLOG アクセンチュア・ クラウド・ ダイアリーズ

May 16, 2019
AWSにおけるビッグデータ分析基盤の導入(2) AWS Glue
By: 青柳 雅之

デジタルコンサルティング本部 アクセンチュア アプライド・インテリジェンス (AAI) シニア・マネジャーの青柳雅之と申します。私はAWSやAzure、GCPといった主要なパブリッククラウドを使用したアナリティクスに関わる業務を中心に担当しています。


AWSにおけるビッグデータ分析基盤の導入(1) ~ビジネス要件定義とデータを起点とするクラウドEAの策定においては、ビジネス要件から可視化要件への流れ、それがビッグデータ分析基盤のアーキテクチャに影響を与えることを説明しました。今回は組織内のデータとその属性(メタデータ)を管理するデータカタログの機能を持ち、ある意味AWSを活用した分析基盤の中心ともいえる「AWS Glue」のアーキテクチャ上のポイントを中心に見ていきたいと思います。


AWS Glueとは

分析作業とは、具体的にはクエリを投げて結果を得たり、DWHでデータマートを作ってBIレポートを作ることを指します。例えば、AWSのDWHであるRedshiftを使うのであれば、データはRedshiftで使える形式でRedshiftにロードしなければなりません。ここでAWS Glue(以下、Glue)が登場します。Glueは、AWSが提供するETL(Extract, Transform, Load)とデータカタログのマネージドサービスです。


Glueのアーキテクチャ

Glueのアーキテクチャを理解するために、いくつかの視点からGlueを見ていきたいと思います。Glueのコンポーネントとしてはどのようなものがあり、どのようにネットワークに配置されるのか、セキュリティはどのように担保されるか、ETLの機能やスケーラビリティに関して、サービスの仕様としての制限はどこにあるのか、といったようなところがアーキテクチャ検討の際に最も重要な知識になります。


Glueを構成するコンポーネントの視点

Glueはデータカタログ、クローラー、ジョブスケジューラ、ETLエンジンのコンポーネントから構成されます。Glueはこれらのコンポーネントから構成されるサーバーレスのサービスのため、ユーザーがインフラストラクチャを管理する必要はありません。



Glueを構成するコンポーネントとその関係



  • データカタログ

データカタログは様々なデータソースに存在するデータの属性情報であるメタデータを集中管理します。このデータカタログは、データの読み取り先、読み取り方法、その他データ処理に必要な情報を属性情報として管理します。これらの情報は、EMR、Athena、Redshift/Redshift Spectrum等から参照されます。データカタログはHiveメタストア互換であり、EMRのメタストア(メタデータを保管する場所)としても利用できます。


  • クローラー

Glueはデータソースをクローラーによってクロールし、データカタログに入力するメタデータを分類します。クローラーには分類子が組み込まれています。 分類子は読み込んだデータの形式を認識します。たとえば、読み込んだデータが、JSON形式なのか、Apache Parquet形式なのかを認識し、これによりデータが分類されます。組み込みの分類子の他、カスタムの分類子を作成することも可能です。詳細はAWS社の公式ドキュメント「AWS Glue の組み込み分類子」を参照してください。また、クローラーを使ってメタデータを分類する他に、AWS Glue APIを使用して、データカタログに直接メタデータを定義する方法もあります。


  • ETLエンジン

メタデータに存在するデータソースとターゲットの属性情報から、PySparkかScalaのETLスクリプトを生成します。PySparkはデータサイエンティストが使い慣れているPythonであり、ScalaはGlueがデータ加工エンジンで使用しているApache Sparkのネイティブ言語です。Scalaを選択するメリットは、データの加工処理の速度と、Javaとの互換性により外部の豊富なJavaクラスライブラリを利用できることです。


Glueを利用するAWSサービスやアプリケーションの視点

GlueはAWS内のリソースのみならず、オンプレミスのデータストアもETL処理のデータソースとして扱うことができます。オンプレミスに存在するデータストアについてはJDBC接続が可能なことが条件です。デフォルトでサポートされているデータストア(データソースとターゲットの両方)の他、それ以外のJDBC接続のデータストアもカスタムに定義可能です。



Glueに関連するAWSサービスとアプリケーション



ネットワーク経路の視点

Glueはデータストアが同じリージョンの別のVPCや別のリージョンに存在する場合も、VPCピアリング、もしくはインターリージョンVPCピアリング経由で接続が可能です。別のAWSアカウントのリソースにも接続が可能です。Glueのジョブがこれら様々な場所にあるデータストアに接続する観点でのネットワーク経路を以下に示します。GlueのジョブがVPC内のリソースにアクセスする際は、プライベートサブネットにENI(Elastic Network Interface)が配置され、そのサブネットのIPアドレス範囲内のプライベートIPアドレスが付与されます。このENIにはパブリックIPアドレスは付与されません。そのため、パブリックインターネットにアクセスする際は、NATゲートウエイとインターネットゲートウエイ経由でアクセスします。また、VPC内からS3にアクセスする際はVPCエンドポイント経由で行います。特に、ハイブリッド環境での詳細な考慮事項は、「AWS Glue を使用することによってオンプレミスデータストアにアクセスして分析する方法」に記載されています。このENIの数はジョブのために選択されたデータ処理ユニット(DPU)の数に依存します。

1 つの DPU では 4 つの vCPU と 16 GB のメモリが提供されます。1つのETLジョブで最低2つのDPUが必要となります。DPUの数はGlueの課金にも関わってきます。

VPCピアリングを行う場合の注意点としては、DNS設定を有効にすることです。これにより、Glueが相手のVPCに存在するデータベースエンドポイントのプライベートIPアドレスを取得できるようになります。この設定を行わないと、Glueは相手をパブリックIPアドレスで解決しようとしますが、GlueのENIはプライベートサブネットに存在するため、パブリックIPアドレスにはNATゲートウエイ経由でしか到達できません。



Glueとデータストアへのネットワーク経路



開発エンドポイントの視点

VPC内にGlueの開発エンドポイントに接続するApache Zeppelinノートブックサーバーを作成し、ノートブックを使用して ETL スクリプトを作成し、テストを行うことができます。ノートブックでETLスクリプトを作成し、開発エンドポイントに接続して実行、デバッグ、テストをインタラクティブに行うことが可能です。下図はパブリックサブネットにノートブックサーバーを配置して開発エンドポイントにアクセスしている例ですが、ユーザーがどこからアクセスするかでノートブックサーバーの配置を決め、適切なルーティングの設定を行います。



開発エンドポイントとノートブックサーバーの配置の例



セキュリティの視点

データカタログのテーブル等のGlueのリソースと、そのデータストアを保護するために、認証、アクセス制御、暗号化を使用します。AWSではIAM(Identity and Access Management)というリソースへのアクセスを制御する仕組みがあります。また、データソースとの通信のため、セキュリティグループも構成する必要があります。


  • 認証

Glueは、AWSアカウントのルートユーザー、IAMユーザーを認証できます。また、IAMロールにより、他のAWSサービスがGlueにアクセスするための権限を付与することも可能です。



Glueの認証のパターン



  • アクセス制御

Glueにはアイデンティティベース(IAMユーザー、IAMグループIAMロール)のポリシー(IAMポリシー)とリソースベースのポリシーがあります。双方によりGlueリソースへのアクセスをコントロールします。リソースポリシーはカタログにアタッチされます。これにより適切なユーザーが必要最小限のメタデータにアクセスするように制御できます。

ポリシーに関するサンプルは「AWS Glue アクセスコントロールポリシーの例」にあります。


  • 暗号化

ジョブ、クローラー、開発エンドポイントによって書き込み処理が行われるS3やCloudWatch Logs、データカタログのメタデータオブジェクトやアカウント内のデータカタログ、データストアへの接続パスワードを暗号化できます。ジョブ、クローラー、開発エンドポイントを作成するときに暗号化設定を有効にします。


Glueの制約

クラウド上のマネージドサービスには一般的に多くの制約があります。様々な機能要件、非機能要件がこれらの制約にひっかからないかを確認する必要があります。ここで、制約の一覧を記載します。この中にはアカウント当たりのデータカタログのテーブル数、ジョブ数、開発エンドポイント数などの上限が記載されています。このような上限は必ず確認します。必要に応じてサポートに上限緩和申請を行います(上限を緩和できないものもあります)。また、開発者ガイドには多くの制約が記載されています。検索をかけて制約を理解した上でアーキテクチャを吟味しましょう。


AWS Glue の制限

AWS Glue 開発者ガイド


Glueのアーキテクチャに影響を与えるデータパイプラインの要件

上記のアーキテクチャに関わる内容から、Glueのアーキテクチャに影響を与えるデータパイプラインの処理要件の例をリストします。一部は前回のブログで紹介した要件項目と被りますが、データ更新頻度のようにデータパイプラインを構成する複数のサービスが1つの要件に影響を与えることもあります。これらを多角的な視点から要件とサービス仕様のFit&Gapを行うことで、より信頼性の高いアーキテクチャを策定することができるでしょう。


要件項目 内容
ステークホルダーの識別
  • データカタログにアクセスできるステークホルダーを識別する。ステークホルダーには分析を行うメンバーの他、ETLスクリプトを開発するメンバーも含む。これはツール(AthenaやRedsift Spectrum)を介するケース、直接データカタログにアクセスするケースを想定する。

    ステークホルダーの属性やどの場所からアクセスするかでセキュリティ構成やネットワーク構成が影響を受ける。

  • GlueではETLスクリプトがPySparkかScalaとなり、担当者にいずれかのスキルが必要となる。

利用ツールや関連するアプリケーション アドホックな分析で利用するAthenaやRedshift Spectrumといったツールの他、IAMロールやAPIでアクセスするケースも想定する。GlueをHiveメタストアとして利用するツールも整理する。
セキュリティ
  • ステークホルダーを識別後、各ステークホルダーの認証・アクセス制御の要件を整理する。

  • ステークホルダーがアクセス可能なデータカタログの範囲を整理する。

  • Glueによって書きこまれるデータの暗号化の要否を確認する。

データ更新頻度
  • 業務に必要なデータ更新頻度により、データがデータパイプラインを流れる時間を定義でき、それに必要なアーキテクチャが検討できる。

  • PySparkよりもScalaのほうが高速なため、処理速度の要件によってはETLスクリプトの言語選定に影響を与える可能性がある。

データ形式 ステークホルダーが必要とするメタデータ項目、データ形式を整理する。また、これらのデータが存在するデータソースを識別し、どのデータ形式から必要なデータ形式に変換するかといった必要なETL処理を見積もる(分類子に影響)。データストアがどの場所に存在するかでネットワーク構成が影響を受ける。
データ量 処理時間をPoCで計測する。性能によってはETLジョブに割り当てられるデータ処理ユニット(DPU)の数を調整する。

処理要件項目の例


参考文献

AWS Glue 開発者ガイド ※ブログ本文中で多数リンクを貼っています。

AWS Glue のクロスアカウントおよびクロスリージョンの接続を行う

AWS Glue を使用することによってオンプレミスデータストアにアクセスして分析する方法

AWS Glue がScala をサポートしました

AWSにおけるビッグデータ分析基盤の導入(1) ~ビジネス要件定義とデータを起点とするクラウドEAの策定


以上、今回のブログではGlueを理解するためにアーキテクチャを中心に説明を行いました。Glueと他のAWSのサービスとの連携とアーキテクチャは各サービスに関する説明の中で行っていきます。

Popular Tags

    最新の記事

      アーカイブ