Selenium 4 の新機能
カテゴリ
シリーズの 4 回目にして最終回となる投稿で、サイモン・スチュワートは Selenium 4 の今後の展望について引き続き語り、Selenium Grid の新機能についてレビューします。
過去数回のブログ投稿では、プロジェクトへの貢献方法や、Selenium ユーザーとして期待できる詳細など、多くの内容を取り上げてきました。しかし、Selenium には、テストを書くために使用する API だけでなく、まだ取り上げていない大きな機能の 1 つである、刷新された Selenium Grid (マシンのフリート全体にテストを分散させるメカニズム) があります。
さらに進む前に、常にどこから来たのかを認識することは素晴らしいことです。興味深いだけでなく、刷新された設計の「理由」を説明するのに役立つからです。
遠い昔 (2008 年) に、ジェニファー・ベビンとジェイソン・ハギンズは、Google で Selenium Farm と呼ばれるシステムに取り組みました。これは、元の Selenium プロトコルを実行できる、どこかの戸棚に置かれたマシンのフリートでした。もちろん、これは Google スケールだったので、戸棚は 1 つ以上ありました :)
これにより、Google の人々はテストを分散し、個々のマシンを超えてスケールアウトすることができました。これは非常に素晴らしいアイデアだったので、ジェニファーが Selenium ミートアップで Farm について話したとき、フィリップ・ハリングー (当時 ThoughtWorks に所属) は、同じもののオープンソース実装を書くことに決め、「Selenium Grid」と名付けました。
Selenium Grid は素晴らしいテクノロジーでしたが、1 つ欠点がありました。それは、元の Selenium RC プロトコルしか話せなかったことです。それはそれで良かったのですが、WebDriver は JSON Wire Protocol と呼ばれる別のワイヤプロトコルを話し、人々は Selenium RC と WebDriver の両方を同時に使用したいと考えていました。
ここでフランソワ・レイノーが登場します。彼は eBay で働き、マイケル・パロタスに報告しており、元の Selenium Grid のようなものを書いていましたが、JSON Wire Protocol でも動作しました。彼らは非常に親切にもその作業を Selenium プロジェクトに寄贈し、それが Selenium Grid 2 の基礎となりました。当時、Selenium スタンドアロンサーバーは事実上「1 つのグリッド」になることを決定しました。Selenium Grid をセットアップするために必要なものすべてと、単一のスタンドアロンサーバーとして動作するために必要なものがすべて含まれます。コードをマージして安定させるには時間がかかりましたが、フランソワ、クリスティアン・ローゼンボルド、その他多くの人々の努力のおかげで、Grid 2 をメインの Selenium プロジェクトにマージし、2011 年に Selenium 2 をリリースしました。
2011 年はそれほど昔に感じられないかもしれませんが、現代の世界は大きく変化しました。2011 年には、Docker はありませんでした。Kubernetes もありませんでしたし、AWS も実際にはありませんでした。そのため、Selenium Grid は、これらのものが登場することを知らず、それらを活用するように書かれていませんでした。幸いなことに、当時は仮想マシンがあり、Grid 2 はそれらをサポートできるように設計されていました。
これは、Zalenium と呼ばれる優れたプロジェクトのきっかけとなりました。ディエゴ・モリーナによって開発された Zalenium は、非常に優れた UI と Docker および Kubernetes のサポートを追加しました。これらはすべて Grid 2 の上に構築されています。これにより、Selenium Grid は今日まで関連性と有用性を維持することができ、これは驚くべき成果です。
しかし、私が言ったように、Grid 2 を安定させるには時間がかかりました。クリスティアンが主導して約 6 か月のハードワークでした。それは、Grid 2 は洗練されていましたが、コードは読みにくく、保守が難しく、それを実行できる人はごくわずかだったからです。さらに悪いことに、Grid 2 と元の Selenium サーバーのマージは非常に粗雑でした。事実上、2 つの別々のサーバーが同じバイナリで出荷されていました。これにより、Grid で発生するがスタンドアロンモードで実行すると発生しない問題や、その逆の問題が発生しました。
Selenium 4 では、これらの 3 つの懸念事項に対処することにしました。第一に、より簡単に作業および保守できるものを求めています。第二に、サーバーを単一のユニットにマージしたいと考えています。第三に、Docker や Kubernetes の形だけでなく、分散トレースなどの新しいテクノロジーも利用できるように、現在利用できる最新のインフラストラクチャの世界を活用できるものを求めています。
これを行うために、Grid が提供する機能を見て、各ピースを「インメモリ」で実行できるコンポーネント (単一のスタンドアロンサーバーを持つことができます) またはより分散された方法で実行できるコンポーネントとしてモデル化し、元の Selenium Grid からおなじみの「ハブとノード」アーキテクチャから、完全に分散された設計までを可能にしました。
最初のコンポーネントは「ルーター」です。これは Grid へのエントリポイントとして機能します。インターネットに公開して、リクエストを Grid に転送できます。ステートレスになるように設計されているため、必要に応じて Grid を追加できます。
ルーターが新しいセッションリクエストを検出すると、「セッションキュー」に配置します。セッションキューは、「ディストリビューター」と呼ばれるコンポーネントによって読み取られます。ディストリビューターは、セッションを実行できる Grid 内のすべての場所のモデルを維持します。これらを「スロット」と呼びます。スロットは「ノード」と呼ばれるコンポーネントによってホストされ、各ノードは 1 つ以上のスロットを持つことができます。ディストリビューターがキューから新しいセッションリクエストをプルすると、使用するのに最適なスロットを特定し、スロットを所有するノードにリクエストを転送します。ノードがセッションを開始すると、ディストリビューターはセッション ID とテストを実行しているノードの URL を「セッションマップ」に配置します。セッションマップは、セッション ID から URL への単純なマップであると考えることができます。新しいセッション応答は、待機中のテストに送り返されます。
実行中のセッションのリクエスト (つまり、ほとんどの webdriver 呼び出しのリクエスト) は、わずかに異なる方法で処理されます。ルーターはセッションマップを使用して、リクエストを転送するノードを検索し、ディストリビューターを完全に関与させる必要性を回避します。これは、Grid にノードを追加し続けるだけでよく、リクエストを遅くするアーキテクチャのボトルネックが少ないことを意味します。
概念的には、Grid 内にはこれら 5 つの可動部分があります。しかし、実際には 6 つ目の部分があり、それはメッセージバスです。5 つの Grid コンポーネントはメッセージバスを介して内部的に通信しますが、Grid について考えるときに考える必要がある実際のコンポーネントは、ルーター、セッションキュー、ディストリビューター、およびノードです。
Selenium Grid 4 を「スタンドアロン」モードで実行すると、実際には「1 つのグリッド」が得られます。これらのコンポーネントをすべて単一のプロセスに配線しますが、すべてそこにあります。
Selenium Grid 2 で見た従来のハブアンドノードアプローチで実行することもできます。ハブとノードを起動して登録します。最近 Selenium Grid を使用したことがある場合は、おそらくそれがおなじみのアーキテクチャでしょう。この場合、ほとんどのコンポーネント (ルーター、セッションキュー、ディストリビューター) はハブで実行され、ノードはセッション自体を実行します。
Grid 4 の新機能は、必要に応じて完全に分散モードに移行できることです。通常、これには Kubernetes のようなものを使用することをお勧めします。一部の主要コンポーネントは、信頼性とスケーラビリティを向上させるために、データベースまたは Redis を使用してデータを保存するように設計されています。
注意すべきことは、分散 Grid を実行している場合、特に問題が発生した場合に、何が起こっているのかを把握するのが非常に難しくなるということです。その問題を軽減するために、Open Telemetry を採用して、Grid に可観測性をもたらしました。可観測性とはどういう意味でしょうか？ それは単に、起こるすべてのことを見ることができるようにしたいということです。
最後に、実行中の Grid に関する情報を有意義かつ有用な方法で公開したいと考えています。元の Grid は、JMX (Java 管理 API) と HTML ベースのコンソールの両方をサポートしていました。これは素晴らしいことでしたが、UI で表面化されていない Grid の特定の領域 (たとえば、利用可能なスロット数や、特定のセッションが実行されているノードを見つけるなど) についてクエリを実行するのは簡単ではありませんでした。より柔軟性を提供するために、Grid 用の GraphQL エンドポイントを提供することにしました。GraphQL エンドポイントが十分に柔軟であることを保証するために、新しい Grid コンソールをそれを使用して構築しています。これにより、監視のニーズに合わせて、Grid から有用なメトリックと情報を抽出することもできます。
これらは、新しい Selenium Grid のハイライトの一部です。最も興奮していることは何ですか？
これはもともと https://saucelabs.com/blog/whats-coming-in-selenium-4-the-new-selenium-grid に投稿されました
