Gridアーキテクチャ
Gridは、Gridの維持においてそれぞれ役割を果たすコンポーネントの集合として設計されています。非常に複雑に見えるかもしれませんが、このドキュメントが混乱を解消するのに役立つことを願っています。
主要コンポーネント
Gridの主要なコンポーネントは以下のとおりです。
- イベントバス
- 他のコンポーネント間で非同期的に受信される可能性のあるメッセージを送信するために使用されます。
- 新規セッションキュー
- ディストリビュータによってノードにまだ割り当てられていない、受信セッションのリストを保持します。
- ディストリビュータ
- セッションを実行できるGrid内の利用可能な場所(「スロット」として知られています)のモデルを維持し、受信する新規セッションリクエストを受け取り、それらをスロットに割り当てる役割を担います。
- ノード
- WebDriverセッションを実行します。各セッションはスロットに割り当てられ、各ノードには1つ以上のスロットがあります。
- セッションマップ
- セッションIDとセッションが実行されているノードのアドレス間のマッピングを維持します。
- ルーター
- Gridのフロントエンドとして機能します。これはGridの唯一の、より広いWebに公開される可能性がある部分です(強く推奨はしませんが)。これは、受信リクエストを新規セッションキューまたはセッションが実行されているノードのいずれかにルーティングします。
Gridについて議論する際に、留意すべき他の有用な概念がいくつかあります。
- スロットは、セッションを実行できる場所です。
- 各スロットにはステレオタイプがあります。これは、ディストリビュータがスロットを所有するノードにリクエストを送信する前に、新規セッションセッションリクエストが一致する必要がある最小限のケイパビリティセットです。
- Gridモデルは、ディストリビュータがGridの状態を追跡する方法です。名前が示すように、これは現実と同期していない場合があります(おそらくディストリビュータが起動したばかりであるため)。ディストリビュータが新規セッションリクエストにスロットを迅速に割り当てることができるように、各ノードをクエリするよりも優先して使用されます。
同期および非同期呼び出し
Grid内で使用される主な通信メカニズムは2つあります。
- 同期的な「REST風」JSON over HTTPリクエスト。
- イベントバスに送信される非同期イベント。
どの通信メカニズムを使用するかをどのように選択するのでしょうか?結局のところ、イベントベースの方法でGrid全体をモデル化することもでき、それでも問題なく動作するでしょう。
答えは、実行されているアクションが同期的である場合(例:ほとんどのWebDriver呼び出し)、または応答が欠落すると問題が発生する場合は、Gridは同期呼び出しを使用します。代わりに、関心のある人に情報をブロードキャストしたい場合、または応答が欠落しても問題ない場合は、イベントバスを使用することを優先します。
注目すべき興味深い点の1つは、非同期呼び出しは、同期呼び出しよりもリスナーからより疎結合であるということです。
コンポーネント間の起動シーケンスと依存関係
Gridはコンポーネントが任意の順序で起動できるように設計されていますが、概念的にはコンポーネントが起動する順序は次のとおりです。
- イベントバスとセッションマップが最初に起動します。これらは他の依存関係がなく、互いにさえ依存関係がないため、並行して起動しても安全です。
- セッションキューが次に起動します。
- ディストリビュータを起動できるようになりました。これは、セッションキューに定期的に接続してジョブをポーリングしますが、このポーリングはイベント(新規セッションがキューに追加されたこと)または定期的な間隔のいずれかによって開始される可能性があります。
- ルーターを起動できます。新規セッションリクエストはセッションキューに送信され、ディストリビュータはセッションを実行するスロットを見つけようとします。
- これでノードを起動できます。ノードがGridに登録される方法の詳細については、以下を参照してください。登録が完了すると、Gridはトラフィックを処理する準備が整います。
コンポーネント間の依存関係は、このように図示できます。「✅」は、コンポーネント間に同期的な依存関係があることを示します。
イベントバス | ディストリビュータ | ノード | ルーター | セッションマップ | セッションキュー | |
---|---|---|---|---|---|---|
イベントバス | X | |||||
ディストリビュータ | ✅ | X | ✅ | ✅ | ||
ノード | ✅ | X | ||||
ルーター | ✅ | X | ✅ | |||
セッションマップ | X | |||||
セッションキュー | ✅ | X |
ノード登録
Gridへの新しいノードの登録プロセスは軽量です。
- ノードが起動すると、定期的に「ハートビート」イベントを発行する必要があります。このハートビートには、ノードステータスが含まれています。
- ディストリビュータは、ハートビートイベントをリッスンします。ディストリビュータがハートビートイベントを検出すると、ノードの
/status
エンドポイントをGET
しようとします。Gridがセットアップされるのは、この情報からです。
ディストリビュータは、同じ/status
エンドポイントを使用してノードを定期的にチェックしますが、Grid状態の永続ストアを持たないディストリビュータを再起動でき、(最終的には)最新の状態になり、正しくなるように、ノードは起動後もハートビートイベントを送信し続ける必要があります。
ノードステータスオブジェクト
ノードステータスは、次のフィールドを持つJSON blobです。
名前 | タイプ | 説明 |
---|---|---|
可用性 | 文字列 | up 、draining 、またはdown のいずれかの文字列。重要なのはdraining で、これは新しいセッションをノードに送信すべきではないことを示し、ノード上の最後のセッションが閉じると、ノードは終了または再起動します。 |
externalUrl | 文字列 | Grid内の他のコンポーネントが接続する必要があるURI。 |
lastSessionCreated | 整数 | このノードで最後にセッションが作成されたときのエポックタイムスタンプ。他のすべての条件が同じ場合、ディストリビュータは最も長くアイドル状態になっているノードに新しいセッションを送信しようとします。 |
maxSessionCount | 整数 | セッション数は利用可能なスロット数を数えることで推測できますが、この整数値は、ノードが「満杯」と見なされる前に、ノードで同時に実行されるべきセッションの最大数を決定するために使用されます。 |
nodeId | 文字列 | このノードのインスタンスを識別するために使用されるUUID。 |
osInfo | オブジェクト | arch 、name 、およびversion フィールドを持つオブジェクト。これは、Grid UIおよびGraphQLクエリで使用されます。 |
slots | 配列 | スロットオブジェクトの配列(下記参照) |
version | 文字列 | ノードのバージョン(Seleniumの場合、Seleniumのバージョン番号と一致します) |
すべてのフィールドに値を入力することをお勧めします。
スロットオブジェクト
スロットオブジェクトは、ノード内の単一のスロットを表します。「スロット」は、単一のセッションを実行できる場所です。ノードが同時に実行できるよりも多くのスロットを持っている可能性があります。たとえば、ノードは最大10個のセッションを実行できますが、それらはChrome、Edge、またはFirefoxの任意の組み合わせである可能性があります。この場合、ノードは「最大セッション数」を10として示し、Chrome用に10個、Edge用に10個、Firefox用に10個のスロットがあるとも言います。
名前 | タイプ | 説明 |
---|---|---|
id | 文字列 | スロットを参照するためのUUID |
lastStarted | 文字列 | スロットで最後にセッションが開始された日時(ISO-8601形式) |
stereotype | オブジェクト | このスロットが一致するケイパビリティの最小セット。最小限の例は{"browserName": "firefox"} です。 |
session | オブジェクト | セッションオブジェクト(下記参照) |
セッションオブジェクト
これは、スロット内で実行中のセッションを表します。
名前 | タイプ | 説明 |
---|---|---|
capabilities | オブジェクト | セッションによって提供される実際のケイパビリティ。新規セッションコマンドからの戻り値と一致します。 |
startTime | 文字列 | セッションの開始時間(ISO-8601形式) |
stereotype | オブジェクト | このスロットが一致するケイパビリティの最小セット。最小限の例は{"browserName": "firefox"} です。 |
uri | 文字列 | ノードがセッションとの通信に使用するURI |