エンタープライズ クラスの WordPress サイトを Azure WebSites で運営する方法
このポストは、5 月 13 日に投稿した How to run Enterprise Grade WordPress sites on Azure Websites の翻訳です。
Azure WebSites (“WebSites”) は、WordPress の本番サイト向けにスケーラブルで安全、簡単に使用できる環境を提供します。今回の記事では、大量の訪問者に対応可能な正真正銘クラウドベースの WordPress サイトの作成、構成、最適化の手順を説明します。
今回の学習内容
- WordPress を Azure WebSites にインストールする方法
- WebSites の構成方法
- WebSites の監視のセットアップ方法
- Azure WebSites で WordPress を運営する場合のベスト プラクティス
- 既存の WordPress サイトを移行する方法
- パフォーマンスを向上させる方法
- WordPress サイトの可用性を高める方法
WordPress を Azure WebSites にインストールする方法
Azure WebSites ギャラリーから WebSites に WordPress をすばやく簡単にインストールできます。ただし、このワークフローで作成したデータベースはアプリケーションを試すための無償版 MySQL データベースなので、本番の WordPress サイトでの使用には適していません。このため、まず Azure ストアからスケーラブルな MySQL データベース サービスを購入します。
Azure 管理ポータルにログインして [STORE (PREVIEW) ] をクリックし、新しい MySQL データベースを購入します。
図 1 Azure 管理ポータルの [STORE] オプションを選択
ストアから ClearDB サービスを選択します。
図 2 ClearDB MySQL サービスを選択
高性能データベース サービス向けの「Jupiter」プランを選択し、任意のデータベース名を入力します。ClearDB プランの詳細については Microsoft Azure 向け ClearDB プラン (英語) を参照し、ニーズに最も合ったプランを選択してください。
図 3 Jupiter プランの MySQL データベースを開始
購入を確定すると、Azure 管理ポータルが有料プランの ClearDB データベースをプロビジョニングします。
図 4 購入を確定
Azure WebSites ギャラリーから WebSites に WordPress を簡単にインストールできます。[NEW]タブ、[COMPUTE]、[WEB SITE]、[FROM GALLERY] の順にクリックします。
図 5 WordPress の WebSites を新規作成
ギャラリー ウィザードから WordPress アプリケーションを選択します。
図 6 Web App ギャラリーで WordPress を選択
サイトの URL 設定やデプロイメント設定を入力します。デプロイメント設定のキーを生成するには、文字列を無作為に生成するこちらのスクリプト (英語) (WordPress.org から取得) を実行します。[Use an existing MySQL database] を選択します。
図 7 WordPress のインストールを構成
先ほど Azure ストアから作成したデータベースを選択して、インストール ウィザードを完了してください。
図 8 MySQL データベースを選択
WebSites の構成方法
サイトのスケーリングにより、安定したパフォーマンス、スケーラビリティ、フォールト トレランスを確保できます。最初に Azure 管理ポータルにログインして、WebSites のダッシュボードに移動します。[SCALE] をクリックして、この WebSites のみ [STANDARD] モードを選択します。Standard モードは、Free や Shared よりも高い可用性や一貫したパフォーマンスを実現できます。Standard モードの詳細については、こちらのページの Standard モードに関するセクションを参照してください。
Azure WebSites のインスタンスには Small、Medium、Large の 3 つのサイズがあります。選択するインスタンス サイズにより、負荷発生時における WebSites のパフォーマンス レベルが決まります。WebSites のトラフィック (単位は一般に、1 秒あたりの要求数である RPS を使用) がわかっていれば、最適なインスタンス サイズを選択できます。RPS の詳細については、「HTTP サーバーの負荷を計算する方法 (英語)」を参照してください。ここでは、Small インスタンスに設定します。
図 9 Standard モードのインスタンスで実行するよう WebSites を構成
以下のように自動スケーリングをセットアップすると、サーバー CPU が固定されている場合またはスケジュールがあらかじめ決められている場合に、複数のインスタンスでスケールアウトできます。[SAVE] をクリックして構成を設定します。
図 10 WebSites の自動スケーリングをセットアップ
WordPress では既定で電子メール サービスは構成されていません。電子メール機能を使用するには、SendGrid などサード パーティの電子メール サービスが必要です。Azure ストアの SendGrid アカウントを構成する方法をご確認ください。このアドオン サービスを購入したら、WordPress の SendGrid プラグイン (英語) をインストールして、新たに作成した SendGrid アカウントで構成します。
WebSites の監視のセットアップ方法
Azure 管理ポータルで WebSites を簡単に監視できます。次のことが可能です。
– CPU 時間、RPS、HTTP エラー コードなどの各種メトリックスの追加
– WebSites のメトリックスのアラートを受信
– 使用量のクォータを表示
– 診断機能の構成と WebSites のログのダウンロード
詳細については、WebSites の監視方法に関するページを参照してください。
Azure WebSites で WordPress を運営する場合のベスト プラクティス
マイクロソフトが行ったベンチマーク テストにおいて、一部の構成を変更すると、Azure WebSites で稼動する WordPress のパフォーマンスとスケーラビリティが大幅に向上することがわかりました。以下に紹介します。
1. Basic モードと Standard モード
Azure WebSites では Shared インスタンスと Dedicated インスタンスを使用できます。同じ共有インスタンスで稼動する他のサイトのせいで自身のサイトの実行に必要なリソースが圧迫されないように、Dedicated インスタンスを使用してサイトを分離することをお勧めします。Dedicated インスタンスでは Basic と Standard のモードを使用できます。両モードとも SSL、Web ソケットなどの各種機能を提供しています。WebSites の Basic および Standard モードの詳細については、レベル別の機能を参照して、自分のニーズに合ったモードを見つけてください。
Web ホスティング プランを Standard モードに切り替える前に、Microsoft Azure WebSites サブスクリプションの利用制限を解除します。それを行わないと、課金期間が満了する前に上限に達して WebSites が利用できなくなるおそれがあります。Microsoft Azure WebSites サブスクリプションのオプションを確認または変更するには、Microsoft Azure サブスクリプションを参照してください。
2. 永続的なデータベース接続を使用する
WordPress は非永続的なデータベース接続を使用するため、データベースを呼び出すたびに新しい接続が確立されます。Azure WebSites から MySQL データベースへの接続回数が 100 回を超えると、Azure プラットフォームにより呼び出しが調整されるようになり、その結果、接続が制限されパフォーマンスが低下します。この問題を回避するために、WordPress サイトでは永続的な接続の使用をお勧めします。永続的な接続を使用するには、wp-includes/wp-db.php ファイルを次のように編集します。
//remove line 1147
//$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );
//Add the line below
$this->dbh = mysql_pconnect( $this->dbhost, $this->dbuser, $this->dbpassword, $client_flags );
if ( false !== $error_reporting ) {
error_reporting( $error_reporting );
}
} else {
//remove line 1152
//$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );
//Add the line below
$this->dbh = @mysql_pconnect( $this->dbhost, $this->dbuser, $this->dbpassword, $client_flags );
}
3. WordPress の自動更新を無効化する
WordPress はマイナー リリースを Web サイトに自動的に適用します (メジャー リリースは適用しません)。自動更新により wp-db.php (前述の永続的なデータベース接続の変更が含まれる) ファイルが上書きされてしまうので、次のいずれかの方法で対処します。
1. WebJob を使用して wp-db.php ファイルの変更をリッスンし、mysql_connect() 関数ではなく mysql_pconnect() 関数を使用するようにします。詳細については WebJob に関する記事 (英語) を参照してください。
2. WordPress の自動更新は簡単に無効化できます。次のコードを wp-config.php ファイルに追加します。
define ( 'WP_AUTO_UPDATE_CORE', false );
この場合は、WordPress のバージョンの更新状況を追跡して、手動で更新する必要があります。WP Updates Notifier (英語) をインストールすれば、新たなメジャー バージョンまたはマイナー バージョンのリリースを追跡できます。
4. ARR Cookie を無効にする
Azure WebSites はアプリケーション要求ルーティング処理 (英語) IIS 拡張機能を活用してアクティブなインスタンスに接続を分散させます。ARR を利用すると、特別な Cookie (アフィニティ Cookie) を使用してユーザーを追跡し、それ以降 Azure WebSites で要求が発生した時に同じユーザーによる前回の要求をどのサーバー インスタンスが処理したかを確認できます。これにより、クライアントが特定のサーバー インスタンスとセッションを確立すると、セッションがアクティブな間は同じサーバーとの通信を維持します。これはセッションを考慮する必要のあるアプリケーション (ステートフル アプリケーション) では特に重要になります。
WordPress は既定でステートレスであり、すべてのセッション情報をデータベースに保存するので、クライアント側が同じ Web サーバー インスタンスに接続する必要はありません。ARR Cookie を無効にすると、WordPress サイトを複数のインスタンスで実行する場合のパフォーマンスが向上します。ARR cookie の無効化についてのブログ記事を参照してください。
5. メディア コンテンツ用の Azure の BLOB ストレージを利用する
WordPress サイトで動画や画像を多用している場合は、BLOB ストレージを使用してすべてのメディア コンテンツを保存することをお勧めします。
Azure のストレージ アカウントの作成方法については、「ストレージ アカウントの作成方法」を参照してください。アカウントを作成したら、WordPress サイト用に Windows Azure Storage for WordPress プラグイン (英語) を有効にして構成してください。
6. 管理者用の独自のユーザー名を設定し、既定の adminユーザーを使用しない
既定の admin ユーザーで WordPress をインストールした場合は、管理者ユーザー名を変更して WordPress サイトの安全を確保してください。
既存の WordPress サイトを移行する方法
あまりカスタマイズせずにシンプルな WordPress ブログを運営している場合は、WordPress の既存のエクスポート機能 (英語) を利用して、既存のすべての WordPress コンテンツを WXR (WordPress 拡張 RSS) XML フィードにエクスポートします。Azure WebSites に移行したい既存の WordPress サイトにログインし、すべてのコンテンツを WXR フィードにエクスポートします。
Azure WebSites の WordPress サイトにログインし、[Plugins]、[Add New] の順にクリックします。WordPress Importer プラグインを検索します。
図 11 WordPress Importer プラグインをインストール
WordPress Importer プラグインを選択しインストールします。
図 12 WordPress Importer プラグインを選択
[Tools]、[Import] の順にクリックして [WordPress] をクリックし、WordPress Importer プラグインを使用します。
図 13 WordPress Importer プラグインを使用
既存の WordPress サイトからダウンロードした WXR ファイルをアップロードして、コンテンツをインポートします。
図 14 コンテンツを WebSites にアップロード
[Download and import file attachments] を選択して、既存の WordPress サイトからメディア コンテンツをインポートします。
図 15 インポートの準備を完了
インポートに成功するとその旨が通知されます。
図 16 インポートに成功
新しい WordPress サイトで次のような構成の変更が必要になります。
- 以前の Web サイトでパーマリンク (英語) を使用している場合は、WebSites ダッシュボードに移動して、[Settings] から [Permalinks] パネルに移動し、パーマリンクの構造が既定でない場合は構造を更新します。
- アップロード済みのメディアへの既存の画像 (メディア) リンクは古いフォルダーを参照しているので、新しい場所に更新します。Velvet Blues Update URLs プラグイン (英語) もしくは検索・置換ツール (英語) を使用して実行するか、またはデータベースで手動で実行します。
- Importer プラグインは WordPress サイトのテーマは更新しません。[Appearance]、[Theme] の順に移動して WebSites のテーマを適宜更新します。
- テーマがメニューをサポートしている場合は、ホーム ページへのリンクに古いサブディレクトリが埋め込まれている可能性があるので、[Appearance]、[Menus] の順に移動して更新します。
- この一連の手順が完了したら、Azure 管理ポータルの WebSites のダッシュボードから WebSites を再起動します。
カスタマイズ可能な WordPress サイトを別のサーバーから移行する方法
サイトがカスタマイズされていてプラグインを多数実装している場合は、前述の方法では面倒です。このような場合は、次の手順でサイトを移行します。
- 既存のサイトから WordPress サイトとデータベースをバックアップする方法の詳細については、「WordPress のバックアップ (英語)」と「データベースのバックアップ (英語)」を参照してください。
- Azure 管理ポータルで [NEW]、[WEB SITE]、[CUSTOM CREATE] の順にクリックし、データベースを指定して新しい WebSites を作成します (この手順を実行する前に、前述のようにストアからデータベースを購入する必要があるので注意してください)。
- ドメインを新しい Azure WebSites のドメインに更新します (例: mywordpres.azureWebSites.net)。WordPress データベースの検索・置換スクリプト (英語) を使用して、すべてのインスタンスを安全に変更します。
- wp-config.php を新しいデータベース/ユーザー情報で更新し、GIT または FTP を使用して新しいサーバーにそのままアップロードします。「Azure WebSites をデプロイする方法 (英語)」を参照してください。
- MySQL Workbench (英語) などの MySQL クライアントを使用して Azure で新規作成したデータベースにアクセスし、WordPress データベースをインポートします。
パフォーマンスを向上させる方法
Azure WebSites で WordPress のパフォーマンスを向上させるためのヒントを紹介します。
- 膨大な量のユーザー トラフィック (大量のページ ビューとユニーク ビジター) が発生する WebSites では、Memcached などの分散キャッシュ サーバーの利用が有効です。詳細については、Memcached のセットアップ方法に関する記事を参照してください。WebSites で単一の Memcached サーバーを使用すると、単一障害点となるおそれがあるので、これを避けるために最低 2 つの Memcached サーバーを使用します。複数のサーバーをセットアップするには、wp-config.php ファイルを更新して、すべての Memcached サーバーをグローバル変数 $memcached_servers に含めます。
global $memcached_servers;
$memcached_servers = array('default' => array('myserver1.cloudapp.net:11211', 'myserver2.cloudapp.net:11211'));
- WebSites のトラフィックがさほど多くない場合は、Memcached を使用する必要はありません。WP-Optimize (英語) や Yoast Optimize DB (英語) などのプラグインで WordPress データベースを最適化することを検討してください。
- Azure WebSites は最新版の Wincache が既定で有効になっています。「WinCache 1.1 で IIS 上の WordPress サイトを高速化する (英語)」を参照してください。
- WP-Optimize プラグイン (英語) を使用して、データベースをクリーンアップおよび最適化します。
- Autoptimize (英語) や Better WordPress Minify (英語) などのプラグインを使用して Javascript や CSS のファイルを最小化します。
WordPress サイトの可用性を高める方法
Azure WebSites の SLA は 99.9% で、WebSites のダウンタイムが一切発生しないわけではなく、WebSites サービスまたはデータベースで予期しない障害が発生して、サイトに影響が及ぶ可能性があります。この問題を解決するには、1 つずつコンポーネントの可用性を高める必要があります。そうすることで、よりスケーラブルでサービス障害に強いシステムが実現できます。
WebSites のスケーリング
Azure WebSites のスケールアップには、Web ホスティング プランのモードを高次のサービスに変更することと、高次のサービスに切り替えた後に一定の設定を行うことの 2 つの対応が必要です。この両方の対応についてこの記事で取り上げています。高次のサービス レベルである Standard モードでは、Azure のリソースの利用方法を柔軟に決定できます。詳細については、前述の Azure WebSites のスケーリング方法を参照してください。
Azure Traffic Manager は、ユーザー トラフィックを制御して指定の WebSites エンドポイントに分散できるだけでなく、特定のデータ センターでサービス障害が発生した場合のエンド ユーザーへの影響を大幅に抑える自動フェールオーバーに対応しています。WebSites を最低 2 つのデータ センターにレプリケートし、Traffic Manager のフェールオーバー メソッドを利用して WebSites の高可用性を維持してください。WebSites の Azure Traffic Manager のエンドポイントの作成方法については、こちらの記事を参照してください。
データベースのスケーリング
データベースはフル機能の WordPress サイトに不可欠な要素です。データベースの可用性を向上させるには、次のいずれかを実行します。
- Azure で Clear DB MySQL サービス (英語) を使用している場合は、ClearDB High Availability SQL Routers (CDBR) (英語) を構成します。Clear DB は一対のリージョン間のデータベース レプリケーションに対応しています (例: 米国東部と米国西部)。また、Azure WebJob を使用してデータベースをレプリケートする独自のツールを作成することも可能です。
- Azure Virtual Machines で MySQL クラスターを管理するためのツールがすべてそろった MySQL Cluster CGE (英語) をセットアップします。この場合はすべての MySQL クラスター、データベース レプリケーションおよびスケーリングを手動で管理します。
追加のコンポーネントのスケーリング
メディア コンテンツ用に Azure の BLOB ストレージを使用している、または Memcached サーバーを使用している場合は、単一障害点となるのを避けなければなりません。たとえば Azure Storage サービスでは地理冗長性を持たせてフェールオーバーを可能にしたり、Content Delivery Network (Azure CDN) を利用したりすることができます。
CDN で Azure データをキャッシュすると次のようなメリットがあります。
- コンテンツ ソースから遠く離れた地域にいるため、コンテンツを読み込むための経路が長い場所でアプリケーションを使用しているエンド ユーザーにとってのパフォーマンスとユーザー エクスペリエンスの向上。
- 製品リリースなどのイベントの開始直後の高負荷状態に適切に対応できる大規模な分散スケーリング。WebSites のメディア コンテンツ用に作成したストレージ アカウントに対して Azure CDN アカウントを作成します。
WordPress プラグインでの CDN の使用
メディア コンテンツの配信に使用した Azure ストレージ アカウントに対して CDN を作成します。こちらの記事で説明されています。プラグイン設定ページの CNAME プロパティ設定に Azure CDN 名を入力します (例: https://az628210.vo.msecnd.net/)。
[Save Changes] を必ずクリックします。CDN の DNS プロパゲーションは作成から 60 分ほどかかります。これでメディア コンテンツ用に Azure CDN を使用する準備が整いました。
参考資料