目的別データベースの事例

AWS シニアソリューションアーキテクト、Cullen Dejean および AWS スタートアップソリューションアーキテクト、Matthew de Anda による記事

初期段階のスタートアップ企業の皆さんは、製品市場への適合性を追求するにあたり、多くの技術的決定を下さなければなりません。こうした技術的決定には、やり直すことができるものもあれば、長期的な影響を伴う重要な分岐点となるものもあります。データベースを選ぶことは後者の例に入る傾向があり、リレーショナルデータベースを使った万能のアプローチはもはや通用しないのです。データベースの選択に取り掛かる前に、一歩下がって実際のユースケースを確認する必要があります。1 つのデータベースですべてを実行できるという期待を改め、目の前のご自身のタスクに最適なデータベースサービスを選択してください。AWS には、さまざまなデータモデルをサポートし、データ主導型でスケーラビリティの高い分散アプリケーションを構築できる、幅広く充実した目的別データベースのポートフォリオが用意されています。このブログ記事では、初期段階のスタートアップ企業が AWS のデータベースオプションを検討する際に考慮すべき要素について説明します。

データベースを選択する際に考慮すべき要素

使用経験

初期段階のスタートアップ企業は、実行可能な最低限の製品を構築し、牽引力と成長を示すことに集中する必要があります。そのため、どのような決定も、市場投入までのスピードと利用可能なスキルを念頭に置いて行う必要があります。チームにとって経験のないテクノロジーを選ぶと、多くの場合、タイムラインが長くなり、ユーザーからのフィードバックに応じて変更を加えるのが難しくなる MVP が生まれます。これが、最初からリレーショナルデータベースを使用することが正しいアプローチであり続ける主な理由です。チームが特定のデータサービス (リレーショナル、ドキュメントなど) を使った経験がある場合は、そこから始めるのが正しい選択です。

将来的な規模

初期段階のスタートアップ企業が留意すべきもう 1 つの要素は、将来的な規模です。使い慣れたテクノロジーを選んで迅速なデリバリーを実現するには、ユースケースを再分析して将来のスケーリングニーズを判断することでバランスを取る必要があります。期待どおりのパフォーマンスを維持しながら、ユーザーに合わせて自動的にスケールするソリューションを活用できると、力が倍増する可能性があります。後で別のテクノロジーに移行することは可能ですが、データが増えるにつれて移行はより複雑になるとに留意してください。Amazon Relational Database Service (Amazon RDS) と Amazon Aurora 間の移行など、一部の移行は元に戻すことができます。これを「双方向の意思決定」と呼んでいます。双方向の決定が可能なため、実験を迅速に行うことができ、「フェイルファスト」アプローチを採用できます。次のセクションでは、Amazon RDS や Aurora などのデータベースサービスについてさらに説明します。

目的別データベースとそのユースケース

これまでずっと、MySQL や Postgres などのリレーショナルデータベースがデータベース界を制していました。しかし現在では、選択できるデータベースタイプが増えています。十分な情報に基づいて決定を下すには、アクセス特性やデータの形状に基づいてデータベースを評価することが役立ちます。

リレーショナルデータベース

リレーショナルデータベースは自己記述型で、開発者がデータベースのスキーマだけでなく、データベース内の行とテーブル間の関係や制約を定義することができます。開発者は、アプリケーションコードではなくリレーショナルデータベースの機能に依存して、スキーマを適用し、データベース内のデータの参照整合性を保持します。リレーショナルデータベースの一般的な使用例には、ウェブアプリケーションやモバイルアプリケーションなどがあります。スタートアップ企業は、AWS 上の高性能でスケーラブルなアプリケーションとして Amazon RDS および Amazon Aurora を使用しています。RDS と Aurora はいずれもフルマネージド型でスケーラブルなデータベースです。

NoSQL: Key-value とドキュメントデータベース

システムの規模が大きくなると、多くの場合、大量のデータは Key-value データの形式になり、1 つの行がプライマリキーにマップされます。Key-value データベースは高度なパーテーション化に対応しており、他のタイプのデータベースでは実現できないレベルでの水平スケーリングが可能です。ゲーム、広告技術、IoT などのユースケースは、アクセスパターンが既知の Key-value に対して低レイテンシーの Get/Put を必要とする Key value データモデルに特に適しています。

Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現する、フルマネージド型のサーバーレスの Key-value NoSQL データベースです。パフォーマンスの高い Key-value ユースケース向けには、スケーラブルで可用性が高く、マネージド型の Apache Cassandra 互換データベースサービスである Amazon Keyspaces も提供しています。

関連性のあるもうひとつのデータベースタイプは、ドキュメントデータベースです。アプリケーション層のデータは通常 JSON ドキュメントとして表示されるため、ドキュメントデータベースは開発者に直感的な使用を提供します。ドキュメントデータベースは、コンテンツ管理システムデータの保存やクエリのほか、ユーザープロファイル、設定、リクエストを管理してレコメンデーションを生成してトランザクションを有効にするなどの用途によく使用されます。

ドキュメントデータについては、開発者はアプリケーションコードで使用しているのと同じドキュメントモデル形式を使用し、フルマネージド型の耐久性の高いデータベースである Amazon DocumentDB (MongoDB 互換) の柔軟なスキーマモデルを使用してデータを永続化できます。これにより、開発者の効率性が向上し、コンピューティングとストレージを個別にスケーリングしながら、1 秒あたり数百万件のドキュメント読み取りをサポートできます。

データウェアハウス

データウェアハウスの必要性を判断する際には、トランザクション (OLTP) データベースと分析 (OLAP) データベースを区別することが重要です。OLAP データベースは、ウェアハウスやデータアーカイブ用の大規模なデータベースです。初期段階のスタートアップ企業の多くにとって、OLAP のユースケースを処理するために Amazon Athena を検討するのが正しい選択です。Amazon Athena は、Amazon Simple Storage Service (Amazon S3) に保存されているデータを標準 SQL で分析できるサーバーレス SQL クエリインターフェイスです。

アプリケーションがより複雑なクエリや、より厳密な SLA を必要とするようになった場合、データウェアハウスの威力がデータ戦略と要件をスケールするのに役立ちます。Amazon Redshift は、クラウドにおけるフルマネージド型のペタバイト規模のデータウェアハウスサービスです。

インメモリデータベース

インメモリデータベースは、マイクロ秒のレイテンシーで配信されるデータへのリアルタイムアクセスを必要とするアプリケーションに使用されます。金融サービス、e コマース、ウェブ、モバイル、ゲームの各アプリケーションでは、インメモリデータベースを使用してリーダーボード、セッションストア、キャッシュ、リアルタイム分析を構築してきました。インメモリデータベースは、リレーショナルデータベースの負荷を軽減し、低レイテンシーを実現し、リレーショナルデータベースに代わってメモリ内の Key-value データストアとなることが可能です。

Amazon ElastiCache を使用すると、インメモリデータストアまたはキャッシュ環境を簡単にセットアップ、管理、およびスケールできます。Amazon ElastiCache は Redis エンジンと Memcached エンジンの両方で動作します。Amazon MemoryDB for Redis は、Redis と互換性のある耐久性に優れたインメモリデータベースサービスで、超高速のパフォーマンスを実現し、マイクロサービスアーキテクチャを備えた最新アプリケーション専用に構築されています。どちらのサービスを選ぶかは、使用するユースケースが一時的なものか、より耐久性が求められるものかによって異なります。Amazon ElastiCache はスタンドアロンデータベースとして使用されることが多いですが、耐久性を必要としないアプリケーションにのみ使用されます。これとは対照的に、MemoryDB はプライマリデータベースとして設計されています。もうひとつの要素は、チームが Redis または Memcached エンジンに精通しているかという点です。

検索

検索データベースは、ほぼリアルタイムの分析と検索を行います。検索データベースの一般的な使用例には、ログ分析、リアルタイムのアプリケーションモニタリング、クリックストリーム分析などがあります。

Amazon OpenSearch Service を使用すると、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できます。Amazon OpenSearch Service は OpenSearch とレガシー Elasticsearch OSS をサポートしています。

グラフデータベース

グラフデータベースの目的は、高度に接続されたデータセットを扱うアプリケーションを簡単に構築して実行できるようにすることです。グラフデータベースの一般的な使用例には、ソーシャルネットワーキング、レコメンデーションエンジン、不正検出、ナレッジグラフなどがあります。グラフデータベースが適切かどうかを判断するには、データをグラフ構造として最も適切に表現できるかどうかを判断することから始まります。関係の幅と深さは増えていくのでしょうか? 関係が複雑になるにつれて、リレーショナルデータベースへのクエリは遅くなります。モデル自体が変化しすぎて、スキーマの変更がチームの負担になっていませんか? 最後に、データ内の関係についての質問に対応する必要がありますか? グラフデータベースは、このような柔軟性を提供すると同時に、これらの関係について複雑なクエリを実行できるようにします。Amazon Neptune は高速で信頼性が高く、完全マネージド型のグラフデータベースサービスです。

台帳データベース

台帳データベースは、データの全体系統を追跡するのに役立ちます。Amazon Quantum Ledger Database (QLDB) はフルマネージド型の台帳データベースで、信頼された中央機関が所有する、透過的でイミュータブルであり、暗号的に検証可能なトランザクションログを備えています。

時系列データベース

時系列データベースは、アプリケーションが時系列データを処理していて、組み込みの分析関数を使用してこのデータを迅速に分析する必要があるユースケースに対応します。Amazon Timestream は、IoT および運用アプリケーション向けの高速でスケーラブルなサーバーレスの時系列データベースサービスです。

まとめ

初期段階のスタートアップ企業にとって、あなたが下す最も重要な決定のひとつは、どのタイプのデータベーステクノロジーを使用するかということです。AWS が提供する目的別データベースを検討するときは、まずユースケースから始め、どのデータベースサービスが適しているかを絞り込むために必要な要件を定義してください。次に、市場投入までのスピードとチームが利用できるスキルを重ね、それらの要素と将来のニーズとのバランスを取るようにしてください。ここで時間をかけてこれらの要素を検討し、業務に最適なデータベースサービスを選択することが重要です。