基本アーキテクチャマニュアル

1 基本アーキテクチャ

1. 単一コンテナ版デプロイ

1. 業務システムは、作業データディレクトリ内にドキュメントの要件に従って処理対象のデバイススキャンデータを入力として準備する；

2. 業務システムは HTTP 形式で LCC の Docker イメージが提供するインターフェースを呼び出し、再構築アルゴリズムの実行を起動する：

    例： http://xxx/api {  --入力データフォルダのパスを渡す  --入力構成パラメータを渡す  --結果受信フォルダのパスを渡す }

3. 業務システムは api をポーリングして再構築の実行が終了したかどうかを確認できる；終了後、結果フォルダのパスから結果データを取得する。

4. hookUrl パラメータを通じて【再構築進捗コールバック API】のアドレスを渡すことができる

2. マルチコンテナデプロイアーキテクチャ

Docker コンテナはマルチカードサーバー上で、各コンテナがそれぞれグラフィックスカードを1枚ずつマウントし、複数の LCC 再構築コンテナノードを形成できる。

複数のコンテナノードは2つの管理モードに対応する：

1）独立マルチコンテナ

各コンテナを独立したノードとし、独立した API ポートを提供して、外部の業務システムが自らタスクの管理・スケジューリングを行うことができる。

各コンテナは LCC 再構築の演算ノードとしてのみ機能し、相互に独立している。単一コンテナ版デプロイを複数回繰り返したものと同等である。

2）コンテナクラスタ（シングルノードマルチカード *）

Consul レジストリセンターを通じて、本マシン上の複数のコンテナを1つのクラスタとして管理できる。

デプロイ時には、あるコンテナノードをマスターノードとして指定する必要があり、マスターノードの API を呼び出すことで複数のノード内の再構築タスクを制御する。

同時に、マスターノードはプラットフォーム化された管理インターフェースを提供し、直接グラフィカルな管理を行える（参考：WebUI 試用マニュアル）

* 注

複数のコンテナノードは、同一の /work ディスクディレクトリにアクセスできて初めて、並列に協調して1つの再構築タスクを高速に完了できる（LCC 再構築タスクの過程では、大量のディスク cache ファイルを共有するため）。したがって現バージョンでは、シングルノードマルチカードサーバー上にマルチコンテナクラスタを作成することを推奨する。

3. クラスタタスクスケジューリング戦略

1) 複数のコンテナノードで1つのタスクを並列に完了する

LCC 再構築タスクは比較的時間がかかるが、その中の一部のステップは、分割する方式で複数のコンテナノードに並列で処理させることができ、これによりこのタスクの全体的な完了時間を短縮できる。

* 注

現バージョンのコンテナノードはプリエンプション戦略を採用しており、あるタスクを最速優先で完了させたい場合は、クラスタ内で先に他のタスクを実行しないことを推奨する。こうすることで、タスクが並列を必要とする際に、より多くの利用可能なノードを取得できる。

後続のバージョンでは、より複雑な優先度構成戦略にアップグレードする予定である。

2) 複数のコンテナノードで複数のタスクを並列に完了する

タスク数が比較的多い場合は、各コンテナノードが1つのタスクを処理する方式でスケジューリングすることを推奨する。

こうすることで、同時に実行するタスク数を最大化でき、各コンテナノードが常に稼働状態にあることを保証できる。

* 注

現バージョンのクラスタでは、デフォルトで戦略 1) 複数のコンテナノードで1つのタスクを並列に完了するを採用する

後続のバージョンでは、より複雑な戦略構成パラメータにアップグレードする予定である