Oracle Database for SAP

導入事例

Oracle Data Guardによる、ディザスタリカバリ環境の構築

Oracle Data Guardの採用により最低限のコストで、
事業の継続性を担保する、ディザスタリカバリ環境を構築

日本バイリーン株式会社様

不織布の国内リーディングカンパニーである日本バイリーン株式会社（以下、日本バイリーン）は、1997年から基幹業務システムにSAPを導入し、そのデータベースとしてOracleを採用してきた。そして今回、システムのバージョンアップにともない、富士通株式会社（以下、富士通）製基幹IAサーバー「PRIMEQUEST」へのリプレースとOracle Data Guardを利用し、ディザスタリカバリ環境の構築を行った。この一連のシステム構築について、同社経営財務部 情報システム担当課長 中村幹生氏と同主任 関口達也氏にお話を伺った。

90年代後半から基幹システムとしてSAPを採用

日本バイリーンは1960年の設立以来、業務系システムは、ホストシステム上ですべて自社構築してきた。また、一部のシステムについては当時の関係会社のシステムを利用してきた。しかし、90年代後半に入り、システムの2000年対応が求められてきたタイミングで、システムのマイグレーションと完全な独立を検討することになった。「ダウンサイジングが叫ばれていたこともあり、ホストシステムではなくオープンシステムへの移行を選択しました。今思えば、2000年対応はシステム移行の良いキッカケでしたね」中村氏は当時の状況をこう振り返る。そして同じタイミングで、業務システムとしてSAPの採用も決めている。当時オープンシステムで動かせる基幹業務パッケージソフトとして、もっとも完成度が高かったことがSAPを採用した理由だという。また同時に、データベースとしてOracleを採用しているが、UNIXからWindowsへ移行する際、SQL Serverへの移行を検討したこともあったという。「SQL Serverに比べ、Oracle Databaseには運用の難しさを感じる部分がありました。しかし最終的にはSQL Serverへの移行リスクや、信頼性の面からOracle Databaseを使い続けることを決断しました」（中村氏）。そこには、Oracle DatabaseもSQL Serverと同程度に運用負荷がかからない製品を出すだろうという読みがあったという。「実際そういう流れになっていると思います。今はOracleを使い続けて良かったと思いますね」（中村氏）。

素材メーカーとして事業の継続性を重視

日本バイリーンでは中期計画の一環として、それまで利用していたSAP R/3 4.6CからmySAP ERP 2005へのバージョンアップを行うことになった。またこれにともない、Oracle8iDatabase(8.1.7)からOracle Database 10g Release2へのバージョンアップ、IAサーバーの更新、さらに以前から構想のあったディザスタリカバリを実現するため、リモートでのバックアップシステム構築も行うことにした。バックアップシステムの構築を決定した背景について中村氏は語る。「日本バイリーンは素材メーカーとして、顧客である製造メーカーに対し、ジャストオンタイムで発注されたものを出荷する使命があります。その状況で基幹業務に障害が起き、受注、出荷が止まってしまうと一大事です。仮に1日システムが止まったとして売り上げで数億の損害が想定されますが、本当に怖いのは、金額では計上できない企業としての信用失墜です」。そこで以前から、事業の継続性を担保するために、機器やネットワークの二重化。さらには、テープメディアへのバックアップと、テープメディアの遠隔地での保管は行ってきたという。それでもなおバックアップシステムの構築を決めた理由について関口氏はこう語る。「やはりテープメディアでのバックアップは手間がかかりました。効率的なバックアップや、障害発生時の迅速なリストアを考えると、やはりレプリケーションが妥当だと考えました」。

二重化が決め手となり富士通の「PRIMEQUEST」採用を決定

2006年後半ごろ、一連の移行、構築作業について検討を始めた日本バイリーンでは、SAPのバージョンアップ、サーバーの更新、バックアップシステムの構築、これらすべてを行えるということと、サーバー自体の性能を考慮して数社のメーカーを検討した。その結果、富士通に作業を依頼することが決まったが、その決め手について中村氏は振り返る。「まず富士通は、SAPやOracleに関する知識、ノウハウが豊富であるということが大きな要因でした。また、提案のあった『PRIMEQUEST』というIAサーバーが、当社の要求と一致したことも重要です」。『PRIMEQUEST』の大きな特長のひとつが、富士通独自の技術により、CPU以外すべてが二重化されていることだ。システムの効率的な安定稼働を考えると、サーバー自体が二重化されているのは非常に重要であると関口氏は語る。「二重化というとクラスターなどがありますが、そうしたシステム構成は非常に複雑で管理が負担になります。当社のように限られた人員でシステムを運用していくためには、システムはできるだけシンプルな方が良いので、そうした観点からは、サーバー自体が二重化されているというのはとても重要です」。

ネットワークにやさしいOracle Data Guardの採用を決定

バックアップシステムと一口でいっても、その構築方法はハードウエア系のソリューション、ソフトウエア系のソリューションいろいろある。当初、富士通から提案された構築手法も、Oracle Data Guardではなかった。しかし、日本バイリーンと富士通が協議を重ねる課程で、Oracle Data Guardの利用が議題にあがってきたという。「実はOracle 8のころからData Guardの前身の機能であるStandby Databaseの存在は知っており、実際に自社内でテストを行ったこともありました。当時はコストや機能の面から導入を見送ったのですが、最近は利用する企業も増えてきたということで、あらためて注目していました」（関口氏）。こうした理由もあり、Oracle Data Guardの採用については特別不安がなかったという関口氏だが、何よりも心配だったのはネットワークだという。「実はリモート環境を構築する茨城工場はエリアの制約によりADSL（実効速度1〜2Mbps程度）しか利用できず、必要とする帯域によっては、専用線の導入などを検討しなければなりませんでした。そうなると当然、導入、ランニングコストが一気に跳ね上がってしまいます」（関口氏）。しかし、さらに協議を重ねた結果、Oracle Data Guardならば帯域の問題をクリアできそうだということがわかってきた。「重要なのは、どの程度のボリュームのデータを、どの程度の頻度で更新するかということでした」（関口氏）。そこで日本バイリーンでは自社が求めるシステム復旧までの許容時間を見直し、1時間に1回の頻度でデータ更新というバックアップポリシーを策定した。また1ファイルのボリュームは50MBに設定し、日々の運用では1度に5〜10ファイル程度の転送を想定した。このレベルであれば、データが集中するタイミングでは若干のネットワーク遅延の可能性があるが、1日のサイクルで見れば、ネットワークへの影響はほぼ皆無であろうということがシミュレーションできたのだ。

バックアップシステムは「持っている」こと自体に意味がある

2007年2月に導入が決まり、同年6月から実際の構築作業が始まった。本社内に構築した仮想のリモート環境、実際に茨城工場に構築したリモート環境でのテストを繰り返し、2008年2月からバックアップシステムが本格稼働している。今回、データの転送技術としてOracle Data Guardを利用しているが、1時間に1度の更新といった運用の仕組みについては富士通が独自に対応したが、現状では当初の想定どおり、ネットワークに負荷をかけることなく、バックアップシステムは安定稼働している。実際の導入効果は何らかの障害が起こらなければわからないが、本当に重要なのは、そのような状況においてシステムを『使う』ことではないと中村氏は語る。「実際に使えるシステムでなければ意味がないのですが、本当に重要なのはこうしたシステムが『使える』ということではなく、『持っている』ということなのです。事業の継続を担保できるシステムを持っているということが、同業他社に対する差別化要因となり、顧客との信頼関係構築を進めることになるのです」。業務とシステムが切り離せない関係となった現在、「システムの信頼性高さ＝企業としての信頼性の高さ」という傾向が顕著になってきた。こうした状況を踏まえると、あらためて「バックアップシステムを持つ重要性」が感じられる。一方で中村氏はコストパフォーマンスについても言及する。「安全を考えると、過度な投資になりがちですが、直接利益を生み出すわけではないバックアップに、そこまでコストを投入できる企業もないでしょう。やはりある程度コストを圧縮する必要があります。そうした面から今回のOracle Data Guardでのバックアップシステム構築を見ると、標準機能ゆえにリモート環境の構築以外、コストはかかっていないので、非常にコストパフォーマンスに優れていると考えます。最低限のコストでディザスタリカバリ環境を構築できたことに非常に満足しています」。

システム構成図

▲ ページトップへ戻る