heesoohi

웹에서 어떤 요청이 들어온다는 건 단순한 일이 아니다. 이 요청이 누구로부터 왔는지, 정상적인 경로를 통해 왔는지, 그 안에 담긴 내용이 안전한지를 모두 확인해야 하기 때문이다. 이번에 하나의 요청이 서버로 도달하기까지 거치는 보안 계층들을 살펴보고, AWS의 Database Migration Service(DMS) 사례를 통해 왜 네트워크 보안만으로는 충분하지 않으며, SSL과 같은 상위 계층 보안이 필수적인지를 정리해보려 한다. 여러 층으로 나뉘어져 있는 보안요청이 네트워크를 통해 시스템에 도달할 때, 보안은 하나의 레이어가 아닌 여러 단계로 분산되어 작동한다. 1. 네트워크 보안 (IP, 포트 기반 접근 제어)방화벽, 보안 그룹, 네트워크 ACL은 IP 주소나 포트를 기준으로 누가 접근할 수 있는지..

회사에서 ALB(Application Load Balancer) 뒤의 Amazon ECS 클러스터에서 애플리케이션을 운영하고 있다고 가정하자. 이때, 특정 국가의 요청은 차단하면서도, 그 국가 내 일부 IP는 예외적으로 허용해야 하는 보안 요구사항이 생길 수 있다. 이러한 정교한 요청 필터링은 어디에서 어떻게 구현해야 할까? WAF로 요청 필터링"누가 들어올 수 있는가?"를 판단하는 보안 계층은 AWS WAF(Web Application Firewall)에서 담당한다. 요청 자체를 허용하거나 차단하는 역할을 하며, 통과된 요청은 ALB에서 어떤 인스턴스나 서비스로 보낼지를 결정하게 된다. AWS WAF는 다음과 같은 요청 필터링 기능을 제공한다:IP 기반 필터링IP set이라는 객체를 정의하여 특정 I..

서비스에서 유료 회원(프리미엄 사용자)의 요청을 무료 회원보다 우선 처리해야 하는 상황에서, AWS SQS를 활용해 어떤 방식으로 아키텍처를 구성할 수 있을지에 대해 학습하고 정리해본다. 1. 문제 상황 가정웹사이트에서 프리미엄 사용자와 무료 사용자 모두 사진을 업로드하고, 이를 비디오로 변환해 다운로드하는 기능을 제공한다고 가정한다. 모든 요청은 SQS 대기열을 통해 EC2 인스턴스에서 처리된다. 이때 프리미엄 사용자의 요청을 무료 사용자보다 먼저 처리해야 하는 요구사항이 존재한다. 2. 단일 SQS의 한계프리미엄 사용자와 무료 사용자의 요청이 단일 SQS 대기열에 저장되고, EC2 인스턴스가 이를 처리하는 구조같은 경우 SQS가 메시지의 우선순위를 자체적으로 지원하지 않기 때문에, 프리미엄 요청을 먼..

서버나 시스템에 장애가 발생했을 때, 얼마나 빨리 복구해야 할까? 또 어느 시점까지의 데이터를 복구할 수 있으면 괜찮을까? 장애 복구(Disaster Recovery)를 설계할 때 꼭 알아야 하는 두 가지 핵심 지표가 바로 RTO와 RPO이다. RTO (Recovery Time Objective): 복구 시간 목표"장애 발생 후, 시스템이 몇 분(또는 몇 시간) 이내에 다시 동작해야 하는가?"초점: 시간예시: 장애 발생 후 10분 내에 시스템이 작동 상태로 돌아와야 한다면,→ RTO = 10분RTO가 짧을수록, 복구 환경이 빠르게 준비되어 있어야 함 RPO (Recovery Point Objective): 복구 지점 목표"장애 발생 시점 기준, 얼마나 이전의 데이터까지 복구할 수 있으면 괜찮은가?"초점:..

AWS의 Auto Scaling 기능은 애플리케이션의 가용성을 유지하면서도 리소스를 효율적으로 관리할 수 있는 중요한 도구이다. 하지만 설정을 어떻게 하느냐에 따라 불필요한 인스턴스 생성, 불안정한 성능, 예상치 못한 비용 증가가 발생할 수 있다. Auto Scaling이 너무 자주 작동한다면?Auto Scaling 그룹이 너무 자주 스케일 아웃(인스턴스 증가)과 스케일 인(인스턴스 감소)을 반복하면 다음과 같은 문제가 발생할 수 있다:비용 증가: 인스턴스가 짧은 시간이라도 실행되면 비용이 발생불안정한 서비스: 인스턴스가 충분히 안정화되기도 전에 종료됨의미 없는 반응: 사소한 트래픽 변화에도 과도하게 반응 최적화를 위한 두 가지 핵심 조정 포인트1. 휴지 기간(Cooldown Period) 늘리기역할: ..

웹사이트를 운영하다 보면 언젠가 이런 문제를 겪게 된다:“사이트 로딩이 너무 느려요.”“방문자가 10초 이상 기다리지 않고 이탈해요.”“트래픽이 몰리면 느려져요.” 이럴 때 대부분의 사람들은 “서버 성능이 부족한가?” 하고 EC2 인스턴스부터 키우려는 경향이 있다.하지만 실무에서는 서버 증설은 마지막 카드일 때가 많다.오히려 먼저 확인해야 할 건 읽기 성능’과 ‘콘텐츠 전달 경로’다. 1. 전체 로딩 속도가 느릴 때, 병목은 어디서 생길까?사용자 입장에서 “느리다”는 건 보통 페이지가 다 뜨기까지 오래 걸린다는 뜻이다.이 과정에서 브라우저는 아래와 같은 리소스들을 요청한다:HTMLCSS, JS이미지, 폰트API 데이터 (자주 읽히는 뉴스, 목록 등)이 중 하나라도 느리면, 전체 페이지 로딩이 지연된다. ..

EC2 인스턴스는 물리 호스트에 문제가 생기면 running 상태로 표시되더라도 정상적으로 동작하지 않을 수 있다.이런 상황에서 인스턴스를 자동으로 복구할 수 있도록 AWS는 CloudWatch 경보를 통한 Auto Recovery 기능을 제공한다. 🛠️ 자동 복구란?EC2 인스턴스의 상태를 감시하다가 시스템 장애(예: 하드웨어 오류)로 인해 인스턴스가 응답하지 않으면, CloudWatch Alarm이 이를 감지해 자동으로 인스턴스를 정상적인 호스트에서 다시 시작한다. ☑️ 인스턴스를 "다시 시작"하는 것이지, 새로운 인스턴스를 생성하는 것이 아니다. 복구 중 유지되는 것 vs 사라지는 것항목복구 후 유지 여부설명인스턴스 ID✅동일 ID로 복구프라이빗 IP✅내부 통신 문제 없음탄력적 IP (EIP)✅고..

ALB와 NLB를 이해하려면 먼저 "요청이 어떻게 전달되는지"부터 알아야 한다. 웹에서 우리가 어떤 요청을 보낼 때, 그 요청은 단순히 “URL을 입력한다”로 끝나지 않는다. 실제로는, HTTP(또는 HTTPS)라는 웹 통신 규칙이 TCP라는 통신 경로 위에서 동작한다. 예를 들어, 사용자가 브라우저에 https://example.com/login을 입력하면, 이 요청은 다음과 같은 흐름으로 전달된다: HTTP 요청 내용 → TCP 연결 → IP 주소와 포트 즉, HTTP는 “어떤 요청을 보내는가”를 담고 있고, TCP는 “그 요청을 어떻게 안정적으로 전달할 것인가”를 담당하는 역할을 한다. ALB와 NLB는 어떤 기준으로 요청을 전달하는가? 이제 본격적으로 ALB와 NLB의 차이를 살펴보자. 두 로..

EC2 인스턴스를 인터넷에 연결하거나 외부 요청을 받아야 하는 상황은 매우 흔하다. 이때 자주 마주치는 개념들이 있다: 퍼블릭 서브넷, 인터넷 게이트웨이(IGW), 퍼블릭 IP, 그리고 로드밸런서(ALB/NLB). 이 글에서는 이 네 가지가 어떻게 작동하고, 어떤 구조로 연결되어야 인터넷 통신이 가능한지 정리해보려 한다.1. 퍼블릭 서브넷이란?퍼블릭 서브넷은 VPC 내에서 인터넷과 직접 연결될 수 있는 서브넷이다. 퍼블릭 서브넷이 되기 위한 조건은 다음과 같다:서브넷이 속한 VPC에 인터넷 게이트웨이(IGW) 가 연결되어 있어야 한다.해당 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있어야 한다.이 두 가지가 모두 만족되면, 해당 서브넷은 퍼블릭 서브넷이 된다. 단, 이 안에 있는 EC2..

VPC 내의 서브넷에 관한 인터넷 액세스를 정의하는 방법에 대해 알아보자. 인터넷에 액세스할 수 있는 공용 서브넷에 EC2 인스턴스가 있으며, 인터넷 게이트웨이를 생성해야 한다. 인터넷 게이트웨이는 VPC 인스턴스가 인터넷에 바로 연결될 수 있게 한다. VPC는 인터넷 게이트웨이를 가지고, 공용 서브넷은 인터넷에 액세스하는 인터넷 게이트웨이에 관한 라우트를 가지게 된다. 즉 1. 인터넷 게이트웨이와 2. 인터넷 게이트웨이로의 라우트가 있으면, 서브넷이 공용 서브넷이 되어 외부 인터넷과 연결될 수 있는 상태가 되는 것이다. 프라이빗 서브넷의 인스턴스는 기본적으로 인터넷에서 액세스할 수 없지만, 필요한 경우 인터넷 액세스 권한을 부여할 수 있다. 예를 들어 운영 체제를 업데이트하거나 파일을 다운로드..