안녕하세요! 여기어때 검색플랫폼개발팀의 레미입니다.Elasticsearch에서 같은 사각형 영역을 검색할 때, Box 방식과 Polygon 방식의 성능은 어떻게 다를까요? 공간 검색은 위치 기반 서비스를 구현할 때 매우 중요한 기능입니다. 특히, 검색 영역이 사각형인 경우, Box와 Polygon 두 가지 접근법 중 어떤 것이 효율적인지 판단하는 것은 검색 속도와 효율성을 높이는 데 큰 영향을 미칠 수 있습니다.이번 글에서는 두 방식을 비교 분석하고, 그 결과를 여러분과 공유하려 합니다. 🚀1. 테스트 개요📌 목적동일한 검색 영역에 대해 Polygon 방식과 Box 방식의 성능을 비교하여 최적의 검색 방식을 선정하기 위함입니다. 특히, 박스 방식은 좌표 두 개(좌상단, 우하단)를 사용하고, 폴리곤 방식은 사각형의 네 꼭짓점을 모두 명시하기 때문에 이 차이가 성능에 어떤 영향을 미치는지 알아보았습니다.📝 테스트 환경테스트 데이터: 10만 개의 좌표 데이터검색 영역: 동일한 사각형 영역 적용색인 방식: geo_point검색 엔진: Elasticsearch검색 쿼리 방식2개 좌표 검색: GeoBoundingBoxQuery 사용4개 좌표 검색: GeoPolygonQuery 사용📊 측정 항목🕒 Mean_Test_Time(ms): 평균 응답 시간 (낮을수록 우수)⚡ TPS (Transaction Per Second): 초당 처리 건수 (높을수록 우수)📦 Mean_response_length: 평균 응답 데이터 크기이제 본격적으로 두 방식의 성능을 비교해볼까요? 🤔2. 테스트 결과 요약📊 특이사항:두 방식 모두 평균 응답 시간(MTT)과 TPS에서 큰 차이 없이 유사한 성능을 보였습니다.특정 구간에서는 박스 및 폴리곤 방식 모두 다소 변동이 있었으나, 전반적으로 비슷한 성능을 유지했습니다.평균 응답 길이(Mean_response_length)는 두 방식에서 완전히 동일하게 측정되었습니다.📌사실, 테스트 전에는 박스 방식이 더 단순한 구조를 가지므로 성능이 더 좋을 것이라고 예상했지만, 결과는 다소 의외였습니다. 예상 외로 두 방식 모두 비슷한 응답 속도를 보여주었기 때문입니다. 이는 Elasticsearch 내부의 공간 필터링 처리 방식이 매우 최적화되어 있다는 것을 보여주는 사례입니다.3. 분석 결과3.1 📌이론적 성능 예상🟦 박스 방식:단순 사각형 경계 검색 방식으로, 계산량이 적고 더 빠를 것으로 예상했습니다.박스는 좌상단(top_left)과 우하단(bottom_right) 두 개의 좌표만을 사용해 검색 영역을 정의하므로, 불필요한 계산이 적습니다.2. 🔺 폴리곤 방식:비정형 다각형 검색 방식으로, 사각형 영역을 포함한 4개의 꼭짓점 좌표를 사용합니다.따라서, 추가적인 계산 비용이 발생할 것으로 보았습니다.3.2 🔍 실제 테스트 결과 차이 원인 분석하지만 실제 결과는 예상과 다르게 두 방식의 성능 차이가 거의 없었습니다. 🧐 그 이유는 Elasticsearch가 geo_point 필드를 활용해 최적화된 인덱스를 생성하기 때문입니다. 또한, 사각

로그 모니터링 시스템은 서비스 운영을 위해서 반드시 필요한 시스템입니다. 로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용됩니다. 네이버도 Elasticsearch 기반의 로그 모니터링 시스템을 구축했으며, 수천 대의 서버로 수 페타바이트 규모의 로그 데이터를 저장하고 있습니다. 최근 들어 서비스 규모가 확장되고 저장해야 하는 로그 데이터의 규모와 트래픽 양이 급속도로 증가하면서 Elasticsearch 기반의 로그 모니터링 시스템은 비용 문제와 더불어 확장성 문제에 직면하게 됐습니다.네이버는 저비용으로 대용량의 로그 데이터를 수집할 수 있도록 Apache Iceberg(이하 Iceberg)를 도입한 신규 컴포넌트 Alaska를 개발해 네이버의 로그 모니터링 시스템 플랫폼 NELO에 적용했습니다. 이 글에서는 기존 로그 모니터링 시스템의 문제와 Iceberg의 특징을 소개하고, Alaska의 작동 방식과 Alaska를 NELO에 적용한 이후의 변화를 소개합니다.Elasticsearch 기반 기존 로그 모니터링 시스템의 한계Elasticsearch를 기반으로 구축된 기존 로그 모니터링 시스템의 구조를 간략하게 도식화하면 다음 그림과 같습니다.클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후 Elasticsearch에 저장됩니다. Elasticsearch는 SSD 타입의 스토리지로 구성된 Hot 계층(Hot Tier)과 HDD 타입의 스토리지로 구성된 Warm 계층(Warm Tier)으로 구분되어 있습니다. 로그 데이터는 Hot 계층에 3일간 저장된 후 Warm 계층으로 이동되어 최대 90일까지 저장됩니다. 이렇게 Hot 계층과 Warm 계층의 두 단계로 나누어 데이터를 저장하면 검색이 빈번하게 일어나지 않는 데이터를 효율적이면서 저비용으로 저장할 수 있습니다.기존 로그 모니터링 시스템은 수년간 이와 같은 구조로 운영되었습니다. 그동안 데이터가 증가함에 따라 Warm 계층에 저장된 데이터의 크기도 급증했습니다. Elasticsearch는 단일 클러스터로 저장할 수 있는 데이터의 크기에 제한이 있기 때문에 다수의 Elasticsearch 클러스터를 구성해 클러스터 수준에서 확장을 진행했습니다. 그 과정에서 모든 클러스터가 한계 수준까지 도달해 운영 장애를 빈번하게 겪었습니다. 연간 수십억 원의 인프라 사용 비용도 부담이 되었습니다. 두 계층으로 구성된 Elasticsearch 클러스터는 더 이상 로그를 효율적으로 저장할 수 있는 구조가 아니게 되었습니다. 새로운 타입의 데이터 저장 스토리지의 필요성Warm 계층에 저장된 데이터의 크기가 급증하는 이유에는 장기간 로그의 저장에 대한 요구 사항도 있습니다. 기존 로그 모니터링 시스템은 Elasticsearch에 최대 90일까지 로그 데이터를 저장할 수 있게 허용했습니다. 하지만 서비스의 법적 요구 사항 등의 이유로 예외로 1년 이상의 로그 데이터 저장을 허용하고 있었습니다. 기존 로그 모니터링 시스템이 한계에 도달하면서

안녕하세요! 검색플랫폼팀 테디예요. 당근 검색플랫폼팀은 사용자에게 보다 나은 검색 경험을 제공할 수 있도록 튼튼한 플랫폼을 만드는 팀이에요. 검색 서비스와 인프라를 운영 및 관리하면서 검색 트래픽을 안정적으로 소화할 수 있도록 만들죠.이를 위해 팀에서 다양한 노력을 하고 있는데요. 최근에는 검색 형태소 분석 사전 배포 과정을 개선하는 프로젝트를 진행했어요. 그래서 오늘은 프로젝트를 진행하게 된 계기와 과정, 그리고 결과를 간략하게 공유드려 볼게요.📚 형태소 분석을 위한 기본 사전검색에서 형태소 분석 기능은 필수예요. 이 기능은 주로 문서를 검색하거나 색인할 때, 검색어 또는 문서의 검색 대상 필드(제목, 본문 등)의 형태소를 분석하기 위해 사용돼요.저희 팀은 Elasticsearch를 검색 엔진으로 사용하면서 Nori를 기반으로 자체 구축한 Analysis-Karrot 플러그인을 통해 형태소를 분석하고 있어요. 이 플러그인은 내부에 가지고 있는 기본 사전 (또는 시스템 사전)을 기반으로 형태소를 분석해요. 해당 사전은 한국어 단어들의 품사, 형태, 가중치 등 형태소 분석에 사용되는 다양한 정보를 가지고 있어요.내부 사전 데이터 일부형태소를 잘 분석하고 나아가 검색 품질을 향상하기 위해서는 이 기본 사전을 잘 관리하는 것이 매우 중요해요. 왜냐하면 줄임말, 신조어 등이 계속해서 생겨나고, 어떤 단어라도 검색어로 들어올 수 있기 때문이에요. 이러한 변화에 잘 대응하기 위해 기본 사전 내용을 주기적으로 업데이트하며 고도화해야 해요.⚙️ 기본 사전 업데이트 프로세스AS-IS: 기본 사전 업데이트 프로세스현재 기본 사전 내용을 업데이트하는 과정은 아래와 같아요.검색 어드민을 통해서 새로운 사전 데이터를 사전 DB에 추가한다.사전 DB를 읽어서 새로운 사전 데이터 셋을 생성한다.사전 데이터 셋을 주입하여 Analysis-Karrot 플러그인을 생성한다.Analysis-Karrot 플러그인을 Elasticsearch 검색 클러스터에 재배포한다.여기서 문제는 ES 검색 클러스터 배포는 매우 신중해야 하는 무거운 작업이라는 점이에요. 만약 검색 클러스터 배포 과정에서 문제가 발생한다면 검색 기능 자체를 사용하지 못할 수도 있어요. (SPOF) 그래서 설정 변경 또는 버전 업데이트 등과 같이 검색 클러스터 운영에 필수적인 상황을 제외하고는 배포를 최소화하는 것이 운영 측면에서 지향하는 방향이에요. (DB 운영과 비슷하다고 볼 수 있죠.)🤔 검색 클러스터 배포 없이 사전 업데이트 가능할까?팀에서는 검색 클러스터 배포를 하지 않고 기본 사전을 업데이트할 수 있는 방법이 없을까 고민하면서, 기본 사전을 사용하는 플러그인 내부 코드를 분석했어요.Nori를 기반으로 자체 개발한 Analysis-Karrot ES 플러그인은 내부적으로 Lucene의 BinaryDictionary를 사용해요. 이를 통해 플러그인 내부에 들어있는 불변하는 성격의 사전 데이터를 싱글톤 객체를 사용해서 메모리에 로드하고 있어요. 여기서 저희는 Dictionary 객체를 생성할 때 플러그인

LINE Plus의 MPR(Mobile Productive & Research) 팀은 LINE 클라이언트 앱의 빌드 개선과 CI 파이프라인 관리, 자동화 지원 등의 업무를 담당하고 있습니다. 이번 글에서는 저희 팀에서 운영하는 CI/CD에 발생했던 흔하지 않은 이슈와 그 해결 방법을 공유하려고 합니다. 이번 글에서 다룰 이슈는 문제가 발생한 시점부터 다시 정상적으로 CI/CD가 운영되기까지 약 10일 정도의 시간이 소요됐는데요. 추후 유사한 문제가 발생했을 때 어떤 식으로 문제의 원인을 찾고, 분석해서, 해결해 나가야 하는지 그 과정을 참고하고자 작성했습니다. 저희의 문제 해결 과정이 이 글을 읽고 계신 분들께도 도움이 되기를 바라며 시작하겠습니다.현재 MPR 팀에서 운영하고 있는 CI의 전체 구성을 간략하게 소개하겠습니다. 먼저 소스 리포지터리로 Git을 사용하고 있으며, Jenkins와 여러 플러그인을 이용해 CI를 운영하고 있습니다. 빌드 개선 및 오류 검토를 목적으로 Gradle을 활용한 빌드 정보를 Develocity에 수집하고 있으며, Jenkins 빌드 로그를 Logstash를 통해 Elasticsearch로 모아서 집계한 뒤 Kibana 및 Grafana를 사용해 빌드 정보를 시각화하고 있습니다.평소와는 다른 빌드 실패 증상의 발현언제부터인가 빌드 실패 알림이 증가했습니다. CI/CD를 운영하다 보면 예기치 못한 여러 문제가 발생할 수 있으며, 그중 빌드 오류가 발생하는 경우는 다음과 같습니다.• 테스트 관련 오류• 플레이키(flaky) 테스트: 코드는 동일한데 테스트 결과는 다른 경우• 느린 테스트: 테스트 실행하는 데 지나치게 오래 걸리는 경우• 인프라 및 성능 관련 오류• 서버 과부하: 동시에 여러 테스트를 처리하느라 서버나 네트워크에 과부하가 걸리는 경우• 확장성 문제: 개발 팀과 프로젝트의 규모가 커지면서 파이프라인이 증가된 부하를 처리하지 못하지만 구조상 확장하기 어려운 경우• 성능 이상: 서버의 응답이 지연되거나 메모리 누수가 발생하거나 부하 분산이 적절히 처리되지 않은 경우• 통합 및 배포 관련 오류• 도구 간 통합 문제: 내부적으로 인터페이스를 구축해 서로 다른 도구를 통합해서 사용하다가 예상치 못한 도구 간 설정 호환 문제가 발생하는 경우일반적인 경우 빌드 실패의 주요 원인은 유닛 테스트 증가에 따른 빌드 및 테스트 수행 시간의 증가입니다. Jenkins에 빌드 타임아웃 시간을 설정해 놓으면 빌드 및 테스트하는 데 이보다 시간이 오래 걸릴 경우 강제로 중단되는데요. 유닛 테스트가 늘어나 테스트 수행 시간이 증가하거나 일시적으로 자원이 부족해 테스트 수행에 실패하면서 설정해 놓은 빌드 타임아웃 시간을 초과하면 빌드에 실패합니다. 보통 이런 경우는 빌드에 사용할 리소스가 일시적으로 부족하거나 네트워크에 간헐적으로 문제가 생겨 발생하기 때문에 빌드를 다시 실행하면 대부분 재현되지 않습니다.저희는 이번 경우 역시 처음에는 이처럼 시간이 지나면 자연스럽게 해결될 일시적인 증상으로 간주하고 원인을 파악하기 시작했습니