Special
» 2016年05月10日 07時00分 公開

1690万人の列車利用を支える大規模DB基盤のアップグレード:JR東日本が輸送総合システムのリプレースを実施──Oracle GoldenGateで“業務停止なし”のデータベース移行を実現 (2/3)

[PR/@IT]
PR

業務への影響を抑えたDB移行の手段にOracle GoldenGateを選んだ理由

 列車ダイヤという多くの人々の生活を支える極めて重要なデータを管理するシステムのリプレースであるため、データベースを同期する仕組みについても慎重に検討が重ねられた。その中で、3つの案が議論されたと秋山氏は明かす。

 「1つ目の案はOracle GoldenGateを利用するというもの。2つ目の案は独自にスクラッチでツールを開発して同期するという方法でした。また、この2つの案がいずれも不可能だった場合に備えて、データのエクスポート/インポートによって同期するという3つ目の案も用意しました。ただし、3つ目の案をとった場合はお客さま(JR東日本)の業務に大きな影響が及ぶことから、これはあくまでも最終手段という位置付けでした」(秋山氏)

photo JR東日本情報システム 鉄道・生活サービス部門 鉄道システム部 次長の平野聖人氏

 Oracle GoldenGateによって同期するか、それとも独自ツールを開発するかを判断するために、JR東日本情報システムはOracle GoldenGateについて徹底的な調査を行った。具体的には、日本オラクルのコンサルタントからOracle GoldenGateに関してレクチャーを受け、実機を使って検証できるレベルにまでスキルを蓄積した上で、スクラッチ開発のツールを使う場合と総合的に比較したという。その結果、Oracle GoldenGateの採用に至ったわけだが、その理由は何だったのだろうか? 鉄道システム部 次長の平野聖人氏が理由の1つとして挙げるのは、「ベンダーごとの品質のバラツキを解消できる」というメリットである。

 「輸送総合システムは14のサブシステムで構成されており、それぞれ開発ベンダーが異なります。スクラッチでツールを開発する場合、サブシステムごとに担当ベンダーにツール開発を依頼することになりますが、移行作業を行いながらツールを開発するのは負担が大きい上、ベンダー間で品質のバラツキが生じる可能性があります。また、サブシステムごとにテストを行う必要があるため、テストの負担も大きくなるでしょう。

 これに対して、Oracle GoldenGateを採用すれば、これを共通の移行ツールとして利用することでベンダーごとの品質のバラツキの問題を解消し、テストの負担も軽減できます。今回のような大規模なプロジェクトにおいて、これは特に大きなメリットだと感じました」(平野氏)

新旧DB間のデータ整合性をどう担保するか? Oracle GoldenGate Veridataでデータ一致確認のコストを大幅に削減

 Oracle GoldenGateを採用した理由としては、「Oracle GoldenGate Veridata」の存在もあった。これは2つのデータベース間のデータ整合性を確認するためのツールであり、このプロジェクトではOracle GoldenGateで同期した新旧データベースのデータ一致確認のための利用が検討された。同ツールのメリットを、秋山氏は次のように説明する。

 「安全・安心が強く求められる列車ダイヤを支えるデータベース基盤ですから、単に同期させるだけでなく、新旧データの整合性を確認することも不可欠です。Oracle GoldenGateならば確実にデータを同期でき、さらにそのことを確かめる手段としてOracle GoldenGate Veridataまで用意されているため、それが大きな安心につながります。大量データの比較を素早く行い、不一致箇所をレポートで確認できるので、手作業で比較するよりも大幅なコストと時間の削減になります。これは非常に重要なポイントでした」(秋山氏)

 Oracle GoldenGateを採用した理由は、もう1つある。それは日本オラクルによる手厚い技術支援の存在だ。実は秋山氏らは、別のベンダーのデータベース連携製品も検討していた。しかし、製品ベンダーからのしっかりとした技術支援に不安があることから、「お客さまの基幹業務を担う重要なシステムの移行で採用するには、リスクが極めて高い」と判断して採用を見送ったと打ち明ける。一方、日本オラクルならばサポート窓口や営業担当、コンサルティングサービスなどを通して十分な支援を受けることができ、実際に製品選定の段階からさまざまな支援を受けた。そのこともあり、最終的にOracle GoldenGateの採用を決めたのだという。

同期遅延はわずか5分 リアルタイムなデータ同期で業務への影響を回避

 新システムへの移行プロジェクトは2012年12月に要件定義が始まり、翌2013年春にOracle GoldenGateの本採用が決まる。そして基本設計から詳細設計、Oracle GoldenGateのインストールと同期試験などが行われた後、2014年12月の本番切り替え(第1回)の4カ月前に当たる同年8月からデータベースの同期が開始された。

 なお、要件定義の段階では新旧環境間で双方向同期を行う予定だったが、プロジェクト内で検討を重ねた結果、よりシンプルに切り替えを行うことを目的として、片方向の同期で進めることにした。まず旧環境から新環境にデータを同期して移行し、その後は逆方向でデータを同期するという形だ。

 実際の同期作業の流れは次のようになる。まずエクスポート/インポートで旧環境のデータを新環境に移行し、続いてOracle GoldenGateによって2つのデータベースの内容を「旧環境→新環境」の方向で同期する。そして新環境への切り替え後は、一部を除いて新環境でデータを更新し、旧環境ではデータを参照するだけという形に役割を切り分け、データ同期の向きを「新環境→旧環境」に変更するといった具合だ。

旧環境から新環境への移行の流れ 旧環境から新環境への移行の流れ
photo JR東日本情報システム 鉄道・生活サービス部門 鉄道システム部 輸送企画プロジェクト サブリーダーの塩谷亜紀氏

 この移行期間中、Oracle GoldenGateによるデータ同期遅延が許された時間はわずか30分であった。新環境の夜間バッチのジョブでデータ更新を行い、その結果をOracle GoldenGateで旧環境にリアルタイムに同期。旧環境では、そのデータを使ってジョブが実行されるというフローである。前述したように、今回のリプレースではデータセンターも移設された。つまり、新旧データベース環境は異なる場所で稼働し、それに伴うネットワーク遅延が生じる。Oracle GoldenGateによる同期作業を担当した鉄道システム部 輸送企画プロジェクト サブリーダーの塩谷亜紀氏は、「時間内に無事データ同期が行えるか不安でした」と明かし、次のように続ける。

 「仮にデータ同期遅延が当初想定していた30分以上になった場合、お客さまの業務が始まる午前6時までにバッチ処理が完了せず、業務に多大な影響が生じます。ところが当初、Oracle GoldenGateを使ったデータ同期の検証では、バッチ処理内の大量データ削除時に40分程度の同期遅延が発生しました。そこで、日本オラクルのコンサルタントの協力を得て議論を重ね、パラメーターを調整したところ、SQLの実行時間を含めて最大で同期遅延が約5分となり、要件を十分に満たすことができたのです」(塩谷氏)

Copyright © ITmedia, Inc. All Rights Reserved.


提供:日本オラクル株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2016年6月9日

関連情報

驚異的なパフォーマンス、優れた運用効率、最高の可用性とセキュリティ、クラウド対応を実現するOracle Exadataとの統合、クラウド、可用性や運用管理など、次世代データベース基盤構築のために参考になる必見資料をまとめてご紹介いたします。

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。