aws·2025년 12월 2일원문

Amazon RDS for SQL Server 및 (새 탭에서 열림)

AWS는 Amazon RDS for Oracle 및 SQL Server 사용자를 위해 비용 효율성과 확장성을 극대화할 수 있는 네 가지 신규 기능을 발표했습니다. 이번 업데이트에는 비프로덕션 환경을 위한 SQL Server Developer Edition 지원, CPU 최적화가 가능한 최신 M7i/R7i 인스턴스 도입, 그리고 최대 128TiB까지 확장된 스토리지 용량이 포함되었습니다. 이를 통해 기업은 개발부터 운영 단계까지 데이터베이스 라이선스 및 인프라 비용을 대폭 절감하면서도 성능 요구 사항에 맞춰 유연하게 자원을 관리할 수 있게 되었습니다. **비프로덕션 환경을 위한 SQL Server Developer Edition 지원** * 개발 및 테스트 워크로드에서 Enterprise Edition의 모든 기능을 라이선스 비용 없이 무료로 사용할 수 있는 SQL Server Developer Edition이 RDS에 추가되었습니다. * 사용자는 Amazon S3에 SQL Server 바이너리 파일을 업로드하여 인스턴스를 생성할 수 있으며, 기존 데이터를 백업 및 복원 방식으로 간편하게 마이그레이션할 수 있습니다. * 자동 백업, 소프트웨어 업데이트, 모니터링 등 RDS의 관리형 기능을 그대로 활용하면서 비프로덕션 환경의 운영 비용을 효과적으로 줄일 수 있습니다. **M7i 및 R7i 인스턴스 도입과 CPU 최적화** * RDS for SQL Server에서 M7i 및 R7i 인스턴스를 지원하여 이전 세대 인스턴스 대비 최대 55%의 비용 절감 효과를 제공합니다. * 인스턴스 비용과 라이선스 비용을 분리하여 청구함으로써 비용 구조의 투명성을 높였으며, 최신 사양의 컴퓨팅 성능을 보다 저렴하게 이용할 수 있습니다. * 'CPU 최적화(Optimize CPU)' 기능을 통해 메모리와 스토리지 용량은 유지하면서 필요한 vCPU 수만 활성화함으로써, 코어 기반 라이선스 비용을 최적화할 수 있습니다. **스토리지 용량 및 성능 확장** * RDS for Oracle 및 SQL Server의 최대 스토리지 용량이 기존 64TiB에서 128TiB로 두 배 확장되었습니다. * io2 Block Express 볼륨을 지원하여 대규모 엔터프라이즈 데이터베이스 운영에 필수적인 고성능 IOPS와 고용량을 동시에 확보할 수 있습니다. * 확장된 스토리지 한도와 유연한 확장 옵션을 통해 급증하는 데이터 규모에도 인프라 재설계 없이 안정적으로 대응이 가능합니다. 비용 절감이 시급한 프로젝트라면 개발 및 테스트 환경을 즉시 SQL Server Developer Edition으로 전환하여 라이선스 비용을 제거하는 것이 좋습니다. 또한, 라이선스 비용 부담이 큰 고사양 데이터베이스의 경우 M7i/R7i 인스턴스로 전환하고 CPU 최적화 기능을 적용하여 성능과 비용의 균형을 맞추는 전략을 권장합니다.

amazon-s3amazon-rdscost-optimizationcloud-databases+3

aws·2025년 12월 2일원문

Amazon CloudWatch, 운영, (새 탭에서 열림)

Amazon CloudWatch가 운영, 보안 및 규정 준수 데이터를 통합 관리하고 분석할 수 있는 새로운 기능을 도입했습니다. 이 업데이트를 통해 데이터 중복과 비용을 줄이면서 여러 소스의 로그를 자동으로 정규화하고, Apache Iceberg 호환 형식을 통해 외부 분석 도구와의 연동성을 극대화했습니다. 이제 사용자는 복잡한 파이프라인 없이도 통합된 환경에서 운영 지표와 비즈니스 데이터를 실시간으로 상관 분석하여 심도 있는 인사이트를 얻을 수 있습니다. **데이터 수집 및 정규화의 간소화** * AWS Organizations와 통합되어 CloudTrail, VPC Flow Logs, AWS WAF, Route 53 리졸버 로그 등 여러 리전 및 계정의 AWS 로그를 자동으로 수집합니다. * CrowdStrike, Okta, SentinelOne, GitHub 등 타사 보안 및 생산성 도구의 로그를 수집할 수 있는 사전 구축된 커넥터를 제공합니다. * OCSF(Open Cybersecurity Schema Framework) 및 OTel(Open Telemetry) 형식을 기본 지원하여 데이터 일관성을 확보하며, Grok 프로세서를 통해 커스텀 파싱과 필드 연산을 수행할 수 있습니다. **Iceberg 호환성을 통한 데이터 개방성 및 비용 절감** * Amazon S3 Tables를 통해 Apache Iceberg 호환 형식으로 로그 데이터에 접근할 수 있는 기능을 도입했습니다. * CloudWatch 내부뿐만 아니라 Amazon Athena, Amazon SageMaker Unified Studio 등 Iceberg를 지원하는 모든 외부 도구에서 별도의 데이터 복제 없이 직접 분석이 가능합니다. * 통합 데이터 저장소 구조를 채택함으로써 여러 도구에 동일한 데이터를 중복 저장할 필요가 없으며, 복잡한 ETL 파이프라인 유지보수에 드는 운영 오버헤드를 줄였습니다. **강력한 로그 분석 및 시각화 도구** * 자연어 기반 쿼리를 비롯해 LogsQL, PPL, SQL 등 다양한 쿼리 언어를 단일 인터페이스에서 사용할 수 있습니다. * 새로운 'Facets' 인터페이스를 통해 소스, 애플리케이션, 계정, 리전 및 로그 유형별로 직관적인 필터링이 가능합니다. * 지능형 파라미터 추론 기능을 지원하여 여러 AWS 계정과 리전에 걸친 방대한 로그 그룹에 대해 효율적인 교차 쿼리를 실행할 수 있습니다. **실용적인 권장사항** 운영 로그와 보안 로그가 서로 다른 도구에 분산되어 있어 상관 분석에 어려움을 겪거나, 로그 분석을 위해 복잡한 ETL 프로세스를 운영 중인 조직에 이 기능을 적극 추천합니다. 특히 CloudWatch의 통합 관리 뷰를 통해 전체 데이터 소스를 한눈에 파악하고, OCSF 정규화 기능을 활용하여 보안 분석의 표준화를 시작하는 것이 좋습니다.

amazon-s3로그 관리apache-icebergdata-analytics+4

aws·2025년 12월 2일원문

확장성과 성능이 향상 (새 탭에서 열림)

Amazon S3 Vectors가 정식 출시(GA)되어 클라우드 객체 스토리지에서 기본적으로 벡터 데이터를 저장하고 검색할 수 있는 길이 열렸습니다. 기존 전용 벡터 데이터베이스 대비 비용을 최대 90% 절감할 수 있으며, 서버리스 아키텍처를 통해 인프라 관리 부담 없이 대규모 AI 애플리케이션을 구축할 수 있습니다. 이번 정식 버전은 프리뷰 대비 확장성과 성능이 대폭 강화되어, 대규모 RAG(검색 증강 생성) 및 AI 에이전트 워크로드를 안정적으로 지원합니다. **비약적인 확장성 및 성능 향상** * **인덱스 규모 확장:** 단일 인덱스에서 최대 20억 개의 벡터를 지원하며, 벡터 버킷당 총 20조 개의 벡터를 저장할 수 있어 프리뷰 대비 확장성이 40배 향상되었습니다. * **검색 속도 최적화:** 빈번한 쿼리의 경우 응답 속도를 100ms 이하로 단축했으며, 간헐적인 쿼리도 1초 미만의 지연 시간을 유지하여 실시간 대화형 AI에 적합합니다. * **검색 결과 확대:** 쿼리당 반환 가능한 검색 결과 수를 기존 30개에서 100개로 늘려 RAG 애플리케이션에 더 풍부한 컨텍스트를 제공합니다. * **쓰기 처리량 강화:** 초당 최대 1,000건의 PUT 트랜잭션을 지원하여 실시간 데이터 스트리밍 및 대량의 동시 쓰기 작업을 원활하게 처리합니다. **서버리스 아키텍처를 통한 운영 및 비용 효율화** * **완전 관리형 서비스:** 별도의 인프라 설정이나 프로비저닝이 필요 없는 서버리스 구조로, 사용한 만큼만 비용을 지불하는 종량제 모델을 채택했습니다. * **비용 절감:** 전용 벡터 데이터베이스 솔루션과 비교했을 때 벡터 저장 및 쿼리 비용을 최대 90%까지 낮출 수 있어 경제적입니다. * **개발 수명 주기 지원:** 초기 프로토타이핑부터 대규모 프로덕션 배포까지 동일한 스토리지 환경에서 유연하게 대응할 수 있습니다. **에코시스템 통합 및 가용성 확대** * **Amazon Bedrock 연동:** Amazon Bedrock 지식 기반(Knowledge Base)의 벡터 스토리지 엔진으로 정식 지원되어 고성능 RAG 어플리케이션 구축이 용이해졌습니다. * **Amazon OpenSearch 통합:** S3 Vectors를 스토리지 계층으로 사용하면서 OpenSearch의 강력한 검색 및 분석 기능을 결합하여 사용할 수 있습니다. * **지역 확장:** 프리뷰 당시 5개였던 지원 리전을 서울을 포함한 전 세계 14개 AWS 리전으로 확대하여 접근성을 높였습니다. 전용 벡터 DB 도입에 따른 비용과 운영 복잡성이 부담스러웠던 기업이라면, S3의 높은 가용성과 보안을 그대로 누리면서 대규모 벡터 검색을 구현할 수 있는 S3 Vectors 도입을 적극 검토해 보시기 바랍니다. 특히 Amazon Bedrock과의 유연한 통합을 통해 생산성 높은 AI 서비스를 빠르게 시장에 출시할 수 있습니다.

amazon-s3AIamazon-bedrockRAG+4

figma·2025년 5월 28일원문

며칠의 지연 시간에서 실 (새 탭에서 열림)

피그마(Figma)는 급격한 사용자 증가와 데이터 볼륨 확대에 대응하기 위해 기존의 배치 기반 동기화 시스템을 실시간 증분 동기화(Incremental Synchronization) 파이프라인으로 전면 재구축했습니다. 과거 수일이 소요되던 데이터 동기화 지연 시간을 근실시간(Near Real-time) 수준으로 단축함으로써 데이터 분석의 신속성과 정확성을 확보했습니다. 이 과정에서 상용 솔루션 대신 자체 인프라에 최적화된 기술 스택을 선택하여 비용 절감과 확장성이라는 두 마리 토끼를 잡는 데 성공했습니다. **기존 배치 동기화 방식의 한계와 비용 문제** * 2020년에 설계된 초기 시스템은 매일 전체 테이블을 `SELECT *` 쿼리로 조회하여 S3에 업로드하고 Snowflake로 가져오는 단순한 구조였습니다. * 데이터 규모가 커짐에 따라 동기화 작업이 6시간에서 길게는 수일까지 지연되었으며, 이를 처리하기 위해 고가의 데이터베이스 복제본을 유지하는 데 매년 수백만 달러의 비용이 발생했습니다. * 동기화 지연은 전사 KPI 분석 및 비즈니스 의사결정을 방해하는 핵심 병목 구간이 되었습니다. **상용 솔루션 대신 자체 구축을 선택한 이유** * **유연성:** Amazon RDS와 같은 특정 클라우드 벤더의 API를 활용해 복제본 유지 관리 오버헤드 없이 직접 스냅샷을 생성하는 등 인프라 최적화가 필요했습니다. * **비용 효율성:** 대규모 데이터 환경에서 상용 솔루션을 사용할 경우 자체 구축 대비 약 5~10배 이상의 비용이 발생할 것으로 예상되었습니다. * **확장성:** 피그마의 지속적인 성장에 맞춰 빠르게 혁신하고 제어할 수 있는 맞춤형 파이프라인이 필요했습니다. **증분 동기화를 위한 기술적 아키텍처** * **스냅샷 및 데이터 적재:** Amazon RDS의 스냅샷 내보내기 기능을 사용해 S3로 초기 데이터를 복사하고, Snowflake의 `COPY INTO` 문을 통해 베이스 테이블에 로드합니다. * **CDC(Change Data Capture) 스트리밍:** Kafka Connect를 활용해 Postgres의 변경 로그를 실시간으로 캡처하고, Amazon MSK를 거쳐 Snowflake의 CDC 테이블로 스트리밍합니다. * **증분 병합(Merge):** Snowflake의 저장 프로시저(Stored Procedure)와 태스크(Task) 기능을 이용해 베이스 테이블과 CDC 데이터를 주기적으로 병합하는 맞춤형 `MERGE` 로직을 구현했습니다. **데이터 무결성을 위한 워크플로우 설계** * **부트스트랩(Bootstrap):** 새로운 테이블을 파이프라인에 추가할 때 스키마 진화에 대응할 수 있도록 아티팩트를 버전화하고, 원자적 뷰(View) 업데이트를 통해 서비스 중단 없는 전환을 지원합니다. * **검증(Validation):** 부분적 실패, 설정 오류, 소스 데이터의 이상 현상으로 인한 데이터 부패를 방지하기 위해 파이프라인 전 과정에서 데이터의 정확성과 일관성을 검증하는 프로세스를 통합했습니다. 데이터 파이프라인의 성능 한계에 직면한 조직은 단순히 컴퓨팅 파워를 늘리기보다, 전체 데이터를 옮기지 않는 '증분 동기화'와 자사 환경에 최적화된 CDC 기술 스택을 도입함으로써 비용과 성능 문제를 근본적으로 해결할 수 있습니다. 특히 대규모 환경에서는 벤더 종속성을 탈피한 자체 아키텍처 설계가 장기적인 확장성 면에서 더 유리할 수 있습니다.

amazon-s3PostgreSQLApache Kafkadata-pipeline+4

coupang·2024년 11월 15일원문

클라우드 서비스 사용량 관리를 통한 운영 비용 최적화 (새 탭에서 열림)

쿠팡은 파이낸스 및 엔지니어링 팀의 긴밀한 협력을 통해 클라우드 온디맨드 비용을 최적화하고 재정적 책임을 강화하는 운영 모델을 구축했습니다. 'Hate Waste'라는 리더십 원칙에 따라 데이터 기반의 분석 도구를 도입하고 리소스 사용량을 효율적으로 통제함으로써, 서비스의 신뢰성을 유지하면서도 연간 수백만 달러 이상의 운영 비용을 절감하는 성과를 거두었습니다. **최적화 전담 팀 구성과 데이터 기반 의사결정 체계 구축** * 클라우드 인프라 엔지니어와 TPM(Technical Program Manager)을 중심으로 전담 프로젝트 팀을 구성하여 각 도메인 팀이 클라우드의 가변 비용 모델을 깊이 이해하도록 지원했습니다. * Amazon Athena를 통해 처리된 CloudWatch 데이터와 AWS CUR(Cost & Usage Reports)을 활용하여 실시간 비용 및 사용량을 분석할 수 있는 맞춤형 BI 대시보드를 개발했습니다. * 파이낸스 팀과의 협업을 통해 월별·분기별 예산 준수의 중요성을 강조하고, 각 팀이 주도적으로 리소스를 관리하는 엔지니어링 문화를 정착시켰습니다. **리소스 효율화와 기술적 최적화를 통한 실질적 비용 절감** * **사용량 절감(Use Less):** 비-프로덕션(Non-prod) 환경에서 리소스가 필요할 때만 자동으로 시작되도록 설정하여 해당 환경의 운영 비용을 약 25% 절감했습니다. * **비용 최적화(Pay Less):** 사용량 패턴을 분석하여 방치된 EC2 리소스를 수동으로 제거하고, 인스턴스를 최신 세대로 조정하여 성능 향상과 가용성 확보를 동시에 달성했습니다. * **기술적 수단 활용:** Amazon S3 스토리지 구조를 최적화하고, AWS Spot Instances 및 ARM 기반의 AWS Graviton 인스턴스를 도입하여 데이터 처리 및 저장 비용을 획기적으로 낮추었습니다. 클라우드 비용 관리는 단순히 지출을 줄이는 작업을 넘어, 인프라를 얼마나 더 똑똑하고 효율적으로 활용하느냐에 대한 기술적 성숙도를 의미합니다. 조직 전체가 비용에 대한 주인의식을 갖고 데이터를 바탕으로 리소스를 관리할 때, 비즈니스의 성장과 인프라의 지속 가능성을 동시에 확보할 수 있습니다.

amazon-s3AWSamazon-ec2finops+3

coupang·2024년 11월 14일원문

비용 효율성을 위한 클라우 (새 탭에서 열림)

쿠팡은 재무와 엔지니어링 팀 간의 긴밀한 협력을 통해 클라우드 지출을 최적화하고 재무적 책임감을 강화하는 전략적 로드맵을 실행했습니다. 이를 위해 구성된 중앙 관리 팀(Central team)은 '낭비 지양(Hate Waste)'이라는 기업 원칙 아래 데이터 기반의 분석 도구와 가변 비용 모델을 도입하여 전사적인 비용 관리 문화를 정착시켰습니다. 결과적으로 비즈니스 성장을 저해하지 않으면서도 리소스 사용 효율을 극대화하여 수백만 달러 규모의 온디맨드 비용을 절감하는 성과를 거두었습니다. ### 중앙 관리 팀 조직과 분석 체계 구축 * 인프라 엔지니어와 기술 프로그램 매니저(TPM)로 구성된 중앙 팀을 조직하여 각 도메인 팀이 클라우드 효율성을 스스로 관리할 수 있도록 지원했습니다. * Amazon CloudWatch, Amazon Athena, 그리고 AWS CUR(비용 및 사용 보고서) 데이터를 활용한 맞춤형 대시보드를 구축하여 실시간으로 비용을 모니터링하고 데이터에 기반한 의사결정을 내릴 수 있는 환경을 마련했습니다. * 재무 팀과의 파트너십을 통해 각 도메인 팀이 할당된 월간 및 분기별 예산을 준수하도록 관리하는 거버넌스 체계를 확립했습니다. ### 지출 감소 및 단가 최적화 전략 (Spend Less & Pay Less) * **지출 감소(Spend Less):** 비운영 환경(Non-production)에서 리소스가 필요할 때만 자동으로 실행되도록 자동화 프로세스를 도입하여, 해당 환경의 비용을 약 25% 절감했습니다. * **단가 최적화(Pay Less):** 사용 패턴 분석을 통해 사용되지 않거나 효율이 낮은 EC2 리소스를 수동으로 제거하고, 워크로드에 맞는 적정 사양으로 조정(Rightsizing)했습니다. * **인프라 현대화:** 기존 인스턴스를 최신 세대로 전환하고, x86 대비 가성비가 뛰어난 ARM 기반의 AWS Graviton 인스턴스 도입을 확대하여 처리 성능은 높이고 비용은 낮추었습니다. ### 기술적 세부 최적화 실행 * **데이터 처리 및 저장:** Amazon S3의 저장 구조를 최적화하고 스토리지 계층화(Tiering)를 적용하여 데이터 보관 비용을 효율화했습니다. * **빅데이터 워크로드:** EMR(Elastic MapReduce) 환경에서 Spot 인스턴스 활용도를 높여 데이터 분석 및 처리 비용을 획기적으로 줄였습니다. * **문화적 확산:** 엔지니어들이 클라우드 비용을 단순한 지출이 아닌 관리해야 할 리소스로 인식하도록 교육하고, 기술적 최적화가 비즈니스 가치로 이어지는 선순환 구조를 만들었습니다. 성공적인 클라우드 비용 최적화를 위해서는 단순히 리소스를 삭제하는 것을 넘어, 엔지니어링 팀과 재무 팀이 공통의 목표를 공유하는 것이 중요합니다. 특히 데이터 분석을 통해 가시성을 확보하고, Graviton 인스턴스나 Spot 인스턴스 같은 클라우드 고유의 가변 비용 모델을 적극적으로 활용할 것을 권장합니다.

amazon-s3AWSfinopsamazon-athena+4

figma·2020년 7월 20일·3분 읽기큐레이션 요약

딥 서치 심층 분석 | 피

Figma의 Deep Search는 파일명이나 폴더명을 몰라도 파일 내부의 텍스트와 내용을 검색할 수 있도록 만든 기능이다. 일반 검색이 데이터베이스의 메타데이터를 색인하는 것과 달리, Deep Search는 S3에 저장된 `.fig` 파일을 직접 읽고 객체 트리를 순회해야 한다. 이를 위해 기존 Design System Analytics 인프라를 확장하고, 처리 비용과 최신성 사이에서 타협해 변경 사항을 시간 단위로 모아 색인하는 방식을 선택했다. ## 브라우저 기반 제품이 제공하는 검색 가능성 - Figma는 데스크톱 애플리케이션이 아닌 브라우저 기반 도구이므로, 사용자가 접근할 수 있는 파일에 대한 풍부한 정보를 수집하고 분석할 수 있다. - 파일의 조회 빈도, 컴포넌트 사용량, 파일 구조 등 웹 환경에 적합한 데이터를 활용할 수 있다. - 이러한 특성은 협업을 강화한다. - 별도 파일을 내보내지 않아도 이해관계자가 진행 중인 작업을 확인할 수 있다. - 프로토타입 공유와 핸드오프가 간소화된다. - 작업 중인 결과물을 쉽게 공유할 수 있다. - Deep Search는 파일명보다 프로젝트의 아이디어, 문구, 해결하려던 문제를 기억하는 사용자의 검색 방식에 맞춘 기능으로 기획됐다. ## Design System Analytics에서 얻은 기술적 기반 - Figma는 앞서 Design System Analytics(DSA)를 출시해 팀 간 디자인 시스템과 공유 라이브러리의 사용 현황을 분석했다. - DSA와 Deep Search 모두 다음과 같은 공통 처리가 필요했다. - 최근 수정된 파일을 식별한다. - 스토리지에서 파일을 내려받는다. - 파일 내부를 순회한다. - 목적에 맞는 정보를 추출한다. - DSA는 공유 라이브러리 사용량을 추출하고, Deep Search는 파일 내부의 텍스트를 추출한다. - Figma는 DSA를 위해 만든 파일 분석 인프라와 워커를 일반화해 Deep Search의 기반으로 활용했다. ## 일반 검색의 색인 파이프라인 - 기존 Unified Search를 포함한 일반 검색은 데이터베이스에 저장된 메타데이터를 대상으로 한다. - 예시로 파일 ID, 폴더 ID, 팀 ID, 파일명, 폴더명, 생성자 등의 정보를 사용한다. - 처리 과정은 다음과 같다. - 데이터베이스의 관련 테이블 변경 사항을 감시한다. - 변경된 항목의 ID를 메시징 시스템으로 전달한다. - 검색 색인기가 최신 데이터를 데이터베이스에서 가져온다. - 가져온 메타데이터를 Elasticsearch 클러스터에 색인한다. - 데이터베이스 조회는 비교적 저렴하기 때문에 변경될 때마다 빠르게 색인을 갱신할 수 있다. ## Deep Search가 더 복잡한 이유 - Figma 파일의 실제 표현은 데이터베이스가 아니라 Amazon S3에 저장된 `.fig` 문서다. - `.fig` 파일은 트리 구조로 구성된다. - 각 노드는 타원, 프레임, 벡터, 텍스트 같은 Figma 객체를 나타낸다. - 노드에는 객체의 속성과 콘텐츠가 함께 저장된다. - Deep Search는 파일의 메타데이터만 확인하는 것이 아니라, S3에서 파일을 가져온 뒤 전체 객체 트리를 순회해야 한다. - 하나의 파일에 수천 개의 노드가 있을 수 있어 파일을 읽고 분석하는 작업은 일반적인 데이터베이스 조회보다 훨씬 계산 비용이 크다. ## 처리 비용과 검색 최신성 사이의 타협 - Figma 파일은 편집 중에도 약 30초마다 자동 저장될 수 있다. - 저장될 때마다 Deep Search 색인을 갱신하면 같은 파일을 반복적으로 내려받고 분석하게 되어 서버 비용이 크게 증가한다. - Figma는 이를 해결하기 위해 파일 변경 사항을 한 시간 동안 중복 제거한다. - 이후 변경된 파일을 파일 분석 워커로 보내 주기적으로 처리한다. - 그 결과 Deep Search 결과가 일반 검색보다 잠시 오래된 상태일 수 있지만, 반복적인 파일 분석을 줄여 상당한 서버 자원을 절약할 수 있다. - 이는 검색 결과의 즉시성보다 시스템 비용과 확장성을 우선한 제품·인프라상의 결정이다. ## 실용적인 결론 대용량 문서나 복잡한 구조를 검색할 때는 모든 변경을 즉시 처리하기보다 변경 사항을 모아 중복 작업을 제거하는 방식이 효율적이다. 검색 결과가 수초 또는 수분 정도 지연되어도 괜찮다면, 배치 처리와 주기적 색인을 통해 계산 비용과 인프라 부담을 크게 줄일 수 있다.

원문 읽기(새 탭에서 열림)

amazon-s3분산 시스템data-pipelineelasticsearch+2