디자인 패턴과 마찬가지로 성능 안티패턴도 조직 내에서 일반적인 결함이 있는 프로세스 및 구현입니다. 애플리케이션이 압박을 받을 때 확장성 문제를 일으킬 수 있는 일반적인 사례입니다. 이러한 사례에 대한 인식은 소프트웨어 실무자 간의 높은 수준의 개념 통신을 간소화하는 데 도움이 될 수 있으며, 코드를 검토하거나 성능 문제를 진단할 때 안티패턴에 대한 지식이 도움이 될 수 있습니다.
일반적인 시나리오는 다음과 같습니다. 성능 테스트 중에 애플리케이션이 제대로 작동합니다. 프로덕션으로 릴리스되고 실제 워크로드를 처리하기 시작합니다. 이 시점에서 성능이 저하되기 시작하여 사용자 요청을 거부하거나 중단하거나 예외를 발생시키는 등 문제가 발생합니다. 그런 다음 개발 팀은 다음 두 가지 질문에 직면합니다.
- 테스트 중에 이 동작이 표시되지 않는 이유는 무엇인가요?
- 해결 방법
첫 번째 질문에 대한 대답은 간단합니다. 테스트 환경에서 실제 사용자와 동작 패턴 및 수행할 수 있는 작업 볼륨을 시뮬레이션하는 것은 어렵습니다. 부하 상태에서 시스템이 동작하는 방식을 완전히 확실하게 이해하는 유일한 방법은 프로덕션 환경에서 시스템을 관찰하는 것입니다. 명확히 하기 위해 성능 테스트를 건너뛰어야 한다고 제안하지는 않습니다. 성능 테스트는 기준 성능 메트릭을 가져오는 데 중요합니다. 그러나 라이브 시스템에서 발생하는 성능 문제를 관찰하고 수정할 준비가 되어 있어야 합니다.
두 번째 질문에 대한 대답, 문제를 해결하는 방법은 덜 간단합니다. 여러 가지 요인이 발생할 수 있으며 경우에 따라 문제가 특정 상황에서만 나타납니다. 계측 및 로깅은 근본 원인을 찾는 데 핵심적이지만 무엇을 찾아야 하는지도 알아야 합니다.
Microsoft Azure 고객과의 계약에 따라 고객이 프로덕션 환경에서 볼 수 있는 가장 일반적인 성능 문제 중 일부를 확인했습니다. 각 안티패턴에 대해, 우리는 왜 안티패턴이 전형적으로 발생하는지, 안티패턴의 증상, 문제를 해결하기 위한 기술을 설명합니다. 또한 안티패턴 및 제안된 확장성 솔루션을 모두 보여 주는 샘플 코드도 제공합니다.
이러한 안티패턴 중 일부는 설명을 읽을 때 분명하게 보일 수 있지만 생각보다 더 자주 발생합니다. 경우에 따라 애플리케이션은 온-프레미스에서 작동하지만 클라우드에서 확장되지 않는 디자인을 상속합니다. 또는 애플리케이션은 매우 깨끗한 디자인으로 시작할 수 있지만 새로운 기능이 추가되면 이러한 안티패턴 중 하나 이상이 들어온다. 그럼에도 불구하고 이 가이드는 이러한 안티패턴을 식별하고 수정하는 데 도움이 됩니다.
안티패턴 카탈로그
식별한 안티패턴 목록은 다음과 같습니다.
| 안티패턴(Antipattern) | 설명 |
|---|---|
| 바쁜 데이터베이스 | 너무 많은 처리를 데이터 저장소로 오프로드합니다. |
| 바쁜 프런트 엔드 | 리소스를 많이 사용하는 작업을 백그라운드 스레드로 이동합니다. |
| 잡음이 많은 I/O | 많은 소규모 네트워크 요청을 지속적으로 보냅니다. |
| 과도한 가져오기 | 필요한 것보다 많은 데이터를 검색하면 불필요한 I/O가 발생합니다. |
| 부적절한 인스턴스화 | 공유 및 재사용되도록 설계된 개체를 반복적으로 만들고 삭제합니다. |
| 모놀리식 지속성 | 사용 패턴이 매우 다른 데이터에 대해 동일한 데이터 저장소를 사용합니다. |
| 캐싱 없음 | 데이터를 캐시하지 못했습니다. |
| 시끄러운 이웃 | 단일 테넌트는 불균형한 양의 리소스를 사용합니다. |
| Storm 다시 시도 | 서버에 대한 실패한 요청을 너무 자주 다시 시도합니다. |
| 동기 입출력 | I/O가 완료되는 동안 호출 스레드 차단 |
다음 단계
성능 튜닝에 대한 자세한 내용은 Well Architected Framework의 성능 효율성을 참조하세요.