Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[D2]pinpoint 개발기

10,161 views

Published on

[D2]pinpoint 개발기

Published in: Technology
  • Be the first to comment

[D2]pinpoint 개발기

  1. 1. Pinpoint 개발기 2015-5-22
  2. 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. 3 • 설계에 대해서 어떻게 접근했는지? • 특히 어려운 부분 • 최초개발시 어떻게 했나? • 기능에 대해서 어떻게 접근했나? • 성능을 높이기 위해서 • HBase를 선택한 이유 • 기술 습득시 신경쓸 부분
  4. 4. 4
  5. 5. 5
  6. 6. 6
  7. 7. 7 • 예측 • 미래에 있을 일을 미리 추측 • 실제 만들지 않더라도 문제의 본질을 알고 계획을 도출
  8. 8. 8 • Pinpoint 개발시 이전에는 경험해 보지 못했던 현상이 발생 • 자꾸 예측이 실패한다.
  9. 9. 9 • 과거 • 예측이 거의 다 들어맞았음. • 80~90% • 한두번 재시도하면 정확한 예측이 가능했다. • Pinpoint 개발시 • 예측의 정확도가 급격히 떨어졌음.
  10. 10. 10 • 복잡도 증가 -> 불확실성이 높아짐 -> 예측실패
  11. 11. 11 • 개발해야 될 부분
  12. 12. 12 • 잘 모르는 부분 특히 더 복잡한 부분
  13. 13. 13 • 난이도를 배제 단순히 생각 • 개발해야 것 3배 • 잘 모르는 것 2개 • 3*2 = 6배가 더 어려워짐
  14. 14. 14 • 과거 내가 해결할수 있는 복잡도 내가 해결한 문제 내가 해결 한 문제 내가 해결한 문제
  15. 15. 15 • 과거 내가 해결할수 있는 복잡도 내가 해결한 어려운 문제 예측 실패 예측 실패 예측 실패
  16. 16. 16 • Pinpoint 개발시 해결해야 하는 문제 해결안됨
  17. 17. 17 발생한 현상 • 설계 실패 • 예측한 내용이 맞지 않는 빈도가 대폭 상승. • 예측의 정확도가 낮아짐. • 방안 A : 정확도 35% • 방안 B : 정확도 30% • A, B말고 다른 방안을 더 찾아낸다. : 30% • 확신이 들지 않음 • 정확도가 낮으니 어떤 선택이 최적인지 모르겠음. • 그냥 어떻게 해야 될지 모르겠음.
  18. 18. 18 해결해야 하는 문제 • 예측의 정확도를 높이기 위해 노력 이걸 증가시키는것
  19. 19. 19 • 택도 없음. • 좀 더 많이 생각하고 신중하게 접근했으나 별반 차이 없음 • 사람의 인지 능력에는 한계가 있음. • 이걸 갑자기 극단적으로 키우는것은 불가능. • 사람이 처리할수 있는 복잡도에는 한계가 있다. • 이 방법으로 안될것을 실감. • 극소수의 선택받은 자는 할수 있을지도 모름. 중요한 점 : 내가 선택받은 자가 아님
  20. 20. 20 • 실패가 아니고 시행착오 • 시행착오는 이제 설계의 일부. • 내 능력에는 한계가 있기 때문에, 필연적으로 발생함. • 조금만 실패하고, 실패시의 비용을 낮추야 한다. • 틀릴것을 가정하고 일을 진행한다. • 내가 감당할 수 있는 부분만 예측 • 가까운 미래만 예측한다. • 먼 미래를 예측 할수록 정확도가 떨어짐.
  21. 21. 21 • 완벽한 코드 X • 변경에 유연하게 대처할 수 있는 코드 • 연관성있는 코드와 자료구조를 집약 변경이 필요할때 리팩토링을 할수 있는 코드면 충분히 멋지다. • 변경 비용이 100이 들었을때, 30만 들게 해도 충분하다. • Interface의 구현체를 변경하면 돌아가는것이 반드시 필요한것은 아님. • 단순(Simple)해야 함 • 변경을 빠르게 하려면 단순해야 함 • 핵심이 아닌 기능 추가는 뒤로 미름 • 문제의 핵심을 완전하게 이해할때까지 • 판단에 확신이 들때까지 • 방법을 찾기 위해 개발을 시도
  22. 22. 22 • 실패하는 것은 자체는 문제가 아님 • 올바로 작동하지 않는다고 걱정하지 마라. 만일 모든 게 잘 된다면, 굳이 당신이 일할 이유가 없다 (Mosher’s Law of Software Engineering) https://subokim.wordpress.com/2015/03/12/101-great-computer-programming-quotes • 문제를 해결하지 못하는것이 문제 • 완벽한 해결책이 필요한 것도 아니다. • 문제가 100생겼는데. 개선해서 30만 발생해도 충분히 멋지다.
  23. 23. 23 • Java Agent를 어떻게 만들되는지? • 해당 도메인의 직접적인 경험이 없다. • 레퍼런스도 부족 : 간접경험 • 지금도 가장 어려운 부분 • 설계를 어떻게 해야 될지 잘모르겠음. • Class를 어떻게 잡아야 되는지? • 특정 기능을 구현하기 위해 뭐가 필요하지? • 어설프게 머리로 생각하니깐 실패확율이 높다. • 문제 자체를 관찰하고 원리를 이해하는게 중요함. • Pinpoint의 API트레이스는 JAVA스택머신의 동작을 흉내낸것에 지나지 않음. • 모르는 상태에서 대단한걸 만들려고 하면 대단한 실패를 한다.
  24. 24. 24 • 문제 해결을 위한 도메인 모델은 우리가 만드는 것이 아니라 발견하는 것이다 • 도메인 모델 자체는 우리의 인식의 경계선에서 관찰하고 인지하여 그것 을 언어로 표현하는 것이므로 우리는 이러한 반복적인 탐구 과정을 통 해 모델을 정제해 나가는 것으로서 보다 정확한 모델을 얻는 것이 가능 해 진다. • 이러한 이유로 처음부터 완벽한 모델을 얻기는 쉽지 않다. 여기서 발상 의 전환이 필요해진다. 처음 얻어지는 모델은 틀린 것일 수 있다는 가정 하에 일을 진행 시키는 것 이다. 문제 영역에 대한 올바른 이해 http://www.moreagile.net/2014/12/1.html
  25. 25. 25 • DDD에서 중요하다고 한것을 상당수하지 않았다. • JAVA 개발자 • 성능 분석 & 트러블슈팅업무 수행 • Network 라이브러리 개발 등을 개발 • Java Framework 패치 등등 • HBase는 Oracle동작 원리를 통해 간접이해 • Distributed Trace 도메인은 Dapper 문서 간접이해 • Pinpoint개발에 필요한 도메인 지식이 이미 있었음. • 부족한 부분은 APM 도메인으로 한정 • 불편함을 느껴서 개선하고 싶은 분야의 고도화, 자동화를 추진하 면 복잡도를 내릴 수 있다.
  26. 26. 26 • 복잡도가 높고 아는게 없는 신규 프로젝트 • 핵심 기능 & 가능성을 조사하고 안될거 같으면 포기하자 • 안하는게 방법일수도 있고, 다른 사람이 할수도 있다. • Fail Fast • 최초 개발 시도시 • 성공확율 -> 성공 3 : 실패 7
  27. 27. 27 • 진짜 만들어 낼수 있는지 검증작업에 들어감. • Bytecode Instrumentaion을 구현해 낼수 있나 • Google Dapper를 보고 Distributed Transaction Trace를 구현해 낼수 있나 • 안될거 같으면 빠르게 버릴려고 했는데 • 하나보니 됬다. • 사실 계속 구현에 문제가 발생해서 엄청 긴장 많이했음. • 다음부터 이런거 만들지 말아야지
  28. 28. 28
  29. 29. 29
  30. 30. 30
  31. 31. 31 • 극도로 기능을 제한 • 제품개발의 성공에 크게 관여하지 않는 핵심이 아니라고 판단되면 다 삭제 • Ex : 알람 (중요한데 기능인데 안만들었네요. 꼭만들겠습니다.) • 시간은 항상 모자름. 문제 도메인은 내생각보다 훨씬 어렵다. • 개발이 가능한지 확인을 하기 위한 시간을 최대한 확보 • 적은 인원으로 시작 • 최초 2명 • 실패하면 회사입장에서는 다 $낭비
  32. 32. 32 • 시간 & 리소스는 항상 부족하다. • 개발의 성공가능성을 판가름하는 핵심 기능에 중점을 둬야 한다. • 어디서 시간을 벌어야 하는가? • 제일 만만한건 기능 • 품질 : 이걸 희생하는건 불가능. • 돈&사람 : 내가 직접적으로 결정할 수 있는것이 아님. • 일정 : 보통 변경이 힘드나, Pinpiont의 플랫폼 특성상 이것도 조정이 가능. • 기능 몇 개 더 들어간다고 해서 성공하는게 아님 • 기능이 많으면 변경을 가하기 어려움.
  33. 33. 33 • Server Map Search algorithm Node A Node B Node C Node D Node F Node E Node G 탐색시작 지점
  34. 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. 35 • Pinpoint를 사용하는 서비스가 증가하면서 • 무제한으로 연관 노드를 탐색하니 조회속도가 느리고, • 조회 노드가 많을 경우 OOM도 발생 • ServerMap이 너무 복잡해짐.
  36. 36. 36 • 탐색 깊이 제한 기능을 만듬. • 아직 릴리즈 안됨.
  37. 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. 38 • 뭔가 이상하다. • 단순히 탐색 깊이 제한을 걸면 된다고 생각했는데 • 생각지도 못한걸 발견
  39. 39. 39 • Depth-limited search Node A Node B Node DNode C 1 2 3 여기 조회가 안됨 이미 방문한 노드라서 스킵
  40. 40. 40 • 방안 강구 • 이미 방문한 노드를 마크하는곳에 추가적인 탐색 깊이가 남겨두 고 더 탐색하게 할까? • 점프 Table같은게 있어야 하나? • 다른 경로를 따라서 추가적 루트가 있다면, 예외가 생기나? • 이상하게 난이도 급격하게 상승함. • 잘못된것 같아 다시 검토
  41. 41. 41 • 잘못된 탐색 알고리즘을 선택 • 개발 당시에는 선택을 잘못했다는 것 자체를 인지하지 못했음. • Depth-fitst search 폐기 • Breadth-first search 로 변경. • 탐색 로직이 별도 클래스로 분리되어 있었음 • 알고리즘 변경시 추가로 구현해야 기능이 없었다. • 빠르게 변경가능
  42. 42. 42 • Breadth-first search (너비 우선 탐색) • 문제 자동해결 Node A Node B Node DNode C 1 3 2 4
  43. 43. 43 • 핵심선택에 의해서 성능의 상당 부분은 이미 결정 • 샘플링 • Bytecode Instrumentation • HBase 선택 • 나머지 선택은 부수적 • Binary 프로토콜 • UDP • 비동기 처리 • 나머지 선택은 IO 부하를 줄이기 위한 기능
  44. 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. 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. 46 • SAAS 형태로 서비스가 가능 • 사용자는 Agent만 다운로드하면 되니 편하다. • 모니터링을 위해서 서버를 설치해야 되면 귀찮다.
  47. 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. 48 • 모니터링 시스템인데. Eventually consistency로 보이면 이상할 것 같다. • Hadoop 패밀리쪽이 향후 기능을 더 추가할때 유리하다고 판단 • 모니터링&운영 툴이 부족한듯하다. • 안될 건 없다.
  49. 49. 49 HBase 추천? • NoSQL은 만능이 아니다. • Application의 저장소는 선택은 핵심 결정사항. • 이 선택을 실패하는것은 치명적 • Application에 적합한지 신중히 생각해서 결정 • Pinpoint를 통해 간접경험해보고 결정. • Pinpoint를 설치해서 운영해보고 판단해보는것도 방법이지 않을까? • HBase도 개발실패시에 대한 보험중 하나였음. • Hadoop, HBase의 사용이 증가하면서, 지원에 대한 수요가 자동으로 발생하고 있음. • 이것만 잘해도 먹고 살수 있을지도 모름.
  50. 50. 50 기술 습득시 집중해야 될부분 • 신기술에 관심을 갖는것은 좋다. • 너무 유행만 따르지 말고 실제 가치가 있는지? 신중히 판단하자. • 유행하는 기술에 시간+리소스를 투자했다가 망하면? 이게 다 낭비 • 기술에 대한 근본원리를 틈틈히 살펴보자. • 자신이 사용하지 않는 코드를 보면 보면 어렵기만 하고 재미도 없다. • 실제 사용하는 프레임워크, 라이브러의 코드를 보자. • 특정기술은 죽어도 근본 원리는 안죽는다. • 유행을 타는 기술의 경우 유행이 지났을 경우 감가상각이 매우 심하다. • 근본 원리는 감가상각이 잘되지 않는다. • 감가상각이 잘안되기 때문에, 누적치가 생긴다. • HBase 를 살펴볼때 : RBD의 근본 원리에 빗대서 차이점을 살펴보면 금방. • JDBC Driver 트러블슈팅 : Network lib와 별반 차이가 없다. 그냥 빗대서 살펴보면 금방.
  51. 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. 52 들어주셔서 감사합니다.

×