あなたは、データ処理・モデル学習・モデルデプロイを行う機械学習パイプラインを作成しようとしています。このパイプラインでは、複数の Google Cloud サービスを利用します。各タスクごとのコードはすでに実装済みであり、今後は新しいファイルが高い頻度で追加されると予想しています。
これらのタスクの上にオーケストレーションレイヤーを構築する必要がありますが、このパイプラインは Cloud Storage バケット内のデータセットに新しいファイルが存在する場合にのみ実行したい と考えています。また、コンピュートノードのコストを最小限に抑えたい という要件もあります。
このとき、どうすべきでしょうか？
正解：C
この問題では、二つの要件がはっきり示されています。ひとつは「Cloud Storage バケットに新しいファイルがあるときだけパイプラインを実行したい」というイベントドリブンな実行条件、もうひとつは「コンピュートノードのコストを最小限に抑えたい」というコスト制約です。この二つを同時に満たす設計を考える必要があります。
まず、Cloud Composer を使う B と D の案から考えてみると、Cloud Composer（Managed Airflow）は常に稼働するワーカーノードを持つため、Airflow 環境自体を立ち上げておくだけでそれなりのコンピュートコストが発生します。特にこの問題では、ファイル到着時にだけパイプラインを動かしたい、つまり「普段は何もしていない時間が多い」可能性が高いため、常時稼働型の Composer はコスト最適化の観点からあまり好ましくありません。D は GCSObjectUpdateSensor によって新ファイルを検知する仕組みを提案していますが、センサーが動作するためには Airflow 環境自体が常に動いている必要があるため、「コンピュートノードのコストを最小化する」という要件と矛盾します。B に至っては、Cloud Functions から DAG を「デプロイする」という少し不自然な構成であり、オーケストレーションの設計としても過剰かつ複雑です。
次に Vertex AI Pipelines を使う A と C を比較します。A の場合、スケジューラーで一定間隔ごとにパイプラインを起動し、その中の最初のステップで「前回実行時から新しいファイルがあるかどうか」をチェックする構成になっています。一見すると悪くないように見えますが、この方法では新しいファイルがなくてもパイプライン自体は定期的に起動されてしまいます。パイプラインの起動ごとに基盤側でオーケストレーション環境が立ち上がるため、無駄な実行が増え、コストやオーバーヘッドも積み上がります。「新しいファイルがあるときだけ動かしたい」という要件を素直に満たしているとは言えません。
それに対して C は、Vertex AI Pipelines で機械学習パイプラインを構成し、そのパイプラインの実行トリガーとして Cloud Functions を用いる構成です。Cloud Functions は Cloud Storage のイベントトリガー（たとえば OBJECT_FINALIZE）を利用することで、新しいファイルがバケットにアップロードされたタイミングでのみ発火させることができます。この Cloud Functions から Vertex AI Pipelines のパイプライン実行を API 経由で開始すれば、「新しいファイルが来たときだけパイプラインを走らせる」という要件を自然に満たせます。さらに、Vertex AI Pipelines はマネージドなサーバレス型のオーケストレーションに近い動きをするため、パイプライン実行時のみリソースを使い、常時稼働のワーカーノードを自前で維持する必要はありません。Cloud Functions もイベントベースで短時間だけ動作するため、アイドル時のコンピュートコストはほぼゼロにできます。この点で C は、イベントドリブン実行とコスト最適化という二つの要件を最もバランスよく満たす構成です。
以上から、Cloud Composer のような常時稼働が必要なオーケストレーション基盤ではなく、Cloud Storage トリガーでイベントを受け、必要なときだけ Vertex AI Pipelines を起動するという構成を取れる C が、問題文の要件に最も適した正解となります。
コメント