참고 : https://www.chaossearch.io/blog/opensearch-vs-elasticsearch-comparison
1. 배경
일전에 서비스를 운영하면서 회원가입이 안되는 이슈가 있었다,
기존에 사용하고있던 Elastic Cloud 인스턴스의 JVM 메모리 압력이 최대치의 도달했기 때문이였다.
우리 서비스의 거의 대부분은 AWS 안에 존재하고, 특정 서버의 메모리나 CPU 사용률은 알람을 통해 만일을 대비하고있지만 ElasticCloud 콘솔에 자주 들어가서 매번 메모리를 확인하기에는 쉽지않았고 이번 기회에 다시 OpenSearch를 사용하여 AWS 안에서 모두 관리하는게 좋겠다는 동료 벡엔드 개발자 분의 말에 다시한번 OpenSearch를 고려해보았다.
2. 비교 분석
| 항목 | OpenSearch | Elastic Cloud | 비고 |
|---|---|---|---|
| CPU | 2 core | 2.2 core | |
| RAM | 4 GB | 4 GB | *Elastic Cloud의 경우 키바나 전용 메모리를 별도로 할당해줌(1GB) 무료 |
| 인스턴스 비용(month) | 92.16 $ | 85.25 $ | |
| 스토리지 비용(100GB) | 13.9 $ | Free | 스토리지는 적게 써도 괜찮음 |
| 다중 노드 구성 | 가능 | 불가능 | 스케일 아웃 불가 |
| 개발 편의성 | 나쁨 | 좋음 | *ES cloud 인터페이스 구성이 더 좋음 |
| 관리 편의성 | 좋음 | 나쁨 | AWS 안에서 전부 관리 가능 대쉬보드, 에러알림 |
| 한국어 토크나이저 | 가능 | 가능 | |
| 자동 튜닝 | 가능 | 불가능 | |
| 보안 | 좋음 | 기본 | |
| 스케일 업 | 무중단 | 무중단 | 블루/그린 배포 체계 |
| 색인 성능(1,000만개) | 1시간40분 | 50분 | opensearch의 경우 Timeout 자주 발생 |
| 메모리 압력 | 20%~80% | 10~15% | |
| 데이터 갱신 | 느림 | 빠름 | |
| 검색 성능 | 빠름 | 빠름 | |
| 활용 사례 | 많음 | 많음 |
*참고 OpenSearch의 JVM 메모리 변동폭
3. 총평
AWS Opensearch
장점:
1. 인스턴스 유형, 스토리지를 유연하게 선택가능함.
2. AWS 안에 있기때문에 접근성이 좋음 (모니터링, 알람 설정)
3. 다중 노드 구성이 가능함. (안정성)
4. 보안 옵션이 다양함 (VPC, 사용자 지정 등등)
5. 최소 비용이 저렴함(T3,시리즈로 구성가능)
6. 예약 인스턴스 구매가능 (35% 저럼하게 사용 가능)
단점:
1. 메모리 압력 편차가 큼
2. 데이터 갱신이 느림
3. 성능이 Elastic Cloud에 비해서 떨어짐
Elastic Cloud
장점:
1. GUI 구성이 편리함.
2. 특정 비용을 넘어설 경우 opensearch에 비해 비용이 저렴함.
3. 키바나가 다른 인스턴스로 분리되어 메모리 점유하지않음
4. 메모리 압력 편차가 일정하고, 동일 데이터 대비 점유량이 적음
5. 색인 성능이 좋고, 타임아웃 에러가 발생하지 않음
단점:
1. 다중 노드 구성 불가
2. 관리 편의성이 떨어짐(지속적으로 인식하고 모니터링해야함)
4. 결론
가격대비 효율과 메모리 안정성 측면에서 Elastic Cloud가 더 좋아보임