はじめに
2023/1/13にオーケー株式会社様における会員カードアプリの導入事例が公開されました。
アイレットはデザインから開発、そしてインフラ構築・運用までをご支援させていただきました。
今回はインフラ構築の裏側について解説する記事となります。
複数回に分けて順次公開予定となっており、前回の構成解説に引き続き、今回より各コンポーネントに焦点を当てた内容を記載していく予定となっており、今回はインフラのNWに関する内容となります。
前回の記事（構成について）
概要
焦点を当てる内容としては赤枠箇所の以下となります。
– VPC
– Serverless VPC Access connector
– プライベートサービス接続
– Cloud Armor
– Cloud Load Balancer
各コンポーネントの詳細
VPC
DB管理で利用しているGCEを配置しているVPC(GCEのVPC)と、Cloud SQL、MemoryStoreを配置したプライベートなVPC(以降DBのVPCと記載)に分かれます。
GÇEのVPCにて「プライベートサービス接続」を利用し、DBのVPCへのアクセスが可能となっております。
構成図イメージ
上の図ですと、下のVPCがGCEのVPCで、上のVPC(Google管理)と記載されたものが、下のVPCの設定にてプライベートサービス接続を利用したことにより、作成されたVPCとなります。
接続形式
今回の構成では主に以下の方法で接続しております。
– GCEからの接続
– VPC内にある「Serverless VPC Access connector」経由でCloud Runからの接続
「プライベートサービス接続」、「Serverless VPC Access connector」については以下で少し詳細に記載します。
プライベートサービス接続
プライベートサービス接続は設定しているVPC(今回だとGCEのVPC)とは異なるVPCとして、Google Cloudのマネージドサービスに対して、プライベートIP接続を提供するものです。
これを利用することでCloud SQL及びMemoryStoreに対して、プライベートIPでのアクセスが可能になります。
なお、ユーザ側が自由にこのDBのVPC内にGCEなどマネージドサービスではないものを作成することはできません。
サポート対象サービスは以下に記載されております。
Serverless VPC Access connector
今回の構成でフロントエンドにCloud Runを利用している関係上、Serverless VPC Access connectorを利用しております。
Serverless VPC Access connectorは、今回利用したCloud Runや、Cloud Functions、App EngineなどのサーバーレスサービスがVPCへ接続するために設けられるものです。
今回のようにCloud RunがCloud SQLに対してプライベートIPアドレスでアクセスしたい場合も可能ですが、もっと多い利用パターンとしては、
サーバーレスサービスがインターネットアクセスする際に、当該機能によりVPCアクセス行い、Cloud NATによってIPアドレスを固定することも可能です。
Cloud Load Balancer
当該案件ではグローバル外部HTTPSロードバランサーを利用し、Cloud StorageとCloud Runをターゲット指定しています。
Cloud Storageをバックエンドバケットとして指定し静的コンテンツを提供し、Cloud RunをサーバーレスNEGとしてコンテンツ提供しています。
Cloud Runのみや、Cloud Storageのみでも、個別にドメインを付与し、サービス提供を行うことも不可ではございませんが、
Cloud ArmorはLoad Balancerのターゲットに対する保護をするため、それを利用したウェブアクセスを介した攻撃に対するセキュリティ対策を実施したかったのと、Load Balancerを利用したルーティングにより、アクセス先を振分けたかったためです。
サーバーレスNEG
サーバーレスNEGはサーバーレスサービスのCloud Functions、App Engine、Cloud RunをLoad Balancerのターゲットとして指定可能なグループです。
これらはリージョン単位で纏める必要があり、他リージョンにまたぐ構成を行う場合には、その分のグループ作成が必要です。
Cloud Armor
基本的には事前構成されたWAFルールを使用し、必要なアクセスが遮断されないことを確認のうえ、適用し、サービス運用に影響がないWAF設定としております。
考慮点及びNWに関するコメント
考慮点
Cloud SQLやMemoryStoreはデフォルトはパブリック利用となりますが、要件定義内でプライベート利用を想定し、それを意識したNW構成としており、両サービスに対するアクセス制限も設定しております。
コメント
このNW観点においては、以下2点、アイレット内の連携により、スムースな進行ができました。
– Cloud RunからCloud SQLへの接続は手段が複数あるため、プライベートでのCloud SQL構築であることを開発チームと事前に認識合わせを行った。
– Cloud Storageでの静的コンテンツ利用は、進行中に新たに発生した要件でしたが、進行に支障なく構成変更が行えた。
当該記事はインフラ担当した亀田、齋藤(寛隆)にて記載しております。
