昨年の12月頃らしいですが、GCEでもSubnetがサポートされました。最初、これを知った時 なんて無駄な機能をつけたんだ!Googleのパワーをこんなしょうもないことに使うな
と思いましたが、調べてみるとGoogle流の考慮は入っていました。
ひとまず、このエントリに引っかかった人は、最後まで読んでください。tl;dr とかでは表せませんが、無理やり概要をまとめると、GCEもsubnetという太古のダサい技術をサポートしてしまったが、他のパブリック・クラウドとは一味ちがうから安心して!
となります。
今までの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対応にも二種類存在します
- autoモード
- customモード
autoモード
自動設定するウィザードではありません
customとは全然違います。
- 各リージョンに1つのSbunetが自動生成
- Subnetの追加・削除は一切できない
- 既存SubnetのCIDRの変更できない
- (多分) 新リージョンが増えたら勝手に新しいCIDRが追加される
サブネットは存在こそしますが、ユーザーはメンテナンス・オペレーション出来ません。 これにより、おそらくですが、新リージョンがリリースされると、勝手にSubnetは追加されていくと思います。
customモード
完全に Subnetをユーザーがコントロール出来ます。つまり
- 各リージョンに Subnetを1つずつ作るか否かはユーザー次第
- 1リージョンに Sbunetが2つとかもユーザー次第
- CIDRも自由自在、ユーザー次第
- (多分) 新リージョンが増えても勝手に新しいCIDRは作られない
どうしても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 ルールとしては下記のようなものを設定すれば、内部通信は全疎通となります。
Subnet間は疎通ルールを足していないが、インスタンスタグで疎通させている場合はどっちが適応?
- Subnet A: 192.168.1.0/24
- Subnet B: 192.168.2.0/24
Subnetレベルで疎通はNGとしているが、各サブネットにインスタンスを立てて、そこに疎通させるためのタグをつけたらどうなるのか?試してみました。
ここで作成した 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の本質は今のところ変わっていないので安心しました。