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.

엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기

3,322 views

Published on

공감세미나에서 발표한 Elasticsearch 대용량 클러스터 운영노하우 발표자료입니다.

Published in: Technology
  • Be the first to comment

엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기

  1. 1. 공감세미나 엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기 JAVACAFE 김흥래
  2. 2. 공감세미나발표자 김흥래 (Naver Business Platform) 자바카페 커뮤니티의 운영진이다. 심심할 틈 없이 신기술이 쏟아지는 IT와 사랑에 빠진 개발자로, 개발자간의 소통과 교류를 즐긴다. 현재 네이버 비즈니스 플랫폼에서 다양한 서비스를 개발하고 있다. hrkim3468@gmail.com
  3. 3. 공감세미나Overview 장애경험 공유 장애방지를 위한 제안 대용량 클러스터를 위한 제안 클러스터 최적화를 위한 밴치마크
  4. 4. 공감세미나 1. 장애경험 공유 2. 장애방지를 위한 제안 3. 대용량 클러스터를 위한 제안 4. 클러스터 최적화를 위한 밴치마크
  5. 5. 공감세미나Cerebro가 노란색으로 바뀐다면 … _cluster/health
  6. 6. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step1 정상상태
  7. 7. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step2 2번 Node 장애 Replica 샤드 Master 샤드로 전환 서비스는 문제없음
  8. 8. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step3 로드 걸리기 시작함 ㅠㅠ
  9. 9. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step4 열심히 Replica 샤드 생성
  10. 10. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step5 Replica 샤드 복제 끝나고 클러스터 안정화라고 생각했는데…
  11. 11. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step6 CPU 치기 시작함 2번 Node 다시 올라왔나 봄.
  12. 12. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step7 역시….. 곧 또 로드 걸리겠군 ㅠㅠ
  13. 13. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step8 2번 Node로 샤드 분산해야지….
  14. 14. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step9 열심히 샤드 분산중
  15. 15. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step10 Master 샤드도 분산되고 Replica 샤드도 분산되고
  16. 16. 공감세미나Cerebro가 노란색으로 바뀐다면 … Recovery Step11 다시 평화 ^^
  17. 17. 공감세미나Cerebro가 노란색으로 바뀐다면 … 고민 할 포인트 • 복구 메커니즘에 따른 적절한 데이터 분산 (Node 수 or Shard 수) • 하나의 Index 사이즈 (데이터 건수 or 데이터 사이즈) • 하나의 Shard 사이즈 (데이터 건수 or 데이터 사이즈) • Replica Set의 개수 • 내부네트워크도 가급적이면 10G로 • IDC 분산이 필요하다면?
  18. 18. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. Spring Batch
  19. 19. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. Spring Batch
  20. 20. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. _bulk Index Queue Index Thread Pool Index Request
  21. 21. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. Scroll Search
  22. 22. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. refresh=wait_for https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-refresh.html 어떤 옵션을 사용할 것인가? refresh=false (Default) // 0.1초 refresh=true // 1.5초 refresh=wait_for // 흠…….
  23. 23. 공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다. • wait_for 옵션을 이용하여 속도를 희생 할 것인가? • Replica Set의 수가 많아지면 많아질수록… • 만약 IDC 이중화가 되어있다면… 고민 할 포인트
  24. 24. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 Dashboard
  25. 25. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 Chart 추가
  26. 26. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 조회기간 변경
  27. 27. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 결국은 …
  28. 28. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 Coordinating Node
  29. 29. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일 • Coordinating Node가 매일 죽는다면? • 과부하를 막기 위해서는 Kibana의 권한제어가 필요하다 고민 할 포인트 원천적인 해결책은? (1) X-Pack 도입 (2) Proxy 도입
  30. 30. 공감세미나Approximate Aggregation과 돈이 만난다면 분산환경과 집계연산 Avg Aggregation 1. 코디네이터 노드가 Avg 집계 요청을 받는다. 2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Avg 집계 요청을 보낸다. 3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 평균값을 계산한다. 4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다. 5. 모든 결과가 도착하면 도착한 값들을 가지고 다시 평균값을 계산한다. 6. 사용자에게 정확한 평균값을 결과로 제공한다. 값을 주고 받는다.
  31. 31. 공감세미나Approximate Aggregation과 돈이 만난다면 분산환경과 집계연산 Cardinality Aggregation ( = Distinct ) 1. 코디네이터 노드가 Cardinality 집계 요청을 받는다. 2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Cardinality 집계 요청을 보낸다. 3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 중복을 제거하고 결과 데이터를 리스트로 작성한다. 4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다. 5. 모든 Shard로 부터 리스트가 도착하면 결과를 하나로 합쳐서 다시 한번 중복을 제거한다. 6. 사용자에게 정확한 중복 제거된 결과를 제공한다. 데이터 리스트를 주고 받는다.
  32. 32. 공감세미나Approximate Aggregation과 돈이 만난다면 분산환경과 집계연산 특정 금액 Avg Aggregation CN DN1 DN2 DN3 평균값 1KB 평균값 1KB 평균값 1KB 총 3KB 데이터를 평균하여 리턴 각각의 DN에 1억건의 데이터씩 총 3억건의 데이터가 분산 저장되어 있고 특정 금액의 종류가 1만건 존재할 경우 특정 금액 Cardinality Aggregation CN DN1 DN2 DN3 중복제거 500MB 중복제거 500MB 중복제거 500MB 총 1.5GB 데이터를 Merge하여 전체를 대상으로 한번 더 중복 제거하여 리턴
  33. 33. 공감세미나Approximate Aggregation과 돈이 만난다면 HyperLogLog++ • 확률 기반의 자료구조 • 정확한 값이 아닌 근사치 값을 제공한다. • 일부 데이터를 샘플링하여 결과를 확률적으로 예측한다. • 버킷 사이즈가 크면 클수록 정확도가 올라간다.
  34. 34. 공감세미나Approximate Aggregation과 돈이 만난다면 Approximate Cardinality Aggregation https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html
  35. 35. 공감세미나Approximate Aggregation과 돈이 만난다면 Approximate Cardinality Aggregation https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html
  36. 36. 공감세미나Approximate Aggregation과 돈이 만난다면 UV, PV • UV를 뽑기 위해서는 반드시 Cardinality 연산이 필요하다. • 대충 비슷하게 나오면 되는거 아닌가? • 만약 UV, PV를 이용하여 과금을 한다면?
  37. 37. 공감세미나Approximate Aggregation과 돈이 만난다면 • Unique 처리한 데이터를 별도의 인덱스로 생성한다면? • 실시간 처리와 배치 처리를 나눠서 보여준다면? 고민 할 포인트
  38. 38. 공감세미나쉬어가기
  39. 39. 공감세미나 1. 장애경험 공유 2. 장애방지를 위한 제안 3. 대용량 클러스터를 위한 제안 4. 클러스터 최적화를 위한 밴치마크
  40. 40. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 [1단계] Cluster 레벨 모니터링 [2단계] Node 레벨 모니터링 [3단계] Index 레벨 모니터링
  41. 41. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  42. 42. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  43. 43. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  44. 44. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  45. 45. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  46. 46. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  47. 47. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _cluster/stats [1단계] Cluster 레벨 모니터링
  48. 48. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  49. 49. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  50. 50. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  51. 51. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  52. 52. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  53. 53. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  54. 54. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  55. 55. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  56. 56. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  57. 57. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  58. 58. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  59. 59. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  60. 60. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  61. 61. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  62. 62. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  63. 63. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  64. 64. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _nodes/stats [2단계] Node 레벨 모니터링
  65. 65. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  66. 66. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  67. 67. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  68. 68. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  69. 69. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  70. 70. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  71. 71. 공감세미나클러스터의 상태를 실시간으로 모니터링하자 _stats [3단계] Index 레벨 모니터링
  72. 72. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 • elasticsearch.yml에서 설정한 내역들이 나의 의도대로 실질적으로 클러스터에 반 영되었는지 확인하는 과정이 반드시 필요하다. • Elasticsearch에서는 물리적 설정과 논리적 설정을 모두 지원하기 때문에 우선 순 위에 따라서 나의 의도와는 다르게 동작할 수 있다. • 해당 물리 노드에만 적용하길 원할 경우 물리적 설정을 한다. (Node명, Node타입, 네트워크 설정) • 일반적으로는 클라우드 전체에 동일하게 적용하기 때문에 논리적 설정을 한다.
  73. 73. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 ./config/elasticsearch.yml [Node] 물리적 설정정보
  74. 74. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _nodes/노드ID [Node] 물리적 설정정보
  75. 75. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _nodes/노드ID [Node] 물리적 설정정보
  76. 76. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _nodes/노드ID [Node] 물리적 설정정보
  77. 77. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _nodes/노드ID [Node] 물리적 설정정보
  78. 78. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
  79. 79. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
  80. 80. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
  81. 81. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자 _cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
  82. 82. 공감세미나Runtime에는 환경설정을 신중하게 변경하자 indices.recovery.max_bytes_per_sec 항목의 설정을 변경해보자. 이 항목은 Index Recovery 상황에서 초당 복구될 사이즈를 설정하는 항목이다.
  83. 83. 공감세미나Runtime에는 환경설정을 신중하게 변경하자 ./config/elasticsarch.yml 파일을 열어본다. indices.recovery.max_bytes_per_sec : 40mb 초당 40MB의 속도로 Recovery를 수행하도록 물리적으로 설정되어 있다.
  84. 84. 공감세미나Runtime에는 환경설정을 신중하게 변경하자 클러스터가 실제 동작하고 있는 설정값을 확인해보자. _cluster/settings?include_defaults=true 마찬가지로 초당 40MB의 속도로 Recovery를 수행하도록 설정되어 있다.
  85. 85. 공감세미나Runtime에는 환경설정을 신중하게 변경하자 PUT _cluster/settings { "transient" : { "indices.recovery.max_bytes_per_sec" : "512mb" } } Runtime 중에 복구속도를 빠르게 조정하기로 결정했다면 아래 API를 이용할 수 있다. _cluster/settings 초당 512MB의 속도로 Recovery를 수행하도록 논리적으로 변경한다.
  86. 86. 공감세미나Runtime에는 환경설정을 신중하게 변경하자 _cluster/settings
  87. 87. 공감세미나장애방지를 위한 제안 • 클러스터의 상태를 실시간으로 모니터링하자 • 환경설정 값들을 Runtime에 반드시 확인하자 • Runtime에는 환경설정을 신중하게 변경하자 결론
  88. 88. 공감세미나쉬어가기
  89. 89. 공감세미나 1. 장애경험 공유 2. 장애방지를 위한 제안 3. 대용량 클러스터를 위한 제안 4. 클러스터 최적화를 위한 밴치마크
  90. 90. 공감세미나Master Node를 반드시 분리하자 Shard 수가 수백개라면 Config 정보는 어디에? Master Node와 Data Node가 같은 JVM에서 동작할때 문제점은? 분산시스템에서 Data Node가 죽을 경우에 Master Node도 죽는다면? 골치 아픈 Split Brain 문제? Master 전용 Node는 낮은 사양의 장비로도 충분하다. 안정적인 클러스터를 운영하려면 Master Node가 안정적이어야 한다.
  91. 91. 공감세미나장비는 64GB의 물리메모리를 가지는 장비가 좋다. Elasticsearch를 VM장비로 운영한다면 그 많은 I/O는? Lucene은 mmap()을 통한 System Call을 공격적으로 사용한다. 물리 장비당 하나의 인스턴스가 적합하다. 물리메모리의 반은 Elasticsearch에게 나머지 반은 Lucene에게 할당하자. 분산 클러스터 특성상 고사양 서버보다는 저사양 서버 다수로 구성하는 것이 좋다.
  92. 92. 공감세미나Elasticsearch 힙사이즈는 31GB가 좋다. Java는 객체를 표현하기 위해 Ordinary Object Pointer (OOP)를 사용한다. 64bit 시스템이라도 힙메모리가 32GB 이하일 경우에는 Compressed OOP를 사용하여 32bit 포인터 사용이 가능하므로 성능향상에 큰 도움이 된다.
  93. 93. 공감세미나디스크는 가급적이면 SSD를 사용하자. 루씬이 디스크 기반이기 때문에 SSD 사용시 효율이 매우 좋아진다. 이제는 SSD 가격이 매우 저렴해졌다. ^^;;;
  94. 94. 공감세미나최대한 메모리 스와핑이 발생하지 않도록 하자. Elasticsearch가 사용하지 않는 메모리가 OS에 의해 강제적으로 스와핑이 될 경우 성능에 치명적인 문제가 생길 가능성이 있다. $ sudo sysctl -w vm.swappiness=1
  95. 95. 공감세미나가상메모리 mmap 카운트를 변경하자. Lucene의 경우 내부적으로 mmap을 많이 활용한다. 기본으로 제공되는 mmap 카운트를 262,144로 늘려야 한다. 최신버전의 Elasticsearch에서는 mmap 카운트가 부족할 경우 실행시 부트스트랩 과정에서 강제적으로 오류를 발생시킨다. $ sudo sysctl -w vm.max_map_count = 262144
  96. 96. 공감세미나생성 가능한 최대 파일 개수를 변경하자. Lucene은 불변 방식으로 데이터의 정합성을 제공한다. 이 과정에서 무수히 많은 Segment가 생성될 수 있기 때문에 응용프로그램에서 생성 가능한 최대 파일 개수가 변경되어야 한다. $ sudo sysctl -w fs.file-max=518144
  97. 97. 공감세미나연결 가능한 최대 Connection 개수를 변경한다. Elasticsearch는 복구과정에서 대량의 데이터를 Tcp/Ip로 주고받는다. 좀더 빠른 네트워크 처리를 위해서 연결 가능한 최대 Connection 개수를 변경해야 한다. $ sudo sysctl -w net.core.somaxconn=65535
  98. 98. 공감세미나대용량 클러스터를 위한 제안 결론 • Master Node를 반드시 분리하자. • 장비는 64GB의 물리메모리를 가지는 장비가 좋다. • Elasticsearch 힙사이즈는 31GB가 좋다. • 디스크는 가급적이면 SSD를 사용하자. • 최대한 메모리 스와핑이 발생하지 않도록 하자. • 가상메모리 mmap 카운트를 변경하자. • 생성 가능한 최대 파일 개수를 변경하자. • 연결 가능한 최대 Connection 개수를 변경한다.
  99. 99. 공감세미나쉬어가기
  100. 100. 공감세미나 1. 장애경험 공유 2. 장애방지를 위한 제안 3. 대용량 클러스터를 위한 제안 4. 클러스터 최적화를 위한 밴치마크
  101. 101. 공감세미나기본개념 Search Rate Primary Shard 및 Replica Shard에 서 실행되는 초당 검색 요청수
  102. 102. 공감세미나기본개념 Search Latency 검색요청을 처리하기 위한 평균 대기시간
  103. 103. 공감세미나기본개념 Indexing Rate 샤드에서 인덱싱 처리가 되고 있는 초당 문서수
  104. 104. 공감세미나기본개념 Indexing Latency 인덱싱 처리를 위한 평균 대기시간
  105. 105. 공감세미나기본개념 Node 모니터링
  106. 106. 공감세미나기본개념 Node 모니터링
  107. 107. 공감세미나기본개념 Node 모니터링
  108. 108. 공감세미나기본개념 Index 모니터링
  109. 109. 공감세미나기본개념 Index 모니터링
  110. 110. 공감세미나기본개념 Index 모니터링
  111. 111. 공감세미나은탄환은 없다. 서버의 Spec, 데이터의 종류, 사이즈, 검색패턴 등에 따라 결과가 달라진다. 지금 최적화 했다고 해서 앞으로도 계속 최적화 상태를 유지하지 않는다. 시간이 지날수록, 데이터가 자랄수록 정답이 달라진다. 자신의 데이터를 이용하여 항상 밴치마크를 해야 한다. 클러스터의 성능을 최대한 끌어내려면?
  112. 112. 공감세미나밴치마크
  113. 113. 공감세미나밴치마크
  114. 114. 공감세미나밴치마크 시나리오 1. JSON 데이터 4500만건 (2.28GB) 색인 2. 검색 테스트 3. 업데이트 테스트
  115. 115. 공감세미나밴치마크 동일한 클러스터에서 3가지 경우 밴치마크 테스트 Case1) 힙사이즈 1G, CMS GC Case2) 힙사이즈 4G, CMS GC Case3) 힙사이즈 4G, G1GC
  116. 116. 공감세미나밴치마크
  117. 117. 공감세미나밴치마크
  118. 118. 공감세미나밴치마크
  119. 119. 공감세미나밴치마크
  120. 120. 공감세미나밴치마크
  121. 121. 공감세미나밴치마크
  122. 122. 공감세미나밴치마크
  123. 123. 공감세미나밴치마크
  124. 124. 공감세미나밴치마크
  125. 125. 공감세미나밴치마크
  126. 126. 공감세미나밴치마크
  127. 127. 공감세미나밴치마크
  128. 128. 공감세미나 Thank You

×