あなたは Kubeflow Pipelines を使って、PyTorch ベースのエンドツーエンドな MLOps パイプラインを開発しています。
このパイプラインは BigQuery からデータを読み込み、その後データ処理、特徴量エンジニアリング、モデル学習、モデル評価を行い、最終的にモデルをバイナリファイルとして Cloud Storage にデプロイします。
あなたは 特徴量エンジニアリングとモデル学習ステップについて、複数バージョンのコードを書いては試しており、それぞれを Vertex AI Pipelines 上で実行しています。
しかし、各パイプライン実行には 1 時間以上かかっています。開発時間を短縮するためにパイプラインの実行を高速化したいと考えていますが、追加コストは発生させたくありません。
どうすべきでしょうか？
正解：B
この問題のポイントは、「開発サイクルを早く回したい」というニーズと、「追加の費用はかけたくない」というコスト制約が同時に存在している点です。Kubeflow/Vertex AI Pipelines を使っている状況で、何度もパイプラインを回しながら feature engineering や学習ロジックを改善している、まさに実務の MLOps 開発フェーズを想定したシナリオになっています。
まず、パイプライン全体に 1 時間以上かかっているということは、多くのステップが毎回最初から実行されているということです。しかし、実際にコードを頻繁に変更しているのは特徴量エンジニアリングやモデル学習の一部であり、データの読み込みや前処理など、毎回同じ処理結果になるステップも多く含まれているはずです。ここで有効なのが Kubeflow Pipelines の「キャッシュ機能」です。キャッシュを有効化しておくと、入力パラメータやコードに変更がないステップについては、前回実行時の出力をそのまま再利用することができます。その結果、そのステップを再実行せずに済むため、パイプライン全体の実行時間を大きく短縮できます。
特にこの問題のように、「何度もパイプラインを回してコードを微調整している」場合、毎回 BigQuery からの読み込みや前処理、変わっていない評価ステップなどを一から再実行するのは明らかに無駄です。キャッシュを有効にしておけば、「変更したステップ以降」だけが再実行され、手を加えていない前段の処理はキャッシュ結果が使われるため、開発効率が飛躍的に向上します。そして、キャッシュは追加の GPU や強力なマシンタイプを購入するわけではなく、仕組みとしての再利用を行うだけなので、「追加コストをかけずに高速化する」という要件にも合致します。したがって、最も合理的な選択肢は B：すべてのステップでキャッシングを有効化する です。
一方、A の「コメントアウトする」という方法は、手作業でパイプラインを部分的に無効化するアイデアですが、これではオーケストレーションとしての一貫性が崩れますし、毎回定義を書き換える必要があり、管理もミスも増えます。また、コメントアウトしても、前段のステップ（データ読み込みや前処理など）が毎回フル実行されるので、時間短縮効果は限定的です。
C は一見「BigQuery に寄せた方が速そうだ」と感じるかもしれませんが、問題が問うているのは「構成を大きく作り替えること」ではなく、「開発中のパイプライン実行をどう効率化するか」です。特徴量エンジニアリングを BigQuery に出してしまうのは設計変更に近く、PyTorch ベースのパイプライン全体との整合性や、既に書いているコードとの再利用性も落ちます。また、BigQuery に処理を移してもクエリコストが余計にかかる可能性があり、「追加コストを避けたい」という要件ともややずれます。
D の GPU 追加は、モデル学習時間を短縮できる可能性はありますが、GPU は明確に追加コストを増やす方向の解決策です。問題文にはっきりと「追加の費用は発生させたくない」とあるため、ここで GPU を選ぶのは要件違反になります。
以上を踏まえると、既存の構成を大きく変えず、追加コストもかけずに、かつ開発ループを高速化できるのは ステップキャッシュを有効にすること（B） であり、これが Professional Machine Learning Engineer 試験としての模範的な解答となります。
コメント