slack·2026년 7월 14일·5분 읽기큐레이션 요약

Shipyard: Slack의 차세대 EC2 플랫폼을 구축한 방법

Slack은 장기 실행 EC2 인스턴스를 지속적으로 수정하는 기존 운영 방식의 한계를 해결하기 위해 차세대 EC2 플랫폼인 Shipyard를 구축했다. Shipyard는 EC2를 계속 변경되는 서버가 아니라 빌드·배포 가능한 불변 아티팩트로 다루며, 점진적 배포와 메트릭 기반 자동 중단·롤백을 지원한다. 이를 통해 컨테이너로 전환하기 어려운 워크로드에도 현대적인 배포 안정성과 예측 가능성을 제공한다. ## 기존 EC2 운영 방식의 한계 - Chef 기반으로 장기간 실행되는 인스턴스를 계속 업데이트하는 방식은 다음 문제를 낳았다. - 서비스 단위 배포가 복잡함 - 인프라 드리프트가 시간이 지날수록 누적됨 - 여러 계층의 변경 사항을 조율해야 함 - 수동 변경과 자동 설정 적용이 충돌할 수 있음 - Slack은 기존 Chef 환경을 다중 스택, 버전 관리, 분리된 프로덕션 환경, 신호 기반 실행 등으로 개선했지만 근본적인 구조적 한계는 남아 있었다. - 컨테이너가 일부 문제를 해결했지만 인프라 컴포넌트, Kubernetes 워커 노드, egress 네트워크 스택 등은 쉽게 컨테이너화하기 어려웠다. ## Shipyard의 핵심 방향 - 인스턴스를 지속적으로 수정하는 대신 이미지와 배포 산출물을 중심으로 운영한다. - 서비스 단위 배포 기능을 제공해 애플리케이션 배포와 유사한 방식으로 EC2 인프라를 관리한다. - 빌드 파이프라인, 배포 오케스트레이션, 자동 안전 장치를 긴밀하게 연동한다. - 인프라 변경을 불변성, 점진적 롤아웃, 자동화된 안전 검증을 갖춘 배포 과정으로 전환한다. ## 멀티 아키텍처와 멀티 운영체제 - AMD64와 ARM 기반 AWS Graviton 인스턴스를 모두 지원한다. - Ubuntu, RHEL, Amazon Linux 등 여러 운영체제를 사용할 수 있다. - 비용, 성능, 호환성에 따라 서비스별 실행 환경을 선택할 수 있다. - 컨테이너 전환이 어려운 다양한 EC2 워크로드를 동일한 플랫폼에서 운영할 수 있다. ## 메트릭 기반 점진적 배포 - Shipyard는 Slack의 배포 오케스트레이션 시스템인 Gondola와 통합된다. - 배포 과정에서 서비스 상태 지표를 기반으로 자동 안전 검사를 수행한다. - 오류율, 성능 저하 등 서비스 헬스 신호가 나빠지면 배포를 자동으로 중단할 수 있다. - 문제가 발생하면 이전의 정상 버전으로 자동 롤백할 수 있다. - 따라서 배포 실패의 영향 범위를 줄이고, 운영자의 수동 판단 의존도를 낮춘다. ## 계층형 이미지와 빠른 프로비저닝 - 컨테이너 이미지와 유사한 계층형 이미지 구조를 사용한다. - 공통 인프라 요소를 포함한 골든 베이스 이미지를 먼저 만들고, 그 위에 서비스별 이미지를 쌓는다. - 인스턴스 시작 시 수행해야 할 작업을 줄여 리전 간에도 빠르고 예측 가능한 프로비저닝이 가능하다. - 실행 시점에 많은 설정을 적용하던 기존 방식보다 부팅 과정의 변동성이 작다. ## 설정 관리 방식의 변화 - 기존에는 실행 중인 인스턴스가 주기적으로 Chef 작업을 실행해 설정을 확인하고 원하는 상태로 되돌렸다. - Shipyard에서는 이미지 생성과 초기 프로비저닝 같은 명확한 수명 주기 단계에서 설정을 적용한다. - 설정 관리 도구는 시스템 전체를 계속 수정하기보다 서비스 배포에 집중한다. - 이 방식의 장점은 다음과 같다. - 백그라운드 작업 부하 감소 - 수동 변경의 의도치 않은 덮어쓰기 방지 - 시간이 지나면서 인스턴스 상태가 달라지는 현상 감소 - 시스템 동작과 장애 원인 분석의 단순화 ## Peekaboo 기반 실시간 인벤토리 - Shipyard는 EC2 플릿을 거의 실시간으로 확인하기 위한 인벤토리 시스템 Peekaboo를 제공한다. - 기존처럼 Chef Server를 단일 정보 원천으로 사용하지 않고 AWS 이벤트와 인스턴스 메타데이터를 직접 활용한다. - Shipyard로 배포되지 않은 인스턴스도 추적해 전체 EC2 플릿을 한곳에서 확인할 수 있다. - AWS EventBridge, OpenSearch, Lambda를 기반으로 구축되었다. - UI, API, CLI를 제공해 다음 작업을 지원한다. - 전체 인스턴스 상태 탐색 - 다른 시스템과의 통합 - 명령줄에서 빠른 상태 확인 - 중앙화된 가시성을 통해 어떤 인스턴스가 어디에 있고 어떤 상태인지 파악하기 쉬워진다. ## 짧은 수명의 불변 인스턴스 - 각 EC2 인스턴스에 제한된 수명을 부여하고 정기적으로 자동 교체한다. - 인스턴스를 직접 수정해 오래 유지하기보다 새 이미지를 배포해 교체하는 방식을 채택한다. - 보안 취약점이 노출된 채 남아 있는 시간을 줄일 수 있다. - 운영팀은 개별 서버를 고치는 대신 최신 이미지를 기반으로 인스턴스를 재생성하는 데 집중한다. - 결과적으로 EC2 플릿의 상태를 지속적으로 신선하게 유지할 수 있다. ## Golden Base Image인 slack-zero - Shipyard의 기반에는 Slack Compute Platform Team이 관리하는 공통 이미지 `slack-zero`가 있다. - 보안 및 모니터링 팀과 협력해 표준화된 기반 환경을 유지한다. - 포함 내용: - 운영체제 기본 설정과 보안 강화 - 네트워크 및 서비스 디스커버리 설정 - 모니터링·보안 에이전트 - 공통 도구와 기반 시스템 설정 - 서비스는 `slack-zero`를 기반으로 필요한 런타임과 애플리케이션 요소를 추가한다. - 기반 이미지는 불변이지만 영구적으로 유지하지는 않는다. - 보안 패치, 모니터링 업데이트, 네트워크 개선이 필요하면 새 이미지를 생성한다. - 서비스 이미지는 최신 `slack-zero`를 기반으로 다시 빌드해 변경 사항을 상속한다. ## AWS Image Builder 활용 - Slack은 기존 Packer 대신 AWS Image Builder를 사용해 `slack-zero`를 생성한다. - AWS Image Builder의 장점으로 다음이 언급된다. - 수명 주기 정책을 통한 오래된 AMI 자동 정리 - AMI 저장 비용 절감 - 새 이미지가 생성될 때 SSM Parameter에 최신 AMI 정보를 게시 - 이를 통해 서비스 이미지 빌드와 인스턴스 교체 과정에서 최신 기반 이미지를 일관되게 참조할 수 있다. Shipyard의 핵심은 EC2를 수동으로 계속 관리하는 서버가 아니라, 버전이 지정된 이미지로 빌드하고 안전하게 교체하는 배포 대상으로 바꾸는 데 있다. EC2를 계속 사용해야 하지만 컨테이너의 불변성, 계층형 이미지, 점진적 배포, 자동 롤백의 이점을 원하는 조직이라면 이와 같은 플랫폼 접근이 효과적이다.

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

opensearchAWSamazon-ec2chef+4

aws·2026년 6월 29일·4분 읽기큐레이션 요약

AWS 주간 요약: Amazon Connect Customer를 위한 에이전틱 CX 디자이너, EC2 AMI 워터마크, MySQL을 위한 오픈 거버넌스 등 (2026년 6월 29일) | Amazon Web Services

AWS는 기업이 긴 개발 백로그를 기다리지 않고 AI 기반 고객 경험과 운영 자동화를 구축할 수 있도록 노코드 도구와 AI 보조 기능을 확대하고 있다. 이번 주의 핵심은 Amazon Connect Customer의 Agentic CX Designer와 다양한 서비스의 AI 에이전트·자동화 기능이다. 동시에 EC2 이미지 추적, MySQL 오픈 거버넌스, 자격증 갱신 제도 등 인프라 관리와 개발자 생태계 변화도 소개됐다. ## Amazon Connect Customer의 Agentic CX Designer - 비즈니스 담당자가 직접 AI 기반 고객 경험을 설계하고 배포할 수 있는 노코드 캔버스다. - 음성 및 디지털 채널에서 다음 두 가지 AI 방식을 하나의 관리된 흐름으로 결합한다. - **Agentic AI**: 상황을 판단하고 여러 단계를 수행하는 자율형 AI - **Deterministic AI**: 정해진 규칙과 절차에 따라 일관되게 동작하는 AI - 설계부터 테스트, 시뮬레이션, 운영 배포까지의 과정을 지원해 구축 기간을 수개월에서 수주로 단축하는 것을 목표로 한다. - 프리뷰로 제공되는 **Live Sync**는 사용자가 말하거나 입력하는 내용을 바탕으로 웹·모바일 화면을 실시간으로 변경한다. - 통화 중 고객이 별도 화면을 찾지 않고도 양식을 작성할 수 있다. - 상담 내용에 맞춰 적절한 상품 페이지를 자동으로 표시할 수 있다. - 고객 경험 설계자의 역할이 개발자 중심에서 비즈니스 사용자까지 확대될 수 있다는 점이 핵심이다. ## AWS Lambda MicroVMs - 각 사용자나 작업에 VM 수준의 격리를 제공하는 새로운 서버리스 컴퓨팅 프리미티브다. - Firecracker를 기반으로 하며 빠른 시작과 재개 속도를 제공한다. - 실행 상태를 최대 8시간 동안 일시 중지했다가 다시 재개할 수 있다. - 멀티테넌트 애플리케이션에서 사용자 생성 코드나 AI가 생성한 코드를 실행할 때 유용하다. - 별도의 가상화 인프라를 관리하지 않으면서도 속도, 격리, 상태 보존을 함께 확보하는 것이 목적이다. ## EC2 AMI Watermarks와 이미지 통제 - 프라이빗 AMI에 사용자 정의 식별자를 삽입할 수 있다. - 워터마크는 AMI 복사, 리전 이동, 계정 공유를 거쳐 파생된 AMI에도 자동으로 전달된다. - **Allowed AMIs** 및 **Declarative Policies**와 함께 사용하면 승인된 이미지로만 EC2 인스턴스를 실행하도록 제한할 수 있다. - 모든 AWS 리전에서 추가 비용 없이 제공된다. - 이미지의 출처와 계보를 추적하거나, 조직의 승인 정책을 강제하는 데 활용할 수 있다. ## Outposts 셀프서비스 수명주기 관리 - AWS 콘솔, CLI, API에서 Outposts 관련 작업을 직접 수행할 수 있다. - 지원 범위에는 다음이 포함된다. - 구성 - 견적 산출 - 주문 - 구독 관리 - 갱신 - 폐기 및 해제 - 새로운 견적 도구는 실시간 비용을 수초 내 계산한다. - 주문 전에 계정 및 리전의 제약 조건을 표시해 구성 오류와 주문 지연을 줄인다. ## Kafka·OpenSearch 운영을 돕는 AI 에이전트 - **Amazon MSK AI Agent Skills** - Kiro, Claude Code, Cursor 같은 AI 코딩 도우미에 Amazon MSK 운영 지식을 제공한다. - 문제 해결, 용량 산정, 구성, 모니터링을 안내한다. - 외부 Kafka 클러스터를 MSK Express로 이전하는 작업도 지원한다. - 전문 운영 지식이 필요한 작업을 개발자가 단계적으로 수행할 수 있게 한다. - **Amazon OpenSearch Service AI-assisted migrations** - 셀프 매니지드 Solr, Elasticsearch, OpenSearch를 OpenSearch Serverless 또는 Managed Clusters로 이전하도록 돕는다. - Kiro와 Claude Code를 활용한 에이전트 기반 마이그레이션 경험을 제공한다. - Solr 환경에서는 실시간 트래픽을 캡처하고 재생하는 기능도 추가됐다. - 이전 전후 동작을 검증하고 마이그레이션 위험을 줄이는 데 초점을 둔다. ## GuardDuty의 AI 기반 보안 조사 - 프리뷰 기능으로, 보안 탐지 결과와 계정 활동을 자동 분석한다. - 최근 90일간의 관련 활동과 주변 맥락을 지식 그래프 및 위협 인텔리전스와 함께 검토한다. - 실제 위협과 정상 활동을 구분해 보안팀의 조사 부담을 줄인다. - 각 조사 결과에 다음 정보를 제공한다. - 위협 여부에 대한 처분 평가 - 신뢰도 점수 - MITRE ATT&CK 분류 - 실행 가능한 대응 권고 - 수동 분석에 걸리는 시간을 줄이고, 몇 분 안에 우선순위가 높은 대응 방향을 제시하는 것이 목표다. ## MySQL 오픈 거버넌스 - Oracle은 MySQL 프로젝트에 외부 조직이 공식적으로 참여할 수 있는 커뮤니티 거버넌스 모델을 발표했다. - 새로운 Steering Committee에 Oracle 외부 인사를 위한 4석을 마련한다. - 공개 GitHub 활동을 통해 개발 과정의 투명성과 커뮤니티 참여를 강화한다. - AWS도 위원회 의석을 보유하며, MySQL 업스트림에 수정 사항을 기여해 온 사례와 이번 변화에 대한 지지를 밝혔다. - 기업 사용자는 특정 공급업체에만 의존하지 않고 프로젝트 방향성과 개발 과정에 더 직접적으로 참여할 가능성이 커진다. ## 자격증 갱신과 개발자 지원 - 일부 AWS Associate 및 Professional 자격증은 전체 시험을 다시 치르지 않고도 갱신할 수 있다. - AWS Skill Builder의 지정 교육과 실습 랩을 완료하면 자격증을 1년 추가로 유지할 수 있다. - 현재 오픈 베타로 제공되며, 대상 자격증은 올해 후반 더 확대될 예정이다. - 2026년 All Builders Welcome Grant는 AWS re:Invent 참가 패스, 항공료, 숙박을 지원한다. - 신청 마감일은 7월 14일이며, AWS Summit과 Community Day를 통해 오프라인 네트워킹과 학습 기회도 제공된다. 실무적으로는 비즈니스 팀이 고객 경험을 직접 설계해야 한다면 Agentic CX Designer를 검토하고, 멀티테넌트 코드 실행에는 Lambda MicroVMs, AMI 거버넌스에는 Watermarks와 Allowed AMIs를 함께 검토할 만하다. 운영 측면에서는 MSK·OpenSearch 마이그레이션과 GuardDuty 조사 기능을 활용해 전문 인력 의존도와 수동 분석 시간을 줄일 수 있다.

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

opensearchAWSApache Kafka서버리스+4

line·2026년 3월 20일원문

기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다 (새 탭에서 열림)

사양서나 소스 코드를 참조할 수 없는 블랙박스 상태의 레거시 시스템을 내재화하기 위해, Kafka 생태계를 활용한 자동화된 검증 파이프라인을 구축하여 시스템의 동일성을 증명했습니다. 데이터 발생부터 분석까지 이어지는 검증 루프를 통해 불일치 건수를 0으로 수렴시키는 과정을 거쳤으며, 결과적으로 대규모 커머스 데이터를 안전하고 정밀하게 신규 시스템으로 이관할 수 있었습니다. **통합 커머스 검색의 도메인 구조** * **상품과 카탈로그**: 판매자가 등록한 개별 '상품'들을 동일 모델별로 묶어 최적의 정보를 제공하는 상위 객체인 '카탈로그'로 관리하며, 이는 최저가 산출 및 객단가 지표 제공의 핵심이 됩니다. * **수신 파이프라인**: 대규모 상품 데이터를 내부 표준 형식으로 변환하고 정합성을 검사하여 상품 및 카탈로그 정보에 반영하는 거대 파이프라인으로, 서비스 전체에 막대한 영향력을 미칩니다. **무중단 검증 루프의 설계** * **검증 파이프라인 아키텍처**: 트리거(DB 변경/이벤트) → 실행 및 비교(양쪽 시스템에 동일 입력 주입) → 가공 및 적재(불일치 데이터 저장) → 분석 및 개선(오류 패턴 수정)으로 이어지는 유기적인 루프를 생성했습니다. * **입력과 출력의 정의**: 동일한 ID나 스냅숏을 입력값으로 설정하고, API 응답이나 DB 업데이트 결과를 출력값으로 명확히 정의함으로써 내부 로직이 복잡하더라도 통계적으로 동일함을 증명할 수 있는 환경을 만들었습니다. **조회 로직 검증과 블랙박스 분석** * **CDC와 Kafka 기반 비교**: DB의 바이너리 로그를 실시간 스트리밍하는 CDC(Change Data Capture)를 트리거로 사용하고, Kafka를 통해 검증 로직을 물리적으로 격리하여 서비스 성능에 영향을 주지 않으면서 기존/신규 API 응답을 1:1로 대조했습니다. * **재귀적 필드 비교 및 정렬**: 100개가 넘는 API 응답 필드를 `Map<String, Object>` 구조로 변환해 재귀적으로 탐색했으며, 리스트 내 순서 차이로 인한 노이즈를 제거하기 위해 문자열 정렬 후 2차 비교를 수행하는 유연한 로직을 도입했습니다. * **가시성 확보 및 최적화**: ksqlDB를 활용해 실시간으로 이상 징후를 Slack으로 알리고 OpenSearch로 상세 로그를 분석했으며, 처리율 제한(Rate Limit)을 적용해 동일 패턴의 중복 오류가 분석을 방해하지 않도록 제어했습니다. **상태 변화를 다루는 업데이트 로직 검증** * **실시간 시뮬레이션**: 카탈로그 통계 업데이트 시 CDC 이벤트가 발생하면 검증 모듈이 신규 로직으로 예상 결과값을 즉시 산출하고, 이를 기존 로직이 업데이트한 DB의 실제값과 대조하는 시뮬레이션 방식을 채택했습니다. * **비동기 지연 및 트리거 누락 해결**: 비동기 환경의 시차 문제는 'N회차 재시도 큐' 전략으로 해결하고, 특정 필드 변경 시에만 검증이 작동하도록 필터링하여 리소스를 최적화했습니다. 또한 ETL 배치 검증을 병행하여 실시간 스트림에서 놓칠 수 있는 트리거 누락 결함까지 포착했습니다. **성공적인 시스템 전환을 위한 제언** 복잡한 시스템의 내재화는 단순히 코드를 옮기는 것이 아니라 '기존과 동일하게 작동함'을 객관적으로 입증하는 과정입니다. 데이터 스트림 기반의 자동화된 검증 체계를 구축하면 블랙박스 로직의 베일을 하나씩 벗겨낼 수 있을 뿐만 아니라, 실시간 트래픽 환경에서의 성능 비교 지표까지 확보하여 안정성과 성능이라는 두 마리 토끼를 모두 잡을 수 있습니다.

opensearch데이터베이스 설계PostgreSQLApache Kafka+4

naver·2025년 12월 17일원문

비용, 성능, 안정성을 목표로 한 지능형 로그 파이프라인 도입 (새 탭에서 열림)

네이버의 통합 데이터 플랫폼 AIDA 내 로그 수집 시스템인 'Logiss'는 대규모 로그 파이프라인을 운영하며 겪었던 무중단 배포의 한계, 리소스 낭비, 로그 중요도 미분류 문제를 해결하기 위해 지능형 파이프라인을 도입했습니다. 핵심은 Storm의 멀티 토폴로지 구성을 통한 블루-그린 배포 구현과 실시간 트래픽 상태에 따라 처리 속도를 동적으로 조절하는 지능형 제어 알고리즘의 적용입니다. 이를 통해 서비스 중단 없는 배포는 물론, 인프라 비용을 약 40% 절감하고 장애 시 핵심 로그를 우선 처리하는 안정성까지 확보하며 성능과 비용의 최적점을 찾아냈습니다. **멀티 토폴로지와 블루-그린 배포를 통한 무중단 운영** * 기존 Traffic-Controller는 단일 토폴로지 구조로 인해 배포 시마다 데이터 처리가 3~8분간 중단되는 문제가 있었으나, 이를 해결하기 위해 멀티 토폴로지 기반의 블루-그린 배포 방식을 도입했습니다. * Storm 2.x의 `assign` 방식 대신 Kafka의 컨슈머 그룹 관리 기능을 활용하는 `subscribe` 방식으로 내부 로직을 커스텀 변경하여, 여러 토폴로지가 동일 파티션을 중복 소비하지 않도록 개선했습니다. * 이를 통해 트래픽이 몰리는 낮 시간대에도 중단 없이 안전하게 신규 기능을 배포하고 점진적인 트래픽 전환이 가능해졌습니다. **지능형 트래픽 제어를 통한 리소스 최적화** * 낮과 밤의 트래픽 차이가 5배 이상 발생하는 환경에서 피크 타임 기준으로 장비를 고정 할당하던 비효율을 제거하기 위해 '지능형 속도 제어' 알고리즘을 도입했습니다. * Kafka의 랙(lag) 발생량과 백엔드 시스템(OpenSearch 등)의 CPU 부하 상태를 실시간으로 감시하여, 시스템이 여유로울 때는 로그 처리 속도를 자동으로 높여 적체를 빠르게 해소합니다. * 유동적인 속도 조절 덕분에 기존 대비 투입 장비 리소스를 약 40% 절감하는 성과를 거두었으며, 갑작스러운 트래픽 유입에도 유연하게 대응할 수 있게 되었습니다. **로그 중요도 기반의 우선순위 처리** * 모든 로그를 동일한 속도로 처리하던 방식에서 벗어나, 비상 상황 발생 시 서비스 핵심 로그가 먼저 처리될 수 있도록 우선순위(High, Medium, Low) 개념을 도입했습니다. * 트래픽 지연이 발생하면 중요도가 낮은 로그의 처리 속도는 제한하고, 사업 및 서비스 운영에 필수적인 핵심 로그는 지연 없이 전송되도록 파이프라인 가용성을 확보했습니다. **저장소별 차등 샘플링을 통한 비용 절감** * 실시간 검색을 위한 OpenSearch와 장기 보관을 위한 랜딩 존(Landing Zone)에 데이터를 전송할 때, 각 저장소의 목적에 맞게 샘플링 비율을 다르게 설정할 수 있는 기능을 구현했습니다. * 모든 데이터를 무조건 100% 저장하는 대신, 분석 목적에 따라 일부 샘플링만으로 충분한 로그는 저장량을 줄여 인덱싱 부하를 낮추고 스토리지 비용을 효율적으로 관리할 수 있게 되었습니다. 대규모 로그 파이프라인 운영에서 비용 효율과 안정성은 상충하기 쉬운 가치이지만, 시스템의 상태를 실시간으로 파악하고 제어하는 '지능형' 로직을 통해 두 마리 토끼를 모두 잡을 수 있습니다. 특히 스트리밍 처리 프레임워크의 제약 사항을 직접 커스텀하여 비즈니스 요구사항에 맞춘 최적화 사례는 유사한 데이터 플랫폼을 운영하는 기술진에게 실무적인 통찰을 제공합니다.

opensearchApache Kafka데이터 엔지니어링apache-storm+3

line·2025년 5월 23일원문

문의 대응을 효율화하기 위한 RAG 기반 봇 도입하기 (새 탭에서 열림)

LY 주식회사의 SR(Service Reliability) 팀은 반복되는 AWX 플랫폼 관련 문의를 효율적으로 처리하기 위해 RAG(검색 증강 생성) 기반의 지원 봇을 도입했습니다. 이 시스템은 사용자가 방대한 가이드 문서를 읽지 않고 중복된 질문을 던질 때 발생하는 운영 리소스 소모 문제를 해결하기 위해 고안되었습니다. 사내 위키와 과거 상담 이력을 활용해 정확도 높은 답변을 생성함으로써 관리자의 개입 없이도 사용자 문제를 신속하게 해결하는 성과를 거두었습니다. **AWX 지원 봇의 기술 스택 및 구성** - **LLM 및 프레임워크:** OpenAI의 GPT 모델을 메인 엔진으로 사용하며, LangChain 프레임워크를 통해 전체적인 워크플로를 관리합니다. Slack과의 연동은 Bolt for Python을 활용했습니다. - **임베딩 모델:** 다국어 지원 및 문장 비교 성능이 뛰어난 'paraphrase-multilingual-mpnet-base-v2' 모델(SBERT)을 선택하여 글로벌 임직원의 다양한 언어 문의에 대응합니다. - **벡터 데이터베이스:** 사내에서 PaaS 형태로 제공되어 접근성이 높은 OpenSearch를 사용하며, 텍스트 데이터를 고차원 벡터로 변환하여 저장하고 검색합니다. **RAG 및 벡터 검색을 통한 답변 정확도 향상** - **LLM의 한계 극복:** 학습되지 않은 최신 정보 부재나 허위 정보 생성(Hallucination) 문제를 해결하기 위해, 질문과 관련된 신뢰할 수 있는 컨텍스트를 LLM에 함께 전달하는 RAG 기법을 적용했습니다. - **벡터 검색 원리:** 사용자의 질문을 임베딩하여 벡터화한 뒤, 벡터 DB 내에서 의미적으로 유사한 문장들을 k-NN(최근접 이웃) 방식으로 검색하여 최적의 참고 자료를 추출합니다. - **유사도 기반 추출:** 단순 키워드 매칭이 아닌 의미적 유사성을 판단하므로, 'Buy'와 'Purchase'처럼 단어는 달라도 맥락이 같은 정보를 정확히 찾아낼 수 있습니다. **봇 워크플로 및 데이터 활용 전략** - **사용자 상호작용:** 사용자가 Slack으로 문의하면 봇이 사내 위키와 과거 Slack 스레드 데이터를 검색합니다. 추출된 데이터를 바탕으로 LLM이 1차 답변을 제공하며, 해결되지 않을 경우에만 '관리자 호출' 버튼을 통해 담당자를 연결합니다. - **데이터 소스 다각화:** 공식 가이드 문서뿐만 아니라 실제 사용자들이 겪었던 문제와 해결책이 담긴 'Slack 문의 스레드 데이터'를 함께 인덱싱하여 실무적인 답변이 가능하도록 구성했습니다. - **리소스 최적화:** 봇의 자동 응답을 통해 단순 반복 문의에 대한 관리자의 수동 대응 시간을 줄이고, 개발 조직이 서비스 운영 본연의 업무에 더 집중할 수 있는 환경을 조성했습니다. RAG 기반 시스템을 구축할 때 가장 중요한 것은 신뢰할 수 있는 데이터 소스의 확보입니다. LY의 사례처럼 공식 문서와 실제 상담 이력을 병행 활용하면 LLM이 훨씬 구체적이고 실무에 유효한 답변을 생성할 수 있습니다. 운영 중인 서비스의 문의 대응 리소스가 부담된다면, 익숙한 벡터 DB와 오픈소스 임베딩 모델을 조합한 RAG 봇 도입을 적극 추천합니다.

opensearchAIPythonRAG+5

figma·2024년 10월 9일·3분 읽기큐레이션 요약

Figma에서의 속도 탐

Figma는 검색 지연의 원인을 OpenSearch 자체의 검색 속도보다 쿼리 전후 처리와 잘못된 모니터링 지표에서 발견했다. OpenSearch가 보고한 평균 8ms는 전체 검색 시간이 아니라 개별 샤드 쿼리 시간에 불과했으며, 실제 애플리케이션 호출은 평균 150ms에 달했다. 조사 결과 권한 필터를 만드는 사전 처리와 검색 결과를 검증하는 사후 처리가 전체 시간의 대부분을 차지했고, 이를 개선하는 것이 확장 가능한 검색 기반을 마련하는 핵심이었다. ## OpenSearch 마이그레이션과 검색 성능 문제 - Figma는 2023년 말까지 오래된 Elasticsearch 버전을 사용하다가 AWS 관리형 OpenSearch로 이전하기 시작했다. - OpenSearch는 Elasticsearch의 라이선스 변경 이후 분기된 프로젝트로, 기본적으로 호환되지만 3년간 세부적인 차이가 누적되어 마이그레이션이 예상보다 어려웠다. - 사용자와 데이터가 증가하면서 검색 시스템이 원하는 콘텐츠를 안정적으로 찾기 어려워졌고, 장기적인 확장을 위한 검색 인프라 재정비가 필요해졌다. ## 잘못 해석한 8ms 지표 - Datadog의 OpenSearch 연동에서는 평균 검색 시간이 약 8ms로 나타났다. - 하지만 Figma 검색 API의 p99 지연 시간은 거의 1초였고, 애플리케이션에서 OpenSearch API를 호출하는 데 걸린 시간은 다음과 같았다. - 평균 약 150ms - p99 약 200~400ms - 최소 지연 시간도 40ms 이상 - OpenSearch와 애플리케이션이 같은 AWS 가용 영역에서 실행되고 있었기 때문에 네트워크 지연만으로는 이 차이를 설명할 수 없었다. - 원인은 8ms가 전체 검색 시간이 아니라 **각 샤드에서 실행된 개별 쿼리의 평균 시간**이었기 때문이다. ## OpenSearch의 쿼리 및 fetch 단계 - 검색 요청은 먼저 coordinator 노드에 전달된다. - coordinator 노드는 인덱스의 각 샤드가 있는 worker 노드에 쿼리를 보낸다. - 이 과정이 OpenSearch의 **query 단계**다. - coordinator는 각 샤드의 결과를 수집하고 정렬한 뒤, 상위 결과에 대한 상세 정보를 다시 요청한다. - 이 후속 과정이 **fetch 단계**이며, 최종 결과가 클라이언트에 반환된다. - Figma의 초기 구성에서는 사용자 검색 하나가 최대 500개의 샤드 쿼리를 발생시킬 수 있었다. - 샤드 쿼리 대부분은 병렬 실행되지만 모두 동시에 처리되는 것은 아니므로, 개별 샤드 시간과 전체 검색 시간 사이에 큰 차이가 발생했다. ## 전체 검색 시간을 측정하도록 계측 개선 - Figma는 검색 코드의 주요 구간에 메트릭과 트레이스를 추가했다. - 조사 결과 OpenSearch가 보고하는 지표와 실제 API 호출 시간 사이에 큰 불일치가 있음을 확인했다. - OpenSearch의 기본 메트릭과 로그에는 coordinator 관점의 전체 쿼리 시간이 포함되지 않았다. - 전체 검색 시간은 검색 API 응답의 `took` 필드에만 제공됐다. - Figma는 모든 검색 응답에서 `took` 값을 추출해 모니터링 시스템에 추가했고, 이를 통해 실제 백엔드 검색 지연을 보다 정확하게 파악했다. ## 병목은 OpenSearch 검색 자체가 아니었다 - 실제로 OpenSearch에서 검색을 기다리는 시간은 전체 쿼리 API 시간의 30% 미만이었다. - 나머지 시간은 검색 전후의 애플리케이션 처리에 사용됐다. - **사전 처리** - 사용자가 접근할 수 있는 파일 관련 정보를 조회한다. - 접근 권한이 없는 파일을 대부분 제외하도록 OpenSearch 필터 절을 생성한다. - **사후 처리** - OpenSearch가 반환한 각 파일 결과에 대해 사용자의 실제 접근 권한을 다시 확인한다. - 권한 검증을 통해 사용자가 볼 수 없는 파일이 검색 결과에 포함되지 않도록 보장한다. - 특히 사후 처리가 매우 느렸으며, Figma는 권한 시스템과 협력해 이 부분을 개선하기 시작했다. 검색 성능을 개선하려면 검색 엔진이 표시하는 단일 지표만 믿지 말고, coordinator부터 애플리케이션의 사전·사후 처리까지 전체 요청 경로를 측정해야 한다. Figma 사례처럼 샤드별 지연 시간보다 실제 사용자 요청의 전체 지연 시간을 기준으로 병목을 찾아야 하며, 권한 필터 생성과 결과 검증도 검색 성능의 핵심 구성 요소로 다뤄야 한다.

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

opensearch옵저버빌리티AWSelasticsearch+2