クラウドネイティブ アプリケーション
Embedded Files
多くの企業は、オンプレミス環境においてモノリシック アーキテクチャを使用してカスタム ソフトウェア サービスを構築しています。新しい変化に適用するために、機能追加や変更を加えていくと、アプリケーションがより複雑になってしまい、費用と時間がかかる上に、展開にはリスクも伴ってきます。
こうした課題を解決するには、コンテナベースのアプリケーション サービスとクラウド ネイティブのデータベースを合わせて利用することが有効です。アプリケーションに高い俊敏性、スケーラビリティ及び可用性など様々なメリットがあり、次の環境変化への適応性を高めることができます。
Google Cloud が提供するいくつかのマネージド サービスは、コンテナベース アプリケーションとスケール可能なデータベースの両方が含まれています。ここでは、クラウド ネイティブの組み合わせと全体構成についての詳細とユースケース、システム要件に合わせた最適なデザイン パターンと、本番におけるベスト プラクティスを紹介します。
デザイン パターン詳細
Cloud Run + Cloud Firestore
Cloud Run + Cloud Firestore
解決する課題・使い所
クラウドネイティブ アプリケーションの開発と運用に求められる要因にはアジリティと運用効率性があります。変化が早い市場に対してより早くアプリケーションを開発し稼働させること、また継続的にアプリケーションの改善に注力できるように運用効率を上げていくことが重要視されています。
使い所
単一機能にフォーカスしているアプリケーション
複数の業務ドメインに跨ってデータを結合して評価を行うような業務アプリケーションには向いていません。データ設計よりも業務ロジック中心的な開発を行うアプリケーション
アジャイル開発のように作りながら動かし、アウトプットとなるデータを永続化するという開発に向いています。スモールスタートしビジネスの成長に伴い徐々にスケールしていくアプリケーション
Google Cloud の無料枠利用でサーバレスの構成でアプリケーションをスタートしたらインフラの運用管理とランニングコストを両方ゼロに近く抑えることが可能です。そしてビジネスの拡大に伴い、 Cloud Run と Cloud Firestore はそれぞれ自動スケールしてくれるので、中小企業や新事業の立ち上げのためのアプリケーションに非常に向いています。適用例
EC サイトの中のカタログ機能や購入履歴管理のように特定の単一機能
ユーザーアカウント管理やユーザーアカウントに紐づくインベントリや設定情報管理のような大量データを扱う機能
ソーシャルサイトの行動履歴ログのようなリアルタイム処理を行う機能
IoT のようにトランザクションが予期できず膨大なリクエストが発生しうる機能
新規事業のインキュベーションようのアプリケーション開発
小売店向けにリアルタイムな在庫と商品の詳細を提供する商品カタログ
ユーザーの過去の行動と好みに応じてカスタマイズされたエクスペリエンスを提供するユーザー プロフィール
ある銀行口座から別の口座への送金など、ACID プロパティに基づくトランザクション
アーキテクチャ
基本的な構成は、インターネット上に公開されている Cloud Run の Service から Cloud Firestore へ接続する形式になります。接続にはクライアント ライブラリや Firebase Admin SDKs を用いて接続する方法と、HTTP (REST) または gRPC により直接 Cloud Firestore API を呼び出す方法があります。提供しているクライアント ライブラリは、C#、Go、Java、Node.js、PHP、Python、Ruby の各種言語に対応しています。クライアント ライブラリや SDKs を利用する場合は、トランザクションが失敗する場合のリトライやオフラインの対応などを自動的に実施してくれます。
適用例
Eモバイルもしくは Web アプリを開発する場合のクライアントからのアクセス、セキュリティルール経由で権限コントロールすることが可能です。
スキーマ情報の確認やバッチを実行する場合には、特権ユーザが必要で、Firebase Admin SDKs を利用します。その場合は IAM 経由で権限コントロールされます。
適用例
完全なクライアント ライブラリを実行できない環境(例えば IoT デバイス)や他のサービスと簡単に連携したい場合は Cloud Firestore API を呼び出すことが便利です。
不特定多数からのアクセスを抑止し限定的に公開する場合は、サービスを作成する際に「認証を必要とする」を選択します。これによりサービスが非公開となります。アクセスを許可するユーザーを追加し、Cloud Run Invoker (roles/run.invoker) ロールを付与します。また Google Cloud 外部から呼び出す際に Authorization Bearer ヘッダに有効な ID トークンを付与してアクセスを行います。
同様にして Cloud Pub/Sub などの Google Cloud 上のサービスから Cloud Run を呼び出す構成を行う事ができます。
リージョナル サービスで提供されている Cloud Run と Cloud Firestore をマルチリージョンで構成し可用性を向上させる場合には Serverless NEG と HTTP(S) ロードバランサを組み合わせて使用します。また、Serverless NEG を組み合わせた構成では、Cloud Armor を利用してウェブアプリケーションの保護をする事が可能になります。
Cloud Run のフロントエンドに構成する HTTP(S) Load Balancing は、Serverless NEG の構成後に バックエンドサービス、URL マップ、HTTP プロキシ、フォワーディング ルールを作成して構成を行います。
利点
フロントエンドのアプリケーションプラットフォームに Cloud Run を用い、バックエンドのデータストアに Cloud Firestore を用いる構成をとる事でアプリケーション開発および運用の観点に容易にアジリティや効率性を享受することが可能となります。
Cloud Run 利点
アジリティ
Cloud Run は作成したコンテナ アプリケーションを秒単位でデプロイしサービス公開する事が可能です。また、CI/CD パイプラインをサポートする Cloud Build と統合され自動化されたビルド・デプロイが可能になります。コンテナの作成も Google Cloud Buildpacks を使用することにより Dockerfile の定義を必要なくコンテナイメージを内部で作成して Cloud Run に公開する事が可能です。ビルド・デプロイの自動化
コンテナイメージ作成の省力化
効率性
Cloud Run にデプロイしたアプリケーションは自動的に Cloud Logging および Cloud Monitoring と統合され、設定や構成の必要なくログ監視やパフォーマンスモニタリングが可能になります。また、デプロイ対象のアプリケーションの特性に応じたリクエストタイムアウトの設定が可能で最小 1 秒から最大 60 分までの範囲で設定する事が可能になります。これにより IoT に窓口アプリケーションから バッチジョブのような様々なアプリケーションに合わせた設定が行えます。組み込みのオブザーバビリティ
Cloud Logging および Cloud Monitoring との統合
リクエスト タイムアウト設定
デフォルト タイムアウト 5 分
スケーラビリティ
Cloud Run では受信したリクエストをすべて処理するために自動的にスケーリングが行われます。リクエストを受け付けていない時にはインスタンス数を 0 までスケールダウンし、リクエストが増加してきた場合には 設定した最大数 (デフォルト 最大数 1000) までスケールアウトします。また、各インスタンスが同時に処理するリクエスト数の設定が可能 (最大同時実行数 80) でリソースを効率的に利用したリクエスト処理が可能です。オートスケーリング
コンカレンシー
Cloud Firestore 利点
アプリケーション向けのスケーラビリティが高い NoSQL データベースです。シャーディングとレプリケーションを自動的に処理し、アプリケーションの負荷に合わせて自動的にスケールする、可用性と耐久性を兼ね備えたデータベースを提供します。 Cloud Firestore は Native モードと Datastore モードの 2 つのモードを提供します。両方とも同じ基盤となるルーティング インフラストラクチャを使用します。ゆえに、プロジェクトごとにどちらか一方しか利用することができません。 新しいモバイルアプリに Cloud Firestore のリアルタイム機能を利用したい場合、もしくは Firebase 側の機能も一緒に利用したい場合は Native モードが最適なオプションです。すでに Datastore SDK を使い慣れている場合、Datastore モードを検討します。Cloud Firestore の主な利点は下記になります。
ACID トランザクション
ACID トランザクション、SQL ライクなクエリ、インデックスなどの多くの機能を備えています。簡単にスケーリング
Cloud Firestore は、Google Cloud の強力なインフラストラクチャを活用するためにゼロから構築された自動スケーリングソリューションであり、アプリの成長に合わせて簡単にスケーリングできます。スキーマレスによるデータ構造の柔軟性
Cloud Firestore は効率的なクエリ機能を備えた NoSQLドキュメントデータベースであるため、論理的に意味のある方法でデータを階層構造に保つことができます。真のサーバーレスソリューション
Native モードを利用する場合は、モバイルまたはウェブクライアントから直接 Cloud Firestore と通信して、中間となるアプリサーバーを設定する必要はありません。包括的なクライアントライブラリ
Cloud Firestore は、ネイティブモバイルアプリ用とWeb 用の両方のリッチで包括的なクライアントライブラリによってサポートされており、Cloud Firestore での作業をシンプルで楽しいものにします。特に Native モードのクライアントライブラリには、次のような特徴があります。オフラインサポート
Cloud Firestore は、ウェブを含む完全なオフラインサポートを備えているため、ユーザーはネットワークに接続していない場合でもデータにアクセスして変更を加えることができます。クライアントライブラリを使用すると、アプリの意味に応じて、データへの変更を自動的に受信したり、必要に応じてデータをプッシュしてリクエストしたりできます。自動同期
Cloud Firestore を使用すると、データが変更されたときにアプリケーションをほぼリアルタイムで更新できます。これは、共同のマルチユーザーアプリケーションを構築するのに最適なだけでなく、複数のデバイスからアプリを使用する可能性のある個々のユーザーとデータを同期させることができることも意味します。使いやすさ
Cloud Firestore を使用すると、データが変更されたときにアプリケーションをほぼリアルタイムで更新できます。これは、共同のマルチユーザーアプリケーションを構築するのに最適なだけでなく、複数のデバイスからアプリを使用する可能性のある個々のユーザーとデータを同期させることができることも意味します。
Cloud Run についての注意事項
向かないアプリケーションのパターン
長時間のトランザクション時間を要するアプリケーション
バッチプログラムなど
ただし、タイムアウト時間を最大 60 分に設定するベータ機能を提供しているため、今後バッチ等のアプリケーションも利用可能
CPU リソースを多く要する演算が中心のアプリケーション
最大 4 vCPU までの割当て可能ですがそれ以上のリソースが必要な演算処理がある場合は GKE の利用を検討してください
コンテナ インスタンスが起動するときにレイテンシが発生します。この時間を最小化した設計を考慮することを推奨します。
コンテナインスタンスの終了時処理の検討
Cloud Run では自動でコンテナ数がスケールします。そのためコンテナが終了する時に送信される SIGTERM を利用したアプリケーションによるグレースフルシャットダウンの検討を推奨します
Cloud Firestore についての注意事項
トラフィックを徐々に増やす
Cloud Firestore では新しい種類 (Datastore モード) もしくはコレクション(Native モード) の操作には毎秒 500 回を上限としています。その後、5 分ごとにトラフィックを 50% 増やしていくことをおすすめします。この方法で読み取りトラフィックを増やした場合、90 分後には毎秒 740,000 回のオペレーションに増やすことができます。
狭いキー範囲に対する高頻度の読み取り、書き込み、削除を行わないでください。
Cloud Firestore に向いていないユースケース
複雑な SQL で OLTP 系のワークロードを取り扱うシステムでは、Cloud SQL や Cloud Spanner を検討してください。
オンライン分析処理 (OLAP) システムでのインタラクティブなクエリが必要な場合は、BigQuery を検討してください。
大容量の画像やムービーなど、大規模な不変 blob を格納する必要がある場合は、Cloud Storage を検討してください。
Native モードの注意事項
1 秒あたり 1 のドキュメント書き込み頻度制限
典型的なケースとして、あるドキュメントに頻繁に発生するイベントのカウンタが保存されるような設計になったら問題になり易いです。この問題に対応するには、複数のドキュメント間でカウンターを分割する「分散カウンタ」と呼ばれる代替ソリューションの利用を検討してください。
1 MB のドキュメントサイズ制限時間と共に、無制限に大きくなる可能性のあるマップおよび配列タイプのフィールドの使用をなるべく避けてください。
トランザクションごとに最大 500 のドキュメント処理可能
サンプル コンフィグ
[Qwiklabs] Google Cloud Run Serverless Workshop
Cloud Firestore データベースへデータを読み込む
Cloud Firebase を使用してサーバーレス ウェブアプリをビルドする
Cloud Run を使用して PDF ファイルを作成するサーバーレス アプリをビルドする
Cloud Run と Pub/Sub を使用して復元性に優れた非同期システムをビルドする
参照ドキュメント
Cloud Run + Cloud Spanner
Cloud Run + Cloud Spanner
解決する課題・使い所
あらかじめ予測を立てたトラフィック設計をすることが困難な非機能要件を持ち、高速なスケーラビリティが求められるアプリケーション課題に対するアプローチです。このようなアプリケーションには、次のような課題が考えられます。
予期していない急激なトラフィックの増加
トラフィックの増加に伴う ウェブレイヤの処理速度の低下
永続化レイヤでの処理能力の低下 ウェブと永続化レイヤを結ぶコネクション数の不足
スケール操作に伴うシステム全体の処理能力の低下
アプリケーション リリース時の割り振り停止などの運用操作の発生
アプリケーションを動作させる際の Google Cloud 製品の主な選択肢としては、Google App Engine、Cloud Run、Compute Engine、および Google Kubernetes Engine（GKE）が考えられます。それらの選択肢の中でも、環境の構築や運用の複雑さを意識する必要がないフルマネージドのサーバーレス プラットフォームで、スケーラブルにコンテナ アプリケーションをデプロイし、稼働させるのが Cloud Run です。
データベースは、ほとんどすべてのアプリケーションの主要なアーキテクチャ コンポーネントです。信頼性の高いデータベースを使用することで、アプリケーションのスケーラビリティを向上させ、データの耐久性と一貫性、サービスの可用性、およびシステムのサポートがより負荷なく行えます。Cloud Spanner は、複雑かつ変化し続けるスキーマを持つアプリケーション、高い整合性が求められるアプリケーションに適したデータ ストレージ サービスです。きわめて大容量のデータを処理できるため、大規模なアプリケーションに最適ですが、中小さまざまな規模のアプリケーションでもその威力を発揮します。
アーキテクチャ
Cloud Run と Cloud Spanner のソリューション デザイン パターンの詳細については、以下の図をご参照ください。
Cloud Run 利点
スケーラビリティ
Cloud Run では、受信したリクエストをすべて処理するために、自動的にスケーリングが行われます。リクエストを受け付けていないときには、インスタンス数をゼロまでスケールダウンし、リクエストが増加してきた場合には、設定した最大数（デフォルトでは最大数 1,000）までスケールアウトします。また、各インスタンスが同時に処理するリクエスト数が設定できる（最大同時実行数 1,000）ので、リソースを効率的に利用したリクエスト処理が可能です。1,000 インスタンスと 1,000 同時実行により、最大 100 万同時リクエストを処理することができます。オートスケーリング
コンカレンシー
アジリティ
Cloud Run は、作成したコンテナ アプリケーションを秒単位でデプロイし、サービスを公開することができます。また、CI / CD パイプラインをサポートする Cloud Build と統合され、自動化されたビルドとデプロイが可能です。コンテナの作成も Google Cloud Buildpacks を使用することにより、Dockerfile の定義なしに、コンテナ イメージを内部で作成して Cloud Run に公開することができます。ビルドとデプロイの自動化
コンテナ イメージの作成の省力化
運用効率性
Cloud Run にデプロイしたアプリケーションは、自動的に Cloud Logging および Cloud Monitoring と統合され、設定や構成の必要なく、ログ監視やパフォーマンス モニタリングが可能になります。また、デプロイ対象のアプリケーションの特性に応じたリクエスト タイムアウトの設定ができるので、最小 1 秒から最大 60 分までの範囲で設定できます。組み込みのオブザーバビリティ
Cloud Logging および Cloud Monitoring との統合
リクエスト タイムアウト設定
デフォルト タイムアウト 5 分
Cloud Spanner の利点
構築は簡単
インスタンスの名前、リージョン、ノード数を指定するだけで、インスタンスを作成して立ち上げられます。一般的な RDBMS のように、インストールや高可用性を実現するために、アーキテクチャを設計して構成する必要がありません。高可用性
Cloud Spanner は、1 ノードから SLA を提供します。月間稼働率では、リージョン インスタンス 99.99%、マルチリージョン インスタンス 99.999% の SLA を提供します。メンテナンスはオンラインにより無停止で行われるので、メンテナンスによるダウンタイムが発生しません。また、アプリの変更による DDL の発行でテーブルロックも発生しないため、計画ダウンタイムも大幅に削減できます。災害対応
Cloud Spanner のマルチリージョン アーキテクチャは、高いビジネス継続性をサポートし、リージョン障害に対する保護を提供します。Cloud Spanner のスケーラビリティや強整合性を犠牲にせずに、99.999% の高可用性を実現します。スケラービリティ
各ノードでは、最大 10,000 QPS の読み取り、または最大 2,000 QPS の書き込みが可能で、保存容量は 2 TB です。ワークロードに合わせ、アプリの修正なしにノードの増減で簡単に伸縮可能で、ランニングコストを最小限に抑えられます。処理ユニット（PU）を指定して Cloud Spanner を構成することで初期費用を最大 90% 削減
これまで Cloud Spanner では、リソースをプロビジョニングするための最小単位は 1 ノードでしたが、より一層きめ細かな制御を可能にするために、 PU と呼ばれる新しい単位を導入しました。Cloud Spanner の 1 ノードは、1,000 PU に相当します。お客様は、100 PU 単位でプロビジョニングを行い、それに比例した量のコンピューティング リソースとストレージ リソースを取得できるようになりました。これにより、Cloud Spanner 上でこれまでより小さなワークロードを、はるかに低コストで実行できます。この機能では、100 PU から開始し、必要に応じてダウンタイムなしで（100 PU 単位で）最大 1,000 PU（1 ノード）までスケールアップできます。その後も、現在と同じようにノードを追加することで、スケールアウトを継続できます。お客様が複数のノードの容量を必要とする場合でも、リソースのプロビジョニングに PU とノードのどちらを使用するかを選択できます。運用コストほぼゼロ
Cloud Spanner では、オンライン バックアップが提供されています。またこのツールを利用して設定することで、スケジュール指定を自動化できます。複数のレプリカで構成されているので、複数の箇所からデータアクセスを提供するためのレプリケーション開発の仕組みは不要です。その上、破損データを手動で修復することも、インデックスを再作成することもまったく必要ありません。データベースで利用可能なストレージ容量を増やす場合も、ダウンタイムなしにノードの追加が可能です。Cloud Spanner は、動的データの再シャーディングとデータ レプリケーションを自動で行うため、水平方向または垂直方向の規模調整に手間はかかりません。こうした理由から、Cloud Spanner の運用費用は、ほぼゼロになります。セキュリティ
Cloud Spanner は、顧客にセキュリティ、透明性、完全なデータ保護を提供しており、お客様の信頼を得ています。金融サービス、ヘルスケア、ライフ サイエンス、電気通信など、レギュレーションの厳しい業界のお客様は、コンプライアンス要件を満たすために各種認定と必要な承認を取得しています。例えば、ISO 27001、27017、27018、PCI DSS、SOC1 | 2 | 3、HIPAA、および FedRamp を必要とするワークロードに使用できます。
セキュリティの観点では、さまざまな機能を利用できます。Identity and Access Management（IAM）を使用すると、プロジェクト、インスタンス、データベースのレベルで、Cloud Spanner リソースに対するユーザーとグループのアクセスを制御できます。データの暗号化について Google Cloud が管理する暗号化鍵と顧客管理の暗号鍵（CMEK）両方用意されているので、必要に応じて選べます。また、Cloud Run から接続する場合、VPC Service Controls 経由でプライベート接続がサポートされます。
デフォルトでは、Cloud Spanner において管理アクティビティ、システム イベントについて監査ログが提供されます。有効設定をすることで、データアクセス監査ログとして提供されます。詳細については、Cloud Spanner 監査ロギングの情報をご参照ください。
アクセスの透明性ログを有効にすると、Google Cloud の担当者が行ったアクションを記録しています。 アクセスの透明性ログは、ほぼリアルタイムのログを顧客に提供します。これを拡張して、さらにアクセス承認を提供します。 Cloud Spanner のアクセス承認を使用すると、お客様は Google Cloud の担当者からのデータへの管理アクセスをブロックし、続行するには明示的な承認が必要になります。
Cloud Run についての注意事
Cloud Run は、コンテナ アプリケーションをデプロイし、稼働させるサーバーレス PaaS です。そのため、コンテナ アプリケーションとしての制約がありますので以下をご参照ください。
Cloud Run についての注意事
Cloud Spanner を効率よく、最大化するにはガイダンスとベスト プラクティスに従い、Cloud Spanner のベスト プラクティスについては以下をご参照ください。
関係するデザインパターン
参照ドキュメント
Google Kubernetes Engine + Firestore
Google Kubernetes Engine + Firestore
解決する課題・使い所
高度なスケーラビリティと構成の柔軟性を提供するコンテナ オーケストレーション プラットフォームを求めているお客様にとって、Google Kubernetes Engine（GKE）は優れた選択肢になります。GKE は、コンテナベースのオーケストレーション システムである Kubernetes のクラスタを構成し、管理するマネージド サービスです。主なユースケースは、以下のとおりです。
マイクロサービス アーキテクチャにおける大規模ウェブ アプリケーション
大規模なゲームインフラ基盤
ML パイプラインを含めたデータ処理基盤
Cloud Run では処理しきれないリソースを必要とする演算処理があるアプリケーションやマイクロサービス アーキテクチャを検討する場合は GKE を検討してください。
次に、リレーショナルな構造が必要とされず、運用負荷をできるだけ軽減したデータベースを検討される場合、Cloud Firestore が優れた選択肢となります。リレーショナル データベースかつ大規模な書き込みを含めたトラフィックの急増にも対応することを検討するときの構成は、以下を参照してください。
アーキテクチャ
GKE と Cloud Firestore のソリューション デザイン パターンのアーキテクチャについては、以下を参照してください。
GKE から Firestore に接続する場合、Cloud Run と同様にサーバー クライアント ライブラリを利用して接続する形式になります。クライアント ライブラリに関しては、Cloud Run と同様に以下を参照してください。
Google Kubernetes Engine 利点
前述のとおり、GKE は Kubernetes のクラスタを構成し、管理するマネージメント システムです。Google Cloud 上で動作し、自動スケールや自動修復、自動アップグレード、自動プロビジョニングなどの機能により、Kubernetes を比較的容易に導入、運用することができます。GKE の主な利点は、以下のとおりです。
スケーラビリティ
GKE では、ノードの水平スケーリング機能と Pod の垂直 / 水平スケーリング機能が備わっており、さまざまな性能要求に対して柔軟なスケーラビリティを確保することができます。クラスタごとの割り当てと上限は以下を参照してください。
割り当てと上限自動アップグレード
クラスタを最新リリース バージョンの Kubernetes に自動的に更新します。管理オーバーヘッドの削減に加えてセキュリティの向上が期待できます。自動修復機能
自動修復機能を有効にするとクラスタ内の各ノードが定期的にチェックされ、修復を必要とするノードが検出された場合、そのノードはドレインされたあとに再作成されます。高可用性
マルチゾーン クラスタやリージョン クラスタを利用することで、コントロール プレーンのアップグレード中にもダウン タイムのない高い可用性を提供できます。高度なセキュリティ機能
コンテナ イメージの脆弱性スキャンやデータ暗号化などがデフォルトで組み込まれています。
GKE には、ノードの構成と管理をユーザー側で行う Standard モードとノードも Google 側で管理する Autopilot モードの 2 つのモードが利用できます。現在は Autopilot モードが推奨されており、デフォルトとなっていますが、課金体系なども異なるので、両者の詳細な違いは、以下を参照してください。
Google Kubernetes Engineについての注意事項
向かないアプリケーションのパターン
単一機能にフォーカスしているシンプルなアプリケーションのパターン
Kubernetes で構築する必要のないシンプルなウェブ アプリケーションでコンテナを利用する場合、Cloud Run で構築することを検討してください。
クラスタ アップグレード戦略
GKE クラスタのアップグレード戦略を適切に計画するために、以下を参照してください。
Autopilot クラスタの制限
Autopilot クラスタは、運用が容易になるので便利ですが、ワークロードなどでいくつかの制限事項があります。詳細は、以下を参照のうえ、ユースケースに合うかどうか検討してください。
Cloud Firestore 利点
Cloud Firestore は、高いスケーラビリティが求められるアプリケーション向けの NoSQL データベースです。シャーディングとレプリケーションを自動的に処理し、アプリケーションの負荷に合わせて自動的にスケールする、可用性と耐久性を兼ね備えたデータベースを提供します。Cloud Firestore は、Native モードと Datastore モードの 2 つのモードを提供します。両方とも同じ基盤となるルーティング インフラストラクチャを使用するので、プロジェクトごとにどちらか一方しか利用することができません。 新しいモバイルアプリに Cloud Firestore のリアルタイム機能を利用したいとき、もしくは Firebase 側の機能も一緒に利用したいときは Native モードが最適なオプションです。従来、Native モードでは秒間あたりの書き込み制限とクライアントの最大同時接続数の制限がありましたが、2022 年 10 月のアップデートで制限が撤廃されたので、より多くのユースケースで Native モードを活用できるようになりました。すでに Datastore SDK を使い慣れている場合、Datastore モードを検討します。 Cloud Firestore の主な利点は、以下のとおりです。
ACID トランザクション
ACID トランザクション、SQL ライクなクエリ、インデックスなどの多くの機能を備えています。簡単にスケーリング
Cloud Firestore は、Google Cloud の強力なインフラストラクチャを活用することを目的に、ゼロから構築された自動スケーリング ソリューションであり、アプリの成長に合わせて簡単にスケーリングできます。スキーマ レスによるデータ構造の柔軟性
Cloud Firestore は、効率的なクエリ機能を備えた NoSQLドキュメント データベースであり、論理的に意味のある方法でデータを階層構造に保つことができます。真のサーバーレス ソリューション
Native モードを利用する場合、モバイル、またはウェブ クライアントから直接 Cloud Firestore と通信をするので、中間となるアプリケーション サーバーを設定する必要はありません。包括的なクライアント ライブラリ
Cloud Firestore は、ネイティブ モバイルアプリ用とウェブ用の両方のリッチで包括的なクライアント ライブラリがサポートされており、Cloud Firestore での作業をシンプルで容易にします。特に Native モードのクライアント ライブラリには、以下のような特徴があります。オフライン サポート
Cloud Firestore は、ウェブを含む完全なオフライン サポートを備えているため、ユーザーはネットワークに接続していない場合でも、データにアクセスして変更を加えることができます。クライアント ライブラリを使用すると、アプリケーションの意味に応じて、データへの変更を自動的に受信したり、必要に応じてデータをプッシュしてリクエストしたりすることができます。自動同期
Cloud Firestore を使用すると、データが変更されたときにアプリケーションをほぼリアルタイムで更新することができます。これは、共同のマルチ ユーザー アプリケーションを構築するのに最適なだけでなく、複数のデバイスからアプリケーションを使用する可能性のある個々のユーザーとデータを同期させることができることも意味します。使いやすさ
Cloud Firestore の慣用的なクライアント ライブラリを使用すると、ネットワーク接続の確立や予期しない競合状態の処理を心配する必要なく、新しいデータを簡単に更新して受信できます。
このパターンで作成された事例
関係するデザインパターン
参照文献
Page updated
Report abuse