잡다한 IT 지식

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: 새로운 버전이 배포되는 환경배포 흐..

TL;DRCNAME은 도메인을 다른 도메인에 매핑하는 표준 DNS 레코드입니다.하지만 루트 도메인(zone apex) 에는 사용할 수 없습니다.서브 도메인에서만 사용 가능하며, 질의가 최소 2회 이상 발생합니다.Alias는 AWS Route 53에서 제공하는 비표준 레코드입니다.AWS 리소스(CloudFront, ALB 등)와 직접 연결할 수 있으며, A 레코드처럼 IP를 바로 응답합니다.루트 도메인에서도 사용 가능하고, DNS 질의는 1회로 끝납니다.AWS 리소스 연결 시에는 가능한 한 Alias를 사용하는 것이 성능과 운영 면에서 유리합니다.CNAME은 도메인과 도메인을 연결해야 할 때만 사용하세요.AWS 자격증을 공부하며 Route 53의 Alias와 CNAME을 구분하는 데 어려움을 겪었습니다. ..

AWS를 처음 접하는 많은 분들이 가장 두려워하는 요소 중 하나는 예기치 않은 요금 폭탄입니다.특히, 단순한 실수나 보안 미숙으로 인해 수십만 원~수백만 원의 비용이 청구되는 경우도 드물지 않습니다.이번 글에서는 요금 폭탄이 발생하는 주요 원인부터, 이를 방지하기 위한 실질적인 방법들(API 키 보호, STS 사용, 예산 알림 시스템)까지 정리해보았습니다.1. 요금 폭탄의 가장 흔한 원인: API 키 노출AWS에서 발생하는 치명적인 과금 사고의 대표적인 원인은 API Key 노출입니다.특히, 다음과 같은 경우가 자주 보고됩니다:GitHub와 같은 공개 SCM에 키를 실수로 커밋메신저, 공유 문서 등을 통해 키가 외부로 유출키가 노출되면 어떻게 되나요?노출된 키는 그 계정이 가진 권한 내에서 모든 작업이 ..