Gleanでのランキングコードの段階的なデプロイ

0
読了時間
Gleanでのランキングコードの段階的なデプロイ
Glean Icon - Circular - White
GleanによるAIサマリー
  • Glean、インデックスサーバーを再起動せずに新しいコードバージョンを動的にロードするメカニズムを実装しました。これにより、より頻繁に、中断の少ないリリースが可能になりました。
  • カスタム ClassLoader とリマッピングツールを使用して Cloud Storage から複数のバージョンのコードを動的に読み込むことで、実験と強力なバージョン管理が容易になりました。
  • このアプローチにより、段階的なデプロイの高速化、サーバーの再起動時間の短縮、Glean サービスの反復処理の柔軟性の向上が実現しました。

Glean 検索では、常に最も関連性の高い結果を返すように努めています。SlackのスレッドからJiraのバグ、O365ドキュメントまで、さまざまなソースからの結果を統合する場合、ランキング機能を試すべき側面はたくさんあります。

これらの機能の構築を支援するために、ランキングチームには頻繁に繰り返しリリースしてもらいたいと考えていました。しかし、ステートフルサービスのコンテキストでは、迅速なターンアラウンドは難しい場合があります。特に、メインのインデックスサーバーは、再起動時に大量のインデックスデータをメモリにプリロードする必要があります。多くの場合、このデータのプリロードには15分以上かかることがあり、これには定期的なサービスダウンタイムまたはある程度の緩和策が必要でした。

実際には、この制約により、顧客向けアップデートを思ったほど頻繁に展開していなかったことがわかりました。また、当社のエンジニアは、サーバーの再起動時間が長くなると、開発サイクルが不必要に遅くなっていることに気付きました。

どのようにしてこの問題を解決し、より迅速な段階的導入に移行したのでしょうか?

  • よくあるケースでコード更新を受け取るためにインデックスサーバーを再起動しなくても済むなら、問題の大部分は解決されることに気付きました。
  • 幸い、この特定のサーバーは Java で作成されており、コードを動的にロードするメカニズムを備えています。カスタム ClassLoader を検討した結果、Cloud Storage から Java JAR アーカイブを読み込んで、再起動せずにそのプロセスでクラスを使用するプロトタイプを作成しました。
  • 再起動せずに Cloud Storage からコードを読み込むことができても、Java では特定のクラス名に対して 1 つの実装しかできません。そうは言っても、クラスのパッケージ名にリリースタグを追加できることに気付きました。たとえば、クラスでは com.glean.ranking.Terminfo 名前に release タグを書き換えるツールを作成すれば、サーバーにいくつでもバージョンをロードできます。 com.glean.ranking.release123.terminfo、com.glean.ranking.release124.Terminfoなど。この再マッピングツールを構築するために、いくつかのオープンソースライブラリ(ObjectWeb ASMなど)を使用しました。最終的に、指定されたリリースタグのビルドアーティファクトを再マップし、数秒でクラウドにアップロードするスクリプトができました。
  • Cloud Storage から複数のバージョンのコードを動的に読み込むことができるため、これらのリリースタグをシステム全体に渡して、特定のクエリに正しいリリースまたはテストが使用されるようにする必要がありました。

すぐにこのアプローチの利点がわかりました。

  • より頻繁に、中断の少ないリリース:サーバーを再起動する必要がなくなったため、ランキングの変更をより頻繁に (社内展開では毎晩、顧客向けには毎週) 展開し始めました。
  • 実験:このメカニズムを開発者の実験にも使用し始めました。開発クラスターの使用を調整してサーバーの再起動を待つ代わりに、開発者は Jar ファイルをアップロードするだけで結果をすばやく確認できました。
  • 強力なバージョン管理:エラーは特定のリリースタグに関連している可能性があり、さまざまな実験が互いに分離されていました。
  • ロールバックサポート:問題のあるリリースのロールバックは、オンラインでの設定変更ですぐに行うことができます。

どのような実装でもそうであるように、このメカニズムをうまく機能させるためにはある程度のチューニングが必要でした。例えば:

  • どのパッケージセットを再マップするかを決める (初期バージョンでは一部の protobuf パッケージがリマップされていなかったが、これは間違いだったことにすぐに気付きました!)
  • Jar ファイルスキャンの重複を避けるための適切なキャッシュ/ロード
  • 同じクラスの並列フェッチの抑制

特定のリリースタグを最初に使用すると、Cloud Storage の取得と Jar デコードのオーバーヘッドを考慮すると、約 1 秒の遅延が発生しますが、それ以降の使用はキャッシュされ、通常の実装と区別がつかないことがわかりました。そのため、本番リリースでは、通常、構成を切り替える前にウォームアップリクエストを送信します。

とはいえ、ステートフルサービスを再起動せずに新しいリリースや実験を動的に読み込むことができるため、Glean サービスの改善をある程度柔軟に繰り返すことができます。

もし 建物 または を使用します クラス最高の検索製品があなたにとって興味深そうですね。連絡してください!

Work AI for All.

デモに申し込む
CTA BG