「AWSではじめるインフラ構築入門」をGCPに読み替えてやってみる その2
前回の続き
勉強メモなので間違ったことが書かれている可能性があります 🙏
第 4 章
VPC について
ネットワークを構築していく
GCP にも VPCネットワーク があるのでそれを使っていく
GCP の VPC も AWS と同じく、他の利用者とは完全に独立したプライベートなネットワークとなる
AWS との違いとして、GCP の VPC はグローバルリソースなので、VPC はリージョンを跨いで構築することができるが、AWS はリージョンリソースなので、リージョンを跨ぐことはできないと言う点があげられる
初めて VPC を使う場合は Compute Engine API の有効化を求められるので有効化する
VPC 関連の API は Compute Engine API の一部とのこと
最初に存在する default という名前の VPC は不要なので削除する
なお、同一 VPC 内にあるサブネット間で通信することができるため、同じ VPC に所属する日本にあるサブネットとアメリカにあるサブネットの通信も可能ということになる
本に倣って VPC を作成する
- 名前
sample-vpc
- 説明
- 適当に入れる
- VPC ネットワーク ULA の内部 IPv6 範囲
- 本で言うところの IPv6CIDR ブロック的な設定だと思うので、
無効でよさそう
- 本で言うところの IPv6CIDR ブロック的な設定だと思うので、
- サブネット
- VPC はグローバルだけど、サブネットはリージョン単位で作成となる
- カスタムモードを選択する
- 名前
sample-vpc-subnet-1- プロジェクト内で一意である必要がある
- 説明
- 適当に入れる
- リージョン
asia-northeast1
- IP スタックタイプ
IPv4(シングルスタック)10.0.0.0/16
- 限定公開の Google アクセス
- 通常オンでよい
- フローログ
- オン
- VPC 内のトラフィックのログを取得することができる設定
- ファイアウォールルール
- 一旦デフォルトのままで
- 動的ルーティングモード
- ここが詳しい
- オンプレミス環境などの、VPC 外と通信する場合だけ影響がある設定なので、GCP で完結する場合はそんなに気にしなくても良さそう
- まぁグローバルをおすすめされているけど、デフォルトのリージョンにしておく
- DNS API も一旦有効にせず保留
- MTU
- デフォルトにしておく
なお、VPC は作るだけなら無料なので安心
アベイラビリティゾーン
本では AWS のアベイラビリティゾーンについて言及がある
特定のアベイラビリティゾーンで障害が発生した際に、できるだけ耐障害性を高めるためにインフラを物理的に分散するのが望ましいため
この辺り GCP ではどのようになるのかまとめると
- VPC は作成しただけでグローバルなリソースとなるので、既にゾーンどころかリージョンを跨いだ存在となっている
- アベイラビリティゾーンは GCP では
ゾーンと呼んでいる- https://www.alpha.co.jp/blog/202007_02#az--%E3%82%BE%E3%83%BC%E3%83%B3
- GCP のゾーンも物理的に他のゾーンとは分離されていて、特定のゾーンの障害が他のゾーンに影響することはない
- GCP で利用可能なリージョンとゾーンはここから確認できる
- 現在日本には
asia-northeast1(東京)とasia-northeast2(大阪)の二つのリージョンがある - さらにそれぞれに
asia-northeast1-a〜asia-northeast1-cの 3 つのゾーンがある
- 現在日本には
- 従って VPC を作成し、その中に東京と大阪に配置するサブネットを作成すれば、簡単にマルチリージョンなシステムを構築できるということ
- なお、サブネット作成時はリージョンまでしか指定できないが、これにも利点があり、マルチリージョンまで行うのか、ゾーンの分散までにしておくのかを選ぶことができる
- ネットワークの比較図はこれが視覚的にわかりやすい
CIDR 設計方法
AWS ではサブネットを一度作成してしまうと、サブネットが利用する CIDR ブロックは変更できないと書かれているが
GCP ではサブネット作成後でも CIDR を変更することができる
ここでは本に従って、パブリックとプライベートなサブネットに加えて、冗長化のためのサブネットを 2 つの合計 4 つサブネットを同一リージョンに作成した
本だと冗長化のサブネットは別 AZ に作っているけど、GCP ではサブネット作成時点ではリージョンまでしか指定できないのでこの形に
インターネットゲートウェイ
本ではインターネットゲートウェイを作成して、VPC へアタッチしているが、GCP だとVPC 作成時に自動で作成されて、削除することもできないらしい
なので VPC とサブネットを作成すれば、AWS のようにインターネットゲートウェイを作成しなくても、サブネット内の VM はインターネットと通信することができる
(VM が内部 IP しか持ってなかったりしたら話は別)
AWS の方でもそうだけど、インターネットゲートウェイはそんなに頻繁にいじる場所ではなさそう
NAT ゲートウェイ
インターネットゲートウェイは、VPC で作成されたネットワークとインターネットとの間の通信を行うのが役割で、
このとき VPC の中に作成されたリソース(VM など)は外部と通信するためにはパブリックな IP を持っている必要がある
しかし、パブリックな IP を持つということは、インターネットに直接公開されている状態となるため、サブネットを公開と非公開にわけた意味がなくなってしまう
そこで Cloud NAT を使って、インターネットには出ていけるが、インターネットからはアクセスさせないという構成を実現する
(外部 IP を持たないインスタンスがインターネットへアクセスするために利用するもの)
なお、ここでは本に従って NAT はパブリックなサブネットに対して作成するが、プライベートサブネットに直接つける例もある
ルートでプライベートサブネット -> パブリックサブネット -> インターネットという通信ができるから、極力プライベートサブネットにはアタッチしないとかそんなイメージだろうか？
この辺り GCP ではどうすればいいのかまだわからないので、一旦本に倣って進めてみて、通信できないようならプライベートサブネットにつけてみようと思う
(ここの NAT を使った通信の条件を見ると、プライベートなサブネットに紐づけないとダメそうな雰囲気があるが)
と言うことで以下のように作成した
- ゲートウェイの名前
- 適当に
- NAT タイプ
- 公開
- Cloud Router の選択
- ネットワークは作成した VPC を選択
- リージョンは asia-northeast1 を選択
- 最後に Cloud Router を選ぶが、まだ Router は作っていないので、「新しいルーターを作成」を選ぶ
- するとモーダルが出てくるので、名前だけ入れて作成した
- Cloud NAT マッピング
- すべてのサブネットではなく、パブリックなサブネットだけを指定したいので、「カスタム」を選択する
- パブリックサブネットを選択して、IP 範囲は「すべて」を選ぶ
- Cloud NAT IP アドレス
- 自動
- ネットワークサービスティア
NAT を通るトラフィックがなければ料金は発生しないので、作りっぱなしでも大丈夫
セキュリティグループ
本では NAT の次にセキュリティグループの作成を行なっているが、その前に VM を色々置いてみて通信できるかどうかの確認を先にやりたい
ということで今はスキップして後で戻ってくることにする
(お金かかるから VM の通信試験の後は全部の VM を落とすので多分大丈夫)
ここまでの構成図
雑に iPad で手書きした構成図を貼っておく
ということで第 4 章は終わり、第 5 章へ続く