| Oracle9i DatabaseによるSQL Serverのリプレースを実施 |
 |
IT時代の中枢を担うチャレンジ精神を持ったエクセレントカンパニーを目指している宇宙通信株式会社は、4機の通信衛星「スーパーバード」を通じて、お客様とともにIT時代の変化に柔軟に対応しながら進化(Evolution)をしていく事により、企業としてもさらに発展を遂げようと「IT
Evolution by Superbird」というスローガンにその決意を示している。2003年11月には、衛星運用の領域においてわが国で初めて情報セキュリティマネジメントシステム(Information
Security Management System :ISMS)認証を取得。信頼性確保とQoS(Quality of Service)の向上に努め常にお客様に高品質かつ安全なサービスの提供を目指している。2004年3月には、飛行機とその乗客向けのブロードバンドインターネット接続サービス「コネクション・バイ・ボーイング(Connexion
by Boeing)」への衛星、ゲートウェイサービスが開始された。世界で4箇所にのみ設置されるゲートウェイのひとつとなるスーパーバード茨城ネットワーク管制センターは、日本からトルコに至る広大なエリアのゲートウェイ機能を担っている。
|
| お客様の利用環境の変化に対応して品質の高いサービスを提供する |
 |
高度なスキルを要求される回線予約の確定や障害対応などは専門のオペレータが対応する必要があるが、単に回線の空きを確認するだけなら自動化は可能だ。特にインターネット環境は、ほぼ全てのお客様が利用できる状況となっている現在、これを利用することは当然の流れとなっていた。宇宙通信としてはインターネットからの予約状況確認を実現することはもちろんのこと、情報セキュリティの観点から、情報の信頼性と安全性を確保するためにISMSでの要件事項を同時に満足することも要求されていた。また災害時などの予約確認はニュース性の観点から見れば一刻を争うもので、ここに時間をかけることはそのままビジネスの機会損失に繋がる。つまりデータの品質と即時性が両立する必要があった。今回構築したインターネットから予約状況を照会するシステムでは、従来15〜30分かかっていた時間を1〜2分で完了できるまで時間を短縮し、かつ担当オペレータを必要としないため、業務効率が約20%程度改善されたと、運用本部テレポート運用部長、高盛哲実氏は言う。
|
| 災害時にもサービスを継続するため、100km以上離れたサーバー間を結ぶ必要があった |
 |
データやシステムの連続性を保つためにはクラスターシステムが有効であるが、通常のクラスターシステムは一般にハードウェアの障害に備えることが目的のため、同一の拠点にバックアップシステムが配置されていることが多い。災害に備えるためには本番システムとバックアップシステムを、同一の災害の影響を受けないよう、ある程度離れた場所に配置する必要がある。またそれぞれのデータ間の一貫性が保証されている必要がある。宇宙通信の採用したOracle
Data GuardはOracle9i Database Enterprise Edition で利用できるオプション機能として、データ保護機能と災害時リカバリ機能を併せて提供している。本番機のトランザクションを記録した完全なログファイルは、障害、自然災害あるいは人的災害からデータを保護するために有効である。このログファイルをバックアップシステムへ転送しログ適用サービスを実行することにより、二つのシステムのデータベースは完全な一貫性が保証されるのだ。
|
|
| 最小のコストで最大のデータ保護を実現 |
 |
宇宙通信では予約業務はスーパーバード茨城ネットワーク管制センター(SPE)で、課金と請求業務については本社で担当が分かれており、これまではそれぞれが独自に開発したシステムを別々に運用していた。今回のシステムの刷新に併せてデータの連携や一貫性を保つために、予約の照会及び受け付けシステムと、課金及び請求システムを連携し業務を一元化することとした。新しいシステムではそれぞれのサーバーが従来と同様にSPEと本社のそれぞれに配置されており、通常はそれぞれ予約と課金・請求のシステムとして稼動している。ひとたび災害が発生すると、災害を受けていない拠点のシステムが災害を受けた拠点の業務を引継ぐ。ふたつの拠点がお互いをバックアップする構成だ。これにより従来のバックアップシステムのように冗長システムを遊ばせておくのとは異なり、システムを常に稼動させておくことが可能となり、投資効率の高い構成が可能となっている。これを実現するためにはお互いのスタンバイデータベースが常に本番システムのトランザクションを実行して、完全な同期が取れている必要がある。Oracle
Database9i Enterprise Edition のData Guardは、データのリカバリ方法として、ブロック単位で物理的に同じコピーを作成するフィジカル・スタンバイと、論理的に同じデータベースを作成するロジカル・スタンバイを選択することができる。ロジカル・スタンバイの場合は本番システムのトランザクションをログファイルからSQLへ変換して実行するため、結果としてデータベースは同じ更新状態となる。またSQL実行中でも同じテーブルへ参照のためのアクセスができるという利点がある。これにより通常は本番システムに対して予約確認のSQLが発行されるところを、ロジカル・スタンバイのシステムに対してSQLを発行することが可能になるため、結果として本番システムの負荷が軽減されるのだ。
|
| 導入プロセス |
 |
2002年初めに業務統合とインターネット利用のプロジェクトの検討を開始。2002年11月に導入プロジェクトを開始し、2003年11月に試験導入開始した。その後セキュリティチェックなどの検証を確認し、2004年5月の連休明けから本格運用を開始した。
|
| 将来計画 |
 |
予約システムに対するユーザーからの評判が良かったことから、今後はお客様のサポートの受付や情報発信へと展開していきたいと鈴木氏は語る。またお客様へ提供するサービスの品質を重視しているため、データベースシステムによるお客様データの管理は非常に有効であると言う。
|
| オラクル選定理由 |
 |
100km以上離れた拠点間にシステムを分散して耐災害性の高いシステムの構築が可能な選択肢はオラクル以外なかったと鈴木氏は言う。また多くのパッケージを利用していく場合に、オラクル製品に対応している製品が豊富にそろっていたこと。そして独自に開発した機能をこれらのパッケージに追加する際に、同じユーザーインタフェースで統一することや、連携することが最も容易だったこともオラクル選定の大きな要因だったと、高盛氏は語った。
|