メンテナンスからイノベーションへ: Checkout における Managed Service for Apache Airflow への移行

※この投稿は米国時間 2026 年 7 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

データ プラットフォームを構築したデータ エンジニアリング チームが、「2 日目」（運用上の現実）に直面することがよくあります。それは、オーケストレーター自体の継続的なメンテナンス作業です。

Checkout.com のデータ プラットフォーム チームの場合、本来であれば他の作業に費やすことができていた時間を、別のハイパースケーラーでセルフホスト型の Apache Airflow 環境を管理することに費やす必要がありました。サーバー管理、パッチ適用、インシデント対応に気を取られ、パイプラインの構築に集中することができずにいました。

Google Cloud のフルマネージド Airflow サービスである Managed Service for Apache Airflow（第 3 世代）に移行することで、Checkout.com はその信頼性と費用構造を大きく変革しました。今回は、同社がよりスケーラブルで費用効率に優れた、堅牢なデータ基盤を構築した手法をご紹介します。

出発点: セルフマネージド Airflow

移行前、Checkout.com はセルフマネージド インフラストラクチャで Airflow を実行していました。機能には問題がありませんでしたが、基盤となるリソースのメンテナンスには細心の注意が必要でした。パッチ適用、アップグレード、サーバー管理により、定期的にサービスを中断する必要がありました。

過去 1 年間の運用データから、同社が以下のような課題に直面していたことが明らかになっています。

• 運用面での障害の軽減: セルフマネージド環境にあった Checkout.com は、特に負荷の高い期間に、安定性に関する課題に直面していました。

• 複雑な依存関係の管理: パッケージのアップグレードと互換性の確保を絶えず手動で行う必要があり、手間がかかっていました。Managed Airflow（第 3 世代）に移行した後は、イメージレベルで依存関係を処理することでこのプロセスを簡素化し、日常的な環境アップグレードの中でシームレスに互換性を確保できるようになりました。

• DAG の同期時間: S3 へのデプロイ後、スケジューラへの DAG の同期に約 6 分かかり、イテレーションの速度に影響を与えていました。

• 手動プロセス: スケーリングには人間による介入が必要で、新しいチームのオンボーディング時には dbt 用のシークレットと変数を手動で作成する必要がありました。

ソリューション: Managed Service for Apache Airflow（第 3 世代）

Checkout.com のチームは、インフラストラクチャに関連する責務を軽減し、Google Cloud のマネージド スケーラビリティを活用するために、Managed Airflow に移行しました。その結果はすぐに表れ、信頼性、費用、開発速度の 3 つの領域で数値で示すことができる成果が上がりました。

動的スケーリングの効果

以前の Elastic Container Service 環境では、ピーク時の負荷に必要な最大数のワーカーを割り当てていました。つまり、実際の使用量に関係なく、常時ピーク時の容量に対応できる料金を支払う必要がありました。

Managed Airflow には動的スケーリング機能が組み込まれているため、リソースを手動で管理する必要がありません。この環境では、ワークロードの具体的な需要に基づいてワーカーの数が自動的に調整されます。システムは、タスクが急増するとスケールアップし、タスクが減少するとスケールダウンしてリソースを節約します。同様に、固定プロビジョニングから動的スケーリングに移行することで、月額費用も推定 30% 削減されました。

信頼性と DAG の分離

Checkout.com による移行の主な目的は、安定性の向上でした。以前は、問題のある DAG が 1 つあるだけで環境全体に影響が及ぶことがあったからです。

Managed Airflow により、アーキテクチャ面での重要な改善点が数多く導入されました。

• DAG の分離: 各 DAG は独自の実行環境で実行されます。1 つの DAG が失敗したり、リソースを過剰に消費したりしても、環境全体に影響することはありません。

• マネージド オペレーション: Google Cloud がスケジュールに従ってパッチ適用とアップグレードを処理するため、手動でのアップグレード管理が不要になります。

• 可視性の向上: Google Cloud Monitoring および Cloud Logging とのインテグレーションにより、タスクの実行を明確に可視化できます。エンジニアは、プラットフォーム チームに問題をエスカレーションすることなく、個別にデバッグできるようになりました。

デベロッパー ワークフローの高速化

この移行により、Checkout.com のデータ エンジニアの日常的なワークフローも改善されました。

• デプロイの高速化: DAG に Cloud Storage を使用することで、ほぼ瞬時の同期が可能になりました。

• オンボーディングの簡素化: チームがオンボーディング前に変数を作成する際に、プラットフォーム サポートが不要になりました。

• dbt 実行のモダナイズ: 同社の最も大きな成果の一つが、dbt の実行方法の変更です。以前は、サポートされている dbt バージョンごとに、エンジニアが複雑な仮想環境を手動でインストールして管理する必要がありました。Managed Airflow（第 3 世代）は、コンテナ化された dbt 実行を活用することで、依存関係のボトルネックを解消します。これにより依存関係が完全に分離されるため、チームは最小限の設定で、手動によるインフラストラクチャのオーバーヘッドなしに、必要な dbt モデルを実行できます。

• 環境の更新: 新しいロールを追加したり、Python パッケージを更新したりするために、Airflow 環境全体を再デプロイする必要がなくなりました。

• Gemini Cloud Assist による AI を活用したトラブルシューティング: セルフマネージド環境では、タスクが失敗すると、断片化されたログや指標でその原因を必死に探すことがよくありました。Checkout.com は、Managed Airflow を導入したことで、Google Cloud コンソールの Airflow DAG UI から直接 Gemini による調査を開始できるようになりました。 

Gemini は一般的なエラー メッセージを提供するだけでなく、裏付けとなる証拠と矛盾する証拠の両方を含む、さまざまな仮説の評価スコアカードを生成します。これにより、平均復旧時間を大幅に短縮できます。

まとめ

Checkout.com にとって、Managed Airflow（第 3 世代）への移行が戦略的転換点となり、エンジニアが価値の提供に集中できる環境を整えることができました。

「Managed Service for Apache Airflow を導入したことで、効率、スケーラビリティ、信頼性が大幅に向上しました。マネージド インフラストラクチャ、自動スケーリング、迅速なデプロイ、分離された実行環境により、業務遂行に変革をもたらすことができました。」- Checkout.com、データ プラットフォーム エンジニア、Keisi Mancellari 氏

スケーラブルで費用効率に優れた、安定したプラットフォームを導入したことで、Checkout.com は自社のデータ パイプラインの将来に集中できるようになりました。今後何が起こっても、自社のオーケストレーション レイヤで対応できると確信しています。

Managed Service for Apache Airflow の詳細と、このソリューションがいかにしてデータ プラットフォームをサポートするかをご確認ください。

この投稿にご協力いただいた Serge Bouschet 氏と Keisi Mancellari 氏に心より感謝いたします。

- Managed Airflow、リード プロダクト マネージャー、Piotr Wieczorek

- カスタマー エンジニア、Michelle Liu