Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

웹서버 부하테스트 실전 노하우

8 870 vues

Publié le

Bestcon 2019에 발표한 웹서버 성능 테스트 실전 노하우 자료입니다.

테스트 케이스 생성부터, 테스트 전략, 데이터 해석 (APM, 인프라 모니터링), 클라우드에서 주의할 사항등 도움이 될만한 내용들만 간추려 전달합니다.

부하 테스트시 어니컴을 불러주세요

Publié dans : Technologie
  • Soyez le premier à commenter

웹서버 부하테스트 실전 노하우

  1. 1. 실전 서버 부하 테스트 노하우 손영수, 차용빈 ysson@onycom.com 어니컴 성능솔루션 사업부
  2. 2. 발표에 앞서 어니컴은 마사회, 대기업 입사 지원 시스템, 글로벌 제약회사, ERP등 다양한 업체의 부하 성능 테스트및 컨설팅을 한 경험을 가진 회사입니다. 이 자료는 부하 테스트 / 성능 측정 노하우를 공유하는 자료입니다. (https://www.facebook.com/imqa.io 에서 자료 공개 예정) 모든 저작권은 어니컴에 있음을 알려 드리며, 원본 출처를 공개하는 조건에서 재 배포를 허락합니다.
  3. 3. 0. 개요 그리고 오해 풀기..
  4. 4. 웹 어플리케이션은 어떻게 동작하나 User Transaction SQL SQL Http File Resource `
  5. 5. 부하 테스트 솔루션은 어떻게 동작하냐? 컨트 롤러 스크 립트 에이전트 에이전트 프로세스 프로세스 쓰레드 1 쓰레드 2 쓰레드 3 쓰레드 4 쓰레드 5 쓰레드 6 USER USER USER USER USER USER 프로세스 프로세스
  6. 6. 부하 테스트 하기 자원을 사용트랜잭션 처리부하발생기 Transaction SQL SQL Http File Resource ` 컨트롤러 가상 유저
  7. 7. 부하 테스트시 실수 하는 것? • 부하만 정말 열심히 준다. • 자 서버 죽었어요? • 개발자 : 원인이 무엇인가요… • 병목 지점을 판단해서 코드 레벨로 말해주기를 원한다. • 성능 테스터 : 전 개발자가 아닌데요… • 고객 : 병목지점을 꼭 찍어서 알려 주셔야죠 • 결론 : 개발자만큼 알아야 한다 (Java, Node, Python등..)
  8. 8. 진짜 우리가 해야 할 것은? Transaction SQL SQL Http File Resource ` 인프라 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  9. 9. 부하 주기 뿐만 아니라 + @를 잘해야 한다. • 부하는 어떻게 발생시키는 가? (Jmeter 잘 쓰기) • 발생된 트랜잭션을 잘 처리하는가? 병목 찾기 (APM 사용하기) • 서버의 자원은 충분한가? (서버 모니터링 - 성능 지표 읽기) • 고급 주제 • 테스트를 현실적으로 잘 할려면 어떻게 해야 하는가? (테스트 계획안) • 테스트에 필요한 요청사항들은? (어떠한 데이터를 수집해야 하나?) • 클라우드 사용시 주의해야 할 것들은? (클라우드의 함정)
  10. 10. 성능 테스팅이란? • 목적 시스템의 병목 지점을 찾는 것!
  11. 11. 성능 테스트 정의 • 정의 : 특정 부하에서 응답성 및 안정성 측면에서, 시스템이 어떻게 동작 하는지, 측정하기 위한 비 기능 테스트입니다. • 얻을 수 있는 것들 : 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성 을 조사, 측정, 검증 또는 검증 할 수 있습니다
  12. 12. 성능 테스트의 종류 부하 / 용량 산정 테스팅 Load/Capacity Testing 스트레스 테스팅 Stress Testing 내구성 테스트 Endurance/Soak Testing 최고점 부하 테스트 Spike Testing
  13. 13. 간단한 정리
  14. 14. 1. JMeter 다루기 7일안에 Jmeter 끝내기 : https://www.guru99.com/jmeter-tutorials.html Blazemeter Jmeter 무료 Webcast : https://www.blazemeter.com/jmeter/ ONYCOM 방문 강좌 : 직원 1명당 10만원 (최소 강좌 100만원부터 시작)
  15. 15. 2. 성능 부하 테스트 안
  16. 16. 주요 논의 사항 • 현 테스트 시나리오 분석 • 테스트 시나리오 보완 방법 • 부하 테스트 진행방안 • 부하 테스트 전략 협의 • 클라우드 기반의 테스트 방안 16
  17. 17. 0. 부하테스트 목적 • 단위 서버(STG 서버) 기준, 최대 동시접속자 수 산정 • 실제 서버 기준, 사용자 시나리오(1) 기반으로 한 테스트 • 실제 서버 기준, 트랜잭션 단위 테스트의 스트레스 테스트(2) • 실제 서버 기준, 부하 테스트(3)를 통한 임계값(Saturation Point) 산정 • 실제 서버 기준, 동시접속자 수, TPS, 응답시간 산정 17 (1)사용자 시나리오 : 실제 마사회 마이카드를 사용하는 사용자의 사용 흐름을 분석하여 테스트 시나리오를 작성함. (2)스트레스(Stress) 테스트 : 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트. (3)부하(Load) 테스트 : 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트.
  18. 18. • Wrk : 간단하게 서버 부하 테스트를 하고 싶을 때 • Vegeta : 초당 몇 개의 부하를 버티는지 테스트 하고 싶을 때 • Gatling : 높은 성능, 시나리오 작성, html 보고서 (코드 작성 필요) • JMeter : 다양한 기능이나 플러그인이 강점 / 빠른 시나리오 작성 가능 • nGrinder : 시나리오, 시나리오 가중치 테스트 불가 , 개별 트랜잭션 TPS 측정에 중점 , Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있음. 18 1. 부하 관련 툴 선정 (장단점.)
  19. 19. 2안. JMETER ü기존 시스템 인터페이스 이용및 변경 적음 üTPS 기반의 단순 테스트에는 유리함 X시나리오 기반 테스트 및 가중치 테스트 불가 X빈약한 리포트 JMETER ü다양한 결과 리포트 쉽게 얻을수 있음 üTPS / 시나리오 기반 /가중치 기반 테스트 가능 ü빠른 부하 스크립트 개발이 가능 (1~3일) ü풍부한 플러그인 제공 (상용, 무료 많음) X진입점 (잘 정리된 자료가 없다) X빈약한 리포트 1. 부하 관련 툴 선정 (부하 발생기) Agent 1안. nGrinder Agent Agent …Agent nGrinder Controller API API API 고객 서비스 고객 서비스
  20. 20. 컨트 롤러 스크 립트 에이전트 에이전트 프로세스 프로세스 쓰레드 1 쓰레드 2 쓰레드 3 쓰레드 4 쓰레드 5 쓰레드 6 USER USER USER USER USER USER 프로세스 프로세스 20 참고. 부하 발생 구조
  21. 21. • 1안) 사용 상황에 맞는 시나리오 수립 후 테스트 (배포전) • 가입 / 수강 / 결재 시나리오 • 딜 종료 후, 결과 확인 시나리오 • 딜 정보 확인 및 배당률 확인 시나리오 • 2안) 사용자로 부터 HTTP(S) 요청을 추출해서 시나리오 산정 (APM 사용) • 내부 APM 연동 후 데이터 수집. (상용, 오픈소스, 유료 15일) • 가능하다면 베타 그룹, 크라우드 테스트를 통해 데이터 수집 할 것을 추천 21 2. 테스트 시나리오 보완 방법 논의
  22. 22. • 고객별 시나리오 도출 • 예) • 경우1_ 5분전에 구매를 완료하는 사용자 비율 • 선 구매 이후 ­> 반복되는 실시간 배당율 확인 • 경우2_ 30~10 초 전에 구매를 완료하는 사용자 비율 • 실시간 배당율 확인 및 실시간 배팅 정보구매 22 1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
  23. 23. 시나리오를 완벽하게 도출하기 위해서 협의 필요
  24. 24. Blazemeter : Jmeter 스크립트 생성 도구(크롬 플러그인) 스크립트 녹화 녹화된 스크립트 편집 다양한 포멧으로 저장
  25. 25. 25 2안) APM의 결과를 추출해서 시나리오 산정 경기 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
  26. 26. • 주요 시나리오 테스트 (Warm-Up 테스트) • 주요 시나리오 선정 후 (가입 , 강좌 수강등) 시나리오별로 얼마나 견디는지 테스트 • • 트랜잭션별 단위 테스트 (Warm-Up 테스트) • Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트 • 주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트) • 위 선정된 주요 시나리오에 가중치를 부여 하여 테스트 • 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50% 26 3. 부하 테스트 진행 방향
  27. 27. 27 3.1. Warm-Up 테스트 진행 (기준 정하기)
  28. 28. 28 3.2. 주요 시나리오 선정
  29. 29. 시나리오 테스트 예시 합격자 발표 시나리오, 1만명씩 늘려서 테스트 부하테스트 1만명 진행 합격자 발표 시나리오는 1만명 이전까지는 큰 문제가 발생하지 않았다. 다만, 1만명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList 에서 문제가 발생하는 것을 확인 할 수 있었다. 평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만명에서는 8초 정도의 응답시간을 보이기도 했다. 2만명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생 하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다. 대부분 느린 쿼리로 인해 발생 한 문제로 추측이 된다. 부하테스트 2만명 진행 부하테스트 3만명 진행 A사 부하테스트 예시 29
  30. 30. Connection Pool 수치는 현재로서는 적당한 수치로 보인다. 다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인 할 수 있었다. 최대 3만명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다. 4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다. 2만명 이상의 사용자가 방문 했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다. / 호출과 /getRecruitList의 성능 저하가 대부분이었으며, / 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다. 메인 페이지 호출 빈도를 줄이거나 메인페이지의 데이터를 Caching하는 방법으로 호출 빈도를 줄이는 것도 한 방법으로 보 인다. 또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다. 합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도) 3. 테스트 결과 이때 문제가 되는 트랜잭션들을 선정해 트랜잭션 단위 테스트 진행 시나리오 테스트 분석 후 - 테스트 결과 공유 30 A사 부하테스트 예시
  31. 31. 부하테스트 2만명 TC 02 - 01 에 비해서 역시 좋은 성능을 보여주고 있다. 대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한색으로 표시된 것으로 보아 대부분은 안정적으로 데이터 응답을 하는 것으로 보인다. 부하테스트 3만명 진행 개선 후 시나리오 테스트 Before / After 비교 A사 부하테스트 예시 31 부하테스트 3만명
  32. 32. 3. 테스트 결과 합격자 발표 시나리오를 비교했을 경우 80% 이상의 성능 향상을 보여주고 있다. 3차 테스트에서는 합격자 발표 부하테스트의 최대 수용 가능한 사용자 수를 측 정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다. 응답시간이 늦은 서비스가 보였으며 해당 부분은 Join문을 사용하고 있어 어쩔 수 없이 저하가 발생 할 수 밖에 없는 부분으로 보인다. 사용자 3만명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이는 전 체에 1%에 해당되는 수치이다. 시나리오 부하테스트 후, 해석 결과 전달 A사 부하테스트 예시 32
  33. 33. 1) 현 서비스 최소 단위 구성하기 • 현 서비스의 최소 단위 WAS, DB등의 세트를 구성해서 테스트 • 섹션 3에서 언급한 시나리오별, 트랜잭션별, 시나리오 가중치 별 테스트 • 최소 단위 세트에서 부하 분석후 컨설팅 리포트 제공 • 주요 트랜잭션 테스트의 성능 고도화에 집중 33 4. 부하 테스트 단계별 전략
  34. 34. 2) 최소 셋트에서 문제점 도출및 안정화 진행 • PRETEST (사전 테스트) : 관련 스크립트및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링) • MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주) • CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트 • REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증 34 4. 부하 테스트 단계별 전략
  35. 35. 3) 실 서비스 대용량 부하 테스트 • 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트 • 클라우드 기반의 100대 인스턴스로 테스트 (100대면 가상 유저 4000명 정도는 가능) • 주요 성능 리포트 제공 35 4. 부하 테스트 단계별 전략
  36. 36. 솔루션 개요 주요 기능 제니퍼 소프트 업계 1위의 APM APM의 시초 강력한 지원 ∙ 실시간 트래픽 수집의 최강자 다양한 파트너와 연동 (모바일 , DB 모니터링 연동) 실 사례및 문제 발생 시 도와줄 파트너가 많다 리포트및 분석 기능이 강력함, 타사 제품과 연동성 강력, 업계 1위의 안정성 Elastic APM 다양한 언어를 지원하 는 APM • 다양한 언어를 지원 (java,node,python, ruby 등) • 오픈소스 로 누구나 사용 가능함. • 실시간 장애 인지보다는 장애 후 원인 분석 가능 Java 이외의 언어도 , 무상으로 쓸수 있는 APM (Java, .NET, Ruby, Python, Node. Go 등) 36 5. 관련 툴 선정 (APM)
  37. 37. 솔루션 개요 주요 기능 와탭 SaaS형 APM으로 큰 설치없이 서버 용 량 걱정없이 무료로 사용가능 (15일 제한) ∙ 막대한 트래픽의 모니터링을 클라우드 상에서 다 수집이 가능 (15일후 데이터 자동 파기) ∙ 트랜잭션에서 걸리는 스택까지 수집이 가능 (강점- 타 APM 없는 기능) ∙ 정확한 동시 접속자 수 산정 가능 (실 유저로 수집이 가능함) 리포트및 분석 기능이 강력함, 15일간 모든 기능을 사용 가능 Pinpoint End 2 End 트랜잭션 분석이 가능함 ( 네이버 개발 ) • 제니퍼와 유사한 기능을지고 있음 • End2End Transaction을 모니터링 하는데 초점이 있음 내부 솔루션 설치의 어려움 / 적절한 용량 논의후 구성 가능한 고객이 사용하는 APM으로 데이터 해석이 필요함. 유료 제품인 경우 APM은 라이센스 문제로 최소 셋트 테스트에만 적용 37 5. 관련 툴 선정 (APM)
  38. 38. 38 5. 왜 Jmeter를 사용해야 하나? 클라우드 연동 구글 클라우드를 활용한 부하 분산 테스트의 경우에는 JMeter 2.9를 이용합니다. JMeter 4 버전 이후에는 SSL 관련 옵션 등 많은 변경부분 때문에, 2.9를 사용합니다. 참 고 X 권장 OS : OS X, Linux
  39. 39. 부하 분산 테스트 환경 구축 39 jmeter controller jmeter server
  40. 40. 7.1. JMeter Controller 설정 40 remote_hosts=10.0.0.2,10.0.0.3,...,10.0.0.n
  41. 41. 통신 포트 설정 변경 41
  42. 42. 통신 포트 설정 변경 42 jmeter-server 설정 server_port=2099 server.rmi.localport=4000 jmeter controller 설정 remote_hosts=10.0.0.2:2099 client.rmi.localport=4001
  43. 43. 8. 테스트 시 주의 사항 43
  44. 44. 44 Jmeter + Google Cloud 관련 프로젝트 링크 - https://bit.ly/2AVq0pk X 권장 OS : OS X, Linux 단 바로 작동하지 않음. 요즘 Google Cloud 관련 API를 변경 및 추가 후 사용할 수 있음. 중급 기준 : 1달 정도 추가 개발 필요.
  45. 45. 1) 버킷 생성하기 45 Console 화면에서 Storage 페이지로 이동한다
  46. 46. 1) 버킷 생성하기 46 Storage 버킷을 만듭니다. 버킷 이름은 원하든 대로 입력을 해주시고, 만들기 버튼을 누른다. gcp_upload_files 폴더에 있는 내용을 전체 올려줍니다
  47. 47. 1) 버킷 생성하기 47 Jmeter-server 파일을 올려줍니다
  48. 48. 2) 구글 클라우드 플랫폼 인증 설정 4 8 구글 클라우드 플랫폼에 스크립트가 접근하기 위해서는 API 사용자 인증이 필요하다. 그림과 같이 API 및 서비스 메뉴로 접근한다
  49. 49. 2) 구글 클라우드 플랫폼 인증 설정 4 9 API 및 서비스 메뉴에서 사용자 인증 정보 탭으로 이동한다
  50. 50. 2) 구글 클라우드 플랫폼 인증 설정 5 0 OAuth 동의 화면 탭으로 이동하여, 애플리케이션 이름 부분에 원하는 이름을 적은 후 저장한다
  51. 51. 2) 구글 클라우드 플랫폼 인증 설정 5 1 사용자 인증 정보 탭으로 다시 이동하여, 사용자 인증 정보를 만든다. 이때 OAuth 클라이언트 ID를 선택한다
  52. 52. 2) 구글 클라우드 플랫폼 인증 설정 5 2 기타를 선택한 후 원하는 이름을 적어 클라이언트 ID 를 만든다
  53. 53. 2) 구글 클라우드 플랫폼 인증 설정 5 3 클라이언트 ID와 클라이언트 보안 비밀은 따로 저장을 해 두십시오. 스크립트에서 사용이 됩니다. 설정이 이 페이지에서 다시 확인 할 수 있다
  54. 54. 4) 스크립트 실행 방법 5 4 # JMETER 인스턴스 생성하기 (PREFIX에 구분할 수 있는 접두어 설정) (NUMBER에 생성하고 싶은 인스턴스 갯수) ./jmeter_cluster.py start --prefix <PREFIX> <NUMBER> # JMETER 서버들 종료하고 반납하기 ./jmeter_cluster.py shutdown --prefix <PREFIX> # JMETER 클라이언트를 실행 방법 ./jmeter_cluster.py client
  55. 55. 3. 서버 성능 분석하기
  56. 56. 진짜 우리가 해야 할 것은? Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  57. 57. 1) 운영체제에서는 어떤 데이터를 수집해야 하나?
  58. 58. 60초안에 서버 성능 보기. http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top load averages kernel errors overall stats by time CPU balance process usage disk I/O memory usage network I/O TCP stats check overview
  59. 59. 어려운 방법보다 USE 메소드를 이용. Saturation Utilization X Errors Utilization : 얼만큼 자원을 썼는지? Saturation : 얼마나 많은 부하(extra works)가 들어왔는지. Error : 발생한 에러는?
  60. 60. USE 메소드의 예 Resource Type Metric CPU utilization CPU utilization CPU saturation run-queue length Memory utilization Available memory Memory saturation Paging or swapping NetworkInterface utilization RX/TX tput / bandwidth StorageDeviceI/O utilization Device busy percent StorageDeviceI/O saturation Wait queue length StorageDeviceI/O errors Device errors
  61. 61. USE 메소드의 예. Resource Utilization Saturation Errors CPU mpstat-PALL1, sumnon-idlefields vmstat1,"r" perf Memory Capacity free­m,"used"/"total" vmstat1,"si"+"so"; demsg|grepkilled dmesg StorageI/O iostat­xz1, "%util" iostat­xnz1, "avgqu-sz">1 /sys/…/ioerr_cnt; smartctl Network nicstat,"%Util" ifconfig,"overrunns"; netstat­s"retrans…" ifconfig, "errors"
  62. 62. 주의할 점 MemFree vs MemoryAvailable. cat /proc/meminfo MemFree보다 MemAvailable을 이용하세요. Ubuntu 14.04이상 (커널 3.14) MemFree: The amount of physical RAM, in kilobytes, left unused by the system. MemAvailable: An estimate of how much memory is available for starting new application
  63. 63. 2) 고객이 클라우드를 사용한다면..
  64. 64. 클라우드는 공유 자원..
  65. 65. 클라우드는 공유 자원.. 요청이 많으면 즉 내 차례를 기다리거나..
  66. 66. 클라우드는 공유 자원.. 상황에 맞게 제한된 자원을 나눠가지던가..
  67. 67. 잘 동작하던 게임서버에서 User들이 갑자기 튕겨나간 사례.
  68. 68. IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우 드에선 늘 발생할 수 있는 문제.. 몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정 알고보니 자원의 제약..
  69. 69. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Provisioned IOPS 구입!
  70. 70. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Premium Storage Disk 구입!
  71. 71. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개. § IOPS § Disk Queue Length (win) / iowait (linux) § CPU Steal Time 등.. § http://bencane.com/2012/08/06/troub leshooting-high-io-wait-in-linux/
  72. 72. 클라우드 에서의 성능 측정이 어려운 이유.. 첫째, 일부 부분은 우리가 통제할 수 없다. 우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만 어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다. 우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나 단절 되는 이유를 알아내기 매우 힘들다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  73. 73. 4. APM 다루기
  74. 74. 진짜 우리가 해야 할 것은? Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  75. 75. APM의 핵심은 무수하게 많은 트랜잭션을 잘 분석하는 것 3:04 3:05 3:06 3:07 40초 80초 10초
  76. 76. 평균 응답시간 – 과연 최적의 표현??
  77. 77. 뉴렐릭, Elastic APM – 사후 분석 , 개발자 관점
  78. 78. AppDynamics - 운영자 중심의 APM
  79. 79. 제니퍼 류 (스카우터, 와탭, 튜나)
  80. 80. 4. 비공개 노하우 공유
  81. 81. Slow Tx보다는 시간 * 빈도수 = 총합 시간이 많은 Tx를 먼저 시행
  82. 82. 장애 스냅샷에 대한 유형 판단 능력을 키워라 A. 수직선 B. 수평선
  83. 83. 83 A. 수직선 (Vertical Lining) 하나의 서버에서만 또는 여러 대의 서버에서 동일하게 이러한 상황이 발생 했는지 파악을 해야합니다. 하나의 서버에서만 이러한 현상을 보인다면, 메소드 락(Java Synchronized) 이나 그 애플리케이션 서버만의 문제지만, 여러 대의 애플리케이션 서버에 서 동일하게 이러한 수직 선이 생기면, 외부의 문제로 보셔야 합니다. 대부분 데이터베이스와 연관된 문제로 DB Lock, Connection Pool, 또는 공 유하고 있는 자원의 부족 문제를 의심해 보셔야 합니다. 또는 특정 외부 http call이 제한된 user만 받거나, 제한된 자원을 쓰고 있는 경우에 호출할 때마다 느려지는 경우 이러한 현상을 볼 수 있습니다.
  84. 84. 84 B. 수평선 (Horizontal Lining) 특정 시간 만큼 공백을 이루면서 가로로 선이 계속 발생하는 현상 이 그림은 20 시 2분경, 응답시간 12초 정도 쯤에서 에러들이 가로로 일직선을 이루는 모습을 보실 수 있습니다. 이런 현상이 서비스 운영 시 발생한다면 다음과 같은 상황을 의심 1) 자원을 획득하기 위해 반복적으로 재시도 할 때 ­ 동일 트랜잭션(URL)인 경우 자주 발생합니다. 특정 자원을 획득하지 못 해 주기적으로 재시도를 하는 로직을 넣은 경우입니다. 2) 30, 60, 90초 라인이 형성되는 경우 ­ DB Timeout을 의심해 봐야 합니다. 30초의 타임 아웃이 풀려, 일제히 찍히는 경우가 발생합니다.
  85. 85. 85 C. 초기화에 의한 일시적인 병목현상 위의 그림은 특정시간에 시스템이 오픈 되고, 다수의 사용자가 대기 상태에 있다 가 동시에 접속을 시도하면서 발생하는 현상입니다. 약 5분 동안 병목 현상을 보 이다가, 서비스가 정상화 되었습니다. 이러한 현상은 수강신청이나 마사회와 같은 특정 시간에 티켓 발급 시 종종 발생 합니다. 사용자의 일순간 급격한 증가가 원인이라면 지속적으로 서비스가 느려 져야 하는데, 몇 분 후 다시 응답이 정상상태로 돌아온 것으로 보아, 초기화 과정 에서 발생한 일시적인 병목이라고 보는 것이 맞습니다. 일반적으로 Java-Web의 초기화 과정 중 주요한 부하 원인들은 다음과 같습니다. - JSP 컴파일 - Class Loading - 메뉴/권한 정보 초기화 - DB, 외부 연동 POOL 초기화
  86. 86. 하지만 실제는 복합적으로 결과가 나온다. 실제 Tx를 보면 문제를 해결할 수 있을까?
  87. 87. Filter Chain에 걸려 있는 상황이 빈번하다
  88. 88. 8 8 메모리 자원 부족으로 인한 Thread (FilterChain) 대기 현상 발생 8000계좌를 초과해서 들어오게 되면, Thread가 Stuck되는 현상이 발생하여, 전체 유저가 늦어지는 것보다는 적절한 Threadshold를 주어 기존 유저들이라도 쾌적하게 대응하는 것들이 필요함
  89. 89. 8 9 원인 메모리 자원의 부족으로 - Thread (FilterChain) 대기 현상 발생 Apache는 동시 접속이 늘어날수록 메모리를 많이 사용하게 되며, 응답시간도 느려지는 Thread Per Connection 구조를 가짐 마사회는 3G Heap Memory의 한계점에 도달하면 Thread가 Stuck 되는 현상이 발생함. (2~3G를 넘으면 FullGC 시 불리) 그리하여, Apache의 메모리를 늘리기 보다, 물리적 /VM 서버 메모리 스펙을 늘리고, Tomcat Instance를 늘리기를 추천 클러스터링/로드발랜서로 묶어서 제공하면 이 현상이 줄어들 수 있음. 참조 글 - https://bcho.tistory.com/788
  90. 90. 올바른 부하테스트를 위해서는. Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  91. 91. 발표 : 모바일 성능 분석 솔루션 : IMQA 자동화 테스트 솔루션 : mTworks 을 전시하고 있으니 많은 참여 바랍니다.
  92. 92. 감사합니다.

×