目次
はじめに
Oracle は強力なデータベースであるにもかかわらず、他のデータベースプラットフォームが企業の特定ミッションにおいて Oracle に取って代わりつつあります。たとえば、Oracle には PostgreSQLなどのオープンソースデータベースのようなオブジェクトリレーショナル機能がなく、オープンソースデータベースよりも動的な拡張性に劣るという欠点があります。これは、複雑なライセンス要件によるものです。Oracleを使用すると、拡張可能な容量を提供するためにインフラストラクチャに多くの費用がかかります。また、Oracleのサポートは価格が高く、大企業ではOracle専任のコンサルタントを雇用したり、ライセンス料の25%という高いコストでOracleのサポートに費用をかけたりしています。
これは、OracleがエンタープライズITに存在しないことを意味するものではありません。Oracle は業務系アプリケーションでは依然として不可欠ですが、高価な Enterprise Edition(EE)機能の必要性は、特に Web ベースのアプリケーションでは低下しています。
その結果、多くの IT 企業が、特定のアプリケーショ ン向けに EE から Standard Edition(SE)、あるいはオープン ソースやクラウドのデータベース プラットフォームに移行することで、Oracle のライセン ス費用を削減できることを見い出しています。他のデータベースプラットフォームが Oracle と同程度に強力であるとは 誰も言っていませんが、特定のミッションに対しては、そちらの方がコスト効率に優れている可能性があるというだけです。Oracle は複雑であるため、PostgreSQL や Oracle オープンソースの MySQL など、他のプラットフォームにはない DBA や DevOps のコストがかかることがよくあります。また、代替データベースの参入コストが低いことに加え、Oracle では、数百または数千のクラウド プロセッサへの動的スケーリングなど、他のプラットフォームが提供する機能の一部を実現できません。
Oracle の最も費用対効果の高い長所と、利用可能な移行経路を理解することで、他のプラットフォームの利点を得ながら、より少ない費用で現在のものを利用することが可能になります。
Oracle EEとSEの比較:懸念事項と注意点
Oracleのライセンスコストを削減する最初のステップとして、企業はEEからより安価なSEライセンスへのステップダウンを検討することがよくあります。これはコスト削減につながりますが、EE機能がアプリケーションに不可欠でない場合に限ります。SEに移行すると、いくつかの主要な機能が失われます。
● 自動ワークロードリポジトリ(AWR)および自動データベース診断モニタ(ADDM)を含む、ほとんどのデータベース開発、診断、チューニング、および管理用ツール
● すべてのデータベースパフォーマンスモニタリング
● データベースのレプリケーション
● 一部のレジリエンス機能(例:アクティブ Data Guard、二重化バックアップ、スナップショット、REDO)
● パフォーマンス(例:キャッシュなし、OESS)
● 高セキュリティ機能(例:きめ細かい監査、ODV、OLC、OAS)
● データウェアハウスとオラクルビジネスインテリジェンス
● データのマスキングやサブセット化などのセマンティクス抽出
また、SE には固有の容量制限があり、最終的に最大性能を低下させます。
● CPU ソケットは 2 つしか許可されないため、既存の 4 ソケットホストではハードウェアのフォークリフトが必要になります。
● Real Applications Cluster (RAC) は、v18c まではサーバあたり 1 ソケットに制限されていますが、v18c はまだ完全にサポートされています。(RACはv19cで利用できなくなりました。)
● データベースはインスタンスあたり16スレッドに制限されます。
良い点としては、稼働中のデータベースをEEからSEに移行するのは簡単で、Oracleデータベースのエコシステム内に完全にとどまるため、容易です。両エディションに共通するものはすべて同じように機能します。これは、あらゆるデータベース移行に共通するリスクであり、適切なバックアップによって潜在的なデータ損失とダウンタイムを軽減することと、DBAとDevOpsスタッフの作業負荷が増えることの2つについて、計画しなければなりません。
また、隠れたライセンスの罠にも注意が必要です。EEライセンスの一部の機能はSEでも使用できますが、監査時に手数料や違約金を支払わなければなりません。これらを考慮して回避しないと、ライセンス違反のペナルティによって、SEへの移行によるコスト削減効果が帳消しになる可能性があります。ちなみに、SE移行プロジェクトは、Oracleデータベースのバージョン番号を上げる、あるいはOSを切り替える(例:SolarisからLinux)良い機会でもあります。これにより、EE専用の機能は失われるものの、少なくとも最新のテクノロジーに移行することができます。
失われたEE機能の代替
アプリケーションにはEEの機能が必要な場合がありますが、オープンソースを含む他の安価な製品で代用できる場合があります。SQLデータベースの代用品はいくつかあります。Amazon Aurora、IBM Db2、MariaDB、Microsoft SQL AzureとSQL Server、Oracle MySQL、PostgreSQL、SAP ASEなどです。これらはそれぞれ、さまざまなアプリケーションの要件に応じた強みを持っています。幅広い機能を活用し、アプリケーションに最適なデータベースを適合させる価値があります。例えば、Db2 は IBM のミッドレンジやメインフレ ームシステムと相性が良く、MariaDB は大規模な組織や企業ユーザのためのビッグデータを扱うことが可能です。
この機能代替評価の一環として、各データベースを重要度で優先順位を決め、ミッションクリティカルなデータベースの保護により多くの労力を費やす必要があります。EEライセンスの大幅なコスト削減を実現していますが、経営陣は利益のことしか考えていないので、初期コストの削減を経営陣に伝える必要はありません。したがって、ライセンスコストの節約分を、すべての Oracle エディション、またはクラウドやオープンソースを含む、幅広いデータベースプラットフォームをサポートする新しいツールセットの資金に充てることも可能です。
とはいえ、異種ツールの乱立を避け、可能な限り「エンタープライズ」な機能セットを備えた統一プラットフォームを目指すことが重要です。DBA/DevOpsチームから感謝されるでしょうし、今後の人件費も節約できでしょう。
SEへの移行戦略を決定したら、移行前のベンチマークテストを実施することが次のステップとなります。このようなベンチマークは、移行計画の重要な検証(テストにより、DBAが対応するEEとSE機能の正しい動作を評価する)を行うだけでなく、パフォーマンスの基本測定値を得ることができます。SEベンチマークをEEクリティカル・アプリケーションのベースライン測定値と比較することで、潜在的なパフォーマンスのボトルネックを回避することができます。ベンチマークとベースラインを比較することで、パフォーマンスの問題がどこにあるのかをよりよく理解することができます。
代替データベース・プラットフォームへの移行
Oracleユーザにとって、EEからSEへの移行は唯一のコスト削減策ではありません。PostgreSQLやMySQLなどのオープンソースシステムを筆頭に、他にも数多くのデータベースプラットフォームが存在します。多くの場合、組織内のプラットフォームの変更は、新しいアプリケーションの展開と関連しているため、既存のデータの移行は問題ではありません
代替データベースを検討する際には、いくつかの重要な要素があります。サポートは重要な検討事項です。多くの場合、オープンソースプラットフォームには、時間的・物質的な支援を提供するために雇用できる営利目的のサポート組織が存在します。Oracle のサポートほど包括的ではありませんが、必要なサポートに 対してのみ料金を支払えばよいのです。さらに、PostgreSQLとMySQLのコミュニティサポートは非常に強力で、有償のコンサルタントよりも迅速に回答を提供できることがよくあります。EnterpriseDB EDB Postgresのような、商業的にサポートされているオープンソースエディションを検討する価値は十分にあります。これらは通常、スケーリング、保守、配布、 および開発者サポートを支援するサブスクリプションベースのサービスを提供し ています。EDB Postgresは、EnterpriseDB の比較資料によると、機能ベースで Oracle EE とよく比較されています。このため、脱Oracleでは、EDB Postgres を選択することも理にかなっています。
Database Performance Analyzer がサポート
Database Performance Analyzer (DPA) for Oracle SE (DPA-SE) は、Oracle SE およびその他のデータベース・プラットフォーム用の統合パフォーマンスおよび診断モニターです。DPAは、OEMに依存することなく、Oracle指向のパフォーマンス監視および診断を提供します。DPAを使用すると、RAC固有の待機イベントを監視してOracle RACを最大限に活用できますが、CPUとメモリのオーバーヘッドが1%未満なので、Oracleであるかどうかにかかわらずデータベース性能に影響を与えることはありません。
Aurora、Azure SQL、MariaDB、MySQL、PostgreSQLなどのオープンソースデータベースでは、DPAは拡張性の高いインフラストラクチャに固有の管理ニーズに対応します。アプリケーションをクラウドに移行する場合、ネイティブであるか、Amazon EC2やRDS、Microsoft Azure SQLなどのPaaSやDBaaSソリューションを使っているかにかかわらず、DPAによってクラウドパフォーマンスと従量課金制のトランザクションコストを管理することができます。
また、DPAのコストモデルは、年間20%という高額な更新料を含むオラクルのプロセッサー単位のライセンス料よりもはるかに魅力的です。DPAでは、各管理パッケージ(診断パック、チューニングパック、データベースライフサイクル管理パック、データベースマスキング&サブセットパック、クラウド管理 for Oracleパック)に対して、インスタンスのデータベース数に関わらず一律の価格が設定されています。
結論
Oracleに費やす費用を削減しながら、機能と俊敏性を向上させるための選択肢がいくつかあります。多種多様なOracleデータベースは、企業ユーザに優れた信頼性と機能を提供し続けていますが、Oracle Enterprise Edition(EE)の機能を厳密に必要としない場合は、可能な限りOracle Standard Edition(SE)、または代替データベースに移行して、さらにコストを削減することが賢明です。
SEでは多くの管理機能が削除されますが、EEライセンスの削減による節約分を代替ツールの資金として活用することができます。DPA for Oracle SEを使用すれば、EEの多面的な管理機能をあきらめる必要はありません。
関連したトピックス
- DPA(Database Performance Analyzer) for Open-Source Database: MySQL, MariaDB, Percona, PostgreSQL
- データベースのバックアップはどのように業務を遂行しているかに依存する
- 進化するクエリと PostgreSQLの台頭:そのデータベー スパフォーマンス重要性
- SQL ServerとMySQLリレーショナルデータベースの比較
- PostgreSQLパフォーマンス・チューニング・ツール(クエリアナライザ付き) [DPA]
- PostgreSQLとMySQLのデータベースとしての機能の違い
- Oracle SE データベースと Query Performance Analyzer [Oracle Performance Analyzer: DPA]
- メモリとインスタンスのパフォーマンス監視のためのAmazon AWS EC2 Monitor [DPA]
- Azure Database for PostgreSQLを使い始めるにあたって
- Database Performance Analyzer [DPA] でSQL Serverのパフォーマンスを見つけ、分析し、最適化へ