EC-CUBE構築編

はじめに

2011年は、多くのECシステムがクラウドベースに刷新された年でした。EC-CUBEにおいても「EC-CUBE クラウドサーバ」がリリースされたり、「⁠ニフティクラウド」がEC-CUBEに標準対応するなど、クラウド化の波が押し寄せています。

しかし、これらの多くはIaaSをベースに構築されたものであり、Webサーバやデータベースを冗長させたり、その上でEC-CUBEを動作させるためには、それなりの専門知識が必要です。

EC業界にはEC-CUBEという手軽に利用可能な、素晴しいオープンソースパッケージがあり、まだβ版ではありますがWindows Azure対応のパッケージも公開されています。これをベースにカスタマイズすれば、専門知識のないユーザにも簡単に利用できるのではないか？と思いました。

そこで、EC-CUBEのコアコミッタであり、EC-CUBE公式エヴァンジェリストの私が自社で運用しているサイト「エクセス」をWindows Azureに対応させてみました。

ECにおいて、Windows Azureを使用するメリットは、運用コストの削減や、抜群のスケーラビリティ、SQL Azure Reportingを使用したBIツールとの連動などが挙げられます。

とくに、タイムセールなど、瞬間的なアクセス増に対応するため、Windows Azureでは簡単にインスタンス数の増減ができ、大変魅力です。

また、基幹システムをWindows Serverベースで構築している企業も多く、既存資産も活用できます。

デメリットはといえば、まだ運用実績が少ないこと、SLA の稼働率がやや低い（99.95％）ことでしょうか。

Windows Azure自体、2010年2月に商用サービスが始まったばかりですので、これから改善されていくと思われます。

Windows Azure対応について

CodePlexにて、EC-CUBE on Windows Azureというパッケージが公開されていますので、今回はこのパッケージをベースに、実際の運用に耐えうるようカスタマイズしました。CodePlexにも公開していますので、よろしければお試しください。

http://eccubeonwaz.codeplex.com/releases/view/85751

EC-CUBE on Windows Azureで対応されているもの

EC-CUBE on Windows Azureでは、主に以下のような対応をされています。

SQL Azure対応

EC-CUBEは、PEAR::MDB2というデータベース抽象化ライブラリを使用しており、データベースごとの振舞いについては、大部分をこのライブラリが吸収してくれます。

まだベータ版ですが、SQL AzureにアクセスするためのMDB2_Driver_sqlsrvがありますので、こちらを使用しています。

しかし、DDLや細部のSQLについてはPostgreSQL/MySQL用のSQLを使用していますので、SQL AzureのSQLに書き直されています。

また、更新系のSQLの文字型にはNプレフィックスをつける必要があり、MDB2_Driver_sqlsrvのパッチを作成して対応されています。

SQL構文の修正

LIMIT/OFFSET

MDB2::setLimit()を使用。サブクエリで使用している場合は、SELECT TOPに書き替え

自動採番

MDB2のシーケンス機能を使用

USING句

ON句に書き替え

DATE()

CONVERT(varchar(10), getdate(), 111) に書き替え

TO_CHAR()

CONVERT(varchar(10), getdate(), 111) に書き替え

ILIKE

LIKEに書き替え

php_azure.dllの使用

Windows Azure - PHP Contributionsにて提供されるphp_azure.dllを使用し、データベースの接続情報などを、サービス構成ファイル（ServiceConfigration.cscfg）に記述できます。

これにより、再デプロイの必要なく設定情報を変更できます。

タイムゾーンへの対応

標準のEC-CUBEはタイムゾーンに未対応ですので、PHP5のDateTimeクラスを使用して、タイムゾーンへ対応しています。

本格運用のための対応

EC-CUBE on Windows Azureは、まだβ版ですので、本格運用のために以下のようなカスタマイズを実施しました。

EC-CUBE 2.11.5へのアップグレード

EC-CUBE on Windows Azure は EC-CUBE 2.11.3 がベースとなっていますので、ベースのバージョンを 2.11.5 へアップグレードしました。

Windows Azure Blob対応

すでにEC-CUBE on Windows Azureで対応がされていますが、直接Blobのデータを参照するため、トランザクション費用がかかってしまいます。

また、画像の縦横サイズが取得できず、様々な画像サイズへの対応ができません。

このため、EC-CUBEの管理画面からアップロードする商品画像や、ヴィジットのテンプレートなど、運用中に動的に追加されるファイルはWindows Azure Blobに格納し、各インスタンスでキャッシュするようにカスタマイズしました。

SMTP AUTH

Windows Azureには、SMTPのサポートがありませんので、EC-CUBEをSMTP AUTHに対応させ、外部のSMTPサーバを使用するようにしました。

URLRewrite

SEO対策のため、 URLRewriteを使用して簡潔なURLでアクセスできるようにしました。

決済モジュールのインストール

標準のEC-CUBEは、クレジット決済などに対応するための決済モジュールを、オーナーズストアにて購入し、EC-CUBE の管理画面からインストールします。

Windows Azureでは、動的に追加したファイルは永続化されないため、この方法が使えませんので、決済モジュールの管理画面をカスタマイズし、デプロイするパッケージに含めるようにしました。

構築のまとめ

デフォルトのEC-CUBEがPostgreSQL/MySQLに依存しているため、SQL Azureに対応するには、相応の労力が必要でした。

しかし、運用面ではPaaSならではの利点が活き、多くの恩恵を授かることができます。

これらの利点を活かすことによって、従来とは一線を画した、次世代 EC システムを構築できると確信しています。

Windows Azure自体も急速に進化していますので、今後の展開にも期待です。

EC-CUBE運用編

EC-CUBE 構築編では、Windows Azureを使用することで、どのようなメリットがあるかを検証しました。

では、実際に運用した場合、どのようなメリットがあるか、とくに価格面を検証してみたいと思います。

価格の見積

Windows Azure料金計算プログラムを使用して、運用時の見積を算出しました。

今回の運用では、以下のような構成を使用しました。

• XS (1GHz CPU、768MB RAM、20GB ストレージ) 2インスタンス
• SQL Azure データベース 1GB
• Windows Azure Blob ストレージ 1GB
• ネットワーク(アジア太平洋地域) 150GB

PHPアプリケーションのフロントエンドは、CPUのスケールアップよりも、複数インスタンスで稼働させたほうが、一般的に効果が高いため、XSインスタンスの2台構成としました。

アプリケーション側でキャッシュを作成し、Blobストレージへのトランザクションを極力抑えるようにしたため、ごく僅かしか発生しませんので、見積から除外しました。

ネットワークのデータ送受信量に関しては以下のような見積をしました。

1ヵ月あたり50万PV×1ページあたり平均サイズ0.3Mバイト。

上記を合計すると、日本円で5,996.72円となりました。

レンタルサーバーと比較して

物理ホストのレンタルサーバーで、同様の環境を構築することを想定してみます。

それぞれ2台以上に冗長化されたWebサーバとDBサーバを構築すると、月間数万円以上のレンタル料金は免れないと思われます。

VPSを使用すれば、安価ですが、繁忙期には台数を増やし、閑散期には台数を減らすといった運用が難しく、 Windows Azureに軍配が上がります。

また、データベースを冗長化するには、高度な技術を必要とするため、多くのコストが発生します。

他のクラウドサービスと比較して

IaaSスタイルのクラウドサービスで代表的なAmazon Web Servicesと比較してみます。

見積にはSimple Monthly Calculatorを使用しました。

データベースにはSQL Azureと競合にあたるAmazon RDS for MySQLを使用しました。

為替は1ドル＝80円で換算しました。

• m1.micro 2インスタンス
• Amazon RDS for MySQL Small Multi-AZ 2インスタンス 1GB 500万回リクエスト
• Amazon Elastic Block Store 1GB
• ネットワーク 150GB

上記を合計すると53,448円にもなりました。

このうち、Amazon RDSのコストが4万9,689円を占めていますので、Amazon EC2を使用して、自前でMySQLを冗長化すれば1万円未満で実現可能と思われます。

しかし、その分高額な人件費が必要になるため、Windows Azureのほうが迅速かつ安価に運用可能です。

料金の比較

このように、Windows Azureを使用することで、優れたパフォーマンスを維持しつつ、運用コストを大幅に削減することが可能です。とくに、データベースやネットワークに係わるインフラ構築/運用コストは、限りなくゼロに近づき、従来と比較して90％以上の削減ができました。

また、オンプレミスのWindows Serverと比較した場合、Windows Updateに関する運用コストが発生しますが、 Windows Azureでは、自動でWindows Updateも行われるため、常に最新の安定した環境を、安全に運用できます。

運用時の対応について

LAMP環境でサービス運用しているユーザの多くは、普段Windowsを使用していると思います。このようなユーザにとって、同様のインターフェースで安定した運用ができれば、多くのコストが削減でき、アプリケーション開発など、本来すべき作業に集中することができます。

私自身、普段はMac OS Xの環境でEmacsを使用して開発しており、日常作業の多くはコマンドラインで済ませてしまいます。

Windows Azure SDK for PHPは、コマンドラインでの操作もサポートされており、bashスクリプトも付属しているため、パッケージングなどの定型作業にも、従来のスキルを活用することができました。

Windowsユーザでしたら、既存の多くの資産を活用でき、LAMPユーザでも、従来のスキルを無駄にすることなく、Windows Azureを使用できます。運用ノウハウやドキュメントなども急速に整いつつありますので、LAMPユーザにも安心してお勧めできます。

日々のアプリケーション保守については、デプロイに時間がかかるため、計画的に行う必要があります。あらかじめ、ステージング環境にデプロイする日時を決めておき、逆算して保守内容を決定します。ステージング環境では、本番環境のデータベースの複製を使用して、検証を行います。

問題がなければ、サービス構成ファイル（ServiceConfigration.cscfg）に記載しているデータベースの接続情報を更新し、VIPスワップを使用して本番環境へ公開しています。

Windows Azureの良い点、悪い点

ほかにも、BIツールであるSQL Azure Reportingや、 大規模運用に対応するためのWindows Azure CDNなど、ECビジネスに活用できる機能がたくさんあります。Windows Azureを活用することで、多くの技術的な課題を解決することができ、新たな技術開発に取り組むことができます。

デプロイ作業は、一見時間がかかり、面倒に思えましたが、アプリケーションの品質向上に一役買ってくれました。SQL Azureによって、いつも悩みの種だったデータベースの運用コストが大幅に削減できました。

悪い点は、デプロイやツールのインストールなど、1つ1つの作業に時間がかかること、まだ実際の運用実績が乏しいため、多くの自己解決能力が必要というところでしょうか。

しかし、これらは急速に解消されつつあります。

これからもWindows Azureを活用し、次世代のECシステムを成功に導いていきたいと思っています。