みなさんこんにちは！ 私はAvitoで働いており、テストツールを開発しています。 多くのUIテストを取得したとき、Seleniumサーバーのスケーリングの問題に直面しました。次に、それをどのように解決したかを説明します。

それでは、Selenium Gridを使用して多くのUIテストをどのように並行して実行するのでしょうか？ 残念ながら、何もありません。

Selenium Gridは、多数のタスクを並行して実行することはできません。

本当に多数のノードを登録したいですか？ まあ、それを試してください。

スピードが欲しいですか？ グリッドに登録されているノードが多いほど、各テストの安定性は低下します。 その結果、再起動します。

グリッドが応答しなくなった場合のフォールトトレランスが必要ですか？ また、複数のレプリカを起動して、それらの前にバランサーを配置することもできません。

ダウンタイムなしでグリッドを更新し、現在実行中のテストが失敗しないようにしますか？ いいえ、これはSelenium Gridに関するものではありません。

何千もの異なる構成のSeleniumをメモリに保持するのではなく、それらをオンデマンドで増やしたいですか？ 動作しません。

これらすべての問題を解決する方法を知りたいですか？ 次に、この記事を読むことを勧めます。

* （同じ名前の私の報告は、 Heisenbug 2017 Moscowで既に聞かれており、おそらく一部の読者はそれに精通しているでしょう。

Seleniumサーバーの動作に関する小さな余談。

• ブラウザーの管理を開始するには、 create session
  
  
  
  要求をSeleniumサーバーに送信する必要があります。
• その結果、ノードでブラウザーが開き、 sessionId
  
  
  
  トークンが返され、各リクエストでsessionId
  
  
  
  がブラウザーを制御します。

さて、なぜSelenium Gridが必要なのですか？ Selenium Gridは、さまざまな構成の多くのSeleniumサーバーで作業するための単一のポイントを提供します。

• たとえば、ブラウザのバージョンに応じて、フィルタリング基準に一致する無料のノードでセッションを作成できます。
• どのセッションがどのノードで開かれているかに関する情報を保存し、すべてのリクエストをターゲットノードにプロキシします。そのため、クライアントが1つのノードまたはグリッドで作業しても違いはありません。

素晴らしいツールですよね？

しかし、それを使用するときに、いくつかの問題が発生しました。

1.予測できない動作

要するに、あなたは彼が望んでいるものと彼が望んでいるときに落ちるでしょう、そしてあなたはそれをいかなる方法でも影響することはできません。

• テストが1つのスレッドで完全に機能する状況に非常によく直面しましたが、グリッドを介したマルチスレッドの実行では、予期しないクラッシュが発生しました。
  
  
• 時々、テストは単にノードの一部に該当しませんでしたが、物理的には使用できましたが、テストのキューはグリッドに蓄積されました。 その結果、リリーススイートの半分がタイムアウトによって落ちました。
  
  

2.多数のノードのサポートの欠如

多くのノードを登録しようとすると（そして多くのノードが必要になります）、登録は行われますが、多くのテストは失敗するため、多くのスレッドでアプリケーションのテストは失敗します。

3.スケーラビリティ

セレングリッドのノードの制限= Nに達したときに最初に頭に浮かぶのは、安定性が損なわれない場合、2、3、5、（少なくとも10）グリッドを取り、それぞれにNノードを登録し、このすべての前に編みます親切にバランサーを実行し、10 * Nスレッドでテストを実行します。 ただし、Selenium Gridはそのようには機能しません。 ノードとセッションに関するすべての情報は特定のノードのメモリに保存され、それらの間で収集されないためです。 次の問題はこれと密接に関連しています。

4.耐障害性

ハブが配置されているマシンの電源を切ると、すべてのテストがすぐに終了します。これは、次のリクエストが送信できるバックアップハブがないためです。 そして、これは絶対にスケールしません（もちろん、いつでもいくつかのグリッドクラスを書き換えることができますが、それについては後で詳しく説明します）。 弱点はSelenium Hubであり、落ちた場合、ノードにアクセスできなくなります。

5.コンテナオーケストレーションシステムを使用してノードを動的に作成できない

テストのために、異なるブラウザー構成のノードの多くの異なる構成が必要な場合、別の問題が発生します。この動物園全体が非常に多くのメモリ空間を占有します。 Google Chrome（150GB RAM）を搭載した300ノード+ Firefox（150GB RAM）を搭載した300ノードと、マジックプラグインを搭載したFirefox Nightly（100GB RAM）を搭載した300ノードを用意したとします。 400GBのRAMは常にビジーです。さらに、1つのスイートをテストするときに700クロームで400GBをすべて使用し、他のニーズのテストがキューに表示されるときに柔軟に交換するなど、1日を通してノードを効果的に再配布します。

Dockerは、この問題を解決するのに理想的です。これは、テストを完了した後、新しいSeleniumでコンテナをすばやく持ち上げて、すぐに終了できるためです。 また、多くのセレンが必要なため、これらはすべて1つのアイロンサーバーに収まらないため、クラスター上でコンテナーオーケストレーションが必要になります。 このタスクには、市場にいくつかの一般的なソリューションがあります。Kubernetesを使用します。 Kubernetesを選んだ理由は、 こちらで確認できます 。 Seleniumの標準的な方法では、この問題を解決できません。

6.ダウンタイムなしでグリッドを更新/再起動することは不可能です

セッションをメモリに保存する別の結果。 それは超臨界マイナスではありませんが、それでも不快です。

上記のすべては、私たちがいつか自分自身を見つける状況です。

既知のソリューション

グリッドルーターと新しいGoグリッドルーターの実装は優れたソリューションですが、残念ながら理想からはほど遠いものです。 この機能の主な問題は、 Selenium Hubの代わりではなく、上からの別のプロキシであることです。

したがって、グリッドルーターという名前は、グリッドではなくグリッドを管理するため、デメリットがあります。

• 新しいセッションを作成しようとする試みは、空きノードのあるグリッドではなく、ランダムなノードで発生します（重みを使用してランダム変数の分布を制御できます）。 グリッドの1つでセッションを作成できなかった場合、要求は次のものに進み、グリッドがなくなるまで続きます。 したがって、新しいセッションを作成する時間を大幅に遅らせることができます。
• セレンのハブの1つが落ちた場合、セッションに関するすべての情報が失われ、ノードはネットワークから切断されます。 これまでのすべての対話はハブを経由し、セッションデータはハブに保存されます。
• ハブ上のデータはxmlファイルに保存され、オペレーティングシステムの信号に従ってファイルとの同期が行われるため、システムに別のハブを追加することは非常に困難です。 取引はありません、すべてが悪いです。

Selenoidは、Dockerコンテナでテストを実行するためのツールです。 セッションを作成するリクエストごとに、新しいコンテナが起動され、セッションが閉じられると削除されます。 ツールは素晴らしいですが、欠点があります：

• オーケストレーションシステムをサポートしていません。
• セッション情報をメモリに保存するため、スケーリングとフォールトトレランスに問題があります。

これらすべての問題に直面したとき、私たちは他の会社の経験に興味を持つことにしました。 Yandex は Habrahabrブログで、多くのノードを登録して操作することは不可能であり、この問題を解決するためにグリッドルーターを使用していると書いています。 グリッドルーターは、タスクに適していません。

Alfa-Bank は 、グリッドがしばらく使用されないとすべてがハングすることを書いており、私たちの経験はこれを確認しています-私たちは定期的に同じことをしていました。

もちろん、いくつかの問題を発見したgithubのセレンを無視しませんでした...ここに、何が起こっているのかに対する著者の態度の例を示します。

Q：「セレングリッドバージョン3.0+はハブの高可用性をサポートしますか？」

A：「ハブを監視する別のサーバーを用意することをお勧めします。ハブがダウンまたはダウンした場合、ハブを復元する方法がわかります。」

私たちは望みがないことに気づき、自分で問題を解決し始めました。

リサーチ

単純なパスから開始し、多数のセレンをkubernetesクラスターに展開し、データベースにIPを入れて、データベースsetUp()



テストのsetUp()



直接移動し、最も長く使用されなかったIPからsessionId



を保存せずにテストを開始することにしsessionId



。 <seleniumワーカーがテストを行っていたため、オーバーフローは発生しませんでした。

この決定はすぐにその実行可能性を示しました。

私達は受け取った：

• 予測可能な動作;
• データベースレベルでのフォールトトレランス。
• 拡張性
• 多数のノードのサポート。
• テストを停止せずにアップグレードします。これは、コードがリポジトリにあり、テストの実行時に実行されるためです。

しかし、多くの問題に直面しました：

• 機能選択メカニズムのサポートなし。
• 便利なメカニズム/グリッド/レジスタはありません。
• 移植性がない-システムはサービスとして機能しなくなり、1つのプログラミング言語に依存し、同じテストリポジトリに実装されます。

最後の問題は最も重要です。テストフレームワークのコードにそれを縫い付けると、使用するすべての言語のすべてのリポジトリで、各テストフレームワークでこれを自動的にサポートする必要があるためです。

この実験で最も重要なことは、得られた経験です。 Selenium Gridが正常に実装できることを確認しました。

最終決定

まず第一に、私たちはセレンのフォーク/プルリクエストでアイデアを検討し始めました。 しかし、プロジェクトコードを詳しく知った後、自転車を書く方が安価で信頼性が高いことに気付きました。

新しいツールに必要なものをもう一度リストします。

• 行動の予測可能性;
• 耐障害性;
• 拡張性
• 携帯性
• 多数のノードのサポート。
• 機能サポート
• Kubernetesのオンデマンドノード。
• statsdでメトリックを収集します。
• メカニズム/グリッド/レジスタ;
• テストを停止せずにアップグレードします。

最終的に起こったこと：

• 上記の問題をすべて解決するアプリケーション。
• Linuxおよびmacosでテストされたクロスプラットフォームアプリケーション。
• Goで書かれた;
• mysqlにデータを保存します。

その結果、すべての問題を解決することができました。 アプリケーションは Goで作成されました。 ステートレスアプリケーション自体-セッションはmysqlに格納されます。必要に応じて、他のデータベースをサポートすることは難しくありません。 コンテナのオンデマンド作成はKubernrtesでのみ実装されますが、他のシステムでコンテナ作成/削除メソッドを実装してプルリクエストを送信できます。 Goはさまざまなプラットフォーム用にコンパイルされていますが、Linuxとmacosでのみパフォーマンスをテストするのに十分でした。他のシステムの理論では問題はないはずです。

次に主な質問です。 このツールへの移行中に何行のテストコードを書き換える必要がありましたか？ 誰が10000/1000/100を信じますか？ ゼロ！ 何も書き換える必要はありませんでした;完全に互換性があります。 アプリケーションをデプロイし、そのアドレスを指定するだけで、それで終わりです。 他に何もする必要はありません。

結果は次のスキームです。

使い方は？ 2つのモードがあります。

• 永続 -すべてが以前と同じで、 -role node
  
  
  
  パラメーターを使用してseleniumサーバーを起動し、ハブアドレスの場所、ノードが登録されていることを指定します。

java -jar selenium-server.jar -role node -hub http://127.0.0.1:4444/grid/register

• オンデマンド -Dockerイメージと、グリッド構成で実装する機能に関する情報を追加する必要があります。 次に、グリッドを実行し、セッションを要求すると、ノード自体がクラスター内に作成されます。

 ... "type": "kubernetes", "limit": 20, "node_list": [ { "params": { "image":"myimage:latest", "port": "5555" }, "capabilities_list": [ { "browserName": "firefox", "browserVersion": 50 ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめ

かなり長い間、このソリューションを実稼働環境で使用してきましたが、機能し、サポートは必要ありません。 その過程で、自転車を作ることを恐れてはならないともう一度確信しました。 一般的なソリューションは常に良いとは限りません。常に問題を解決する可能性を探るべきです。