단일 VM에서 여러 클라이언트 전자 상거래 웹 애플리케이션이 실행되고 있으며 각 웹 애플리케이션은 node.js Express 애플리케이션입니다.
Express 웹 애플리케이션은 API를 통해 백엔드와 통신하여 페이지 콘텐츠와 제품 목록 등을 검색합니다. 그러나 제품 검색을 더 빠르게 하기 위해 현재 메모리 내 데이터베이스(로키스) 모든 검색이 수행되도록 하려면 각 클라이언트의 평균 제품 카탈로그가 약 80개 항목에 불과하기 때문에 현재 우리에게는 매우 잘 작동합니다. 각 클라이언트 웹 앱 내에서 실행되는 간단한 크론이 있어 메모리 내 데이터베이스를 새로 고칩니다. API 호출을 통해 최신 제품 목록을 확인하세요.
이에 대한 몇 가지 단점은 PM2를 사용하여 2노드 클러스터에서 각 애플리케이션을 실행하기 때문에 노드 간에 메모리를 공유할 수 없으므로 인메모리 데이터베이스가 유지되도록 인메모리 데이터베이스를 복제해야 한다는 것입니다. 동기화에서는 IPC를 사용하여 클러스터 내의 모든 프로세스에 메시지를 전달합니다.
우리는 더 큰 제품 카탈로그를 통해 더 큰 클라이언트를 온보드로 가져올 때 각 하위 프로세스에 대해 중복된 메모리 내 데이터베이스를 유지하고 싶지 않습니다.
우리가 제공하는 방식은 비록 고객당 제품 카탈로그가 크지는 않지만 검색량이 꽤 크기 때문에 80개 항목을 가진 고객이 여전히 하루에 1000건의 검색을 받을 수 있다는 것입니다.
몇 가지 옵션을 염두에 두었지만 무엇이 최선인지 확신할 수 없습니다.
옵션 1 - 단일 전역 Elasticsearch 클러스터
저는 Elasticsearch 사용에 대해 이야기하고 생각해 본 후 모든 단일 클라이언트 웹 애플리케이션을 단일 글로벌 Elasticsearch 클러스터로 지정하여 제품 검색을 수행합니다. 이렇게 하면 이벤트를 사용하여 Elasticsearch 데이터베이스를 실시간으로 최신 상태로 유지할 수 있습니다.
하지만 규모가 확장되면 이것이 어떻게 작동할지 모르겠습니다. Elasticsearch가 병목 현상을 일으키는 것을 원하지 않습니다.
옵션 2 - 로컬 nosql 데이터베이스
두 번째 옵션은 단순히 lokijs를 인메모리 데이터베이스로 대체하고 각 VM에 대해 공유 nosql 데이터베이스(예: mongo)를 갖는 것이었습니다. 그런 다음 모든 웹 앱은 쿼리에 로컬 데이터베이스를 사용하고 각 웹 앱은 여전히 책임을 집니다. 자신의 매장에 대한 제품 카탈로그를 업데이트합니다. 그런 다음 더 많은 VM을 추가하면 각 VM은 그곳에서 실행되는 모든 앱이 사용할 수 있는 자체 로컬 데이터베이스를 갖게 됩니다.
우리는 패싯 검색과 패싯 집계를 많이 사용하여 패싯 개수를 얻습니다.