From 9dbd481853731fd83ff1a71ddbef9d9116aeb4ee Mon Sep 17 00:00:00 2001 From: "wusub.shin@softcamp.co.kr" Date: Mon, 15 Apr 2024 18:05:12 +0900 Subject: [PATCH 1/5] =?UTF-8?q?=EC=97=98=EB=9D=BC=EC=8A=A4=ED=8B=B1?= =?UTF-8?q?=EC=84=9C=EC=B9=98=20=EA=B4=80=EB=A0=A8=20=ED=8F=AC=EC=8A=A4?= =?UTF-8?q?=ED=8C=85=20=EC=9E=91=EC=84=B1=EC=A4=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ral-system-change-db-selection-process.mdx | 45 +++++++++++++++++++ ...ok-at-the-caches-used-in-elasticsearch.mdx | 24 ++++++++++ 2 files changed, 69 insertions(+) create mode 100644 pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx create mode 100644 pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx diff --git a/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx b/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx new file mode 100644 index 0000000..5870c46 --- /dev/null +++ b/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx @@ -0,0 +1,45 @@ +# elasticsearch 단독 체제에서 RDB 를 병행하는 체제로 전환하기 (1부) + +현재 사용하던 서비스가 로그 조회 기능을 메인으로 시작되어 elasticsearch 단독 체제로 사용중에 있었으나 + +몇가지 이슈사항들이 발생하여 RDB 를 병행하는 방식으로 체제 전환을 고려하게 되었다. + +## elasticsearch 단독 체제의 문제점 + +### 태생이 다름 + +`elasticsearch`는 `검색 엔진`으로 태어났다 주 목적이 `검색` 이다 +`rdb`는 `저장소`로 태어났다 주 목적이 `저장` 이다 + +위와 같은 이유로 각자의 메인 역할이 있다 +물론 둘다 `저장`과 `검색` 이 가능하나 메인 기능이 아닌 어떻게 보면 `부가기능`이므로 `한계가 명확하다` + +### 1. 높은 메모리 점유율 + +elasticsearch 는 메모리를 많이쓴다 + +그 이유는 주 목적이 `검색` 이기 때문인데, + +`검색`의 중요 요소는 `정확성`과 `속도` 이기 때문이다 + +구글에서 키워드를 입력하고 검색 버튼을 눌렀을 때 검색 결과를 보기 까지 10초 이상이 걸린다고 생각하면 + +많은 스트레스가 예상된다. + +그렇기 때문에 `elasticsearch` 는 검색 성능을 극대화하기 위하여 작업 처리속도가 느린 `보조기억장치(하드디스크)` 에서 데이터를 바로 검색하기 보다는 + +메모리 캐싱을 적극적으로 활용하여 `높은 검색 성능`을 발휘환다. + +대표적으로 캐싱되는 데이터들은 아래와 같다 + +#### 필드 데이터 캐시 + +#### 쿼리 캐시 + +#### 샤드 요청 캐시 + +#### 도큐먼트 캐시 + +### 2. ACID 미지원 + +### 3. Deep Paging 불가(가능하지만 권장하지 않음) diff --git a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx new file mode 100644 index 0000000..7c33643 --- /dev/null +++ b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx @@ -0,0 +1,24 @@ +# elasticsearch 에서 사용하는 캐싱들을 알아보자 + +opster 에서 설명하는 캐시 : https://opster.com/guides/elasticsearch/glossary/elasticsearch-cache/ + +## 노드 요청 캐시 + +노드 요청 캐시는 필터 컨텍스트에 사용된 쿼리 결과를 유지한다 +결과는 가장 최근에 사용된 항목을 기준으로 제거된다 + +## 샤드 데이터 캐시 + +샤드 데이터 캐시는 크기 + +## 필드 데이터 캐시 + +--- + +공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time + +## 페이지 캐시 + +## 샤드 레벨 요청 캐시 + +## 쿼리 캐시 From e9b5e0393514bb1333351669552aba2e33898c52 Mon Sep 17 00:00:00 2001 From: "wusub.shin@softcamp.co.kr" Date: Tue, 16 Apr 2024 18:51:23 +0900 Subject: [PATCH 2/5] =?UTF-8?q?=EC=9E=84=EC=8B=9C=EC=BB=A4=EB=B0=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ok-at-the-caches-used-in-elasticsearch.mdx | 22 ++++++++++++------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx index 7c33643..eec7aa7 100644 --- a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx +++ b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx @@ -1,5 +1,19 @@ # elasticsearch 에서 사용하는 캐싱들을 알아보자 +공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time + +## 페이지 캐시 + +**운영 체제 레벨의 캐시**이다 + +페이지란, **프로세스가 할당받는 가상 메모리 공간을 균일한 크기로 나눈 메모리 영역을 지칭한다.** + +## 샤드 레벨 요청 캐시 + +## 쿼리 캐시 + +--- + opster 에서 설명하는 캐시 : https://opster.com/guides/elasticsearch/glossary/elasticsearch-cache/ ## 노드 요청 캐시 @@ -14,11 +28,3 @@ opster 에서 설명하는 캐시 : https://opster.com/guides/elasticsearch/glos ## 필드 데이터 캐시 --- - -공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time - -## 페이지 캐시 - -## 샤드 레벨 요청 캐시 - -## 쿼리 캐시 From d7052636f1fda6c479649fd9ebeb3dfd2bf864b3 Mon Sep 17 00:00:00 2001 From: WooSub Shin <40654598+mainmethod0126@users.noreply.github.com> Date: Tue, 16 Apr 2024 20:37:10 +0900 Subject: [PATCH 3/5] =?UTF-8?q?=ED=8F=AC=EC=8A=A4=ED=8C=85=20=EC=9E=91?= =?UTF-8?q?=EC=84=B1=EC=A4=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ok-at-the-caches-used-in-elasticsearch.mdx | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx index eec7aa7..a11ab70 100644 --- a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx +++ b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx @@ -8,8 +8,36 @@ 페이지란, **프로세스가 할당받는 가상 메모리 공간을 균일한 크기로 나눈 메모리 영역을 지칭한다.** +그렇다면 페이지 캐시란 무엇인가? + +CPU 는 보조기억장치에서 바로 데이터를 읽는게 아니라 메모리에서 읽어온다 + +이때 접근하려는 페이지가 물리 메모리에 Load 되어있지 않을 경우 `페이지 폴트(Page Fault)` 가 발생하는데 하드 디스크(윈도우는 pagefile.sys, 리눅스는 swap 영역) 의 페이지를 물리 메모리로 Load 한다(Page In) 그 이후에 이 로드된 페이지로 부터 데이터를 읽게되는데, 이렇게 Load 된 페이지들은 OS의 관리하에 자주 사용되는 페이지의 경우 물리 메모리 영역에 좀 더 오래 유지되고 자주 안쓰는 페이지는 다시 디스크 영역으로 내리는 일련의 관정들이 발생한다. + +이렇게 CPU 가 저장된 데이터에 더 빠르게 접근하도록 하기 위하여 물리 메모리에 페이지를 로드하고 관리하는 것을 `페이지 캐시` 라고 한다 + +단순하게 요약하면 `보조기억장치의 데이터를 더 빠르게 접근하기 위해 페이지 단위로 물리 메모리에 올려놓고 쓰는 것` + +### 제거 시점 + +운영체제가 알아서 함 + +### 특징 + +운영체제가 관리하기 때문에 커널 메모리 영역을 사용하게된다 +elasticsearch 실행시 할당하는 jvm heap 영역과는 상관없다. +그러기 때문에 elasticsearch 실행 시 [heap 영역을 최대 현재 호스트 pc의 반](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/tune-for-search-speed.html#_give_memory_to_the_filesystem_cache_2)으로 권장한다. +나머지 반은 페이지 캐시를 위한 커널 메모리 영역으로 남겨놔야하기 때문이다. + +만약 대부분의 메모리를 elasticsearch heap으로 할당하게되면 페이지 캐시의 성능이 저하될 것이다 + +--- + ## 샤드 레벨 요청 캐시 +집계로만 구성된 검색 결과를 캐시함 + + ## 쿼리 캐시 --- From 1f2c3e194fdbacd281053937f8cd41c3b9d102bf Mon Sep 17 00:00:00 2001 From: "wusub.shin@softcamp.co.kr" Date: Wed, 17 Apr 2024 18:07:06 +0900 Subject: [PATCH 4/5] =?UTF-8?q?=ED=8F=AC=EC=8A=A4=ED=8C=85=20=EC=9E=84?= =?UTF-8?q?=EC=8B=9C=20=EC=A0=80=EC=9E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ok-at-the-caches-used-in-elasticsearch.mdx | 85 ++++++++++++++----- 1 file changed, 65 insertions(+), 20 deletions(-) diff --git a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx index a11ab70..690812c 100644 --- a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx +++ b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx @@ -1,42 +1,87 @@ -# elasticsearch 에서 사용하는 캐싱들을 알아보자 +import { Callout } from "nextra/components"; + +# elasticsearch 에서 사용하는 캐시들을 알아보자 공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time ## 페이지 캐시 -**운영 체제 레벨의 캐시**이다 +리눅스 토발즈가 1995년에 리눅스 운영체제의 파일 시스템 관리를 개선하기 위해 가상 파일 시스템(VFS)과 실제 파일 시스템(FS) 사이에 캐시 계층을 도입하면서 이를 `페이지 캐시` 라고 부르게되었다 + +간단하게 `리눅스의 파일 시스템 캐시 방식` 이라고 보면 된다 + +파일 시스템 캐시의 정의는 + +**파일 I/O 가 발생하면 캐시 레이어에 파일 핸들별로 파일 데이터를 캐싱해놓고 동일한 파일에 대한 I/O 발생 시 디스크가 아닌 메모리상의 캐시 데이터를 읽고쓰도록하여 파일 I/O 속도를 빠르게 하기 위한 목적이다.** + + +쓰기의 경우 캐시 메모리상의 데이터를 변경하고 해당 캐시의 데이터가 +변경되었음을 알리는 **dirty(변경됨) 플래그를 ON**한다 그러면 운영체제의 +`쓰기용 워커 스레드(flusher thread)` 가 주기적으로 **dirty 플래그가 ON** +되어있는 캐시들을 찾아서 디스크에 쓰게 된다 + +이렇게 뒤늦게 디스크에 쓰이는 것을 [쓰기 지연(writeback)](https://scslab-intern.gitbooks.io/linux-kernel-hacking/content/chapter16.html) 이라고 한다 + + + +흔히 알고있는 가상 메모리를 페이지 단위로 관리하는 **페이징 매커니즘과 다른 용어다** + + +"아니 그럼 그냥 파일 시스템 캐시라고 하지 왜 페이지 캐시라고 부르는거야?" + +필자는 처음에 위와 같은 의문이 들었다. + +찾아보니 그냥 `페이지 단위` 로 캐싱하는 방식이라 `페이지 캐시` 라고 부르게된 것 같다. + + + +### 엘라스틱서치 세그먼트 불변성과 페이지 캐시의 관계 -페이지란, **프로세스가 할당받는 가상 메모리 공간을 균일한 크기로 나눈 메모리 영역을 지칭한다.** +엘라스틱서치에서는 저장되는 데이터들을 [세그먼트](https://mainmethod0126.github.io/elasticsearch/Basic-Concepts-of-Elasticsearch#%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8%EB%9E%80)라는 `파일`로 관리한다. -그렇다면 페이지 캐시란 무엇인가? +이 **세그먼트의 아주 중요한 특성**이 있는데 바로 [불변하다](https://mainmethod0126.github.io/elasticsearch/Basic-Concepts-of-Elasticsearch#%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8%EB%8A%94-%EB%B6%88%EB%B3%80immutable%ED%95%98%EB%8B%A4)는 것이다 -CPU 는 보조기억장치에서 바로 데이터를 읽는게 아니라 메모리에서 읽어온다 +이말은 즉슨, **한번 페이지 캐시된 세그먼트 파일의 경우 세그먼트 파일이 삭제되어서 영원히 안쓰게 되는 경우를 제외하고는 dirty(변경됨) 체크될 일이 없다** -이때 접근하려는 페이지가 물리 메모리에 Load 되어있지 않을 경우 `페이지 폴트(Page Fault)` 가 발생하는데 하드 디스크(윈도우는 pagefile.sys, 리눅스는 swap 영역) 의 페이지를 물리 메모리로 Load 한다(Page In) 그 이후에 이 로드된 페이지로 부터 데이터를 읽게되는데, 이렇게 Load 된 페이지들은 OS의 관리하에 자주 사용되는 페이지의 경우 물리 메모리 영역에 좀 더 오래 유지되고 자주 안쓰는 페이지는 다시 디스크 영역으로 내리는 일련의 관정들이 발생한다. +**페이지 캐시의 데이터 변경으로 인하여 디스크 I/O가 발생할 일이 극히 드물다는 뜻이다.** -이렇게 CPU 가 저장된 데이터에 더 빠르게 접근하도록 하기 위하여 물리 메모리에 페이지를 로드하고 관리하는 것을 `페이지 캐시` 라고 한다 - -단순하게 요약하면 `보조기억장치의 데이터를 더 빠르게 접근하기 위해 페이지 단위로 물리 메모리에 올려놓고 쓰는 것` - -### 제거 시점 +그렇기 때문에 **거의 대부분의 경우 캐시에서 데이터를 불러오기 때문에 속도가 상당히 빠르다** -운영체제가 알아서 함 - -### 특징 +위와 같은 이유로, **엘라스틱서치의 세그먼트 불변성은 페이지 캐시와 아주 찰떡이다** + + +"세그먼트 병합은 삭제가 아니니까 dirty 체크 되는거 아니니?" + +사실상 병합도 삭제다. + +A, B의 데이터가 하나로 압축되어 AB 라는 새로운 세그먼트 파일이 생성되고 A, B 단일 세그먼트 파일들은 삭제된다 +그러니 세그먼트 파일은 `생성`, `삭제` 두 케이스만 존재하는거라고 봐야한다. + + + +### 유의 사항 1 : 최대 메모리의 반은 남겨놔야한다 운영체제가 관리하기 때문에 커널 메모리 영역을 사용하게된다 -elasticsearch 실행시 할당하는 jvm heap 영역과는 상관없다. -그러기 때문에 elasticsearch 실행 시 [heap 영역을 최대 현재 호스트 pc의 반](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/tune-for-search-speed.html#_give_memory_to_the_filesystem_cache_2)으로 권장한다. -나머지 반은 페이지 캐시를 위한 커널 메모리 영역으로 남겨놔야하기 때문이다. -만약 대부분의 메모리를 elasticsearch heap으로 할당하게되면 페이지 캐시의 성능이 저하될 것이다 +그렇기 때문에 elasticsearch 실행 시 [최대 메모리의 반은 남겨놓고 나머지 반에서 heap을 할당하는 것으로 권장](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/tune-for-search-speed.html#_give_memory_to_the_filesystem_cache_2)한다. + +**나머지 반은 페이지 캐시를 위한 커널 메모리 영역**으로 남겨놔야하기 때문이다. + +만약 이를 무시하고 대부분의 메모리를 elasticsearch heap으로 할당하게되면 페이지 캐시 성능이 저하될 것이다 + +### 유의 사항 2 : 엘라스틱서치의 높은 리소스 점유율 + +엘라스틱서치에 굉장히 많은 요청이 들어오는 환경이라면, 페이지가 캐시가 할당될 수 있는 공간을 엘라스틱서치의 세그먼트 파일 캐시가 대부분 차지하게된다. + +그렇게되면 엘라스틱서치보다는 I/O가 적은 타 프로세스들에서는 페이지 캐시를 활용할 수 없게될 가능성이 존재하여 타 프로세스의 성능 저하가 발생할 수 있다. + +이는 리눅스에서 가장 오랫동안 참조되지 않은 페이지를 교체하는 방법인 [LRU](https://ko.wikipedia.org/wiki/Least_Recently_Used) 알고리즘을 사용하기 때문이다 --- ## 샤드 레벨 요청 캐시 -집계로만 구성된 검색 결과를 캐시함 - +**집계로만 구성된 검색 결과를 캐싱함** ## 쿼리 캐시 From 56d9f627dc2089844124013e651db0a3df02e5bd Mon Sep 17 00:00:00 2001 From: wusubsin Date: Thu, 18 Apr 2024 00:00:11 +0900 Subject: [PATCH 5/5] =?UTF-8?q?=EC=9E=91=EC=84=B1=EC=A4=91=EC=9D=B8=20?= =?UTF-8?q?=ED=8F=AC=EC=8A=A4=ED=8C=85=EB=8F=84=20=EC=A4=91=EA=B0=84?= =?UTF-8?q?=EC=A4=91=EA=B0=84=EC=97=90=20=EB=82=B4=EC=9A=A9=20=ED=99=95?= =?UTF-8?q?=EC=9D=B8=ED=95=98=EA=B3=A0=EC=9E=90=20main=20=EB=B8=8C?= =?UTF-8?q?=EB=9F=B0=EC=B9=98=EC=97=90=20=EB=A8=B8=EC=A7=95=ED=95=A0=20?= =?UTF-8?q?=EB=AA=A9=EC=A0=81=EC=9C=BC=EB=A1=9C=20=ED=91=B8=EC=89=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...tem-to-db-and-general-system-change-db-selection-process.mdx | 2 +- .../lets-look-at-the-caches-used-in-elasticsearch.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx b/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx index 5870c46..b88ecae 100644 --- a/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx +++ b/pages/elasticsearch/elasticsearch-solo-system-to-db-and-general-system-change-db-selection-process.mdx @@ -1,4 +1,4 @@ -# elasticsearch 단독 체제에서 RDB 를 병행하는 체제로 전환하기 (1부) +# elasticsearch 단독 체제에서 RDB 를 병행하는 체제로 전환하기 (1부, 2024-04-17 기준 미완성, 현재 작성중) 현재 사용하던 서비스가 로그 조회 기능을 메인으로 시작되어 elasticsearch 단독 체제로 사용중에 있었으나 diff --git a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx index 690812c..107ea0b 100644 --- a/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx +++ b/pages/elasticsearch/lets-look-at-the-caches-used-in-elasticsearch.mdx @@ -1,6 +1,6 @@ import { Callout } from "nextra/components"; -# elasticsearch 에서 사용하는 캐시들을 알아보자 +# elasticsearch 에서 사용하는 캐시들을 알아보자 (2024-04-17 기준 미완성, 현재 작성중) 공홈에서 설명하는 캐시 : https://www.elastic.co/kr/blog/elasticsearch-caching-deep-dive-boosting-query-speed-one-cache-at-a-time