Cells ADR 009: Cell の初期サイズ
コンテキスト
Cell をプロビジョニングする際、最初にどのリファレンスアーキテクチャを選択するかを決める必要があります。 その後、フレキシブルアーキテクチャに基づいてワークロードに応じてスケールします。
https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/2838 では、最初にどのリファレンスアーキテクチャを選択すべきかについて調査を行いました。
決定事項
Ring 0
Ring 0 では QA ジョブのみを実行し、顧客トラフィックを処理しません。 コスト効率の観点から、3k リファレンスアーキテクチャを採用します。
Ring 2 以上
最初の Cell は 社内顧客専用 / GitLab Inc. として使用され、GitLab Inc. のすべてのリポジトリを一度に移行するのではなく段階的に行います。 この Cell を最初にプロビジョニングしてから GitLab Inc. 全体をオンボードするまでの期間はまだ不明なため、 中規模の 25k リファレンスアーキテクチャサイズの Cell から開始し、50k リファレンスアーキテクチャにスケールアップします。
このリングおよびそれ以上の外側のリングでプロビジョニングするその他の Cell は、50k リファレンスアーキテクチャから開始します。
結果
Ring 0 の Cell については、現時点では影響は想定されていません。
GitLab Inc. にサービスを提供する Cell については、25k から 50k へのスケールアップが必要になる場合があり、 Gitaly、Database、Redis などのステートフルなサービスをリサイズする必要があるためダウンタイムが発生する可能性があります。 このダウンタイムの時間はまだ不明であり未検証ですが、 AWS 上の Dedicated ではおよそ 20〜40 分程度です。 このダウンタイムが発生する場合は社内のみへの影響にとどまるため、 影響を最小化するために週末に実施することができます。
代替案
GitLab Inc. にサービスを提供する最初の Cell を最初から 50k リファレンスアーキテクチャで構築することも可能ですが、以下の理由から採用しませんでした。
- 全員をオンボードする際にこれらのリソースが必要かどうか不明です。
- 全員をいつオンボードするか不明なため、多くのコンピューティングリソースが無駄になります。
- フレキシブルリファレンスアーキテクチャを使用して、まずアーキテクチャ内の特定のホットスポットを解消することができます。
