新機能
3forgeのAMIスクリプトは、従来のスレッドベース開発の複雑さなしに、並行性と一時停止機能の追加サポートを提供するようになりました。
なぜ重要なのか
マルチスレッディングのパフォーマンス上の利点は、リモートデータソースに接続して大規模なデータセットを処理するアプリケーションにとって重要です。AMIスクリプトの新しい並行性と一時停止機能のサポートは、リモートシステムコールなど即座に返らないコードや、大規模なデータセットを処理するコードを最適化することを目的としています。並行性と一時停止機能により、3forgeはマルチスレッディングのように動作する動作を実装できますが、複雑さとサポートの負担はありません。
スレッディングの説明
コンピュータサイエンスにおいて、スレッドはプロセッサ（CPU）による単一の命令ストリームの処理を表します。シングルスレッドアプリケーションは、単一のストリームで実行される命令の集合です。一部のアプリケーションは処理して素早く終了しますが、ユーザーインターフェイス（UI）のように無期限に実行し続けるアプリケーションもあります。
「マルチスレッディング」という用語は、コンピュータがアプリケーション内で複数の命令ストリームを同時に実行する責任を担う場合に登場します。スレッディングは、ドキュメントを1人で書くのと複数の人で書くのを比較するのに似ています。1人の場合は、更新を調整したり変更をマージしたりする必要はありません。複数の人の場合は、ドキュメントの作成が早くなるかもしれませんが、変更が上書きされるのを防ぐために構成プロセスの調整が必要です。
例：シングルスレッドの取引レポートアプリケーション
Trade Reporterは、30秒ごとに「新規取引」レポートを作成するシングルスレッドのプロセスです：
- 取引データのクエリ （ブロッキングコール）
- 関連するカウンターパーティの参照データのクエリ （ブロッキングコール）
- 両方のデータセットに基づいたレポートファイル（例：CSV）のレンダリング
- メールまたはSFTP経由でのレポートの公開 （ブロッキングコール）
レポートプロセスは単一の命令ストリームの一部として順次実行されます。Trade Reporterは別のサーバーにホストされているReference Data Managerへのブロッキングコールを行います。Reference Data Managerのスレッディングモデルは関係ありません。ただし、それが参照データリクエストをリッスンし、レスポンスを構築して送信することを理解することが重要で、これにはTrade Reporterを遅らせる貴重な時間がかかります。
パフォーマンスの制限
Trade Reporterのシングルスレッドバージョンはしばらくはうまく動作しますが、取引量と参照データ量が大幅に増加するまでの話です。このプロセスは（1）取引データの取得、（2）クライアント参照データの取得のために2つのリモートシステムコールを行う必要があります。企業が3倍のカウンターパーティと取引し、5倍の取引量を生成している場合、これらのコールは時間がかかり、Trade Reporterが30秒以内にレポートを作成する能力が危機に瀕します。
パフォーマンスチューニング：別スレッドで参照データをキャッシュおよびクエリ
参照データは取引データほど頻繁に変化しないことの一因として、参照データをキャッシュするための別スレッドを採用するという決定がなされ、ローカルのMapベースのデータキャッシュから高速クエリで利用できるようにします。このアプローチにより、レポート生成プロセス中のブロッキングが最小化されます。
参照データサーバーへのブロッキングコールがメイン実行ストリームから削除されたため、参照データキャッシュへのコールが即座に返るようになり、Trade Reporterは大幅にスピードアップします。レポートは30秒間隔内で容易に作成できるようになります。
これまでのところは良いですが、前述の複数人でのドキュメント作成の例と同様に、参照データキャッシュの更新は調整されるか、技術用語では「スレッドセーフ」である必要があります。調整がなければ、レポーターは再構築中の空または部分的に満たされたキャッシュに対してクエリを実行することになるかもしれません。セマフォやsynchronizedブロックなどのコーディングメカニズムがこれを助けることができますが、結果のコードはシングルスレッドバリアントと比べて大幅に複雑になります。
非同期3forge開発：あなたはすでに使っています
一時停止可能なコルーチン文による非同期実行は、AMIスクリプトの一部として長年シームレスに組み込まれています。多くの開発者はこれに気づいていなかったかもしれませんが、メールを送信したり1つ以上の大規模なデータベースクエリを実行したりするときにユーザーインターフェイスがフリーズしないことを確かに感謝しています。
コルーチンはスレッディングの複雑さなしに実行を一時停止および再開する能力を提供します。3forgeの実装はasync/awaitパターンに準拠しており、コードが同期設計に似せて書けるようにしながら、スレッドを追加することなく非同期実行を可能にすることを目指しています。したがって、3forgeのステートメントは他の同期コードブロックと同様に宣言されますが、即座の実行の代わりに、実行のために準備されてアクティブスレッドによってキューに入れられます。
一時停止可能なステートメントのスコープ
メソッドに一時停止可能なステートメントが含まれる場合、それは「一時停止可能なフォーミュラ」と見なされます。遅延ステートメントの前のすべてのステートメントはインラインで実行されます。遅延ステートメントとそれに続くコードは後の実行のためにキューに入れられます。「dispatch」ブロックがない場合、遅延ステートメントの境界はメソッドの終わりに決定されます。したがって、2つの遅延ステートメントを持つメソッドは、並行ブロックが使用されない限り順次実行されます。
並行性
並行性により、複数のブロックの一時停止可能なコードを同時に実行できます。例えば、メソッドが3つのデータソースからデータをクエリする必要がある場合、並行アプローチにより、すべてのソースを同時にクエリし、「順番に一つずつ」という順次実行を避けることができます。
並行性と一時停止機能を組み合わせたパフォーマンス向上
3forgeでは、複数の一時停止可能なステートメントを並行コードブロックで並行して実行できます。並行性と一時停止機能のための新しいAMIスクリプティング要素には、並行して実行される一時停止可能なステートメントのセットをラップするconcurrent{}ブロックと、一時停止可能なステートメントブロックを定義するdispatch{}ブロックが含まれます。
並行実行は障害に対して耐久性があります
ディスパッチされたコードブロックは失敗することがあり、適切なエラー処理で分離され、残りの実行ストリームが完了して返ることができます。
一時停止可能なステートメントをいつ使用するか
多くの状況で強力ですが、一時停止可能なステートメントが意味をなさないシナリオもあります。これには、コードブロックが繰り返し実行されるタイトなループ（例：カラムフィルター）のシナリオが含まれます。システムのパフォーマンスのボトルネックを防ぐために、3forgeはSQLステートメントやWeb UIフォーミュラを含むラムダシナリオで一時停止可能なステートメントが実行されることを許可していません。
