ݺߣ

ݺߣShare a Scribd company logo

Pinpoint 도입기 - 2016 신림프로그래머 오픈 세미나

•Download as PPTX, PDF•
•
none
none

2016년 신림프로그래머 오픈세미나에서 발표한 슬라이드 입니다.

1 of 50
Downloaded 31 times
PINPOINT도입기 정재한
이야기할 내용 • 나에게 어떤 문제가 있었는지? • 문제를 고민했던 과정에 대해서 • 어떻게 문제를 풀었고 • 그 결과는 어떻게 되는지?
하인리히 법칙이라고 아시나요?
1년 전 이맘때쯤.. 장애 발생 장애 발생 장애 발생 장애 발생 장애 발생 장애 발생 장애 발생
1년 전 이맘때쯤.. 0 200 400 600 800 1000 1200 2010 2011 2012 2013 2014 2015 2016 VOC 건수 • 원인 불명 장애가 장시간 지속.. • 손해 보상 등 금전적인 피해 발생 • 고객 신뢰도 급하락
부끄러운 이야기지만.. • 원인을 한번에 찾아줄 사람이 없었음 • 추측성 작업이 난무 하기 시작.. • 의심 가는 항목 죄다 수정 (S/W , H/W) -> 2차, 3차 장애의 원인 • 장애 시간이 길어질수록 초상집 분위기 • 시간이 지날 수록 근본 원인보다 누구 책임인가? • 이후 사소한 장애 발생시 방어적, 보수적, 소극적 태도 문화가 형성
장애 상황을 잠시 분석 해봅시다
WEB/ WAS DB서버 장애 발생 이렇게 단순하지는 않았습니다
WEB WEB WEB WAS WAS WAS WAS WAS DB서버 DB서버 장애 포인트가 늘어나기 시작 장애 발생
연동 DB 연동 DB WEB WEB WEB WAS WAS WAS WAS WAS DB서버 DB서버 연동 시스템A 연동 시스템A 연동 DB 연동 DB 연동 시스템A 연동 시스템B 연동 DB 연동 DB 연동 시스템A 연동 시스템C 연동 DB 연동 DB 연동 시스템A 연동 시스템D 연동 DB 연동 DB 연동 시스템A 연동 시스템E 연동 DB 연동 DB 연동 시스템A 연동 시스템F 연동 DB 연동 DB 장애 발생 연동 서비스를 다 그리고 보니
연동 DB 연동 DB WEB WEB WEB WAS WAS WAS WAS WAS DB서버 DB서버 연동 시스템A 연동 시스템A 연동 DB 연동 DB 연동 시스템A 연동 시스템B 연동 DB 연동 DB 연동 시스템A 연동 시스템C 연동 DB 연동 DB 연동 시스템A 연동 시스템D 연동 DB 연동 DB 연동 시스템A 연동 시스템E 연동 DB 연동 DB 연동 시스템A 연동 시스템F 연동 DB 연동 DB DB보안 DB보안 DB보안 장애 발생 인프라및 네트워크 장비까지 추가
내가 할 수 있는 일 • 로그 확인 (tomcat log, apache/nginx log 등) • 서버 상태 모니터링 (cpu, memory, load 등) • gc dump, thread dump • 예외 코드 작성 후 소스 배포 개별 서버 모니터링으로 전체 상황을 파악하는데 한계가 있음
분산 아키텍쳐는 꿈 같은 이야기?
더 큰 시스템을 보유한 서비스는? • Google: 900,000 servers • Intel: 100,000 servers (company, Feb. 2010) • 1&1 Internet: 70,000 servers (company, Feb. 2010) • OVH: 65,000 servers (company, Feb. 2010) • Facebook: 60,000 servers (estimate, Oct. 2009) • Rackspace: 59,876 servers (company, May 2010) • The Planet: 48,500 servers (company) • Akamai Technologies: 48,000 servers (company) • SoftLayer: 30,000 servers (company, July 2010) • SBC Communications: 29,193 servers (Netcraft) • Verizon: 25,788 servers (Netcraft) • Time Warner Cable: 24,817 servers (Netcraft) • AT&T: 20,268 servers (Netcraft) • Peer1/ServerBeach: 10,277 servers (company) • iWeb: 10,000 servers (company) 분명 방법은 있을텐데..
좋은 방법에 대한 고민..
모든 서버에 로그를 남기고 조회가 가능하도록 해보자 해야 할 일 • 로그 규격 정의 • 로그 전송 모듈 개발 • ElasticSearch구성, 사용법 학습 • Logstash구성, 사용법 학습 • Kibana구성, 사용법 학습 고민스러운 부분 • 모든 서비스에서 소스 변경이 필요함 • 소스 변경은 내가 할 수 없음.. • 담당자들은 항상 바쁘다..
그러던 중… 지하철에서 고민을 털어놨더니 범균님 께서 툭 던진 한마디.. “ 가 딱인데..” 집에 가자 마자 검색 해봤습니다
이 화면 보자 마자 느낌이 똭!!
필요한 건 이미 만들어져 있다
PINPOINT 소개
• 대규모 분산 시스템의 성능을 분석하고 문제를 진단, 처리하는 Java 플랫폼 • 네이버에서 2012년 7월에 개발을 시작해 2015년 1월 9일에 오픈 소스로 공개 PINPOINT란?
• 분산된 애플리케이션의 메시지를 추적할 수 있는 분산 트랜잭션 추적 • 애플리케이션 구성을 파악할 수 있는 애플리케이션 토폴로지 자동 발견 • 대규모 서버군을 지원할 수 있는 수평 확장성 • 코드 수준의 가시성을 제공해 문제 발생 지점과 병목 구간을 쉽게 발견 • bytecode instrumentation 기법으로 코드를 수정하지 않고 원하는 기능을 추가 PINPOINT 특징
PINPOINT 아키텍쳐
PINPOINT MAIN
ServerMap
Request/Response Scatter Chart
Realtime Active Thread Chart
CallStack Tree
Inspector
도입 과정
• 어플리케이션 환경 확인 (java version, framework & lib, was 등) • 할당 가능한 서버와 스토리지 확인 • 네트워크 정책 확인 (TCP, UDP 포트 허용 정책) 도입 전 사전 확인
• JDK 6+ • Tomcat 6/7/8, Jetty 8/9 • Spring, Spring Boot • Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient • Thrift Client, Thrift Service, DUBBO PROVIDER, DUBBO CONSUMER • MySQL, Oracle, MSSQL, CUBRID, DBCP, POSTGRESQL, MARIA • Arcus, Memcached, Redis, CASSANDRA • iBATIS, MyBatis • gson, Jackson, Json Lib • log4j, Logback 지원하는 모듈 (2016.06.06 기준)
• HBase 이중화? 샤딩? Hadoop 구성을 해야 하는가? • 해당 지식이 없었음, 배워서 구축할 경우 배보다 배꼽이 더 크다고 판단 • 모니터링을 위한 데이터이기 때문에 손실되어도 문제 없다고 판단 • 단순하게 로컬 디스크로 진행 • Collector는 몇대로? • 우선 1대로 시작하고 서버에 부하가 갈 경우 수평확장 하기로 함 • 현재 Agent가 14대 인데도 잘 버텨주고 있음 • HBase 디스크 용량 산정? • 투입될 웹 서버 1대에서 2주간 프로파일 진행 • 2주 누적 용량 * 서버대수 * 버퍼 20% • 그래도 엄청난 Hbase 디스크 용량 • Hbase TTL (Time To Live)적용 (최근 2주 보관) • 중요도가 낮은 서비스의 경우 샘플링 주기를 낮게 설정 • 오래된 데이터 압축 (주기적으로 major compaction 실행) 도입 과정에서 고민했던 내용
• Step1 : 개발 서버 적용 (당시 개발중인 서비스에 적용) -> 관심 끌기 (팀원, 팀장) • Step2 : 중요도가 낮은 서비스 적용 -> 실제 사례를 통한 PINPOINT 장점 인지 시키기 • Step3 : 미션 크리티컬한 서비스 적용 -> PINPOINT 신뢰도 향상 시키기 • Step4 : Java로 구현된 모든 서비스 적용 -> 전사 APM으로 자리 매김 도입 계획 및 전략 현재
도입 결과
PINPOINT 덕분에 • 이전보다 훨씬 빠르고 명확하게 장애 포인트를 알아낼 수 있게 되었음 • 평소 몰랐던 서비스 패턴을 알게 되었음 (평균 응답시간, 시간대별 Request, TPS 등) • 코드를 보지 않고도 프로세스 흐름이 확인 가능해짐 (리버스 엔지니어링 효과) • 수작업으로 그렸던 시스템 구성도를 PINPOINT내 토폴로지 그래프로 대체하게 되었음 • 많은 부분이 PINPOINT만으로도 확인되기 때문에 터미널에서 하던 단순 반복작업이 줄어 들었음 • 장애 발생시 시각화된 근거 자료를 손쉽게 작성할 수 있게 되었음 개발하는 시간에 조금이라도 더 투자할 수 있게 되었음
사례 소개
필수 파라미터 누락
파라미터 처리 오류
404 오류 발견
배포 이후 서비스 패턴 변경
회원 가입 느림 ˳ѫ
응답 속도 느린 프로세스 패턴 인지
외부 API의 비정상 응답으로 인한 StackOverFlowError
잘못된 JPA 사용
연동 서버 별 Request 확인 연동A 연동B 연동C 연동D 연동E
데모
데모 구성 testapp1 Agent testapp2 Agent • Sleep 3,5,7 초 테스트 • CPU, Memory 부하 테스트 • 외부 API 호출 테스트 • 분산 트랜젝션(RPC) 호출 테스트 HBase Collector Web
좋은 기술을 오픈소스로 제공해준 네이버와 컨트리뷰터에게 감사 마지막으로!!
감사니다

More Related Content

Pinpoint 도입기 - 2016 신림프로그래머 오픈 세미나

  • 2. 이야기할 내용 • 나에게 어떤 문제가 있었는지? • 문제를 고민했던 과정에 대해서 • 어떻게 문제를 풀었고 • 그 결과는 어떻게 되는지?
  • 5. 1년 전 이맘때쯤.. 0 200 400 600 800 1000 1200 2010 2011 2012 2013 2014 2015 2016 VOC 건수 • 원인 불명 장애가 장시간 지속.. • 손해 보상 등 금전적인 피해 발생 • 고객 신뢰도 급하락
  • 6. 부끄러운 이야기지만.. • 원인을 한번에 찾아줄 사람이 없었음 • 추측성 작업이 난무 하기 시작.. • 의심 가는 항목 죄다 수정 (S/W , H/W) -> 2차, 3차 장애의 원인 • 장애 시간이 길어질수록 초상집 분위기 • 시간이 지날 수록 근본 원인보다 누구 책임인가? • 이후 사소한 장애 발생시 방어적, 보수적, 소극적 태도 문화가 형성
  • 7. 장애 상황을 잠시 분석 해봅시다
  • 10. 연동 DB 연동 DB WEB WEB WEB WAS WAS WAS WAS WAS DB서버 DB서버 연동 시스템A 연동 시스템A 연동 DB 연동 DB 연동 시스템A 연동 시스템B 연동 DB 연동 DB 연동 시스템A 연동 시스템C 연동 DB 연동 DB 연동 시스템A 연동 시스템D 연동 DB 연동 DB 연동 시스템A 연동 시스템E 연동 DB 연동 DB 연동 시스템A 연동 시스템F 연동 DB 연동 DB 장애 발생 연동 서비스를 다 그리고 보니
  • 11. 연동 DB 연동 DB WEB WEB WEB WAS WAS WAS WAS WAS DB서버 DB서버 연동 시스템A 연동 시스템A 연동 DB 연동 DB 연동 시스템A 연동 시스템B 연동 DB 연동 DB 연동 시스템A 연동 시스템C 연동 DB 연동 DB 연동 시스템A 연동 시스템D 연동 DB 연동 DB 연동 시스템A 연동 시스템E 연동 DB 연동 DB 연동 시스템A 연동 시스템F 연동 DB 연동 DB DB보안 DB보안 DB보안 장애 발생 인프라및 네트워크 장비까지 추가
  • 12. 내가 할 수 있는 일 • 로그 확인 (tomcat log, apache/nginx log 등) • 서버 상태 모니터링 (cpu, memory, load 등) • gc dump, thread dump • 예외 코드 작성 후 소스 배포 개별 서버 모니터링으로 전체 상황을 파악하는데 한계가 있음
  • 13. 분산 아키텍쳐는 꿈 같은 이야기?
  • 14. 더 큰 시스템을 보유한 서비스는? • Google: 900,000 servers • Intel: 100,000 servers (company, Feb. 2010) • 1&1 Internet: 70,000 servers (company, Feb. 2010) • OVH: 65,000 servers (company, Feb. 2010) • Facebook: 60,000 servers (estimate, Oct. 2009) • Rackspace: 59,876 servers (company, May 2010) • The Planet: 48,500 servers (company) • Akamai Technologies: 48,000 servers (company) • SoftLayer: 30,000 servers (company, July 2010) • SBC Communications: 29,193 servers (Netcraft) • Verizon: 25,788 servers (Netcraft) • Time Warner Cable: 24,817 servers (Netcraft) • AT&T: 20,268 servers (Netcraft) • Peer1/ServerBeach: 10,277 servers (company) • iWeb: 10,000 servers (company) 분명 방법은 있을텐데..
  • 16. 모든 서버에 로그를 남기고 조회가 가능하도록 해보자 해야 할 일 • 로그 규격 정의 • 로그 전송 모듈 개발 • ElasticSearch구성, 사용법 학습 • Logstash구성, 사용법 학습 • Kibana구성, 사용법 학습 고민스러운 부분 • 모든 서비스에서 소스 변경이 필요함 • 소스 변경은 내가 할 수 없음.. • 담당자들은 항상 바쁘다..
  • 17. 그러던 중… 지하철에서 고민을 털어놨더니 범균님 께서 툭 던진 한마디.. “ 가 딱인데..” 집에 가자 마자 검색 해봤습니다
  • 18. 이 화면 보자 마자 느낌이 똭!!
  • 19. 필요한 건 이미 만들어져 있다
  • 21. • 대규모 분산 시스템의 성능을 분석하고 문제를 진단, 처리하는 Java 플랫폼 • 네이버에서 2012년 7월에 개발을 시작해 2015년 1월 9일에 오픈 소스로 공개 PINPOINT란?
  • 22. • 분산된 애플리케이션의 메시지를 추적할 수 있는 분산 트랜잭션 추적 • 애플리케이션 구성을 파악할 수 있는 애플리케이션 토폴로지 자동 발견 • 대규모 서버군을 지원할 수 있는 수평 확장성 • 코드 수준의 가시성을 제공해 문제 발생 지점과 병목 구간을 쉽게 발견 • bytecode instrumentation 기법으로 코드를 수정하지 않고 원하는 기능을 추가 PINPOINT 특징
  • 31. • 어플리케이션 환경 확인 (java version, framework & lib, was 등) • 할당 가능한 서버와 스토리지 확인 • 네트워크 정책 확인 (TCP, UDP 포트 허용 정책) 도입 전 사전 확인
  • 32. • JDK 6+ • Tomcat 6/7/8, Jetty 8/9 • Spring, Spring Boot • Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient • Thrift Client, Thrift Service, DUBBO PROVIDER, DUBBO CONSUMER • MySQL, Oracle, MSSQL, CUBRID, DBCP, POSTGRESQL, MARIA • Arcus, Memcached, Redis, CASSANDRA • iBATIS, MyBatis • gson, Jackson, Json Lib • log4j, Logback 지원하는 모듈 (2016.06.06 기준)
  • 33. • HBase 이중화? 샤딩? Hadoop 구성을 해야 하는가? • 해당 지식이 없었음, 배워서 구축할 경우 배보다 배꼽이 더 크다고 판단 • 모니터링을 위한 데이터이기 때문에 손실되어도 문제 없다고 판단 • 단순하게 로컬 디스크로 진행 • Collector는 몇대로? • 우선 1대로 시작하고 서버에 부하가 갈 경우 수평확장 하기로 함 • 현재 Agent가 14대 인데도 잘 버텨주고 있음 • HBase 디스크 용량 산정? • 투입될 웹 서버 1대에서 2주간 프로파일 진행 • 2주 누적 용량 * 서버대수 * 버퍼 20% • 그래도 엄청난 Hbase 디스크 용량 • Hbase TTL (Time To Live)적용 (최근 2주 보관) • 중요도가 낮은 서비스의 경우 샘플링 주기를 낮게 설정 • 오래된 데이터 압축 (주기적으로 major compaction 실행) 도입 과정에서 고민했던 내용
  • 34. • Step1 : 개발 서버 적용 (당시 개발중인 서비스에 적용) -> 관심 끌기 (팀원, 팀장) • Step2 : 중요도가 낮은 서비스 적용 -> 실제 사례를 통한 PINPOINT 장점 인지 시키기 • Step3 : 미션 크리티컬한 서비스 적용 -> PINPOINT 신뢰도 향상 시키기 • Step4 : Java로 구현된 모든 서비스 적용 -> 전사 APM으로 자리 매김 도입 계획 및 전략 현재
  • 36. PINPOINT 덕분에 • 이전보다 훨씬 빠르고 명확하게 장애 포인트를 알아낼 수 있게 되었음 • 평소 몰랐던 서비스 패턴을 알게 되었음 (평균 응답시간, 시간대별 Request, TPS 등) • 코드를 보지 않고도 프로세스 흐름이 확인 가능해짐 (리버스 엔지니어링 효과) • 수작업으로 그렸던 시스템 구성도를 PINPOINT내 토폴로지 그래프로 대체하게 되었음 • 많은 부분이 PINPOINT만으로도 확인되기 때문에 터미널에서 하던 단순 반복작업이 줄어 들었음 • 장애 발생시 시각화된 근거 자료를 손쉽게 작성할 수 있게 되었음 개발하는 시간에 조금이라도 더 투자할 수 있게 되었음
  • 41. 배포 이후 서비스 패턴 변경
  • 43. 응답 속도 느린 프로세스 패턴 인지
  • 44. 외부 API의 비정상 응답으로 인한 StackOverFlowError
  • 46. 연동 서버 별 Request 확인 연동A 연동B 연동C 연동D 연동E
  • 48. 데모 구성 testapp1 Agent testapp2 Agent • Sleep 3,5,7 초 테스트 • CPU, Memory 부하 테스트 • 외부 API 호출 테스트 • 분산 트랜젝션(RPC) 호출 테스트 HBase Collector Web
  • 49. 좋은 기술을 오픈소스로 제공해준 네이버와 컨트리뷰터에게 감사 마지막으로!!