はじめに
クラウドコンピューティングサービスを使用するにあたり、AWS を使ったことのある方は多いとおもいますが、マルチクラウド環境を構築する必要があったり、所属する組織のルールなどで AWS 以外のクラウドを使用する必要に迫られることもあるかとおもいます。
本記事では、私が実務において Google Cloud でインフラ構築をする際に感じた AWS との違いや、構築時のポイントについて、リソースごとに3回に分けて取り上げたいとおもいます。
記事構成、対象リソース
第1回（本記事）
- ネットワーク系リソース
- VPC
- サブネット
- ルーティング
- ファイアウォール
- インターネットとの接続
- Cloud NAT
- 限定公開のGoogleアクセス
第2回
- Compute系リソース、負荷分散
- ComputeEngine
- CloudRun
- サーバーレスVPCアクセス
- Cloud Load Balancing
- Cloud Armor
第3回
- データベース系リソース
- Cloud SQL
- Cloud Spanner
- まとめ
Google Cloud の概要・特徴
Google Cloudは、Googleが提供するクラウドコンピューティングサービスです。利用者は Google のインフラストラクチャ上でアプリケーションの開発、デプロイ、実行が可能となります。他のパブリッククラウドと同様に、利用者は物理的なサーバーやデータセンターの維持管理を気にすることなく、高度なコンピューティングリソースを活用することが可能です。
主なサービスとしては、Google Compute Engine (仮想マシン), Google Kubernetes Engine (コンテナ管理), Google Cloud Storage (オブジェクトストレージ), BigQuery (ビッグデータ解析) などがあります。これらのサービスは、利用者が必要とするリソースをスケーラブルに利用できるため、小さなスタートアップから大手企業まで幅広く活用されています。
また、Google Cloud は機械学習やAIのサービスも充実しており、Googleの技術を背景に、容易に高度な解析や学習が行えます。Vertex AI や AutoML などのサービスは、プログラミングの知識が少ないユーザーでもAIの恩恵を受けることができる点が魅力です。
VPCネットワーク
VPC（Virtual Private Cloud ）ネットワークは、Google Cloud 上で仮想的なプライベートネットワークを構築できるサービスです。「Andromeda」と呼ばれる仮想ネットワーク技術を使用して実装されています。
VPC 上で出来ることとして、仮想マシンを構築し、マネージドデータベースサービスであるCloud SQLへ接続を行なったり、仮想マシンをアプリケーションサーバーとして、一般ユーザーに公開するなどがあります。
また、本記事では取り上げませんが、VPC 上に社内専用アプリケーションを構築し、社内ネットワークとプライベート接続を行い利用することなども可能です。
AWS の VPC と違う点としては、リージョンリソースではなくグローバルリソースである、ということが挙げられます。そのため、どこのリージョンに作るといった概念はありません。後述するサブネットにおいてリージョンを指定することとなります。また、VPCネットワーク自体はIPアドレス帯を持たず、VPC内に作成するサブネットにおいてCIDR形式でIPを指定する点も AWS との相違点となります。
サブネット
サブネットはVPC内に作成する、リソースが配置されるIPアドレス空間です。分かりやすく言えば、VPC 内に分けて作成されたネットワークです。CIDR 形式でIPアドレス帯を指定します。
AWS のサブネットとは違い、リージョンリソースとなるため、同一VPC内に別リージョンのサブネットを作成することが可能になります。
IPv4 サブネット範囲
各サブネットは作成時に、プライマリ IPv4 アドレス範囲をCIDR形式で指定します。有効なIP範囲として、 RFC1918 のプライベート IP アドレス（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）の他、複数のRFCにて定義されているIPアドレスが使用可能です。公式ドキュメント
なお、作成した全てのサブネットにおいて、プライマリ IP 範囲に4 つの予約済み IP アドレスがあります。プライマリ IP 範囲の最初、2つ目、最後から2つ目、最後のアドレスです。
e.g. 10.1.2.0/24 のサブネットの場合 -> 10.1.2.0, 10.1.2.1, 10.1.2.254, 10.1.2.255
サブネット作成モード
VPCの作成時に、サブネットの作成モードを指定する必要があり、「カスタム」と「自動」の2つから選択します。
「自動」を選択した場合、全てのリージョンにおいて 10.128.0.0/9 CIDR ブロック内 の決まったCIDRにてサブネットが作成されます。（参考）
特別な理由がない限りは、「カスタム」を選択し、自身でCIDRを指定することをお勧めします。
ルーティング
Google Cloud におけるルートは、仮想マシン(VM)インスタンスから、VPC内やVPCの外に到達する経路を指定します。
ルートのタイプは、デフォルトで作成される「システム生成ルート」と、利用者が作成可能な「カスタムルート」に別れます。システム生成ルートには、VPC作成の際に作成される、インターネットゲートウェイへのルートや、サブネット作成時にサブネット間を相互にルーティングするサブネットルートなどがあります。
このように自動でルーティングが設定されるため、AWSと比較して、自身でルートを編集する機会は少ないです。
ファイアウォール（VPCファイアウォールルール）
Google Cloud におけるファイアウォールは、Google Cloud 上のリソースを内部、または外部の攻撃から保護するための機能を備えたサービスです。主に以下の機能がありますが、本記事ではVPCに関連のある、VPCファイアウォールルールについて取り上げます。
- VPCファイアウォールルール
- 階層型ファイアウォールポリシー
- ファイアウォール インサイト
- ファイアウォール ルール ロギング
VPCファイアウォールルールは、仮想マシンなどのVPCリソースとの通信に対して、「送信元、宛先、通信プロトコル、ポート番号」によってトラフィックの許可や拒否を制御する機能を持ちます。パケットの制御についてはステートフルファイアウォールとなっており、例えば上り方向のSSH（TCP22ポート）トラフィックを許可するルールを作成すれば、下り方向のパケットも暗黙的に許可されることとなります。
VPCファイアウォールルールはプロジェクト、VPCネットワーク単位で適応されます。
暗黙のルール
VPCネットワークには、サブネット作成モードに関係なく、全てのVPCにおいて、以下2つの暗黙の IPv4 ファイアウォール ルールが存在します。
暗黙の IPv4 の下り（外向き）許可ルール
アクションが allow、宛先が 0.0.0.0/0、優先度が可能な限り低い（65535）下り（外向き）ルールです。
他のファイアウォールルールにて明示的に拒否されなかった下り（Egress）パケットは許可されます。
暗黙の IPv4 上り（内向き）拒否ルール
アクションが deny、送信元が 0.0.0.0/0、優先度が可能な限り低い（65535）上り（内向き）ルールです。
他のファイアウォールルールにて明示的に許可されなかった上り（Ingress）パケットは拒否されます。
AWS のサービスではセキュリティグループが近いものになりますが、ファイアウォールの適用対象と送信元の指定方法が異なります。具体的には、IPアドレスの他、ネットワークタグ、サービスアカウントなども対象として柔軟な指定が可能となっています。
Cloud NAT
Cloud NAT は、インターネットと接続ができない、外部IPを持たない仮想マシンが、送信元アドレス変換（SNAT）を行い、外部との通信を可能にするマネージドサービスです。
ユースケースとして、外部からの通信は許可したくないサーバが、セキュリティパッチ適用のために外部リポジトリとの通信が必要な場合などが挙げられます。
また、外部IPアドレスをGoogle Cloud で取得し、CloudNATに設定することで、外部サービスとの通信においてIPを固定し、共有することなども可能です。
AWS のサービスではNATゲートウェイが類似のサービスと言えるとおもいます。
限定公開のGoogleアクセス
限定公開のGoogleアクセスは、外部IPを持たない仮想マシンなどが VPC内から Google Cloud のAPI や Google が提供するサービスに対して、プライベートIPを使用してアクセスを可能にする機能です。サブネット単位でアクセスを有効にすることができます。
注意点として、全てのAPIがサポートされている訳ではないため、公式ドキュメントなどによる確認が必要となります。
使用例としては、外部IPを持たない仮想マシンから、CloudStrorage 内のデータにアクセスする場合などがあるかとおもいます。
VPC設計におけるポイント
これまでVPCに関連するサービスの概要に触れてきました。ここからは Google Cloud のVPC設計におけるポイントをまとめます。
VPC作成
VPCの作成時に、サブネットモードの指定が必要です。自動モードは決められたCIDRが割り振られることとなり、使用するメリットがあまりないため、カスタムモードを指定します。本記事では詳しく触れませんが、社内ネットワークなどとプライベート接続する場合は CIDR が重複しないようにする必要があります。
サブネット作成
サブネットはGoogle Cloud においてリージョンリソースです。AWS では配置するサーバの冗長化を考慮して、アベイラビリティゾーンごとにサブネットを作成するケースがありますが、Google Cloudにおいてはゾーンにまたがってサブネットの作成が可能なため、ゾーンごとにサブネットを作成する必要がありません。その分VPC内のネットワーク設計の簡素化が可能です。
また、限定公開のGoogleアクセスはサブネット単位で有効、無効にする必要がありますので、通信要件も考慮して設計する必要があります。
サブネットにはRFC1918などの多くのIPを割り当てることができますが、一部制限などもありますので、内容を理解したうえでIPを指定します。
ルーティング
すでに触れたように、VPC内にサブネットを作成する際やVPCの作成時には、ルートが自動的に作られます。
Google Cloudにおいてルーティングを設定する機会はあまりありません。通信の制御についてはファイアウォールを使用して行うこととなります。
手動で設定を行うケースとしては、特定のトラフィックを内部ロードバランサーに向けたい場合などに限られます。
インターネットとの通信
セキュリティ上の理由で、インターネットからVPC内の仮想マシンへの通信を不可能にし、仮想マシンから必要に応じてインターネットにアクセスはしたいというケースはよくあるとおもいます。
AWS ではNATゲートウェイや、場合によってはプロキシサーバを使用しますが、Google Cloud では Cloud NAT の使用を検討します。VPC内の仮想マシンをプロキシサーバとして構築する方法もありますが、仮想マシンの運用コストが生じます。Cloud NATは マネージドサービスですので、運用の手間を省くことが可能です。
接続元IPを固定したい場合は、手動で Cloud NAT へIPを設定することで対応が可能となります。また、複数のIPを持たせ、宛先によって使用する接続元IPを切り替えることなども可能となっています。
インターネットへのアクセス経路を持たない仮想マシンから CloudStorage などの APIを呼び出したい場合は、限定公開のGoogleアクセスの使用を検討します。
通信制御
ルーティングのところで触れたように、Google Cloud において通信制御は主にファイアウォールを使用して行います。
おさらいになりますが、ファイアウォールは暗黙のルールによって、上り（外部からGoogle Cloudへの通信）はデフォルトで拒否され、下り（Google Cloudから外への通信）はデフォルトで許可される仕様となっています。
例として、Cloud NAT への経路があるサブネット内に配置する2つの仮想マシンのうち、1つはインターネットと通信をさせたくない場合は、インターネットとの通信を拒否するファイアウォールルールを作成し、ネットワークタグやサービスアカウントにより仮想マシンを区別して通信を制御することが可能です。このあたりは AWS の設計と考え方が異なる部分になるので、よく理解して設計する必要があります。
おわりに
本記事では Google Cloud のネットワークに関して基本的な内容と、設計における注意点や AWS との違いについて記載しました。次回は仮想マシンなどの Compute 系リソース、負荷分散について紹介したいとおもいます。
