データベースは、インスタンス統合でムダをなくす！

2018年08月16日
2021年05月07日

データベースの統合の最適化において話題となっています。本格的なAIの時代に突入し、まず一般企業でのAIの活用事例は、ビッグデータの取り扱いがほとんどだと推測されます。
しかし、データベースは、部門別に管理され、導入しているベンダー企業もバラバラで、まとまりがなく、終始がつかない状況のデータベースを抱えている企業がほとんどだと推測されます。
自社のPDCAサイクルの見直し、目標設定、新規開発などを行っていくにあたり、データベースの資料、数値は裏付ける格好の材料であります。

しかし、ビッグデータ活用の時代で、まとまりがなく、終始がつかない状況のデータベースの統合性を図り、わかりやすく、有効に活用する手段としてインスタンス統合に注目を浴びています。

データベースの老舗企業Oracleのデータベースにおける開発、手法、導入企業例を見ながら、データベースの統合、インスタンス統合の効果を見ていきます。

＜目次＞

インスタンス統合とは
インスタンス統合においてのOracle RACとは
インスタンス統合においてのOracle Expanadaとは
インスタンス統合においてのOracle Expanadaの導入例
インスタンス統合の展望

インスタンス統合とは

家庭においていつの間にか物は増えつつあります。子供のおもちゃは先日買ったカゴに、日用品は2、3年前にホームセンターで買ったケースにしまってあるとします。
いざ子供が遊びたいおもちゃがすぐに取り出せなかったり、ハサミや荷造り紐がすぐに取り出せないということは、誰でも経験があるかと思われます。

企業においても同じようなケースが想定されます。
売り上げデータ、会計処理、人事給与システム、マーケティング資料など。それぞれに部門が違うので、大企業ともなるとセクション毎で導入しているデータベースの種類も起用しているベンダーも違うケースは、多々あります。

ビッグデータを駆使してBIで経営の方向性をいざ分析するとなると、データの整合性がなくては、データを抽出し、分析するのに、時間と手間がかかってしまいます。
クラウド以前においては、Oracle RAC（Oracle Reak Appilication）を導入することによって、ロードバランス（不可分散）の方式を手法で、複数のサーバーを使用してシステムを構築しておりました。
複数運用しているので、障害が起きても他のサーバーでリスク管理をしておりました。
しかし、いくつもサーバーを増やす事は、オフィスのスペースにも制限があり、電力も要します。

いくつものサーバーを保持し、運用に限界を感じ、世の中のサーバーがクラウド化する中で、ついにオラクルが複数のインスタンスを統合するデータベースシステムOracle Expandaを開発しました。
クラウド対応したデータベースOracle datevcase c12で導入されたマルチテナントアーキテクチャは話題になりました。

インスタンス統合においてのOracle RACとは

Oracle RAC（Oracle Reak Appilication）の概念を振り返ってみます。
Oracle RACとは、ロードバランス（負荷分子）型のクラスタリング構成のデータベースです。この構成は、複数のインスタンスで１つのデータベースを管理していました。

Oracle RAC（Oracle Reak Appilication）の特徴は

サーバーに障害が発生しても、他のインスタンスでカバー
他のノードでの処理に置き換えることで、サービスの継続可能
負荷分散化によるアクセスして更新や外部のアクセスもランダムに負荷を自動的に低いノードに振り分けることを可能
追加可能な拡張機能の増設可能
システム全体の処理能力を維持

インスタンスを分散し、中枢にデータベースを司ると言う方式を導入しています。

インスタンス統合においてのOracle Expanadaとは

Oracle Expanadaは、オラクルが誇る最強のリレーションデータベースです。
Oracle RACと組み合わせて、最速に動かす事ができます。

Oracle Expanadaの特徴とは

マシン自体大量データを高速で処理
データベースサーバーを並列稼働、拡張性を実現
最高速化
パラレルの実行
広帯域、低遅延ネットワーク、flashの活用
圧縮によるI/Oの削減、不要なI/Oの削減
ストレージへの処理のオフロードの格段の優位性の保持

インスタンス統合においてのOracle Expanadaの導入例

Expanadaを有効活用した企業の例をみてみます。

大手保険会社のシステムを支えるインフラ

東京海上日動システムでは、社員のうち300名前後の社員がインフラ部門に属しています。従来のデータベース蓄積しており、1990年代に構築されたデータマートシステムの刷新、運用コストやシステムの最適化が課題となっていました。その数、アプリケーションの数は、65種類にも及びました。

アプリケーションの数だけ、ソリューションの数も増えます。インフラの増設、さらに集約するために15台のデータベース、サーバー３台、ストレージ装置とそのスペースを確保するにも賃料がのしかかます。コスト的にも圧迫されていました。
その一方、保守やサポートなどの保守においても予算がかかり、かつシステム障害などの問題も起きます。月間400万件ほどの処理をこなすことになり、システムのキャパが大幅に不足する問題が深刻化していました。
運用コスト制限とキャパ不足の解消のソリューションを解決するがごとく、この問題を解決したのが、Expanadaであります。
15台のデータベース、３台のストレージ、65のデータマートアプリからなる巨大なデータベースシステムは、一挙に集約を解決してくれました。

ITインフラの簡素化

システムの集約を解決しただけでなく、ITインフラの簡素化を見直すきっかけとなりました。
Oracle を導入することにより、そもそもそのシステムは必要なのか？統合可能なシステムなのか？仮想サーバー基盤にとりあえず構築できるのかというルールを設ける事ができました。

東京海上日動システムは、ルールに従ってデータマートアプリケーションを40程度までに絞り混む事ができました。もちろんOracle Expanadaの移行対象のアプリケーションです。

データの増殖に伴う処理能力の低下を食い止めるために、テーブルをサブテーブルに分散し、負荷を軽減し、処理能力の低下を食い止めたのです。

また、多大な時間を要していたパッチ処理も28時間から8時間で終了、オンライン処理についてもレスポンスタイムが30秒以内から5秒以内へと短縮されました。

また、最近話題のBIシステムのセクションごとに選定していたので、組織全体としては、結果として使用頻度、共にバラついた整然としない結果となっていました。
そうした乱立していたBIもOracle Expanadaを導入することにより、統廃合を行いました。

インスタンス統合による効果

こうしてOracle Expanadaを導入することより、結果的にIT予算を削減する事ができ、パッチ処理の時間やれスポンスに要する時間も大幅に削減する事ができました。
しかし、削減、削減を叫んでばかりでは、社員の士気も削減され、下がってしまいます。
この導入、見直すことにより人材のスキルアップ、業務改善、プロセス構築を図ることに成果を上げました。
他社の例でも、パナソニックは、22台のデータベースを集約しています。

インスタンス統合の展望

個人は、物を所有しないミニマムライフを好む傾向になりつつあります。企業も従来のような大型なサーバーを所持し、運用するには限界を感じつつあるのが現状です。
Oracle ExpanadaやOracle Datebase Applicationのようなデータベースにシステムが基盤になりつつ、活用する中でさらに、クラウド型のoracle12cの到来で一気に、マルチテアント・アーキテクチャの概念が注目されて、クラウド化によるデータベースの統合という概念を検討する企業が注目されました。

データベースの王道Oracle社が展開する事例を例に、自社のデータベースのあり方を見直すきっかけになれば幸いです。