
DX推進が年々加速する中、これまでのオンプレミス(オンプレ)からクラウドへのシフトも進んでいます。オンプレとパブリッククラウドでのネットワークの基本的な概念をIaaSでも活用できる一方、最終的にはPaaSへのシフトをゴールとする企業も多くなっており、パブリッククラウド特有のマネージドサービスを活用したネットワークの考え方を理解することがキーとなっています。また一挙にこれまでのインフラをパブリッククラウド、しかもPaaS環境へ移行するのは難しいため、IaaSへのリフト&シフトから始め、徐々にPaaS環境へシフトするためにはIaaSとPaaS間のネットワーク構成が重要となります。
企業によっては、当面の間オンプレとクラウドの両方を稼働させるハイブリッド環境が必要なケースもあり、オンプレとGoogleのようなクラウドサービスプロバイダ(CSP)との間をどのように中継するかといったことも検討が必要となります。自社のデータセンターからCSPが提供するサービスに効率よく、かつコスト面も考慮しながらベストな接続環境を構築するためにはパブリッククラウドが提供する様々なサービスを適切に利用する知識も必要です。
今回ご紹介するGoogle Cloudのネットワーク管理者向けプロフェッショナル認定である、Google Cloud Certified Professional Network Engineer(PNE)を取得することにより、現時点でまだまだ少ないクラウドネイティブ人材として、パブリッククラウド特有のネットワーク知識を習得することができます。
これまで3回のPNE受験経験から、Google Cloudにおける各分野別出題傾向をまとめると以下のような割合となります。これはあくまでも私の受験経験からの所感としての数字となりますので、あくまでも参考としていただければと思います。
Google CloudネットワークはVPCを始めとする各種ネットワーク関連のサービス群です。Google Cloudは文字通りGoogleの地球規模のネットワークをバックボーンに、高速で安定した回線によりグローバルロードバランサに代表されるリージョン間の高速通信が特徴です。またオンプレからの移行や並行運用にも豊富なオプションを用意し、中でもCloud Interconnectなどによりお客様環境とGoogle間を内部IPにより安定した回線を利用したデータの移行や移行後のオンプレとクラウドのハイブリッド環境構築なども可能となっています。ここではGoogle Cloudのネットワーク関連のサービスについて見ていきたいと思います。
マイグレーション関連の問題で出題が多いのがDedicated Interconnectです。特に大量のオンプレ内に保存されているデータを、内部IP経由で安全かつ高速に安定したネットワークにより移行する際の選択肢として検討されます。また大量のデータ転送というキーワードでTransfer Applianceとの比較も出題されます。
Partner Interconnectは直接Googleのコロケーションに接続するのではなく、指定のパートナーが提供するサービスプロバイダーネットワークを一旦介してGoogleのネットワークに接続します。Dedicated Interconnect コロケーション施設から地理的に離れた場所にインフラストラクチャを設置しているお客様や、常時 10 Gbps の専用回線を必要としない場合などに検討します。
Google CloudのVPNやその他のサービスではなくGoogle Workspace またはサポート対象の Google API のみにアクセスする必要がある場合はダイレクトピアリングもしくはキャリアピアリングを検討します。通常SaaSプロダクトであるGoogle WorkspaceやCloud SQL、BigTableなどの(VPCを経由せず)API経由でアクセス可能なサービスへは外部IP経由でアクセスします。
Cloud VPN は、IPSec VPN 接続を使用してピア ネットワークを Virtual Private Cloud(VPC)ネットワークへ安全に接続します。2 つのネットワーク間のトラフィックは、一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号されます。これにより、インターネットでデータをやり取りする際もデータが保護されます。Cloud VPN の 2 つのインスタンスを相互に接続することもできます。
VPC Service Controls を使用すると、Cloud Storage や BigQuery などの Google Cloud サービスからデータが漏洩するリスクを軽減できます。VPC Service Controls を使用すると、明示的に指定したサービスのリソースとデータを保護する境界を作成できます。
Access Context Managerは、Google Cloudのプロジェクトとリソースに対する、属性ベースのアクセス制御を定義するものになります。例えばアクセス元のデバイスの種類やオペレーティング システム、IPアドレス、ユーザーIDなどの属性によって制御することが可能です。
インターネット越しに3rdパーティサービスにアクセスするような新しいアプリケーションをホストしたいが会社の規定によりGCEにパブリックIPの付与は禁止されている場合に Cloud NATの利用を検討します。 限定公開の Google アクセスも選択肢としては出て来る可能性はありますが、Google APIとサービスへの外部IPへのアクセスとなるため、3rdパーティサービスにアクセスする場合、Cloud NATを選択肢としては検討します。Cloud NAT(ネットワークアドレス変換)を使用すると、外部IPアドレスのない特定のリソースでインターネットへのアウトバウンド接続を作成できます。
VMインスタンスに外部IPを設定したくない場合、基本的にはGoogle APIなどのGoogle Cloudサービスを利用することはできません。そのような場合にこの限定公開のGoogleアクセスを有効化することにより、外部IPを持たないVMやオンプレなどからCloud StorageやBigQueryなどのGoogle Cloudサービスはもちろん、 Google Map,、Google WorkspaceなどへGoogle API経由でのアクセスが可能になります。外部 IP アドレスを持つインスタンスには影響しません。例えばVMからGCSにデータを保存する場合に、セキュリティの観点から外部IPアドレスを許可しない場合、このサービスを利用することにより安全にVPCからGCSにアクセスさせることができます。
VPC内のインスタンスからGCSなどのGoogleが提供するサービスにアクセスする場合、storage.googleapis.comなどのインターネットを経由してアクセスすることになります。安全に内部IP経由でアクセスしたい場合に、このPrivate Service Connectを利用します。
Network Service Tiers を使用すると、インターネット上のシステムと Google Cloud インスタンス間の接続を最適化できます。プレミアム ティアは Google のプレミアム バックボーンでトラフィックを配信し、スタンダード ティアは通常の ISP ネットワークを使用します。
2019年に発表されたNetwork Intelligence Center(NIC)は、これまでネットワークの変更や追加の際に発生する問題を事前に確認するため、5つの機能を統合したサービスです。直近の試験でもNICに関する出題が確認されているので、事前に利用シーンなどをチェックしておいてください。
Webサイトでサービスを提供している場合、ユーザーのブラウザとの間で通信を暗号化する場合はL7ロードバランサー(外部HTTP(S)ロードバランサー)でSSL証明書を作成し、暗号化を要求するようにします。またGoogle Cloudリージョンに冗長メールサーバーを持っており、場所に基づいて顧客を最寄りのメールサーバーにルーティングしたい場合などはポート995でリッスンするグローバル負荷分散サービスとしてTCPプロキシロードバランサをコンフィグレーションします。
外部 HTTP(S) ロード バランシングは、プロキシベースのレイヤ 7 ロードバランサであり、単一の外部 IP アドレスの背後でサービスを実行し、スケーリングできます。外部 HTTP(S) ロード バランシングは、さまざまな Google Cloud プラットフォーム(Compute Engine、Google Kubernetes Engine(GKE)、Cloud Storage など)でホストされているバックエンドや、インターネットまたはハイブリッド接続を介して接続された外部バックエンドに、HTTP / HTTPS のトラフィックを分散します。
外部 TCP プロキシロードバランサは、インターネットから送信された 外部 TCP トラフィックを Google Cloud VPC ネットワークの仮想マシン(VM)インスタンスに分散するリバース プロキシ ロードバランサです。外部 TCP プロキシ負荷分散を使用する場合、1 つの TCP 接続で受信したトラフィックは負荷分散レイヤで終端し、TCP または SSL を使用して最も近い利用可能なバックエンドに転送されます。
PNEではロードバランサのヘルスチェックに関しての問題も出題されます。ここではPNEで出題が予想されるトピックを中心に解説していきます。
Virtual Private Cloud(VPC)ネットワークは、Andromeda を使用して Google の本番環境ネットワーク内に実装された物理ネットワークを仮想化したネットワークです。VPCはグローバルリソースです。特定のリージョンやゾーンには関連付けられていません。以下の図によりVPC、リージョン、サブネットなどの関係を整理して理解してください。
Google Cloud では、サブネット作成モードで決定される 2 種類の VPC ネットワークを提供します。
Google Cloud VPCネットワークピアリングでは、2 つの Virtual Private Cloud(VPC)ネットワークが同じプロジェクトまたは同じ組織に属しているかにかかわらず、内部 IP アドレス接続できます。VPC ネットワーク ピアリングを使用すると、異なる VPC ネットワーク内のワークロードが内部で通信できるように、VPC ネットワークを接続できます。以下にVPCネットワークピアリングに関しての基本特性をまとめます。
VPC内部には、コンピュータやデータベースに加えてネットワークも管理対象となります。しかし、場合によってはコンピュータなどの管理とネットワークの管理を別々なチームに任せたい場合があります。ネットワーク管理者はすべてのプロジェクトとプロジェクト間のネットワークトポロジに責任を持つためには、勝手にアプリケーション開発者や開発インフラ担当にネットワークの変更までしてほしくない場合もあります。これをIAM、ロール、サービスアカウントだけで実現することが難しいような場合、この共有VPCネットワークとの併用を検討します。
デフォルトでは、VPC ネットワーク内の各仮想マシン(VM)インスタンスには 1 つのネットワーク インターフェースがあります。ただし、複数のネットワーク インターフェースを持つインスタンスを構成することもできます。1 つのインスタンスで複数のインターフェースを使用する場合、各インターフェースはそれぞれ異なる VPC ネットワークに接続する必要があります。複数のネットワーク インターフェースを同じ VPC ネットワークに接続することはできません。
GCEでは非常に多く利用されているLinux 仮想マシン(VM)に対しての接続方法としてコンソールもしくはGoogle Cloud CLIによるコマンドベースのアクセス、サードパーティ製ツールなどの方法があります。また接続に使用するツールとしてメタデータもしくはOS Login(Linux VMのみ)の2つがあります。以下に2つの違いに関してまとめます。
マネージドインスタンスグループ(MIG)の仮想マシン(VM)インスタンスに、更新されたインスタンス テンプレートとインスタンスごとの構成を適用する方法を解説します。
パブリッククラウドのセキュリティの基本となる「最小権限の原則(Principle of least privilege)」を念頭に置いて回答することが必要な場合があります。回答肢の中にいくつかのロール選択肢がある場合、問題文のシーンを理解し、その設定や作業を行う際に最低限必要なロールを選択することが重要です。
ネットワーク関連のロールとしてキーとなるのがネットワーク管理者権限です。具体的にはroles/compute.networkAdmin付与により、どのような事ができて、どのような事が制限できるのかを理解しておいてください。また、共有VPCネットワークなどと合わせて、アプリケーションの開発とネットワーク管理とをいかにしてシンプルに安全に運用するのかといった点においても、ネットワーク管理者の権限をチェックしておくことが重要です。
Google Cloudでは管理すべきサービスはリソースと呼び、GCEやGCSなどは組織、フォルダ、プロジェクトと言ったリソース階層によりアクセス制御する仕組みになっています(リソース階層の例を参照)。例えば会社として統一したポリシーを適用したい場合、組織(Organization)という、通常ドメインといった単位でアクセス制御を行います。更に部署ごとや会社配下の事業部毎に細かく制御したい場合などはフォルダにより管理します。その配下に開発、テスト、本番環境のようにプロジェクト単位でリソースを管理します。ちなみにGoogle Cloudでのベストプラクティスとして、同じアプリケーションやシステムでも開発、テスト、本番環境はプロジェクト単位に分けて管理をします。
Google Cloudにおける権限の管理に関して、各名称や役割に関してしっかりと理解しておきましょう。Google Cloudにおけるアクセス管理モデルはプリンシパル、ロール、ポリシーから構成されています。
これまでPaaSのGAE、IaaSのGCEといった2択のコンピュータですが、GKEリリース以降その中間的な位置としてコンテナによるIaaS的なサーバ環境とそれをマネージドのクラスタで運用するインフラ環境が次第に注目されるようなりました。
GKE は、高可用性コントロール プレーンを含む完全な機能セットを備えた、フルマネージド Kubernetes デプロイメントを実現します。GKE クラスタは迅速に起動でき、最大 15,000 個のノードまでスケーリングできます。GKEには以下の2つのモードが選択可能です。
KubernetesではPOD間は直接接続することを推奨しています。デフォルトではKubernetesはPOD間通信に静的ルートを使用します。これには各Kubernetesノードのコントロールプレーンが各ノードへのこれらのルートを維持することが難しく、スケールするためのコストがかかってしまいます。GKEではコンテナネイティブネットワーク、つまりVPCネイティブクラスタを提供することにより、この問題を解決します。
オンプレミスと 1 つ以上のクラウド プラットフォームで構成されるハイブリッド環境では、環境間で内部リソースの DNS レコードへの参照が必要になることが少なくありません。従来の方法では、オンプレミスの DNS レコードは権威 DNS サーバー(UNIX / Linux 環境の BIND や Microsoft Windows 環境の Active Directory など)を使用して手動で管理されます。Cloud DNSを使用することによりGoogle Cloudとオンプレミス間で統一したDNS環境を利用することが可能になります。
DNSSEC(Domain Name System Security Extensions)は、ドメイン名のルックアップに対するレスポンスを認証するドメイン ネーム システム(DNS)の機能です。これらのルックアップに対するプライバシー保護は行いませんが、DNS リクエストに対するレスポンスの改ざんや汚染を防ぎます。また攻撃者による中間者攻撃がドメイン/IP乗っ取りによる悪意のあるサイトへのユーザーのリダイレクトを防ぐことも可能です。
VPCフローログは、Google Cloud上において、より高度なネットワーク オペレーションを可能にします。ネットワークの透明性を高め、個々の仮想インターフェースまでのネットワークフローをほぼリアルタイム(5秒間隔でログを作成)で追跡するために利用できます。
ファイアウォール ルール ロギングを使用すると、ファイアウォール ルールの効果を監査、検証、分析できます。たとえば、トラフィックを拒否するように設計されたファイアウォール ルールが意図したとおりに機能しているかどうかを判別できます。ファイアウォール ルールロギングは、特定のファイアウォール ルールによって影響を受ける接続数を判別する必要がある場合にも役立ちます。
DX推進が年々加速する中、これまでのオンプレミス(オンプレ)からクラウドへのシフトも進んでいます。オンプレとパブリッククラウドでのネットワークの基本的な概念をIaaSでも活用できる一方、最終的にはPaaSへのシフトをゴールとする企業も多くなっており、パブリッククラウド特有のマネージドサービスを活用したネットワークの考え方を理解することがキーとなっています。また一挙にこれまでのインフラをパブリッククラウド、しかもPaaS環境へ移行するのは難しいため、IaaSとPaaSとのハイブリッド環境から始め、徐々にPaaSへシフトするためにはIaaSとPaaS間のネットワーク構成が重要となります。
また企業によっては、当面の間オンプレとクラウドの両方を稼働させるハイブリッド環境が必要なケースもあり、オンプレとGoogleのようなクラウドサービスプロバイダ(CSP)との間をどのように中継するかといったことも検討が必要となります。自社のデータセンターからCSPが提供するサービスによりどのように効率よく、かつコスト面も考慮しながらベストな接続環境を構築するためにはパブリッククラウドが提供する様々なサービスを適切に利用する知識も必要です。
今回ご紹介するGoogle Cloudのネットワーク管理者向けプロフェッショナル認定である、Google Cloud Certified Professional Network Engineer(PNE)を取得することにより、現時点でまだまだ少ないクラウドネイティブ人材として、パブリッククラウド特有のネットワーク知識を習得することができます。