レンタルサーバー選びの迷いを解決!全力サポートします

Google or AdMax Promotion (srv)

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

      2015/05/02

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

なお、ここでご紹介する構成はあくまでも私個人が設置して、
設置可能であったパターンとしてご紹介しています。
Google .IncならびにWordPress Foundationによって、
何らかの推奨・承認を受けるものではありません。実装は自己責任でお願いします。

 

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

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

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

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

 

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

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

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

06_WordPressの通常の構成配置

WordPressの通常の構成配置

 

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

 

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

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

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

01_通常WordPress配置・AppEngine

通常WordPress配置・AppEngine

 

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

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

 

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

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

 

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

02_CloudSQL共用WordPress配置・AppEngine

CloudSQL共用WordPress配置・AppEngine

 

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

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

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

 

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

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

 

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

 

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

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

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

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

03_CloudStorage共用WordPress配置・AppEngine

CloudStorage共用WordPress配置・AppEngine

 

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

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

 

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

 

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

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

04_CloudSQL/CloudStorage共用WordPress配置・AppEngine

CloudSQL/CloudStorage共用WordPress配置・AppEngine

 

この構成ではCloud SQLのインスタンスも1つ有効な状態で共用します。
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 or AdMax Promotion (srvpos)

さいごに

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

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

 


AdMax Promotion

 - Google App Engine

コンテンツナビ
すべて展開 | すべて省略

AdMax Promotion

カテゴリ
すべて展開 | すべて省略

QRコードからもこのURLを開けます。


Comment

  1. […] Google App Engine for PHP + WordPressの構成パターン […]

  関連記事

eye_google
Google App Engineにデプロイしたアプリが反映されない場合の対処法

Google App Engineに対してアプリケーションをデプロイしてから、 …

eye_google
JetPackをGoogle App Engineで有効化してエラーの場合の対処法

Google App Engine上にWordPressをインストールして、 J …

eye_google
Google App Engineでプラグイン新規追加画面がエラーの場合の対処法

Google App Engineに対してWordPressをインストールして、 …

eye_google
Google App Engineでパスに「/index.php/」が挿入される場合

Google App Engineに対してWordPressをインストールして、 …