제로부터시작하는개발생활

파이썬 알고리즘 문제풀이 : collections.Counter

baektothefuture — Wed, 28 May 2025 20:31:49 +0900

파이썬에서 자주 등장하는 라이브러리 중 하나인 collections에는 아주 유용한 자료구조인 Counter가 있습니다.

collections.Counter란?

Counter는 파이썬의 내장 모듈 collections에 포함된 특수한 딕셔너리입니다.

리스트, 문자열 같은 반복 가능한(iterable) 객체를 받아, 각 요소가 몇 번 등장했는지를 세어주는 자료형입니다.

from collections import Counter

arr = ['a', 'b', 'a', 'c', 'b', 'a']

counter = Counter(arr)
print(counter)
## 결과 : Counter({'a': 3, 'b': 2, 'c': 1})

즉, 요소를 key로, 등장 횟수를 value로 저장합니다.

Counter 끼리 산술 연산이 가능합니다.

a = Counter(['a', 'b', 'c', 'a'])
b = Counter(['a', 'b'])
print(a - b)  # 결과: Counter({'a': 1, 'c': 1})

- 같은 key에 대해 개수를 빼줍니다.

- 결과가 0 이하인 항목은 자동으로 제거됩니다.

Counter는 딕셔너리 처럼 동작합니다.

return list(answer.keys())[0]

- 딕셔너리의 .keys()를 통해 이름만 추출할 수 있습니다.

정리

개념	정리
collections.Counter	리스트에서 각 요소의 등장 횟수를 세어주는 딕셔너리
산술연산 가능 : Counter(A) - Counter(B)	A에서 B의 항목 수를 빼고 남은 것만 반환
딕셔너리 처럼 동작 : .keys()	딕셔너리 메서드 가능

APM Agent

baektothefuture — Tue, 20 May 2025 20:52:00 +0900

Elasticsearch에 Http Request를 보낼 때 계측하여 모니터링 할 수 있도록 APM을 테스트 및 개발중이다.

복기 겸,, 개발 가능성 유무를 확고히 하기 위해 기록..합니다.

테스트 환경 : 각 노드에 Elastic Agent가 설치

Elastic APM

Fleet 이란?

Agent Server를 관리하며 정책을 부여

Elastic APM 이란?

incoming requests, database queries, caches, external HTTP request, ... 등등 수집

디버깅 시 발생하는 로그 수집

Elastic APM은 APM Agent 역할을 함과 동시에 APM Server 역할도 가능하다.

Kibana에서 확인할 수 있는 로그 저장소 - data_stream

APM은 Metrics를 ILM(Index Lifecycle Management)을 활용하여 데이터를 관리한다.
- Application traces : `traces-apm.internal-<namespace>` → traces-apm-default
- APM internal metrics: `metrics-apm.internal-<namespace>` → metrics-apm.internal-default
- APM transaction metrics: `metrics-apm.transaction.<metricset.interval>-<namespace>`
- APM service destination metrics: `metrics-apm.service_destination.<metricset.interval>-<namespace>`
- APM service transaction metrics: `metrics-apm.service_transaction.<metricset.interval>-<namespace>`
- APM service summary metrics: `metrics-apm.service_summary.<metricset.interval>-<namespace>`
- Application metrics: `metrics-apm.app.<service.name>-<namespace>`
출처 : https://www.elastic.co/guide/en/observability/current/apm-data-streams.html

Data streams | Elastic Docs

APM data follows the <type>-<dataset>-<namespace> naming scheme. The type and dataset are predefined by the Elasticsearch apm-data plugin, but the namespace...

www.elastic.co

Elasticsearch에 Http Request를 날리는 어플리케이션에서 헤더에 특정 id를 포함하여 전송하면 해당 task를 키바나의 트랜잭션(APM -> Servcie -> Transactions)에서 감지 가능할까?

-> NO : Elasticsearch는 Tracer 인스턴스를 상속받아야 인식가능한 Task로 변환된다.

https://github.com/elastic/elasticsearch/blob/main/TRACING.md#how-to-i-trace-something-that-isnt-a-task

elasticsearch/TRACING.md at main · elastic/elasticsearch

Free and Open Source, Distributed, RESTful Search Engine - elastic/elasticsearch

github.com

어플리케이션 모니터링 -  APM Service 생성

환경 : IDE (Intellij)
언어 : Java

설정
- Run/Deug Configurations (IDE)
    - Modify options를 통해 환경변수 설정 추가
    -javaagent:C:\Users\<사용자>\IdeaProjects\<프로젝트>\src\elastic-apm-agent-1.53.0.jar
    (다운받은 agent 주소)
    -Delastic.apm.service_name=seonmin (서비스 이름)
    -Delastic.apm.server_url=http://192.168.125.69:8200 (apm 서버 주소)
    -Delastic.apm.environment=dev
    -Delastic.apm.application_packages=controller (source project가 속해 있는 상위 폴더)

주요 코드

https://www.elastic.co/guide/en/apm/agent/java/current/public-api.html
https://www.elastic.co/guide/en/apm/agent/java/current/method-api.html

pom.xml

    <dependency>
      <groupId>co.elastic.apm</groupId>
      <artifactId>apm-agent-api</artifactId>
      <version>1.52.0</version>
    </dependency>

.java

Span span = ElasticApm.currentSpan();
Transaction transaction = ElasticApm.startTransaction();
try {
    transaction.setName("서비스 이름");
    transaction.setType(Transaction.TYPE_REQUEST);

    <code...>

    } catch(Exception e) {
        transaction.captureException(e);
        throw e;
    } finally {
	    transaction.end();
}

서비스 이름을 임의로 지정하여 테스트

Spring 프레임워크의 경우 더욱 간단하게 어플리케이션 로그를 남길 수 있다.
https://www.elastic.co/guide/en/apm/agent/java/current/setup-attach-api.html
지원되는 프레임워크
https://www.elastic.co/guide/en/apm/agent/java/current/supported-technologies-details.html#supported-java-versions

elasticsearch 한글 형태소 분석사전

baektothefuture — Tue, 1 Apr 2025 20:51:52 +0900

기본 개념

https://esbook.kimjmin.net/06-text-analysis/6.7-stemming/6.7.2-nori

6.7.2 노리 (nori) 한글 형태소 분석기 | Elastic 가이드북

esbook.kimjmin.net

위 글에 따르면 Nori는 한국어 텍스트 분석을 위해 설계되었으며 Elasticsearch 공식 분석기 입니다.

주요 특징

- 일반 명사, 고유 명사만 등록 ( 한글의 경우 명사, 동명사 정도만 검색 )

- Nori는 기본적으로 품사 필터링을 통해 조사, 접미사 등 17개 품사를 제거(default)

- stoptags 값에 배열로 제외할 품사 코드를 나열해서 입력

벤치 마크 및 알고리즘

https://www.elastic.co/kr/blog/nori-the-official-elasticsearch-plugin-for-korean-language-analysis

공식 한국어 분석 플러그인 “노리”

6.4에 추가된 Elasticsearch 공식 한국어 분석 플러그인 “노리”에 대한 모든 것...

www.elastic.co

형태소 분석 과정

1. 입력 문장 처리

형태소 분석은 입력된 텍스트를 어절 단위로 나눕니다.

예시) "21세기 세종계획" -> "21 + 세기 + 세종 + 계획" 혹은 "21 + 세 + 기세 + 종계 + 획" 등

2. 비용 계산 알고리즘

Viterbi 알고리즘을 사용하여 각 분할 경로의 비용을 계산합니다.

- 비용은 형태소 간 전이 비용과 형태소 자체의 비용으로 구성

- 비용이 낮을수록 더 자연스러운 분할로 간주

- 위의 예시로는 "21 + 세기 + 세종 + 계획" 이 가장 낮은 비용으로 선택될 수 있다.

3. 처리 최적화

- 노리는 입력 텍스트를 글자 단위로 처리하며, 실시간으로 격자를 생성하고 비용을 계산한다.

- 특정 상태에서 가능한 전이가 하나뿐일 때는 즉시 결과를 출력하여 처리 속도를 높인다.

4. 바이너리 사전 활용

- 노리는 MeCab-ko-dic 사전을 바이너리 형식으로 압축하여 효율적으로 검색합니다

(FST(Finite State Transducer)를 사용해 빠르게 검색)

유의사항

- 사용자 사전이 기본사전보다 항상 우위

- 최장일치 우선 등록 / 우선 분석 이슈

profile을 통해 실제 쿼리가 어떻게 구성되는지 확인해보기

baektothefuture — Thu, 27 Mar 2025 20:59:30 +0900

예시 데이터

{
    "id": "park_rocky-mountain",
    "title": "Rocky Mountain",
    "description": "Bisected north to south by the Continental Divide, this portion of the Rockies has ecosystems varying from over 150 riparian lakes to montane and subalpine forests to treeless alpine tundra."
}

"profile"을 통해 실제 쿼리가 어떻게 진행되는지 확인

필드 미지정 시 Query?

GET my-index/_search
{
    "profile": true,
    "query": {
        "query_string": {
          "query":  "(\"park\")"
        }
    }
}

description 확인

필드 미지정 시 모든 필드에 search를 하는것을 확인

괄호 밖과 안에서 서로 다른 필드 지정

case 1:

GET my-index/_search
{
    "profile": true,
    "query": {
        "query_string": {
          "query":  "id:(\"park\")"
        }
    }
}

case 2:

GET my-index/_search
{
    "profile": true,
    "query": {
        "query_string": {
          "query":  "id:((\"park\") AND title:(\"mountain\"))"
        }
    }
}

profile 결과는 각 쿼리 단계별로 소요된 시간과 리소스 사용량을 JSON 형태로 제공합니다.
이를 통해 어떤 부분이 성능 저하를 유발하는지 파악하고, 인덱스 구조나 쿼리 문법을 최적화할 수 있습니다.

활용 방안:
• 인덱스 최적화: 자주 검색되는 필드나 패턴을 파악하여, 해당 필드에 대한 인덱싱 전략을 조정할 수 있습니다.
• 쿼리 구조 개선: 불필요한 복잡한 쿼리 구조를 단순화하거나, 효율적인 검색 연산자로 변경하여 성능을 향상시킬 수 있습니다.

인덱스 샤드 설정에 대해

baektothefuture — Sat, 22 Mar 2025 02:04:09 +0900

유튜브 데이터에 특화된 분석기가 업데이트되어 데이터를 재색인 해야하는 일이 생겼다.

이로인해 새로운 인덱스를 생성해야 했는데

이 과정에서 샤드를 어느정도 설정해야 이상적일까에 대해 생각해보았다.

사용환경 : 크론탭

유튜브 데이터의 하루 색인량은 약 1000건이며 기능 명세상 사용자 쿼리에 의해 업데이트되는 기능은 아니다.

Elasticsearch Shard에 대해

Elasticsearch 쿼리는 샤드당 단일 스레드로 실행된다.
각각의 Shard는 Lucene 인덱스의 인스턴스이며 Lucene 인덱스는 내부적으로 다수의 세그먼트로 구성되어 있다.
노드가 더 많은 힙공간을 가질수록 처리할 수 있는 데이터와 샤드가 늘어난다.
시계열 데이터 기준 적정 샤드 크기는 10GB~50GB이다.
하나의 노드에 저장할 수 있는 샤드의 개수는 가용한 힙의 크기와 비례 하지만 Elasticsearch에서 그 크기를 제한하고 있지는 않다.

* Elasticsearch 공식 블로그에서 제시한 샤드의 개수는 힙 1GB당 20개 미만이다. ( 30GB -> 최대 600 샤드)

위 사용환경을 고려해본다면 색인량도 작고, 크론탭도 5분마다 실행되므로 부담가는 프로세스는 아니다.

2년치 데이터를 색인해 보았을 때 샤드당(pri, rep) 6GB를 사용하므로 샤드 구성을 1:1(pri, rep), 속도를 조금 더 생각한다면 2:1 정도를 생각하고 있다. (물론 이상적인 수치가 아니라 개인적인 의견입니다.)

혹시나 헷갈리실까봐 적습니다..!
프라이머리 샤드 2개, 레플리카 샤드 1개가 있다고 가정한다면 총 샤드 수는 4개입니다.

혹 속도 개선을 위해 샤드 수 변경 요청이 오거나 적정 샤드 크기를 넘어선다면 (20GB)

추후 alias 설정과 ILM을 통해 새로운 인덱스를 만들어 묶어주기로 했다.

참고
공식 사이트 : https://www.elastic.co/guide/en/elasticsearch/refzerence/current/size-your-shards.html
블로그 : https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

병렬 프로세스 최적화_CompletableFuture

baektothefuture — Sat, 11 Jan 2025 15:58:15 +0900

저희 회사는 SNS 데이터를 다룹니다.

데이터의 제목, 내용 길이가 매우 짧은 것부터 긴 것까지 다양한 형태의 데이터들을 처리하고 관리합니다.

재색인 프로세스를 Airflow에 적용하기 위한 검토 과정에서 문제점을 발견하여 최적화를 진행해 보았는데요..!

나름 성공적인 결과를 낸 것 같아 최적화 과정을 공유해드리려고 합니다.

현재 프로세스는 Elasticsearch에서 데이터를 가져와 해당 문서를 분석하고

다시 Elasticsearch로 재색인 하는 과정을 진행하고 있습니다.

그 중 시간이 가장 오래걸리는 텍스트 분석 과정에서 병렬처리를 하고 있는데요! 코드는 아래와 같습니다.

기존 병렬 프로세스 코드

CompletableFuture<List<RDataResultDTO>> analysisDataFuture = CompletableFuture.supplyAsync(() ->
			dataList.parallelStream()
      // 연관어 + 감성어
      .map(data -> dao.getAnalyzedRDataDTO(data, searchDate))
      .collect(Collectors.toList())
);

time : 43~46 sec

개선방안

무작위로 들어오는 텍스트 길이(분석 대상)를 고려할 때, work stealing으로 인한 빈번한 Context Switching이 단일 스레드보다 성능이 저하되지는 않을지, 또는 스레드 수를 고정하는 것이 더 효율적일지에 대해 테스트를 진행했습니다.

분석 결과, I/O 집중 작업보다 CPU 집중 작업의 비중이 높다는 것을 확인했으며, 스레드 풀을 미리 생성하여 고정된 스레드로 처리했을 때 성능이 향상되는 것을 검증했습니다.

하지만 모니터링을 보며 의아했던 점은 worker Thread Running time 입니다.

Worker Thread 실행 시간 : 전체 실행 시간의 약 23%

모니터링을 보고 느낀점은 "일 편하게 하네?" 였습니다.

현재는 분석 단계에서만 병렬 프로세스를 활용하고 있습니다. 하지만 병렬 작업을 분석에서 색인 과정까지 확대하면 처리 속도를 개선하고 CPU를 더욱 효율적으로 사용할 수 있을 것으로 판단했습니다. CPU 사용률과 메모리 활용도가 높지 않은 상태였기에, 시스템에 추가 부하를 주어도 충분히 감당할 수 있을 것으로 보였습니다.

변경사항

리팩토링 (메서드 세분화)
CompletableFuture의 thenAccept를 활용한 비동기작업 동기처리

List<CompletableFuture<Void>> futuresList = new ArrayList<>();
while (check.get()) {
	List<RDataResultDTO> docs = getDocument(searchDate, instance, distribute);
    if(docs.isEmpty()) {
    	break;
    }
    int size = docs.size();
    lastSeq = docs.get(size - 1).getLo_seq_org();
    CompletableFuture<Void> pipeline = CompletableFuture.supplyAsync(() -> doAnalysis(docs),forkJoinPool)
    	.thenAccept(this::postAnalyzedData);
    futuresList.add(pipeline); // 모든 작업을 리스트에 저장
}

// 모든 CompletableFuture 작업이 완료될 때까지 대기
CompletableFuture.allOf(futuresList.toArray(new CompletableFuture[0])).join();

테스트 결과

기존 대비 65% 속도 향상

리팩토링 후 적용된 병렬처리 방식으로 처리 속도가 기존 40초대에서 16초로 65% 향상되었습니다.

열심히 일하는 스레드

다만, 이 방식은 모든 task를 작업 Queue에 넣고 시작하기에 시스템 부하를 고려한 코드 설계가 필요합니다.

텍스트 길이가 5000자에서 9000자인 21,220개의 문서를 34분간 색인해 보았을때

힙 메모리가 지속적으로 증가하는 현상을 확인했으며, 최종적으로 메모리가 감소하긴 했으나 이를 안정적으로 관리하기 위한 코드 개선이 필요했습니다.

추가된 코드


// 가용 프로세서 확인
int processors = Runtime.getRuntime().availableProcessors()-2;
System.out.println("Processor : " + processors);
// 작업 예정 Task 수 관리 변수
int getQueuedTaskCount = processors*2; 

while (check.get()) {
	// 기존 코드
	...
    // 추가
    if (futuresList.size() >= 50) { ///  task를 비워줌으로써 heap을 살짝 덜먹음
        CompletableFuture<Void> allFutures = CompletableFuture.allOf(futuresList.toArray(new CompletableFuture[0]));
        allFutures.join();
        futuresList.clear();
    }
}
if (!futuresList.isEmpty()) {
    CompletableFuture<Void> allRemainingFutures = CompletableFuture.allOf(futuresList.toArray(new CompletableFuture[0]));
    allRemainingFutures.join();
}

CPU와 메모리 사용률을 조정 후 테스트 결과 (최종)

- 왼쪽 (오리지널) : Uptime: 6 min 15 sec / Heap Size: 3,302,490,112B
- 오른쪽 (튜닝) : Uptime: 4 min 38 sec / Heap Size: 3,615,490,048B

시스템 부하를 고려하지 않았을 때는 초반 Used Heap 사이즈가 3GB를 가볍게 넘었었지만 작업량 관리 코드를 추가함으로써 개선된 모습을 볼 수 있었습니다.

지금까지는 현재 환경에 바로 적용할 수 있도록 설계를 하여 최적화를 진행했지만

앞으로 도입될 Airflow, Kubernetes 환경을 감안하면 외부 Queue를 활용하여 확장성과 운용성을 높일 수 있는 설계도 고려해 보면 좋을것 같습니다..!

Curator를 활용한 Snapshot 테스트

baektothefuture — Wed, 8 Jan 2025 21:01:30 +0900

데이터 생애주기를 관리하기 위하여 Curator을 활용한 Bash Script를 구성해보았습니다..!

현재 Crontab으로 하루에 한번 운용되고 있으며 아래와 같은 순서로 동작이 구성되었습니다.

동작 순서
1. allocation : hot → warm
2. snapshot : 사용자 인덱스만 snapshot 생성
3. delete_indices : snapshot이 완료된 인덱스 삭제

#!/bin/bash

snapshot_date=$(date -d '7 days ago' +%Y%m%d)
snapshot_name="lucy_main_bac1_${snapshot_date}_snapshot"

cat << EOF > action_file.yml
actions:
  1:
    action: allocation
    description: "apply shard allocation"
    options:
      key: tier
      value: warm
      wait_for_completion: True
      allocation_type: require
    filters:
      - filtertype: pattern
        kind: prefix
        value: 'lucy_main_bac1_'
      - filtertype: age
        source: name
        timestring: '%Y%m%d'
        unit: days
        unit_count: 3
        direction: older
  2:
    action: snapshot
    description: "Snapshot"
    options:
      repository: backup
      name: ${snapshot_name}
      wait_for_completion: True
      max_wait: 3000
      include_global_state: False
      ignore_unavailable: False
      wait_interval: 5
    filters:
      - filtertype: pattern
        kind: prefix
        value: 'main_target_'
      - filtertype: age
        source: name
        timestring: '%Y%m%d'
        unit: days
        unit_count: 7
        direction: older
  3:
    action: delete_indices
    description: "Delete Selected indices"
    options:
      continue_if_exception: False
    filters:
      - filtertype: pattern
        kind: prefix
        value: 'main_target_'
      - filtertype: age
        source: name
        timestring: '%Y%m%d'
        unit: days
        unit_count: 7
        direction: older
EOF

/usr/local/bin/curator --config /app/curator.yml /app/action_file.yml

매일 갱신해야 하기 때문에 동적인 변수 할당을 위해 Script로 작성하여 실행

Curator을 통한 Snapshot 결과

2025년 1월 1일
목표 인덱스 : main_target_20250101
데이터량 : 약 400만건
걸린 시간 : 8 min

2025년 1월 2일
목표 인덱스 : main_target_20250102
데이터량 : 약 400만건 (4,002,556)
걸린 시간 : 8 min

Docker Hub를 Helm Charts 저장소로

baektothefuture — Mon, 6 Jan 2025 18:56:26 +0900

사이드 프로젝트를 Helm Charts로 배포하려고 합니다.

이를 위해 Helm Charts를 저장할 저장소를 선택해야 하는데,, 현 직장에서는 Harbor을 쓰지만

조금 오래된 내 맥북에서 개발 환경을 구성한다고 생각하니 용량이 아까워,,ㅎ 외부 레지스트리를 이용하려고 합니다.

~~Helm Charts 설치는 되어있다고 가정햐겠습니다.~~

먼저 터미널(iterm, wsl)에 접속해 docker에 로그인 해줍니다.

docker login -u <id> -p <password>

비밀번호를 바로 쓰지 말라네요,,ㅎ 로그인 성공

그 다음 Docker Hub에 올릴 Helm Chart를 만듭니다. (예시용)

helm create <example_이름>

다운로드를 하셨다면 아래와 같은 구조의 폴더가 생성 됩니다.

demo % tree             
.
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 10 files

완성 되었다면..! helm package 명령어를 통해 .tgz 파일로 패키지화 시켜줍니다.

helm package <example_이름>

이제 Docker Hub에 release 하도록 하겠습니다.

helm push example-0.1.0.tgz oci://registry-1.docker.io/<docker id>

Docker Hub에 들어가 확인해보시면 잘 저장되어 있는걸 확인할 수 있습니다..!

Helm Chart 개념 정리

baektothefuture — Tue, 31 Dec 2024 16:16:56 +0900

까먹지 않기 위해 정리하는 글 입니다..!

헬름이란?

쿠버네티스에 패키지를 손수비게 배포할 수 있도록 패키지를 관리하는 쿠버네티스 전용 패키지 매니저

패키지 : 실행 파일뿐만 아니라 실행 환경에 필요한 의존성 파일과 환경 정보들의 묶음

패키지 매니저 : 외부에 있는 저장소에서 패키지 정보를 받아와 패키지를 안정적으로 관리하는 도구 (저장소 아님)

좀 더 이해하기 쉽게 다른 예시를 아래와 같이 정리해보았습니다.

플랫폼	패키지 매니저	저장소	사용 목적
리눅스	yum, apt	배포판 저장소	소프트웨어 의존성 관리
파이썬	pip	pypi.org	파이썬 모듈 의존성 관리
자바	maven	maven repository	자바 라이브러리 의존성 관리
쿠버네티스	helm	artifacthub.io	쿠버네티스 패키지 관리

패키지 매니저의 역할

패키지 관리
패키지 의존성 관리
패키지 보안 관리

왜 쓸까?

문제상황

다수의 오브젝트를 배포하는 yaml 파일은 '---' 인 파일 구분자로 묶어 여러 오브젝트를 단일 야믈로 배포할 수 있습니다.
하지만 이런 경우 변경 사항을 추적할 때 모든 내용이 한 야믈 파일에 담겨 있기 때문에 혼선을 줄 수 있습니다.

이를 해결하려면 목적에 맞게 디렉터리를 만들고 야믈 파일을 분리해 관리하면서 배포 시에는 디렉터리를 kubectl apply -f의 인자로 넘겨
줘야 합니다.

하지만..! 이런 방식을 사용한다면 요구 조건에 변경되는 야믈 파일을 매번 개별 디렉터리에 작성해야 하고 디렉터리가 늘어날수록 관리 포인트도 늘어나게 됩니다.

헬름을 사용한 해결

헬름을 사용하면 요구 조건별로 리소스를 편집하거나 변수를 넘겨서 처리하는 패키지를 만들 수 있습니다.
다양한 요구 조건을 처리할 수 있는 패키지를 차트(Chart)라고 하는데, 이름 헬름 저장소에 공개해 여러 사용자와 공유합니다.

헬름의 전반적인 흐름

누군가 책에서 따온걸 내가 다시 따온..

아티팩트허브 영역은 저장소 영역이라고 보면 될 것 같습니다..!

helm chart의 저장소는 여러가지가 있는데 저희 회사의 경우 Harbor을 주로 쓰는 편입니다.

생산자 영역

작업자가 helm 명령으로 작업 공간을 생성하면 templates 디렉터리로 애플리케이션 배포에 필요한 여러 야믈 파일과 구성 파일을 작성할 수 있습니다.

values.yaml : 조건별 분기, 값 전달, 기본값 처리 등

Charts.yaml : 차트의 이름, 목적, 배포되는 애플리케이션 버전 정보 등

저장소 영역

사용자가 찾고자 하는 애플리케이션 패키지를 검색하여 저장된 주소를 확인

사용자 영역

애플리케이션의 차트 저장소 주소를 저장소에서 얻으면 헬름을 통해서 주소를 등록 및 설치(릴리스)

NiFi 성능 최적화 테스트_스레드 개수와 Concurrent Tasks 상관관계

baektothefuture — Fri, 6 Dec 2024 21:18:58 +0900

오늘은 NiFi 테스트를 해보며 얻었던 인사이트들을 여러분들께 공유하려고 합니다.

~~(조회수는 적지만)~~

스레드 생성 개수와 Concurrent Tasks 상관관계 찾기

이번 테스트는 Java 스레드 풀을 통한 스레드 생성 개수와 NiFi에서 관리하는 스레드 개수(Concurrent Tasks)를 조정하여 최적의 관계를 찾아볼 예정입니다.

최적화 대상

ExecuteStreamCommand 프로세서 : Elasticsearch에 색인하는 Jar 파일

env.

- 3 node cluster
- core : 40/40/32

알아두기

전체 메뉴인 (우상단의 햄버거 아이콘)을 클릭하여 노드 당 할당할 수 있는 Concurrent Tasks의 최대 개수를 설정해야합니다.
개수를 늘릴 때는 클러스터를 재시작할 필요가 없지만, 이를 줄이게 된다면 클러스터를 재시작할 필요가 있습니다!

Test

1. 스레드 생성 개수 (10) : Concurrent Tasks (10)
2. 스레드 생성 개수 (10) : Concurrent Tasks (20)
3. 스레드 생성 개수 (20) : Concurrent Tasks (20)
4. 스레드 생성 개수 (30) : Concurrent Tasks (30)

ExecuteStreamCommand Status History (차례대로 1, 2, 3, 4번 테스트)

Bytes Read (5 mins)

CPU 사용률

CPU 사용률 From Prometheus

첫번째와 두번째 그래프의 cpu사용량이 같은것으로 보아 Java에서 발생된 스레드의 수는 concurrent tasks 설정에 의해 제한을 받는다는것을 알 수 있습니다.

Number of time driven Threads

파란색 그래프는 NiFi를 통해 돌아가는 모든 스레드의 개수를 나타낸다. -> 노랑, 빨강, 초록을 합친값의 + 1(NiFi 스레드)

스레드 증가율을 확인해보면 그래프는 CPU 사용량과 비례하여 증가하는 형태를 띄우는걸 확인할 수 있습니다.

정리

이번 테스트를 통해 알게된 점은 이와 같습니다.

스레드 생성 개수는 Concurrent tasks 설정값을 넘지 못합니다. -> CPU 점유율이 비슷함

또한 가용한 모든 스레드가 올라가고 일정시간이 지난 후 (빠른 비교를 위해 searchElasticsearch 프로세서의 Schedule Duration을 1 sec로 하였습니다.) Queue에 남아있는 FlowFile을 탐색해 봤을 시 스레드를 코어 수 이상 늘린다고 더 좋은 효율을 내진 않습니다 (큐에 남아있는 FlowFile 수를 비교)

해당 결과를 통해 추측해 볼 수 있는 결과는 스레드 수 : Concurrent tasks 수가 1대1일 때 적합하다고 예상하지만...

저의 경우 긴 시간 측정해보지 않았기에 정확한 값은 아니라고 생각합니다.

좀 더 지켜봐야할 점이 있다고 생각합니다. 두가지 관점으로 생각해보자면 코드, 스레드 생애주기 관점입니다.

코드 관점

실행시킬 코드를 확인해보면 ForkJoinPool을 통해 스레드간 간섭을 허용하여 테스크를 처리하고 있지만 이는 길이가 100인 JSONArray를 처리하고 있으므로 오히려 컨택스트 스위칭이 빈번해져 부하가 더 클 수 있다고 생각합니다. (어떤 데이터를 처리하고 있는지에 따라 다름) 따라서 인입 데이터의 유형에 맞춘 병렬 처리를 좀 더 고려해보는것이 좋을 것 같다고 생각합니다.

스레드 생애주기

Concurrent Threads 개수가 사용 가능한 스레드 수의 배수가 되는것이 1:1 관계보다 더 최적화된 설정일 가능성이 있습니다.
위의 측정한 그래프 중 Number of time driven Threads의 Status History를 보면 스레드 개수보다 ConcurrentTasks가 조금 더 높은것을 확인할 수 있는데 조금 더 오래 돌려본다면 1:1 관계보다 좋은 결과가 나올 가능성이 있습니다.

특이사항

테스트 진행 후 아래와 같은 작업을 진행했었습니다.

- 불필요한 프로세서 정리 (실행대상이 아닌 프로세서 포함)

- 클러스터 재시작

이후 동일조건 하 CPU 점유율이 상당히 줄은 경험이 있습니다.

혹 NiFi를 통해 작업을 하실 경우 불필요한 프로세서는 정리하는 것을 추천드립니다..!

NiFi Index to Index Data Pipeline

baektothefuture — Wed, 20 Nov 2024 21:12:43 +0900

오늘은 Nifi 데이터 파이프라인을 소개하려고 합니다!

NiFi는 Attribute, Content로 이루어진 FlowFile을 활용하며, 직관적으로 파악할 수 있는 UI 제공과 코드 없이도 기존 프로세서를 사용하여 데이터 파이프라인을 개발할 수 있습니다. (기존 프로세서 외에도 Jar, Nar 파일을 프로세서로 실행시킬 수도 있습니다.)

제가 소개할 NiFi를 통한 목표는 아래와 같습니다.

목표

인덱스 to 인덱스 데이터 색인 (Reindex 과정)
- search_after 사용
- Bulk API 사용
제약사항
- Query를 날릴 수 있어야 함
- 중복 불가

구성 환경

NiFi 1.27.0
Linux Centos

필자의 경우 해당 프로세스를 사용하기 전에 SSL 설정, Key를 발급받아 Variables에 저장해둔 상태입니다.

Datapipe line

구성된 파이프라인의 일부인 SearchElasticsearch -> Update Attribute -> SplitJson 부분을 먼저 보겠습니다.

SearchElasticsearch (시작) -> Update Attribute -> SplitJson

SearchElasticsearch 특징

[] JSONArray 형태로 인입
Lucene Syntax 쿼리(ex. query_string)는 지원하지 않는다. (DSL 쿼리를 활용해야 함)
Paging 처리를 할 때 (search_after, ..) 모든 document를 돌았음에도 중지되지 않는다.

이러한 SearchElasticsearch Processor의 특징 때문에 Update Attribute, SplitJson을 추가로 해주어 데이터를 처리합니다.

UpdateAttribute

Update Attribute 프로세서에서는 SearchElasticsearch로 들어온 JSONArray의 길이를 Attribute에 추가해줍니다.

'+' 눌러 속성추가 : ${hit.count:gt(0):and(${hit.count:equals(${size})})}
(여기서 size 는 해당 프로세서 그룹의 variables에 적용해둔 search_after을 페이징 사이즈입니다.)

SplitJson

SplitJson 프로세서에서는 []로 들어온 JSONArray를 JSONObjecty 단위로 분할해 줍니다.

(이어서) EvaluateJsonPath -> RouteOnAttribute -> PutElasticsearchJson

EvaluateJsonPath

EvaluateJsonPath 프로세서에서는 JSONObject로 쪼개진 FlowFile을 중복 처리를 하기 위해 속성을 추가해줍니다.

'+' 눌러 속성추가 : 해당 FlowFile Content 부분에서 Bulk API의 _id로 쓸 고유값을 가져옵니다.
$.kw_docid ('$'는 원문을 뜻함)

RouteOnAttribute

RouteOnAttribute 프로세서를 통해 "UpdateAttribute" 프로세서에서 설정한 속성값에 따라 분기 처리를 해줍니다.

PutElasticsearch

이 프로세서를 통해 Bulk API를 날려줍니다. bulk size를 지정할 수 있으며 Identifier Attribute 설정을 통해
"EvaluateJsonPath"에서 설정한 bulk api의 _id를 지정해줍니다.

* 주의 사항 *
필자는 해당 프로세스를 설정할 때 설정한 _id값이 아닌 랜던값이 설정되었는데요..
당시 속성 이름을 언더바가 포함된 "_id"로 설정했으며 언더바를 지우니 해결되었습니다.

저의 경우 데이터 색인작업이 끝나면 "InvokeHttp" 프로세서를 통해 해당 데이터 파이프라인(프로세서 그룹)을 정지 시켰습니다.
NiFi의 설정이나 다른 부분들을 자세하게 다루진 않았습니다..만 혹시 InvokeHttp를 적용하고 싶으시거나 막히는 부분이 있으시다면 댓글 남겨주세요! 추후에 글을 작성할수도 있지만 댓글달아주시면 바로바로 답변드리겠습니다!

CompletableFuture 테스트

baektothefuture — Sat, 26 Oct 2024 18:52:40 +0900

https://baektothefuture.tistory.com/13

Java - 병렬처리 (Future 인터페이스 활용)

90만건 가까이 되는 데이터를 Elasticsearch에서 읽어 전처리 후 다시 Elasticsearch에 색인했었습니다.이 과정에서 약 3~4시간정도 소요가 되는데 이를 어떻게하면 빠르게 처리할 수 있을까 고민하다가

baektothefuture.tistory.com

이전글에서는 Future 인터페이스에 다루어 보았는데요 이번에는 CompletableFuture에 대해 알아보도록 하겠습니다.

Future vs CompletableFuture

출처 : https://11st-tech.github.io/2024/01/04/completablefuture/

Future	CompletableFuture
Blocking	non-blocking
여러 연산을 함께 연결하기 어려움	여러 연산을 함께 연결
여러 연산 결과를 결합하기 어려움	여러 연산 결과를 결합
연산 성공 여부만 확인할 수 있고 예외처리 어려움	execeptionally(), handle()을 통한 예외 처리

위의 표를 보면 Future 인터페이스의 한계점을 CompletablFuture을 통해 해결한 것을 볼 수 있습니다.

주로 활용하는 메서드

runAsync(): 반환값이 없는 비동기 작업을 실행합니다.

supplyAsync(): 반환값이 있는 비동기 작업을 실행합니다.

thenApply(): 이전 단계의 결과를 받아서 새로운 값을 반환합니다.

thenAccept(): 이전 단계의 결과를 받아서 소비(consumer)합니다.

thenRun(): 이전 단계의 결과를 사용하지 않고 후속 작업을 수행합니다.

이에 대한 간단한 테스트를 해보았는데 CompletableFuture의 특성을 잘 살린(?) 코드는 아니지만 처음접하는 분들은 예시를 보며 조금이나마 감을 잡았으면 좋겠습니다.

package main;

import java.util.*;
import java.util.concurrent.CompletableFuture;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public class CompletableFutureExample {
    public static void main(String[] args) {
        List<Integer> job = IntStream.range(1, 11).boxed().collect(Collectors.toList());

        // jobList 생성 및 초기화
        List<List<Integer>> jobList = IntStream.range(1, 101)
                .mapToObj(i -> new ArrayList<>(job)) // 각기 다른 복사본 추가
                .collect(Collectors.toList());

        String version = System.getProperty("java.version");
        System.out.println("JAVA Version : " + version);

        try {
            System.out.println("=========== multi thread ==============");
            long start = System.currentTimeMillis();

            // CompletableFuture 리스트 생성
            List<CompletableFuture<List<Integer>>> futureList = new ArrayList<>();

            // 각 job에 대해 비동기 작업 수행
            for (List<Integer> ob : jobList) {
                CompletableFuture<List<Integer>> future = CompletableFuture.supplyAsync(() -> {
                    System.out.println("현재 스레드 : " + Thread.currentThread().getName());
                    return working(ob);
                }).thenApply(a -> {
                    System.out.println(Thread.currentThread().getName() + " 마지막 단계");
                    return lastWorking(a);
                });
                futureList.add(future);
            }

            // 모든 작업이 완료될 때까지 대기
            CompletableFuture<Void> combinedFuture = CompletableFuture.allOf(
                    futureList.toArray(new CompletableFuture[0])
            );
            combinedFuture.get(); // 또는 combinedFuture.join();

            long end = System.currentTimeMillis();
            long secDiff = (end - start);

            System.out.println("parallel : " + secDiff + "ms");

            // 작업 결과 수집 (필요한 경우)
            /*
            List<List<Integer>> results = futureList.stream()
                    .map(CompletableFuture::join)
                    .collect(Collectors.toList());
            */

            System.out.println("=========== single thread ==============");
            long start2 = System.currentTimeMillis();

            for (List<Integer> ob : jobList) {
                lastWorking(working(ob));
            }

            long end2 = System.currentTimeMillis();
            long secDiff2 = (end2 - start2);
            System.out.println("single thread : " + secDiff2 + "ms");

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static List<Integer> working(List<Integer> list) {
        try {
            Thread.sleep(2000);
            for (int i = 0; i < list.size(); i++) {
                list.set(i, list.get(i) * 10);
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return list;
    }

    public static List<Integer> lastWorking(List<Integer> list) {
        try {
            Thread.sleep(2000);
            for (int i = 0; i < list.size(); i++) {
                list.set(i, list.get(i) + 1);
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return list;
    }
}

위 코드의 결과값을 보면 아래와 같습니다.

..(생략)..
ForkJoinPool.commonPool-worker-10 마지막 단계 ForkJoinPool.commonPool-worker-16 마지막 단계 ForkJoinPool.commonPool-worker-17 마지막 단계 ForkJoinPool.commonPool-worker-4 마지막 단계
parallel : 24140ms
=========== single thread ==============
single thread : 401558ms
Disconnected from the target VM, address: '127.0.0.1:50706', transport: 'socket' Process finished with exit code 0

본래는 분석 프로세스를 잘게 나누어 병렬처리를 하려 했지만 사실 컨택스트 스위칭 비용만 늘어나 성능이 더 떨어질 뿐 유의미한 결과를 보지 못했습니다. 병렬프로세스라고 무조건 빠르다고 생각하고 적용하지 말고 프로세스 특성에 맞는지 잘 확인하고 적용하면 좋을것 같습니다...!

docker-compose.yml 활용하여 Elasticsearch Cluster 만들기

baektothefuture — Fri, 25 Oct 2024 20:42:55 +0900

동작 테스트를 위해 만들었던 Elasticsearch Cluster docker-compose.yml 파일을 공유하려고 합니다.

본래는 보안모드로 구성하려 했으나 빠른 테스트를 위해 보안설정을 하지 않았습니다.

클러스터의 구성은 아래와 같습니다.

Elasticsearch Cluster
마스터 노드 : 1개
데이터 노드 : 4개 (node.attr.tier을 통해 노드 구분)
- Hot Node : 3개
- Warm Node : 1개
KIbana

++ Hot, Warm 설정은 node.roles 설정이 아닌 node.attr.tier 설정입니다.

docker-compose.yml

version: '3.8'
services:
  # 마스터노드 설정
  master:
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: master
    environment:
      - node.name=master
      - cluster.name=${CLUSTER_NAME}
      - discovery.seed_hosts=hot01,hot02,hot03,warm
      - cluster.initial_master_nodes=master
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - node.roles=[master]
    ulimits:
      # 메모리 제한 해제 (Elasticsearch) 
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data_master:/usr/share/elasticsearch/data
    # 메모리 제한 설정 (Docker container) : 전체 메모리 사용량 제한
    mem_limit: ${ES_MEM_LIMIT}
    ports:
      - ${ES_PORT}:9200

  hot01:
    depends_on:
      - master
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: hot01
    environment:
      - node.name=hot01
      - cluster.name=${CLUSTER_NAME}
      - discovery.seed_hosts=master,hot02,hot03,warm
      - cluster.initial_master_nodes=master
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - node.attr.tier=hot
      - node.roles=[data]

    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data_hot01:/usr/share/elasticsearch/data
    mem_limit: ${ES_MEM_LIMIT}
    ports:
      - 9201:9200

  hot02:
    depends_on:
      - master
      - hot01

    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: hot02
    environment:
      - node.name=hot02
      - cluster.name=${CLUSTER_NAME}
      - discovery.seed_hosts=master,hot01,hot03,warm
      - cluster.initial_master_nodes=master
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - node.attr.tier=hot
      - node.roles=[data]      
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data_hot02:/usr/share/elasticsearch/data
    mem_limit: ${ES_MEM_LIMIT}
    ports:
      - 9202:9200

  hot03:
    depends_on:
      - master
      - hot01
      - hot02
      
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: hot03
    environment:
      - node.name=hot03
      - cluster.name=${CLUSTER_NAME}
      - discovery.seed_hosts=master,hot01,hot02,warm
      - cluster.initial_master_nodes=master
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - node.attr.tier=hot
      - node.roles=[data]      
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data_hot03:/usr/share/elasticsearch/data
    mem_limit: ${ES_MEM_LIMIT}
    ports:
      - 9203:9200

  warm:
    depends_on:
      - master
      - hot01
      - hot02
      - hot03
    
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    container_name: warm
    environment:
      - node.name=warm
      - cluster.name=${CLUSTER_NAME}
      - discovery.seed_hosts=master,hot01,hot02,hot03
      - cluster.initial_master_nodes=master
      - bootstrap.memory_lock=true
      - xpack.security.enabled=false
      - node.attr.tier=warm
      - node.roles=[data]      
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data_warm:/usr/share/elasticsearch/data
    mem_limit: ${ES_MEM_LIMIT}
    ports:
      - 9204:9200

  kibana:
    image: docker.elastic.co/kibana/kibana:${STACK_VERSION}
    container_name: kibana
    ports:
      - ${KIBANA_PORT}:5601
    environment:
      - ELASTICSEARCH_HOSTS=http://master:9200
    mem_limit: ${KB_MEM_LIMIT}
    depends_on:
      - master
      - hot01
      - hot02
      - hot03
      - warm

volumes:
  data_master:
    driver: local
  data_hot01:
    driver: local
  data_hot02:
    driver: local
  data_hot03:
    driver: local
  data_warm:
    driver: local

#네트워크 설정
networks:
  default:
    name: elastic
    external: true # 기존에 만들어둔 네트워크 사용

.env

#ELASTIC_PASSWORD=elastic

#KIBANA_PASSWORD=elastic

STACK_VERSION=8.15.3

CLUSTER_NAME=docker-cluster

ES_PORT=9200

KIBANA_PORT=5601

ES_MEM_LIMIT=1000000000
KB_MEM_LIMIT=1000000000

docker-copose.yml과 .env를 같은 파일내에 두고 docker-compose up을 실행시키면 Elasticsearch cluster를 구성할 수 있습니다.

아무도 안들어오지만 혹여라도 보신분들은 테스트 시 잘 사용하셨으면 좋겠네요ㅎ
다음에 기회가 된다면 보안설정도 추가한 docker-compose 파일도 작성해보도록 하겠습니다..!

Java - 병렬처리 (Future 인터페이스 활용)

baektothefuture — Sat, 12 Oct 2024 15:32:19 +0900

90만건 가까이 되는 데이터를 Elasticsearch에서 읽어 전처리 후 다시 Elasticsearch에 색인했었습니다.

이 과정에서 약 3~4시간정도 소요가 되는데 이를 어떻게하면 빠르게 처리할 수 있을까 고민하다가 여러개의 파일을 읽고 처리하는 과정에서 병렬처리를 활용하면 어떨까 생각이 들어 공부해보았습니다.

Future 예시

출처 : https://pjh3749.tistory.com/280

public class FutureMain {
    public static void main(String[] args) {
        ExecutorService executorService = Executors.newCachedThreadPool();
        Future<Double> future = executorService.submit(new Callable<Double>() {
            public Double call() throws InterruptedException {
                return someLongComputation();
            }
        });
        doSomethingElse();
        try {
            Double result = future.get(1, TimeUnit.SECONDS); // <--- 블록 방지
            System.out.println("result : " + result);
        } catch (InterruptedException e) {
            e.printStackTrace();
            // handle e
        } catch (ExecutionException e) {
            e.printStackTrace();
            // handle e
        } catch (TimeoutException e) {
            e.printStackTrace();
            executorService.shutdown();
            // handle e
        }
    }

    private static Double someLongComputation() throws InterruptedException {
        // do something
        System.out.println("someLongComputation");
        Thread.sleep(2000);
        return 1d;
    }

    private static void doSomethingElse() {
        // do something else
        System.out.println("doSomethingElse");

    }
}

결과

doSomethingElse
someLongComputation
java.util.concurrent.TimeoutException
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
at main.FutureMain.main(FutureMain.java:16)

Process finished with exit code 0

Java 5 버전에 나온 비동기 연산을 할때 사용되는 인터페이스입니다. 시간이 오래걸릴 것 같은 작업을 Future를 활용해 작업을 하고 다른 작업을 할 수 있다는 장점이 있습니다.

위 코드를 보면 ExecutorService와 Future 인터페이스가 같이쓰이는것을 볼 수 있습니다.

이는 스레드 Pool을 관리해주는 인터페이스이며 Executors를 통해 여러가지의 스레드 풀을 생성할 수 있습니다.

CachedThreadPool
일정시간동안 스레드를 검색하여 60초 동안 동작이 없을 시 Thread Pool에서 제거한다. Thread의 제한 없이 무한정 생성되며, 해당 Thread가 작업이 60초간 없을 시 제거하는 방식이므로 삭제속도보다 생성되는 양이 더 많다면 효율적이지 못할 수 있기 때문에.
최대 스레드 생성개수, 타임아웃을 설정해주는 것이 바람직해보인다.

FixedThreadPool
고정된 스레드 개수만큼 생성

SingleThreadExecutor
단일 스레드

이와같이 스레드를 만들어 ExecutorService 객체작업을 할당할 수 있습니다.

할당 방법도 여러가지가 있는데 그 중 2가지를 알아보면 아래와 같습니다.

execute() : 리턴타입이 없으며 Runnable 객체로 작업을 할당받는다.
submit() : Future 객체로 리턴을 하며 Callable 객체로 작업을 할당받는다.

ExecutorService의 작업 할당과정에서 return 값을 Future 객체로 반환해주기 때문에 같이 쓰이는 것을 확인할 수 있습니다.

Future를 활용하면 비동기적으로 작업을 처리할 수 있다는 장점이 있는데요

여러 연산을 결합하기 어렵다
비동기 처리 중에 발생하는 예외를 처리하기 어렵다

라는 문제가 있어 개선된 버전인 CompletableFuture 클래스가 Java 8에 업데이트 되었습니다.

Future vs CompletableFuture

출처 : https://11st-tech.github.io/2024/01/04/completablefuture/

Future	CompletableFuture
Blocking	non-blocking
여러 연산을 함께 연결하기 어려움	여러 연산을 함께 연결
여러 연산 결과를 결합하기 어려움	여러 연산 결과를 결합
연산 성공 여부만 확인할 수 있고 예외처리 어려움	execeptionally(), handle()을 통한 예외 처리

이어서 작성하면 좋겠지만

아직 예제 코드들을 충분히 돌려보지 않았기 때문에 다음글에 이어서 작성하도록 하겠습니다..!

Curator에 대해

baektothefuture — Wed, 9 Oct 2024 19:30:17 +0900

데이터 생애주기 관리 프로세스를 개발중입니다..!

원래라면 ILM 을 활용하여 페이즈(Hot, Warm, Cold)를 결정하는것이 적절하나

데이터 관리 시스템이 특별한 상황일 경우(항상 writable, 언더바(_)가 활용된 Index pattern) ILM을 활용하기 어려웠습니다.

따라서 Curator + Shell Script 를 활용하여 ILM 을 대체할 프로세스를 소개하려고 합니다.

목표

1. 지난달 데이터를 Warm 페이즈로 Rollover

2. Warm 노드에 있는 데이터는 primary shard 축소

예시

configuration File

https://www.elastic.co/guide/en/elasticsearch/client/curator/current/configfile.html

Configuration File | Curator Reference [8.0] | Elastic

All hosts must be in HTTP[S]://FQDN.DOMAIN.TLD:PORT form or they will be rejected and Curator will exit with an error. The only exception to this is HTTPS://FQDN.DOMAIN.TLD (without port), in which case :443 is implicit, and is, in fact, appended automatic

www.elastic.co

설정 파일의 경우 해당 예시를 복사하여 hosts 부분을 Elasticsearch의 클러스터로 변경해 주었습니다.

action_file.yml

actions:
  1:
    action: allocation
    description: "apply shard allocation"
    options:
      key: tier
      value: warm
      allocation_type: require
    filters:
    - filtertype: pattern
      kind: regex
      value: '^lucy_test_v[1-9]_\d{8}$'
    - filtertype: allocated
      key: tier
      value: hot
      allocation_type: require
      exclude: False
  2:
    action: shrink
    ...
  3: 
    action: index_settings

간단 설명

actions: 를 통해 action_file.yml을 작성할 경우 1, 2를 통해 action을 지정할 수 있다 .

options를 통해 목적 설정을 할 수 있고

filters통해 타겟 인덱스를 지정할 수 있다.

현재는 allocation을 쓰지 않고

shrink action의 allocation 설정을 활용중 입니다.

공식문서를 살펴보면 shrink를 활용하기 위한 조건이 있으니 꼭 꼭 확인하고 사용하세요!

https://www.elastic.co/guide/en/elasticsearch/client/curator/current/shrink.html

Kafka Monitoring 환경 구축

baektothefuture — Fri, 30 Aug 2024 19:52:09 +0900

오늘은 카프카 Lag을 모니터링 하기 위한 Grafana 모니터링 환경을 구축하려고 합니다.

어떤 것들을 설치했고, 어떻게 구성했는지 기록하며 복기해보도록 하겠습니다..!

설치 목록

kafka-exporter
prometheus
grafana

설치 환경 - 리눅스

localhost
- kafka-exporter (docker)
- prometheus (bin)
- grafana (bin)
Test-Server
- Kafka

1. kafka-exporter 설치

설치 : https://hub.docker.com/r/danielqsj/kafka-exporter

https://hub.docker.com/r/danielqsj/kafka-exporter

hub.docker.com

docker run -ti --rm -p 9308:9308 danielqsj/kafka-exporter --kafka.server=<kafka>:9092

설치 할 시 kafka.server가 잡히지 않는다면 체크해봐야할 사항

kafka 실행중인지 확인
kafka의 config (config/kraft/) 폴더 내 server.properties 파일 확인
- advertised.listeners 설정에 PLAINTEXT://<host ip>:9092 설정 확인
방화벽 확인 : 해당 포트 열려있는지 확인
- sudo firewall-cmd --permanent --add-port=9092/tcp
- sudo firewall-cmd --reload

2. prometheus 설치 및 설정

설치 : https://github.com/prometheus/prometheus/releases/download/v2.54.1/prometheus-2.54.1.linux-amd64.tar.gz

# my global config
global:
 scrape_interval: 1s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
 evaluation_interval: 1s # Evaluate rules every 15 seconds. The default is every 1 minute.
 # scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
 alertmanagers:
 - static_configs:
 - targets:
 # - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
 # - "first_rules.yml"
 # - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config
 - job_name: "<이름 설정>"
	 # metrics_path defaults to '/metrics'
	 # scheme defaults to 'http'.
 static_configs:
 - targets: ["<localhost>:9308"]

3. Grafana

설치 : https://grafana.com/grafana/download?pg=get&plcmt=selfmanaged-box1-cta1&platform=linux

Download Grafana | Grafana Labs

Overview of how to download and install different versions of Grafana on different operating systems.

grafana.com

dashboard -> kafka에 맞는 화면을 구성해줍니다!

설치 : https://grafana.com/grafana/dashboards/7589-kafka-exporter-overview/

Kafka Exporter Overview | Grafana Labs

Thank you! Your message has been received!

grafana.com

실행화면

이렇게 해서 모니터링 화면을 구성해보았습니다..!

Kafka + HPA 테스트

baektothefuture — Sun, 4 Aug 2024 23:57:22 +0900

쿠버네티스를 공부해보며 도입해볼만한 것들을 추리고 있는데, HPA를 활용한 어플리케이션 병렬처리가 Kafka의 Consumer Group을 다루기에 궁합이 좋다고 느껴 테스트를 해보았습니다.

++ Kafka 선택 이유

레디스와 카프카를 고민해보긴했는데 온프레미스 환경에서 서비스가 돌아가기 때문에 In-memory로는 Scale-out, Scale-up에 한계가 있어 카프카를 선택하게 되었습니다.

테스트

실행환경

local : minikube

내부망 : Server 1 (Kafka)

동작

1. Elasticsearch 에서 문서를 가져와 Kafka (topic 1)에 적재

2. topic 1에 적재된 문서들을 가져와 전처리 (간단한 Key, value 추가) 후 다시 Kafka (topic 2)에 적재

Kafka client

public class KafkaUtil {

    private static final String bootstrapServer = "192.168.125.64:9092";
    Properties properties = new Properties();

    private Properties setProperties(SwitchParameters switchParameters) {
        switch (switchParameters) {
            case producer:
                properties.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServer);
                // 전송/수신 하는 데이터에 맞추어 Serializer 설정 -> 문자열일 시 StringSerializer
                properties.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
                properties.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
                properties.setProperty(ProducerConfig.ACKS_CONFIG, "all");
                properties.setProperty(ProducerConfig.MAX_BLOCK_MS_CONFIG, "30000");
                return properties;
            case consumer:
                properties.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServer);
                // 전송/수신 하는 데이터에 맞추어 Serializer 설정 -> 문자열일 시 StringSerializer
                properties.setProperty(ConsumerConfig.GROUP_ID_CONFIG, "testtopic");
                properties.setProperty(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
                properties.setProperty(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
                properties.setProperty(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");

                return properties;
        }
        return null;
    }

    public KafkaProducer getProducer() {
        properties = setProperties(SwitchParameters.producer);
        System.out.println("get Properties : " + properties);
        KafkaProducer<String, String> producer = new KafkaProducer<>(properties);
        return producer;
    }

    public KafkaConsumer getConsumer() {
        properties = setProperties(SwitchParameters.consumer);
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);
        return consumer;
    }
}

Maven 환경

- Client를 이용해 pub, sub 기능 구현

Kafka-hpa.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
	name: kafka-hpa
spec:
	selector:
		matchLabels:
			run: kafka-hpa
	replicas: 1
	template:
		metadata:
			labels:
				run: kafka-hpa
		spec:
			containers:
				- name: kafka-hpa
					image: baektothefuture98/kafkatest:0.0.5
					ports: 
						- container: 9092
					resources:
						limits:
							memory: 128Mi
							cpu: 500m
						requests:
							memory: 64Mi
							cpu: 300m
___
apiVersion: v1
kind: Service
metadata:
	name: kafka-hpa
	labels:
		run: kafka-hpa
spec:
	ports:
		- port: 0
	selector:
		run: kafka-hpa

해당 Yaml 파일 작성 후 아래 명령어로 등록

1. kubectl apply -f <kafka-hpa.yaml 파일 위치>

2. kubectl autoscale deployment/kafka-hpa --min=1 --max=4 --cpu-percent=10
-> 최소 1개의 pod - 최대 4개의 pod까지 / cpu 한계 10 퍼센트일 시 적용 (테스트 차 낮게 적용)

Kafka 모니터링 도구 - 임시

https://github.com/provectus/kafka-ui

GitHub - provectus/kafka-ui: Open-Source Web UI for Apache Kafka Management

Open-Source Web UI for Apache Kafka Management. Contribute to provectus/kafka-ui development by creating an account on GitHub.

github.com

결과

kubectl get hpa를 통해 CPU 한계 시 replicas(pod)가 늘어나는지 확인

-> Consumer 어플리케이션에 HTTP API가 없기에 K6 테스트가 아닌 한계를 낮춰 파드 증가 확인

Replicas가 1 -> 4로 CPU 증가량에 따라 설정된 MaxPods만큼 증가하는 것을 확인

minikube dashboard 확인

총 100만건 인입
평균 전송 속도 (100건 기준) : 0.071 sec
CPU 사용률 (LOAD) : 최대 90%

[K8s] 크론잡 기본활용_Cronjob

baektothefuture — Mon, 15 Jul 2024 20:03:28 +0900

개요
현 서비스 중 리눅스의 Crontab을 사용하고 있는 어플리케이션을 쿠버네티스 환경으로 전환하기

쿠버네티스에 대한 전반적인 지식은 공식 Document와 "컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커" 도서에서 공부하였습니다.

구성환경

서버 : Local (Minikube)참고 : https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Fx86-64%2Fstable%2Fbinary+download

minikube start

minikube is local Kubernetes, focusing on making it easy to learn and develop for Kubernetes. All you need is Docker (or similarly compatible) container or a Virtual Machine environment, and Kubernetes is a single command away: minikube start What you’ll

minikube.sigs.k8s.io

➡️ kubectl 업그레이드 필요

기본개념

Cronjob 실행 과정 (출처 : 무신사 테크)

Cronjob workflow, Deployment와 비교 (출처 : 무신사 테크)

Cronjob Manifest 파일 구조

# -------------------------------- Cronjob 부분
apiVersion : batch/v1
kind: Cronjob # 유형 지정

metadata:
	# ...
spec:
	schedule: "*/1 * * * *" #1분마다 실행
    # ...
    # --------------------------- Job 부분
    jobTemplate:
    	# ...
        # ----------------------- Pod 부분
		template: 
        	metadata: 
            # ...
            containers: 
            	- name:
                  image: <docker image>

Test

사용파일 : System.out.println("Hello Docker!"); 여러개로 구성된 간단한 Java 어플리케이션

1. DockerFile 작성

FROM maven:3.6.3-jdk-8-slim AS build

COPY ../.. /root/sources

WORKDIR /root/sources

RUN mvn package

FROM openjdk:8-jdk-alpine

RUN mkdir /app

COPY --from=build /root/sources/target/dockerTest-1.0-SNAPSHOT.jar /app/dockerTest.jar

# ----2-3. JAR 파일 실행
CMD ["java", "-jar", "/app/dockerTest.jar"]

2. docker-compose 작성

version: '3'
services:
  bpe-test:
    image: baektothefuture98/test:0.0.1
    build:
      context: .
      dockerfile: ./Dockerfile
    ports:
      - "80:8080"

3. pom.xml 설정
➡️ maven project를 docker 이미지로 묶는 과정에서 오류 발생

-해결 : shade dependency plugin 적용

    <!-- https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin -->
   <dependency>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>3.6.0</version>
   </dependency>
    
  <build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>3.6.0</version>
      <configuration>
        <transformers>
          <transformer
                  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
            <mainClass> 실행할 main 클래스 위치 지정(Source 파일 기준) </mainClass>
          </transformer>
        </transformers>
      </configuration>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>shade</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
  </build>

4. docker hub에 올리기 (혹은 Harbor)

docker-compose build ➡️ docker-compose up (local에 올리기) ➡️ docker-compose push (docker hub에 배포)

5. Cronjob YAML 파일 작성하여 배포

Cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: bpe-test
  namespace: default
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      ttlSecondsAfterFinished: 30
      backoffLimit: 0
      template:
        spec:
          containers:
            - name: bpe-test
              image: <도커 허브 아이디 : baektothefuture98>/test:0.0.1
          restartPolicy: Never

Cronjob YAML 파헤치기
metadata.namespace : 쿠버네티스 클러스터내의 논리적 분리 단위
→ 이름으로 구분하며 namespace.yaml 파일에서 명시가 되어있어야 사용 가능
spec.schedule : 시간 설정

spec.concurrencyPolicy

Allow : old Job, new Job 병렬처리 가능
Replace : 새로운 Job이 발생 시 이전 Job 종료
Forbid : 이전 Job이 완료되지 않았다면 새로운 Job 건너뛰기

spec.successfulJobsHistoryLimit : 성공한 Job 기록을 N개 남기기

spec.failedJobsHistoryLimit : 실패한 Job 기록을 N개 남기기

JOB
ttlSecondAfterFinished : 완료된 Job 자동 정리
→ 완료된 Job은 자동으로 사라지지 않기 때문에 리소스를 차지하므로 정리 필요
backoffLimit : 재시도 횟수
→ 몇 회의 재시도 이후에 잡이 실패되도록 만들어야 하는 경우
https://kubernetes.io/ko/docs/concepts/workloads/controllers/job/#파드-백오프-backoff-실패-정책

Pod
container.image : 도커 이미지 지정
restartPolicy :
Always : 항상 재시작
OnFailure : 비정상 종료 시 재시작
Never : 컨테이너를 재시작 하지 않음

매우매우 간단한 파일로 docker image, docker-compose를 구성하여 크론잡을 구성해 보았습니다.

저처럼 쿠버네티스에 대한 지식이 부족한 분들에게 조금이나마 도움이 되길 바랍니다,,,!

Elasticsearch ILM 탐색기

baektothefuture — Sat, 29 Jun 2024 17:01:58 +0900

그동안 자사 서비스의 최신/과거 데이터 관리를 크론탭을 활용하여 자바 프로세스를 통해 관리를 했다면

이번엔 Elasticsearch의 기능 중 하나인 ILM을 통해 자체적으로 자동화를 할 수 있는지 알아보겠습니다..!

ILM을 통해 관리한다는 것은,,! 자동으로 Phase를 옮긴다는 것과 같은 말이라고 생각합니다.

하지만 애석하게도 서비스의 노드마다 elasticsearch.yml 설정인 node.roles를 상세하게 설정해놓지 않았습니다.(master냐? data냐?) node.attr.tier을 통해 구분할 뿐 node의 역할을 명시해 놓지 않았습니다.

대신. yml 파일에 node.attr을 통해 설정하므로써 노드에 속성을 부여해주며 구분을 지었습니다.

( Node attribute에 대해 공식문서 링크해드리려 했는데 없습니다,, ㅎ ㅠㅠ 찾으면 알려주세요)

즉 ! "node.attr으로 구분한 클러스터에 ILM 적용하기"가 이 글의 주제가 되겠습니다.

목표
1. ILM을 활용하여 daily(hot) -> montly(warm)으로 phases 이동
2. 과거 데이터는 삭제하지 않음
3. warm phase로 이동시 primary shard 수 감소 -> 과거 데이터 수정을 위해 삭제하지 않음

환경설정

- 서버 : 3대

- 데이터 노드에 적용되어 있는 설정 - elasticsearch.yml

node.roles : [data]
node.attr.tier : <hot, warm, …>

node.attr.partition : <number>

Kibana - 페이즈 변경 속도 확인 및 변경
GET /_cluster/settings
PUT /_cluster/settings

** 페이즈 변경 및 인덱스 refresh의 간격이 좁을수록 cpu 부하 **

1. ILM 작성

PUT _ilm/policy/test_policy
{
  "policy": {
    "phases": {
      "hot": {   # ---------- 1
        "min_age": "0d", # ----- 1-1
        "actions": {
          "set_priority": { # ---- 1-2
            "priority": 100
          },
          "rollover": { # ------ 1-3
            "max_age": "30d",
            "max_docs": 1000,
            "max_size": "5gb"
          }
        }
      },
      "warm": { # ----------- 2
        "min_age": "0d",
        "actions": {
          "set_priority": { # ------- 2-1
            "priority": 50
          },
          "allocate": { # ------ 2-2
            "require": {
              "tier" : "warm"
            }
          }, 
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      }
    }
  }
}

1. "hot" phase

1-1 : min_age를 0으로 설정함으로써 대기시간 없이 바로바로 hot phase로 유입된다.

1-2 : set_priority를 설정함으로써 phase의 우선순위를 정해준다.

1-3 : rollover 설정 > 아래의 조건 중 하나라도 만족 시 새로운 인덱스로 rollover

2. "warm" phase

2-1 : 1-2와 같음

2-2 : allocate 설정( 접근 위치를 설정할 수 있음) -> replica shard는 1개로 설정하고, "require" 설정을 통해 사용자가 지정한 노드에 접근

kibana를 통해 접근된 노드를 확인

2. Index_template 작성 및 ILM 적용

PUT _index_template/<Index Template 이름>
{
  "index_patterns": ["hit-test-*"],
  "template": {
    "settings": {
      "number_of_replicas": 1,
      "number_of_shards": 3,
      "index.lifecycle.name" :<ILM_POLICY_이름>,
      "index.lifecycle.rollover_alias" : <rollover_별칭>
    }
  }
}

"index.lifecycle.name" : <앞서 만들었던 ILM Policy>
"index.lifecycle.rollover_alias" : <별칭 설정>

3. Rollover 별칭을 사용하여 초기 인덱스에 적용

PUT hit-test-1
{
  "aliases": {
    <rollover_별칭>: {
      "is_write_index": true
    }
  }

TEST

- "max_docs"의 한계인 10개 이상 doc 넣어보기

put <rollover_alias>/_doc/15
{
  "test" : "hi"
}

초기 인덱스인 "hit-test-1"이 "warm" phase로 넘어가는 것 확인
변경이 안된다면? -> 페이즈 변경 속도 확인 / refresh_interval 확인

- 강제 rollover을 시켜주어 phase 넘어가는 것 확인

PUT /rollover_alias/_rollover 를 날리면 강제 rollover 가능
Rollover 조건을 강제로 변환

POST ilm_test/_rollover
{
  "conditions": {
    "max_docs": 1
} }
POST ilm_test/_rollover
{
  "conditions": {
    "max_age": "1s"
} }

* 오류 시 "is_write_index" : true 설정과 "indices.lifecycle.poll_interval" 설정 확인

결과

1. ILM을 활용하여 daily(Hot) -> montly(Warm)으로 phase 이동 Rollover

※
ILM은 기본적으로 인덱스 생성 시간과 min_age 설정 기준으로 동작하기 때문에 날짜가 변경되어도 Rollover되지 않을 수 있음
-> 현재 날짜에 맞추어 다루려면 Logstash와 연동 모색
관련 링크 :
https://discuss.elastic.co/t/index-not-rollover-when-the-date- changes/272385

2. warm phase로 이동 시 primary shard 수 축소 (삭제는 하지 않음)

※
warm phase에서 shrink를 통해 Primary shard 수를 축소 가능하나 ILM에서의 Warm phase는 더 이상 update가 필요하지 않은 데이터이다.
> primary shard 를 줄인다면 update가 불가하다. 이를 가능하게 하려면 수동으로 처리가 필요하다
(ex - reindex, ...)

3. Phase 변경 중 유입된 데이터는 어떻게 관리되는지?

※ Phase 변경 속도를 늦추어 Test
변경 되기 전 인덱스로 데이터가 유입 (조건에 맞지 않는 인덱스가 발생)
> ex) max_docs는 10까지가 한계임에도 조건 개수를 초과하는 인덱스가 발생한다.

4. 인덱스 이름 제한

인덱스 이름은 ^.*-\d+$ 패턴에 일치해야 한다. (ex ilm-test-000001)

https://www.elastic.co/guide/en/elasticsearch/reference/7.16/indices-rollover- index.html#_using_date_math_with_the_rollover_api

결론

ILM을 통해 이루고자 하는 목표인 자동 인덱스 관리를 하려면 부가적이 프로세스가 필요하다고 생각합니다.

Date 관리 (29,39,31) -> alias : 최대 index 수명 단위가 day이며 month 단위 부터는 없다.
조건 초과 index 관리 -> 강제 rollover 프로세스 개발 (인덱스를 검사하는 최소 interval 단위 1초)

대체 가능 프로세스 고안

※ 글쓴이의 개인적인 생각이므로 완벽하지 않습니다 ※

JAVA + ILM 혼용

ILM : 29일, 30일, 31일에 맞춘 ILM 정책 - alias로 구분하기 때문에 정책이 다르지 않다면 한개도 가능
_index_template : 1~12월의 template 총 12개 → index_pattern = [service_main_2024<01~12>-*<day>]
해당 월에 맞추어 ILM 적용 → Rollover_alias는 12개 (alias 하나에 인덱스 하나만 적용 가능)

순서

Logstash
1. Date에 맞추어 Elasticsearch로 데이터 전달
Elasticsearch(_index_template)
1. day
  1. crontab을 활용하여 강제 rollover
  2. 생성 예시 → service_main_202401-<000001, ... ~>
2. month
  1. logstash 활용하여 date에 맞게 인덱스명 변경
Java Process
1. 년도가 바뀔때마다 template 변경 필요

기대효과

월별 인덱스 검색을 위한 alias 설정 안해도 된다. → rollover_alias 명으로 검색 가능
logstash 활용으로 Date 관리
ILM 장점 활용 가능 (후처리 process 등)

필요사항

template 수정 필요 → 매년 만들어주어야 함
인덱스 rollover 조건이 하루가 지나기 전 rollover이 되지 않도록 충분해야 한다.
- 후처리 목표 (shard, index location) 위주 조건
Logstash에서 ILM에 강제 Rollover을 걸 수 있는지 봐야한다.
기존 서비스가 활용하는 인덱스 명을 ILM 규칙에 맞게 변경

RAID

baektothefuture — Sun, 26 May 2024 21:44:23 +0900

오늘은 RAID에 대해 알아보도록 하겠습니다

Disk 1

단순 데이터 A, B, C, D를 디스크에 저장한다고 한다면 위 그림의 Disk1 처럼 디스크에 차곡차곡 쌓이게 될 것입니다.

하지만 데이터의 양이 늘어난다면? Disk의 용량을 높이기 위해 더 많은 비용이 들것이며 데이터를 쌓는데도 시간이 더 걸릴것입니다.

또한 디스크 하나로 데이터를 관리하다보면 가용성 측면에서도 매우 안좋을 것입니다,,!

이에대한 해결책은? -> RAID

RAID는 아래와 같은 의미를 가지고 있습니다.

- Redundant Array of Independent Disk(독립된 디스크의 복수 배열)

- Redundant Array of Inexpensive Disk(저렴한 디스크의 복수 배열)

말 그대로 RAID는 여러개의 디스크를 연결하여 가용성 보장하고, 비용을 절감하는 방법입니다.

그렇다면 RAID는 어떤 종류가 있는지 알아보도록 하겠습니다!

RAID

RAID 0 _ Striping

RAID 0

RAID 1 _ Mirroring

RAID 1

RAID 5 _ Striping with Parity

Striping with Parity

패리티 비트란?

https://ko.wikipedia.org/wiki/%ED%8C%A8%EB%A6%AC%ED%8B%B0_%EB%B9%84%ED%8A%B8

패리티 비트 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 7 비트 데이터 패리티 포함 8 비트 짝수 홀수 0000000 (0) 00000000 10000000 1010001 (3) 11010001 01010001 1101001 (4) 01101001 11101001 1111111 (7) 11111111 01111111 패리티 비트(Parity bit)는

ko.wikipedia.org

RAID 6 _ Striping with Double Parity

Striping with Double Parity

++ RAID 방식

RAID 10 _ Mirroring + Striping

RAID 50 _ Striping with Parity + Striping

RAID 60 _ Striping with Double Parity + Striping

Elasticsearch_security 설정

baektothefuture — Sun, 5 May 2024 16:02:54 +0900

파일 전송 방법

scp : ssh 원격 접속 프로토콜을 기반으로 한 파일 전송 프로토콜 -> 모든 노드에 배포해야 하기 때문
- 사용 방법
  - scp [option] [filename] [remote id]@[remote ip]:[remote path] > 단일 파일을 원격지로 전송
  - scp [option] [file 1] [file 2] ,,, [file N] [remote id]@[remote ip]:[remote path] > 복수의 파일을 원격지로 전송
  - scp [option] [dic name] [remote id]@[remote ip]:[remote path] > 디렉터리를 원격지로 전송
Filezilla : FTP 프로그램 중 하나 > FTP란? 파일전송 프로그램(File Transfer Protocol)

파일 암호화 방식

X-Pack : Elasticsearch 에서 배포하는 공식 상용 플러그인
P12(Personal informaion Exchange File) : 암호화 키파일
- 바이너리 형식으로 저장, 포멧 파일은 인증서, 개인키 내용을 파일하나에 모두 담고 있다.
- 백업용, 이동용으로 주로 사용
대칭키 방식
- 동일한 키로 암호화, 복호화를 동시에 할 수 있는 방식
- 대칭키 전달 과정에서 누군가가 대칭키를 획득한다면 쉽게 암호화된 데이터를 알아낼 수 있다.
공개키 방식 (대칭키 방식의 단점을 보완한 방식)
- 공개키와 개인키(비밀키) 두개를 가지고 있다.
  - 공개키로 암호화를 하면 데이터 보안에 집중
  - 개인키로 암호화를 하면 인증 과정에 집중

KeyStore

본인의 인증서 및 개인키 (Private Key)
개인키들만 따로 모아서 만든 저장소
생성방법
- bin/elasticsearch-certutil --ca [공개키 절대경로] -> 이름 미입력시 elastic-certificates.p12

TrustStore

신뢰하는 상대방의 root ca 인증서 보관 (root ca란? -> 인증서를 발급해주는 기관 중 최상위 기관, 일반적으로 os에 내장되어 있음)
공개키들만 따로 모아서 만든 저장소
생성방법
- bin/elasticsearch-certutil ca --ca 의 이름 미입력 시 elasticsearch-ca.p12

Elasticsearch 8.12 설치 + 클러스터링 (리눅스)

baektothefuture — Sat, 4 May 2024 09:50:26 +0900

임시저장을 놓쳐 다시 쓰는 글.

티스토리가 익숙치 않은지라 쓰던 글을 다 날렸네요 ㅎ ㅎ ㅎ

! 제정신이 아닐 수 있습니다.

안녕하세요!

오늘은 elasticsearch를 설치 및 클러스터링을 구성했던것을 적어 보도록 하겠습니다.

먼저 Elasticsearch 설치 과정에 대해 설명하고..!

그 다음 환경설정(yml 파일)에 대해 알아보며 클러스터링 과정을 적어보도록 하겠습니다.

후 한번 더 간다

Elasticsearch 설치

설치 환경 : Ubuntu

설치 폴더 : 원하는 위치에 설정 (mkdir /elastic)

설치(바이너리 파일)

* elasticsearch-8.12.0 버전으로 tar.gz 파일 다운

(바이너리 파일 : 아이콘 우클릭 후 링크 주소 복사!)

설치 명령어 : wget https://artifacts.elastic.co/downloads/elasticsearch-8.12.0-linux-x86_64.tar.gz

해당 파일을 다운 받은 후 -> tar -xvf 를 통해 압축을 풀어줍니다.

* 압축 해제 한 후 해당 설치파일 삭제

Elasticsearch 환경 설정

노드 하나에 elasticsearch를 설치하고 운용할 경우 이는 개발모드라고 합니다.

이는 클러스터링을 하지 않으므로 따로 보안설정에 대해 설명하지 않겠습니다. (내맘임.)

elasticsearch는 yml 파일을 활용해 환경설정을 합니다.

이 파일은 config 폴더에 elasticsearch.yml에 있으며 vi 에디터를 활용하여 설정합니다.

이제 single node, clustering 시 위 파일을 어떻게 설정했는지 약간의 설명과 함께 적어보도록 하겠습니다.

single node

cluster.name : 클러스터 이름 지정 (ex. cluster.name : node-1)
node.name : node 이름 지정
node.roles : node 권한 지정 -> 하나만 사용하므로 master와 data 노드 권한 모두 준다.
path.data : master 노드에서 관리하는 메타 데이터의 데이터 파일 경로
path.logs : log 파일 경로
bootstrap.memory_lock : elasticsearch는 jvm 환경에서 동작하므로 고정된 heap 메모리를 두어 다른 프로세스가 침범하지 못하게 막아준다. (boolean)
network.host : node의 ip 설정
http.port : elastiscsearch는 http 프로토콜을 통해 통신하므로 9200 ~ 9299 포트로 설정
transport.port : elasticsearch는 tcp를 통해 노드끼리 통신하므로 9300 ~ 9299 포트로 설정

security 설정 (개발모드이므로 꺼놓을게요)

xpack.security.enabled: false

xpack.security.enrollment.enabled: false

xpack.security.http.ssl:

enabled : false

xpack.security.transport.ssl:

enabled : false

실행 시 유의사항

실행 : bin 폴더의 elasticsearch

-> bin/elasticsearch

Elasticsearch는 관리자 계정으로 실행하면 실행이 안되므로 새로운 user를 만들어 실행시킨다.(useradd 명령어를 통해 사용자 추가)

* 로그 확인 *

[2024-05-01T10:59:47,966][INFO ][o.e.n.Node ] [single-node] initialized
[2024-05-01T10:59:47,966][INFO ][o.e.n.Node ] [single-node] starting ...

이제 클러스터링에 대해 설명해보도록 하겠습니다.

~~키보드를 바꿨더니 키감이 아주 좋군요~~

~~계속 타자를 치고 싶습니다.~~

Elasticsearch Clustering + Security 설정

설치환경 : 서버 3대

이제 clustering 시 elasticsearch.yml 파일 설정 방법에 대해 알아보도록 하겠습니다.

똑같은 elasticsearch.yml 파일 설정이라 크게 달라진 것은 없습니다만

클러스터링 시 오류를 유발할 수 있거나 부가적인 설명이 필요하다고 생각되는 필드만 다시 적어보도록 하겠습니다.

Clustering - elasticsearch.yml

cluster.name : 클러스터 이름 설정 -> 이름이 같지 않다면 같은 클러스터라고 인식하지 않는다.
node.roles : 노드 역할 지정 -> 클러스터링 시 데이터 노드, 마스터 노드 등 역할을 지정해준다.
discovery.type : 다중 노드 클러스터를 형성할 지 여부를 지정 한다.
- discovery.type : multi-node -> 다른 노드가 클러스터에 join 할 수 있도록 허용
- discovery.type : single-node -> 개발모드
node.attr.<rack_id> : 샤드를 여러 rack에 거쳐 분배하고 싶을 때 rack_id를 설정하여 분배
discovery.seed_hosts : 연결할 노드들의 ip, 클러스터 명(cluster.name)도 확인하므로 이름이 일치하는지 확인
cluster.initial_master_nodes : 마스터 후보 노드 지정
보안설정
- security (bin/elasticsearch-certutil) 활성화
  - elasticsearch-certutil ca : 해당 명령어를 실행 후 받은 p12 파일을 모든 노드에 배포
  - elasticsearch-certutil cert --ca <ca.p12경로> : 모든 노드는 분배받은 ca.p12파일로 certificates.p12 파일을 생성
  - certificates.p12를 config 폴더에 놓기 (필수)
- xpack.security.enabled=true로 security 홝성화
- xpack.security.transport.ssl.verification_mode : certificate
- xpack.security.transport.ssl.keystore.path : certificates.p12
- xpack.security.transport.ssl.trustore.path : certificates.p12
- xpack.security.enrollment.enabled : true
- xpack.security.authc.api__key.enabled : false -> API키를 활용하여 보안설정을 하는 방법

보안설정 예시

오류가 나왔다면 고려해봐야 하는 설정

클러스터 이름이 동일한가?
이름과 노드 역할 설정이 제대로 되어있나?
위치 설정 : path, logs 파일 위치
다른 프로세스가 elasticsearch 메모리에 접근 못하도록 방지 되어있나 ? : bootstrap.memory_lock
discovery.seed_hosts에 연결되어야 할 노드의 ip가 제대로 작성되어 있는지
vm 설정이 되어있는지 -> config/jvm.conf 에서 확인
방화벽에 elasticseach가 사용하는 포트가 열려있는지

다음 글은 보안설정에 대해 조금 더 자세히 알아보도록 하겠습니다.

(keystore이 뭔지 truststore이 뭔지,,)

Elasticsearch_security 설정

파일 전송 방법scp : ssh 원격 접속 프로토콜을 기반으로 한 파일 전송 프로토놀 > 모든 노드에 배포해야 하기 때문사용 방법scp [option] [filename] [remote id]@[remote ip]:[remote path] > 단일 파일을 원격지로

baektothefuture.tistory.com

네트워크 기초

baektothefuture — Mon, 29 Apr 2024 21:02:51 +0900

네트워크 계층

TCP/IP 4계층을 기준으로 네트워크에 대해 알아보겠습니다

먼저! 각 4계층에 대해 간략하게 설명하자면.

애플리케이션 계층 : User(사용자) 영역
- 특정 서비스를 제공하기 위해 애플리케이션 끼리 정보를 주고 받을 수 있다.
전송 계층 : (S/W) Kernel 영역
- 송신된 데이터를 수신측 애플리케이션에 확실히 전달하게 한다.
인터넷 계층 : (S/W) Kernel 영역
- 수신
링크 계층 : H/W 영역

이라고 생각하면 됩니다.

조금 더 자세히 각 계층에 대해 설명하자면 이와 같습니다.

애플리케이션 계층 : User(사용자) 영역
- Socket
전송 계층 : (S/W) Kernel 영역
- Port
인터넷 계층 : (S/W) Kernel 영역
- TCP/IP
링크 계층 : H/W 영역
- MAC

MAC

MAC이란 물리적 네트워크 주소(하드웨어의 주소)로써 NIC(Network Interface Card)에 대한 식별자입니다.

NIC

(유선, 무선 두가지 방법을 통해 인터넷에 연결 할 수 있다면 NIC이 2개)

IP 주소

Host에 대한 식별자 (Host란 인터넷에 연결된 컴퓨터)

- NIC이 하나면 IP 하나? : Nope

- NIC에 여러 IP를 Binding할 수 있다.

Port 번호

프로그램에 할당된 번호

제로부터시작하는개발생활

파이썬 알고리즘 문제풀이 : collections.Counter

collections.Counter란?

APM Agent

Elastic APM

https://www.elastic.co/guide/en/apm/agent/java/current/public-api.htmlhttps://www.elastic.co/guide/en/apm/agent/java/current/method-api.htmlpom.xml

.java

서비스 이름을 임의로 지정하여 테스트

elasticsearch 한글 형태소 분석사전

기본 개념

벤치 마크 및 알고리즘

profile을 통해 실제 쿼리가 어떻게 구성되는지 확인해보기

필드 미지정 시 Query?

괄호 밖과 안에서 서로 다른 필드 지정

인덱스 샤드 설정에 대해

병렬 프로세스 최적화_CompletableFuture

기존 병렬 프로세스 코드

개선방안

테스트 결과

CPU와 메모리 사용률을 조정 후 테스트 결과 (최종)

Curator를 활용한 Snapshot 테스트

Curator을 통한 Snapshot 결과

Docker Hub를 Helm Charts 저장소로

Helm Chart 개념 정리

헬름이란?

패키지 매니저의 역할

왜 쓸까?

문제상황

헬름을 사용한 해결

헬름의 전반적인 흐름

NiFi 성능 최적화 테스트_스레드 개수와 Concurrent Tasks 상관관계

스레드 생성 개수와 Concurrent Tasks 상관관계 찾기

최적화 대상

env.

알아두기

Test

ExecuteStreamCommand Status History (차례대로 1, 2, 3, 4번 테스트)

CPU 사용률

Number of time driven Threads

정리

NiFi Index to Index Data Pipeline

목표

구성 환경

Datapipe line

SearchElasticsearch (시작) -> Update Attribute -> SplitJson

SplitJson 프로세서에서는 []로 들어온 JSONArray를 JSONObjecty 단위로 분할해 줍니다. (이어서) EvaluateJsonPath -> RouteOnAttribute -> PutElasticsearchJson

CompletableFuture 테스트

docker-compose.yml 활용하여 Elasticsearch Cluster 만들기

docker-compose.yml

.env

Java - 병렬처리 (Future 인터페이스 활용)

Curator에 대해

목표

예시

configuration File

action_file.yml

Kafka Monitoring 환경 구축

설치 목록

설치 환경 - 리눅스

1. kafka-exporter 설치

2. prometheus 설치 및 설정

3. Grafana

실행화면

Kafka + HPA 테스트

실행환경

동작

Kafka client

Kafka-hpa.yaml

Kafka 모니터링 도구 - 임시

결과

minikube dashboard 확인

[K8s] 크론잡 기본활용_Cronjob

구성환경

기본개념

Cronjob Manifest 파일 구조

Test

Elasticsearch ILM 탐색기

RAID

이에대한 해결책은? -> RAID

RAID

https://www.elastic.co/guide/en/apm/agent/java/current/public-api.html
https://www.elastic.co/guide/en/apm/agent/java/current/method-api.html

pom.xml

SplitJson 프로세서에서는 []로 들어온 JSONArray를 JSONObjecty 단위로 분할해 줍니다.

(이어서) EvaluateJsonPath -> RouteOnAttribute -> PutElasticsearchJson