TOP>企業情報>コラム>技術情報>はじめましてOracle! Vol.6

はじめましてOracle! Vol.6

はじめましてOracle!

第6回目(最終回)となる今回は、Oracle Database Applianceがどのようなシステムで活用できるのかを解説します。

(全6回連載)

Vol.1 誰でも簡単!Oracle Database 11g Release2のインストールと初期設定(活用編)

Oracle Database Applianceならではのメリットを活かす


第3回から第5回にかけて、Oracle Database Applianceのインストール方法や検証結果を解説してきました。

2時間という非常に短い時間でインストールでき、さらに一般的なRAC構成と同等の可用性を持ちながらも、Pay as you growによってコストと性能のバランスを調整できるのが、Oracle Database Applianceです。

Oracle Database Applianceの特徴 説明
ハードウェアとソフトウェアが事前設計・構成済み 高可用性データベースに必要なハードウェアとソフトウェアが設計・構成された状態で組み込まれています。組み合わせや相性の問題が発生することなく、設計の期間を大幅に短縮できます。
Oracle Appliance Managerによる簡単なインストール GUIの画面に従って進むだけで、誰でも簡単にRACのインストールができます。必要な時間は2時間だけです。
Pay as you growによるスモール・スタート 搭載されているコアのうち、実際に使用するコアだけをライセンス対象にできます。RAC構成でも最小2プロセッサライセンスからスタートできます。
Enterprise Editionを低コストで利用可能 Pay as you growを使うことで、Standard Editionと同等のコストでEnterprise Editionを使うことができます。Enterprise Editionの機能を使うことで、性能や管理性が大幅に向上します。
高可用性、高性能 ハードウェアの各部品が冗長化されているため、高い可用性を備えています。また、REDOログ・ファイル配置用のディスクをSSDにするなど、高い性能が出るためのノウハウが凝縮されています。
1Boxで省スペース、低価格 必要なハードウェアとソフトウェアが1Box(4U)の中に全て収まっており、無駄なスペースを消費しません。また、ストレージやスイッチといった本来サーバーとは別に存在する機器も1Boxに収まっているため、低価格を実現しています。


第6回目(最終回)となる今回は、Oracle Database Applianceがどのようなシステムで活用できるのか、実例を交えながら紹介します。

アクティブ・スタンバイ構成からOracle Database Applianceにリプレース


Oracle Databaseで可用性を高める場合に多く利用されているのが、アクティブ・スタンバイ構成です。最低2台のサーバーから構成され、稼働系となるサーバーがダウンした場合に、待機系のサーバーで運用を継続することができます。可用性を検討する際には必ずといって良いほど候補に挙がってくる構成です。

『仕組みがシンプルで使いやすい』、『安定稼働した実績がある』といった理由から、アクティブ・スタンバイ構成を採用しているケースが多いのではないでしょうか。

Oracle Database Applianceは、このアクティブ・スタンバイ構成のシステムをリプレースする場合の有力な候補として考えることができます。

アクティブ・スタンバイ構成からのリプレース

アクティブ・スタンバイ構成からのリプレース

ポイント① 組み合わせの考慮が不要

リプレースを行う際の大きな理由として、ハードウェアの保守切れがあります。

これまで問題なく稼働していたとしても、リプレースに伴ってハードウェアを新しく入れ替えなければなりません。

アクティブ・スタンバイ構成には、ストレージやノード間通信用のネットワークなどの様々なハードウェアが必要ですが、それぞれが正しく動作するかは、実際に稼働テストを行うまで分かりません。

Oracle Database Applianceは事前に検証済みのハードウェアとソフトウェアを搭載しているため、組み合わせによって問題が発生することがなく、稼働テストの工数を大幅に削減することができます。

ポイント② RAC One Node構成を選択できる

これまでは、リプレース後もそのままアクティブ・スタンバイ構成を踏襲するか、それともRACに変更するかというのが主な選択肢でしたが、Oracle Database 11g Release2からRAC One Nodeという新機能が提供されました。

RAC One Nodeはアクティブ・スタンバイ構成と非常に良く似ているため、リプレース後の構成を検討する際の候補として考えることができます。

RAC One Nodeとアクティブ・スタンバイ構成の比較
項目 RAC One Node アクティブ・スタンバイ構成
最低限必要なサーバー数 2台 2台
障害発生時の動作 稼働系から待機系へ切り替え 稼働系から待機系へ切り替え
アプリケーションからの接続先 仮想IPアドレス 仮想IPアドレス
Oracleライセンスの対象 稼働系のみ 稼働系のみ
クラスタウェア Oracleが無償提供 ベンダークラスタウェアが必要


Oracle Database ApplianceはRAC One Nodeにも対応しているため、アクティブ・スタンバイ構成と同じ感覚で運用することができます。また、無停止でRACにアップグレードすることが可能なため、処理能力や可用性の強化といった要件が後から出てきた場合にも柔軟に対応することができます。

ポイント③ Pay as you growで既存環境のライセンスに合わせられる

Enterprise Editionのアクティブ・スタンバイ構成をリプレースする場合、CPUのコア数によってコストが大きく変わってきます。

できればリプレース前後でコア数を合わせたいところですが、リプレースに至るまでの数年間でCPUのマルチコア化が進んでしまい、コア数が合わなくなる場合があります。

例えば、デュアルコアのCPUが主流だった頃のサーバーをリプレースする場合、クアッドコア、ヘキサコアが主流になっている現在のサーバーとはコア数が合いません。

この問題を解決するのが、Oracle Database ApplianceのPay as you growです。

必要なコア数を指定することができるため、リプレース前のライセンスに合わせることができます。

Pay as you growによるコア数の調整

Pay as you growによるコア数の調整

運用開始後にコア数を増やすことも可能なため、柔軟性にも優れています。

Oracle Database Applianceを災害対策に活用


これまで解説してきたRAC One NodeやRACといった可用性構成は、データセンターや事業所といった同一拠点内において、部分的な障害に耐えることを目的としたものです。

サーバーやディスクに障害が発生したとしても運用を継続できますが、災害などで拠点全体のネットワークがダウンしたり停電が発生した場合は、復旧を待たなければなりません。

このような場合に備えて、離れた拠点に代替となるシステムを構築する「災害対策構成(ディザスタリカバリ構成)」を検討する企業が増えています。

Oracle Databaseには様々な災害対策構成が存在しますが、特に多く採用されているのがOracle Data Guardと呼ばれる機能です。プライマリからスタンバイに向けてREDOログの情報を送信することによって、遠隔地にデータベースの複製を保持することができます。

アシストの基幹システムにおいても、Oracle Data Guardを使った災害対策が実装されており、東日本に存在するプライマリからのREDOログ情報を西日本のスタンバイに送信して同期をとっています。東日本で災害が発生した場合は、西日本の環境に切り替えて業務を継続します。

Oracle Data Guardによる災害対策構成

Oracle Data Guardによる災害対策構成

Oracle Data Guardを構築するためには、コストや運用管理といった様々な考慮が必要になりますが、Oracle Database Applianceを使うことで、簡単に低コストでOracle Data Guardの環境を手に入れることができます。

ポイント① 災害対策を超短時間で実装、メンテナンスも簡単

災害対策構成は単にデータベースを複製して終わりではなく、災害発生時に切り替えて使うことまで想定して構築しなければなりません。そのため、スタンバイには以下のような要件が求められます。

 ・プライマリと同程度の性能があること
 ・プライマリと同程度の可用性があること
 ・プライマリと運用管理、メンテナンス方法が同じであること など

つまり、プライマリとスタンバイを極力似た構成にしておくのが望ましいということです。

単純に考えると、プライマリを構築するのと同じだけの工数をかけて、スタンバイを構築しなければなりません。

この工数を削減するために、プライマリとスタンバイの両方でOracle Database Applianceを使うという方法があります。非常に短い時間でOracle Data Guardの環境を手に入れられることに加え、性能や可用性、運用管理方法を統一することができます。

また、Oracle Database ApplianceのパッチはOS、ハードウェア、Oracle製品全てを1つにまとめた「Oracle Appliance Kit Patch Bundle(OAK Patch Bundle)」として提供されるため、メンテナンスも非常に簡単です。

Oracle Database Applianceのパッチ

Oracle Database Applianceのパッチ

製品ごとにパッチを適用するのではなく、OAK Patch Bundleを1つ適用するだけで、システム全体が最新の状態に更新されます。プライマリとスタンバイでパッチのレベルに差が出ることもありません。

ポイント② Pay as you growでスタンバイのライセンスを節約

Oracle Data GuardはEnterprise Editionの標準機能であるためオプションは必要ありませんが、プライマリだけでなくスタンバイもライセンスの対象となります。

ポイント①で解説した通り、プライマリとスタンバイを極力同じ構成にすることが望ましいですが、CPUコア数を同じにするとライセンスコストが大きくなる可能性があります。

こういったケースではPay as you growが役に立ちます。

スタンバイのコア数をプライマリより低く設定し、コストを抑えながらOracle Data Guardを構築することができます。

Pay as you growによるスタンバイのコア数変更

Pay as you growによるスタンバイのコア数変更

上記の例ではプライマリが8コアでスタンバイが4コアとなっているため、一般的なOracle Data Guard構成と比べると4コア分のコストを節約できます。

さらなるコスト削減が必要な場合は、スタンバイをRAC One Node構成やシングル・インスタンス構成にすることもできるため、最小のコストで災害対策構成を実現できます。

ポイント③ Active Data Guardによるスタンバイの有効活用

災害対策を検討する際によくあるのが、「災害対策の重要性は分かるけど、普段寝かせている環境に投資するのはもったいない」という意見です。予算確保のために上申したものの、この理由で却下されたという話をよく耳にします。

スタンバイを有効活用する方法として、Oracle Database 11gから提供されているActive Data Guardがあります。プライマリからREDOログの情報を受け取って適用しながら、スタンバイを読み取り専用でオープンできます。

オープンしたスタンバイを使って、集計やレポートの作成といった参照処理を実行することができます。REDOログの適用は継続されているため、最新の情報をもとに参照処理の結果を返すことができます。

Active Data Guardによるリアルタイム・クエリー

Active Data Guardによるリアルタイム・クエリー

Active Data Guardを利用することで、参照系の処理をスタンバイに任せることができるようになるため、プライマリの負荷を大きく軽減することができます。

Oracle Database ApplianceのPay as you growを組み合わせれば、プライマリとスタンバイの負荷バランスに応じてコア数を調整できるため、スタンバイを有効活用する災害対策構成を低コストで実現できます。

散在するデータベースをOracle Database Applianceに統合


皆さんは自社にいくつデータベースが存在するか、数えたことがあるでしょうか?

1システム1データベースというのは大げさかもしれませんが、低価格で高性能のIAサーバーが主流になったこともあり、システムごとに専用のデータベース・サーバーが用意されているケースが多いのではないでしょうか。

専用のサーバーを用意することで、ハードウェアのリソースを占有できるというメリットはありますが、実際にシステムの負荷状況を調べてみると、「ピーク時以外のCPU使用率は数%程度」「メモリの半分が未使用状態」といったことがよくあります。

いわゆる遊休リソースが大量に発生しており、各システムにかかる保守・運用コストを考えると決して良い状態とはいえません。

こうした状況を打開するため、近年ではデータベース・サーバーの統合が盛んに検討されています。サーバーの台数を削減することによって、ハードウェアの保守やソフトウェアのライセンス、運用管理の人件費といったコストを抑えることができます。

統合の基盤となるデータベース・サーバーには、性能や可用性といった様々な要件が求められますが、Oracle Database Applianceであれば十分に対応することができます。

また、Pay as you growやEnterprise Editionの機能を組み合わせることによって、今までなかった新しい統合の選択肢が生まれます。

ポイント① 仮想化を使わないOracle Databaseならではの手法

統合の主な手法として、「物理サーバー統合」、「物理データベース統合」、「論理データベース統合」があります。どの手法を選択するかによって、得られる効果と難易度が異なります。

データベース・サーバーの統合手法と難易度

データベース・サーバーの統合手法と難易度

この中で最も多く行われているのが、物理サーバー統合です。単純にサーバー台数を減らすだけという手法なので、アプリケーションの改修やデータベース設計の見直しも殆ど必要なく、速やかに実施することができます。

また、近年広く浸透してきた仮想化も物理サーバー統合を後押しする要因となっています。仮想マシンごとに独立して管理することができるため、統合前と極力同じ環境を維持したいという場合は仮想化が非常に役立ちます。

しかし、仮想化はデータベースに特化した技術ではないため、仮想化によるオーバーヘッドの影響で思うように性能が出ないことがあります。使用する仮想化ソフトによっては、Oracle Databaseのサポートに制限が加わる場合もあり、コスト削減を達成するためには少なからずリスクを伴います。

そこで仮想化に変わる統合手法として使えるのが、Oracle Database 11g Release2の新機能であるインスタンス・ケージングです。仮想化を使わずに物理サーバー統合を行い、Oracle Databaseの機能で各データベースが使用するリソースの量を制限するというものです。

インスタンス・ケージングによるCPU使用率の制御

インスタンス・ケージングによるCPU使用率の制御

上記の例では、DB#1~DB#4という4つのデータベースをOracle Database Applianceに統合しています。インスタンス・ケージングによって各データベースが使用するCPU使用率を制御できるため、仮想化を使わなくてもデータベースの独立性を確保できます。

例えばDB#1には全体の半数にあたる12コアが割り当てられているため、CPU使用率50%までは占有することができます。他のデータベースがどんなに高負荷だったとしても、50%を超えるCPUを使用することはできません。

設定はOracle Enterprise Managerから簡単に行えるので、使い方はとても簡単です。

データベースがオンラインの状態でも設定を変更できるため、日々の稼働状況に合わせて柔軟な運用が可能です。

ポイント② 無駄なコストを発生させない、段階的な統合

統合するデータベース・サーバーの数が多いほどコスト削減の効果は高まりますが、実際には1度に全てのデータベースを統合するのではなく、段階的に1つずつ統合していくケースがよく見受けられます。

統合基盤となるサーバーには高いスペックが要求されるため、ハードウェアやOracle Databaseのライセンスなど高額な初期投資が必要ですが、段階的に統合していく場合は最初から全てのリソースを使うわけではありません。CPU使用率が極端に低かったり、メモリに大幅な空き領域がある状態が少なからず続くことになります。

Oracle Database ApplianceにはPay as you growがあるため、初期投資を最小限に抑えたスモール・スタートが可能です。最初はコア数を少なく設定しておき、データベースを統合するタイミングでコアを増やせば、無駄な投資が一切発生しません。

Pay as you growを使った段階的な統合

Pay as you growを使った段階的な統合

更に、ポイント①で解説したインスタンス・ケージングを組み合わせれば、追加したコアをどのデータベースに割り当てるのかを簡単に調整することができます。

Oracle Database Applianceユーザの声


続いては、Oracle Database Applianceを実際に採用している現場から届いた声を紹介します。

Oracle Database Applianceは2011年12月に国内販売が開始されたばかりの新しい製品ですが、「シンプル」「低コスト」「高性能」といったこれまでのアプライアンスになかったコンセプトが評価され、既に多くの採用事例が生まれています。

  • 「以前、OSをバージョンアップしようとしたらストレージが対応しておらず、断念したことがあった。Oracle Database Applianceならハードウェアとソフトウェアの相性を気にしなくて良いので非常に安心。」
  • 「Oracle Database Applianceにリプレースしたら、サーバーラックの消費スペースが大幅に減った。データセンターの利用料金を年間百万円削減できる。」
  • 「Tuning PackとDiagnostics Packがあると、Enterprise Managerから簡単にデータベースの稼働状況が分かるので非常に楽。これまで別の管理ツールを利用していたが、Enterprise Managerのほうが簡単で使いやすい。」
  • 「REDOログ・ファイルを低レイテンシーなSSDに配置するのはパフォーマンス上非常に効果的。Enterprise Managerからハッキリと効果が確認できた。」
  • 「数TBの大規模データを扱っているが、(Pay as you growの)4コアで想像以上に良いパフォーマンスが出てしまった。Oracle Database Applianceより高価な機材を使っているユーザのデータベースが想像できない。」


コストやパフォーマンス、Enterprise Editionの機能など、ケースによって評価されているポイントが異なるのが、Oracle Database Applianceならではの面白いところです。

『はじめましてOracle!』の連載は今回が最終回となりますが、今後もセミナーなどを通じてOracle Database製品に関する最新情報を発信していきたいと思います。

記事を読んでいただいた皆様、本当にありがとうございました!


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る