요약

  • Atlas Core의 별도 Search Nodes는 클러스터를 일시 중지하면 데이터가 삭제된다. 재개 때 새 노드와 색인을 만들며, 재구축 중에는 $search와 $vectorSearch를 쓸 수 없다.
  • 중지 이전 검색 지표는 보존되지 않는다. 재개 전후를 비교할 근거는 구매자가 따로 챙겨야 한다.
  • 중지 중에는 저장 공간만 과금된다. 절감 효과는 실제 청구액과 검색 업무를 다시 시작하는 데 필요한 준비 시간을 함께 봐야 드러난다.

절감 보고서에 빠진 출근 시간

클라우드 비용 회의에서 가장 보기 좋은 숫자 중 하나는 사용하지 않은 시간이다. 밤새 꺼 두었다면 아침의 표에는 절약한 시간이 들어간다. 그 환경이 아침에 다시 일할 준비를 마쳤는지는 다른 사람의 표로 넘어가기 쉽다. MongoDB Atlas의 검색은 이 사소한 회계 습관을 시험한다.

MongoDB가 공개한 일시 중지 절차를 보면, Atlas Core에서 별도로 배치한 Search Nodes의 데이터는 중지할 때 지워진다. 재개하면 새 검색 노드를 만들고 검색 색인을 재구축한다. 이 과정에서 $search와 $vectorSearch는 사용할 수 없다. 공개 미리보기 단계의 Atlas Infinite는 Search Nodes를 지원하지 않으므로 여기서 다루는 구성은 Atlas Core다.

검색 장치를 완성된 채로 재워 두는 상품이 아니다. 보관한 문서를 다시 검색할 수 있게 장치를 조립하는 상품이다. 플랫폼이 조립을 맡아 주는 만큼 운영자는 손을 덜 쓴다. 그러나 고객에게 문을 여는 시각은 여전히 구매 회사가 책임진다.

상품 카탈로그 시연을 준비하는 상황을 생각해 보자. 데이터베이스 연결이 되고 애플리케이션 화면도 떴는데 검색 색인은 아직 공사 중일 수 있다. 이는 해당 동작에서 도출되는 운영 시나리오다. 시연을 약속한 팀이 필요한 것은 자원의 재개 표시가 아니라 실제 상품을 찾는 결과다. 두 가지를 같은 완료로 처리하면, 비용을 줄인 사람의 성과가 시연 담당자의 대기 시간이 된다.

계산기를 끌 수 있는 곳과 없는 곳

클러스터 구성별 비용 문서는 중지 중인 클러스터에는 저장 비용만 부과한다고 설명한다. 기본 제공 저장 용량도 여기에 포함된다. 한동안 쓰지 않는 개발 환경이라면 계산 자원을 계속 돌리지 않는 이점이 분명하다. 중지는 합리적인 선택지가 될 수 있다.

다만 돌아오는 절차까지 계산해야 그 선택을 비교할 수 있다. 누가 미리 재개하고, 누가 색인 상태를 확인하고, 누가 핵심 검색을 실행할 것인가. 이런 작업이 각자의 일정에 흩어지면 구매 부서는 꺼 둔 시간을 알고도 다시 켜는 데 쓰인 조직의 시간을 모르게 된다. 청구서가 줄었다는 관찰과 운영이 싸졌다는 판단 사이에는 그 작업이 놓여 있다.

검색 노드 요금에는 노드 수, 사양, 데이터베이스 노드와의 전송이 반영된다. 노드는 시간 단위로 과금하고, 한 시간의 일부만 실행해도 한 시간분을 청구한다. 실제 비용을 평가하려면 이 규칙을 실제 청구서와 대조해야 한다. 색인이 준비된 순간부터 돈을 받는다는 새 약속을 가격표에 덧붙일 수는 없다.

긴 공백 뒤의 한 번의 준비는 소화하기 쉽다. 짧은 공백을 자주 만들면 준비 과정도 거듭 돌아온다. 그래서 중지의 경제성은 사용 패턴에 달려 있다. 쉬는 시간을 길게 잡을 수 있는 환경과 갑자기 호출되는 환경은 같은 스위치를 눌러도 다른 상품을 산 셈이다.

검색 기록도 새 출발을 한다

검색 지표 안내에는 또 다른 변화가 나온다. 재개 후 제공하는 지표는 새 검색 노드의 것이며, 중지 전 검색 지표는 보관하지 않는다. 새 노드가 일을 시작할 때 비교 그래프의 과거까지 함께 가져오는 구조가 아니다.

팀이 절감 정책을 검증하려면 중지 전에 대표 검색의 결과와 시간을 자체 기록으로 남기는 편이 낫다. 같은 데이터와 같은 색인 정의를 썼는지도 적어야 한다. 조건이 바뀌었다면 그 변화를 표시한다. 그래야 복귀 후 속도가 달라졌을 때 공백의 효과인지, 데이터와 테스트의 차이인지 따져 볼 수 있다.

이 기록의 경제적 가치는 통계의 화려함에 있지 않다. 재개를 관리한 사람과 고객 경험을 맡은 사람이 같은 사건을 이야기할 수 있게 해 준다. 새 그래프만 남으면 옛 기준은 기억력 대회로 바뀐다. 회사가 돈을 쓰고 산 서비스의 평가는 기억력보다 오래 버티는 근거를 가져야 한다.

이름이 같은 재구축도 출발선은 다르다

MongoDB의 색인 관리 문서는 보통의 정의 변경에서 새 색인을 배경에서 만들고 기존 색인이 질의에 계속 답한다고 설명한다. 검색 배치 구성을 바꿀 때도 새 노드를 준비한 뒤 기존 노드를 제거한다. 인수인계가 끝날 때까지 기존 능력이 남는다.

중지 후 복귀는 별도 검색 노드의 데이터를 이미 지운 상태에서 시작한다. 정의 변경에서 제공하는 연속성을 중지에도 적용하면 운영 계획은 틀어진다. 문서에서 같은 '재구축'이라는 단어를 발견하는 것보다 어떤 상태를 남겨 두고 작업하는지 확인하는 일이 더 중요하다.

확인 도구도 있다. getSearchIndexes()는 색인의 상태와 질의 가능 여부를 뜻하는 queryable 등을 반환한다. 기술적 준비를 확인한 다음에는 제품이 실제로 사용하는 검색을 실행해야 한다. 원하는 상품이 나오고 필요한 시간 안에 결과가 도착해야 시연이나 업무를 재개할 수 있다.

고객의 재구축 시간, 검색 결과와 청구서를 연결한 실측 자료가 빠져 있으며, 복귀가 짧고 일정하다면 잦은 중지의 매력은 커진다. 지금도 구매 조건은 충분히 구체적이다. 일시 중지는 준비된 능력을 내려놓고 자동 재조립을 받는 거래다. 절감 보고서는 검색이 다시 출근한 뒤에 마감하는 것이 맞다.