[Leadership Session]AWSデータベースを使った未来への構築 #reinvent #DAT292-L

2020.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちはオンジーです!

[leadership session] DATABASES のセッションに参加しましたので、主に新サービスの紹介にポイントを絞ったセッションレポートになります!

気になった方は後日公開される(はず?)セッションをぜひご覧ください。

セッション概要

登壇者:Shawn Bice 氏  Vice President, Databases, AWS

タイトル:Building for the future with AWS databases

データはあらゆるアプリケーションの中核をなしており、企業はアプリケーションと組織の将来のイノベーションの基盤としてデータを利用しようとしています。このセッションでは、データベース担当副社長のShawn Biceが、完全に管理された目的別データベースを使用して、組織がどのように未来に向けて構築しているかを説明します。既存のデータベースを多用するアプリケーションをクラウドに移行するための支援から、いち早く導入している企業の事例まで、将来に向けて構築を開始するための戦略を紹介します。Shawn氏と一緒に、最新の革新的なデータベースについて(デモを交えて)深く掘り下げてみましょう。

セッションのポイント

セッションで印象に残ったポイントを紹介していきます!

クラウドによるデータベースの変化

プレゼンター「データはアプリケーションや多くのシステムの基礎となるコンポーネントです。強固な基盤を持つことで予期せぬ事態を克服し、革新的で新しい方法を生み出す最高のチャンスを得られます。データベースがクラウドによってどのように変化したか見ていきましょう。」

次のような例を挙げていました。

プレゼンター「AWSに管理されたAPIによって数秒のうちにテスト・インスタンスを作成できる様になりました。本番環境に移行する準備ができたら 大規模なコンピューティング環境にインスタンスを簡単に変更することもできます。」

たしかにメンテナンスされているAPIが公開されておりそれによって様々な操作ができるようになったのはクラウドの大きな強みに感じます。

プレゼンター「またクラウドによってアプリケーションをより小さなパーツに分解できるようになりました。ワークロードとそのアクセスパターンを考え、適切な仕事に適したツールを選ぶことができます。その結果、開発者は機能的なパフォーマンスとスケールをトレードオフする必要がなくなります。」

図の様なそれぞれの機能に特化したサービスをすぐさま起動・連携できるのは大きいですよね。

クラウドが出る前はセットアップや管理が非常に困難なため、しばしば単一のデータベース管理システムに多くのことを展開することを余儀なくされていました。

データベースのマイグレーション

プレゼンター「ここ数年、多くの顧客が加速的にクラウドに移行しているのを目の当たりにしてきました。35万件以上のデータベースがクラウドに移行したということだけではなく、毎年のように顧客が移行しているということもあります。そして多くの顧客がすでに移行している一方で、移行にかかる時間を短縮したいと考えているお客様がもっとたくさんいます。

具体的には、商用システムからオープンソースへの移行にかかる時間を短縮したいということです。」

エンタープライズからオープンソースのデータベースへ移行したいという需要はコストの面でよく聞きますよね。

プレゼンター「SQLサーバーアプリケーションをネイティブで使用している顧客がデータベースを移行する際に、AWSスキーマ変換ツール(SCT)を使用してデータベーススキーマを移行し、AWSデータベース移行サービス(DMS)を使用してダウンタイムを最小限に抑えてデータを移行することで、移行の大部分を自動化することができるとします。

しかし、そうなるとまだまだやるべきことがあります。アプリケーション自体を移行する場合、レガシーなT-SQLをPostgres SQLに書き換えたり、クライアントドライバを切り替えたりする必要があり、面倒で時間のかかる作業になります。(③部分)」

データベースの移行にあたってアプリケーションの改修が入ってしまうのは大きなハードルです。

プレゼンター「左側はT-SQLアプリケーション構文の例で、右側はPostgresアプリケーション構文の例です。SQL文はほぼ同じですが、商品テーブルの識別子が微妙に違うことに注目してください。これらのクエリ結果をよく見てみると価格の違いがあります。Postgresではお金のデータ型が小数点以下の右2桁を使って固定されているからです。この微妙な違いは、正しく対処しなければ、丸めエラーを引き起こし、アプリケーションが壊れてしまう可能性があります。このように、アプリケーションのデータベースコードを移行することは、SQLクエリの書き換えやアプリケーションの再テストに時間がかかることがあります。多くの方がこれを簡単にする方法を求めています。」

例えばSQL Server → Postgresではこういうハードルがあるんですね。

Babelfish for Amazon Aurora PostgresSQL

ここで、Aurora Postgresの新しい機能であるBabelfishが登場します。

プレゼンター「これはSQLアプリケーションが接続するTDSエンドポイントです。①レガシーアプリケーションのコードはSQL Server用に書かれたままで、②クライアントドライバを変更する必要はありません。先ほど見たお金のデータ型の例のように、ユニークなデータ型の場合、どのような新しいアプリケーションでもPostgresにコードを書くことができ、レガシーなT-SQLと並べて実行することができます。」

なるほどこのケースに当てはまればBabelfishで移行のハードルがグッと下がりそうです!

プレゼンター「BabelfishはAmazon Aurora PostgresSQLのための新しい翻訳レイヤーで、Microsoft SQL Server用に書かれたアプリケーションからのクエリをAuroraが理解できるようにします。Babelfishを使えば、現在SQLサーバー上で動作しているアプリケーションをAurora Postgres上で直接実行することができ、コードをほとんど変更する必要がありません。また、アプリケーションのクエリを書き換える必要もありません。

アプリケーションのテストが終わったら、SQL Serverデータベースをシャットダウンして、必要のないライセンスの支払いを止めることができます。これにより、レガシーアプリケーションのコードを新しいデータベースで動作するように更新するのに費やしていた数ヶ月から2年の時間を節約することができます。」

プレゼンター「Babelfish for Postgres SQLはオープンソースプロジェクトで、この翻訳レイヤのソースコードをカスタマイズしたり、新しい機能を追加したりしたい人が誰でも利用できるようにします。すべての作業と計画はGitHub上で行われ、私たちが取り組んでいる特定のSQL Serverの機能について完全な透明性を得ることができます。来年利用可能になります。」

One size fits nothing at all

プレゼンター「私たちが学んだことの中で最も重要なことは、One size fits nothing at all1つのサイズには何も当てはまらないということでした。あらゆるワークロードのアクセスパターンやストレージのニーズに最適に対応できる単一のデータベース管理システムという考えは過去のものです。適切なデータ基盤の鍵は、開発者に自分の得意なことをさせることです。これまでは単一のモノリスとして開発されていた複雑なアプリを、より小さな断片に分解し、適切な仕事に適したツールを選択します。」

冒頭でも似た様な話が出ましたが1つのデータベースに色々役割持たせすぎちゃダメだよっていうメッセージを強調していました。

AWS Glue Elastic Views

プレゼンター「AWS Glue Elastic Viewsを使うと、SQLを使って、異なるデータストアから結合したいデータのマテリアライズドビューと呼ばれる仮想テーブルを素早く作成することができます。マテリアライズド・ビューの定義に基づいて、エラスティック・ビューは各ソース・データベースからターゲット・データベースにデータをコピーし、ターゲット・データベースのデータを自動的に最新の状態に保ちます。データモデルとソースデータベースのいずれかに変更があった場合、開発者に積極的に警告を発し、この変更に適応するためにビューを更新することができます。開発者が運用データベースからS3などのデータレイクに運用データをコピーして、ほぼリアルタイムでアナリティクスを実行したい場合も、それが可能です。また、ワークロードの増減に応じて自動的に容量をスケーリングしてくれるます。これにより、自分でやろうとする煩わしさがなくなり、数ヶ月から数分へと時間を短縮することができます。」

AWS Glue Elastic Views でデータ転送・同期が容易になるかも?まだプレビューですがこれからの検証ブログが楽しみですね!

Aurora Serverless v2

プレゼンター「Aurora Serverless v2は、データベースのワークロードを数百から数十万トランザクションまで、あっという間にスケールさせることができます。データベースのワークロードをスケーリングするたびに容量を2倍にするのではなく、Aurora Serverless v2は、アプリケーションが必要とするちょうど良い量のデータベースリソースを提供するために、容量を微調整します。顧客は消費した容量分だけを支払うので、ピーク時に容量をプロビジョニングするコストと比較して、データベースコストを最大90%削減できます。

また、Aurora Serverless v2は、1つのAuroraデータベースを複数のAWSリージョンにまたがって低レイテンシのバックアップを可能にするマルチAZサポートグローバルデータベースを含む、Auroraの機能をフルに提供します。並行してAuroraのデータに対して高速な分析クエリを実行するために、Auroraを特定の時点にリセットしたり巻き戻したりすることができます。

Aurora Serverless v2は本日プレビューでAmazonのMySQL互換版、Aurora Postgresは来年早々にもプレビューで公開される予定です。」

既存の Aurora Serverless から高可用性が大幅に強化されるとのことでこちらも今後の検証ブログが楽しみなサービスですね!

AWS re:Invent 2020 Virtualは 〜12/19までと1/12 - 1/14(JST)で開催中です!

参加がまだの方は、この機会にぜひこちらのリンクからレジストレーションして豊富なコンテンツを楽しみましょう!

AWS re:Invent | Amazon Web Services

またクラスメソッドではポータルサイトで最新情報を発信中です!

AWS re:Invent 2020 JAPAN PORTAL | クラスメソッド