이 블로그 글의 AI 요약으로 바로 가기

점점 더 많은 팀이 클라우드 네이티브 검색 플랫폼으로 전환하거나 새로운 Apache Solr 대안을 모색함에 따라, 많은 기업이 진퇴양난에 처하게 됩니다. 즉, 신속히 업그레이드하기에는 너무 오래되었지만 포기하기에는 너무 중요한 미션 크리티컬한 Solr 환경을 유지해야 하는 상황입니다. 이런 상황이 발생하면, 한 가지 주제가 갑자기 매우 중요한 이슈로 부각됩니다:

Apache Solr 모니터링
사실은 간단합니다. 구형 Solr도 여전히 뛰어난 성능을 발휘할 수 있지만, 모니터링을 사후 고려 사항이 아닌 최우선 과제로 삼아야만 가능합니다.

왜 여전히 많은 기업이 구버전의 Solr을 사용하고 있을까

대기업만이 구버전을 사용한다고 생각하기 쉽지만, 실제로는 스타트업, 중견 SaaS 기업, 디지털 출판사, 심지어 전자상거래 플랫폼까지 모두 구버전을 사용하고 있습니다. 왜 그럴까요?

몇 가지 일반적인 패턴:

1. 검색 스키마가 지나치게 맞춤화되었다

Solr는 유연성이 뛰어나며, 이는 Solr의 가장 큰 장점이자 업그레이드가 지연되는 원인이기도 합니다. 일단 팀이 스키마, 분석기, 토큰화기 또는 요청 핸들러를 대대적으로 맞춤 설정해 버리면, 업그레이드는 마치 “고고학 프로젝트”와 같은 작업이 되어버립니다.

2. 시스템은 ‘그냥 잘 돌아가기’ 때문에 아무도 손대려 하지 않는다오래된 Apache Solr 클러스터를 물려받은 적이 있다면, 아무도 입 밖으로 내지 않는 진실을 이미 알고 계실 것입니다. 프로덕션 환경에서 Solr을 운영하는 것은 마치 고전 자동차를 도로 위에서 계속 달리는 것과 비슷하다는 사실 말입니다.

모든 것이 완벽하게 조율되면 시스템은 빠르고 안정적이며 실전 검증을 거친 상태로 원활하게 작동합니다. 하지만 단 한 가지라도 제자리를 벗어나는 순간? 검색 지연 시간이 급증하고, JVM 메모리 사용량이 이상하게 변동하며, 결국 당신은 이렇게 묻게 됩니다. “이 Solr 인스턴스는 도대체 몇 년 된 거였지?”

이는 대부분의 엔지니어들이 인정하는 것보다 훨씬 흔한 일입니다. 검색 시스템이 안정적으로 작동하고 고객 만족도가 높다면, 무언가를 변경하는 데 드는 비용이 너무 크다고 느껴지기 마련입니다. 굳이 불일치나 서비스 중단이라는 위험을 감수할 필요가 있을까요?

3. Solr의 주요 버전 간에는 호환성 변경 사항이 있습니다

Solr는 크게 발전해 왔습니다. 구버전과 최신 Solr 릴리스 간에는 보안 설정, 플러그인 호환성, 구성 구조를 재설계해야 하는 경우가 종종 있습니다.

4. Solr는 더 이상 적극적으로 개발되지 않는 레거시 애플리케이션을 지원합니다

많은 조직에서 구형 제품군이나 내부 도구를 지원하기 위해 Solr를 계속 사용하고 있습니다. 이러한 시스템은 안정적이며 수익을 창출하므로, 검색 플랫폼을 전면적으로 교체할 만한 이유가 거의 없습니다.

5. Solr의 Windows 지원 소식에 팀들이 당황했다

Solr는 많은 조직이 적극적으로 추적하지 않는 릴리스 및 지원 종료 주기를 따릅니다. 어느 날은 7.x나 8.x 버전을 사용하다가, 다음 날에는 더 이상 중요한 업데이트가 제공되지 않는다는 사실을 알게 되기도 합니다.

바로 이때 아파치 솔르(Apache Solr)의 취약점에 대한 우려가 제기됩니다. 지원이 중단된 솔르를 사용하는 것은 단순히 기능이 부족해서가 아닙니다. 보안 패치를 적용받지 못하기 때문입니다.

하지만 좋은 소식이 있습니다. 올바른 접근 방식을 취한다면 구버전 Solr도 안정적이고, 성능이 뛰어나며, 안전하게 유지할 수 있습니다.

모든 것은 모니터링에서 시작됩니다.

왜 레거시 Solr 환경에서는 최신 배포 환경보다 모니터링이 더 중요한가

새로운 Solr 클러스터를 모니터링하는 것은 쉽습니다. 모든 것이 문서화되어 있고, 지원도 잘 되며, 클라우드 환경에도 최적화되어 있으니까요. 하지만 구버전을 모니터링하는 건 어떨까요? 그건 완전히 다른 문제입니다.

아파치 솔르(Apache Solr)에 대한 심층 모니터링이 필수적인 이유는 다음과 같습니다:

1. 구버전 Solr에는 “알 수 없는 미지의 요소”가 더 많다

사소한 메모리 누수, 느린 병합 작업, 오래된 구성 설정, 그리고 JVM의 특이한 동작들은 서서히 드러나는 경향이 있습니다. 검색 성능이 갑자기 저하되거나 색인 생성이 느려지기 전까지는 이를 알아차리지 못합니다.

모니터링을 통해 사용자가 영향을 느끼기 훨씬 전에 초기 징후를 포착할 수 있습니다.

2. 항상 교체할 수 있는 엔지니어가 있는 것은 아닙니다

5년 전 Solr의 초기 설계자가 회사를 떠날 때, 그와 함께 많은 노하우도 함께 사라졌습니다. 모니터링은 그 공백을 메워줍니다.

3. 로그만으로는 충분하지 않다

구버전 Solr은 때때로 로그 기록이 일관되지 않거나 모호한 경우가 있습니다. 메트릭스는 로그로는 파악하기 어려운 부분을 명확하게 보여줍니다.

4. 기존 Solr 환경은 종종 과도한 리소스가 할당되어 있다

또한 모니터링을 통해 리소스를 적정 수준으로 조정할 수 있으므로, 불필요한 CPU나 RAM 비용을 지불하지 않아도 됩니다.

5. 보안은 이것에 달려 있습니다

Solr의 취약점, 특히 오래된 취약점은 주로 다음을 악용합니다:

설정 오류
노출된 엔드포인트
보호되지 않은 코어
클러스터 간 통신의 불안정성
구식 라이브러리

보이지 않는 것은 고칠 수 없다.

구형 Solr 클러스터에서 모니터링해야 할 사항 (대부분의 팀이 간과하는 부분)

대부분의 팀은 CPU, 힙 사용량, 쿼리 처리 시간 등 기본적인 항목을 모니터링합니다. 하지만 오래된 클러스터의 경우 더 심층적인 가시성이 필요합니다.

가장 큰 차이를 만드는 지표는 다음과 같습니다:

1. JVM 메모리 풀

구버전 Solr은 JVM에 크게 의존하며, 가비지 컬렉션 동작은 다른 어떤 지표보다도 시스템 상태를 더 잘 알려줄 수 있습니다.

주목할 점:

긴 GC 일시 정지
구형 기기의 높은 점유율
에덴의 갑작스러운 급등
프로모션 실패

이는 종종 초기 불안정성을 나타내는 신호입니다.

2. 쿼리 지연 시간 분포 (단순한 평균값만이 아닌)

평균 지연 시간은 문제를 가려버립니다. P95와 P99 수치는 실제 사용자들이 극한 상황에서 겪는 경험을 보여줍니다.

3. 병합 정책 동작

인덱스 병합은 시간이 지남에 따라 정렬이 어긋나게 되면 클러스터 전체의 성능을 저하시킬 수 있습니다.

찾아보세요:

병합 대기열의 누적
오랫동안 진행 중인 병합 작업
과도한 세그먼트 수

4. 복제 지연

노드 하나가 뒤처지는 것은 더 심각한 성능 문제의 초기 징후입니다.

5. 디스크 I/O 포화

구형 Solr 배포 환경은 대개 구형 디스크에 구축되어 있는 경우가 많으며, Solr 레이어에서 I/O 문제를 해결할 수는 없습니다.

6. 스레드 풀 고갈

Solr의 내부 스레드 풀이 한계에 도달하면, 검색 시스템이 불안정해지는 것은 시간문제입니다.

7. 느린 커밋 주기 또는 커밋 실패

이는 종종 다음과 같은 사실을 드러냅니다:

스키마 문제
잘못된 인덱스 업데이트
디스크 쓰기 속도가 느림
리소스가 부족하게 할당된 노드

8. /admin/metrics 또는 로그에 숨겨진 오류

구버전의 Solr에서는 겉보기에는 별문제 없어 보이지만 인덱스 손상 위험을 암시하는 경고가 표시되는 경우가 있습니다.

모니터링은 단순히 ‘있으면 좋은’ 것이 아닙니다. 이는 여러분의 가장 중요한 방어 수단입니다.

보안 문제: Solr 지원이 종료되면 어떻게 될까

보안은 가장 중요한 문제입니다. 과거에는 Solr에 대한 무단 접근으로 인해 데이터 유출, 원격 코드 실행, 랜섬웨어로 인한 인덱스 암호화 등 심각한 보안 사고가 발생했습니다.

현재 사용 중인 Apache Solr 버전에 대한 지원이 종료되면 다음과 같은 변경 사항이 발생합니다:

1. 더 이상 패치 없음

사용 중인 버전에서 새로운 취약점이 발견된다면, 해결은 전적으로 본인의 몫입니다.

2. 이전 버전으로 적용된 수정 사항 없음

중요 수정 사항은 현재 지원 중인 릴리스에만 적용됩니다.

3. 공격자들은 어떤 버전이 취약한지 알고 있다

익스플로잇 키트는 패치가 적용되지 않은 버전을 자동으로 추적합니다.

4. 오래된 플러그인이 공격 경로가 된다

구형 라이브러리에 의존하는 플러그인도 더 이상 업데이트를 받지 못하게 됩니다.

5. 강화 과정이 복잡해진다

당신은 더 많은 시간을 시스템을 방어하는 데 그 시스템을 사용하는 것보다 방어하는 데 더 많은 시간을 씁니다.

이 때문에 아파치 솔르(Apache Solr)의 대안을 모색하는 것이 화두가 되고 있습니다. 솔르의 지원 종료가 다가오면서 엘라스틱서치(Elasticsearch), 오픈서치(OpenSearch), 메일리서치(Meilisearch) 및 클라우드 네이티브 검색 서비스들이 매력적인 대안으로 떠오르고 있습니다.

하지만 Solr를 교체하는 일은 결코 간단하지 않습니다. 특히 해당 시스템의 인덱싱 로직과 생태계가 밀접하게 연동되어 있다면 더욱 그렇습니다.

그렇다면 당장 업그레이드가 불가능하다면 어떻게 해야 할까요?

공격 표면을 줄이고 모니터링 시스템을 현대화함으로써 시간을 벌 수 있습니다.

모든 코드를 다시 작성하지 않고도 구버전 Solr의 보안을 유지하는 방법

다음은 엔지니어링 팀이 기존 인프라를 버리지 않고 레거시 Solr 클러스터를 보호하기 위해 실제로 사용하는 실용적인 접근 방식입니다.

1. 모든 Solr 엔드포인트 차단

구버전의 Solr은 실수로라도 공개 인터넷에 노출될 경우 위험할 수 있습니다.

다음 항목에 대해서는 인증되지 않은 액세스를 절대 허용하지 마십시오:

/solr/admin
/solr/config
/solr/update
/solr/select (쓰기 가능한 매개변수가 있는 경우)

리버스 프록시, 방화벽 또는 사설 네트워크 규칙을 사용하십시오.

2. 모든 곳에서 TLS 적용

구형 Solr 클러스터는 대개 일반 텍스트로 실행됩니다. 이는 트래픽을 가로채는 공격자들에게는 더할 나위 없는 기회입니다.

3. 기존 인증 플러그인을 모두 교체하십시오

사용 중단된 플러그인은 Solr의 가장 흔한 보안 취약점 중 하나입니다.

4. 인증 정보 및 키 주기적 교체

특히 지난 몇 년간 여러 팀이 해당 클러스터를 관리해 온 경우라면 더욱 그렇습니다.

5. Solr 관련 종속성 패치 적용

Solr 자체를 업그레이드할 수 없더라도 패치를 적용할 수는 있습니다:

시스템 패키지
JVM
컨테이너 기본 이미지
Zookeeper 종속성
OS 수준 라이브러리

6. 런타임 이상 탐지 기능 추가

다음 사항을 감지하는 도구를 사용하십시오:

갑작스러운 아웃바운드 연결
예상치 못한 Solr API 호출
인덱스 조작 패턴
의심스러운 급등 패턴

현대적인 모니터링 도구(Prometheus, Grafana, Datadog, OpenTelemetry 등)는 모두 이를 지원합니다.

7. Canary Core 추가하기

이 작은 요령이 정말 큰 도움이 됩니다.

카나리아 코어는 알려진 콘텐츠를 기반으로 하는 통제된 “조기 경보 시스템” 역할을 합니다. 검색 결과나 지연 시간이 예기치 않게 변동할 경우, 프로덕션 환경에 영향을 미치기 전에 클러스터에 문제가 발생했음을 파악할 수 있습니다.

8. 서두르지 않는 업그레이드 경로 구축하기

내일 당장 Solr 9로 전환할 필요는 없습니다. 대신, 이 과정을 위험이 적은 작은 단계들로 나누어 마이그레이션 계획을 수립하세요.

아직 업그레이드할 수 없을 때 (그리고 그게 괜찮은 이유)

기술 분야에서는 “그냥 업그레이드하라”는 압박이 심하지만, 실제 운영 시스템에서는 항상 그렇게 할 수 있는 것은 아닙니다.

때로는:

스키마가 지나치게 맞춤화되어 있습니다
이 회사는 가동 중지 시간을 감당할 여유가 없다
이 마이그레이션은 너무 많은 변수가 얽혀 있습니다
검색 로직은 앱과 깊이 밀접하게 연결되어 있습니다
이번 분기에는 팀에 여유가 없습니다

그건 당연한 일이에요.

중요한 것은 기존 시스템을 책임감 있게 보호하는 것입니다.

또한 지원이 종료된 구버전에 대한 장기적인 보호가 필요한 경우, TuxCare의 'Apache Solr를 위한 Endless Lifecycle Support' 와 같은 솔루션이 존재하며, 이는 더 안전한 마이그레이션을 계획하는 동안 이러한 미션 크리티컬 시스템을 안전하게 유지하기 위해 특별히 마련된 것입니다.