めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

OpenStackユーザーのためのGoogle Cloud Platform入門（パート４）

前置き

これは、GCPの公式文書ではありません。公式ドキュメントについては、公式ホームページを参照ください。

・Google Cloud Platform

実際に試してみたい方は、60日の無料トライアルをお試しください。（クレジットカードの登録が必要ですが、トライアル終了後は明示的に課金設定を行わない限り、勝手に課金されることはありませんので、ご安心ください。）

cloud.google.com

本記事のパート3はこちらです。

enakai00.hatenablog.com

パート4では、Web3層アプリケーションを例として、どのようなコンポーネントを組み合わせてシステムを作るのかを比較してみます。

OpenStackによる構成例

「OpenStackクラウドインテグレーション」では、次のような構成例が紹介されています。

ロードバランサー、Webサーバー、Webアプリケーションサーバー、DBサーバーからなる、典型的なWeb３層アプリケーションを構築するもので、複数のデータセンターを利用して、DR構成を実現しています。上記の書籍にしたがって、この環境を構築した場合、次のようなコンポーネントが利用されることになります。

・ネットワーク（Neutron）
・VMインスタンス（Nova）
・セキュリティグループ（Nova）
・Cinderボリューム（Cinder）
・オブジェクトストレージ（Swfit）

これらのコンポーネントの構成を順番に説明していきます。

なお、上記の書籍では、1つのリージョンの複数のAvailability Zone（以下、ゾーン）を用いてDRを実現する想定になっていますが、パート１で説明したように、現在のOpenStackでは、地理的に離れた場所で複数ゾーンを構成するのはそれほど簡単ではありません。ここでは、複数のリージョンを用いて、DRを実現する想定とします。（OpenStackの場合、同一リージョンのゾーンは、コントローラーノードを共有している点に注意してください。）日本国内の２箇所のデータセンターに、別リージョンとして、独立したクラスターを構成しているものとしてください。

ネットワーク

前述の書籍では物理ネットワークをクラウド上で再現するために、複数のサブネットを作成していますが、ここでは、単一のサブネットを用いて、セキュリティグループでインスタンス間の通信を制限することにします。この場合、それぞれのリージョンに単一のサブネットを用意するだけなので、仮想ネットワークの構成はシンプルになります。

VMインスタンス

上記の書籍では、ロードバランサー、Webサーバー、Webアプリケーションサーバー、DBサーバーをすべてVMインスタンスとして導入しています。ロードバランサーについては、LBaaS（Load Balancer as a Service）の機能を利用することも可能ですが、オープンソースとして標準提供されるプラグインはサンプル実装の位置づけとなっており、本格的に利用するにはサードパーティーの商用プラグインが必要となります。

セキュリティグループ

OpenStackのセキュリティグループでは、サーバーの役割ごとにセキュリティグループを定義して、受信を許可するパケットを指定します。パケットの送信元をセキュリティグループで指定することもできるので、全体として、次のようなセキュリティグループを定義することになります。

Security Group Source Protocol
load-balancer any HTTP/HTTPS
Management Subnet SSH
web-server load-balancer HTTPS
Management Subnet SSH
web-application web-server TCP8080
Management Subnet SSH
database web-application MYSQL
Management Subnet SSH

「Management Subnet」は、システム管理者が外部からインスタンスにSSHログインする際の接続元ネットワークのサブネットレンジを与えます。また、クライアントとのSSL通信はロードバランサーでターミネートして、Webサーバーとの通信にはHTTPS、Webアプリケーションサーバーとの通信にはTCP8080を使用します。データベースには、MySQLを使用するものとしています。

この上で、それぞれのインスタンスに対して、次のようにセキュリティグループを割り当てます。

Instance Security Group
Load Balancer load-balancer
Web Server web-server
Web Application Server web-application
Database Server database
Cinderボリューム

VMインスタンスの接続するディスクには、Ephemeral DiskとCinderボリュームがありますが、永続保存が必要なデータには、Cinderボリュームを使用する必要があります。今回の構成では、DBサーバーのデータ保存領域には、Cinderボリュームの使用が必須となります。

オブジェクトストレージ

DBサーバーのデータバックアップをオブジェクトストレージに取得します。

DRの切り替え手順について

DRでリージョンを切り替える際は、オブジェクトストレージに取得したデータベースのバックアップを切り替え先のDBサーバーにリストアします。この前提として、オブジェクトストレージ自体が複数のリージョンにレプリケーションされる構成で、データセンター障害に対する冗長性を持っている必要があります。

この他には、ゾーン間でデータベースのレプリケーションを行うという方法もありますが、地理的に離れた場所の場合、ネットワーク帯域の不足に伴う問題が発生する可能性もあるので注意が必要です。

また、外部からアクセスするIPアドレスについては、リージョン間で同一のグローバルIPを使用することができないため、IPアドレスの変更を外部のクライアントに意識させないためには、DDNSを利用して、DNSに登録するIPアドレスを変更するなどの作業が必要となります。

GCPによる構成例

GCPでは、データベースとロードバランサーについては、マネージドサービスとして機能が提供されていますので、VMインスタンスとして機能を用意する必要はありません。また、GCPが提供するネットワークは、同一のリージョンであれば、ゾーン間においても、ゾーン内と同等のネットワーク帯域が提供されています。そのため、単一リージョンにおける複数のゾーンを利用することで、比較的簡単に独立したFailure zone（故障域）にまたがる冗長性を実現することができます。これらの点に注意すると、次のようなコンポーネントを利用して、前述のOpenStackの場合と同等の環境を構築することが可能です。

全体像を先に示すと、次のようになります。


ネットワーク

GCPのネットワークでは、複数ゾーンにまたがったサブネットが構成できるので、使用するリージョンに単一のサブネットを作成します。

VMインスタンス

WebサーバーとWebアプリケーションサーバーをVMインスタンスとして構築します。

ファイアウォールルール

GCPのファイアウォールルールでは、インスタンスに付与したタグを用いて送信先を指定します。送信元については、サブネットレンジ、もしくは、タグでの指定が可能ですので、次のようなルールを用意することになります。

Source Destination Protocol
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP8080
Management Subnet web-server, web-application SSH

「130.211.0.0/22」はロードバランサーがWebサーバーにアクセスする際の送信元のサブネットレンジです。また、「Management Subnet」は、システム管理者が外部からインスタンスにSSHログインする際の接続元ネットワークのサブネットレンジを与えます。「web-server」と「web-application」は、WebサーバーとWebアプリケーションサーバーのインスタンスに付与するタグになります。セキュリティグループのように、インスタンスにルールを割り当てるのではなく、インスタンスには、単純にタグを付与するだけでよい点に注意してください。

Webアプリケーションサーバーからデータベースへの接続については、後述のCloud SQLの設定を用いて、接続を許可するIPアドレスを指定します。

HTTP(S)ロードバランサー

GCPが提供するロードバランサーは、単一のグローバルIPアドレス（VIP）で複数のリージョン、ゾーンに負荷分散することが可能です。この後で説明するように、複数のゾーンから同一のデータベースを参照することもできるので、両方のゾーンを同時に使用する構成で、複数データセンターを用いた冗長構成が実現できます。

Cloud SQL

Cloud SQLは、MySQLのマネージドサービスで、レプリケーションによる複数ゾーンにまたがった冗長構成を取ることが可能です。定期的なバックアップ処理、あるいは、障害時のフェイルオーバー処理も自動化されています。また、前述のように、GCPのネットワークでは、ゾーン間においてもゾーン内と同等のネットワーク帯域が確保されているので、それぞれのゾーンのWebアプリケーションサーバーから同一のデータベースにアクセスすることも問題ありません。

DRの切り替え手順について

上記で説明したように、両方のゾーンを同時に使用する構成をとることにより、データセンター障害時に特別な切り替え手順が発生することはありません。ロードバランサーが単一のグローバルIPアドレス（VIP）を提供するため、クライアントからのアクセス先が変わることもありません。

この例からも分かるように、Compute Engineとマネージドサービスを適切に組み合わせることで、シンプルで可用性の高い環境を構築することが可能になります。