Chapter 04. 성능 테스트 패턴 및 안티패턴

[MinJunKweon]

느낀점

• 우리팀에도 해당되는 내용이 몇 개 있어서 슬펐다..

정리

• 성능 테스트는 정량적(Quantitative)이기 때문에 어떤 질문이든 수치화해서 답변이 가능
• 따라서, 테스트 별로 목표가 독립적이라 도메인을 심사숙고 해야함

성능 테스트 종류

• 지연 테스트 - 페이지 로딩을 얼마나 오래 참고 기다려야하는가?
  • 단순 평균값은 의미가 없음
• 처리율 테스트 - 지연 테스트를 하면서 지연분포가 변하는 시점(변곡점)을 찾기 위함
  • 지연분포가 갑자기 변하는 시점이 최대 처리율
• 부하 테스트 - 트래픽이 많아졌을 때, 버틸 수 있는지를 검증하기 위함
• 스트레스 테스트 - 시스템 여력이 어느 정도인지 알아보는 수단
  • 일정한 수준의 트랜잭션을 계속 걸어서 시스템 성능이 저하되는 것을 확인함
• 내구성 테스트 - 얼마나 오래 애플리케이션이 떠있을 수 있는가?
  • 메모리 누수, 캐시 오염, 메모리 단편화 등 며칠이 지나고 나서 드러나는 문제점을 감지함
  • 평균 이상의 일정 수준 부하를 계속 줘서 시스템 리소스가 고갈되거나 깨지는 시점을 찾음
• 용량 계획 테스트 - 어느 정도 부하를 버틸 수 있는지 알아봄
  • 업그레이드한 시스템이 어느 정도 부하를 감당할 수 있는지 미리 내다보는 테스트
• 저하 테스트 - 부분 실패가 일어났을 때, 복원이 제대로 이뤄지는지, 성능이 살실되는 시점 등을 점검
  • DB 서버에서 RAID 디스크가 빠져버린다거나, 네트워크 대역폭이 갑자기 줄어드는 경우
  • 카오스 몽키 - 한 컴포넌트가 무너져도 다른 컴포넌트는 멀쩡한지 검증하는 테스트

성능 튜닝 시 지켜야할 세 가지 기본 원칙

• 나의 관심사가 무엇인지 식별하고 그 측정 방법을 고민한다.
• 최적화하기 용이한 부분이 아니라, 중요한 부분을 최적화한다.
• 중요한 관심사를 먼저 다룬다.

성능 안티패턴

• 수많은 프로젝트를 수행하면서 밝혀낸 좋지 않은 패턴
• 성능테스트를 하지않는 팀은 안티패턴의 제물이 되기 쉬움

안티패턴의 원인 1 - 지루함

• 개발자가 지루함을 느껴서 필요이상으로 직접 구현함
• 또는, 알려지지 않은 실험적인 컴포넌트를 쓰거나 맞지도 않는 유즈케이스를 억지로 넣음

안티패턴의 원인 2 - 이력서 부풀리기

• 이력서를 부풀리기 위해 프로젝트를 불필요한 방향으로 끌고가는 선택의 발단이 됨

안티패턴의 원인 3 - 또래 압박

• 충분한 논의 없이 진행하면 쓰디쓴 결과를 맛보기 쉬움
• 개발을 빠르게 진행하는 분위기라서 성급하게 중요한 결정을 내리는 것

안티패턴의 원인 4 - 이해 부족

• 툴의 기능을 제대로 알지 못하고 문제를 해결하려고 쓰는 경우
• 툴을 너무 복잡하게 사용해서 오히려 걷어내야하는 경우가 생김

안티패턴의 원인 5 - 오해와 있지도 않은 문제

• 문제 자체가 무엇인지 제대로 이해하지 못한 채 오로지 기술을 이용해서 문제를 해결하려는 자세
• 기술 이슈를 활발히 공유하는 분위기를 적극 장려해야함

[LOG-INFO]

끄적끄적

• 가볍고 재밌는 챕터였음. 그간 경험도 떠올려보고!
• 단지 여기 나오는 안티패턴들이 항상 안좋다고 할 수도 없어서 비판적으로 읽는게 좋을 듯
• 안티패턴
  • 화려함에 사로잡히다: 멋져보이는 최신 기술에 의존해서 해결하려 함 (뜨끔..)

  • Project Loom만 사용하면 비동기 로직 문제 다 해결될거야~~

  • 단숨함에 사로잡히다: 익숙하지 않은 부분은 회피하려 함
  • 성능 튜닝 도사: 성능 향상을 위한 단 한 명의 초인을 지향함
  • 민간 튜닝: 스택오버플로에서 찾은 마법의 팁에 의존하려 함
  • 안되면 조상탓: 충분히 분석하기 전에 성급히 특정 기술의 문제로 지목함

  • 비슷한 경험이 있음: 여러 객체들에 캐싱(TTL 5분)을 걸고 배포를 했는데 얼마 후 5분마다 latency, cpu, memory 등이 튀는 현상이 발견되어 캐시 문제로 성급히 판단하고 캐시 관련 설정/로직만 쳐다보고 있었음

    • 나중에 찾아 보니 특정 테이블을 scan하는 쿼리가 있었고 해당 결과를 캐싱하도록 했는데, 처음엔 해당 테이블의 데이터가 별로 없어서 몇년간 문제가 되지 않았었는데, 마침 최근에 새로운 기획으로 인해 해당 테이블에 데이터가 대량 주입되어 쿼리날릴 때마다 문제가 되던 것

    • 캐시의 TTL이 지나 DB를 조회할 때마다 문제가 발생했던 것이고, 사실상 캐시가 시스템이 죽지 않게 살려주고 있었음

  • 숲은 못 보고 나무만 보다: 전체적인 변경 영향도를 완전히 파악하지 않은 채 일단 그냥 변경해보거나 일부만 프로파일링

  • 이건 설정값 뿐만 아니라, 로직도 마찬가지 인 듯. 복잡한 레거시 로직 하나 변경했다가 장애가 난다거나...

  • 내 데스크톱이 UAT: UAT 환경은 운영계와 똑같이 맞춰야 한다

  • UAT 환경이 운영계와 달라서 서비스가 중단되는 사태가 벌어지면 장비 몇 대 더 추가하는 비용보다 훨씬 더 값비싼 대가를 치르게 됩니다 -> 딱히 공감은 되지 않음. 작은 시스템이면 상관 없는데, 이렇게 할 수 있는 곳이 많으려나? 이런 UAT 환경을 갖춘 채 유지하려면 돈이 너무 많이 듦. 우리 DB 비용만해도... 음....

  • 운영 데이터처럼 만들기는 어려워(Datalite): 운영데이터와 다른 데이터를 가지고 테스트를 하려 함
• 인지 편향과 성능 테스트
  • 환원주의: 시스템을 아주 작은 조각으로 나누어 그 구성 파트를 이해하면 전체 시스템도 다 이해할 수 있다는 분석주의적 사고방식
  • 확증 편향: 원래 갖고 있는 생각이나 신념을 확인하려는 경향성. '사람은 보고 싶은 것만 본다'

  • 원래 갖고 있는 생각이나 신념을 확인하려는 경향성 -> 설명이 이게 맞나? 잘 이해가 안되는데..

  • 확증 편향은 '자신의 신념이나 가치를 확인하거나 뒷받침하는 방식으로' 정보를 검색, 해석, 호의 및 회상하는 경향 - Wikipedia(영문 번역) 이 설명이 더 와닿는 듯

  • 대학 과제로 진행했던 설문조사들이 생각나는 군

  • 전운의 그림자(행동 편향):
  • 위험 편향: 위험을 피하고 변화를 거부함
  • 엘스버그 역설
  • 상황. 90개 중 30개는 파란공, 나머지는 녹색공 또는 빨간공
  • A. 통에서 꺼낸 공이 파란색이면 상금
  • B. 통에서 꺼낸 공이 빨간색이면 상금
  • C. 통에서 꺼낸 공이 파란색 또는 녹색이면 상금
  • D. 통에서 꺼낸 공이 빨간색 또는 녹색이면 상금

  • 보통 사람들은 A,B 중엔 A를 / C,D 중엔 D를 고른다고 함. 근데 A를 고른 사람이 D를 고르는 것은 비이성적이라고 함.

  • 잘 이해 안됨. A,B 중에서 A를 골랐다고 해서 왜 C,D 중에서 D를 고르는게 이성적이지 않은거지??

  • A, B중에서 A를 고른 이유는 암묵적으로 녹색이 빨간공보다 많다고 생각한 것이기 때문에, D를 고르는건 비이성적이고, C를 고르는게 이성적이다라고 나와있는데, 이것은 가정이 잘못된 것 같음. A,B 중에서 A를 고르는 사람 중 녹색이 빨간공보다 많다고 생각하기 때문에 A를 고르는 사람이 얼마나 될까? 단지 A는 확정적으로 1/3이고 B는 불확실하기 때문에 A를 고른 것이지, 암묵적으로 녹색공이 빨간공보다 많다고 생각해서 A를 고른 것은 아닐 것임.

[HaeUlNam]

정리

성능 테스트 유형

• 지연 테스트(Latency test): 고객이 트랜잭션(또는 페이지 로딩)을 얼마나 오래 참고 기다려야 하는지 테스트.
  • Latency를 튜닝하는 목적: 유저 경험 개선 및 SLA(Service Leve Agreement) 조항 이행
• 처리율 테스트(Throughput test): 지연 분포가 갑자기 변하는 한계점이 ‘최대 처리율’인데, 이 수치를 측정하는 것이 목표
• 부하 테스트(Load test): 시스템이 이 정도 부하는 견딜 수 있을까, 없을까?하는 예/아니오 질문에 답을 구하는 과정. 처리율 테스트와 조금 다름
  • e.g. 광고 캠페인, 소셜 미디어 이벤트
• 스트레스 테스트(Stress test): 시스템 여력이 어느 정도인지 알아보는 수단. 현재로선 최대치 처리율을 걸어두고, 시스템이 어떻게 변화하는지 지켜본다
  • e.g. 시간이 갈수록 서서히 동시 트랜잭션이 증가하고, 시스템 성능은 저하됨)
• 내구 테스트(Endurance test): 평균(또는 그보다 높은) 사용률로 시스템에 일정 부하를 계속 주면서 몇 일동안 모니터링하고 리소스가 고갈되거나 시스템이 깨지는 지점을 찾는다.
• 용량 계획 테스트(Capacity planning test): 업그레이드한 시스템이 어느 정보 부하를 감당할 수 있을지 미리 내다보는 것
• 저하 테스트(Degradation test): 어떤 컴포넌트나 전체 서브시스템이 갑자기 능력을 상실하는 시점에 벌어지는 일들을 확인.
  • 넷플릭스의 Chaos Monkey: 운영 환경에 있는 라이브 프로세스를 하나씩 랜덤하게 죽이면서 검증. 이를 잘 구축하려면, 조직 차원에서 시스템 위생, 서비스 설계, 운영 탁월성을 최고 수준으로 확보

성능 튜닝 시 기본 원칙

• 관심사가 무엇인지 식별하고 측정 방법을 고민
• 최적화하기 용이한 부분이 아니라, 중요한 부분을 최적화
• 중요한 관심사를 먼저 다룬다

Best Practices

• 하향식 성능(Top-Down performance): 전체 Application의 성능 양상부터 먼저 알아보는 접근 방식. 작은 코드 섹션별로 정확하기 수치를 얻는 것보다 훨씬 쉽다.
• 테스트 환경 구축: 운영환경과 동일하게 복제.
  • 운영환경과 많이 차이 나는 성능 테스트 환경에서는 실제 환경에서 어떤 일들이 일어날지 예측하기 어렵고, 쓸모 있는 결과를 얻지 못할 가능성이 크다
• 성능 요건 식별: 최적화하려는 핵심 지표를 선별. 이를 성능 비기능 요건(NonFunctional Requirement)라고 함.
  • 목표 예시
    • 95% Percentile 트랜잭션 시간을 100ms 줄인다
    • 기존 하드웨어 처리율을 5배 높일 수 있게 시스템을 개선
    • 평균 응답 시간을 30% 줄인다
• 자바에 특정한 이슈
• SDLC(Software Development LifeCycle)의 일부로서 성능 테스트를 수행.

성능 안티패턴

https://web.obsidianscheduler.com/why-developers-keep-making-bad-technology-choices/

• 이력서 부풀리기: 불필요한 기술을 자꾸 덧댄다
• 또래 압박: 충분한 논의 없이 진행. 섣불리 중요한 결정을 내림
• 이해 부족: 온전히 알지도 못하는데 무턱대고 새로운 툴로 문제를 해결
• 오해와 있지도 않은 문제: 문제 자체가 무엇인지 제대로 이해하지 못한 채 오로지 기술을 이용해서 문제를 해결하려는 개발자

안티 패턴 예시들

• 화려함에 사로잡히다: 멋진 기술을 튜닝 타깃으로 정한다.
• 단순함에 사로잡히다: 전체적으로 애플리케이션을 프로파일링해서 객관적으로 아픈 부위를 들추려 하지 않고 무작정 시스템에서 제일 간단한 부분만 파고든다. 익숙한 것만 하는 태도.
• 성능 튜닝 도사: 모든 걸 성능 튜닝 도사한테 맡기려고 한다?
• 민간 튜닝: 성능 문제를 해결하려고 안간힘을 쓰던 도중, 마법의 설정 매개변수를 발견.
  • 유통기한이 짧아 금세 낡은 유물이 되기 쉽다
• 안되면 조상 탓: 아무 상관도 없는 특정 컴포넌트를 문제 삼는다.
  • 분석도 해보지 않고, 성급한 결론을 내린다
• 숲을 못 보고 나무만 보다: 전체적인 변경 영향도를 완전히 파악하지 않은 채 그냥 변경 해보거나 Application의 국소적인 부분만 프로파일링.
• 운영 데이터처럼 만들기는 어려워: 데이터라이트라고도 하는 패턴. 테이터셋을 단순화하여 테스트하는 경우, 쓸만한 결과를 얻을 확률도 떨어진다

인지 편향과 성능 테스트

• 인지 편향: 인간의 두뇌가 부정확한 결론을 내리게 이끄는 심리 작용. 편향을 보이는 사람이 대개 자신이 그런 줄 모르고 스스로는 아주 이성적이라고 믿는 게 더 큰 문제. 앞선 안티패턴들은 모두 하나 이상의 인지 편향으로 비롯된 것들.
• 행동 편향: 시스템이 예상대로 작동하지 않는 상황 중에 발현되는 편향
  • 시스템 중단을 해결하려고 뭐라도 해야 한다는 막연한 느낌으로 서두르기만 함
  • 어느 서브시스템에서 문제가 발생했는지 밝히지 않은 채 무작정 시스템을 구성 요소로 쪼개어 저수준 코드부터 뒤적이는 것도 마찬가지
• 위험 편향: 위험을 피하고 변화를 거부.
  • 단위 테스트 세트와 운영계 회귀 테스트 체계만 확실히 갖추고 나면 리스크를 상당히 줄일 수 있음
  • 피처 관련된 변경 아니면 잘 변경을 안하려고 함.
• 엘스버그 역설: 인간이 확률을 이해하는데 얼마나 서투른지 잘 보여주는 사례. '알려지지 않은 미지의 것'보다 '알려진 기지의 것'을 추구하는 인간 본연의 욕구에 관한 역설.

더 알아본 내용

Chaos engineering

• Steady state: throughput, error rates, latency percentiles 등 시스템 지표들을 기반으로 안정된 상태 정의
• Define Scenariao: 여러 실제 이벤트들을 기반으로 시나리오 정의
• Test with production traffic: 실제 운영 환경의 트래픽을 가지고 test.
• Automate Experiments

ref: http://principlesofchaos.org/

질문

• 각 서비스별 SLA가 존재하는가? 우리는 딱히 SLA가 명확한 거 같진 않음.
• 성능 테스트는 얼마나 주기적으로 하는지?
• 각 엔지니어가 인지 편향에 빠지는 것보다 각 조직을 책임지는 팀장/매니저가 인지 편향에 빠지는 건 정말 무서운 것 같음.

[minkukjo]

끄적끄적

• 지연테스트 : 종단 트랜잭션에 걸리는 시간을 테스트

• 처리율 테스트 : 현재 시스템이 처리 가능한 동시 트랜잭션 개수 테스트

• 부하 테스트 : 특정 부하를 감당할 수 있는지 테스트

• 스트레스 테스트 : 이 시스템의 한계점은 어디인지 테스트

• 내구성 테스트 : 시스템을 장시간 실행할 경우 성능 이상 증상이 있는지 테스트

• 용량 계획 테스트 : 리소스를 추가한 만큼 시스템이 확장되었는지를 확인하는 테스트 ( Scalue Out/ Up 을 하고 처리량 테스트를 하는 것으로 이해함 )

• 저하 테스트 : 시스템이 부분적으로 실패할 경우를 테스트

• 위 테스트들을 같은 용어로 부르기도 했었는데, 이번 기회에 정리할 수 있어서 좋았다!

• JIT를 타겟으로 삼거나 안삼을 수도 있는 기능이 따로 있구나 처음 알았다.

성능 안티패턴

• 개발자들은 왜 잘못된 기술 선택을 밥 먹듯이 하나

• 그것이 개발자니까

• 지루함 : 맨날 쓰는게 똑같으니까 지겨워서 새로운 시도!

• 이력서 부풀리기 : 이직할라고!

• 또래 압박 : 가면증후군으로 인해 뭔가 남들 앞에서 멋져 보이려고 중요한 결정을 쉽게 함

• 이해 부족 : 하이버네이트 씁시다! 공감하는 부분임. 팀에서 신입 분이 JPA를 안쓰고 하이버네이트만으로 개발해봤는데 진짜 생 지옥이었다고 함.

• 오해와 있지도 않은 문제 : 문제 자체를 잘못 인식해서 오로지 기술을 사용해서 문제를 해결하려는 경향. ( 뜨끔..! )

• 뭔가 이 파트는 이 책이 굉장히 딱딱했는데 좀 유쾌한 파트여서 재밌었음 ㅋㅋ

성능 안티패턴 카탈로그

• 화려함에 사로잡히다 -> 애플리케이션을 측정하고 튜닝해서 진짜 병목을 찾자. 최신 기술로만 문제를 해결하려고 하지 말자.
• 단순함에 사로잡히다 -> 페어프로그래밍을 안하면 해당 업무 전문가가 생겨버린다는 부분에서 페어프로그래밍을 강조하는 부분이 인상깊었다.
• 성능 튜닝 도사 -> 새로 채용된 팀 내 전문가가 다른 팀원들과 지식을 공유하게 만들라는 대목이 인상깊었다.
• 민간 튜닝 -> 스택 오버플로우를 너무 믿진 마세요. 확실히 파악되고 검증된 기술을 씁시다.
• 안되면 조상 탓 -> 이거 관련해서 이야기하고 싶은 썰이 있어서 스터디때 말씀드리겠습니다... ㅋㅋㅋ ( 여기 적기는 너무 민감한 내용 )
• 숲을 못보고 나무만 보다 -> 변경에 있어서 전체적인 영향도를 파악하는게 먼저.
• 내 데스크톱이 UAT -> UAT 환경이 일종의 프로덕션 환경이고 개발자 로컬 환경이 단일 장비 성능 보다 좋아서 문제가 될 수 있음을 지적하고 있음. ( 요즘같이 k8s 기반에선 맞는 말인 듯. ) 근데 한편으론 이런 성능상 이슈가 되는 거대한 기능을 작성할 일이 있나 싶기도..? 테스트 DB에 데이터가 아주 많으면 가능할 지도 모르겠으나 그것도 이미 쿼리 플랜으로 사전에 최적화가 가능함.
• 운영 데이터처럼 만들기는 어려워 -> 그래서 가급적이면 QA분들에게 테스트 환경에서 QA를 받는 편임. 그래야 유의미한 데이터 셋들이 만들어지고 나중에 이걸 활용하기도 좋음.

인지 편향과 성능 테스트

• 환원 주의 : 시스템을 아주 작은 조각으로 나누어 전체 시스템도 다 이해할 수 있는 사고방식.
• 확증 편향 : 화려함에 사로잡혀 테스트 수행 결과를 잘못 이해하여 시스템을 더 나쁘게 만드는 경우가 많음. (어째 이거 좀 공감되는 이야기... ㅋㅋㅋ)
• 전운의 그림자 : 꽤나 공감가는 이야기. 그래서 로깅을 깔끔하게 잘 남기는게 중요한 것 같음. -위험 편향 : 개발자가 가장 경계해야할 편향이 아닐까 싶다. 구더기 무서워서 장 못담구냐라는 속담도 있듯이, 장애날 것이 두려워서 변화하하지 않으면 시스템은 계속해서 노후화될 수 밖에 없음...
• 엘스버그 역설 : 엘스버그 역설 예시 책이 희찬님 말씀대로 이해가 잘 안가서 변호사님이 쓴 글을 봤는데, 아래 내용이 좀 더 잘 이해가 가는 듯 함.. ㅋㅋ

카오스 몽키와 관련해서

https://minkukjo.github.io/cs/2022/07/17/netflix/

• 카오스 몽키 이외에도 넷플릭스 내부 시스템에선 Split-brain, Chaos Kong과 같은 서비스도 있다고 합니다.