はじめのGCP⑦Google Associate Cloud Engineer取得までの道のり-その漆-

今回も、「Google Associate Cloud Engineer」認定取得の勉強におけるアウトプット内容となっています。

将来、「Google Associate Cloud Engineer」認定取得を目指している方向けに、ぴったりの内容となっています。

今回は、ネットワーキング②について説明します。

共有VPC
VPCピアリング
ロードバランサー
まとめ

共有VPC

共有VPCとは、複数のプロジェクトで共有できるVPCのことをいいます。

GCPは、上図のように、一番トップに「組織」があり、その下に「フォルダ」「プロジェクト」「リソース（サービス）」という構造になっています。

そのプロジェクト間で共有して使用できるのが、「共有VPC」になります。

共有VPCのメリット

一つのVPCを多くのプロジェクトで共有
組織としての集中的なネットワーク管理を実現
リソースへ安全に接続
多くのサービスプロジェクトをサポート

ホストプロジェクトとサービスプロジェクト

共有VPCは、「ホストプロジェクト」と「サービスプロジェクト」を割り当てることで作成できます。ホストプロジェクトが使用しているVPNを共有VPCとよび、サービスプロジェクトがホストプロジェクトのVPCを使用することを共有VPCと呼びます。

ちなみに、ホストプロジェクトとサービスプロジェクト以外をスタンドアロンプロジェクトと呼びます。

共有VPCにおけるIAM

共有VPCを使用する際は、下記3つのIAMを使用します。

組織管理者
共有VPC管理者
サービスプロジェクト管理者

1.組織管理者

ロール

resourcemanager.organizationAdmin

権限

Workspace又はCloud Identityの特権管理者
共有VPN管理者を指名
IAMポリシーを管理し、組織、フォルダ、プロジェクトのポリシーを表示できるアクセス権

2.共有VPN管理者

ロール

compute.xpnAdmin
resourcemanager.projectIamAdmin

権限①（compute.xpnAdminロール）

共有VPCホストの有効化
サービスプロジェクトの紐付け
組織管理者のみがこの権限を付与可能

権限②（resourcemanager.projectIamAdminロール）

プロジェクトの許可ポリシー管理の権限

3.サービスプロジェクト管理者

ロール

compute.networkUser

権限

ホストプロジェクトのVPNとサブネットを使用可
VPCの作成・削除は不可
プロジェクトオーナー
Computeインスタンス管理

Computeインスタンス管理

Computeインスタンス管理は、以下のリソースを作成可能です。

VMインスタンス
インスタンステンプレート
インスタンスグループ
静的内部IP
ロードバランサー

VPCピアリング

VPCピアリングは、異なる組織間のVPCをプライベート接続できるネットワークのことをいいます。

VPCピアリングの特徴

Compute Engine、GKE、App Engineフレキシブル環境で動作可能
VPC同士の通信はインターネット経由ではない
ピアリングしているVPCの管理は別々（ファイアウォール等）
片方のVPCのルート設定を使用する場合、もう片方でも同じルート設定する必要有
ピアリングしてVPCでサブネットワークのIP範囲重複不可
1つのVPCが接続できるVPCの数は25
推移的ピアリングはサポート不可※下記で説明
VPCピアリングの作成と削除ができるロールは、Computeネットワーク管理者(compute.networkAdmin)
IPv4のみサポート

推移的ピアリングのサポート不可

推移的ピアリングのサポート不可とは、上記のように3つのVPCがあった場合、「A_VPC」と「C_VPC」は通信できないということです。

一見、「B_VPC」に「A_VPC」と「C_VPC」が接続しているので、「A_VPC」から「C_VPN」に接続できるかのように思えますが、「VPCピアリング」は推移的ピアリングをサポートしていない為、通信できません。

通信したい場合は、「A_VPC」と「C_VPC」に「VPCピアリング」の設定を行います。

共有VPCとVPCピアリングの違い

項目	共有VPC	VPCピアリング
組織間	不可	可能
プロジェクト間	可能	可能
管理方法	集中型	分散型

共有VPCとVPCピアリングの比較表

共有VPCは、あくまで同組織のプロジェクト間のVPCを接続するための機能です。

逆に、VPCピアリングは、異なる組織間の接続を可能にする機能です。

共有VPCとVPCピアリングの接続

共有VPCを設定しているネットワークとVPCピアリングは相互に接続可能です。

上図のように「ネットワークA」と「ネットワークB」がVPCピアリングで接続している場合、「ホストプロジェクト V1」のVMは、「サービスプロジェクトS1」と「サービスプロジェクトS2」のVMに対してアクセスすることが可能です。

ロードバランサー

ロードバランサーとは、外部からのアクセスを複数のサーバに分散して振り分けるサービス（機器）のことをいいます。

例えば、ショッピングサイトを運営していて、サイトにアクセスが集中した時に、それを複数のサーバに分散することで、顧客にショッピングサイトを安定して使用していただく機能です。

GCPのロードバランサーには、下記6個のロードバランサーがあります。

HTTP(S)負荷分散
SSLプロキシ負荷分散
TCPプロキシ負荷分散
ネットワークTCP/UDP負荷分散
内部TCP/UDP負荷分散
内部HTTP(S)負荷分散

1.HTTP(S)負荷分散

HTTP(S)負荷分散は、HTTP(S)アクセスによる負荷分散になります。一番よく使用する負荷分散になります。

特徴は、

グローバルな負荷分散
リクエストポートは、「80」「8080」「443」
IPv4とIPv6をサポート
自動スケーリング
顧客から最も近いサーバにルーティング
URLマップ（決められたマッピングルールでルーティング）
通常ロードバランサーを使用する場合、HTTP(S)負荷分散を使用する

2.SSLプロキシ負荷分散

SSLプロキシ負荷分散は、セッション層のSSLで負荷分散をします。

特徴は、

暗号化された非HTTP通信の負荷分散
グローバルな負荷分散
ロードバランサーでSSLセッションを終端
IPv4とIPv6をサポート
SSL証明書の管理
最適な経路でルーティング
SSL/TLSセキュリティパッチ自動適用
SSLポリシーの使用可

3.TCPプロキシ負荷分散

TCPプロキシ負荷分散は、トランスポート層のTCPで負荷分散をするサービスです。

特徴は、

暗号化されていない非HTTP通信の負荷分散
グローバルな負荷分散
ロードバランサーでTCPセッションを終端
IPv4とIPv6をサポート
最適な経路でルーティング
TCPセキュリティパッチ自動適用

4.ネットワークTCP/UDP負荷分散

ネットワークTCP/UDP負荷分散は、プロキシを使用しないロードバランサーです。

特徴は、

プロキシを使用しない
リージョナルな負荷分散
決められた経路でルーティング

5.内部TCP/UDP負荷分散

内部TCP/UDP負荷分散は、Google Cloud内部通信のトラフィックを分散できます。

特徴は、

リージョン内の負荷分散
バックエンド用負荷分散
レイテンシの短縮
グローバルアクセスオプション（任意リージョンのVMにアクセス可）
ソフトウェア定義の完全分散型負荷分散

6.内部HTTP(S)負荷分散

内部HTTP(S)負荷分散は、GCP内部のHTTP(S)アクセスによる負荷分散になります。

特徴は、

リージョン内負荷分散
プロトコルは、HTTP、HTTPS、HTTP/2
Envoyプロキシに基づく負荷分散

Envoyプロキシ

Envoyプロキシとは、各サービスとの通信をEnvoy経由で制御するプロキシです。要は、DBや他のサービス等、ネットワーク通信の部分をEnvoyに委譲することで、アプリケーションは、アプリケーションを正常に動作することだけを考えればよくなります。

Envoyを使用することで、アプリケーション開発者は、通信部分を意識することなくアプリケーションを開発することができます。

まとめ

今回は、下記3点について説明を行いました。

共有VPC
VPCピアリング
ロードバランサー

GCPのベストプラクティスは、可能な限り、サービスはGoogle Cloud内のネットワークで完結させるというポイントがあるので、今回説明した、「共有VPC」「VPCピアリング」「ロードバランサー」はよく使用するサービスです。是非、覚えておいてください！

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！