- 重要な個人情報は独自サーバーで管理するためセキュリティ対策も万全。
- キャンペーン告知などで集中アクセスが発生してもサーバーがダウンせず、顧客を逃がさない。
- 空きリソースの費用が発生しないため、ランニングコストを抑えることが可能。
- 「ＥＲＳ v6」を使用することにより柔軟なデザイン変更及び細かいカスタマイズも実現。
- 世界標準の決済（24通貨に対応）「PayPal」との提携により、世界の消費者を顧客とすることが可能。
- コールセンター、商品管理から物流システムとの連携のよりトータルソリューションでの提供。
従来のインフラ構成は、MAX時を想定して設計が必要でした。
しかし、ピーク時のみクラウド環境を増設することにより、平常時のインフラコストを削減することが可能です。
クラウドを活用した増設／解約
インフラ環境の増設／解約が短い期間で対応が可能です。
インフラの縮尺は月額予算を設定すれば、分単位にて自動制御可能になります。
又、クラウドのベースにGoogle App Engineを利用すればインフラの縮尺は全自動で行われます。世界最大規模のデータセンターを保有するGoogleの設備を利用する事で、瞬時のピークアクセスも楽々とこなせます。
しかも従来のデータセンターの常識を覆す驚きの低価格です。
クラウド環境の増設に関する特徴
- 必要量のみを増設できる。
- 急激なアクセス増加も最短１時間程度で増設対応可能。
- キャンペーン等が終了次第、解約可能。
キャンペーン時に負荷が大きい部分のみをクラウド環境へ
通常、アクセス量（トラフィック）が大きいのは、カートに入れる前のトップページから商品情報までになります。こちらのページでは、個人情報の取り扱うケースは少なく、通常ＳＳＬ等のセキュリティ対策の必要はありません。
個人情報を取り扱うページのみのインフラ環境は、セキュリティや保存の保護のため、一般的なサーバー構成が必要ですが、もっともインフラ費用がかかっていた部分がクラウドになるため、大幅なコスト削減が可能になります。個人情報入力等のアクセス数が軽減されるページでは専用サーバー上で処理を行います。セキュア情報をやりとりするサーバーは、専用サーバー内で行なうため、セキュリティの担保も可能です。
セキュリティを確保するページおよびデータベースは、クラウドを利用しません。
IVPデータセンター内によって、セキュリティを確保します。
クラウドサービスは歴史的に浅く、セキュリティやデータ保存については長年に渡る実績を提示できない状況にあります。したがって、個人情報が関わる部分などセキュリティが必要な部分は「アプケーション」「データベース」を問わず、すべてIVPサーバーで独自保持するように致します。
現在、ERS.クラウドではベースとなるクラウドシステムに
（１）Google App Engine （PaaS型クラウド）
（２）NIftyクラウド （IaaS型クラウド）
のどちらかを選択する事が可能です。
PaaS型のGoogle App EngineではGoogleが定めるアプリケーション制作上の制約の範疇にあれば、インフラの縮尺は全自動で行われ事前申請の必要はありません。すべての最適化をGoogleが行ってくれます。又、拡大時には予め定められた上限予算の範疇で従量課金が発生しますが、従来のデータセンター常識にはない低価格です。しかしながら、Google App Engineではアプリケーション制作の制限が多く、どんなアプリケーションでも制作できる訳ではありません。一方でIaaS型のNiftyクラウドはインフラの縮尺は事前申請が必要です。ただし、申請して３０分後には使えるようになりますので、従来のレンタルサーバーにはない柔軟で迅速なインフラの縮尺が可能です。又、サーバー上ではLinuxやWindowsなどの通常OSが動く事からアプリケーション制作において制限は全くありません。料金体型としてはNiftyクラウドは通常レンタルサーバーと同程度の費用がかかります。
詳しくは御気軽にお問い合わせください。
クラウドは万能ではありません。特徴を良く理解して活用することが重要です。
- 機能要件とサービスのフィット＆ギャップ分析を実施して要件を定義する。
- SLAが非機能要件を満たせるかを検討して、クラウド採用の可否を判断する。
| メリット | デメリット |
|---|---|
| 開発基盤が準備されているので、プロトタイピングで要件定義がやりやすい。 | 性能や可用性、セキュリティなどの非性能要件がサービスのSLAに依存する。 |
- データ・アクセス方式の違いなど、サービス特有の仕組みを意識してアプリケーション・パターンを設計する。
- データ転送負荷を意識SLAが非機能要件を満たせるかを検討して、クラウド採用の可否を判断する。
| メリット | デメリット |
|---|---|
| システム基盤のキャパシティ・プランニングが不要 | データ・アクセスの仕組みなど、クラウド特有の技術仕様に準拠する必要がある。 |
- 規程された開発環境を習熟し、プログラミングの制限事項などを把握しておく。
- ローカル環境でバージョン管理や変更管理ができる仕組みを用意しておく。
| メリット | デメリット |
|---|---|
| 用意されたフレームワークを利用することで、開発生産性を高められる。 | 規定された開発環境や技術仕様の制約の中で開発する必要がある。 |
- サービスで規定されたテスト条件や、問題発生時の対処法を確認しておく。
- ローカル環境からの移行時は、クラウド環境との互換性に注意。
| メリット | デメリット |
|---|---|
| 信頼性テストや障害時のリカバリ・テストは必要がない。 | サービス提供者が指定するテストを実施する必要がある。 |
- 障害発生時にどう対応するかのポリシーを決めておく。
- サービス提供者が公開する計画停止などの情報を把握して利用者に周知する。
| メリット | デメリット |
|---|---|
| 基盤サービスの運用を任せられる
（開発したアプリケーションの運用は除く） |
基盤サービスで障害が発生しても復旧を待つしかない。 |
日経システムズ2009年2月号掲載より
営業時間内（平日10：00～18：00）内にいただいたお問合せは、その日のうちにお返事差し上げます。
ご不明な点は、お気軽にお問合せください。
