MySQL과 Elasticsearch의 장단점은 명확하다. MySQL은 트랜잭션을 기반으로 데이터의 정합성을 보존해주는 게 큰 장점이다. 반면에 Elasticsearch는 빠른 검색에 최적화 되어 있다. 현업에서는 이 2가지의 장점을 둘 다 활용하기 위해서 MySQL과 Elasticsearch를 둘 다 활용하는 경우가 많다.
이 때, 문제되는 점이 데이터를 삽입할 때 MySQL과 Elasticsearch에 둘 다 삽입해주어야 한다는 점이다. 즉, 데이터 동기화 문제를 해결해야 한다. 검색해보면 카프카(kafka)와 같은 메시지 큐를 활용해 처리하는 경우가 대부분이다.
하지만 소규모 서비스에서는 카프카(kafka)를 도입하고 관리하는 것 자체가 부담인 경우가 많다. 이런 경우에는 애플리케이션 레벨에서 아래와 같이 직접 동기화를 하기도 한다.
public class ProductService {
...
@Transactional
public Product createProduct(Product product) {
// MySQL에 데이터 저장
productRepository.save(product);
// Elasticsaerch에 데이터 저장
productSearchRepository.save(product);
}
}
아키텍처 그림으로 표현하자면 다음과 같다.
이번 프로젝트에서는 카프카(kafka)를 활용하지 않고 구성할 것이기 때문에 이 아키텍처에 맞게 프로젝트를 진행해보자.
❗
인프라 구성은 정답이라는 게 없다. 장단점이랑 기회 비용(trade-off)만 있을 뿐이다. 만약 ‘Elasticsearch는 무조건 카프카를 써서 데이터를 동기화 해야 돼'라는 생각을 가지고 있었다면, 카프카를 쓰지 않았을 때 정말 서비스를 운영하지 못할 정도의 치명적인 문제점이 있는 지 다시 한 번 찾아보고 고민해보자.
