구성 컨트롤러 인스턴스별: 하나의 Google Cloud 프로젝트에 구성 컨트롤러 인스턴스를 여러 개 만들 수 있습니다.
프로젝트별: 여러 Google Cloud 프로젝트에 구성 컨트롤러 인스턴스 여러 개를 만들 수 있습니다. 이러한 메커니즘은 하나의 프로젝트에서 할당량 병목 현상이 발생하는 경우 API 할당량 문제를 해결하는 데 도움이 됩니다. 자세한 내용은 리소스를 여러 프로젝트로 분할을 참조하세요.
샤딩 구현 시 주의사항
구성 컨트롤러 사용에 대해 샤딩을 구현할 때는 주의해야 하는 몇 가지 문제가 있으며 이러한 문제를 완화하기 위한 계획을 세워야 합니다.
인스턴스 간 리소스 참조
구성 컨트롤러를 샤딩할 때의 문제 중 하나는 인스턴스 간 리소스 참조를 처리하는 것입니다. 예를 들어 플랫폼팀은 하나의 인스턴스에 여러 프로젝트를 만들고, 앱팀은 다른 인스턴스에서 해당 프로젝트를 참조하는 리소스를 만들 수 있습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다.
복잡성 증가: 클러스터 간 리소스 참조를 관리하면 구성이 더 복잡해지고 관리하기 어려울 수 있습니다.
위험 증가: 한 샤드에서 리소스가 삭제되어도 다른 샤드의 리소스에서 계속 참조할 수 있습니다. 이로 인해 예기치 않은 동작 및 데이터 손실이 발생할 수 있습니다.
성능 저하: 클러스터 간 리소스 참조로 인해 구성 변경 지연 시간이 늘어날 수 있습니다.
교차 참조 문제점을 해결하는 몇 가지 방법이 있습니다.
샤드 간 참조가 필요 없는 방식으로 샤딩. 이를 위해서는 환경 또는 팀별로 샤딩하면 됩니다.
외부 참조 사용. 즉, 참조되는 객체가 실제로는 구성 컨트롤러에서 관리되지 않습니다. 이는 객체가 자주 변경되지 않는 경우에 적합한 옵션일 수 있습니다.
모든 샤드에서 동일한 객체 사용. 이는 더 복잡한 옵션이지만 객체가 자주 변경되는 경우 가장 좋은 옵션일 수 있습니다.
객체는 서로 다른 샤드에서 이러한 객체 간의 조정 경합을 방지하기 위해 동일한 정보 소스를 공유해야 합니다. 이러한 객체에서 충돌 방지 정책을 none으로 설정해야 합니다.
옵션을 선택하기 전에 각 방법의 장점과 단점을 신중하게 고려해야 합니다.
API 할당량
샤딩은 API 할당량을 늘릴 수 있습니다. 이를 충분히 인지하고 그에 따라 계획해야 합니다. API 할당량 한도 관리에 대한 권장사항은 API 할당량 한도 관리를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-01(UTC)"],[],[],null,["# Config Controller sharding guidelines\n\nThis document provides recommendations on how to shard your\nConfig Controller usage. Sharding is the process of splitting\nConfig Controller-managed Google Cloud resources across multiple namespaces,\nclusters, or projects.\n\nSharding brings the following benefits:\n\n- **Reduces the impact of changes**: If a single shard stops functioning, the other shards are not impacted.\n- **Helps you manage security**: Each shard can have dedicated IAM and RBAC configurations. Malicious attackers who compromise one shard cannot access other shards. Misconfiguration in one shard cannot affect other shards.\n- **Better scalability**: A single shard can have scalability bottlenecks such as the number of managed objects, or API quotas. Having multiple shards increases the overall scalability of your Config Controller usage.\n\nUse sharding with Config Controller\n-----------------------------------\n\nThere are a few different ways to implement sharding. The best approach for you\nwill depend on your specific needs and requirements.\n\n### Sharding models\n\nThere are two main sharding models:\n\n- **By business lines or application teams**: This model is typically used when Config Controller is used by different teams. In this model, each team has their own shard.\n- **By environment**: This model is typically used when Config Controller is used in different environments. For example, you might have a shard for your development environment, a shard for your QA environment, and a shard for your production environment.\n\n### Minimize the need for cross-shard references\n\nWhen you shard your Config Controller usage, you should minimize the\nneed for cross-shard references. Cross-shard references can make your\nconfiguration more complex and difficult to manage. See\n[Resource references across instances](#resource-references-across-instances)\nfor more details.\n\n### Sharding mechanisms\n\nThere are three main sharding mechanisms:\n\n- **By namespaces** : You can create additional namespaces and [configure Config Connector to manage resources in those namespaces](/config-connector/docs/how-to/advanced-install#project-namespace).\n- **By Config Controller instances**: You can create multiple Config Controller instances in one Google Cloud project.\n- **By projects** : You can create multiple Config Controller instances in multiple Google Cloud projects. This mechanism helps address API quota issues if you are hitting quota bottlenecks with one single project. See [Split your resources into multiple projects](/config-connector/docs/best-practices#quota-split) for more details.\n\nCaveats when implementing sharding\n----------------------------------\n\nWhen implementing sharding for your Config Controller usage, there are some\npotential issues you should be aware of and plan to mitigate.\n\n### Resource references across instances\n\nOne of the challenges of sharding Config Controller is dealing with resource\nreferences across instances. For example, a platform team might create Projects\nin one instance, and then app teams might create resources that refer to those\nProjects in other instances. This can create problems such as:\n\n- **Increased complexity**: Managing resource references across clusters can make your configuration more complex and difficult to manage.\n- **Increased risk**: If a resource is deleted in one shard, it can still be referenced by resources in other shards. This can lead to unexpected behavior and data loss.\n- **Performance degradation**: Resource references across clusters can increase the latency of your configuration changes.\n\nThere are a few ways to work around the cross-reference challenge:\n\n- Sharding in a way that no reference across shards is needed. This could be done by sharding by environments or by teams.\n- Using external references. This means that the object that is being referenced is not actually managed by Config Controller. This can be a good option if the object isn't changing frequently.\n- Having the same object available in all shards. This is a more complex option, but it can be the best option if the object changes frequently. The objects should share the same source of truth to avoid reconciliation fights between these objects in different shards. You need to set the [conflict prevention policy](/config-connector/docs/concepts/managing-conflicts#modifying_conflict_prevention) to `none` for these objects.\n\nIt is important to carefully consider the advantages and disadvantages of each approach\nbefore choosing one.\n\n### API Quotas\n\nSharding could increase your API quotas. You should be aware of this and plan\naccordingly. See\n[Manage API quota limits](/config-connector/docs/best-practices#quota-limits)\nfor best practices on managing API quota limits.\n\nWhat's next\n-----------\n\n- Learn more about [Config Controller scalability](/kubernetes-engine/enterprise/config-controller/docs/scalability)"]]
