Cloud Datastore を使用したスケーラブルなウェブ アプリケーションの構築

この記事では、スケーラブルで高可用性があり、高性能なフルマネージド NoSQL データベース システムである Datastore を使用し、大規模なウェブ アプリケーションを構築する方法の概要を説明します。また、Google Cloud(GCP)エコシステム内の他のプロダクトと連携して Datastore を使用する完全なウェブ アプリケーションのシナリオについても説明します。

大規模なウェブ アプリケーション用のデータベース システムを管理するインフラストラクチャ管理者は、重大な課題を抱えています。特に、そのようなデータベース システムがステートフルな特性を持ち、この特性に起因する予期しない状況が発生した場合に、構成の変更が複雑になり、リスクを伴う可能性があります。新しいアプリケーションをリリースする前に、管理者は、最大限のスループットを得て、レイテンシを最小限に抑えることができるように、仮想マシン(VM)の数、ディスク ストレージの量、ネットワーク構成など、容量に関する計画に多くの時間を費やさなければならないことがよくあります。こうした計画は、オープン データベース接続の量と頻度、時間の経過に伴う使用パターンの変化など、多数の不確定要素があるため困難な作業です。高まり続ける需要に対応できるように、データベース ソフトウェアをアップグレードし、リソースをスケールするための定期的なメンテナンスも必要です。

このようなあらゆる計画やメンテナンスにより、新しいアプリケーション機能を開発するための時間、お金、関心が奪われてしまうため、負荷の大きい作業を処理するために十分なリソースをプロビジョニングすることと、未使用のリソースにコストを掛けすぎないようにすることのバランスを取ることが重要です。Datastore は、このような問題を最小限に抑えるために役立ちます。これにより、インフラストラクチャ管理者はアプリケーションに集中できるようになります。

Datastore のユースケース

大まかに言うと、Datastore は柔軟で非リレーショナルなスキーマを持つ階層的なトランザクション データを格納するのに非常に適しています。特に、ウェブ アプリケーションで以下が必要な場合は、Datastore を使用することを検討してください。

  • 任意のストレージ容量: Datastore は、保存するデータの量に影響を及ぼしません。パフォーマンスに影響を及ぼすことなく、キロバイト単位からペタバイト単位のデータ量を同じ方法で処理します。
  • アトミック性、整合性、独立性、永続性(ACID)への準拠: Datastore は、マルチ ドキュメントで ACID 準拠のトランザクションをサポートしています。
  • バランスが取れた整合性: Datastore では、強整合性と結果整合性のバランスを適切に取ることができます。祖先クエリとキーによるエンティティ検索が常に強整合性を実現し、他のすべてのクエリは結果整合性を実現します。
  • インデックス作成: プライマリ インデックスに加え、Datastore ではセカンダリ インデックスと複合インデックスがサポートされています。
  • マルチテナンシー: Datastore では、複数のクライアント組織に対して名前空間と呼ばれる別個のデータ パーティションを提供することで、マルチテナント データベースがサポートされています。
  • 自動スケーリング: Datastore は、ダウンタイムなしで、数万台ものマシンにまで自動的にスケールします。10 年以上にわたり App Engine で実証されているこのスケーリング メカニズムによって、Datastore は 1 秒間に数百万ものリクエストを処理できます。お客様は、ストレージのサイズとオペレーション数に基づき、実際の使用量に対してのみお支払いいただきます。詳しくは、Datastore の料金をご覧ください。
  • セキュリティ: Datastore は、ディスクにデータを書き込む前に、自動的にすべてのデータを暗号化します。Datastore には Identity and Access Management(IAM)も備わっており、特定のリソースに対するアクセス権をきめ細かく設定して、他のリソースへの不要なアクセスを防止できます。
  • 冗長性: Datastore では、複数のロケーションでの 2 つの異なるレプリケーション タイプに基づく、2 つのレベルの冗長性が提供されています。

    • リージョナル レプリケーション: データは同じリージョン内の少なくとも 3 つの異なるゾーンで複製されるため、ゾーンで障害が発生してもデータベースの復元性が確保されます。このタイプのレプリケーションは、書き込みのレイテンシを低くすることが最優先事項である場合に最適です。そのような場合、アプリケーションのコンピューティング マシンを同じリージョンに配置することもできます。
    • マルチリージョン レプリケーション: データは少なくとも 2 つの異なるリージョンにわたって複数のゾーンで複製されるため、可用性と冗長性は高まりますが、書き込みレイテンシは高くなります。次の図に示されているように、監視ノードが 3 番目のリージョンに配置され、複製された 2 つのリージョン間のタイブレーカーとして機能します。

Datastore でのマルチリージョン データベースのレプリケーション スキーム

図 1. Datastore でのマルチリージョン データベースのレプリケーション スキーム

Datastore は前述のすべての要件を満たすことができるため、以下のようなさまざまなユースケースに適しています。

  • ユーザー プロフィール: ユーザーの過去のアクティビティや好みに基づいて、ユーザー エクスペリエンスをカスタマイズします。Datastore の柔軟なスキーマを使用して、ユーザー プロフィールの構造を経時的に発展させることができます。たとえば、新しいプロパティを追加して、アプリケーションで新機能をサポートできます。スキーマの変更はダウンタイムなしで行われます。ユーザー数が増えても、パフォーマンスは低下しません。
  • リアルタイム インベントリ: たとえば、小売業者の製品カタログなどを扱う場合、Datastore の豊富でネストされたエンティティを使用し、構造を過度に特殊化することなく、さまざまなプロダクトの多種多様で膨大な量の疎データを保存できます。
  • ユーザー セッション管理: たとえば、小売店のショッピング カートや、イベントを予約するためのマルチパート処理フォームなどを管理する場合、Datastore では ACID トランザクションがサポートされているため、ユーザーはトランザクションが完了するまでの特定の期間、特定のアイテムをロックダウンできます。
  • 状態のミューテーション: たとえば、すべてのプレーヤーに対して一貫した状態を維持するゲームなどの場合、Datastore の ACID トランザクションを使用して、膨大な数の同時ユーザー全体にわたり、変位を伝搬できます。具体的な例については、大規模なゲームサービスを対象とした Datastore での高速かつ信頼性の高いランキング処理をご覧ください。
  • 永続的なライトスルー キャッシュ: たとえば、簡単に使用できる Key-Value ストアを利用する場合、Cloud Datastore の高可用性と耐久性を利用して状態を持続させ、アプリケーションがクラッシュした場合のデータ損失を回避できます。

代替ストレージ オプション

データベース ソリューションの候補として Datastore を評価するときは、その本番環境での制限が構築するアプリケーションの要件を満たしていることを確認してください。Datastore は汎用性があり、多くの場合に適用可能ですが、状況によっては、他の GCP ストレージ オプションのほうが適している可能性があります。

極めて低いレイテンシ

Datastore では、レイテンシよりも耐久性と可用性が重視されており、クロスリージョンまたはクロスゾーンでの同期書き込みが行われます。アプリケーションでデータの読み取り時または書き込み時に一貫して 10 ミリ秒未満のレイテンシが求められる場合、MemcachedRedis などのインメモリ データベースの使用を検討してください。また、Datastore のキャッシュとしてインメモリ データベースを使用することもできます。これについては、後述の Platform as a Service(PaaS)シナリオで説明します。Memcached の詳細については、App Engine での使用方法Google Kubernetes Engine での使用方法に関するドキュメントをご覧ください。

過度な負荷

Datastore は大規模なオペレーションを処理できます。ただし、レプリケーションやトランザクションなどの複雑な機能をサポートするために、Datastore にはいくつかのトレードオフがあり、それらによって、特定の種類の非常に高い負荷を処理するシステムでパフォーマンスが下がる可能性があります。Internet of Things センサーからの継続的なデータ取り込みなど、アプリケーションで非常に大規模な書き込みが生じる場合は、Cloud Bigtable を使用し、トランザクションとセカンダリ インデックスを差し置いてデータ取り込み機能を高めることを検討してください。アプリケーションがユーザーに同じ情報を頻繁に表示する場合(ゲームでのプレーヤー リーダーボードなど)、クライアント側でキャッシュすることで、サーバーへの不要なリクエストを回避して負荷を減らすことを検討してください。

SQL スキーマとセマンティクス

複雑で効率的なクエリを作成するために、Datastore は GQL と呼ばれる、SQL のような構文を使用します。ただし、Datastore は非リレーショナル データベースであるため、SQL セマンティクスを使用するリレーショナル スキーマまたはクエリはサポートしていません。特に、Datastore では、結合オペレーション、複数のプロパティに対する不等式フィルタリング、サブクエリの結果に基づいたデータに対するフィルタリングはサポートされていません。アプリケーションで SQL のサポートが必要な場合、非水平スケーリングには Cloud SQL を使用し、より規模の大きい水平スケーリングやグローバル スケーリングには Cloud Spanner を使用します。

データ分析

Datastore は、オンライン トランザクション処理(OLTP)に最適化されています。アプリケーションで、テーブルの完全スキャン用のストレージ オプションや、オンライン分析処理(OLAP)システムでのインタラクティブなクエリが必要な場合は、BigQuery を使用してください。アプリケーションで OLTP と OLAP の両方のシステムが必要な場合、後述のデータ分析システムのシナリオで説明されているように、OLTP システムとして Datastore を使用し、Datastore のデータを BigQuery にエクスポートして分析してください。

リアルタイム モバイル アプリケーション

Datastore は、サーバー側でアクセス可能な膨大な量のデータを保存できるように設計されています。アプリケーションがモバイルベースであり、データ変更によってトリガーされる自動プッシュ更新などのリアルタイム機能が必要な場合は、Firebase の使用を検討してください。Firebase プラットフォームには、クラッシュ レポートユーザー管理と認証ユーザー イベント分析など、モバイルに焦点を当てた機能が多数備わっています。

他の GCP プロダクトと Datastore の統合

大規模なウェブ アプリケーションでは、単なるスケーラブルなデータベース システム以上のものが必要です。また、データ分析や機械学習(ML)ワークロードをサポートするための、スケーラブルなウェブサーバー、キャッシング システム、バックアップ用ストレージ ソリューションも必要になります。さらに、抽出、変換、読み込み(ETL)パイプラインを持つデータ ウェアハウスが必要になることもあります。Datastore はアプリケーションの中心となる信頼できる単一のソースを管理するのに適していますが、その他の複数の GCP プロダクトと統合して、さまざまなニーズに対処することもできます。次の図は、その柔軟性を示しています。

他の GCP プロダクトと Datastore の統合の概要

図 2. 他の GCP プロダクトと Datastore の統合の概要

Compute EngineGoogle Kubernetes Engine、App Engine、Cloud Functions で実行されているプログラムは、Datastore を使用して大量のトランザクション データを読み取り / 書き込みできます。どのようなランタイム環境を選択するかについては、開発チームやインフラストラクチャ チームで必要な管理とカスタマイズのレベルによって異なります。次に例を示します。

  • Compute Engine は、仮想マシン(VM)全体を完全に制御できます。
  • GKE は、コンテナのデプロイとオーケストレーションを促進します。
  • App Engine は、インフラストラクチャ全体を管理するため、ユーザーはコードに集中できます。
  • Cloud Functions は、イベント ドリブン マイクロサービスをデプロイできます。

プログラムは、低レベルの REST または RPC API、あるいは C#、Go、Java、Node.js、PHP、Python、Ruby の各言語を使用できるクロス プラットフォーム クライアント ライブラリのうちの 1 つを使用して、Cloud Datastore と相互作用します。

Datastore では、アーカイブまたは障害復旧を目的とした Cloud Storage へのデータ エクスポートや、データ分析を目的とした BigQuery へのデータ エクスポートがサポートされています。これらの操作は直接行うことも、Cloud Storage を介して行うこともできます。また、カスタムの Dataflow パイプラインを作成し、true に設定されているプロパティを使用してエンティティにフィルタを設定できます。また、BigQuery にデータを読み込んで分析する前にデータを前処理できます。定期的なバックアップについては、App Engine(フレキシブル環境のみ)または Cloud Functions を使用して、Dataflow パイプラインの実行をスケジューリングできます。また、Compute Engine で cron ジョブを使用することもできます。

最後に、Datastore は機械学習パイプラインの一部として使用できます。たとえば、パイプラインでは AI Platform 内のデータを、Datastore の Python ライブラリを使用して直接的に処理することも、Cloud Storage や BigQuery にデータをエクスポートして間接的に処理することもできます。

リファレンス アーキテクチャ

このセクションでは、Datastore を他の GCP プロダクトと組み合わせる大規模なウェブ アプリケーションの構築に関するシナリオについて説明します。毎日のエクスポート、キャッシュ保存、データ処理、機械学習用モデルのトレーニングなど、さまざまな種類の機能について説明し、各シナリオの基準アーキテクチャを提供します。

シナリオやアーキテクチャは規範的なものではありません。それよりも、スケーラブルなウェブ アプリケーションを構築する際に、Datastore を幅広く使用できることをわかりやすく示すことを目的としています。また、特定の要件を満たすよう独自のウェブ アプリケーションのコンポーネントを再編成して適応させることができるため、ご使用のアプリケーションを変更したくなるかもしれません。

シナリオ 1: 毎日のデータベース スナップショットを使用した簡単な自動スケーリング インフラストラクチャ

このシナリオでは、Compute Engine VM のマネージド インスタンス グループが大規模なウェブ アプリケーションを処理します。インスタンス グループは負荷の増減に基づいて自動的にスケーリングされ、Cloud HTTP(S) ロードバランサによって使用可能なインスタンス間で着信トラフィックがルーティングされます。VM は Datastore と直接相互作用し、トランザクション データの読み取りと書き込みを行います。データベースの毎日のスナップショットは Cloud Storage に保存されます。古いスナップショットはオブジェクトのライフサイクル管理ルールによって定期的に Cloud Storage Coldline に移動されるため、アーカイブしたデータの保存に要するコストが削減されます。

毎日のデータベース スナップショットを使用した簡単な自動スケーリング インフラストラクチャ

図 3. 毎日のデータベース スナップショットを使用した簡単な自動スケーリング インフラストラクチャ

シナリオ 2: コンテナベースのインフラストラクチャ

このシナリオでは、ゲーム用プラットフォームで数万人のプレーヤーによる同時アクセスがサポートされています。このプラットフォームは、GKE にホストされている何百ものコンテナ化されたマイクロサービスで構成されています。プラットフォームにはマイクロサービスの 3 つのレイヤがあり、それらはすべて自動スケーリング Kubernetes PodNGINX Controller Pod、フロントエンド Pod、バックエンド Pod)としてデプロイされています。

Cloud SSL プロキシは、NGINX Controller Pod 間の着信 TCP トラフィックと SSL トラフィックを負荷分散します。この Pod は、セッション固定を使用してフロントエンド Pod 間の HTTP 負荷分散を処理します。この手法では、同じクライアントからのリクエストは、常に同じフロントエンド Pod に転送されます。レイテンシを削減するために、フロントエンド Pod はクライアント固有の情報とプレーヤー構成をローカル側でキャッシュに保存できます。バックエンド Pod はゲームの世界の特定の領域を管理することでレイテンシを削減し、領域固有の情報をローカル側でキャッシュに保存できます。フロントエンドとバックエンドの Pod は、キャッシュされた情報を同時に Datastore に書き込み、長期保存できます。この方法により、フロントエンドとバックエンドの Pod が終了しても、状態は失われません。

Kubernetes Engine と Datastore が搭載されたコンテナベースのゲーム用プラットフォーム

図 4. Kubernetes Engine と Datastore が搭載されたコンテナベースのゲーム用プラットフォーム

NGINX Controller を GCP にデプロイする方法の詳細については、ハンズオン ガイドをご覧ください。複雑なゲーム用プラットフォームの代替基準アーキテクチャについて詳しくは、詳細なソリューションをご覧ください。

シナリオ 3: 機能ベースのインフラストラクチャ

このシナリオでは、イベント管理プラットフォームによって、API がモバイルおよびデスクトップのユーザー アプリケーションに公開されます。各 API エンドポイントは、Cloud Functions にデプロイされるマイクロサービスとして実装されます。各 API エンドポイントは、イベントの一覧表示、会場情報の返信、チケットの予約など、特定のサービスを提供します。マイクロサービスは JavaScript で実装され、Datastore 用の Node.js クライアント ライブラリを使用して永続データの読み取りと書き込みを行います。この完全に分離されたサーバーレス アーキテクチャを使用して、各サービスを個別にスケーリングできます。

Datastore に永続データを書き込むサーバーレスで機能ベースのインフラストラクチャ

図 5. Datastore に永続データを書き込んでいるサーバーレスで機能ベースのインフラストラクチャ

シナリオ 4: サービスとしてのプラットフォーム

このシナリオでは、Google の PaaS ソリューションである App Engine スタンダード環境を使用して、小売アプリケーションをビルドします。アプリケーションは独立した App Engine マイクロサービスに分解され、それぞれが担当する領域(ユーザー プロフィール、購入記録、製品情報、顧客サービス)を管理します。

App Engine は各マイクロサービスの自動スケーリングと、インスタンス間の自動負荷分散を処理します。各マイクロサービスは、その目的に最も適したサポート対象のプログラミング言語(Java、Python、PHP、Go)を使用して実装されます。また、各マイクロサービスは App Engine 標準クライアント ライブラリを使用して Datastore にアクセスします。ユーザーによる相互作用を高速化し、データベースの負荷を軽くするために、App Engine は頻繁なデータベース クエリの結果をその内蔵 Memcached コンポーネントにキャッシュします。

App Engine スタンダード環境、Datastore、Memcached によって管理されるウェブ アプリケーションの自動スケーリング

図 6. App Engine スタンダード環境、Datastore、Memcached によって管理されるウェブ アプリケーションの自動スケーリング

シナリオ 5: データ分析プラットフォーム

このシナリオでは、ウェブ プラットフォームをビジネス オペレーションとビジネス分析という 2 つの主要なコンパートメントに分けています。ビジネス オペレーションは、クライアント要求に応答するウェブ アプリケーションで構成されています。このアプリケーションは、Cloud HTTP(S) ロードバランサによって負荷分散される Compute Engine インスタンスの自動スケーリング グループを使用して構築されます。アプリケーションは、Datastore でデータベースに対して直接データの読み取りと書き込みを行います。データベースのスナップショットが毎日作成され、Cloud Storage に保存されます。

ビジネス分析コンパートメントは、ビジネス オペレーションのパフォーマンスに対する分析情報をモニタリングして取得し、今後の改善を計画して実施します。システムは、Cloud Storage に保存されているデータベースのスナップショットから BigQuery に履歴データを毎日読み込みます。また、システムは Pub/Sub を介してリアルタイムに、Compute Engine インスタンスから BigQuery にライブ アプリケーション ログを読み込みます。この設計により、データ アナリストは履歴データとライブデータの両方を探索し、ビジネス アナリストや他の意思決定者が使用できるように、Google データポータルにインタラクティブなビジュアル ダッシュボードを生成できます。

Datastore からの履歴データと Pub/Sub を介したリアルタイム データの両方を管理するデータ分析プラットフォーム

図 7. Datastore からの履歴データと Pub/Sub を介したリアルタイム データの両方を管理するデータ分析プラットフォーム

シナリオ 6: 機械学習プラットフォーム

このシナリオでは、オンライン ストア アプリケーションによってさまざまな商品を提供して販売します。このアプリケーションは、Cloud HTTP(S) ロードバランサによって負荷分散される Compute Engine インスタンスの自動スケーリング グループを使用して構築されます。ユーザーと商品に関するすべてのデータは Datastore に保存されます。

機械学習パイプラインは、ユーザー用にカスタマイズされたプロモーションを提供するレコメンデーション エンジンを管理します。履歴データは Datastore から定期的に抽出され、バッチモードで Dataflow によって変換されます。変換されたデータは Cloud Storage に保存され、レコメンデーション エンジンのモデルをトレーニングするために AI Platform によって特徴として使用されます。トレーニングされたモデルの各バージョンが Cloud Storage に保存され、AI Platform に読み込まれ、アプリケーションのユーザー インターフェースに表示されるライブ プロモーションの特典が生成されます。全体的なプロセスは、Compute Engine で実行されている Apache Airflow を介してオーケストレーションされます。データ サイエンティストは、Datalab を介して新しい機械学習モデルをテストします。

ユーザー用のライブ プロモーションの特典を生成するために Datastore から履歴データを処理する機械学習プラットフォーム

図 8. ユーザー用のライブ プロモーションの特典を生成するために Datastore から履歴データを処理する機械学習プラットフォーム

次のステップ