Google Cloud Platformのワークフロー
Google Cloud Platform(GCP)では、ワークフローサービスが2つあります。Cloud ComposerとCloud Workflowです。しかしこの2つのサービスですが、Cloud ComposerはPythonゴリゴリ感、Cloud Workflowはyaml地獄感がすごい。(個人の感想です。)
小中規模のワークフローをサクッと作りたいときってないですか? そういう時は、OSSのワークフローエンジンであるDigdagを使うことをオススメします。
Digdagとは
OSSのワークフローエンジンDigdagとは、公式ドキュメントを引用すると次の通りです。
Digdag is a simple tool that helps you to build, run, schedule, and monitor complex pipelines of tasks. It handles dependency resolution so that tasks run in series or in parallel.
Digdagは、複雑なタスクのパイプラインを構築、実行、スケジューリング、監視するためのシンプルなツールです。Digdagは、タスクが直列または並列に実行されるように依存関係を解決します。
Treasure Dataが開発したシンプルでわかりやすく使いやすいワークフローツールです。マルチクラウドと謳っていて、AWS(S3、Redshiftなど)にも対応、GCPではBigQuery, Cloud Storage(GCS)に対応しています。SaaSであるTreasure DataのWorkflow機能は、このDigdagがベースとなっています。(Digdagは当然Treasure Dataにも対応しています。)
Cloud Composerなんか裏でGoogle Kubernetes Engine(GKE)とGoogle App Engine(GAE)とGCSを使って仰々しくてお金かかりそうですし、PythonでDagファイルをゴリゴリ書かないとならないし(テンプレありますが)、フルマネージドですが敷居が高いし、めんどくさいです。(個人の感想です。)
サーバーレス・フルマネージド環境
本記事では環境構築編でDigdagの環境をGCPで作り、次の実践編で実際にワークフローを実行しようと思います。
環境構築編では、Digdagを以下のGCPサービスを使って構築します。
GCPサービス | コメント |
---|---|
Cloud Run | コンテナサーバーレスフルマネージドサービス |
Cloud SQL for PostgreSQL | フルマネージドRDBサービス |
サーバーレスVPCアクセス | CloudRunなどサーバーレスサービスとCloud SQLをプライベート接続するサービス |
Cloud Build | サーバーレスCI/CDプラットフォーム |
Cloud Container Registry | Dockerコンテナのレポジトリ |
また、構築には超便利な(最近AWSも真似した)Cloud Shellを使います。ちなみに、AWSはCloudShellでGCPはCloud Shellです、どうでもいいけど。
環境構築
ここからは実際に環境を構築していく手順です。
バージョン
今回のDigdagバージョンは、0.10.0を使用しました。(最新は0.10.1ですが色々あって)
設定ファイルの準備
設定ファイルとしては、DockerfileとDigdag設定ファイル(ここではdigdag.config)の2つを準備します。
Dockerfile
Dockerfileは、以下の感じにしてみました。
ENV DIGDAG_VERSION 0.10.0
WORKDIR /src
RUN apk update --no-cash && \
apk add --no-cache \
bash \
curl && \
curl -o /usr/local/bin/digdag --create-dirs -L "https://dl.digdag.io/digdag-${DIGDAG_VERSION}" && \
chmod +x /usr/local/bin/digdag
COPY ./digdag.config /etc/digdag/digdag.config
ENTRYPOINT ["java", "-jar", "/usr/local/bin/digdag","server","--config","/etc/digdag/digdag.config"]```
Digdag設定ファイル
Digdagサーバの設定は、ポイントとしてbindを0.0.0.0に設定すること、それとDigdagのデフォルトポートは65432なので65432とadminポートとして65433を設定しました。(ポートは変更も可能です。)
database.hostは、Cloud SQLを作成後にIPアドレスが割り振られてから埋めます。PostgreSQLのデータベース名は"digdag_db"、Digdagの実行ユーザー名を"digdag"とします。
server.bind = 0.0.0.0
server.port = 65432
server.admin.bind = 0.0.0.0
server.admin.port = 65433
database.type = postgresql
database.user = digdag
database.password= ********
database.host = <Cloud SQLのIPアドレス>
database.port = 5432
database.database = digdag_db
database.maximumPoolSize = 32
digdag.secret-encryption-key = *********************
digdag.secret-encryption-keyについては、digdag secretsコマンドで必要になりますので設定します。設定値はDigdagドキュメントの「Secret Encryption Key」に記載があります。
また、本記事では最低限の設定しかしていません(ログ出力とかしてない)が、他にも設定がありますのでDigdagドキュメントを確認して、もし必要な設定があれば追加しましょう。
Cloud Shellに保存
Cloud Shellを起動してフォルダを作成し、そのフォルダの中に上記2ファイルを保存します。
Cloud Shellを起動する
Google Cloudコンソールの右上のCloud Shellのボタンをクリックします。
フォルダを作成する
ここではdigdag-gcpフォルダを作成します。好きな名前で良いです。
フォルダにファイルを保存する
先程の2ファイルをフォルダに保存します。ローカルファイルをCloud Shellにアップロードします。
Cloud SQL for PostgreSQLの作成
公式ドキュメントのInternal architecture-Databaseによると、DIgdagでは、すべてのデータをデータベース(PostgreSQLまたはH2データベース)に保存します。
このPostgreSQLをGCPのフルマネージドサービスであるCloud SQLで作成します。
Cloud SQL for PostgreSQLの作成
Google CloudコンソールからCloud SQLインスタンスを作成します。
インスタンスIDは"digdag-db"にしました。好きなID名でいいです。
データベースのバージョンは最新13を選択します。
リージョンは、この記事ではus-central1にしました。(基本USは安いので)
お金が掛かるので、この記事ではシングルゾーンを選択しています。
マシンタイプですが、ここでは1コアを指定します。(お金が掛かるので)
接続はパブリックIPをチェック、プライベートIPにチェックします。本記事ではネットワークはdefaultを選択しますが、ご自分に合わせたVPCネットワークを選択してください。
ロール(ユーザー)とデータベースの作成
ロール(ユーザー)データベースの作成は、Cloud SQLのPostgreSQLにログインして作成します。gcloud sqlコマンドを使い、PostgreSQLにログインします。
ロール(ユーザー)の作成
データベースの作成
ロールをオーナーとしてデータベース"digdag_db"を作成します。
Extensionの作成
Digdagで使用するPostgreSQLのExtensionであるuuid-osspを作成します。これはUUIDを生成する関数を使えるようにするExtensionです。
digdag.configにプライベートIPアドレスを保存
Cloud Runの設定の前に、digdag.configにCloud SQLに割り振られたプライベートIPアドレスを保存します。
サーバーレスVPCアクセスの設定
Cloud RunとCloud SQLを接続するために、サーバーレスVPCアクセスを使います。
「コネクタを作成」をクリックして、コネクタを作成します。
コネクタ名を"digdag-connector"として、VPCネットワークにCloud SQLと同じ"default"を選択し登録します。
Cloud Runにデプロイ
やっとCloud Runにデプロイします。Cloud Runですが、昔は一度Cloud Buildでビルドするコマンドを実行していましたが、少し前にできたらしい魔法の--sourceを使って一気にデプロイします。Dockerfileとdigdag.configがあるフォルダで、以下のコマンドを実行します。
gcloud beta run deploy digdag-run --region us-central1 \
--platform managed \
--port 65432 \
--allow-unauthenticated \
--vpc-connector digdag-connector \
--source .
このコマンドでは、リージョンをus-central1、ポートをdigdag.configのserver.portに設定したポートを指定します。--vpc-connectorには、先ほど作成したサーバレスVPCアクセスのサービス名を指定します。--sourceはカレントフォルダということで、「.」を指定しています。
実行後、APIが有効になっていない場合は有効にするか聞かれたりしますので、"y"で進んでください。デプロイが完了すると、Service URLが出力されます。(Google Cloudコンソールでも確認できます。)
Google CloudコンソールのCloud Runの画面にも表示されました。
Digdag WEB画面の表示
成功した時に出力されたURLをWEBブラウザで表示します。Cloud Shell上のURLをクリックすると表示されます。
DigdagコマンドラインツールをCloud Shellにインストール
Digdagの操作のためのdigdagコマンドをインストールします。この記事では、便利なのでCloud Shellを使いますが、Cloud Shellを使わずローカルPCでも問題ないです。
Cloud Shellはgcloud, bq, gs, git, docker, kubectlコマンドなど既にインストール済みで最高なのですが、さすがにdigdagコマンドは入っていないので、インストールする必要があります。ドキュメントのGetting startedの1. Downloading the latest versionの通り進めます。
インストールしたら、念のためdigdag --version
で確かめて、バージョンが出力されたら正常にインストールできていることが確認できます。
サーバーレス・フルマネージドDigdag環境完成
Google推し推しのサーバレスCloud RunとフルマネージドRDBであるCloud SQLでDigdag環境を作ることができました。
実用を考えると、セキュリティ面ではこの記事では触れませんが、Identity-Aware Proxy(IAP)を使ってログインするようにしたいところです。また、Cloud RunでアクセスできるIPアドレスを制限したい場合、現時点ではGAEのようにFirewallがありませんし、実現するにはロードバランサーが必要のようです。(ロードバランサーはお金掛かりますし、GAEと同じくFirewall機能を作って欲しいところです。)
Cloud SQLとはプライベート接続できて、Cloud SQLをグローバルに晒す必要はなく安全と言えます。
実際に実用するとなると、上記のようにセキュリティについて、そしてスペックは考える必要があります。
(マネージドDigdagであるWorkflowを利用できるTreasure Dataは、セキュリティもしっかりしてます|д゚)チラッ)
次の実践編では、実際にサーバーレス・フルマネージドDigdagを実行してみます。(しかし、実際動かすと問題が・・・続く)