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

Serverless は、新たに登場したサーバーレス アーキテクチャです。これを使用すると、開発者は運用や保守、リソースの配信や展開を気にすることなく、コードに集中するだけで済みます。この記事では、Python アプリケーションを変換して、アプリケーションがサーバーレス アーキテクチャの利点を継承できるようにすることで、コードの観点からサーバーレスを理解できるようにします。

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

遺伝子検査サービス

上記のリソースを使用して、2人の遺伝子サンプルを比較し、比較結果（直接の血縁関係の確率など）を出力します。
ディレクトリ構造は次のように構築します。
。
├── リレーション.py
└── サンプル
├── 1.サンプル
└── 2.サンプル

relationships.py コードは次のとおりです。
インポートシステム
定義関係アルゴリズム(人間のサンプル1、人間のサンプル2):
# それは秘密です
結果を返す
__name__ == “__main__” の場合:
長さ = len(sys.argv)
# sys.argv はリストであり、最初の要素は常にスクリプトの名前になります
長さ!= 3の場合:
sys.stderr.write("2つのサンプルが必要です")
それ以外：
# 最初のサンプルを読む
open(sys.argv[1], “r”) をsample_oneとして実行します:
sample_one_list = sample_one.readlines()
# 2番目のサンプルを読む
open(sys.argv[2], “r”) を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. サーバーレス製品の紹介: UGC

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

AWS Lambda とは異なり、UGC では計算集約型のアルゴリズムを Docker イメージ (以下、「アルゴリズム イメージ」と呼びます) としてカプセル化できます。指定されたアルゴリズム リポジトリにアルゴリズム イメージをプッシュするだけで、UGC がアルゴリズム イメージをいくつかのコンピューティング ノードに事前にプルします。次の 2 つの形式を使用する場合:
• アルゴリズム イメージの名前と、クエリ文字列形式の認証情報 (例: http://api.ugc.service.ucloud.cn?ImageName=relation& AccessToken=!Q@W#E)
• アルゴリズムミラーに必要なデータはHTTPボディの形式で送信されます

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

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

2. サーバーレスアーキテクチャの変革

2つの部分:
1. アルゴリズムのメタデータを「ファイル入力」から「標準入力」に変更し、出力を「標準出力」に変更します。
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 リクエストを構築し、返された結果を読み取ります。
イメージ名 = “cn-bj2.ugchub.service.ucloud.cn/testbucket/relationship:0.1”
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(メンバー)
open('result.txt','a') を resultf として実行します:
文字列 = 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
open(sample_one_dir) を onef として実行します:
one_data = onef.read()
open(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)
プール.map(ワーカー、すべて)

200 個のタスクを同時に送信するのは簡単です。

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

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

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

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

つまり、一連のテストを実行するのにかかる時間は 400 秒だけとなり、7 日間から 400 秒に短縮されます。結果は驚くべきもので、グラフはより直感的になりました。

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

最も重要なことは、変換されたアーキテクチャが、運用とメンテナンスが不要、高可用性、従量課金制、リリースが容易といったサーバーレス アーキテクチャの利点も継承していることです。

メンテナンスは不要です。サーバーが不要になったためです。

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

従量課金制— 記事によると、各アルゴリズムの実行にはコアあたり 2 秒の CPU 時間がかかります。コストを直接計算してみましょう。
2000 * 20 * 2 = 80000 (秒)
80000 / 60 / 60 = 22.22 (時間)
22.22 (時間) * 0.09 (元) * 1 (コア) ~= 2 (元)
1コア時間あたり0.09元（つまり、シングルコアCPU時間1時間あたり9セント）

簡単に公開可能- Docker をキャリアとして使用するため、言語に依存せず、迅速に公開できます。コードが記述されたら、画像をアップロードするだけです。グレースケールの場合、クライアントの imageName は異なるコードを区別するために異なるバージョンを指定します。

サーバーレス製品によって変換方法が異なる場合があります。エンジニアとしては、変換コストが低く柔軟性が高いため、この方法を好みます。どう思いますか？サーバーレス アーキテクチャや UGC に興味がある場合は、WeChat u_nknow を追加して、当社の技術交流グループに参加できます。