前置き
これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。
実際に試してみたい方は、60日の無料トライアルをお試しください。（クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。）
本記事のパート1はこちらです。
パート2では、ネットワークの基本的な仕組みを紹介します。
ネットワークモデルの比較
OpenStack Neutronのネットワークモデル
OpenStack Neutronでは、テナント（プロジェクト）ごとに仮想ルーターを配置することで、独立したプライベートネットワークを提供します。仮想ルーターの背後に任意の数だけ仮想スイッチを用意して、それぞれにプライベートIPのサブネットを割り当てます。同一テナントのVMは、仮想ルーターを経由することで、プライベートIPによる相互通信を行います。
・参考 「絵で見てわかるクラウドインフラとAPIの仕組み」より
また、外部ネットワークから接続が必要なVMインスタンスには、フローティングIPを割り当てて、仮想ルーター上でNATを行います。フローティングIPは、それぞれのテナントで事前に確保しておく、グローバルIPアドレスのプールになります。
また、上記のプライベートネットワークは、アベイラビリティゾーンを意識せずに利用することができます。すべてのアベイラビリティゾーンにまたがる形で、仮想ネットワークが構成されていると考えることができます。ただし、リージョンをまたいで仮想ネットワークを構成することはできません。リージョンごとに個別に仮想ネットワークを構成するため、リージョン間で通信する際は、フローティングIPを用いた、外部ネットワーク経由の通信が必要となります。
また、テナント内に複数の仮想ルーターを配置する事も可能で、この場合、異なる仮想ルーターの配下にあるインスタンス同士は、直接に通信することはできなくなります。フローティングIPを用いて、外部ネットワークを介して通信する必要があります。
GCPのネットワークモデル
GCPでは、1つのプロジェクト内に複数の「ネットワーク」を定義することができます。ここで言う１つの「ネットワーク」は、Neutronで言うところの１つの「仮想ルーター」に対応すると考えることができます。ただし、Neutronと大きく異る点として、この仮想ルーターは、すべてのリージョンを内部ネットワークで直結する形で配置されます。（具体的なイメージは、この後の図を参照してください。）
また、GCPの「ネットワーク」には、「レガシー構成」と「サブネット構成」の2種類があります。レガシー構成は、なんと（！）1つのプロジェクトに対して、「全世界のすべてのリージョンにまたがった単一のプライベートなサブネット」が用意されるというGoogleらしい大胆な仮想ネットワークを提供します。下図のVirtual Switchが仮想ルーターに相当すると考えてください。
・参考 「Using Networks and Firewalls」より
冷静に考えると、従来のサブネットは、ネットワーク機器の物理的な配置に合わせてネットワークを分割するために考えだされたものですので、完全に仮想化されたネットワーク上でわざわざサブネットを利用する必要はありません。ファイアウォールによるアクセス制御については、後述のように「ラベル」を用いたパケットフィルタリングが利用できるので、レガシー構成を利用すれば、「サブネットの管理」という作業から開放されて、より柔軟で抽象化されたアクセス制御が実現できます。
・・・とはいえ。
そうは言ってもサブネットがないと・・・という状況もあるため、現在は「サブネット構成」のネットワークがデフォルトになっています。（Cloud Consoleからはサブネット構成のネットワークのみが作成可能で、レガシー構成のネットワークを作成する際は、gcloudコマンドを使用する必要があります。）
サブネット構成は、Neutronの仮想ネットワークに考え方が似ており、リージョンごとに複数のサブネットを用意することが可能です。ただし、Neutronと異なる点として、リージョンをまたいでのルーティングが可能になっており、プライベートIPのままでリージョン間の通信を行うことが可能です。この際、物理的なネットワーク経路として、GCPの内部ネットワークが使用されます。つまり、インターネットを経由せずに、専用線によるリージョン間通信が可能になります。
下図のように、各リージョンのVirtual Switch（仮想ルーター）がグローバルな内部ネットワークで直結されているものと考えてください。
・参考 「Using Networks and Firewalls」より
※ GCPの内部ネットワークについては、この後で詳しく説明します。
なお、レガシー構成のネットワークとサブネット構成のネットワークは、排他的なものではありません。両方の種類のネットワークを定義して利用することも可能です。新しいプロジェクトを作成した直後は、デフォルトで、「default」という名称の（サブネット構成の）「ネットワーク」が用意されており、さらに、各リージョンに「default」という名称の/20の大きさのサブネットが用意されています。
最後に、インターネットから接続するためのグローバルIPについては、Neutronと同様にリージョンごとに確保してインスタンスに割り当てます。GCPでは、「External IP」という名称になります。External IPには、「Static」と「Ephemeral」の2種類があり、Staticは（フローティングIPと同様に）永続的に確保することが可能です。一方、Ephemeralは、インスタンスを起動すると自動的に割り当てられるもので、永続性は保証されません。インスタンスを停止・起動するとIPアドレスが変化する可能性があります。グローバルIPを固定したい場合は、StaticなExternal IPを確保して割り当てる必要があります。
ファイアウォールの設定
Neutronでは、「セキュリティグループ」を用いてパケットフィルタリングを行います。1つのセキュリティグループは、複数のACLをまとめて定義したもので、インスタンスに対してセキュリティグループを適用することで、該当のACLが適用されます。セキュリティグループは、リージョンごとに定義する形になります。典型的には、インスタンスの役割ごとに対応するセキュリティグループを用意します。
一方、GCPでは、ファイアウォールルールは、「ネットワーク」ごとに定義する形になっており、「ルール」と「タグ」の組み合わせでパケットフィルタリングを行います。タグは、それぞれのインスタンスにメタデータとして付与する任意のラベルで、1つのインスタンスに複数のタグを付けることも可能です。一方、ルールは、パケットの転送を許可するACLに対応するものですが、対象のプロトコル／ポート番号に加えて、送信元と宛先を次のような条件で指定します。
・送信元：IPレンジ、サブネット、タグのいずれか
・宛先：タグ
これにより、「インスタンスの役割を示すタグ」と「役割に応じたACLを示すルール」を分離することが可能になります。たとえば、任意のソースIPからタグ「web-server」にTCP80の転送を許可するルールを事前定義しておけば、後は、TCP80での接続を許可したいインスタンスに対しては、「web-server」というタグを付けるだけでOKです。また、宛先のタグを省略したルールを定義すると、任意のインスタンスに対して許可することになります。
ちなみに、プロジェクト作成時のデフォルトでは、「default」ネットワークに対して、以下のようなルールが事前に定義されています。これは、どのような通信を許可するルールかわかるでしょうか？「10.128.0.0/9」は各リージョンのサブネットを包含する上位のサブネットになります。
これは、上から順に「外部からのicmpを許可」「defaultネットワークのサブネットに接続したインスタンス間はすべてのパケットを許可」「外部からのRDPを許可」「外部からのSSHを許可」という意味になります。
GCPの内部ネットワーク構成について
Googleは、もともと自社サービス用のグローバルネットワークを保持しており、その全体的な構成が下記のWebサイトで紹介されています。
・Understand Our Infrastructure
これは、GCPのネットワークインフラにも用いられており、これによって、専用線によるグローバルな内部ネットワークを実現しています。また、インターネットとの相互接続は、世界の複数の拠点にある「Edge Points of Presence (PoPs)」で行われており、インターネットからGCP上のインスタンスに接続する際は、最適な場所のPoPから内部ネットワークに到達します。これにより、利用者の住んでいる場所とインスタンスが存在するリージョンがネットワーク的に遠い場合でも、高速な内部ネットワークを経由して、インスタンスにアクセスすることが可能になります。
また、それぞれのPoPには、コンテンツキャッシュの機能が用意されており、App EngineやCompute Engineを利用して外部向けのWebサービスを提供する際は、グローバルロードバランサーを使用することで、特別な手続き無しにコンテンツキャッシュの機能を利用することが可能です。
その他には、利用者の社内ネットワークを（インターネットを介さずに）GCPの内部ネットワークに直結するための専用線を提供するプロバイダーもあります。詳しくは、下記を参照してください。
次回予告
パート３は、Nova/CinderとCompute Engineの比較です。メタデータサーバーとcompute-image-packages（OpenStackのcloud-init的なツール）なども紹介します。
