背景紹介
OSSのシンプルなインターフェイスと優れたスケーラビリティにより、さまざまなシナリオのアプリケーションで1日あたり数十億から数十億のオブジェクトファイルを簡単に保存できます。単純なキー/値データアクセス構造により、データのアップロードと読み取りが大幅に簡素化されます。ただし、アップロードと読み取りに加えて、OSSを中心に一連の新しいアプリケーションシナリオがすばやく生成されました。
- 大量のOSSファイルコピー（バケット内またはバケット間）、ストレージタイプを変更（標準->アーカイブ）してコストを節約
- 使用するバックアップアーカイブファイルを復元する大規模な同時OSSファイル解凍（復元）
- このイベントは非常に大きなファイルの解凍、GBレベルの圧縮パッケージをトリガーします。100,000を超えるレベルを含むファイルは、アップロード後に新しいOSSパスに自動的に解凍する必要があります
上記の3つのシナリオには、いくつかの共通の課題があります。
- 長い合計処理時間：数億ものOSSファイルの処理OSSへの同時アクセスが多い場合でも、合計時間は数日またはそれ以上です
- 多数のリモート呼び出しが原因で発生する可能性のある例外処理：OSS APIは基本的に単一のファイルで動作するため、数百万から数千万のファイルを処理すると、リモート呼び出しの順序が等しくなります。分散システムでは、これらのリモート呼び出しの失敗を処理する必要があります。
- 状態の永続性：部分的な障害が発生した場合にすべての再処理を減らし、時間の浪費を避けるために、チェックポイントのようなメカニズムが必要です（バッチ処理では、処理された最初の1000万のキーをスキップできます）。
この記事では、上記の3つのシナリオについて、サーバーレスワークフローと関数コンピューティング（FC）に基づくサーバーレスベストプラクティスソリューションを紹介します。
大量のOSSファイルのコピー+アーカイブ
OSSファイルのバックアップは、単純なリストアンドコピーのメインプログラムで問題が発生するように聞こえますが、現実には多くの問題を考慮する必要があります。たとえば、マシンがダウンしているか、メインプログラム中にプロセスが異常終了した場合、どのようにして自動的にリカバリ（自分で高可用性を実現）？リカバリ後に処理されたファイルをすばやく処理する方法（データベースのメンテナンスステータスを自分で書き込む）アクティブプロセスとスタンバイプロセスを調整する方法（自分でサービスディスカバリを実装）レプリケーション時間を短縮する方法（並列呼び出しと管理を自分で実装）インフラストラクチャの保守コストと経済コストおよび信頼性の間でどのように選択するか？何億ものOSSオブジェクトの前では、単純なシングルスレッドのリストアンドコピーのメインプログラムでは、そのようなニーズを確実に満たすことができませんでした。
ユーザーがバケット内に数億個のOSSファイルを持ち、それらを同じリージョンの異なるバケットにコピーする必要があり、標準のストレージタイプをアーカイブストレージに変換する必要があるとします。このoss-batch-copyの例では、ユーザーが提供するインデックスファイル内のすべての関数を順番に呼び出し、OSS CopyObject操作を計算してバックアップを実行するワークフローアプリケーションテンプレートを提供します。インデックスファイルには、処理が必要なOSSオブジェクトメタが含まれています。次に例を示します。
インデックスファイルもOSS百ギガバイトレベルの数百万あり、ページを読むことが必要であるインデックスファイルを使用して範囲を読んで、各ファイルの部分を処理するOSSは、同様の必要がwhile hasMore {}全体のインデックスファイルが最初から最後まで処理されることを保証するために、制御ロジックを。サーバーレスワークフローを使用する実装ロジックは次のとおりです。
-
copy_filesタスクの手順：入力インデックスファイルの位置（オフセット）から入力ファイルの長さを読み取り、そこから処理するファイルを抽出し、FC関数を呼び出してOSS CopyObjectを呼び出します。 -
has_more_files選択ステップ：ファイルのバッチを正常に処理した後、現在のインデックスファイルが条件比較によって処理されたかどうかを判断します。処理された場合、成功したステップを入力します。それ以外の場合は、ループ実行のために次のページ（オフセット、サイズ）をcopy_filesに転送します。 -
start_sub_flow_executionタスクステップ：1つのワークフローの実行には履歴イベントの数に制限があるため、選択ステップも現在のワークフローのイベントIDに基づいて判断されます。現在のイベントの数がしきい値を超えた場合、新しい同一のプロセスがトリガーされます実行、プロセスはサブプロセスの終了後も続行されます。サブプロセスはそのサブプロセスもトリガーする可能性があるため、再帰のレイヤーにより、OSSファイルの数に関係なく、プロセス全体を確実に処理できます。
ワークフローを使用してバッチ処理を実装すると、次のことが保証されます。
- 単一の処理時間は、ほぼすべての長さ、任意の数のファイルにすることができます。ワークフローは、最大1年間の実行をサポートします
- 運用やメンテナンスが不要で、高可用性を実現する必要がない：ワークフローと関数の計算は、高可用性のサーバーレスクラウドサービスです。
- チェックポイントや状態の維持などのロジックを実装する必要はありません。何らかの理由でプロセスが失敗した場合は、最後に成功したオフセットからやり直すことができます。このプロセスでは、データベースやキューを使用する必要はありません。
- 失敗時の再試行構成：指数バックオフの構成は、ほとんどの一時的なリモート呼び出しエラーを処理できます。
OSSファイルの同時並行解凍
この記事では、サーバーレスワークフローとOSSファイルの高同時バッチ解凍に基づいて、多数のOSSアーカイブファイルを効率的かつ確実に解凍するためのソリューションを紹介します。このシナリオには、ファイルのコピーと同様の課題がありますが、その特殊性もあります。
- CopyObjectとは異なり、Restore操作は非同期です。つまり、オブジェクトのステータスは、フリーズが完了したことを確認するためにトリガーされた後にポーリングされる必要があります。
- 単一のオブジェクトの解凍時間は分単位であり、オブジェクトのサイズによって変わる場合があります。これは、解凍が指定された時間内に完了することを保証するために、プロセス全体のより高い並行性を必要とします。
oss-batch-copyと同様のロジックで、この例では、ListObjectsを使用してOSSをバッチで復元します。ここで、解凍の各バッチはサブプロセスです。各プロセスでforeach並列ループステップを使用して、高い同時実行性（最大100の同時実行性）を持つOSSオブジェクトを解凍します。Restoreインターフェースは非同期操作であるため、解凍が完了するまで、各Restore後のオブジェクトの状態をポーリングする必要があります。解凍とポーリングは同じ並行ブランチで行われます。
ワークフロー+関数を使用して、バッチ解凍の特性を計算します。
- 当然のことながら、高い同時実行の解凍をサポートし、全体の時間のかかる作業を短縮します
- ステートフルで信頼性の高いポーリングにより、プロセスの最後にすべてのオブジェクトがフリーズ解除されます
特大のOSSファイルのイベント駆動型解凍
OSSの主な役割は、ファイルの共有ストレージを実行することです。たとえば、一方の当事者が処理されたコンテンツをダウンストリームアプリケーションにアップロードします。複数のファイルをアップロードするには、PutObjectインターフェイスを何度も呼び出す必要があり、エラーが発生する可能性が高く、実装も簡単ではないため、多くのアップストリームサービスは圧縮パッケージを使用して、1回のインターフェイス呼び出しでアップロードを完了します。これによりアップローダーが簡素化されますが、ダウンストリームユーザーは、ファイルの元の構造を確認して使用したいと考えています。ここでの要件は、OSSファイルのアップロードイベントに応じて、圧縮されたパッケージを自動的に解凍し、別のOSSパスに格納することです。現在、コンソールには関数計算をトリガーして解凍を実行する関数がすでに存在しますが、現在の純粋な関数ベースのソリューションにはいくつかの問題があります。
- 1つの関数の実行時間の制限は10分です。GBレベルの圧縮パッケージの場合、または圧縮パッケージに多数の小さなファイルがあるシナリオでは、タイムアウトを実行して解凍に失敗するのは簡単です
- フォールトトレランスが低い：OSS非同期呼び出し関数の計算、関数内のOSSへの瞬時の失敗の可能性があります。関数呼び出しが失敗した場合、FC非同期呼び出しは最大3回再試行します。回数を超えた後、メッセージは破棄され、解凍が失敗します。
- 不十分な柔軟性：複数のユーザーが、通知、テキストメッセージを送信し、解凍後に元の圧縮パッケージを削除する必要があることを提案していますが、これは単一の機能に基づいて実装するのは簡単ではありません。
長い実行とカスタム再試行の問題を解決するために、このサンプルアプリケーションではサーバーレスワークフローオーケストレーション関数の計算を導入しています。OSSイベントトリガー関数が計算された後、ワークフローの実行が開始されます。ワークフローが読み取られ、解凍され、ZIPパッケージのメタデータを介してOSSターゲットパスにアップロードされます。各関数の実行時間が特定のしきい値を超えると、現在のマーカーが返されます。ワークフローは、現在のマーカーがすべてのファイル処理が完了したことを示すかどうかを判断し、完了した場合はプロセスの実行を終了します。それ以外の場合は、現在のマーカーからストリームの解凍を最後まで続行します。
ワークフローの追加により、関数呼び出しの10分の制限がなくなり、状態管理とカスタム再試行が付属しています。GBレベルのサイズであっても、100,000レベルのファイルを含む圧縮パッケージは確実に解凍できます。ワークフローは最長1年間の実行をサポートし、あらゆるサイズのほぼすべてのZIPパッケージもストリーミングにより正常に解凍できます。
ワークフローは、解凍プロセスの柔軟なカスタマイズ機能を提供します。次の図は、解凍後にMNSキューに通知するユーザーを示しています。通知が完了したら、次の手順は、元の圧縮パッケージを削除することです。
テイクアウェイ
OSSの大規模な普及も一連の問題を引き起こしていることがわかりますが、問題を解決する方法は面倒で退屈でエラーが発生しやすいものです。この記事では、バッチファイルバックアップ、大規模な同時解凍、および大規模なZIPファイルのイベント駆動型解凍の3つの一般的なシナリオに基づいた、シンプルで軽量なサーバーレスワークフローと機能計算を紹介します。サーバーレスソリューションは、次の問題を効率的かつ確実に解決します。
- 最長1年間、中断のない実行が可能な長期実行プロセスをサポート
- システムのフェイルオーバーの影響を受けない状態のメンテナンス
- 一時的なエラー耐性を向上させる
- 非常に柔軟なカスタマイズ
大規模なOSSファイルのバッチ処理シナリオは、記事で述べた3つをはるかに超えています。より多くのシナリオと要件を楽しみにしています。また、サーバーレスエコロジー、ワークフロー、関数計算に興味があり、内部釘打ちグループに参加する学生も歓迎します。
