aws·2026년 1월 20일원문

AWS 주간 요약: Kiro CLI 최신 기능, AWS 유럽 주권 클라우드, EC2 X8i 인스턴스 등 (2026년 1월 19일) (새 탭에서 열림)

이 글은 2026년 1월 셋째 주 AWS의 주요 기술 업데이트와 커뮤니티 소식을 다루며, 특히 Kiro CLI의 기능 강화와 유럽 주권 클라우드의 정식 출시를 핵심 성과로 제시합니다. 또한 고성능 메모리 최적화 인스턴스인 EC2 X8i의 상용화와 Amazon Quick Suite를 통한 AI 에이전트 활용 사례를 통해 더욱 고도화된 클라우드 생태계를 구축했음을 보여줍니다. 이번 소식은 엔터프라이즈급 성능 요구 사항과 지역별 규제 준수, 그리고 AI 기반 생산성 향상이라는 세 가지 측면에서 AWS의 진보를 요약하고 있습니다. **Kiro CLI의 제어 및 사용자 경험 강화** * 웹 호출(web fetch) URL에 대한 세밀한 제어 기능을 도입하여, 허용 목록(allowlist)과 차단 목록(blocklist)을 통해 에이전트가 접근할 수 있는 URL 범위를 엄격하게 제한할 수 있습니다. * 커스텀 에이전트를 위한 전용 키보드 단축키와 개선된 Diff 뷰를 제공하여, 단일 세션에서 여러 전문화된 에이전트와 협업할 때 발생하는 마찰을 최소화했습니다. **AWS 유럽 주권 클라우드 정식 출시** * 2023년부터 추진해 온 독립적인 클라우드 인프라인 'AWS European Sovereign Cloud'가 모든 고객을 대상으로 정식 서비스(GA)를 시작했습니다. * 유럽 내 가장 엄격한 데이터 주권 및 규제 요건을 충족할 수 있도록 설계되었으며, 포괄적인 AWS 서비스 세트를 제공하여 유럽 고객들의 컴플라이언스 대응을 지원합니다. **메모리 최적화 EC2 X8i 인스턴스 상용화** * AWS 전용 커스텀 Intel Xeon 6 프로세서를 탑재한 EC2 X8i 인스턴스가 정식 출시되었으며, 모든 코어에서 최대 3.9GHz의 터보 주파수를 유지합니다. * SAP 인증을 획득한 이 인스턴스는 클라우드 내 인텔 기반 프로세서 중 최고 수준의 성능과 메모리 대역폭을 제공하여 메모리 집약적인 워크로드에 최적화되어 있습니다. **생산성 향상을 위한 AI 에이전트 및 도구** * AI 에이전트 동료인 'Amazon Quick Suite'를 통해 비즈니스 질문에 답을 구하고 인사이트를 행동으로 전환하는 생산성 활용 사례가 공유되었습니다. * GitHub Actions를 사용하여 Amazon Bedrock AgentCore에 AI 에이전트를 자동 배포하는 방법이 소개되어, 개발자들이 더욱 효율적으로 AI 기능을 운영 환경에 적용할 수 있게 되었습니다. 이번 업데이트는 강력한 보안과 규제 준수가 필요한 유럽 시장부터, 고성능 컴퓨팅이 요구되는 엔터프라이즈 환경, 그리고 실무 효율을 높이는 AI 에이전트 기술까지 폭넓은 영역을 아우르고 있습니다. 기술 조직은 특히 강화된 Kiro CLI와 Bedrock AgentCore 배포 자동화 가이드를 참고하여 사내 AI 에이전트 운영 환경을 최적화하고 개발 생산성을 한 단계 더 끌어올릴 수 있을 것입니다.

AWSAIAI 에이전트amazon-bedrock+5

toss·2026년 1월 8일원문

수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기 (새 탭에서 열림)

토스페이먼츠는 수천 개의 API 서버와 배치 설정을 관리하기 위해 설정을 단순한 텍스트가 아닌 '진화하는 코드'로 정의하여 운영합니다. 복사-붙여넣기식의 중복 설정을 제거하기 위해 오버레이 아키텍처와 템플릿 패턴을 도입했으며, 이를 통해 오타나 설정 오류로 인한 대규모 정산 장애 리스크를 원천 차단합니다. 결과적으로 인프라 설정을 테스트 가능한 영역으로 끌어올려 대규모 하이브리드 클라우드 환경에서도 높은 안정성과 유연성을 확보했습니다. ### 실시간 API 서버: 오버레이와 템플릿의 결합 * **오버레이 아키텍처:** 설정을 `global`, `cluster`, `phase`, `application` 순서의 계층형 구조로 설계하여 하위 계층이 상위 계층의 기본값을 덮어쓰도록 구성했습니다. 이를 통해 공통 설정은 한 번만 정의하고 각 환경에 필요한 차이점만 관리할 수 있습니다. * **템플릿 패턴 도입:** YAML의 단순 오버레이만으로는 해결하기 어려운 긴 문자열(예: JVM 옵션) 내의 특정 값만 수정하기 위해 `{{MAX_HEAP}}`과 같은 변수 치환 방식을 사용합니다. * **동적 설정 주입:** 설정 파일 내부에 파이썬 스크립트를 삽입하여 랜덤 포트 생성이나 외부 API 호출을 통한 동적 값 할당이 가능하며, 클러스터 이름에 따른 조건부 로직을 적용해 복잡한 환경 변수 요구사항을 해결합니다. ### 배치 서버: DSL과 GitOps를 통한 단순화 * **Jenkins 기반의 단순화:** 대규모 정산 데이터를 다루는 배치 환경일수록 단순함이 강력하다는 원칙 아래, Jenkins를 활용하면서도 수동 조작의 단점을 보완하는 방향을 택했습니다. * **Groovy DSL 활용:** Jenkins의 웹 UI를 통한 수동 설정을 배제하고, Groovy 기반의 자체 DSL(Domain Specific Language)을 구축하여 수천 개의 배치 Job을 코드 형태로 관리합니다. * **GitOps 체계:** 모든 배치 설정을 코드 저장소에서 관리하고 CI/CD 파이프라인과 통합함으로써, 개발자가 직접 Jenkins에 접속하지 않고도 표준화된 환경에서 배치 작업을 배포할 수 있도록 개선했습니다. ### 인프라의 코드화와 검증 자동화 * **테스트 가능한 설정:** 설정값에 대한 오타나 논리적 오류를 방지하기 위해 설정 코드에 대한 유닛 테스트를 수행합니다. 이를 통해 수천 개의 설정 중 단 하나의 오타가 치명적인 금융 장애로 이어지는 것을 사전에 방지합니다. * **유연한 확장성:** 고정된 설정 체계에 안주하지 않고, 인프라의 변화와 개발자의 요구사항에 맞춰 설정 인프라 자체가 계속해서 진화할 수 있는 구조를 지향합니다. 단순히 설정 파일을 잘 작성하는 것에 그치지 않고, 인프라 설정을 애플리케이션 코드와 동일한 수준의 설계와 테스트를 거쳐 관리하는 것이 대규모 시스템의 안정성을 보장하는 핵심입니다. 초기에 다소 복잡해 보일 수 있는 오버레이나 DSL 도입은 장기적으로 중복을 제거하고 휴먼 에러를 막는 가장 확실한 투자입니다.

AWS쿠버네티스infrastructure-as-codegitops+3

netflix·2025년 12월 15일원문

Netflix Live Origin. Xia (새 탭에서 열림)

넷플릭스의 라이브 오리진(Live Origin)은 클라우드 라이브 스트리밍 파이프라인과 자사 콘텐츠 전송 네트워크(CDN)인 오픈 커넥트(Open Connect) 사이에서 콘텐츠 공급을 조율하는 핵심 마이크로서비스입니다. 이 시스템은 다중 파이프라인 구조와 지능적인 세그먼트 선택 로직을 통해 실시간 방송 중 발생할 수 있는 데이터 손실이나 지연을 효과적으로 방지합니다. 결과적으로 넷플릭스는 라이브 환경에서도 VOD 수준의 안정성과 고품질 시청 경험을 전 세계 사용자에게 제공할 수 있게 되었습니다. **다중 파이프라인 기반의 탄력적인 아키텍처** 라이브 스트리밍은 실시간 특성상 프레임 누락이나 세그먼트 손실 같은 결함이 발생할 가능성이 높습니다. 라이브 오리진은 이를 극복하기 위해 다음과 같은 전략을 사용합니다. * **이중화된 파이프라인:** 서로 다른 클라우드 리전에서 독립적으로 운영되는 중복 파이프라인을 운영하여, 한쪽 경로에 결함이 생겨도 다른 경로의 정상 세그먼트를 즉시 선택할 수 있습니다. * **지능적 후보 선택:** 패키저에서 수행된 미디어 검사 메타데이터를 활용하여, 여러 후보 세그먼트 중 가장 품질이 좋은 것을 결정론적 순서에 따라 선택합니다. * **에포크 로킹(Epoch Locking):** 클라우드 인코더 단계부터 적용된 에포크 로킹 기술을 통해 오리진이 여러 파이프라인의 세그먼트 중 최적의 결과물을 일관되게 식별하고 조합할 수 있도록 합니다. **오픈 커넥트와의 스트리밍 최적화** 기존 VOD에 최적화되어 있던 오픈 커넥트(Open Connect) 인프라를 라이브에 맞게 확장하여 효율적인 전송 구조를 구축했습니다. * **요청 병합(Request Collapsing):** 동일한 세그먼트에 대해 수많은 클라이언트 요청이 동시에 몰릴 때, 오리진에는 단 하나의 요청만 보내고 나머지는 응답을 기다리게 하여 서버 부하(Thundering Herd 문제)를 방지합니다. * **세그먼트 템플릿 활용:** 오픈 커넥트 가전(OCA)은 라이브 이벤트 설정 데이터를 기반으로 유효한 세그먼트 범위를 미리 파악하며, 범위를 벗어난 잘못된 요청을 사전에 차단합니다. * **적응형 채우기(Adaptive Fill):** 오리진은 응답 헤더를 통해 OCA에 백업 파이프라인 위치를 알려줍니다. 특정 리전의 오리진에 문제가 발생하면 OCA가 스스로 다른 리전의 오리진으로 전환하여 데이터를 가져옵니다. **효율적인 저장소 관리 및 관찰 가능성** AWS EC2 인스턴스에서 동작하는 라이브 오리진은 대규모 트래픽과 데이터를 관리하기 위해 정교한 리소스 관리 기법을 도입했습니다. * **계층화된 스토리지:** 실시간으로 자주 액세스되는 세그먼트는 RAM에 저장하고, 상대적으로 덜 빈번한 데이터는 SSD에 저장하는 계층 구조를 통해 응답 속도를 극대화했습니다. * **자동 가비지 컬렉션:** 라이브 이벤트의 진행 상황에 맞춰 오래된 세그먼트를 자동으로 삭제하는 시간 기반 가비지 컬렉션을 수행하여 스토리지 공간을 효율적으로 유지합니다. * **실시간 모니터링:** 수천 개의 지표를 실시간으로 수집하여 파이프라인의 건강 상태를 추적하며, 장애 발생 시 즉각적인 대응이 가능한 가시성을 확보하고 있습니다. 라이브 오리진은 단순한 저장소를 넘어 라이브 스트리밍의 안정성을 결정짓는 지능형 브로커 역할을 수행합니다. 실시간 방송의 불확실성을 소프트웨어 계층의 이중화와 지능적 선택 로직으로 해결하고자 하는 기술적 접근은 대규모 라이브 서비스를 설계할 때 중요한 이정표가 됩니다. 특히 클라이언트의 복잡도를 낮추면서 서버 측에서 장애를 복구하는 설계 방식은 사용자 경험을 최우선으로 하는 서비스 기획에 필수적인 요소입니다.

AWS마이크로서비스live-streamingnginx+4

aws·2025년 12월 8일원문

AWS 주간 요약: AWS re (새 탭에서 열림)

AWS re:Invent 2025는 단순한 기술 발표를 넘어 AI 어시스턴트가 자율적인 'AI 에이전트'로 진화하는 중대한 변곡점을 시사했습니다. AWS는 개발자들에게 발명의 자유를 제공한다는 핵심 미션을 재확인하며, 자연어로 복잡한 작업을 수행하고 코드를 실행하는 에이전트 중심의 미래 비전을 제시했습니다. 이번 행사는 AI 투자가 실질적인 비즈니스 가치로 전환되는 시점에서 보안, 가용성, 성능이라는 클라우드의 본질적 가치를 다시 한번 강조했습니다. **AI 에이전트 중심의 비즈니스 혁신** * **어시스턴트에서 에이전트로의 진화:** 단순한 답변 제공을 넘어 스스로 계획을 세우고, 코드를 작성하며, 필요한 도구를 호출해 작업을 완수하는 자율형 에이전트가 핵심 기술로 부상했습니다. * **실질적 비즈니스 수익 창출:** AI가 단순한 실험 단계를 지나 기업의 업무를 자동화하고 효율성을 높임으로써 구체적인 재무적 성과를 내기 시작하는 단계에 진입했습니다. * **비결정적 특성에 최적화된 인프라:** 결과가 매번 다를 수 있는 AI 에이전트의 특성(Non-deterministic)을 고려하여, 안전하고 신뢰할 수 있으며 확장이 용이한 전용 인프라를 구축하고 있습니다. **아키텍트의 르네상스와 개발자 생태계** * **설계 역량의 재발견:** 기술적 세부 사항에 매몰되기보다 시스템 전체를 조망하고 설계하는 고수준 아키텍처 역량이 중요해진 '아키텍트의 르네상스' 시대가 도래했습니다. * **커뮤니티 기여의 가치:** 필리핀의 AWS 히어로 라피(Rafi)가 'Now Go Build' 상을 수상한 사례를 통해, 기술 혁신만큼이나 커뮤니티 빌딩과 개발자 역량 강화가 중요함을 강조했습니다. * **발명의 자유(Freedom to Invent):** 지난 20년간 AWS의 중심이었던 개발자들이 창의성을 발휘할 수 있도록 도구와 환경을 제공하는 것이 AWS의 변함없는 목표임을 천명했습니다. **클라우드 기반 기술의 지속적 고도화** * **커스텀 실리콘과 인프라:** 보안, 가용성, 성능이라는 클라우드의 기본 속성을 유지하면서도 AI 워크로드에 최적화된 하드웨어 혁신을 지속하고 있습니다. * **자연어 기반 솔루션 구현:** 사용자가 달성하고자 하는 목적을 자연어로 설명하면 시스템이 실행 가능한 솔루션으로 변환하는 인터페이스의 혁신이 가속화되고 있습니다. AI 에이전트가 주도하는 기술 환경 변화에 대응하기 위해, 기업들은 단순한 챗봇 도입을 넘어 비즈니스 프로세스 자체를 자동화할 수 있는 에이전트 활용 전략을 수립해야 합니다. AWS re:Invent 2025의 주요 세션 영상과 발표 자료가 온디맨드로 제공되고 있으므로, 조직의 요구 사항에 맞는 AI 아키텍처를 재설계하고 새로운 기술 도구들을 선제적으로 검토해 보시길 권장합니다.

AWSAIAI 에이전트머신러닝+3

aws·2025년 12월 3일원문

Amazon SageMaker HyperPod에서 (새 탭에서 열림)

Amazon SageMaker HyperPod은 대규모 AI 모델 학습의 효율성을 극대화하기 위해 '체크포인트리스(Checkpointless) 학습'과 '엘라스틱(Elastic) 학습' 기능을 새롭게 출시했습니다. 이 기술들은 하드웨어 장애 발생 시 복구 시간을 획기적으로 단축하고 클러스터 자원 활용도를 자동 최적화하여 전체 개발 주기를 대폭 앞당깁니다. 이를 통해 엔지니어는 인프라 관리 부담에서 벗어나 모델 성능 고도화와 시장 출시 속도 향상에 더욱 집중할 수 있습니다. ### 체크포인트리스 학습을 통한 중단 없는 상태 복구 기존의 체크포인트 기반 복구는 작업 종료, 재시작, 네트워크 설정, 체크포인트 검색 및 로드 등 복잡한 단계를 거치느라 최대 1시간 이상의 다운타임이 발생하곤 했습니다. 체크포인트리스 학습은 이러한 병목 현상을 해결하기 위해 다음과 같은 기술적 요소를 도입했습니다. * **피어 투 피어(P2P) 상태 복제**: 모델의 상태를 클러스터 내의 건강한 노드(Peer)에 실시간으로 복제하여 저장하며, 장애 발생 시 체크포인트를 불러오는 대신 이웃 노드로부터 즉시 상태를 복구합니다. * **복구 시간 단축**: 전통적인 방식 대비 복구 시간을 분 단위로 줄였으며, 내부 테스트 결과 2,000개 이상의 GPU 환경에서도 다운타임을 80% 이상 감소시키는 성과를 보였습니다. * **4가지 핵심 구성 요소**: 집합 통신 초기화 최적화, 캐싱이 가능한 메모리 매핑 데이터 로딩, 프로세스 내 복구(In-process recovery), 그리고 P2P 상태 복제 기술이 유기적으로 결합되어 작동합니다. * **검증된 확장성**: 수만 개의 가속기를 활용한 Amazon Nova 모델 학습에 이미 성공적으로 적용되어 대규모 환경에서의 안정성을 입증했습니다. ### 자원 활용을 극대화하는 엘라스틱 학습 엘라스틱 학습은 클러스터의 가용 자원 상태에 따라 학습 워크로드의 규모를 유연하게 조절하는 기능입니다. 인프라의 가변적인 상황에 맞춰 학습 효율을 최대로 끌어올립니다. * **자동 확장 및 축소**: 클러스터 내에 유휴 자원이 발생하면 학습 규모를 자동으로 확장하고, 추론 서비스와 같은 고우선순위 작업이 몰릴 때는 자원을 즉시 반납하며 축소합니다. * **운영 효율성**: 매주 수동으로 인프라 설정을 변경하던 엔지니어링 시간을 절약할 수 있으며, 클러스터 활용도를 높여 전체 학습 완료 시간을 단축합니다. * **우선순위 기반 할당**: 비즈니스 요구사항에 따라 자원을 재배치함으로써 고비용의 컴퓨팅 자원을 낭비 없이 사용할 수 있도록 지원합니다. ### 실용적인 권장 사항 수천 개의 GPU를 사용하는 초거대 모델 학습 환경에서는 하드웨어 장애가 빈번하게 발생할 수밖에 없습니다. 인프라 장애로 인한 학습 중단 리스크를 최소화하고 싶은 팀은 SageMaker HyperPod의 체크포인트리스 학습을 도입하여 복구 골든타임을 확보할 것을 권장합니다. 특히 가변적인 인프라 환경에서 비용 효율성을 중시한다면 엘라스틱 학습 기능을 활성화하여 클러스터 유휴 자원을 100% 활용하는 전략이 유효할 것입니다.

AWSAI머신러닝클라우드 컴퓨팅+5

aws·2025년 12월 2일원문

AWS 데이터베이스용 Database Savings Plans를 (새 탭에서 열림)

AWS는 관리형 데이터베이스 서비스의 비용을 최대 35%까지 절감할 수 있는 새로운 요금 모델인 'Database Savings Plans'를 출시했습니다. 사용자는 1년 동안 일정 금액의 시간당 지출($/hour)을 약정함으로써, 특정 리전이나 엔진에 국한되지 않고 다양한 데이터베이스 리소스에 대해 자동적인 할인 혜택을 받을 수 있습니다. 이 플랜은 클라우드 현대화나 글로벌 확장 과정에서 데이터베이스 환경이 변하더라도 유연하게 비용 최적화를 유지할 수 있도록 설계되었습니다. **Database Savings Plans의 핵심 가치와 유연성** * **시간당 약정 모델:** 1년 기간 동안 일정액의 시간당 사용량을 약정하며, 약정 금액을 초과하는 사용분은 일반 온디맨드 요금으로 청구됩니다. * **광범위한 유연성:** 특정 리전, 인스턴스 제품군, 크기에 얽매이지 않고 지원되는 모든 데이터베이스 서비스에 할인이 자동 적용됩니다. * **현대화 지원:** 프로비저닝 방식에서 서버리스로 전환하거나, 데이터베이스 엔진을 변경(예: 상용 DB에서 오픈소스 기반 Aurora로 전환)하더라도 할인 혜택이 중단 없이 유지됩니다. **서비스별 지원 범위 및 할인율 상세** * **지원 서비스:** Amazon Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, AWS DMS 등 주요 관리형 데이터베이스를 모두 포함합니다. * **배포 모델별 혜택:** 서버리스 배포의 경우 온디맨드 대비 최대 35%, 프로비저닝된 인스턴스는 최대 20%의 할인율이 적용됩니다. * **처리량 기반 할인:** DynamoDB 및 Keyspaces의 온디맨드 처리량은 최대 18%, 프로비저닝된 용량은 최대 12%의 비용 절감이 가능합니다. **구매 및 운영 관리** * **통합 관리:** AWS Billing 및 비용 관리 콘솔을 통해 구매 프로세스를 진행할 수 있으며, 기존의 비용 관리 도구로 활용률(Utilization)과 커버리지를 분석할 수 있습니다. * **자동 업데이트:** 향후 새로운 데이터베이스 엔진, 인스턴스 유형 또는 신규 리전이 출시될 경우에도 별도의 조치 없이 Savings Plans 혜택이 자동으로 확장 적용됩니다. **실용적인 권장 사항** 1년 이상의 장기적인 워크로드를 운영하거나, 마이크로서비스 아키텍처 도입으로 인해 여러 종류의 데이터베이스를 혼용하는 기업에게 매우 유리합니다. 특히 서버리스로의 전환이나 리전 확장을 계획 중이라면, 기존의 예약 인스턴스(RI)보다 훨씬 유연한 이 플랜을 통해 관리 부담을 줄이면서 비용 효율을 극대화할 수 있습니다.

AWS서버리스amazon-rdsamazon-dynamodb+4

aws·2025년 12월 2일원문

전문가 지원에 AI 기능을 더한 (새 탭에서 열림)

AWS는 고객 지원 모델을 기존의 사후 대응 방식에서 사전 예방적 문제 해결 방식으로 전환하기 위해 AI 역량이 강화된 새로운 지원 플랜을 도입했습니다. 이번 개편은 생성형 AI 기술과 AWS 전문가의 가이드를 결합하여 비즈니스에 영향이 생기기 전 잠재적 문제를 식별하고 클라우드 워크로드를 최적화하는 데 중점을 둡니다. 고객은 운영 규모와 비즈니스 요구 사항에 맞춰 세분화된 세 가지 플랜을 통해 더 빠른 응답 시간과 맥락 중심의 지원을 받을 수 있습니다. ### AI 기반의 지능형 지원, Business Support+ * 개발자, 스타트업 및 중소기업을 대상으로 하며, AI 기반의 맥락 맞춤형 권장 사항을 제공하여 문제 해결 속도를 높입니다. * 비즈니스 크리티컬한 사례에 대해 이전보다 2배 빨라진 30분 이내의 응답 시간을 보장합니다. * AI 도구로 상담을 시작하더라도 필요 시 상담 맥락을 그대로 유지한 채 AWS 전문가에게 원활하게 연결되어 반복적인 설명 없이 지원을 이어갈 수 있습니다. ### 데이터 기반의 지능형 운영, Enterprise Support * 지정된 기술 고객 관리자(TAM)가 AI 기반의 통찰력과 고객 환경의 데이터를 결합하여 운영 위험을 사전에 식별하고 최적화 기회를 제안합니다. * 보안 사고 대응 서비스(AWS Security Incident Response)가 추가 비용 없이 포함되어 보안 이벤트의 중앙 집중식 추적 및 자동화된 모니관링이 가능해집니다. * 운영 환경에 치명적인 문제가 발생할 경우 최대 15분 이내의 응답 속도를 제공하며, 지원 엔지니어는 AI 에이전트가 정리한 고객 맞춤형 맥락을 바탕으로 신속하게 대응합니다. ### 미션 크리티컬을 위한 통합 운영 지원, Unified Operations Support * TAM, 도메인 엔지니어, 청구 및 계정 전문가로 구성된 전담 팀이 고객의 고유한 운영 이력을 바탕으로 가장 높은 수준의 맥락 맞춤형 지원을 제공합니다. * 24시간 상시 모니터링과 AI 기반 자동화 시스템을 통해 위험을 선제적으로 차단하며, 마이그레이션이나 보안 전문가를 온디맨드로 호출할 수 있습니다. * 최우선 순위 사고 발생 시 5분 이내에 응답하는 가장 빠른 서비스 수준 계약(SLA)을 제공하여 비즈니스 연속성을 극대화합니다. 클라우드 운영의 복잡성이 증가함에 따라 단순히 문제가 터졌을 때 해결하는 것을 넘어, AI의 분석력과 전문가의 통찰력을 결합한 사전 관리형 지원을 선택하는 것이 중요해졌습니다. 단순 개발 환경이라면 Business Support+가 경제적이지만, 보안이 중요하거나 중단 없는 서비스가 핵심인 기업이라면 Enterprise 이상의 플랜을 통해 AI와 전담 인력의 통합 관리를 받는 것이 권장됩니다.

AWSAIincident-managementcloud-monitoring+3

aws·2025년 12월 2일원문

Amazon OpenSearch Service, GPU (새 탭에서 열림)

Amazon OpenSearch Service가 벡터 데이터베이스의 성능을 극대화하고 비용을 절감하기 위해 서버리스 GPU 가속 및 자동 최적화 기능을 도입했습니다. 이 기능을 통해 사용자는 수십억 건 규모의 벡터 인덱스를 기존보다 최대 10배 빠른 속도와 4분의 1 수준의 비용으로 구축할 수 있으며, 복잡한 수동 튜닝 없이도 최적의 검색 품질을 유지할 수 있습니다. 결과적으로 생성형 AI 애플리케이션 개발에 필요한 대규모 벡터 검색 환경을 훨씬 더 경제적이고 효율적으로 운영할 수 있게 되었습니다. **GPU 가속을 통한 대규모 벡터 데이터베이스 구축** * **성능 및 비용 혁신:** 비가속 환경 대비 인덱싱 속도는 10배 빨라진 반면, 관련 비용은 75%까지 절감되었습니다. 이를 통해 10억 개 규모의 벡터 데이터베이스를 1시간 이내에 생성할 수 있는 놀라운 확장성을 제공합니다. * **서버리스 관리 모델:** 사용자가 직접 GPU 인스턴스를 할당하거나 관리할 필요가 없으며, 실제 처리량에 따른 OCU(OpenSearch Compute Units) 단위로만 비용을 지불하면 됩니다. * **보안 및 통합:** 가속화된 작업은 사용자의 VPC(Amazon Virtual Private Cloud) 내에서 안전하게 격리되어 실행되며, 기존 OpenSearch 서비스의 워크플로우 내에서 자연스럽게 통합됩니다. **자동 최적화(Auto-optimization) 기반 성능 튜닝** * **자동화된 균형 탐색:** 벡터 데이터의 특성에 맞춰 검색 지연 시간, 검색 품질(재현율), 메모리 요구 사항 사이의 최적의 균형점을 시스템이 자동으로 찾아냅니다. * **전문성 장벽 완화:** 과거에는 벡터 인덱스 최적화에 몇 주간의 수동 튜닝과 전문 지식이 필요했으나, 이제는 설정 하나만으로 기본 구성보다 뛰어난 비용 효율성과 재현율을 확보할 수 있습니다. * **유연한 적용 범위:** 새 도메인이나 컬렉션을 생성할 때는 물론, 기존에 운영 중인 환경에서도 설정을 업데이트하여 즉시 최적화 기능을 활성화할 수 있습니다. **실제 적용 방법 및 권장 사항** 생성형 AI 애플리케이션이나 대규모 지식 베이스를 구축하려는 개발자는 AWS 콘솔의 '고급 기능' 섹션에서 GPU 가속을 활성화하는 것만으로 즉시 성능 향상을 경험할 수 있습니다. 기술적으로는 인덱스 설정 시 `index.knn.remote_index_build.enabled` 옵션을 `true`로 설정하여 GPU 기반의 원격 인덱스 빌드를 활성화할 것을 권장하며, 이를 통해 대량의 데이터를 벌크(Bulk) API로 처리할 때 최적의 가속 효과를 얻을 수 있습니다.

AWSAI생성형 AIvector-db+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 인스턴스를 도입하여 데이터 처리 및 저장 비용을 획기적으로 낮추었습니다. 클라우드 비용 관리는 단순히 지출을 줄이는 작업을 넘어, 인프라를 얼마나 더 똑똑하고 효율적으로 활용하느냐에 대한 기술적 성숙도를 의미합니다. 조직 전체가 비용에 대한 주인의식을 갖고 데이터를 바탕으로 리소스를 관리할 때, 비즈니스의 성장과 인프라의 지속 가능성을 동시에 확보할 수 있습니다.

AWSamazon-ec2amazon-s3finops+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 인스턴스 같은 클라우드 고유의 가변 비용 모델을 적극적으로 활용할 것을 권장합니다.

AWSamazon-s3finopsamazon-athena+4

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 사례처럼 샤드별 지연 시간보다 실제 사용자 요청의 전체 지연 시간을 기준으로 병목을 찾아야 하며, 권한 필터 생성과 결과 검증도 검색 성능의 핵심 구성 요소로 다뤄야 한다.

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

AWS옵저버빌리티elasticsearchopensearch+2

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

Figma 및 FigJam 파일용

Figma는 유럽 고객의 데이터 보호와 규제 준수를 지원하기 위해 Figma·FigJam 파일을 EU 내에 호스팅하는 선택권을 제공하기 시작했습니다. 파일 데이터의 주 저장 위치는 독일 프랑크푸르트, 백업 위치는 아일랜드 더블린이며 AWS 인프라를 사용합니다. 다만 모든 데이터가 EU에 저장되는 것은 아니며, 이 기능은 Figma Enterprise 고객에게만 제공됩니다. ## EU 데이터 호스팅 도입 배경 - 유럽 조직은 GDPR을 비롯한 데이터 보호·개인정보 규제를 중요하게 고려하고 있습니다. - Figma는 EU Cloud Code of Conduct 준수 마크를 획득했으며, 기존 보안·개인정보 보호 체계를 강화하는 차원에서 EU 데이터 레지던시를 도입했습니다. - Volkswagen Group도 설계 도구의 데이터가 EU 내에 저장되는 기능을 데이터 보호 측면에서 중요한 요구사항으로 평가했습니다. - EU 호스팅을 이용하면 클라우드 기반 플랫폼의 확장성과 효율성을 유지하면서 데이터 저장 위치를 보다 세밀하게 통제할 수 있습니다. ## EU에 저장되는 데이터 - 초기 대상은 Figma 및 FigJam 파일의 문서 콘텐츠입니다. - 지원되는 파일 유형과 저장 범위는 Figma의 별도 도움말 문서에서 확인해야 합니다. - 파일 데이터의 실제 저장 위치는 다음과 같습니다. - 주 저장소: 독일 프랑크푸르트 - 백업 저장소: 아일랜드 더블린 - 인프라는 기존 클라우드 제공업체인 AWS를 사용합니다. ## EU에 포함되지 않는 데이터 - 사용자 메타데이터와 로그인 데이터는 EU 내에 호스팅되지 않습니다. - 데이터 전송 과정에서 생성되는 일부 데이터는 제한된 기간 동안 EU 외부에 임시 저장될 수 있습니다. - 따라서 “EU 호스팅”은 모든 Figma 관련 데이터가 EU 국경 밖으로 나가지 않는다는 의미가 아니라, 특정 파일 콘텐츠의 저장 위치를 EU로 제한하는 기능입니다. - 조직은 도입 전에 파일 유형별 EU 저장 가능 여부와 제외되는 데이터 범위를 확인해야 합니다. ## 이용 대상과 기존 파일 마이그레이션 - EU 데이터 호스팅은 Figma Enterprise 요금제 고객에게만 제공됩니다. - 기존 고객도 Enterprise로 이용 중이거나 Enterprise로 업그레이드하면 미국에서 EU로 기존 파일을 이전할 수 있습니다. - 마이그레이션 일정은 Figma 계정 관리자가 고객과 조율합니다. - Enterprise 업그레이드 후 데이터 이전 대기 목록에 등록할 수 있습니다. - 다른 요금제 고객은 Enterprise 데모나 상담을 신청해야 합니다. ## 보안 및 규제 준수 체계 EU 데이터 레지던시는 Figma의 기존 보안 인증과 함께 제공됩니다. - SOC 2 Type II 보고서 - ISO 27018 및 ISO 27001 인증 - EU Cloud Code of Conduct Level 2 준수 ## 도입 시 고려할 점 EU 내 파일 저장이 법적·조직적 요구사항에 부합하는지 검토하려면 저장 대상 데이터, EU 외부에 남는 메타데이터, 전송 중 임시 저장 가능성, 마이그레이션 범위를 함께 확인해야 합니다. EU 데이터 주권과 파일 위치 통제가 중요한 대기업이라면 Enterprise 요금제와 공식 파일 유형별 저장 정책을 기준으로 도입 여부를 판단하는 것이 적절합니다.

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

AWSFigmafigjamdata-residency+3

datadog·2022년 4월 13일원문

언제나 DNS 문제다… 그렇지 않은 경우를 제외하면: gRPC, Kubernetes, AWS 네트워킹 심층 분석 (새 탭에서 열림)

데이터독(Datadog)의 엔지니어들이 서비스 업데이트 중 발생한 원인 불명의 DNS 에러를 추적하며, 쿠버네티스 네트워킹과 AWS VPC 환경의 복잡한 상호작용을 해결해 나가는 과정을 다룬 글입니다. 로그상으로는 단순한 DNS 문제처럼 보였으나, 실제 원인은 AWS VPC의 연결 추적(conntrack) 한계와 하위 네트워크 레이어의 패킷 드랍에 있었습니다. 이 글은 고도화된 인프라 환경에서 단순히 리소스를 증설하는 것보다 커널 수준의 메트릭과 VPC 플로우 로그를 통한 심층 분석이 왜 중요한지를 잘 보여줍니다. **DNS 오류의 표면적 원인과 NodeLocal DNSCache** * 서비스 배포 시마다 DNS 에러가 발생하여 쿼리 지연과 모니터링 성능 저하가 나타났습니다. * 쿠버네티스의 `node-local-dns`가 메모리 부족(OOM) 및 최대 동시 요청 수(`max_concurrent`) 제한인 1,000개에 도달하여 요청을 거부하는 현상이 발견되었습니다. * 하지만 실제 초당 쿼리 수(QPS)는 예상 용량보다 훨씬 낮았으며, 이는 상위 DNS 리졸버와의 TCP 연결 실패로 인해 타임아웃이 발생하면서 동시 요청 슬롯이 빠르게 점유되었기 때문임이 밝혀졌습니다. **AWS VPC 연결 추적(conntrack)과 패킷 드랍** * 네트워크 성능을 정밀하게 확인하기 위해 AWS ENA(Elastic Network Adapter) 메트릭을 분석한 결과, `conntrack_allowance_exceeded` 수치가 급증한 것을 확인했습니다. * VPC 수준의 연결 추적 테이블(Hypervisor 레벨)이 포화 상태에 도달하면 보안 그룹 등의 상태 저장을 위한 연결 생성이 불가능해져 패킷이 드랍됩니다. * 특이하게도 인스턴스 내부의 리눅스 conntrack 엔트리는 6만 개 미만으로 안정적이었으나, VPC 레벨의 conntrack은 이미 한계에 도달하여 두 레이어 간의 가시성 차이가 존재함을 발견했습니다. **VPC 플로우 로그를 통한 심층 분석** * 인스턴스 유형을 상위 모델로 변경하여 임시적으로 문제를 해결할 수 있었으나, 근본 원인 파악을 위해 VPC 플로우 로그 분석을 병행했습니다. * Cilium, 쿠버네티스, AWS 네트워킹이 결합된 환경에서는 역경로 필터링(Reverse Path Filtering)이 정상적인 패킷을 'Martian packet'(출처가 불분명한 패킷)으로 오인하여 드랍하는 등 복잡한 문제가 발생할 수 있음을 시사했습니다. * DNS 전파 시간과 네트워크 마이크로버스트(Traffic Spikes) 역시 이러한 연결 추적 테이블 포화에 기여하는 핵심 요소임을 확인했습니다. **실용적인 결론** 단순히 로그에 나타나는 "DNS 에러"에만 집중하기보다, AWS ENA 메트릭의 `conntrack_allowance_exceeded`나 VPC 플로우 로그와 같은 하위 레이어의 지표를 함께 모니터링해야 합니다. 특히 대규모 쿠버네티스 클러스터를 운영한다면, 인스턴스 크기에 따른 VPC 수준의 conntrack 제한 수치를 미리 파악하고 적절한 인프라 사이징과 네트워크 정책 설정을 검토해야 합니다.

AWS데이터베이스 설계쿠버네티스PostgreSQL+4

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

Figma의 인프라: 웹

Figma는 웹 기반 디자인 도구도 데스크톱 애플리케이션 수준의 속도와 안정성을 제공해야 한다고 주장한다. 이를 위해 클라우드 기반의 단일 진실 공급원, 실시간 협업, 프로토타이핑과 개발자 핸드오프를 통합했으며, 사용자와 데이터가 증가함에 따라 인프라를 확장 가능한 구조로 전환하고 있다. 핵심 과제는 불필요한 데이터 로딩을 줄이고, 데이터베이스를 수평 확장하며, 전 세계 사용자의 지연 시간을 낮추는 것이다. ## Figma가 해결하려는 문제 - 기존 디자인 작업은 특정 데스크톱 애플리케이션과 플랫폼에 종속됐다. - 파일을 내보내거나 여러 도구 사이에서 옮기는 과정에서 최신 버전 관리와 협업이 어려웠다. - Figma는 디자인 파일을 클라우드에 저장하고 고유 URL을 부여해 팀 전체의 단일 진실 공급원으로 만든다. - 프로토타이핑과 개발자 핸드오프 기능을 제품 안에 포함해 별도 도구와 파일 변환의 필요성을 줄였다. ## 실시간 협업과 인프라 요구사항 - 여러 사용자가 하나의 파일을 동시에 보고 편집할 수 있는 멀티플레이어 기능을 제공한다. - 디자인 파일에는 복잡한 도형과 대용량 이미지가 포함될 수 있어 백엔드와 네트워크로 전송되는 데이터가 많다. - 사용자는 데스크톱 도구와 같거나 더 나은 상호작용 성능을 기대한다. - 따라서 인프라는 다음 요구사항을 동시에 충족해야 한다. - 낮은 상호작용 지연 시간 - 높은 가용성 - 대규모 파일과 동시 접속 처리 - 실시간 변경사항 동기화 ## 초기 인프라의 한계 - 초기 Figma는 단순한 백엔드 구조를 사용해 빠르게 제품을 개발하고 운영했다. - 예를 들어 파일을 로드할 때 사용자가 접근 가능한 공유 컴포넌트를 모두 미리 불러왔다. - 공유 디자인 요소가 수천 개일 때는 효과적이었지만, 조직의 라이브러리가 약 1만 개에 가까워지면 백엔드에 큰 부담이 발생했다. - Microsoft, Uber 같은 대규모 조직의 도입과 글로벌 사용자 증가로 이러한 문제가 일반적인 확장성 문제로 나타났다. ## 필요한 데이터만 불러오는 구조 - 기존 시스템은 사용자가 실제로 즉시 필요로 하지 않는 데이터까지 파일 로드 시점에 미리 가져오는 경우가 있었다. - 이 방식은 초기 진입 속도와 백엔드 부하 모두에 악영향을 준다. - 단순히 서버 성능만 개선하는 것으로는 해결되지 않으며, 클라이언트와 서버 간 상호작용 방식을 다시 설계해야 한다. - 클라이언트가 필요한 정보만 요청하도록 제품의 데이터 로딩 방식과 사용자 경험을 함께 바꿔야 한다. - 인프라 팀뿐 아니라 제품과 클라이언트 개발팀의 협업이 필요한 문제다. ## 단일 데이터베이스에서 수평 확장으로 - 당시 Figma의 전체 인프라는 AWS의 매우 강력한 단일 데이터베이스 인스턴스에 의존했다. - 단순한 구조를 선호하는 KISS 원칙 덕분에 초기에는 운영이 쉬웠고 빠르게 성장할 수 있었다. - 그러나 단일 인스턴스는 성능과 용량 확장에 한계가 있다. - 다음 단계에서는 여러 노드로 확장할 수 있는 수평 확장형 데이터베이스 계층을 구축하려 했다. - 데이터베이스를 거의 모든 시스템과 서비스가 사용하므로, 일관성·장애 처리·서비스 의존성까지 함께 재설계해야 하는 대규모 작업이다. ## 글로벌 사용자의 지연 시간 개선 - 주간 활성 사용자의 80% 이상이 미국 외 지역에 있었다. - 당시 요청은 미국 오리건의 데이터센터까지 왕복해야 했기 때문에, 사용자 경험이 물리적 네트워크 거리에 영향을 받았다. - 이를 개선하기 위해 사용자와 가까운 곳에 인프라 구성 요소를 배치하려 했다. - 첫 단계로 전 세계 주요 지역에 원격 프록시를 전략적으로 배치해 데이터센터까지의 네트워크 지연을 줄이는 방안을 추진했다. - 장기적으로는 글로벌 사용자에게 더 가까운 위치에서 요청을 처리하는 방향으로 인프라를 발전시키려 했다. ## 실용적인 결론 웹 기반 협업 도구의 확장은 서버를 더 큰 장비로 교체하는 것만으로 해결되지 않는다. 필요한 데이터만 지연 로딩하고, 데이터베이스를 수평 확장하며, 사용자가 가까운 위치에서 서비스를 이용하도록 네트워크 구조를 개선하는 등 제품 경험과 시스템 아키텍처를 함께 재설계해야 한다.

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

AWSreal-time-collaboration분산 시스템성능 최적화+2

datadog·2019년 4월 2일원문

Datadog에서 고신뢰성 데이터 파이프라인 구축하기 (새 탭에서 열림)

데이터독(Datadog)은 매일 수조 건의 데이터를 처리하며 시스템의 신뢰성을 '정해진 시간 내에 정확한 결과물을 출력할 확률'로 정의합니다. 이들은 파이프라인의 장애를 완전히 막는 대신, 장애가 발생하더라도 데이터 전달 기한을 지킬 수 있도록 결함 허용(Fault Tolerance)과 빠른 복구에 초점을 맞춘 아키텍처를 구축했습니다. 특히 개별 작업 단위로 클러스터를 분리하고 장시간 실행되는 작업을 작게 쪼개는 전략을 통해 대규모 데이터 처리의 안정성을 확보하고 있습니다. ### 작업 격리를 위한 개별 클러스터 아키텍처 * 하나의 거대한 공유 클러스터를 사용하는 대신, 각 데이터 파이프라인 작업마다 독립적인 전용 클러스터를 할당하여 운영합니다. * 작업 간 리소스 경쟁을 원천 차단하여 특정 작업의 부하가 다른 파이프라인에 영향을 주지 않으며, 클러스터별 상태를 명확히 파악할 수 있어 모니터링이 용이합니다. * 작업의 특성에 따라 CPU 최적화 인스턴스나 메모리 최적화 인스턴스를 선택하는 등 하드웨어를 유연하게 튜닝할 수 있습니다. * 새로운 버전의 Hadoop이나 Spark를 도입할 때 전체 시스템을 중단할 필요 없이, 특정 클러스터부터 점진적으로 업그레이드하며 버그나 호환성을 테스트할 수 있습니다. ### 스팟 인스턴스 활용과 실패를 고려한 설계 * 비용 절감을 위해 AWS 스팟 인스턴스를 적극 활용하며, 이는 클러스터가 언제든 중단될 수 있다는 전제하에 파이프라인을 설계하도록 강제하는 '카오스 엔지니어링'의 효과를 줍니다. * 단일 작업의 실행 시간이 길어질수록 실패 시 손실되는 작업량과 복구 시간이 늘어나므로, 이를 방지하기 위해 작업을 수직적·수평적으로 세분화합니다. * **수직적 분할:** 데이터 변환 과정을 여러 단계의 작업으로 나누고, 단계 사이의 중간 데이터를 S3에 저장(Checkpointing)하여 실패 시 처음부터 다시 시작하지 않고 중간 지점부터 재개할 수 있게 합니다. * **수평적 분할:** 입력 데이터를 샤드(Shard) 단위로 파티셔닝하여 여러 작업이 병렬로 처리하게 함으로써 개별 작업의 규모를 작게 유지합니다. ### 롤업(Rollup) 파이프라인의 최적화 사례 * 과거 14시간 이상 소요되던 단일 메트릭 집계 작업을 '집계' 단계와 '커스텀 포맷 저장' 단계로 분리하여 관리합니다. * 첫 번째 집계 작업의 결과물을 S3에 Parquet 파일로 저장함으로써, 두 번째 단계에서 장애가 발생하더라도 집계 과정을 다시 반복할 필요가 없습니다. * Kafka 파티션 구조를 기반으로 데이터를 샤딩하여, 데이터 규모가 급증하거나 특정 샤드에 문제가 발생했을 때 해당 부분만 격리하여 리소스를 집중 투입하거나 빠르게 복구할 수 있습니다. * 이러한 구조는 작업 시작 오버헤드나 S3 쓰기 비용을 발생시키지만, 장애 복구 시간을 단축하고 전체 시스템의 데이터 가용성을 보장하는 데 결정적인 역할을 합니다. 대규모 데이터 시스템에서 신뢰성은 시스템이 절대 중단되지 않는 것이 아니라, 중단되었을 때 얼마나 빠르게 복구되어 사용자에게 제때 데이터를 전달하느냐에 달려 있습니다. 이를 위해 파이프라인을 최대한 작고 독립적인 단위로 쪼개고 중간 상태를 유지하는 설계는 복잡한 데이터 환경에서 필수적인 전략입니다.

AWS데이터베이스 설계PostgreSQLmonitoring+4