Solr 이중화 문제

이중화는 이름만으로 안전을 보장하지 않는다. 실제 전환 로직이 올바르게 작동하지 않으면, 운영자는 “보호 장치가 있다”고 믿는 동안 같은 문제를 더 오래 보게 된다. Solr 이중화 문제는 그 점을 아주 선명하게 보여준 사례였다. 겉으로는 이중화 구조가 있었지만, 실제로는 새로운 데이터를 안정적으로 서비스하지 못했고, 그 결과 사용자는 상품 목록이 비정상적으로 보이는 경험을 했다.

이 글은 그래서 단순한 설정 오류 기록이 아니라, 왜 운영자는 항상 “구조가 존재하는가”가 아니라 “구조가 실제로 작동하는가”를 확인해야 하는지를 남기기 위해 쓴다. 검색 계층이 커머스에서 어떤 무게를 가지는지도 함께 드러나는 사례다.

커머스 플랫폼에서 검색 인프라는 보조 기능이 아니라 상품 노출의 중심 경계다. 상품 목록이 정상적으로 보이지 않으면 사용자는 상품 자체를 찾지 못하고, 이는 곧 판매 기회 손실로 이어진다. 그래서 검색 계층의 문제는 단순한 조회 오류가 아니라 사용자 경험과 비즈니스 영향이 직접 맞닿은 운영 문제다.

당시 구조는 인덱싱과 조회를 분리해 안정성을 확보하려는 의도를 갖고 있었다. 그러나 의도가 있다고 해서 결과가 자동으로 따라오는 것은 아니다. 실제 서비스 참조가 기대한 방향으로 전환되지 않으면, 이중화는 오히려 문제를 숨기는 장치가 된다. 이런 유형의 문제는 겉으로 보기엔 부분적인 화면 이상처럼 보이지만, 실제로는 운영자가 믿고 있던 안정성 전제가 깨진 경우가 많다.

증상: 상품이 순차적으로 나타남

처음 관측된 증상은 상품 목록이 한 번에 안정적으로 그려지지 않고, 일부 상품이 늦게 나타나거나 순차적으로 보이는 현상이었다. 사용자 입장에서는 페이지가 열렸는데도 내용이 완성되지 않은 것처럼 보였고, 운영 입장에서는 단순한 프런트엔드 렌더링 문제로 착각하기 쉬운 증상이기도 했다. 하지만 커머스에서는 이런 어색한 노출도 곧바로 신뢰 문제와 이탈로 이어질 수 있다.

이 시점에서 중요한 것은 화면 증상만 보고 판단을 닫지 않는 것이었다. 실제로는 웹 계층보다 검색 인프라의 응답과 반영 상태를 먼저 의심해야 할 이유가 있었고, 그 이유는 시스템 경계를 이미 알고 있었기 때문이다. 같은 현상이라도 어떤 경계 위에서 보는지에 따라 조사 순서가 달라진다.

원인 추적: 검색 인프라 switching 로직 불량

조사를 진행하며 드러난 핵심은 이중화 구조 자체보다 전환 설정이 기대처럼 작동하지 않았다는 점이었다. 인덱싱이 완료된 쪽을 서비스가 새 기준으로 바라봐야 했지만, 실제 참조는 그대로 남아 있거나 일부만 전환되고 있었다. 겉으로는 active/standby 구조가 존재했지만, 실제 운영 경로는 그 설계를 충분히 따라가지 못하고 있었다.

이 문제는 특히 위험했다. 완전히 멈추는 장애라면 오히려 빨리 눈에 띄지만, 일부만 어긋나는 상태는 한동안 애매한 증상으로 남기 쉽기 때문이다. 운영자는 “이중화가 있으니 괜찮다”는 인식을 갖기 쉽지만, 실상은 잘못된 참조 전환 때문에 최신 데이터가 안정적으로 서비스되지 않는 상태였다.

돌이켜 보면 이 이슈의 본질은 “이슈가 없는데 있는 것처럼 보이는 상황”과 “이슈가 있는데 없는 것처럼 보이는 상황”이 동시에 생긴 데 있었다. 화면에서는 프런트 문제처럼 보였지만 핵심은 검색 전환 경로였고, 반대로 이중화가 있으니 괜찮다는 인식 때문에 실제 문제가 한동안 가려지기도 했다. 이런 착시를 줄이려면 증상과 구조를 분리해 보는 운영 습관이 필요하다.

장애 대응 순서

Active/Standby 전환의 원래 의도

원래 의도는 분명했다. 인덱싱 작업은 서비스 중인 노드와 분리된 쪽에서 수행하고, 완료되면 서비스 참조만 안전하게 넘기면 된다. 이렇게 하면 인덱싱 중에도 사용자 조회 안정성을 유지할 수 있고, 검색 결과 반영 시점도 더 통제하기 쉬워진다. 설계 자체는 운영 친화적인 방향이었다.

문제는 설계의 의도가 구현과 운영 설정에서 끝까지 지켜지지 않았다는 점이다. 전환 조건, 참조 대상, 반영 순서를 실제로 검증하지 않으면, 좋은 설계도 운영 현장에서는 무력해질 수 있다. 이 사건은 결국 “좋은 구조”보다 “검증된 구조”가 중요하다는 사실을 다시 확인시켰다.

수정: 설정 변경으로 참조 전환 복원

복구의 핵심은 전환 설정이 실제 의도와 맞게 동작하도록 되돌리는 것이었다. 중요한 것은 복잡한 재설계를 하는 게 아니라, 현재 구조가 약속한 동작을 다시 현실에서 맞추는 일이었다. 운영 이슈의 많은 부분이 그렇듯, 해결은 새로운 구조를 만드는 것보다 기존 구조가 원래 하기로 했던 일을 제대로 하게 만드는 데서 시작했다.

전환이 정상화되자 상품 노출도 다시 안정됐다. 이때 얻은 교훈은, 검색 결과 이상을 볼 때 단순히 인덱스 재생성이나 조회 성능만 의심할 것이 아니라, 전환과 참조 경로까지 함께 봐야 한다는 점이었다. 특히 이중화 구조에서는 “어디가 active로 인식되고 있는가”가 생각보다 중요하다.

교훈: Redundancy does not mean working redundancy

이 사건은 이중화가 존재하는 것과, 실제로 작동하는 이중화가 존재하는 것이 전혀 다르다는 점을 보여줬다. 운영자는 종종 설계 문서에 있는 구조를 신뢰하지만, 실제 안정성은 전환 조건과 참조 경로, 복구 절차가 계속 검증되고 있는지에 달려 있다. 구조가 있다고 끝나는 것이 아니라, 그 구조가 현장에서 살아 움직이는지 확인해야 한다.

커머스의 검색 인프라는 매출과 사용자 경험에 바로 닿아 있기 때문에, 이런 종류의 미세한 실패도 방치하면 비용이 커진다. 이 글을 남기는 이유도 같은 실수를 반복하지 않기 위해서다. 운영에서 중요한 것은 멋진 아키텍처 명칭보다, 그 구조가 실제로 어떤 순간에 깨질 수 있는지 아는 감각이다.

비슷한 패턴의 문제들

이 사건을 겪고 나니 다른 운영 이슈도 비슷한 패턴으로 보이기 시작했다. 이중화, 캐시, 배치, 대체 경로 같은 구조는 모두 “있다”는 사실보다 “정말로 그 순간에 기대한 대로 전환되는가”가 중요했다. 운영자는 결국 이런 전제를 계속 점검하는 사람이다.

시리즈 전체로 보면 이 글은 시스템 경계와 정기 배포, 운영 안정성 이야기를 검색 계층 사례로 압축한 셈이다. 앞선 글들의 맥락을 검색 문제에 대입하면, 왜 구조를 먼저 이해해야 하는지, 왜 운영 판단이 설계 문서만으로 끝나지 않는지 더 분명하게 보인다.

아키텍처 대안 비교와 운영 비용

검색 이중화 설계에서 대안은 크게 두 가지였다. 하나는 전환 로직을 단순화해 운영 실수를 줄이는 방식이고, 다른 하나는 유연한 전환 기능을 유지하되 검증 자동화를 강화하는 방식이다. 전자는 운영 단순성이 장점이고, 후자는 기능 유연성이 장점이다.

당시 교훈은 어느 대안을 선택하든 “전환 검증”을 배포 파이프라인의 필수 단계로 넣어야 한다는 점이었다. 이중화의 실효성은 설계 문서가 아니라 실제 전환 검증 로그와 관측 지표로만 증명된다.

원인-대응 요약표

기술 체크포인트

• active/standby 전환 직후 샘플 검색 질의로 인덱스 반영 상태를 즉시 검증한다.
• 전환 설정 값과 실제 조회 대상 노드가 일치하는지 배포 단계에서 자동 확인한다.
• 검색 이상 징후는 프런트 증상보다 인덱스 전환 경로부터 우선 점검한다.