aws-lambda

21 개의 포스트

aws원문

AWS Lambda Durable Functions를 사용하여 다단계 (새 탭에서 열림)

AWS Lambda Durable Functions의 출시로 개발자들은 별도의 상태 관리 인프라를 구축하지 않고도 복잡한 다단계 애플리케이션과 AI 워크플로우를 익숙한 Lambda 환경에서 구현할 수 있게 되었습니다. 이 기능은 '체크포인트 및 재실행(Checkpoint and Replay)' 메커니즘을 통해 실행 상태를 자동으로 추적하며, 실행 도중 실패가 발생하더라도 마지막 완료 지점부터 작업을 재개합니다. 특히 대기 상태에서는 컴퓨팅 비용이 발생하지 않으면서도 최대 1년까지 실행을 일시 중단할 수 있어, 결제 처리나 사용자 승인이 필요한 장기 프로세스에 최적화된 솔루션을 제공합니다. ### 지속성 실행(Durable Execution)의 핵심 메커니즘 * **체크포인트 및 재실행:** Durable execution SDK를 사용하면 함수가 실행될 때마다 진행 상황이 자동으로 기록됩니다. 예기치 않은 오류로 실행이 중단되더라도 Lambda는 처음부터 핸들러를 다시 실행하되, 이미 완료된 단계는 스킵하고 마지막 체크포인트부터 비즈니스 로직을 이어갑니다. * **비용 효율적인 대기:** 실행 중 특정 지점에서 실행을 일시 중단하면 컴퓨팅 자원 할당이 해제되어 유휴 비용이 발생하지 않습니다. 이후 정의된 조건이 충족되면 자동으로 실행이 재개됩니다. ### 워크플로우 제어를 위한 주요 프리미티브(Primitives) * **context.step():** 비즈니스 로직에 자동 재시도 및 체크포인트 기능을 추가합니다. 해당 단계가 성공적으로 완료되면 이후 재실행 시 다시 수행되지 않도록 보장합니다. * **context.wait():** 지정된 기간 동안 함수의 실행을 중단합니다. 최대 1년까지 대기가 가능하며, 대기 기간 동안에는 비용이 청구되지 않습니다. * **create_callback():** 외부 API 응답이나 사람의 직접적인 승인과 같은 외부 이벤트를 기다릴 수 있는 콜백을 생성합니다. * **wait_for_condition():** REST API 폴링 등을 통해 특정 조건이 충족될 때까지 실행을 일시 정지합니다. * **parallel() 및 map():** 복잡한 병렬 처리 및 동시성 유스케이스를 지원하여 효율적인 리소스 활용을 돕습니다. ### 서비스 도입 시 고려사항 * **설정 방식:** Durable Functions 기능은 Lambda 함수를 처음 생성하는 단계에서만 활성화할 수 있으며, 기존에 이미 생성된 함수에는 소급 적용이 불가능합니다. * **개발 환경:** 함수 생성 시 'Durable execution' 옵션을 활성화한 후, 코드 내에 오픈 소스로 제공되는 Durable Execution SDK를 포함하여 비즈니스 로직을 작성해야 합니다. * **활용 사례:** 주문 처리 프로세스, AI 에이전트의 다단계 추론 오케스트레이션, 인적 승인이 필요한 결재 시스템 등 상태 유지가 필수적인 워크로드에 강력한 이점을 제공합니다. AWS Lambda Durable Functions는 Step Functions와 같은 외부 오케스트레이션 도구 없이도 코드 수준에서 상태ful한 워크플로우를 관리할 수 있게 해줍니다. 단순한 이벤트 처리를 넘어 긴 호흡의 비즈니스 로직을 관리해야 하는 백엔드 개발자나 AI 엔지니어에게 매우 실용적인 도구가 될 것입니다.

datadog원문

밀리초 하나하나까지 단축하기: Datadog Lambda Extension을 Rust로 재구축한 방법 (새 탭에서 열림)

Datadog은 기존 Go 기반의 AWS Lambda 확장이 가진 높은 오버헤드를 해결하기 위해, 이를 Rust 언어로 완전히 재작성한 'Project Bottlecap'을 진행했습니다. 이를 통해 콜드 스타트 시간을 82% 단축하고 메모리 사용량을 40% 절감했으며, 바이너리 크기를 55MB에서 7MB로 줄이는 획기적인 성능 개선을 달성했습니다. 결과적으로 리소스가 제한된 서버리스 환경에서도 사용자 애플리케이션에 영향을 주지 않고 고정밀 텔레메트리 데이터를 수집할 수 있게 되었습니다. ### 기존 범용 에이전트 기반 설계의 한계 - 초기 Datadog Lambda 확장은 다중 호스트나 클러스터 환경에 최적화된 기존 Datadog 에이전트 코드를 기반으로 구축되었습니다. - 범용 에이전트는 대규모 처리량과 캐싱, 버퍼링에 초점이 맞춰져 있어 리소스가 극도로 제한된 람다의 단기 실행 환경에는 부적합했습니다. - 종속성 제거, 바이너리 압축(UPX), 지연 로딩 등 모든 최적화 수단을 동원했음에도 불구하고 콜드 스타트 지연 시간이 450~500ms 이하로 내려가지 않는 성능 한계에 직면했습니다. - 결국 범용 도구와 서버리스 전용 도구의 스케일 차이를 인정하고, 밑바닥부터 다시 작성하는 결정을 내렸습니다. ### Lambda 환경에서 Rust 언어의 전략적 이점 - **안정성 및 메모리 안전성:** 람다 확장이 충돌하면 함수 전체가 종료되고 샌드박스가 초기화되어 다시 콜드 스타트가 발생하는데, Rust는 컴파일 타임에 메모리 안전성을 보장하여 이러한 위험을 최소화합니다. - **바이너리 경량화:** 가비지 컬렉터와 대규모 런타임이 포함된 Go와 달리, Rust는 킬로바이트 또는 낮은 메가바이트 단위의 매우 작은 바이너리를 생성하여 초기 로딩 시간을 줄입니다. - **제한된 환경의 이점:** 람다는 아마존 리눅스와 x86/Arm 아키텍처라는 고정된 환경만 고려하면 되므로, 다양한 환경을 지원해야 하는 시스템 프로그래밍에서 Rust가 가질 수 있는 복잡성 문제가 크게 완화되었습니다. ### Project Bottlecap의 핵심 설계 원칙 - **철저한 성능 오버헤드 통제:** 모든 풀 리퀘스트(PR)마다 벤치마크를 수행하여 성능 저하를 감시했으며, 성능 향상을 위해 공식 AWS SDK 사용을 포기하고 직접 AWS API 호출과 서명 로직을 작성하는 트레이드오프를 감수했습니다. - **핸들러 영향 최소화:** 람다 확장 API를 활용하여 함수 핸들러가 결과를 반환한 후에 텔레메트리를 처리함으로써, 사용자 API 응답 속도에 미치는 영향을 제거했습니다. - **다양한 플러시(Flush) 전략:** 리소스 사용량이 적은 API 함수부터 대규모 배치 작업까지 대응할 수 있도록 데이터 전송 시점을 유연하게 설정할 수 있는 구조를 갖추었습니다. 범용 소프트웨어를 특정 환경에 맞춰 최적화하는 것에는 한계가 있습니다. 특히 실행 시간과 리소스 사용량이 곧 비용과 직결되는 서버리스 환경에서는, 해당 환경의 제약 조건을 반영한 전용 도구를 구축하는 것이 초기 개발 비용이 높더라도 장기적으로 성능과 안정성 측면에서 압도적인 이점을 제공합니다.

datadog3분 읽기큐레이션 요약

밀리초 단위까지 아끼

제공된 내용에는 본문이 아니라 Datadog 웹사이트의 제품 메뉴와 “Gartner® Observability Platforms Magic Quadrant™에서 Leader로 선정”되었다는 홍보 문구가 대부분 포함되어 있습니다. 따라서 Datadog Lambda Extension을 Rust로 구현한 기술적 배경이나 설계·성능 관련 결론은 확인할 수 없습니다. 현재 확인 가능한 범위에서는 Datadog이 인프라부터 애플리케이션, 로그, 보안, 사용자 경험, 소프트웨어 공급망, AI까지 통합 관측성 플랫폼으로 제공한다는 점이 중심입니다. ### Gartner 관측성 플랫폼 리더 선정 - Datadog은 Gartner의 Observability Platforms Magic Quadrant에서 Leader로 선정되었다고 소개합니다. - 이는 인프라 모니터링, 애플리케이션 성능 모니터링(APM), 로그 관리 등 여러 관측성 기능을 하나의 플랫폼에서 제공한다는 맥락으로 제시됩니다. - 다만 Gartner 평가의 세부 기준이나 Datadog의 강점·약점에 대한 본문 내용은 제공된 자료에 포함되어 있지 않습니다. ### 인프라 및 애플리케이션 모니터링 - 인프라 영역에는 다음 기능이 포함됩니다. - 메트릭 및 인프라 모니터링 - 컨테이너와 Kubernetes 오토스케일링 - 네트워크, 서버리스, GPU, 스토리지 모니터링 - 클라우드 비용 관리 - 애플리케이션 영역에는 다음 기능이 제공됩니다. - APM과 서비스 모니터링 - 연속 프로파일링 및 동적 계측 - 에이전트 관측성 ### 로그·데이터 관측성 - 로그 관리와 민감 데이터 탐지 기능을 제공합니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태를 관찰할 수 있습니다. - Observability Pipelines를 통해 로그와 관측 데이터를 수집·처리하는 기능도 포함됩니다. ### 보안과 사용자 경험 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석, IaC 보안 등 개발 단계의 보안 기능을 제공합니다. - 클라우드 보안, 취약점 관리, Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 기능도 포함됩니다. - 브라우저·모바일 RUM, 세션 리플레이, 합성 모니터링, 오류 추적을 통해 실제 사용자 경험을 분석할 수 있습니다. ### 소프트웨어 전달과 서비스 관리 - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지, 기능 플래그 등의 기능이 나열되어 있습니다. - 서비스 카탈로그, SLO, 인시던트 대응, 케이스 관리, 워크플로 자동화 등 운영 관리 기능도 제공합니다. - 이를 통해 개발·배포·운영 과정의 데이터를 하나의 플랫폼에서 연결하려는 방향을 보여줍니다. ### AI 기반 기능 - Datadog은 AI 에이전트 관측성, GPU 모니터링, AI 통합 기능을 별도 영역으로 제공합니다. - Bits AI Agents, Bits Chat, Bits Investigation, Bits Security Analyst, MCP Server 등 AI 기반 조사·자동화 도구가 포함됩니다. - 그러나 제공된 내용만으로는 각 AI 기능의 동작 방식이나 실제 성능을 평가할 수 없습니다. 제공된 자료만으로는 링크된 기술 블로그의 본문을 요약하기 어렵습니다. Rust 기반 Datadog Lambda Extension의 구현 방식이나 성능 개선을 요약하려면 해당 글의 본문 내용이 추가로 필요합니다.

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

Datadog IT 팀이 계정 비활성화와 SaaS 지출 관리를 자동화한 방법 (새 탭에서 열림)

데이터독(Datadog)은 급격히 증가하는 SaaS 라이선스 비용을 최적화하고 보안 리스크를 줄이기 위해 기존의 내부 도구인 'Clarity'를 'Clarity License Manager(CLM)'로 확장했습니다. 이 시스템은 여러 SaaS 애플리케이션의 사용자 활동을 자동으로 모니터링하여 비활성 계정을 식별하고, 사용자 알림 및 자동 비활성화 프로세스를 통해 운영 효율성을 극대화합니다. 결과적으로 데이터독은 불필요한 비용 지출을 막는 동시에, 미사용 계정으로 인한 보안 위협을 효과적으로 제거하고 직원들에게는 원활한 계정 복구 경험을 제공하고 있습니다. ### 기존 라이선스 관리의 문제점 * 과거 IT 지원 팀은 분기별로 수동 감사를 수행하여 라이선스 사용 현황을 파악했으나, 이는 매우 비효율적이고 지루한 작업이었습니다. * IT 직원이 사용자에게 일일이 연락해 계정 유지 여부를 확인해야 했기 때문에 직원들의 업무 흐름을 방해하는 등 사용자 경험이 저하되었습니다. * 실시간 데이터에 기반한 인사이트가 부족하여 소프트웨어 구매 시 데이터에 기반한 의사결정을 내리기 어려웠습니다. ### 자동화된 라이선스 최적화 워크플로우 * 개별 SaaS API와 Google Workspace SAML 감사 로그를 결합하여 사용자 활동 데이터를 유연하고 보안상 안전한 방식으로 수집합니다. * 특정 기간(기본 90일) 동안 앱을 사용하지 않은 사용자에게 Slack과 이메일로 자동 알림을 발송하여 활성 상태 유지에 필요한 구체적인 행동을 안내합니다. * 사용자가 안내된 조치를 취하지 않을 경우 CLM이 해당 SaaS 계정을 자동으로 비활성화하며, 이 데이터는 Amazon RDS(Postgres)에 저장되어 관리됩니다. * 재접속이 필요한 직원을 위해 티켓 시스템(Freshservice)과 연동된 자동 복구 워크플로우를 구축하여, 단 몇 초 만에 이전 권한 그대로 계정을 복구할 수 있게 했습니다. ### 마이크로서비스 및 어댑터 기반 아키텍처 * Python과 AWS Lambda를 기반으로 한 마이크로서비스 구조를 채택하여 SaaS 환경의 확장에 유연하게 대응하고 시스템 회복 탄력성을 높였습니다. * 각 SaaS 애플리케이션의 고유한 로직을 처리하기 위해 '애플리케이션별 어댑터(Adapter)' 패턴을 도입했습니다. * 어댑터는 사용자 조회, 로그인 데이터 획득, 활성화/비활성화 등 공통 인터페이스를 제공하여 메인 마이크로서비스 로직과 개별 앱의 복잡한 API 통신 로직을 분리합니다. * 이러한 설계는 단일 책임 원칙(Single Responsibility)을 준수하며 코드의 재사용성을 높이고, 새로운 SaaS 도구를 시스템에 빠르게 통합할 수 있게 합니다. 기업의 규모가 커질수록 수동 라이선스 관리는 비용 누수와 보안 취약점을 야기하는 큰 부담이 됩니다. Datadog의 CLM 사례처럼 사용자 활동 데이터를 기반으로 비활성 계정을 자동 관리하고, 셀프 서비스 형태의 복구 프로세스를 갖추는 것은 비용 절감과 보안 강화라는 두 마리 토끼를 잡을 수 있는 실무적인 해법이 될 수 있습니다.

figma3분 읽기큐레이션 요약

피그마 내부 이야기: 내부 웹

Figma는 내부 웹 애플리케이션을 안전하게 공개하기 위해 AWS Application Load Balancer(ALB), Cognito, Okta, SAML, Lambda, Terraform을 조합한 중앙화된 접근 제어 시스템을 구축했다. 이 시스템은 사내 네트워크를 신뢰하지 않는 제로 트러스트 원칙을 따르면서도, 직원에게 빠르고 일관된 인증 경험을 제공하는 것을 목표로 한다. 또한 권한 관리를 중앙화하고 인프라 구성을 코드로 자동화해 보안팀의 운영 부담을 줄였다. ## 내부 웹 앱 보안의 요구사항 - 배포, 고객 지원 등 내부 웹 도구는 직원 업무에 필수적이지만 사용자 데이터에 접근할 수 있어 높은 보안 수준이 필요하다. - 공격자는 사용자 데이터를 노리기 위해 관리용 백엔드와 내부 애플리케이션을 주요 공격 대상으로 삼는다. - 시스템 설계 시 다음 요구사항을 우선했다. - 빠르고 안정적이며 사용하기 쉬운 인증 - 네트워크 위치만으로 신뢰하지 않는 제로 트러스트 접근 - WebAuthn 같은 최신 인증 기술 활용 - IT·보안팀이 관리하는 중앙화된 권한 부여 - 소규모 보안팀의 운영 부담 최소화 ## 사용한 핵심 기술 - **SAML** - 서비스 간 사용자 신원 정보를 전달하는 인증 프로토콜이다. - 사용자 신원뿐 아니라 그룹과 역할 정보도 assertion에 포함할 수 있다. - Okta와 AWS Cognito를 연결하는 기반으로 사용된다. - **AWS Application Load Balancer** - HTTP/HTTPS 요청을 받아 규칙에 따라 내부 인프라로 전달하는 관리형 리버스 프록시다. - 애플리케이션 앞단에서 사용자 인증을 수행할 수 있다. - **AWS Cognito** - 사용자 인증 및 관리 API를 제공한다. - SAML과 같은 외부 연합 로그인 기술과 통합할 수 있다. - **AWS Lambda** - 특정 이벤트나 조건에 따라 코드를 실행하는 서버리스 컴퓨팅 구성요소다. - **Terraform** - AWS와 Okta 설정을 코드로 관리한다. - 인증 인프라를 검토·자동화·재사용할 수 있게 해준다. ## ALB와 Okta를 이용한 인증 구조 - Figma는 클라우드 인프라에 AWS를, 직원 인증·권한 관리에 Okta를 사용한다. - ALB는 일반적으로 OIDC 인증을 구성할 수 있지만, Okta의 OIDC 지원 비용 문제로 다른 방식을 검토했다. - 대안으로 **ALB + Cognito 사용자 풀 + Okta SAML** 조합을 사용했다. - Cognito가 SAML 기반 Okta 로그인과 ALB 사이를 연결하므로, ALB가 인증된 트래픽만 내부 애플리케이션으로 전달할 수 있다. - 각 내부 앱마다 Okta에 SAML 애플리케이션을 만들고, 해당 앱과 연결된 Cognito Identity Provider를 구성한다. ## Terraform을 통한 표준화와 자동화 - Figma는 ALB와 Cognito를 올바른 설정으로 생성할 수 있도록 Terraform 모듈을 직접 만들었다. - 인프라 엔지니어는 모듈을 사용해 Okta 인증이 적용된 ALB를 빠르게 배포할 수 있다. - 인증 구성을 수작업으로 반복하지 않고 코드로 관리하므로 다음 효과가 있다. - 설정의 일관성 확보 - 변경 사항 검토 가능 - 여러 내부 앱에 동일한 보안 패턴 재사용 - 운영 및 유지보수 부담 감소 ## Cognito 사용자 풀 구성 - Cognito User Pool에서는 일반 사용자의 직접 회원가입을 허용하지 않는다. - 사용자는 Okta에서 인증되어야 하며, Cognito는 Okta용 SAML Identity Provider와 연결된다. - `email`과 `profile` 같은 속성 매핑을 설정해 Okta의 사용자 정보가 인증 과정에서 전달되도록 한다. - 결과적으로 내부 앱은 각자 복잡한 인증 로직을 구현하지 않고도, ALB 앞단에서 중앙화된 인증을 적용할 수 있다. ## 확장 방향 - 글에서는 기본 인증 구조 외에도 다음 기능 확장을 다룬다. - Okta Groups를 활용한 세밀한 권한 제어 - 엔지니어를 위한 CLI 인증 - 외부 게스트의 안전한 접근 허용 - 공통 인증 계층을 기반으로 웹 브라우저뿐 아니라 명령줄 도구와 제한된 외부 사용자 접근까지 동일한 보안 원칙으로 확장하려는 접근이다. 실무에서는 내부 앱마다 인증 기능을 따로 구현하기보다, ALB 같은 공통 진입점과 중앙 IdP, Terraform 모듈을 결합하는 방식이 효과적이다. 특히 네트워크 위치를 신뢰 기준으로 삼지 않고, 강력한 사용자 인증과 중앙화된 그룹·권한 관리를 적용하는 것이 중요하다.

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

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 보안 가시성을 획기적으로 높일 수 있습니다.