aws2026년 5월 25일

AWS 주간 요약: 이스탄불의 AWS 로컬 영역, 오픈 소스 ExtendDB, Kiro Web 등 (2026년 5월 25일) | Amazon Web Services (새 탭에서 열림)

AWS는 이번 주 지역 인프라 확장, 보안·AI 개발 편의성 강화, 오픈소스 생태계 확대에 집중했다. 특히 튀르키예 이스탄불 Local Zone은 데이터 주권과 낮은 지연 시간이 중요한 기업에 새로운 아키텍처 선택지를 제공하며, SageMaker의 OpenAI 호환 API와 ExtendDB는 기존 애플리케이션의 AWS 이전 및 데이터 계층 이식성을 높인다. 또한 Kiro Web, Secrets Manager Agent 개선, SDK 재시도 정책 변경 등 개발·운영 효율을 높이는 업데이트도 소개됐다. ## 이스탄불 AWS Local Zone 개설 - AWS가 튀르키예 이스탄불에 새로운 Local Zone을 개설했다. - AWS 리전의 인프라를 대도시와 사용자 가까이에 배치해 다음을 지원한다. - 단일 자릿수 밀리초 수준의 지연 시간 - 특정 국가 내 데이터 저장·처리 - 금융, 정부, 통신, 의료 분야의 데이터 레지던시 및 규정 준수 - 튀르키예 기업은 데이터를 국경 안에 저장하고 백업하면서, 지연 시간에 민감한 워크로드를 이스탄불에서 실행할 수 있다. - 이스탄불 Local Zone은 AWS 리전과 연결되므로, 자체 데이터센터를 운영하지 않고도 Local Zone과 리전을 결합한 하이브리드 애플리케이션을 구성할 수 있다. - Local Zone은 하드웨어, 전력, 네트워크, 운영 체계 측면에서 높은 수준의 인프라 투자가 필요한 서비스다. ## 보안 및 운영 업데이트 - **AWS Security Hub Extended** - 통합 가능한 파트너 보안 솔루션이 21개로 확대됐다. - 엔드포인트 보호, CSPM, 위협 인텔리전스 등 9개 보안 영역을 다룬다. - AWS 및 서드파티 도구의 보안 탐지 결과를 Security Hub에서 통합·우선순위화할 수 있다. - 별도 커스텀 통합을 줄여 엔터프라이즈 보안 운영을 단순화한다. - **Secrets Manager Agent 개선** - 애플리케이션 시작 시 시크릿을 미리 가져오는 pre-fetch 기능이 추가됐다. - 요청 시 시크릿을 조회하면서 발생하던 콜드 스타트와 지연 시간을 줄일 수 있다. - IAM 역할을 맡아 시크릿을 조회할 수 있어, 서로 다른 권한 경계를 가진 워크로드 간 에이전트 공유가 쉬워졌다. - **AWS SDK 및 CLI 재시도 동작 변경** - 일시적 오류와 API throttling에 더 효과적으로 대응하도록 기본 재시도 로직이 개선됐다. - 더 지능적인 백오프 전략이 적용된다. - 별도 설정 변경 없이 프로덕션 애플리케이션의 복원력을 높일 수 있다. ## AI 개발 및 모델 이전 편의성 - **SageMaker AI의 OpenAI 호환 API** - SageMaker 추론 엔드포인트를 OpenAI API와 호환되는 방식으로 호출할 수 있다. - 기존 OpenAI용 SDK나 애플리케이션 코드를 크게 수정하지 않고 SageMaker로 전환할 수 있다. - 애플리케이션에서 엔드포인트 주소만 변경해 여러 모델 제공자나 AWS 인프라를 활용할 수 있다. - OpenAI 기반 프로토타입을 비용과 확장성을 고려한 SageMaker 환경으로 이전하는 장벽을 낮춘다. - **Amazon Bedrock 프롬프트 최적화 및 마이그레이션 도구** - 프롬프트를 자동으로 조정해 모델 성능을 개선한다. - 서로 다른 파운데이션 모델 사이에서 프롬프트를 이전하는 작업을 지원한다. - 프로덕션 AI 서비스의 프롬프트 품질을 반복적으로 개선하는 데 유용하다. - **Kiro Web** - AWS의 AI 기반 개발 환경 Kiro를 웹 브라우저에서 사용할 수 있게 됐다. - 데스크톱 IDE 설치 없이 스펙 기반 개발, AI 채팅, 에이전트 기능을 이용할 수 있다. - 다른 컴퓨터에서 빠르게 검토하거나 프로토타입을 제작하고, 팀에 Kiro 워크플로를 소개하기 쉬워졌다. ## ExtendDB와 데이터 계층의 이식성 - AWS가 **ExtendDB**를 오픈소스로 공개했다. - DynamoDB API와 데이터 모델을 사용하면서, 실제 저장소는 다른 백엔드 시스템으로 구성할 수 있는 어댑터다. - 주요 활용 사례는 다음과 같다. - 로컬 개발 및 테스트 환경에서 실제 AWS 연결 없이 DynamoDB API 사용 - 저장소 계층을 직접 제어해야 하는 환경 - DynamoDB 호환 의미론을 유지하면서 특정 백엔드에 종속되지 않는 구조 - 데이터 접근 계층의 이식성을 높이고, 개발·테스트 환경 구축 비용을 줄이는 데 도움이 된다. ## 서버리스 로컬 개발 개선 - AWS SAM CLI가 CloudFormation Language Extensions를 로컬에서 지원한다. - 로컬 개발 및 테스트 과정에서 다음과 같은 CloudFormation 기능을 사용할 수 있다. - 트랜스폼 - 동적 참조 - 기타 CloudFormation 언어 확장 기능 - 로컬 환경과 실제 배포 환경 사이의 기능 차이를 줄인다. - SAM 기반 서버리스 애플리케이션에서 로컬 테스트로 재현하기 어려웠던 엣지 케이스를 더 안정적으로 검증할 수 있다. ## 컨테이너 이미지 및 생태계 변경 - Amazon ECR Public에서 Bitnami 컨테이너 이미지가 제거될 예정이다. - ECR Public에서 Bitnami 이미지를 가져오는 워크로드는 영향을 받을 수 있다. - Bitnami 자체 레지스트리에서는 이미지가 계속 제공된다. - 운영 중인 이미지 참조를 Bitnami 레지스트리로 변경하고, 제거 일정과 마이그레이션 절차를 확인해야 한다. ## 예정된 AWS 행사 - AWS Summit Amsterdam: 5월 27일 개최 - AWS Summit Bangkok: 5월 28일 개최 - AWS Summit Milan: 5월 28일 개최 예정 - 클라우드·AI 세션, 실습, 네트워킹 등을 제공하며 유럽과 동남아시아 개발자 및 고객을 대상으로 한다. 실무적으로는 ECR Public의 Bitnami 이미지 의존성을 먼저 점검하고, OpenAI 호환 SageMaker API와 Secrets Manager Agent pre-fetch를 기존 서비스에 적용할 수 있는지 검토하는 것이 좋다. 튀르키예에서 서비스를 운영하거나 데이터 레지던시가 중요한 경우에는 이스탄불 Local Zone을 활용한 리전-Local Zone 아키텍처도 고려할 만하다.

dynamodbaiawsamazon-bedrock+4

aws2026년 3월 25일

수 초 만에 Amazon Aurora PostgreSQL 서버리스 데이터베이스 생성 기능 발표 | Amazon Web Services (새 탭에서 열림)

Amazon Aurora PostgreSQL Serverless의 '익스프레스 구성(Express Configuration)' 기능이 정식 출시되어, 이제 단 몇 초 만에 데이터베이스를 생성하고 사용할 수 있게 되었습니다. 이 기능은 복잡한 네트워크 설정과 인증 과정을 자동화하여 개발자가 아이디어를 즉시 애플리케이션으로 구현할 수 있는 환경을 제공합니다. 특히 인터넷 액세스 게이트웨이와 IAM 인증을 기본으로 설정해 보안과 편의성을 동시에 확보한 것이 핵심입니다. **익스프레스 구성을 통한 초고속 데이터베이스 생성** * 단 두 번의 클릭만으로 사전에 정의된 최적의 설정을 통해 Aurora PostgreSQL Serverless 인스턴스를 즉시 생성할 수 있습니다. * 생성 과정에서 용량 범위(Capacity range)를 조정하거나, 생성 후 읽기 복제본(Read Replica) 추가 및 파라미터 그룹 수정을 자유롭게 수행할 수 있습니다. * AWS CLI나 SDK 사용 시 `--with-express-configuration` 옵션을 추가하면 단 한 번의 API 호출로 클러스터와 인스턴스를 동시에 구축할 수 있어 자동화에 용이합니다. **복잡한 설정이 필요 없는 네트워크 및 보안 환경** * Amazon VPC를 직접 구성하거나 VPN, Direct Connect를 연결할 필요 없이, 새로운 '인터넷 액세스 게이트웨이(Internet Access Gateway)' 라우팅 계층을 통해 외부 개발 도구에서 즉시 접속이 가능합니다. * 이 게이트웨이는 여러 가용 영역(AZ)에 분산되어 있어 Aurora 클러스터와 동일한 수준의 고가용성을 보장하며 PostgreSQL 와이어 프로토콜을 지원합니다. * 기본적으로 AWS IAM 인증이 활성화되어 있어, 별도의 비밀번호 관리 없이도 안전한 '패스워드리스(Passwordless)' 인증 환경을 기본으로 제공합니다. **개발자 친화적인 연결 및 도구 통합** * AWS 콘솔 내에서 Python, Node.js, Go, TypeScript 등 다양한 언어별 연결 코드 스니펫을 제공하여 애플리케이션 코드에 즉시 반영할 수 있습니다. * AWS CloudShell을 통해 별도의 클라이언트 설치 없이 브라우저에서 바로 SQL 쿼리를 실행할 수 있는 통합 환경을 지원합니다. * Vercel의 'v0'와 같은 AI 기반 도구와 통합되어 자연어만으로 데이터베이스가 포함된 풀스택 애플리케이션을 신속하게 구축할 수 있습니다. 이제 Amazon Aurora가 AWS 프리티어(Free Tier) 범위에 포함되어 초기 비용 부담 없이 시작할 수 있습니다. 신속한 프로토타이핑이나 현대적인 서버리스 애플리케이션 개발이 필요한 경우, 익스프레스 구성을 활용해 인프라 설정 시간을 단축하고 비즈니스 로직 구현에 집중할 것을 추천합니다.

dynamodbdatabase-designpostgresqlserverless+4

dropbox2025년 12월 18일

Dropbox Dash의 실시간 (새 탭에서 열림)

Dropbox Dash는 흩어져 있는 업무 데이터를 통합하여 실시간으로 답변과 검색 결과를 제공하는 AI 도구이며, 이 시스템의 핵심은 머신러닝 모델에 필요한 데이터 신호인 '피처(Feature)'를 관리하고 전달하는 피처 스토어입니다. 수만 개의 문서 중 가장 관련성 높은 정보를 순위화하기 위해 드롭박스는 온프레미스와 클라우드가 결합된 하이브리드 인프라 위에서 초저지연 읽기와 실시간 데이터 업데이트가 가능한 독자적인 피처 스토어를 구축했습니다. 결과적으로 이 시스템은 수천 개의 피처를 병렬로 조회하면서도 100ms 미만의 응답 속도를 유지하여 사용자에게 최적화된 검색 경험을 제공합니다. ### 하이브리드 인프라를 위한 설계 목표와 요구사항 * **복합적인 인프라 환경 대응:** 저지연 통신을 위한 온프레미스 에코시스템과 대규모 데이터 처리를 위한 Spark 기반 클라우드 환경을 동시에 지원해야 했습니다. * **대규모 병렬 조회 처리:** 사용자 쿼리 하나당 수천 건의 피처 룩업(Lookup)이 발생하므로, 엄격한 지연 시간 예산 내에서 막대한 병렬 읽기를 처리할 수 있는 구조가 필요했습니다. * **실시간성 확보:** 사용자의 최근 행동(문서 열람, 채널 참여 등)이 몇 초 내에 다음 검색 결과에 반영될 수 있도록 빠른 데이터 수집 파이프라인이 요구되었습니다. * **통합 프레임워크 구축:** 실시간 스트리밍과 배치 처리를 통합하여 엔지니어가 아이디어 단계부터 실제 배포까지 빠르게 진행할 수 있는 환경을 목표로 했습니다. ### Feast와 Dynovault를 활용한 아키텍처 설계 * **Feast 프레임워크 채택:** 피처 정의와 인프라 구현을 분리하고 모듈화된 어댑터 생태계를 가진 Feast를 선택하여 인프라 복잡성을 추상화했습니다. * **Dynovault 활용:** 드롭박스 자체 개발 DynamoDB 호환 스토리지인 Dynovault를 온라인 저장소로 사용하여 공용 인터넷 호출 없이 약 20ms의 클라이언트 지연 시간을 달성했습니다. * **관측 가능성 강화:** 작업 실패 모니터링, 데이터 신선도 추적, 데이터 계보(Lineage) 가시성 등을 추가하여 안정적인 운영 기반을 마련했습니다. ### Go 언어 재작성을 통한 성능 최적화 * **Python SDK의 한계 극복:** 초기 Python 기반 구현에서는 JSON 파싱 속도와 GIL(Global Interpreter Lock)로 인해 동시성 처리에 병목이 발생했습니다. * **고성능 서빙 레이어 구축:** 서빙 레이어를 Go 언어로 재작성하고 가벼운 고루틴(Goroutine)과 공유 메모리를 활용하여 동시성 성능을 극대화했습니다. * **지연 시간 단축:** 최적화 결과 p95 기준 지연 시간을 25~35ms 수준으로 유지하며, 초당 수천 개의 요청을 처리할 수 있는 확장성을 확보했습니다. ### 효율적인 데이터 신선도 유지 전략 * **계층화된 수집 방식:** 복잡한 연산이 필요한 데이터는 메달리온 아키텍처(Medallion architecture) 기반의 배치 수집을, 실시간 신호는 스트리밍 방식을 병행합니다. * **지능형 변경 감지:** 모든 데이터를 매번 다시 쓰는 대신 변경된 레코드만 온라인 스토어에 기록하는 방식을 도입했습니다. * **비용 및 성능 최적화:** 변경 감지 기술을 통해 쓰기 작업량을 수억 건에서 백만 건 미만으로 줄여 업데이트 시간을 단축하고 인프라 부하를 최소화했습니다. 이러한 드롭박스의 접근 방식은 기성 제품을 그대로 사용하기보다 오픈소스를 활용해 내부 인프라에 최적화된 형태로 커스터마이징하는 것이 대규모 AI 서비스 운영에 얼마나 중요한지를 잘 보여줍니다. 특히 성능 병목 지점을 정확히 파악하여 서빙 레이어를 Go로 전환한 결정은 지연 시간에 민감한 실시간 랭킹 시스템 구축 시 고려해 볼 만한 전략입니다.

dynamodbmachine-learninggofeature-store+4

figma2024년 10월 14일

피그마 AI 검색의 (새 탭에서 열림)

Figma의 AI 검색은 텍스트·이미지·레이어 선택을 동일한 임베딩 공간에서 비교해 디자인과 컴포넌트를 의미적으로 찾도록 구축됐다. 핵심 기반은 CLIP 멀티모달 임베딩 모델과 벡터 검색 인덱스이며, 수십억 개의 임베딩을 생성·관리하면서도 비용과 처리량을 고려한 인프라 설계가 필요했다. 특히 파일 내부의 검색 가능한 프레임을 식별하고 썸네일과 임베딩을 비동기적으로 생성하는 과정이 주요 기술 과제였다. ## AI 검색이 해결하는 문제 - **디자인 검색** - 조직이나 팀 전체의 Figma 파일에 포함된 프레임을 검색한다. - 파일명이나 레이어 이름이 없어도 프레임의 시각적 내용으로 찾을 수 있다. - 텍스트 설명, 스크린샷, 선택한 Figma 레이어를 검색 입력으로 사용할 수 있다. - 선택 영역은 새 스크린샷으로 렌더링한 뒤 이미지 검색과 같은 경로로 처리한다. - **컴포넌트 검색** - 기존 Assets 검색의 엄격한 텍스트 일치 방식을 의미 기반 검색으로 확장했다. - 예를 들어 이름이 😀인 컴포넌트를 “smiley”, “happy”, “face”, “grin” 같은 표현으로도 찾을 수 있다. - 컴포넌트 이름과 설명에 검색 키워드를 일일이 추가하는 SEO 작업이 필요 없다. - 컴포넌트 역시 스크린샷이나 레이어 선택을 이용해 시각적으로 검색할 수 있다. ## CLIP 기반 멀티모달 임베딩 - 임베딩 모델은 텍스트나 이미지를 의미를 보존한 숫자 배열로 변환한다. - Figma는 현재 오픈소스 **CLIP** 모델을 사용한다. - CLIP은 이미지와 텍스트를 같은 벡터 공간에 표현한다. - 고양이 이미지의 임베딩과 `"cat"`이라는 텍스트의 임베딩이 서로 가까운 위치에 놓인다. - 따라서 이미지와 텍스트를 서로 다른 입력 방식으로 검색해도 의미적으로 비교할 수 있다. - 모델은 고객의 비공개 Figma 파일이나 고객 데이터를 학습에 사용하지 않았다. - 공개된 무료 Community 파일의 UI 이미지로 미세 조정했다. - 초기에는 선택 영역을 JSON 같은 텍스트 표현으로 변환해 임베딩하는 방식도 검토했다. - 그러나 이미지로 임베딩을 생성하는 방식이 더 나은 검색 결과를 제공했다. - 스크린샷 검색과 동일한 처리 경로를 사용할 수 있다는 장점도 있었다. ## 벡터 검색 처리 방식 - 검색 대상 콘텐츠마다 임베딩을 생성해 벡터 검색 인덱스에 저장한다. - 예: 디자인 시스템의 모든 컴포넌트와 각 컴포넌트의 임베딩 - 사용자가 검색하면 입력을 먼저 임베딩으로 변환한다. - 텍스트 검색은 입력 문장을 임베딩 모델에 전달한다. - 스크린샷 검색은 이미지에서 임베딩을 생성한다. - 레이어 선택 검색은 선택 영역을 스크린샷으로 만든 뒤 임베딩한다. - 생성된 쿼리 임베딩과 인덱스의 임베딩 사이 거리를 계산해 가장 가까운 항목을 반환한다. - 전통적인 문자열 검색처럼 검색어와 색인 항목을 직접 비교하는 것이 아니라, 고차원 벡터 공간에서 최근접 이웃을 찾는다. ## 검색 가능한 프레임 식별 - Figma 파일 깊숙한 곳에 있는 모든 검색 대상 프레임을 찾아야 한다. - 각 프레임에 대해 다음 작업을 수행한다. - Figma 레이어를 렌더링해 썸네일을 생성한다. - 썸네일에서 임베딩을 생성한다. - 메타데이터와 임베딩을 검색 인덱스에 기록한다. - 게시되지 않은 프레임은 일반적인 방식으로 쉽게 열거할 수 없다는 문제가 있다. - 이를 해결하기 위해 비동기 작업에서 서버 측 C++ Figma 에디터를 헤드리스 방식으로 실행한다. - 서버에서 C++ 에디터를 실행하기 위해 별도의 샌드박싱 기술을 사용한다. ## 저장소와 인프라 선택 - Figma는 자체 RDS 클러스터도 운영하지만, AI 검색에는 DynamoDB를 사용한다. - AI 검색의 저장 요구사항이 복잡한 관계형 트랜잭션보다 단순한 키-값 저장에 가깝기 때문이다. - 주요 요구사항은 다음과 같다. - 임베딩과 관련 메타데이터의 대량 저장 - 높은 쓰기 처리량 - 검색 시 빠른 읽기 - 대규모 인덱스 생성 및 갱신 처리 - 전체 시스템은 수십억 개의 임베딩을 생성하고 색인해야 하므로 검색 품질뿐 아니라 생성 비용과 운영 비용도 중요한 설계 기준이 된다. Figma의 접근 방식은 이미지와 텍스트를 하나의 의미 공간에 매핑하고, 프레임·컴포넌트별 임베딩을 사전에 구축하는 것이다. 유사한 기능을 구현한다면 먼저 검색 대상을 안정적으로 열거하고, 렌더링·임베딩 생성·색인 갱신을 비동기 파이프라인으로 분리하며, 모델 학습 데이터와 고객 데이터의 경계를 명확히 관리하는 것이 중요하다.

dynamodbmultimodal-aivector-dbc+++2

figma2022년 10월 19일

멀티플레이어를 더 안정적으로 (새 탭에서 열림)

Figma는 인메모리 상태와 30~60초 간격의 체크포인트에 의존하던 멀티플레이어 시스템에 변경 이력을 기록하는 저널(write-ahead log)을 도입했다. 저널은 파일의 전체 상태가 아닌 증분 변경을 자주 저장하므로 장애 발생 시 최신 체크포인트 이후의 변경을 재생해 복구할 수 있으며, 목표 데이터 손실을 1초 미만으로 줄였다. 또한 배포 시 모든 파일을 동시에 체크포인트하는 쓰기 부하 급증도 해소했다. ## 기존 멀티플레이어 구조 - 브라우저 클라이언트는 WebSocket으로 `multiplayer` 서비스에 연결한다. - 서버는 파일 상태를 메모리에 보관하면서 여러 클라이언트의 변경 사항을 수신·검증·정렬·충돌 해결한 뒤 전체 클라이언트에 전달한다. - 메모리 상태는 휘발성이므로 30~60초마다 파일 전체를 바이너리로 인코딩하고 압축해 S3에 체크포인트로 저장한다. - 체크포인트는 버전 기록 등 일부 기능의 기반이 된다. ## 체크포인트 중심 방식의 문제점 - 서버가 장애를 일으키면 마지막 체크포인트 이후 최대 60초의 작업을 잃을 수 있다. - 파일 전체를 저장하므로 파일의 크기와 복잡도가 커질수록 저장 비용도 증가한다. - 멀티플레이어를 재배포하면 메모리에 있던 모든 파일을 닫아야 하므로 동시에 대량의 체크포인트 쓰기가 발생한다. - 이로 인해 데이터베이스 부하가 급증하고, 배포가 사용자에게 보이지 않는 작업이어야 한다는 목표를 방해한다. ## 증분 변경을 저장하는 저널 - Figma는 파일 변경 사항을 기록하는 내구성 있는 트랜잭션 로그인 저널을 추가했다. - 멀티플레이어가 변경을 수락하면 변경 내용을 비동기적으로 저널에 기록한다. - 각 변경에는 파일별로 증가하는 시퀀스 번호를 부여한다. - 체크포인트에도 해당 시점의 시퀀스 번호를 함께 저장한다. - 저널에는 전체 파일이 아니라 사용자가 수행한 증분 변경만 저장한다. - 예: 텍스트 수정, 디자인 요소의 위치 변경, 목업 업데이트 등 - 증분 변경은 전체 파일보다 훨씬 작기 때문에 더 자주 기록해도 효율적이다. ## 장애 복구 방식 - 서버가 재시작되면 기존 체크포인트를 먼저 불러온다. - 체크포인트의 시퀀스 번호보다 큰 시퀀스 번호를 가진 저널 항목을 조회한다. - 해당 변경들을 순서대로 재생해 최신 파일 상태를 복원한다. - 기존 체크포인트 방식은 약 60초 간격으로 저장했지만, 저널은 약 0.5초 수준으로 변경 사항을 기록하는 방향을 취한다. - 그 결과 장애 시 데이터 손실 목표를 1초 미만으로 낮췄다. ## 배포 시 쓰기 부하 안정화 - 배포할 때 모든 연결을 종료하고, 아직 저장되지 않은 변경이 저널에 기록될 때까지 기다린다. - 99번째 백분위수 기준으로 이 과정은 1초 이내에 완료된다. - 배포를 위해 대규모 체크포인트를 한꺼번에 생성할 필요가 없어졌다. - 저널 쓰기는 평상시에도 지속적으로 발생하므로 데이터베이스 부하가 일정하고 예측 가능해진다. ## 데이터 저장소 선택 - 저널의 백엔드 저장소로 DynamoDB를 사용했다. - Postgres와 로컬 디스크 등 여러 선택지를 검토했지만, 높은 쓰기량을 수평 확장해야 한다는 점 때문에 Postgres는 선택하지 않았다. - 이 사례에서는 익숙한 데이터베이스보다 쓰기 규모와 확장성을 감당할 수 있는 저장소가 더 중요한 기준이었다. ## 변경 사항 배치 처리 - 클라이언트는 초당 30프레임, 즉 약 33ms마다 업데이트를 보낸다. - 모든 업데이트를 같은 빈도로 저널에 기록할 필요는 없으므로 여러 변경 사항을 묶어 일정 주기로 저장한다. - 이 배치 처리는 저널 쓰기 횟수를 줄이고 성능을 개선하면서도 체크포인트보다 훨씬 짧은 복구 지연 시간을 유지하기 위한 방식이다. Figma의 사례는 전체 상태를 드물게 저장하는 체크포인트와, 작은 변경을 자주 저장하는 저널을 함께 사용하는 구조가 실시간 협업 시스템에 적합하다는 점을 보여준다. 장애 복구 시간과 데이터 손실을 줄이려면 증분 로그를 도입하고, 시퀀스 번호를 기준으로 체크포인트와 로그를 연결하는 방식을 고려할 수 있다.

dynamodbpostgresqlreal-time-collaborationwebsockets+2

datadog2021년 4월 30일

Datadog IT 팀이 서드파티 계정 모니터링을 자동화한 방법 (새 탭에서 열림)

현대 기업이 사용하는 수많은 SaaS 애플리케이션의 계정을 수동으로 관리하는 것은 보안 위협과 비용 낭비를 초래할 수 있는 매우 어렵고 비효율적인 작업입니다. Datadog은 이를 해결하기 위해 사내 인사 관리 시스템(HRIS)인 Workday를 단일 진실 공급원(Single Source of Truth)으로 삼아 SaaS 계정을 자동으로 전수 조사하는 자체 도구 'Clarity'를 구축했습니다. 이 시스템은 정기적인 감사를 통해 퇴사자나 미승인 계정을 실시간으로 탐지하고, 티켓팅 및 알림 시스템과 연동하여 즉각적인 조치를 가능하게 함으로써 기업의 보안 거버넌스를 강화합니다. **SaaS 계정 감사의 필요성과 요구사항** * **보안 및 비용 관리:** 관리되지 않는 유령 계정은 민감 데이터 유출의 통로가 될 수 있으며, 불필요한 라이선스 비용을 발생시키므로 정기적이고 자동화된 감사가 필수적입니다. * **신뢰할 수 있는 데이터원 확보:** 모든 직원의 상태를 정확히 반영하는 Workday(또는 Okta, ADP 등)를 기준으로 삼아 SaaS 앱의 사용자 목록과 대조해야 합니다. * **운영 효율성:** 감사는 수시로 자동 실행될 수 있어야 하며, 필요에 따라 수동 실행도 가능해야 합니다. 또한 기존 업무 흐름을 방해하지 않도록 사내에서 이미 사용 중인 도구들과 긴밀하게 통합되어야 합니다. **Clarity의 작동 아키텍처 및 프로세스** * **자동 실행 및 데이터 수집:** AWS CloudWatch Event Rule을 통해 매일 정해진 시간에 실행되며, AWS Lambda를 사용하여 Workday와 주요 SaaS(Slack, GitHub, Zoom 등)의 활성 사용자 명단을 동시에 가져옵니다. * **교차 검증(Auditing):** SaaS 앱의 이메일 주소 목록을 Workday의 현직자 명단과 비교하여, 일치하는 기록이 없는 계정을 즉시 식별합니다. * **데이터 이력 관리:** 감사 결과 발견된 비정상 계정 정보는 추후 추적 및 분석을 위해 DynamoDB 테이블에 기록됩니다. **로깅, 알림 및 사후 조치 통합** * **Datadog 메트릭 활용:** 탐지된 각 계정 정보는 Datadog Metrics API를 통해 전송됩니다. 이때 'gauge' 타입을 사용하여 시간 경과에 따른 비정상 계정 추이를 시각화합니다. * **태그 기반의 상세 분석:** 메트릭 전송 시 환경(prod/dev), 담당 팀, 해당 SaaS 서비스명, 사용자 이메일 등을 태그로 포함하여 문제 발생 시 즉각적인 식별이 가능하도록 합니다. * **워크플로우 연동:** 감사가 완료되면 Freshservice를 통해 자동으로 조치 티켓을 생성하고, Slack으로 요약 보고서를 발송하여 담당 팀이 Datadog 로그 링크를 통해 즉시 상세 내용을 확인할 수 있게 합니다. SaaS 환경이 확장됨에 따라 수동 감사는 한계에 부딪힐 수밖에 없습니다. Datadog의 사례처럼 인사 시스템을 API로 연결하고 기존의 모니터링 및 알림 도구(Slack, Jira 등)를 통합한 자동화 파이프라인을 구축한다면, 최소한의 운영 리소스로도 기업 전체의 SaaS 보안 가시성을 획기적으로 높일 수 있습니다.

dynamodbdatabase-designdatadogslack+4