로드 밸런서를 가상 머신 또는 베어 메탈로 사용

Question 1

앞으로 나아갈 길을 결정하기 전에 답을 찾아야 할 몇 가지 정보는 다음과 같습니다.

영향을 받는 VM의 CPU 사용량

게스트 운영 체제의 관점에서 볼 때 CPU 사용량이 80%를 초과하는 경우가 많거나 사용량이 급증하지 않고 정체기를 보이는 경우가 있습니까? VM에 CPU가 부족할 가능성이 있습니다. vCPU를 더 추가합니다(단, 발생할 수 있는 라이선스 문제도 고려하세요).
서버의 일부 vCPU는 다른 vCPU보다 로드가 훨씬 적습니까? 애플리케이션에 확장 문제가 있을 수 있는데, 단순히 단일 VM(또는 물리적 머신)에 더 많은 vCPU를 넣는 것만으로는 문제가 해결되지 않습니다.
CPU ready시간은 호스트가 오버커밋되었음을 나타냅니다 . 경험상으로 볼 때 평균 준비 시간은 5% 미만이어야 하지만 내 경험에 따르면 실제로 작업하는 시스템에는 그 시간이 너무 많은 것 같습니다. vCenter를 사용하는 경우 표시된 준비 시간은 마지막 그래프 업데이트 이후 집계된 밀리초 단위입니다. "실시간" 보기에서는 그래프가 20초(=20000ms)마다 업데이트되므로 공식을 사용하여 VM의 CPU당 평균 백분율을 계산할 수 있습니다 (indicated_ready_time * 100 / 20000) / number_of_vcpu.

RAM 사용량

(항상 게스트 운영 체제 내에서 확인해야 함)

보통 80%이상? 메모리를 추가하세요.
메모리 누수의 징후? 응용프로그램을 수정하거나 더 자주 다시 시작/재부팅할 준비를 하십시오.
과도한 교환의 징후? 구성 문제를 확인하세요. 메모리를 추가하세요.
"설명할 수 없을 정도로" 4GB 미만의 메모리를 사용하는 주요 애플리케이션/프로세스가 있습니까? 64비트 주소 지정을 활용하려면 다시 작성하거나 재구성해야 할 수도 있습니다.

또한 지연 문제가 있는지 디스크 및 네트워크 성능을 확인하세요.

애플리케이션 확장 방식에 따라 기존 서버에 컴퓨팅 성능이나 메모리를 추가하는 대신 웹 서버를 더 추가하는 것이 좋을 수도 있습니다.

병목 현상이 있는 위치와 하드웨어를 가장 잘 활용하는 방법에 대한 아이디어를 얻은 후에는 무엇을 구매할 것인지에 대한 비즈니스 사례를 만들기 시작할 수 있습니다.

가상 머신의 주요 사례는 관리가 더 쉽고, 백업도 더 쉽고, 시스템 장애 시 마이그레이션도 더 쉽다는 것입니다. 실제로 사용할 수 있는 모든 리소스가 필요하지 않은 경우 하드웨어를 더 잘 활용할 수 있으며 반가상화 네트워크 인터페이스를 사용하는 경우 동일한 호스트에 있는 시스템 간의 통신은 CPU가 관리할 수 있는 것보다 빠릅니다. 물리적 네트워크 인터페이스 속도로 제한됩니다.

물론 물리적 시스템에서 직접 실행되는 시스템에는 리소스 공유로 인한 오버헤드가 없지만 이는 가용 전력을 사용할 수 있는 경우에만 이점이 됩니다.

Answer

앞으로 나아갈 길을 결정하기 전에 답을 찾아야 할 몇 가지 정보는 다음과 같습니다.

영향을 받는 VM의 CPU 사용량

게스트 운영 체제의 관점에서 볼 때 CPU 사용량이 80%를 초과하는 경우가 많거나 사용량이 급증하지 않고 정체기를 보이는 경우가 있습니까? VM에 CPU가 부족할 가능성이 있습니다. vCPU를 더 추가합니다(단, 발생할 수 있는 라이선스 문제도 고려하세요).
서버의 일부 vCPU는 다른 vCPU보다 로드가 훨씬 적습니까? 애플리케이션에 확장 문제가 있을 수 있는데, 단순히 단일 VM(또는 물리적 머신)에 더 많은 vCPU를 넣는 것만으로는 문제가 해결되지 않습니다.
CPU ready시간은 호스트가 오버커밋되었음을 나타냅니다 . 경험상으로 볼 때 평균 준비 시간은 5% 미만이어야 하지만 내 경험에 따르면 실제로 작업하는 시스템에는 그 시간이 너무 많은 것 같습니다. vCenter를 사용하는 경우 표시된 준비 시간은 마지막 그래프 업데이트 이후 집계된 밀리초 단위입니다. "실시간" 보기에서는 그래프가 20초(=20000ms)마다 업데이트되므로 공식을 사용하여 VM의 CPU당 평균 백분율을 계산할 수 있습니다 (indicated_ready_time * 100 / 20000) / number_of_vcpu.

RAM 사용량

(항상 게스트 운영 체제 내에서 확인해야 함)

보통 80%이상? 메모리를 추가하세요.
메모리 누수의 징후? 응용프로그램을 수정하거나 더 자주 다시 시작/재부팅할 준비를 하십시오.
과도한 교환의 징후? 구성 문제를 확인하세요. 메모리를 추가하세요.
"설명할 수 없을 정도로" 4GB 미만의 메모리를 사용하는 주요 애플리케이션/프로세스가 있습니까? 64비트 주소 지정을 활용하려면 다시 작성하거나 재구성해야 할 수도 있습니다.

또한 지연 문제가 있는지 디스크 및 네트워크 성능을 확인하세요.

애플리케이션 확장 방식에 따라 기존 서버에 컴퓨팅 성능이나 메모리를 추가하는 대신 웹 서버를 더 추가하는 것이 좋을 수도 있습니다.

병목 현상이 있는 위치와 하드웨어를 가장 잘 활용하는 방법에 대한 아이디어를 얻은 후에는 무엇을 구매할 것인지에 대한 비즈니스 사례를 만들기 시작할 수 있습니다.

가상 머신의 주요 사례는 관리가 더 쉽고, 백업도 더 쉽고, 시스템 장애 시 마이그레이션도 더 쉽다는 것입니다. 실제로 사용할 수 있는 모든 리소스가 필요하지 않은 경우 하드웨어를 더 잘 활용할 수 있으며 반가상화 네트워크 인터페이스를 사용하는 경우 동일한 호스트에 있는 시스템 간의 통신은 CPU가 관리할 수 있는 것보다 빠릅니다. 물리적 네트워크 인터페이스 속도로 제한됩니다.

물론 물리적 시스템에서 직접 실행되는 시스템에는 리소스 공유로 인한 오버헤드가 없지만 이는 가용 전력을 사용할 수 있는 경우에만 이점이 됩니다.

Question 2

성능 문제의 원인을 조사하고 애플리케이션에 대한 지식이 없으면 가장 쉽고 최선의 해결 방법이 무엇인지 알 수 없습니다.

문제가 실제로 하드웨어 리소스 부족인 경우 모니터링을 통해 현재 한계에 도달한 위치와 무엇을 구입해야 하는지(CPU 코어 또는 CPU 속도, 더 많은 RAM 메모리, 더 빠른 디스크) 및 이를 할당할 위치를 매우 명확하게 알 수 있습니다. .

내 경험에 따르면 문제에 더 많은 하드웨어 리소스를 투입하는 대신 적절한 조정을 통해 성능 문제의 절반 이상이 어느 정도 쉽게 해결되었습니다. 대부분의 개발자와 너무 많은 공급업체는 프로덕션 환경에서 얻는 것과 동일한 양의 데이터와 유사한 로드를 사용하여 애플리케이션과 데이터베이스 백엔드를 테스트할 수 있는 능력이나 리소스가 없으며 너무 확장되지 않는 가정과 설계 선택을 합니다. 실제로는 글쎄요.

주의 깊게 모니터링하면 병목 현상이 무엇인지, 애플리케이션, 데이터베이스 또는 하드웨어 수준에서 해결해야 할 사항이 무엇인지에 대한 통찰력을 얻을 수 있습니다.

성능 분석과 튜닝은 과학이자 마술이라는 점에 유의하십시오.

쉽게 해결할 수 있고 종종 상당한 이점을 제공하는 매우 일반적인 응용 프로그램 문제는 다음과 같습니다.

데이터베이스에서 누락된 인덱스
연결 풀링 및 쿼리 캐싱
메모리 제한, 연결 수, 소켓 및 애플리케이션 동시 스레드 조정

해결하기 더 어려운 애플리케이션 디자인의 결함은 애플리케이션 프런트 엔드에 너무 많은 데이터 처리 로직이 있고 데이터베이스 쿼리가 너무 단순하고 바인딩되지 않고 너무 많은 데이터(예: SELECT * from GrowingDataSet)를 반환하는 경우입니다. 증상을 모니터링할 때 데이터베이스 서버의 높은 디스크 IO 로드 - 애플리케이션 서버의 높은 메모리 소비 - 포화된 네트워크 링크 - 각 링크는 다양한 하드웨어 구매 결정을 지원하는 데 사용될 수 있습니다(데이터베이스 서버에서 SSD로 업그레이드 - 증가). 애플리케이션 서버의 RAM - 네트워크 업그레이드) 애플리케이션이 쿼리에 더 나은 논리와 페이지 매기기를 적용하기 시작할 때 이 중 어느 것도 필요하지 않을 것입니다.

Answer