サーバーレスアーキテクチャ変革の実践: 遺伝子サンプルの比較

Serverless は、新たに登場したサーバーレスアーキテクチャです。これにより、開発者は操作、リソースの配信、デプロイメントについて心配することなく、コードに集中できるようになります。

この記事では、Python アプリケーションを変換して、アプリケーションがサーバーレスアーキテクチャの利点を継承できるようにすることで、コードの観点からサーバーレスを理解できるようにします。

[[230487]]

既存のリソース:

成熟した遺伝子比較アルゴリズム（Python で実装、1 回の実行に 2 秒かかります）
2020 遺伝子サンプルファイル (各ファイルのサイズは 2 MB で、アルゴリズムの入力として直接使用できます)
8コアのクラウドサーバー

遺伝子検査サービス

上記のリソースを使用して、2人の遺伝子サンプルを比較し、比較結果（直接の血縁関係の確率など）を出力します。

ディレクトリ構造は次のように構築します。

 。
 ├── リレーション.py
 └── サンプル
    ├── 1.サンプル
    └── 2.サンプル

relationships.py コードは次のとおりです。

インポートシステム
 
定義関係アルゴリズム(人間のサンプル1、人間のサンプル2):
    #それは秘密です
結果を返す
 
 __name__ == &quot;__main__&quot; の場合:
    長さ = len(sys.argv)
    # sys.argv はリストであり、最初の要素は常にスクリプトの名前になります 
    長さ!= 3の場合:
        sys.stderr.write(&quot;2 つのサンプルが必要です&quot;)
それ以外：
        #最初のサンプルを読む
と  open (sys.argv[1], &quot;r&quot;)をsample_oneとして開きます:
            sample_one_list = sample_one.readlines()
        # 2番目のサンプルを読む
と  open (sys.argv[2], &quot;r&quot;)をsample_twoとして開きます:
            sample_two_list = sample_two.readlines()
        # アルゴリズムを実行する
        relationship_algirithm(sample_one_list, sample_two_list) を印刷します

使い方は次のとおりです:

 ➜ Python relationship.py ./samples/one.sample ./samples/two.sample
 ➜ 0.054

プロセスは比較的簡単です。遺伝子配列を表す 2 つのファイルがローカルディスクから読み取られ、アルゴリズムが計算された後に結果が返されます。

私たちは以下のビジネス要件を受け取りました

2,000 人が子供を探していて、20 人が父親を探しているとします。

まず、唾液サンプルを採取し、専門機器で分析します。次にサンプルファイルを生成し、ホストにアップロードします。サンプルファイルは全部で2020個あります。 ***上記のアルゴリズムを実行する必要があります

2000 * 20 = 40000（回）

要件を完了するには、費やした合計時間を計算しましょう。

40000 (回) * 2 (秒) = 80000 (秒)
80000 (秒) / 60.0 / 60.0 ≈ 22.2 (時間)

一連の計算を完了するには 22 時間かかり、これは遅すぎます。ただし、マシンには 8 つのコアがあるため、8 つのプロセスを実行して一緒に計算することができます。

22.2 / 8 ≈ 2.76 (時間)

完了するまでに 3 時間かかりますが、それでもまだ遅すぎます。 8 コアの計算能力が限界に達したと仮定した場合、どのように最適化できるでしょうか?

1.1.1 サーバーレス製品の紹介: UGC

UCloud 一般的なコンピューティング

AWS Lambda とは異なり、UGC では計算集約型のアルゴリズムを Docker イメージ (以下、「アルゴリズムイメージ」と呼びます) としてカプセル化できます。指定されたアルゴリズムリポジトリにアルゴリズムイメージをプッシュするだけで、UGC はアルゴリズムイメージをコンピューティングノードの一部に事前にプルします。次の 2 つの形式を使用する場合:

アルゴリズムイメージの名前と、クエリ文字列形式の検証情報 (例: http://api.ugc.service.ucloud.cn?ImageName=relation&Token=!Q@W#E)
アルゴリズムミラーに必要なデータは、HTTP ボディの形式で送信されます。

特別に構築された HTTP リクエストが UGC API サービスに送信されると、「タスクスケジューラ」が、アルゴリズムイメージを正常に取得できたノードを選択し、そのノードへのリクエストをスケジュールするのに役立ちます。次に、アルゴリズムイメージ「コンテナ」を起動し、リクエストの HTTP 本文を標準入力 stdin の形式でコンテナに渡します。アルゴリズムが計算された後、アルゴリズムの標準出力 stdout と標準エラー stderr が tar パッケージにパッケージ化され、HTTP 本文の形式で返されます。このアルゴリズムの実行結果を取得するには、返された本体を tar パッケージとして解凍するだけです。

とはいえ、この製品を使用すると、数万個のコアを備えた小型の 8 コアマシンではなく、数万個のコンピューティングノードに集中的な計算を実行できます。では、このような大量のコンピューティングリソースをどのように使用すればよいのでしょうか?プログラムには少し修正が必要です。

1.1.2 サーバーレスアーキテクチャの変換

2つの部分:

変更されたアルゴリズムのメタデータは「ファイル入力」から「標準入力」に変更され、出力は「標準出力」に変更されました。
HTTPリクエストを構築し、同時実行性を向上させるクライアントを開発する

1. 変換アルゴリズムの入力と出力

① 入力をstdinに変換する

cat ./samples/one.sample ./samples/two.sample | python リレーション.py

これは、コンテンツを relationship.py の stdin にパイプし、次のように relationship.py で取得します。

インポートシステム
 
 mystdin = sys.stdin.read ()関数
# ここで、mystdin には、区切り文字なしの ./samples/one.sample ./samples/two.sample の内容全体が含まれます。実際に分割するには、独自の区切り文字を設定できます。

②アルゴリズムの出力データをstdoutに書き込む

# 標準入力を2つのサンプルに分割する
sample_one、sample_two = 別々の(mystdin) 
 
 # アルゴリズムの出力をSTDOUTに変換する
定義関係アルゴリズム(サンプル1、サンプル2)
    # 変身前
結果を返す
    # 変身後
    sys.stdout.write(結果)

変換が完了しました。それは早いでしょう。

2. クライアントと同時実行

アルゴリズムミラー（タスク実行）のロジックを変更しました。それでは、タスクの送信を見てみましょう。

HTTPリクエストを構築し、返された結果を読み取る

イメージ名 = &quot;cn-bj2.ugchub.service.ucloud.cn/testbucket/relationship:0.1&quot;
 token = tokenManager.getToken() # SDKには既製のものが用意されています
 
 # SummitTask はHTTPリクエストを構築し、イメージのSTDOUTをtarballにパッケージ化して返します。
レスポンス = submitTask(イメージ名、トークン、データ)

非同期リクエストもサポートしています

前述したように、この Serverless 製品はアルゴリズムの標準出力を tarball にパッケージ化し、それを HTTP 本文に入れてクライアントに返すので、次の解凍関数を用意します。

 tarファイルをインポートする
インポートio 
 
 def untar(データ):
    tar = tarfile.open (fileobj=io.BytesIO(データ))
 tar.getmembers()内のメンバーの場合:
        f = tar.extractfile(メンバー)
と  (&#39;result.txt&#39;,&#39;a&#39;) をresultfとして開きます:
            strs = f.read ()文字列
            resultf.write(文字列)

tarballを解凍し、結果をresult.txtファイルに書き込みます。

2200個のサンプルファイルの絶対パスリストはget_sample_listメソッドで取得できると仮定します。

sample_2000_list、sample_20_list = get_sample_list()

2000サンプルと20サンプルの直積を計算するには、itertools.productを直接使用できます。

 itertoolsをインポートする 
すべて= リスト(itertools.product(sample_2000_list, sample_20_list))  
長さ(すべて) == 40000 であるとアサートする

上記のコードスニペットを組み合わせて、メソッドをカプセル化します。

 defワーカー(2つのファイルタプル):
    sample_one_dir、sample_two_dir = two_file_tuple 
 
と  (sample_one_dir)を onefとして開きます:
        one_data = onef.read ()です。
と  (sample_two_dir)を twofとして開きます:
        two_data = twof.read () です
     
    データ = 1 つのデータ + 2 つのデータ
    レスポンス = SummitTask(イメージ名、トークン、データ)
    untar(応答)

HTTP リクエスト送信の構築は計算集約的ではなく I/O 集約的であるため、コルーチンプールを使用して非常に効率的に処理します。

 gevent.pool をインポートする
gevent.monkeyをインポートする
gevent.monkey.patch_all() # モンキーパッチ
 
プール = gevent.pool.Pool(200)
 pool.map(ワーカー、すべて)

タスク200を送信するだけで、同時に実行するのは簡単です

すべての変換が完了したので、簡単に分析してみましょう。

以前は、8 つのプロセスが計算集約型のアルゴリズムを実行していました。現在、私たちは計算集約型のアルゴリズムをサーバーレス製品に組み込んでいます。クライアントは I/O を集中的に行うため、コルーチンを使用して単一のマシンで非常に高い同時実行性を実現できます。欲張らず、200 の同時実行に基づいて計算します。

詳細な読み物:上記の場合、帯域幅がボトルネックになる可能性があります。 gzip を使用して HTTP 本文を圧縮できます。これは計算集約的な操作です。 8 つのコアの計算能力を効率的に活用するために、サンプルデータを 8 つの部分に分割し、8 つのプロセスを開始し、コルーチンを使用してプロセス内でタスクを送信します。

40000 * 2 = 80000 (秒)
80000 / 200 = 400 (秒)

つまり

一連のテストにはわずか 400 秒しかかかりません。これは、前の 7 日間と比べて改善された結果です。結果は驚くべきもので、グラフはより直感的になりました。

さらに、コンピューティング能力のボトルネックにはまだ達していません。同時実行タスクの数を増やすことができます。タスクを送信するマシンをもう 1 台追加すると、時間は 200 秒に短縮され、マシンが 4 台の場合は 100 秒、マシンが 8 台の場合は 50 秒になります...

最も重要なことは、変換されたアーキテクチャがサーバーレスアーキテクチャの利点も継承していることです。

無料の運用とメンテナンス
高可用性
使った分だけ支払う
シンプルな公開

1. サーバーがないので、運用・保守が無料です。

2. 高可用性- サーバーレスサービスは通常、クラウドコンピューティングの強力なインフラストラクチャに依存します。どのモジュールにも単一のポイントはなく、すべてのモジュールは可能な限りクロスアベイラビリティゾーンまたはクロススイッチの災害復旧です。また、今回使用したサービスには、一度同じタスクを送信すると、複数のノードでそのタスクが実行されるという興味深い仕組みがあります。コンピューティングノードに障害が発生した場合でも、他のノードは正常に復帰できます。先に終わった人が先に戻ります。

3. 従量課金制 - 記事によると、各アルゴリズムの実行にはコアごとに 2 秒の CPU 時間がかかります。コストを直接計算してみましょう。