Google Cloud 各サービスの解説

本アーキテクチャで使用しているクラウド サービスと設計のポイントを、下記で解説します。

Google Compute Engine

Compute Engine を使用することにより、Google のインフラストラクチャ上で仮想マシンを作成して実行できます。Compute Engine は、スケーラビリティとパフォーマンスに富んでおり、Google のインフラストラクチャ上に大規模なコンピューティング クラスタを簡単に構築できます。 ここでは、Compute Engine の利用時のポイントについて解説します。詳細については、ここでは触れませんので、参考資料のドキュメントをご参照ください。 


仮想マシンの選択

Compute Engine では、システムの多様な要件に対応するため、さまざまなマシンタイプを提供しています。マシンタイプとは、システムメモリ サイズ、仮想 CPU（vCPU）数、永続ディスクの制限など、仮想マシン（VM）インスタンスで使用できる仮想ハードウェア リソースのセットのことです。 下記の表を参考に、マシンタイプを選択してください。 なお、お客様のニーズへの対応や技術の進化にあわせて、新しいマシンタイプが追加される可能性があります。最新のマシンタイプの情報については、Compute Engine のドキュメントをご参照ください。

上図：Compute Engine マシンタイプ 

インスタンス サイズの決定

マシンタイプ ファミリーを選択したあと、vCPU やメモリ要件に応じて、マシンタイプを選択します。事前定義されたマシンタイプ（例 : n2-standard-4、e2-standard-16 など）では、vCPU 数やメモリ数があらかじめ決められています。 一部の汎用マシンタイプ ファミリーにおいては、ニーズに適合した汎用の事前定義されたマシンタイプがない場合、インスタンスに必要な vCPU の数とメモリ量のカスタム マシンタイプを作成できます。


改ざん防止

Compute Engine の機能である Shielded VM は、VM インスタンスの検証可能な整合性を提供します。これにより、インスタンスがブートレベル、またはカーネルレベルのマルウェアやルートキットによって改ざんされていないことを確認できます。Shielded VM の検証可能な整合性は、下記 3 つを使用して実現され、それぞれの項目を VM インスタンス作成時に有効化 / 無効化することができます。

ストレージ

Compute Engine には、インスタンス向けに複数のストレージの選択肢が用意されています。ストレージの選択により、料金と性能特性が異なります。 

下記の表を参考に、要件に該当するストレージを選択してください。

上図：ストレージの選択肢 

ディスクタイプにより、パフォーマンス特性は異なります。ディスクタイプの詳細については参考資料のドキュメントをご参照ください。


顧客管理暗号鍵

Compute Engine は、すべての保存データを既定で暗号化します。Compute Engine は、この暗号化を自動的に処理、および管理するため、お客様側での作業は必要ありません。ただし、お客様が自分でこの暗号化を制御、および管理したい場合、独自の暗号鍵を提供できます。 

お客様が独自の暗号鍵を提供した場合、Compute Engine はその鍵を使用して、データの暗号化と復号に使用される Google 生成の鍵を保護します。正しい鍵を提供できるお客様だけが、お客様指定の暗号鍵で保護されたリソースを使用できます。

Google は、お客様指定の鍵を保持せず、お客様が鍵を提供しない限り保護されたデータにはアクセスできません。このことは、お客様が鍵を忘れたりなくしたりした場合、Google には失われた鍵、または鍵で暗号化されているデータを復旧する手段が無いことも意味しますので、暗号化鍵の管理にご注意ください。

永続ディスクを削除すると、Google は暗号鍵を破棄し、データを回復不能にして、セキュリティを確保します。

Virtual Private Cloud（VPC）

Virtual Private Cloud（VPC）は、IaaS 環境の構築において、そのシステム用に論理的に隔離されたプライベート ネットワーク空間を構築することができます。VPC には Compute Engine の VM インスタンス以外にも、Google Kubernetes Engine（GKE）クラスタ、App Engine フレキシブル環境などの CaaS、PaaS サービスも参加可能です。

VPC は、グローバル リソースです。単一の VPC で、東京、大阪間などの複数のリージョンにまたがった通信を実現できます。複数リージョンを構成するために、VPC を東京・大阪個別に作成して、その間をピアリング接続するなどの構成は必要ありません。 VPC 内の通信は、リージョンが異なっていても、Google 内部のネットワークを通り、公共のインターネットを経由することもありません。また、VPC とオンプレミス リソースとの間の接続を、1 つの VPC 内のすべてのリージョンと共有できます。

サブネットは、リージョンリソースです。サブネットごとに、IP アドレスの範囲が定義されます。同じセキュリティ ポリシーを持つ VM インスタンスを、同一のサブネットに配置します。 最小特権の原則に従い、サブネット レベルでネットワーク ユーザーロールを付与し、セキュリティを確保します。


共有 VPC

アーキテクチャでは、このシステム専用の VPC を作成しました。VPC は同じアカウント内でも独立したネットワーク空間のため、異なる VPC 上のシステムが通信を行うためには、VPC 同士を接続するための何らかの手段が必要となります。 これに対し、共有 VPC を使用することで、共通の VPC ネットワークに接続することもできます。組織全体で 1 つの VPC を使用しながら、プロジェクト内のチームごとに請求や割り当てを個別に管理できます。これにより、ネットワークを一元管理することが可能です。もちろん、共有プライベート IP 空間や、共同で利用するサービスへのアクセスはどのチームも同様に利用できます。

ファイアウォール ルール

ファイアウォール ルールを使用することで、どの通信をどの宛先に送信できるようにするかを制御できます。必要とする通信のみを許可することで、VPC ネットワークのセキュリティを確保できます。

ファイアウォール ルールには、下記の特性があります。


ファイアウォールの暗黙のルール

すべての VPC ネットワークには、2 つの暗黙のファイアウォール ルールがあります。 暗黙のルールは削除できませんが、優先度は低く、ユーザーが作成したルールの優先度を高くすることにより上書きできます。暗黙のルールを理解し、必要に応じて VPC ネットワーク内のルールを変更してください。

Cloud Load Balancing

Cloud Load Balancing は、分散されたソフトウェア定義型のマネージド ロードバランサで、1 秒あたり 100 万を超えるクエリに応答できるスケーラビリティを持っています。 Cloud Load Balancing を使用することで、複数の VM インスタンスに負荷を分散させたり、冗長構成における単一のフロントエンドを提供したり、外部からの DDoS 攻撃から保護することができます。 Cloud Load Balancing は、いくつかの種類があり、トラフィックの種類や、インターネットからのアクセスの要否などの要件に応じて選択肢が異なります。

上図：Cloud Load Balancing の種類

今回のリファレンス アーキテクチャでは、一般の利用者からの外部インターネット アクセスに対しては、外部 HTTP(S) 負荷分散を使用し、庁内からの Cloud Interconnect 経由でのプライベート ネットワーク アクセスに対しては、内部 HTTP(S) 負荷分散を使用します。

Cloud Interconnect

Cloud Interconnect により、オンプレミス ネットワークを、可用性が高くレイテンシの低いプライベート接続を通じて Google のネットワークに拡張することができます。 Dedicated Interconnect を使用して、オンプレミス ネットワークと Google のネットワークを物理的に直接接続する、または Partner Interconnect を使用して、サポートされているサービス プロバイダを介して、オンプレミス ネットワークと Google のネットワークを接続できます。

リファレンス アーキテクチャ図は、簡略化された表現になっていますが、実際の Cloud Interconnect のネットワーク構成は、求める可用性によって異なります。

1 つのリージョンに、少なくとも 2 つの VLAN アタッチメントを配置し、個別のエッジ アベイラビリティ ドメインで、それぞれ固有の Cloud Router を使用します。この構成で、99.9% の可用性を達成することができます。

上図：Partner Interconnect における 99.9% の可用性構成の例

さらにミッション クリティカルなシステムにおいては、2 つのリージョンに 2 つの VLAN アタッチメント（合計 4 つ）を配置し、それぞれに専用の Cloud Router を使用します。この構成で 99.99% の可用性を実現することができます。 

上図：Partner Interconnect における 99.99% の可用性構成の例

Cloud Router

Cloud Router は、VPC ネットワークにボーダー ゲートウェイ プロトコル（BGP）を使用して、動的ルーティングを提供するサービスです。Cloud Interconnect、Cloud VPN（HA VPN）、Cloud NAT を使用、接続する際に必要となります。

Cloud NAT

VM インスタンスのゲスト OS の更新プログラムの取得などの理由により、VM インスタンスがインターネット経由で外部へ通信する必要があることが考えられます。 Cloud NAT は、外部 IP アドレスを持たない VM に送信元ネットワーク アドレス変換（SNAT）を提供します。また、Cloud NAT は、確立された受信レスポンス パケットに宛先ネットワーク アドレス変換（DNAT）を提供します。Cloud NAT を使用することにより、個別の VM インスタンスに外部 IP アドレスを割り振る必要がなくなります。 Cloud NAT はソフトウェア定義の分散マネージド サービスです。プロジェクト内の VM や単一の物理ゲートウェイ デバイスには依存しません。これにより、可用性やスケーラビリティを持つことができます。

Cloud IAM

Cloud Identity and Access Management（IAM）は、クラウド リソースのアクセス制御の機能を提供します。Cloud IAM により、特定のリソースに対するアクションの実行を、承認を受けたユーザーのみに許可でき、システム全体のセキュリティを強固にします。 アクセス制御の構成のポイントについては「アクセス制御」で取り上げます。

Cloud Operations

Cloud Operations は、これまで Stackdriver と呼ばれていたサービスで、Google Cloud 環境でアプリケーションやサービスの運用監視機能を提供します。

Cloud Operations は、運用監視サービスの総称であり、下記のようなサービスが含まれます。

運用監視のポイントについては「運用監視」で取り上げます。

Config Connector

Config Connector では、Kubernetes のカスタムリソース定義（CRD）とコントローラのコレクションが提供され、YAML ベースのリソース定義や、kubectl によるデプロイなど Kubernetes アプリケーションを管理するのと同じ方法で Google Cloud リソースを管理することができ、管理者の複雑さと開発者の認知的負荷を軽減できます。

Config Connecter を活用することにより、再現可能なデプロイ プロセスを構築することができます。このサービスを活用し、インフラストラクチャの構築をコード化、自動化することにより、下記のような利点があります。