はじめに
2024年3月4日にMIRARTHホールディングス株式会社様（以下、MIRARTH様）のアイレットによるGoogle Cloud導入支援の事例を公開しました。
この事例では顧客向けのGoogle Cloudに関するオーダーメイドのレクチャーとBare Metal Solution（以下、BMS）のPoCを実施しました。
本記事はPoCで構築したBMS環境のインフラ構成を解説します。
本事例のレクチャー編については以下記事をご覧下さい。
背景
上記の導入事例記事にもありますが、MIRARTH様ではオンプレミスで運用をしていたWebアプリやOracleDBをGoogle Cloudに移行することを検討されていました。
PoCではBMS環境を構築し、各サービスの概要からインフラ構成、構築手順をそれぞれご提供しました。
インフラ構成図
図中の左側がGoogle Cloud環境、右側がBMS環境となっています。
使用サービス
- Bare Metal Solution
- Partner Interconnect（BMSで利用）
- VPCネットワーク
- NAT Gateway
- Cloud Router
- Cloud Firewall
- Cloud DNS
- Compute Engine（GCE）
BMSについて
正式名称をBare Metal Solutionといい、専用のベアメタルサーバをリージョンごとに提供しているサービスです。インフラやネットワーク、セキュリティ、モニタリング機能などすべてのGoogle Cloudサービスにアクセスできるベアメタル環境をGoogle Cloud管理下のもと運用可能なサービスとなっています。
Oracleをはじめとしたライセンスが必要なサービスを利用する場合などでは、他のテナントと共有されていない物理的なマシンが求められるケースがあり、そのような場合にBMSが選択肢の一つとなります。
IaaSとしてインフラ環境のみ提供されているため、ハードウェア以外のOS以上のレイヤは利用者側が設定することができます。
本構成における主要サービスの解説
Bare Metal Solution
BMS環境はGCのリージョン内ではなく拡張された施設に存在しているためRegion Extensionとして記載しています。
BMSはクライアントネットワークとプライベートネットワークという概念があります。
- クライアントネットワーク：Partner Interconnect経由でGoogle Cloud環境と接続可能なネットワーク。
- プライベートネットワーク：ベアメタルサーバ間で接続するネットワーク。プライベートネットワークからVPCへの接続は不可。
BMSサーバ上ではOracle Linux8が起動しており、その中でOLVMが起動し、VMを作成しています。そしてWindowsサーバ上にOracleDBが起動するという構成になっています。
VPCネットワーク
VPCとクライアントネットワーク間はPartner Interconnect経由で接続を行います。
VPCからVLANアタッチメントを作成して、BMSのサーバ注文時にネットワークを接続先として設定しています。
VPCはアタッチメント経由でCloud RouterとBMS間でのBGPピアを確立し、これにより疎通することができます。
NAT Gateway
BMSからインターネットに接続する際はグローバルIPやNAT Gatewayがないため、NAT用GCEを経由してインターネットに接続する形となっています。
Cloud Firewall
ファイアウォールルールによりクライアントネットワークのCIDRからの通信を許可し通信可能となっています。
Cloud Router
Cloud Router経由で拡張したBMSのクライアントネットワークのCIDRはVPCのルートにBGP経由で自動で登録されるようになっています。
Cloud Router側からBMSに対して、BMSのデフォルトルートをVPCに向けることで宛先不明な通信はVPC経由で通信するようにアドバタイズできます。
VPC内にはインターネットGWやNAT Gatewayはありますが、VPC外からの通信には適用されないようになっています。そのためBMSネットワークから一度Parter Interconnect経由でGCEに通信し、そこからインターネットに出る形となっています。
Cloud DNS
今回のBMSにはDNSサーバがないためベアメタルのホストOSに対して、VPCに存在するDNSサーバがIPを指定することによって、Partner Interconnect経由でDNSサーバに接続させて名前解決が可能となります。
Compute Engine(GCE)
本構成では3つのGCEをセットアップしており、以下は各GCEの使い分けとなります。
| 種別 | 用途 | 補足 |
| NAT用GCE | BMS環境からインターネット接続する。 | BMSからVPC内のインターネットGatewayは利用できないためGCEを経由させる。 |
| 踏み台用GCE | OLVM管理ポータルへのアクセスやBMSホストOSへのSSHアクセス、OLVM上のOracleDBへのアクセスを行う。 | このVMにはインターネット経由で通信し、RDPを使用して接続する。 |
| OLVM用GCE | OLVM管理ポータルを稼働させる。 | OLVM自体がホストの他にOLVMを管理するエンジンが必要となる。 |
推しポイント
外部への通信制御
VPCルートで特定のネットワークタグを持たないインスタンスはNAT Gatewayから出るようなルートの設定を適用し、これをデフォルトのNAT Gatewayを使って出る通信より優先度を低くすることで、BMSからの通信は優先度の低いNAT用GCEを通ってインターネットに出るようになっています。
内部への通信制御
BMS環境ではグローバルIPがないため、外から直接アクセスすることはできず、VPCを経由したPartner Interconnectアクセスとなっています。
OracleDBへのアクセスもプライベートIP経由での通信となっており、外部からVPCを通って接続することが難しく、Partner Interconnect経由でプライベートにアクセスする必要があるため、アクセス用のGCEを作成しています。
アプリケーション層とデータ層の分離
本構成では3層アーキテクチャを取り入れ、アプリケーション層とデータ層を分離させています。
- ウェブ層：フロントエンドやプレゼンテーション階層、UIなど。（今回は構築なし）
- アプリケーション層：バックエンドやデータの処理を行う層。
- データ層：データベース、アプリケーションに関連づけられたデータの保存と管理を行う層。
アプリケーション層のWebサーバではGCEを利用することでVM自体の管理をGoogle Cloudに委任することができ運用コストを削減可能な上、クラウドならではのスケーリングなどのメリットを受けることができます。
ただし、データ層からアプリケーション層にレスポンスされるデータはPartner Interconnectを経由するため、帯域幅が小さいとデータ量次第でボトルネックとなる可能性があるため注意が必要です。
またアプリケーション層はクラウドネイティブ化されているため、今後クラウドに完全シフトする際にはデータ層の移行のみで対応可能となります。
考慮事項
ネットワークの制御とセキュリティについて
BMSからVPCに入ってくる通信はVPCのファイアウォールルールで制御しているが、BMS側に入ってくる通信についてはベアメタル上のホストOSにてファイアウォールを設定するか、アプライアンスの製品を導入する必要があります。
BMS環境でのOLVMのセットアップ
OLVM自体がホストの他にOLVMを管理するエンジンを必要とし、ホストと同じ環境か別の環境に分けることができます。別の環境に分ける場合はスタンドアロン型、同じホスト上に立てる場合は自己ホスト型となります。
自己ホスト型の場合はOLVMエンジンが乗っている物理エンジンが停止してしまうとOLVM自体にアクセスできなくなるため、GCEにOLVMのみをセットアップし、OLVM管理ポータルに対してOLVM実行ホストとして登録しています。
BMSにおける冗長化について
ベアメタルサーバの再起動には約30分から60分かかるため、障害対応時にサーバ自体の再起動を行うとダウンタイムが発生してしまいます。そのため、複数のベアメタルサーバやOracleDB用のVMを用意して冗長化する必要があります。
OracleDBの冗長化についてはRACやOracle Data Guard、ASMなどOracleの機能を使って冗長化します。
さいごに
最後までご覧いただきありがとうございます。
今回は国内でも事例の少ないBMSを利用したインフラ構成について解説をさせていただきました。オンプレミスにてライセンスを保有し、システムを稼働させているためになかなかクラウドに移行できないというケースも少なくないかと思います。こうした場合にBMSはオンプレミスからGoogle Cloudへ環境を移行させるための一つの選択肢となり得ると考えております。
こちらの記事が少しでも皆様のお役に立てると幸いです。
