Dbvisit Standby を選ぶ理由の鍵となったのは、サポートレベルの高さにありました。
フィリピン国内にはセブンイレブンが1,000店舗以上あり、人口9,900万人が日々利用しています。多数の店舗を支援すること、諸島全域に人口が広がっていることを踏まえ、セブンイレブン・フィリピンでは大規模かつ複雑な在庫管理の運用が必要とされていました。
現地のオペレーターは1982年から、国内全店の在庫管理をする為の免許を所持し、現在ではメイン倉庫と運用センターで300人以上の正社員が在庫を管理しています。 フィリピンは、世界で最もハリケーンの影響を受けやすい国で、毎年平均して6~9回ほどハリケーンが上陸します。一度のハリケーンで最大1mもの雨量をもたらし、島の人々や企業の唯一の脅威であり、最大の自然災害です。
課題
･ディザスターリカバリーソリューション
･1,000店舗の在庫管理システムの運用
･24時間 ／ 365日運用の必要性
･900GBデータベース
･毎週3GBのデータ増加
･Oracle Standard Edition
･Linuxデータベース環境
フィリピン国内全ての企業に共通しているように、セブンイレブン・フィリピンでもハリケーンによるシステムや運用へのリスクを軽減させる必要がありました。特に、首都マニラのメイン倉庫では国内1,000店舗の在庫を常に管理していました。セブンイレブン･フィリピンの在庫管理システムは、社内のITプラットフォームであり、重要な役割を担っており、24時間365日の運用が必須となっていました。そのため、緊急時に即座に起動でき、確実かつ信頼性の高いディザスターリカバリー(DR)ソリューションが必要でした。
在庫管理システムは、WindowsベースのアプリケーションサーバーとLinuxベースのデータベースサーバーで構成されています。データベースサーバーでは、Oracle 10g Standard Editionが使用されており、約900GBのデータが蓄積され、毎週約3GBのベースで増加しています。また、トランザクションデータは一日14GB生成され、スタンバイデータベースに送るアーカイブログデータは100GBとなっていました。この転送量をパフォーマンスインパクトなしに実現することが大きな課題でした。
ソリューション
･2011年、社内ITチームで実装
･Oracle Enterprise Edition不要
･80％以上のコスト削減
･データ破損からのリカバリーに成功
･データ移行もサポート
セブンイレブン･フィリピンは、Dbvisit StandbyをDRソリューションとして採用を決定しました。理由として、Dbvisit Standbyは確かな信頼と実績が数多くあり、OracleデータベースStandard Edition向けにコストエフェクティブなDRを実現できると確信したからです。
当初、セブイレブン・フィリピンではOracle Data Guardを検討していました。在庫管理システムは、Oracle Standard Editionで運用されており、Oracle Data Guardを使用するには別途Enterprise Editionライセンス購入が必要となり、6倍ものライセンス費用がかかることが判明。そこで、Dbvisit Standbyを導入することで80%以上ものコスト削減を実現しました。
セブンイレブン・フィリピンは、Dbvisit Standbyを他社製品と比較して同等、またはそれ以上のサポートが提供されていることを知りました。更に、製品トライアルから実装まで、ソフトウェアの展開や運用を容易に出来ることが明らかとなりました。
セブンイレブン・フィリピンがDbvisit Standbyを選択したもう一つの理由に、Dbvisit社が提供するサポートレベルの高さにありました。トライアル評価・プロジェクトの実装から現在継続中のサポートまで、セブンイレブン・フィリピンではDbvisit社に対して、感動するほどの手厚いサポートを高く評価しています。
結果
セブンイレブン・フィリピンでは、2011年より本番環境でDbvisit Standbyの使用を開始しています。Dbvisit Standbyは本番環境のプライマリーデータベースからスタンバイデータベースへ、5分から15分の間隔で24時間365日データを転送しています。Dbvisitでのレプリケーション時や災害時でも容易に使用することが可能でした。3年に渡りDbvisit Standbyを使用している現在、災害時にDRサイトへ切り替える作業のみ必要となっています。
セブンイレブン・フィリピンでは、在庫管理システムのデータベースのひとつが破損した際でも、スタンバイデータベースへ瞬時にスイッチ（フェイル）オーバーすることが可能な為、アプリケーションの停止を最低限に抑えることが出来ました。ITチームがプライマリーデータベースを復旧している間、スタンバイデータベースをアクティブにし、本番環境として稼動することが可能でした。復旧準備が整ったとき、再度Dbvisit Standbyを使用し、スタンバイデータベースから複製を戻すことで、交換用サーバー上にデータベースを再作成。全ての作業が完了したとき、アプリケーションは交換サーバー上に再構築されました。
その為、Dbvisit Standbyはフェイルオーバーだけでなく、復旧プロセスとしても活用されています。フェイルオーバー時に最新のデータベースの複製を使用するだけでなく、アプリケーションを停止させずに新しいプライマリーデータベースを再作成できるので、復旧プロセスとしても使用することが可能となります。
