ユースケースごとの
構成パターン

目次

はじめに

Google Cloud をご利用いただく際に、よく使われるデザインパターンをユースケースごとにまとめています。

Windows ファイルサーバー

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 サービスや広告サービスとの連携も簡単に可能になります。

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

自動スケールするアプリケーションプラットフォーム(Compute Engine 利用の場合)

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

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

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

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

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


自動スケールするアプリケーションプラットフォーム(Cloud Run の場合)

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

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

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

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

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

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