はじめに
当記事は、「Google Cloud のインフラストラクチャ構成のベスト プラクティスを一挙に紹介」についての紹介セッションレポートです。
紹介されていた中で私の印象に残った部分を中心に記載していきます。
VPC について
VPC は理由があってわけるのであれば問題はないですが、わけたい理由がなければ、VPC は1個から始めてみるのがおすすめとのことでした。
インフラと開発で責任分離したいような場合、共有 VPC で開始するのは良いとのことです。
以下画像のように、アプリケーション側とインフラ側で責務を分離した形で構成することが可能になり、こういった管理を明確にして構築したいような場合、便利な構成と感じました。
VPC 間の接続について
構成としてハブ＆スポークで必要なVPC間をピアリングでつなぐというやり方が一般的でしたが、 Network Connectivity Center で VPC 間をハブする Google Cloud プロジェクトを準備して、それを起点に、各プロジェクトだったり、必要な VPC と接続し構成する方法も可能になり、こちらによりシンプルな構成が可能になるとのことです。
以下は Cloud Interconnect を利用し、更にリージョンもまたいだ状態で利用した場合の構成ですが、これが Network Connectivity Center がなかったら、、と思うとかなり煩雑な構成になったかと思います。
Firewall について
1つ1つのFirewall Rule を利用する以前のような Firewall 制御ではなく、Cloud Firewall Policy を利用することを推奨しているとのことです。
同一ルールを再利用する場合には、1つのポリシーを複数の VPC で利用することも可能ですし、組織内のフォルダ単位でポリシーを適用できるため、フォルダ単位で Firewall Policy を制御することも可能になります。それにより、不要な許可ルールを勝手に登録することなく、制御することも可能になるとのことです。
組織を利用して、複数プロジェクトを組んでいるようなケースでは活用するにあたり、効率的でありかなり有用な機能だと感じました。
Cloud NGFW
IPS は パロアルトネットワークス社のマネージドルールを利用しており、最新のルールを利用することができ、利用するには許可ルールのパス通信先を IPS へ向けるだけで利用できるとのことです。
アプライアンスなどの IPS 入れる場合には、ルーティング変更などが必要ですが、それが不要となり、容易に組み込めるのが良い点だと感じました。
VPC 内各種サービス
ハイブリッド NAT
ハブ&スポークや Inter Connect の構成において、IP アドレスが重複する、というようなこともあるかと思いますが、ソース NAT で IP アドレスを変換する仕組みがあるため、それを行う前提で、IP アドレスが重複している VPC 同士を接続することも可能となります。こちらプレビュー機能となります。
ハイブリッドサブネット
同じ IP アドレスを利用して、段階的にインスタンスを移行することが可能な機能になったとのことです。
これから Inter Connect 越しに接続されたプロジェクトへ移行するような場合、とても魅力的な機能であり、余計な障害ポイントを防ぐことができる機能だと感じました。
Private Service Connect
図内のピアリングしていない方の線が対象となります。当該機能を使うとサービスアタッチメントを設けて、他 VPC にあるサービスを利用することが可能になります。
以前までは対応サービスが少ない状況でしたが、徐々に対象が増えつつあり、 VPC 同士や NW を接続しよう、と考える前に、Private Service Connect を利用して接続できないか、をまず始めに検討することで、必要なサービスのみに、必要な人がアクセスする仕組みになり、煩雑性も少なくなるとのことでした。
まとめ
自分が気になった機能を中心にセッションで紹介された機能とポイントについて纏めてみました。
自分はインフラ構築時に Private Service Connect は使えるとシンプルな構成になると考えており、推している機能という紹介もあったので、これから積極的に活用できるよう、制限事項等把握し、進めていきたいと感じました。
インフラ面でも色々とアップデートが多いので、これからも失わないように、キャッチアップしていきたいと思います。
