クラウド運用管理

Oracle DatabaseをAWSへ移行するには?~事例で学ぶ検討ポイント~

近年のクラウド化の加速に伴い、オンプレミスで運用していた業務システムをパブリッククラウドへ移行するお客様が増えています。
特に、エンタープライズでの利用が多いOracle Databaseをクラウド移行したいというご相談を多く受けます。
本記事では、特にご相談が多いOracle Databaseをアマゾン ウェブ サービス(Amazon Web Services:以降、AWSと略す)に移行する際に取り得るシステム構成や注意点などを、実際にあった事例をもとに説明します。

本記事はこんな方にお勧めします

  • オンプレミスのOracle DatabaseをAWSに移行することをご検討中の方
  • オンプレミスからAWSに移行することでどのように費用が変わるのか知りたい方
  • AWS上で業務システムを運用するにあたってクラウドの障害やその復旧に不安がある方

1. AWSにおけるシステム構成のパターン

オンプレミスのOracle DatabaseをAWSへ移行する際に、まずは、コンピュートサービスであるAmazon EC2(以降、EC2と略す)とマネージドサービスであるAmazon RDS(以降、RDSと略す)のどちらのサービスを利用するか決定します。
それぞれのサービスの特徴を踏まえたうえで、お客様の要件に沿ったサービスを選択します。
EC2は、ユーザーが配備したインスタンスにOracle Databaseなどのソフトウェアをインストールして利用できるため、オンプレミスとほぼ同じ利用形態となります。 ユーザーが自由に運用できますが、そのための運用費が必要になります。
RDSは、AWSマネージドサービスとして提供されており、セットアップからパッチ適用などの運用まで含めてほぼAWSにお任せできるので、導入や運用費を削減できます。 ただし、データベース単体としてのサービスなので、アプリケーションなどは別サーバーで運用する必要があり、1台でアプリケーションとデータベースを稼働させる場合と比較して費用が割高になります。
利用するサービスを決定したら、次に、システム構成について検討します。
システム構成は、サーバー単体構成と冗長構成があります。 サーバー単体構成は、単一のインスタンスから成るシステム構成で、サーバー冗長構成は複数のインスタンスから成るシステム構成です。 高い可用性が求められるシステムであれば冗長構成、そうでなければ単体構成が適しています。
まとめると、システム構成は4つのパターンに分かれます。

サービス サーバー単体構成 サーバー冗長構成
EC2 EC2単体 HAクラスタソフトウェア
RDS Single-AZ配置 Multi-AZ配置

どのパターンが適しているかは、システム要件によって変わります。
今回は、オンプレミス環境の社内システムをAWSへ移行することを検討中のお客様から、実際にご相談いただいた内容を基に、選定のポイントを説明します。

2. お客様の移行要件の例

現行環境

  • オンプレミス環境で運用している社内システム
  • アプリケーションとデータベースが同一サーバー上で動作
  • 費用の観点からデータベースは冗長化しておらず、故障が発生した場合は手動で復旧

AWS移行後の要件

  • 構成:オンプレ資産を活かすためアプリケーションとデータベースは同一インスタンス内に構築したい
  • 可用性:業務停止した場合は、2時間以内に復旧したい
  • 費用:現行環境の運用費と同等にしたい
  • 障害発生時の運用負荷:AZ障害時のインスタンス復旧は可能な限り自動化したい

構成については、現行環境で同一サーバー内にアプリケーションやデータベースソフト、監視ソフト等を運用しており、AWS移行後もこれらを利用したいと考えていました。
可用性については、帳票システム、勤怠管理システム、内部向けWebサーバーなどの社内システムを移行対象としており、いずれもシステム停止時の影響度を中程度として、1~2時間の業務停止であれば許容範囲と考えていました。
障害発生時の運用負荷については、これまで現行環境で障害が発生した際は、手動でシステムを復旧していましたが、手順のメンテナンスや障害発生時の費用を削減するために、AWS移行後は復旧を自動化したいと考えていました。
まとめると、社内システムということもあり、高い可用性は求めない代わりに、ライセンス費用や障害発生時の運用負荷を抑えたいという要件となっていました。
今回のお客様では、構成に関する要件(アプリケーションとデータベースを同一インスタンス内に構築したい)を満たすため、RDSではなくEC2を採用しました。
以降は、EC2を選択した場合に絞って説明します。

3. システム構成の検討

サーバー単体・冗長構成は、それぞれに一長一短があるため、お客様の要件に沿ってどちらがより合うかを決める必要があります。
ここでは、それぞれの構成について概要と、お互いのメリット・デメリットを比較します。

3.1. サーバー単体構成

データベースを1台で運用する構成です。

サーバー単体構成図

Figure 1: サーバー単体構成図

この構成における最大のメリットは費用です。
インスタンスが1台なので、AWSの利用料金やOracleライセンス費用などをサーバー冗長構成と比較して低く抑えられます。
例として、以下のシステム構成でEC2インスタンスを1年間運用した場合の費用を参考として記載します。(注1

  • インスタンスタイプ:m5.xlarge(4vcpu) = 2,698.08 USD ≒ 350,000円
  • Oracleライセンス:SE2(1年間サポート付) = 2,989,000円
  • 合計:3,339,000円

一方、デメリットとしては、可用性が低くなる点が挙げられます。
サーバー単体構成の場合、必然的にSingle-AZ配置での運用になるため、AZ障害が発生した場合はデータベースが停止します。 EC2のSLAは90%を保証しており、これは年間約30日停止する可能性があるため、要件によっては問題となるケースがあります。 可用性を求めるシステムでは、複数のAZを活用することが推奨されているため、手順など何らかの方法でAZを切り替える復旧手段を用意する必要があります。 しかし、復旧に必要なボリュームのバックアップの設計や、復旧手順書のメンテナンス、検証などに追加の費用が必要になります。
また、障害が発生したサーバーを別のAZに切り替える際には注意が必要です。 Oracleのライセンス違反を起こさないためには、障害が発生したサーバーを必ず削除し、削除を確認したあとに、別の正常なAZで再作成する必要があります。 もし、Oracleがインストールされたサーバーが各AZに同時に存在した場合、必要なライセンスが2倍必要になるため、このような対処が必要です。 一見単純な手順には見えますが、障害発生時に遵守することは作業者の心理的にも大きな負荷がかかり、作業ミスなどのリスクがあります。
このように、サーバー単体構成では、お客様の要件によっては費用をクリアして、復旧手段を準備することで、可用性の問題を回避できるケースがあります。しかし、依然としてAZ故障時の復旧にかかる費用の増加や予期せぬトラブルによる可用性に対するリスクが残ります。

3.2. サーバー冗長構成

EC2インスタンスをHAクラスタソフトウェアなどで冗長化する方法です。
この構成では、データベースを複数台で運用できます。
今回は、Oracle Data Guardを利用した構成を例に説明します。

サーバー冗長構成図

Figure 2: サーバー冗長構成図

この構成における最大のメリットは高い可用性です。 障害発生時に待機系のデータベースへ自動で処理を引き継ぐため、業務停止時間を大きく短縮できます。
また、切り替え時間も数分程度と高速です。 データベースを別AZに配置することで、AZ障害時も障害が発生していないAZに自動で切り替わり、業務が継続できます。 サーバー単体構成ではインスタンスを手動で復旧するケースが多いですが、サーバー冗長構成の場合、その手間はなくなります。
一方、デメリットとしては、費用が高額になる点が挙げられます。 例として、サーバー単体構成の例と同様のEC2インスタンスで1年間運用した場合、以下のような料金となります。(注1

  • インスタンスタイプ:m5.xlarge(4vcpu) x 2 = 5,396.16 USD ≒ 701,000円
  • Oracleライセンス:EE(1年間サポート付) 8,113,000円 x 4 = 32,452,000円
  • 合計: 33,153,000円

サーバー単体構成の3,339,000円に対して、およそ10倍と高額になることがわかります。

4. まとめ

最後に、今回のお客様の要件のポイントである可用性、費用、障害発生時の運用負荷に対して検討結果をまとめます。

要件 サーバー単体構成 サーバー冗長構成
可用性 低(1~2時間で復旧) 高(数分で切替え)
切り替え操作 手動 自動化可能
費用 低額 高額

このお客様では、サーバー単体構成において、障害発生時の復旧運用の問題に対し、手作業による復旧手順を作成して対処しようと検討していました。
しかし、その作業は複雑であり、緊急時の実施では心理的な負荷も大きく、ミスのもとになります。
一方で、サーバー冗長構成では、可用性や復旧運用も優れていますが、待機サーバー分、Oracleのソフトライセンス費用を追加で負担する必要があります。
いずれの構成においても一長一短で、今回のお客様の要件を満たせません。
このように、可用性を確保しつつ、費用を抑えた運用が難しいという、同様のお悩みを持つお客様から多くの声を受けていました。
そこで、今回のお客様のような要件を満たせる製品をリリースしました。

5. PRIMECLUSTER Cloud Editionによる解決

当社製品のPRIMECLUSTER Cloud Editionでは、今回のお客様の要件に対して、可用性、障害発生時の運用負荷をクリアしながら、費用面でも冗長構成と比較して4割以上削減できました。
このように、Oracle DatabaseをAWSに移行するにあたり、可用性を確保しつつ、費用を削減したいとお考えの方は、以下の記事を是非ご覧ください。

  • 注1
    記載している費用は、比較の目安として、当社調べ (2023年2月現在。1USD=130JPYで計算) によりEC2インスタンスとライセンスのみの費用を算出したものです。実際の利用には、ストレージやネットワークなど他にも利用料が必要となります。
  • 備考
    Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
    Amazon Web Services、Amazon RDS、 Amazon EC2、 AWS Cloudは、Amazon.com, Inc. またはその関連会社の商標です。
    記載されている会社名、システム名、製品名、サービス名などの固有名詞は一般に各社の登録商標または商標です。
    また、本文および図表中に記載されている会社名、システム名、製品名、サービス名などには必ずしも「TM」、「®」を付記しておりません。

本コンテンツに関するお問い合わせ

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)

0120-933-200

受付時間:9時~12時および13時~17時30分
(土曜日・日曜日・祝日・当社指定の休業日を除く)

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ