Tenant Controls チーム

Production Engineering 内で、Tenant Controls チームは GitLab.com のアプリケーションレベルのレート制限を担当します。 これには、すべてのアプリケーションのレート制限を定義・計数・観測するフレームワークと、 既存の実装をそのフレームワークへ移行する作業が含まれます。制限そのものについては、 運用担当者にとって信頼できる唯一の情報源である レート制限を参照してください。

ミッション

私たちのミッションは、GitLab.com のすべてのアプリケーションのレート制限を定義・設定・観測する方法を統一し、 インシデント中に制限について判断でき、デプロイせずに変更できるようにすることです。

担当範囲と責任

チームの担当範囲は 統一レート制限アーキテクチャで定められており、 ボードに記載したワークストリームとして実行します:

1. 統一 SDK: 共通のレート制限 SDK としての labkitと、 呼び出し側の SDK への準拠。
2. アプリケーションの統一: 既存の実装である Rack::Attack と ApplicationRateLimiter を、破壊的変更を加えずにその SDK を経由するようにします。
3. 設定の外部化: 制限の設定をアプリケーションとデータベースから、 labkit が読み込む設定ファイルに移します。
4. 動的ルールサービス: リクエストごとにルールを返す外部サービスで、 顧客ごと、ティアごとの制限を可能にします。
5. ティアに応じたスロットリング: 全員に同じ数値を適用するのではなく、プランによって異なる制限を適用します。
6. 運用上の責任: 本番環境のレート制限フレームワークを担当し、 そのオブザーバビリティ、ドライラン、バイパスの動作も含みます。

個々の制限値の設定は、運用担当者と共同で行う変更管理の対象となる作業であり、 このチームが単独で担当するものではありません。 レート制限を参照してください。

支援を受ける

• Slack: #g_tenant-controls
• ユーザーまたはグループのレート制限設定: リクエストテンプレートを使用してください。
• バイパスのリクエスト: レート制限バイパスポリシーに従ってください。

共通リンク

チームメンバー

以下のメンバーが Tenant Controls チームに所属しています:

作業の追跡方法

チームは gitlab-com/gl-infra グループのエピックと Issue を使って作業を計画・追跡します。 以下のボードはすべてラベルのみに基づいて表示されます。GitLab はエピックから子 Issue へ ラベルを引き継がないため、作成者がエピックや Issue の作成時にラベルを適用します。

ラベルとボードには、チーム名ではなく作業内容である Rate Limiting に基づく名前を付けています。そのため、 team::Rate Limiting が Tenant Controls チームのラベルです。

ボードの正確さを保つために、2 つの原則があります:

エピックがラベルを定義します。 エピックに付けられた team:: と rate-limits:: のラベルは、 その子 Issue にも付ける必要があります。これらのラベルなしで作成された Issue はどのボードにも表示されず、 計画やステータスレビューで見落とされます。

エピックボードが対象の一覧です。 対象となるエピックは、 team::Rate Limiting が付いているものです。別の一覧は管理しません。ラベルを付けるとエピックは対象に入り、 ラベルを外すかエピックをクローズすると対象から外れます。

ボード

エピックボードが 1 つ、チーム全体の Issue ボードが 1 つ、各ワークストリームの Issue ボードが 1 つずつあります。

rate-limits:: ラベルはスコープ付きのため、Issue に付けられるのは 1 つだけです。そのため、 ワークストリームのボードは Delivery ボードを分割したものになり、各ワークストリームの件数の合計は チーム全体の件数と一致します。一致しなくなった場合は、ワークストリームのラベルがない Issue があります。通常は、 エピックがワークストリームのラベルなしでボードに追加されたことが原因です。

ラベル

これらのラベルは gitlab-com/gl-infra グループで定義されており、このチーム専用です。 workflow-infra::、group::、section::、infra-category:: など、 すべての Infrastructure Platforms チームが使用するラベルについては、 Infrastructure Platforms のプロジェクト管理を参照してください。

新しいワークストリームのラベルの命名

形式は rate-limits::<workstream> で、<workstream> はワークストリームを表すケバブケースの短い名前です。 例として rate-limits::config-externalization があります。現在使用しているラベルは、 ボードの表に記載しています。

• 成果物ではなく、成果を名前にします。config-externalization を使用し、yaml-file は使用しません。 形式は変わっても、通常、成果は変わらないためです。
• 短くします。1 〜 3 語とし、ワークストリームのエピックのタイトルやボード名に近い名前にして、 その 3 つの対応が一目でわかるようにします。
• エピックのタイトルがイギリス式の綴りでも、アメリカ式の綴りを使用します。 -ization を使用し、-isation は使用せず、フィルタリングの際に綴りを推測する必要がないようにします。
• エピックごとにワークストリームのラベルは 1 つにします。 2 つ付けるとボード間の分割が崩れます。また、ラベルは スコープ付きのため、いずれにしても GitLab は通知なしで一方を他方に置き換えます。
• Issue でラベルを勝手に作らないでください。 エピックに rate-limits:: ラベルがない場合は、 まずラベルを作成し、エピックに付けてください。

新しいワークストリームの追加

次の 3 つのステップを順番に実行します:

1. gitlab-com/gl-infra でラベルを作成します。形式は rate-limits::<name>、色は #5843AD とし、 説明にエピックへのリンクを含めます。
2. team::Rate Limiting とともにエピックに付けます。この 2 つ目のラベルが、 エピックをエピックボードに表示します。
3. エピックの子 Issue にも両方のラベルを付け、新しい Issue が作成されるときにも 引き続き適用します。

その後、ワークストリームに専用ボードが必要であれば、新しいラベルを対象とする Issue ボードを作成します。

どのワークストリームにも当てはまらない定常作業

どのワークストリームにも属さない小さな改善や稼働維持のための作業は、rate-limits::ktlo の 四半期ごとの定常エピックに追加します。既存のワークストリームに当てはまる作業は、そちらに登録してください。 定常エピックは四半期ごとにクローズして次の四半期に引き継ぎます。これにより、作業が際限なく蓄積するのを防ぎ、 内容のレビューを必ず行います。

既知の不足点

• 別のグループの子 Issue には、これらのラベルを付けられません。 ラベルは gitlab-com/gl-infra で定義されているため、 gitlab-org/gitlab などの別のグループの Issue に適用すると、そのプロジェクト内だけで有効な ラベルが作成されてしまいます。それらの Issue にはラベルを付けないでください。エピック内では引き続き追跡されますが、 チームのボードには表示されません。
• 子エピックもラベルを引き継ぎません。 エピックに子エピックがある場合は、各子エピックにラベルを付け、 それぞれ独立してボードに表示してください。

ページのソースコードを見る - ページの編集 - please contribute.