データパイプラインの管理～ワークフロー管理に利用できる、さまざまなAWSサービス

はじめに

本連載の第2回では様々なデータソースからの収集について、第3回では収集されたデータの管理についてそれぞれ解説してきました。今回は、それぞれのデータの収集から分析するまでの処理の流れを管理するデータパイプライン管理に着目し、求められる要素や関連するサービスとその使い分けについて解説します。

データパイプラインとETL

分析するためのデータを様々なデータソースから収集してデータレイクのような基盤で実際に分析できる状態にするまでには、一般的にいくつかのサービスや機能、処理を組み合わせて実現します。このようにデータの抽出（Extract⁠）⁠、変換（Transform⁠）⁠、ロード（Load）の一連のフロー（流れ）をETLと呼び、データソースやデータの種類ごとに異なるフロー（パイプライン）を構成する必要があります。

さらにこの処理は当然ながら自動化することが一般的です。なお、データウェアハウスにロードした後にデータウェアハウス上でSQLを用いて追加加工をするケースもあり、Load後にTransformするフローを明示的に示す場合はELT（TとLが逆）といいます。

抽出や変換、ロードの各処理は1つの製品やツールで完結できる場合もあれば、処理毎に最適化された異なるツールを組み合わせて利用する場合も想定されます。後者について例えば、大規模データの加工処理についてのみ分散処理フレームワークのApache Sparkを利用し、加工済みデータをさらに異なるツールで名寄せや匿名化などの追加処理を行うなどが考えられます。これらの処理は定常的かつ順番に正しく実行される必要があり、もし何か途中で問題が発生した場合は正しく検知およびリカバリする必要もあります。

このように複数のデータパイプラインおよびその構成要素である各ETL処理の管理と実行制御等を行うために必要なツールがワークフロー管理ツールです。

ワークフロー管理ツールに求められる機能

一般的にワークフロー管理ツールに求められる機能をいくつかまとめます。

1. 実行順序制御

前述のようにデータパイプラインは複数の処理が連なる形で順番に実行されるため、例えば処理Aが終わってから処理Bを実行するように実行順序を制御します。やや複雑なワークフローになると処理Aと処理Bの両方が終わってから処理Cを実行するなど、柔軟性のあるパイプラインを構築したいケースも出てきます。

2. 実行状況の可視化（モニタリング）

データパイプラインは複数の処理（またはタスク）で構成されますが、例えば「パイプラインの途中で何かしらのエラーが発生した場合、どの処理でエラーとなったか？」「⁠今どこまで処理が進んでいるのか？」「⁠そもそもどのパイプラインが正常動作しているか？」など、実行状況を正しく把握できるためのモニタリング機能が必要です。

3. 冪等性（べきとうせい）をベースとしたリトライ制御

データパイプラインの特定の処理でエラーとなった場合、基本的には自動的にリトライする仕組みが重要です。ただし、リトライすることで例えばデータ登録が重複したり意図しない結果とならないように冪等性《べきとうせい》を考慮することが前提となります。

冪等性とは、同じ操作を何度繰り返しても同じ結果が得られる性質のことです。例えば、データベースにデータを追加する処理で、冪等性を考慮しない場合に単純に処理をリトライすると、同じデータが重複登録するなどの問題が生じます。冪等性を考慮して例えばデータ追加の前に同じデータが登録済みかのチェックを入れるなどの実装をすることで、仮に処理でエラーとなった場合は単純にリトライするだけで良いため、自動化がしやすく、運用がラクになります。

4. デバッグのためのログ確認

データパイプラインの特定の処理でエラーとなった場合、場合によってはデバッグが必要となるので、エラーログを確認できる仕組みが必要です。

5. 様々なETLツールとの連携コネクタ

ワークフロー管理というよりは、どちらかというとワークフロー管理ツールで実行される処理に関する要件ですが、ETLは一般的にさまざまなデータソースとの連携が必要となるため、より多くのデータソースとの接続コネクタがあることが望ましいです。

ワークフロー管理に利用できるAWSサービス

AWSが提供するワークフロー管理に利用できるサービスをいくつか紹介します。

Amazon Managed Workflow for Apache Airflow (MWAA)

オープンソースソフトウェアのワークフロー管理ツールApache AirflowをAWSマネージドサービスとして提供しているサービスです。複雑なセットアップやインフラストラクチャを管理することなくApache Airflowを利用できます。なお、Apache Airflowはもともと2014年に民泊サービスを提供する（米）Airbnb社が開発し、現在はApache Software Foundationのトッププロジェクトになっており、非常に多くの企業やユーザに利用されているソフトウェアです。

特徴としては、ETL運用に最適化した視認性の高いGUIをベースとし、デバッグやリトライ制御など操作性も高いです。また、AWSサービスに閉じない様々なサービスと連携した処理の実装を容易にする各種Operatorが提供されています。

AWS以外の環境にもオープンソースソフトウェアのApache Airflowをセットアップできることから、ハイブリッド環境などで統一的な運用・管理を望まれるユースケースや、もともとオンプレミスでApache Airflowを利用していてクラウドに移行したい場合などにもフィットしやすいです。また、パイプラインはDAG（有向非巡回グラフ）という形式でPython言語で定義できるため、実際のETL処理とパイプラインの両方を共通的にプログラミングコードで定義できる点なども、コードを主体とした開発のユースケースによってはメリットと言えます。

AWS Step Functions

AWS Step FunctionsはAWSが提供するサーバーレスで実現する汎用性の高いワークフロー管理サービスです。サーバーレスサービスとは、ユーザーがサーバーを意識せずに利用できるサービスの提供形態で、負荷に応じたオートスケーリング、ビルトインの高可用性、使用量に応じた課金モデルなどの特徴があり、高い俊敏性とコスト最適化を実現しやすいサービスと言えます。

AWSネイティブサービスであるため各種AWSサービスと統合されており、連携がしやすい点がメリットです。本サービスはETL用途に限らず汎用的なワークフロー管理サービスである点も特徴で、ETLに限らず他の様々な用途でも利用できます。パイプラインの定義は基本的にはJsonまたはYaml形式で記述しますが、AWS Step Functions Data Science SDK for Pythonを利用することでPython言語でも定義でき、さらにStep Functions Workflow Studioを利用することで、非常にリッチなGUIで容易にパイプラインの構成も可能です。

AWS Glue

AWS Glueは、データ収集、カタログ化、データ加工を一気通貫して行うことができる統合的なデータインテグレーションサービスとしてETLに関する様々な機能を提供します。

その機能の1つにワークフロー管理機能があります。AWS Step Functionsと同様にサーバーレスサービスであるため、保守性や俊敏性、コスト最適化観点で同様のメリットがあります。AWS Glueの機能の１つであるため、当然ですがAWS Glueのジョブ機能など各種機能との統合・連携が容易です。パイプラインの構築も専用のGUIが提供されており、汎用的なパイプラインをテンプレート化して共有可能なBlueprint機能なども特徴的な機能の１つです。比較的シンプルなユースケースのETLに関する機能を全てAWS Glueで完結することもできます。

各サービス使い分け

ワークフロー管理に利用できるAWSサービスとして、Amazon MWAA、AWS Step Functions、AWS Glue (Workflow)の概要を紹介しました。それぞれ特徴があり、どれを利用すれば良いかはユースケースや要件によって異なります。例えばあくまで参考ですが、以下のようなユースケース・要件をベースに考えることもできます。

例1）エンタープライズ、大規模統合分析基盤など: 大多数かつ複雑なETLパイプラインを構成する必要がある・運用チームによる効率的な監視とデバッグが課題・ハイブリッド環境などのような要件においては、オープンソースソフトウェアをベースとしてAWS以外の環境やサービス連携との親和性が高く、複雑なパイプライン構築への対応や高性能な運用ダッシュボードも有するAmazon MWAAの利用が考えられます。
例2）スタートアップ、新規事業プロジェクト: ETLパイプラインの数が一定数で、高いアジリティと最小限のメンテナンス（非常に少ない開発運用体制⁠）⁠・クラウドベースの環境などの用件においては、AWSネイティブサービスとの親和性が高く、サーバーレスサービスで保守性や俊敏性、コスト最適化のメリットが得やすいAWS Step Functionsが考えられます。さらにAWS Glueサービスで完結したい場合はAWS Glue Workflowの利用も考えられます。

さらに、次に示すような各ユースケースの違いをもとにより使いやすい・要件にマッチするサービスを選択することもできます。

[1] 運用監視オペレーション観点での比較

Amazon MWAA

MWAAではAirflow UIというパイプラインのモニタリングやトラブルシュートを容易にする専用GUIを利用できます。パイプラインを一覧表示し、各パイプラインのステータスのサマリを高い粒度で確認できるほか、パイプラインの詳細についてさまざまな角度で確認ができます。パイプラインと構成タスク（処理）の数が非常に多い場合でも、どのパイプラインのどのタスクでエラーが発生しているか？の把握が容易に行えます。

さらに、エラーとなったタスクの詳細ログ（標準出力ログ）の確認や、パイプラインの途中からの再開含めた手動リトライ操作もUIからスムーズに行うことができます。

また、パイプラインの構成コード（DAGコード）をこのUIから確認することもできます。

AWS Step Functions

Step FunctionsはAWSマネージメントコンソールにて、パイプラインに相当するステートマシンの一覧と、各ステートマシンのサマリ状況を確認できます。また各ステートマシンを選択すると、実行履歴やフロー詳細画面にて、どのステップまで進行したか？どのステップでエラーとなったか？などを確認できます。

なお、エラーメッセージはこの画面内で確認できますが、詳細ログはAmazon CloudWatch Logs等で確認する必要があります。シンプルなUIで構成され、必要な機能は提供されている一方で、UIのリッチさではMWAAのAirflow UIが視認性や操作性の点でより優れていると言えます。

また、パイプラインに相当するステートマシンの途中でエラーとなり手動再開が必要な場合、本来であればそのステップから再開する操作を想定しますが、Step Functionsは特定のタスクからの途中再開はできず、基本的には再開用のステートマシンを作成するか、冪等性を担保している前提で最初からステートマシンを再実行します。

AWS Glue

GlueにもWorkflowというパイプライン管理機能が包含されています。他のサービス同様にパイプラインに相当するワークフローの一覧や、実行履歴の確認、エラーログの確認、パイプラインの途中からの再開含めた手動リトライなど基本的な機能は提供されています。一方で、UIのリッチさではMWAAのAirflow UIが視認性や操作性の点でより優れていると言えます。

なお、Glue Studioの機能としてジョブの詳細なモニタリング機能も提供されています。

[2] パイプライン作成観点での比較

Amazon MWAA

MWAAではパイプラインをPython言語によるプログラムコードで記述します。プログラムというと敷居が高い印象もありますが、特にデータ分析領域においても幅広く利用されている言語で、実際のETL処理をPython言語で実装するケースも多いことから、パイプラインの定義と処理（タスク）を共通的にコードで記述・管理ができるという点はメリットと言えます。また、Operatorと呼ばれる事前定義されたタスクのテンプレートが数多く提供されており、うまく活用することで実際に記述するコード量を軽減できます。

大規模な運用になってくると、毎回パイプラインをゼロから構築するよりは、既存の類似のパイプラインやテンプレートを複製して微修正したり、あるいは定常的な仕様変更へ追従するために既存のパイプラインを更新およびバージョン管理する必要も出てきます。一般的にプログラムコードを開発・管理する場合に広く利用されている仕組みにgitがあります。gitとはコードの変更履歴を記録・トレースするためのシステムです。パイプラインとETL処理を統合的にコードで管理できることで、gitを利用したバージョン管理やCI/CD（継続的インテグレーションと継続的デリバリーまたは継続的デプロイ）と呼ばれる自動化の仕組みとの親和性も高いと言えます。なお、パイプラインの定義はコードで行いますが、構成されたパイプラインは前述のAirflow UIで視覚的に確認できます。

AWS Step Functions

Step Functionsでは基本的にはJSON形式でステートマシーンと呼ばれるパイプラインを定義します。なお、AWS Toolkit for Visual Studio Code内またはAWS CloudFormation内においてはYAML形式での定義もでき、またData Science SDK for Amazon SageMakerを利用すると、Python言語による定義も可能です。

さらに、Step Functions Workflow StudioではGUIを利用してノーコードでパイプラインを構成することも可能です。AWSネイティブサービスであることから200以上のAWSサービスと容易に連携できる点もメリットと言えます。Step FunctionsはETLに特化したサービスではなく汎用的なワークフロー制御のためのサービスであり、その他さまざまな用途でも活用可能です。

AWS Glue

Glue Workflow機能では、AWSマネジメントコンソール上のGUIで視覚的にパイプラインを構成できます。MWAA同様にETLのユースケースを想定した必要な機能を包含しつつ、Step Functions Workflow StudioのようなGUIをベースとしたノーコード設計が可能です。他のGlueの機能と組み合わせシンプルな利用を想定する場合は選択肢となりますが、より高度な拡張性や柔軟性が求められるユースケースではMWAAやStep Functionsがフィットします。

[3] コスト観点での比較

Step FunctionsとGlueはサーバーレスサービスであり、パイプライン実行に応じた従量課金モデルのため、無駄が生まれにくくコスト最適化がしやすいと言えます。一方でMWAAは環境インスタンスを構築し、その稼働時間による課金のためパイプラインの実行有無に限らず料金が発生する点が異なります。よって、多数のパイプラインが常時実行されるようなユースケースなど、環境インスタンスを効率的に稼働させる工夫が求められます。

以上を踏まえて簡単に比較表を示します。それぞれの開発体制や規模、保有スキル、人それぞれの使いやすさなどによって適切な選択肢は変わってきます。ハンズオンなどで実際に触って試すのがお勧めです。

※1 ETLステータスサマリ情報粒度や確認画面への操作ステップ数で相対評価
※2 ETL処理内容もパッケージ化した形でコードベースで開発可能なblueprin機能もあり
※3 YAMLはAWS Toolkit for Visual Studio Code/AWS Step Functions利用で対応
※4 パイプラインの手動再開操作や詳細ログ等への操作ステップ数で相対評価

ユースケース別の組み合わせパターン

パイプラインを構成する場合はワークフロー管理サービスに加えて実際のタスク（処理）を実行するサービスも組み合わせて実現します。ただし、Step Functionsは外部サービスをトリガーするワークフロー管理に特化した専用サービスですが、MWAAは構成要素であるワーカーで軽量タスクを実行することもでき、Glueは軽量タスクを実行可能なPythonシェルジョブや大規模タスクも実行可能なSparkジョブなど各種機能を有しています。

それらを踏まえ、いくつかデータパイプライン実行のための構成パターンを示します。

例1: サーバーレサービスを中心に構成した最もシンプルな構成パターン。俊敏性や保守性、コスト最適化が測りやすい。
例2: ワークフロー管理に加え軽量タスクについてもMWAAで実現し、中/大規模なタスクに並列分散処理フレームワークが利用可能なGlueまたはEMRを組み合わせた柔軟性の高い構成パターン。
例3: ワークフロー制御からジョブ実行まで全てのコンポーネントをGlueで完結したシンプルパターン。

まとめ

今回は、それぞれのデータの収集から分析するまでの処理の流れを管理するデータパイプライン管理に着目し、求められる要素や関連するサービスとしてAmazon MWAA、AWS Step Functions、AWS Glue Workflowについてそれぞれの特徴や使い分けについて解説しました。この他、AWSではゼロETL統合機能のように複雑なデータパイプラインをシンプル化するための機能追加も進めています。それぞれの特徴を踏まえながら要件と照らし合わせて適材適所で選択してみてください。

次回はデータ分析に利用可能なサービスとその使い分けをテーマにお届けする予定です。是非ご期待ください。