IBM Cloud Code Engineのサーバーレス機能を活用して1000コアでPythonコードを実行する方法

次世代のサーバーレス・プラットフォーム IBM Cloud Code Engine と Lithops の統合により、これまでにない柔軟性が利用できます

オブジェクト・ストレージ・データ（事前）処理、ハイパー・パラメーター最適化、ログの検索と処理、モンテカルロ・シミュレーションやゲノム解析などの重いタスク、大量のデータのダウンロード、Webスクレイピング、モデル・スコアリングなどは、CPU、メモリ、ネットワーク負荷に高い処理能力が求められるほんの一例です。

これをプログラムで処理するための一般的なアプローチとしては、単に “for “ループを実行し、そのループ内で非同期処理をキック・オフすることがあげられるでしょう。Pythonの一般的なアプローチとしては、multiprocessing.Poolや concurrent.futuresを使用することがあげられます。ここでは、実行される関数を1つのパラメータとして、処理される（多数の）オブジェクトのリストをパラメーターとして、マップ処理が呼び出されます。以下では、説明を簡単にするために前者のmultiprocessing.Poolに焦点を当てていますが、concurrent.futuresにも同様のアプローチがあります。

以下に、これがどのように動作するかの概念的な例を示します。マップ操作は2つのパラメータを受け取ります:

このアプローチの優れた点は、完全にサーバーレスであることです。これを使用するためには、開発者は n 回実行される操作と、処理してもらいたい n 個のオブジェクトを渡すだけです。しかし、これらのライブラリーのオリジナル・バージョンでは、Pythonプロセスが実行されている(仮想)マシンで利用可能なCPUコア、メモリー、ネットワーク帯域幅などを利用することしかできないという制限があります。

n 個のオブジェクトをパラメータとして Pool.map を呼び出すたびに、裏で n 個のコンテナが起動されるといいですよね。コンテナのそれぞれが作業の一部を処理し、作業が完了すると自動的に消滅します。これはまた、よく議論されるクラウドの開発者への関連性がどのようにして実現されるかをうまく示しています。開発者はコードを書くだけで、コードを実行する際には、数百、数千のCPUコアが陰でユーザーが気づくことなくプロビジョニングされ、また終了します：

Lithops と IBM Cloud Code Engine の統合

この基本的なアプローチは、オープンソースの Lithops(英語)プロジェクトにクライアント・サイド・ライブラリーとして実装されています。

Lithops と IBM Cloud Code Engine  (IBMの次世代サーバーレス・プラットフォーム）を統合することで、これまでにない柔軟性を実現しています。他にもいくつかありますが、Code Engine では、バックエンドで多数の並列コンテナを割り当てることができます。それぞれのコンテナは数秒でプロビジョニングでき、最大 32 GBのメモリー、8つのCPUコア、最大実行時間は 2 時間です（これらはすべてのユーザーがすぐに入手できるデフォルト値で、ユーザーごとにさらに上げることができます）。

既存のPythonプログラムにLithopsを適用するために必要なコード変更は非常に最小限で済みます。理想的なケースでは、文字通り、いわゆる「ドロップ・イン・ライブラリー」のアプローチに従うだけです  –   例: rultiprocessing.Poolからlithops.multiprocessing.Pool. へのインポート文の変更。

初期設定の指示も非常に最小限に抑えられています。(参照:  公開文書(英語) )

さらに、Lithops では、概念的には無制限のリソース・プールにまたがって純粋な並列化を行い、最後にr educe/aggregation ステップを適用することができます。これは、単純に3番目のパラメーターとして reduce 関数を渡すだけで実現できます – 例: map_reduce(business_logic, <list_of_data_elements, reduce_operation)

価格の変更はありません – 100秒で10コアであろうと、100秒で100コアであろうと、価格に違いはありません。もちろん、問題の性質によっては、作業を分散させるためのオーバーヘッドが一定の割合で発生しますので、これは考慮に入れる必要があります。

もう一つの利点は、Pythonプログラム内で最も負荷のかかる処理に基づいてリソースを割り当てなければならない代わりに、より長いPythonプログラム内の個々のマップ操作が正確に必要なリソースを動的に割り当てられることです。これにより、大幅なコスト削減とともに、パフォーマンスを大幅に向上させることができます（下図参照）:

このアプローチは、データ・サイエンティストが、画面の前にいる間に重い処理が終わるのを期待するような時など、データ・サイエンスやその他のインタラクティブなシチュエーションで活用することができます　(例:  Watson Studio か何か、エディター機能を使って Python を使ったり、Jupyter notebook を使ったりなど)。また、Python で書かれたバックエンド・アプリケーションを継続的に実行する場合にも適用できます (または、基本的には、いくつかの重い作業を行う必要がある Python コードの他の部分にも適用できます)。

上の図で示されているように、開発者の視点から見ると、これは1台のコンピュータ上で実行されている 1 つのプログラムのように見えます。実際には、非常に多くの分散されたリソースが動的に割り当てられています。このように、クラウドを VM、コンテナ、Web サーバー、アプリケーション・サーバー、データベース・サーバーの集合体ではなく、それ自体が単一のコンピューターとして扱うという、サーバレス・スーパーコンピューターのビジョンに向けて一歩前進しています。

さあ、IBM Code Engineを使ってみましょう

いかがでしたでしょうか。この機会にぜひ、こちらの文書にある手順に従って、 IBM Cloud Code Engine のご利用をご検討ください。