IBM Cloud Code Engine: アプリケーションのスケール、レイテンシー、スループットを最適化する方法

アプリケーションのコンカレンシー設定と、レイテンシーをとスループットを最適化する方法

IBM Cloud Code Engine は、フル・マネージドのサーバーレス・プラットフォームで、Web アプリケーション、マイクロサービス、イベント駆動型のファンクション、バッチ・ジョブなど、コンテナ化されたワークロードを実行します。IBM Cloud Code Engine は、「ジョブ」と「アプリケーション」という2 つのコンピュート・モデルを提供します。これらのモデルについては、英文ブログ”IBM Cloud Code Engine: When to Use Jobs and Applications“を参照してください。

並行処理の限界

このブログでは、アプリケーションのコンカレンシーの設定と、レイテンシーとスループットを最適化する方法をご紹介します。

コンカレンシーは、アプリケーションの各インスタンスが同時に処理できるリクエストの数を決定します (詳細については Knative の公式ドキュメント(英文)を参照してください)。

アプリケーションのリビジョンごとにコンカレンシーを管理するには、アプリケーションの詳細ページのランタイム・セクションでコンカレンシー数を設定します。CLI では、IBM Code Engine CLI を使用して ic ce app create/update でアプリケーションを作成または更新する際に --concurrencyフラグを使用してコンカレンシーを設定できます。API 仕様では、リビジョン・テンプレートで containerConcurrency を設定することができます（リビジョン仕様のドキュメント(英語)を参照してください）。

コンテナ・コンカレンシー (cc) 構成を設定すると、アプリケーション・インスタンス内で処理されるリクエストの上限が適用されます。コンカレンシーがこの制限に達すると、それ以降のリクエストはバッファリングされ、リクエストを実行するのに十分なキャパシティが空くまで待たなければなりません。追加のキャパシティは、リクエストの完了やアプリケーション・インスタンスのスケールによって増やすことができます。

アプリケーションのスケールがどのように機能するか

Knative 内にあるオートスケーラーは、システム内のリクエスト数を監視し、ユーザーのコンカレンシー設定を満たすように、アプリケーションのインスタンスをスケーリングさせます。特にオートスケーラーは、アプリケーションにリクエストがない場合には、アプリケーションをゼロにスケールすることができます。この場合、インスタンスは実行されず、コストも発生しません。ゼロにスケールした状態でアプリケーションにリクエストがあった場合、オートスケーラーはゼロからアプリケーションをスケール・アップし、新たに作成されたアプリケーション・インスタンスにリクエストをルーティングします。そのため、システムはアプリケーション・インスタンスがリクエストを受け付ける準備が整うまで、リクエストをキューに入れるための内部バッファーを持っています。

内部的には、オートスケーラーは60秒のスライディング・ウィンドウを持っており、そのスライディング・ウィンドウに対しコンカレンシーが満たされるようにアプリケーションをスケーリングします。リクエスト・レートは非常に大きく変化(リクエスト・バースト)する可能性があるので 、コンテナ・コンカレンシーが 70% となったときに、オートスケーラーはすでにスケール・アップを実行するようになっています。すなわち、コンカレンシーを10と設定した場合、60秒間で平均7リクエストがあったときに、オートスケーラーはアプリケーション・インスタンスを追加します。

リクエスト・レートが非常に大きく増加した場合、オートスケーラーはパニック・モードに入ります。パニック・モードの間、オートスケーラーのフィードバック・ループはより短く（このときスライディング・ウィンドウは6秒になります）、スケーリング・ポリシーはより積極的になります（すなわち、6秒間のウィンドウに対しコンテナ・コンカレンシーが70%を満たすために、より迅速にスケールアップします）。オートスケーラーは、コンテナ・コンカレンシーの200%が観測されるとパニック・モードに入ります。つまりコンカレンシーを10と設定した場合、システムに対し20リクエストが観測されるとパニック・モードに入ります。

ic ce app create/updateを使用してアプリケーションを作成または更新する際に --min-scale と --max-scaleフラグを使って以下の 2 つのアノテーションを追加すれば、オートスケーラーのスケーリング境界を設定することができます。

• autoscaling.knative.dev/minScale (--min-scale):  実行し続けるアプリケーションインスタンスの最小数。ゼロ（デフォルト）に設定すると、アプリケーションにリクエストがない場合、オートスケーラーはすべてのインスタンスを削除します。
• autoscaling.knative.dev/maxScale (--max-scale): 実行されるアプリケーション・インスタンスの最大数。オートスケーラーはこの値を超えてスケールアップしません。

レイテンシーとスループットをどのように最適化するか

以下のセクションでは、コンテナ・コンカレンシー (cc) を設定するための例とベストプラクティスをご紹介します:

• Single, cc=1: アプリケーションがメモリや CPU を多く使用する場合は、コンカレンシーは1にしたほうがよいでしょう。他のアプリに邪魔されることなくリソースをフルに使うことができるためです。ただ、既存のアプリケーション・インスタンスを再利用しづらく、アプリケーションのスケール・アウトが頻繁に起こりうります。新しいインスタンスを作成するとレイテンシーが発生したりスループットが低下したりするので、注意が必要です。したがって、リクエストを同時に処理することができ、レイテンシーが重要である場合には、このモデルを選択すべきではありません。
• High, cc=100 (デフォルト) 以上: アプリケーションがメモリや CPU を多く使用せず、大量の HTTP リクエスト/レスポンスを処理する場合には、この設定を選択すべきです。例えば、リモート・データベースに対する CRUD 操作でデータを読み書きする API バックエンドのアプリがこれにあたります。一部のリクエストが I/O で待機している間、他のリクエストは全体的なレイテンシーとスループットに影響を与えることなく処理することができます。ただし、この設定は CPU、メモリ、または I/O で競合する同時リクエストには向いていません。
•  Optimal, cc=N: アプリケーションのリソース要件を非常によく理解しており、望ましい応答時間を満たすために、1つのリクエストに必要なリソースの量を知っている場合はそれに応じた値を設定してください。例えば、自然言語翻訳アプリケーションで、言語翻訳の機械学習モデルにメモリが32GB、翻訳計算には1回あたり約0.7vCPUが必要だった場合、インスタンスごとに9個のvCPUと32GBのメモリを構成することができます。この場合、最適なコンテナ・コンカレンシーは13(9 vCPU/0.7 vCPU)となるでしょう。どのように動作するかが正確に知られておらず、理解されていない場合は、値の設定に注意が必要です。コンカレンシーの設定を間違えると、頻繁なスケーリングやまったくスケーリングされないようなことになり、アプリケーションのレイテンシー、エラー率、およびコストに影響を与える可能性があります。後述のステップを使用して、最適なコンテナコンカレンシーを決定してください。
• Infinite, cc=0 (無効): Knative はこの設定をサポートしていますが、IBM Cloud Code Engine ではサポートされません。この設定は、可能な限り多くのリクエストを単一のアプリケーション・インスタンスに転送しようとし、アプリケーション・インスタンスの追加を遅延させます。さまざまなテストや分析では、エラー率が高くなり、待ち時間が長くなることが確認されています。そのため、IBM Cloud Code Engine ではこの設定を無効にして、ユーザーを予期せぬ動作から守るようにしています。

コンテナのコンカレンシーをどのように決定するか

コンテナ・コンカレンシー (cc) は、アプリケーションの成功率、レイテンシー、スループットに大きな影響を与えます。コンテナ・コンカレンシーが高すぎると、ユーザーはレイテンシーの増加とスループットの低下により、一時的に 502 や 503 エラーに遭遇することになるかもしれません。

逆に、コンカレンシーが低すぎても頻繁にスケールアウトが発生し、コストのやレイテンシーに影響を与えることになります。また、負荷が集中したときに、システムの内部バッファーがさばききれず一時的に 502 応答が発生する可能性もあります。

最適なコンテナ・コンカレンシーは、アプリケーションが許容可能なレイテンシーで処理することのできる最大同時リクエスト数によって決定されます。

以下の手順を使用して、アプリケーションに適したコンテナ・コンカレンシーを見積もることができます:

1. アプリケーションを作成し、cc=1000(最大値) と minScale と maxScale を1に設定します。
2. vegeta(英語)や wrk(英語)のようなツールを使用して、アプリケーションに対して負荷を生成します。最初は、高いレートでリクエストを送信します。502 エラーが出た場合は、結果が 100% の成功率になるまでレートを下げてください。
3. 次に、ステップ2で出た結果から、リクエストに対するレイテンシーを取得します。もしレイテンシーが許容できない値の場合は、許容できるようになるまでリクエスト率をさらに下げてください。リクエストの処理時間も重要です。(リクエストの処理に2秒かかるか100ミリ秒かかるかで大きな違いが出てきます)。
4. アプリケーションのコンテナ・コンカレンシーを計算するには、ステップ2のRATE(req/s)を取り、ステップ3のLATENCY(秒)で割ってください。CC = RATE/LATENCY。例えば、レートが 80 req/s、レイテンシーが 2s の場合、結果としての同時実行率は CC = 80 req/s / 2s = 40 となります。
5. 次に、前のステップで得た値(40)にコンテナ・コンカレンシーを設定するようにアプリケーションを更新し、ワークロードを再実行して、成功率とレイテンシーが許容できるかどうかをチェックします。
6. コンテナ・コンカレンシーを少し大きめの値に設定して、アプリケーションを実験してみて、成功率とレイテンシーが許容できるかどうかを確認します。
7. 最後に、最適なコンテナ・コンカレンシーの値を取得し、アプリケーションが自動的にスケールできるようにするためにminScaleとmaxScaleの境界を取り除くことができます。

さらに詳しくは

さあ、はじめてみませんか? こちらの文書の「はじめに」をご覧ください。詳細については、IBM Cloud Code Engineチュートリアル をご覧いただくとともに、ブログ “IBM Cloud Code Engine: Enjoy Your Cloud Again” (英語)もご参考になれば幸いです。