pinpoint 도입기 - 2016 신림프로그래머 오픈 세미나
TRANSCRIPT
PINPOINT 도입기정재한
이야기할 내용• 나에게 어떤 문제가 있었는지 ?• 문제를 고민했던 과정에 대해서• 어떻게 문제를 풀었고• 그 결과는 어떻게 되는지 ?
하인리히 법칙이라고 아시나요 ?
1 년 전 이맘때쯤 ..
장애발생장애발생 장애발생
장애발생
장애발생
장애발생장애발생
1 년 전 이맘때쯤 ..
2010 2011 2012 2013 2014 2015 20160
200
400
600
800
1000
1200
VOC 건수
• 원인 불명 장애가 장시간 지속 ..
• 손해 보상 등 금전적인 피해 발생• 고객 신뢰도 급하락
부끄러운 이야기지만 ..• 원인을 한번에 찾아줄 사람이 없었음• 추측성 작업이 난무 하기 시작 ..• 의심 가는 항목 죄다 수정 (S/W , H/W) -> 2 차 , 3 차 장애의 원인• 장애 시간이 길어질수록 초상집 분위기• 시간이 지날 수록 근본 원인보다 누구 책임인가 ?• 이후 사소한 장애 발생시 방어적 , 보수적 , 소극적 태도 문화가 형성
장애 상황을 잠시 분석 해봅시다
WEB/WAS DB 서버장애발생
이렇게 단순하지는 않았습니다
WEBWEB
WEB
WASWAS
WASWASWAS
DB 서버DB 서버
장애 포인트가 늘어나기 시작장애발생
연동 DB 연동 DBWEB
WEBWEB
WASWAS
WASWASWAS
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 연동 DBWEB
WEBWEB
WASWAS
WASWASWAS
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
좋은 기술을 오픈소스로 제공해준 네이버와 컨트리뷰터에게 감사
마지막으로 !!
감사합니다