【注意】この情報は、EC-Cube バージョン 3 (古いバージョンの EC-Cube) に関する情報です。

こんにちは。

Microsoft Azure を使うと数分で EC-CUBE を使った EC サイトが公開できますが、本番運用 (実運用) に入る際にはいくつか構成変更をおこなう必要があります。今回は、この紹介したポイントをザッとメモしておきます。

なお、今後予定の「EC-CUBE 実用セミナー 第 3 回」では下記で述べる構成や、EC-CUBE 独自のチューニング ポイントなど、システム面での話を実際の手順や注意点も含め解説予定ですので、手順詳細は第 3 回にご参加ください。

インストール

Azure を使用すると、あっという間にサイトとデータベースが構築でき、EC サイトが公開できます。(しかも、ここまでなら、無償でインストール・公開できます。)
このため、EC-CUBE を使ったデザイン カスタマイズなど、基本的な確認をしたいなら Azure はお勧めです。

Azure の管理ポータルには、現行リリースされている Azure Management Portal (https://manage.windowsazure.com) と、次期版として先行リリースされている (現在開発中の) Azure Preview Portal (https://portal.azure.com) の 2 種類があります。前者の Azure Management Portal を使ったインストール手順については、「EC-Cube かんたんガイド」で画面付きで紹介していますので、今回は、以下に、Azure Preview Portal (後者) を使った手順を紹介しておきます。

1. Azure Portal (https://portal.azure.com) にログインし、左下の [新規] をクリックして [すべて] を選択します。
2. 表示される画面で、左から [Web] を選択し、右の中段あたりの Ecommerce の中にある [EC-CUBE] をクリックします。
3. 出てくる画面で [作成] ボタンを押すと下図の通り表示されるので、右の [WEB サイト]、[データベース] を順番にクリックして、EC-CUBE の Web サイト (Web App) と、MySQL のデータベースを順番に構成します。
4. まず、上図の [WEB サイト] から選択 (構成) します。
   これを選択すると、下図のように、右に、作成する Web App の URL、使用する Plan (Free Plan など)、Region (配置先のデータセンター) を選択する画面が表示されるので、好みに応じて選択します。(Region では、[東日本]、[西日本] が選択できます。)
   なお、Plan として Free (無料) を選択すると、デザイン・開発・テストなどが可能な無償版のサイトが構築できます。(有償版との違いについては後述します。)
   
5. つぎに [データベース] を選択し、同様に、作成するデータベースの名前、Plan (下図の価格レベル)、Region を設定します。(データベースとして、MySQL が使用されます。)
   後述しますが、「Mercury」と書かれた Plan が無償で利用可能なデータベースです。
6. 設定が完了したら [作成] ボタンを押します。
   これにより、EC-CUBE のインストールされた WEB サイトと、使用する MySQL データベースが作成されます。(この段階では、まだデータベースの中は空です。)
7. 作成が完了したら、作成された Web サイト (Web App) にブラウザーでアクセスします。
   すると、初回接続時は下図の通り EC-CUBE のインストール ウィザードが表示されるので、このウィザードを順番に進めてインストールを完了します。(この設定が完了すると、MySQL のデータベースにテーブルやデータなどの必要なオブジェクトが作成されます。)
   なお、接続先のデータベースなどは初期設定されていますので、変更する必要はありません。
   この設定が完了すると、以降、EC-CUBE が使用できます。

補足 : EC-CUBE のセットアップの際に SMTP サーバー (ホスト名、ポート番号など) の設定を入力する必要がありますが、これについては後述します。(現時点では、ブランクのまま進んでください。)

以上で最低限 動く環境は完成です。
はじめて操作する方にとっては 5 分はちょっと大げさだったかもしれませんが、ウィザードに従ってボタンを押していくだけで、あっという間に EC サイトが公開できます。 (慣れてくれば 5 分程度で作れます)

(追記) また、追加の作業として、「IIS で PHP の ob_* 関数が効かない場合の対処法」で EC-CUBE エバンジェリストの大河内さんが記載しているように、Web.config を編集して下記の通り responseBufferLimit を 0 に設定しておくと良いレスポンスが得られます。なお、使用している PHP のバージョンにあわせて設定する必要があるので注意してください。(App Service Editor を使ってブラウザーで直接編集できます。)

<configuration>  <system.webServer>    . . .    <handlers>      <remove name="PHP55_via_FastCGI" />      <add name="PHP55_via_FastCGI" path="*.php" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\Program Files (x86)\PHP\v5.5\php-cgi.exe" resourceType="Either" requireAccess="Script" responseBufferLimit="0"/>    </handlers>  </system.webServer></configuration>

また、[Settings] – [Application Settings] を選択して PHP のバージョンを簡単に変更できるので、こちらも必要に応じ変更しておいてください。(Azure Web App の PHP 環境には wincache が組み込まれているので、opcache は既に有効になっています。)

なお、Azure Portal には、Web サイト (Web App) や MySQL データベースなどをまとめた「リソース グループ」(Resource Group) というオブジェクトが作成されるので、削除 (Delete) する際は、このリソース グループ (resource group) という単位で削除してください。(現在、MySQL を単独で消すことはできないようで、この方法で消す必要があります。)

構成の解説

出来上がった環境の内部構成は下図の通りです。
以降で、このポイント (構成) をザッと解説します。

• Web サイト側 (EC-CUBE のプログラム側) の環境として Azure App Service の Azure Web App (旧 Azure WebSite) と呼ばれるコンピューティング環境が使用されています。
  この環境は、あらかじめ OS、Web サーバー、アプリケーション フレームワーク (PHP, Node.js, Python, etc) がセットアップされた PaaS (Platform as a Service) 環境で、皆さんは、この上の EC-CUBE のオブジェクト (PHP のソース ファイル、画像ファイル、など) のみを管理すれば良いようになっています。
  Azure Web App では、ベースとして Windows と IIS が使われています。(例えば、/data フォルダーの参照禁止設定なども、.htaccess ではなく、web.config というファイルに記述されています。)
  以前「App Service Editor で PHP アプリ開発」でも紹介したように、ソースコードの確認や config.php 書き換えなどのカスタマイズには、FTP、Git 以外に、App Service Editor を使ったブラウザーによる直接編集が可能です。
• 現時点では、EC-CUBE バージョン 2.13.2 が使用されています。
  ご存じの通り、先日のユーザーカンファレンスで EC-Cube 3 が発表されましたが、EC-CUBE 3 の (Azure 上での) セットアップ方法については、またリリースされたら解説したいと思います。
  (PHP はバージョン 5.3 が使用されていますが、上述の通り、Azure Portal を使って簡単に 5.4 以降にあげていただくことができます。EC-CUBE も PHP 5.4 以降に対応しています。)
• データベースは、既定で、ClearDB (MySQL のクラウド ホスティング) の Mercury Plan (無償版) が使われています。(Azure のデータセンター上で動作しています。) ClearDB も同様にデータベースの PaaS 環境 (DBaaS) であり、皆さんは、この上に作成されたテーブルやデータなどのオブジェクトのみを管理します。
  なお、Azure Management Portal (https://manage.windowsazure.com) を使用している場合は、作成された Azure Web App を表示して [リンク済みリソース] を選択するとデータベースの情報 (ClearDB のダッシュボード) が表示できます。Azure Preview Portal (https://portal.azure.com) の場合は、作成された Resource Group 内にデータベースが登録されているので、これをクリックすることで (ClearDB のダッシュボードが) 確認できます。
  ClearDB のダッシュボード (https://www.cleardb.com/dashboard) を表示して、ホスト名、データベース名、Credential (ID/Password) などの基本的な情報が取得できるので、これらの接続情報を使って普通に MySQL Workbench やコマンドライン (mysql, mysqldump など) からデータベースを管理できます。
  なお、Azure の 1 サブスクリプションで作成可能な無償版の ClearDB は 1 つまでです。開発・テストが終わったら、すぐ消しておいてください。
• 商品をカートに入れた場合など、EC-CUBE の Session 情報も、上述の ClearDB (MySQL) に登録されます。
• アップロードされた商品画像などのバイナリ データは、サーバー (上述の Azure Web App のインスタンス) のディレクトリ (フォルダ) に保存されます。

実運用のための構成変更

さて、デザイン・開発・テストなどの目的では上記の構成で充分ですが、実運用 (本運用) の際には必須の検討ポイントがいくつかあります。(上記の環境のまま、実運用をしないでください。)

以下に、実運用に際して必要な検討ポイントをザッと記載します。(なお、ここから 有償の機能が必要になります。)

コンピューティングのスケール アップ / スケール アウト

Azure Web App の Free Plan では、CPU などのリソース使用制限 (Quota) が低く設定されており、数名の開発や単体テストなどで使う分には問題なく使用できますが、実運用には向いていません。(ツールを使ってロードテストなどをかけていただくと一目瞭然です。ちょっとした負荷で、すぐにエラーを出して止まります。)

Azure Web App の場合、Plan の変更や、稼働しているコンピューティング インスタンスのスケールアップ (コア数, メモリ数などの変更)、スケールアウト (インスタンス数の変更) は、Azure Portal の画面からの操作 (ボタンの選択など) で可能です。(スケールアウトについては、CPU 使用率に応じて自動的に伸縮させることも可能です。)
特に Azure の場合、2 インスタンス以上でなければ SLA (サービスの稼働率など) も保証されないため、実運用では、必ずスケールアップ・スケールアウトをおこなっておきましょう。(下図は Azure Management Portal の場合の設定画面です。)

なお、スケールアウトの際、「EC-CUBE は正しく動くのか ?」という点が気になると思います。結論を書くと、ちゃんと マルチ インスタンスに対応しています。

例えば、EC-CUBE の Session 情報は、上述の通りデータベースに保存されているためインスタンス間で共有されます。
また、商品画像などのファイルはディスクに保存されますが、このディスク (EC-CUBE がインストールされている領域) はスケールアップされたインスタンス間で共有されています。(ただし、ドライブによってはコンピューティング環境のための一時領域となっており共有されていないので注意してください。こうした場所には、コンピューティングのログなどが入っています。)

補足 : Azure Web App の既定の設定では、Cookie を使った Request Routing によって、同一ブラウザーのセッションは同一インスタンスに割り振られます。(この動作を変えることもできます。)
このため、Azure Web App の既定の設定では、Session がインスタンス間で共有されていなくても、一見正しく動作してしまいます。

データベース (ClearDB) の Plan 変更

上述の通り、データベースには、MySQL のサービス (DBaaS) である ClearDB が使用されており、既定で Mercury Plan (同じく Free) が使用されます。(Azure 上で動いています。)
この Mercury Plan も制限がきつく (Max 20 MB など)、パフォーマンスも遅いため、同様に、開発用途などで使う Plan と考えてください。つまり、実運用では、この Plan も変更してください。

ClearDB on Azure Today
https://www.cleardb.com/store/azure

Plan のアップグレード方法は簡単で、ClearDB のダッシュボードで [Upgrade] ボタン (下図) を押すだけです。(ただし、Mercury 以外は、Amazon payment での支払が必要です。)
Jupitar Plan でも、月額 8,000 円弱といった感じで比較的安価です。

なお、ClearDB には、さらに上位の 占有プラン (Dedicated/Private Plan) がありますが、現時点では、日本の Region (東日本、西日本) で ClearDB の占有プランは使用できないので、さらに高いパフォーマンスが要求される場合は 後述する Azure Virtual Machine (仮想マシン) を使ってください。(ClearDB の Jupitar Plan よりも、標準的な Azure Virtual Machine の A1 インスタンス上の MySQL のほうが速く応答します。)

ドメイン変更

Azure Web App でサイトを立てた場合、既定では *.azurewebsites.net (例: https://ec-cube01.azurewebsites.net など) がドメインとして使用されます。
もちろん、このまま運用しても動作上の問題はありませんが、サービス提供そのもの (顧客がアクセスする URL) や、SEO、今後の運用・システム移行なども見据えると、ドメインも独自に設定しておくべきでしょう。(もしかしたら、将来的は Azure 以外のプラットフォームを使用するかもしれません。)

Azure Web App でカスタム ドメインを設定する場合は、[無料] (Free) では設定できないので、コンピューティングの Plan を [共有] (Shared) 以上に変更してください。

補足 : Azure では DNS のサービス (カスタム ドメインを取得可能なサービス) はないので、ドメインそのものは外部 (3rd party) のレジストラーなどで取得し (レコード設定、アリアス設定など必要な設定をおこない)、この取得したドメインにあわせて Azure Web App を設定します。

なお、カスタム ドメインを設定した際の EC-CUBE 側の設定変更ですが、結論を書くと何も設定変更する必要はありません。
data/config.php を見ていただくとわかりますが、内部で使用される HTTP_URL、HTTPS_URL の値は動的に取得しており ($_SERVER[“SERVER_NAME”] を使用)、アクセスする URL により動的に変更されるためです。

また、カスタム ドメインを設定しても、元のドメイン (*.azurewebsites.net) は使用できますので、Web.config に下記の通り記述してカスタム ドメイン以外の接続はできないように構成しておくと良いでしょう。
下記では、URL Rewrite Module を使用して、「ホスト名が *.azurewebsites.net なら 404 (Not Found) のエラーを返す」という設定を記述しています。(Apache の場合は、.htaccess に同様の設定を記述します。)

<configuration>  <system.webServer>    . . .    <rewrite>      <rules>        <rule name="DomainCheck" stopProcessing="true">          <match url="(.*)" ignoreCase="true" />          <conditions logicalGrouping="MatchAll">          <add input="{HTTP_HOST}" pattern="^(.*).azurewebsites.net$" ignoreCase="true" />          </conditions>                    <action type="CustomResponse" statusCode="404" />        </rule>      </rules>    </rewrite>  </system.webServer></configuration>

カスタム ドメインで SSL (https) を使用する場合、証明書の作成とアップロードも必要になるので注意してください。(*.azurewebsites.net で SSL を使用する際には Microsoft が提供する証明書が使用されますが、カスタム ドメインではこの証明書は使用できないためです。) なお、プライベート CA が発行する証明書は Azure Web App の証明書として使用できないので注意してください。

メール (SMTP) サーバー

EC-CUBE ではインストール時に SMTP の設定が必要ですが (もちろん、あとから設定することもできます)、Azure の Marketplace を使用すると、SMTP のサービスとして SendGrid が使用できます。GMail や Exchange (Outlook) のような個人メールのサーバーとは異なり、Click 統計の取得や、送信ドメイン認証など、まさにこうしたメール システムに適したサービスです。

Azure Web App や ClearDB 同様、わざわざメール サーバーを立てる必要はなく、また、SendGrid にも無料の Plan があるので、開発・テスト目的など Light にスタートできます。(実運用の際には、有償 Plan を使ってください。)

成果物 (ソースコード、データベースなど) の移行

EC-CUBE の環境移行は、基本的には、EC-CUBE 本体 (PHP のソースコード) とデータベースを移行して、EC-CUBE 側のデータベースの接続先を変更すれば動作します。
テスト環境から本番環境への移行や、ソース管理をおこなっているリポジトリからの本番移行、後述する Azure Virtual Machine (仮想マシン) に移行する場合など、簡単に移行できます。

補足 : ただし、Apache 上の PHP 環境に移動する場合には、Web.config ではなく .htaccess を使って書き換えてください。また、「IIS で PHP の ob_* 関数が効かない場合の対処法」で 紹介しているような書き換えをおこなっている場合は、移行先で使用する PHP のバージョンにも注意してください。

EC-CUBE 本体 (PHP のソースコード) ですが、Azure Web App は Git プロトコルに対応しているため、カスタマイズした EC-CUBE のソースは、ローカル環境、Github など、さまざまな場所に迅速に移行でき、相互運用できます。これについては「Azure Web App の Git 活用」で手順を紹介しましたので参考にしてください。

また、データベースも、ローカル環境に MySQL のユーティリティをインストールし、以下のコマンドを実行すれば環境間を簡単に移行できます。

cd [My SQL install path]/bin// dump database to filemysqldump -u [username] -p[password] -h[host name] [db name] --add-drop-table > [save file path]// restore object to database from dump filemysql -u[username] -p[password] -h[host name] --default-character-set=utf8 [db name] < [read file path]

例えば、ある ClearDB のデータベースから別の ClearDB のデータベースにオブジェクトをコピーする場合、以下のような感じです。

cd C:\Program Files\MySQL\MySQL Server 5.6\binmysqldump -u aaaaaaa -pxxxxxxx -hja-cdbr-azure-east-a.cloudapp.net eccubetestdb --add-drop-table > C:\tmpdb.sqlmysql -ubbbbbbb -pyyyyyyy -hja-cdbr-azure-east-a.cloudapp.net --default-character-set=utf8 cdb_test < C:\tmpdb.sql

さらなる応用 ～ Going beyond

Azure Virtual Machine (仮想マシン)

高トランザクション、高パフォーマンス、高信頼などの「要件」に応じて、より厳密な構成が必要な場合、いわゆる OS (Windows, CentOS, Ubuntu 等) から環境設定をおこなう Azure Virtual Machine (仮想マシン) も検討してください。
Azure Web App と異なり (OS のレイヤから構成するため) 運用負荷は高くなる一方、構成の自由度が享受できます。
Azure Virtual Network (仮想ネットワーク) と組み合わせたネットワークも含むインフラ全体の構成や、Azure Web App 上の EC-CUBE から Azure Virtual Machine 上の MySQL を使用するといったへトロな構成も可能です。

例えば、データベース (MySQL) については、上述の通り ClearDB は定額で扱いやすいというメリットがありますが、パフォーマンス、データサイズ、同時接続数などの制限があります。また、マルチマスター、シャーディングなどの構成も不可能です。

補足 : ClearDB も複数リージョン (東日本と西日本など) の active/active な構成で動作していますが、双方の read/write (負荷分散) が前提ではなく、Primary が存在します。(高可用性を担保するための構成です。) なお、上述の 占有プラン (Dedicated/Private Plan) には Read/Write Scaling Support を提供するものもあります。

同様に、アプリケーション (EC-CUBE) 側も、nginx や HHVM を使用するケースなど、さまざまなケースで Azure Virtual Machine (仮想マシン) の選択が考えられます。

Blob Storage

上述の通り、既定の設定では、商品画像などのバイナリ データは PHP などのプログラムが入っている領域と同じディスク上に保存されます。
本来、こうした「データ」は「プログラム」とわけて構成 (IO キャッシュ、ディスクの冗長化方法など) や運用 (バックアップなど) をおこなうべきでしょう。

Azure には、こうしたデータを扱うための専用の Storage サービスが提供されています。例えば、バイナリ データを保管できる Azure Blob Storage を使うと、キャッシュ方法、監視・ログの設定、地理冗長化構成、セカンダリーの読み取り専用領域としての使用、スナップショットと組み合わせたバックアップ等々、さまざまな構成と運用が可能です。
特に、Azure Virtual Machine (仮想マシン) を使用する場合、上述の Azure Web App と異なり、既定ではインスタンス間でディスク共有されないため、こうした画像データの管理方法の検討は必要不可欠です。

EC-CUBE で Azure Blob Storage を使用するサンプルを「EC-CUBE の商品画像を Blob Storage で管理する (Azure)」に記載しましたので参照してください。

Database

データベースのもう 1 つの選択肢として、Azure の SQL Database を使用することもできます。
ClearDB が MySQL ベースの DBaaS (Database as a service) であるのに対し、Azure SQL Database は SQL Server ベースの DBaaS であり、例えば、DTU (Database Throughput Unit) による性能保証や、最長で 35 日以内の任意の時点に戻せる Point in Time Restore など、ClearDB と比較しても、よりスケーラブルで高信頼な Plan を選択可能です。(その分、料金は高くなってしまいますが。。。)

また、プラグインをインストールすることで EC-CUBE の接続先として SQL Database を使用できます。
なお、プラグイン (EC-CUBE プラグイン) によっては、SQL Database に対応していないケースもあるようなので、周辺の細かなプラグインを入れる際には注意してください。

Session / Cache

前述の通り、既定の設定では、Session 情報も永続データと同じ MySQL を使用しますが、Azure が既定で提供している Redis Cache のサービスをセッション管理に使うと、データベース (MySQL) への負荷も軽減できるでしょう。

Redis Cache は Azure にビルトインされたサービスなので、わざわざ Redis 用のサーバーを立てる必要はありません。EC-CUBE における Redis 利用の手順は「EC-CUBE の Session を Redis に変更する (Azure)」に記載しましたので参照してください。

まずは、実運用で必要になる基本的な内容をザッと解説しましたが、Azure の各種サービスを使えば、さらに横の広がり (付加価値) を持たせることもできます。(例えば、Azure Virtual Network を使った企業内資産との連携、連携用のバッチジョブ、Azure Machine Learning による消費行動分析、CDN の使用、などなど)
EC サイトでは、小さな商店から、著名店舗のネット販売まで幅広いニーズがありますが、上述の通り、Azure を活用して、超ライトな構成からミッション クリティカルな構成まで柔軟に対応してください。

なお、構成検討や動作に際して EC-CUBE エバンジェリストの大河内さんにいろいろとアドバイスをいただきました。ありがとうございます！

※ 変更履歴

2015/03/26  responseBufferLimit に関する設定を追記。Azure WebSite から Azure Web App に名称変更。詳細の手順は、他の投稿への誘導を設定。

2016/07/19  Visual Studio Online (Monaco) から App Service Editor に名称変更