「Oracle Exadata＋マルチテナント」でデータベース集約／運用の効率がさらに向上 パナソニックISが基幹データベース統合で証明：高性能を無駄遣いしない各種ルールの徹底も鍵に（1/3 ページ）
「Oracle Exadata」による全社データベース基盤の統合を進めるパナソニック インフォメーションシステムズは、Oracle Database 12cのマルチテナント機能を活用することで、データベース集約や運用管理の効率をさらに高めることに成功した。[プライベートクラウド/データベース統合][Engineered System]
個別にサイロ化したデータベース環境の運用効率化とパフォーマンス改善を目的にOracle Exadataを導入
「Oracle Exadata」と「Oracle Database 12c」のマルチテナントアーキテクチャを活用し、理想的なデータベース統合を進める1社が、本サイト記事「パナソニックISが実践するOracle Exadataとマルチテナントを活用した大規模DB統合のアプローチ」でも取り上げたパナソニック インフォメーションシステムズだ。日本オラクルが2016年10月に開催した「Oracle Cloud Days Tokyo 2016」における同社 辻本貴士氏（IDCサービス事業部 IT基盤部 アプリ基盤チーム DBAユニット）による講演では、その内容があらためて紹介されるとともに、Oracle Database 12cのマルチテナント機能（Oracle Multitenant）を活用した最新の成果が披露された。
「Accelerate IT Innovation」をスローガンに掲げるパナソニック インフォメーションシステムズは現在、基幹業務からIT基盤、文教関連まで幅広い領域で事業を展開している他、オラクル製品の導入支援においても豊富な実績を持つ。
そんな同社のシステム環境は、かつてはシステムごとに個別にデータベースが構築されており、そのプラットフォームもSolarisやLinux、Windowsなどが混在していた。そうした状況を振り返りながら、辻本氏は「システムごとにデータベースが構築された結果、運用管理に多くの工数がかかる他、ライセンス費用やハードウェアコストも大きな負担となっていました」と話す。
また、辻本氏はデータ量の増大などによる弊害にも触れ、「データ量が増えたことで夜間バッチがなかなか終わらず、翌日の始業に間に合わない、あるいはデータの不具合でバッチ処理が正常に終わらず、再実行して翌日の業務開始時間を遅らせるといった事態が頻繁に発生していました」と話す。
それらの問題の解決策としてパナソニック インフォメーションシステムズが着目したのがOracle Exadataであった。事前に開発環境で検証を行い、実際にデータを流してSQLのパフォーマンスがどの程度改善するかを検証したところ、「劇的に向上することが確認できた」（辻本氏）ことで本番環境への導入を決めたという。
Oracle Exadataの高性能を無駄遣いしない！ 統合DB基盤を有効に活用するための各種社内ルールを策定
Oracle Exadata上にデータベースを統合する際、パナソニック インフォメーションシステムズはさまざまな観点から検討を重ね、幾つかのルールを定めている。その1つは、Oracle Database Resource Managerを利用し、各システムが使用できるCPUリソースの上限を設定したことである。仮にシステムが暴走しても、CPUリソースの上限が設定されていれば他のシステムへの影響を抑えられる。また、IPアドレスとユーザーの組み合わせが一致しない場合はデータの参照を不可能にしてセキュリティを高めた他、データの更新や参照にも厳しい制限を設けている。
シェルスクリプトやJavaによるアプリケーションをデータベースのレイヤーからアプリケーションのレイヤーに変更するといった方針の変更も行った。「シェルスクリプトやJavaアプリケーションをデータベースサーバ上で実行すると、何かトラブルが生じた際、その原因がデータベースにあるのか、それともシェルスクリプトやJavaアプリケーションにあるのかが分かりにくくなってしまう」（辻本氏）ことが理由だ。
Oracle Exadataの圧倒的なパフォーマンスに頼ったアプリケーションの設計も禁止した。その理由について辻本氏は、「何の工夫もせずにパフォーマンスが出るからといってチューニングを怠れば、50システムを統合できるはずが20システムしか載せられないといったことが起こりかねません」と話し、この方針を徹底するために開発環境のCPUリソースを0.5％に制限し、その状態でも十分なパフォーマンスを出せるシステムだけが本番に進める決まりにしていると明かす。
データベースを集約すれば、統合基盤が停止した際の影響が多くのシステムに及ぶことにも配慮した。これについては、プライマリーとスタンバイでデータベースを分けた上でOracle Data Guardによって両者間を同期。障害発生時や大規模メンテナンス時にはスタンバイ側に切り替えることでダウンタイムを最小化するという対応が図られた。
「障害発生時だけでなく、全体的に停止させなければならないメンテナンス時でも、この構成ならばスタンバイ側で稼働を続けられます。その間、プライマリーデータベースに対してパッチを当てたり、メンテナンスを行ったりするわけです」（辻本氏）
なお、プライマリーとスタンバイへの接続の切り替えはアプリケーション側で行う。具体的には、プライマリー側とスタンバイ側のIPアドレスをアプリケーションに記述しておき、プライマリーに接続できないときは自動的にスタンバイにつなぎ直す仕組みだ。これにより、本番サーバがダウンしたりメンテナンスしたりしている場合でも、アプリケーション側では何も対応を施すことなく接続先を切り替えられる。
提供：日本オラクル株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2017年4月20日
Copyright © ITmedia, Inc. All Rights Reserved.
