特定のジョブクラスの処理

ほとんどのGitLabインスタンスは、すべてのキューをリッスンするすべてのプロセスを持つ必要があります。

別の方法として、ルーティングルールを使用して、アプリケーション内の特定のジョブクラスを設定済みのキュー名に転送することができます。そうすると、Sidekiqプロセスは設定済みの少数のキューのみをリッスンすればよくなります。そうすることで、Redisへの負荷が軽減され、これは大規模なデプロイにおいて重要です。

ルーティングルール

ほとんどのGitLabインスタンスでは、Sidekiqキューを管理するためにルーティングルールを使用することをお勧めします。これにより、管理者は、ジョブクラスのグループの属性に基づいて単一のキュー名を選択できます。この構文は、[query, queue]のペアの順序付き配列です:

1. このクエリはワーカーマッチングクエリです。
2. キュー名は有効なSidekiqキュー名である必要があります。キュー名（queue_name）がnilまたは空の文字列の場合、ワーカーはワーカー名から生成されるキューにルーティングされます。詳細については、利用可能なジョブクラスのリストを参照してください）。キュー名は、利用可能なジョブクラスのリストにある既存のキュー名と一致する必要はありません。
3. 最初にワーカーに一致するクエリがそのワーカーに対して選択され、それ以降のルールは無視されます。

ルーティングルール移行

Sidekiqルーティングルールが変更された後、特に長いキューを持つシステムでは、移行の際にジョブが完全に失われないように注意する必要があります。移行は、Sidekiqジョブ移行で述べられている移行手順に従って実行できます。

スケールされたアーキテクチャでのルーティングルール

ルーティングルールは、アプリケーションの設定の一部であるため、すべてのGitLabノード（特にGitLab RailsおよびSidekiqノード）で同じである必要があります。

詳細な例

これは、さまざまな可能性を示すことを目的とした包括的な例です。A Helmチャートの例も利用できます。これらは推奨事項ではありません。

1. /etc/gitlab/gitlab.rbを編集します:

   sidekiq['routing_rules'] = [
     # Route all non-CPU-bound workers that are high urgency to `high-urgency` queue
     ['resource_boundary!=cpu&urgency=high', 'high-urgency'],
     # Route all database, gitaly and global search workers that are throttled to `throttled` queue
     ['feature_category=database,gitaly,global_search&urgency=throttled', 'throttled'],
     # Route all workers having contact with outside world to a `network-intensive` queue
     ['has_external_dependencies=true|feature_category=hooks|tags=network', 'network-intensive'],
     # Wildcard matching, route the rest to `default` queue
     ['*', 'default']
   ]

   queue_groupsは、これらの生成されたキュー名と一致するように設定できます。例:

   sidekiq['queue_groups'] = [
     # Run two high-urgency processes
     'high-urgency',
     'high-urgency',
     # Run one process for throttled, network-intensive
     'throttled,network-intensive',
     # Run one 'catchall' process on the default and mailers queues
     'default,mailers'
   ]

2. ファイルを保存して、GitLabを再設定します:

   sudo gitlab-ctl reconfigure

ワーカーマッチングクエリ

GitLabは、ルーティングルールによって使用されるワーカーの属性に基づいてワーカーを照合するためのクエリ構文を提供します。1つのクエリには2つのコンポーネントが含まれます:

• 選択できる属性。
• クエリの構築に使用される演算子。

利用可能な属性

キューマッチングクエリは、GitLab開発ドキュメントのSidekiqスタイルガイドで説明されているワーカーの属性に基づいて機能します。私たちは、ワーカーの属性のサブセットに基づいたクエリをサポートしています:

• feature_category - キューが属するGitLabの機能カテゴリ。たとえば、mergeキューはsource_code_managementカテゴリに属します。
• has_external_dependencies - キューが外部サービスに接続するかどうか。たとえば、すべてのインポーターでこれはtrueに設定されています。
• urgency - このキューのジョブが迅速に実行されることの重要度。high、low、throttledのいずれかです。たとえば、authorized_projectsキューはユーザー権限を更新するために使用され、highの緊急度です。
• worker_name - ワーカー名。この属性を使用して特定のワーカーを選択します。利用可能なすべての名前は、以下のジョブクラスのリストで確認できます。
• name - ワーカー名から生成されるキュー名。この属性を使用して特定のキューを選択します。これはワーカー名から生成されるため、他のルーティングルールの結果に基づいて変更されることはありません。
• resource_boundary - キューがcpu、memory、またはunknownによって制限されているかどうか。たとえば、ProjectExportWorkerは、エクスポートのためにデータを保存する前にメモリに読み込む必要があるため、メモリに制約されます。
• tags - キューの短命な注釈。これらはリリースごとに頻繁に変更されることが予想され、完全に削除される可能性もあります。
• queue_namespace - 一部のワーカーはネームスペースでグループ化されており、nameは<queue_namespace>:をプレフィックスとしています。たとえば、cronjob:admin_emailのキューnameの場合、queue_namespaceはcronjobです。この属性を使用してワーカーのグループを選択します。

has_external_dependenciesはブール型の属性です。厳密にtrueという文字列のみがtrueと見なされ、それ以外はすべてfalseと見なされます。

tagsはセットであり、これは=が交差するセットをチェックし、!=が互いに素なセットをチェックすることを意味します。たとえば、tags=a,bはa、b、またはその両方のタグを持つキューを選択します。tags!=a,bはそれらのどちらのタグも持たないキューを選択します。

利用可能な演算子

ルーティングルールは、優先順位が高い順から低い順に、次の演算子をサポートしています:

• | - 論理OR演算子。たとえば、query_a|query_b（ここでquery_aとquery_bは他の演算子で構成されるクエリです）は、いずれかのクエリに一致するキューを含みます。
• & - 論理AND演算子。たとえば、query_a&query_b（ここでquery_aとquery_bは他の演算子で構成されるクエリです）は、両方のクエリに一致するキューのみを含みます。
• != - NOT IN演算子。たとえば、feature_category!=issue_trackingはissue_tracking機能カテゴリのすべてのキューを除外するします。
• = - IN演算子。たとえば、resource_boundary=cpuはCPUバウンドのすべてのキューを含みます。
• , - 連結セット演算子。たとえば、feature_category=continuous_integration,pagesはcontinuous_integrationカテゴリまたはpagesカテゴリのいずれかのすべてのキューを含みます。この例はOR演算子を使用しても可能ですが、簡潔になり、優先順位も低くなります。

この構文の演算子の優先順位は固定されており、ANDをORよりも高い優先順位にすることはできません。

以前にドキュメント化された標準キューグループ構文と同様に、キューグループ全体としての単一の*はすべてのキューを選択します。

利用可能なジョブクラスのリスト

既存のSidekiqジョブクラスとキューのリストについては、以下のファイルを確認してください:

• すべてのGitLabエディションのキュー
• GitLab Enterprise Editions専用のキュー