サーバーレス

フルマネージド型のアプリケーションでコストと信頼性を管理

Google_Blog_Serverless - 04.jpg

※この投稿は米国時間 2020 年 5 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

すべてが順調に稼働しているときも、困難に直面しているときも、フルマネージド型のサーバーレス環境でアプリケーションを実行することには多くの利点があります。需要が急激に高まった場合、アプリケーションは自動的にスケールアップされ、クラッシュやダウンタイムを回避できます。需要が低下するとアプリケーションはスケールダウンされて、コストを節約できます。

しかし、顧客の需要が大幅に変動すると、予期しないシステム動作のみならず、想定外の料金も発生します。先行きが不透明なときは、条件を満たすサービスレベルを維持しながら全体的な費用を一時的に削減し、ある程度の予測可能性を得る必要があるでしょう。

Google Cloud では、App Engine、Cloud Run、Cloud Functions といった複数のサーバーレス コンピューティング プロダクトをご用意しており、さまざまなユースケースに利用することが可能です。各プロダクトでは、それぞれの方法でコストを管理してトラフィックの急増に備えることができます。このブログ記事では、簡単なタスクとチェック項目を使って、サーバーレス アプリケーションのダウンタイムを最小化しながら不測のコストを軽減する方法をご案内します。

費用管理

サーバーレスの全体的な課金を削減したり、予算超過を防ぐための保護対策を講じたりするのに利用できるアプローチがいくつかあります。

最大インスタンス数の設定

Google Cloud のサーバーレス インフラストラクチャは、アプリケーション内のインスタンス数(少ないほどコストが下がります)と、リクエストのレイテンシ(インスタンス数が多いほどレイテンシは低下します)の両方について最適化を試みます。すべてのサーバーレス プロダクトで、特定のアプリケーション、サービス、関数のインスタンス数を最大に設定することが可能です。

これは強力な機能ですが、適切に使用する必要があります。「最大インスタンス数」の値を低く設定すると、全体的な課金を削減できますが、リクエストのレイテンシやリクエストのタイムアウトが増加するという結果につながる可能性もあります。インスタンスで処理されなかったリクエストは、キューに入れられた後にタイムアウトになる場合があるためです。

これとは逆に、高い値を設定したり、最大インスタンス数を無効にしたりすると、リクエストのレイテンシは最適化されますが、特にトラフィックが急増したときの全体的なコストが上昇します。

適切な最大インスタンス数の選び方は、トラフィックと、目標とするリクエストのレイテンシによって変わります。この設定の構成方法はプロダクトによって異なります。

App Engine

App Engine は、通常の状況下でアプリケーションに必要なインスタンス数の見積もりに使用できる指標(appengine.googleapis.com/system/instance_count)を Cloud Monitoring に提供します。App Engine の最大インスタンス数の値は app.yaml ファイルにより変更できます。

  service: my-service
...
automatic_scaling:
  ...
  max_instances: 100
  ...

App Engine でのインスタンス管理についての詳細をご覧ください。

Cloud Run

課金対象のコンテナ インスタンス時間」指標を使用して、アプリケーションの実行に使用されているインスタンス数を見積もることができます。たとえば、「100s/s」と表示されている場合は、およそ 100 個のインスタンスがスケジュール設定されていたことを意味します。バッファを最大 30% に設定して、アプリケーションの現在のパフォーマンスの特性を保持することもできます(例: 100s/s のトラフィックに対して 130 個の最大インスタンス数)。

コマンドラインを使用して、Cloud Run の最大インスタンス数を変更できます。

  gcloud run services update SERVICE --max-instances MAX-VALUE

Cloud Run のコスト管理のもう 1 つの要素は、インスタンスの自動スケーリングを処理して受信リクエストに対応する方法です。デフォルトでは、Cloud Run コンテナ インスタンスは同時に複数のリクエストを受信できます。インスタンスが応答できるリクエストの最大数は、同時実行の設定で制御可能です。Cloud Run は、インスタンスの CPU とメモリ使用率に基づいて、特定のインスタンスに送信するリクエスト数を自動的に判定します。この値に最大数を設定するには、Cloud Run サービスの同時実行を調整します。デフォルト値(80)より低い値を使用している場合は、最大インスタンス数を変更する前に同時実行の設定を増やしてみることをおすすめします。同時実行の設定を増やせば、必要となるインスタンス数は減ります。

Cloud Run のインスタンスの自動スケーリングについての詳細をご覧ください。

Cloud Functions

Cloud Functions は、通常の状況下で関数に必要なインスタンス数の見積もりに使用できる Cloud Monitoring 指標(cloudfunctions.googleapis.com/function/active_instances)を提供します。

コマンドラインを使用して、Cloud Functions の最大インスタンス数を変更できます。

  gcloud functions deploy FUNCTION_NAME --max-instances MAX-VALUE

Cloud Functions のインスタンス管理についての詳細をご覧ください。

予算アラートの設定

予算アラートは、アプリケーションのフットプリントを削減するための変更を行ったかどうかに関わらず、予期しない課金の増加に対する重大な早期警告シグナルを提供します。予算アラートの設定は簡単で、メールまたは Cloud Pub/Sub 経由でアラートを送信するよう構成できます。Cloud 関数をトリガーできるため、アラートをプログラム処理することが可能です。

ラベルの使用

ラベルを使用すると、単純なテキスト値を特定のリソースに割り当て、請求書の料金をフィルタするために利用できます。たとえば、複数の Cloud Run サービスと 1 つの Cloud 関数から構成されるアプリケーションがあるとします。こうしたリソースに一貫したラベルを適用することで、請求書に記載されているこのマルチサービス アプリケーションの全体的な影響を確認できます。これは、請求額の大半を占める Google Cloud の使用エリアを特定して、的を絞った対応策を取るのに役立ちます。詳細については以下をご覧ください。

インスタンス クラスのサイズ設定

Google のすべてのサーバーレス コンピューティング プロダクトでは、アプリケーションで使用可能なメモリ量や CPU をある程度選択できます。通常、こうしたリソースに大きな値をプロビジョニングすると、料金が上がります。ただし、より強力なインスタンスを選ぶことで、全体的な課金を削減できる場合もあります。

大量の CPU を消費するワークロードでは、CPU を多く割り当てると(具体的には、より大きな 1 秒あたりの CPU サイクル数)、実行時間が短くなるため、作成されるアプリケーションのインスタンスが少なくなります。どのような場合でも使える万能なインスタンス クラスのサイズ設定はありませんが、大量の CPU を使用する一般的なアプリケーションでは、より多くの CPU を割り当てることでメリットが得られます。一方、CPU を十分に活用していないアプリケーションでは過剰なプロビジョニングとなる可能性があります。この場合は、小規模なインスタンス(低コスト)でアプリケーションへのトラフィックを処理できるでしょう。

さまざまな Google Cloud のサーバーレス プラットフォームでインスタンスのサイズを設定する方法についてご紹介します。  

App Engine スタンダード環境

現在のところ、App Engine スタンダード環境では CPU 利用率についてのインスタンスごとの指標をご提供していません。appengine.googleapis.com/system/cpu/usage を使用すれば、すべてのインスタンスのアプリケーション全体の CPU 使用率を追跡できます。CPU の制約を大きく受けるアプリケーションでは、大きなインスタンス クラスが適している場合があります。これは、必要とされるインスタンス数とインスタンス作成イベント数が少なくなり、アプリケーション全体の CPU 使用率が低下するためです。

App Engine フレキシブル環境

App Engine フレキシブル環境は、アプリケーションのインスタンスごとの CPU 使用率を追跡するのに使用できる CPU 使用率の指標(appengine.googleapis.com/flex/instance/cpu/utilization)を提供します。

Cloud Run

Cloud Run は、Cloud Run サービスの全インスタンスにわたる CPU 使用率のパーセンタイル分布を表示する、CPU 使用率の分布指標(run.googleapis.com/container/cpu/utilizations)を提供します。

Cloud Functions

現在のところ、Cloud Functions では、CPU 使用率をレポートする指標をご提供していません。最適なインスタンス クラスを判定する最善の方法は、テストを行うことです。関数の実行時間をモニタリングすることで、割り当てられた CPU の使用率の増加による影響をモニタリングできます(cloudfunctions.googleapis.com/function/execution_times)。通常、CPU の制約を大きく受ける関数は、多くの CPU リソースが与えられた場合、より短い実行時間をレポートします。

必要なインスタンスの大きさに関わらず、トラフィック管理を使用して最適な構成を見つけることをおすすめします。まず、構成を変更して、サービスやアプリケーションの新しいリビジョン(App Engine の場合はバージョン)を作成します。これが完了したら、前述の指標をモニタリングして、改善がみられるかどうかを調べます。

スケーリングに関する対策

サービスの需要が予測よりも多い場合、アプリケーションがトラフィックの大幅な増加に対応できるよう確認すべき点をいくつかご紹介します。

最大インスタンス数の確認

上記でコスト管理についてご説明したように、コスト管理よりもアプリケーションのパフォーマンスと信頼性を重視する場合は、最大インスタンス数の設定が適切であることを再確認してください。

割り当ての確認

リソースの割り当ては、予測より多くのリソースを消費しないための設定で、予想を上回る請求を避けることができます。しかし、アプリケーションのトラフィックが予測を超えて増加している場合、リソースの割り当てを増やすことにより、顧客がアプリケーションを必要としているときに停止するという事態を防ぐ必要があります。一部の割り当ては、Google Cloud Console から直接変更できます。その他の割り当てについては、サポート チケットを使用して変更します。サービスの割り当てに対する現在の使用量は、Cloud Console の [割り当て] ページから確認できます。

すべてを組み合わせる

需要に応じて自動的にスケールされるアプリケーションが必要な場合は、まずはサーバーレス プラットフォームで構築することをおすすめします。パフォーマンスを犠牲にしたり、予期しないコストを負担したりすることなく、効率的なスケーリングを実現するための対策は数多くあります。次に作成するアプリケーションでサーバーレス コンピューティング プロダクトをご利用になる方法について詳しくは、Google のその他のサーバーレス プロダクトをご覧ください。

- By ソフトウェア エンジニア Greg Block、リード プロダクト マネージャー Jason Polites