AWS에서 ELB의 역할, 개념잡기 그리고 실습

처음 근무를 했던 회사의 서버는 2개의 WEB서버, 2개의 WAS서버 그리고 1개의 DB로 구성되어 있었다. 비교적 큰 회사였기때문에 인프라팀이 따로 있었고 개발자는 개발만 할 수 있는 환경이었다. 여하튼 웹서버가 2대인데 서버1대가 죽었을때 나머지 한대가 서비스를 지속적으로 할 수 있는 구조였는데 평상시에는 부하 분산을 어떻게 할까 궁금해서 PM에게 질문을 한 적이 있었다. 그때 WEB서버 앞에 로드밸런서가 있어서 적절하게 분산시키고 있어요라고 대답을 들었다. 아마도 로드밸러서라는것에대해서 처음 알게 되었다. 이렇게 예전에는 “로드밸런서 = 트래픽 나눠주는 것” 정도로만 알고 있었다. 그런데 AWS에서 ELB를 보니 ALB, NLB, (그리고 예전의 CLB)까지 종류가 나뉘어 있어서 더 헷갈렸다. 그래서 이번 기회에 AWS 공부를 하면서 정리한 ELB 개념을 정리해보려 한다. 목표는 “언제 ALB를 쓰고, 언제 NLB를 쓰는지”를 내 말로 설명할 수 있게 되는 것이다.

소제목 1 - ELB 기본: 내가 이해한 “트래픽 입구를 하나로 만드는 역할”


ELB(Elastic Load Balancing)는 내가 이해하기로 “서비스 앞단에서 트래픽을 받아서 뒤쪽 자원으로 분산해주는 입구”다. 사용자는 내 서비스의 실제 서버(EC2)가 몇 대인지, 어디에 있는지 몰라도 된다. 사용자는 ELB로 들어오고, ELB가 뒤에서 살아있는 서버로 요청을 넘겨준다. 그래서 나는 ELB를 “문지기 + 교통정리”라고 생각했다.
처음엔 로드밸런서를 굳이 왜 써야 하나 싶었는데, 공부하면서 가장 크게 와닿은 건 고가용성과 확장성이다. 서버 한 대가 죽어도 ELB가 다른 서버로 보내주면 서비스가 계속 살아있다. 트래픽이 늘면 서버를 더 붙이고(오토스케일링), ELB는 새로 붙은 서버로도 자동으로 분산한다. 또한 보안 측면에서도 장점이 있다. 외부에 직접 노출되는 건 ELB만 두고, 실제 앱 서버는 Private Subnet에 숨기는 구조가 가능해진다. 나는 “Public ALB + Private EC2” 구조를 공부하면서 이걸 확실히 체감했다. 앞서 작성한 글에서도 언급했지만 보안은 아무리 강조해도 부족하지 않은거 같다. 우리회사 인프라 담당자도 모든 구성들은 private으로 되어 있다고 했다. 
ELB를 쓸 때 항상 같이 나오는 개념이 Target Group과 Health Check다. ELB는 아무 서버에나 보내지 않고, 헬스체크에 통과한 타겟(EC2, ECS, IP, Lambda 등)에게만 트래픽을 보낸다. 여기서 내가 자주 겪는 실수는 “서버는 살아있는데 헬스체크가 실패해서 트래픽이 안 간다”였다. 결국 로드밸런서 문제처럼 보여도, 실제로는 보안그룹(ELB → EC2 포트 허용)이나 헬스체크 경로(/health 같은 것), 앱 리슨 포트가 문제인 경우가 많았다. 그래서 나는 ELB를 볼 때 “Target Group 헬스체크부터 확인”을 습관으로 잡아두고 있다.

소제목 2 - ALB vs NLB: 내가 헷갈렸던 차이를 이렇게 정리했다

ELB는 종류가 있는데, 내가 주로 만나는 건 ALB(Application Load Balancer)와 NLB(Network Load Balancer)다. 예전의 CLB(Classic Load Balancer)는 레거시 성격이라 신규에서는 ALB/NLB를 먼저 보는 흐름이라고 이해했다(다만 기존 서비스에 남아있을 수는 있다).
내가 정리한 핵심은 “ALB는 HTTP/HTTPS 같은 애플리케이션 레벨(L7), NLB는 TCP/UDP 같은 네트워크 레벨(L4)”이다. 이 말이 교과서 같아서 처음엔 감이 안 왔는데, 나는 기능 차이로 외웠다.
- ALB: URL 경로(/api, /images), 호스트(도메인), 헤더 같은 기준으로 라우팅이 가능하다. 즉, 같은 로드밸런서 하나로도 “/api는 API 서버로, /static은 다른 서버로” 같은 분기가 된다. 웹 서비스에서는 이런 기능이 정말 자주 필요해서, 나는 대부분의 일반적인 웹/백엔드 서비스는 ALB가 기본이라고 생각하게 됐다. 또 HTTPS 종료(SSL/TLS Termination)를 ALB에서 처리하고, 뒤쪽 서버는 HTTP로 단순화하는 구성도 흔하다.
- NLB: 더 낮은 레벨에서 빠르고 단순하게 트래픽을 전달하는 느낌이다. TCP 기반의 서비스, 고정 IP가 필요한 상황, 매우 높은 처리량/지연시간에 민감한 트래픽 같은 케이스에서 고려한다고 들었다. 특히 “클라이언트 IP를 보존해야 한다”거나 “TLS를 패스스루로 처리해야 한다” 같은 요구가 있으면 NLB 쪽이 떠오른다.
내가 실제로 선택할 때 쓸 기준도 적어뒀다. “HTTP 기반 웹/REST API면 일단 ALB부터”, “TCP/UDP 또는 고정 IP/극저지연 요구가 강하면 NLB 후보” 정도로. 물론 실무에서는 더 복잡하겠지만, 초보자인 내가 길을 잃지 않으려면 이 정도 원칙이 먼저 필요했다.
그리고 ELB와 보안그룹의 관계도 헷갈렸는데, 나는 이렇게 기억했다. ALB를 쓰는 구조에서는 보통 “ALB SG는 80/443을 외부에 열고, EC2 SG는 ALB SG에서 오는 트래픽만 허용”으로 묶는다. 이 패턴이 잡히면, 외부에서 서버로 직접 들어오는 길을 막을 수 있다. 즉, 로드밸런서는 단순한 분산 장치가 아니라 “보안 경계” 역할도 한다.

소제목 3 - 내가 실습에서 자주 막히는 지점: 헬스체크와 리스너, 그리고 포트

ELB를 실습하다 보면 “분명 다 만들었는데 접속이 안 된다” 상황이 자주 생긴다. 나도 그랬고, 거의 매번 원인이 비슷했다. 그래서 나만의 점검 순서를 기록해둔다.
첫째, 리스너(Listener)를 확인한다. ALB라면 80 또는 443 리스너가 있어야 하고, 그 리스너가 어떤 Target Group으로 포워딩하는지 확인해야 한다. 둘째, Target Group의 헬스체크 설정을 확인한다. 포트는 맞는지, 프로토콜은 맞는지, 헬스체크 경로(/, /health)가 실제 서버에서 200을 주는지 확인한다. 셋째, 보안그룹이다. ALB SG는 외부 인바운드를 열어야 하고, EC2 SG는 “ALB SG를 소스로” 앱 포트를 열어줘야 한다. 여기서 소스를 0.0.0.0/0로 열면 테스트는 되지만 보안은 망가진다. 나는 학습 단계에서도 최대한 SG 참조 방식으로 해보려고 한다.
넷째, 서브넷 배치다. ALB가 Public Subnet에 들어가려면 그 서브넷 라우트 테이블에 0.0.0.0/0 -> IGW가 있어야 한다. 그리고 ALB는 보통 2개 이상의 AZ에 걸쳐 서브넷을 선택한다. 다섯째, 서버 애플리케이션이 실제로 포트를 리슨하고 있는지 확인한다. ELB 설정이 아무리 완벽해도 서버에서 8080을 열지 않으면 헬스체크가 실패한다.
마지막으로, 로그와 관측도구를 켜는 습관을 들이려고 한다. ALB 액세스 로그(S3), CloudWatch 지표/알람 같은 걸 켜두면 “왜 안 되는지”를 감으로 추측하지 않고 근거로 확인할 수 있다. 나는 인프라 초보라서 추측만 하다가 시간 버리는 일이 많았는데, ELB는 특히 관측을 붙이는 게 중요하다고 느꼈다.

ELB는 트래픽의 입구를 하나로 만들고, 살아있는 서버로 분산해주는 AWS의 핵심 구성요소다. 내가 정리한 선택 기준은 “웹/HTTP면 ALB, TCP/UDP/고정 IP/고성능 요구면 NLB”였다. 그리고 실습에서 막히면 리스너 → 타겟 그룹 헬스체크 → 보안그룹 → 서브넷/라우팅 순으로 점검하면 대부분 해결 실마리가 보였다. 다음에는 ALB 하나를 실제로 만들고, “ALB SG → EC2 SG” 연결 규칙을 내가 어떻게 설정했는지까지 캡처 기준으로 기록해보려고 한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

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; 실행 결과는 ...
자세한 내용 보기