昨年の12月頃らしいですが、GCEでもSubnetがサポートされました。最初、これを知った時 なんて無駄な機能をつけたんだ！Googleのパワーをこんなしょうもないことに使うな と思いましたが、調べてみるとGoogle流の考慮は入っていました。
ひとまず、このエントリに引っかかった人は、最後まで読んでください。tl;dr とかでは表せませんが、無理やり概要をまとめると、GCEもsubnetという太古のダサい技術をサポートしてしまったが、他のパブリック・クラウドとは一味ちがうから安心して！ となります。

20160625192154

今までのGCE:Network

GCPドキュメント上では、Legacy mode と書いていますが、こちらのほうが よっぽど先鋭的 です。簡単にまとめると

  • ローカルIPアドレスの CIDRだけ指定する
  • そのCIDRは全リージョンにまたがる

たったこれだけです。AWSで言い換えると

  • 全リージョンをまたぐVPCが1つ
  • VPCのなかにsubnetは存在しない。言い換えるならVPC全体が1つのsubnet

これでほぼすべてを賄っていました。これで十分なんです。

Subnet対応でできるようになったこと

一応メリットはあります

  • ローカルIPアドレスを手動固定できる
  • SubnetのCIDR単位でFW ルールを指定できる （ただし AWSのような ルートテーブル – サブネットのひも付けはない)

正直、どうでもいい。。

Legacy Network におけるローカルIPアドレスは、すべてDHCPで、ユーザーで指定出来ませんでした。嘘でした、今確認したらLegacyでもできるようになってました。できると嬉しい！と思うひともいるかもしれませんが、GCEはAWSと異なり、起動時に決めるホスト名で内部DNSが自然に登録されるため、ローカルIP同士をIPアドレスで叩く必要はほぼ皆無です。AWSのような、IPアドレスベースの使いにくいFQDNではなく、ホスト名のみで、/etc/hostsとか登録無しでOKです。

次に SubnetのCIDR単位でFW ルールを指定できる点ですが、これもAWSとは考え方が全く違います。手っ取り早く説明するため、AWSの Public-Subnet / Private-subnet で説明します。
どこかのブログのエントリでもありましたが、このGCE:subnet をつかったとしても Public-subnet / Private-subnet は実現出来ません、が、GCEは AWS流の考え方ではなく、別の方法でこれを実現しています。私の感覚では、GCEの実現方法の方がよりスマート です。

AWSの考え方

旧来のネットワークに近い考え方
Public-Subnet: グローバルIPアドレスをもち、インターネットから直接アクセスできる subnet
Private-Subnet: ローカルIPアドレスしか持たず、インターネットから直接アクセスできない subnet

GCEの考え方

インスタンスタグで、FWのみならず、ルートテーブルも管理すればいい (下記名称は私の造語)
Internet-faced-Instance: グローバルIPアドレスをもち、インターネットから直接アクセスできる instance
Local-only-Instance: グローバルIPアドレスをもたず、インターネットから直接アクセスできない instance

双方の違いとメリット

つまり、ネットワーク経路に関することは subnet単位でやるのがAWS流。 subnetなんて元々存在しないので、インスタンスタグでインスタンス単位管理するのがGCE流。 この考え方は Legacy でも Subnetでも変わっていません

また、VPNを張った場合ですが、この場合はSubnetで切れたほうが(全リージョンにアクセス可能な状態がNGならば)メリットはあります。ただし、必須ではないですね、そこもインスタンスタグで制御すればいいので、所詮気分の問題でどうでもいいです。

新しいのGCE:subnet

厳密には subnet対応にも二種類存在します

  1. autoモード
  2. customモード

autoモード

自動設定するウィザードではありません customとは全然違います。

  • 各リージョンに1つのSbunetが自動生成
  • Subnetの追加・削除は一切できない
  • 既存SubnetのCIDRの変更できない
  • (多分) 新リージョンが増えたら勝手に新しいCIDRが追加される

20160625191119

サブネットは存在こそしますが、ユーザーはメンテナンス・オペレーション出来ません。 これにより、おそらくですが、新リージョンがリリースされると、勝手にSubnetは追加されていくと思います。

customモード

完全に Subnetをユーザーがコントロール出来ます。つまり

  • 各リージョンに Subnetを1つずつ作るか否かはユーザー次第
  • 1リージョンに Sbunetが2つとかもユーザー次第
  • CIDRも自由自在、ユーザー次第
  • (多分) 新リージョンが増えても勝手に新しいCIDRは作られない

20160625191209

どうしてもSubnetを弄りたい人は custom一択です。

customモードの説明

customの説明を詳しく書きます。

CIDRの考え方

ドキュメントの絵を見るのが早いですが、1つのネットワークの中に 10.1.0.0/16 と 192.168.0.0/16 が混在出来ます。

Using Subnetworks | Compute Engine | Google Cloud Platform

AWSの場合、Subnetの前にVPCが存在し、VPCのCIDRの範囲内にSubnetを指定する必要があります。(この成約があるので、最初にネットワーク設計をしないと、手戻りが発生してしまいます。)
しかしGCEには VPCに相当するものはNetworkで、Network自体はCIDRを持ちません。よってこんなことが出来ます。

各Subnet間の通信は?

AWSのNetworkACLのように、Subnetに対してのみ効果を発揮するACLは存在しません。AWS的に言うなれば、SGしか存在しません。
各Subnet間の通信も、FW Ruleで、IPアドレス単位での指定に過ぎません。また、デフォルトでは各Subnet間での疎通は出来ません。同Subnet内でも同じく、デフォルトでは別マシンと疎通出来ません
FW ルールとしては下記のようなものを設定すれば、内部通信は全疎通となります。

20160625191310

20160625191319

Subnet間は疎通ルールを足していないが、インスタンスタグで疎通させている場合はどっちが適応？

  • Subnet A: 192.168.1.0/24
  • Subnet B: 192.168.2.0/24

Subnetレベルで疎通はNGとしているが、各サブネットにインスタンスを立てて、そこに疎通させるためのタグをつけたらどうなるのか？試してみました。

20160625191344

ここで作成した internal タグを、互いのインスタンスにつけて、pingを打ちます。 結果は予想通り疎通OKとなります。デフォルトが暗示Deny、明示Denyできないので、Allowが1つでもあるとそれが適応されます。

全リージョンにSubnetを作ることは必須ではない

作りたければ使いたい時、使いたいだけ作れ！というスタンス 私は大好きこの思想。

あとからCIDRは変更できる？

できない。Subnetは新規作成か削除のみ操作可能

Zoneについて

SubnetはZoneには縛られません。 ただし、リージョンを跨ぐことは出来ません。

一先ずここだけでも安心しました。AWS VPCの最大の設計ミス、Subnetは AZを跨げない という悪手は踏襲していません。

まとめ

  • 基本的なACLの考え方は昔から変わっていない。
  • 今までのNetworkは Legacyとか言われるようになって(気に入らない)、作成するには gcloud コマンド経由となった。
  • Auto の Subnet は今までのNetworkとほとんど変わらない。ただ意味もなくリージョン毎にSubnetを切るだけで、追加も削除もできない。
  • Custom の Subnet は自由にSubnetを切れる
    • Classをあわせる必要すらない
    • 大きなアドレス空間を細切れにしていく設計も不要
    • SubnetはRegionを跨げない
    • SubnetはZoneを跨ぐ、絞りたければインスタンスを建てなきゃいいだけ
    • ubnet毎にルートテーブルとか、ダサい仕様もない
  • Subnet内にインスタンスを構築するとき、ローカルIPアドレスを指定しなくとも、連番で若番から使う

なんでこんなにSubnetを嫌うのか

AWS-VPCを触ったあとに、初めてGCEを触った時に、ネットワークの簡素さに不安を覚えました。
「え、こんなに簡素でいいの？これしかできないの？」
しかし、インスタンスタグレベルでサーバ間通信、ルート、セグメントを分割できると知ったとき
「なんて賢いんだ！さすがGoolge！」
と思いました。私はネットワーク屋ではありませんが、オンプレ時代、というかクラウドコンピューティングが存在しなかった頃のインフラ屋を知っています。その概念から考えると

  • 各セグメントはSubnetで切るものだ！
  • セグメント毎にFWでコントロールするものだ！

という固定観念が多くの人にあるはずです。しかし、ほとんどのパブリック・クラウドはブロードキャストはおろか、ARPすら無いネットワークで、Subnetでセグメントを割る必要すら本当は無いのです。
ACLをサブネットに求める必要すらなく、他の選択肢が存在するので、そちらを選べば良いのです。はっきり行って、Subnetにこだわるのは時代遅れです。
GCEは私が知る限り、最後発だと思いますので、先人(AWS達)が継承した 古臭い固定概念 をバッサリ捨てました。正しい判断だと思います。

だいぶネガティブな論調で書きましたが、今回のSubnet対応により、Subnetを切らないと気がすまない という 意味のないこだわり は実現出来ます。ただしGCEのNetworkの本質は今のところ変わっていないので安心しました。

元記事はこちら

「GCEのSubNetwork対応による、変更点とAWSとの違い 」