従量課金モデルを採用したPaaS型の新しいタイプのECプラットフォームを提供するCommerbleは、Microsoft Azureを中心に、AWSやCIツール、プロジェクト管理ツール、ソースコード管理ツールを連携させることによって、継続的に進化を続ける質の高いECサービスの提供に成功している。その舞台裏を聞いた。
「受注した注文数に応じて利用料金を支払うだけで、質の高いECサービスを利用できる」。読者の皆さんは、まさに「使った分」の料金を支払うだけで利用できる、新しいタイプのEC特化型PaaSプラットフォーム・サービスが提供されていることをご存じだろうか。
クラウドが普及する以前は、事業者がECシステムを導入する際には、自社でインフラを準備してスクラッチで、あるいはパッケージソフトを使って、ECシステムを構築するか、ASPやSaaSを利用するしかなかった。しかし、自社でシステム構築を行うと、ECアプリケーションの構築・運用だけではなく、サーバやOS、ネットワークなどのインフラの構築や運用、セキュリティ対策、チューニングなどに膨大なコストが必要になる。また、ASPやSaaSを利用したとしても、自社固有の業務や仕様に柔軟に対応できず、「インフラを自由に制御できない」「ビジネス環境の変化に迅速に対応できない」という問題があった。
ECビジネスは日々変化を遂げている。このため、これまでのやり方で、せっかく高いコストを掛けてECシステムを構築しても、稼働を開始するとすぐに陳腐化が始まり、わずか数年で時代遅れになってリプレースを余儀なくされるケースも少なくない。場合によってはプラットフォームごと破棄しなければならないことさえある。
こうしたECシステムの課題をいかに解決し、システム全体の開発・保守・運用を効率化し、コストを最小化できるのか。Commerbleでは、クラウドを駆使したEC専用のPaaSプラットフォーム「Commerble EC PaaS」を提供することにより、EC事業者が抱える課題を根本的に解決することを目指している。
EC事業者は、このEC PaaSを利用することによって、サーバやOS、ネットワークなどのインフラはもちろん、セキュリティ対策や運用監視などのことを意識することなしに、ECサービスを安心して利用できる。しかも、受注件数に応じた従量課金モデルを採用しており、EC事業者は、コスト面でもシステムの増強や機能強化を意識する必要がなくなる。
EC PaaS提供の意義について、Commerbleの竹原貴司氏は、「クラウドのメリットを最大限に生かして、EC事業者に対して機能や性能の向上を永続的に提供できる新しいスタイルのECプラットフォームを提供したいと考えた。EC事業者からシステムの改善に関連する費用を安易に徴収するのではなく、できるだけ負担を軽減することに努力しながら質の高いサービスを提供することを目指している」と強調する。
一口に従量課金モデルを採用したPaaS型ECプラットフォームと言っても、その実現は決して簡単なことではない。Commerbleはもともと、5年前にオンプレミス環境で稼働するECシステムを開発していたが、それを多くのEC事業者が同時に利用するマルチテナント環境で稼働させるためには、高い能力と性能を備えたサーバリソースが必要になる。そのため、2年前にクラウド上に置き換え、「Commerble EC PaaS」として提供を開始した。
しかし、ECプラットフォームの性能をクラウドリソースだけに求めようとすると、その分コストも高くなってしまうため、必然的に提供するECサービスの利用料金も高く設定せざるを得なくなる。それでは、十分な競争力を確保することはできない。
そこで重要になってくるのが、ECエンジンを含むECサービスの開発・保守・運用を効率化すること。マルチテナント環境のECプラットフォームにおいては、サービス提供の効率向上がコスト削減に大きく寄与し、利用料金の値下げにつながるからだ。また、サービスを安心して使ってもらうためには、クラウド環境を使い分けるなど耐障害性を実現しておくことも欠かせない。
ECエンジン開発の当初から開発に携わってきた竹原氏は、「ECサービスの性能を高めることがわれわれのビジネスにとって命綱になる。クラウドリソースに多くのコストを掛けなくても、われわれの知恵と努力でプログラムの開発・保守作業を効率化し、改善することによって性能を高めることができる」と力説する。
ではEC PaaSの舞台裏では、サービスや機能の開発・保守・運用を、どのように効率化、最適化しているのだろうか。
EC PaaSの構築に当たって、Commerbleが最初に取り組んだのがCI(Continuous Integration)サーバの導入によるプログラムのビルドやデプロイの自動化である。
というのも、以前のオンプレミスのECシステムでは、ソフトウェアのビルドやデプロイの管理はEC事業者ごとに半自動で行い、デプロイのバージョン管理などは手人力で行っていた。しかし、単一のPaaS上で多くのEC事業者に対してサービスを提供するマルチテナント環境では、それぞれのテナントごとにデータベースや接続モジュールなどの構成が異なり、サービスの機能改善やリファクタリング、チューニングなども個別に行う必要があるため、手作業での管理は困難である。しかも、以前のシステムよりも少人数で開発や運用に当たらなければならなかったため、CIサーバの導入によるビルドやデプロイの自動化が不可欠だった。
しかしCommerableの渡邉寛之氏によると、最初に導入したCIツールは、それまで使用していたソース管理ツールのBitBucketとの連携を実現できなかったため、プロジェクトの管理が複雑になり、かえって事務作業が増える事態になったという。
そこで、白羽の矢が立ったのがアトラシアンが提供するプロジェクト管理ツールのJIRA Softwareである。同ツールは、アジャイル開発に対応するチケット駆動型の課題管理を実現するものだ。Commerbleではプログラムの開発・保守・運用の効率化、ビルドやデプロイの自動化を実現するのに、このJIRA Softwareを核に、CIツール「Bamboo」、ソース管理ツール「BitBucket」、チャットツール「HipChat」を連携させて利用している。なお、HipChatについては、ビルドの実行やデプロイの完了といった通知のみに使用しているという。
JIRA Softwareなどのアトラシアン製品を採用した理由について、渡邉氏は「ビルドやそれに連なる処理は、全てチケットでひも付けて統一的に管理し、記録しておきたいと考えた。そうしておけば、例えばどのビルドがどこまでリリースされているかなど、開発作業全体をトラッキングし、“見える化”できる。またどのタイミングでも切り戻しを行うことも可能になる」と説明している。
このように、Commerbleでは、ツール連携によって、プログラムのビルドやデプロイの自動化と作業の見える化を実現しているが、テナントのプロダクション環境へのデプロイに関しては、自動ではなく、必ず人が確認した上で行うようにしている。また、実際のデプロイの実行は、外部ネットワーク上のターゲットにデプロイすることを考慮して、エージェントを介して非同期で行うようにしている。そのため、CIツール(Bamboo)上ではターゲットファイルをキューに入れた段階で処理が完結し、プロダクション環境へのデプロイが最終的に終了したかどうかはHipChatで最終確認している。これにより、自動化できるところは極力自動化するという効率性に加え、人の運用による安心感を担保しているのだ。
EC PaaSの性能を支えるもう1つの重要な要素は、パブリッククラウド側のリソースである。
EC PaaSでは、仮想サーバにはMicrosoft AzureのAzure VM、データベースにはAzure SQL Database、VPNにはAzure VNet、プロビジョニング用ストレージにはAzure Storageを採用。またオリジン用CDNにはAmazon Web Services(AWS)のAmazon CloudFront、DNSにはAmazon Route53、ログアーカイブにはAmazon S3を採用している。その他に、パフォーマンス監視サービスとしてNewRelic、ログ監視サービスとしてLogentriesなどを使用している。
パブリッククラウドのサーバリソースとしてAzureを選んだ理由は、データベースとしてSQL Serverを利用することを前提の上で、AWS上のSQL Serverよりも、Azure上のSQL Databaseの方が一日の長があったからだという。この点についてCommerbleの谷口慈行氏は、「AzureのマネージドデータベースサービスであるSQL Databaseは、運用の楽さと、フェイルオーバーなどの復旧の速さでAmazon RDSに勝っていました。DTU(Database Throughput Unit)単位でフォーマンスチューニングすることが可能になり、『Azure エラスティック データベース プール』などマルチテナント向けの機能も登場しました」と利点を説く。
一方、EC PaaSのWeb処理を高速化するオリジン用CDN(コンテンツ配信ネットワーク)サービスとしてはAmazon CloudFrontを採用している。これはEC PaaSに適用しやすいという利点だけではなく、サーバとCDNを異なるクラウドに分けることによって、ある種の耐障害性を実現できるという利点がある。なお、リソース用CDNサービスとしてはkeyCDNを採用しており、CDNコストのさらなる削減を図っている。
従量課金モデルを採用した新しいタイプのPaaS型ECプラットフォームだが、少なくとも現時点においては、費用対効果が大きいのは中大規模系のECで、小規模系のECには効果は大きくない。例えば、月間注文が2000以上の規模だと1受注ごとに100円の料金、月間注文が5000以上になると1受注ごとに50円の料金となっている。大規模系のECが1受注当たり50円のコストとなれば効果は非常に大きい。一方、月当たりの受注数が2000件以下の場合は固定で20万円となっており、このケースでは月間2000受注以下の顧客は1件単位が100円以上になる。
しかし、商品単価と受注数が条件にマッチするテナントであれば、EC PaaSのサービスを利用することによって大きなメリットを享受できる。プラットフォームのサーバやOSの開発・運用のコストのことを考える必要もないし、アップデートや不具合について心配する必要もない。もちろん、アクセスの急増によるネットワーク障害の回避やネットワークリソースの確保についても全く心配する必要はなく、24時間365日の運用も保証されている。また、パッケージ費用やテンプレート費用、アプリケーション保守費も不要であり、セキュリティ対策やシステム監視に煩わされることもない。これらの全てがサービスにインクルードされているのだ。
前述したようにCommerbleでは、プログラムのビルドやデプロイの自動化と、作業の見える化によって、DevOpsの環境を実現している。そして、こうした基盤を整えながら、日々パフォーマンスのチューニングに取り組んでおり、現時点で既に同時受注件数4000件/分という高い受注性能を実現している。クラウドリソースを増強することなしに、この性能をさらに高めることができれば、テナントの数をさらに増やすことが可能になり、利用料金もより低く抑えられるはずだ。
竹原氏は、EC PaaSのビジネスの今後の方向性について、「利用者が料金を支払った分だけサービスを提供するビジネスが成立する実例を示すことによって、このモデルをソフトウェアのさまざまな領域に普及させていきたい」と展望を語っている。
およそ全てのビジネスをITが支えている今、「ビジネス展開にリニアに連動した開発・運用」を実現できるか否かが、「差別化」のカギを握っていると言ってもいいだろう。だが、「ビジネスと開発・運用が連動する」と言葉で言うのは簡単だが、現実はそれほど単純ではない。差別化のためにはスピーディな開発・リリースが大前提。しかしニーズにかなったものでなければ意味がない以上、要件変更にも柔軟に対応できることが求められる。
このためには関係者間の密接かつ正確なコミュニケーションが不可欠だが、立場や観点、使っている言葉の違いなどからすれ違いが生じ、プロジェクトはいつしか足並みが狂い始めるの通例だ。では一体どうすれば、「差別化」に役立つシステムをスピーディかつ柔軟に作れるのだろうか?――プラクティスやツールの効用を生かし切る、「アジャイル時代のプロジェクト管理」の要件を今明らかにする。
Copyright © ITmedia, Inc. All Rights Reserved.