Google App Engine for PHP ＋ WordPressの構成パターン

Google App Engineの環境に対してWordPressをインストールしてサイトの公開を行う場合には、
一般的には１つのアプリケーション内のAPIですべてを賄う構成が普通です。
通常はその構成で何ら問題はないのですが、
自身でプログラムを記述したりしている場合には、
共通のテーブルを参照したりといったことをしたい場合もあります。
共通のファイルを参照したい場合もあるでしょう。
そんな時には、Google App EngineにWordPressを配置する構成を変えるといいでしょう。

Google App Engine for PHP ＋ WordPressの構成パターン

Google App Engineでは１つのアプリケーション単位で、

課金情報の登録有無、APIのON/OFFを個別に設定することができます。
１アカウント内には25アプリケーションまで利用することができます。

こうした仕組みの中で、一般的な構成から少し変わった構成までを順にご紹介します。

１アプリケーション内実装

１アプリケーション内で課金情報の有効化、
Cloud SQL API有効、Cloud Storage有効を設定して実装する方法です。

この構成を図示すると以下のようになります。

WordPressの通常の構成配置

以下の導入方法ではこの実装方法を元にご紹介しています。

１アプリケーション実装の複数配置

上記の１つのアプリケーション構成を複数配置する構成で、
それぞれが独立し、影響を受けない構成で複数配置する例です。

この構成を図示すると以下のようになります。

通常WordPress配置・AppEngine

これは上記の１アプリケーション構成と変わりはありませんが、
アプリケーションごとに課金登録、API有効化を行っていく形になります。

この構成は１つのアプリケーションを導入する手順を複数回、行うというだけになります。

複数アプリケーションCloudSQL共用構成

１つのアプリケーション構成を複数配置する構成で、
Cloud SQLデータベースのインスタンスを共用するという構成です。

この構成ではCloud SQLを共用インスタンスとして利用します。

CloudSQL共用WordPress配置・AppEngine

この構成ではCloud SQLの接続文字列が同じインスタンスを参照させることができ、
データベースでインストール先を分ける形が取れます。

通常WordPressの標準関数では別データベースの参照はあまりありませんが、
自身で独自関数やデータの参照などをしている場合には、
インスタンスが同じであった方が便利な場合もあるでしょう。

マスターテーブルなどを利用する場合などに便利かもしれません。

この構成を利用する場合にはCloudSQL API の有効化・課金は、
参照される側のアプリケーションのみで設定すれば利用することができます。

結果、データの総量は変わらないと思いますので、
コスト削減策としてはメリットはないと思いますが、ケースによっては便利かもしれません。

この場合、以下でご紹介するような設定が必要になります。

複数アプリケーションCloud Storage(バケット)共用構成

１つのアプリケーション構成を複数配置する構成で、
Cloud Storageのバケット領域を共用するという構成です。

この構成ではCloud Storage内に作成されるバケットを、
同じアプリケーション内に配置することになります。

この構成を図示すると以下のようになります。

CloudStorage共用WordPress配置・AppEngine

この例ではバケット内に作成したフォルダを分けて利用する例を図示していますが、
バケットを新しく作成し、アプリケーションごとにバケットを分けることも可能です。

この構成とした場合、Cloud Storage内で共通のデータを保管する場合に
それぞれのバケットに同じデータを保管せずに、
そのアプリケーションでも共通のフォルダを参照したりといった利用方法が考えられます。

この場合、以下でご紹介するような設定が必要になります。

複数アプリケーションCloudSQL・Cloud Storage共用構成

そして最後がCloud SQL、Cloud Storageを１つのアプリケーションで有効化し、
他のアプリケーションではそれを参照する構成です。

CloudSQL/CloudStorage共用WordPress配置・AppEngine

この構成ではCloud SQLのインスタンスも１つ有効な状態で共用します。
Cloud Storageの領域も共用します。

Application BではAPIの利用がすべてApplication Aによって賄われることから、
ふと、課金情報の登録が不要であるかのように感じます。

実際、プログラムからアクセスした場合は不明ですが、
少なくともWordPressでメディアフォルダをApplication Aのバケット内に構成すると、
Application Bからバケットにアクセスする際に、Socket API を介して接続されるようです。

Socket APIの利用自体は課金対象ではないのですが、
利用には課金情報の登録が必要になります。

結果、Application BではCloud SQL API, Cloud Storage APIを
有効化する必要はありませんが、課金情報は登録し、
無料範囲内で利用するという形になります。

この構成は、Cloud SQL共用＋Cloud Storage共用の両方を設定することで利用できます。

さいごに

どの構成で利用するのが自身の用途に合っているかはわかりませんが、
こうした形での各サービスの利用ができるということで、ご紹介させて頂きました。

何かのお役に立ちますと幸いです。

Google™はGoogle Inc. の登録商標（第４４７８９６３号及び第４９０６０１６号）です。
GoogleロゴはGoogle Inc. の国際登録商標です。
国際登録番号：８８１００６及び９２６０５２及び１０８６２９９及び１０９１９９０及び１１４５９３４