同じ「データベースのクラウド移行」、なのに違う!?　AWSとオラクルの「戦略の違い」を理解する：Database Watch（2017年5月版）（1/2 ページ）

連載バックナンバー

　「データ基盤のクラウド移行」を計画する企業の需要が急速に高まっています。

　しかし「データ基盤をクラウド化する」にしても、業界、業種、システム規模、用途などによって、企業が選ぶべき選択肢はオンプレミスと同様に無数に存在します。「そもそも、よく分からない」などと諦めて、変革を止めてしまうと、今度は「ライバル社や、最初からクラウド活用を武器にしている“新たな参入者”に先を越され、ビジネスが先行かなくなる」恐れもあるといわれます。

　そこで今回は、クラウドで使うデータベースの2大サービスと位置付けられる、AWS（Amazon Web Services）の「Amazon Aurora（以下、Aurora）」と、Oracle Cloudの「Oracle Database Cloud Service」を比較し、両者の機能や戦略の違いから「自社はどちらが合っているか」を判断するためのヒントを探ります。

　まずAuroraは、クラウドプラットフォームであるAWSでの利用を「前提」にしたデータベースサービスです。一方のOracle Database Cloud Serviceは、2017年現在もオンプレミス環境で多く使われているOracle Databaseを、そのままクラウドへ移行、また、その逆も含めてクラウドとオンプレミスを行き来できるように工夫され、これまでオンプレミスで実現してきた機能や特徴はそのままに、クラウドで使うメリット“も”享受できるよう工夫されたサービスです。どちらも、「特にクラウドでの利用を推進する企業」を強力に支援する姿勢は変わらず、日々機能は進化しています。

クラウドでの利用に特化して独自開発された「Aurora」

　Auroraは、AWSで提供されるデータベースサービス群「Amazon Relational Database Service（以下、Amazon RDS）」の1つで、AWSが独自開発したMySQL互換のデータベースサービスです。マネージドサービスなので運用管理はAWSに任せられ、ソフトウェアのライセンス料は不要、利用料金は使った分だけとするシンプルな課金体系となっています。耐障害性や自己修復機能も備え、扱うデータ量に応じてストレージ容量を自動的に64TBまで拡張できることなどを強みとしています（2017年5月時点）。

Amazon Aurora

　中でも大きな特徴といえるのは、Auroraは「AWSが独自開発したRDB（リレーショナルデータベース）である」ことです。大昔、RDBが登場した頃はまだクラウドという概念がありませんでした。そのために一般的なRDBは、原則として従来型のインフラ環境で稼働させることを前提としたアーキテクチャになっています。それに対してAuroraは、「最初から」AWSのクラウドインフラを最大限生かすようにRDBを再構築して設計されています。そもそもクラウドで稼働させることを前提にしてあることから、「クラウドネイティブである」などとも表現されます。

　AWSは、このAuroraをとても力を入れて開発しています。当然、時代のニーズも迅速に採り入れています。例えば、容易で柔軟なスケールアウト性、高いスループットパフォーマンス、マネージドサービスなど、これまでのオンプレミス環境のシステムやソリューションでは簡単にはできなかった、クラウドならではの利点を最大限に生かした機能やサービスを実現しています。またAuroraは、Amazon Simple Storage Service（以下、Amazon S3）やAmazon Elastic Compute Cloud（以下、Amazon EC2）などのAWSの豊富なサービスとも容易に連携できる、AWSならではのアーキテクチャになっています。

　一般的な従来型RDBとの大きな違いは、キャッシュとストレージです。Auroraでは、キャッシュをデータベースプロセスと切り離して管理します。データベースプロセスを再起動したとしてもキャッシュは別に残る仕組みのため、万が一のときも素早くデータベースをリカバリーできる利点があります。また、データの保存先は、フラッシュベースのディスクに6つ、正しくは「3つのAZ（アベイラビリティゾーン）に2つずつ」のコピーを作成する体制を提供する他、障害の自動検知と自動修復などの耐障害性に優れた機能も備えています。

　Auroraは、2014年の年次イベント「re:Invent 2014」で発表されました。それから2年後の2016年12月に行われた「re:Invent 2016」では、ユーザーから要望が高かったとされるPostgreSQL互換版の「Amazon Aurora PostgreSQL-compatible edition」も追加されました。2017年5月現在、プレビュー版として展開されています。

　AuroraのPostgreSQL互換版は、Amazon RDSのストレージエンジンを選択をするところで、PostgreSQLではなく、Auroraを選ぶと選択できます。ちなみにここでPostgreSQLを選ぶと、別のサービスであるAmazon RDS for PostgreSQL（Amazon RDSで、エンジンにPostgreSQLを選択したもの）が対象になるので注意してください。少し分かりにくいのですが、プレビューから一般公開版になれば、Auroraを選んだ画面でMySQL互換版とPostgreSQL互換版が並ぶことになるようです。

　AuroraのPostgreSQL互換版は2017年5月現在、PostgreSQL 9.6.xと互換性があり、Amazon RDS for PostgreSQLで提供される機能や拡張モジュールは同等と告知されています。また、64TBまでの自動スケール機能や、3つのAZに計6つのコピーを作成する機能など、AuroraのMySQL互換版と基本的な仕組みはだいたい同じです。

　ただし、AuroraのPostgreSQL互換版には「Performance Insights」と呼ばれる機能が“別途”組み込まれる違いがあります。Performance Insightsは、「どのクエリがどのくらいのCPUやメモリを使ったか」などを管理コンソールからドリルダウンして調べられるようにするツールです。データベースの状態を手軽にチェックするのに役立つでしょう。Performance InsightsはAmazon RDSの他のサービスにも展開される予定ですが、最初はAuroraのPostgreSQL互換版だけの利点となりそうです。

AWSの星野豊氏

　2017年3月に開催された「JAWS Days 2017」でも、AWSがAuroraに力を入れていることがうかがえます。セッションに登壇したアマゾン ウェブ サービス ジャパン 技術本部 レディネスソリューション部 ソリューションアーキテクトの星野豊氏が「（Auroraは）ここ半年で、特に可用性向上のための機能改善を集中的に行った」と述べ、集中的に可用性を向上させる方針を示しました。Auroraは基本的にスループットを高める作りになっているものの、運用中に可用性を落としてしまう要因が生じる可能性がありました。そうした穴をゼロに近づけていくことで、結果として可用性も向上させる考えだといいます。

　例えば、先日リリースされた「ゼロダウンタイムパッチ」機能。ゼロダウンタイムパッチは、データベースやソフトウェアにパッチを適用するときのダウンタイムを極力なくせる機能です。これまでは一度セッションを切断する必要がありましたが、この機能によって、サービス停止なしはおろか、「セッションを維持したまま」パッチを適用できると説明されています。一応、2017年5月時点のプレビュー版では、長時間実行中のトランザクションがあったり、テーブルがロックされていたりする場合などには適用できない課題が残っているそうなので、こちらは注意してください。

　この他、「高速DDL」も注目されています。これは、2017年4月にリリースされたAuroraの新しいバージョン「1.12」で実装されました。DDL（Data Definition Language：データ定義言語）でカラムを追加する時の処理が、これまでより高速になります。特に「大きなテーブルにカラムを追加するとき」に効果があると説明されています。2017年6月時点では、「ラボモードを有効」にすると利用できます。

　さらに、これまでは「監査のプラグインを有効にする」ことも可用性を落とす要因の1つとされていました。監査のための操作履歴取得は、多くのソフトウェアではシングルスレッドで記録されるため、処理遅延の要因になるわけです。それに対してAuroraでは、この処理をマルチスレッド化する改善によって、全体のパフォーマンスを落とさない工夫をしているといいます。

　最後に、今後の実装が予定される機能である「Online point in time restore」にも筆者は注目しています。Online point in time restoreは、データベースのデータを指定した時間の状態に戻す機能です。通常は特定の時間に採取したスナップショットなどからリカバリーしますが、Online point in time restoreでは「指定時間以降のログを非表示にする形」で指定した時間の状態に戻す仕組みを採用しています。さすがに「半年前のある時点」までに戻すのは難しいとしても、直前の操作ミスをリカバリーする程度の時間なら迅速に戻せるそうです。これもAuroraのログの性質を生かした、ニーズのある実装といえます。