Bokeh と BigQuery によるカスタム インタラクティブ ダッシュボードの作成

このチュートリアルでは、Bokeh ライブラリを使用し、BigQuery の一般公開データセットのデータを可視化しながら、Google Cloud でカスタム インタラクティブ ダッシュボード アプリを構築する手順を説明していきます。また、セキュリティとスケーラビリティの両方を考慮してこのアプリをデプロイする方法についても説明します。

Google データポータルのような強力な Software-as-a-Service（SaaS）ソリューションを使うと、インタラクティブなデータ可視化ダッシュボードをとても容易に構築できます。ただし、このようなタイプのソリューションでは十分なカスタマイズ オプションが提供されていない場合があります。そのような場合、D3.js、Chart.js、Bokeh などのオープンソース ライブラリを使用してカスタム ダッシュボードを作成できます。これらのライブラリを使えば、カスタマイズ化された機能や可視化機能を備えたダッシュボードを柔軟に構築できます。ただし、これらのダッシュボードをインターネットにデプロイして関係者が容易にアクセスできるようにするという大きな課題が残されています。

目標

• Bokeh を使用して構築したカスタムアプリから BigQuery に接続する方法を学ぶ。
• Memcached を使用した並列クエリやアプリレベルでのキャッシングなどの最適化手法を実装する。
• Kubernetes を使用して Google Kubernetes Engine（GKE） にダッシュボード デモをデプロイする。
• HTTPS ロードバランサを作成する。
• 静的アセットを提供するための CDN 対応バックエンドをデプロイする。
• Identity-Aware Proxy 認証と SSL 暗号化を使用してアプリを保護する。

費用

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

• BigQuery
• Compute Engine
• Cloud Storage
• Cloud CDN
• ロードバランサ
• 静的 IP アドレス

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただけます。

始める前に

1. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   [プロジェクトの選択] ページに移動

2. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する。

3. GKE and BigQuery API を有効にします。

   API を有効にする

4. Cloud Shell インスタンスを起動します。このチュートリアルでは最後まで Cloud Shell を使用します。

   Cloud Shell を開く

5. Cloud Shell で次のコマンドを実行して、Git リポジトリからクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/bigquery-bokeh-dashboard

6. Cloud Shell で、デフォルトの Compute Engine ゾーンを、GKE クラスタを作成するゾーンに設定します。このチュートリアルでは、us-central1-a ゾーンを使用します。

   gcloud config set compute/zone us-central1-a

7. デモアプリが BigQuery にアクセスできるようにするには、次のコマンドを実行してサービス アカウント キーを作成します。

   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   export SERVICE_ACCOUNT_NAME="dashboard-demo"
   cd bigquery-bokeh-dashboard
   gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \
       --display-name="Bokeh/BigQuery Dashboard Demo"
   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
       --role roles/bigquery.user
   gcloud iam service-accounts keys create --iam-account \
       "${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
       service-account-key.json
         

   サービス アカウントの詳細については、サービス アカウントをご覧ください。

デモアプリを理解する

デモアプリは、米国の 50 州すべてについて、公開されているデータを処理して可視化するダッシュボードを表示します。ダッシュボードには、簡単な操作が備わっています。ユーザーはプルダウン ウィジェットから 50 州のいずれかを選択して、その州に関する情報をドリルダウンして表示できます。ダッシュボードには 4 つのモジュールがあり、各モジュールにはさまざまな種類の情報が表示されます。

• 折れ線グラフに、過去数十年にわたるさまざまな大気汚染物質のレベルの推移が示されます。データは EPA Historical Air Quality Dataset から取得したものです。
• 棒グラフに、2016 年の降水量が示されます。データは、NOAA Global Historical Climatology Network Weather Dataset から取得したものです。
• 折れ線グラフに、2016 年の気温と平均気温が示されます。データは NOAA Global Surface Summary of the Day Weather Dataset から取得したものです。
• 表には、上位 100 位までの人口の多い郵便番号がリストされます。データは United States Census Bureau Dataset から取得したものです。

実行中のデモのスクリーンショットを次に示します。

全体的なアーキテクチャ

デモのアーキテクチャは 主に 6 つ要素で構成されています。次の図は、これらのコンポーネント間の相互作用を示しています。

これらの要素には、次のようなものがあります。

• ダッシュボード ユーザーのデスクトップ マシンとモバイル デバイス上のクライアント ウェブブラウザ。
• IAP によって管理される認証プロキシ。アプリへのアクセスを制御します。
• HTTPS ロードバランサ。着信したウェブ トラフィックを該当するバックエンドに効率的に配布し、システムに入出力するデータの SSL 復号 / 暗号化を処理します。
• アプリ バックエンド。ダッシュボードの動的コンテンツ（HTML およびプロットデータ）を提供します。このアプリ バックエンドでは、GitHub で利用可能な Dockerfile でビルドされた Docker イメージを使用します。独自のイメージを作成することもできますが、このチュートリアルでは説明しません。
• 静的アセット バックエンド。クライアント ウェブブラウザ レンダリングに必要な静的 JavaScript ファイルと CSS ファイルを提供します。

注: このデモで使用される GKE クラスタノード、Bokeh / Memcached ポッド、Bokeh 作業サブプロセスの数は任意です。各数値が 1 より大きい理由は、アーキテクチャの水平スケーラビリティを強調するためです。現実のシナリオでは、これらの数値をアプリのニーズと予算の制約に合わせて調整できます。

アプリ バックエンド

アプリ バックエンドは、ロードバランサからの着信リクエストを受け取り、BigQuery から該当するデータを取り出して変換します。バックエンドはリクエストされた動的コンテンツを HTTP を介して HTML 形式て返し、WebSocket 経由でプロットデータを返します。

次の図にアーキテクチャを示します。

アプリ バックエンドには、2 つの主要なサブコンポーネントが含まれています。

• Bokeh サービス。アプリの中心的存在であるこのサービスには、Bokeh サーバーを実行するポッドが含まれており、BigQuery のデータをクエリし、クライアント ウェブブラウザに表示される動的コンテンツを生成します。
• Memcached サービス。頻繁に要求されるデータをキャッシュする Memcached サーバーを実行するポッドが含まれています。

これらのサブコンポーネントは Docker コンテナに存在し、Kubernetes Engine に Kubernetes Pod としてデプロイされることで、水平スケーラビリティが実現されます。

Bokeh サービス

このデモでは、Bokeh サービスに 2 つの Bokeh ポッドを組み込みます。各ポッドは別の Bokeh サーバー インスタンスを実行します。これは、Tornado の非ブロッキング ウェブサーバーのラッパーです。このサーバーは、HTML コンテンツの情報を HTTP 経由で同期的に提供し、ダッシュボードのプロットデータの情報を WebSocket を介して非同期的に提供できます。

このチュートリアルでは、各 Bokeh サーバーが 4 つの異なる作業サブプロセスにフォークするように構成されています。これは、コンテナ Dockerfile の CMD ステートメントの --num-procs パラメータによって示されます。

dashboard/Dockerfile

GitHub で表示

CMD bokeh serve --disable-index-redirect --num-procs=4 --port=5006 --address=0.0.0.0 --allow-websocket-origin=$DASHBOARD_DEMO_DOMAIN dashboard.py

Bokeh サーバーはサブプロセス間の着信トラフィックを自動的に負荷分散します。この方法により、各 Pod のパフォーマンスと復元力が向上します。このチュートリアルで使用されるサブプロセスの数は任意です。現実のシナリオでは、実際の本番環境トラフィックと、クラスタで使用可能なメモリと CPU リソースに基づいてこの数を調整します。

BigQuery には、read_gbq メソッドを使用して Bokeh アプリから直接アクセスします。詳細については、Pandas ライブラリの gbq 拡張機能で提供される read_gbq メソッドに関するドキュメントをご覧ください。このメソッドは非常にシンプルなインターフェースを持っています。クエリをパラメータとして受け取り、ネットワーク経由で BigQuery に送信します。その他の必須パラメータには、プロジェクト ID とサービス アカウント キーがあり、どちらも GKE Secret から読み込まれた環境変数を介して受け渡しできます。その後、read_gbq メソッドが BigQuery から返された結果のページネーションを透過的に処理し、それらを単一の Pandas DataFrame オブジェクトに統合して、Bokeh が直接処理できるようにします。

例として、read_gbq を使用して送信されるクエリの例を示します。これは、カリフォルニア州（州コード「CA」）の上位 100 位までの人口が多い郵便番号を収集します。

query = """
    SELECT
      A.zipcode,
      Population,
      City,
      State_code
    FROM
      `bigquery-public-data.census_bureau_usa.population_by_zip_2010` AS A
    JOIN
      `bigquery-public-data.utility_us.zipcode_area` AS B
    ON
     A.zipcode = B.zipcode
    WHERE
     gender = ''
    AND
     state_code = '%(state)s'
    ORDER BY
     population DESC
    LIMIT
     100
"""

import os
import pandas
dataframe = pandas.io.gbq.read_gbq(
   query % 'CA',
   project_id=os.environ['GOOGLE_PROJECT_ID'],
   private_key=os.environ['GOOGLE_APPLICATION_CREDENTIALS'],
   dialect='standard'
)

結果データはネットワーク経由で転送される必要があるため、できるだけ多くの事前処理を BigQuery にオフロードすることを強くおすすめします。たとえば、クエリレベルで必要なダウン サンプリング（LIMIT 句、ターゲットにする SELECT 句のフィールド、表の事前分割、または GROUP BY 句を使用した結果の事前グループ化による）を行うことにより、全体的なネットワーク トラフィックを削減し、レスポンス時間を短縮します。

デモ ダッシュボードには 4 つの異なるプロット モジュールが表示されることを思い出してください。ユーザーが米国の州を選択すると、アプリは BigQuery に 4 つの個別のクエリ（モジュールごとに 1 つずつ）を送信し、合計 7 ギガバイトのデータを処理します。これらの各 BigQuery クエリの実行には、平均して 1〜3 秒かかります。この処理の経過中、アプリはアイドル状態のままで、BigQuery から結果が返されるのを待っています。ダッシュボードの全体的なレスポンス時間を改善するため、これらの 4 つのクエリは、次のコードに示すように、別個のスレッドで並列に実行されます。

dashboard/dashboard.py

GitHub で表示

def fetch_data(state):
    """
    Fetch data from BigQuery for the given US state by running
    the queries for all dashboard modules in parallel.
    """
    t0 = time.time()
    # Collect fetch methods for all dashboard modules
    fetch_methods = {module.id: getattr(module, 'fetch_data') for module in modules}
    # Create a thread pool: one separate thread for each dashboard module
    with concurrent.futures.ThreadPoolExecutor(max_workers=len(fetch_methods)) as executor:
        # Prepare the thread tasks
        tasks = {}
        for key, fetch_method in fetch_methods.items():
            task = executor.submit(fetch_method, state)
            tasks[task] = key
        # Run the tasks and collect results as they arrive
        results = {}
        for task in concurrent.futures.as_completed(tasks):
            key = tasks[task]
            results[key] = task.result()
    # Return results once all tasks have been completed
    t1 = time.time()
    timer.text = '(Execution time: %s seconds)' % round(t1 - t0, 4)
    return results

BigQuery からすべての結果を受け取ったら、Bokeh のグラフ ライブラリがデータをプロットします。たとえば、次のコードは、大気汚染物質レベルの経時的推移をプロットします。

dashboard/modules/air.py

GitHub で表示

def make_plot(self, dataframe):
    self.source = ColumnDataSource(data=dataframe)
    palette = all_palettes['Set2'][6]
    hover_tool = HoverTool(tooltips=[
        ("Value", "$y"),
        ("Year", "@year"),
    ])
    self.plot = figure(
        plot_width=600, plot_height=300, tools=[hover_tool],
        toolbar_location=None)
    columns = {
        'pm10': 'PM10 Mass (µg/m³)',
        'pm25_frm': 'PM2.5 FRM (µg/m³)',
        'pm25_nonfrm': 'PM2.5 non FRM (µg/m³)',
        'lead': 'Lead (¹/₁₀₀ µg/m³)',
    }
    for i, (code, label) in enumerate(columns.items()):
        self.plot.line(
            x='year', y=code, source=self.source, line_width=3,
            line_alpha=0.6, line_color=palette[i], legend=label)

    self.title = Paragraph(text=TITLE)
    return column(self.title, self.plot)

Bokeh サービスのデプロイ

アプリの水平スケーラビリティを促進するために、アプリ バックエンドのすべてのコンポーネントは、GKE を使用して Docker コンテナによりデプロイされます。これらのコンポーネントを GKE にデプロイする手順は次のとおりです。

1. まず、Cloud Shell で次のコマンドを実行して、例として 2 つのノードを持つ GKE クラスタを作成します。

   gcloud container clusters create dashboard-demo-cluster \
     --tags dashboard-demo-node \
     --num-nodes=2
   

2. 以前に作成したプロジェクト ID とサービス アカウントキーを安全に保存するために GKE Secret を作成します。

   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   
   kubectl create secret generic project-id \
     --from-literal project-id=$PROJECT_ID
   
   kubectl create secret generic service-account-key \
     --from-file service-account-key=service-account-key.json
   

3. 静的 IP アドレスを作成します。

   gcloud compute addresses create dashboard-demo-static-ip --global
   

4. xip.io を使用してドメインを定義します。xip.io は、無料の DNS サービスで、IP アドレスを含むドメインをその同じ IP アドレスに自動的に解決します。

   export STATIC_IP=$(gcloud compute addresses describe \
     dashboard-demo-static-ip --global --format="value(address)")
   
   export DOMAIN="${STATIC_IP}.xip.io"
   
   echo "My domain: ${DOMAIN}"
   

5. このドメインで GKE Secret を作成します。

   kubectl create secret generic domain --from-literal domain=$DOMAIN
   

6. これで、Bokeh サービスを次のコマンドでデプロイできるようになりました。

   kubectl create -f kubernetes/bokeh.yaml
   

最後のステップでは、任意の数のポッドをデプロイします。この例では 2 つで、それぞれがデモアプリの別個のインスタンスを実行します。また、以前に env.valueFrom.secretKeyRef エントリにより作成した 3 つの GKE Secret を環境変数として公開し、アプリがこの情報を取得して BigQuery にアクセスできるようにします。

詳細は、bokeh.yaml をご覧ください。

Memcached サービス

ダッシュボードに表示されるデータが一定期間変化しないと想定される場合は、パフォーマンスとコストの改善を検討することが重要です。この目的のため、デフォルトで、BigQuery は重複するクエリの結果を 24 時間内部的にキャッシュします。これにより、レスポンス時間が大幅に短縮され、不要な費用を節約できます。このキャッシュ メカニズムの詳細については、Memcached サービスに関するドキュメントをご覧ください。

このキャッシュ メカニズムは、頻繁に使用するデータをダッシュボード アプリのメモリ内にローカルにキャッシュすることによってさらに改善できます。この方法を利用すると、BigQuery で繰り返し同じ処理が行われなくなり、キャッシュされたデータを収集するために不必要にネットワーク トラフィックを使用することがなくなります。このチュートリアルでは、このタイプのアプリレベルでのキャッシュ処理に Memcached を使用します。Memcached は非常に高速で、このチュートリアルの例ではレスポンス時間を数秒から数ミリ秒に短縮します。

Memcached の特徴として、負荷分散メカニズムが組み込まれていないことがあります。代わりに、複数の Memcached Pod 間の負荷分散は、次の図に示すように、各 Bokeh Pod に含まれる Memcached クライアントによって実行される必要があります。

Memcached クライアントが Memcached Pod を検出できるようにするには、Memcached サービスをヘッドレスとして宣言する必要があります。これを行うには、GKE 構成ファイルの clusterIP: None エントリを使用できます（memcached.yaml をご覧ください）。このようにすることで、Memcached クライアントは、kube-dns に対して memcached.default.svc.cluster.local ドメイン名をクエリして、個々の Pod の IP アドレスを取得できます。

Memcached サービスのデプロイ

Bokeh サービスと同様に、Memcached サービスは Kubernetes を使用して Docker コンテナにより GKE にデプロイされます。

次のコマンドを実行して、Memcached Pod とヘッドレス サービスをデプロイします。

kubectl create -f kubernetes/memcached.yaml

ロードバランサの追加

この時点で、ダッシュボード アプリはプライベート サービス内で実行されています。ユーザーがダッシュボードにアクセスできるようにするために、HTTPS ロードバランサを導入してアプリをインターネットに公開する必要があります。これは次の手順で行います。

1. SSL 証明書を作成する。
2. ロードバランサを作成する。
3. 接続タイムアウトを延長する。

SSL 証明書を作成する

現実のシナリオでは、ダッシュボードに表示されるデータは機密または限定公開の場合があります。インターネットを介してこのデータをユーザーに送信する前に、SSL を使用して暗号化する必要があります。最初の手順は SSL 証明書を作成することです。

本番環境の設定の場合、公式認証局に証明書を発行してもらう必要があります。このチュートリアルでは、以下のコマンドを実行して自己署名証明書を発行できます。

export STATIC_IP=$(gcloud compute addresses describe \
  dashboard-demo-static-ip --global --format="value(address)")

export DOMAIN="${STATIC_IP}.xip.io"

mkdir /tmp/dashboard-demo-ssl

cd /tmp/dashboard-demo-ssl

openssl genrsa -out ssl.key 2048

openssl req -new -key ssl.key -out ssl.csr -subj "/CN=${DOMAIN}"

openssl x509 -req -days 365 -in ssl.csr -signkey ssl.key -out ssl.crt

cd -

HTTPS ロードバランサを作成する

HTTPS ロードバランサは、複数のリソースで構成されています。

• グローバル転送ルール
• ヘルスチェック
• バックエンド サービス
• URL マップ
• ターゲット プロキシ

GitHub ソース リポジトリに同時に含まれるこれらすべてのリソースは、次のように作成します。

./create-lb.sh

このコマンドで返された URL にアクセスして、ダッシュボードが有効であることを確認します。

echo https://${STATIC_IP}.xip.io/dashboard

ブラウザがコード 502 でエラーを返す場合、ロードバランサはまだデプロイ中です。デプロイが完了するまで、数分かかることがあります。数秒待ってから、ページを更新表示してください。ページが機能し、ダッシュボードが表示されるまで、この操作を試してください。

注: 自己署名証明書を使用しているため、ブラウザに警告が表示されます。この警告は無視して、ページの読み込みに進むことができます。

この時点で、HTTPS ロードバランサが暗号化を終端します。システムで送受信されるトラフィックには HTTPS と Secure WebSocket が使用されますが、システム内のトラフィックには通常の HTTP と WebSocket が使用され、暗号化されません。ほとんどのシナリオでは、このレベルの暗号化で十分です。より強固なセキュリティが必要な場合は、Google Cloud プロジェクトの Virtual Private Cloud ネットワークによる SSL 暗号化の適用を検討してください。VPC ネットワークでの SSL 暗号化の設定は、このチュートリアルの対象外です。

接続タイムアウトを延長する

デフォルトでは、HTTPS ロードバランサは 30 秒を超えて開いているすべての接続を閉じます。

ダッシュボードの WebSocket 接続を長時間開いたままにできるようにするには、接続タイムアウトを長くする必要があります。次の gcloud コマンドは、タイムアウトを 1 日（86,400 秒）に設定します。

gcloud compute backend-services update dashboard-demo-service \
    --global --timeout=86400

静的アセット バックエンド

Bokeh ポッドは、ダッシュボードのレンダリングに必要なすべての静的な JavaScript ファイルと CSS ファイルを直接提供できます。しかし、これらのポッドにこのタスクを処理させるには、次のようないくつかの欠点があります。

• Bokeh ポッドに不必要な負荷がかかり、動的プロットデータなど、他のタイプのリソースを提供する能力が低下する可能性がある。
• クライアントの地理的な位置にかかわらず、同じ配信元サーバーからアセットをダウンロードする必要がある。

これらの欠点を軽減するには、静的アセットを効率的に提供するための専用バックエンドを別途作成します。

この静的アセット バックエンドは、次の 2 つの主要コンポーネントを使用します。

• Cloud Storage でホストされるバケット。ソースの JavaScript と CSS アセットを保持します。
• Cloud CDN。これらのアセットを潜在的なダッシュボード ユーザーの近くにグローバルに配布することにより、レイテンシを短縮し、ページの読み込みを高速化します。

次の図にアーキテクチャを示します。

静的アセット バックエンドの作成

1. 次のコマンドを実行して、静的アセットを Bokeh コンテナから抽出し、一時ディレクトリにローカルに保存します。

   gcloud auth configure-docker --quiet
   
   export DOCKER_IMAGE="gcr.io/cloud-solutions-images/dashboard-demo"
   
   export STATIC_PATH=$(docker run $DOCKER_IMAGE bokeh info --static)
   
   export TMP_PATH="/tmp/dashboard-demo-static"
   
   mkdir $TMP_PATH
   
   docker run $DOCKER_IMAGE tar Ccf $(dirname $STATIC_PATH) - \
       static | tar Cxf $TMP_PATH -
   

2. Cloud SDK に含まれている gsutil コマンドを使用して、バケットを作成し、そのバケットにすべてのアセットをアップロードします。

   export BUCKET="${PROJECT_ID}-dashboard-demo"
   
   # Create the bucket
   gsutil mb gs://$BUCKET
   
   # Upload the assets to the bucket
   gsutil -m cp -z js,css -a public-read -r $TMP_PATH/static gs://$BUCKET
   

   -z オプションは js および css ファイル拡張子を持つファイルに gzip エンコードを適用します。これにより、Cloud Storage のネットワーク帯域幅とスペースが節約され、ストレージ コストが削減され、ページの読み込み速度が向上します。-a オプションは public-read 権限を設定し、アップロードしたアセットにすべてのクライアントがパブリックにアクセスできるようにします。

3. --enable-cdn オプションを使用して Cloud CDN サポートを含むバックエンド バケットを作成します。

   gcloud compute backend-buckets create dashboard-demo-backend-bucket \
       --gcs-bucket-name=$BUCKET --enable-cdn
   

4. /static/* ディレクトリ内のアセットをリクエストするすべてのトラフィックについて、バックエンド バケットを HTTPS ロードバランサに接続します。

   gcloud compute url-maps add-path-matcher dashboard-demo-urlmap \
       --default-service dashboard-demo-service \
       --path-matcher-name bucket-matcher \
       --backend-bucket-path-rules="/static/*=dashboard-demo-backend-bucket"
   

5. この構成変更は、伝搬に数分かかることがあります。しばらく待ってから、静的アセットのレスポンス ヘッダーに x-goog-* パラメータが含まれていることをチェックすることにより、Cloud CDN が機能していることを確認します。

   curl -Iks https://${DOMAIN}/static/js/bokeh.min.js | grep x-goog
   

認証

以前はロードバランサ レベルで有効になっていた SSL 暗号化によってトランスポートが保護されていましたが、アプリへのアクセスを制御し、潜在的な不正行為を防止するために認証レイヤを追加することをおすすめします。1 つの選択肢は、IAP を有効にすることです。

最初のステップとして、[OAuth] 同意画面を設定します。

1. [OAuth] 同意画面を設定します。

   同意画面を構成

   1. [User Type] で [外部] を選択し、[作成] をクリックします。
   2. [アプリ名] に「Dashboard demo」と入力します。
   3. [サポートメール] で、一般公開される連絡先として表示するメールアドレスを選択します。これは、自分のメールアドレスまたは自分が所有する Google グループである必要があります。
   4. [保存] をクリックします。
   警告: OAuth 同意画面に保存された情報は、URL にアクセスするすべてのユーザーに表示される可能性があります。メールとサービスの詳細は、ログイン画面だけでなく、ユーザーが権限のないリソースにアクセスしようとしたときにも表示されます。OAuth 同意画面に機密情報を入力しないでください。

2. [認証情報] で、[認証情報を作成] > [OAuth クライアント ID] をクリックします。

3. [アプリケーションの種類] で [ウェブアプリケーション] を選択し、[名前] の値として「Dashboard demo」を入力します。

4. 詳細の入力が完了したら、[作成] をクリックし、OAuth クライアント ウィンドウに表示された [クライアント ID] と [クライアント シークレット] を書き留めます。

5. [Dashboard demo] 認証情報をクリックします。

6. [承認済みのリダイレクト URI] に、次の形式でエントリを追加します（[CLIENT_ID] は、前の手順でメモしたクライアント IP の値で置き換えます）。

   https://iap.googleapis.com/v1/oauth/clientIds/[CLIENT_ID]:handleRedirect
   

7. Cloud Shell で次のコマンドを実行して、IAP を有効にします。[CLIENT_ID] と [CLIENT_SECRET] の値は、前の手順でメモした値に置き換えます。

   gcloud beta compute backend-services update dashboard-demo-service --global \
       --iap=enabled,oauth2-client-id=[CLIENT_ID],oauth2-client-secret=[CLIENT_SECRET]
   

8. 最後に、アプリへのアクセスが許可されるメンバーを追加します。[EMAIL] 値は Google アカウントのメールアドレスに置き換えます。

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --role roles/iap.httpsResourceAccessor \
       --member user:[EMAIL]
   

この構成変更は、伝搬に数分かかることがあります。完了すると、アプリは IAP によって保護され、上記で指定したメールアドレスを持つユーザーのみがアクセスできるようになります。上記の最後の手順と同じプロセスを使用して、さらにユーザーを追加できます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除する手順は次のとおりです。

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のチュートリアルとクイックスタートを検討する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て制限を超えないようにできます。

1. Cloud Console で [リソースの管理] ページに移動します。

   [リソースの管理] に移動

2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

リソースを個別に削除する

プロジェクト全体ではなく個々のリソースを削除するには、次のコマンドを実行します。

export PROJECT_ID=$(gcloud info --format='value(config.project)')

# Delete the load balancer resources
gcloud compute forwarding-rules \
    delete dashboard-demo-gfr --global --quiet
gcloud compute target-https-proxies \
    delete dashboard-demo-https-proxy --quiet
gcloud compute ssl-certificates \
    delete dashboard-demo-ssl-cert --quiet
gcloud compute url-maps \
    delete dashboard-demo-urlmap --quiet
gcloud compute backend-services \
    delete dashboard-demo-service --global --quiet
gcloud compute health-checks delete \
    dashboard-demo-basic-check --quiet
gcloud compute firewall-rules delete \
    gke-dashboard-demo-lb7-fw --quiet

# Delete the Kubernetes Engine cluster
gcloud container clusters delete dashboard-demo-cluster --quiet

# Delete the service account
export SERVICE_ACCOUNT_NAME="dashboard-demo"
gcloud iam service-accounts delete \
    "${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" --quiet

# Delete the backend bucket
gcloud compute backend-buckets delete dashboard-demo-backend-bucket --quiet

# Delete the Cloud Storage bucket
export BUCKET="${PROJECT_ID}-dashboard-demo"
gsutil -m rm -r gs://$BUCKET

# Delete the static IP address
gcloud compute addresses delete dashboard-demo-static-ip --global --quiet

# Delete the local Docker image
docker rmi -f gcr.io/cloud-solutions-images/dashboard-demo

最後に、Oauth クライアント ID を削除します。

1. [認証情報] ページを開きます。

   認証情報を表示

2. [Dashboard demo] エントリをクリックします。

3. [削除] をクリックし、確認のためもう一度 [削除] をクリックします。

次のステップ

• 独自のデータを処理して BigQuery にアップロードする場合は次をご覧ください。

  • Google Cloud でクラウドネイティブ データ ウェアハウスのための ETL アーキテクチャを設計する
  • リレーショナル データベースから BigQuery に ETL を実行する
  • データ ライフサイクル

• リアルタイム ダッシュボードの実装に関する情報が必要な場合は、Bokeh の stream メソッドと BigQuery へのデータのストリーミングに関するドキュメントをご覧ください。

• Google Cloud のその他の機能を試す。チュートリアルをご覧ください。