prefect
用語
prefect cloud
マスターサーバー的な。実行タスクの管理を行う
worker
ワーカーノード的な
マスターサーバーから実行ジョブ定義（deployment）を取得して、そのとおりに動作（flowの実行）させる
work pool
flow/taskの実行環境
workerから実行されたflowのこと
flow
単一のジョブ。さらにtaskという粒度でもかける
flow同士でも実行順序を依存させたりできる
vs airflow
airflowでの実現が一筋縄で行かない方法
イベント駆動、スケジュール無しで実行する
複雑な分岐をもつ
動的に生成
欠点
あるワークフローが同じexecution_dateで実行されることはない
定刻以外で実行する場合は難しい
手動で実行
複数を同時実行する
など
スケジューラを持っているために、タスクの実行までに時間がかかる
リアルタイム処理を意識した場合、ボトルネックとなりうる
job間のデータの依存などがある場合
xcoms（内蔵のデータベース）を使ったりするが、これはTTLや有効期限がないためコストの問題になる
上流のタスクが失敗したときなどに自前でハンドリングする必要がある
また、xcomsに大きなデータはのせられないなどの問題もある
タスクのスケジューラは外部にもたせている
タスク間のデータの共有ができる。依存関係などの定義も明示的にしている
ワークフローに更新が入った場合、バージョン管理が行われる
構成
cloup版
メタデータなどはcloudに記録される
スケジューリングなどの実行順序管理周りはcloud上に送信される
agent（worker）
ワークフローの実行や監視は手元（worker環境）で行われる
タスク結果は外部ストレージに保存もできる
results を使う
prefect cloud
無料枠来ている
project init
code:sh
prefect init
... # gitを選択
prefect.yaml
launch server
code:sh
prefect server start
...
___ ___ ___ ___ ___ ___ _____
| _ \ _ \ __| __| __/ __|_ _|
| _/ / _|| _|| _| (__ | |
|_| |_|_\___|_| |___\___| |_|
how to 参考
設定周り
work pools
フロー実行環境を動的に設置できる。ワールプールというところでフローのための実行環境が動的に整備される
flow.serve()を使ったデプロイでは、prefectのサーバー上で実行される
サーバー（オーケストレーション環境）と実行環境を繋ぐ役割を持つ
インフラ的に分離したいときはflow.deployment()を使う
on cloud run
サービスアカウント作成
prefectからcloud runをjobとして実行する権限をもつ
"roles/run.admin" "roles/iam.serviceAccountUser"
work pool作成
適当に設定
サービスアカウントのjsonkeyファイル設定する
flow開発
prefect init --recipe dockerを実行すると
image_name tag の入力インターフェイスから入力
image_name: us-docker.pkg.dev/{project-id}/{artifact-registry-name}/{image-name} tag: latest
prefect.yamlがなければ作成される。作り直したい場合は削除すると良い
deploymentsセクションをflowの定義で書き換える。多分imageのentry pointとかになる
deploy
prefect deploy するとbuild->pushが実行される
prefect.yamlの設定に準じて、Dockerfileが作られる
📝 deploymentsセクションを dockerfile: auto にしておくと毎回作られる。そのせいか再実行時点エラー出るので、一回作られたらdockerfile: Dockerfileのvalueにしておくと良い
作成されたdeploymentをrunするとcloud runのjobが作成されるconsole画面から確認できる
prefectのエラーログとcloud runのエラーログが噛み合わないことがある
prefect This may be caused by attempting to run an image with a misspecified platform or architecture.
cloud run job textPayload: "prefect.exceptions.ScriptError: Script at 'main.py' encountered an exception: ModuleNotFoundError("No module named 'prefect_dbt'")"
on coiled
pythonのスクリプトを軽量に動かせるサービス
prefectのdeploymentとして動かせる
dockerでdeployment作る？
deploymentとworkflowとワーカーの関係
deploymentにてflow run（実行環境）を監視する、
prefect serverにて、実行結果の管理を行う
https://gyazo.com/7461746662b997d44e8affe72409919e
疑問点 with ChatGPT
エージェント とPrefectサーバーが分かれているの不思議なのですが、なぜ？
GPT > Prefectのアーキテクチャにおいて、エージェントとPrefectサーバー（OrionサーバーやPrefect Cloud）が分かれている理由は、システムの柔軟性、スケーラビリティ、セキュリティ、および役割の分離を実現するためです。これにはいくつかの重要な理由と利点があります。
1. 役割の分離
Prefectサーバーとエージェントにはそれぞれ異なる役割があります。
Prefectサーバー（Orionサーバー/Prefect Cloud）:
中央管理とオーケストレーション: フローの定義、スケジューリング、実行状況の管理、ログの収集などを担当します。
データの保存と監視: 実行結果、メタデータ、ログ、エラーなどの情報を保存し、ユーザーがフローの実行状況を監視できるようにします。
ユーザーインターフェース: フローの管理やモニタリングのためのUI（Webアプリケーション）を提供します。
エージェント:
フローランの実行: フローラン（フローの実行インスタンス）を実際に実行します。指定された実行環境（ローカル、クラウド、Kubernetesなど）でフローのタスクを実行し、その結果をPrefectサーバーに報告します。
実行環境の分離と管理: エージェントは異なる実行環境で動作することができ、特定のフローランを特定のインフラ上で実行するように設定できます。
2. 柔軟性とスケーラビリティ
分離されたアーキテクチャにより、エージェントとサーバーを独立してスケールアウトできます。
エージェントのスケーラビリティ: 必要に応じてエージェントの数を増やすことで、フローランの並行実行数を増加させることができます。これは特に大規模なデータパイプラインやワークロードが重い場合に有効です。
サーバーのスケーラビリティ: Prefectサーバーは、負荷が増加してもエージェントの管理やデータの保存、ユーザーインターフェースの提供に専念できるよう、独立してスケールアウトできます。
3. セキュリティとコンプライアンス
エージェントとサーバーが分離されていることで、セキュリティとデータアクセスの制御が容易になります。
データの分離: エージェントはデータを扱う環境（例えばデータベースやストレージへのアクセス権限）に配置されるため、セキュリティやコンプライアンスの要件を満たしやすくなります。
セキュアな通信: エージェントとサーバー間の通信は、セキュアなプロトコル（例：HTTPS）を使用して行われるため、データの安全性が保たれます。
4. 異なる環境での実行
Prefectのエージェントは、異なる実行環境（ローカル、クラウド、Kubernetesなど）で動作するフローランを実行するための柔軟性を提供します。
異なるクラウドプロバイダー: 同じPrefectサーバーに接続されているエージェントは、異なるクラウドプロバイダーやオンプレミス環境で動作するフローランを処理できます。
特定のリソースにアクセス: 特定のエージェントを特定のネットワークやセキュアな環境に配置することで、機密データや特定のリソースへのアクセスを制御できます。
まとめ
エージェントとPrefectサーバーが分離されている理由は、役割の分離による責務の明確化、システムの柔軟性とスケーラビリティの向上、セキュリティとコンプライアンスの強化、および多様な実行環境への対応が可能になるためです。このアーキテクチャにより、Prefectは異なるインフラストラクチャや運用要件に柔軟に対応する強力なワークフローオーケストレーションプラットフォームを提供します。
細かい機能
トランザクション
タスクの制御。実行回数などを指定できる
タスクのキャッシュ
キャッシュを有効にすることでタスクの結果を保持し、該当タスクをスキップする
結果の保持する場所は設定できる
with cloud run
Cloud Run Admin API を有効にする