필요성
교내 프로젝트 진행시에 금전적인 문제로 최종 배포 전에 테스트 단계에서는 AWS ec2 t2.medium 단계를 사용하여 Elasticsearch DB 서버를 구축해야 했습니다. 이 과정에서 DB의 노드 개수와 메모리 할당 크기를 결정해야 했습니다.
과정
Docker를 이용하여 Elasticsearch를 구축했기 때문에 Docker compose.yml 파일과 설정 파일 .env 파일을 수정하여 테스트를 진행했습니다.
테스트를 진행할 때는 top 명령어를 이용하여 서버의 메모리 할당 상태를 모니터링하고, 동시에 Docker Elasticsearch 노드의 로그를 분석하여 테스트를 진행했습니다. 이를 통해 각 단계에서의 메모리 사용량과 서버의 상태를 확인하고 최적의 구성을 찾았습니다


테스트 과정 및 결과
1. 4GB, 3개 노드 + Kibana: es02와 es03에서 서버 다운이 발생했습니다.
- Aws 홈페이지에서 볼 수 있는 ec2 log를 통해 확인했습니다
- 따라서 노드에 할당된 메모리를 줄일 필요가 있다고 생각했습니다
2. 2GB, 3개 노드 + Kibana: es03는 실행 실패했습니다. 한마디로 3번째 노드는 실행조차 안된다는 말입니다

3. 2GB, 2개 노드 + Kibana(500MB): 메모리 알맞게 할당했다고 생각했지만 금방 다운되는 서버
- 노드 2개 사용을 위한 compose 파일 수정


- 성공적으로 실행된 모습

- 금방 다운된 서버, 로그 내용: 서버 내 너무 많은 메모리 할당

4. 1.56GB, 2개 노드 + Kibana(500MB): 노드는 정상 작동하지만 시간이 지나면 Kibana가 다운
- 실행은 성공
- 사진이 복잡해보이지만 위에가 docker로 띄워진 노드와 kibana, 아래가 서버 메모리 사용량입니다

- 하지만 몇분 뒤 kibana의 메모리 할당량이 낮아 다운됩니다

5. 1GB, 3개 노드 + Kibana: 할당 메모리 부족으로 ElasticSearch 서버 다운
- docker container log 내용: 137번 OOM(Out Of Memory) 오류 발생
한마디로 메모리 할당량을 늘려줘야합니다

최종결과
- 4GB를 사용하여 Elasticsearch와 kibana를 띄우는 것은 2GB 노드 1개에 1GB Kibana를 띄우는 것이 옳다고 생각했습니다
- 결론적으로 Docker compose.yml 파일에서 노드 3개를 생성하는 대신 노드 1개와 Kibana 조합으로 생성하여 작동 시켰습니다.
- Node1: 2GB 할당(1.56GB으로 해도 되지만 서버 메모리 여유가 있으므로 2GB 할당)
- Kibana: 1GB 할당
- 데이터 삽입시에 문제없이 잘 작동하는 것을 확인했습니다

결론 및 진행사항
제한된 서버에서 ElasticSearch를 사용하여 DB를 구축했습니다. 이 과정에서 로컬 및 가상 서버의 의존성에 따른 환경 변수 및 Compose 파일을 조정하여 메모리와 노드 개수를 사용자 정의했습니다. 이를 통해 과도한 사양을 요구하지 않고도 최적의 성능을 유지할 수 있었습니다.
현재는 데이터 양이 증가와 노드 1개 DB 데이터 안정성 문제를 고려하여 스펙을 향상의 필요성을 느겼습니다. 현재는 이를 해결하고자 팀원이 자신의 작업환경에 별도로 서버(스팩: 4CPU 및 16GB)를 설치했습니다. 이 서버에 새로운 DB 구축할 예정이고 이후에 데이터 이전을 할 계획입니다.
'데이터베이스 > ElasticSearch' 카테고리의 다른 글
Elasticsearch 8.* 버전의 복잡한 쿼리를 QueryDSL의 BoolQuery로 처리하기 (0) | 2024.04.01 |
---|---|
Start Elasticsearch with docker (0) | 2024.03.03 |
필요성
교내 프로젝트 진행시에 금전적인 문제로 최종 배포 전에 테스트 단계에서는 AWS ec2 t2.medium 단계를 사용하여 Elasticsearch DB 서버를 구축해야 했습니다. 이 과정에서 DB의 노드 개수와 메모리 할당 크기를 결정해야 했습니다.
과정
Docker를 이용하여 Elasticsearch를 구축했기 때문에 Docker compose.yml 파일과 설정 파일 .env 파일을 수정하여 테스트를 진행했습니다.
테스트를 진행할 때는 top 명령어를 이용하여 서버의 메모리 할당 상태를 모니터링하고, 동시에 Docker Elasticsearch 노드의 로그를 분석하여 테스트를 진행했습니다. 이를 통해 각 단계에서의 메모리 사용량과 서버의 상태를 확인하고 최적의 구성을 찾았습니다


테스트 과정 및 결과
1. 4GB, 3개 노드 + Kibana: es02와 es03에서 서버 다운이 발생했습니다.
- Aws 홈페이지에서 볼 수 있는 ec2 log를 통해 확인했습니다
- 따라서 노드에 할당된 메모리를 줄일 필요가 있다고 생각했습니다
2. 2GB, 3개 노드 + Kibana: es03는 실행 실패했습니다. 한마디로 3번째 노드는 실행조차 안된다는 말입니다

3. 2GB, 2개 노드 + Kibana(500MB): 메모리 알맞게 할당했다고 생각했지만 금방 다운되는 서버
- 노드 2개 사용을 위한 compose 파일 수정


- 성공적으로 실행된 모습

- 금방 다운된 서버, 로그 내용: 서버 내 너무 많은 메모리 할당

4. 1.56GB, 2개 노드 + Kibana(500MB): 노드는 정상 작동하지만 시간이 지나면 Kibana가 다운
- 실행은 성공
- 사진이 복잡해보이지만 위에가 docker로 띄워진 노드와 kibana, 아래가 서버 메모리 사용량입니다

- 하지만 몇분 뒤 kibana의 메모리 할당량이 낮아 다운됩니다

5. 1GB, 3개 노드 + Kibana: 할당 메모리 부족으로 ElasticSearch 서버 다운
- docker container log 내용: 137번 OOM(Out Of Memory) 오류 발생
한마디로 메모리 할당량을 늘려줘야합니다

최종결과
- 4GB를 사용하여 Elasticsearch와 kibana를 띄우는 것은 2GB 노드 1개에 1GB Kibana를 띄우는 것이 옳다고 생각했습니다
- 결론적으로 Docker compose.yml 파일에서 노드 3개를 생성하는 대신 노드 1개와 Kibana 조합으로 생성하여 작동 시켰습니다.
- Node1: 2GB 할당(1.56GB으로 해도 되지만 서버 메모리 여유가 있으므로 2GB 할당)
- Kibana: 1GB 할당
- 데이터 삽입시에 문제없이 잘 작동하는 것을 확인했습니다

결론 및 진행사항
제한된 서버에서 ElasticSearch를 사용하여 DB를 구축했습니다. 이 과정에서 로컬 및 가상 서버의 의존성에 따른 환경 변수 및 Compose 파일을 조정하여 메모리와 노드 개수를 사용자 정의했습니다. 이를 통해 과도한 사양을 요구하지 않고도 최적의 성능을 유지할 수 있었습니다.
현재는 데이터 양이 증가와 노드 1개 DB 데이터 안정성 문제를 고려하여 스펙을 향상의 필요성을 느겼습니다. 현재는 이를 해결하고자 팀원이 자신의 작업환경에 별도로 서버(스팩: 4CPU 및 16GB)를 설치했습니다. 이 서버에 새로운 DB 구축할 예정이고 이후에 데이터 이전을 할 계획입니다.
'데이터베이스 > ElasticSearch' 카테고리의 다른 글
Elasticsearch 8.* 버전의 복잡한 쿼리를 QueryDSL의 BoolQuery로 처리하기 (0) | 2024.04.01 |
---|---|
Start Elasticsearch with docker (0) | 2024.03.03 |