クラウドネイティブ アプリケーション 

多くの企業は、オンプレミス環境においてモノリシック アーキテクチャを使用してカスタム ソフトウェア サービスを構築しています。新しい変化に適用するために、機能追加や変更を加えていくと、アプリケーションがより複雑になってしまい、費用と時間がかかる上に、展開にはリスクも伴ってきます。

こうした課題を解決するには、コンテナベースのアプリケーション サービスとクラウド ネイティブのデータベースを合わせて利用することが有効です。アプリケーションに高い俊敏性、スケーラビリティ及び可用性など様々なメリットがあり、次の環境変化への適応性を高めることができます。

Google Cloud が提供するいくつかのマネージド サービスは、コンテナベース アプリケーションとスケール可能なデータベースの両方が含まれています。ここでは、クラウド ネイティブの組み合わせと全体構成についての詳細とユースケース、システム要件に合わせた最適なデザイン パターンと、本番におけるベスト プラクティスを紹介します。 

デザイン パターン詳細

❏ Cloud Run + Cloud Firestore
❏ Cloud Run + Cloud Spanner

 

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 を利用する場合は、トランザクションが失敗する場合のリトライやオフラインの対応などを自動的に実施してくれます。 

  • クライアント ライブラリを用いた接続
    • モバイルもしくは Web アプリを開発する場合のクライアントからのアクセス、セキュリティルール経由で権限コントロールすることが可能です。
    • スキーマ情報の確認やバッチを実行する場合には、特権ユーザが必要で、Firebase Admin SDKs を利用します。その場合は IAM 経由で権限コントロールされます。
    • クライアント ライブラリの概要
  • 直接 Cloud Firestore API を呼び出す接続
1

不特定多数からのアクセスを抑止し限定的に公開する場合は、サービスを作成する際に「認証を必要とする」を選択します。これによりサービスが非公開となります。アクセスを許可するユーザーを追加し、Cloud Run Invoker (roles/run.invoker) ロールを付与します。また Google Cloud 外部から呼び出す際に Authorization Bearer ヘッダに有効な ID トークンを付与してアクセスを行います。

同様にして Cloud Pub/Sub などの Google Cloud 上のサービスから Cloud Run を呼び出す構成を行う事ができます。

2

リージョナル サービスで提供されている Cloud Run と Cloud Firestore をマルチリージョンで構成し可用性を向上させる場合には Serverless NEG と HTTP(S) ロードバランサを組み合わせて使用します。また、Serverless NEG を組み合わせた構成では、Cloud Armor を利用してウェブアプリケーションの保護をする事が可能になります。

3

Cloud Run のフロントエンドに構成する HTTP(S) Load Balancing は、Serverless NEG の構成後に バックエンドサービス、URL マップ、HTTP プロキシ、フォワーディング ルールを作成して構成を行います。 

4

利点

フロントエンドのアプリケーションプラットフォームに 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 との統合
    • リクエスト タイムアウト設定
  • スケーラビリティ
    Cloud Run では受信したリクエストをすべて処理するために自動的にスケーリングが行われます。リクエストを受け付けていない時にはインスタンス数を 0 までスケールダウンし、リクエストが増加してきた場合には 設定した最大数 (デフォルト 最大数 1000) までスケールアウトします。また、各インスタンスが同時に処理するリクエスト数の設定が可能 (最大同時実行数 80) でリソースを効率的に利用したリクエスト処理が可能です。 

Cloud Firestore 利点 

アプリケーション向けのスケーラビリティが高い NoSQL データベースです。シャーディングとレプリケーションを自動的に処理し、アプリケーションの負荷に合わせて自動的にスケールする、可用性と耐久性を兼ね備えたデータベースを提供します。 Cloud Firestore は Native モードと Datastore モードの 2 つのモードを提供します。両方とも同じ基盤となるルーティング インフラストラクチャを使用します。ゆえに、プロジェクトごとにどちらか一方しか利用することができません。 新しいモバイルアプリに Cloud Firestore のリアルタイム機能を利用したい場合、もしくは Firebase 側の機能も一緒に利用したい場合は Native モードが最適なオプションです。 サーバー側でのみ使用する場合、もしくは大規模で書き込みが発生するようなワークロードの場合は、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 のドキュメント書き込み頻度制限
      • 典型的なケースとして、あるドキュメントに頻繁に発生するイベントのカウントーが保存されるような設計になったら問題になり易いです。この問題に対応するには、複数のドキュメント間でカウンターを分割する「分散カウンタ」と呼ばれる代替ソリューションの利用を検討してください。
    • 1MB のドキュメントサイズ制限 時間と共に、無制限に大きくなる可能性のあるマップおよび配列タイプのフィールドの使用をなるべく避けてください。
    • 1秒あたり 10,000 の書き込み
    • トランザクションごとに最大 500 のドキュメント処理可能
    • 同時接続最大数は 1,000,000 まで 

 

サンプル コンフィグ

参照文献

 

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 のソリューション デザイン パターンの詳細については、以下の図をご参照ください。  

image

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 との統合 
    • リクエスト タイムアウト設定

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 Spanner を効率よく、最大化するには​​ガイダンスとベスト プラクティスに従い、Cloud Spanner のベスト プラクティスについては以下をご参照ください。

関係するデザインパターン

参照文献