Code Engine の計画

IBM Cloud® Code Engine は、アプリケーション、ジョブ、および機能という 3 つの基本タイプのワークロードをサポートします。

アプリケーション (アプリ) は、HTTP 要求を処理するコードを実行します。 IBM Cloud® Code Engine は、従来型の HTTP 要求に加えて、通信プロトコルとして WebSocket を使用するアプリケーションもサポートします。アプリの実行中のインスタンス数は、入ってくるリクエストとコンフィギュレーション設定に基づいて自動的にスケールアップまたはスケールダウン（ゼロに）されます。アプリには、1 つ以上のリビジョンが含まれています。リビジョンとは、アプリの構成プロパティーの変更不可能なバージョンの 1 つを表します。アプリの構成プロパティーが更新されるたびに、アプリの新規リビジョンが作成されます。

ジョブは、あなたの実行コードの1つ以上のインスタンスを並列に実行します。 HTTP 要求を処理するアプリケーションとは異なり、ジョブは一度実行したら終了するように設計されています。ジョブを作成するときには、ジョブの実行時に毎回使用するワークロードの構成情報を指定できます。

関数は、 HTTP リクエストによって呼び出されるタスクを実行するステートレスなコード・スニペットである。 IBM Code Engineの関数を使用すれば、スケーラブルでサーバーレスな方法でビジネス・ロジックを実行できます。 IBM Code Engineの機能は、低レイテンシーと迅速なスケールアウト・シナリオをサポートするために最適化されたランタイム環境を提供します。あなたの関数コードは、特定の Node.js または Python バージョンを含むマネージド・ランタイムで書くことができます。

アプリケーション、ジョブ、関数の比較 Code Engine アプリケーション、ジョブ、関数の比較
特性	アプリケーション	ジョブ	関数
実行時間 (期間)	長期実行 (要求ごとに 10 分)	長期実行 (最大 24 時間)	短時間実行 (2 分以下)
始動待ち時間	中	予定開始日	低
終了	継続的に実行	実行から完了まで	実行から完了まで
呼び出し	要求時または永続的に実行中	スケジュール済み	要求時、インスタント
プログラミング・モデル	コンテナー・ベースのビルドと実行	コンテナー・ベースのビルドと実行	言語固有のソース・コード・ファイルおよび依存関係メタデータ
並列処理	並列実行、柔軟性	低から中程度の並列実行	高並列実行
スケールアウト	要求の数に基づく	ジョブ・ワークロード定義に基づく	イベントまたは直接呼び出しに基づく
最適化の対象	長時間実行され、非常に複雑なワークロードとオンデマンド・スケールアウト	リソース要求が高い、スケジュールされたワークロードまたは計画されたワークロード	起動時間と迅速なスケールアウト

Code Engine のユース・ケース

Code Engine のユース・ケースは非常に幅が広いため、取り掛かるためのいくつかの例をご紹介します。

コンテナーに関する経験がありますが、クラスターの管理に関するスキルも予算もない: あなたはコンテナーについてよく理解している開発者です。ただし、クラスターの管理を複雑にしたり、そのために時間を費やしたりすることは望んでいません。 Code Engine を使用すると、クラスターを管理するために必要なスキルについて心配したり、管理するための時間について気にしたりする必要はありません。代わりに、Code Engine がこうした複雑な処理を行い、IBM チームが IBM Cloud サービスの一環としてご使用のインフラストラクチャーを管理します。
断続的なスパイクを伴うワークロード: あなたの Web サイトは週末に多くのトラフィックがありますが、週中のトラフィックはそれほど多くありません。この Web サイトでは、アクティビティーが爆発的に多くなった後に、非アクティブな期間が続くため、Code Engine が適切なソリューションとなります。 Code Engine を使用すると、Web サイト・アプリケーションは、トラフィックの増加に対応してアプリケーション・インスタンスを自動的にスケール・アップし、非アクティビティー期間に再びスケール・ダウンします (ゼロになることもあります)。
ストレージと統合されたバッチ・ワークロード: 毎月末に従業員の給与を処理するバッチ・ジョブを使用しています。このジョブは月単位で実行されるため、ほとんどの期間はアイドル状態になりますが、実行時には大量の CPU とメモリーを消費します。バッチ・ジョブは、結果を保管するためにストレージと統合する必要があります。 Code Engine を使用すると、バッチ・ジョブを IBM Cloud Object Storage と統合できるため、実行時にジョブが使用するリソースに関してのみ課金されます。ジョブがアイドル状態のときはリソースを消費しないため、料金が発生することはありません。ただし、ジョブにより IBM Cloud Object Storage インスタンスのコストがかかる場合があります。
ワークロードの移動: ジョブには、イメージを作成し、それをデプロイすることが含まれます。コンテナー・イメージの作成やそのデプロイに関しては経験がありますが、他の作業に集中できるようにこのプロセスを単純化したいと考えています。 Code Engine を使用すると、同じインターフェースから直接イメージを作成してデプロイできるので、日常業務を簡略化し、さらに多くのコードを開発する時間を作り出すことができます。
テスト、PoC (概念検証)、または「タイヤキック」: あなたはコンテナー・ベースのアーキテクチャーに関して理解を深めたいと考えています。チームでアプリケーションを開発しましたが、アプリケーションを利害関係者に提示する前にテストする必要があります。このアプリケーションは小規模なので、専用のごく小さなクラスターでも支払いは避けたいと考えています。この場合は、専用クラスターを使用する場合には発生する可能性があるコストをかけずに、アプリケーションをテストし、設計の PoC (概念検証) を利害関係者に提供できます。

アプリケーション、ジョブ、または機能をいつ使用するか

アプリケーションとジョブはよく似ており、結局はどちらもコードを実行します。しかし、コードをアプリまたはジョブのどちらとして構成するかを決定する際には、以下の重要な点を考慮する必要があります。

コードはイベントに応答する必要がありますか?: Code Engine のコンテキストでは、あらゆる着信 HTTP 要求 (Web ページのロード要求を含む) や REST API 呼び出しがイベントと見なされます。イベント・ドリブンの概念は、多くの場合、アプリケーションまたはジョブのいずれかを選択する際の重要な要素です。これは、定義上、呼び出しの結果としてジョブが実行されている間に、HTTP 要求のためにアプリケーションが実行されるためです。; ワークロードで着信 HTTP 要求に応答する場合は、アプリが適しています。他方、ワークロードが実行され、完了するような場合は、ジョブが適しています。
コードはどのようにスケーリングされますか？: アプリもジョブもスケーラブルです。アプリの各インスタンスは一度に特定の数の並行要求しか処理できない可能性があるため、測定可能なリアルタイムの基準 (アクティブな着信要求の数など) に応じてアプリはスケーリングされます。ジョブについては、ジョブが作成されたときに指定されたインスタンス数に基づいてスケーリングされます。; コードの特定の数のインスタンスを実行し、着信 HTTP 要求なしで各インスタンスを実行する場合は、ジョブが適しています。他方、着信 HTTP ロードに基づいてインスタンス数を動的にスケーリングする必要がある場合は、アプリが適しています。

Code Engine の一般的なシナリオ

これらの一般的なシナリオのいくつかを読んで、特定のタイプのワークロードをいつ選択するかを理解してください。

ワークロードが低遅延を必要とするか、または対話式か: クライアントまたはユーザーが要求の応答を同期的に待つ必要があり、数ミリ秒以内に応答を受け取る必要があるようなワークロードの場合は、アプリケーションを使用します。アプリケーションは、外部から到達可能なエンドポイントを提供し、要求に同期的に応答します。そのようなワークロードの例として、Web サイト、チャットボット、モバイル・アプリケーションなどがあります。アプリケーションを使用します。
計算負荷が軽めで、CPU、メモリー、および入出力の要求が低いか: ワークロードが軽量で、CPU、メモリー、および入出力の要求が低い場合は、アプリケーションで使用可能な並行性オプションが役立つ可能性があります。典型的な例として、基本的な操作を提供し、NoSQL データベースによってサポートされる API サーバーがあります。こうしたタイプの要求で使用されるデータ量はたいてい少なく、必要なメモリーや CPU サイクルが少なくて済みます。並行性が高いと、アプリケーションは、2 番目の要求が入出力を待機している間に、最初の要求のデータを処理できます。 CPU とメモリーの所要量が少ないため、多くの要求を並行して実行できます。アプリケーションを使用します。
計算が CPU、メモリー、または入出力に拘束されるか: データの各チャンクが大規模で、大容量の CPU とメモリーが必要な、特定の量のデータを処理する場合、通常はジョブの方が適しています。ただし、要求/応答パターンが必要なワークロードの場合は、アプリを使用することも可能です。どちらのケースでも、計算タスクは単一並行性で実行されます。各アプリケーション・インスタンスまたはジョブ・タスクは、インスタンス用に構成されたリソースを完全に活用するために、1 つの要求またはデータのチャンクのみを同時に処理します。並列処理はインスタンスまたはタスクの数に基づいて実現し、追加タスクの作成コストは、高いリソース制約のために無視できるものとなります。典型的な例として、Object Storage バケット内のイメージ・データの処理や、機械学習モデルのサービス提供があります。アプリケーションまたはジョブを使用します。
計算が長時間実行されるか: 計算が長時間実行される場合、ジョブには非同期特性があるため、ジョブの方が適しています。アプリケーションの場合、接続を大規模に開いておくコストが大きいため、最大所要時間は常に限定されます。典型的なワークロードとして、機械学習モデルのトレーニングやハイパーパラメーターの最適化があります。ジョブを使用します。
計算の並行性を前もって指定できるか: 実行する必要のある計算量が分かる場合、厳密なインスタンス数を指定してジョブを完了するまで実行できます。典型的な例として、ハイパーパラメーターのチューニングやニューラル・ネットワークのトレーニングがあります。ジョブを使用します。
ワークロードで何らかのイベントに対応するか?: リポジトリーへの Git コミットのプッシュ、Object Storage バケットへのオブジェクトのアップロード、データベース内での文書の変更などのイベントに対してワークロードで対応する必要がある場合は、アプリケーションを使用します。アプリケーションでは、イベント・ソースからイベントを受信するように構成できるエンドポイントを利用できます。アプリケーションを使用します。
イベントまたは要求に応じて短時間で大量のデータを処理する必要があるか: 予測できない要求またはイベントに対して高速に対応する必要があるワークロードの場合は、通常、アプリケーションの方が適しています。アプリケーションであれば、動的に (ゼロからでさえ) スケーリングできます。アプリケーションを使用します。
アプリとジョブの組み合わせ: アプリとジョブを組み合わせることもできます。この場合、アプリケーションがジョブを開始して、特定の計算をアウトソーシングすることができます。また、ジョブがアプリケーションに照会することもできます。ジョブとアプリの両方を組み合わせる典型的な例として、機械学習モデルのトレーニングとサービス提供があります。ジョブは通常、モデルのトレーニングのために使用し、アプリケーションはモデルのサービス提供のために使用します。アプリケーションおよびジョブを使用します。