[Question][framework] Configuring DevLake for ~6.5k GitLab repos and company-wide metrics

この issue では、ソースファイル、テスト、エントリーポイントが指定されていません。まず関連する issue #8448、#8802、#8260 を確認し、次に大規模な GitLab デプロイメント、プロジェクトと blueprint の構成、パイプラインの並列性、共有データベースの制限について根拠を集めてください。対応完了の条件は、サポートされる規模、設定に関するガイダンス、ボトルネック、および共有 MySQL を使用したマルチインスタンス運用がサポートされるかどうかを文書化することです。

We are sizing a DevLake deployment for a large GitLab estate and want to know whether a single instance is expected to handle this, and how we should configure projects/blueprints if so.

Scale

• One product org already has ~6,500 GitLab repos; we need to plan for tens of thousands across the company.
• Teams are disjoint (no shared repos between team projects).
• We still need org- and company-wide metrics (e.g. Cycle Time) from one database. We do not use Grafana; a metrics API reads the same MySQL.
• Splitting into isolated DevLake+MySQL stacks would speed collection, but then we could not compute org- or company-wide Cycle Time with a single query against one database.

What we think is the intended setup (please correct us) :

• One lake process, one MySQL (we know a second instance on the same DB_URL hits the exclusive _devlake_locking_stub lock).
• Many team-sized projects/blueprints (tens to ~150 repos each), not one project with 6,500 scopes.
• PIPELINE_MAX_PARALLEL > 1, staggered crons, incremental sync, skip heavy gitextractor options if needed.

Questions

1. Has anyone run DevLake successfully at a few thousand GitLab repos on one instance? What project size, PIPELINE_MAX_PARALLEL, and sync policy actually worked?
2. Is the guidance above right, or is there a better project/blueprint layout for this?
3. At this scale, is the bottleneck expected to be the single runner (sequential blueprints / sequential GitLab stages) rather than MySQL?
4. If one instance cannot keep a daily incremental cycle, is the intended path still “more hardware on one process”, or is multi-instance sharing one DB something the project would consider?

Related: #8448, #8802, #8260