Elasticsearch

# of Posts

1 more property

Gallery

Elasticsearch는 또한 내부적으로 왜 안정적이며, 어떤 알고리즘, 자료구조 등등이기 때문에 빠른것이 보장되는지에 대한 이해도 추가 필요

Elasticsearch가 내부적으로 안정적이며 빠른 이유는 여러 가지가 있습니다.

먼저, Elasticsearch는 Apache Lucene을 기반으로 만들어졌습니다. Lucene은 검색 엔진에 사용되는 강력한 오픈 소스 라이브러리로, 텍스트 인덱싱과 검색에 특화돼 있습니다.

Elasticsearch는 대량의 데이터를 효율적으로 처리하기 위해 여러 가지 알고리즘과 자료구조를 사용합니다. 그 중 하나는 역색인화라는 개념입니다. 역색인화는는 단어가 어느 문서에 나타나는지를 기록해 두어 검색 속도를 향상시키는 데 도움이 됩니다.

Elasticsearch는 분산 시스템으로 설계돼 있어서 여러 노드에 데이터를 분산 저장하고 병렬 처리를 가능하게 합니다. 이렇게 함으로써 데이터 검색 및 분석 작업을 효율적으로 처리할 수 있습니다.

Elasticsearch는 실시간 검색을 지원하고 있어서 데이터가 업데이트되더라도 거의 실시간으로 검색 결과를 반영할 수 있습니다. 이는 대규모의 데이터셋에서도 높은 성능을 제공하는 데 기여하고 있습니다.

엘라스틱 서치의 검색이 빠른 이유?

Elasticsearch는 Lucene 인덱스 를 기반으로 한 검색 엔진입니다.

Lucene은 Apache 소프트웨어 재단에서 개발한 텍스트 검색 라이브러리로, 역색인화를 포함한 다양한 검색 기능을 제공합니다.

엘라스틱 서치는 Lucene을 기반으로 만들어졌기 때문에 Lucene의 강력한 역색인화 기능을 활용하여 대용량의 데이터를 효율적으로 검색할 수 있습니다.

결국, 엘라스틱 서치는 사용자에게 더 편리하고 확장 가능한 인터페이스를 제공하면서 Lucene의 강력한 검색 엔진을 내부적으로 활용하고 있어.

Lucene 의 특징?

Lucene은 텍스트를 단어 또는 토큰 단위로 분석하여 색인화합니다.

[Spring][258] Elasticsearch의 Lucene 인덱싱

JPQL 쿼리로 직접 검색 방식 정하기

아래 쿼리를 @Query 어노테이션을 통해서 작성하여 검색의 방식을 변경 할 수 있다. 기존 직접 내부 로직을 구성하는 방식과 다르게, 마치 JPQL을 사용하는것 처럼 쿼리문을 작성 할 수 있다. 그럼 마찬가지로 쿼리문이 컴파일 단계에서 검사되지 않는 단점이 있을 것으로 보여진다.

QueryDSL로 구현해보기

build.gradle 의존성 추가

QueryDSL 플러그인 및 태스크 설정

ElasticBookRepository를 상속받은 ElasticBookSearchRepositoryImpl.java 구현체에서 다음처럼 구현한다. Q객체를 통해서 쿼리팩토리를 통해 쿼리를 메소드형태로 작성하게 된다. 이러면 컴파일 단계에서 개발자의 오류를 찾을 수 있다.

아래는 JPQL로 직접 쿼리를 보낼 때의 각 검색 API이다.

1. 검색API Template

2. 검색 파라메터

[Spring][258] Elasticsearch APIs

EC2 Kibana의 외부 접속 환경 설정

Kibana는 Elasticsearch의 데이터를 관제하고 각종 분석도구를 제공합니다. 시각화를 담당하는 HTML + Javascript 엔진이라 볼 수 있습니다.

하지만 EC2에서 구축한 경우 해당 서비스에 접속하기 위해서는 외부 사용자 또는 관리자가 EC2서버의 5601포트에 접근 할 수 있어야 하는데 대부분의 DB는 기본적으로 Localhost를 통한 접근만을 허용하고 있습니다. 따라서 외부 접속에 대한 커넥션을 열어주어야 합니다.

Kibana의 설정 파일은 EC2의 다음과 같은 경로에 위치합니다. vi에디터를 통해 CLI환경에서 파일을 수정합니다.

server.host 부분이 기본적으로 localhost로 되어있으며, 이것 조차 주석처리되어 default가 localhost임을 알려주고 있습니다. 해당 부분에 외부 접근을 허용 할 수 있도록 0.0.0.0을 입력해줍니다.

Kibana의 기본 포트는 5601포트입니다.

:wq 를 통해 저장하고 서버를 재시작해줍니다.

EC2의 인바운드 규칙 설정

외부 접근은 허용했지만 EC2 컴퓨터 자체의 포트 접근을 허용해야 합니다. 이는 AWS EC2의 인바운드 규칙 부분에서 대상 포트를 추가하여 접근 권한을 열 수 있습니다.

현재는 기본 설정인 22 SSH-SFPT 포트와 이전 Elasticsearch의 환경 구축을 통해 추가된 9200 Elasticsearch의 포트만 설정되어 있는것을 볼 수 있습니다.

[Spring][258] AWS EC2 Elastic Stack의 Kibana 외부 접속 환경 설정

AWS EC2의 Ubuntu환경에서 Elasticsearch를 설치를 완료한 상태에서는 EC2입장에서의 localhost:9200으로만 Elasticsearch에 접근 할 수 있습니다. 본래 EC2 자체를 생성하고 Elastic stack을 설치한 이유는 해당 인스턴스 자체를 Elasticsearch 전용 서버로 사용하기 위함이기 때문에 스프링부트 프로젝트가 실행되는 EC2와 RDS로 구축된 MySQL에서 해당 서버에 외부접속을 통해서 접근 할 수 있어야 합니다.

Elasticsearch 서비스 시작 및 포트확인

우선 Elasticsearch는 기본적으로 9200포트를 사용하며, 기본 설정에서 현재 로컬 서버(EC2)에서만 통신이 가능하도록 지정되어 있습니다.

elasticsearch의 대부분의 설정은 elasticsearch.yml라는 파일에서 관리하고 있습니다. 해당 파일을 열어 일부분 수정하여 외부 주소로 접근 할 수 있도록 하고자 합니다.

해당 파일을 열어보면 path를 제외한 모든 부분이 주석처리된 상태가 기본입니다.

•

기존 network.host 부분은 다음과 같이 # network.host: 192.168.0.1  주석처리되어있을 것이며, 이곳에 network.host: 0.0.0.0 을 작성합니다.

•

cluster.initial_master_nodes 부분도 주석처리 되어있을 것이며, 이곳에 주석을 해제하여 활성화 시켜줍니다.

vi 에디터를 :wq로 저장하고 나와서 Elasticsearch 서비스를 재시작해줍니다

재시작 후 netstat로 확인해 보도록 하겠습니다.

[Spring][258] AWS EC2 Elasticsearch 외부 접속 환경 설정

로컬(나의 컴퓨터)의 외부접속 환경 만들어서 테스트하기

MySQL의 도서데이터는 book 테이블에 존재하고 709만 개의 대용량데이터로 이동 성공 및 실패를 떠나 AWS에 큰 비용을 초래할 수 있기 때문에 충분한 테스트를 진행하고 있는 과정입니다. 따라서 비교적 데이터양이 적은 book_category로 테스트를 우선 진행하고자 합니다.

Elasticsearch, Logstash, Kibana는 다른 컴퓨터(EC2 인스턴스)에 있으며 특히 Logstash는 내 컴퓨터의 MySQL에 접근해야 합니다. 따라서 내 컴퓨터의 MySQL의 외부 접속을 가능하도록 해야 합니다.

이는 AWS RDS에 MySQL을 구축해둔 프로젝트의 방향과 비슷하게 localhost가 아닌 특정 주소를 통해서 데이터를 받아 올 수 있는지에 대한 원격 접근을 테스트하기 위함입니다.

나의 로컬 컴퓨터의 콘솔에서 MySQL의 설정 파일을 찾아야 합니다. 우선 my.cnf 또는 my.ini라는 파일을 찾아야 합니다. 저의 경우 Homebrew를 통해 MySQL을 설치 했기 때문에 /usr/local/etc/ 라는 경로에서 찾을 수 있습니다.

해당 파일을 vi 에디터를 통해 열어보면 MySQL server 설정 정보가 나타나있습니다. 기본 설정은 localhost로 작동하도록 되어 있습니다.

bind-address = 127.0.0.1 부분을 bind-address = 0.0.0.0으로 변경해줍니다.

이제 mysql 서버를 재시작해줍니다.

현재 계정들은 localhost에 대한 접근 권한을 가진 유저들밖에 없습니다.

root으로 MySQL에 접속해서 %로 표기된 모든 호스트로부터 접근 권한을 가진 유저를 만들어봅니다.

[Spring][258] AWS EC2에 구현된 Elasticsearch 에 내 외부(RDS) MySQL 데이터 전달 테스트 및 EC2 스케일업

AWS EC2에 Elasticsearch 설치하기

Elasticsearch 전용 EC2 인스턴스 생성합니다. 구글링을 통해 기본적으로 프리티어에서 사용되는 t1.micro로는 문제가 발생하는 것을 확인했고, t2.medium(2core CPU / 4GB RAM)을 최초 구성하는 것이 안정적인 테스트가 될 것으로 판단되었습니다.

인스턴스에 접속

기본적으로 AWS 서비스의 키페어를 생성하고 로컬에 다운 받는 과정은 생략했습니다. 결과적으로 {keyname}.pem 이라는 확장자의 사용자 키를 로컬에 받을 수 있고 이것을 통해서 EC2를 접속할 수 있는 권한을 얻게 됩니다. FTP 접속에서도 필요한 인증 방법입니다.

AWS 콘솔에서 간단히 브라우저에서도 콘솔로 EC2 내부에 접근 할 수도 있습니다. SSH 클라이언트에서 제공해주는 CLI 명령어를 통해서 로컬 터미널을 통해 EC2로 접근했습니다.

Elasticsearch 설치를 위한 JDK 설치

EC2 인스턴스를 초기 생성했으니 패키지매니저를 업데이트 합니다.

Elasticsearch에는 JDK가 필요합니다. 우선 Java부터 설치합니다. 프로젝트에서는 JDK17버전을 사용하고 있으므로 openjdk-17 버전을 설치해줍니다.

정상적으로 JDK가 설치 완료되면 버전을 확인해서 설치 상태를 확인합니다.

[Spring][258] AWS EC2 ubuntu 환경의 Elasticsearch 구축

MySQL DB의 데이터와 Elasticsearch 데이터는 동기화로 일관성을 유지해야 한다.

기존 MVP 기능으로 도서의 정보를 변경하는 부분들이 있습니다. 특히 Elasticsearch와 연결된 도서 목록에서 사용자는 도서 대출, 도서 대출 예약을 진행 할 수 있습니다.

사용자가 도서 대출을 진행하면 도서의 대출 가능 여부를 알 수 있는 Status 컬럼은 POSSIBLE에서 IMPOSSIBLE로 변경됩니다. 해당 기능은 HTML의 Ajax HTTP 요청을 통해 MySQL DB에 있는 대상 book_id의 도서의 상태를 즉시 변경하지만, Elasticsearch는 MySQL의 DB를 Logstash로 가져와서 인덱싱하기 때문에 이 과정에서 새로 목록을 불러와야 할 필요성이 있습니다.

Logstash의 데이터 변경 추적 설정 필요성

기존 Logstash를 통해 MySQL의 DB를 전달하여 색인하는 부분입니다. 709만개의 도서 데이터를 한번에 읽어오는 과정에서 JVM의 메모리 부족 현상이 발생하여 200만개씩 메모리에 로드하고 Elasticsearch로 전달하도록 구성되어있습니다.

하지만 이 부분에서 설정의 문제점이 있습니다.

•

최초 실행 1회 이후로 데이터를 전달하고 해당 소스는 종료됨

•

MySQL DB의 변경사항이 생기면 수동으로 해당 파일을 다시 실행시켜 주어야 업데이트가 됨

•

다시 한번 200만개씩 총 709만개를 돌면서 업데이트가 아닌 모든 정보를 덮어쓰는 형태

최초의 전체 709만개 도서 데이터 전달은 기본적으로 실행되어야 하는데 지속적으로 어떤 도서의 정보 업데이트에 대한 별도 동기화 처리가 필요했습니다.

Logstash의 tracking_column을 이용한 변경 추적

Logstash와 JDBC를 사용해 RDBMS와 Elasticsearch의 동기화를 유지하는 방법

Elasticsearch가 기존 관계형 데이터베이스(RDBMS)와 더불어 검색 솔루션으로 배포될 때, 두 데이터 저장소 간에 데이터 동기화를 유지하는 것이 중요합니다. Logstash JDBC 입력 플러그인을 이용해 손쉽게 데이터를 동기화하는 방법을 알아보세요.

https://www.elastic.co/kr/blog/how-to-keep-elasticsearch-synchronized-with-a-relational-database-using-logstash

공식 문서에 따라서 tracking_column을 통해서 특정 컬럼의 값이 변경되는 것을 추적할 수 있고, Elasticsearch에 변동된 행만을 업데이트 할 수 있는 방안이 있었습니다.

[Spring][258] MySQL→Logstash→Elasticsearch 의 동기화 처리에서 발생하는 문제

메인 서버 스캐일 업

•

기존 인스턴스 t1.micro에서 c5.large로 변경

•

IOPS 3000

이벤트 적용 서버 스캐일 업

•

기존 인스턴스 t1.micro에서 c5.xlarge로 변경

•

IOPS 3000

Redis 서버 스캐일 업

[Spring][258] 서버 스케일 업: AWS EC2 인스턴스 업그레이드 및 성능 향상