• 본 문서는 2025년 12월 23일 기준으로 작성되었습니다.

• Elasticsearch 9.2.0, Kibana 9.2.0 버전을 기준으로 기술하였습니다.

Streams

Streams란

 Streams는 엘라스틱서치 9.2.0 버전에 정식 출시된 실시간 로그 중앙 관리 기능입니다. 실시간 로그를 한데 모아 상태 요약 확인, 전처리, 필드 매핑(스키마) 관리, 파티셔닝(로그 분리), ILM(수명주기) 관리, 설정 관리, 에러 확인 등 대부분의 작업을 하나의 UI에서 처리할 수 있게 되었습니다. 9.2.0 버전 이전에는 이 각각의 메뉴들이 전부 분리되어있어 작업을 할 때 여러 탭이 필요하고 이동이 필요했는데, 이제 그럴 필요 없이 하나의 UI에서 해결이 가능해졌습니다.

Retention

 하나의 스트림을 클릭하여 들어가면 스트림에 대한 상세 화면이 나옵니다. 가장 처음 나오는 화면은 Retention 탭으로,  가장 위쪽에 스트림명과 상태정보가 표기됩니다.

 Retention 탭에서는 Ingestion average 항목에서 전체 용량과 일일, 한달 평균 용량을 확인할 수 있습니다. 오래동안 엘라스틱서치의 약점으로 생각되어온 하루치 인덱스 용량을 확인하기 까다롭다는 점이 해결되었습니다. 분명 '어? 엘라스틱서치는 매일 인덱스가 쌓여서 용량 확인이 엄청 편한데?'라고 하는 관리자분들도 있을거라 생각됩니다.

 물론 매일 인덱스를 생성하게 설정하면, cat indices API로 바로 확인할 수 있는것은 맞습니다. 그러나 클러스터 최적화를 위해 인덱스를 날짜별이 아닌 용량에 따라 생성하게 하였을 때는, 전체 용량에서 적재한 날짜만큼 나누어야 평균 적재량이 계산되었는데 Streams에서는 스트림별로 하루치 데이터 평균값과, 한달치 데이터 평균값을 요약화면에서 바로 보여주어 굉장히 편리하였습니다. 참고로 mapper size plugin을 사용하여 용량을 방법도 있으나 이는 인덱스 적재 전 원본 로그양을 측정하는 방법이라 실제 인덱스의 크기와는 오차가 크게 났습니다. 

 Streams의 Ingestion Average를 통해 특정 시스템을 엘라스틱서치에 연동하기 전 테스트 단계에서 며칠간의 데이터로 견적을 잡는 등 로그양을 예상하는데 유용할 것으로 생각됩니다.

 Partitioning

 Partitioning 탭에서는 스트림에 대한 분기 처리를 할 수 있습니다. 즉, 실시간으로 들어오는 로그를 조건에 따라 다른 스트림으로 보내는 분류작업을 여기에서 할 수 있습니다. 기존에는 Ingest Pipeline에서 Reroute Processor를 통해 이 작업을 해야 했었는데 이제 여기서 전부 분기처리가 가능합니다. 또한, AI를 활용하여 파티셔닝 기준을 추천받을 수 도 있습니다.

 자동 생성을 누르면 연결된 AI가 로그 패턴을 분석하여 따라 자동으로 조건식을 생성해줍니다. 이 조건식은 수정이 가능하며, 아래 사진에는 없지만 조건식에 따라 분기되는 데이터 예시도 보입니다. 이 점을 활용하여 초기 설계나 구축 단계에서 먼저 logs 스트림에 연동 장비별 데이터를 전부 집어넣고, 추후에 분류하는 식으로도 구성이 가능합니다. 이렇게 할 경우 매핑에 구애받지 않고, 데이터 유실 없이 하나의 스트림에 먼저 적재할 수 있다는 장점이 있습니다.

 만약 매핑이 정해지지 않은 다양한 장비들의 데이터를 우선 수집하고 수집된 데이터를 기반으로 매핑 구성을 해야한다면, Streams를 사용하면 훨씬 편리합니다. 모든 데이터를 한데 모아 원본을 보관하고, 이후에 목적에 따라 다시 분리하면 됩니다. 이렇게 했을 경우 매핑 충돌에 의해 아예 엘라스틱서치에 적재가 안되어버리는 것을 방지할 수 있습니다. Streams가 9.2.0 버전에 새로 출시된 기능인지라 그런지 스트림을 Copy하는 기능은 없고, 분기 조건에 따라 move하는 기능만 있습니다. 만약 copy가 있다면 원본을 유지할 수 있으므로, 진정한 의미의 메인스트림 역할을 할 수 있을 듯 합니다.

 또한 이미 적재중인 데이터 스트림이나 인덱스의 매핑을 변경해야하는 경우에는 굉장히 불편함이 많았었습니다. 기존에는 새로운 인덱스와 스트림을 신규 매핑을 반영하여 만들고, 기존 스트림으로 향하는 엔드포인트를 신규 스트림으로 변경한 뒤, 적재 확인 후 기존 스트림과 인덱스를 다시 신규 스트림에 마이그레이션 해야 해서 불편했습니다. 스트림을 이용하면 매핑 변경이 필요할 때 조건식에서 스트림만 변경해서 바꾼뒤 기존 스트림 데이터를 마이그레이션 하면 되어 조금 더 편리합니다.

Processing

 전처리 역시 Streams에서 처리 가능합니다. 기존에는 Ingest Pipeline 내에서 처리하였고, Ingest Pipeline을 만들고 테스트 후 Index Template에 넣어주거나 직접 Settings에 넣어줘야 전처리가 가능했는데 이젠 Streams에서 가능합니다. Processing 탭에서 Create your first step을 클릭, Create Processor를 클릭합니다 

 어떤 전처리도 안되어있다면 Grok Processor를 선택하여 Generate pattern을 해보는것도 방법입니다. 현재 로그 기반으로 패턴을 찾아 Grok pattern으로 생성해주며, 패턴 Accept를 누르면 우측에 적용된 예시가 색깔별로 구분되어 표기됩니다.

Schema

 Streams에서는 스트림별 매핑 스키마를 정의하는 Schema UI가 존재합니다. Index Template 상에서 Mapping을 명시하는 것과 비슷한데, UI에서 관리하기 때문에 편리하다는 점과 AI에 의한 자동 매핑 추천 기능이 있다는 점이 다릅니다.

 필드들의 현재 매핑 타입을 확인할 수 있는데, alias를 통해 묶여있다면 어떤 필드와 묶여있는지도 Types 속성에서 확인 가능합니다. 또한, 만약 매핑이 정의되지 않은 필드가 있다면 선택하여 우측의 Map field UI를 통해 매핑을 정의할 수 있습니다.

 만약 매핑이 안된 필드가 많다면 Suggest 기능을 써보는 것도 방법입니다. 매핑이 안된 필드들을 클릭한 뒤(좌측 상단의 버튼 하나로 매핑 안된 필드들만 전부 선택 가능합니다), Suggest type을 누릅니다.

 자동으로 Type을 지정해주며, Status도 Unmapped에서 Mapped로 변경됩니다. 이대로 Submit changes를 누르면 변경이 되거나 오류 발생시 원인을 보여줍니다. Unmapped인데도 Suggest를 했을 때 ype 지정이 안되는 경우가 있는데, 그런 필드들은 데이터상 AI에 의해 필드 지정이 어려운 것인지 직접 필드 지정이 필요한 듯 합니다. 그럼에도 불구하고 Suggest 기능을 UI에서 제공해주는 것만으로도 큰 편리함이라는 생각이 듭니다.

Data Quality

 많은 데이터를 적재하고 분리하고 전처리하는 것도 중요하지만, 데이터를 '올바르게' 적재하는지 검토하는 것도 중요합니다. Data Quality 기능은 들어오는 도큐먼트가 정상 적재되는지, 만약 그렇지 않다면 이유가 무엇인지 분석하여 보여주는 UI입니다. Time Range에 따라 얼마나 많은 도큐먼트에 Degraded, Failed가 발생하였는지 한눈에 볼 수 있고, Issue 탭의 개별 필드를 클릭하면 어떤 이유에서 발생한건지도 이유가 나옵니다.

 위 사진의 경우에는 필드 길이 최대값인 ignore_above에 걸려 필드값이 전부 들어오지 못한 경우입니다. 이 경우 설명에 따라 field limit을 증가시키면 되는데, 아래 Possible mitigation에 있는 component template을 클릭하면 바로 적용 가능한 component template UI로 이동되며, 거기서 필드별 ignore_above 값을 수정해주면 됩니다.

Advanced

 마지막으로 Advanced 탭에서는 스트림에 연결된 Index Template과 Pipeline, Data Stream을 확인할 수 있으며, 클릭시 해당 UI로 이동됩니다. 또한 간단히 Primary Shards와 Replica Shards를 지정할 수 있고, 그 외에도 Component Template과 Delete stream 메뉴를 제공합니다.

마치며

 이번 포스팅에서는 Elasticsearch 9.2.0 버전에서 새로 출시된 로그 관리 기능, Streams를 살펴보았습니다. Streams는 특히 AI 기능을 활용한 편의 기능에 집중한듯 한 것으로 보이며, 지금도 전처리의 Grok이나 분기 처리에서 활용할 여지가 보입니다. 또한 하나의 프로젝트마다 문제였던 데이터를 파싱하는 과정에서 매핑이 맞지 않았을 때 데이터 드롭, 원인 분석이 오래 걸렸던 부분이 일부 해소되어 다행이라는 생각이 듭니다. 앞으로도 엘라스틱서치에서 Streams 기능을 꾸준히 업데이트 하고, 연동된 AI 성능이 향상시켜 전처리 과정과 스트림 관리가 편해지길 기대해봅니다.