편집

다음을 통해 공유

노이지 네이버 안티패턴

Azure

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

문제 설명

여러 고객 또는 테넌트가 공유할 서비스를 빌드할 때 다중 테넌트로 빌드할 수 있습니다. 다중 테넌트 시스템의 이점은 테넌트 간에 리소스를 풀링하고 공유할 수 있다는 것입니다. 따라서 비용이 절감되고 효율성이 향상되는 경우가 많습니다. 그러나 단일 테넌트에서 시스템의 리소스를 필요 이상으로 사용하는 경우 시스템의 전반적인 성능이 저하할 수 있습니다. 노이지 네이버 문제는 다른 테넌트의 활동으로 인해 한 테넌트의 성능이 저하될 때 발생합니다.

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

두 테넌트의 리소스 사용량을 보여 주는 그림. 테넌트 A는 전체 시스템 리소스 세트를 사용합니다. 즉, 테넌트 B에서 오류가 발생합니다.

먼저 도착하는 테넌트의 요청이 우선적으로 적용될 가능성이 높습니다. 그러면 다른 테넌트는 노이지 네이버 문제를 겪을 것입니다. 또는 두 테넌트 모두 성능이 저하될 수 있습니다.

개별 테넌트가 소비하는 시스템 용량은 상대적으로 적지만, 많은 테넌트가 집단적으로 리소스를 사용하여 전체 사용량이 최고조에 달할 때도 노이지 네이버 문제가 발생합니다.

각각 솔루션의 최대 처리량을 적게 사용하는 테넌트가 3개인 그림. 총 세 테넌트는 전체 시스템 리소스를 사용합니다.

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

문제를 해결하는 방법

시끄러운 인접 문제는 단일 리소스를 공유할 때 내재된 위험이며 시끄러운 이웃의 영향을 완전히 제거할 수는 없습니다. 그러나 클라이언트와 서비스 공급자 모두 시끄러운 인접 문제의 가능성을 줄이거나 관찰될 때 영향을 완화하기 위해 수행할 수 있는 몇 가지 단계가 있습니다.

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

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

  • 시스템의 리소스 사용량을 모니터링합니다. 각 테넌트가 사용하는 전체 리소스 사용량과 리소스를 모두 모니터링합니다. 리소스 사용량 급증을 감지하도록 알림을 구성하고, 가능한 경우 스케일 업 또는 아웃하여 알려진 문제를 자동으로 완화하도록 자동화를 구성합니다.
  • 리소스 거버넌스를 적용합니다. 단일 테넌트가 시스템에 과부하는 것을 방지하는 정책을 적용하고 다른 사용자가 사용할 수 있는 용량을 줄이는 것이 좋습니다. 이 단계에서는 조절 패턴 또는 속도 제한 패턴을 통해 할당량 적용 형식을 취할 수 있습니다.
  • 더 많은 인프라를 프로비전합니다. 이 프로세스에는 일부 솔루션 구성 요소를 업그레이드하여 스케일 업이 있을 수 있고, 분할 패턴을 따르는 경우 추가 분할을 프로비저닝하여 스케일 아웃이 있을 수 있고, 배포 스탬프 패턴을 따르는 경우 스탬프가 있을 수 있습니다.
  • 테넌트가 미리 프로비전되거나 예약된 용량을 구매할 수 있도록 합니다. 이 용량을 통해 테넌트는 솔루션이 워크로드를 적절하게 처리할 수 있다는 확신을 갖게 됩니다.
  • 테넌트의 리소스 사용량을 원활하게 처리합니다. 예를 들어 다음 방법 중 하나를 시도할 수 있습니다.
    • 솔루션의 여러 인스턴스를 호스트하는 경우 인스턴스 또는 스탬프 간에 테넌트 균형을 다시 조정하는 것이 좋습니다. 예를 들어 여러 스탬프에 예측 가능하고 유사한 사용 패턴이 있는 테넌트에 배치하여 사용량의 최고를 평면화하는 것이 좋습니다.
    • 백그라운드 프로세스 또는 시간에 민감하지 않은 리소스 집약적인 워크로드가 있는지 고려합니다. 사용량이 많은 시간에 이러한 워크로드를 비동기적으로 실행하여 시간에 민감한 워크로드의 최대 리소스 용량을 유지합니다.
  • 다운스트림 서비스가 시끄러운 인접 문제를 완화하기 위한 컨트롤을 제공하는지 확인합니다. 예를 들어 Kubernetes를 사용할 때는 Pod 제한을 사용하는 것이 좋고, Service Fabric을 사용할 때는 내장된 거버넌스 기능을 사용하는 것이 좋습니다.
  • 테넌트가 수행할 수 있는 작업을 제한합니다. 예를 들어, 쿼리에 대해 반환 가능한 최대 레코드 수 또는 시간 제한을 지정하는 등 매우 큰 데이터베이스 쿼리를 실행하는 작업을 테넌트에서 실행하지 못하도록 제한합니다. 이 작업은 테넌트가 다른 테넌트에 부정적인 영향을 미칠 수 있는 작업을 취하는 위험을 완화합니다.
  • QoS(서비스 품질) 시스템을 제공합니다. QoS를 적용할 때 일부 프로세스 또는 워크로드의 우선순위를 다른 프로세스보다 먼저 지정할 수 있습니다. 설계 및 아키텍처에 QoS를 팩터링함으로써 리소스에 부담이 있을 때 우선 순위가 높은 작업이 우선하도록 보장할 수 있습니다.

고려 사항

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

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

참고

적용하는 제한 또는 서비스에 대한 사용 할당량에 대해 클라이언트에 알려야 합니다. 실패한 요청을 안정적으로 처리하고 적용하는 제한 사항 또는 할당량에 놀라지 않도록 하는 것이 중요합니다.

문제를 감지하는 방법

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

서비스의 관점에서 시끄러운 인접 문제는 다음과 같은 여러 가지 방법으로 나타날 수 있습니다.

  • 리소스 사용량이 급증합니다. 일반적인 기준 리소스 사용량을 명확하게 이해하고 리소스 사용량 급증을 감지하도록 모니터링 및 경고를 구성하는 것이 중요합니다. 서비스의 성능 또는 가용성에 영향을 줄 수 있는 모든 리소스를 고려해야 합니다. 이 리소스에는 서버 CPU 및 메모리 사용량, 디스크 IO, 데이터베이스 사용량, 네트워크 트래픽, 그리고 관리되는 서비스에서 노출되는 메트릭(예: 요청 수 및 Azure Cosmos DB 요청 단위와 같은 가상 및 추상 성능 메트릭)이 포함됩니다.
  • 테넌트에 대한 작업을 수행할 때 오류가 발생합니다. 특히 테넌트가 시스템 리소스의 상당 부분을 사용하지 않을 때 발생하는 오류를 찾습니다. 이러한 패턴은 테넌트가 시끄러운 이웃 문제의 희생자임을 나타낼 수 있습니다. 테넌트별 리소스 사용량을 추적하는 것이 좋습니다. 예를 들어 Azure Cosmos DB를 사용할 경우 각 요청에 사용되는 요청 단위를 로깅하고 테넌트의 식별자를 원격 분석에 차원으로 추가하여 각 테넌트에 대한 요청 단위 사용량을 집계할 수 있습니다.

참가자

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

보안 주체 작성자:

  • John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.