NCP Search Engine Service to Local ELK

|  배경

woosan 프로젝트에서 네이버 클라우드 플랫폼의 Search Engine Service를 사용해 elasticsearch를 사용했다. 

https://github.com/LuckyVickys/woosan-back/blob/main/Readme.assets/config/ELK.md

woosan-back/Readme.assets/config/ELK.md at main · LuckyVickys/woosan-back

교육과정을 수료하고 바우처 기간이 지나버렸기 때문에 프로젝트를 실행시키려면 다시 elasticsearch 클러스터를 만들어야 한다. 

기존에 사용하던 ncp 클러스터 차이를 느껴보고, 로컬 환경에 ELK 스택을 구축하기 위해 해당 작업을 진행했다. 

 

 

|  과정

|  Docker Compose 란..

 명령어를 입력하는 데 익숙해져도 여러 개의 컨테이너로 구성된 시스템을 실행하기는 조금 귀찮게 느껴진다. 인자나 옵션도 많을뿐더러 볼륨이나 네트워크까지 설정해야하기 때문이다.

 나중에 시스템을 뒷정리 할 때도 만들었던 컨테이너를 ps 커맨드로 일일이 확인해가며 지우려니 수고스럽다.

이렇듯 시스템 구축과 관련된 명령어를 하나의 텍스트 파일(yml)에 기재해 명령어 한번에 시스템 전체를 실행하고 종료와 폐기까지 한 번에 하도록 도와주는 도구가 바로 도커 컴포즈다.

말하자면 docker run 명령어를 여러 개 모아놓은 것과 같다. 컨테이너와 주변 환경을 생성한다. 네트워크와 볼륨까지 함께 만들 수 있다.
*반면 Dockerfile 스크립트는 이미지를 만들기 위한 것으로 네트워크나 볼륨은 만들 수 없다.

 

 

|  Docker Compose 파일 작성

ELK 스택을 로컬 환경에 구성하기 위해 docker-compose.yml 파일을 작성했다. 

Elasticsearch, Kibana, Logstash를 각각 설정하고, MySQL 데이터베이스와 연동했다.

특히, Logstash는 ARM64 환경에서 호환성 문제 때문에 컨테이너를 퍽 많이 내렸다 올렸다 했다..

 

다음과 같이 ELK 스택과 MySQL을 설정하였다. Elasticsearch, Kibana, Logstash, MySQL을 각기 다른 컨테이너로 구성하며, Docker 네트워크 WB-net을 통해 상호 연결되도록 설정하였다.

version: '3.8'
services:
  es:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.10
    container_name: WB-es
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
      - TZ=Asia/Seoul  # 추가된 시간대 설정
    volumes:
      - esdata:/usr/share/elasticsearch/data
    ports:
      - "9200:9200"
    networks:
      - wb-net

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.10
    container_name: WB-kibana
    environment:
      - ELASTICSEARCH_HOSTS=http://WB-es:9200
    ports:
      - "5601:5601"
    networks:
      - wb-net

  logstash:
    image: arm64v8/logstash:7.17.10
    container_name: WB-logstash
    volumes:
      - ./logstash/pipeline:/usr/share/logstash/pipeline
      - ./logstash/mysql-connector-java-8.0.30.jar:/usr/share/logstash/mysql-connector-java-8.0.30.jar
      - logstash_data:/usr/share/logstash/data
    environment:
      - xpack.monitoring.enabled=false
    ports:
      - "9600:9600"
    networks:
      - wb-net

  mysql:
    image: mysql:latest
    container_name: WB-mysql
    environment:
      - MYSQL_ROOT_PASSWORD=********
      - MYSQL_DATABASE==********
      - TZ=Asia/Seoul  # 추가된 시간대 설정
    volumes:
      - mysqldata:/var/lib/mysql
    ports:
      - "3306:3306"
      - "33060:33060"
    networks:
      - wb-net

  redis:
    image: redis:latest
    container_name: WB-redis
    volumes:
      - /Users/tars/Documents/WB/redis:/data
    ports:
      - "6379:6379"
    networks:
      - wb-net

volumes:
  esdata:
  logstash_data:
  mysqldata:

networks:
  wb-net:

 

elk 스택을 활용한 데이터베이스 연동

elk 스택을 활용한 데이터베이스 연동

logstash는 동일하게 설정했다.

 

모든 서비스가 정상적으로 작동하는지 확인하고, Kibana에서 인덱스를 조회해 Elasticsearch와 Logstash가 연동되는 것을 확인하였다.

|  서비스 실행 및 로그 확인

docker-compose up -d

각 서비스가 컨테이너로 실행되면서 Elasticsearch, Kibana, Logstash, MySQL, 그리고 Redis가 동시에 작동된다.

docker logs WB-()

서비스들이 정상적으로 시작된 후, 각 서비스의 로그를 확인하여 초기화 과정과 오류 발생 여부를 점검했다.

이후

Kibana는 http://localhost:5601로 접속하여 웹 인터페이스를 통해 서비스 상태를 확인했고,

Elasticsearch는 http://localhost:9200에 접속하여 클러스터 상태를 확인했다.

 

로그를 통해 모든 서비스가 정상적으로 작동하고 있음을 확인한 후, Kibana에서 인덱스를 조회하여 Elasticsearch와 Logstash가 연동되고 있음을 확인하였다. 

 

|  오류 해결

NCP 환경과의 차이

NCP에서는 기본적으로 관리형 서비스를 제공하기 때문에 인프라 관리가 간단하였다. 반면 로컬 Docker 환경에서는 모든 설정을 수동으로 구성해야 하며, 특히 ARM64 환경에서의 호환성 문제를 해결하기 위해 추가적인 삽질이 필요했다. 

 

버전 선택 

ELK 스택의 최신 버전인 8.x 버전에서는 기본적으로 보안이 활성화되어 있어, 사용자 인증 및 TLS 설정이 필요하다.

예를 들어, Elasticsearch와 Kibana 간의 통신에도 TLS 인증이 기본적으로 요구되며, 이를 구성하는 과정이 추가로 필요하게 된다. 또한, Elasticsearch의 보안 사용자 관리도 기본 설정으로 제공되기 때문에, 기본적으로 제공되는 elastic 사용자의 초기 비밀번호 설정도 필요하다. 

반면, 7.17.23 버전은 이러한 보안 설정을 비활성화할 수 있는 옵션을 제공하며, 초기 설정 과정이 비교적 단순하다. 특히, ARM64 환경에서도 잘 동작하여 호환성 문제를 해결하는 데에도 도움이 되었다. 이러한 이유로 여러 버전을 시도한 끝에 7.17.23 버전을 선택하게 되었다.

 

 

|  소감

Docker Compose를 사용하여 로컬 환경에서 ELK 스택을 구축하는 과정은 클라우드 서비스에서 관리형으로 제공하는 서비스와는 달리 많은 설정과 호환성 이슈를 해결해야 했다. 

NCP는 클라우드 기반으로 모든 것이 최적화된 환경에서 운영되지만, 로컬 Docker 환경에서는 각종 호환성 문제와 리소스 제약 등을 직접 해결해야 한다는 점이 달랐다.

 

처음엔 그냥 컨테이너만 띄우면 되잖아? 쉬운데..라고 생각했지만, 실제로는 버전 문제와 arm 호환성 때문에 꽤 지쳤다...

하지만 이런 문제들을 차근차근 해결하고 e,l,k 하나씩 정상적으로 돌아가는 걸 확인할 때마다 드래곤볼 모으는 기분이었고.. 

마침내 모두 잘 작동하는 걸 확인했을 때는 함박미소 지었다. ㅎㅎ