콘텐츠로 이동

2026년 객체 저장소의 관찰성: 로깅이 100배 저렴해진 이유

· 13 min read · default
monitoringobservabilityloggingdevopsopentelemetryinfrastructure

지난 십년의 대부분 동안, 관찰성은 불편한 비밀을 가졌습니다. 관찰할 수 있는 것에 대한 주요 제약은 기술적이지 않았지만 재정적이었습니다. 팀들은 저장소 청구서가 트래픽보다 빠르게 증가했던 Elasticsearch 클러스터를 실행했으며, 표준 응답은 데이터를 버리는 것이었습니다. 보관을 90일에서 7일로 자르고, 로그를 10%에서 샘플링하고, 디버그 출력을 완전히 드롭합니다. 그러면, 불가피하게, 사건은 갭에 내려옵니다. 그것을 설명했을 데이터가 비용을 절감하기 위해 버려졌고, 사후 행동 항목은 "로그 보관 증가"라고 읽었습니다. 아무도 자금을 지원하지 않았습니다.

경제학은 변경되었습니다. 로그 저장소를 비싼 로컬 디스크에서 저렴한 객체 저장소 — S3, GCS, Azure Blob으로 이동하는 새로운 도구 세대 때문에. 저장소가 한 자리 수 저비용일 때, 보관은 더 이상 예산 협상이 아닙니다. 이 가이드는 그 변화를 다룹니다. 이전 아키텍처가 비싼 이유, 객체 저장소 모델이 작동하는 방식, 그것을 구현하는 도구 — Quickwit은 검색 가능한 로그 및 트레이스 보관을 위해, OpenObserve는 전체 관찰성 플랫폼으로, Vector는 그것들을 공급하는 파이프라인입니다.

이전 아키텍처가 비싼 이유

Elasticsearch 및 그것 위에 구축된 스택은 요구 사항을 고집스럽게 사용하기 위해 설계되었습니다. 변경되는 데이터에 대한 대화형 전체 텍스트 검색이며, 결과는 밀리초 단위입니다. 전달하기 위해, 그들은 인덱스를 빠른 로컬 디스크에 연결된 항상 실행 중인 노드 에 유지하고, 내구성 및 가용성을 위해 모든 샤드를 복제하고, 메모리에 실질적인 인덱스 구조를 유지합니다. 그들 각각은 검색에 합리적이며, 각각 비싸입니다.

비용은 팀을 놀라게하는 방법으로 복합됩니다. 저장소는 프로비저닝되며, 전체인지 아닌지 디스크에 대해 비용을 지불하고, 실행하는 것이 중단되기 때문에 과도 프로비저닝합니다. 복제는 그것을 2배 또는 3배로 곱합니다. 노드는 그들이 작성된 첫 날 이후 쿼리되지 않는 대부분의 로그에도 불구하고 지속적으로 실행됩니다. 그리고 확장이 결합되어 있습니다. 더 많은 저장소가 필요하면 노드를 추가하는 것을 의미하며, 필요하지 않은 CPU 및 RAM을 지불하는 것입니다. 결과는 보관과 함께 가파르게 상승하는 비용 곡선이며, 정확히 왜 "보관을 줄이기"가 표준 비용 제어 레버가 되었습니다.

더 깊은 불일치는 로그가 Elasticsearch가 최적화된 워크로드가 아니라는 것입니다. 로그 데이터는 추가 전용입니다. 한 번 쓰고, 절대 업데이트되지 않습니다. 압도적으로 추운 것입니다. 대부분은 쿼리되지 않습니다. 그것이 쿼리되는 작은 부분은 사건 중에 쿼리되며, 몇 초의 지연은 완전히 수용 가능합니다. 밀리초 대화형 검색 및 가변 문서 머신을 페타바이트의 추가 전용, 대부분 쿼리되지 않은 데이터에 지불하는 것은 청구서 아래의 건축 오류입니다.

객체 저장소 모델

더 새로운 아키텍처는 이 속성부터 시작합니다. 데이터가 추가 전용이고 대부분 차갑다면 객체 저장소 에 저장하세요. 프로비저닝된 블록 저장소보다 테라바이트당 대략 한 자리 수 저렴하고, 사실상 무한하며, 당신이 복제를 관리하지 않고도 기본적으로 내구합니다. 그런 다음 계산을 저장소에서 분리: 객체 저장소에서 읽는 쿼리 노드를 필요할 때만 실행하고, 보유하는 데이터와 독립적으로 확장합니다. 다른 해의 로그를 저장하는 데 비용이 저장소만이며, 더 이상 노드가 아닙니다.

문제는, 물론, 객체 저장소는 로컬 디스크에 상대적으로 느립니다. 모든 읽기는 의미 있는 지연이 있는 네트워크 요청입니다. 이를 보상할 수 있는 엔지니어링 통찰력은 형식 및 인덱싱입니다. 데이터는 압축된 컬럼 형식 (Parquet은 일반적)으로 작성되며, 쿼리가 실제로 필요한 바이트 범위만 가져올 수 있도록 하는 인덱스 구조와 함께합니다. 스캔하지 않고 모두를 합시다. 적극적인 캐싱은 핫 데이터를 가깝게 유지합니다. 결과는 밀리초가 아닌 초 단위로 반환되는 쿼리입니다. 로그 검색을 위한 완전히 수용 가능한 트레이드오프이며, 사용자 마주 검색 상자에서는 완전히 수용할 수 없으며, 이는 정확히 이 아키텍처가 관찰성에 적합하고 일반 검색에는 적합하지 않은 이유입니다.

무엇이 이것을 구매하는가는 금전적 기억 이상의 것입니다. 보관이 저렴할 때, 데이터를 예방적으로 버리는 것을 중단합니다. 이는 다음 사건에 대한 답변이 여전히 존재할 가능성이 더 크다는 것을 의미합니다. 이것이 진정한 보상입니다. 더 작은 송장이 아니라, 삭제된 데이터 때문에 행き止まり인 적은 조사입니다.

Quickwit: 로그 및 트레이스를 위해 구축된 검색

Quickwit은 아이디어의 가장 순수한 표현입니다. 객체 저장소의 추가 전용 데이터를 위해 처음부터 설계된 Rust 검색 엔진입니다. 인덱스를 위한 로컬 디스크가 필요 없으며, 그들을 위한 클러스터 상태 머신이 필요 없으므로, 인덱스는 S3에 불변 split 으로 존재합니다. 진정한 전체 텍스트 검색을 제공하고 (단순히 라벨 필터링이 아님), Elasticsearch 호환 검색 API를 노출하여 마이그레이션을 완화하며, 기본 Jaeger 백엔드 로서 트레이스를 제공합니다. 이미 OpenTelemetry를 실행하는 팀에 자연스러운 적합입니다.

Quickwit의 달콤한 자리는 실제 검색 기능이 있는 로그 및 트레이스에 대해 저렴하고, 검색 가능하고, 장기 보관 저장입니다. 보관 관리는 사소합니다. 오래된 데이터를 만료하는 것은 단지 오래된 split을 삭제합니다. 그것의 트레이드오프는 범위입니다. 그것은 검색 엔진이지, 완전한 관찰성 플랫폼이 아니므로, 대시보드 (Grafana), 자신의 경고 및 자신의 메트릭 스택을 가져옵니다. 이미 이 부분들을 가지고 있고 저장소 비용을 구체적으로 수정하고 싶은 팀을 위해, 이 포커스는 기능입니다.

OpenObserve: 배터리 포함 플랫폼

OpenObserve는 동일한 저장소 통찰력을 취하고 그 주위에 전체 플랫폼을 래핑합니다. 하나의 시스템에서 로그, 메트릭, 트레이스 를 처리하고, 객체 저장소에서 압축된 Parquet로 데이터를 저장하고, 내장 UI, SQL 쿼리, 대시보드, 경고 엔진이 있는 단일 Rust 바이너리로 제공합니다. 모두. 기본적으로 OpenTelemetry를 수집하고 Prometheus 원격 쓰기를 지원하므로 기존 계측에 적합합니다.

호소력은 통합입니다. 검색 엔진 + Grafana + 경고 스택 + 별도 메트릭 저장소를 실행하는 대신, 당신은 하나를 실행합니다. 특히 작은 및 중간 팀의 경우, 운영 절감이 테라바이트당 비교보다 더 중요할 수 있습니다. 관찰성 스택의 모든 추가 구성요소는 업그레이드, 보안, 오전 3시에 디버그할 항목입니다. 그것의 트레이드오프는 통합 플랫폼의 일반적인 것입니다. Grafana 또는 Elastic 세계보다 모듈화보다 덜 유연하고 더 젊은 생태계. 운영 단순함이 모듈화보다 중요할 때 선택하세요.

Vector: 마이그레이션을 안전하게 만드는 파이프라인

어떤 백엔드도 그것에 데이터를 넣을 수 없으면 중요하지 않으며, 이것이 Vector가 조용한 추축이 되는 곳입니다. Vector는 고성능, 공급 업체 무관 파이프라인입니다. 모든 소스 에서 로그, 메트릭, 트레이스를 수집하고, VRL로 작성된 변환 을 통해 재형성한 후 모든 싱크 로 전달합니다. Rust로 작성되면, Logstash 또는 Fluentd 일부의 리소스를 사용합니다. 모든 노드에서 에이전트가 실행되기 때문에 중요합니다.

그것의 전략 가치는 당신의 계측을 당신의 백엔드에서 분리한다는 것입니다. 애플리케이션 및 에이전트는 데이터를 Vector로 전송합니다. Vector는 그것이 어디로 가는지 결정합니다. 이는 백엔드 마이그레이션을 전체 재계측 프로젝트에서 구성 변경으로 변합니다. 그리고 중요한 것으로, 그것은 당신이 이중 쓰기 를 할 수 있게 합니다. 전환 중, 동일한 데이터를 기존 스택과 새로운 것 모두로 전송하여 새로운 것을 실제 트래픽에서 유효성 검사할 수 있습니다. 잘라내기 전에. Vector의 변환도 소스에서 비용을 절감합니다. 디버그 로그 삭제, 높은 볼륨 이벤트 샘플링, 저장소 전에 PII 수정은 모두 당신이 유지할 것을 줄입니다. 백엔드를 변경할 의도가 없는 팀도 종종 양만해도 비용을 지불합니다.

위험한 마이그레이션 없이 채용

현명한 경로는 증분이며, Vector는 그것을 안전하게 만듭니다. 기존 스택 앞에 파이프라인을 두십시오. Vector를 배포하고, 소스를 지정하고, 현재 무엇을 실행하도록 앞에 두십시오. 기능적으로 아무것도 변경되지 않지만, 당신은 제어 포인트를 얻었습니다. 그리고 당신은 즉시 변환을 사용하여 노이즈를 드롭하고 현재 비용을 절감할 수 있습니다.

그런 다음 후보 백엔드로 이중 쓰기합니다. Quickwit 또는 OpenObserve를 지정하는 두 번째 싱크를 추가하고 실제 프로덕션 데이터를 모두에게 흐르게 합니다. 이제 당신은 정직하게 평가할 수 있습니다. 당신이 실제로 실행하는 쿼리가 충분히 빠릅니까? 검색 구문이 당신의 필요를 다룹니까? 저장소가 실제로 당신의 볼륨에서 비용이 얼마나 듭니까? 이것은 벤치마크보다 훨씬 낫고, 시도 중에만 새 백엔드의 저장소에서만 비용이 듭니다.

핫 쿼리 전에 보관을 이동하십시오. 낮은 위험 중간 상태는 짧은 보관 핫 데이터가 그것이 있는 곳에 있는 동안 장기 보관 데이터를 객체 저장소로 전송하는 것입니다. 비용 절감을 얻습니다. 이벤트 응답을 알려지지 않은 시스템에 베팅하지 않고 큰 보관이 있는 부분 (비싼 부분)을 합니다. 그런 다음 점진적으로 쿼리를 이동합니다. 긴급하지 않은 분석부터 시작하여 사건 응답으로 이동하십시오. 그리고 당신이 팀이 그것을 신뢰할 때까지 이전 스택을 실행하십시오. 할 수 있는 새로운 것을 발견할 때는 당신이 가장 회전목마를 원하지 않는 순간입니다.

당신이 주는 것, 정직하게

모든 아키텍처는 뭔가를 트레이드하며, 결정이 열정적이 아니라 정보가 있도록 객체 저장소로 이동하는 비용을 명시적인 것은 가치가 있습니다.

쿼리 지연. 객체 저장소의 읽기는 네트워크 요청이므로, 쿼리는 따뜻한 로컬 디스크 인덱스가 제공할 수 있는 1초 미만의 응답이 아닌 초 단위로 반환됩니다. 사건 중 로그 검색의 경우 이것은 진정으로 괜찮습니다. 당신은 결과를 읽습니다. 당신이 앞서 타이핑하지 않습니다. 그러나 즉각적인 대화형 필터링을 의존하는 워크플로우를 구축했거나, 모든 새로 고침이 수십 개의 쿼리를 발사하는 대시보드가 있다면, 그들은 느려질 것 같습니다. 당신의 실제 쿼리 패턴을 합성 벤치마크가 아니라 테스트하십시오.

생태계 성숙도. Elasticsearch는 축적된 통합, 자습서, Stack Overflow 답변, 규모에서 그것을 실행한 엔지니어의 십년을 가집니다. 더 새로운 도구는 더 작은 커뮤니티, 엣지 경우를 위한 더 얇은 문서, 많은 사람이 당신은 고용할 수 없습니다. 이상한 시간에 무언가가 깨질 때, 그 차이는 실질적입니다. Elasticsearch 호환 API는 마이그레이션을 완화하지만 지식 갭을 제거하지 않습니다.

기능 표면. Elasticsearch는 로그 검색 이상을 합니다. 복잡한 집계, 기계 학습 작업, 관련성 조정, 풍부한 쿼리 DSL. 목적 구축 로그 엔진은 의도적으로 덜 합니다. 당신이 이 기능을 신뢰한다면, 약속 전에 동등한 것이 존재하는지 검증하세요. 마이그레이션 중간에 갭을 발견하는 것보다.

운영 무익함. 당신의 실행장, 경고, 직관은 현재 스택에 보정됩니다. 새 백엔드는 새로운 실패 모드와 팀이 느린 시간입니다. 진단. 이것이 이중 쓰기 접근 방법과 이전 스택을 최소한 하나의 실제 사건을 통해 실행하는 것이 가장 강력한 주장입니다. 당신이 여전히 대체품을 가질 때 학습 곡선을 원합니다.

아무도 이 사람들이 대부분의 팀, 특히 현재 삭제하고 있는 데이터의 이유인 절감 한 자리 수를 능가합니다. 그러나 그들이 신중하게 모두 한 번에 마이그레이션하는 대신 신중하게 마이그레이션하는 이유입니다.

요점

관찰성은 도구화가 마침내 워크로드와 일치했기 때문에 극적으로 저렴해졌습니다. 로그는 추가 전용이고 대부분 추운 것이므로, 변경 가능한 밀리초 검색에 최적화된 복제, 항상 켜진 로컬 디스크에 저장하는 것은 데이터가 필요하지 않은 속성에 대한 큰 프리미엄을 지불했습니다. 객체 저장소로 이동하여 몇 밀리초로 트레이드합니다. — 로그 검색을 위해 무관함 — 및 저장소 비용을 한 자리 수로 절감합니다. Quickwit은 Jaeger 백엔드가 있는 집중적인, 검색 가능한 로그 및 트레이스 저장소로 전달합니다. OpenObserve는 내장 UI, 대시보드, 경고가 있는 통합 플랫폼으로 전달합니다. Vector는 계측을 분리하는 파이프라인으로 이것 둘 중 하나에서, 마이그레이션을 구성 변경과 이중 쓰기로 만듭니다. 파이프라인을 먼저 두고, 실제 트래픽에서 평가하도록 이중 쓰기하고, 핫 쿼리 전에 장기 보관을 이동하고, 당신이 당신의 사건을 설명하는 데이터를 삭제하는 것을 멈추십시오.

참고 자료 및 리소스

도구

배경 및 분석

관련 1337skills 치트시트