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

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

構築済の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 を、どうぞよろしくお願いします。