ソリューション

Earth Engine からの衛星画像を BigQuery の表形式データに変換

Tue, 28 Jun 2022 10:23:00 +0000

※この投稿は米国時間 2022 年 6 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

地理空間データには、従来のマッピング以外にも、場所の選定や土地インテリジェンスなどの多くの用途があります。そのため、多くの企業が地理空間データをデータウェアハウスや分析に組み込む方法を見出そうとしています。Google Earth Engine と BigQuery はどちらも、地理空間データの解釈、分析、可視化に使用できる Google Cloud Platform 上のツールです。たとえば、Google Earth Engine から取得した衛星データに基づく作物分類を BigQuery の天候データと組み合わせて作物の収穫量を予測できます。

これら 2 つのプロダクトの機能は一部重複していますが、両者は同じものではなく、次の表に示すように異なるユースケース向けに設計されています。このブログでは、地理空間データを Google Earth Engine から BigQuery に移動する方法と必要なデータ形式の変更について説明します。

Earth Engine と BigQuery

Earth Engine は優れた可視化機能とデータカタログを備えているため、地理空間ソリューションの発見 / 開発段階などで重要な役割を果たします。BigQuery は完成されたデータウェアハウスと評価されており、非地理空間データセットが関与するソリューションに役立ちます。両方のツールを併用したいと思うユースケースは数多くあります。ここから、「Earth Engine のデータを BigQuery に移動するにはどうすればよいだろうか？」という疑問が浮かんできます。

Geobeam を使用して Earth Engine のデータを BigQuery に移動

地理空間データには多くの形態、ファイル形式、投影座標系があるため、ツール間でのデータの移動は簡単ではありません。ただし、Geobeam という比較的新しいオープンソースライブラリは、Earth Engine と BigQuery のギャップを埋めるために役立ちます。

Geobeam は Apache Beam を拡張する Python ライブラリで、Dataflow を使用して大量の地理空間データを並列で取り込んで分析するのに使用できます。Geobeam は、地理空間データの読み取り、処理、書き込みを容易にする一連の FileBasedSource クラスと Apache Beam 変換を備えています。

このブログでは、Geobeam を使用して Earth Engine から取得した GeoTIFF 形式のラスターデータセットを BigQuery にベクターデータテーブルとして取り込むチュートリアルを見ていきます。

地理空間データの処理

コードの説明に入る前に、今回使用する各プロダクトが地理空間データをどのように処理するかを理解しておくことは重要です。Earth Engine は地図やアセットの大規模なデータカタログを備えており、これがユーザーに公開されています。また、Earth Engine では CSV ファイルと Shapefiles（ベクターデータ用）または GeoTIFF と TFrecords（ラスターデータ用）のインポートとエクスポートもできます。BigQuery も、Earth Engine より規模は小さいものの、同じように地理空間データセットを公開しています。BigQuery が対応しているデータ形式は、CSV 形式、WKT 形式、または適切にフォーマットされた GeoJSON 形式です。

ラスターファイル（画像）は独特な種類のファイルであり、BigQuery でネイティブにはサポートされていません。したがって、ラスターファイルは変換してから BigQuery に取り込む必要があります。次の図に示すように、この変換に Geobeam を使用できます。

Geobeam による変換

現在、Geobeam で BigQuery を送り先として使用することはまだテスト段階中です。ただし、これは MySQL などの他のシンクに拡張できます。Geobeam は、Python 用の rasterio、shapely、GDAL を主に使用して必要な変換を行います。Geobeam GitHub リポジトリをフォークすることで、Apache Beam で独自の変換を構築することも可能です。

チュートリアル

チュートリアルを実行するには、Earth Engine アカウント（こちらから無料で登録できます）と Google Cloud アカウント（こちらから無料トライアルに登録できます）が必要です。このチュートリアルのすべてのコードは、関連する GitHub リポジトリで見ることができます。このブログを読み進める前提として、読者は Google Cloud Platform についてある程度の知識を持っていると想定しています。

このチュートリアルは次のステップからなります。

Earth Engine で USDA Cropland データを可視化する。
このデータセットを GeoTIFF としてエクスポートする。
Dataflow ジョブを実行し、Geobeam を使用して以下を行う。

ラスター GeoTIFF をベクター形式に変換する。
そのデータを BigQuery に取り込む。

データが正しく BigQuery に読み込まれたことを確認する。

データセットの可視化

ここで使用するデータセットは、USDA Cropland データレイヤーです。これは、Earth Engine カタログに登録されている、米国本土の作物種別データを含む画像コレクションです。次の図は、このデータセット全体が Earth Engine コンソールでどのように可視化されるかを示します。

Earth Engine からのデータのエクスポート

Earth Engine からのデータのエクスポートには、Earth Engine コンソールを使用できます。これには JavaScript を利用します。この例では、Earth Engine Python API を使用して Earth Engine にコマンドを送信しました（このチュートリアルの作成時には、Vertex AI Workbench 環境で Jupyter ノートブックを使用しました）。

データセットの Cloud Storage バケットへのエクスポートには、次のスクリプトを使用しました。

code_block: <ListValue: [StructValue([('code', "# 地域を定義します。\r\ncolorado = ee.Geometry.Rectangle([-104, 37, -102, 38]);\r\n# Cropland 画像コレクション内の 2019 年の最初の（そして唯一の）画像と耕作地バンド（ここから作物種別がわかります）を選択します。現時点で Geobeam が GeoTIFF から一度に取り込めるバンドの数は 1 つだけです。\r\nimage = ee.ImageCollection('USDA/NASS/CDL').filter(ee.Filter.date('2019-01-01', '2019-01-02')).first();\r\ncropland = image.select('cultivated');\r\ntask_config = { 'description': 'cropland',\r\n 'crs': 'EPSG:4326', # BigQuery がこのデータを適切に取り込めるように、この投影を指定します。\r\n 'scale': 30, # 再投影する場合は縮尺も指定する必要があります（30 m はオリジナルのデータセットの縮尺）。\r\n 'bucket': BUCKET_NAME,\r\n 'fileNamePrefix': 'croplandExport_co1',\r\n 'region': colorado,\r\n 'maxPixels': 1e12 # エクスポートするピクセル数の上限を増やします。\r\n}\r\ntask = ee.batch.Export.image.toCloudStorage(cropland, **task_config)\r\ntask.start()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05778670>)])]>

このデータセットの更新頻度は年 1 回なので、単一の日付に絞り込んでおけば、その年全体の作物種別が得られます。上記のコードでは、first() メソッドを使用してコレクションから最初の画像を選択しています。もっとも、この例ではその日付範囲に画像は 1 つしかありません。first() メソッドを使用することで、出力は ImageCollection 型ではなく Image 型（エクスポートに使用したい型）として扱われます。

エクスポート文では、画像を EPSG:4326 として再投影しました。この投影は、BigQuery が地理空間データに使用するものです。Geobeam は入力データを EPSG:4326 に再投影するよう設計されており、in_epsg パラメータを使用して入力データのオリジナルの投影を提供できます。Cropland データセットでデフォルトで使用されている投影（Albers Conical Equal Area Map）は特殊なので、それをそのまま Geobeam に渡してデータを再投影するのではなく、エクスポート時により一般的な投影を指定しました。Earth Engine で再投影する場合は、scale 値と crs（座標参照系）値を指定することが重要です。

例として、エクスポートと取り込みの時間を短縮するために小さい地域（コロラド州の一部）をエクスポートしました。米国全体をエクスポートした場合は、エクスポートに約 30 分、Geobeam への取り込みジョブに約 30 分はかかるでしょう。

Google Earth Engine から広大な地域の高解像度ラスターデータを BigQuery にエクスポートすることは推奨されず、一般的に効率的な方法ではありませんが、必要であればそうすることもできます。このチュートリアルでは、単一のバンドを 2.4 MB の GeoTIFF ファイルとしてエクスポートしました。これを変換すると 200 万行の BigQuery データになります。もっとサイズが大きくて複雑なデータセットでは、エクスポートに長時間かかります（メモリ制限を超える可能性もあります）。さらに、BigQuery は衛星画像を可視化するのに適したツールではありません。その代わりに、Earth Engine で画像コレクションの分析を行うことをおすすめします。関連するデータのサブセットがある場合は、そのデータを BigQuery に移動することを検討してください。

Geobeam を使用した BigQuery へのデータの取り込み

ラスター GeoTIFF を Cloud Storage バケットにエクスポートしたら、GeoTIFF をベクター（表形式）データとして BigQuery に取り込む Dataflow ジョブを実行する準備は完了です。パイプラインコード（これは Geobeam GitHub の例にあります）では、Geobeam の GeotiffSource クラスと format_record メソッドを使用して、入力ファイルを BigQuery が取り込める形式に変換しています。

Dataflow で Apache Beam を使用すれば、考えられるほとんどどのような種類のデータ変換でも記述できます。この例で行ったのは、バンドの値（作物種別）を整数として直接読み取り、ピクセルをポイントとして読み取ったことだけです。

Dataflow でのジョブの実行には次のコマンドを使用しました。

code_block: <ListValue: [StructValue([('code', 'python -m geobeam.examples.crop_geotiff \\\r\n --runner DataflowRunner \\\r\n --worker_harness_container_image gcr.io/dataflow-geobeam/example \\\r\n --experiment use_runner_v2 \\\r\n --project ${PROJECT_ID} \\\r\n --temp_location gs://${GEOBEAM_BUCKET}/ \\\r\n --region ${BQ_DATASET_REGION} \\\r\n --gcs_url gs://${IMAGES_BUCKET}/croplandExport.tif \\ \r\n --dataset ${BQ_DATASET} \\\r\n --table ${BQ_TABLE} \\\r\n --band_column croptype \\\r\n --max_num_workers 4 \\\r\n --machine_type c2-standard-4 \\\r\n --merge_blocks 10 \\\r\n --centroid_only true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d057788e0>)])]>

centroid_only パラメータを true に設定することで、ピクセル全体（複数のピクセルが同じバンド値を持つ場合はそれら複数のピクセル全体）を含むポリゴンを生成するのではなく、各ピクセルの中心を計算してポイントを生成しました。

merge_blocks パラメータは、読み取り中にピクセルをどのように結合するかを制御します。このパラメータを使用して取り込み時間を調整できます。一般に、merge_blocks の値を増やすと取り込み時間が長くなります。

Dataflow ジョブは Cloud コンソールでモニタリングできます。この例では、ジョブの実行に約 11 分かかり、次のように表示されました。

BigQuery でのテーブルの表示

ジョブが完了したら、BigQuery のエクスプローラパネルでプロジェクト > データセット > 取り込まれたテーブルの順に移動して結果のテーブルを確認できます。テーブルのプレビューは次のようになります。

ご覧のように、Earth Engine ではピクセルであったデータが BigQuery ではポイントになっています。つまり、データがラスターからベクターに変換されました。これらのポイントは、BigQuery Geo Viz ツールを使用して地図上に可視化できます。

データの分析

このブログでは、Earth Engine から取得したラスターデータを Geobeam で変換して BigQuery にベクターデータとして取り込みました。これは、Geobeam を使用して衛星画像データセット全体を BigQuery で再現できる、またはそうすべきであることを意味するものではありません。BigQuery は画像を処理するようには作られていないため、Sentinel-2 データセット全体を BigQuery に取り込んで分析しようとしても、なかなか思い通りにはいかないでしょう。おすすめの方法は、地理空間データセット内の関心のある特定のバンド、特性、地域を特定し、Geobeam を使用してそれらを BigQuery に取り込むことです。このようにして BigQuery に取り込んだデータを他の表形式データと簡単に組み合わせたり、モデルの構築やその他の分析に使用したりすることができます。

これで作物分類データの BigQuery への取り込みは完了したので、これらのデータを天候情報を含む別のデータセットと空間的に結合し、それらを BQML 予測モデルで特徴として使用できます。たとえば、大豆畑の間の平均距離を計算し、大豆系食品を販売している会社の店舗を探すことができます。

最初は理解しにくいかもしれませんが、地理空間データはデータの世界にまったく新しい次元を開きます。Earth Engine、BigQuery、Geobeam の組み合わせは、地図上での分析に効果的です。

謝辞: この投稿に協力してくれた Travis Webb、Rajesh Thallam、Donna Schut、Mike Pope に感謝します

- カスタマーエンジニア Remy Welch

- データエンジニア Kannappan Sirchabesan

BigQuery の監査ログパイプラインを活用した使用状況分析

Thu, 13 Jan 2022 02:00:00 +0000

※この投稿は米国時間 2021 年 12 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

BigQuery スポットライトシリーズでは、モニタリングについてお話ししました。このブログ投稿では、監査ログを使用した詳細なモニタリングについてご紹介します。BigQuery の監査ログは Google Cloud のログを集めたもので、BigQuery を使用したオペレーションに関する分析情報を提供します。監査ログからは豊富な情報を入手できます。Cloud Logging がキャプチャするさまざまなイベントからは、「誰」が「どのような」操作を行い、システムが「どのように」動作したかがわかります。

BigQuery 監査ログの概要

Google Cloud 監査ログの機能は次のとおりです。

監査ログは、BigQuery のユースケースのうち INFORMATION_SCHEMA や BigQuery 管理パネルなどでは実現が難しい、特定のユースケースのモニタリングに活用できます。利用可能なモニタリングオプション全般について詳しくは、こちらのブログをご覧ください。以下は、BigQuery をモニタリングするために監査ログを活用できる重要なユースケースです。

データ侵害などのセキュリティインシデントを特定し、対処する
ユーザーのデータアクセスパターンを把握する（列アクセス情報など）
ユーザー行動を分析する
IP アドレス分析により、複数リージョンにわたって不正な行為者を特定する

BigQuery の監査ログメッセージには、以下の 3 種類があります。

AuditData - API 呼び出しをレポートする旧バージョンのログ
BigQueryAuditMetadata - テーブルの読み込み、テーブルの期限切れなど、リソースのインタラクションをレポートする
AuditLogs - BigQuery Reservations と BigQuery Connections がリクエストのレポート時に使用するログ

BigQuery の監査ログは、以下のストリームに分類されます。

管理アクティビティログ: PatchDataset、UpdateTable、DeleteTable、PatchTable などのイベント
データアクセスログ: Query、TableDataChange、TableDataRead などのイベント
システムイベント: 内部テーブルの期限切れなどのイベント
ポリシー拒否ログ: BigQuery の権限に関連するイベント

BigQuery のログイベントの種類

新しいワークロードには、新バージョンのログイベントのみを使用します。新しいログイベントは google.cloud.bigquery.v2 という接頭辞で始まります。旧バージョンのログイベントは無視してもかまいません。これには datasetservice、tabledataservice などが該当します。

ペルソナとユースケース

ペルソナとユースケースは、BigQuery 監査ログを使用したモニタリングの分析要件とアクセスレベルを理解するために非常に重要です。以下は、一般的なペルソナとユースケースの一部です。

データオーナー / ユーザー - アプリケーションの開発と運用を行い、ソースデータを生成するシステムを管理します。このペルソナが関わるのは、ほとんどの場合、自分に固有のワークロードに限定されます。例: デベロッパー
プラットフォームオペレーター - 多くの場合、社内の顧客に対応するプラットフォームを運用します。例: データプラットフォームリード
管理者 - セキュアな運用と、リソースの GCP フリートの健全性を主に管理します。例: SRE

BigQuery 監査ログのエクスポートオプション

上記のペルソナとユースケースに対応するために、ログをログエクスプローラ以外のさまざまな出力先にエクスポートできます。以下の出力先がサポートされています。

Cloud Storage - GCS バケットに保存される JSON 形式のファイル
BigQuery - BigQuery データセットに作成されるログテーブル
Pub/Sub - Pub/Sub トピックに配信される JSON メッセージ
ログバケット - Cloud Monitoring で詳細な分析が可能な JSON 形式のログ

モニタリング用に BigQuery のログの適切なエクスポート先を選択する際には、以下の項目を考慮します。

エクスポート要件 - 異なる出力先に応じたさまざまなユースケース
言語 - BigQuery 監査ログの分析に必要な言語のサポート
パイプライン設定 - エクスポートパイプラインの設定で使用できるオプション
メンテナンスのオーバーヘッド - エクスポートパイプラインの維持と管理に必要な作業
保持期間 / 消去サポート - データの保持と有効期限に関するポリシーのサポート

パイプラインの設定

集約シンクの使用

ほとんどの企業は、数多くのプロジェクトに取り組んでいるため、さまざまなログがまとまりなく増えていきます。プラットフォーム事業者や管理者の方には、管理プロジェクトを一元化し、集約シンクを使用して、監査ログを組織レベルでエクスポートすることをおすすめします。データオーナーの場合は、集約シンクを使用して、プロジェクトレベルのログをエクスポートすることもできます。

Logging サービスアカウント

Cloud Logging はデフォルトのサービスアカウントを使用して、ログデータをリアルタイムで作成およびエクスポートします。VPC Service Controls を使用している場合は、制約のためにこのサービスアカウントをアクセスレベルに追加してから、出力先のサービス境界に割り当てる必要があります。詳細については、VPC Service Controls: Cloud Logging をご覧ください。

エクスポートオプション

Logging のクエリ言語で記述されたさまざまなフィルタを使用してログをエクスポートしたり、さまざまな出力先を選択したりできます。以下のサンプルアーキテクチャ図では、さまざまなユースケースに応じて、ログエクスポートを特定の出力先に設定しています。

出力先ごとのパイプラインの設定手順を詳しく見ていきましょう。

BigQuery へのエクスポート

BigQuery へのエクスポートでは、読み込みジョブを使用する代わりに、ログデータが一度に 1 レコードずつ BigQuery にストリームされます。この方法では、データのクエリを BigQuery でほぼリアルタイムで実行でき、読み込みジョブの実行やデータ取り込みパイプラインのメンテナンスによる遅延が発生することはありません。

シンクを作成して、ログを BigQuery にエクスポートする場合は、日付別シャーディングテーブルまたはパーティション分割テーブルを使用できます。どちらのテーブルタイプも、ログエントリのタイムスタンプフィールドに基づいてログデータを分割します。デフォルトでは、日付別シャーディングテーブルが選択されていますが、アクセスと管理が容易でパフォーマンスが高い、パーティション分割テーブルを使用する方法をおすすめします。

集約シンクを選択すると、対応するイベントタイプに応じて、BigQuery 内に以下の監査ログテーブルが作成されます。

cloudaudit_googleapis_com_system_event
cloudaudit_googleapis_com_policy
cloudaudit_googleapis_com_data_access
cloudaudit_googleapis_com_activity

設定手順

ステップ 1: 組織レベルで集約シンクを作成し、BigQuery シンクにログを転送する

code_block: <ListValue: [StructValue([('code', 'gcloud beta logging sinks create my_org_logs_to_bq \\\r\nbigquery.googleapis.com/projects/my-project/datasets/my_dataset \\\r\n--use-partitioned-tables \\\r\n--include-children \\\r\n--organization=12345678910 \\\r\n--log-filter=protoPayload.serviceName=bigquery.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059552e0>)])]>

その他のフィルタ:

code_block: <ListValue: [StructValue([('code', 'protoPayload.serviceName=bigquerydatatransfer.googleapis.com\r\nprotoPayload.serviceName=bigqueryreservation.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955be0>)])]>

ステップ 2: サービスアカウントにアクセス権を付与する

出力先の BigQuery データセットで、BigQuery データ編集者のロールをデフォルトの Logging サービスアカウントに付与します。

ステップ 3: 保持ポリシーを設定する

テーブルの作成時にパーティションの有効期限を設定して、ロギングのエクスポートに使用するストレージのサイズを制限します。

ステップ 4: 派生テーブルや派生ビューを作成して詳細な分析に活用する

以下は、アクセスを行ったユーザー、ユーザーがアクセスしたデータセット / テーブル / 列、ユーザーがアクセスにあたり持っていた権限の詳細を提供する SQL クエリの例です。

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n timestamp AS time_of_access,\r\n protopayload_auditlog.authenticationInfo.principalEmail as user_email,\r\n protopayload_auditlog.requestMetadata.callerIp as ip,\r\n auth.permission as auth_permission,\r\n auth.granted as auth_granted,\r\n data_access.resource.labels.project_id AS job_execution_project,\r\n SPLIT(protopayload_auditlog.resourceName, \'/\')[SAFE_OFFSET(1)] AS referenced_project,\r\n SPLIT(protopayload_auditlog.resourceName, \'/\')[SAFE_OFFSET(3)] AS referenced_dataset,\r\n SPLIT(protopayload_auditlog.resourceName, \'/\')[SAFE_OFFSET(5)] AS referenced_table, ARRAY_LENGTH(SPLIT(JSON_EXTRACT(JSON_EXTRACT(protopayload_auditlog.metadataJson, \'$.tableDataRead\'), \'$.fields\'), \',\')) as num_fields,\r\n SPLIT(JSON_EXTRACT(JSON_EXTRACT(protopayload_auditlog.metadataJson, \'$.tableDataRead\'), \'$.fields\'),",") as fields\r\nFROM `my-project`.my_dataset.cloudaudit_googleapis_com_data_access As data_access, UNNEST(protopayload_auditlog.authorizationInfo) AS auth\r\nWHERE\r\nprotopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob"\r\nAND data_access.resource.type = \'bigquery_dataset\'\r\nAND JSON_EXTRACT(JSON_EXTRACT(protopayload_auditlog.metadataJson, \'$.tableDataRead\'), \'$.reason\') = \'"JOB"\';'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059556d0>)])]>

以下は、データセットの読み取り、作成、削除などのさまざまなデータセットアクティビティを行ったユーザーと、アクティビティの実行方法の詳細を提供するクエリの例です。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n REGEXP_EXTRACT(protopayload_auditlog.resourceName, 'projects/([^/]+)') as projectid,\r\n REGEXP_EXTRACT(protopayload_auditlog.resourceName, '/datasets/([^/]+)') AS datasetid,\r\n protopayload_auditlog.authenticationInfo.principalEmail as principalemail,\r\n protopayload_auditlog.requestMetadata.callerIp as callerip,\r\n auth.permission as permission,\r\n protopayload_auditlog.requestMetadata.callerSuppliedUserAgent as agent\r\n protopayload_auditlog.methodName as method,\r\n protopayload_auditlog.status.message as status,\r\n auth.granted as granted,\r\n timestamp\r\nFROM `tw-pso-bq-admin.bq_logs.cloudaudit_googleapis_com_activity`, unnest(protopayload_auditlog.authorizationInfo) as auth\r\nWHERE\r\nlower(protopayload_auditlog.methodName) like '%dataset%'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955790>)])]>

以下は、期限切れテーブルの詳細を提供するクエリの例です。

code_block: <ListValue: [StructValue([('code', "SELECT\r\nREGEXP_EXTRACT(protopayload_auditlog.resourceName, 'projects/([^/]+)') as projectid,\r\nREGEXP_EXTRACT(protopayload_auditlog.resourceName, '/datasets/([^/]+)') AS datasetid,\r\nREGEXP_EXTRACT(protopayload_auditlog.resourceName, '/tables/([^/]+)') AS tableid,\r\nprotopayload_auditlog.methodName as method,\r\nprotopayload_auditlog.metadataJson,\r\ntimestamp\r\nFROM `tw-pso-bq-admin.bq_logs.cloudaudit_googleapis_com_system_event`\r\n WHERE lower(protopayload_auditlog.methodName) = 'internaltableexpired'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955dc0>)])]>

Google Cloud Storage へのエクスポート

Google Cloud Storage では、ログを低コストで長期保存できます。ログを Nearline または Coldline に移動してから削除すると、ログの維持に必要な運用コストを管理できます。これらのログをエクスポートして詳細な分析を行う場合は、JSON 形式のログファイルを BigQuery に読み込むか、GCS のログデータに対する外部テーブルを作成します。

設定手順

ステップ 1: 組織レベルで集約シンクを作成して、ログを GCS シンクに転送する

code_block: <ListValue: [StructValue([('code', 'gcloud beta logging sinks create my_org_logs_to_gcs \\\r\nstorage.googleapis.com/my_bucket \\\r\n--include-children \\\r\n--organization=12345678910 \\\r\n--log-filter=protoPayload.serviceName=bigquery.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059550d0>)])]>

ステップ 2: サービスアカウントにアクセス権を付与する

バケットに書き込みを行えるよう、Logging のデフォルトサービスアカウントに Storage オブジェクト作成者のロールを付与します。

ステップ 3: 保持ポリシーを設定する

GCS でオブジェクトのライフサイクル管理を使用して保持ポリシーを構成します。

ステップ 4: 外部テーブル

GCS に保存された監査ログデータにクエリを行う必要がある場合、BigQuery で外部テーブルを使用すると、データをさらに詳細に確認できます。ただし、外部テーブルへのクエリは、ネイティブの BigQuery テーブルへのクエリよりパフォーマンスが低下します。

ステップ 4.1: 外部テーブルを作成する

code_block: <ListValue: [StructValue([('code', 'bq mk \\\r\n--external_table_definition=source_format=Cloud Storage URI \\Dataset.table'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955eb0>)])]>

ステップ 4.2: クエリ用のビューを作成する

code_block: <ListValue: [StructValue([('code', "CREATE VIEW `project.dataset.view`\r\nAS SELECT\r\n PARSE_TIMESTAMP('%Y/%m/%d/%H', REGEXP_EXTRACT(_FILE_NAME, '[0-9]+/[0-9]+/[0-9]+/[0-9]')) pt\r\n , _FILE_NAME filename\r\n , *\r\nFROM `project.dataset.external_table_name`"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955310>)])]>

Pub/Sub 経由のエクスポート

Pub/Sub シンクを使用して、ログを Cloud Logging から Splunk などのサードパーティツールにリアルタイムでエクスポートできます。Splunk を使用すると、オンプレミスとクラウドのデプロイメントから収集したログ、イベント、指標を検索、分析、可視化し、IT とセキュリティのモニタリングを行うことができます。また、Pub/Sub から BigQuery への Dataflow パイプラインを作成して変換と集約を行い、その結果を BigQuery に読み込んでデータ分析に使用できます。

設定手順

ステップ 1: 組織レベルで集約シンクを作成して、ログを Pub/Sub シンクに転送する

code_block: <ListValue: [StructValue([('code', 'gcloud beta logging sinks create my_org_logs_to_gcs \\\r\npubsub.googleapis.com/projects/my-project/topics/my_logs_topic \\\r\n--include-children \\\r\n--organization=12345678910 \\\r\n--log-filter=protoPayload.serviceName=bigquery.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059559d0>)])]>

ステップ 2: サービスアカウントにアクセス権を付与する

トピックに対する Pub/Sub パブリッシャーのロールをデフォルトの Logging サービスアカウントに付与します。

ステップ 3: 作成したトピックからログメッセージを pull できるよう、サブスクリプションを設定する

コマンドラインを使用して、Pub/Sub サブスクリプション pull 経由でメッセージを pull します。または、簡単なサブスクライバーを実装することもできます。詳しくは、こちらのコードサンプルをご覧ください。

ステップ 4: サードパーティ統合の設定を行う

Dataflow を使用するか、Google Cloud Platform 用の Splunk アドオンでログを直接 pull して、ログメッセージを Splunk のようなサードパーティ製ツールに取り込むことができます。

Cloud Monitoring

Cloud Monitoring は、Cloud Logging および Cloud Monitoring フレームワークの一部です。ログバケットのログ情報は、Cloud Monitoring ワークスペースに自動的に同期され、概要分析に使用できます。また、大まかなログ指標やアラート機能を備えています。

ただし、高度な分析要件のためのカスタマイズはできません。また、Monitoring ワークスペースで、権限やアクセス制御レベルをきめ細かく構成することは困難です。

パイプラインの自動化

Terraform を使用すると、パイプライン設定手順の自動化、バージョンコントロール、管理を簡単に行えます。以下は、BigQuery に集約シンクを設定する Terraform スクリプトの例です。

code_block: <ListValue: [StructValue([('code', '######### BigQuery に組織レベルの集約ロギングシンクを作成する #######\r\nresource "google_logging_organization_sink" "bigquery_logs" { \r\nname = "bigquery_logs" \r\ndescription = "some explanation on what this is" \r\norg_id = 12345678910\r\n# BigQuery 関連のログを集約する BigQuery データセット\r\ndestination = "bigquery.googleapis.com/projects/my-project/datasets/${google_bigquery_dataset.audit_dataset.dataset_id}" \r\n# BigQuery および対応するプロジェクトに関連するすべてのメッセージをログに記録する\r\nfilter = "protoPayload.serviceName=bigquery.googleapis.com"\r\n# すべてのプロジェクトを含める \r\ninclude_children = true\r\n\r\n# 監査ログ用に、パーティション分割テーブルを BigQuery に作成する \r\nbigquery_options = { \r\n use_partitioned_tables = true\r\n}\r\n} \r\n######### BigQuery データセットを作成する #######\r\nresource "google_bigquery_dataset" "audit_dataset" { \r\ndataset_id = "my_dataset" \r\nproject_id = "my_project"\r\nlocation = "US" \r\n}\r\n\r\n######### サービスアカウント権限を割り当てる #######\r\nresource "google_project_iam_member" "log-writer" { \r\nrole = "roles/bigquery.dataEditor" \r\nmember = google_logging_organization_sink.bigquery_logs.writer_identity \r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955a60>)])]>

次のステップ

BigQuery シンク内の監査ログデータを活用し、データポータルや Looker で高度な分析ダッシュボードを作成できます。以下は、監査ログを使用して BigQuery をモニタリングするユースケースの例です。

プロジェクトオーナー向けアクセスレポート
プロジェクトオーナーにとって、プロジェクト内のどのデータセットに、いつ、誰がアクセスしたかといった情報は重要です。たとえば、特定のデータセットに、誰がどのロケーションからアクセスしているかという情報を得ることで、異常を特定して、アクセスに関する事象を積極的にレポートできます。
データオーナー向け使用状況レポート
データオーナーにとって、プロジェクトのデータセットやテーブルの詳しい使用状況に関する情報は重要です。たとえば、特定のテーブル内のある列に対するアクセス頻度、アクセスしたユーザー、期限切れになるテーブル数といった情報を確認します。

以下は、データポータルを使用するサンプルダッシュボードの例です。

こちらの GitHub リポジトリから、BigQuery 内のログの情報を照会する SQL スクリプトや、ログエクスポートパイプラインの自動化全般に関する Terraform スクリプトをご覧ください。

- データ分析担当戦略クラウドエンジニア Vrishali Shah

- データ分析担当クラウドコンサルタント Namita Sharma

アーキテクチャフレームワークの原則に沿ったシステム設計の最適化

Fri, 07 Jan 2022 01:00:00 +0000

※この投稿は米国時間 2021 年 12 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

お客様が Google Cloud を使用してビジネスを成功に導けるよう、Google は、Google Cloud アーキテクチャフレームワークを公開しました。これは、セキュアで効率性と復元力が高く、高性能で費用対効果の高い、ワークロード構築と運用のための一連の正規ベストプラクティスです。

今日は、アーキテクチャフレームワークのシステム設計の柱について、システム設計の 4 つの重要原則と Google のドキュメントに対する最近の改善内容を含めて、より深く掘り下げていきます。また、Google Cloud コミュニティに新たに設けられたアーキテクチャフレームワーク専用のスペースについてもご紹介します。このスペースは、協力的で知識の豊富な仲間、Google 社員、プロダクトエキスパートからなるグローバルなコミュニティとともに、お客様の目標達成を支援するために設けられました。

システム設計とは？

システム設計の柱とは、アーキテクチャフレームワークの基礎となる柱であり、Google Cloud のプロダクト、機能、設計原則を含み、ビジネスとシステムの要件を満たすために必要なアーキテクチャ、コンポーネント、データを定義するのに役立ちます。

システム設計のコンセプトと推奨事項は、アーキテクチャフレームワークの他の 5 つの柱、「卓越した運用」、「セキュリティ、プライバシー、コンプライアンス」、「信頼性」、「費用の最適化」、「パフォーマンスの最適化」にも適用できます。

システム設計の柱で提示されているガイダンスに照らして、アーキテクチャの現状を評価し、潜在的なギャップや改善すべき箇所を特定できます。

システム設計の基本原則

堅牢なシステム設計とは、安全性、信頼性、拡張性、独立性を備えたものであり、変更を一度ですべてに適用し、潜在的なリスクを最小限に抑え、運用効率を向上させることができます。堅牢なシステム設計を実現するには、以下の 4 つの基本原則に沿って実行することをおすすめします。

すべてを文書化する

お客様がクラウドへの移行を検討されている場合や、アプリケーションの構築を開始される場合に成功の大きな妨げとなるのが、文書の不足です。特に、現在のアーキテクチャのデプロイを正しく可視化した文書が不足しがちです。

クラウドアーキテクチャを適切に文書化することで、共通の言語と標準を定め、部門横断的なチーム間でのコミュニケーションとコラボレーションを効果的に行いやすくなります。また、この文書化により、クラウドの効果的な利用を促進するため、将来的な設計上の意思決定を促し、これを推進するために必要な情報も得られます。

時間の経過とともに、設計上の意思決定が増え、変化していきますが、変更履歴があれば、チームが構想を調整し、重複を避け、時間の経過に沿ったパフォーマンスの変化を効果的に測定するために必要な背景情報が得られます。変更ログは、現行システムの設計、戦略、履歴に精通していない新しいクラウドアーキテクトを迎え入れるときに、特に重要な役割を果たします。

設計を簡素化する（フルマネージドサービスを利用する）

システム設計においては、シンプルさが重要となります。アーキテクチャが複雑すぎて理解できない場合、デベロッパーと運用チームがシステム導入時や現在継続中の管理において面倒な問題に直面する可能性があります。可能な限り、フルマネージドサービスを利用して、基本システムの管理と保守のリスク、およびチームが必要とする時間と労力を最小限に抑えることを強くおすすめします。

すでに本番環境でワークロードを運用している場合は、マネージドサービスを試しに利用することで、複雑な運用を簡素化できます。新規にシステムを導入する場合は、シンプルに始め、MVP を確立し、さまざまな機能を取り入れたい衝動を抑えましょう。特殊なユースケースを特定し、イテレーションを行い、時間をかけて段階的にシステムを改善していくことができます。

アーキテクチャを分離する

分離とは、モノリシックアプリケーションスタックなどのアプリケーションやサービスコンポーネントを、独立的に動作する小さなコンポーネントに分ける手法をいいます。したがって、分離されたアーキテクチャは、さまざまな依存関係があるにもかかわらず、独立して機能できます。

アーキテクチャを分離することで、独自のアップグレードの適用、特定のセキュリティ対策の適用、信頼性目標の設定、健全性のモニタリング、パフォーマンスと費用の細かいパラメータ制御をより柔軟に行えます。

分離は、設計段階早期から始めることも、規模の拡大に伴うシステムアップグレードの一部として行うこともできます。

ステートレス性を活用する

ステートフルアプリケーションは、タスクを実行するために、ローカルにキャッシュされたデータなどのさまざまな依存関係を利用し、多くの場合、進捗状況の把握、再起動後のデータの維持などをするための追加の仕組みを必要とします。

一方、ステートレスアプリケーションは、共有ストレージやキャッシュサービスを利用することで、ローカルの依存関係をさほど利用することなくタスクを実行できます。これにより、アプリケーションは最小限のブート依存関係を利用するだけで迅速にスケールアップでき、強制的再起動に耐え、ダウンタイムを削減し、エンドユーザーへのサービスパフォーマンスを最大限に高めることができます。

システム設計の柱では、アプリケーションをステートレスにするための推奨事項、すなわちステートフルアプリケーションのためのマシン状態の取得を改善するためにクラウドネイティブの機能を利用する方法について説明しています。

他の柱に適用されるシステム設計の原則

システム設計の基本原則は、卓越した運用、セキュリティ、信頼性、費用、パフォーマンスの最適化など、アーキテクチャフレームワークの他の 5 本の柱にも適用できます。ここでは、システム設計の基本原則が実際にどのようなものか、以下に例を示します。

フルマネージドの、可用性の高い運用ツールを使用してワークロードをデプロイ、モニタリングする。これにより、ワークロードの維持と最適化にかかる運用上のオーバーヘッドを最小限に抑えることができます。

コンポーネントレベルでセキュリティ対策を行う。コンポーネントを分離することで、きめ細かな管理対策を適用し、効果的なコンプライアンス管理を行うとともに、セキュリティ上の潜在的な脆弱性の影響範囲を最小限に抑えることができます。

高可用性と高いスケーラビリティを念頭に置いた設計を行う。アーキテクチャを分離することにより、きめ細かな信頼性目標を定義、管理できます。これによって、重要性の高いサービスの耐久性、スケーラビリティ、可用性を最大限に高めると同時に、重要性が高くないコンポーネントを必要に応じて最適化することが可能になります。

予算を決め、費用対効果を考慮した設計を行う。通常、信頼性の目標を定義するときは、費用が重要な要素となります。そのため、アプリケーションの設計時には、早い段階でさまざま費用指標を考慮することが重要です。アーキテクチャを分離することで、きめ細かな費用の予算設定と管理を行うことができ、これによって運用効率を向上させ、費用の最適化を図ることができます。

最良のスピードとパフォーマンスを求めて設計を最適化する。費用予算内でサービス可用性を設計するときは、パフォーマンス指標も考慮するようにしてください。さまざまな運用ツールを使用することで、パフォーマンスのボトルネックを把握し、パフォーマンスの効率化を図ることができます。

これらはほんの一例ですが、システム設計の原則が、アーキテクチャフレームワークの他の 5 本の柱において、他のさまざまなユースケースにも拡張できることがおわかりいただけると思います。

Google Cloud コミュニティの一部となったアーキテクチャフレームワーク

Google Cloud コミュニティは、Google Cloud ユーザーが質問して答えを見つけ、積極的に参加して有意義な関係を築き、アイデアを共有してプロダクトロードマップに影響を与え、さらに新しいスキルについて学んで専門知識を身につけるための、革新的で信頼できる、活気に満ちた交流の場です。

本日は、Google Cloud コミュニティにアーキテクチャフレームワーク専用の新しいスペースが開設されたことをお知らせします。このスペースでは、以下を行えます。

実践的な手引きを示し、システム設計の柱に関連する具体的な質問や課題を取り上げた、正規の記事を読むことができます。今後、残りの 5 本の柱に焦点を当てた記事を公開していく予定です。
メンバーが質問したり、回答を得たりできる自由な議論の場に参加できます。
「Ask Me Anything（なんでも聞いて）」シリーズなどのコミュニティイベントに参加できます。同シリーズでは、Google がアーキテクチャフレームワークの特定のトピックに関するバーチャルウェブセミナーを開催し、参加者からの質問を受け付けます。

Google Cloud コミュニティとアーキテクチャフレームワークは、協力的で知識豊富な仲間、Google 社員、プロダクト専門家からなるグローバルコミュニティとともに、お客様が目標を達成するための信頼できる場を提供します。

今すぐ Google Cloud コミュニティの新しいスペースにアクセスし、まだメンバー登録をされていない方は、ぜひメンバー登録を行って、あらゆる機会をご活用ください。

システム設計 2.0 の変更点

今年初め、Google は、アーキテクチャフレームワークの最新版（2.0）をリリースしました。また、世界中のパートナーとお客様、Google プロダクトエキスパートのチームからのフィードバックをもとに、Google が持つ一連のベストプラクティスを強化し続けています。

システム設計の柱における変更点を以下に紹介します。

リソースのラベルとタグのベストプラクティスが追加され、リソース管理が容易になりました。
コンピューティングセクションは、コンピューティングワークロードの選択、設計、運用、スケーリングに焦点を当てて再編成されました。
データベースセクションは、データベースワークロードの選択、移行、運用などのトピックに再編され、ワークフロー管理に関するベストプラクティスに焦点を当てています。
データ分析セクションには、データライフサイクル、データ処理、トランスフォーメーションのセクションが追加されました。
人工知能（AI）と機械学習（ML）に関する新しいセクションが追加され、ML ワークロードのデプロイと管理に関するベストプラクティスを取り扱っています。

今後も、Google Cloud をご利用のお客様がビジネスを成功に導けるようサービスを改善し、お客様を支援できるよう、お客様からのご意見をお待ちしております。

Google Cloud コミュニティのサイトでアーキテクチャフレームワークの開催に協力してくれた Andrew Biernat、Willie Turney、Lauren van der Vaart、Michelle Lynn、Shylaja Nukala に感謝します。また、Minh "MC" Chung、Rachel Tsao、Sam Moss、Nitin Vashishtha、Pritesh Jani、Ravi Bhatt、Olivia Zhang、Zach Seils、Hamsa Buvaraghan、Maridi Makaraju、Gargi Singh、Nahuel Lofeudo には、システム設計のコンテンツをうまく立ち上げるうえで協力してくれました。

- アーキテクチャフレームワーク担当ソリューションエンジニア / プロジェクトリーダー Omkar Suram

- Google Cloud ソリューションアーキテクチャ担当ディレクター Rob Rosen

GitHub Actions からのキーなしの認証の有効化

Tue, 21 Dec 2021 01:00:00 +0000

※この投稿は米国時間 2021 年 12 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

GitHub Actions は Google Cloud の多くのお客様とデベロッパーの間で人気があるサードパーティ CI / CD ソリューションです。GitHub Actions ワークフローで Google Cloud 上でのリソースの読み取りや変更が必要な場合（Artifact Registry へのコンテナの公開や Cloud Run での新しいサービスのデプロイなど）、最初に認証をしなくてはなりません。

GitHub Actions から Google Cloud への従来の認証では、有効期間が長い JSON サービスアカウントキーのエクスポートと保存が必要でした。よって、ID 管理をするためにシークレット管理も必要でした。これは、サービスアカウントキー漏洩時のセキュリティリスクの増大をもたらすだけではありません。デベロッパーの組織が、組織ポリシーの制約（constraints/iam.disableServiceAccountKeyCreation など）により、一般的なセキュリティのベストプラクティスとしてサービスアカウントキーの作成を無効にした場合、デベロッパーが GitHub Actions から Google Cloud に認証できなくなることも意味します。

しかし今は、GitHub が GitHub Actions ワークフローに OIDC トークンを導入したため、Workload Identity 連携を使用して GitHub Actions から Google Cloud に認証できるようになりました。そして、有効期間が長い JSON サービスアカウントキーのエクスポートも不要になりました。

詳細なスコープ　Workload Identity プールとプロバイダは、OIDC トークンと Google Cloud で利用可能な権限の間に詳細な属性マッピングを定義できます。JSON サービスアカウントキーはアクセス可能とアクセス不能のいずれかである一方、Workload Identity 連携は、ダウンストリームの OIDC トークンのプロパティに基づいて認証を選択的に許可するように構成できます。GitHub Actions の場合は、たとえば、特定のリポジトリ、ユーザー名、ブランチ名、パブリッシュされたクレームに認証を制限できます。また、CEL を使用して、より複雑で複合的な制約を組み合わせて構築できます。
有効時間が短い認証情報　JSON サービスアカウントキーと異なり、Workload Identity 連携は有効時間の短い OAuth 2.0 または JWT 認証情報を生成します。デフォルトでは、これらの認証情報は作成から 1 時間後に自動的に期限が切れます。これにより、悪意のある人物が不正使用された認証情報を利用できる時間を潜在的に短縮します。
最小限の管理オーバーヘッド　JSON サービスアカウントキーは、安全に保存、ローテーション、管理する必要があります。これには、たとえ小規模であっても労力を要し、エラーも発生しやすい傾向にあります。Workload Identity 連携は有効時間の短い認証情報を使用するため、最初の構成以外にローテーションや管理の必要なシークレットは存在しません。

新しい GitHub Action – auth

Workload Identity 連携による Google Cloud への GitHub Actions ワークフローの認証と承認のプロセスを容易にするため、新しい GitHub Action の auth をご用意しました。auth アクションが、増大を続ける Google GitHub Actions コレクションに加わり、Google Cloud への認証の設定と構成をシンプルにします。

code_block: <ListValue: [StructValue([('code', "steps:\r\n- id: 'auth'\r\n name: 'Authenticate to Google Cloud'\r\n uses: 'google-github-actions/auth@v0.4.0'\r\n with:\r\n workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider'\r\n service_account: 'my-service-account@my-project.iam.gserviceaccount.com'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05696be0>)])]>

code_block: <ListValue: [StructValue([('code', "steps:\r\n- id: auth\r\n uses: google-github-actions/auth@v0.4.0\r\n with:\r\n workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider'\r\n service_account: 'my-service-account@my-project.iam.gserviceaccount.com'\r\n\r\n- id: get-gke-credentials\r\n uses: google-github-actions/get-gke-credentials@v0.4.0\r\n with:\r\n cluster_name: my-cluster\r\n location: us-central1-a\r\n\r\n- id: get-pods\r\n run: kubectl get pods"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05696250>)])]>

アプリケーションのデフォルト認証情報をサポートしていないサードパーティのツールを使用している場合や、Google Cloud API を curl で手動で呼び出す場合、auth GitHub Action は、今後のステップでの使用のために、OAuth 2.0 トークンと JWT を作成できます。次の例では、有効時間の短い OAuth 2.0 アクセストークンを作成し、そのトークンを使用して、Google Secret Manager から curl でシークレットにアクセスします。

code_block: <ListValue: [StructValue([('code', 'steps:\r\n- id: \'auth\'\r\n name: \'Authenticate to Google Cloud\'\r\n uses: \'google-github-actions/auth@v0.4.0\'\r\n with:\r\n token_format: \'access_token\'\r\n workload_identity_provider: \'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider\'\r\n service_account: \'my-service-account@my-project.iam.gserviceaccount.com\'\r\n\r\n- name: \'Access secret\'\r\n run: |-\r\n curl https://secretmanager.googleapis.com/v1/projects/my-project/secrets/my-secret/versions/1:access \\\r\n --header "Authorization: Bearer ${{ steps.auth.outputs.access_token }}"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059553a0>)])]>

移行を簡単にして、以前のワークフローをサポートするため、auth GitHub Action は、Google Cloud サービスアカウントキー JSON ファイルによる認証にも対応しています。

code_block: <ListValue: [StructValue([('code', "steps:\r\n- id: 'auth'\r\n name: 'Authenticate to Google Cloud'\r\n uses: `google-github-actions/auth@v0.4.0'\r\n with:\r\n credentials_json: '${{ secrets.GOOGLE_CREDENTIALS }}'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955520>)])]>

auth GitHub Action の詳細と例を google-github-actions/auth でご確認ください。

GitHub Actions の ID 連携の設定

新しい GitHub Actions auth アクションを使用するには、Workload Identity プールと Workload Identity プロバイダを作成して Workload Identity 連携を設定および構成する必要があります。

code_block: <ListValue: [StructValue([('code', 'gcloud iam workload-identity-pools create "my-pool" \\\r\n --project="${PROJECT_ID}" \\\r\n --location="global" \\\r\n --display-name="Demo pool"\r\n\r\n gcloud iam workload-identity-pools providers create-oidc "my-provider" \\\r\n --project="${PROJECT_ID}" \\\r\n --location="global" \\\r\n --workload-identity-pool="my-pool" \\\r\n --display-name="Demo provider" \\\r\n --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.aud=assertion.aud" \\\r\n --issuer-uri="https://token.actions.githubusercontent.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d059552b0>)])]>

属性マッピングは、GitHub Actions JWT のクレームを、リクエストについて行うことのできるアサーションにマップします（リポジトリや GitHub Action を呼び出すプリンシパルの GitHub ユーザー名など）。これらを使用して、--attribute-condition フラグで認証をさらに制限できます。たとえば、属性の repository 値をマップして、認証を特定のリポジトリに制限するためにこの値を後で使用することができます。

code_block: <ListValue: [StructValue([('code', '--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955400>)])]>

最後に、Workload Identity プロバイダからの認証について、目的のサービスアカウントの権限の借用を許可します。

code_block: <ListValue: [StructValue([('code', 'gcloud iam service-accounts add-iam-policy-binding "my-service-account@${PROJECT_ID}.iam.gserviceaccount.com" \\\r\n --project="${PROJECT_ID}" \\\r\n --role="roles/iam.workloadIdentityUser" \\\r\n --member="principalSet://iam.googleapis.com/${WORKLOAD_IDENTITY_POOL_ID}/attribute.repository/my-org/my-repo"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d05955c70>)])]>

その他の構成オプションについては、Workload Identity 連携ドキュメントをご覧ください。Terraform を使用してインフラストラクチャのプロビジョニングを自動化している場合は、GitHub OIDC Terraform モジュールもご確認ください。

「見えないセキュリティ」に向けて

長期間有効な JSON サービスアカウントキーを使用せずに GitHub Action から Google Cloud に認証することは、魔法のように見えるかもしれません。しかしこれは、「見えないセキュリティ」を実現し Google のプラットフォームをデフォルトで保護するという、Google Cloud の現在の取り組みを集約するものです。GitHub Actions で長期間有効な JSON サービスアカウントキーに代わり Workload Identity 連携を使用することで、セキュリティと監査対応力が向上します。

はじめに、auth GitHub Action を今すぐご覧ください。

- デベロッパーアドボケイト兼プロダクトマネージャー Seth Vargo

- ソリューションアーキテクト Bharath Baiju

Google Cloud で予測市場を作成する

Tue, 14 Dec 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 12 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

予測分析は長い間、革新的な企業が戦略的優位性を獲得するための情報源となってきました。高い業績を上げている企業は、将来の結果をより正確に予測し、未知の出来事に対する計画を立て、製品の機会や顧客機会を見つけるために、強力な予測分析を使用しています。

予測分析における課題の一つは、予測の精度を上げるために行う過去のデータの生成です。非常に重要な質問であっても、利用できるデータが少なく、機械学習モデルのトレーニングが困難な場合も少なくありません（例: COVID-19（新型コロナウイルス感染症）によってサプライチェーンはどのような影響を受けているか、新しいテクノロジーにはどのような効果があるか）。

予測分析のお客様は、従業員、パートナー、ベンダーの判断に頼ることでそのギャップを埋めているのが現状です。そこで Google は考えました。どうすれば予測分析はより厳密なものになるでしょうか。Google の集合知を予測モデルで機械学習と組み合わせたらどうなるでしょうか。

2020 年、パンデミックにより先行きの見えない状況に直面した Google 社員の一グループは、これを Google Cloud で試すために内部的な予測市場を立ち上げました。Google は 2005 年から 2007 年にかけて初めて予測市場を実行し、有望な結果を残しました。現在のチームには、2005 年にはなかった 2 つの強みがありました。Google に参加できる多くの人材がいることと、Google Cloud 上にプラットフォームを構築できることです。

構造化と設計を繰り返し、1 万人以上の Google 社員から寄せられた 175,000 件以上の予測を分析しました。今回はその中で、COVID-19 や、エンジニアリングマイルストーン、新しいテクノロジーのトレンドなど、難易度の高い分野で正確な予測を生成するのに役立った設計パターンとテクノロジーをご紹介します。

予測市場を構造化する方法

予測市場の背後にある分析情報の中核は、適切な人にインセンティブを与えて正確な予測をさせることで、どの個人よりも正確なコンセンサス予測を生成することです。

たとえば、「2022 年に金利が上昇するか」という質問について予測するとします。顧客行動の予測や、さらにはマクロ経済の動向の予測を行う ML モデルがすでにあるかもしれません。しかし、この種のイベント予測には、組織内の人材の知識と判断を活用する必要があります。

このような質問について未来を正確に予測することは非常に困難です。その一方で、ついつい単純な答えに飛びつきたくなってしまいますし、反対に誰も知り得ないと悲嘆するのも簡単です。しかし実際には、正しい構造を使用すれば組織は驚くべき精度を達成できることが、予測市場や予測トーナメントによって実証されています。

Google はこれまでの経験に基づき、組織から正確な予測を引き出すための 5 つの基本原則を導き出しました。順を追って説明します。

1. 適切な UI を用意することで、きめ細かい正確な予測が表現しやすくなる。

ほとんどの質問は、確率（下の例を参照）、日付（「金利はいつ上昇するか」）、または数値（「来年の金利はいくらになるか」）の予測として提起できます。これらを予測するにあたり、2 つの方法を選べるようにしました。（a）ワンクリックで、現在のコンセンサスよりも確率 / 日付 / 数値が低いか高いかを予測する方法、そして（b）具体的な予測を範囲で示す方法です。

例として次のような確率の市場を考えてみましょう。

上部の UI から、確率がコンセンサスの範囲を下回っていると思うか、上回っていると思うかを素早く指定できます。また、確率の範囲を設定することで、よりきめ細かい予測の指定が可能になります。この際、確率が水準内に収まるかどうかの確信の度合いを下限と上限で個別に指定することができます。

全員が同じことを予想できるよう、解決の条件を厳密に設定することに特に注意を払ってください。正確な予測は、質問が正確に定義されて初めて可能になります。新しい質問の提案を確認するために組織から管理者を任命し、ソースデータと期間が正しく選択されるようにします。

2. 組織からスペシャリストを選出してインセンティブを与え、豊富な知見に基づいて質問に対する予測を行ってもらう。

他の予測市場と同様、Google のインセンティブシステムにもオプション市場との類似があります。予測を「bid（売値）」と「ask（買値）」に変換し、確率、数値、日付を「price（価格）」と解釈、信頼度を「volume（数量）」と解釈します。アプリケーションブローカーは、対立する bid と ask を最適な price でマッチさせます。次の疑似コードで示されるように、取引が行われると、当事者間に契約が成立します。

code_block: <ListValue: [StructValue([('code', 'def process_bid(event, bid):\r\n """Trades a bid against the best priced asks."""\r\n unfilled_bid_volume = volume\r\n for ask in _get_asks_by_increasing_price(event):\r\n # 次の ask price が bid price より高いか、この bid で\r\n # 約定した場合、それ以上の取引は行われません。\r\n if unfilled_bid_volume == 0 or ask.price > bid.price: \r\n break\r\n\r\n # この ask が残りの volume の約定に必要な値より大きい場合、\r\n # 残りを取引します\r\n if ask.volume > unfilled_bid_volume:\r\n ask.volume -= unfilled_bid_volume\r\n _execute_trade(event, bid, ask)\r\n break\r\n\r\n # そうでない場合は、この bid で ask のすべての volume を取引します。\r\n unfilled_bid_volume -= ask_volume\r\n ask.mark_filled()\r\n _execute_trade(event, bid, ask)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d06e4f5b0>)])]>

金融市場が注文を効率的にマッチさせることでコンセンサス価格を見つけるのと同様に、予測市場は予測を効率的にマッチさせることでコンセンサス予測を見つけます。これにより、予測者のインセンティブが最大化され、よりよい予測を行うことで市場を修正する機会を生み出します。現実の世界で更新が行われて問題が解決すると、取引された契約一つ一つで、一方の当事者がインセンティブを得ます。同時に、双方ともにその経験から学ぶことができます。

3. 継続的な予測をサポートすることで、新しい情報が入ってきたときにコンセンサス予測がリアルタイムに更新されるようにする。

予測分析でとりわけ問題となるのは、新しい情報がどの時点でも表面化する可能性があることです。bid と ask として解釈された予測の傾向は、時間の経過とともに、参加者全員のコンセンサスを表すようになります。bid-ask スプレッド（取引相手が見つかっていない時点の bid と ask の値）をグラフ化することで、コンセンサスの進化を確認できます。

これは、COVID-19 に関連する確率（0～100%）の質問に対するコンセンサス予測の例です。青い線は bid の最高値、赤い線は ask の最低値を表しています。イベントが 9 か月間にわたって展開されるにつれ、確率が最低 10% から最高 90% まで変動しているのが確認できます。

4. 予測者へのパフォーマンスに関するフィードバックで、予測精度の長期的な改善を促す。

質問が解決したら、ユーザーに結果を通知するだけでなく、パフォーマンスを状況に合わせて分析できます。たとえば、そのカテゴリ、または現四半期でどのくらいの成果を上げているでしょうか。トップの予測者と比べてどうでしょうか。

好成績の予測者へのインセンティブとして、リーダーボードやバッジを付与するだけでなく、市場コンセンサスへの影響力が強まるよう、その人の予測の信頼性を高めます。次第に予測者は、より正確に予測できるトピックに魅力を感じるようになり、結果的に市場全体の予測精度も向上します。

職場で使用する他の多くのスキルと同様に、予測も時間をかけて改善させていくものです。インセンティブとフィードバックが適切に構造に組み込まれていれば、個人レベルでも市場全体でも精度の向上が期待できます。ここで重要なのは、より短い時間軸で質問を設定することです。「来年の新しいサービスの採用率はどうなるか」を問うのではなく、次の四半期の採用率を予測することから始め、それを反復します。

Google の内部予測市場に寄せられた、確率に関する最初の 200 の質問。質問に対する答えが得られる 6 か月前、3 か月前、2 か月前、1 か月前、1 週間前に集計した Google 社員のコンセンサスの確率（0～10%、10～20% など）を基準に質問をグループ化し、実際に起こったことと比較します。

青い線は完全な精度を表しています。つまり、10% の確率で起こると予測されたイベントが、10% の確率で実際に起こるということです。赤い線は市場コンセンサスの予測を表しています。非常に難易度の高い質問であっても、市場はかなり正確です。

5. 市場予測を機械学習と総合的に扱う

予測市場は、過去のデータが十分でなく、機械学習だけに頼ることができない場合に、そのギャップを埋めることができます。戦略的な意思決定に役立つデータはある程度持っているものの、正しい選択を判断できるほど十分ではないというのはよく見受けられる状況です。たとえば、あるプラットフォームにはお客様の消費行動に関する十分な時系列データがあるが、リリース前の新しいプラットフォームにはまだ何もないかもしれません。

予測市場と機械学習を総合的に利用する方法は 2 つあります。1 つ目の方法は、予測市場の出力をより大規模な予測分析システムの入力として使用する方法です。入力用のデータは、時系列データに対して機械学習の推論を実行することでも引き出すことができます。2 つ目の方法は、機械学習システムをマーケットメーカーとして追加し、ベースラインとなる bid-ask スプレッドと流動性を提供することで、正確な予測に対するインセンティブを高める方法です。

Google Cloud 上でプラットフォームを設計する

Google Cloud Platform（GCP）を活用することで、Google は少人数のチームで 1 年以内にプラットフォーム全体を構築し、何千人ものユーザーにスケーリングできました。堅牢なプラットフォームを非常に短期間でプロトタイプ化、構築、拡張するために使用した GCP ツールを具体的にご紹介します。

サーバーレスをプラットフォームの主軸として使用しました。App Engine を使用し、さらに取引のバックエンドを実装するために Cloud Run と Cloud Functions でもテストを行っています。

サーバーレスは優れたツールキットで、アプリケーションをビルドしてから、Compute Engine 上で使用するセルフマネージドのバックエンドの種類を決定できます。デプロイ、バージョニング、リソースのスケーリングに追加のコードを記述する必要がないため、バックエンドのアーキテクチャの柔軟性が確保されます。

Cloud Scheduler と Cloud Tasks はサーバーレスアーキテクチャをうまく補完し、成績優秀者へのバッジ付与のような定期ジョブや、市場の解決や分析の計算といった長時間にわたるバックグラウンドタスクの実行が容易になります。
Cloud Firestore は Datastore モードで実行し、アプリケーションデータベースとして利用します。スケーラブルな NoSQL クラウドデータベースなので、フロントエンドを柔軟性に作成でき、新しい機能を設計してビルドしてもすぐにスキーマを更新できます。また、複雑な階層構造のデータもサポートしています。今回のケースでは、bid、ask、取引済みポジションをマーケットエンティティの子として保存することで、データのクエリを迅速かつ簡単に実行できるようにしました。

データポータルを使用することで、たとえば、時間の経過に伴う市場全体のトレンドを可視化するなど、予測結果から得られる分析情報をダッシュボード化できます。Looker を使用すれば、市場予測と既存の予測分析を集約して、どちらか一方だけでは生成できない優れた分析情報を生み出すことができます。
分析向けの BigQuery や機械学習向けの BigQuery ML への簡単なエクスポートにも対応しており、人間のコンセンサスをアルゴリズムで絞り込むことができます。そのデータを基に GCP の Vertex AI の機能で予測モデルをトレーニングすれば（ほとんどコードを記述する必要はありません）、難しい戦略的な質問に対しても、人間と機械の推論を最良の形で組み合わせることができます。

Dataflow では、バックアップからの復元など、データストアでの大規模なバッチ処理を、マネージドプロセスとして実行できます。

予測市場の運営面でも、さまざまな基本的な GCP ツールを使用しています。使用したもの:

Logs Explorer を使用して、クエリがタイムアウトしたときや、内部 API で問題が発生したときなど、厄介な状況でのデバッグを実行しました。
Cloud Profiler と Cloud Trace は、非同期でよい Cloud Firestore クエリの不必要な同期実行といったスケーリングのボトルネックを早期に特定するのに役立ちました。
Cloud Error Reporting により、エラーのモニタリングの構成、根本的な問題への素早いアプローチ、より頻繁に発生しているエラーの特定が容易になりました。

使ってみる

予測分析を一つ上のレベルに引き上げ、組織の知恵を存分に活用する準備はできましたか。Google Cloud を利用したこのようなプラットフォームの構築についてさらに説明をお受けになりたい場合は、こちらのフォームにご自身の情報をご記入ください。

- シニアソフトウェアエンジニア Dan Schwarz

- 製造担当主要アカウントディレクター Lindsay Taylor

Google Cloud Platform を使用して再入院率を予測する

Wed, 24 Nov 2021 06:00:00 +0000

※この投稿は米国時間 2021 年 11 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

医療データに関する現在の課題:

現在、収集されるデータの量はこれまでにないほど増加しており、そのデータを理解して活用する必要性も急速に高まっています。あらゆる業種の組織が、データや分析情報への簡単かつ迅速なアクセスを実現して、ユーザーが情報に基づいてリアルタイムで行動できるようにしたいと思っています。医療分野も例外ではありません。

この最近の GCP のブログ記事では、電子医療記録（EHR）システムと、医療システムの相互運用性の重要性について説明しました。EHR システムには本来、システム間で通信する機能はありません。そのため、病院や診療所をまたいで医療システム内で患者を追跡することは簡単ではありません。EHR のデータは非常に複雑で、非常に多くの診断コード、治療コード、通院データ、医療機関データ、処方箋などが含まれています。さらに、病院が EHR システムをアップグレードした場合や患者が転院した場合には、（たとえ同じシステムを使用している場合でも）患者を追跡することは困難になります。

ソリューションとなるのは、乱雑な実際のデータをさまざまな EHR システム間で標準化する仕組みとしての役割を担う、共通のデータスキーマです。これは、FHIR（Fast Healthcare Interoperability Resources）と呼ばれています。

Google Cloud はこれまで、多くの組織が Healthcare Data Engine（HDE）を活用したソリューションを実装して、臨床データのストリーミングから FHIR レコードを生成するのを見てきました。これらの組織は、そのデータを BigQuery や Looker を使用して分析することにより、分析情報を引き出して臨床転帰を改善しています。

この Cloud への移行とビジネスインテリジェンス（BI）のモダナイゼーションにより、組織は、スケーリングの柔軟性、ビジネス指標とビジネスロジックについての信頼できる統合ビューを作成する機能、リアルタイムの決定を促進する拡張可能なアクティベーションレイヤを備えた単一のプラットフォームを手に入れることができます。

背景とビジネスの機会:

Mayo Clinic によると、計画外の再入院を経験する患者の数は、医療機関が提供する治療の質と成果を追跡して評価するための方法の一つです。定義として、7 日再入院率は、退院後 7 日以内に、予定されていないにもかかわらず病院に戻り、入院することになった患者の割合を意味します。この指標は、患者が受けた治療がどの程度のものだったかを示唆するものと考えられます。再入院率が高いことは治療の質が低かったことを意味していますし、不必要な再入院は高くつきます。このことは特に、「価値に基づく償還」が適用される病院や医療機関に当てはまります。

医療分野の他の多くの質と成果の指標の中でも特に、病院の再入院率を正確に分析および理解することに関して、次のような共通する障害があります。結果の共有におけるレイテンシ、スケーラビリティ、スピード、ガバナンス、セキュリティ、全体的なアクセシビリティです。

最近、Google は BigQuery に保存された FHIR データと、BigQuery ML、Looker、Cloud Functions を使用して、7 日再入院率を予測する実際のユースケースについて検討しました。

BigQuery は、Google Cloud で提供されるフルマネージドのサーバーレス SQL データウェアハウスおよびデータレイクです。高性能でクエリ実行が高速であり、データが Cloud 内と他の場所への転送中に十分に暗号化されるため、セキュリティが確保されます。また、BigQuery ML と呼ばれる機能を使うと、ユーザーは BigQuery 内で標準 SQL を使用して機械学習（ML）モデルを実行できます。BigQuery ML で提供されるモデルには、線形回帰、二項ロジスティック回帰、多クラスロジスティック回帰、K 平均法、行列分解、時系列、ブーストツリー、ディープニューラルネットワーク（DNN）などが含まれます。また、入力データに基づいてさまざまなモデルアーキテクチャを検索して最善のモデルを選択してくれる、AutoML 機能も使用できます。BigQuery ML ではデータを移動する必要がないため、開発スピードを向上させることができ、データサイエンスチームは時間と労力を、より堅牢で複雑なモデルを作成することに集中させることができます。
Looker は Google Cloud のクラウドネイティブな BI および分析のプラットフォームであり、ユーザーは、そのデータベース内アーキテクチャとセマンティックモデリングレイヤにより、リアルタイムでデータにアクセスできるようになります。Looker は BigQuery（および他のほとんどの SQL 互換データベース）に直接接続できます。つまり、データを移動したりコピーを作成したりする必要はなく、キューブや抽出に制約されません。これにより大規模なガバナンスが可能になり、Looker は、ユーザーが情報を入手し、分析情報に基づいて行動を起こすにあたっての、信頼できる単一の情報源となります。
Cloud Functions は、クラウドサービスの構築と接続に使用できるサーバーレスの実行環境を提供します。トリガーされたときに実行できる、シンプルな単一目的の関数を作成することができ、Looker と BigQuery それぞれの情報の間で橋渡しの役割を果たすことができます。

このユースケースソリューションの目標は次のとおりです。（1）病院の臨床医と管理者が、7 日再入院率に関してどこに最も力を入れるべきかを理解できるよう支援する（2）アラート、セルフサービス、データドリブンなアクションにより、プロアクティブな介入を開始できるようにする（3）Cloud の最新の統合プラットフォームで、データのスケーリング、ガバナンス、セキュリティ保護を行う。

ソリューションとその仕組み:

データを BigQuery に取り込み、BigQuery を Looker に接続したら、分析を開始できます。Looker のセマンティックモデリングレイヤは LookML を活用します。これは、再利用可能なコンポーネントに変換することで SQL を簡素化する、抽象化された SQL です。LookML を使用することで、統合指標を構築して定義するための変換を行うことができます。そして、AutoML Tables による分類と回帰のための BigQuery ML Looker ブロックを実装することにより、BigQuery ML モデルを Looker のセマンティックモデリングレイヤで直接作成できます。

このブロックは、トレーニング方法、評価方法、予測方法のコンポーネントを実行してターゲット変数を求めます。今回のユースケースの場合、ターゲット変数は 7 日再入院の傾向スコアです。すでに説明したように、BigQuery ML では標準 SQL を使用してこれを簡単に行うことができます。モデルのパフォーマンスは、BigQuery ML で提供されていてすぐに使える評価関数を使用して評価でき、CREATE MODEL 構文のモデルオプションを使用して、必要に応じてハイパーパラメータを簡単に調整できます。

Looker でモデルを構築するメリットは次のとおりです。

従来のデータサイエンス手法と異なり、コードを一か所で管理できるため、使用とアクセスが容易になる
新しく取り込んだデータに基づくモデルの自動的な再実行を継続するための更新頻度を選べる
コードを迅速に実装でき、Looker UI で結果の可視化と検討を容易に行える

モデルの重要業績評価指標に着目したダッシュボードを Looker 内で作成できます。他のデータサイエンス手法を使用する場合、精度と適合率の結果は利用できないか、共有するのが難しいことがあります。Looker のダッシュボードではモデルのパフォーマンスについての透明性が提供されます。また、新しいデータが追加されるたびに Looker は BigQuery からそれを直接読み込むため、予測の変化をリアルタイムで確認したり、モデルのパフォーマンス KPI の変動を確認したりできます。

モデルのパフォーマンスダッシュボード: 混同行列や ROC カーブなど、未知のデータに対する BQML モデルのパフォーマンスを示す精度と適合性の指標に着目します。また、トレーニング期間、F1 スコア、再現率、ログ損失も確認できます。

モデルのパフォーマンスを確認するためのダッシュボードを構築することに加えて、病院全体での、および患者レベルでの再入院率を分析することもできます。Google は、病院の臨床医、ケアマネージャー、管理者が、概要ダッシュボードで施設別、専門領域別、条件別の病院の全体的なパフォーマンスをどのように確認できるかを示す例を構築しました。この例では、患者ビューで個々の患者とその平均再入院率スコアも確認できます。

再入院の概要ダッシュボード: 全体の再入院率が 21% であることを示すサンプル

患者の再入院ダッシュボード: 患者 John Doe の平均再入院率リスクスコアが 34.16% であることを示すサンプル

*免責事項: このユースケースの検討では、サンプルの合成データを使用しています（実際の個人情報または保護対象保健情報は使用していません）

臨床医やケアマネージャーは、予測スコアに基づいて個々の患者をモニタリングするアラートを Looker 内で設定できます。Looker のアラートにしきい値を設定して、そのしきい値に到達したときに通知を受け取れるようにすることもできます。これにより、ケアマネージャーは患者の退院ケアプランを作成する際に、後手後手で対応するのではなく、よりプロアクティブに行動することができるようになります。

リスクスコアが高い患者に対しては、フォローアップのためのメールをプラットフォームから直接送信することもできます。

これは Looker アクションの一例です。他にも次のような多くのことができます。

Twilio を使用してテキストメッセージを送信する
データを Google スプレッドシートに送信する
データを Google Cloud Storage などのリポジトリに送信する
フォームを使用して BigQuery に書き戻す

Cloud Functions を使用すると、書き戻しのプロセスが容易になります。今回のユースケースでは、退院時の患者のフィードバックと満足度を収集するために LookML でフォームを作成しました。これにより、フォームを提出した際に Looker アクションによって書き戻しがトリガーされます。書き戻しは Cloud Function によってバックグラウンドで実行されます。フォームを使用することで、病院は分析のためのアンケートデータの収集と構造化された形式での保存をシームレスかつ簡単に行えるようになります。データが BigQuery に取り込まれたら、再入院率リスクスコアを再学習して予測するための追加の特徴として、データを最終的に BigQuery ML モデルに戻すことができます。

新規アンケートダッシュボード: Looker の書き戻しが、Looker アクションのフォームを使用してどのように行われるかを示すサンプル

サンプルの Cloud Functions 関数コードを GitHub でご確認ください。

有用性と今後の可能性:

Google Cloud は、データに関するシームレスなエクスペリエンスを提供します。このソリューションは、結果の共有におけるレイテンシ、スケーラビリティ、スピード、ガバナンス、セキュリティ、全体的なアクセシビリティの課題解決を目指したものです。Looker のデータベース内アーキテクチャとセマンティックモデリングレイヤは、BigQuery と BigQuery ML の性能、スピード、セキュリティを受け継いでいます。そして、Cloud Functions を使用して実装することにより、データと運用ワークフロー両方の強化が実現できます。このようなワークフローは、臨床医、ケアマネージャー、病院管理者、データサイエンティストが日々の業務に取り組む方法に影響を与え、結果として医療コストを下げ、患者治療の質を向上させることができます。

このソリューションの構築に関する今後の取り組みには、GCP Healthcare NLP API の活用が含まれるでしょう。Healthcare NLP API は、臨床に関するメモなど、構造化されていないデータを、データの検討や下流での追加の AI / ML 活用に適した構造化形式に変換します。

Looker の医療およびライフサイエンス分野のソリューションに関する今後の進展にご期待ください。

- Looker エンタープライズカスタマーエンジニア Rachel Kamienski

- Looker テクニカルソリューションコンサルタント Alick Zhang

自社データを活用してワークフローの最適化に取り組むマーケターが、Looker をどのように役立てているか

Fri, 19 Nov 2021 01:00:00 +0000

※この投稿は米国時間 2021 年 11 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

変革に備え、ブランドやマーケティングチームが新しい体験で消費者を惹きつける方法を見つけ出すために、自社データがますます重要となっていくことは明白です。使い慣れてきたサードパーティのデータから離れ、自社組織のデータを真に活用しようとしたとき、今日マーケターが抱えている問題点（データがサイロ化されていて顧客の全体像をとらえにくい、分析情報が行動に結びつかない、一般的なデータアクセスの問題）がはっきりと見えてきます。

自社データの収集は第 1 段階として非常に重要ですが、単にデータを収集するだけでは成功は保証されません。競合他社から抜きん出て、ビジネスの目標に向かって着実に前進するには、マーケターは自社データを十分に活用できなければなりません。どうすれば、マーケターは組織の自社データから価値を創出できるようになるでしょうか。

Looker と Media.Monks（旧社名 MightyHive）は、5 月に「データを使用してマーケティングインテリジェンスを獲得し、測定可能な影響を促進する」というウェブセミナーを主催し、両社のお客様であるブランドが自社データ掌握のために採用している戦略を紹介し、これをテクノロジーの支援で実現したこと、そして Looker 分析プラットフォームが成功への鍵となったことを事例を挙げて説明しています。

しかし、テクノロジーだけではデータの課題すべてを解決することはできません。自社データの価値の認識に関して言えば、ブランドの成功を決めるのは、以下に概説する原則に忠実に従えるかどうかなのです。テクノロジーは重要ですが、それを活用するには、人材、プロセス、戦略の正しい組み合わせが必要だからです。

誰もアクセスできないデータは宝の持ち腐れ

サイロ化されたデータや、アクセスしにくいデータは、移行しやすく、摩擦なく利用できるデータと比べて価値が劣ります。そして、データとそこから得られた分析情報や能力が適切な人材によって使用されなければ（または、理解しにくければ）、広告主が日ごとに機敏で賢くなっている市場で競合力を維持できません。

データの摩擦を解消し、有用に活用するための作業の大半は、アクセスに使用するプラットフォーム内で行われます。そして、データにアクセスして恩恵を得られる関係者チームは多けれど、プラットフォームの多くは専門的すぎてチームが理解できないか（SQL データベース）、セキュリティリスクが大きすぎる（サイト分析プラットフォーム）のが実情です。

刻一刻変化する世界でマーケターが要求する速度とアジリティを考えた場合、使いやすさは極めて重要になります。ウェブセミナーのオープニングで、Looker のアウトバウンドプロダクトマネージャーである Elena Rowell は、ブランドにおける基本的なデータ要件は「データの複雑性に応じた柔軟性」であると言及しました。

顧客を理解する

クラス最高のデータドリブンなマーケティング組織になるための変革は、長くて厳しい過程に見えるかもしれませんが、実際はそうでもありません。Elena は、これは繰り返しの過程であり、その変革の過程でブランドは急速に価値を実現できると考えています。「顧客行動についての知見が徐々に蓄積されるにつれ、顧客に関するより深い理解に近づきます」と彼女は述べています。「これはスイッチの切り替えのようなものではなく、その過程で多くの価値が得られるものです。」

彼女は、英国を拠点とする保険会社の Simply Business がこの手法を採った例を示しました。この会社は最初に、Looker を使用して信頼できるデータへの簡単なアクセスを作り上げることにより、よりデータドリブンな意思決定を実装しました。これにより、同社はマーケティングキャンペーンを深く掘り下げられるようになり、その過程で必要な変更を実装していきました。Looker でリストの構築を開始し、これによってアウトバウンドコミュニケーションキャンペーンのターゲットを正しく設定し、的確にスケジューリングできるようになりました。

最初の目標は、マーケティングキャンペーンで何が起きているのかを十分に理解することでした。しかし、保存されているデータとインテリジェンスを活用することで、Simply Business はあらゆるステップにおいて価値を見出せるようになったのです。

影響に関する分析情報

サブスクリプションベースのマルチビタミンサービスを提供する e コマース、Ritual は、自社のユーザー獲得チャネルと広告での取り組みについて実際の影響を測定する方法を必要としていました。ビジネスを効果的に成長させる手段のひとつは、どの広告やメッセージングの影響が最も大きかったのか、現在と将来の顧客の心に響いたのは何だったのかを明察することであると、同社は理解していました。

Ritual が Looker の使用に舵を切ったのは、マーケターに自社データへのインタラクティブなアクセスを提供できるからでした。ウェブキャスト「ユーザー獲得の 360° ビュー」では、データサイエンティストの Kira Furuichi 氏と Ritual のユーザー獲得アソシエートマネージャーの Divine Edem 氏を招いて、e コマースの新興企業がユーザー獲得とそのパフォーマンスに関する多面的な理解を深めるために、プラットフォームとオンサイトのアトリビューションデータをどのように活用しているかについて話していただきました。

今では、Ritual のサイトに引き寄せるトラフィックチャネルだけでなく、各チャネルからサイトに来た顧客がその後どのような行動を取るかについても的確に情報をとらえて、顧客の間でプロダクトがどのような反響を呼んでいるかを総合的によく理解できるようになりました。消費者インサイトチームはこの情報をユーザー獲得チームと共有することで、特に Google 広告などにおいて協力して全体的な意思決定を行えるようになりました。広告コピーやビジュアルについての深遠な分析情報を収集することで、毎日のルーティンに取り入れる新しい商品を探している見込み顧客が、一体何を求めているかに両チームの焦点を合わせることができます。また、ビジネス成長とユーザー獲得は同社全体の戦略に占める割合が大きいことから、社内で同じ領域に注力しているチームは他にもあり、それらのチームとこの分析情報を共有することでコラボレーションが促進されました。

Edem 氏は「Google のようなユーザー獲得チャネルプラットフォームを Looker と同期させることで、プロダクトチーム、エンジニアリングチーム、オペレーション業務のチームなど、ユーザー獲得チーム以外のチームの主要関係者がチャネルで起こっていることを理解し、機会の可能性を把握できるようになりました。チャネルはとてつもなく大きいのですが、情報の一元化と同期ができる Looker を導入したことで、本来なら非常に膨大な処理が軽減され、データの探索と発見が簡単になりました。精度の高い虫めがねでのぞいている気分です」と述べています。

自社データのアクセス、分析、有用化

どの企業でも、システム統合から取り残され気味なのがマーケティングです。IT チームは往々にして、専門分野のマーケティング知識はありません。しかもデータに対するニーズは百社百様。そうしたニーズに応えられるのが Media.Monks です。同社は専門知識を投入してマーケティングプロセスを導き、技術リソースを集結し、ブランドのロードマップに沿ってプロセスを実現するサービスを提供しています。専門分野のマーケティング知識と、エンジニアリングおよびデータサイエンスに関する深遠な経験を併せ持つ Media.Monks は、ブランドのリソース不足により社内に生じる空洞化を補い、データ戦略の加速化を支援します。

Looker 上で動作し、Looker と連携してブランド固有のニーズを満たすカスタムアプリケーションをパートナー様に開発していただけるように、Looker 拡張フレームワークを提供しています。Media.Monks は、こうしたカスタム Looker アプリケーションの開発も行い、読み取り専用のダッシュボードだけでなく、プラットフォームやエコシステムをまたいでアクションをトリガーするためのツールやインターフェースも提供することができます。

たとえば、Media.Monks が最近マーケター向けに開発した Looker アプリケーションでは、CRM データから自社オーディエンスを定義し、そのオーディエンス定義を Google の Customer Match API に送信して、最終的にオーディエンスを特定の Google 広告アカウントに送信して使用することができます。このエンドツーエンド処理はすべて Looker の 1 つの画面内で行われるため、従来は煩雑でエラーが起きやすかった処理を、技術的な知識のないユーザーでもわずか数分で完了することができます。

Looker の自社データを Google 広告で有用化するために Media.Monks が構築したプロダクト

サイロを打ち砕き、データを組織全体で利用可能にし、有用化する道を構築することは極めて重要です。テクノロジー面では Looker によってかなり楽になりますが、データを思いどおりに扱うには、専門知識、労力、時間も必要です。そこでお役に立てるのが、Google の経験と GC [Google Cloud] パートナーエコシステムです。

Looker プラットフォームにより、新しいデータエクスペリエンスに無限の可能性が拓け、採用、デプロイ、ユースケースをサポートする適切なパートナーにより、変革過程のあらゆる段階において価値創出を加速できるようになります。

広告チャネルのパフォーマンスをより正確に理解することで、広告プラットフォームの有効性を過大評価するリスクを最小化できます。
何が顧客の共感を呼ぶかについての洞察を明らかにすることで、広告コピーとクリエイティブを的確に最適化できます。
社内でデータを必要とする関係者向けにデータを民主化できます。Google スプレッドシートや Slack などのコラボレーションツールとの統合により、Looker へのアクセスを限定されているチームメンバーにも価値を提供できます。

自社データを扱う手法や、各ブランドが Looker を使用してどのように成功を収めたかの詳細については、ウェブセミナーをご覧になり、採用されている戦略のいくつかをお確かめください。また、Looker JOIN 年次コンファレンスに登録して参加すると、Google の「マーケティングチームを支援する 3 つの方法: 常に変化に先んじるために」のプレゼンテーションをご覧になれます。「Empowering Others with Data」（データを活用して支援）のカテゴリをご覧ください。

JOIN への参加は無料ですご登録はこちらで受け付けております。Looker を活用して、レポートやダッシュボードにとどまらず、ビジネスとともに成長する、カスタムのデータドリブンエクスペリエンスを構築して提供する方法、開発者が革新的なデータプロダクトを迅速に構築して、データが全員に確実に行き渡るようにする方法についてのセッションにご参加ください。

- Media.Monks エンタープライズコンサルティングマネージャー Hayden Klei 氏

- Google Cloud プリセールスマネージャー Zev Lebowitz

地理空間の分析情報をビジネス目標達成に役立てる方法

アーキテクチャフレームワークの最新ベストプラクティスで Google Cloud のワークロードを強化

Fri, 29 Oct 2021 10:00:00 +0000

※この投稿は米国時間 2021 年 10 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

アーキテクチャフレームワークは、お客様が Google Cloud 上で安全性、信頼性、スケーラビリティに優れたワークロードを設計、構築しつつ、費用とパフォーマンスの最適化テクニックも応用できる、一連の正規ベストプラクティスの活用をサポートします。

アーキテクチャフレームワークは 6 つのカテゴリに体系化できます。

システム設計上の考慮事項では、コンピューティング、ストレージ、データベースのような基盤を築く構成要素をカバーし、ベストプラクティスを展開することでワークロードの設計を支援します。
卓越した運用では、運用能力の構築と最適化の支援といったトピックを取り上げています。
セキュリティ、プライバシー、コンプライアンスでは、セキュリティ対策を強化するためのセキュリティやコンプライアンス面での考慮事項を取り上げています。
信頼性では、ワークロードの復元力の向上といったトピックを取り上げます。
費用の最適化では、クラウド運用の費用を抑える技術やベストプラクティスを紹介しています。
パフォーマンスの最適化では、ワークロードの効率を改善するツールやテクニックを紹介しています。

本日、フレームワークの最新版（2.0）をリリースいたします。このフレームワークは、ワークロードが初めてデプロイされた瞬間からお客様がベストプラクティスを採用できるように支援する専用の機能で、Google Cloud のスタッフ、パートナー、お客様の集合的な経験を情報源としています。各カテゴリはモジュール化されたサブトピックに分類されているため、ワークロードのデザインを助ける Google Cloud やオープンソースのプロダクトについての説明がある一方で、「システム設定によるネットワーキング」または「信頼性による高可用性」といった特定のトピックについても重点的に知ることができます。

フレームワークを利用する理由

Google Cloud では、お客様にビジネスの可能性を開放してもらえるように、プロダクトや機能を改善し続けています。正規のベストプラクティスを公開し、サポートを提供することで、Google 社員、パートナー、Google のクラウドユーザーは、フレームワークに沿って、GCP 上でのワークロード実行の成功への道筋を作ることができるようになります。新しい技術に関する集合知が時間とともに成熟していくにつれ、経験を通して得たことを他の人も学ぶことができるように、そうした技術から得たワークロード運用に関する重要な知識を伝えたいと考えるようになりました。

実施した Architecture Framework Workshop で Google のセールス、サポート、プロフェッショナルサービスのチームと接した多くのお客様にはご満足いただいており、結果としてお客様は自身のワークロードの改善点を特定できるようになりました。継続的な習慣としてアーキテクチャフレームワークのベストプラクティスに沿ったワークロードのレビューと調整をおすすめします。このアプローチは、プロダクトが成熟し、ユースケースが生まれ、有用なパターン（またはアンチパターン）が蓄積され、時間の経過とともにアーキテクチャフレームワークのコンテンツに知識が集約されるにつれて、重要性を増していきます。

次のステップ

Google はこれからもベストプラクティスのカタログを増強する作業を続け、Google Cloud のお客様やパートナーがより簡単にワークロードやビジネス機能を最適化するタイミングを分析できるようにします。今後、Google Cloud コミュニティを通してアーキテクチャフレームワークに関するコンテンツを追加し、アーキテクチャフレームワークの露出度、認知度、フィードバックを拡充していきますので、最新情報にぜひご期待ください。 Google は、継続的な Google スタッフからの協力に加え、Google のパートナーやお客様ベースからのさらなる貢献を、今後リリースするコンテンツに組み込んでいく予定です。皆様からのフィードバックをお待ちしております。

最後に重要な点として、アーキテクチャフレームワークのようなイニシアチブは、ベストプラクティスを共有することに情熱を注ぐスペシャリストの共同作業を通してのみ成功させることができるものです。初期のフレームワーク構築は、GCP スペシャリストのコアグループが小規模で始めたものでしたが、すぐに Google 内部の 20% プログラムを通して勢いに乗り、Google 内の職務や所在地の違いを超えた専門知識を活用できるようになりました。

アーキテクチャフレームワークの詳細についてはこちらをご覧ください cloud.google.com/architecture/framework

^{アーキテクチャフレームワークバージョン 2.0 の提供を支援してくれた Google 社員コミュニティ、Vivek Rau、Pathik Sharma、Daniel Lees、Amber Yadron、Shylaja Nukala、Brandon Bouier、Fernando Rubbo、Jenny Rosewood、Rafee Mohamed、Kumar Dhanagopal、Markus Schneider、Minh "MC" Chung、Rachel Tsao、Sam Moss、Nitin Vashishtha、Pritesh Jani、Ravi Bhatt、Olivia Zhang、Zach Seils、Tabitha Smith、Jhilam Biswas、Mohamed Fawzi、Vijay John-Britto、Alida Wilms、Mike Pope、Arun Reddy、Abhijeet Rajwade、Lucy Carey、Todd Kopriva、Victoria Hurd、Michelle Irvine、Iain Foulds、Olaf Schnapauff、Hamsa Buvaraghan、Maridi Makaraju、Gargi Singh、Nahuel Lofeudo、Mark Schlagenhauf に感謝します。}

- Google Cloud、ソリューションアーキテクチャ担当ディレクター、Rob Rosen

- ソリューションエンジニア、アーキテクチャフレームワークプロジェクトリーダー、Omkar Suram

Google Kubernetes Engine で進化戦略を実行する方法

Fri, 12 Jul 2019 01:00:00 +0000

*この記事は Yujin Tang と David Ha による Cloud Blog の記事 "How to run evolution strategies on Google Kubernetes Engine" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

強化学習（RL）は、ゲーム、チェス、ロボティクスですばらしい成果をあげており、それとともに機械学習コミュニティでの人気も高まっています。以前のブログ投稿では、Google の強力なコンピューティングインフラや、ハイパーパラメータのベイズ最適化などスマートなトレーニングサービスを活用して、AI Platform で RL アルゴリズムを実行する方法を紹介しました。このブログでは、進化戦略（ES）アルゴリズムについて説明し、Google Kubernetes Engine（GKE）で実行する方法を紹介します。

進化戦略は、進化の考え方に基づいた最適化テクニックです。最近、ES は RL に代わってさまざまな難題に対処するものと見なされるようになっています（1、2）。特に、ノイズの多いポリシー最適化の勾配推定をバイパスでき、かつ収束の早い分散コンピューティングに向いた性質を備えているという 2 点が、よく知られている ES のメリットとしてあげられます。ES は 1960 年代に開発され、容易にスケールする点がメリットとして知られていました。しかし、研究コミュニティのオープンソースプロジェクト（Salimans 他、2007 年）によって、ES を大量のマシンにスケーリングすることで RL アルゴリズムの最高性能に匹敵する結果を出せることが実証されたのは、つい最近のことです。そのため、最新の研究に進化型のアルゴリズムを取り入れる方法を探るディープラーニング分野のリサーチャがますます増えています（1、2、3、4、5）。

進化型コンピューティングアルゴリズムをスケーリングする優れたインフラストラクチャを構築すれば、この領域はさらに進展するということは判明していましたが、大規模システム開発に明るい研究者は多くはいません。幸い、ここ数年間で Kubernetes などのテクノロジーが生み出され、専門のエンジニアでなくても簡単に分散環境によるソリューションを構築できるようになりました。そこで本稿では、Kubernetes を活用してスケーラブルな進化型アルゴリズムをデプロイする仕組みの実例を紹介します。コードと手順もこちらで公開していますので、ML 研究において GKE 上で ES を試す際の参考にお役立てください。

ちなみに、Google Cloud ではコンテナによる分散トレーニングが可能なプラットフォームとして AI Platform も提供しています。AI Platform では TensorFlow と同様の分散処理をサポートする ML フレームワークが利用可能です。しかしその目的は、おもにモデルを非同期でトレーニングすることであり、次のセクションで説明するような ES の分散コンピューティングの目的とは異なります。

進化戦略入門

ES は一種のブラックボックス最適化です。ベースとなるタスクや関数に勾配がない場合や、勾配の計算が非常に複雑な場合、または勾配推定にノイズが多く学習できない場合など、勾配ベースのアルゴリズムではうまく解決できない ML タスクに有効です。例として、下の図の左側に示す地形に立っていることを想像してみてください。あなたのタスクは、目隠しをして最も低い場所へ向かうことです。あなたは複数の魔法の玉を持っており、それを介してしか周囲の状況を知ることができません。

図 1. 球関数（左）と Rastrigin 関数（右）（出典: Wikipedia）

大ざっぱに言えば、勾配ベースのアルゴリズムでは、玉を落として転がしながら行く先を決めるというステップを経ていきます。玉の動く速さを見て、一番速く転がる方向（勾配が一番急な方向）に進みます。左側の地形であれば、このルールに従って何度か玉転がしを繰り返せばゴールにたどり着けます。しかし、同じやり方を右側の地形で試すとどうなるでしょうか。おそらく、山に囲まれた谷底にはまってしまい、目標は達成できないでしょう。

ES のアプローチはこれとはまったく異なります。最適化のステップごとに、複数回の試行を行います。そして、高い適応度（fitness）を示した設定に基づいて進み先を決めます（適応度とは、試行がどのくらい優れているかを測る指標です。上図の地形の例では地面の高さがそれに当たり、低いほど適応度が高いことになります。RL で言えば試行で得られる累積報酬に当たります）。この過程を通じて、適応度が低い試行は取り除かれ、適応度がもっとも高いものだけが生き残ります。これが進化の過程に似ているため、進化戦略という名前が付けられています。

先ほどのたとえに当てはめて ES の仕組みを説明するなら、各ステップで玉を落として転がす代わりにピストルに玉を込めて数発を発射し、いくつかの玉を周囲に散りばめる、ということになります。それぞれの玉が地面に打たれた時点で位置と高度がわかるので、ステップを繰り返すうちに高度が低いと推定される場所に徐々に移動していけます。この方法は、図の左右どちらの地形にもうまく働きます（高い山の向こうにも届く強力なピストルを使うことを想定します）。またこの方法なら、複数回の試行を同時に実行することで最適化を簡単に高速化できます。ますたとえるならピストルの代わりに散弾銃を使うようなものです。

ここまで、ES の基本的な考え方と仕組みを説明しました。さらに興味がある方は、筆者によるブログ記事により詳しい説明が記載されていますので、ぜひ読んでみてください。

Kubernetes 入門

Kubernetes は、コンテナ化したワークロードとサービスを宣言的な設定や自動化を活用して管理するためのプラットフォームです。Google が開発を始め、2014 年にオープンソース化されました。Kubernetes を詳細に解説するには何ページも必要なので、ここでは概説にとどめ、ES への応用を中心に説明します。

これまでの説明で、ES がいわゆるコントローラワーカー（controller-worker）アーキテクチャで実装できることが分かるかと思います。この場合、ある設定で試行するようコントローラがワーカーに命令し、ワーカーから戻ってきた結果に基づいて最適化を進める、という処理を繰り返し行います。この実装方法について、先ほどの地形の例を使って Kubernetes 上で ES を実行する方法の定義と説明を書いてみましょう。

今回は、銃や玉は使いません。その代わり、携帯電話で誰かに連絡して玉を発射してもらえます。ただしその前に、何を実行したいのかを具体的に伝えなければなりません（この例では、玉を発射してもらうことです）。そこで「サービスプロバイダへのメモ」に仕様を記述します。また記録のため「自分用のメモ」も準備します。サービスプロバイダにこの仕様を送れば、そこからは Kubernates の楽しい仕掛けが動き始めます。

この仕様を Kubernetes で実装する場合、サービスプロバイダへのメモにある「やるべきこと」の部分をワーカーのプログラムとして記述し、自分用のメモの部分をコントローラのプログラムとして記述します。これらをいくつかのランタイムライブラリと合わせてパッケージ化し、コンテナイメージを作成します。そして Kubernetes がサービスプロバイダとなり、ワークロードと呼ばれる仕様を受け取り。ワークロードはコンテナイメージとリソースなどのいくつかのシステム設定で構成されます。

上記例にある 10 台のクルマは、クラスタ内の 10 個のノードに相当します。また 100 人の玉の射撃手は、実行したいコンテナ（Kubernetes の用語ではポッドと言います）の数を表します。Kubernetes は、これらのポッドを用意する責任を持ちます。また 100 人の射撃手を用意できても、個々の射撃手と直接やりとりして結果を集めたりするのは面倒な作業です。中には、病気で休んだ人（マシンの再起動により動作していないコンテナ）が、あなたの知らない別の人（新しく起動したコンテナ）に仕事を引き継いでいるかもしれません。こうした面倒に対処するため、Kubernetes はワークロードをサービスとして公開し、コントローラとワーカーの連絡窓口とします。サービスは関連するポッドを取りまとめているので、いつでもポッドに取り次いでくれるうえ、負荷の分散も可能です。

プラットフォームとして Kubernetes を使うと、高可用性（希望どおりの数のポッドを確実に実行可能）と大きな拡張性（実行時にポッドを追加・削除可能）が得られます。こうした性質を備えた Kubernetes は、ES に理想的なプラットフォームだと私たちは考えています。また、Kubernetes の可用性と拡張性をノードレベルにまで拡張する GKE を導入することで、さらに優れたプラットフォームが実現可能です。

GKE による ES の実装

では、ES の実装方法の詳細と、それを GKE で実行する手順を見ていきましょう。コードと実装手順はこちらでアクセスできます。

実装

上述のとおり、実装にはコントローラワーカーアーキテクチャを採用します。各ワーカーは独立したサーバーで構成され、コントローラがクライアントとなります。プロセス間通信には gRPC を利用します。リモートプロシージャコール（RPC）はデータを渡す手段としてはメッセージパッシングインターフェース（MPI）などの他の選択肢ほど高効率ではありません。しかしデータのパッケージングが簡単で耐障害性も高いため、クラウド環境ではよく使われています。

次のコードスニペットに、メッセージの定義を示します。「ロールアウト」とは 1 回の試行を表しており、rollout_reward はロールアウトから返される適応度です。

code_block: <ListValue: [StructValue([('code', 'message RolloutRequest {\r\n // Index of rollout\r\n int32 rollout_index = 1;\r\n // Random seed from the master\r\n int32 env_seed = 2;\r\n // The weights of the neural network policy\r\n Repeated double policy_weights = 3;\r\n // Whether this request is evaluation\r\n bool evaluate = 4;\r\n}\r\n\r\nmessage RolloutResponse {\r\n // Index of rollout\r\n int32 rollout_index = 1;\r\n // The reward collected in the rollout\r\n double rollout_rewards = 2;\r\n}\r\n\r\nservice Rollout {\r\n // The RPC service for policy evaluation\r\n rpc RolloutWithParameter(RolloutRequest) returns (RolloutResponse) {}\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d0516b940>)])]>

このサンプルで利用する ES アルゴリズムは、estool に基づく Parameter-exploring Policy Gradients（PEPG）と、pycma に基づく Covariance Matrix Adaptation（CMA）です。これらは解決がとりわけ難しい連続制御 RL 環境である Google Brain の Minitaur Locomotion や OpenAI の BipedalWalkerHardcore-v2 でも試せます。また、コードを拡張して ES アルゴリズムを追加したり、設定を変更して独自の環境でアルゴリズムを試したりすることも簡単です。具体的には、algorithm.solver.Solver で定義されたインターフェースに従った実装であれば他のコードと合わせて実行できるはずです。

GKE で ES を実行する

GKE でのコードの実行には、Google Cloud Platform（GCP）で動作するクラスタが必要です。こちらの手順に従ってクラスタを作成します。この例では、次のコマンドと設定を使ってクラスタを作成しましたが、必要に応じて変更しても構いません。

code_block: <ListValue: [StructValue([('code', 'GCLOUD_PROJECT={your-project-id}\r\n\r\n# Create a cluster.\r\ngcloud container clusters create es-cluster \\\r\n--zone=us-central1-a \\\r\n--machine-type=n1-standard-64 \\\r\n--max-nodes=20 \\\r\n--min-nodes=16 \\\r\n--num-nodes=17 \\\r\n--enable-autoscaling \\\r\n--project ${GCLOUD_PROJECT}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d054eb1c0>)])]>

クラスタができたら、次の 3 つのステップでサンプルの ES コードを GKE で実行できます。それぞれ簡単な bash コマンドです。

コントローラとワーカーのコンテナイメージをビルドする
ワーカーをクラスタにデプロイする
コントローラをクラスタにデプロイする

code_block: <ListValue: [StructValue([('code', '# Step 1: Build a container image for the controller and the workers.\r\ngcloud builds submit \\\r\n--tag gcr.io/${GCLOUD_PROJECT}/es-on-gke:1.0 . \\\r\n--timeout 3600 \\\r\n--project ${GCLOUD_PROJECT}\r\n\r\n# Step 2: Replace the ${GCLOUD_PROJECT} in the YAML file and run the command.\r\nkubectl apply -f deploy_workers.yaml\r\n\r\n# Step 3: When all the workers are started and running,\r\n# replace the ${GCLOUD_PROJECT} in the YAML file and run the command.\r\nkubectl apply -f deploy_master.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d06e16520>)])]>

図 2. デプロイが成功した GCP コンソールの例

以上です。これで、GKE 上の指定した環境で ES のトレーニングが実行されています。

トレーニングプロセスの確認は、次の 3 つの方法で行えます。

Stackdriver—GCP コンソールで [GKE Workloads] ページをクリックすると、ポッドの詳細ステータスレポートが表示されます。es-master-pod の詳細に移動すると、[Container logs] から Stackdriver のログを確認できます。ここから、トレーニングやテストの報酬を確認します。
HTTP サーバー—今回のコードではコントローラ内で簡単な HTTP サーバーが動作しており、トレーニングのログに簡単にアクセスできます。[GKE Services] ページにある es-master-service のエンドポイントからアクセスできます。
kubectl—kubectl コマンドでもログやモデルを取得できます。例として以下のコマンドを示します。

code_block: <ListValue: [StructValue([('code', "POD_NAME=$(kubectl get pod | grep es-master | awk '{print $1}')\r\n\r\n# Download reward vs time plot.\r\nkubectl cp $POD_NAME:/var/log/es/log/reward_vs_time.png $HOME/\r\n\r\n# Download reward vs iteration plot.\r\nkubectl cp $POD_NAME:/var/log/es/log/reward_vs_iteration.png $HOME/\r\n\r\n# Download best model so far.\r\nkubectl cp $POD_NAME:/var/log/es/log/best_model.npz $HOME/\r\n\r\n# Download model at iteration 1000.\r\nkubectl cp $POD_NAME:/var/log/es/log/model_1000.npz $HOME/\r\n\r\n# Download all test scores.\r\nkubectl cp $POD_NAME:/var/log/es/log/scores.csv $HOME/"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d06adb970>)])]>

ローカルで ES を実行する

トレーニングとテストの両方をローカルで実行してデバッグに利用できます。train_local.sh と test.py に適切なオプションを追加して使います。

code_block: <ListValue: [StructValue([('code', '# Train locally.\r\n# E.g. bash ./train_local.sh -c configs/BipedalWalkerHardcore.gin -n 10\r\nbash ./train_local.sh -c {path-to-config-file} -n {number-of-workers}\r\n\r\n# Test locally.\r\n# E.g. python test.py --checkpoint=1000 --logdir=./log\r\npython test.py --checkpoint={checkpoint} --logdir={path-to-log-directory}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1d06adbdf0>)])]>

実験結果

では、GKE で ES を実行するメリットを 2 つの例を通じて確認しましょう。1 つは OpenAI の BipedalWalkerHardcore 環境で CMA を使ってトレーニングした 2D ウォーカー、もう 1 つは Google Brain の MinitaurLocomotion 環境の四足歩行ロボットです。ここでは、テスト試行で 100 回連続して TargetReward よりも大きな平均報酬を実現できれば、エージェントがタスクを解決したと見なします。RL で試せばわかりますが、どちらのタスクも難易度はかなり高いです。

次の表は、実験環境の設定についてまとめたものです。比較のため、スタンドアロンの 64 コア Google Compute Engine インスタンスでも実験を行いました。この Compute Engine インスタンスのワーカーの数は、CPU 使用率が 90% を超えるように調整します。

今回の実装では、両方のタスクをクリアできました。結果を下に示します。

厳密にはタスクの内容に依存しますが、GKE で ES を実行すると速度を大幅に向上できる可能性があります。今回の例では、BipedalWalkerHardcore の学習は 5 倍、四足歩行ロボットの学習は 10 倍以上高速です。ML 研究においてこの高速化はより多くのアイデアを試すチャンスとなり、ML アルゴリズム開発のイテレーションの向上にもつながります。

まとめ

ES は、勾配ベースのアルゴリズムでよい結果が得られない ML タスクに対して強力なソリューションとなります。ES には並列処理との親和性が高い性質があるので、Kubernetes で ES を実行することで大幅な高速化を実現できます。これにより、ML リサーチャやエンジニアが新しいアイデアを試すイテレーションのスピードが上がります。

簡単にスケールできるという ES の力をもっとも活かせる応用は、難しい問題を解くためのシミュレーション環境をローコストに用意できるケースです。最近の研究（1、2）では、コントローラを実環境にデプロイする前に、まずシミュレーションで仮想ロボットコントローラをトレーニングする方法が効果的であることが実証されています。また、手作業のプログラミングではなく、収集した観測結果から学習で得られたディープラーニングモデルでもシミュレーション環境を実現できます（1、2、3）。こうした応用であれば、ES のスケーリングを活かした数 1000 ノード規模の並列シミュレーション環境での学習が可能でしょう。

進化の手法を用いると最適化する対象の選択肢がぐんと広がるため、従来の RL ポリシー最適化では対応できなかったさまざまな応用が可能です。たとえば、この最新の研究では RL 環境で ES を使い、ポリシーのトレーニングだけでなくより優れたロボットの設計まで学習しています。進化の手法を使うジェネラティブデザインの領域では、ずっと多くのクリエイティブな応用が生まれるはずです。また、この最新の研究成果では、複数の RL タスクを実行できる最小のニューラルネットワークアーキテクチャが、進化型アルゴリズムを使うことでパラメータのトレーニングなしで得られることを実証しています。この結果は多くの ML リサーチャを驚かせ、進化の手法が切り拓くまったく新しい研究分野の存在を示しています。

ディープラーニングの革命は、大規模なディープニューラルネットワークのトレーニングを実現する GPU が触媒となり生じました。同様に、ローコストな CPU で構成された大規模クラスタへ簡単にスケールできる進化の手法は、これからのコンピューティング革命をリードするカギとなるでしょう。

GKE や Kubernetes によるディープラーニングの詳細については以下をご覧ください。

ソリューション

Earth Engine からの衛星画像を BigQuery の表形式データに変換

Geobeam を使用して Earth Engine のデータを BigQuery に移動

地理空間データの処理

チュートリアル

データセットの可視化

Earth Engine からのデータのエクスポート

Geobeam を使用した BigQuery へのデータの取り込み

BigQuery でのテーブルの表示

データの分析

BigQuery の監査ログ パイプラインを活用した使用状況分析

BigQuery 監査ログの概要

ペルソナとユースケース

BigQuery 監査ログのエクスポート オプション

パイプラインの設定

集約シンクの使用

Logging サービス アカウント

エクスポート オプション

BigQuery へのエクスポート

設定手順

Google Cloud Storage へのエクスポート

設定手順

Pub/Sub 経由のエクスポート

Cloud Monitoring

パイプラインの自動化

次のステップ

INFORMATION_SCHEMA による BigQuery の予約とスロット使用率のモニタリング

アーキテクチャ フレームワークの原則に沿ったシステム設計の最適化

システム設計とは？

システム設計の基本原則

すべてを文書化する

設計を簡素化する（フルマネージド サービスを利用する）

アーキテクチャを分離する

ステートレス性を活用する

他の柱に適用されるシステム設計の原則

Google Cloud コミュニティの一部となったアーキテクチャ フレームワーク

システム設計 2.0 の変更点

アーキテクチャ フレームワークの最新ベスト プラクティスで Google Cloud のワークロードを強化

GitHub Actions からのキーなしの認証の有効化

新しい GitHub Action – auth

GitHub Actions の ID 連携の設定

「見えないセキュリティ」に向けて

キーなしの API 認証 - サービス アカウント キーを必要としない Workload Identity 連携によるクラウド セキュリティの向上

Google Cloud で予測市場を作成する

予測市場を構造化する方法

使ってみる

Google Cloud Platform を使用して再入院率を予測する

FHIR を基盤とした医療システムの相互運用性を Google Cloud で向上

自社データを活用してワークフローの最適化に取り組むマーケターが、Looker をどのように役立てているか

誰もアクセスできないデータは宝の持ち腐れ

顧客を理解する

影響に関する分析情報

自社データのアクセス、分析、有用化

地理空間の分析情報をビジネス目標達成に役立てる方法

アーキテクチャ フレームワークの最新ベスト プラクティスで Google Cloud のワークロードを強化

フレームワークを利用する理由

次のステップ

Google Kubernetes Engine で進化戦略を実行する方法

進化戦略入門

Kubernetes 入門

GKE による ES の実装

実装

GKE で ES を実行する

ローカルで ES を実行する

実験結果

まとめ

BigQuery の監査ログパイプラインを活用した使用状況分析

BigQuery 監査ログのエクスポートオプション

Logging サービスアカウント

エクスポートオプション

アーキテクチャフレームワークの原則に沿ったシステム設計の最適化

設計を簡素化する（フルマネージドサービスを利用する）

Google Cloud コミュニティの一部となったアーキテクチャフレームワーク

アーキテクチャフレームワークの最新ベストプラクティスで Google Cloud のワークロードを強化

キーなしの API 認証 - サービスアカウントキーを必要としない Workload Identity 連携によるクラウドセキュリティの向上

アーキテクチャフレームワークの最新ベストプラクティスで Google Cloud のワークロードを強化