rakumoコンサルティング部 Tech Blog

GCPの構築ノウハウをそろりと公開 コンサル部によるテックブログ

構築済のWordPressをGoogle App Engineに移行する(3)

rakumoコンサルティング部の小山(@koyhoge)です。

既存のWordPressGCPに移行する解説記事の3回目です。

前回の作業で GCP 環境のセットアップが終わりましたので、次に Google App Engine (GAE) 上に構築する WordPress の準備をしていきます。

WPonGAE のセットアップ

第1回で紹介した「WordPress on App Engine Starter Project (WPonGAE) 」を使って GAE 上に WordPress を構築していきます。

ここで一つ注意点があって、GAE の PHP は通常の環境 (Standard Environment) では PHP 5.5 で動作します。PHP 5.6 以上が必要な WordPress プラグインを使用している場合はこのやり方ではうまくいきません。その場合は Flexible Environment を用いてカスタムランタイムを利用することになりますが、この記事ではそのやり方については取り上げません。

GitHub から取得

まずは WPonGAE のソース一式を GitHub より取得します。これには git コマンドを使います。コマンドラインが苦手な方は GitHub Desktop などのGUI環境でも良いでしょう。

 git clone --recursive https://github.com/googlearchive/appengine-php-wordpress-starter-project.git

すると「appengine-php-wordpress-starter-project」という名前のディレクトリができます。以下にはいくつかのファイルとディレクトリがあります。

appengine-php-wordpress-starter-project_build_linux_mac.zip
appengine-php-wordpress-starter-project_windows.zip
appengine-wordpress-plugin/
app.yaml
batcache/
cron.yaml
databasesetup.sql
move_files_after_editing.bat
move_files_after_editing.sh
php.ini
README.md
wordpress/
wp-config.php
wp-memcache/

このディレクトリをGAEへの配布元として作業していきます。

$ cd appengine-php-wordpress-starter-project

WordPress の置き換え

まずは現在動作している WordPressディレクトリをコピーしてきて、WPonGAE の wordpress と入れ替えます。こうすることで既存環境にインストールされている各種プラグインも、そのまま GAE 上で動作するようになります。

$ rm -rf wordpress
$ cp -r original_wordpress ./wordpress

設定ファイルの変更

app.yaml の変更

まずは GAE の設定ファイルである app.yaml を変更します。先頭の application と version 行を削除します。

-application: your-project-id
-version: wpfromstarterproject
  runtime: php55
 api_version: 1

参考diff

これは WPonGAE が作られた後で、GAE 側の仕様が変わったことによります。現在では application と version は環境から渡すことになっており、app.yaml に記述することは推奨されません。

あと git clone した環境だと、.git/ ディレクトリに不要な大きいファイルがあるので、これを無視するように skip_files に追加します。

skip_files:
- ^(.*/)?\.zip$
- ^(.*/)?\.bat$
- ^(.*/)?\.sh$
- ^(.*/)?\.md$
- \.git/

wp-config.php の変更

次に WordPress の実行設定である wp-config.php を変更します。

WPonGAE に用意されている wp-config.php をベースにしても良いですが、これは WordPress 3.X のものであまりに古いので、既存環境の wp-config.php に変更を追加していくことにします。そのためまずは WPonGAE の wp-config.php を wp-config-gae.php にリネームして、既存の wp-config.php をカレントディレクトリにコピーします。

$ mv wp-config.php wp-config-gae.php
$ cp wordpress/wp-config.php .

wp-config.php をエディタで開いて修正を加えていきます。

まずはデータベースの設定から。現在の設定はおそらく以下のようになっていると思います。(4.9.1-ja)

/** WordPress のためのデータベース名 */
define('DB_NAME', 'my_wordpress_db');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'my_wordpress_user');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'xxxxxxxx');

/** MySQL のホスト名 */
define('DB_HOST', 'localhost');

その部分をこうします。

if (isset($_SERVER['SERVER_SOFTWARE']) &&
    strpos($_SERVER['SERVER_SOFTWARE'],'Google App Engine') !== false) {
    /** The name of the Cloud SQL database for WordPress */
    define('DB_NAME', 'my_wordpress_db');
    /** Live environment Cloud SQL login and SITE_URL info */
    /** Note that from App Engine, the password is not required, so leave i\
        t blank here */
    define('DB_HOST', 'localhost:/cloudsql/wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql');
    define('DB_USER', 'my_wordpress_user');
    define('DB_PASSWORD', 'xxxxxxxx');
} else {
    /** The name of the local database for WordPress */
    define('DB_NAME', 'my_wordpress_db');
    /** Local environment MySQL login info */
    define('DB_HOST', 'localhost:/cloudsql/wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql');
    define('DB_USER', 'my_wordpress_user');
    define('DB_PASSWORD', 'xxxxxxxx');
}

if 文の最初のブロックが GAE で動作する場合の設定で、else 以降のブロックがそれ以外の設定になっています。上記の例では、この後の都合で両者とも同じ設定値になっていますが、ローカルで動かしたときだけ DB 設定を変えたい等の場合は、下のブロックを変更して下さい。

DB_NAME, DB_USER, DB_PASSWORD は、それぞれご自身の環境のものに書き換えます。

GAE の場合の設定の以下の記述ですが、

    define('DB_HOST', 'localhost:/cloudsql/wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql');

これは * 実行マシンの * /cloudsql ディレクトリに存在する * 「wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql」 という名前のUNIXドメインソケット に接続するという意味になります。第1回目で作成した Cloud SQLの「インスタンス接続名」をここで使用します。

次に WordPress のサイト URLを、アクセスされた URL から自動設定するために以下を挿入します。

// Determine HTTP or HTTPS, then set WP_SITEURL and WP_HOME
if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVE\
R_PORT'] == 443) {
    $protocol_to_use = 'https://';
} else {
    $protocol_to_use = 'http://';
}
define( 'WP_SITEURL', $protocol_to_use . $_SERVER['HTTP_HOST']);
define( 'WP_HOME', $protocol_to_use . $_SERVER['HTTP_HOST']);

GAEには処理の定期実行の仕組みがありますので、WordPressによる cron の疑似実行は無効にします。

/**
 * Disable default wp-cron in favor of a real cron job
 */
define('DISABLE_WP_CRON', true);

WPonGAE に含まれる batcache プラグインのための設定を追加します。

// Required for batcache use
define('WP_CACHE', true);
// configures batcache
$batcache = [
    'seconds' => 0,
    'max_age' => 30 * 60, // 30 minutes
    'debug' => false
];

以上で wp-config.php の編集はおしまいです。

インストールスクリプトの実行

WPonGAE 用意されているスクリプト "move_files_after_editing.sh" を実行します。これは各種プラグインを ./wordpress 以下に移動します。

$ sh move_files_after_editing.sh

WordPress 側の準備はこれにて完了です。

Cloud SQL Proxy のインストール

Cloud SQLのデータベースに接続するには、以下の2つの方法があります。

  • 送信元IPアドレスによって承認する
  • cloud_sql_proxy コマンドを用いてトンネルを作成する

GAEの環境では、後者の cloud_sql_proxy 経由になりますので、手元でも同じ環境を作っておくほうが何かと便利でしょう。ということでローカルに Cloud SQL Proxy をインストールします。

Cloud SQL Proxy については以下の Google のページを参考にします。

https://cloud.google.com/sql/docs/mysql/connect-admin-proxy?hl=jacloud.google.com

Cloud SQL Administration APIを有効にする

以下のURLの管理画面から Cloud SQL Administration APIをプロジェクトに対して有効にします。

Cloud SQL Administration APIの有効化

プロキシをインストールする

cloud_sql_proxy のソースコードGitHub で公開されていますが、各種プラットフォーム毎のバイナリも用意されていますので、そちらを用います。今回は Linux 64ビット環境で用いますので以下のコマンドでダウンロードします。

$ wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
$ chmod +x cloud_sql_proxy

アプリケーション認証情報を取得

Cloud SQL Proxyは Cloud SQLに接続する際にGCPの認証を必要とします。このために専用のサービスアカウントを作成する方法もあります(上記Googleの解説ではそのやり方について説明しています)。今回は Cloud SDK の認証情報を使用する簡易な方法でいきます。

まずは gcloud コマンドで application-default の認証を行います。

$ gcloud auth application-default login
Go to the following link in your browser:

    https://accounts.google.com/o/oauth2/auth?<後略>

Enter verification code:

ブラウザが開く環境ならおそらく自動で認証画面が表示されるでしょう。リモートログインしている環境などブラウザを開けない状況では、上記のように認証用の URL が表示されるので、それをブラウザで開いて許可を行った結果、表示される認証コードを入力します。

認証許可ダイアログ 認証コードの表示

Enter verification code: XXXXXXXXXX

Credentials saved to file: [/home/koyama/.config/gcloud/application_default_credentials.json]

These credentials will be used by any library that requests
Application Default Credentials.

これにより割り当てられた認証情報用いて cloud_sql_proxy コマンドは Cloud SQL に接続できるようになります。

プロキシを起動

cloud_sql_proxy コマンドは、オプションにより TCP ソケットと UNIX ドメインソケットのどちらかを使用して接続を受け付けます。ここでは GAE の実行環境と同様に UNIX ドメインソケットを用います。

まずはソケットが置かれるディレクトリを作成します。これは GAE の環境に合わせて「/cloudsql」固定です。

$ sudo mkdir /cloudsql
$ sudo chmod 777 /cloudsql

作成したディレクトリを指定して cloud_sql_proxy コマンドを起動します。

$ cloud_sql_proxy -dir=/cloudsql &

現在有効な Cloud SQL インスタンスを調べて、そこに接続するソケットを自動的に /cloudsql に作成してくれます。

Cloud SQLにデータベースインスタンスを作成

第2回目で Cloud SQL の設定を行いましたが、ここにはまだ DB インスタンスが何もない状態ですので、これを作っていきます。

以下の設定で DB インスタンスを作成します。

  • ユーザ: my_wordpress_user
  • パスワード: xxxxxxxx
  • データベース名: my_wordpress_db

まずは cloud_sql_proxy 経由で Cloud SQLMySQL に接続します。<ROOT_PASSWORD> の部分は第2回の「Cloud SQLの設定」の時に生成したパスワードを使います。

$ mysql -u root -p<ROOT_PASSWORD> -S /cloudsql/wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 144326
Server version: 5.7.14-google-log (Google)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

無事に接続でき、mysql> プロンプトが表示されました。

まずは DB インスタンスを作成します。

mysql> create database my_wordpress_db;

次にユーザーを作成します。

mysql> create user my_wordpress_user;

作成したユーザに DB へのアクセス権限を与えます。

mysql> grant all on my_wordpress_db.* to my_wordpress_user@'%' identified by 'xxxxxxxx';

これで wp-config.php に記述した情報で、データベースにアクセスできるようになりました。

GAE へデプロイ

さて長くなりましたが、いよいよ GAE に WordPress をデプロイします。

$ gcloud app deploy
Services to deploy:

descriptor:      [/home/koyama/work/appengine-php-wordpress-starter-project/app.yaml]
source:          [/home/koyama/work/appengine-php-wordpress-starter-project]
target project:  [wp-on-gae-187408]
target service:  [default]
target version:  [20171212t084527]
target url:      [https://wp-on-gae-187408.appspot.com]


Do you want to continue (Y/n)?

プロンプトに「y」と入力すると、作業中のプログレスバーが徐々に伸びていき、問題がなければ無事にデプロイが完了します。

Do you want to continue (Y/n)?  y

Beginning deployment of service [default]...
Some files were skipped. Pass `--verbosity=info` to see which ones.
You may also view the gcloud log file, found at
[/home/koyama/.config/gcloud/logs/2017.12.12/08.45.25.627575.log].
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 1732 files to Google Cloud Storage             ═╣
╚════════════════════════════════════════════════════════════File upload done.
Updating service [default]...done.
Updating service [default]...Waiting for operation [apps/wp-on-gae-187408/operations/9b5abc74-6bda-4c10-aae8
-2c6c00b6497f] to complete...done.
Updating service [default]...done.
Deployed service [default] to [https://wp-on-gae-187408.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

表示されている URL にアクセスすると、無事に WordPress のインストール画面が出てくることを確認できます。

WordPressインストール画面

次回はデプロイされた WordPress の設定と既存のデータのインポートを行います。

構築済のWordPressをGoogle App Engineに移行する(2)

rakumoコンサルティング部の小山(@koyhoge)です。

既存のWordPressGCPに移行する解説記事の2回目です。

前回に引き続き、具体的な移行作業について解説します。

今回の移行手順

今回の移行手順は以下の順番で進んでいきます。こうして並べると手順が多いように感じますが、特にセットアップ系は慣れればさほど大変ではありません。クラウドサービスを使う際にはどうしても必要なことなので慣れていきましょう。

  • WordPressのデータエクスポート
  • GCP環境のセットアップ
    • プロジェクトの作成
    • CloudSQLの設定
    • GAEコンソールの設定
    • Cloud SDK のインストール
  • WPonGAEのセットアップ
  • GAEにデプロイ
  • GAE上のWordPressのインストール
  • データを新環境にインポート
  • DNSの切り替え

ではこれらの手順を順番に追っていきます。

WordPressデータのエクスポート

まず最初に、動作しているWordPressのデータをエクスポート機能を使ってファイルに書き出します。ダッシュボードの「ツール」メニューから「エクスポート」を選択し、

WordPressのエクスポートメニュー

エクスポート管理画面の「すべてのコンテンツ」を選択して「エクスポートファイルをダウンロード」ボタンを押します。すると<ブログ名>.wordpress.<日付>.xml というファイルがダウンロードされます。識別子から分かるように、これはコンテンツの情報を格納したXMLファイルになります。

WordPressのエクスポート画面

このXMLデータは、後の手順でGAE上の新環境にインポートすることになります。

GCPの環境セットアップ

それではいよいよ移行先の GCP 環境の設定を行っていきます。GCPのアカウント作成に関しては詳しく解説しませんが、まだアカウントをお持ちでない場合は、GCPのトップページの「無料トライアル」からアカウントを作成して下さい。

プロジェクトの作成

GCPに限らずGoogleAPIを使用するには、まず開発者向けダッシュボードで「プロジェクト」を作成する必要があります。各種リソースや課金情報はプロジェクト単位で管理されます。新規にアカウントを作成した場合は「My First Project」というプロジェクトが自動で作成されています。

新しくプロジェクトを作成するには、GCPのコンソール画面の上部メニューからプロジェクトの選択ボタンを押し、

プロジェクト選択ボタン

そこで表示されるダイアログの右端にある「+」ボタンクリックします。

プロジェクト新規作成ボタン

プロジェクト名を入力する画面になるので、任意の文字列を入力します。今回のプロジェクト名は「wp-on-gae」としました。

プロジェクト名の入力

ここから先、いくつかの GCPサービスの設定をしていきますが、すべてこの「wp-on-gae」プロジェクトで行うこととします。

Cloud SQLの設定

まずはWordPressのバックエンドデータベースであるMySQLの移行先として、Cloud SQLの設定をしましょう。Cloud SQLクラウド上で動作するフルマネージドなRDBMSで、

GCPコンソールの左上にある「三」のような形の「ハンバーガーメニュー」ボタンを押して、サービスメニューを開き、

GCPサービスメニュー

下の方にスクロールすると表示される「SQL」を選択します。

SQLメニュー

まだCloud SQLインスタンスが存在しない場合は、新規作成画面になります。

Cloud SQLインスタンス新規作成

まず MySQLPostgreSQLの選択画面になりますので、MySQLを選択します。

データベースエンジンの選択

MySQL インスタンスタイプの選択」では「第2世代を選択」を選びます。

インスタンスタイプの選択

MySQL 第2世代インスタンスの作成」で必要項目を入力します。

  • インスタンスID」は「wp-on-gae-mysql」としました。
  • 「rootパスワード」は右端の「生成」ボタンを押して自動生成しました。
  • 「リージョン」は、東京リージョンにしたいので「asia-northeast1」としました。
  • 「ゾーン」はどれでも良いですが、今回は「asia-northeast1-c」にしました。

MySQLインスタンスの設定

必要事項を入力して「作成」ボタンを押すと、しばらく時間をおいたあと、無事にMySQLインスタンスが立ち上がります。

インスタンス作成完了

インスタンスのリスト表示内の「インスタンス接続名」は後で必要になるのでメモっておきます。今回は「wp-on-gae-187408:asia-northeast1:wp-on-gae-mysql」でした。

GAEの設定

次に WordPress の実行環境となる Google App Engine(GAE) の設定を行います。サービスメニューから「App Engine」を選択しGAE の設定画面に入ります。

App Engineメニュー

「初めてのアプリへようこそ」という画面でチュートリアルがはじまるように見えます。とりあえず「言語を選択」して先に進みます。

App Engine へようこそ

WordPressPHPで作られているので「PHP」を選択します。

PHPを選択

次に「ロケーションを選択」します。国内からのアクセスを想定するので「asia-northeast1」を選択します。

ロケーション選択

「App Engine サービスを準備しています」というメッセージが表示されてしばらくすると、準備が整います。

App Engine サービスを準備しています

しかしこのWebコンソールからは、動作しているアプリケーションの各種状況は確認できますが、アプリケーションのデプロイそのものはできません。デプロイは次にインストールする gcloud コマンドで、コマンドラインから行います。

Cloud SDK のインストール

GAE のデプロイに必要な gcloud コマンドのために、Google Cloud SDKを手元のマシンにインストールします。以下のページのガイドラインに従って進めます。

https://cloud.google.com/sdk/downloads?hl=jacloud.google.com

今回はLinux環境にインストールするので、以下のコマンドを実行します。

$ curl https://sdk.cloud.google.com | bash

以下のようにインストール先を聞いてきます。

Installation directory (this will create a google-cloud-sdk subdirectory) (/home/koyama):

意味: インストールするディレクトリを指定して下さい(そこに google-cloud-sdk ディレクトリが作成されます) (省略時は /home/koyama):

自分のホームディレクトリの下で問題ないので、そのままエンター。

大量にファイルが展開された後、フィードバックのためのデータを匿名化して収集してよいかと質問されます。

/home/koyama/google-cloud-sdk/install.sh
Welcome to the Google Cloud SDK!

To help improve the quality of this product, we collect anonymized usage data and anonymized stacktraces when crashes are encountered; additional information is available at <https://cloud.google.com/sdk/usage-statistics>;. You may choose
to opt out of this collection now (by choosing 'N' at the below prompt), or at any time in the future by running the following command:

    gcloud config set disable_usage_reporting true

Do you want to help improve the Google Cloud SDK (Y/n)?

私は問題ないので「Y」ですが、各々の考え方によって判断して下さい。

SDKの各コンポーネントのインストールが終わった後、パスとコマンド補完の設定を追加するか聞いてきます。

Modify profile to update your $PATH and enable shell command
completion?

Do you want to continue (Y/n)?

「Y」を入力すると、設定を追加するあなたの「rcファイル」は「/home/koyama/.bashrc」で良いかと聞いてきます。

The Google Cloud SDK installer will now prompt you to update an rc
file to bring the Google Cloud CLIs into your environment.

Enter a path to an rc file to update, or leave blank to use
[/home/koyama/.bashrc]:

こちらも問題ないのでエンターを押すと、.bashrc が更新されて以前のファイルは .bashrc.backup に残してあると表示され、インストーラは終了します。

Backing up [/home/koyama/.bashrc] to [/home/koyama/.bashrc.backup].
[/home/koyama/.bashrc] has been updated.

==> Start a new shell for the changes to take effect.


For more information on how to get started, please visit:
https://cloud.google.com/sdk/docs/quickstarts

さきほど .bashrc に追加した設定を有効にするためにログインシェルを再起動します。

$ exec -l $SHELL

gcloud 環境を初期化するために gcloud init コマンドを実行します。実行結果はおそらく人それぞれに異なるでしょうが、私の場合はログインして認証チェックを求められました。

$ gcloud init
Welcome! This command will take you through the configuration of gcloud.

Your current configuration has been set to: [default]

You can skip diagnostics next time by using the following flag:
  gcloud init --skip-diagnostics

Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
Reachability Check passed.
Network diagnostic (1/1 checks) passed.

You must log in to continue. Would you like to log in (Y/n)?

yを入力すると認証用のURLが表示され、これをブラウザで開くように求められます。

Go to the following link in your browser:

https://accounts.google.com/o/oauth2<省略>

ブラウザで開くとリソースに対するアクセスの許可を求められて、

認証画面

「許可」ボタンをクリックすると、

認証用のコード文字列が表示されます。

認証用コード

そのコード文字列をコピーして、ターミナルに戻ってペーストすると無事に GCP アカウントでログインできました。

Enter verification code: XXXXXXXXXXXXXXXXXXX
You are logged in as: [koyhoge@gmail.com].

引き続きどのプロジェクトを利用するかメニューで表示されますので、さきほど作成した wp-on-gae プロジェクトを選択します。

You are logged in as: [koyhoge@gmail.com].

Pick cloud project to use:
 [1] wp-on-gae-187408
 [2] Create a new project
Please enter numeric choice or text value (must exactly match list
item):

Google Compute Engine が有効化されてないけど良いと聞いてきますが、今回はGCEは使用しないので「n」にします。

Your current project has been set to: [wp-on-gae-187408].

API [compute.googleapis.com] not enabled on project [4565231767].
Would you like to enable and retry?  (Y/n)?

すると諸々のメッセージを表示して、初期化処理はおしまいです。

Not setting default zone/region (this feature makes it easier to use
[gcloud compute] by setting an appropriate default value for the
--zone and --region flag).
See https://cloud.google.com/compute/docs/gcloud-compute section on how to set
default compute region and zone manually. If you would like [gcloud init] to be
able to do this for you the next time you run it, make sure the
Compute Engine API is enabled for your project on the
https://console.developers.google.com/apis page.

Created a default .boto configuration file at [/home/koyama/.boto]. See this file and
[https://cloud.google.com/storage/docs/gsutil/commands/config] for more
information about configuring Google Cloud Storage.
Your Google Cloud SDK is configured and ready to use!

* Commands that require authentication will use koyhoge@gmail.com by default
* Commands will reference project `wp-on-gae-187408` by default
Run `gcloud help config` to learn how to change individual settings

This gcloud configuration is called [default]. You can create additional configurations if you work with multiple accounts and/or projects.
Run `gcloud topic configurations` to learn more.

Some things to try next:

* Run `gcloud --help` to see the Cloud Platform services you can interact with. And run `gcloud help COMMAND` to get help on any gcloud command.
* Run `gcloud topic -h` to learn about advanced features of the SDK like arg files and output formatting

事前準備だけでずいぶん長くなってしまいましたので、今回はここまでにします。次回はGAEにデプロイするWordPressの設定を行います。

構築済のWordPressをGoogle App Engineに移行する(1)

rakumoコンサルティング部の小山(@koyhoge)です。

GCPの使い方の一例として、既存のWordPressサイトをGoogle App Engine (GAE)に移転する方法を、これから数回に分けて書いていこうと思います。

クラウド化の基本

既存サービスをクラウド化する場合は、その構成要素をしっかり分けて考えることが必要になります。WordPressもその例外ではなく、どの部分をどこに移していくかということを明確にしなければいけません。現在動いているものを単に仮想マシンに乗せ換えるだけでは、クラウドのメリットを活かしているとは言えません。

WordPressの構成要素を挙げてみると、以下のようになります。

  • WordPressそのもののPHPプログラム
  • データベースに格納されているブログデータ
  • サイトにアップロードされているメディアライブラリ

このそれぞれに関して、移行を考えていきます。

GCP移行に使えるツール/プラグイン

WordPressGCPに載せるのに便利なツール/プラグインがいくつか公開されています。

WordPress on App Engine Starter Project

github.com

Google自らによって作成された、WordPressGCPで動かすためのプラグインをまとめたスターターキットです。上記の構成要素の各部分をまとめてGCP上に移行することができます。

WP-Stateless

ja.wordpress.org

既存のWordPress上にある画像や動画などのメディアファイルを、Google Cloud Storage (GCS)に移行するためのプラグインです。すでにあるファイルをGCSに自動で一括アップロードする機能の他に、以下の3つの動作モードを持っています。

  • バックアップ
    • 単にメディアのバックアップとしてGCSを使用
  • CDN
    • サーバ上のファイルは残したままCDNとしてGCSを使う
  • ステートレス
    • メディアの置き場としてGCSだけを使う

メディアファイルの転送に対するサーバー負荷を減らしたいだけならば、このプラグインは大変良くできているので有用ですが、今回はWordPressの動作環境全部をGCPに移行することを考えているので、Googleのスタータープロジェクトの方を採用することにします。

各構成要素の移行先のサービス

ではWordPress on App Engine Starter Project (以下 WPonGAE)では、最初に書いた構成要素をそれぞれどのようにGCPに移すのでしょうか?

WordPressそのもののPHPプログラム

これはPaaSであるGoogle App Engine (GAE)に乗せます。そもそもそのためのプロジェクトだから当然ですね。GAEは、特定のプログラムの実行環境だけを統合管理してくれるサービスです。今回の場合で言えば、OS等の基礎部分はユーザは気にすること無く、PHPの動作環境だけを提供してくれます。

データベースに格納されているブログデータ

WordPressはデータベースとしてMySQLを使いますが、GAEからアクセス可能なMySQLサービスとしてGoogle Cloud SQLがあります。フルマネージドなRDBMSとしてこれを使えば問題ないでしょう。

サイトにアップロードされているメディアライブラリ

WPonGAEでも、WP-Statelessと同様にGoogle Cloud Storage (GCS)をメディアファイルの置き場として使用します。GAEではプログラムが動作するディスクに書き込むことはできないので、WP-Statelessで言うところのステートレスモードに相当する動作になります。

次回からは具体的な移行作業について解説していきます。

GCSバケットをマウントする Cloud Storage FUSE

こんにちは。rakumoコンサルティング部の末木(id:ksueki)です。

本記事ではGoogleから提供されているCloud Storage FUSE(GCS FUSE)について扱います。 GCS FUSEオープンソース(Apache License)のFuseアダプタで、 これを利用することでGoogle Cloud Storage(GCS)のバケットをLinuxもしくはOS X上でファイルシステムとしてマウントすることが可能です。

今回はGCS FUSEGCPリソース上で利用する方法、 またGoogle Compute Engine(GCE)インスタンスでGCSバケットをマウントした環境におけるベンチマークの結果について紹介します。

GCP環境

前述の通り、今回はGCEインスタンスにGCSバケットをマウントする構成を想定しました。 以下にGCE・GCSの構成を列挙します。

  • GCE
    • OS: Debian GNU/Linux 8 (jessie)
    • マシンタイプ: f1-micro (vCPU x 1, メモリ 0.6GB)
    • ゾーン: asia-northeast1-a
  • GCSバケット
    • ストレージクラス: Regional
    • リージョン: asia-northeast1

GCS FUSEの導入

Googleによるチュートリアルに沿った形で、GCEにGCS FUSEを導入します。 GCS FUSEGitHubホスティングされています。 以下の行程では、Cloud Shellを利用してGCEインスタンス上で作業します。

  1. gcsfuseのインストール
    apt-getgcsfuseをインストールします。
$ export GCSFUSE_REPO=gcsfuse-`lsb_release -c -s`
$ echo "deb http://packages.cloud.google.com/apt $GCSFUSE_REPO main" | sudo tee /etc/apt/sources.list.d/gcsfuse.list
$ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get install gcsfuse
  1. GCEにGCSバケットをマウント
$ mkdir ${LOCAL_DIR}
$ gcsfuse ${BACKET_NAME} ${LOCAL_DIR}

これでGCS FUSEの導入とGCSバケットのマウントは完了です。

ベンチマーク

さて、構成した環境についてベンチマークを実施しました。 今回はfioというベンチマーカーを利用して、シーケンシャル/ランダム アクセスそれぞれの read/write 処理に関してレイテンシを計測しました。 fioはディレクトリを指定してベンチマークを実行することができます。

以下、ランダムアクセス時のベンチマーク結果です。

read/write ファイルサイズ ジョブ数 最小レイテンシ /msec 最大レイテンシ /msec 平均レイテンシ /msec 標準偏差 /msec
1 read 1GB 1 21.00 451.00 102.06 84.67
2 read 1MB 500 60.00 1568.00 919.47 482.98
3 write 1GB 1 0.00 28666.00 0.23 56.02
4 write 1MB 500 0.00 22359.00 142.08 1393.01

次に、シーケンシャルアクセス時のベンチマーク結果です。

read/write ファイルサイズ ジョブ数 最小レイテンシ /msec 最大レイテンシ /msec 平均レイテンシ /msec 標準偏差 /msec
5 read 1GB 1 0.00 139.30 0.01 0.37
6 read 1MB 500 0.00 5545.20 893.67 1641.82
7 write 1GB 1 0.00 28957.00 0.24 56.70
8 write 1MB 500 0.00 27091.00 154.34 1484.77

まとめ

さて、今回はCloud Storage FUSEを利用してGCSバケットをマウントし、fioを使ってその性能を検証しました。 単純な比較ではありませんが、サイズの大きなファイルのアクセス(一括アクセス)の方が、レイテンシが小さいことがわかりました。 特にシーケンシャルアクセスでは大きな差が出ていることがわかります。 このことに関してはGCS FUSEドキュメントにも以下のように記載があります。

パフォーマンス: Cloud Storage FUSE のレイテンシは、ローカル ファイル システムよりもはるかに高くなっています。そのため、サイズの小さなファイルを 1 つずつ読み取る / 書き込むと、スループットが低下することがあります。サイズの大きなファイルを使用するか複数のファイルを一括転送することで、スループットは上がりやすくなります。

また、所感としてもwriteの最大レイテンシが非常に大きいという印象を得ました。 NFSを利用した分散ストレージ環境などと比較調査していく必要があるかもしれません。

rakumo コンサルティング部 Tech Blogでは随時GCP関連の情報をお届けしていきます! お楽しみに!

おまけ

ベンチマークに利用したfioの設定ファイルを以下に掲載します。 番号はベンチマーク結果表と照合してください。

[random-read-remote-1gx1]
rw=randread
size=1g
numjobs=1
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[random-read-remote-1mx500]
rw=randread
size=1m
numjobs=500
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[random-write-remote-1gx1]
rw=randwrite
size=1g
numjobs=1
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[random-write-remote-1mx500]
rw=randwrite
size=1m
numjobs=500
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[sequencial-read-remote-1gx1]
rw=read
size=1g
numjobs=1
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[sequencial-read-remote-1mx500]
rw=read
size=1m
numjobs=500
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[seqencial-write-remote-1gx1]
rw=write
size=1g
numjobs=1
group_reporting
directory=./gcs_cfuse_test/
runtime=600
[sequencial-write-remote-1mx500]
rw=write
size=1m
numjobs=500
group_reporting
directory=./gcs_cfuse_test/
runtime=600

rakumoコンサル部テックブログはじめました

rakumoコンサルティング部の小山(@koyhoge)です。

rakumoは、Googleのオフィス製品 G Suiteグループウェアとしてさらに便利に使えるようにする拡張パッケージで、1,300社以上の企業さまに導入されています。ここで様々なお客さまの要望をお聞きして、rakumo製品の改善につなげたことは、我々の大きな資産になっています。

rakumo.com

このたびrakumo株式会社は、新たな試みとしてGoogle Cloud Platform (GCP)のパートナーとして、GCPコンサルティング/再販事業に取り組むことになりました。rakumo製品の時と同様に、お客さまの多種多様な問題をGCPを始めとする技術を用いて解決し、より効率的で挑戦的な業務改善のお手伝いをしていきたいと思います。

私たちが得たノウハウは、できる限り公開していくつもりです。そのためにこのブログを立ち上げました。GCPの優れている点やハマりどころ、使いこなし方などをどんどん公開していく予定ですので楽しみにしていて下さい。

これからも GCP と rakumo を、どうぞよろしくお願いします。