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

こんにちは。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が提案するアーキテクチャの戦略です。このセッションでは、それぞれのサービスがどうカテゴリ化されており、どう使っていけば良いのかを、最新のアップデートを含めて、事例と一緒に解説しています。データベースエンジニア必見です!

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

  • 開発者たちの最近の傾向は……
    • モノリシックなアプリを構築したくない
    • 用途に沿ったシステムを目指している
    • 大きなアプリケーションを小さなパーツに分解
    • 適切なジョブのために、適切なツールを選択したい
  1. 60年代: メインフレーム
  2. 80年代: クライアント・サーバー
    1. アプリケーションのロジックをデータベースから分離
  3. 90年代: 3層構造
    1. インターネットが登場
    2. クライアント層、アプリケーション層、単一のデータベース層
  4. マイクロサービス
    1. クラウド時代に突入し、システムはより特化型に
    2. データベースがより特化し始めている

共通のデータベース戦略

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

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

顧客が求める最優先事項

  1. マネージドサービスへ移行
    1. サービス: RDS, Aurora, ElastiCache, DocDB
    2. ツール: SCT, DMS
    3. プログラム MAP, Pro Serve, Partner
  2. ライセンスからの開放
    1. サービス: Aurora, Amazon Redshift
    2. ツール: SCT, DMS
    3. プログラム: MAP, DM Freedom, Pro Serve, Partner
  3. モダンなアプリケーション
    • 新たな要件
      • ユーザー数: 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%スピードが高速化
  • システム全体を、半年もかからずクラウドに移行した

最新のアップデート

Amazon Managed Cassandra Service (Preview)

  • 課題: 巨大なCassandraクラスタがスケールできるように管理する
    • セットアップ、設定、インフラやソフトウェアの維持するために、それぞれ専門エンジニアとして特化させていた
    • クラスタのスケーリングには時間がかかり、手動で、エラーを起こしやすく、過剰投資だった
    • 統合性を維持するための、手動バックアップとエラーの起きやすい手順
    • 無骨なロールバックとデバッグ機能のため、アップグレードが信用できない

Federated Query for Amazon Athena (Preview)

  • 課題: 様々なデータベースからデータをクエリする
    • マイクロサービスで爆発半径を最小化できるが、それぞれを除きいいくことが難しい
    • 複数のシステムへアクセスすることが困難

Amazon Aurora integration with ML

  • 課題: データベースに機械学習の機能を統合する
    • モデルを選択してトレーニング
    • データベースからデータを読み込んでアプリケーションのコードを作成する
    • 機械学習のアルゴリズムにあったデータをクエリしてフォーマットする
    • アルゴリズムを実行するために機械学習のサービスを呼ぶ
    • 結果をフォーマットする

参照