2TB 容量の Windows ファイルサーバー環境を Google Cloud で構築する例です。

バックアップには Persistent Disk スナップショットを活用しており、複数世代のバックアップを保持する目的で 3TB の容量を想定しています。

ユーザーは社内ネットワークから VPN 経由でファイルサーバにアクセスすることを想定しています。Google Cloud から社内ネットワークへの転送量料金は一ヶ月に格納されたデータの 10% ほどが転送されるとして試算しています。

ユーザー認証を提供する Active Directory については、オンプレミス上にある既存の Active Directory を利用するか、Google Cloud でマネージド Microsoft AD を利用するか等の複数の選択肢が考えられるために本構成例には含まれていません。

本料金試算の詳細はこちらのリンクからご確認いただけます。手順と必要なリソースはこちらから入手可能です。

オンプレミス環境や Google 以外のサービスから取得したデータを Google Cloud / Google Workspace で分析する例です。

1 日 1 回の頻度でオンプレミスと外部 SaaS サービスから Google Cloud Storage を経由して BigQuery に分析対象データが送られるものとし、そのデータ容量は毎月合計 10 GiB、過去 5 年分のデータを保存することを想定しています。

ユーザーは BigQuery に保存されたデータを スプレッドシートや Data Portal を利用しレポートを作成することで情報の可視化をします。BigQuery にて毎月実行される分析クエリは毎月 500 GiB を想定します。

BigQuery にデータを保存することで Google が提供する AI/ML サービスや広告サービスとの連携も簡単に可能になります。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。

需要に合わせて VM インスタンスを増減させることができる、一般的な 3 層ウェブアプリケーション構成の例です。

VM の自動スケーリングには、Compute Engine のマネージド インスタンス グループ (MIG) を作成した上で、ロードバランサを使用してトラフィックを受けるためにグローバル静的外部 IP アドレス を利用します。

また Cloud CDN や Memorystore といったキャッシュの活用や、オブジェクトストレージである Cloud Storage にて静的ファイルを扱うことで、ウェブサーバーへの負荷の軽減を図ります。

 今回は、Compute Engine にて一般的なe2-standard-2 (vCPU2, Memory 8GB)、平均して 3 台のインスタンスが稼働すると仮定して試算しています。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。

需要に合わせて Cloud Run インスタンスを増減させることができる、3 層ウェブアプリケーション構成の例です。

Cloud Run の 自動スケーリングは、コールドスタートの遅れを解消するため、最小インスタンス数を1とし、ロードバランサを使用してトラフィックを受けるためにグローバル静的外部 IP アドレス を利用します。

また Cloud CDN や Memorystore といったキャッシュの活用や、オブジェクトストレージである Cloud Storage にて静的ファイルを扱うことで、ウェブサーバーへの負荷の軽減を図ります。

さらに Cloud Armor を活用することで、アプリケーションレイヤーでの攻撃からの防御も追加することができます。

 今回は、Cloud Run インスタンスを 2 vCPU,  Memory 512MB とし、1 インスタンス当たり、50 リクエストを同時処理すると仮定して試算しています。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。

Document AI API は、文書やメールなどの非構造化データを取り込み、データの理解、分析、消費を容易にする文書理解ソリューションです。

この例は、Cloud Storage にアップロードされたドキュメントを自動的に処理するドキュメント処理パイプラインのシンプルなアーキテクチャです。このパイプラインは、Cloud Storage にアップロードされた新しいファイルをDocument AI フォームプロセッサーで処理し、それらのファイルから検出されたフォームデータを BigQuery に保存するプライマリ Cloud Function で構成されています。

この例では、住所情報を含むラベル付きフィールドのような基本的なフォームデータを検出する一般的なフォームプロセッサを使用するパイプラインです。

一般的なパーサー以外にも、Document AI プロセッサには、読み込む文書がラベル付きフィールドを含まない場合に、特定な情報を読み取ることができるパーサーもあります。例えば、Document AI Invoice パーサーは、請求書のレイアウトを理解しているため、ラベルのない請求書文書から詳細な住所やサプライヤー情報を読み取ることができます。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。
※ Document AI はリンク先の試算には含まれていません。

e コマースサイトではレスポンスタイムの最小化や、アクセス数急増への対応が課題です。

HTML、JavaScript、CSS、画像などの静的なコンテンツは Cloud Storage に格納し、動的なコンテンツは Compute Engine などのコンピューティング サービスにリクエストが渡るようにします。

動的コンテンツをホスティングする Compute Engine は、マネージド インスタンス グループ (MIG) として、平均２つのインスタンスで処理するものと試算しています。

Cloud Load Balancing では設定の有効化だけで簡単に Cloud CDN による静的コンテンツのキャッシングが利用できます。さらに Cloud Load Balancing が持つパスルーティングの機能を使い、パスによって静的コンテンツのオリジンを返すか、動的コンテンツのオリジンを返すかを振り分けます。これにより、動的コンテンツを生成するコンピューティングリソースへのリクエストを最小限に抑えつつ、コストとパフォーマンスの最適化が可能になります。

データベースにより高いスケーラビリティを求める場合は Cloud Spanner も検討ください。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。

Google Cloud はもちろん、他のクラウドやオンプレミス環境で稼働するアプリケーションの各種ログを分析するプラットフォームを BigQuery を中心に構成した例です。

この例では、コンテナ化されたアプリケーションを Cloud Run で稼働しつつ、別のコンポーネントは他のクラウドやオンプレミス環境で稼働しているものと想定しています。

Cloud Run 上のコンテナアプリケーションのログはデフォルト Cloud Logging に集約されます。集積した大量のログに対して高度な分析に高速に行うことができるよう、Cloud Logging から BigQuery に自動的にログエントリが出力されるように設定しておきます。

他クラウドやオンプレミス環境で稼働するアプリケーションのログについても、 データレイクとして Cloud Storage に転送・集積させた後、必要に応じて Dataflow を用いて ETL 処理を施し、BigQuery に保存します。

アプリ上のユーザー行動ログは Google Analytics for Firebase を活用できます。こちらのログも標準機能を用いて BigQuery に統合することが可能です。

BigQuery に保存された各種ログは SQL を用いて容易に分析ができる他、簡単に連携が可能な Data Portal などの視覚化ツールを用いてダッシュボードの作成が可能です。

本料金試算の詳細はこちらのリンクから確認いただけます。手順と必要なリソースはこちらから入手可能です。

バッチ予測を行う機械学習プラットフォームを構築する例です。

BigQuery MLにより、普段データを貯蓄しているBigQuery からデータを移動させることなしに、データアナリストが使い慣れている SQL を用いて機械学習モデルの構築、予測の実行ができます。

BigQuery MLでサポートされているモデルを用いて、需要予測、おすすめ商品の提示、キャンペーン施策のためのユーザ分類といったことが可能です。モデルの詳細はこちらをご確認ください。

こちらは、BigQuery に保存されている 5 年分のデータの中から 500 MiB の今週の取引情報を元に、来週の 100 万人の顧客の生涯価値を予測し、キャンペーン施策検討に繋げる例を示しています。

本料金試算の詳細はこちらのリンクから確認いただけます。

Cloud Support API を利用した Slackbot では以下のようなアクションが Slack から行えます。

• Google サポート からの更新を Slack にポスト

• Slack からケースへのコメント追加

• 組織の配下で現在アクティブなケースがいくつあるか確認する

こちらの料金試算例ではサポートとのやりとりによりサポートケースの更新が 100 回 / 月 の頻度で発生すると想定しています。

デプロイの手順はこちらの Github を参照ください。

https://github.com/GoogleCloudPlatform/professional-services/tree/main/tools/google-cloud-support-slackbot

本料金試算の詳細はこちらのリンクから確認いただけます。

Wordpress ウェブサイトを展開するアーキテクチャパターンの例です。このアーキテクチャは、ブログ、イントラネット / 社内 Wiki、e コマースプラットフォームに利用することができます。

Cloud Run：Web 指向のアプリケーションのコンテナをホストするサーバーレス PaaS で、セキュリティ、スケーラビリティ、容易なバージョン管理を提供します。

Cloud SQL：SQLデータベースのマネージド ソリューション

VPC Service Connector：Cloud Run から Cloud SQL VPC にアクセスするためのソリューションで、内部IPアドレスのみを使用します。

Terraform スクリプトはこちら、価格試算はこちらで確認可能です。手順と必要なリソースはこちらから入手可能です。

オンプレミス環境、Google 以外のサービス、マルチクラウド環境から取得したデータを可視化する例です。

可視化されるデータはソースから Looker に送られ、可視化ダッシュボードの作成や Looker BI Engine の活用により、データの予測分析および洞察を得ることができます。

また、Looker を活用して、データ駆動型のカスタムアプリケーションを構築し、データ駆動型のワークフローを設計することができます。

スタンダード版は、中小企業のお客様に最も人気のあるサービスで、1 ヶ月あたり最大 1 万件のクエリー API アクセスと 1 万件のアドミン API アクセスを提供し、追加ユーザーと機能拡張アドオンは追加料金で利用できます。

これは、社内のオンライン予測アプリケーションのオブジェクト検出パイプラインを構築した例です。

Vertex AI は、データセットの管理、ビルド済み ML ソリューションの使用、カスタムモデルのトレーニング、推論用モデルのデプロイメントのための統一プラットフォームを提供します。

AutoML Vision API を使用すると、画像に対する機械学習の最小限の知識で物体検出モデルをトレーニングすることができます。

この例では、クラウドストレージに保存されている、それぞれ 1MB の 50 万枚の画像を使用して、物体検出用の AutoML Vision モデルをトレーニングします（年に1回のタスクとして）。このモデルはその後、1 日 12 時間、週 5 日、オンライン推論に使用されます。

なお、1 回限りのトレーニングにかかる費用は、12 ヶ月にわたって分配されます。また、Vertex AI モデルにアクセスして推論を行うアプリケーションのホスティングと実行にかかる費用は、ここでは考慮されていません。

料金試算例は、こちらから確認できます。

このソリューションでは、多くの異なるソースから同時に多数のイベントを取り込み、処理し、分析するアーキテクチャパターンの例を探ります。処理はイベントの展開に応じて行われるため、リアルタイムでの対応と意思決定が可能になります。

• Pub/Sub はリアルタイムイベントの取り込みのためのパイプラインとして機能します。

• データフローはデータ変換を実行します。

• そのデータは BigQuery の分析エンジンにロードされます。

ダッシュボードの作成やデータの可視化には、Data Studio や Looker を使用することができます。

価格の試算は、以下の前提で行っています。

ユーザーあたり 100MB / 時間

1000 ユーザー

手順と必要なリソースはこちらから入手可能です。

この料金計算の詳細は、こちらから確認できます。