Google Cloud （GCP）が進化中？ネットワークアーキテクチャ設計のコツを徹底解説！

本記事は、2021年5月27日に開催された Google の公式イベント「 Google Cloud Day : Digital ’21 」において、カスタマーエンジニアネットワークスペシャリストの有賀昇爾氏が講演された「最新 Google Cloud ネットワークアーキテクチャ設計のコツ（2021年版）」のレポート記事となります。

今回は Google Cloud （GCP）に搭載されている様々なネットワーキングサービスについて、最新のアップデート情報を中心に具体的な内容を解説します。ネットワークアーキテクチャを設計する上でのコツも理解できると思いますので、ぜひ最後までご覧ください。

なお、本記事内で使用している画像に関しては Google Cloud Day : Digital ’21 「最新 Google Cloud ネットワークアーキテクチャ設計のコツ（2021年版）」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

Google Cloud（GCP）の進化

Google Cloud（GCP）上で提供されるネットワーキングサービスは年々アップデートや新たな機能追加をしており、昨年度も数多くのアップデートが行われています。その機能は大きく4つのカテゴリ「接続」「スケーリング」「安全」「最適化」に分類されており、2021年5月現在で全15サービスが提供されています。

有賀氏は本セミナーの中で、これらの機能単体の説明ではなく、その機能追加がどのようにお客様の設計を支援できるか？、どういう風にこれまでの設計を変えられるか？という目線で解説しており、その後の機能アップデートについても顧客目線で紹介しています。

次章以降で具体的な内容をご紹介します。

Google Cloud（GCP）のネットワーキングサービス：アップデートと設計のコツ

それでは、 Google Cloud（GCP）ネットワーキングサービスのアップデート情報についてご紹介します。本記事では、主に6つの機能を取り上げており、それぞれ詳細な内容や設計時のポイントなどをユーザー目線で解説します。

一つ重要なポイントとして、 Google 自体はクラウドコンピューティング企業でありながらも、 SD-WAN に近い機能や UTM 並みのファイアウォール機能など、最新のネットワーク技術が取り入れられている点は覚えておいてください。

Private Service Connect

Private Service Connect は、従来の PVC のアップデート版であり、オンプレミス環境と Google Cloud（GCP）をセキュアに接続するサービスです。

従来、 PVC 接続を利用する際は以下の2点が課題として挙げられていました。

• お客様のオンプレミス環境に Google Cloud（GCP）のグローバルアドレスの Rouring table を広告しなければならない
• オンプレミスと Google Cloud（GCP）環境間に複数の接続経路があった場合において、複数の VPC を有効活用する接続構成をとることができない

この2つの課題に対して、 Private Service Connect は、単なる PVC 機能ではなく、オンプレミス環境、および Google Cloud（GCP）双方のエンドポイントとなることで対処しています。

例えば、オンプレミス環境から Google Cloud（GCP）上の2つの API に対して別々の経路で通信するよう設計したい場合、2つの経路の先に Private Service Connect を設定し、それぞれの API の Gateway とします。オンプレミス環境側には API 向けの経路を Static に設定することで Google Cloud（GCP）上のグローバルアドレスの動的な Routing table を広告することなく、経路分離ができるようになります。

この手法は旧来のネットワークアーキテクチャで構成できるものの、実際にはオンプレミス環境でしか実現できない機能です。なぜなら API サーバーごとに物理的な Gateway を設置するのはコスト的に困難であり、クラウド環境だからこそ実現できる構成だと言えるでしょう。

これまでのネットワークエンジニアからすればなんだ、と思われるかもしれませんが、クラウド環境下ということを考えれば有効な手段と言えるのではないでしょうか。

階層型ファイアウォールポリシー

元々 VPC にはアクセスコントロールができるファイアウォール機能が標準搭載されていました。しかし、ファイアウォールのルールに関しては、すべての VPC 単位で個別にルール設定する必要がありました。

これは大きな課題であり運用負荷を上げる原因となります。 VPC が1つの構成であればそこだけ管理すればよいのですが、規模が大きくなり1つの組織配下で複数の VPC を管理するとなれば話は変わります。

組織レベル、あるいはフォルダレベルで共通ルールを設定する場合、すべての VPC に同一ルールを設定していく必要があるのです。これまでもルールを一元管理するツールはありましたが、あくまでもそれは管理であり、複数の VPC に設定する手間は変わらないわけです。

そこで登場したのが、階層型ファイアウォールポリシーです。 Google Cloud （GCP）のリソース階層は組織-フォルダ-プロジェクト-リソースの構成となっており、 API はリソースに属しています。

階層型ファイアウォールはこれまでリソースレベルで1つずつ API 設定を行う必要があったルール設定を組織レベルやフォルダレベルでルール設定ができるようになったのです。

組織やフォルダレベルでルール設定ができるようになったことで、その配下に配置した VPC には共通ツールが適応されます。これにより共通ルールを1つずつ設定する手間を削減できるようになりました。

ネットワーク仮想アプライアンスと共有VPCによる構成

2021年の春のアップデートでサブネットごとに管理権限を与えることができるようになりました。

これまで VPC では管理権限を1つしか与えることができなかったため、利用者が管理者にならざるを得ませんでした。そのため、サブネット管理は利用ユーザー、ファイアウォール等の管理をネットワーク管理者と分けざるを得ない状況が生まれており、アプリ管理者にネットワーク管理を強いることになる点で課題を残していました。

そこで、今回の共有 VPC が効果を発揮します。管理権限を複数持てることで、ファイアウォールを含めた VPC 全体の管理はネットワーク管理者が行い、サブネット単位で個別に必要な VPC 管理権限は利用ユーザーがそれぞれ持つことで、利用ユーザー側の負担を最小限とし、ネットワーク管理者にとっても柔軟な運用を可能としています。

これまで、 Google Cloud（GCP）の管理における責任分界点で苦慮されていた企業担当者様にとっては、非常に嬉しい機能だと言えるでしょう。

ロードバランサ―

Google Cloud（GCP）では、様々な種類のロードバランサーをサポートしています。

数あるロードバランサーの中から、今回は「外部 HTTP（S）ロードバランサー」と「L4内部ロードバランサー」の2つのロードバランサーについて、アップデート内容を詳しくご紹介します。

外部 HTTP（S） Load　Balancing + サーバーレス NEG

1つ目は外部 HTTP（S）ロードバランサーについてのアップデートです。

これまでロードバランサーでは、サーバータイプのサービスでなければバックエンドとして指定できませんでした。つまりロードバランシングできるのは Compute Engine のみで、サーバーレスタイプのサービスには適応できず、不便な部分がありました。

そこで登場したのがサーバーレス NEG です。サーバーレス NEG と組み合わせて利用することで、 App Engine 、 Cloud Functions 、 Cloud Run などを指定できるようになりました。これによりコンテンツルーティング、証明書などのサービスにもロードバランス機能を適用できるようになり、各サービスの信頼性を上げる手段ができたと言えます。

L4 内部ロードバランサー

2つ目は L4内部ロードバランサーの機能追加です。

これまでの L4内部ロードバランサーでは、1台の仮想ロードバランサーで1つの IP アドレスに対し、1つのプロトコル・ポートしか対応ができませんでした。そのため、オンプレミス環境から Google Cloud（GCP）への移行が困難になるケースも存在していました。

しかし、今回のアップデートで下記の対応が可能となりました。

• 同じ IP アドレス・違うプロトコル・同じポート
• 同じ IP アドレス・同じプロトコル・違うポート
• 同じ IP アドレス・違うプロトコル・ Port any

これにより、前述した制約がなくなり、オンプレミス環境からの移行が容易になりました。加えて、新規アプリケーションに対してもロードバランサ―構成の自由度が上がったため、より利便性が高まったと言えるでしょう。

Cloud Armor

Cloud Armor は DDoS 対策と WAF （Web Application Firewall）の機能を持つサービスです。

今回は「 Cloud Armor Managed Protection Plus 」と「 Cloud Armor　Adaptive Protection 」の2つのサービスのアップデートについて、詳しくご紹介します。

Cloud Armor Managed Protection Plus

Cloud Armor Managed Protection Plus は DDoS 対策について、 Google の DDoS サポートチームのサポートを受けられるサブスクリプションサービスです。

これまでのサービスでは DDoS から攻撃を受けた場合、検知までは Cloud Armor 側で実施するものの、実際のトラフィック分析や対策検討、ルール適応についてはお客様側で実施する必要がありました。しかしながらこれには高いネットワーク、およびセキュリティスキルが必要となります。

Managed Protection Plus では Google の DDoS サポートチームのサポートを受けることができ、実際のトラフィック分析や、それに対する適切なルール内容のアドバイスを受けることができるため、それほど高いスキルがなくとも Cloud Armor を運用することができます。いわば SOC などに近い機能と言えます。

Cloud Armor Adaptive Protection

Cloud Armor Adaptive Protection は、トラフィックを AI で機械学習させることで AI 側が異常通信を検知、適切なルールを提案してくれる、というサービスです。

導入後、まずはノーマルな状態のトラフィックを分析、ベースラインを作成した上で、通常と違う通信状態を確認した場合、アラートを上げ、脅威内容や追加すべき新たな対策についてリコメンドしてくれます。

専門家のアドバイスを得られるという意味では Managed Protection Plus と同じですが、 AI を活用することで人間の目ではわからない兆候などを把握することが可能になります。

Network Intelligence Center

Network Intelligence Center はネットワーク監視、およびトラフィックなどを監視するための統合監視ツールです。

以下、いくつか機能を抜粋して詳しくご紹介します。

パフォーマンスダッシュボードと Network Topology

パフォーマンスダッシュボードは、ネットワーク側のトラフィックや遅延状態を監視できるツールです。これまで仮想マシン単位でしか見ることができなかったトラフィック、遅延などを、リージョン間や VPC 単位などあらゆる単位で監視できるようになっています。

これにより、仮にネットワーク上の遅延トラブルが発生した場合、どこで輻輳や遅延が発生していたか切り分けることが可能になり、ネットワークトラブルを解消する手段としても利用できます。

また、 Network Topology は、ネットワーク構成を元に管理できるツールです。例えば外部から内部、別々のリージョン同士でどこの間でどんなトラフィックが流れているのか？などを監視できます。

Firewall Insights

Firewall Insights は Firewall ルールが適切に利用されているか？を確認できるツールです。ルールごとの利用状況を確認することでシャドールールの存在や適切に使われていないルールがないか？を確認することができます。

オンプレミス環境でありがちなのが Firewall ルールの棚卸です。利用し続ければ未使用ルールがゴミのように溜まってしまうため定期的な棚卸が推奨されていますが、実際にルールが利用されているか否かを判断するのは難しく、正確な棚卸しは困難であることが多く見受けられます。

Firewall Insights はルールの利用状況を確認でき、未使用ルールの洗い出しも容易に行えるため、棚卸業務には最適な機能だと言えます。

Connectivity Test

Connectivity test とは、ネットワークトラブルを分析する為のテストツールです。このツールを使うことで、ネットワーク上で発生する遅延や接続問題などのトラブルについて簡単に原因追及することができます。

テストすることで Firewall ルールの問題なのか？経路の問題か？機器故障の問題か？などについて適切に確認、判断してくれます。またその発生個所についても短期間に解析してくれるのも特徴です。

ネットワークトラブルは切り分けに時間がかかるケースも多いのですが、このツールを使うことで多くのトラブルシュートから担当者を解放することができるでしょう。

その他機能

最後にその他機能として2つの機能が紹介されています。

Google Connectivity Center

Google Connectivity Center は Google のネットワーク環境を通じて、お客様のオンプレ環境と Google Cloud（GCP）環境をハブ‐スポーク型に接続するサービスです。回線としては SD-WAN 、専用線、 VPN などあらゆるサービスを使うことができます。

これまで、クラウドサービスとネットワークは別々に管理され、別の会社から提供されるケースがほとんどで、相互接続はお客様の責任下で実施する必要がありました。これらを Google が統合管理することで、お客様の負担をさらに減らすことができます。

組織ポリシー

先ほど階層型 Firewall ポリシー機能として組織ポリシー設定について解説しましたが、それ以外にもアプリケーション利用や VPC 、ロードバランサーの利用制限など多くの点で組織ポリシーを設定することができます。これにより、それぞれのサービスごとに設定していたルールを一か所で設定できるようになり、管理者の利便性が向上します。

ネットワークアーキテクチャ設計に関する質問

Q.User Agent が偽装されてても Adaptive Protection は可能ですか？

A.偽装された User Agent を含むトラフィックが有意に通常のトラフィックと異なっており、 Adaptive Protection によって攻撃と判断された場合は、当該 User Agent を含むトラフィックをブロックするようなルールが提示される可能性が高くなります。

Q.ネットワークのガバナンスを効かせる場合、共有 VPC と階層化 FW のどちらを利用するのがオススメですか？

A.共有 VPC ではネットワークの管理をインフラチームが一括することで、アプリ/システム開発チームがインフラの管理を意識しないで済むという責任分担が実現できます。一方、階層化 FW では、インフラチームが複数あった場合に、組織（会社）全体としてのネットワークアクセスポリシーの一元化を実現可能になります。このように、共有 VPC 、階層化 FW を組み合わせて、全体としてのガバナンスを実現いただけるものと思います。

Q.Cloud Armor は OWASP のルールセットが使われている認識ですが、 Adaptive Protection はそのルールセットをオーバーラップするのですか？

A.Cloud Armor の Adaptive Protection は、攻撃と判断したトラフィックをブロックするためのルールを提示し、ユーザーがそのルールを実際に適用する、という運用になります。一方、 OWASP 由来の攻撃を防ぐのも同じくルールになります。ルールは優先度を持っており、優先度が高いルールから適用されますので、 OWASP 由来のルールと Adaptive Protection が生成したルールと、どちらの優先度を高くするかによって、どちらのルールが適用されるかが決まります。

Q.Private Service Connect で API サービスへのアクセスができるのは理解しましたが、既存の方法との使い分けはありますか？

A.既にこれまでの方法で設定・運用されている場合はすぐに変更する必要はないですが、これから設計される場合は Privatre Service Connect による接続をオススメします。

まとめ

今回は Google Cloud （GCP）に搭載されている様々なネットワーキングサービスについて、最新のアップデート情報を中心に具体的な内容を解説しました。ネットワークアーキテクチャを設計する上でのコツをご理解いただけましたでしょうか。

従来、 Google　Cloud(GCP)を利用するにあたり、ネットワーキングサービスや機能の不足が課題になっているケースもありましたが、 Google Cloud（GCP）は日々ネットワーク機能の追加・アップデートを行なっています。今後もさらなるアップデートによる利便性向上が期待できるでしょう。

皆様もこの機会に Google Cloud（GCP）の利用を検討されてみてはいかがでしょうか？