신규 사용자에게 이는 고품질 벡터 검색을 실행할 수 있는 가장 빠른 방법입니다. 이미 Elasticsearch를 사용 중인 경우, 별도의 시스템을 도입하지 않아도 새로운 기능을 통해 데이터가 이미 존재하는 플랫폼에서 바로 벡터 검색을 이용할 수 있습니다. Elasticsearch 벡터 데이터베이스는 대규모 언어 모델(LLM)의 기반 구축부터 AI 에이전트에 검색 및 메모리 기능 제공, 수천억 개의 벡터 처리에 이르기까지 다양한 시나리오를 지원합니다. 새 프로젝트를 생성하고 몇 분 안에 시작해 보세요.

하나의 엔진, 모든 벡터 사용 사례

Elasticsearch 벡터 데이터베이스는 벡터를 사용하여 애플리케이션을 구축하는 모든 사용자를 위해 구축되었습니다.

• RAG: 밀집 및 희소 벡터 검색으로 LLM에 적합한 컨텍스트를 검색하거나, 벡터 검색과 어휘 검색을 모두 결합한 하이브리드 검색을 사용하십시오. 생성 품질은 검색 품질에 따라 향상됩니다.

• AI 에이전트: 다단계 에이전트 루프에서 요구하는 짧은 지연 시간으로 문서 및 대화 메모리에 대한 빠르고 필터링된 검색 기능을 에이전트에 제공하세요.

• 시맨틱 검색: 파이프라인 코드 없이 단 하나의 필드 유형으로 키워드가 아닌 의미를 기반으로 매칭합니다.

• 추천 및 유사성: 제품, 이미지 또는 보유한 모든 콘텐츠 전반에서 대규모로 최근접 이웃을 찾습니다.

벡터 워크로드에 필요한 모든 것을 기본 최적화 상태로 제공

벡터 기반 애플리케이션을 구축하려면 여러 개의 개별 요소를 연결해야 합니다. 즉, 임베딩 모델을 설정하고 호스팅하며, 이를 통해 문서를 색인하고, 벡터를 효율적으로 저장하고, 각 쿼리에 임베딩 모델을 적용하고, 벡터 저장소와 일치시키고, 마지막으로 일치 항목에 해당하는 문서를 검색해야 합니다. Elasticsearch 벡터 데이터베이스는 추가 구성이나 설정 없이 이 모든 작업을 처리합니다.

vectordb_document 인덱스 모드를 사용한 벡터 색인

vectordb_document 인덱스 모드는 벡터 우선 워크로드를 위해 특별히 설계된 새로운 인덱스 구성으로, 기본적으로 활성화되어 있으므로 전문가가 선택할 설정을 사용할 수 있습니다. 활성화되는 기능은 다음과 같습니다.

• 기본적으로 bfloat16 적용: 벡터는 재현율에 거의 영향을 주지 않으면서 float32의 절반 크기로 저장되므로, 양자화를 적용하기 전부터 디스크 사용 공간을 대략 절반으로 줄여 줍니다.

• 소스 벡터 제외: Elasticsearch에서는 임베딩이 이미 검색에 사용되는 인덱스 구조에 존재하므로, _source에 두 번째 원시 사본을 보관하는 것은 저장 공간을 늘리고 결과를 가져오는 속도를 늦출 뿐입니다. 중복을 제외하여 응답이 더 빠르게 반환되며 저장하는 양도 줄어듭니다.

• 적절한 파일을 캐시에 미리 로드: 벡터 쿼리가 가장 먼저 사용하는 데이터 구조를 미리 메모리에 워밍업하므로 첫 번째 쿼리부터 천 번째 쿼리까지도 번개처럼 빠르게 실행됩니다.

• 병렬 병합: 병합을 통해 세그먼트가 더 체계적인 벡터 구조로 통합되므로 재현율과 지연 시간이 모두 개선되며, 이러한 병합을 멀티스레드로 실행하면 더 빠르게 도달할 수 있습니다.

벡터 저장 공간, 압축 및 자동 튜닝

• 벡터가 자동으로 압축됩니다. 더 나은 이진 양자화(BBQ)는 재현율을 유지하면서 벡터 메모리 공간을 최대 32배까지 줄이고, DiskBBQ는 대규모 워크로드의 메모리 요구 사항을 더욱 줄여줍니다. 

• 자동 보정을 선택하면 각 세그먼트의 양자화가 데이터에 맞게 조정되고, 데이터가 변화함에 따라 병합할 때마다 다시 조정됩니다. 18개 데이터 세트에서 테스트한 결과, 초당 쿼리 수(QPS)는 평균 16.7% 향상되었으며 대부분의 데이터 세트에서 재현율도 개선되었습니다.

관리형 GPU 추론 기반 임베딩

• 기본 Jina AI 임베딩 및 순위 재지정 모델로 임베딩을 생성하거나, 모델 서버를 운영할 필요 없이 Elastic Inference Service(EIS)를 통해 관리형 GPU에서 타사 모델을 가져오세요. 자체 모델을 선호하신다면 자체 호스팅도 가능합니다.

• semantic_text 필드 유형은 청킹 및 임베딩과 함께 쿼리를 자동으로 처리하므로, 시장에서 시맨틱 검색으로 가는 가장 간단한 경로입니다. 

하이브리드 검색 및 필터링된 벡터 검색

• 하이브리드 검색이 기본 제공되어 단일 쿼리에서 전체 텍스트 검색과 벡터 검색을 결합할 수 있습니다. 상호 순위 결합(RRF) 또는 원하는 다른 결합 메커니즘을 사용하여 결과를 혼합할 수 있습니다. 벡터 검색은 일반적으로 하이브리드 검색에서 제대로 구성하기 가장 까다로운 부분입니다. Elasticsearch 벡터 데이터베이스를 사용하면 이 문제를 쉽게 해결할 수 있으며 전체 하이브리드 스택이 더욱 향상됩니다. 

• 필터링된 벡터 검색을 사용하면 재현율을 저하시키는 사후 처리가 아니라 벡터 검색 자체의 일부로 메타데이터 필터를 적용할 수 있습니다.

첫날부터 엔터프라이즈

또한 역할 기반 액세스 제어(RBAC), 감사 로깅, 순수 벡터 데이터베이스에는 일반적으로 부족한 규정 준수 인증도 이용할 수 있습니다.

확장 시에도 경제적이고 예측 가능

Elasticsearch 벡터 데이터베이스는 규모가 확장되어도 경제적인 비용을 유지하도록 구축되었습니다. 저장 공간을 선형적으로 유지하고 메모리 사용량을 낮게 유지하는 BBQ 및 DiskBBQ 압축 기술 덕분에 수천억 개의 벡터로 확장하더라도 비용이 급증하지 않습니다. 또한 실제로 지불하는 비용은 여러분이 이미 알고 있는 수치, 즉 저장하는 데이터 양, 인덱싱하는 데이터 양, 필요한 검색 용량을 기반으로 산정됩니다. 문서 수, 벡터 차원 및 쿼리 부하를 예측하면 프로젝트를 생성하기 전에 지불할 비용을 산출할 수 있습니다. 또한 월말에 청구서의 항목을 한 줄 한 줄 명확하게 파악할 수 있습니다. 불투명한 컴퓨팅 단위가 없으며 백그라운드 작업에 예상치 못한 요금도 청구되지 않습니다.

Elasticsearch 벡터 데이터베이스 시작하기

서버리스 벡터 데이터베이스 프로젝트 만들기

Elastic Cloud에서 새로운 서버리스 벡터 데이터베이스 프로젝트를 생성하세요. 데이터를 엔드포인트로 지정하면 인덱싱 준비가 완료됩니다.

semantic_text를 사용한 인덱스 생성

벡터 인덱스 모드는 벡터 구성을 처리합니다. semantic_text를 사용하면 관리형 GPU 추론에서 임베딩 및 청킹 설정과 인덱스 설정이 관리되므로 구축할 임베딩 파이프라인이 필요하지 않습니다.

문서 수집

텍스트를 색인하면 임베딩이 자동으로 생성됩니다.

시맨틱 검색 쿼리 실행

방금 생성한 동일한 시맨틱 필드에 대해 쿼리 작업을 수행합니다.

그리고 결과가 반환됩니다.

시맨틱 검색은 시작에 불과합니다. 완전한 텍스트 기반 쿼리를 실행하거나 두 가지를 결합하여 하이브리드 쿼리로 만들 수 있습니다. 완전한 제어를 위해 자체 벡터 쿼리를 작성할 수도 있습니다. 전체 지침은 문서의 시맨틱 검색 빠른 시작을 참조하세요.

Elasticsearch 벡터 검색의 다음 단계

이미 다음 개선 사항을 진행 중입니다.

• 향상된 멀티테넌트 처리: 테넌트별로 데이터를 분리하여 유지해야 하는 경우, 더 적은 코드로 더 빠르게 처리할 수 있는 방법을 제공해 드립니다.

• 자동 인덱스 최적화: '새 인덱스'부터 '완전히 최적화된 인덱스'까지, 가능한 한 적은 조정으로 가능합니다.

• 지속적인 인프라 개선: 항상 최고의 처리량과 가장 빠른 응답을 얻을 수 있도록 벡터 데이터베이스의 설정 및 인프라를 지속적으로 튜닝합니다.

Elastic Cloud Serverless에서 Elasticsearch 벡터 데이터베이스 써보기

프로덕션급 기본 설정이 튜닝을 대신 처리하여, 빈 프로젝트에서 단 몇 분 만에 하이브리드 필터링 벡터 쿼리를 구축해 보세요. 인프라가 아닌 신속하고 확장 가능한 AI 앱을 구축하세요.

Elastic Cloud Serverless에서 시작하거나 전체 설명서 및 API 참조를 살펴보십시오.

Elastic Cloud Serverless는 이미 인프라 관리 및 버전 업그레이드의 번거로움을 없애고 있습니다. CPS는 여기서 한 걸음 더 나아갑니다. 복잡한 네트워크 피어링과 수동 인증서 관리 방식을 간편한 연결 모델로 대체했습니다. 이제 Elastic Cloud Serverless 프로젝트를 데이터를 위한 단순한 네임스페이스처럼 취급하면 됩니다. 엄격한 데이터 레지던시 법률을 준수해야 하거나 테넌트 데이터를 격리해야 하거나 로그 중복으로 인한 막대한 네트워크 전송 비용을 피해야 하는 경우, CPS를 사용하면 한 번의 쿼리로 데이터가 있는 위치를 정확하게 검색할 수 있습니다.

이 글에서는 CPS의 작동 방식, 프로젝트 태그를 사용하여 검색을 제어하는 방법, 이 새로운 모델이 기존의 클러스터 간 검색(CCS)과 어떻게 다른지 자세히 살펴보겠습니다.

프로젝트 간 검색을 위한 프로젝트 연결 방법

프로젝트 간 검색을 시작하려면 Elastic Cloud 콘솔 또는 API에서 프로젝트를 연결하세요. 연결 방식은 간단하며 단방향으로 이루어집니다. 원본 프로젝트를 선택한 다음, 그 프로젝트가 검색해야 할 프로젝트를 연결합니다. 이러한 연결은 리전, 클라우드 서비스 제공자, 프로젝트 유형에 걸쳐 사용할 수 있으므로 통합된 검색 환경을 유지하면서도, 데이터가 원래 위치에 남아 있을 수 있습니다.

연결이 생성되면 보통 1분 이내에 반영됩니다. 이미 Kibana가 열려 있다면 새로 고침하여 새로운 프로젝트 간 검색 기능을 확인하세요.

프로젝트 간 검색이 연결된 모든 프로젝트를 기본적으로 쿼리하는 방법

프로젝트 연결되면, 프로젝트 간 검색은 분리된 프로젝트 하나의 논리적인 검색 화면으로 전환합니다. 로그가 여러 프로젝트에 걸쳐 분산되어 있더라도, FROM logs* 같은 쿼리는 원본 프로젝트 및 일치하는 데이터가 연결된 모든 프로젝트를 검색합니다. 각 원격 대상을 미리 지정할 필요가 없습니다.

이는 기존의 클러스터 간 검색에 비해 크게 개선된 점입니다. CCS에서 로컬 데이터와 원격 데이터에 모두 접근하려면 보통 FROM logs*,*:logs* 같은 방식으로 작성해야 합니다. 사용자에게는 쿼리의 복잡성이 줄어든다는 것을 의미합니다. 팀에게는 분산된 데이터 전체를 아우르는 진정한 단일 제어 화면에 한 걸음 더 가까워짐을 의미합니다.

이에 대한 자세한 내용은 CPS 검색 모델 문서를 참조하세요.

이를 어떻게 구축했는지 기술적인 세부 사항을 알아보고 싶으시다면, Elasticsearch Serverless의 프로젝트 간 검색(CPS) 작동 방식을 참조하세요.

프로젝트 라우팅을 통한 검색 제어

기본적으로 연결된 모든 프로젝트를 검색하는 방식은 많은 워크플로우에서 편리하고 유용하지만, 모든 검색을 모든 위치에서 수행해야 하는 것은 아닙니다. 프로젝트 간 검색은 쿼리를 특정 프로젝트 서브셋으로 제한할 수 있는 방법인 프로젝트 라우팅을 도입했습니다.

이는 Elastic Cloud에 정의된 프로젝트 태그를 통해 작동합니다. 모든 프로젝트에는 별칭, 클라우드 서비스 제공자, 리전과 같은 기본 제공 속성이 포함되어 있습니다. 또한 조직의 자산 관리 방식에 맞춰 environment:prod, environment:test나 비즈니스 부서, 또는 고객 이름과 같이 고유 태그를 직접 추가할 수도 있습니다. 그러면 Elasticsearch는 해당 메타데이터를 사용하여 어떤 연결된 프로젝트를 검색에 참여시킬지 결정할 수 있습니다.

프로젝트 간 검색을 지원하는 모든 Elasticsearch 엔드포인트는 project_routing 매개변수를 허용합니다. 기술 미리보기에서 라우팅은 프로젝트 별명 사용으로 제한됩니다. 예를 들어, project_routing을 _alias:my-linked-project(으)로 설정하면 쿼리가 해당 연결된 프로젝트로만 전송되며, _alias:_origin(으)로 설정하면 쿼리가 원본 프로젝트에만 머무르게 됩니다. 시간이 흐름에 따라 이 모델은 훨씬 더 풍부한 라우팅의 가능성을 열어 줄 것입니다. 이를 통해 검색 범위가 인프라의 물리적 배치 대신 조직의 논리적 구조를 따르도록 할 수 있습니다.

어떻게 작동하는지 다양한 예시와 자세한 내용이 궁금하시다면 프로젝트 라우팅 문서를 참조하세요.

Kibana Space 수준의 기본 프로젝트 라우팅

검색 라우팅에 더 정밀한 제어가 필요한 대표적인 예로, 연결된 모든 프로젝트를 검색할 경우 Kibana 규칙에서 오탐이 대량으로 발생하거나 기존 대시보드에 혼란스러운 결과가 표시될 수 있습니다. 이를 해결하기 위해 Kibana에서 Space 수준의 기본 프로젝트 범위를 설정할 수 있습니다. 이는 해당 특정 Space를 위한 안전한 사전 설정 역할을 하며, 이에 따라 모든 대시보드, Discover 세션, 알림 규칙이 이 설정을 자동으로 따르게 됩니다. 다만, 분석가는 조사 과정에서 더 넓은 범위의 데이터 확인이 필요한 경우, 범위를 수동으로 재정의할 수 있습니다.

이는 MSP, MSSP, 최고 전문가 조직처럼 중앙 프로젝트를 공유하여 사용하는 팀에게 특히 유용한 기능입니다. 팀별로 전용 Kibana 스페이스를 할당하고 특정 고객 프로젝트만 쿼리하도록 제한함으로써, 테넌트별 맞춤형 경험을 보장할 수 있습니다. 다만, 분석가는 조사 과정에서 더 넓은 범위의 데이터 확인이 필요한 경우, 범위를 수동으로 재정의할 수 있습니다.

클라우드 UI에서 프로젝트를 실제로 연결하기 전이나 후에 이 Space 기본값을 구성할 수 있습니다. 하지만 프로젝트 간 검색(CPS)은 링크가 연결되는 즉시 '전체 검색' 동작이 활성화되므로, Kibana 기본값을 먼저 설정해 두어야 기존 탐지 규칙이 갑자기 방대한 글로벌 데이터셋을 대상으로 실행되어 팀에 과부하가 걸리는 상황을 방지할 수 있습니다.

검색에서 태그 사용

프로젝트 라우팅에 태그를 사용하는 것 외에도 ES|QL 및 _search 쿼리에도 태그를 사용할 수 있습니다. 이는 결과 집합에서 각 레코드나 행의 출처를 식별하거나 해당 태그를 기준으로 정렬, 필터링 또는 집계하는 데 유용할 수 있습니다.

예를 들어, ES|QL 응답의 각 행이 어떤 프로젝트에서 가져온 것인지 확인하고 싶다면 ES|QL 쿼리에 _project._alias 태그를 추가하면 됩니다.

또한 이를 통해 KEEP 절을 포함한 쿼리의 다른 부분에서 _project._alias를 사용할 수 있어 최종 결과에서 이를 확인할 수 있습니다.

쿼리에서 태그를 사용하는 더 많은 예시는 Search API와 ES|QL 모두에서 태그를 사용하는 방법을 설명하는 이 문서를 참조하세요.

Search와 ES|QL 쿼리에 태그를 어떻게 추가했는지 기술적인 세부 사항이 궁금하시다면 프로젝트 태그 및 라우팅을 이용한 Elasticsearch Serverless의 더 빠른 프로젝트 간 검색을 참조하세요.

프로젝트 간 검색 시 원본 프로젝트와 연결된 프로젝트를 동일하게 처리하는 방법

기존에 클러스터 간 검색(CCS)을 사용해 보셨다면, 로컬 클러스터와 원격 클러스터가 몇 가지 측면에서 서로 다르게 처리된다는 점을 알고 계실 것입니다.

• 로컬 클러스터의 오류는 원격 클러스터에서 발생하는 오류와는 다르게 처리됩니다. 특히, CCS는 원격 클러스터의 오류가 어떻게 작동할지 제어하기 위해 skip_unavailable 설정을 사용하지만, 이 설정은 로컬 클러스터에는 존재하지 않습니다.

• 로컬 클러스터에는 '클러스터 별칭'이 없기 때문에, 인덱스 표현식 *:logs*은(는) 모든 원격 프로젝트를 검색하지만, 로컬 클러스터는 건너뛸 수 있습니다. 둘 다 검색하려면 인덱스 표현식 logs*,*:logs*을(를) 사용해야 합니다.

하지만 CPS에서는 이 두 가지 동작을 모두 변경하여, 원본 프로젝트와 연결된 프로젝트가 훨씬 더 동등한 위치에서 처리되도록 했습니다.

먼저, skip_unavailable 설정은 Elastic Cloud Serverless에서 사용되지 않습니다. 대신, _search나 _async_search에서는 allow_partial_search_results 매개변수를, ES|QL에서는 allow_partial_results 매개변수를 사용하여 검색 시 부분 결과를 허용할지 여부를 제어합니다.

둘째, Elastic Cloud Serverless에서는 원본 프로젝트도 프로젝트 별칭이 있습니다. 별칭은 모든 프로젝트 태그와 마찬가지로 Elastic Cloud에서 정의됩니다. 따라서 CPS에서는 아래의 모든 쿼리가 동일하게 처리되며, 'logs' 인덱스를 가진 모든 프로젝트를 대상으로 합니다.

주의: 누락된 인덱스에 대한 오류 처리가 작동하는 방식과 관련하여, 정규화된 인덱스 표현식*:logs와(과) 비정규화된 표현식 logs 사이에는 중요한 차이점이 있습니다. 자세한 내용은 공개 문서의 비정규화 및 정규화된 검색 표현식을 참조하세요.

프로젝트 간 검색을 위한 액세스 제어 및 보안 모델

Elastic은 프로젝트 간 검색의 핵심 원칙을 가능하게 하는 새로운 클라우드 기반 보안 모델인 보편적 신원 및 액세스 관리(UIAM)를 구축했습니다. 핵심은 액세스할 수 있는 프로젝트와 데이터는 접근하는 위치에 영향을 받지 않는다는 것입니다.

기본 통합 가시성 프로젝트에서 검색을 시작하든, 혹은 임시 분석 프로젝트에서 시작하든 상관없이 액세스 권한이 중앙 위치에서 정의되었기 때문에 연결된 데이터에 대한 액세스 권한은 일관되게 유지됩니다. 클라우드 기반 인증 및 권한 부여 모델은 클라우드 UIAM 서비스를 사용하여 원본 프로젝트와 관계없이 액세스 권한이 동일하게 유지되도록 보장합니다.

프로젝트 간 검색 사용해 보기

궁극적으로, Elastic Cloud Serverless와 CPS를 함께 사용하면 운영상의 마찰을 줄일 수 있으며, 물리적 또는 운영상의 고려 사항이 아닌 논리적인 고려 사항을 바탕으로 데이터를 구성할 수 있는 추가적인 선택지를 얻게 됩니다. 프로젝트 간 검색을 통해 사용자는 데이터의 논리적 구성에만 온전히 집중할 수 있으며, 과거의 물리적 복잡성에서 벗어나 통합된 검색 환경을 경험할 수 있습니다.

오늘날에는 그 이야기가 훨씬 더 간단해졌습니다. Elastic Cloud API 키를 사용하여 Elastic Cloud Serverless에서 Elasticsearch 및 Kibana API에 대해 직접 인증할 수 있습니다. 이제 단일 자격 증명을 사용해 조직의 리소스를 관리하고, 이에 덧붙여 Elasticsearch 쿼리 언어(ES|QL) 쿼리, 데이터 수집 및 알림과 같은 데이터 작업을 실행할 수 있습니다.

이를 구축한 이유, 이를 가능하게 하기 위해 전 세계적으로 분산된 ID 계층을 설계한 방법, 프로젝트 간 검색의 토대를 마련한 방법을 살펴보세요.

비밀 관리 부담

데이터 플랫폼을 중심으로 안정적인 CI/CD 파이프라인, GitOps 워크플로우 또는 테라폼 자동화를 구축하는 데에는 숨겨진 비용, 즉 비밀스러운 확산이 따릅니다.

이전 모델에서 개발자들은 단절된 인증 방식에 직면했습니다.

• 컨트롤 플레인(Elastic Cloud API 키): Elastic Cloud API를 통해 프로젝트를 생성하고, 사용자를 초대하고, 청구를 관리하는 데 사용되는 조직 범위의 키입니다.

• 데이터 플레인(Elasticsearch API 키): 특정 서버리스 프로젝트 내부에서 생성된 프로젝트 범위 키로 Elasticsearch 및 Kibana API와 상호 작용합니다.

즉, 배포 스크립트는 Elastic Cloud에 인증하고 서버리스 프로젝트를 프로비저닝하며, 해당 프로젝트에서 새로 생성된 Elasticsearch API 키를 추출한 뒤 그 두 번째 키를 하위 애플리케이션이나 자동화 도구에 주입해야 했습니다. 이로 인해 복잡한 파이프라인, 조각화된 감사 로그, 자격 증명 유출 위험이 증가했습니다.

Elastic Cloud Serverless의 통합 인증

이번 릴리스에서는 서버리스 프로젝트의 분할이 사라졌습니다. 이제 클라우드, Elasticsearch 및 Kibana API에 대해 명시적으로 권한이 부여된 Elastic Cloud API 키를 생성할 수 있습니다.

• 이전: Elastic Cloud API 키는 컨트롤 플레인 토큰으로만 사용되었습니다. 프로젝트를 생성하고, 청구를 관리하며, 사용자를 초대할 수 있었지만 한계가 있었습니다. 해당 프로젝트 내에서 Elasticsearch나 Kibana API를 호출하는 데는 사용할 수 없었습니다. 데이터 작업을 위해서는 항상 프로젝트별로 구분된 두 번째 키가 필요했습니다.

• 현재: Elastic Cloud API 키를 생성할 때 클라우드, Elasticsearch 및 Kibana API 액세스를 선택하면 Serverless에 대한 엄격한 경계가 제거됩니다. 해당 API 키는 진정한 통합 자격 증명이 됩니다. 해당 솔루션은 조직의 인프라를 관리하는 기능을 유지하면서, 동시에 모든 권한 있는 서버리스 프로젝트에서 데이터를 쿼리, 인제스트 및 분석할 수 있는 기본 액세스 권한을 확보합니다.

Elastic Cloud API 키 하나로 이를 통합함으로써 범위를 지정하고, 감사하고, 순환하고, 하나의 단위로 취소할 수 있는 단일 ID를 얻게 됩니다. 모든 API 호출은 새 프로젝트를 프로비저닝하든 ES|QL 쿼리를 실행하든 감사 로그에서 동일한 자격 증명으로 표시되므로, 사고 조사 또는 규정 준수 검토 중에 단일 추적을 따를 수 있습니다. 자격 증명 순환이 더 이상 컨트롤 플레인 및 데이터 플레인 비밀 정보를 각각 따로 업데이트하는 방식이 아니라, 단일 단계 작업으로 처리됩니다. 또한 역할 할당은 프로젝트별로 이루어지기 때문에, 하나의 키로 여러 프로젝트에 걸쳐 통합 가시성 프로젝트에서 수집을 관리하고 보안 프로젝트에서 쿼리를 실행할 수 있으며, 각각에 대해 별도의 자격 증명을 처리하지 않아도 됩니다.

중요한 점은, '통합' 이 '전능함'을 의미하지는 않는다는 것입니다. role_assignments 페이로드를 사용하면 통합 키의 범위를 단일 프로젝트와 특정 역할(예: 읽기 전용)로 엄격하게 제한할 수 있어, 자격 증명이 노출되더라도 영향 범위가 완전히 제한되도록 보장합니다. 개발자가 퇴사하거나 애플리케이션이 폐기되는 경우, Elastic Cloud 콘솔에서 단일 키를 취소하여 컨트롤 플레인 및 연결된 모든 Elasticsearch 프로젝트 전반에 걸쳐 액세스를 즉시 종료할 수 있습니다.

(참고: Elastic Cloud Hosted/관리형 배포의 경우 클라우드 API 키는 여전히 컨트롤 플레인만 관리할 수 있습니다. 호스팅 스택 API에 대한 지원 확장은 향후 릴리스에서 제공될 예정입니다.)

워크플로우 자동화

시작 방법은 간단합니다. 이 모든 설정은 Elastic Cloud 콘솔을 통해 하거나 Elastic Cloud API를 사용해 자동화할 수 있습니다.

UI 프로세스는 동일하게 유지되지만, 이제 프로젝트 역할 할당에서 클라우드, Elasticsearch 및 Kibana API 액세스 권한을 선택할 수 있습니다.

다음은 Elastic Cloud API를 사용하여 프로그래밍 방식으로 통합 키를 생성하는 방법입니다. application_roles 배열에 주목하세요. 이 배열이 바로 키에 Elasticsearch 데이터 플레인에 대한 네이티브 액세스 권한을 부여하는 부분입니다.

생성된 후에는 이 키를 Authorization: ApiKey 헤더에 포함하여 api.elastic-cloud.com과 특정 서버리스 Elasticsearch 엔드포인트에 전달합니다.

작동 원리: 분산 ID 계층 구축

클라우드 API 키를 컨트롤 플레인과 데이터 플레인 모두에서 작동하도록 만드는 것은 단순히 토큰을 전달하는 것만큼 간단하지 않습니다. 이를 위해서는 근본적인 분산 시스템 문제를 해결해야 합니다.

과거에는 클라우드 API 키가 중앙 집중식 글로벌 보안 클러스터에 저장되었습니다. 컨트롤 플레인 작업에서는 더 높은 대기 시간이 허용되므로 잘 작동합니다. 하지만 Elasticsearch 데이터 요청은 지연 시간이 매우 짧아야 합니다. 모든 검색 쿼리나 인제스트 요청을 검증하기 위해 전 세계를 중앙 제어기로 왕복하는 비용을 감당할 수 없습니다.

이 문제를 해결하기 위해 당사는 전 세계적으로 분산된 데이터 저장소를 기반으로 하는 새로운 인증 아키텍처를 도입했습니다. 다음 시퀀스 다이어그램은 클라이언트가 Elastic Cloud API 키를 사용해 Elasticsearch 쿼리를 전송하는 것을 보여주며, 글로벌 컨트롤 플레인으로의 왕복 없이 전적으로 로컬 영역 내에서 인증이 어떻게 이루어지는지 설명합니다. Elasticsearch는 전 세계적으로 분산된 데이터베이스의 로컬 복제본에 대해 키를 검증하고 역할 할당을 확인하는 지역 IAM 서비스에 인증을 위임합니다. 인증이 완료되면 Elasticsearch는 쿼리를 실행하고 결과를 클라이언트에 반환합니다.

전 세계적으로 분산된 지속성

이제 Elastic Cloud API 키와 관련 역할 정의는 중앙 집중식 보안 클러스터에만 의존하는 대신, 전 세계적으로 분산되어 가용성이 높은 데이터베이스에 저장됩니다. 이 데이터베이스는 글로벌 컨트롤 플레인과 서버리스 프로젝트가 실제로 실행되는 지역 데이터 플레인 간에 아이덴티티 및 액세스 관리(IAM) 데이터를 동기화합니다.

지역 IAM을 통한 로컬 유효성 검사

클라이언트가 Elastic Cloud API 키를 사용하여 Elasticsearch에 요청을 보내면 해당 요청은 글로벌 제어 플레인으로 되돌아가지 않습니다. 대신 새로운 지역 IAM 서비스로 라우팅됩니다. 로컬 데이터베이스 복제본에 대해 키를 검증하여 지연 시간이 거의 없는 상태에서 인증이 이루어지고 글로벌 컨트롤 플레인 중단으로부터 완전히 격리되도록 합니다.

동적 역할 매핑

인증은 절반의 성공에 불과합니다. 시스템은 요청을 승인하는 절차도 수행해야 합니다. 지역 IAM 서비스는 클라우드 수준 역할 할당(예: application_roles)을 기본 Elasticsearch 권한으로 즉시 변환합니다. 그 후 Elasticsearch는 로컬 .security 인덱스 없이도 로컬에서 요청을 승인하고 실행할 수 있습니다.

프로젝트 간 검색의 기반

이 분산형 아이덴티티 아키텍처는 Elastic 플랫폼의 미래를 위한 기반이 되는 핵심 구성 요소입니다.

신원과 접근 권한이 통합되어 전 세계적으로 동기화되므로, 서로 다른 프로젝트 간에 안전하게 신원을 전달할 수 있는 프레임워크를 갖추게 되었습니다. 이를 통해 향후 Serverless 환경에서 구현될 프로젝트 간 검색(CPS) 기능을 사용할 수 있게 됩니다.

CPS를 사용하면 보안 및 통합 가시성 워크로드를 결합하는 것처럼 여러 원격 서버리스 프로젝트에 걸쳐 있는 데이터를 단일 데이터 세트처럼 쉽게 쿼리할 수 있습니다. 통합된 API 키를 사용함으로써 시스템은 복잡한 신뢰 관계, 인증서 또는 중복 자격 증명을 각 대상 프로젝트에 구성할 필요 없이 모든 프로젝트에 걸쳐 사용자의 권한을 자동으로 평가할 수 있습니다.

자세히 알아보기

스택을 간소화할 준비가 되셨나요?

• Elastic Cloud API 키 문서를 읽고 스택 접근 권한을 할당하는 방법을 알아보세요.

• 키 생성을 자동화하려면 API 키 생성(Elastic Cloud API) 참고 자료를 확인하세요.

• Elastic 플랫폼 전반에서 키 유형을 완전히 비교하려면 Elastic API 키를 확인하세요.

지금 바로 Elastic Cloud에서 빌드를 시작하거나 계속하세요.

안내 및 면책 조항

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

파티가 점점 붐비고 있습니다

여러분이 피자 파티를 주최하는 중입니다. 몇 명의 친구들이 파티 장소의 각기 다른 장소에서 서빙을 돕고 있습니다. 각 친구에게 피자를 한 조각씩 건네주면, 친구들은 도착하는 배고픈 손님들에게 피자 조각을 나눠주기 시작합니다.

처음에는 모든 것이 순조롭게 진행됩니다. 손님 몇 명이 조금씩 들어오고, 친구들이 피자 조각을 나눠 주니, 모두가 만족합니다. 하지만 곧 사워도우 피자에 대한 소문이 퍼지기 시작합니다. 초인종이 계속 울립니다. 손님들이 몰려듭니다. 곧 모두가 먹고 싶어 하는 페퍼로니 피자를 들고 있는 친구 주위로 사람들이 모여들기 시작합니다.

페퍼로니 피자를 든 친구는 어쩔 줄을 모릅니다. 손님들이 기다리고 있으며, 점점 불만이 쌓이고 있고, 긴 대기 줄이 형성되었습니다. 한편, 마르게리타 피자를 든 친구는 한 조각 달라고 하는 사람이 거의 없이 가만히 서 있습니다.

이제 어떻게 할까요?

여러분은 페퍼로니 피자 몇 개를 더 주문하여 다른 친구들에게 건넵니다. 이제 한 명이 아닌 세 명의 친구가 페퍼로니 피자를 들고 있습니다. 인파가 분산되어 갑자기 3배나 많은 손님을 한꺼번에 대접할 수 있습니다.

파티를 더 주최할수록 몇 가지 사실이 분명해집니다.

• 모든 피자가 똑같이 인기 있는 것은 아닙니다. 어떤 것은 수요가 많고, 다른 것은 수요가 적습니다. 인기 없는 피자는 추가 '사본'이 없어도 됩니다. 대기열이 있는 것만 추가하면 됩니다.

• 대기열이 너무 길어지기 전에 피자를 더 주문하세요. 친구가 허둥지둥거리고 손님들이 화를 내며 떠나기 시작할 때까지 기다린다면, 너무 오래 기다린 것입니다. 인파가 몰리는 게 보이면 피자를 한 판 더 주문하는 것이 좋습니다.

• 피자를 너무 빨리 버리지 마세요. 페퍼로니 피자 주변에 5분 동안 인파가 줄었다고 해서 혼잡한 시간이 끝난 것은 아닙니다. 어쩌면 사람들은 음료를 다시 채우고 있거나 서로 대화하고 있을지도 모릅니다(요즘도 그러나요?). 추가 피자를 유지해 주세요. 잠잠한 상태가 한동안 계속된다면, 그땐 피자를 치워도 됩니다.

• 도와주는 친구 수만큼만 피자를 나눠줄 수 있습니다. 도와주는 친구가 네 명이면 피자를 열 판으로 늘려도 결과는 달라지지 않습니다. 한 번에 네 조각만 제공할 수 있습니다. 피자의 수를 도와주는 인원에 맞춰야 합니다.

• 친구가 떠나면 피자를 가져오세요. 친구 중 한 명이 떠나야 한다면 즉시 그들의 피자를 가져오세요. 피자를 방치하면 안 됩니다. 다른 사람에게 건네주거나 치워두세요.

피자부터 복제품까지

이것을 다시 Elasticsearch에 매핑해 볼까요.

이 비유에서 피자는 복제본(인덱스 샤드 복사본), 서빙을 돕는 친구들은 검색 노드, 배고픈 손님은 검색 쿼리, 주변에 인파가 모인 인기 있는 피자는 검색 부하가 높은 핫 인덱스입니다.

특정 인덱스에서 검색 트래픽이 증가하면 추가 복제본을 생성하여 검색 노드 전체에 배포합니다. 모든 복제본은 해당 인덱스에 어떤 쿼리든 서빙할 수 있습니다. 마치 페퍼로니 피자를 든 친구가 페퍼로니 피자 조각을 나눠줄 수 있는 것처럼 말이죠. 복제본 수가 많을수록 처리량이 높아집니다. 복제본이 세 개면 복제본 한 개보다 초당 3배 더 많은 쿼리를 처리할 수 있습니다.

허기 측정

피자를 몇 개나 주문할지 결정하기 전에, 우리는 사람들이 얼마나 배고픈지 알아야 합니다.

Elasticsearch는 모든 샤드의 검색 부하를 추적합니다. 검색 부하는 샤드가 처리하는 검색 활동의 양을 나타내는 지표입니다. 전체 검색 수요를 파악하기 위해 인덱스의 전체 샤드에서 이를 집계합니다.

가장 중요한 것은 상대적 검색 부하입니다. 즉, 프로젝트의 전체 검색 트래픽 중 각 인덱스에 도달하는 비율을 파악하는 것입니다. 한 인덱스가 전체 검색의 60%를 받고 다른 인덱스가 5%를 받는다면, 어디에 용량을 추가해야 할지 알 수 있겠죠.

피자에 숨겨진 수학적 원리

다음 공식에 따라 최적의 복제본 수를 계산합니다.

위치:

• L은 인덱스의 상대적 검색 부하(0~1 사이)입니다.

• N =프로젝트에서 원하는 검색 노드 개수입니다.

• S = 인덱스의 샤드 수입니다.

• X = 핫스팟을 방지하기 위한 임계값입니다(기본값: 0.5).

예시: 검색 노드 4개, 기본 샤드 2개를 가진 인덱스 1개, 검색 트래픽의 80%를 수신하는 경우:

이 핫 인덱스는 검색 노드에 분산된 네 개의 복제본을 갖습니다.

임계값 X(기본값은 0.5)가 중요합니다. 복제본이 완전히 과부하될 때까지 기다리지 않고, 용량의 절반에 도달하면 규모를 확장합니다. 손님이 떠날 때가 아니라 인파가 모이기 시작할 때 여분의 피자를 나눠줍니다.

신속한 확장과 느긋한 축소

검색 부하가 증가하면 즉시 복제본을 추가합니다. 사용자를 기다리게 할 이유가 없습니다.

검색 부하가 떨어지면 조치를 취하기 전에 잠시 기다립니다. 낮은 수요가 약 30분 동안 일관적으로 지속되어야 복제본을 줄입니다. (이는 급증하는 트래픽을 처리하기 위한 것이며 조용한 순간이 파티가 끝났다는 의미는 아닙니다.)

복제본을 추가하려면 비용이 들기 때문에 이는 중요한 문제입니다. 새로운 복제본은 데이터를 복사하고 캐시를 워밍한 후 쿼리를 효율적으로 처리합니다. 너무 성급하게 복제본을 제거하면 트래픽의 자연스러운 변동에 따라 지속적으로 이러한 시작 비용을 지불하게 됩니다.

토폴로지 경계 준수

복제본 수는 검색 노드 수를 초과할 수 없습니다. 노드보다 더 많은 복제본을 갖는 것은 아무런 이점이 없습니다(피자 조각을 제공하는 친구의 수만큼만 피자를 제공할 수 있습니다).

프로젝트에서 노드가 제거되면 복제본 수를 즉시 줄여서 노드 수와 일치시킵니다. 할당되지 않은 복제본을 보유할 수 없기 때문에 쿨다운을 기다리지 않습니다. 친구가 떠나는 순간, 그 피자도 제거됩니다.

더 큰 서버리스 그림

검색 로드 밸런싱을 위한 복제본은 다른 자동 확장 시스템과 함께 작동합니다.

• 검색 자동 확장은 검색 노드 수(도와주는 친구 수)를 조정합니다.

• 검색 부하 분산을 위한 복제본은 인덱스당 복제본 수(종류별로 필요한 피자 수)를 조정하여 트래픽을 분산합니다.

• 데이터 스트림 자동 샤딩은 쓰기에 대한 샤드 수를 최적화합니다(각 피자를 자르는 방법은 이전 포스트에서 다뤘습니다).

중요한 설계 원칙: 로드 밸런싱용 복제본은 검색 자동 확장을 직접 유발하지 않습니다. 대신, 검색 요청을 더 많은 복제본에 분산함으로써 검색 노드 전체의 리소스 사용량을 높일 수 있습니다. 이렇게 높은 사용량은 필요한 경우 용량을 추가하도록 기존의 자동 확장 로직을 작동시킵니다. 로드 밸런싱을 위한 복제본은 자동 확장이 제 기능을 수행하도록 하여, 다른 노드가 사용되지 않는 동안 모든 트래픽이 단일 복제본에 병목 현상을 일으키는 대신 검색 노드가 실제로 사용되도록 합니다.

이것이 귀하에게 의미하는 것

어떤 인덱스가 인기를 끌지 예측할 필요는 없습니다. 트래픽 패턴이 변경될 때 복제본을 수동으로 조정하지 않아도 됩니다. 가장 사용량이 많은 인덱스에 과부하가 걸렸다고 해서 새벽 3시에 일어날 필요는 없습니다.

시스템은 대기열이 형성되는 위치를 감지하여 해당 지점에 더 많은 피자를 주문합니다. 콜드 인덱스는 불필요한 복제본에 자원을 낭비하지 않습니다. 핫 인덱스는 필요한 용량을 확보합니다. 예산은 중요한 곳에 사용됩니다.

결론

자동 샤딩 게시물에서 피자를 적절하게 잘랐습니다. 이제 검색 부하 분산을 위한 복제본으로 배고픈 사람들이 몰려들 때 충분한 양의 피자를 적절한 사람들에게 전달하겠습니다.

Elastic Cloud Serverless를 사용하면 피자 배달을 처리해 드립니다.

에이전트는 효율성 향상과 더 나은 고객 경험을 제공할 수 있는 잠재력으로 인해 주목받고 있습니다. 그러나 실제로는 에이전트에게 적절한 컨텍스트를 제공하기가 쉽지 않으며, 특히 복잡하고 비정형적인 엔터프라이즈 데이터를 처리할 때는 더욱 그렇습니다. 개발자는 도구, 프롬프트, 상태, 추론 논리, 모델을 관리해야 하며, 특히 비즈니스 소스에서 관련 컨텍스트를 검색하여 정확한 결과와 작업을 제공해야 합니다. Elastic Agent Builder는 안전하고 신뢰할 수 있는 컨텍스트 기반 에이전트를 개발하기 위한 핵심 구성 요소를 제공합니다.

Agent Builder의 핵심 기능

Agent Builder는 검색 정확도와 검색 증강 생성 분야에 대한 Elastic의 지속적인 투자와 Elasticsearch를 최적의 벡터 데이터베이스로 만들기 위한 노력을 통해, 맥락적이고 데이터에 초점을 둔 AI 에이전트 개발을 단순화합니다.

Agent Builder로 할 수 있는 일은 다음과 같습니다.

• 질문에 답하고, 분석을 수행하며, Elasticsearch에 있는 모든 데이터를 기반으로 조사까지 진행할 수 있는 기본 제공 대화형 에이전트를 즉시 시작할 수 있습니다.

• 복잡하고 비정형적인 데이터에서 출발해, 설정 기반의 개발 환경을 갖춘 사용자 정의 에이전트로 신속히 전환할 수 있습니다.

• 기본 제공 ES|QL이나 사용자 정의 도구를 활용해 업계 최상급의 하이브리드 검색 정확도를 적용함으로써, 컨텍스트의 품질과 에이전트의 안정성을 높일 수 있습니다.

• 복잡한 워크플로우를 재사용 가능한 도구로 실행하여 데이터 강화, 기록 갱신, 메시지 발송 등 다양한 규칙 기반 자동화를 구현할 수 있습니다(미리보기 버전).

• 워크플로우 및 MCP를 사용하여 Elasticsearch 외부의 데이터 소스에 연결하고 에이전트에 대한 컨텍스트를 상호 연관시키고 결합할 수 있습니다.

• MCP 기반의 기본 제공·사용자 정의 도구를 통해 다양한 에이전틱 및 애플리케이션 프레임워크와 연동할 수 있고, 외부 MCP 연결(미리보기 버전), A2A 지원, 완전한 API 지원을 제공합니다.

• Agent Builder의 기능을 더욱 확장하려면 복잡한 문서 처리에는 LlamaIndex를, 보안성과 구조화를 갖춘 도구 액세스에는 Arcade.dev를 연동할 수 있습니다.

Agent Builder의 기능성을 한층 강화하고자, 새로운 규칙 기반 자동화 기능인 Elastic Workflows를 기술 미리보기로 선보입니다. 조직 차원의 작업에서 에이전트는 특정 비즈니스 로직을 구현하기 위해 규칙 기반 조치의 확실성과 신뢰성이 필요한 경우가 종종 있습니다. Elastic Workflows는 에이전트가 내부·외부 시스템을 오케스트레이션해 조치를 실행하고, 데이터와 컨텍스트를 수집 및 가공할 수 있는 단순한 선언형 방법을 제공합니다. 워크플로는 완벽하게 조합 가능하고, 이벤트 중심 구조와 높은 유연성을 갖추고 있으며, MCP를 통해 에이전트에 도구로 노출될 수 있습니다.

데이터에서 에이전트로 단 몇 분 만에 전환

에이전트 개발은 분산된 데이터 저장소를 통합하고, 수동 파이프라인을 구축하며, 쿼리를 튜닝하고, 복잡한 오케스트레이션을 관리해야 해 초기 단계에서 몇 주가 걸리기도 합니다. Agent Builder는 별도의 데이터 저장소, 벡터 데이터베이스, RAG 파이프라인, 검색 계층, 쿼리 변환기, 도구 오케스트레이터가 필요 없도록 해 주어 에이전트 개발 시간을 단축하고, 에이전트 로직과 애플리케이션 제공에 집중할 수 있게 합니다.

Agent Builder는 Elasticsearch 플랫폼의 기본 구성 요소를 네이티브로 통합해 에이전트 개발을 빠르게 만듭니다.

• 인덱싱된 데이터를 대상으로 즉시 대화하고 추론할 수 있는 기본 제공 대화형 에이전트를 통해 바로 시작할 수 있습니다.

• Kibana, API, MCP, A2A를 통한 대화형 접근을 활용해 에이전트를 애플리케이션, 대시보드 또는 CI/CD 시스템에 통합할 수 있습니다.

• 기본 제공 도구를 활용해 데이터 구조를 이해하고, 적절한 인덱스를 선택하며, 최적화된 하이브리드·시맨틱·구조화 쿼리를 생성하고, 자연어 프롬프트를 기반으로 ES|QL을 사용해 시각화를 유연하게 구성할 수 있습니다.

더 깊이 살펴보려면 전 과정의 실습형 단계별 안내를 활용해 보세요.

컨텍스트 엔지니어링을 위한 완벽한 데이터 플랫폼인 Elasticsearch 기반 구축

AI 에이전트의 경우, 효과적인 추론을 제공하고 환각의 위험을 줄이기 위해서는 컨텍스트의 품질이 매우 중요합니다. 많은 기업용 AI 에이전트에게 있어 작업을 수행하는 데 필요한 비즈니스 데이터는 가장 중요한 컨텍스트 정보입니다. 대규모 확장이 가능한 데이터 저장소이자 벡터 데이터베이스이며 검색 정확도 분야의 선두 주자인 Elasticsearch는 이미 강력한 컨텍스트 엔지니어링 핵심 기능을 다수 제공하고 있습니다. 컨텍스트 엔지니어링은 단순한 검색 증강 생성을 넘어, 데이터 조회·순위화·필터링·표현 방식을 조정 및 확장할 수 있게 하여 에이전트가 받는 잡음과 모호함을 줄이는 데 도움이 됩니다.

Elasticsearch는 어휘 검색, 벡터 검색, 구조화 필터링을 결합한 컨텍스트 엔진을 제공하여 모델이 관련성 높고 정확한 컨텍스트에서 동작하도록 보장해 실질적으로 LLM 성능을 향상시킵니다. 이 기능은 에이전트형 검색을 기반으로 하며, 적절한 인덱스를 자동으로 선택하고 자연어를 컨텍스트에 최적화된 쿼리로 변환하는 기본 제공 도구와 검색 로직이 이를 지원합니다.

Agent Builder를 사용하면 정확도와 순위화를 제어하는 기능을 통해 에이전트가 가장 유용한 컨텍스트를 우선적으로 받도록 할 수 있으며, 점수 매기기·순위화·필터링 로직을 세밀하게 조정할 수 있습니다. Elasticsearch는 불명확한 검색 동작에 의존하는 대신, 무엇이 중요한지, 왜 중요한지, 그리고 어떻게 우선순위를 둘지를 직접 제어할 수 있게 합니다. 이 모든 것은 텍스트, 벡터, 메타데이터, 로그 등 모든 데이터를 하나의 플랫폼에서 저장·확장할 수 있는 확장형 데이터 플랫폼인 Elasticsearch를 기반으로 하여, 에이전트용 컨텍스트 관리를 더욱 용이하게 합니다.

재사용 가능한 도구로 복잡한 워크플로우 실행

AI 에이전트가 복잡한 작업에서 추론을 수행하더라도, 자동화의 상당 부분은 특정 비즈니스 로직을 적용하는 규칙 기반 조치를 안정적으로 실행하는 데 의존합니다. Elastic Workflows는 내부 및 외부 시스템을 오케스트레이션하여 작업을 실행하고 컨텍스트 또는 데이터를 수집한 뒤, 이를 에이전트에 통합할 수 있도록 하는 단순한 선언형 방법을 제공합니다. 워크플로우는 YAML로 정의되며, 완전한 조합 구조를 지원하여 작업 성격에 따라 단순하게도, 복잡하게도 구성할 수 있습니다. 이를 통해 에이전트는 Elasticsearch 플랫폼과 다양한 솔루션, 나아가 서드파티 애플리케이션까지 아우르며 효율적으로 동작할 수 있습니다.

워크플로우를 Agent Builder와 통합하는 과정은 세 단계로 진행할 수 있습니다(전제 조건: 여기 안내된 자세한 내용에 따라 워크플로우 활성화).

1. 기본 제공 자동 완성 및 테스트 기능을 갖춘 간단한 YAML 기반 편집기를 사용하여 새 워크플로우를 생성하고 저장합니다.

2. Agent Builder에서 “워크플로우” 타입의 새 도구를 생성한 뒤, 에이전트가 해당 워크플로우 도구를 사용할 시점을 결정하는 데 도움이 되도록 설명을 입력합니다.

3. 사용자 정의 에이전트에 워크플로우 도구를 추가합니다.

4. 끝입니다! 이제 에이전트가 대화 도중에 워크플로우를 호출할 수 있습니다.

나만의 에이전트, 나만의 규칙

Agent Builder는 하나의 개발 패러다임만을 강요하지 않습니다. 대신 데이터, 정확도, 모델, 상호 운용성, 보안, 에이전트 설계 전반을 완전히 제어할 수 있는 개방적이고 유연한 에이전트 개발 방식을 지원하도록 설계되었습니다.

사용자 지정 에이전트 정의를 사용하면 에이전트가 사용할 수 있는 도구를 명확히 지정하고, 사용자 지정 시스템 프롬프트를 삽입하며, 에이전트 지침을 세밀하게 조정하고 보안 범위를 설정할 수 있습니다. 에이전트는 특정 모델에 종속되지 않으므로, 하나의 제공업체에 의존하지 않고 기본 제공 모델부터 외부 에코시스템의 LLM까지 원하는 대로 자유롭게 설정할 수 있습니다.

도메인별 로직(예: 특정 인덱스 필터, ES|QL 조인, 분석 파이프라인)을 캡슐화한 확장형 도구를 구축하고, 프로덕션 환경에서 안전하게 사용하도록 제약을 설정할 수 있습니다. 완전한 API 지원으로 다른 에이전트형 프레임워크와의 상호 운용이 가능하며, 모델 컨텍스트 프로토콜(MCP)을 기본적으로 지원합니다. A2A 통합을 통해 Elastic 에이전트를 다른 프레임워크, 서비스, 클라이언트 앱에 노출할 수 있으며, 동일한 데이터와 컨텍스트 엔지니어링 로직을 여러 통합 환경에서 재사용할 수 있습니다.

Agent Builder는 유연하고 개방적인 개발을 지원하며, 널리 사용되는 에이전트 프레임워크 및 플랫폼과 쉽게 통합되도록 설계되었습니다. 효과적인 에이전트를 제공하려면 이러한 통합이 필수적인 요소가 될 수 있습니다. Arcade.dev의 공동 창립자인 Sam Partee의 말처럼,

"오늘날 에이전트형 시스템이 실패하는 이유는 AI를 도구와 데이터에 연결하는 과정이 복잡하기 때문입니다. Arcade.dev와 연동된 Elastic Agent Builder는 에이전트의 컨텍스트 조회, 추론, 실행 과정을 개발자가 체계적이고 안전하게 관리할 수 있는 방식을 제공하여, 데모 수준의 에이전트를 프로덕션 등급으로 끌어올릴 수 있게 합니다.

Agent Builder는 복잡한 데이터 처리를 위해 Elasticsearch의 확장성을 활용하기도 합니다. LlamaIndex CEO인 Jerry Liu의 말처럼,

"비정형 데이터 소스에서 엔터프라이즈 컨텍스트를 끌어내는 것이 효과적인 에이전트를 구축하는 데 있어 핵심입니다. LlamaIndex의 복잡한 문서 처리 기능과 결합된 Elastic Agent Builder는 핵심 컨텍스트 계층을 강화해, 팀이 데이터를 검색·가공·준비할 수 있도록 지원하며 에이전트가 보다 정확하게 추론하고 더 나은 결과를 제공하도록 합니다.

무엇을 구축할 수 있나요?

Agent Builder는 이미 다양한 사용 사례에 사용되고 있습니다. 아래에는 에이전트 개발을 시작하는 데 참고할 수 있는 몇 가지 예시와 아키텍처가 소개되어 있습니다.

• 인프라 자동화: 지원 업무 상황에서 에이전트는 읽고, 생각하고, 대화하는 데 활용되어 왔지만, 지금까지는 실제로 관리 대상인 인프라에 직접 접근해 제어하지는 못했습니다. Elastic의 엔지니어링 팀은 해커톤의 일환으로 자동화된 인프라 관리를 위한 에이전트를 구축했습니다. 이 에이전트는 애플리케이션 인프라 문제를 적극적으로 조사하고 자동화된 조치를 취합니다. 인프라 로그를 지능적으로 이해한 결과를 바탕으로 워크플로우를 사용하여 설정을 최적화하고, 문제에 대응하며, 리소스를 확장합니다.

• 보안 위협 분석: Elastic Agent Builder, MCP, Elasticsearch를 사용하여 보안 취약점 에이전트가 개발되었습니다. 내부 보안 데이터와 외부 위협 인텔리전스를 연관시켜 위협 분석을 자동화합니다. 이 에이전트는 과거 인시던트 및 설정 정보를 대상으로 시맨틱 검색을 수행하고, 실시간 인터넷 데이터로 결과를 강화한 뒤 LLM 추론을 적용해 환경적 관련성을 평가하고 위험 우선순위를 정하며 실행 가능한 대응 방안을 도출합니다. 참조 아키텍처를 확인하세요.

• 기술 고객 지원: 에이전트는 사례 요약부터 문제 중복 정리와 신규 문제 생성, 고급 기술 분석까지 여러 지원 작업을 처리할 수 있습니다. Agent Builder는 다단계 하이브리드 검색을 통해 가장 관련성 높은 문제와 해결책, 절차만을 찾아내고, 근본 원인 가설과 조치 계획을 수립할 수 있도록 지원합니다. Agent Builder는 복잡한 지원 시스템의 아키텍처를 단순화하고 제공까지 걸리는 시간을 단축할 수 있습니다.

• 제품 및 콘텐츠 탐색: Agent Builder는 대화형 환경에서 복잡한 제품 카탈로그를 공개하는 과정을 간소화하는 동시에, 조직이 자체 비즈니스 로직과 요구 사항을 유연하게 반영할 수 있도록 합니다.

• 직접 구축: 2026년 1월 22일부터 2월 27일까지 진행되는 Agent Builder 해커톤에 참여하세요. 커뮤니티와 협력하여 검색, 워크플로우, 도구, 추론을 통합한 컨텍스트 중심의 다단계 AI 에이전트를 만들고, 현실 세계의 작업을 자동화할 수 있습니다*

지금 바로 맞춤형 에이전트를 구축해 보세요

Elastic Cloud 체험판으로 시작하고, 설명서를 여기에서 확인해 보세요. 기존 고객의 경우, Agent Builder는 Cloud Serverless와 Elastic Cloud Hosted, 자체 관리형의 Enterprise 티어에서 사용할 수 있습니다.

* 해커톤의 전체 약관, 조건, 참가 자격 요건을 확인하려면 여기를 클릭하세요

AWS에서 실행되는 모든 Elastic Cloud Serverless 프로젝트에 대한 주요 인프라 업그레이드를 완료하여 더 새롭고 빠른 하드웨어로 마이그레이션하였습니다. 해당 변경 사항이 모든 서버리스 프로젝트에 자동으로 적용되었습니다. 이 솔루션은 AWS에서 Elasticsearch, Elastic Observability 및 Elastic Security 서버리스 프로젝트에 더 높은 처리량과 더 낮은 지연 시간을 제공합니다.

개발자를 위한 주요 성능 혜택

새로운 AWS 하드웨어 인프라는 Elastic Cloud Serverless에서 수행하는 모든 작업을 뒷받침하여 애플리케이션의 속도와 반응성에 실질적인 이점을 제공합니다.

쿼리 지연 시간 감소 및 처리량 증가

향상된 하드웨어가 획기적으로 컴퓨팅 리소스의 속도를 높여 검색 쿼리가 그 어느 때보다 빠르게 처리됩니다.

• 검색 및 벡터 검색: 기존의 풀텍스트 쿼리를 실행하든, 생성형 AI 및 검색 증강 생성(RAG) 애플리케이션에 최첨단 벡터 검색을 사용하든, 대기 시간이 현저히 줄어듭니다. 내부 벤치마킹 결과 검색 지연 시간이 평균 35% 감소한 것으로 나타났습니다.

• 더욱 빠른 색인: 데이터 수집 속도가 최적화되어 대용량 데이터와 복잡한 문서를 처리량을 높여 색인할 수 있습니다. 이는 거의 실시간 데이터 가시성이 필요한 애플리케이션에 매우 중요합니다. 내부 벤치마킹 결과, 색인 처리량이 평균 26% 증가했습니다.

부하 상태에서도 일관된 성능

수요에 맞춰 실시간으로 동적으로 자동 확장되도록 설계된 Elastic Cloud Serverless는 작업 부하에 관계없이 대기 시간을 최소화합니다. 이번 하드웨어 업그레이드를 통해 확장이 더욱 향상되고 반응 속도도 빨라졌습니다.

• 급증하는 데이터를 손쉽게 처리: 사용자 트래픽이 갑자기 급증하거나 대규모 배치 데이터 인제스트에 직면하더라도, 새로운 인프라가 검색 및 색인 리소스를 보다 효율적으로 확장하여 낮은 지연 시간을 일관적으로 유지합니다.

• 컴퓨팅-저장 공간 분리 최적화: 서버리스 아키텍처는 컴퓨팅과 저장 공간을 분리하여 워크로드가 독립적으로 확장될 수 있도록 함으로써 최적의 성능과 비용 효율성을 제공합니다. 더 빠른 하드웨어가 컴퓨팅 계층을 향상시켜 분리된 설계의 효율성을 극대화합니다.

작동 원리: 내부 벤치마킹 결과

Elastic 엔지니어링 팀은 AWS 인프라 업그레이드의 영향을 정량화하기 위해 다양한 서버리스 워크로드를 대상으로 포괄적인 내부 벤치마킹을 수행했습니다. 이러한 워크로드는 사용 사례와 관계없이 애플리케이션 전반에서 기대할 수 있는 성능 향상에 대한 실증적 증거를 제공했습니다.

벤치마킹 접근법

개발자 경험과 애플리케이션 반응성에 직접적인 영향을 미치는 주요 지표인 응답 시간(지연 시간)과 검색 및 색인 작업 처리량을 집중적으로 테스트했습니다.

• 테스트를 마친 워크로드: 테스트에는 사용자 대면 애플리케이션에서 흔히 볼 수 있는 동시성이 높은 검색 작업, 복잡한 벡터 검색 쿼리, 통합 가시성 및 보안 사용 사례에 대한 대용량 데이터 수집/색인 등이 포함되었습니다. 그중에서도 테스트 방법론에서 Elastic의 벤치마킹 도구인 Rally에 대해 공개적으로 이용 가능한 데이터 세트를 사용했습니다.

  • wikipedia: 위키피디아 텍스트 콘텐츠의 스냅샷에서 추출된 데이터 세트로, 일반 텍스트 검색 성능을 측정하는 데 사용됩니다.

  • MSMARCO-Passage-Ranking: Microsoft의 Machine Reading Comprehension(MS MARCO)에서 파생된 데이터 세트로, 희소 벡터 필드에서 검색 성능을 측정합니다.

  • OpenAI_Vector: BEIR의 NQ에서 파생된 데이터 세트로, OpenAI의 text-embedding-ada-002 모델이 생성한 임베딩으로 보강되어 조밀한 벡터 필드에서의 검색 성능을 측정하기 위한 것입니다.

• 측정: 구식 인프라와 신규 인프라의 성능을 비교했으며, 최악의 경우인 극한 지연 시간 성능과 초당 작업량을 파악하기 위해 99번째 백분위수(P99)에서의 지연 시간을 측정했습니다. 결과의 일관성을 확보하기 위해 하드웨어 프로필마다 각 트랙을 5회씩 실행했습니다.

• 목표: 목표는 빠른 자동 확장 기간에도 전반적으로 일관되게 더 빠르고 예측 가능한 성능을 제공하는 인프라의 기능을 검증하는 것이었습니다.

성능 데이터 요약

그 결과 효율성과 속도가 크게 향상되었음을 확인할 수 있었습니다. 이러한 이점은 사용자 응답 시간 단축과 운영 비용 절감으로 직결됩니다. 더 적은 컴퓨팅 리소스로 동일한 작업을 완료할 수 있기 때문입니다.

다음 표에는 정량적 개선 사항이 자세히 설명되어 있습니다. 높은 값은 처리량에 더 좋고, 낮은 값은 지연 시간에 더 좋습니다.

벤치마크 결과 검색:

벤치마크

비교

구식 인프라

새로운 인프라

차이

'위키피디아'(일반 텍스트)

검색 작업 처리량(초당 연산 수)

729

1107

+52%

'위키피디아'(일반 텍스트)

검색 작업 지연 시간(p99, ms)

56

35

-37%

`MSMARCO-Passage-Ranking` (희소 벡터)

검색 작업 처리량(초당 연산 수)

22

31

+40%

`MSMARCO-Passage-Ranking` (희소 벡터)

검색 작업 지연 시간(p99, ms)

108

67

-38%

`OpenAI_Vector`(고밀도 벡터)

검색 작업 처리량(초당 연산 수)

475

624

+31%

`OpenAI_Vector`(고밀도 벡터)

검색 작업 지연 시간(p99, ms)

35

22

-37%

색인 벤치마크 결과:

벤치마크

비교

구식 인프라

새로운 인프라

차이

'위키피디아'(일반 텍스트)

검색 작업 처리량(초당 연산 수)

2845

3220

+13%

'위키피디아'(일반 텍스트)

검색 작업 지연 시간(p99, ms)

1769

1120

-37%

`MSMARCO-Passage-Ranking` (희소 벡터)

검색 작업 처리량(초당 연산 수)

7087

8900

+26%

`MSMARCO-Passage-Ranking` (희소 벡터)

검색 작업 지연 시간(p99, ms)

824

677

-18%

`OpenAI_Vector`(고밀도 벡터)

검색 작업 처리량(초당 연산 수)

2972

3187

+7%

`OpenAI_Vector`(고밀도 벡터)

검색 작업 지연 시간(p99, ms)

2946

2944

0%

추가 보너스: 비용 절감

낮은 지연 시간으로 뛰어난 성능을 제공하는 데 중점을 두고 있지만, 새로운 하드웨어의 효율성은 Elasticsearch 프로젝트의 비용에도 직접적이고 긍정적인 영향을 미칩니다.

Elasticsearch Serverless 요금제는 사용량 기반이므로, 사용한 인제스트 및 검색 리소스에 대해서만 비용을 지불하면 됩니다. 더 빠른 신규 하드웨어는 효율성이 높기 때문에 대부분의 프로젝트에서 종종 더 적은 리소스를 사용하여 워크로드가 작업을 완료하게 되어 본질적인 비용 절감으로 이어집니다. 높은 금액을 지불하지 않고도 프리미엄 수준의 성능 향상을 얻을 수 있습니다. 최적화된 효율성이라고 할 수 있죠.

이것이 개발자에게 의미하는 바는 무엇일까요?

Elastic에서 이 인프라 업그레이드를 전적으로 관리하므로 손가락 하나 까딱하지 않아도 됩니다. 마이그레이션이나 구성 변경도 필요 없습니다. 이러한 개선 사항은 모든 AWS 기반 서버리스 프로젝트에 즉각적으로 자동 적용됩니다.

업그레이드의 효과:

• 더 빠른 애플리케이션 구축: 기본 검색 플랫폼이 사용자가 요구하는 속도를 제공한다는 것을 알기 때문에 기능 개발 속도에 집중할 수 있습니다.

• 자신감 있는 혁신: 플랫폼이 최고의 성능으로 부하를 처리할 수 있다는 확신을 가지고 벡터 검색 및 관련성 순위와 같은 복잡한 AI 기능을 포함한 새로운 검색, 통합 가시성 및 보안 기능을 배포하세요.

• 스택 간소화: 인프라 관리, 용량 계획 및 확장을 처리하는 완전 관리형 서비스를 사용하여 코드와 데이터에 집중할 수 있습니다.

1. 리포지토리를 복제합니다: git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent a을 사용하여 GitHub에서 도구의 코드를 다운로드하고 cd serverless-ai-agent 을 사용하여 디렉토리로 이동합니다.

2. 환경을 설정합니다: python -m venv venv 으로 가상 환경(선택 사항)을 만들고 활성화합니다(Windows의 경우source venv/bin/activate 또는 venv\Scripts\activate ). 그런 다음 pip install -r requirements.txt 를 사용하여 필요한 Python 패키지를 설치합니다.

3. 자격 증명을 구성합니다: 프로젝트 루트에 .env 파일을 생성하고 Elasticsearch API URL(ES_URL), API 키(API_KEY), 지역(REGION), OpenAI API 키(OPENAI_API_KEY)로 채웁니다.

4. 도구를 실행합니다: 터미널에서 python main.py 을 실행하여 도구를 실행합니다. 그러면 AI 에이전트가 시작되고 명령에 대한 프롬프트가 표시됩니다.

5. 자연어로 프로젝트를 관리하세요: " 내\_프로젝트라는 서버리스 프로젝트 만들기", "내\_프로젝트라는 서버리스 프로젝트의 상태 보기", 또는 "내\_프로젝트라는 서버리스 프로젝트 삭제" 와 같은 일반 영어 명령을 사용하여 도구와 상호 작용합니다. AI가 사용자의 명령을 해석하고 해당 기능을 실행합니다.

배경

이 작은 명령줄 도구를 사용하면 서버리스 Elasticsearch 프로젝트를 일반 영어로 관리할 수 있습니다. AI(이 경우 OpenAI)와 대화하여 사용자가 의미하는 바를 파악하고 LlamaIndex를 사용하여 올바른 함수를 호출합니다!

Elasticsearch 서버리스 AI 에이전트가 수행할 수 있는 작업

• 프로젝트를 생성합니다: 새 서버리스 Elasticsearch 프로젝트를 생성합니다.

• 프로젝트를 삭제합니다: 기존 프로젝트를 삭제합니다(예, 자동으로 정리됩니다).

• 프로젝트 상태를 확인하세요: 프로젝트 진행 상황을 확인하세요.

• 프로젝트 세부 정보 가져오기: 프로젝트에 대한 모든 중요한 세부 정보를 가져옵니다.

GitHub에서코드를 확인하세요.

Elasticsearch 서버리스 AI 에이전트의 작동 방식

다음과 같은 내용을 입력하면

"내_프로젝트라는 이름의 서버리스 프로젝트를 만듭니다."

...무대 뒤에서 일어나는 일들을 소개합니다:

• 사용자 입력 & 컨텍스트: 자연어 명령이 AI 상담원에게 전송됩니다.

• 함수 설명: AI 에이전트는 이미 자세한 설명을 제공했기 때문에 create_ess_project, delete_ess_project, get_ess_project_status, get_ess_project_details와 같은 몇 가지 함수에 대해 알고 있습니다. 이러한 설명은 각 기능이 수행하는 작업과 필요한 매개변수를 AI에 알려줍니다.

• LLM 처리: 쿼리와 함수 정보가 LLM으로 전송됩니다. 즉, AI가 본다는 뜻입니다:

  • 사용자 쿼리입니다: 일반 영어 명령어.

  • 사용 가능한 기능 & 설명: 올바른 도구를 선택할 수 있도록 각 도구의 기능에 대한 세부 정보입니다.

  • 컨텍스트/기록 채팅 정보: 대화이기 때문에 이전에 대화한 내용을 기억합니다.

• 함수 호출 & 응답: AI가 어떤 함수를 호출할지 파악하고 프로젝트 이름과 같은 올바른 매개변수를 전달한 다음 함수가 실행됩니다. 응답은 친숙한 형식으로 다시 전송됩니다.

즉, 자연어 쿼리와 자세한 도구 설명 목록을 모두 LLM에 전송하여 요청에 대한 올바른 조치를 '이해'하고 선택할 수 있도록 합니다.

AI 에이전트 설정

전제 조건:

AI 에이전트를 실행하기 전에 다음 사항을 설정했는지 확인하세요:

1. Python(v3.7 이상)이 설치되어 있어야 합니다.

2. Elastic Cloud에 서버리스 계정 설정.

3. 언어 모델과 상호 작용할 수 있는 OpenAI 계정입니다.

단계:

1. 리포지토리를 복제합니다:

2. 가상 환경 만들기(선택 사항이지만 권장): 환경 관련 문제가 발생하면 가상 환경을 설정하여 격리할 수 있습니다:

3. 종속성을 설치합니다: 실행하여 필요한 모든 종속성이 설치되었는지 확인합니다:

4. 환경을 구성합니다:.env 파일을 프로젝트 루트에 다음 변수와 함께 추가합니다. 다음은 도움이 되는 .env.example 파일 예제입니다:

ES_URL, API_KEY, OPENAI_API_KEY 에 올바른 값을 입력했는지 확인합니다. API 키는 각 서비스 대시보드에서 찾을 수 있습니다.

5. 프로젝트 파일: 이 도구는 projects.json 파일을 사용하여 프로젝트 매핑(프로젝트 이름과 세부 정보)을 저장합니다. 이 파일이 아직 존재하지 않으면 자동으로 생성됩니다.

AI 에이전트 실행

다음과 같은 메시지가 표시됩니다:

명령을 입력하면 AI 에이전트가 마법을 부립니다! 완료되면 exit 또는 quit 을 입력하여 종료합니다.

몇 가지 추가 정보

• LLM 통합: LLM에는 쿼리와 사용 가능한 각 기능에 대한 자세한 설명이 모두 제공됩니다. 이를 통해 컨텍스트를 이해하고 예를 들어 create_ess_project 또는 delete_ess_project 으로 전화할지 여부를 결정할 수 있습니다.

• 도구 설명: 각 함수 도구(FunctionTool.from_defaults를 사용하여 생성됨) 에는 친절한 설명이 있습니다. 이 설명은 LLM에 전송되는 프롬프트에 포함되어 있어 사용 가능한 작업과 각 작업이 무엇을 기대하는지 "알 수 있도록" 합니다.

• 지속성: 프로젝트와 프로젝트의 세부 정보는 projects.json에 저장됩니다, 매번 정보를 다시 입력할 필요가 없습니다.

• 자세한 로깅: 에이전트가 자세한 정보 모드로 설정되어 있어 디버깅을 하고 명령어가 함수 호출로 변환되는 과정을 확인하는 데 유용합니다.

Elasticsearch AI 에이전트 활용 예시

시작점

Elasticsearch의 첫 번째 버전은 2010년에 사용자가 중요한 인사이트를 빠르게 검색하고 표시할 수 있는 분산 확장형 검색 엔진으로 출시되었습니다. 12년이 지나고 65,000개 이상의 커밋이 이루어진 후에도 Elasticsearch는 사용자에게 다양한 검색 문제에 대한 실전에서 검증된 솔루션을 계속 제공하고 있습니다. 수백 명의 정규직 Elastic 직원을 포함해 1,500명이 넘는 기여자들의 노력 덕분에 Elasticsearch는 검색 분야에서 발생하는 새로운 과제를 해결하기 위해 끊임없이 발전해 왔습니다.

데이터 손실에 대한 우려가 제기된 Elasticsearch 출시 초기에 Elastic 팀은 인정된 데이터가 안전하게 저장되도록 클러스터 조정 시스템을 재작성하기 위해 다년간의 노력을 기울였습니다. 대규모 클러스터에서 인덱스를 관리하는 것이 번거롭다는 것이 분명해지자, 팀은 사용자가 인덱스 패턴과 수명 주기 작업을 미리 정의하여 이 작업을 자동화할 수 있는 광범위한 ILM 솔루션을 구현하기 위해 노력했습니다. 사용자들이 상당한 양의 메트릭 및 시계열 데이터를 저장할 필요성을 느끼면서 데이터 크기를 줄이기 위해 더 나은 압축 등 다양한 기능이 추가되었습니다. 방대한 양의 콜드 데이터를 검색하는 데 드는 스토리지 비용이 증가함에 따라 저비용 개체 저장소에서 사용자 데이터를 직접 검색할 수 있는 방법으로 검색 가능한 스냅샷을 만드는 데 투자했습니다.

이러한 투자는 Elasticsearch의 다음 진화를 위한 토대를 마련합니다. 클라우드 네이티브 서비스와 새로운 오케스트레이션 시스템이 성장함에 따라, 우리는 클라우드 네이티브 시스템으로 작업할 때의 경험을 개선하기 위해 Elasticsearch를 발전시켜야 할 때라고 판단했습니다. 이러한 변화는 Elastic Cloud에서 Elasticsearch를 실행하면서 운영, 성능 및 비용을 개선할 수 있는 기회를 제공한다고 생각합니다.

우리가 나아갈 방향 - 무국적 아키텍처 채택

Elasticsearch를 운영하거나 오케스트레이션할 때의 주요 과제 중 하나는 수많은 영구 상태 조각에 의존하기 때문에 상태 저장 시스템이라는 점입니다. 세 가지 주요 요소는 번역, 인덱스 저장소, 클러스터 메타데이터입니다. 이 상태는 스토리지가 영구적이어야 하며 노드를 다시 시작하거나 교체하는 동안 손실되지 않아야 함을 의미합니다.

Elastic Cloud의 기존 Elasticsearch 아키텍처는 중단 시 중복성을 제공하기 위해 여러 가용성 영역에 걸쳐 인덱싱을 복제해야 합니다. 이 데이터의 지속성을 로컬 디스크에서 AWS S3와 같은 객체 저장소로 옮길 계획입니다. 이 데이터를 저장하기 위해 외부 서비스에 의존함으로써 인덱싱 복제의 필요성을 없애고 수집과 관련된 하드웨어를 크게 줄일 수 있습니다. 또한 이 아키텍처는 AWS S3, GCP 클라우드 스토리지, Azure Blob 스토리지와 같은 클라우드 개체 저장소가 가용 영역 간에 데이터를 복제하는 방식 덕분에 매우 높은 내구성을 보장합니다.

인덱스 저장소를 외부 서비스로 오프로드하면 인덱싱과 검색 책임을 분리하여 Elasticsearch를 다시 설계할 수도 있습니다. 기본 인스턴스와 복제 인스턴스가 두 워크로드를 모두 처리하는 대신, 인덱싱 티어와 검색 티어를 만들려고 합니다. 이러한 워크로드를 분리하면 독립적으로 확장할 수 있고 하드웨어를 각 사용 사례에 맞게 더 세분화하여 선택할 수 있습니다. 또한 검색과 색인 부하가 서로 영향을 미칠 수 있는 오랜 문제를 해결하는 데 도움이 됩니다.

수개월에 걸친 개념 증명과 실험 단계를 거친 결과, 이러한 개체 저장소 서비스가 인덱스 스토리지와 클러스터 메타데이터에 대해 우리가 구상하는 요구 사항을 충족한다고 확신하게 되었습니다. 테스트와 벤치마크 결과, 이러한 스토리지 서비스는 Elastic Cloud에서 본 최대 규모의 클러스터의 높은 인덱싱 요구 사항을 충족할 수 있는 것으로 나타났습니다. 또한 개체 저장소에 데이터를 백업하면 인덱싱 비용이 절감되고 검색 성능을 간단하게 조정할 수 있습니다. 데이터를 검색하기 위해 Elasticsearch는 데이터가 클라우드 네이티브 개체 저장소에 영구적으로 보존되고 로컬 디스크가 자주 액세스하는 데이터의 캐시로 사용되는, 수많은 테스트를 거친 검색 가능한 스냅샷 모델을 사용합니다.

차별화를 위해 기존 모델을 "노드 간" 복제라고 설명합니다. 이 모델의 핫 티어에서는 기본 샤드와 복제 샤드 모두 수집을 처리하고 검색 요청을 제공하기 위해 동일한 작업을 수행합니다. 이러한 노드는 로컬 디스크에 의존하여 호스팅하는 샤드의 데이터를 안전하게 유지한다는 점에서 "stateful" 입니다. 또한 기본 샤드와 복제 샤드는 동기화 상태를 유지하기 위해 지속적으로 통신합니다. 이는 기본 샤드에서 수행된 작업을 복제 샤드로 복제하는 방식으로 이루어지며, 이는 지정된 각 복제본에 대해 해당 작업의 비용(주로 CPU)이 발생한다는 의미입니다. 수집을 위해 이 작업을 수행하는 동일한 샤드와 노드가 검색 요청도 처리하므로 프로비저닝과 확장은 두 가지 워크로드를 모두 염두에 두고 수행해야 합니다.

노드 간 복제 모델의 샤드는 검색 및 수집 외에도 Lucene 세그먼트 병합과 같은 다른 집중적인 작업을 처리합니다. 이러한 설계에도 장점이 있지만, 수년 동안 고객과 함께 배운 점과 광범위한 클라우드 에코시스템의 진화를 바탕으로 많은 기회를 발견했습니다.

새로운 아키텍처를 통해 다음과 같은 많은 즉각적인 개선과 향후 개선이 가능합니다:

1. 동일한 하드웨어에서 수집 처리량을 크게 늘리거나, 다른 방식으로 말하면 동일한 수집 워크로드의 효율성을 크게 개선할 수 있습니다. 이러한 증가는 모든 복제본에 대한 인덱싱 작업의 중복을 제거한 결과입니다. CPU 집약적인 인덱싱 작업은 인덱싱 계층에서 한 번만 수행하면 결과 세그먼트를 오브젝트 저장소로 전송합니다. 이제 검색 계층에서 데이터를 그대로 사용할 수 있습니다.

2. 컴퓨팅과 스토리지를 분리하여 클러스터 토폴로지를 간소화할 수 있습니다. 현재 Elasticsearch는 데이터를 하드웨어 프로필과 일치시키기 위해 여러 데이터 계층(콘텐츠, hot, warm, cold, frozen)을 갖추고 있습니다. 핫 티어는 실시간에 가까운 검색을 위한 것이고, 프로즌은 검색 빈도가 낮은 데이터를 위한 것입니다. 이러한 계층은 가치를 제공하지만 복잡성을 증가시키기도 합니다. 새로운 아키텍처에서는 데이터 계층이 더 이상 필요하지 않으므로 Elasticsearch의 구성과 운영이 간소화됩니다. 또한 인덱싱과 검색을 분리하여 복잡성을 더욱 줄이고 두 워크로드를 독립적으로 확장할 수 있도록 하고 있습니다.

3. 로컬 디스크에 저장해야 하는 데이터의 양을 줄임으로써 인덱싱 계층의 스토리지 비용을 개선할 수 있습니다. 현재 Elasticsearch는 인덱싱을 위해 핫 노드(기본 및 복제본 모두)에 전체 샤드 복사본을 저장해야 합니다. 오브젝트 저장소에 직접 인덱싱하는 상태 비저장 방식에서는 해당 로컬 데이터의 일부만 필요합니다. 추가 전용 사용 사례의 경우 인덱싱을 위해 특정 메타데이터만 저장하면 됩니다. 이렇게 하면 인덱싱에 필요한 로컬 저장 공간을 크게 줄일 수 있습니다.

4. 검색 쿼리와 관련된 스토리지 비용을 절감할 수 있습니다. 검색 가능한 스냅샷 모델을 데이터 검색의 기본 모드로 설정하면 검색 쿼리와 관련된 스토리지 비용이 크게 감소합니다. 사용자의 검색 대기 시간 요구 사항에 따라 Elasticsearch는 자주 요청되는 데이터에 대한 로컬 캐싱을 늘리도록 조정할 수 있습니다.

벤치마킹 - 75% 인덱싱 처리량 개선

이 접근 방식을 검증하기 위해 단일 노드에서만 데이터를 인덱싱하고 클라우드 개체 저장소를 통해 복제를 수행하는 광범위한 개념 증명을 구현했습니다. 인덱싱 복제에 전용 하드웨어를 사용할 필요가 없어짐으로써 인덱싱 처리량을 75%(% ) 향상시킬 수 있다는 사실을 발견했습니다. 또한, 단순히 개체 저장소에서 데이터를 가져오는 것과 관련된 CPU 비용은 오늘날 핫 티어에 필요한 것처럼 데이터를 인덱싱하고 로컬에 쓰는 것보다 훨씬 낮았습니다. 즉, 검색 노드는 CPU를 검색에 전적으로 사용할 수 있게 됩니다.

이러한 성능 테스트는 3대 퍼블릭 클라우드 제공업체(AWS, GCP, Azure) 모두에 대해 2노드 클러스터에서 수행되었습니다. 프로덕션 상태 비저장 구현을 추진하면서 더 큰 규모의 벤치마크를 계속 구축할 계획입니다.

인덱싱 처리량

CPU 사용량

우리는 무국적자, 당신은 절약

Elastic Cloud의 상태 저장소 없는 아키텍처를 사용하면 색인 오버헤드를 줄이고, 수집과 검색을 독립적으로 확장하며, 데이터 계층 관리를 간소화하고, 확장이나 업그레이드와 같은 운영을 가속화할 수 있습니다. 이것은 Elastic Cloud 플랫폼의 실질적인 현대화를 향한 첫 번째 이정표입니다.

Elasticsearch 상태 저장소 없는 비전의 일부가 되세요.

다른 사람들보다 먼저 이 솔루션을 사용해보고 싶으신가요? 토론이나 커뮤니티 슬랙 채널에서 문의하실 수 있습니다. 새로운 아키텍처의 방향을 설정하는 데 도움이 되는 여러분의 피드백을 기다립니다.