[D2]pinpoint 개발기

1. Pinpoint 개발기
2015-5-22

2. 2
• Backend Java developer
• 2006~
• 비동기 네크워크 라이브러리
• 전사 JAVA FRAMEWORK 지원
• JAVA 트러블 슈팅
• Heap dump, thread dump
• Open source patch, Debugging
• Multi thread, Concurrey
• Pinpoint Technical Leader

3. 3
• 설계에 대해서 어떻게 접근했는지?
• 특히 어려운 부분
• 최초개발시 어떻게 했나?
• 기능에 대해서 어떻게 접근했나?
• 성능을 높이기 위해서
• HBase를 선택한 이유
• 기술 습득시 신경쓸 부분

4. 4

5. 5

6. 6

7. 7
• 예측
• 미래에 있을 일을 미리 추측
• 실제 만들지 않더라도 문제의 본질을 알고 계획을 도출

8. 8
• Pinpoint 개발시 이전에는 경험해 보지 못했던 현상이 발생
• 자꾸 예측이 실패한다.

9. 9
• 과거
• 예측이 거의 다 들어맞았음.
• 80~90%
• 한두번 재시도하면 정확한 예측이 가능했다.
• Pinpoint 개발시
• 예측의 정확도가 급격히 떨어졌음.

10. 10
• 복잡도 증가 -> 불확실성이 높아짐 -> 예측실패

11. 11
• 개발해야 될 부분

12. 12
• 잘 모르는 부분
특히 더
복잡한
부분

13. 13
• 난이도를 배제 단순히 생각
• 개발해야 것 3배
• 잘 모르는 것 2개
• 3*2 = 6배가 더 어려워짐

14. 14
• 과거
내가 해결할수
있는 복잡도
내가
해결한
문제
내가 해결
한 문제
내가 해결한
문제

15. 15
• 과거
내가 해결할수
있는 복잡도 내가 해결한
어려운
문제
예측 실패
예측 실패 예측 실패

16. 16
• Pinpoint 개발시
해결해야 하는 문제
해결안됨

17. 17
발생한 현상
• 설계 실패
• 예측한 내용이 맞지 않는 빈도가 대폭 상승.
• 예측의 정확도가 낮아짐.
• 방안 A : 정확도 35%
• 방안 B : 정확도 30%
• A, B말고 다른 방안을 더 찾아낸다. : 30%
• 확신이 들지 않음
• 정확도가 낮으니 어떤 선택이 최적인지 모르겠음.
• 그냥 어떻게 해야 될지 모르겠음.

18. 18
해결해야 하는 문제
• 예측의 정확도를 높이기 위해 노력
이걸 증가시키는것

19. 19
• 택도 없음.
• 좀 더 많이 생각하고 신중하게 접근했으나 별반 차이 없음
• 사람의 인지 능력에는 한계가 있음.
• 이걸 갑자기 극단적으로 키우는것은 불가능.
• 사람이 처리할수 있는 복잡도에는 한계가 있다.
• 이 방법으로 안될것을 실감.
• 극소수의 선택받은 자는 할수 있을지도 모름.
중요한 점 : 내가 선택받은 자가 아님

20. 20
• 실패가 아니고 시행착오
• 시행착오는 이제 설계의 일부.
• 내 능력에는 한계가 있기 때문에, 필연적으로 발생함.
• 조금만 실패하고, 실패시의 비용을 낮추야 한다.
• 틀릴것을 가정하고 일을 진행한다.
• 내가 감당할 수 있는 부분만 예측
• 가까운 미래만 예측한다.
• 먼 미래를 예측 할수록 정확도가 떨어짐.

21. 21
• 완벽한 코드 X
• 변경에 유연하게 대처할 수 있는 코드
• 연관성있는 코드와 자료구조를 집약
변경이 필요할때 리팩토링을 할수 있는 코드면 충분히 멋지다.
• 변경 비용이 100이 들었을때, 30만 들게 해도 충분하다.
• Interface의 구현체를 변경하면 돌아가는것이 반드시 필요한것은 아님.
• 단순(Simple)해야 함
• 변경을 빠르게 하려면 단순해야 함
• 핵심이 아닌 기능 추가는 뒤로 미름
• 문제의 핵심을 완전하게 이해할때까지
• 판단에 확신이 들때까지
• 방법을 찾기 위해 개발을 시도

22. 22
• 실패하는 것은 자체는 문제가 아님
• 올바로 작동하지 않는다고 걱정하지 마라.
만일 모든 게 잘 된다면, 굳이 당신이 일할 이유가 없다
(Mosher’s Law of Software Engineering)
https://subokim.wordpress.com/2015/03/12/101-great-computer-programming-quotes
• 문제를 해결하지 못하는것이 문제
• 완벽한 해결책이 필요한 것도 아니다.
• 문제가 100생겼는데. 개선해서 30만 발생해도 충분히 멋지다.

23. 23
• Java Agent를 어떻게 만들되는지?
• 해당 도메인의 직접적인 경험이 없다.
• 레퍼런스도 부족 : 간접경험
• 지금도 가장 어려운 부분
• 설계를 어떻게 해야 될지 잘모르겠음.
• Class를 어떻게 잡아야 되는지?
• 특정 기능을 구현하기 위해 뭐가 필요하지?
• 어설프게 머리로 생각하니깐 실패확율이 높다.
• 문제 자체를 관찰하고 원리를 이해하는게 중요함.
• Pinpoint의 API트레이스는 JAVA스택머신의 동작을 흉내낸것에 지나지 않음.
• 모르는 상태에서 대단한걸 만들려고 하면 대단한 실패를 한다.

24. 24
• 문제 해결을 위한 도메인 모델은 우리가 만드는 것이 아니라 발견하는
것이다
• 도메인 모델 자체는 우리의 인식의 경계선에서 관찰하고 인지하여 그것
을 언어로 표현하는 것이므로 우리는 이러한 반복적인 탐구 과정을 통
해 모델을 정제해 나가는 것으로서 보다 정확한 모델을 얻는 것이 가능
해 진다.
• 이러한 이유로 처음부터 완벽한 모델을 얻기는 쉽지 않다. 여기서 발상
의 전환이 필요해진다. 처음 얻어지는 모델은 틀린 것일 수 있다는 가정
하에 일을 진행 시키는 것 이다.
문제 영역에 대한 올바른 이해
http://www.moreagile.net/2014/12/1.html

25. 25
• DDD에서 중요하다고 한것을 상당수하지 않았다.
• JAVA 개발자
• 성능 분석 & 트러블슈팅업무 수행
• Network 라이브러리 개발 등을 개발
• Java Framework 패치 등등
• HBase는 Oracle동작 원리를 통해 간접이해
• Distributed Trace 도메인은 Dapper 문서 간접이해
• Pinpoint개발에 필요한 도메인 지식이 이미 있었음.
• 부족한 부분은 APM 도메인으로 한정
• 불편함을 느껴서 개선하고 싶은 분야의 고도화, 자동화를 추진하
면 복잡도를 내릴 수 있다.

26. 26
• 복잡도가 높고 아는게 없는 신규 프로젝트
• 핵심 기능 & 가능성을 조사하고 안될거 같으면 포기하자
• 안하는게 방법일수도 있고, 다른 사람이 할수도 있다.
• Fail Fast
• 최초 개발 시도시
• 성공확율 -> 성공 3 : 실패 7

27. 27
• 진짜 만들어 낼수 있는지 검증작업에 들어감.
• Bytecode Instrumentaion을 구현해 낼수 있나
• Google Dapper를 보고 Distributed Transaction Trace를 구현해 낼수 있나
• 안될거 같으면 빠르게 버릴려고 했는데
• 하나보니 됬다.
• 사실 계속 구현에 문제가 발생해서 엄청 긴장 많이했음.
• 다음부터 이런거 만들지 말아야지

28. 28

29. 29

30. 30

31. 31
• 극도로 기능을 제한
• 제품개발의 성공에 크게 관여하지 않는 핵심이 아니라고 판단되면 다 삭제
• Ex : 알람 (중요한데 기능인데 안만들었네요. 꼭만들겠습니다.)
• 시간은 항상 모자름. 문제 도메인은 내생각보다 훨씬 어렵다.
• 개발이 가능한지 확인을 하기 위한 시간을 최대한 확보
• 적은 인원으로 시작
• 최초 2명
• 실패하면 회사입장에서는 다 $낭비

32. 32
• 시간 & 리소스는 항상 부족하다.
• 개발의 성공가능성을 판가름하는 핵심 기능에 중점을 둬야 한다.
• 어디서 시간을 벌어야 하는가?
• 제일 만만한건 기능
• 품질 : 이걸 희생하는건 불가능.
• 돈&사람 : 내가 직접적으로 결정할 수 있는것이 아님.
• 일정 : 보통 변경이 힘드나, Pinpiont의 플랫폼 특성상 이것도 조정이 가능.
• 기능 몇 개 더 들어간다고 해서 성공하는게 아님
• 기능이 많으면 변경을 가하기 어려움.

33. 33
• Server Map Search algorithm
Node A
Node B
Node C
Node D
Node F
Node E
Node G
탐색시작 지점

34. 34
• Depth-fitst search (깊이우선탐색)
Node A
Node B
Node C
Node D
Node F
Node E
1
2
3
4
5
Node G
6
탐색시작 지점

35. 35
• Pinpoint를 사용하는 서비스가 증가하면서
• 무제한으로 연관 노드를 탐색하니 조회속도가 느리고,
• 조회 노드가 많을 경우 OOM도 발생
• ServerMap이 너무 복잡해짐.

36. 36
• 탐색 깊이 제한 기능을 만듬.
• 아직 릴리즈 안됨.

37. 37
• Depth-limited search
• 2 Depth
여기까지 탐색
Node A
Node B
Node C
Node D
Node F
Node E
1
2
3
4
5
Node G
탐색시작 지점

38. 38
• 뭔가 이상하다.
• 단순히 탐색 깊이 제한을 걸면 된다고 생각했는데
• 생각지도 못한걸 발견

39. 39
• Depth-limited search
Node A
Node B
Node DNode C
1
2
3
여기 조회가 안됨
이미 방문한 노드라서 스킵

40. 40
• 방안 강구
• 이미 방문한 노드를 마크하는곳에 추가적인 탐색 깊이가 남겨두
고 더 탐색하게 할까?
• 점프 Table같은게 있어야 하나?
• 다른 경로를 따라서 추가적 루트가 있다면, 예외가 생기나?
• 이상하게 난이도 급격하게 상승함.
• 잘못된것 같아 다시 검토

41. 41
• 잘못된 탐색 알고리즘을 선택
• 개발 당시에는 선택을 잘못했다는 것 자체를 인지하지 못했음.
• Depth-fitst search 폐기
• Breadth-first search 로 변경.
• 탐색 로직이 별도 클래스로 분리되어 있었음
• 알고리즘 변경시 추가로 구현해야 기능이 없었다.
• 빠르게 변경가능

42. 42
• Breadth-first search (너비 우선 탐색)
• 문제 자동해결
Node A
Node B
Node DNode C
1
3
2 4

43. 43
• 핵심선택에 의해서 성능의 상당 부분은 이미 결정
• 샘플링
• Bytecode Instrumentation
• HBase 선택
• 나머지 선택은 부수적
• Binary 프로토콜
• UDP
• 비동기 처리
• 나머지 선택은 IO 부하를 줄이기 위한 기능

44. 44
• 하드웨어에서 CPU가 과연 비싼자원인가?
• CPU도 램과 같이 싼자원이 되고있는것 같다.
• 8~9년전에는 고가의 HP Superdom이 24~32 core
• 200~300만원 짜리 표준 웹서버가 24 core
• IO작업은 CPU작업보다 더 비싸고 느리다.
• HBase 리전 서버 : CPU가 하는 일이 없음.
• Snappy 같은 압축 모듈은 반드시 사용하는게 좋다.
• 압축율 5:1 ~ 8:1

45. 45
• 오토 샤딩
• 서버를 꼽기만 하면 용량이 늘어나게 하고 싶었음.
• Write-intensive workload
• RDB의 약점
• Read 성능은 캐시등으로 극복방법이 있으나, Write 성능은 마땅한 방법이 없다.
• Google Dapper 데이터 모델을 그대로 채용하기 위해
• Hadoop 패밀리들과의 연동
• 나중에 기능을 더 추가할수 있을것 같다.
• 운영&모니터링 툴이 좋음
• Cloudera 좋긴한데, 자체 버그도 있으니 주의
• CDH 5.4, 5.4.1 zkCli.sh 가 동작하지 않아 자체 패치.
• https://github.com/Xylus/zookeeper

46. 46
• SAAS 형태로 서비스가 가능
• 사용자는 Agent만 다운로드하면 되니 편하다.
• 모니터링을 위해서 서버를 설치해야 되면 귀찮다.

47. 47
HBase 때문에 잃어버린 가치
• SQL
• 기능이 정말 없다.
• 복잡한 조회로 기능은 그냥 안된다고 보면됨.
• DBA
• 서포트 조직을 잃어 버림.
• 전문가에서 요청하고 DB를 내가 다 알지 않아도 됬는데.
• 이제 개발팀이 다해야 됨. 이게 다 부하.
• RBD보다 검증, 경험도 부족
• 모르는게 많아서 운영하기 어렵다.
• 오래된 CDH 4.7.x 버전을 사용하니 버그가 많음
• HBASE 9.4.x 리전 서버 버그로 장애. HBASE-7711
• Hadoop 무한 루프. HDFS-5225
• 얼마전 HBase 1.0 업그레이드

48. 48
• 모니터링 시스템인데. Eventually consistency로 보이면 이상할
것 같다.
• Hadoop 패밀리쪽이 향후 기능을 더 추가할때 유리하다고 판단
• 모니터링&운영 툴이 부족한듯하다.
• 안될 건 없다.

49. 49
HBase 추천?
• NoSQL은 만능이 아니다.
• Application의 저장소는 선택은 핵심 결정사항.
• 이 선택을 실패하는것은 치명적
• Application에 적합한지 신중히 생각해서 결정
• Pinpoint를 통해 간접경험해보고 결정.
• Pinpoint를 설치해서 운영해보고 판단해보는것도 방법이지 않을까?
• HBase도 개발실패시에 대한 보험중 하나였음.
• Hadoop, HBase의 사용이 증가하면서, 지원에 대한 수요가 자동으로 발생하고 있음.
• 이것만 잘해도 먹고 살수 있을지도 모름.

50. 50
기술 습득시 집중해야 될부분
• 신기술에 관심을 갖는것은 좋다.
• 너무 유행만 따르지 말고 실제 가치가 있는지? 신중히 판단하자.
• 유행하는 기술에 시간+리소스를 투자했다가 망하면? 이게 다 낭비
• 기술에 대한 근본원리를 틈틈히 살펴보자.
• 자신이 사용하지 않는 코드를 보면 보면 어렵기만 하고 재미도 없다.
• 실제 사용하는 프레임워크, 라이브러의 코드를 보자.
• 특정기술은 죽어도 근본 원리는 안죽는다.
• 유행을 타는 기술의 경우 유행이 지났을 경우 감가상각이 매우 심하다.
• 근본 원리는 감가상각이 잘되지 않는다.
• 감가상각이 잘안되기 때문에, 누적치가 생긴다.
• HBase 를 살펴볼때 : RBD의 근본 원리에 빗대서 차이점을 살펴보면 금방.
• JDBC Driver 트러블슈팅 : Network lib와 별반 차이가 없다. 그냥 빗대서 살펴보면 금방.

51. 51
읽어보면 재미있는 링크
• 근본적인 내용은 다 비슷하다.
• 내가 그렇게 못하는 것이 문제
• 소프트웨어 개발의 본질 (The Nature of Software Development)
• http://kwangshin.pe.kr/blog/2015/03/04/the-nature-of-software-development/
• SW 종사자들을 위한, 아주 작은 기여 하나
• http://blog.gorekun.com/?p=1623
• 개발자는 왜 야근을 해서 소중한 시간을 버리는가?
• http://okky.kr/article/279511

52. 52
들어주셔서 감사합니다.