モダンなIT運用管理、ジョブ管理システムとしてのMWAA
最終更新日: 2025年 2月 1日 編集履歴
概要
DX(デジタルトランスフォーメーション)に真剣に取り組んでいるお客様が、モダンなIT運用管理・ジョブ管理システムの選択のお手伝いをする機会があり、候補としてMWAA (Amazon Managed Workflows for Apache Airflow)を推薦しました。
ここ数年来、DXという言葉が業界をにぎわせています。業務システムの運用をたくさん抱えるインテグレーターさんなら、扱っているシステムの更改のタイミングで、この言葉を意識しない訳にはいきません。
抽象的な概念を表すDXという言葉は人や組織、語られる時期によって実現のイメージに多くのばらつきが生じています。
今回のDX対応に求められるITインフラ
クラウド（AWS, Azure, GCP）を活用した柔軟なシステム構築
オンプレミスという選択肢はありません。
サーバーレスアーキテクチャの採用
EC2という選択肢がなくなります。
セキュアなネットワーク環境の整備
完全に企業内でしか使用しないシステムでもAWSを利用します。プライベートサブネットで全ての機能が動く必要があります。 SaaSを利用する場合は、どうしてもそのサービスである理由が説明でき、安全を守るための具体的な施策の提示を求められます。
他にも多くの要件はありますが、割愛します。
ジョブ管理システム
業務システムでは定期的にバッチジョブを走らせ、正しく処理を完了できたかを一元的に管理する仕組みが求められます。 IT運用管理・ジョブ管理システムといわれる分野で、以下のような代表的な製品が有ります。
どれも安定した確実な運用をサポートするため、ジョブ管理と監視システムが一体化したものが多いです。
- JP1 (日立製作所)
- Hinemos (NTTデータ)
- Systemwalker (富士通)
- 多くのOSS
メリット・デメリットを表にして整理しましたが、どれも大きな特徴が見当たりません。
多くのDXプロジェクトの要件には定番の解決案がありますが、なぜか運用管理・ジョブ管理システムに定番が見当たらないのです。
観点
- AWSを軸としたDX移行なので、監視系はCloudWatch一択です。
- 別途、定期ジョブ実行において信頼性の高い仕組みが必要です。
定期実行ジョブは確実に実行されているか
- どのような仕組みで信頼性は担保されるのか。
障害発生時
- どのジョブまで実行され、どこでリトライし、どんなエラーが出たのかを素早くオペレータが把握できるか。
障害を解決後
- 通常運用に戻す際の手順は解りやすいか。
- 二次災害を起こしてはならない。
依存関係といった、多少複雑なジョブを定義できるか
- 前段実行ジョブが遅延しても、後続ジョブが追い越す事があってはならない。
AWSサービスで固めるとどうなるか
調べるうちに以下のような穂方法が出てきました。
EventBridgeで定期実行をキック、StepFunctionsでフローを定義
検索するとこの案が結構出てきます。GUIでフローチャートを作成するようにジョブを定義出るので、従来のシステムと同様の使い勝手が期待されるのでしょう。
ジョブの依存関係が実装できるかを確認するためにサンプルを作成しました。 基本的に定期実行。ただし、前段Jobは絶対に追い越してはいけない、あれ、なんか難しいぞ。
実行状態と結果を一旦DynamoDBに書き出すかな。Lambda要るな。ん、実行時間15分制限があるから処理本体はLambdaに統一できないじゃん。Fargateを組み合わせる? なんかAWSマネージドサービス総動員って感じになってきたぞ。障害点多すぎじゃね・・・。
AirFlowの利用
Job管理ではなくワークフローで調べると、MWAAが見つかりました。
複雑なワークフローをサポートする
ビッグデータプロバイダーからの複雑なデータを準備および処理する、スケジュールされたワークフローまたはオンデマンドワークフローを作成します。
抽出、変換、ロード (ETL) ジョブを調整する
複雑な ETL ワークフロー内で多様なテクノロジーを使用する複数の ETL プロセスをオーケストレートします。
ML データを準備する
パイプラインを自動化して、機械学習 (ML) モデリングシステムがデータを取り込んでトレーニングするのをサポートします。
「ETLじゃないからデータパイプラインを強調されても・・、機械学習でもないしな、Job制御はワークフローとも言えるな」などと、先入観まみれでメリット・デメリットの表に並べてみたところ、「かなりイケるんじゃないか」と感じるようになりました。
- AWSマネージドサービスである。
- DAG(有向非巡回グラフ)は、Jobネットワークの定義である。
- GUIではなくPythonでDAGを定義しなくてはいけないが、バージョン管理やIaCを考えるとむしろ利点が多い。
- 実行/未実行/エラーのステータスは基本機能だけで管理できる。
- そもそもFargateの上にデプロイされていてプライベートサブネットで動かせる。
- 縦にも横にもスケールできる。Web、Scheduler、Workerは別インスタンスで、それぞれキャパシティに応じて拡張できる。
サンプル構築と説明資料作成
この段階で、だいぶAirFlowを推したい気持ちになってきたので、お客様と相談しながら、実際の業務を想定したデモを作成しました。
Javaバッチを想定して、簡単なプログラムをECR -> ECS Fargateにデプロイ、AirFlowから呼び出し、ステータスの遷移を確認、画面キャプチャ動画と数ページの資料にまとめて結果をご報告しました。
移行したい業務のスケルトンだけですが、運用上懸念されていたリトライやJobのスキップ方法も見えてきました。癖は強いので運用要員の学習コストは高くなる旨も申し添えました。
採用
数日後、Job管理はAirFlowで行く事が決まったとお客様から連絡がありました。 移行Prjは始まったばかりですが、全力でサポートしていきます。