健康食品や医薬品などをインターネットで販売するEコマースサイト「ケンコーコム」（http://www.kenko.com/）を2000年から運営 しています。 18万点以上の商品を取り扱っている国内最大級の健康関連ECサイトです。PCサイトだけではなく、モバイル・スマートフォンの自社サイトも運営していま す。また、楽天市場等のモールにも出店するなど、様々なチャネルを運営しております。
ケンコーコムは、2011年３月11日の東日本大震災を機に、安定的事業運営の構築を目指して、オンプレミス（自社運用）のサーバーシステムからクラウド対応のシステム構築に着手し、2011年内にAWSへの移行を完了いたしました。
その後、当社は商品数・顧客数の増加に伴い拡大している業務の効率化と安定化に向け、企業全体を統合的に管理する基幹システムとなるSAP ERPの導入を進めていくにあたり、AWS上でSAP ERPを導入しました。これはリスク分散・BCPという意図だけではなく、ケンコーコムの速いビジネススピードにあわせた選択でした。
2011年のオンプレミス（自社運用）からクラウドへのシステム移行で、既に活用メリットを実感していました。そのため、新規のシステム導入に際し てはAWS を検討することは自然なことでした。但し当時AWS がまだSAP ERPの認証プラットフォームではなかったため導入には慎重な判断が必要でしたが、長期的視点に立って考え、将来の二重投資を回避するために稼動時から AWS 利用を決定しました。
商品数・顧客数の増加のスピードが一段と速まったこともあり、SAPの導入期間の長期化は許されない状況でした。その中でリードタイムの長 いハードウェア調達は進捗のボトルネック要素でした。そこで最初にプロトタイプ環境としてAWS を利用したのですが、結果としてもすばやく要件定義を実施 でき、短納期で稼動させる自信にもつながりました。
当社では、2009年に商品画像送出用にS3を活用し始めたのをきっかけに、AWS の活用範囲を広げています。
その後、2011年には、自社サイト（PC/モバイル/スマホ）、モール上支店連携システム、在庫管理システム、ドロップシップ販売管理システム SAP ERPプロトタイプ・開発環境でAWSを採用しており、2012年には、SAP ERP本番環境をAWS 上で稼働開始しました。また、データウェアハウスとしても利用させていただいています。
「ケンコーコム株式会社様 システム構成図」
SAP導入にあたっての要件定義フェーズではAWS上でプロトタイプ環境を構築し、その後開発環境として引き続き利用しました。テストおよび移行フェーズ では、テストを並行実施するため、作成したAMIから別インスタンスを起動し、SAPの移送により環境の同期をとることで期間の短縮を実現することができ ました。さらに、サーバーを占有してしまうデータ移行リハーサルでは、テスト環境と別インスタンスを作成し、環境の準備で開発が滞るような状況を回避でき ました。
なお、データ移行本番時は、一時的にインスタンスサイズを2xLargeから4xLargeに変更し、処理時間を短縮できた結果、システム停止時間を最小限にすることができました。
AWS のソリューションパートナーであるアイレット社のcloudpackを通じて、AWS Support の「ビジネス」を利用させていただいております。
導入にあたって初期導入費と5年間の運用費の合計額で比較を行った結果、AWS 利用の場合、オンプレミスと比べて６５％削減することができました。
ハードウェアを購入していないため、当然ですが初期投資は大幅に圧縮できました。これにより、アプリケーションの開発面ではシステム化の範囲において妥協することなく当初目的を達成することができたと思います。
ハードウェアを購入する場合、ビジネス拡大を見越して余裕をもったサイジングをしますが、その結果不要なパワーを備えたマシン購入に多大なコストがかかり ます。一方、AWSではビジネスの拡大にあわせたサイズアップができるため、過剰な余裕は必要ありません。安定稼動後に開発用インスタンスはAMIを作成 して一旦停止するなどの対策も考慮すると、運用コスト自体はそれほど大きな差はないという認識です。
データウェアハウスなど情報系のシステムでは、蓄積するデータ量・種類は増加する一方となるため、柔軟にサイズを拡張できるAWSは利用価値があると考えています。このため今後、ビッグデータ対応も検討しています。
オンプレミスでは、ハードウェアの調達リードタイムや、サーバーサイズの固定化により、プロジェクトリスク回避の選択肢が限られます。一方、AWS を利用することによって、ハードウェア調達を待たずにプロトタイプ環境での要件定義や技術検証を開始でき、リスクを早期につぶすことができるのは大きな利 点だと考えています。
また、プロジェクト終盤には、テストやデータ移行準備などでサーバー利用の要求が急激に高まり、開発者に待ちが生じたり、夜間シフトなどで負担を強いられ ることが多くなります。AWS の場合、複製した環境を並行して稼動させることが可能だったため、プロジェクトは遅延なく進めることができ、予定通りにシス テムを稼動させることができました。
また、オンプレミスの場合サーバーのサイジングはプロジェクトの最初に行うことになりますが、その時点ではシステムの概要しか決まっておら ず、ハードウェアのマシンパワーについての精密な検討は困難です。このため必要マシンパワーの見積もりの際には、余裕をもった上で、さらに安全性を加味し て必要以上に大きなマシンを選定するケースも多いのではないかと思います。しかしながら、稼動してみたらリソースが余剰になり、無駄が多いということもよ く耳にします。AWS の場合、常に現状に合わせて適切なコストで運用することができるので、無駄な初期投資を回避し、継続的に運用コストを適正化できると 考えています。