IBM Cloud Code Engine: ジョブやアプリケーションを使い分ける方法

Code Engineの2つのコンピュート・モデル(ジョブとアプリケーション)をいつ、どのように、そしてなぜ使い分けるかについて

ユーザーの皆様からは、よくジョブを使うべきか、アプリケーションを使うべきか、あるいはその両方を組み合わせて使うべきかとご質問をいただきますが、ここではその背景をご説明し、パブリック・クラウドでのサーバーレス・ワークロードから学んだことを共有したいと思います。

アプリケーションは、主にマイクロサービスやウェブ・アプリケーションを実行してhttpリクエストに応答するように設計されています。そのため、アプリケーションにはクライアントが呼び出すことができるエンド・ポイント（ルート）があります。リクエストはアプリケーション・インスタンスにルーティングされ、レスポンスがクライアントに送信されるまで接続はオープンになったままになります。

アプリケーション・インスタンスは、受信したhttpリクエストの数に基づいてスケール・アップしたり、スケール・ダウンしたりします。アプリケーションをスケーリングする基準は、ユーザーによって定義することができ、特定のアプリケーション・インスタンスの同時リクエスト数によります（例えば、ユーザーは、処理される同時リクエストを10個だけ許可するように指定することができます）。システム内の同時リクエスト数が10を超える場合、Code Engineはユーザーの基準を満たすようにインスタンス数をスケール・アップします。アプリケーションは、大量のhttpリクエスト/レスポンス ・ワークロードを低レイテンシーで処理するのに最適です。アプリケーションは、より高い同時実行性を備えた同期リクエスト・レスポンス・モデルを提供します。

ジョブは主に、与えられた入力データに対して、完了するまでタスクやプロセスを実行するように設計されています。そのため、ジョブは非同期的に実行するために開始することができます。ユーザーはインデックス値のリストを指定することができ、Code Engineはリスト内の各インデックスに対してジョブ タスクを開始します（例えば、ユーザーは値1～10を指定することができ、結果として10のタスクが発生し、各タスクには1～10の間の値が割り当てられます）。割り当てられたインデックスに基づいて、タスクはどのデータを処理するかを決定することができます（例えば、インデックス1はCOSバケットのオブジェクト1にマップされます）。ジョブ・タスクが失敗した場合、タスクは最終的に失敗するまで一定回数再試行されます。ジョブは非同期で実行されるので、ジョブは長時間実行されることがあります。

アプリケーションとジョブはどのような場合に使い分けるのか

アプリケーションとジョブの基本的な機能を理解したところで、どのような場合に使い分けるべきかを見ていきましょう。正しい技術を選ぶためには、ワークロードの性質とその特性を理解することが重要です。

• ワークロードに低レイテンシーが必要な場合、もしくは対話型の場合:アプリケーションを使用する: ワークロードでクライアントやユーザーがリクエストのレスポンスを同期的に待つ必要があり、レスポンスが数ミリ秒以内に利用可能でなければならない場合、開発者はアプリケーションを使用するべきです。その理由は、アプリケーションは外部から到達可能なエンドポイントを提供し、リクエストに同期して応答するからです。このようなワークロードの例としては、ウェブサイト、チャット・ボット、モバイル・アプリケーションなどがあります。
• ご利用のCPUワークロードが軽量で、CPU/メモリとI/Oをあまり必要としない場合:アプリケーションを使用する:ワークロードが軽量で、CPU/メモリとI/Oの使用量が少ない場合は、同じアプリケーション・インスタンス内での同時呼び出しの方がメリットがあります。典型的な例としては、CRUD 操作を提供し、NoSQL データベースでバックアップされている API サーバーがあります。リクエストを処理するためには、データ量が少なく、そのデータを処理するために必要なメモリーやCPUサイクルはそれほど多くありません。より高い同時実行性があれば、アプリケーションは、2 番目のリクエストが I/O を待っている間に、1 番目のリクエストのデータを処理することができます。CPUとメモリーの必要量が少ないので、多くのリクエストを同時に実行することができます。ジョブを使用することも可能ですが、ジョブは単一の同時実行モードで実行されるため、オーバーヘッドとそれに伴うコストが高くなります。
• ご利用のワークロードがCPU、メモリ、またはI/Oに縛らる場合:ジョブとアプリケーションを使用する:与えられた量のデータを処理する必要があり、データの各チャンクが大きく、多くのCPUとメモリを必要とする場合は、一般的にジョブを使用するのが良い選択です。しかし、ワークロードがリクエスト・レスポンス・パターンを必要とする場合は、アプリケーションを使用することも可能です。どちらの場合も、計算タスクは単一の同時実行で実行されます。各アプリケーション・インスタンスまたはジョブ・タスクは、インスタンスに設定されたリソースを十分に利用するために、1つのリクエストまたはデータの塊を同時に処理するだけです。並列性はインスタンス/タスクの数によって達成されますが、リソースの制約が大きいために追加タスクを生成するオーバーヘッドは交渉可能です。典型的な例としては、COSバケット上での画像データの処理や機械学習モデルの提供などがあります。
• ご利用のワークロードが多くの時間を必要とする場合:ジョブを使用する: 計算が長時間に渡って実行される場合、ジョブは非同期の性質を持っているため向いています。アプリケーションの最大持続時間は常に制限されています。典型的な作業負荷がかかるのは、機械学習モデルのトレーニングやハイパー・パラメータの最適化です。
• 前もって並列的なワークロードを指定できる場合:ジョブを使用する: 実行する必要のある計算量が分かっている場合、完了するまでの間、正確なインスタンス数のジョブを実行することができます。典型的な例としては、ハイパー・パラメーターのチューニングやニューラル・ネットワークのトレーニングなどがあります。
• ワークロードが何かのイベントに対応する場合:アプリケーションを使用する:リポジトリーにプッシュされたGitコミット、COSバケットにアップロードされたオブジェクト、データベース内で変更されたドキュメントなど、ワークロードがイベントに対応する必要がある場合、アプリケーションを使用するとよいでしょう。
• イベント/リクエストに対応して、短期間に大量のデータを処理する必要がある場合:アプリケーションを使用する:ワークロードが予測できないリクエストやイベントに対して迅速な応答を必要とする場合、アプリケーションが動的にスケーリングされるため、一般的にはアプリケーションの方が適しています。

まとめ

IBM Cloud Code Engineにはジョブとアプリケーションという2つのコンピュート・モデルがあり、それぞれに多くのユース・ケースがあります。そのうちいくつかはこの記事で紹介しました。アプリケーションとジョブを組み合わせることも可能で、アプリケーションはジョブを起動して特定の計算をアウトソースすることができます。一方、ジョブがアプリケーションに問い合わせをすることも可能です。両方の組み合わせの典型的な例は、機械学習モデルのトレーニングとサービスです。ジョブは一般的にモデルを訓練するために使用され、アプリケーションはモデルを提供するために使用されます。

以下は、アプリケーションとジョブをどのように使いわけるのがおすすめかをまとめたものです:

アプリケーション

• 外部ストレージへのデータの入出力
• リクエスト/レスポンスの入出力データ
• リクエストに基づく動的スケーリング
• 低レイテンシーの対話型ワークロードへのリクエスト/レスポンス
• イベントへの対応
• リソース要件の少ない高い同時実行性（最適なケース)
• 高いリソース要件を持つ単一の同時実行（ただし、レイテンシーのオーバーヘッドに注意)
• 高スループットのリクエスト/レスポンス・ワークロード

ジョブ

• 外部ストレージへのデータの入出力
• 入力データに基づく静的スケーリング
• 計算時間が10分以上かかる
• 低いリソース要件で高い同時実行性を実現（ただし、コストのオーバーヘッドに注意)
• 高いリソース要件を持つ単一の同時実行（最適なケース)

より詳しいことは

いかがでしたか? この機会にぜひIBM Cloud Code Engine のご利用をご検討ください 。

始めるにあたっては、こちらの文書の「はじめに」がお役に立てれば幸いです。より詳しいことは関連ブログ「IBM Cloud Code Engine : クラウドをもう一度ご活用ください」やIBM Cloud Code Engineのソリューション・チュートリアルもぜひご活用ください。

IBM Cloud Code Engine がみなさまのお役に立てれば幸いです。