Cloud Scheduler での HTTP リクエストのタイムアウトを調査してみた | DevelopersIO

Cloud Scheduler の HTTP ターゲットで Cloud Run Function を呼び出してみた | DevelopersIO

BigQuery テーブル作成イベントで、description の日本語をカラム名にしたビューをバッチ処理で作成してみた。 | DevelopersIO

Cloud Storageにオブジェクトが置かれたらAmazon S3に転送するCloud Run FunctionsをPythonで書いた [Google Cloud --> AWS] | DevelopersIO

Google Cloud の Cloud Storage にオブジェクトが作られたことを検知して、それをトリガにAWSのAmazon S3に転送(push)する... ということをやってくれるCloud Run Functionsをつくりました

BigQuery テーブル更新トリガで、Dataplex のプロファイリングを実行してみた。 | DevelopersIO

Cloud Functions と Secret Manager でサービスアカウントキーローテーションを自動化してみた。 | DevelopersIO

こんにちは、みかみです。 仕事中に犬が「遊べ」とおもちゃの紐を持ってくるので、無視を貫き通していたら、肩に紐を置いて去ってゆきました（このくさい紐をどうしろと？ はじめに 2024/04以降に Google Cloud プロジェクトを作成した場合、デフォルトで有効になる組織ポリシーがいくつか追加になりました。 いずれもセキュリティ強化に関する項目です。 2024/04以前に作成した Google Cloud プロジェクトをお使いの場合には、一部のポリシーを除き自動で有効にはならないので、一度組織ポリシーを見直してみるのも良いのではないかと思います。 デフォルトで安全な組織リソースの管理 ｜ Resource Manager ドキュメント デフォルトで有効化されることになった組織ポリシーの中に、下記、サービスアカウントに関するポリシーがあります。 サービスアカウントキー作成を無効にする： iam.disableServiceAccountKeyCreation その名の通り、サービスアカウントキーの発行を禁止する組織ポリシーです。 Google Cloud では、近年、サービスアカウントの認証には、キー情報ではなく Workload Identity 連携を利用することが推奨されています。 Workload Identity 連携 ｜ IAM ドキュメント とはいえ、これまでずっとサービスアカウントキーを利用して本番運用しているシステムなど、認証方法の変更が簡単にできないケースもあるのではないでしょうか。 そんな時には、以下の組織ポリシーを有効にして、サービスアカウントキーローテーションを強制することを検討しても良いのではないかと思います。 なお、こちらのポリシーは2024/04以降もデフォルト有効にはなりません。 サービス アカウント キーの有効期限（時間）： constraints/iam.serviceAccountKeyExpiryHours 特定のサービスの制約 ｜ Resource Manager ドキュメント サービス アカウント キーの有効期間を制限する ｜ Resource Manager ドキュメント ですが、人間は忘れる生き物です。 手動でのキーローテーションを想定している場合、作業を忘れてシステム障害が発生するリスクも否定できません。 また、定期的なローテーション作業には労力がかかることになります。 ということで。 やりたいこと サービスアカウントキーを定期的に自動でローテーションしたい Cloud Functions をスケジュール起動して、Secret Manager に登録済みのサービスアカウントキーを新しいキーに置き換えたい 前提 Google Cloud SDK（gcloud コマンド）の実行環境は準備済みであるものとします。 本エントリでは、Cloud Shell を使用しました。 Cloud Shell の使用 ｜ Cloud Shell ドキュメント また、Cloud Functions や Secret Manager など各サービス操作に必要な API の有効化と必要な権限は付与済みです。 なお、文中、プロジェクトIDに関する一部の文字は伏字に変更しています。 [準備]Secret Manager のシークレットを作成 以下のコマンドで、サービスアカウントキーを保管しておく Secret Manager のシークレットを作成しておきます。 [準備]サービスアカウントを作成 以下のコマンドで、検証用のサービスアカウントを作成しました。 [準備]サービスアカウントキーを作成して Secret Manager に登録する ローテーションするサービスアカウントキーを作成して、Secret Manager に登録します。 後ほど Cloud Functions で実行するため、以下の Pyhon コードで実行しました。 念のため、正常にシークレットバージョンが登録されたか確認しておきます。 …

Cloud Tasksで複数のCloud Functionsを非同期に呼び出してみた | DevelopersIO

Google Cloudデータエンジニアのはんざわです。 前回の記事では、Cloud Tasksの簡単な概要を紹介した後に単一のCloud FunctionsをCloud Tasksで呼び出す方法を紹介しました。 今回のブログでは、Cloud Tasksで複数のCloud Functionsを非同期に呼び出してみたいと思います。 前回と同様にCloud Tasksでタスクを作成し、Cloud Functionsを呼び出しますが、複数のCloud Functionsを呼び出す場合、その呼び出す数だけタスクを作成する必要があります。 ひとつずつタスクを作成するのは現実的ではないため、Pythonのクライアントライブラリで複数のタスクをまとめて作成したいと思います。 事前準備 今回の検証では、以下のリソースを準備します。 Cloud Tasksのキュー Cloud Tasksから呼び出されるCloud Functions Cloud Tasksのタスクを作成するCloud Functions さっそく作成していきましょう。 Cloud Tasksのキュー まずは、Cloud Tasksのキューを作成します。 次のキャプチャのような構成でキューを作成しました。 名前: exec-cloud-functions 最大ディスバッチ数: 10 / 秒 最大同時ディスバッチ数: 2 最大同時ディスバッチ数で最大並列数を２に制限しているため、同時に実行されるCloud Functionsは２つのみになる想定です。 これらのオプションの詳細は前回のブログで紹介しているので、興味がある方は是非確認してみてください。 Cloud Tasksから呼び出されるCloud Functions 次にCloud Tasksから呼び出されるCloud Functionsをデプロイします。 以下のコードをexec-by-tasksという名前でデプロイしました。 見ての通り、処理はシンプルで、Cloud Functionsが受け取ったリクエストボディから変数を受け取り、出力するだけです。 また、後続で呼び出されるCloud Functionsの挙動も確認したいため、5秒間のスリープを仕込んでいます。 Cloud Tasksのタスクを作成するCloud Functions 最後にCloud Tasksのタスクを作成するCloud Functionsをデプロイします。 上記のドキュメントを参考にHTTPタスクをPythonで作成します。 処理の流れとしては、1から10までの数字をリクエストボディのパラメータに加えたタスクを順次作成し、それをキューに送信しています。 さっそく動かしてみる まずはcreate-tasksを起動してタスクをキューに送信します。 Cloud Loggingを確認すると次のキャプチャのようにログが出力されていました。 タスクがキューに送信されるとそのタスクの終了を待たず、非同期に次のタスクが送信されていることがわかると思います。 次にexec-by-tasksのログも確認します。 1番目と2番目は、ほぼ同時に呼び出されていますが、3番目と4番目は1番目と2番目が終了してから呼び出されていることがわかると思います。 これは事前にキューの設定で最大同時ディスバッチ数を2にしたため、同時に2つまでしか実行されないようにキューが制御しています。 制限事項 Cloud Tasksにもいくつか制限事項があります。詳細は、上記のドキュメントを確認してみてください。 特に気を付けるべき項目は次の2点だと思いますので実装する際は気をつけてください。 1分あたりで作成できるAPIリクエストの合計数が600万回 キューに追加できるタスクの最大サイズが1MB まとめ 今回は、Cloud Tasksで複数のCloud Functionsを非同期に呼び出してみました。 シンプルに1から10までの数字をリクエストボディに含めてみました。他の例として、バケットからファイルの一覧を取得して、それらをリクエストボディに含めて何らかの処理をさせたりすることも可能だと思います。 正確に並列数を制御したい場合、Cloud Tasksは有効なサービスだと思うので、是非利用を検討してみてください。

Google Cloud Tasksを完全に理解する | DevelopersIO

Google Cloudデータエンジニアのはんざわです。 つい最近、Cloud Tasksを触ってみる機会があり、そこで学んだことや実際に動かしてみた内容を共有したいと思います。 今回の記事では、Cloud Tasksの概要を整理し、単一のCloud FunctionsをCloud Tasksで起動するまでの流れを実際に構築してみたいと思います。 Cloud Tasksの概要 Cloud Tasksは、大量の分散タスクの実行、ディスパッチ、配信を管理できるフルマネージドサービスです。 Cloud Tasksを使用すると非同期処理を簡単に実装でき、実行のタイミングや回数などを柔軟に制御することが可能です。 公式ドキュメントで紹介されている通り、主なユースケースとしては、次のようなものがあります。 データベースの更新のようなバックグラウンド処理に時間がかかる可能性のある処理をワーカーに委譲することで、ユーザの応答時間を短縮する 予期せぬ本番インシデントが発生した場合にリクエストを維持する メインユーザフローから非ユーザ向けタスクを削除することでトラフィックの急増をスムーズにする サードパーティのAPIコールレートを管理する もう少し詳しく Cloud Tasksには、タスクとキューが存在し、それぞれ異なる役割を持っています。 タスクとキューは以下の画像のような構成になっています。 処理の流れは以下の通りです。 「メールを送信する」や「データを加工する」などの実行したい処理を呼び出すリクエストをタスクとして登録する タスクはキューに追加され、正常に実行されるまでタスクは保持される キューはそのタスクをユーザーが定義したレートで「メールを送信する」や「データを加工する」などの実行したい処理をするターゲットにリクエストを送信する キューが正常なHTTPレスポンスコード（200〜299）を受け取ったらそのまま終了し、別のレスポンスが送信されたり、レスポンスがない場合はタスクが再試行される 続いて、タスクとキューについてもう少し詳しく見てみたいと思います。 タスクについて タスクは、 「メールを送信する」や「データを加工する」などの実行したい処理を呼び出すリクエストに該当します。 タスクで定義したリクエストの送信先は、HTTP/Sエンドポイント と App Engineアプリケーション の２つがあります。 HTTP/SエンドポイントであればCloud Functions、Cloud Run、GKE、Compute Engine、またはオンプレミスのウェブサーバーなどにリクエストを送信することが可能です。 これらのリクエストを受け取り、処理を実行するエンドポイントを ワーカー と呼びます。 HTTP/Sのタスクの場合、すべてのワーカーは、デフォルトのタイムアウトが10分で最大でも３０分以内にHTTPレスポンスコード（200～299）を送信する必要があります。別のレスポンスが送信されたり、レスポンスがない場合はタスクが再試行されてしまうので注意しましょう。 キューについて キューは、タスクが追加されるとユーザーが定義したレートでワーカーにリクエストを送信し、確実に処理されるようにします。 ワーカに送信するリクエストのレートに関しては、後ほどCloud Tasksを準備するパートで紹介します。 実際に動かしてみる Cloud Functionsの準備 まずは呼び出されるCloud Functionsをデプロイします。 設定内容は次の通りです。その他の項目は全てデフォルトの設定を使用しています。 名前： exec-by-tasks リージョン： asia-northeast1 Cloud Functionsをセキュアーに呼び出すためにトリガーのタイプをHTTPSに設定し、認証は認証が必要に設定しました。 また、ソースコードは次のようなシンプルなものを用意しました。 サービスアカウントの準備 次にCloud TasksがCloud Functionsを呼び出す際に使用するサービスアカウントの準備をします。 今回の検証では、Cloud Functionsを認証が必要なHTTPSトリガーに設定しているため、HTTPリクエストに認証情報を含める必要があります。 一般的にCloud FunctionsやCloud Runにリクエストを送信するときは、OpenID Connect（OIDC）を使用して認証します。 つまり、タスクを実行するサービスアカウントがOIDCから認証情報を取得できるように適切な権限を付与する必要があります。 一見難しそうに見えますが、実際にはとても簡単です。 まずは、OIDCから認証情報を取得するサービスアカウントを作成します。名前は次の通りです。 名前： cloud-tasks さらに、このサービスアカウントが事前にデプロイした第２世代のCloud Functionsを実行するためにサービス単位でroles/run.invoker（Cloud Run 起動元）の権限を割り当てます。 これでCloud TasksからCloud FunctionsにHTTPリクエストを送信する際、OIDCで取得した認証情報を含められるようになりました。 Cloud Tasksのキューの準備 次にCloud Tasksのキューを作成します。 名前とリージョンは次の通りです。 名前： exec-cloud-functions リージョン： asia-northeast1 キューの詳細設定は、以下のキャプチャの通りです。 ディスパッチとは、キューのタスクをワーカーに送信することを指します。 つまり、最大ディスパッチ数は、１秒間にキューからタスクをワーカーに送信する最大レート数を指します。 同様に最大同時ディスパッチ数は、Cloud Tasksがキューからタスクをワーカーに送信することを許可する最大数に該当します。 これらのパラメータを適切に設定することでAPIコールレートなどを管理し、バックエンドシステムへの負荷の調整が可能になります。 また、各パラメータの詳細は以下のドキュメントで確認してください。 タスクを作成してCloud Functionsを実行してみる 次に作成したキューからCREATE HTTP TASKを選択し、タスクを作成します。 入力内容は以下のキャプチャの通りです。 注意点として、AuthヘッダーにOIDC トークンを追加を選択し、事前に作成したサービスアカウントを割り当てるようにしましょう。 しかし、Cloud Functionsのログを確認すると415エラーが発生していました。。。 …

BigQueryのリモート関数実行中にCloud Functionsでジョブをキャンセルしてみた | DevelopersIO

Google Cloudデータエンジニアのはんざわです。 先日、BigQueryのリモート関数で呼び出されたCloud Functionsから直接リモート関数を実行しているジョブをキャンセルさせたいケースがありました。 本ブログの検証項目は以下の通りです。 リモート関数で呼び出されたCloud Functionsから直接リモート関数を実行しているジョブをキャンセルする そもそもリモート関数とは？ 簡単にBigQueryのリモート関数を紹介すると、BigQueryでCloud FunctionsやCloud Runのような外部データソースの関数を呼び出すことができる機能です。 以下はリモート関数に関連するブログ記事になります。 検証の前提条件 リモート関数からCloud Functionsを呼び出します 今回の検証で使用するCloud Functionsの設定は以下の通りです 世代： 第2世代 ランタイム： Python 3.12 リージョン： asia-northeast1 メモリ： 256 MiB CPU： 0.167 vCPU タイムアウト： 30分 検証 リモート関数で呼び出されたCloud Functionsから直接リモート関数を実行しているジョブをキャンセルできるか検証してみます。 リソースの準備 リモート関数から呼び出されるCloud FunctionsのPythonのソースコードとパッケージは以下の通りです。 処理の概要として、入力データからBigQueryのジョブIDを取得し、BigQueryのAPIクライアントから対象のジョブをキャンセルさせる流れになっています。 本ブログでは省略しますがリモート関数のデプロイ方法は、以下のブログのCLOUD_RESOURCE 接続を作成とリモート関数を作成の項目を確認してください。 動かしてみる さっそくですが、以下のクエリでリモート関数を呼び出してみます。 少し待ちましたが終わりませんね… ログを確認してみましょう Cloud Loggingからログを確認すると以下のログが繰り返し流れていました。 ログの詳細は以下の通りです。 ログの詳細を確認するとbigquery.jobs.updateの権限が不足しているため、対象のジョブをキャンセルできないと403エラーが発生していることがわかりました。 再度動かしてみる 不足している権限を付与してから再度動かしてみます。 bigquery.jobs.updateの権限を保有している事前定義済みロールは、roles/bigquery.adminとroles/bigquery.studioAdminの２つのみでした。 今回の検証では、roles/bigquery.adminの権限を付与しますが、非常に強い権限になりますので必要に応じて、カスタムロールの作成を検討してください。 権限を付与した後に再度同じクエリでリモート関数を呼び出してみます。 期待していた通りにジョブをキャンセルすることができました！ まとめ 今回は、リモート関数で呼び出されたCloud Functionsから直接リモート関数を実行しているジョブをキャンセルする検証を実施しました。 開始当初に期待していた通りの結果になったので良かったです。 Cloud Functionsがリモート関数から受け取ったデータの中に不都合があった際などに利用していただけると良いと思います。

BigQueryのスケジュールされたクエリをPythonで呼び出してみる | DevelopersIO

Google Cloudデータエンジニアのはんざわです。 この記事では、BigQueryのスケジュールされたクエリをPythonでコールしてみたいと思います。 検証内容 BigQueryのスケジュールされたクエリは、Bi …