흰색기린

NLB

Network Load Balancer

L4(Layer 4)는 OSI 7 계층 모델에서 전송 계층(Transport Layer)을 의미

TCP: 안전한 택배 서비스

• 연결 지향: 물건(데이터)을 보내기 전에 보내는 사람과 받는 사람이 확실히 준비되었는지 확인합니다.
  • 예: 택배 회사가 물건을 받을 주소와 받는 사람의 정보를 확인.
• 신뢰성 보장: 물건이 안전하게 도착하지 않으면, 다시 보내줍니다.
  • 예: 택배가 분실되면 택배 회사가 재발송.
• 순서 보장: 여러 상자를 보냈을 때 도착 순서를 바르게 맞춥니다.
  • 예: 1번 상자, 2번 상자, 3번 상자가 차례로 도착.
• 속도보다 안정성 우선: 다소 시간이 걸리더라도 정확한 전달을 보장합니다.
  • 예: 귀중품을 배송할 때.

UDP: 간단한 편지

• 비연결 지향: 받는 사람과 미리 확인하지 않고 바로 보냅니다.
  • 예: 편지를 우체통에 넣고 바로 보내는 것.
• 신뢰성 낮음: 편지가 가끔 분실될 수 있지만, 이를 확인하거나 다시 보내지 않습니다.
  • 예: 엽서를 보냈는데 받는 사람이 못 받았을 수 있음.
• 순서 보장 없음: 여러 장의 편지를 보냈을 때 도착 순서는 신경 쓰지 않습니다.
  • 예: 편지 3장을 보냈는데 2번이 먼저 오고 1번이 나중에 도착.
• 속도 우선: 빠르게 보내는 것이 중요합니다.
  • 예: 생일 파티 초대장처럼 빨리 도착하면 좋지만, 없어도 큰 문제는 없는 경우.

HTTP (택배로 보내는 일반 편지)

• HTTP는 TCP 위에서 작동하는 프로토콜로, 웹 브라우저와 서버가 대화하는 규칙입니다.
  • 예: "내가 www.example.com에서 이 페이지를 보고 싶어!"라는 요청을 보내고, 그에 대한 웹 페이지 데이터를 받음.
• 보안이 없음:
  • 요청과 응답 내용이 암호화되지 않아서, 누군가 중간에서 볼 수 있습니다.
  • 예: 일반 편지를 보낼 때, 누군가 봉투를 열어 내용을 읽을 수 있음.
• HTTP는 빠르고 간단하지만, 민감한 정보에는 적합하지 않습니다.

HTTPS (택배로 보내는 금고 편지)

• HTTPS는 HTTP + SSL/TLS 보안이 결합된 프로토콜입니다.
  • 모든 데이터가 암호화되어 중간에 누가 훔쳐봐도 내용을 알 수 없습니다.
  • 예: 중요한 문서를 금고에 넣고, 택배로 안전하게 전달.
• 브라우저와 서버 간의 데이터 전송이 보안 연결을 통해 이루어집니다.
  • 예: 온라인 쇼핑, 은행 사이트, 로그인 등.
• HTTPS는 오늘날 대부분의 웹사이트에서 사용되며, 주소창에 자물쇠 아이콘🔒으로 표시됩니다.

• TCP: 데이터를 안전하게 전달하는 택배 서비스.
• UDP: 신뢰성 낮은 일반 편지
• HTTP: 웹에서 데이터를 요청하고 주고받는 규칙, 보안은 없음.
• HTTPS: HTTP에 보안을 더한 프로토콜, 민감한 데이터를 안전하게 주고받음.

ALB (Application Load Balancer)

• **L7(애플리케이션 계층)**에서 작동.
• 웹사이트 관리자처럼, 요청 내용을 보고 알맞은 곳으로 보냄.
  • 예: "로그인 페이지 요청이면 서버 A로 보내고, 이미지 요청이면 서버 B로 보내자!"
• 주로 HTTP/HTTPS 트래픽을 처리.
• 사용 사례:
  • 웹사이트, API, 마이크로서비스.

NLB (Network Load Balancer)

• **L4(네트워크 계층)**에서 작동.
• 빠른 우체부처럼, 요청 내용을 보지 않고 지정된 서버로 바로 전달.
  • 예: "이 요청은 서버 C로 보내야 해!" (IP/포트 기반).
• TCP/UDP 트래픽을 처리.
• 사용 사례:
  • 실시간 게임, 채팅 서비스, IoT 데이터 전송.

핵심 차이:

• ALB는 똑똑하게 요청 내용을 분석하고,
• NLB는 단순하고 빠르게 요청을 전달합니다.

인바운드 규칙과 아웃바운드 규칙이란?

인바운드 규칙과 아웃바운드 규칙은 네트워크 보안 설정에서 사용되며, 클라우드 인프라(예: AWS 보안 그룹)나 방화벽에서 특정 트래픽의 허용 여부를 제어합니다.

1. 인바운드 규칙 (Inbound Rules)

• 정의:
  • 네트워크 외부에서 내부로 들어오는 트래픽을 허용하거나 차단하는 규칙입니다.
  • 예를 들어, 클라이언트가 서버에 접속하려는 트래픽이 인바운드 트래픽에 해당합니다.
• 사용 사례:
  1. 웹 서버(예: HTTP 요청):
     • 외부 사용자가 **포트 80(HTTP)**을 통해 웹사이트에 접속.
     • 인바운드 규칙: 포트 80을 허용.
  2. 데이터베이스 접근 제한:
     • 애플리케이션 서버만 **데이터베이스 포트(예: 3306)**에 접근 가능.
     • 인바운드 규칙: 포트 3306을 애플리케이션 서버의 IP만 허용.
• 예시:
  • 허용 규칙: "모든 IP(0.0.0.0/0)에서 포트 80으로의 트래픽 허용".
  • 차단 규칙: "외부에서 포트 22로의 SSH 접속 금지".

2. 아웃바운드 규칙 (Outbound Rules)

• 정의:
  • 네트워크 내부에서 외부로 나가는 트래픽을 허용하거나 차단하는 규칙입니다.
  • 예를 들어, 서버가 다른 서버에 요청하거나 인터넷에 데이터를 보내는 트래픽이 아웃바운드 트래픽에 해당합니다.
• 사용 사례:
  1. 애플리케이션 서버가 외부 API에 요청:
     • API 서버의 포트 443(HTTPS)으로 나가는 트래픽 허용.
     • 아웃바운드 규칙: 포트 443을 특정 IP로 허용.
  2. 데이터 유출 방지:
     • 특정 내부 서버가 인터넷에 직접 접속하지 못하도록 차단.
     • 아웃바운드 규칙: 모든 포트와 IP로의 트래픽 차단.
• 예시:
  • 허용 규칙: "서버에서 포트 443으로의 모든 아웃바운드 트래픽 허용".
  • 차단 규칙: "내부 데이터베이스에서 외부 네트워크로 나가는 트래픽 금지".

사례 예시

사례 1: 웹 애플리케이션 서버

• 목표: 외부 사용자가 웹사이트에 접속하고, 서버가 외부 API를 호출 가능하게 설정.
• 설정:
  • 인바운드 규칙:
    • 포트 80(HTTP) 및 443(HTTPS) 허용 (모든 IP).
  • 아웃바운드 규칙:
    • 포트 443(HTTPS)을 통한 외부 API 호출 허용.

사례 2: 데이터베이스 서버

• 목표: 외부에서의 접속 차단, 애플리케이션 서버만 접근 허용.
• 설정:
  • 인바운드 규칙:
    • 포트 3306(MySQL) 허용 (애플리케이션 서버의 IP만).
  • 아웃바운드 규칙:
    • 외부 인터넷으로 나가는 모든 트래픽 차단.

요약

• 인바운드 규칙: 외부 → 내부 트래픽을 관리 (클라이언트 요청 처리).
• 아웃바운드 규칙: 내부 → 외부 트래픽을 관리 (외부와 통신 제어).

• ALB (Application Load Balancer)
  👉 웹 애플리케이션을 운영할 때 사용.
  • HTTP/HTTPS 트래픽(7계층) 처리를 잘함.
  • URL별로 트래픽 분배 가능.
  • 예: "로그인 페이지 트래픽은 서버 A로, 상품 페이지 트래픽은 서버 B로 보내라!"

• NLB (Network Load Balancer)
  👉 빠른 트래픽 처리가 필요할 때 사용.
  • TCP/UDP(4계층) 트래픽에 적합.
  • 매우 높은 성능과 낮은 지연 시간 제공.
  • 예: "수천 개의 게임 클라이언트 트래픽을 서버로 보내라!"

• GWLB (Gateway Load Balancer)
  👉 보안 트래픽 관리가 필요할 때 사용.
  • 방화벽 같은 네트워크 보안 장치와 연계.
  • 모든 트래픽을 한 번 거쳐서 검증 가능.
  • 예: "트래픽을 방화벽으로 보내서 악성 트래픽 걸러내라!"

선택 기준:

1. 웹 애플리케이션 운영 → ALB
2. 낮은 지연, 높은 성능 필요 → NLB
3. 보안 장치와 통합 필요 → GWLB

Sticky Session (스티키 세션)

스티키 세션은 사용자의 요청을 항상 같은 서버로 보내는 방식을 말합니다. 로드 밸런서를 사용하는 환경에서 클라이언트와 서버 간의 상태를 유지해야 할 때 사용됩니다.

왜 사용하나요?

1. 상태 유지를 위해
   일부 웹 애플리케이션은 서버 간 세션 상태를 공유하지 못하는 경우가 있습니다.
   예: 로그인 상태, 장바구니 정보, 폼 입력 상태 등.
   • 스티키 세션은 사용자가 항상 같은 서버로 연결되도록 보장해, 이러한 데이터를 유지합니다.
2. 단순화된 애플리케이션 설계
   스티키 세션을 사용하면 별도로 서버 간 세션 동기화를 구현할 필요가 없어 애플리케이션 설계가 단순해집니다.

어디에 사용하나요?

1. 로그인 기반 애플리케이션
   로그인 상태가 서버에 저장되는 경우, 사용자가 항상 같은 서버에 연결되어야 인증 상태를 유지할 수 있습니다.
2. 전자상거래
   장바구니 정보가 특정 서버의 세션에 저장될 때, 사용자가 쇼핑하는 동안 동일한 서버에 연결해야 합니다.
3. 폼 제출 및 작업 흐름 관리
   사용자가 특정 작업을 처리하는 도중 서버가 바뀌면 데이터 유실이나 작업 흐름 중단 문제가 발생할 수 있습니다.

스티키 세션의 작동 방식

• 세션 쿠키 기반:
  로드 밸런서가 클라이언트에게 특정 서버를 식별할 수 있는 쿠키를 발급하고, 해당 쿠키를 기반으로 요청을 같은 서버로 라우팅합니다.
  예: AWS의 Application Load Balancer(ALB)에서는 AWSALB 쿠키 사용.
• 소스 IP 기반:
  클라이언트의 IP 주소를 기반으로 항상 같은 서버에 연결되도록 설정. (주로 NLB에서 사용)

장점

1. 상태 유지 보장
   서버 간 세션 동기화 없이 사용자의 상태를 유지.
2. 애플리케이션 코드 단순화
   상태를 관리하기 위한 추가적인 개발이 불필요.

단점

1. 확장성 제한
   특정 서버에 트래픽이 몰릴 수 있어 부하 분산 효과 감소.
2. 서버 장애 시 문제
   특정 서버가 다운되면 사용자가 세션 정보를 잃을 위험.
3. 멀티 서버 환경에 비효율적
   클라우드 환경에서 서버 간 세션 공유가 가능한 구조에서는 스티키 세션이 필요하지 않을 수도 있음.

대안

1. 세션 공유
   Redis, Memcached와 같은 중앙 세션 저장소를 사용해 모든 서버가 세션 상태를 공유.
2. JWT(JSON Web Token)
   상태를 서버에 저장하지 않고, 클라이언트 측에서 유지하여 서버 간 상태 동기화 문제를 해결.

결론

스티키 세션은 애플리케이션이 서버 간 세션을 공유하지 못하는 경우 간단한 해결책이 될 수 있지만, 확장성과 장애 대응을 고려해야 하는 환경에서는 다른 방법(예: 세션 공유, JWT)을 고려하는 것이 좋습니다.

크로스존 로드 밸런싱 (Cross-Zone Load Balancing)

크로스존 로드 밸런싱은 **로드 밸런서가 요청을 가용 영역(AZ, Availability Zone)**에 관계없이 모든 대상(target)으로 고르게 분배하는 기능을 의미합니다.

작동 방식

기본적으로 AWS의 로드 밸런서는 가용 영역(AZ)별로 균등하게 트래픽을 분배합니다.

• 크로스존 로드 밸런싱 비활성화
  가용 영역 간에 분배는 균등하게 이루어지지만, 각 가용 영역의 대상 수에 따라 불균형이 발생할 수 있음.
  예:
  • AZ1에 2개의 서버, AZ2에 5개의 서버 → AZ1의 각 서버에 더 많은 트래픽이 집중.
• 크로스존 로드 밸런싱 활성화
  로드 밸런서가 가용 영역에 상관없이 모든 대상에게 트래픽을 고르게 분배.
  예:
  • AZ1에 2개의 서버, AZ2에 5개의 서버 → 총 7개의 서버에 트래픽을 균등하게 분배.

어디에 사용되나요?

1. 애플리케이션 로드 밸런서(ALB)
   기본적으로 크로스존 로드 밸런싱이 활성화되어 있음.
2. 네트워크 로드 밸런서(NLB)
   선택적으로 활성화 가능.
3. 클래식 로드 밸런서(CLB)
   선택적으로 활성화 가능.

장점

1. 균등한 부하 분산
   가용 영역의 대상 수가 다르더라도 모든 서버에 트래픽이 균등하게 분배됩니다.
2. 효율적인 리소스 사용
   특정 가용 영역에서 대상 수가 적어도 전체 리소스를 최적으로 활용 가능.
3. 트래픽 불균형 문제 해결
   대상 그룹 내 리소스가 고르게 트래픽을 처리하므로 과부하 방지.

단점

1. 네트워크 비용 증가
   크로스존 로드 밸런싱을 활성화하면 가용 영역 간 트래픽 전송 비용이 발생할 수 있음.
2. 특정 사용 사례와의 비효율성
   만약 가용 영역 간의 데이터 전송을 피해야 하거나, 대상 간 완벽한 격리를 요구하는 경우 크로스존 로드 밸런싱은 적합하지 않을 수 있음.

SSL과 TLS의 차이

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 둘 다 인터넷에서 데이터의 보안을 보장하는 암호화 프로토콜입니다. 하지만, SSL은 더 이상 안전하지 않아서 대부분의 시스템에서 TLS로 대체되었습니다. TLS는 SSL을 개선한 버전입니다. 기본적으로 SSL과 TLS는 비슷한 목적을 가지고 있지만, 차이점도 존재합니다.

1. SSL (Secure Sockets Layer)

• SSL은 인터넷을 통한 데이터 전송의 보안을 제공하는 프로토콜로, 웹 브라우저와 서버 간의 암호화된 연결을 설정하기 위해 사용되었습니다.
• 버전: SSL 1.0은 발표되지 않았고, SSL 2.0(1995)과 SSL 3.0(1996)이 주요 버전이었습니다.
• 문제점: SSL 2.0과 SSL 3.0은 여러 가지 보안 취약점이 발견되어 더 이상 사용되지 않습니다.

2. TLS (Transport Layer Security)

• TLS는 SSL을 대체하는 암호화 프로토콜로, SSL의 보안 취약점을 해결하고 성능과 보안을 향상시킨 버전입니다.
• 버전: TLS 1.0 (1999), TLS 1.1 (2006), TLS 1.2 (2008), TLS 1.3 (2018) 등이 있으며, 최신 버전은 TLS 1.3입니다.
  • TLS 1.3: 성능과 보안을 강화하여 암호화 방식과 핸드쉐이크 절차를 단순화함.
• 보안 강화: TLS는 암호화 수준을 높이고, 더 안전한 알고리즘을 채택하여 공격에 강합니다.

주요 차이점

항목SSLTLS

실제 사용

• 현재 사용되는 프로토콜: 대부분의 현대 웹 서버와 클라이언트는 TLS를 사용하며, SSL은 더 이상 안전하지 않아 대부분 사용하지 않습니다.
• "SSL"이라는 용어의 남아 있는 사용: TLS가 SSL의 후속 프로토콜이지만, 여전히 많은 사람들은 SSL이라는 용어를 사용하여 TLS를 의미하는 경우가 많습니다. 예를 들어, "SSL 인증서"라고 말하지만 실제로는 TLS 인증서를 사용하는 것입니다.

결론

• SSL은 더 이상 안전하지 않으며, 최신 보안 프로토콜인 TLS로 대체되었습니다.
• TLS는 보안 수준이 향상되어, 현재는 인터넷 상에서 데이터를 안전하게 암호화하여 전송하는 표준 프로토콜로 사용되고 있습니다.
• TLS 1.2와 TLS 1.3을 사용하는 것이 현재의 추천된 방식입니다.

드레이닝 (Draining)

**드레이닝 (Draining)**은 주로 네트워크와 서버 관련 용어로 사용되며, 서비스나 리소스를 순차적으로 종료하는 과정을 의미합니다. 이는 서버나 로드 밸런서의 대상 서버에서 트래픽을 더 이상 받지 않도록 처리하는 작업입니다.

1. 로드 밸런서에서의 드레이닝

드레이닝의 역할

로드 밸런서에서 드레이닝은 대상 서버가 요청을 받지 않도록 설정하는 과정으로, 서비스 중단 없이 서버를 점진적으로 종료하기 위해 사용됩니다. 이는 서버 유지보수나 종료 시 중요한 트래픽 손실을 방지합니다.

작동 원리

• 트래픽 차단: 드레이닝을 시작하면 로드 밸런서는 해당 서버로의 새로운 트래픽을 더 이상 보내지 않음.
• 기존 연결 처리: 기존에 연결된 클라이언트 요청은 처리하되, 새로운 요청은 다른 서버로 보내는 방식으로 운영됩니다.
• 목적: 서비스 중단 없이 서버나 리소스를 종료하거나 교체할 수 있도록 합니다.

2. AWS에서의 드레이닝

AWS에서는 **Elastic Load Balancer (ELB)**와 Auto Scaling 그룹에서 드레이닝을 설정할 수 있습니다.

ALB/NLB에서의 드레이닝

1. 정의: 로드 밸런서가 대상 서버로 트래픽을 더 이상 보내지 않도록 하는 과정.
2. 실행 방법: 대상 서버에서 "등록 해제" 또는 "디레게이트(Draining)" 상태로 설정하면 로드 밸런서는 해당 서버로의 새로운 트래픽을 보내지 않음. 기존의 연결은 종료되지 않고 계속 처리됩니다.
3. 유지보수: 서버가 유지보수 상태로 전환되거나 Auto Scaling 그룹에서 서버를 교체할 때 드레이닝을 사용하여 안정적인 종료가 가능합니다.

Auto Scaling 그룹에서의 드레이닝

• 배치 교체: Auto Scaling 그룹에서 인스턴스 종료 시 새로 배치된 인스턴스로 트래픽을 전환하면서, 이전 인스턴스는 드레이닝 상태로 전환되어 현재 진행 중인 트래픽 요청을 끝내고 종료됩니다.

3. 애플리케이션에서의 드레이닝

애플리케이션에서는 유저 세션이나 작업 처리를 종료할 때 드레이닝을 사용하여, 사용자가 작업을 중단하기 전에 트래픽을 안전하게 종료하고 새 요청을 받지 않도록 처리할 수 있습니다.

4. 드레이닝을 사용하는 이유

• 서비스 중단 최소화: 서버나 서비스를 종료할 때, 드레이닝을 사용하여 기존에 진행 중인 연결을 마무리할 수 있어, 서비스 중단 없이 순차적인 종료가 가능합니다.
• 트래픽 손실 방지: 새로운 요청을 받지 않게 하여 불필요한 트래픽 손실을 방지하고, 리소스를 안전하게 종료합니다.
• 시스템 안정성: 불필요한 서버 종료로 인한 시스템 장애를 방지합니다.

결론

드레이닝은 서버나 리소스를 안전하고 점진적으로 종료하기 위한 중요한 과정으로, 로드 밸런서나 서버의 유지보수 및 교체 시에 사용됩니다. 서비스 중단 없이 연결을 종료하고 트래픽을 다른 서버로 원활하게 전환하는 데 도움을 줍니다.

**키 페어(Key Pair)**를 설정하는 이유는 AWS EC2 인스턴스에 안전하게 접근할 수 있도록 하기 위함입니다. 쉽게 말해서, 보안과 접근 제어를 위해 사용됩니다.

키 페어란 무엇인가?

AWS에서 키 페어는 **공개 키(Public Key)**와 비공개 키(Private Key) 한 쌍으로 이루어져 있습니다. 이 키 쌍은 EC2 인스턴스에 SSH로 접속하거나, 암호화된 연결을 통해 로그인할 때 사용됩니다.

• 공개 키(Public Key): 이 키는 서버에 저장됩니다. 공개적으로 공유할 수 있습니다.
• 비공개 키(Private Key): 이 키는 자신만 가지고 있어야 하며, 서버에 접근할 때 사용합니다. 비공개 키를 누구에게도 공유해서는 안 됩니다.

키 페어의 주요 역할

1. 안전한 인증

• 키 페어를 설정하면 암호를 사용하지 않고, 공개 키와 비공개 키를 통해 안전하게 인증합니다.
• 비공개 키는 자신만 가지고 있어야 하므로, 그 키를 가진 사람만 EC2 인스턴스에 접근할 수 있습니다.

2. 암호화된 연결

• 키 페어를 이용한 SSH 연결은 암호화된 연결입니다. 즉, 비공개 키를 사용하여 인증 후 서버와의 통신이 암호화되어, 데이터가 중간에 가로채지지 않도록 보호됩니다.
• 이는 **중간자 공격(MITM)**을 방지하는 중요한 보안 수단입니다.

3. 무차별 대입 공격 방지

• 암호 기반의 로그인은 **무차별 대입 공격(brute force attack)**에 취약할 수 있습니다. 예를 들어, 공격자가 여러 비밀번호를 시도하여 로그인할 수 있습니다.
• 키 페어 방식에서는 비공개 키를 가지고 있어야 하므로, 단순히 비밀번호를 추측해서 로그인하는 방식은 불가능합니다. 키가 없으면 아예 접속 자체가 불가능합니다.

왜 키 페어를 설정하나요?

1. 보안 강화
   • 비밀번호를 사용하는 대신, 키 페어를 이용한 인증은 더 안전합니다. 비밀번호는 사람이 쉽게 추측할 수 있는 반면, 키 페어는 복잡한 암호화 방식을 사용하므로 안전합니다.
2. 접근 제어
   • 키 페어를 소유한 사람만 EC2 인스턴스에 접근할 수 있습니다. 즉, 비공개 키를 가진 사람만 로그인할 수 있기 때문에, 불법적인 접근을 막을 수 있습니다.
3. 암호화된 통신
   • 비공개 키와 공개 키는 암호화된 연결을 설정하는 데 사용됩니다. 이로 인해 네트워크에서 데이터를 주고받을 때 중간에서 탈취되는 일이 없도록 보장합니다.

실제 예시

1. 키 페어 생성 및 다운로드
   • AWS EC2 인스턴스를 생성할 때, 키 페어를 생성합니다. 이때 비공개 키를 다운로드합니다.
   • 이 키는 EC2 인스턴스에 SSH로 연결할 때 사용됩니다.
2. EC2 인스턴스에 접근
   • 예를 들어, ssh -i "your-key.pem" ec2-user@your-ec2-public-ip 명령어를 통해 EC2 인스턴스에 접근할 때, your-key.pem 파일(비공개 키)이 인증에 사용됩니다.
   • 만약 비공개 키가 없다면, 접근이 불가능합니다.

결론

키 페어는 보안적인 이유로 사용되며, EC2 인스턴스에 안전하게 접근할 수 있도록 하는 중요한 방법입니다. 비공개 키를 가진 사람만 해당 인스턴스에 접근할 수 있으며, 이 과정에서 암호화된 연결을 통해 데이터를 보호할 수 있습니다.