다음을 통해 공유

노이지 네이버 안티패턴

Azure

다중 테넌트 시스템은 둘 이상의 테넌트 간에 리소스를 공유합니다. 테넌트는 동일한 공유 리소스를 사용하므로 한 테넌트의 활동이 다른 테넌트의 시스템 사용에 부정적인 영향을 줄 수 있습니다.

컨텍스트 및 문제

When you build a service that multiple customers or tenants share, you can build it to be multitenanted. 다중 테넌트 시스템의 이점은 테넌트 간에 리소스를 풀링하고 공유할 수 있다는 것입니다. 이러한 리소스 공유로 인해 비용이 절감되고 효율성이 향상되는 경우가 많습니다. 그러나 단일 테넌트에서 시스템의 리소스를 필요 이상으로 사용하는 경우 시스템의 전반적인 성능이 저하할 수 있습니다. The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.

두 개의 테넌트가 있는 예제 다중 테넌트 시스템을 생각해 보세요. 테넌트 A의 사용 패턴 및 테넌트 B의 사용 패턴이 일치합니다. 사용량이 많은 시간에 테넌트 A는 시스템의 모든 리소스를 사용합니다. 즉, 테넌트 B가 만드는 모든 요청이 실패합니다. 즉, 총 리소스 수요가 시스템의 용량보다 높습니다.

두 테넌트 리소스 사용량을 보여 주는 다이어그램

요청이 먼저 도착하는 테넌트가 우선적으로 적용됩니다. 그러면 다른 테넌트에 노이즈 네이버 문제가 발생할 수 있습니다. 또는 두 테넌트 모두에서 성능이 저하될 수 있습니다.

각 개별 테넌트가 시스템 용량의 작은 부분만 사용하는 경우에도 시끄러운 인접 문제가 발생합니다. 그러나 많은 테넌트가 결합된 리소스 사용량은 전체 사용량이 최고조에 달할 수 있습니다.

각각 최대 처리량 미만을 사용하는 세 개의 테넌트를 보여 주는 다이어그램 함께 총 시스템 리소스를 완전히 사용합니다.

이 시나리오는 모두 유사한 사용 패턴을 가진 테넌트가 여러 개 있거나 시스템의 집단 로드에 충분한 용량을 프로비전하지 않은 경우에 발생할 수 있습니다.

Solution

단일 리소스를 공유하면 기본적으로 완전히 피할 수 없는 시끄러운 인접 문제의 위험이 발생합니다. 그러나 클라이언트와 서비스 공급자가 노이즈 이웃 문제의 가능성을 줄이거나 영향을 완화하기 위해 수행할 수 있는 몇 가지 단계가 있습니다.

클라이언트가 수행할 수 있는 작업

서비스 공급자가 수행할 수 있는 작업

  • 시스템의 리소스 사용량을 모니터링합니다. 각 테넌트가 사용하는 전체 리소스 사용량과 리소스를 모두 모니터링합니다. 리소스 사용량 급증을 감지하도록 경고를 구성합니다. 가능하면 확장 또는 확장하여 알려진 문제를 자동으로 완화하도록 자동화를 구성합니다.

  • 리소스 거버넌스를 적용합니다. 단일 테넌트가 시스템을 압도하지 못하도록 하는 정책을 적용하고 다른 테넌트에서 사용할 수 있는 용량을 줄이는 것이 좋습니다. This step might take the form of quota enforcement through the Throttling pattern or the Rate Limiting pattern.

  • 더 많은 인프라를 프로비전합니다. 이 프로세스에는 일부 솔루션 구성 요소를 업그레이드하여 스케일 업이 포함될 수 있습니다. Or it might include scaling out by provisioning extra shards if you follow the Sharding pattern, or stamps if you follow the Deployment Stamps pattern.

  • 테넌트가 미리 프로비전되거나 예약된 용량을 구매할 수 있도록 합니다. 이 접근 방식을 통해 테넌트는 솔루션이 워크로드를 안정적으로 처리할 수 있다는 확신을 갖게 됩니다.

  • 테넌트 리소스 사용량의 균형을 조정합니다. 예를 들어 다음 방법 중 하나를 시도할 수 있습니다.

    • 솔루션의 여러 인스턴스를 호스트하는 경우 인스턴스 또는 스탬프 간에 테넌트 균형을 다시 조정하는 것이 좋습니다. 예를 들어 여러 스탬프에 예측 가능하고 보완적인 사용 패턴이 있는 테넌트에 배치하여 사용량의 최대값을 평면화하는 것이 좋습니다.

    • 백그라운드 프로세스 또는 시간에 민감하지 않은 리소스 집약적인 워크로드가 있는지 고려합니다. 사용량이 많은 시간에 이러한 워크로드를 비동기적으로 실행하여 시간에 민감한 워크로드에 대한 리소스 용량을 유지합니다.

  • 다운스트림 서비스가 시끄러운 인접 문제를 완화하기 위한 컨트롤을 제공하는지 확인합니다. For example, when you use Kubernetes, consider using pod limits. Azure Service Fabric을 사용하는 경우 기본 제공 거버넌스 기능을 사용하는 것이 좋습니다.

  • 테넌트가 수행할 수 있는 작업을 제한합니다. 예를 들어, 쿼리에 대해 반환 가능한 최대 레코드 수 또는 시간 제한을 지정하는 등 매우 큰 데이터베이스 쿼리를 실행하는 작업을 수행하지 못하도록 테넌트를 제한합니다. 또는 이러한 작업을 비동기 작업으로 변경하고 사용량이 많은 시간에 실행되도록 예약합니다. 이 작업은 테넌트가 다른 테넌트에 부정적인 영향을 줄 수 있는 작업을 수행하는 위험을 완화합니다.

  • QoS(서비스 품질) 시스템을 제공합니다. QoS를 적용할 때 다른 프로세스 또는 워크로드 앞에 일부 프로세스 또는 워크로드의 우선 순위를 지정합니다. 설계 및 아키텍처에 QoS를 팩터링함으로써 리소스에 부담이 있을 때 우선 순위가 높은 작업이 우선하도록 보장할 수 있습니다.

Considerations

대부분의 경우 개별 테넌트는 시끄러운 인접 문제를 일으키지 않습니다. 개별 테넌트는 워크로드가 다른 테넌트에 대해 시끄러운 이웃 문제를 일으킨다는 것을 알지 못할 수 있습니다. 그러나 일부 테넌트는 공유 구성 요소의 취약성을 악용하여 개별적으로 또는 분산 서비스 거부 공격을 수행하여 서비스를 공격할 수 있습니다.

원인에 관계없이 이러한 문제를 리소스 거버넌스 문제로 처리하고 사용 할당량, 제한 및 거버넌스 제어를 적용하여 문제를 완화하는 것이 중요합니다.

Note

적용하는 제한 메커니즘 또는 사용 할당량에 대해 클라이언트와 투명하게 유지합니다. 실패한 요청을 정상적으로 처리하고 제한 사항으로 인해 보호되지 않는 것이 중요합니다.

문제를 감지하는 방법

클라이언트의 관점에서 노이즈 네이버 문제는 일반적으로 서비스에 대한 실패한 요청 또는 완료하는 데 시간이 오래 걸리는 요청으로 나타납니다. 특히 동일한 요청이 다른 시간에 성공하고 임의로 실패하는 것처럼 보이는 경우 시끄러운 인접 문제가 있을 수 있습니다. 클라이언트 애플리케이션은 서비스에 대한 요청의 성공률 및 성능을 추적하기 위해 원격 분석을 기록해야 합니다. 또한 애플리케이션은 비교를 위해 기준 성능 메트릭을 기록해야 합니다.

Azure 기반 서비스의 경우 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 검토하여 솔루션의 각 Azure 구성 요소에 적용되는 제한 및 할당량을 이해합니다.

서비스의 관점에서 노이즈 네이버 문제는 다음과 같은 방식으로 나타날 수 있습니다.

  • 리소스 사용량 급증: 일반적인 기준 리소스 사용량을 명확하게 이해하고 급증을 감지하도록 모니터링 및 경고를 구성하는 것이 중요합니다. 서비스의 성능 또는 가용성에 영향을 줄 수 있는 모든 리소스를 고려합니다. 이러한 리소스에는 서버 CPU 및 메모리 사용량, 디스크 입력 및 출력, 데이터베이스 사용량 및 네트워크 트래픽과 같은 메트릭이 포함됩니다. 또한 요청 볼륨 및 Azure Cosmos DB 요청 단위와 같은 가상 또는 추상 성능 지표를 포함하여 관리되는 서비스에서 노출되는 메트릭을 모니터링해야 합니다.

  • 테넌트에 대한 작업을 수행할 때 발생하는 오류: 테넌트가 시스템 리소스의 큰 부분을 소비하지 않을 때 발생하는 오류를 찾습니다. 이 패턴은 테넌트에 시끄러운 인접 문제가 있음을 나타낼 수 있습니다. 테넌트별 리소스 사용량을 추적합니다. 예를 들어 Azure Cosmos DB를 사용하는 경우 각 요청에 대한 요청 단위를 기록하고 각 테넌트의 요청 단위 사용량을 집계할 수 있도록 원격 분석에 테넌트의 식별자를 포함합니다.

Contributors

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

Principal author:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.