ALB 실습 기록 (ALB 생성, SG 연결, 헬스체크)

AWS를 실제로 구성하고 연결하는 실습을 진행해 보았다. 전체적으로 개념이 약해서겠지만 실습을 진행하면서 AWS 네트워크가 어렵다고 느껴졌고, ALB를 “만든다”보다 “제대로 연결한다”가 더 어렵게 느껴졌다. 특히 ALB는 만들었는데 접속이 안 되면 보안그룹, 타겟그룹, 서브넷, 라우팅까지 다 의심해야 해서 머리가 하얘진다. 그래서 ALB 하나를 실제로 만들고, “ALB SG → EC2 SG” 연결 규칙을 어떻게 설정했는지 콘솔 화면 기준(캡처 순서)으로 학습 기록을 남긴다.

사전 준비: 내가 점검한 체크리스트


나는 실습 전에 “구조를 먼저 고정”하는 게 중요했다. ALB는 퍼블릭에서 요청을 받고, EC2는 프라이빗에 숨긴다는 기본 원칙을 세웠다. 그래서 내가 준비한 전제는 다음과 같다.
첫째, VPC는 이미 있고(없으면 새로 생성), Public Subnet 2개 + Private Subnet 2개로 AZ 2개에 걸쳐 준비되어 있어야 한다. ALB는 최소 2개 AZ에 걸쳐 서브넷을 선택하는 경우가 많고, 나도 고가용성 감각을 익히려고 2개를 기준으로 잡았다. Public Subnet 라우트 테이블에는 0.0.0.0/0 -> IGW가 있어야 한다. 여기서 나는 캡처를 하나 남겼다. “Public Subnet 선택 화면 + 해당 Subnet의 Route Table 화면”을 같이 찍어두면 나중에 ‘왜 퍼블릭이 아닌데?’를 바로 확인할 수 있다.
둘째, EC2는 Private Subnet에 배치해두고, 앱이 실제로 포트를 리슨하게 만들어둔다. 나는 여기서 실수를 자주 했는데, SG만 열어놓고 애플리케이션이 안 떠 있으면 헬스체크가 실패한다. 그래서 EC2에서 80이나 8080 중 하나를 정하고, 그 포트로 간단한 응답(예: /health에서 200)을 주도록 준비했다. 이 부분도 캡처 포인트다. “EC2 인스턴스 상세 화면(서브넷/보안그룹/프라이빗 IP) + 서버에서 리슨 포트 확인”을 같이 남겨두면 원인 추적이 쉬워진다.
셋째, NAT가 없으면 Private Subnet의 EC2가 업데이트/패키지 설치가 막힐 수 있다. 나는 비용 때문에 NAT를 최소화하고 싶은 편인데, 이번 실습에서는 이미 앱이 올라간 상태라는 전제라면 NAT 없이도 가능하다. 다만 EC2에서 뭔가 설치가 필요하면 NAT 또는 SSM을 고려해야 한다.
마지막으로, 이름 규칙을 정했다. 나는 나중에 지우기 쉽게 `study-alb`, `study-tg`, `study-ec2-sg` 같은 식으로 리소스 이름을 통일했다. 실습 후 정리할 때 이 규칙이 진짜 도움이 된다.

ALB 생성: 내가 콘솔에서 작업한 순서 그대로 적어보기

이제 진짜 ALB를 만든다. 나는 AWS 콘솔에서 EC2 메뉴로 들어가서 Load Balancers를 찾는다(또는 검색창에서 “EC2” → “Load balancers”). 그리고 Create load balancer를 누르고, Application Load Balancer를 선택했다.
1: “Load balancer 유형 선택 화면(ALB 선택)”
다음은 기본 설정이다. 이름은 `study-alb`로 하고, Scheme은 internet-facing(외부 공개)으로 선택했다. IP address type은 기본 IPv4로 두었다(학습 목적).
2: “ALB 기본 설정 화면(이름, scheme, IP type)”
그 다음 Network mapping에서 VPC를 선택하고, Availability Zones에서 Public Subnet 2개를 체크한다. 나는 여기서 실수할 뻔했다. 실수 포인트는 “퍼블릭처럼 보이는 서브넷 이름을 골랐는데, 실제로는 IGW 라우팅이 없는 서브넷”을 선택하는 것이다. 그래서 이 단계에서 서브넷 선택 화면을 캡처해두고, 바로 라우트 테이블 화면을 추가 캡처로 남겼다.
3: “Network mapping에서 Public Subnet 2개 선택 화면”
4: “각 Public Subnet의 Route Table(0.0.0.0/0 -> IGW 확인)”
리스너(Listener)는 우선 HTTP:80으로 시작했다. SSL은 나중에 붙일 계획이다(ACM 인증서 등). Default action은 Target group으로 Forward인데, 여기서 나는 “새 타겟 그룹 생성”으로 진행했다.
5: “Listener(80) + Default action(Target group 연결) 설정 화면”
Target group을 만들 때 Target type은 Instances로 했다(가장 단순). Protocol/Port는 내 앱이 리슨하는 포트로 맞춘다. 나는 학습용으로 EC2에서 80을 열고 Nginx 같은 걸로 응답을 주는 방식이 제일 쉬웠다. 헬스체크는 기본이 / 인 경우가 많은데, 나는 /health 같은 엔드포인트를 만들어둔 뒤 그 경로로 바꾸는 습관을 들이려고 했다.
6: “Target group 생성 화면(타입, 포트, 헬스체크 경로)”
그리고 마지막에 EC2 인스턴스를 타겟으로 등록한다. 여기서 등록은 됐는데 헬스체크가 Unhealthy로 뜨면, 대부분 보안그룹 또는 앱 포트 문제다. 나는 일단 등록 화면을 캡처했다.
7: “Target 등록 화면(인스턴스 체크 후 Include)”
여기까지 하고 Create를 누르면 ALB가 생성된다. 생성 직후에는 Provisioning 상태라 몇 분 뒤 Active로 바뀐다(이건 시간 문제라서 나는 상태 화면을 캡처로 남겨두는 정도만 했다).
8: “ALB 상태(Active) + DNS name 확인 화면”

핵심: “ALB SG → EC2 SG” 연결 규칙을 내가 만든 방식

이 실습에서 진짜 핵심은 보안그룹이었다. 나는 예전에는 테스트한다고 EC2 SG에 0.0.0.0/0로 80을 열어버린 적이 있는데, 그 순간 이 아키텍처의 의미가 사라진다. 그래서 이번에는 무조건 “ALB가 받은 트래픽만 EC2가 받게” 만들었다.
내가 만든 SG는 두 개다.
1) ALB용 SG: `sg-alb`
2) EC2용 SG: `sg-app`
ALB SG 설정은 단순했다. 인바운드에 HTTP 80을 0.0.0.0/0로 열었다(학습용). 운영이라면 443 중심으로 바꾸고, 80은 리다이렉트 정도로 쓰는 구성이 많다고 들었다. 아웃바운드는 기본 허용으로 뒀다.
캡처 9: “ALB SG 인바운드 규칙(80 from 0.0.0.0/0)”
그리고 제일 중요한 EC2 SG 설정을 했다. EC2 SG 인바운드에 HTTP 80(또는 앱 포트)을 열되, 소스를 0.0.0.0/0가 아니라 “ALB의 SG(sg-alb)”로 지정했다. AWS 콘솔에서 Source에 보안그룹을 선택할 수 있는데, 여기서 sg-alb를 지정하면 된다.
이 설정을 한 문장으로 적으면 이렇다. “앱 서버는 ALB에서 오는 트래픽만 받는다.”
캡처 10: “EC2 SG 인바운드 규칙(앱 포트 from sg-alb)”
그리고 DB가 있다면(이번 글은 ALB 실습이지만 내 머릿속 기본 그림이라) RDS SG는 DB 포트를 EC2 SG(sg-app)만 허용하는 패턴으로 이어진다. 이렇게 SG를 ‘연결’해두면 IP가 바뀌어도 구조가 유지돼서, 내가 좋아하는 방식이다.
마지막으로 헬스체크가 실패하면 내가 보는 순서는 정해져 있다.
- Target Group에서 Unhealthy 이유 확인(상태 메시지 캡처)
- EC2에서 앱 포트 리슨 여부 확인
- EC2 SG 인바운드 소스가 sg-alb로 되어 있는지 확인
- ALB가 public subnet에 있고 IGW 라우팅이 있는지 확인
나는 이 순서로 보면 대부분 10~15분 안에 원인을 찾는 편이었다(예전에는 몇 시간을 날렸다). 그래서 실습 기록에도 “문제 발생 → 원인 → 해결”을 캡처와 함께 남겨두는 게 좋다고 느꼈다.

나는 ALB를 만들 때 “서브넷 선택(퍼블릭/IGW 확인) → 타겟그룹(헬스체크 경로) → 보안그룹 연결(ALB SG → EC2 SG)” 이 세 단계가 핵심이라고 정리했다. 특히 EC2 SG를 0.0.0.0/0로 열지 않고, ALB SG를 소스로 제한하는 순간부터 이 구조가 ‘진짜’가 된다. 다음 글에서는 80에서 443(ACM 인증서)로 바꾸고, 80은 443로 리다이렉트하는 설정까지 해보면서 운영 감각을 조금 더 붙여볼 생각이다.

AWS콘솔화면은 실습하기 전에는 너무 어렵게만 느껴졌다. 그리고 이 부분은 실습이 정말 중요하다고 이번에 다시한번 느꼈다. AWS를 배우고자하는 사람들에게 가장 어려움이 되는 부분이 이게 아닐까 생각도 들었다. 프리티어가지고는 다 실습하기에는 부족하고 일반 회사에서는 AWS구성과 관련된 내용을 직원들이 접할수가 없다. 이 부분이 AWS 인프라 전문가가 되기위한 장애물이 되는것 같다. 담당자가 아니면 배울기회가 없고 시중에 나와있는 교재는 충분한 지식을 얻기에 너무 부족하다. 특히 과금과 관련된 구성 노하우는 누가 가르쳐주지도 않는다. 경험이 중요한데 이부분은 시행착오(요금폭탄)를 겪지 않으면 지식을 습득하기도 어렵다. 정말 갈길이 멀다는 생각이 든다. 


댓글

댓글 쓰기

이 블로그의 인기 게시물

JOIN 기초: users와 point_history를 합쳐 ‘회원별 요약(잔액/최근 활동)’ 만들기

포인트 원장(point_history)만으로도 잔액과 통계를 만들 수 있지만, 실제 화면이나 운영 도구에서는 거의 항상 “사용자 정보”가 함께 필요합니다. 예를 들어 이런 질문들은 point_history만으로는 답이 부족합니다. 이 uid가 누구인지(가입일, 상태 등) 함께 보고 싶다 회원 목록을 보면서 각 회원의 잔액/최근 활동을 한 줄로 요약하고 싶다 최근 7일 동안 사용이 많은 회원을 “회원 정보와 함께” 추려 보고 싶다 이때 필요한 것이 JOIN입니다. JOIN은 테이블을 “합치는” 기능이지만, 정확히는 두 테이블의 행을 연결 해 새로운 결과를 만드는 방식입니다. 이번 글에서는 포인트 시스템에서 가장 흔한 JOIN 패턴(회원 + 원장 요약)을 중심으로, INNER JOIN/LEFT JOIN의 차이와 실전에서 헷갈리는 포인트를 정리합니다. 이 단원의 목적: “회원 목록 + 포인트 요약”을 안정적으로 뽑아내기 JOIN은 문법을 외우는 것보다 “어떤 결과를 만들고 싶은지”를 먼저 그리는 것이 중요합니다. 이번 글의 목표는 아래 3가지입니다. INNER JOIN과 LEFT JOIN의 차이를 이해하고 상황에 맞게 선택한다 집계(GROUP BY)와 JOIN을 결합해 ‘회원별 잔액/통계’를 만든다 JOIN에서 자주 발생하는 오류(행 폭증, 중복 집계)를 피하는 패턴을 익힌다 준비: users에 최소한의 컬럼을 더해 “JOIN 결과가 읽히게” 만들기 이전 글에서는 users가 uid와 created_at만 있었지만, JOIN 결과를 보기 편하게 하려면 display_name 같은 컬럼이 하나 있으면 좋습니다. 실제 서비스라면 이메일/닉네임/상태값이 있을 텐데, 여기서는 학습 목적상 간단히 display_name을 추가합니다. -- 이미 있다면 생략 ALTER TABLE users ADD COLUMN display_name VARCHAR(50) NULL; -- 예시 값 입력(학습용) UPDATE users SET display_n...
자세한 내용 보기

점검 SQL: “원장 합계(SUM) vs balance” 불일치를 찾아내고 원인을 좁히는 방법

포인트 시스템은 “정상 처리”만 잘 만들면 끝나는 것처럼 보이지만, 실제로는 시간이 지날수록 다양한 이유로 데이터가 어긋날 수 있습니다. 예를 들어 이런 상황이 생깁니다. 중간 장애로 트랜잭션이 일부만 반영된 것처럼 보이는 케이스(재처리/수동 개입 포함) 운영 정정(ADJUST)이나 소프트 삭제(hide) 처리 기준이 흔들린 케이스 배치 작업(만료/정산)이 예상과 다른 시간에 들어간 케이스 코드 변경 이후 특정 action_type이 누락/중복 집계된 케이스 그래서 “점검 쿼리”는 기능 쿼리만큼 중요합니다. 특히 balance 테이블(잔액 캐시)을 함께 쓰는 구조라면, 주기적으로 원장 합계와 balance가 같은지 확인해야 합니다. 이 단원의 목적: 불일치를 “발견”하고 “원인”을 좁힐 수 있는 쿼리 세트 만들기 이번 글에서는 아래 3가지를 목표로 합니다. 원장 합계(SUM)와 balance를 비교해 불일치 UID를 뽑는다 불일치가 발견되면 어디서부터 어긋났는지 범위를 좁힌다 자주 발생하는 유형(숨김 처리, 중복 요청, 배치 만료)을 점검 항목으로 만든다 1) 1차 점검: uid별 “원장 잔액”과 “balance 잔액” 비교 가장 기본은 uid별로 두 값을 나란히 놓고 비교하는 것입니다. 여기서는 hide=0만 원장 합계에 포함한다고 가정합니다. SELECT b.uid, b.balance AS balance_cache, COALESCE(l.ledger_balance, 0) AS balance_ledger, b.balance - COALESCE(l.ledger_balance, 0) AS diff FROM point_balance b LEFT JOIN ( SELECT uid, SUM(amount) AS ledger_balance FROM point_history WHERE hide = 0 GROUP BY uid ) l ON l.uid = b.uid WHERE b.balance <> COALESCE(l.ledger_...
자세한 내용 보기

EXPLAIN 기초: 점검/리포트 쿼리가 느려질 때 “왜 느린지” 확인하는 방법

포인트 시스템을 만들어가면서 새삼 느끼는것은 생성형AI가 있어서 설계하고 구상하는게 너무 쉬워졌다는것입니다. 혼자서 했다면 아마도 어려움이 많았을거 같은데 AI와 대화를 하며 개선점을 찾아가는 방식으로 진행하다보니 생각보다 기능이 치밀하게 설계를 할 수 있었습니다. 지금까지 하나하나 학습범위를 늘려가며 왔는데 아직도 갈길이 먼거 같습니다.  포인트 원장(point_history)은 시간이 지날수록 커집니다. 데이터가 커지면, 기능 쿼리(내역/잔액)뿐 아니라 점검 쿼리(원장 vs balance 비교, 월별 집계, ref_id 그룹핑)도 점점 느려집니다. 이때 흔히 “인덱스를 더 만들면 되지 않을까?”라고 생각하지만, 인덱스는 무조건 늘린다고 좋아지지 않습니다. 어떤 쿼리가 어떤 방식으로 실행되는지 모르면 잘못된 인덱스를 만들거나, 효과 없는 튜닝을 반복할 가능성이 큽니다. 그래서 필요한 도구가 EXPLAIN 입니다. EXPLAIN은 “이 쿼리를 DB가 어떤 순서로 실행할지”를 보여주는 실행 계획입니다. 즉, 느린 이유를 추측하지 않고 눈으로 확인 할 수 있게 해줍니다. 이 단원의 목적: 실행 계획을 보고 “어디를 고칠지” 결정하기 이번 글의 목표는 아래 3가지입니다. EXPLAIN 결과에서 최소한의 핵심 항목을 읽을 수 있게 된다 포인트 시스템 쿼리에서 자주 나오는 느린 패턴(풀 스캔, filesort)을 구분한다 인덱스를 “조회 패턴에 맞게” 설계하는 감각을 만든다 1) EXPLAIN 사용법: SELECT 앞에 붙이면 된다 가장 기본은 SELECT 앞에 EXPLAIN을 붙이는 것입니다. EXPLAIN SELECT id, action_type, amount, created_at FROM point_history WHERE uid = '11111111-1111-1111-1111-111111111111' AND hide = 0 ORDER BY created_at DESC, id DESC LIMIT 50; 실행 결과는 ...
자세한 내용 보기