일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- cloudwatch
- Lamda
- 분산시스템
- 병목
- fcm
- Validation
- serverless
- aws
- IaC
- amazonqcli
- PACELC
- terraform
- kubernetes
- CAP
- SageMaker
- CHECK
- sns
- rds
- lambda
- Today
- Total
목록분류 전체보기 (252)
잡다한 IT 지식

문제 상황저희 팀 프로젝트는 사기 의심 거래가 발생하면 FCM을 통해 사용자에게 알림을 보내도록 설계했습니다.이제 첫 테스트를 하는 중인데 첫 번째 알림 발송까지 무려 33초가 걸렸습니다.아래는 CloudWatch Log insights를 통해 추출한 로그입니다.[ { "@timestamp": "2025-07-09 08:50:41.765", "@log": "secret:/aws/lambda/FinGuard-Backend-dev-createTransaction" }, { "@timestamp": "2025-07-09 08:51:14.996", "@log": "secret:/aws/lambda/sns-receive-and-send-fcm" ..

팀프로젝트 중, 백엔드 개발 담당 팀원이 Lambda 함수가 SageMaker와 통신이 안된다는 문제를 겪고 계셔서 트러블 슈팅을 진행했다.문제 상황 Lambda 함수가 SageMaker Endpoint로부터 응답을 받지 못하고 타임아웃 후 종료원인 추측하기추측 1. Lambda의 제한 시간이 짧다.SageMaker serverless 엔드포인트는 Lambda와 동일하게 Cold Start 현상이 존재한다.첫 호출 시엔 프로비저닝에 수 초 이상 소요될 수 있다.Lambda의 제한 시간이 짧다면, SageMaker의 프로비저닝 시간을 기다리는 동안 시간 초과가 발생했을 수 있다.반론:- Cold Start는 첫 요청에만 발생하며, 이후엔 Hot Start로 빠른 응답이 가능하다.- 하지만 Lambda의 두..
Terraform 1.5부터 도입된 check 블록은 인프라를 구성하기 전에 외부 리소스나 시스템 상태를 검증할 수 있도록 지원하는 기능입니다.이 기능은 terraform plan, terraform apply 시점에서 동작하며, 리소스의 상태, 연결성, 응답 값 등을 검증하는 데 유용합니다.check 블록 기본 개념Terraform의 check 블록은 주로 다음과 같은 경우에 사용됩니다.배포 전 API 또는 외부 서비스가 정상 동작 중인지 확인하고 싶을 때RDS, S3, DNS 등 리소스의 상태를 별도 조건으로 확인하고 싶을 때특정 변수나 입력값이 유효한지 사전에 검증하고 싶을 때기본 문법 예제check "health_check" { data "http" "terraform_io" { url =..

Terraform을 사용해 AWS 인프라를 구성할 때, 보안 그룹(Security Group)을 설정하는 과정에서 종종 순환 참조(Circular Dependency) 문제가 발생하곤 합니다.특히 서로 통신해야 하는 두 리소스가 각자의 보안 그룹에서 서로를 참조하는 구조일 경우 이 문제가 쉽게 발생합니다.대표적인 예로, AWS Lambda 함수가 RDS(MySQL 등)에 접근해야 하는 상황을 들 수 있습니다.RDS와 Lambda 연결 예제기본적으로 Lambda와 RDS가 통신하기 위해선 보안그룹 허용이 필요합니다.Lambda에선 egress로 RDS의 보안그룹을, RDS에선 ingress로 Lambda의 보안 그룹이 필요합니다.이제 해당 코드를 작성해보겠습니다.resource "aws_vpc" "main..

테스트 코드를 작성할 때 가장 중요한 지표 중 하나는 테스트 커버리지(Test Coverage)입니다. 이 지표는 테스트가 실제 코드의 몇 %를 실행하고 있는지를 보여주며, 코드의 신뢰성과 안정성 확보에 직결됩니다.1. Code Coverage란?Code Coverage는 테스트 코드가 전체 코드 중 얼마나 많은 부분을 실행하는지를 측정하는 지표입니다.보통 “실행된 라인의 비율”로 계산되며, 일반적으로 다음과 같은 코드 유형을 기준으로 분류합니다:Syntax Line함수 정의, 닫는 중괄호 등 구조적인 코드 (예: def, return)Logic Line변수 연산, 값 처리, 실제 동작하는 라인Branch Line조건문(if, for, while)으로 분기되는 라인 예제 코드def some_functio..

서비스 운영 환경에서 무중단 배포(Zero Downtime Deployment)는 매우 중요한 과제입니다.사용자에게 영향을 주지 않으면서 새로운 버전을 배포하기 위해 다양한 전략들이 사용되며, 각 방식은 트래픽 전환 방식, 리소스 사용량, 롤백 전략, 배포 속도 등에 따라 차이가 있습니다.이 글에서는 대표적인 배포 전략인 Blue/Green, Rolling, Canary, Rainbow 방식을 개념부터 장단점까지 일관된 흐름으로 정리합니다.1. Blue/Green 배포Blue/Green 배포는 두 개의 독립된 배포 환경(Blue, Green)을 운영하여, 새로운 버전을 별도의 환경에 배포한 뒤 트래픽을 전환하는 방식입니다.Blue: 현재 운영 중인 기존 버전Green: 새로운 버전이 배포되는 환경배포 흐..