데이터허브(Datahub) 구축기 - (2/3) ElasticSearch 구축 및 연동 과정

안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.

 

 

데이터허브 구축기를 작성해 보고자 한다.
목차는 아래와 같으며, 포스팅이 생각보다 길어져서, 몇 개의 글로 나누어 포스팅할 예정이다.
직전 포스팅에서는 데이터허브가 무엇인지 알아보았다면,
이번 포스팅에서는, 데이터 허브 구축 과정을 포스팅할 생각이다. 구축 개요 및 ElasticSearch 구축~연동 과정을 정리 작성하였다.

 

 

목차

01. Datahub

02. Datahub 용어 정리

03. Datahub 구축 (1/2)

04. Datahub를 구축하며 느낀 점, 마무리

 

 

---

 

 

 

03-1. Datahub 설치 - 개요

 

나는 Datahub를 K8S Helm 차트를 통해 구성하였다.

이때 연동되는 리소스의 경우, 아래와 같이 설정하였다. 설치 혹은 설정 과정을 하나씩 살펴보고자 한다.

 

*Datahub - K8S Helm 차트를 이용해 구축 (version: 0.11.0)

*Elasticsearch- 같은 네임스페이스에 ELK 이미지를 활용해 구축

*Kafka - Conluent Kafka 연동

*PostgreSQL - GCP CloudSQL의 PostgreSQL 인스턴스 연동

 

 

 

 

위에 잠시 언급하였듯, Datahub는 helm차트로 구성돼 있어, 손쉽게 설치가 가능하다.

helm 차트 링크는 아래와 같다.

https://github.com/acryldata/datahub-helm

GitHub - acryldata/datahub-helm: Repository of helm charts for deploying DataHub on a Kubernetes cluster

 

 

다만, Datahub를 설치하기에 앞서, 선수적으로 필요한 리소스가 있다.

가령 위에서 언급한 Kafka, PostgreSQL(MySQL), Elasticsearch (+ neo4 j...)등이 그것들이다.

따라서 이 선수 리소스들이 없다면 이를 설치해주어야 하는데, 이 모든 것을 간편하게 한 번에 설치하기 위해, 링크 내 prerequisites 차트를 우선 구축할 수 있도록 구성이 되어 있다.

 

즉, 위 git link인 acryldata/datahub-helm을 클릭하면, 아래 사진과 같은 두 개의 폴더가 있음을 확인할 수 있으며,

1. (필요한 인프라들이 구축되어 있지 않을 경우 선수 리소스로서) prerequisites 설치

2. datahub 설치

 

와 같은 단계로 작업을 진행해야 한다.

 

다만 prerequisites는 Quick Start를 하는 것이 주요 목적으로 알고 있고, 내부 리소스가 있으면 내부 리소스로 연결해도 무방하다.

나는 prerequisites을 사용하지 않고, (위에 언급하였지만 한번 더) 아래와 같은 리소스들을 이용하였다.

 

*Elasticsearch- 같은 네임스페이스에 ELK 이미지를 활용해 구축

*Kafka - Conluent Kafka 연동

*PostgreSQL - GCP CloudSQL의 PostgreSQL 인스턴스 연동

 

prerequisites로 설치 및 연동 시에는 큰 특이점이 없었지만, 기타 리소스들을 연결하여 설치하려니 자잘한 트러블 슈팅 과정을 겪었다.

이 내용은 포스팅을 통해 천천히 다뤄 보고자 한다.

 

 

---

 

 

 

03-2. Datahub 설치 - 1단계: Elasticsearch 설치 

datahub helm을 설치하기에 앞서, 선수적으로 필요한 Elasticsearch 리소스를 세팅한다.

 

 

 

3-2-1. Storage Class 정의하기

 

K8S에서는 PV와 PVC, Storage Class의 개념이 존재한다. 간단히 개념을 살펴보면 아래와 같다.

 

• Storage Class: 동적 프로비저닝을 수행하기 위해, PV(물리적 Disk) 타입을 설정하는 일종의 템플릿. 네임 스페이스에 속하지 않음.
• PVC(Persistent Volume Claim): 네임 스페이스 레벨에서 관리되며, 저장 정보(요청 사항, ex: 사용할 용량, 읽기 쓰기 모드 설정 방법 등)를 PV에 전달, 이때 PV와는 1:1 관계로 매핑이 됨. 이를 통해 리소스를 효율적으로 사용
• PV(Persistent Volume): 영구 볼륨. 네임 스페이스에 속하지 않음

프로비저닝이란?
저장소 자원 할당 및 구성하는 과정을 의미한다. (1) 동적 프로비저닝과 (2) 정적 프로비저닝으로 나뉜다.

(1) 동적 프로비저닝이란?
PV가 Storage Class 조건에 맞게(=PVC 요청에 맞게) 자동 생성하는 것을 동적 프로비저닝이라고 한다.

(2) 정적 프로비저닝이란?
사용자가 직접 PV를 구성할 경우 정적 프로비저닝이라고 한다.

 

 

즉, 그림으로 보자면 아래와 같다.

GKE(GCP K8S) 의 구조, 출처: https://medium.com/devops-mojo/kubernetes-storage-options-overview-persistent-volumes-pv-claims-pvc-and-storageclass-sc-k8s-storage-df71ca0fccc3

 

 

우선적으로 ElasticSearch 가 동적 프로비저닝을 수행할 수 있도록, StorageClass를 정의했다.

 

 

[Storage Class Deploy 시 유의사항]

이때, 혹시 모를 삭제 사고(?)에 방지하기 위해 reclaimPolicy를 'Retain'으로 설정해 주었다. 

 

reclaimPolicy란, PVC 삭제 시 바인딩 됐던 PV는 어떻게 처리할 지에 대한 옵션이다. 이것이 'Delete'면 바인딩 됐던 PVC가 삭제 시 PV도 함께 삭제된다.

reclaimPolicy: Retain

 

 

reclaimPolicy 설정 시 주의사항은 아래와 같다.

1.  default 값은 'Delete' 이므로 'Retain'설정을 원하면 'Retain' 명시가 필요하다.
2. Storage Class 생성 후에는 reclaimPolicy 설정 값을 업그레이드 변경할 수 없다. Forbidden 에러가 나므로, 초기 생성 시 잘 설정하자! (Error - Forbidden: updates to reclaimPolicy are forbidden)

 

 

 

---

 

 

 

3-2-2. ElasticSearch 설치하기

이후, ECK helm image를 사용해서 ElasticSearch를 설치해 준다. 

연습용으로 설치할 때 사용하는 기본 yaml의 경우, elastic 공식 홈페이지에 접속하면 잘 설명돼 있다.

 

 

다른 설정은 각자 설정하고 싶은 값으로 해도 무방하지만,

위에서 작성한 storage class를 참조해야 하기 때문에, volumeClaimTemplates 옵션은 꼭 정의해주어야 한다.

예시 코드 일부를 보자면 아래와 같다.

  nodeSets:
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
        namespace: {}
      spec: 
        storageClassName: {storage-class-name}

 

 

이처럼, {storage-class-name}을 위에서 생성한 storage class 이름으로 설정해 준 뒤 yaml을 apply 하면,

(1) 우리가 원하는 storage class를 바라보는 PVC, (2) PVC에 정상 바운드된 PV, (3) ElasticSearch 가 잘 생성이 됨을 알 수 있다.

 

 

서비스가 뜨기까지 약 3분 정도 소요되며, 서비스가 뜬 이후 같은 네트워크 내 pod shell에 접속해 curl 명령어를 입력해 정상 실행되는지 체크할 수 있다.

Q. elasticsearh에 접속하기 위한 default password는 어디에 저장되는가?
elasticsearch를 설치한 네임스페이스 내 secret 중, 'elasticsearch-es-elastic-user'이 elasticsearch의 default password다. 또한 default username은 elastic이다.

# elasticsearch-es-elastic-user 내 값 확인 방법
kubectl get secret elasticsearch-es-elastic-user -n {namespace} -o yaml
# 인코딩 된 password를 디코딩하는 방법
echo {value} | base64 --decode

패스워드를 알아냈으면, 아래와 같이 접근을 시도하여 정상적으로 접근이 가능한 지 확인이 가능하다.
# 인덱스 조회(elasticsearch에 잘 접근이 되는지 확인 가능)
curl -X GET -u "elastic:{password}" -k "http://elasticsearch-es-http:9200/_cat/indices? v"

 

 

 

[elasticsearch 설치 시 주의사항]

1. 상황에 따라, elasticsearch TLS(SSL) 비활성화

Elastic 8 버전 이후로는 기본값으로 TLS(SSL)이 설정 돼 있다.

따라서, 접속 시 아래와 같은 에러가 발생하여 연결이 어려운 상황이라면, 자체 서명된 인증서 생성을 비활성화 함으로써 TLS(SSL)를 비활성화시켜야 한다.

curl: (52) Empty reply from server

 

 

다만, 상황에 따라 비활성화가 가능한 경우와 불가능한 경우가 있다. 각 환경에서 보안 상 이슈가 될 수 있을지, 즉 TLS(SSL)을 비활성화시켜도 될지 검토를 하고, 검토 후 비활성화를 해야 한다.

비활성화 설정은 elasticsearch 의 yaml 파일 내 http 옵션에서 설정할 수 있다. 예시 코드는 아래와 같다.

  http:
    tls:
      selfSignedCertificate:
        disabled: true

 

여기서 잠깐! SSL과 TLS란 무엇일까 ?
* SSL: 서버 간 암호화 통신을 위해 동작하는 프로토콜, 인증서를 통해 무결성을 보장
* TLS: SSL의 표준화 용어

 

 

 

 

---

 

 

 

 

03-3. Datahub 설치 - 2단계: Elasticsearch 연동

 

이제, 앞서 생성한 Elasticsearch에 datahub을 연동하자.

Datahub helm의 default values.yaml 은 링크와 같다.

 

 

 

[elasticsearch 연동 시 유의사항]

elasticsearch를 연동할 때 자잘한 이슈가 있었는데, (1) 접속 설정 이슈 / (2) index 관련 파라미터 설정 이슈가 있었다.

추후 운영 시 helm upgrade를 할 상황까지 고려하여 index 구성 값을 세팅하면 좋을 것 같다.

• 접속 설정
  • 본 포스팅처럼 자체 구축한 elastic일 경우, host 명은 'elasticsearch-es-http'이다.
  • default values.yaml에는 구성값 작성 항목이 명시돼 있지 않지만, auth 파라미터로 username, password 설정이 가능하다.

이 접속 설정과 관련한 예시는 아래와 같다.

  elasticsearch:
    host: "elasticsearch-es-http"
    port: "9200"
    auth:
      username: elastic
      password: 
        secretRef: elasticsearch-es-elastic-user
        secretKey: elastic

 

 

• index 파라미터 설정
  • refreshIntervalSeconds 값으로 업데이트된 인덱스를 끌어오는 주기를 결정한다. 길게 설정하면, 업데이트 값이 즉각 반영되기 어려우므로 유의한다.
  • enableMappingsReindex, enableMappingsReindex, upgrade 조건은 re-index 등의 작업 시 직접적인 영향을 준다. 해당 설정에 따라, helm upgrade 시 업그레이드될 때마다 인덱스를 재생성할 수 있다. 따라서, 이를 상황에 맞게 설정해주어야 한다. 해당 설정을 통해, 추후 helm upgrade 등 운영할 때의 상황을 고려한다.

기타 정보는 values.yaml에 잘 설명(주석)이 되어 있으므로, default values.yaml 파일을 참고하자.

index 관련 구성 값	설명
enableMappingsReindex	매핑 변경 시 리인덱싱 활성화 여부
enableMappingsReindex	정적 인덱스 변경 시 리인덱싱 활성화 여부
upgrade- cloneIndices	리인덱싱 시 기존 인덱스를 백업으로서 복제
upgrade - allowDocCountMismatch	리인덱싱 시 기존 인덱스와 신규 생성된 인덱스의 문서 수 일치 여부

 

 

 

적절히 잘 설정이 됐다면, datahub helm values.yaml 내 elasticsearchSetupJob의 enable 상태가 true인지 확인한 뒤,

datahub을 설치하면, datahub-elasticsearch-setup-job job이 뜰 것이다.

helm repo add datahub https://helm.datahubproject.io/
helm install datahub datahub/datahub --values {file_name}.yaml -n {namespace}
# job 정상실행여부 확인
kubectl get job -n {namespace}

 

 

datahub helm 설치 시, 제일 먼저 뜨게 되는 job이 datahub-elasticsearch-setup-job인데,해당 job이 succeeded 상태로 완료되었다면, 설치했던 Elasticsearch와 Datahub가 정상 연동이 된 것이다.

 

 

 

 

 

다음 포스팅에서는 Kafka 관련 구성 값 세팅 시 겪었던 과정을 작성해 보도록 하겠다!