Workflows のベスト プラクティス

Workflows を使用してサービスをオーケストレートする場合は、ここに記載されているベスト プラクティスを参照してください。

これは、推奨事項をすべて網羅したものではありません。また、Workflows 使用方法の基本についての説明もありません。このドキュメントは、 Google Cloud のランドスケープと Workflows に関する全般的な知識があることを前提としています。詳細については、Google Cloud Well-Architected Framework と Workflows の概要をご覧ください。

最適な通信パターンを選択する

複数のサービスをデプロイするマイクロサービス アーキテクチャを設計する際は、次の通信パターンから選択できます。

  • サービス間の直接通信

  • 間接的なイベント ドリブン通信（コレオグラフィとも言う）

  • 自動化された構成、調整、管理（オーケストレーションとも言う）

上記の各オプションのメリットとデメリットを考慮して、ユースケースに最適なパターンを選択してください。たとえば、サービス間の直接通信は他のオプションよりも実装が簡単ですが、サービスが密結合になります。一方、イベント ドリブン アーキテクチャでは、サービスが疎結合されます。ただし、モニタリングとデバッグはより複雑になることがあります。最後に、Workflows のような中央のオーケストレーターは、柔軟性は低いものの、サービス間の直接通信の密結合や、複雑なイベントの調整を必要とせずに、サービス間の通信を調整できます。

通信パターンを組み合わせることもできます。たとえば、イベント ドリブン オーケストレーションでは、密接に関連するサービスは、イベントによってトリガーされるオーケストレーションで管理されます。同様に、1 つのオーケストレーションが別のオーケストレーション システムへの Pub/Sub メッセージになるシステムを設計することもできます。

全般的なヒント

Workflows をサービス オーケストレーターとして使用することに決めたら、次のヒントを参考にしてください。

URL のハードコーディングを避ける

ハードコードされた URL を避けることで、複数の環境間で移植可能で、保守しやすいワークフローをサポートできます。これは次の方法で実現できます。

  • URL をランタイム引数として定義します。

    これは、クライアント ライブラリまたは API を介してワークフローが呼び出される場合に役立ちます。（ただし、ワークフローが Eventarc のイベントによってトリガーされ、渡すことができる引数がイベント ペイロードのみの場合は、この方法は機能しません）。

    例

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    ワークフローを実行するときに、URL を指定できます。次に例を示します。

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • 環境変数を使用して、デプロイ先の環境に応じて動的に構成されるワークフローを作成します。または、テンプレートとして再利用でき、個別に管理される環境変数に従って構成できるワークフローを作成します。

  • 1 つのワークフロー定義ファイルを作成し、ワークフロー内のプレースホルダを置き換えるツールを使用してバリアントをデプロイできる置換手法を使用します。たとえば、Cloud Build を使用してワークフローをデプロイし、Cloud Build 構成ファイルで、ワークフロー内のプレースホルダ URL を置き換えるステップを追加できます。

    例

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    そうすると、ビルド時に変数値を置換できます。次に例を示します。

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    詳細については、CLI と API を使用してビルドを送信するをご覧ください。

    または、Terraform を使用してインフラストラクチャをプロビジョニングし、入力変数を使用して各環境のワークフローを作成する構成ファイルを定義することもできます。

    例

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    構成のルート モジュールで変数が宣言される場合、変数は、さまざまな方法で割り当てられた値にすることができます。次に例を示します。

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Secret Manager コネクタを使用して、URL を Secret Manager に安全に保存し、取得します。

ネストされたステップを使用する

すべてのワークフローには、少なくとも 1 つのステップが必要です。 デフォルトで、Workflows は、ステップが順序付きのリストにあるかのように扱い、すべてのステップが実行されるまで、ステップを 1 つずつ実行します。論理的には、一部のステップはグループ化する必要があります。steps ブロックを使用して、一連のステップをネストできます。これにより、一連のステップを処理するために正しいアトミック ステップを指定できるため便利です。

例

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput