[レポート]データベースもマイクロサービス化！Purpose-Built Databaseのススメ #reinvent [DAT209-L]

AWS re:Invent 2019

春田拓海 | Takumi

2019.12.19

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

こんにちは。DA事業本部の春田です。

本記事は、AWS re:Invent2019の DAT209-L: Leadership session: AWS purpose-built databases のセッションレポートです。

The English version is here.

概要

In this session, Shawn Bice, VP of databases, discusses the AWS purpose-built database strategy and explains why your application should drive the requirements for which database(s) to use, not the other way around. Learn about the purpose of each AWS database service and how AWS customers are using purpose-built databases to build some of the most scalable applications on the planet. If you are a technology or engineering leader and you’re trying to understand how to modernize your data strategy, this session is for you. We discuss using various approaches for new application development, lifting-and-shifting to managed services, and refactoring monolithic database architectures to use purpose-built databases.

このセッションでは、データベースのVP、Shawn Bice氏がAWSの最適なデータベース戦略について議論し、なぜアプリケーション側がどのデータベースを使用するべきかの要件を掘り下げていき、その逆はないのかを説明します。AWSのデータベースサービスそれぞれの目的についてと、AWSのカスタマーはグローバル規模でスケーラブルなアプリケーションを構築するために、どのように最適なデータベースを使っているのかが学べます。あなたがもし、技術やエンジニアリングのリーダーで、今のデータベース戦略をモダンなものにどう変えていくか理解しようとしてるのであれば、このセッションがまさに当てはまります。このセッションでは、新しいアプリケーション開発のための様々なアプローチ方法や、マネージド・サービスへのリフト&シフト、モノリシックなデータベースアーキテクチャのリファクタリングを通して議論していきます。

スピーカー

Shawn Bice
- VP, Databases, Amazon Web Services
Tobias Ternstrom
- Director, RDS & Aurora, Amazon Web Services
Joseph Idziorek
- Principal Product Manager, Amazon Web Services

AWSのデータベースサービスは、ここ数年でかなり多様化してきました。その根本にあるのは、 Purpose-Built Database という用途別に適切なデータベースを使い分けるというAWSが提案するアーキテクチャの戦略です。このセッションでは、それぞれのサービスがどうカテゴリ化されており、どう使っていけば良いのかを、最新のアップデートを含めて、事例と一緒に解説しています。データベースエンジニア必見です！

ここ数年かけて進化してきたアプリケーション・アーキテクチャ

開発者たちの最近の傾向は……
- モノリシックなアプリを構築したくない
- 用途に沿ったシステムを目指している
- 大きなアプリケーションを小さなパーツに分解
- 適切なジョブのために、適切なツールを選択したい

60年代：メインフレーム
80年代：クライアント・サーバー
1. アプリケーションのロジックをデータベースから分離
90年代： 3層構造
1. インターネットが登場
2. クライアント層、アプリケーション層、単一のデータベース層
マイクロサービス
1. クラウド時代に突入し、システムはより特化型に
2. データベースがより特化し始めている

共通のデータベース戦略

データベース戦略を考えるための簡単な方法　→　カテゴリ化

リレーショナル型
1. レスポンスを強固に一貫させたい
2. データ型に一貫性をもたせる
Key-Value型
1. １つのアイテムでも１兆のアイテムでも、同じパフォーマンスが出るようスケール
ドキュメント型
1. システムを止めることなく、JSONのようなデータ型を作成
インメモリ型
1. 頻繁にアクセスするデータは、テーブルのフルスキャンをさせない
グラフ型
1. 高度にコネクションがあるデータ
時系列型
1. 主軸が将来的に続いていくデータモデル
2. アップデートはなし、インサートのみ
台帳型
1. 一度記入したら、二度と変更できない
2. 暗号的な認証性によって、変更不可能なトランザクションログに

顧客が求める最優先事項

マネージドサービスへ移行
1. サービス： RDS, Aurora, ElastiCache, DocDB
2. ツール： SCT, DMS
3. プログラム MAP, Pro Serve, Partner
ライセンスからの開放
1. サービス： Aurora, Amazon Redshift
2. ツール： SCT, DMS
3. プログラム： MAP, DM Freedom, Pro Serve, Partner
モダンなアプリケーション
- 新たな要件
  - ユーザー数： 100万人以上
  - データ量： TB〜PB〜EB
  - パフォーマンス：ミリマイクロ秒
  - リクエスト率：数100万以上
  - アクセス方法：どんなデバイスからでも
  - スケール：アップ、イン、アウト
  - 料金体系：使った分だけ支払う
  - 開発者のアクセス方法：マネージドAPI

顧客の事例

Lyft： Key-value・データベースのAmazon DynamoDBを使用

ユーザー数が10人でも1000万人でも、スケールするパフォーマンスが必要
DynamoDBを使用して、道順を含めて個々のGPS位置情報を保存
Key-valueパターンによって、搭乗者のIDでデータを取得できる
DynamoDBは水平にスケールするので、制限がなく、ミリセカンドのパフォーマンスが維持できる

ZipRecruiter：リレーショナル・データベースのAmazon Aurora（RDS）を使用

100万のビシネスと1億の求職者をまたぐ豊富なクエリ機能が必要
誰が何を検索するのかは不明
ワークロードをサポートするためのリードレプリカ

Liberty Mutual：ドキュメントデータベースのAmazon DocumentDBを使用

顧客や施策、資産といった情報をJSONで保管するフレキシブルなデータモデルが必要
高速に開発フローを回し、スキーマやデータベースの変更なしに、新しい機能を届ける
アクセスパターンを知らないが、無限にスケールさせる必要がある場合、DynamoDBよりもDocumentDBの方が適切

UBISOFT：インメモリデータベースのAmazon ElastiCacheを使用

耐久性よりもレイテンシに最適化し、読み込みも書き込みもミリセカンドを実現
最小限のレイテンシは、オンラインゲームにとって必要不可欠
台帳の部分やリーダーボードを簡単に作成し、更新するための実践的なデータ構造

Nike：グラフデータベースのAmazon Neptuneを使用

名詞を持った円と、方向とコネクションを持った接線
コネクションに対してクエリできる
顧客とアスリートを繋げるソーシャルグラフを構築

Klarna：台帳型データベースのAmazon QLDBを使用

誰しもがレコードに入って突き回すことができなように確保
レコードを保護するトラディショナルな方法では、アクセス制限や人間による監査が必要だった
何にも改ざんできないことを証明するためのハッシュキー

Fender：適切なジョブのための、適切なツール

製品データや画像、購入履歴をマイグレーション
- SQL Servers　→　DynamoDB、S3、Lambda、ElastiCache
コストが20%低下
50%スピードが高速化
システム全体を、半年もかからずクラウドに移行した

[レポート]データベースもマイクロサービス化！Purpose-Built Databaseのススメ #reinvent [DAT209-L]