本連載の第5回で紹介した「Apache Airflow」は米Adobe（アドビ）や米Airbnb（エアビーアンドビー）、米Google（グーグル）、米Twitter（ツイッター）をはじめとした世界的なIT企業などで採用されているオープンソースの統合ジョブ管理ツールです。 ワークフローをコードベースで管理でき、時間などを含めた様々な依存関係を簡潔に表せるため、多くの企業で利用されており、ジョブ管理ツールとしてデファクトスタンダードになりつつあります。現在、Apache AirflowはGoogle CloudやAmazon Web Services（AWS）といったプラットフォームでマネージドサービスが提供されています。
今回はマネージドサービスとしてGoogle Cloudで提供されている「Cloud Composer」、AWSで提供されている「Amazon Managed Workflows for Apache Airflow（MWAA）」、 そしてApache Airflowのマネージドサービスを専門とした米Astronomer（アストロノマー）の「Astro」について解説します。
マネージドサービスである利点
Apache Airflowはオープンソースソフトウエア（OSS）であるため、ライセンス料は不要です。実行環境さえ準備すれば無料で使用できます。ではなぜマネージドサービスを選ぶのでしょうか。3つの理由が挙げられます。
第1にApache Airflowをマネージドサービスとして利用することで柔軟で容易なリソース管理ができます。 SaaS（ソフトウエア・アズ・ア・サービス）やクラウドサービスについて一般的に言えることですが、マネージドサービスとして提供されるApache Airflowは実行サーバーを自前で用意する必要がありません。初期投資を少なく抑えられることに加え、必要に応じて実行環境の性能を制御できます。
例えばApache Airflowの利用開始時には動作するワークフローが少ないため、性能の低い実行環境でも問題なく動作していたものを、 ワークフローの数や扱うデータ量が増えた段階で順次利用するリソースを増強できます。
第2にマネージドサービスを使用することで高い障害耐性を期待できます。 Apache Airflowのマネージドサービスに限らず多くの場合、SaaSやクラウドサービスを提供するプロバイダーは、SLA（サービス・レベル・アグリーメント）として最低限稼働することが保障される時間を提示しています。 今回紹介するGoogle CloudのCloud Composerでは月99.5％、AWSのMWAAでは月99.9％以上のSLAを設定しています。 そのため自前で準備したサーバーでは見積もりの難しい可用性設計を考慮した運用が可能となります。
そして第3に最適化されたアーキテクチャーの元でApache Airflowを実行できます。Cloud Composerでは「Google Kubernetes Engine（GKE）」をベースに、Cloud SQLやCloud StorageといったGoogle Cloudのマネージドサービスを使用した構成を採用しています。
MWAAではApache Airflowのスケジューラー、ワーカーを「AWS Fargate」で実行し、「Amazon Simple Storage Service（Amazon S3）」や「Amazon Aurora」などAWSのマネージドサービスを使用したアーキテクチャーを採用しています。単純にサーバーや「Amazon Elastic Compute Cloud（Amazon EC2）」上でApache Airflowを実行する場合に比べ、データベースやキュー、データストレージの管理などをマネージドサービスに任せられるため、より簡単に信頼性の高い実行環境を作成できます。
そしてAstroにおいても現在主流となっているクラウドサービスであるAWS、Microsoft Azure、Google Cloud上での構築が可能であり、 運用部分のみをAstroのサーバーで運用しています。この設計によりデータをサービス運営者にたいして秘匿でき、よりセキュアな構築を実践できます。 いずれの構成もマネージドサービスに頼らずクラウドサービス上で再現できますが、関連するサービスが多くリソースの管理が複雑になります。特別な理由がない限り、マネージドサービスの使用をお勧めします。
