Kubernetes에서 파드는 언제든 생성되고 삭제될 수 있는 일시적인 존재이지만, 그 위에서 동작하는 애플리케이션들은 서로 끊김 없이 통신할 수 있어야 합니다. 이러한 파드 간 통신을 실제로 구현해주는 것이 CNI(Container Network Interface) 플러그인이며, 그중에서도 Calico는 L3 라우팅 기반 아키텍처와 강력한 NetworkPolicy 기능 덕분에 프로덕션 환경에서 널리 사용되는 CNI 중 하나입니다. 이번 글에서는 Calico 환경에서 같은 노드 내부의 파드끼리 통신하는 방식과 서로 다른 노드에 있는 파드끼리 통신하는 방식을 살펴보겠습니다. 목차1. Kubernetes 네트워크 모델과 Calico 기본 구조2. 같은 노드 내부 파드 간 통신3. 다른 노드에 있는 파드 간..

Amazon Bedrock은 AWS에서 제공하는 관리형 생성형 AI 서비스로, 여러 Foundation Model을 하나의 플랫폼에서 사용할 수 있게 해줍니다. RAG 구조로 기업 내부 문서나 서비스 데이터를 기반으로 답변하게 만들 수 있고, Agent를 활용하여 외부 API를 호출해 실제 작업까지 수행할 수 있다는 점이 특징입니다. 이번 글에서는 Amazon Bedrock에서 자주 함께 언급되는 RAG for Amazon Bedrock과 Agents for Amazon Bedrock의 개념을 정리하고, 실제 서비스에서 사용할 수 있는 Bedrock 기반 RAG / Agent 아키텍처를 설계하는 방법을 알아보겠습니다. 목차1. RAG for Amazon Bedrock2. Agents for Amazon..

현대 웹 서비스에서 HTTPS 암호화 통신은 보안뿐만 아니라 사용자 신뢰도와 검색엔진 최적화를 위해서도 선택이 아닌 필수입니다. AWS 환경에서는 AWS Certificate Manager를 활용해 간편하게 TLS/SSL 인증서를 발급받고, 이를 Application Load Balancer에 연결하여 손쉽게 HTTPS 접속 환경을 구축할 수 있습니다. 이번 포스팅에서는 ACM을 통한 도메인 인증서 발급 과정부터 ALB 리스너 규칙을 설정하여 실제 웹 서비스에 안전한 HTTPS 통신을 적용하는 방법까지, 전체 과정을 단계별로 차근차근 알아보겠습니다. 목차1. Route53과 ACM을 통해 인증서 발급2. ALB에 인증서 연결하고 설치3. Terraform 실습4. 결론 #1 Route53과 ACM을 ..

Terraform은 인프라를 코드로 관리할 수 있게 해주는 IaC이지만, 실무에서는 코드 작성만큼이나 상태파일 관리가 중요합니다. Terraform은 terraform.tfstate 파일을 기준으로 실제 클라우드 리소스와 코드의 차이를 판단하기 때문에, 이 파일이 꼬이거나 서로 다른 작업자가 다른 상태를 기준으로 작업하면 동기화가 되지 않아 문제가 발생할 수 있습니다. 그래서 실무에서는 상태파일을 S3 같은 원격 저장소에 보관하고, 동시에 여러 사용자가 terraform apply를 실행하지 못하도록 Lock 구조를 함께 구성합니다. 이번 포스팅에서는 Terraform 상태파일을 AWS 환경에서 S3와 DynamoDB Lock을 이용해 안전하게 관리하는 방법을 알아보겠습니다. 목차1. 상태파일 중앙관리..

오늘날 대부분의 서비스가 클라우드 환경 위에서 운영되면서, 보안과 컴플라이언스에 대한 요구 역시 함께 높아지고 있습니다. 국내에서는 일정 규모 이상의 기업이라면 ISMS-P(정보보호 및 개인정보보호 관리체계) 인증이 법적으로 의무화되어 있고, 이 인증 과정에서 클라우드 인프라 아키텍처는 가장 집중적으로 검증받는 영역 중 하나입니다. 네트워크 분리, 접근 통제, 암호화, 로그 관리, 백업 정책 등 인프라 엔지니어가 직접 설계하고 구현해야 하는 영역이 심사의 핵심을 차지하고 있습니다. 그렇다면 AWS 환경에서 ISMS-P 인증을 통과할 수 있는 인프라는 어떻게 설계해야 할까요? 이번 글에서는 ISMS-P의 102개 통제항목 중 클라우드 인프라 엔지니어가 반드시 알아야 할 핵심 7가지를 선별하여, 각 항목이 ..

오늘날 많은 서비스들이 컨테이너 기반 아키텍처를 도입하면서, 애플리케이션 배포와 운영 방식 역시 빠르게 변화하고 있습니다. 특히 AWS 환경에서는 Amazon ECS를 통해 컨테이너 환경을 비교적 손쉽게 구성할 수 있고, 여기에 EC2 기반 방식과 Fargate 기반 방식이라는 두 가지 실행 모델이 존재합니다. 많은 조직들이 컨테이너 환경을 도입할 때 단순히 “서버를 직접 관리할 것인가, 관리하지 않을 것인가” 정도의 기준으로 ECS on EC2와 ECS on Fargate를 구분하곤 합니다. 하지만 실제로는 그보다 훨씬 더 많은 요소를 함께 고려해야 합니다. 예를 들어, 트래픽 패턴이 일정한지, 운영 인력이 충분한지, 비용 최적화가 중요한지, 혹은 인프라에 대한 세밀한 제어가 필요한지에 따라 더 적합한..

오늘날 많은 인프라 조직들이 클라우드 환경을 효율적으로 관리하기 위해 Terraform과 같은 IaC(Infrastructure as Code) 도구를 도입하여 프로비저닝 과정을 자동화하고 생산성을 높이고 있습니다. 하지만 아무리 코드로 인프라를 깔끔하게 배포한다고 해도, 네트워크 통신의 기본 원리를 간과한 채 단순히 포트만 열어두는 보안 설계는 치명적인 운영 리스크를 안고 있습니다. 실제 네트워크 통신은 TCP, UDP, ICMP 등 각 프로토콜의 고유한 동작 방식과 연결 상태(State)에 따라 전혀 다르게 처리됩니다. 따라서 진정으로 안전한 클라우드 환경을 구축하려면 단순히 통로를 여닫는 수준을 넘어, 데이터가 오가는 전체적인 흐름을 정확히 이해하고 제어해야 합니다. 이 트래픽 흐름을 조절하는 핵심..

오늘날 많은 웹서비스들이 CI/CD 파이프라인을 구축하여 배포 과정을 자동화하고 개발 생산성을 높이고 있습니다. 하지만 아무리 테스트를 거쳤다고 해도, 단순히 새로운 버전을 전체 서버에 일괄 적용하는 방식은 치명적인 리스크를 안고 있습니다. 예를 들어, 새로 배포한 애플리케이션에 예상치 못한 치명적인 버그가 포함된 상황을 가정해 봅시다. 배포가 완료되는 순간 접속하는 모든 사용자가 즉시 오류를 경험하게 되고, 서비스는 장애 상태에 빠지게 될 것이고, 이는 매출에 큰 손실을 불러오게 됩니다. 이때 가장 효과적으로 사용할 수 있는 기술이 AWS의 가중치 기반 라우팅(Weighted Routing)입니다. Application 레벨에서와 DNS 레벨에서 트래픽을 정교하게 조절하여 안전하게 배포하는 방법에 대해..

규모가 어느 정도 있는 웹 서비스들은 대부분 MSA(Micro Services Architecture) 환경으로 운영되고 있습니다. 거대한 서비스를 독립적인 단위로 배포하여 확장성을 높이고, 장애 피해를 최소화하는 데 아주 효과적입니다. 하지만 서비스를 독립적으로 분리한다고 해서 좋은 점만 있는 것은 아니며, 오히려 서비스 간 통신 복잡성이 생기게 됩니다. MSA 환경에서는 TCP 기반 동기 통신으로 서비스들과 데이터를 주고받는데, 여기서 문제가 생깁니다. 예를 들어, 한 서비스가 다른 서비스에게 요청을 보내고 응답이 오지 않는 상황을 가정해 봅시다. 요청을 보냈던 서비스는 RTO 타임아웃과 재전송을 반복하게 되는데, 굉장히 오랜 대기시간을 소요하게 되고, 결국에는 요청을 보냈던 서비스까지 장애 상태가 ..

AWS VPC Endpoint란 인터넷 게이트웨이(IGW)나 NAT 게이트웨이 장치 없이, VPC 내부에서 EC2, S3와 같은 AWS 서비스와 비공개적으로 통신할 수 있게 해주는 기능입니다. 예를 들어, 한 VPC 내의 EC2가 인터넷 연결 없이 S3 버킷에 Private Network 액세스가 가능합니다. 따라서 오늘은 VPC 엔드포인트의 종류와 상황에 따른 사용 방법에 대해 적어보려고 합니다. 목차1. VPC Endpoint 개념 및 특성2. NAT Gateway vs. Interface VPC Endpoint3. 비용 최적화4. 결론 #1 VPC Endpoint (Virtual Private Cloud Endpoint) 개념 및 특성 VPC Endpoint를 사용하는 이유는 무엇일까요? 핵심 이점..