TIL

3-7 성능 설계

성능 설계 아이디어

• Well-Architected 프레임워크에서는 ‘성능 효율’ 부문에서 5개 설계 원칙을 제시하고 있다.
  • 고급 기술의 대중화 - 전문 지식이 요구되는 기술은 클라우드에 위임
  • 몇 분만에 전 세계 배포 - 최적인 AWS 리전을 선택하고 사용자 경험 개선
  • 서버리스 아키텍처 사용 - 서버 관리 운영 부하를 경감
  • 실험 횟수 증가 - 유연한 자원 할당으로 적절한 자원 구성을 찾아냄
  • 기계적 동조 고려 - 각 AWS 서비스 사용 사례를 파악해 서비스를 선택

적절한 용량 설계

• AWS 에서는 수요에 맞춰 자동으로 자원 확장이 가능한 Auto Scaling 기능을 제공한다.
  • 자원을 쉽게 확장 가능
  • 때문에 AWS 이용 시 자세한 용량 계획을 세우지 않아도 된다.
  • 그렇지만 자원 이용에 비용은 발생하기 때문에 용량 설계 계획은 필요하다.
• Auto Scaling 주요 정책 중 어느 것을 활용할지 검토해 둘 필요가 있다.
  • 단계 조정 정책
  • 대상 추적 조정 정책
• 아키텍처 디자인 단계에서 용량을 예측할 수 없기에 부하 테스트 수행이 필요하다.

Step 1: 비즈니스 성능 요건

• 우선 비즈니스 특성과 요건을 파악해야 하는데 다음 요건을 상정해보자
  • API 시스템을 전제로 한다.
  • 업무 시간대에 매초 10개 API 콜이 발생
  • 야간엔 업무 시간 대비 1/3 정도의 요청이 발생
  • 마케팅이나 광고 등으로 인해 평소보다 최대 10배 정도 많은 요청이 예상됨
  • 다중 AZ 구성을 기본으로 하지만 AZ 장애가 발생해도 다중 AZ와 동일한 성능을 유지하고 싶다.

Step 2-1: 자원 할당

• ECS 태스크를 시작하려면 컴퓨팅 자원을 할당해야 하는데 초기에는 어느 정도 여유를 가지고 할당하는 것이 좋다.
• ECS에서는 태스크 정의에 할당한 CPU/메모리 크기만큼 시간당 요금이 발생하기에 과도한 자원 설정 또한 피하는 것이 좋다.
• 자원 할당 후 안정적으로 동작하는지 확인 후 테스트를 해보며 성능 균형을 맞춰나가자

Step 2-2: 확장 전략 검토

스케일업과 스케일아웃

• 스케일업
  • 처리 가능한 컴퓨팅 용량 단위를 높이는 것
  • ECS 태스크의 CPU 수와 메모리 값을 늘려 성능 향상
  • 스케일업을 반영하려면 태스크를 재시작해야 한다.
• 스케일아웃
  • ECS 태스크 수를 늘려 전체 처리 능력을 높이는 것
  • 실행 중인 태스크를 재시작하지 않아도 된다.
• 확장성이 높은 스케일아웃 구성을 추천하는 이유
  • 스케일업은 용량 상한에 도달하기 쉽다.
  • 태스크를 재시작하지 않아도 된다.
  • Auto Scaling을 활용해 쉽게 자동 확장이 가능하다.
  • 성능 효율뿐 아니라 가용성과 내장애성도 향상된다.
• ECS/Fargate 스케일아웃 주의점
  • AWS 계정에서 리전당 실행 가능한 태스크 수는 기본 1000개다.
    • 요청을 통해 상한을 높일 순 있고 순간 접속율이 올라가는 경우 할당량 증가 요청을 고려해야 한다.
  • ECS 태스크가 늘어날 때마다 VPC 서브넷 내의 IP 주소가 줄어든다.
    • 태스크에는 ENI가 제공돼 프라이빗 IP가 할당되기 때문
    • 급격한 스케일아웃으로 인해 IP 주소가 부족해질 수도 있다.

Application Auto Scaling 활용

• Application Auto Scaling을 이용하면 수요 변화에 맞춰 컨테이너 수를 자동으로 조절할 수 있다.
• ECS/Fargate에선 CloudWatch 알람에서 정한 임계치에 따라 스케일아웃 또는 스케일인이 실행된다.

단계 조정 정책

• 단계 조정 정책스케일아웃 및 스케일인 조건에 ‘단계’를 설정해 단계적으로 확장할 수 있도록 하는 정책
  • ex) CPU Utilization이 70%까지 상승한다면 태스크 수의 10%를 추가
• 스케일링 이벤트가 발생하는 도중에 발생한 다른 이벤트에도 응답할 수 있다.
  • 스케일아웃 후에도 부하가 줄어들지 않는 경우 여러 단계를 정의해 두면 단계적인 스케일아웃이 가능

대상 추적 조정 정책

• 지정한 지표의 설정 값이 유지되도록 스케일아웃 또는 스케일인을 수행하는 정책
  • 태스크를 얼마나 증가시키면 좋을지에 대한 판단은 하지 않는다.
  • AWS에서 자동으로 태스크 수를 조절하므로 단계 조정 정책에 비해 관리가 편하다.
• 대상 추적 조정 정책 사용 시 파악해야 할 사항과 제한
  • 지표가 지정한 값을 초과하는 경우에만 스케일아웃을 수행
  • 스케일아웃은 고속으로 진행하지만 스케일인은 천천히 실행한다.
  • 여러 지표의 목푯값을 지정할 수 있어 어느 하나의 목푯값을 초과하는 경우 스케일아웃이 실행된다.

단계 조정 정책 vs 대상 추적 정책

• 필자의 추천은 ‘대상 추적 조정 정책’이다.
  • 이용자가 직접 설정해야할 부분이 최소한이라 작업 부하를 줄일 수 있음
  • 비용과 성능을 균형 있게 맞출 수 있다는 있음
• 단 목푯값을 밑돌 때 빠른 스케일인을 하고 싶은 경우라던지 제약이 문제가 된다면 단계 조정 정책을 검토하는 것이 좋다.

Step 3: 테스트 수행

• Step 1에서 정의한 성능 요건이 충족되는지 테스트한다.
• 활용 가능한 도구
  • Locust, Apache HTTP server benchmarking tool(ab), Apache JMeter 등
• 미리 소량의 요청을 전송하며 다음 내용을 확인하는 것도 좋다.
  • CloudWatch 지표가 기대한 대로 취득되는가?
  • Auto Scaling의 스케일아웃 및 스케일인이 설정돼 있는가?
  • 애플리케이션에서 에러가 출력되고 있지는 않은가?
  • 로그 출력 내용은 적절한가?

Step 4: 지표 확인

• 성능 테스트를 실행하면서 CloudWatch의 다음 내용을 확인한다.
  • 성능 요건에서 정의한 처리량을 만족하는가?
  • ECS 태스크 정의에 할당한 CPU/메모리 용량이 적절한가?
  • ECS 태스크 정의 각 컨테이너에 할당한 CPU/메모리 용량이 적절한가?
  • Auto Scaling이 잘 동작하는가?
  • Auto Scaling에서 에러가 발생하지 않는가?

Step 5: 용량 할당 및 확장 전략의 수정

• Step 4의 결과에 따라 전략을 수정한다.
• Step 2 ~ 5를 반복하며 최적의 성능 설계를 만들어 나간다.

성능 설계에 필요한 사고방식

• 클라우드에서 성능 설계를 하는 데 있어 중요한 것이 운영 비용과의 균형이다.
  • 적절한 수요를 고려하지 않으면 불필요하게 많은 자원이 할당될 수 있다.
• 클라우드는 확장 가능하지만 이를 현명하게 사용하는 것은 이용자에게 달려있다.
• 지표를 수집하고 적절한 자원 할당과 확장 전략을 세워 최적의 판단을 하는 것이 중요