Skip to content
BranchesTags

Latest commit

 

History

52 Commits

Folders and files

NameName
Last commit message
Last commit date
README.md
README.md
 
 

Repository files navigation

Network

이정민

VMware 환경에서 NAT = Bridge + LAN Segment ?

NAT

역할: 내부 네트워크의 여러 기기가 하나의 공인 IP를 사용해 인터넷에 접근할 수 있도록 하는 IP를 공유한다.

주요 기능:

  • 주소 변환: 내부의 사설 IP(예: 10.x.x.x)와 외부의 공인 IP(예: 203.0.113.x)를 상호 변환한다.
  • 포트 매핑: 하나의 공인 IP를 여러 내부 기기가 공유할 수 있도록 각 연결마다 다른 포트 번호를 할당하여 구분한다.
  • 연결 추적 및 보안: 각 연결의 상태를 NAT 테이블에 기록해 응답을 올바른 내부 기기로 전달하며 내부 네트워크 구조가 외부에 노출되지 않도록 보호한다.

예시: 집의 Wi-Fi를 사용할 때 컴퓨터, 스마트폰 등이 각각 10.0.0.10, 10.0.0.11의 사설 IP를 사용하며 라우터는 하나의 공인 IP(예: 203.0.113.5)를 통해 외부와 통신한다. 각 기기의 연결은 포트 번호로 구분되어 관리한다.

Bridge

역할: 여러 LAN Segment를 Cable이나 Switch과 같은 물리적 장비나 vLAN 등의 논리적 설정을 통합해 모든 기기가 동일한 브로드캐스트 도메인을 공유하도록 한다.

주요 기능:

  • 데이터 전달: 데이터 링크 계층에서 작동해 MAC 주소를 기반으로 데이터를 그대로 전달한다.
  • 네트워크 확장: 각 Segment를 한 기기가 보낸 브로드캐스트 메시지가 도달할 수 있는 모든 기기들의 범위로 통합한다. 동일한 네트워크 내의 모든 기기가 같은 브로드캐스트 영역을 공유하게 함으로써 기기들 간의 통신이 원활하게 이루어지도록 지원한다.

예시: 사무실 내 각 층의 네트워크를 Switch 또는 Bridge 장비로 연결하여 모든 기기가 동일한 네트워크 상에서 자유롭게 통신할 수 있도록 하는 경우

LAN Segment(vSwitch 옵션)

역할: 동일한 IP 대역과 브로드캐스트 영역을 공유하는 기기들의 집합으로 기본적인 네트워크 통신 환경을 제공한다.

주요 기능:

  • 고유 IP 할당: 각 기기는 네트워크 내에서 충돌 없이 고유한 IP(예: 10.x.x.x)를 사용한다.
  • 기본 통신: 같은 LAN Segment에 속한 기기들은 직접 통신하며 데이터를 주고받을 수 있다.

예시: 가정 내 컴퓨터, 프린터 등 모두 동일한 10.x.x.x 대역을 사용하여 하나의 LAN을 구성, 서로 데이터를 교환하는 환경

그래서 NAT는 Bridge + LAN Segment인가?

NAT는 LAN Segment의 내부 통신, Bridge의 외부 연결과 유사한 기능을 제공하지만 LAN Segment와 Bridge를 결합한 것이 아닌 가상 라우터, 스위치, DHCP 서버가 통합된 별도의 가상 네트워크 인프라를 구성한다.

Proxy 서버의 역할과 구성 방법: Forward Proxy, Reverse Proxy

Proxy

Proxy는 클라이언트와 서버 간의 중계자로 클라이언트의 요청을 서버로 전달하고 서버의 응답을 클라이언트에 전달하는 역할을 한다.

Forward Proxy

역할: Forward Proxy는 클라이언트의 요청을 대신하여 서버로 전달하는 프록시이며 클라이언트는 직접 서버와 연결하지 않고 Forward Proxy를 통해 요청을 보내고 응답을 받는다.

주요 기능:

  • 클라이언트의 요청을 대신 처리한다.
  • 인터넷 필터링: 특정 사이트의 접근을 제한한다.
  • 익명화: 사용자의 IP를 숨겨서 익명으로 웹을 서핑한다.
  • 캐싱: 자주 요청되는 데이터를 캐시하여 빠른 응답을 제공한다.

동작 흐름:

  1. 클라이언트 요청: 클라이언트가 웹 요청을 보낸다.
  2. 프록시 서버: 요청은 Forward Proxy 서버로 전달되고 요청을 실제 웹 서버로 전달한다.
  3. 서버 응답: 실제 서버에서 응답을 Forward Proxy 서버로 보낸다.
  4. 클라이언트 응답: Forward Proxy 서버가 응답을 클라이언트로 전달한다.

설정 (예: SQUID, NGINX로 설정):

sudo apt update && sudo apt install squid
sudo nano /etc/squid/squid.conf

wget http://nginx.org/download/nginx-1.18.0.tar.gz
tar -xzvf nginx-1.18.0.tar.gz

git clone https://github.com/chobits/ngx_http_proxy_connect_module.git # ngx_http_proxy_connect_module 모듈을 추가
server {
    listen 3128;  # 포트 3128에서 클라이언트 요청을 수신
    server_name localhost;  # 서버 이름을 'localhost'로 설정

    # 포워드 프록시에서 DNS를 처리하는 DNS 리졸버 설정
    resolver 8.8.8.8;  # 포워드 프록시 요청에 대해 DNS 질의를 처리할 DNS 서버를 구글의 8.8.8.8로 설정

    # 포워드 프록시 요청을 위한 CONNECT 메서드 처리
    proxy_connect;  # CONNECT HTTP 메서드를 사용하여 프록시 연결을 허용 (주로 HTTPS 연결에 사용)
    proxy_connect_allow         443 563;  # CONNECT 메서드가 연결할 수 있는 포트를 443(HTTPS), 563(SSL)으로 지정
    proxy_connect_connect_timeout 120s;  # 프록시 서버와의 연결 타임아웃을 120초로 설정
    proxy_connect_read_timeout 120s;  # 프록시 서버로부터 응답을 읽는 타임아웃을 120초로 설정
    proxy_connect_send_timeout 120s;  # 프록시 서버에 요청을 보내는 타임아웃을 120초로 설정

    location / {  # 기본 위치 설정, 모든 경로에 대해 프록시 설정을 적용
        proxy_set_header Host $host;  # 클라이언트의 호스트 헤더를 프록시 서버에 전달
        proxy_set_header X-Real-IP $remote_addr;  # 클라이언트의 실제 IP 주소를 X-Real-IP 헤더로 전달
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # X-Forwarded-For 헤더에 클라이언트 IP를 추가
        proxy_set_header X-Forwarded-Proto $scheme;  # 클라이언트 요청의 프로토콜(HTTP/HTTPS)을 X-Forwarded-Proto 헤더로 전달

        # 본문과 쿼리 문자열 전달을 활성화
        proxy_method $request_method;  # 클라이언트의 HTTP 요청 메서드를 그대로 사용하도록 설정
        proxy_set_body $request_body;  # 요청 본문을 프록시 서버에 전달
    }
}
cd /usr/local/nginx/sbin
sudo ./nginx
tail -f /usr/local/nginx/logs/access.log

예시:

  • 익명 Proxy: 사용자가 직접 웹사이트에 접속하지 않고 프록시를 통해 접속하여 IP를 숨긴다.
  • 인터넷 필터링: 특정 기업이나 학교에서 불필요한 웹사이트를 차단할 때 사용한다.

출처: Squid Forward Proxy

Reverse Proxy

역할: Reverse Proxy는 클라이언트가 요청하는 서버가 아닌 중간의 Reverse Proxy 서버가 요청을 백엔드 서버로 전달하여 처리한다.

주요 기능:

  • 로드 밸런싱: 여러 서버로 요청을 분배하여 부하를 분산한다.
  • 보안 강화: 실제 서버의 IP를 숨겨 보안을 향상한다.
  • SSL 종료: SSL 연결을 Reverse Proxy 서버에서 처리하고 실제 서버는 암호화되지 않은 데이터만 처리한다.

동작 흐름:

  1. 클라이언트 요청: 클라이언트가 요청을 Reverse Proxy 서버로 보낸다.
  2. 리버스 프록시: Reverse Proxy 서버가 요청을 백엔드 서버로 전달한다.
  3. 백엔드 서버 응답: 백엔드 서버에서 응답을 Reverse Proxy 서버로 전달한다.
  4. 클라이언트 응답: Reverse Proxy 서버가 응답을 클라이언트에게 전달한다.

설정 (예: NGINX로 설정):

brew install nginx # Homebrew로 설치한 Nginx의 모든 파일은 /opt/homebrew 경로 아래에 위치한 파일들을 수정해야 한다.
sudo mkdir -p /opt/homebrew/etc/nginx/ssl # HTTPS를 활성화하기 위한 SSL 인증서 및 키 파일을 저장하는 용도

sudo openssl genpkey -algorithm RSA -out /opt/homebrew/etc/nginx/ssl/private.key # RSA 알고리즘을 사용하여 개인 키를 생성하고 /opt/homebrew/etc/nginx/ssl/private.key에 저장
sudo openssl req -new -key /opt/homebrew/etc/nginx/ssl/private.key -out /opt/homebrew/etc/nginx/ssl/csr.pem # 개인 키를 사용하여 CSR(Certificate Signing Request)을 생성하고 /opt/homebrew/etc/nginx/ssl/csr.pem에 저장
sudo openssl x509 -req -in /opt/homebrew/etc/nginx/ssl/csr.pem -signkey /opt/homebrew/etc/nginx/ssl/private.key -out /opt/homebrew/etc/nginx/ssl/selfsigned.crt # CSR을 사용하여 자체 서명된 SSL 인증서를 생성하고 /opt/homebrew/etc/nginx/ssl/selfsigned.crt에 저장
sudo vi /opt/homebrew/etc/nginx/nginx.conf # 각 서버 블록과 관련된 설정뿐만 아니라 리소스 관리, 로깅, 파일 포함 등의 설정
#user  nobody;  # nginx 프로세스가 사용할 사용자 이름
worker_processes  1;  # nginx가 사용할 워커 프로세스 수 설정 

#error_log  logs/error.log;  # 에러 로그 파일의 경로 
#error_log  logs/error.log  notice;  # 에러 로그 레벨을 'notice'로 설정 
#error_log  logs/error.log  info;  # 에러 로그 레벨을 'info'로 설정 

#pid        logs/nginx.pid;  # nginx 프로세스의 PID 파일 경로 설정

events {
    worker_connections  1024;  # 한 워커 프로세스가 처리할 수 있는 최대 연결 수 설정
}


http {
    include       mime.types;  # mime 유형을 설정하는 파일을 포함
    default_type  application/octet-stream;  # 기본 MIME 유형 설정

#   log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '  # 로그 형식 설정
#                      '$status $body_bytes_sent "$http_referer" '  # 로그 형식의 일부로 요청 상태 및 바디 크기 포함
#                      '"$http_user_agent" "$http_x_forwarded_for"';  # 로그 형식의 일부로 사용자 에이전트 및 프록시 정보 포함

#   access_log  logs/access.log  main;  # 요청에 대한 접근 로그를 'access.log' 파일에 기록

    sendfile        on;  # 파일을 직접 전송하는 것을 활성화 
    keepalive_timeout  65;  # 연결 유지 시간 설정

#   gzip  on;  # Gzip 압축 활성화

    include servers/*;  # 'servers' 디렉토리 내의 설정 파일들을 포함
    include /opt/homebrew/etc/nginx/sites-enabled/*;  # 'sites-enabled' 디렉토리 내의 설정 파일들을 포함하고 링크가 있어야만 실제 적용
}

sudo mkdir -p /opt/homebrew/etc/nginx/sites-available
sudo vi /opt/homebrew/etc/nginx/sites-available/default # 서버가 처리할 HTTP 및 HTTPS 요청에 대한 라우팅 및 리디렉션 등을 설정
# /opt/homebrew/etc/nginx/sites-available/default
server {
    listen 80;  # HTTP 요청을 받을 포트
    server_name localhost;  # 서버 이름

    # HTTP -> HTTPS 리디렉션
    location / {
        return 301 https://$host$request_uri;  # 모든 HTTP 요청을 HTTPS로 리디렉션
    }
}

server {
    listen 443 ssl;  # HTTPS 요청을 받을 포트와 SSL 활성화
    server_name localhost;  # 서버 이름

    ssl_certificate /opt/homebrew/etc/nginx/ssl/selfsigned.crt;  # SSL 인증서 경로
    ssl_certificate_key /opt/homebrew/etc/nginx/ssl/private.key;  # SSL 인증서 키 경로

    # SSL 설정
    ssl_protocols TLSv1.2 TLSv1.3;  # 지원하는 SSL/TLS 프로토콜 버전 
    ssl_prefer_server_ciphers on;  # 서버 측 암호화 우선 사용
    ssl_ciphers HIGH:!aNULL:!MD5;  # 사용할 암호화 알고리즘 지정 (HIGH 보안 등급 암호화만 허용, NULL 및 MD5 제외)

    # 요청에 대한 로깅
    access_log /var/log/nginx/frontend_access.log;  # HTTP 요청에 대한 접근 로그 파일 경로
    error_log /var/log/nginx/frontend_error.log;  # 오류 로그 파일 경로

    location / {  # 웹 애플리케이션의 루트 디렉토리로 들어오는 요청 처리
        # 프론트엔드로 들어오는 요청을 백엔드 서버로 전달
        proxy_pass http://localhost:8080;  # 요청을 실제 백엔드 서버로 전달
        proxy_set_header Host $host;  # 원본 요청의 호스트 헤더를 백엔드 서버로 전달
        proxy_set_header X-Real-IP $remote_addr;  # 클라이언트의 실제 IP 주소를 백엔드 서버로 전달
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # 프록시 체인을 통해 전달된 모든 IP를 백엔드 서버로 전달
        proxy_set_header X-Forwarded-Proto $scheme;  # 사용된 프로토콜(HTTP/HTTPS)을 백엔드 서버로 전달
    }
}
sudo ln -s /opt/homebrew/etc/nginx/sites-available/default /opt/homebrew/etc/nginx/sites-enabled/default
sudo mkdir -p /var/log/nginx
sudo nginx -t
sudo nginx -s reload
curl -I http://localhost
Image

sites-available과 sites-enabled의 차이

폴더 이름 역할 비유 실제 역할 설명
sites-available/ 메뉴판 창고 모든 사이트 설정 파일을 저장하는 장소로 Nginx는 이 폴더만으로는 적용하지 않지만 실제 설정 수정은 이 파일에서 진행
sites-enabled/ 오늘의 메뉴 Nginx가 실제로 읽고 서비스에 적용하는 설정 파일들의 위치지만 sites-available에 있는 파일을 참조하는 심볼릭 링크만 존재

Q. vi로 수정한 건 sites-available의 파일인데 왜 sites-enabled에도 같은 이름의 파일이 보이는가?
A. sites-enabled에 있는 파일은 실제 파일이 아닌 sites-available에 있는 설정 파일을 참조하는 심볼릭 링크다.
따라서 수정은 available의 원본에서만 발생하며 enabled는 그 결과를 그대로 반영하여 보여준다.

Q. 설정 파일을 sites-enabled/에 직접 작성하면 되는데 왜 sites-available/에 만들고 링크를 연결하는가?
A. 심볼릭 링크 구조를 사용하면 설정 파일을 한 곳(sites-available/)에서 통합 관리할 수 있고 적용 여부는 멀티탭 개별 스위치처럼 심볼릭 링크(sites-enabled/)로 제어할 수 있다. 이는 테스트·운영 등 여러 서비스 환경을 효율적으로 관리하는 데 매우 유리한 방식이다.

예시:

  • 웹 애플리케이션 로드 밸런싱: Reverse Proxy를 사용하여 여러 웹 서버로 트래픽을 분배하고 서버 부하를 분산시킬 수 있다.
  • API 서버 보호: 클라이언트의 요청을 Reverse Proxy 서버로 보내고 실제 API 서버는 보호된다.

그래서 Forward Proxy와 Reverse Proxy는 무엇인가?

  • Forward Proxy는 클라이언트의 요청을 대신 처리하며 익명화, 인터넷 필터링 등에 사용된다.
  • Reverse Proxy는 클라이언트의 요청을 백엔드 서버로 전달하여 로드 밸런싱, 보안 강화 등에 사용된다.
DHCP의 작동 원리는 무엇일까?

DHCP

DHCP는 자동으로 IP를 받고, 네트워크에 바로 접속할 수 있게 해주는 시스템이다.

DHCP를 왜 써야 하는가? : DHCP를 사용하면 IP 설정을 자동화할 수 있어 사람이 일일이 수동으로 설정하지 않아도 된다.

Image

DHCP 작동 원리

시나리오: 스마트폰이 사무실 Wi-Fi에 처음 접속하면서 자동으로 IP를 부여받는 상황을 가정한다. 네트워크에는 DHCP 서버, DNS 서버, File Server, L2 스위치 등이 존재하며 모든 장비는 192.168.0.x 대역의 IP 주소를 사용한다고 전제한다.

DHCP 동작 단계

단계 메시지 설명
1️⃣ DHCP Discover 클라이언트가 DHCP 서버를 찾기 위해 브로드캐스트를 전송
2️⃣ DHCP Offer DHCP 서버가 사용 가능한 IP 주소를 제안
3️⃣ DHCP Request 클라이언트가 특정 IP를 요청
4️⃣ DHCP ACK 서버가 해당 IP 할당을 최종 승인

이미지 기반 흐름 해설

1️⃣ 클라이언트 부팅 또는 Wi-Fi 연결

  • 클라이언트(스마트폰)는 네트워크에 처음 연결되며, IP 주소가 없는 상태이다.
  • 클라이언트는 자신의 MAC 주소만 알고 있으며, 네트워크의 다른 정보는 모른다.
  • 클라이언트는 L2 스위치를 통해 네트워크에 접속된다.

2️⃣ DHCP Discover 전송

  • 클라이언트는 DHCP 서버를 찾기 위해 브로드캐스트 패킷을 전송한다.
  • 이때 출발지 IP는 0.0.0.0, 목적지 IP는 255.255.255.255이다.
  • 포함되는 정보
    • 클라이언트 MAC 주소
    • 호스트 이름 (있을 경우)
    • 요청 옵션 (Gateway, DNS 등)

3️⃣ DHCP Offer 수신

  • DHCP 서버는 IP 풀(예: 192.168.0.10~100) 중 사용 중이지 않은 IP 주소를 선택하여 제안한다.
  • 동일한 MAC 주소가 예전에 사용한 IP가 있다면 해당 IP를 다시 제안할 수도 있다.
  • Offer 메시지에 포함하는 정보
    • 제안된 IP 주소
    • 서브넷 마스크
    • 게이트웨이 주소
    • DNS 서버 주소
    • 임대 시간 (예: 1시간)

4️⃣ DHCP Request 전송

  • 클라이언트는 DHCP Offer에서 받은 IP 주소를 "사용하겠다"고 명시하며 요청을 보낸다.
  • 이때도 클라이언트는 여전히 IP가 없기 때문에 브로드캐스트로 전송한다.
  • 요청 메시지에 포함하는 정보
    • 요청하는 IP 주소 (예: 192.168.0.10)
    • DHCP 서버의 식별자
    • 클라이언트 MAC 주소

5️⃣ DHCP ACK 수신

  • DHCP 서버는 해당 IP가 여전히 유효한지 확인한 후 클라이언트에게 ACK 메시지를 전송한다.
  • 이로써 클라이언트는 정식으로 IP 주소를 부여받고 네트워크 설정이 완료된다.
    • IP 주소: 192.168.0.10
    • 서브넷 마스크: 255.255.255.0
    • 게이트웨이: 192.168.0.1
    • DNS: 192.168.0.100
    • 임대 시간: 1시간

6️⃣ 네트워크 접속 완료

  • 클라이언트는 이제 네트워크에 정상적으로 연결된다.
  • 내부 DNS 서버를 통해 도메인 조회가 가능하다.
  • 내부 File Server 등과도 통신할 수 있다.
  • 게이트웨이를 통해 외부 인터넷에도 접속할 수 있다.

Q. DHCP 서버는 IP를 어떻게 정하는가?
A. IP 풀에서 사용되지 않은 IP를 선택하거나 MAC 주소 이력을 기준으로 동일 IP를 재할당한다.

Q. Request 단계에서 클라이언트는 무엇을 기준으로 요청하는가?
A. Offer 단계에서 받은 IP를 기준으로 “그 IP를 사용하겠다”고 명시적으로 요청한다.

Q. IP 없이 어떻게 통신이 가능한가?
A. 0.0.0.0 출발지, 255.255.255.255 목적지 브로드캐스트를 이용해 통신한다.

위의 네트워크 구성일 경우:

  • 모든 장비가 192.168.0.x 대역을 사용한다.
  • DHCP 서버는 게이트웨이 역할도 수행할 수 있다.

예시: DHCP 없는 네트워크는 주소 없는 마을에서 각자 벽에 자기 주소 적고 살아가는 것과 같고,
DHCP 있는 네트워크는 입주할 때마다 관리실에서 정확히 주소와 우편함 번호를 배정해주는 아파트 시스템과 같다.

네트워크 문제를 계층별로 진단하는 법

2계층 – 데이터링크 계층 (Data Link Layer)

역할: 같은 네트워크 내에서 MAC 주소 기반 통신
장비/요소:

  • Switch
  • MAC 주소
  • ARP
  • vLAN, STP

예시:

  • 같은 스위치에 연결된 PC들끼리는 잘 통신되지만, 다른 VLAN에 있는 장비와는 통신이 되지 않는 경우
  • 서로 다른 두 PC가 동일한 IP를 사용하고, 네트워크 연결이 불안정해지거나 접속이 끊어지는 경우 → MAC 주소 충돌이 발생했거나 IP가 중복 설정된 문제

3계층 – 네트워크 계층 (Network Layer)

역할: IP 주소를 통해 네트워크 간 라우팅
장비/요소:

  • Router, L3 Switch
  • IP 주소, 서브넷, 게이트웨이
  • 라우팅 프로토콜 (OSPF, BGP 등)
  • Switch

예시:

  • 회사 내부 공유폴더나 프린터는 잘 열리는데, 네이버 같은 웹사이트는 접속이 안 되는 경우 → 기본 게이트웨이 설정이 누락되었거나 잘못되어 외부로 나가는 경로가 없는 문제
  • 내부망에서 다른 사내 시스템은 접속되지만 외부 인터넷 사이트만 접속이 되지 않는 경우 → 기본 게이트웨이 설정은 되어 있지만 외부망으로 나가는 경로가 막혀 있는 문제
  • 다른 사무실에 있는 서버 IP를 알고 ping을 쳐봤지만 응답이 없는 경우 → 사무실마다 다른 IP 대역을 사용하고 있고 그 사이의 라우팅 경로가 없는 문제
  • ping 8.8.8.8 같은 외부 IP로도 테스트했는데 응답이 없는 경우 → 기본 게이트웨이 설정이 누락되었거나 외부망으로 나가는 트래픽이 방화벽에서 차단된 문제
  • 다른 부서에 있는 프린터나 NAS의 IP를 알아도 접속이 되지 않는 경우 → 다른 VLAN 또는 네트워크로 분리돼 있고 그 경로를 라우터가 모르기 때문에 통신이 안 되는 문제
  • 동일한 IP 주소를 가진 장비가 네트워크에 두 대 이상 잡혀서 연결이 불안정해지는 경우 → 고정 IP가 중복 설정되어 IP 충돌이 발생하는 문제
  • VPN 연결 후 회사 메일이나 ERP는 접속되지만 유튜브나 구글 접속이 안 되는 경우 → VPN이 인터넷 트래픽까지 터널링하고 있고, 사내망에서는 외부 인터넷이 차단된 문제
  • traceroute를 찍었더니 중간까지만 가고 이후엔 * * *만 계속 나오는 경우 → 중간 라우터가 다음 네트워크로 가는 경로를 모르거나, ICMP 패킷이 방화벽에서 차단된 문제

4계층 – 전송 계층 (Transport Layer)

역할: 포트를 기반으로 어플리케이션 간 데이터 전송, 신뢰성 보장
장비/요소:

  • TCP / UDP
  • 포트 번호 (예: 80, 443, 22)
  • NAT, 방화벽

예시:

  • 웹사이트는 정상적으로 열리는데, SSH 접속만 안 되는 경우 → 22번 포트가 방화벽에서 차단되어 있는 문제
  • 같은 내부 서버에 ping은 되지만 웹페이지가 뜨지 않는 경우 → TCP 80번(HTTP) 또는 443번(HTTPS) 포트가 오픈되지 않은 문제
  • 사내 메신저는 잘 되는데, 화상회의나 음성 통화는 작동하지 않는 경우 → UDP 포트가 차단되었거나, NAT 설정이 제대로 되어 있지 않은 문제
  • 특정 애플리케이션만 간헐적으로 접속이 끊기거나 반응 속도가 느린 경우 → MTU(MSS) 설정이 잘못되었거나, TCP 재전송이 반복되는 문제
  • 로드밸런서(L4) 뒤에 있는 서버로 간헐적으로 접속이 안 되는 경우 → 세션 유지 설정이 누락되었거나, L4 스위치에서 서버 연결 설정이 불안정한 문제
계층 주요 키워드 장비 예시 대표 문제 예시
2계층 MAC 주소, vLAN Switch VLAN 분리, ARP 오류, MAC 충돌
3계층 IP 주소, 라우팅 Router, L3 Switch 게이트웨이 오류, 라우팅 경로 없음
4계층 TCP/UDP, 포트 방화벽, NAT, L4 포트 차단, NAT 설정 오류

핵심:

  • 2계층: 같은 네트워크 안에서 통신이 되는가?
  • 3계층: 다른 네트워크와 통신할 수 있는가?
  • 4계층: 통신은 되는데 특정 서비스만 안 되는가?
LINUX MASTER : NETWORK

통신망

LAN < MAN < WAN

  • LAN : 하나의 건물이나 캠퍼스, 가까운 거리 내 컴퓨터와 정보기기를 연결하는 네트워크
    • 예시: Ethernet, Token Ring, FDDI
  • MAN : 동일 도시나 지역사회 내 여러 LAN을 연결하여 백본 라인을 형성하는 네트워크
    • 예시: DQDB
  • WAN : 국가, 대륙 등 광범위한 지역에 걸쳐 여러 LAN 또는 MAN을 연결하는 네트워크

LAN 토폴로지

  • 성형 : 중앙 집중식 형태
  • 망형 : 모든 노드 간 직접 연결
  • 버스형 : 모두 하나의 버스에 연결
  • 링형 : 양 옆 장치와만 연결해 원형 구성
  • 트리형 : 여러 스타 토폴로지가 계층적 버스에 연결

LAN 구성 장비

  • 케이블 : 데이터 신호를 전달하는 매체
  • 리피터 : 약해진 신호를 재생 및 증폭
  • 허브 : 수신 신호를 모든 포트로 전송
  • LAN 카드 : 컴퓨터를 네트워크에 연결하는 장치
  • 브릿지 : 두 LAN을 MAC 주소 기준으로 연결
  • 스위치 : MAC 주소 기반 목적지 포트로 데이터 전달 (스위칭 허브는 트래픽 분산)

인터네트워킹 장비

  • 라우터 : 서로 다른 네트워크를 연결하고 IP 기반 최적 경로 설정
  • 게이트웨이 : 서로 다른 프로토콜/구조를 변환하여 통신 가능하게 하는 장비

3-Way Handshaking

클라이언트와 서버가 신뢰성 있는 연결을 수립하기 위해 3단계 절차 수행

  • 패킷 교환 순서 : SYN → SYN+ACK → ACK
  • 상태
    • LISTEN : 서버가 연결 요청 대기
    • SYN_SENT : 클라이언트 연결 요청 전송
    • SYN_RECEIVED : 서버가 응답했지만 클라이언트 확인 대기
    • ESTABLISHED : 연결 완료 상태

IPv4

  • IP 주소 : 네트워크 주소 + 호스트 주소
  • 서브넷 마스크 : IP 주소의 네트워크/호스트 구분
  • 사설 IP 주소
    • A 클래스 : 10.0.0.0 ~ 10.255.255.255
    • B 클래스 : 172.16.0.0 ~ 172.31.255.255
    • C 클래스 : 192.168.0.0 ~ 192.168.255.255
  • 서브넷팅 : 하나의 네트워크를 더 작은 단위로 분할

DNS

사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환하거나 그 반대로 변환하는 계층적/분산형 네임 시스템

네트워크 인터페이스

  • lo : 루프백 인터페이스
  • eth : 이더넷 인터페이스

네트워크 설정 파일

  • /etc/sysconfig/network

    • 시스템 네트워크 기본 설정
    NETWORKING=yes
HOSTNAME=jjeong
GATEWAY=192.168.1.1
    • NETWORKING : 네트워크 사용 여부
    • HOSTNAME : 호스트 이름
    • GATEWAY : 기본 게이트웨이 주소
    • GATEWAY DEV : 게이트웨이 인터페이스 이름

  • /etc/sysconfig/network-scripts/ifcfg-ens@

    • 인터페이스별 네트워크 설정
    DEVICE=ens33
BOOTPROTO=static
BROADCAST=192.168.10.255
IPADDR=192.168.1.100
NETMASK=255.255.255.0
NETWORK=192.168.1.0
DNS1=8.8.8.8
ONBOOT=yes
    • DEVICE : 네트워크 장치명
    • BOOTPROTO : static / dhcp / none
    • BROADCAST : 브로드캐스트 주소
    • IPADDR : IP 주소
    • NETMASK : 서브넷 마스크
    • NETWORK : 네트워크 주소
    • ONBOOT : 부팅 시 활성화 여부
    • TYPE : 네트워크 환경 타입

  • /etc/resolv.conf

    • 기본 도메인명, 네임서버 설정

  • /etc/hosts

    • IP 주소와 도메인 이름을 매핑

네트워크 설정

IP 주소 설정

  • 이전 명령어 
    ifconfig eth0 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255 up
  • 최신 명령어 
    ip addr add 192.168.1.100/24 dev eth0
ip link set eth0 up
목적 이전 명령어 예시 최신 명령어 예시
IP 주소 설정 ifconfig eth0 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255 up ip addr add 192.168.1.100/24 dev eth0; ip link set eth0 up

라우팅 테이블 설정

  • 이전 명령어 
    route add -net 192.168.2.0 netmask 255.255.255.0 dev eth0
  • 최신 명령어 
    ip route add 192.168.2.0/24 dev eth0
목적 이전 명령어 예시 최신 명령어 예시
라우팅 테이블 설정 route add -net 192.168.2.0 netmask 255.255.255.0 dev eth0 ip route add 192.168.2.0/24 dev eth0

주요 네트워크 명령어

용도 이전 명령어 최신 권장 명령어 설명
인터페이스 정보 확인 ifconfig ip addr show 인터페이스 상태, IP, MAC 주소 등 확인
DNS 질의 nslookup dig 도메인 ↔ IP 주소 변환 질의
네트워크 경로 점검 ping ping 통신 가능 여부, 응답 속도 확인
경로 추적 traceroute traceroute 패킷 경유 경로 확인
연결 상태/포트 확인 netstat ss 포트, 소켓 연결 상태 확인
라우팅 테이블 확인/관리 route ip route show 라우팅 테이블 조회 및 수정

김동욱

Subnet vs VLAN

Subnet

정의

  • 네트워크를 논리적으로 분할한 단위로, 계층 3(네트워크 계층)에서 동작합니다.
  • 서브넷 마스크를 통해 IP 주소의 네트워크 ID와 호스트 ID를 구분합니다.

목적

  • 브로드캐스트 도메인 분리
    • 큰 네트워크를 작은 서브넷으로 나누어 불필요한 브로드캐스트 트래픽을 줄입니다.
  • 보안 및 관리 효율성
    • 다른 서브넷 간 통신은 라우터/방화벽을 거치게 해 접근 제어가 가능합니다.
  • IP 주소 효율적 할당
    • 필요한 호스트 수에 맞춰 서브넷 크기를 최적화합니다 (예: /24 → 254개 호스트, /30 → 2개 호스트).

예시

네트워크: 192.168.1.0/24
서브넷 A: 192.168.1.0/26 (호스트 62개)
서브넷 B: 192.168.1.64/26 (호스트 62개)

VLAN

정의

  • 하나의 물리적 스위치를 여러 논리적 네트워크로 분할하는 기술로, 계층 2(데이터 링크 계층)에서 동작합니다.
  • 태그 기반(VLAN ID, 예: IEEE 802.1Q)으로 트래픽을 구분합니다.

목적

  • 브로드캐스트 도메인 분리
    • 서브넷과 유사하지만 L2 스위치에서 구현되므로 라우터 없이도 통신 격리가 가능합니다.
  • 물리적 배치와 무관한 그룹화
    • 다른 층/건물에 있는 기기를 하나의 VLAN으로 묶어 관리할 수 있습니다 (예: 재무부서 VLAN, 개발부서 VLAN).
  • 보안 강화
    • VLAN 간 통신은 L3 장비(라우터)를 거치도록 강제해 접근 제어를 적용할 수 있습니다.

예시

VLAN 10: 영업부서 (포트 1-8)
VLAN 20: 개발부서 (포트 9-16)

Subnet과 VLAN의 기능이 중복되는데 둘 중 한가지만 써도 될까?

A. 한가지만 사용해도 네트워크 분리는 가능하지만 같이 사용할 경우 아래와 같은 장점이 있음

기능 서브넷만 사용 VLAN + 서브넷 사용
브로드캐스트 분리 서브넷 단위 (IP 기반) VLAN 단위 (스위치 레벨에서 완전 분리)
L2 보안 제어 불가능 가능 (포트 고정, MAC ACL 등)
포트 기반 정책 어렵거나 복잡 간단 (VLAN ID만 설정하면 끝)
유연한 구성 물리적 위치 중요 위치 무관, VLAN으로 논리적 묶기 가능
공격 격리 라우터에 의존 스위치 레벨에서 차단 가능
PC(호스트)에서 브라우저에 google.com을 입력하면 어떻게 될까? (네트워크 관점)

흐름도

[🖥️ 호스트 PC]

↓ (DNS 요청: www.google.com)

[🌐 로컬 DNS 리졸버] (8.8.8.8, 1.1.1.1 등)

↓ (재귀 요청 진행)

[🌎 루트 DNS 서버]

↓ (".com" TLD 서버 주소 반환)

[🗂️ TLD DNS 서버 (.com)]

↓ ("google.com" 권한 서버 주소 반환)

[🏢 구글 권한 DNS 서버]

↓ (www.google.com에 대한 최종 IP 주소 반환)

[🌐 로컬 DNS 리졸버]

↓ (호스트로 최종 IP 응답 전달)

[🖥️ 호스트 PC]

↓ (구글 서버로 실제 접속 시도)

각 노드(장비, 서버) 역할

노드 역할 설명
🖥️ 호스트 PC 사용자가 www.google.com 입력하는 기기. DNS 요청을 처음 발생시킴.
🌐 로컬 DNS 리졸버 PC가 설정한 DNS 서버 (예: 8.8.8.8). 호스트 대신 IP를 찾아오는 재귀 질의를 담당.
🌎 루트 DNS 서버 도메인 이름 최상위 레벨(TLD, 예: .com, .net 등)을 알려주는 글로벌 최상위 DNS 서버.
🗂️ TLD DNS 서버 (.com) .com 도메인 관련 정보를 관리하는 서버. 예: google.com, naver.com 등.
🏢 구글 권한 DNS 서버 google.com 도메인에 대한 최종 IP주소를 제공하는 구글 소유 DNS 서버.
🌐 로컬 DNS 리졸버 (응답) 최종 IP를 받아서 호스트 PC에 전달하고, 캐싱함(TTL 시간 동안 저장).

요약

  • 호스트는 IP주소를 알지 못해서, 로컬 DNS 리졸버에게 물어봄
  • 로컬 리졸버는 답을 직접 알지 못하면 "루트 → TLD → 권한 DNS" 순서로 점점 깊게 들어감
  • 권한 서버가 최종 답(IP주소)을 알려줌
  • 최종 IP주소를 받은 후, 호스트는 TCP 연결을 해서 실제 통신을 시작함
프록시 서버와 로드밸런서

프록시 서버란?

📌 프록시 서버(proxy server)

→ 사용자의 요청을 대신 전달해주는 중간 서버

쉽게 말하면, “내가 직접 가기 좀 그러니까, 너가 대신 가서 가져와줘” 하는 느낌

🔁 동작원리


[클라이언트] ─→ [프록시 서버] ─→ [실제 서버]
                            ↑
                  대신 요청하고 응답 전달

🔍 프록시 종류

종류 설명 예시
정방향 프록시 (Forward Proxy) 사용자가 외부로 나갈 때 중계 회사 내부에서 인터넷 접속 시
역방향 프록시 (Reverse Proxy) 외부 요청을 서버 앞에서 중계 웹 서버 앞단에서 요청 분산 (HAProxy, Nginx 등)

프록시 서버 vs 로드밸런

구분 프록시 서버 로드밸런서
역할 중간에서 요청을 중계 요청을 여러 서버로 분산
사용 목적 보안, 캐시, 익명성 트래픽 분산, 고가용성
특징 원래 목적은 보안과 필터링 대규모 트래픽 대응
예시 Squid, Nginx(프록시용) HAProxy, F5, AWS ELB
👉 Reverse Proxy = 프록시 + 로드밸런서 역할도 가능함

상황에 따른 프록시와 로드밸런서 활용

프록시만 필요한 상황

✅ 상황 1: 보안·제어 목적

  • 회사 내부에서 외부 인터넷 접속을 제한할 때
  • 로그, 감시, 필터링이 필요한 경우 (예: URL 차단, 사용자 모니터링 등)

📌 예:

사내 네트워크에서 외부 웹사이트로 나가는 모든 트래픽을 Squid 프록시 통해서 나가게 함.

✅ 상황 2: 캐싱 목적

  • 자주 요청되는 리소스(이미지, JS 등)를 프록시 서버에서 캐싱해서 응답속도 향상

📌 예:

CDN이랑 비슷한 개념. 정적 파일을 미리 저장해두고, 매번 원서버에 요청하지 않도록 함.

✅ 상황 3: 익명성 / 경유 목적

  • 사용자의 IP를 숨기거나,
  • 지역 우회(예: 특정 국가 접속 제한 우회) 용도

📌 예:

VPN, Tor, 프록시 브라우저 설정 등

로드밸런서가 필요한 상황

✅ 상황 1: 사용자 수가 많고 트래픽이 큰 경우

  • 단일 서버로는 감당 안 됨
  • 여러 대의 서버에 요청을 분산해야 함

📌 예:

쇼핑몰, 뉴스 포털, 게임 서버, OTT 서비스 등 수백~수천 명이 동시에 접속하는 서비스

✅ 상황 2: 무중단 서비스가 중요한 경우 (고가용성)

  • 하나의 서버가 죽어도 서비스는 계속 살아 있어야 함
  • 장애 조치(Failover), 헬스체크 필수

📌 예:

금융 서비스, 병원 시스템, 온라인 강의 플랫폼 등

✅ 상황 3: 버전 테스트, 조건 분기, 세션 고정 등 필요

  • A/B 테스트
  • 브라우저별 서버 분기 (앞에서 했던 HAProxy ACL 예시)
  • 세션 유지 (Sticky session)

📌 예:

일부 유저는 신버전 웹으로, 일부는 기존 버전으로 보내는 실험

요약

상황 추천 방식
사내에서 인터넷 나갈 때 제어하고 싶다 프록시 서버 (Squid 등)
서버는 하나인데 캐싱만 하고 싶다 프록시 서버 (정적 캐싱)
트래픽이 많고 서버 여러 대 필요하다 로드밸서 (HAProxy 등)
장애가 나도 무중단으로 서비스하려면 로드밸서 + 헬스체크
브라우저에 따라 다른 응답을 주고 싶다 로드밸서의 ACL 기능
둘 다 필요하다 HAProxy, Nginx (reverse proxy + lb) 사용
라우터란? (feat. VM으로 라우터 만들기)

라우터란?

라우터(router) 는

네트워크와 네트워크를 연결해주는 장비

즉 이 네트워크에서 저 네트워크로 데이터가 가야 하는데, 어디로 보내야 할지 결정해주는 장비

라우터의 동작 흐름

  1. 패킷(데이터)이 라우터에 도착
  2. 패킷 안의 목적지 IP 주소를 읽음
  3. 라우팅 테이블을 확인함
  4. 최적 경로(다음 목적지)를 찾아서 패킷을 보냄

라우터 기능

기능 설명
네트워크 연결 서로 다른 네트워크(예: 집 인터넷과 인터넷 망)를 이어줌
길찾기 (Routing) 패킷을 목적지까지 최적의 경로로 보내줌
NAT(Network Address Translation) 집안 내부 사설 IP(192.168.x.x)를 공인 IP로 변환해줌 (※ 가정용 라우터 특징)
DHCP 서버 기능 (옵션) 내부 기기들한테 IP주소를 자동으로 배분해줌
방화벽 기능 (옵션) 외부 공격을 막거나, 특정 트래픽을 차단할 수 있음

동작 예시

📍 집 인터넷 구조

(집 내부)
[PC/노트북/스마트폰]
    ↔
[Wi-Fi 공유기 = 가정용 라우터]
    ↔
[인터넷 통신사(ISP)]
    ↔
[인터넷 세상 전체]
  • 집안 기기들은 192.168.x.x 같은 사설 IP를 쓰고,
  • 라우터(공유기) 가 NAT 기능으로 내부 사설 IP ↔ 외부 공인 IP 변환
  • 그리고 외부 인터넷과 통신할 때 라우터가 경로를 찾아서 보내주는 거야.

"라우터"랑 "스위치" 차이

항목 라우터 (Router) 스위치 (Switch)
기본 역할 네트워크와 네트워크를 연결해줌 (예: 집 → 인터넷) 하나의 네트워크 내부에서 여러 기기를 연결해줌 (예: 집안 PC들끼리)
작동 계층 OSI 3계층 (네트워크 계층, IP 기반) OSI 2계층 (데이터링크 계층, MAC 주소 기반)
주소 기준 IP 주소를 보고 경로 결정 MAC 주소를 보고 데이터 전송
라우팅 기능 있음 (최적 경로 찾음) 없음 (단순 연결)
NAT 지원 있음 (주로 라우터) 없음 (스위치는 NAT 안 함)
사용 예시 집에서 인터넷에 나갈 때, 회사 지사 연결할 때 사무실에서 컴퓨터/프린터/서버 연결할 때

정리:

  • 라우터 = "다른 네트워크로 나가는 길 안내"
  • 스위치 = "내부 기기들끼리 연결해주기"

라우터 안에도 CPU랑 메모리 들어가 있을까?

그렇다, 라우터 안에는 사실상 미니 컴퓨터가 들어있는 셈

부품 설명
CPU 패킷 읽고, 경로 계산하고, NAT 처리 등 복잡한 작업 수행
RAM (메모리) 현재 처리 중인 데이터/라우팅 테이블/캐시 임시 저장
Flash 메모리 운영체제(OS) 파일이나 설정파일 저장
전용 칩셋 (ASIC) 고성능 라우터는 패킷 처리 속도 빠르게 하려고 별도 칩셋도 넣음

특히 고성능 라우터(기업/ISP용)는

➔ 진짜 서버처럼 엄청 강력한 CPU와 메모리를 갖고 있어. 🚀

라우터도 운영체제(OS) 있어?

존재함, 라우터 OS란?

하드웨어를 관리하고, 패킷 처리, 라우팅 프로토콜(예: OSPF, BGP) 관리하는 소프트웨어.

VM으로 가상라우터 만들기 (VMware 사용 가정)

  • 랜카드를 두개로 구성하여 하나는 외부 네트워크 연결용, 다른 하나는 내부 내크워크 연결용으로 사용한다.
  • firewall-cmd --permanent --zone=external --change-interface=ens160 -> 가상 랜카드 'ens160'을 외부연결용으로 설정
  • firewall-cmd --permanent --zone=internal --change-interface=ens224 -> 가상 랜카드 'ens224'을 외부연결용으로 설정

** dhcp 기능을 추가하여 dhcp 서버의 기능도 하는 라우터를 구성할 수도 있다

마운트(Mount)란?

마운트(Mount) 기능이란?

리눅스의 기능(명령어)로서 "마운트(Mount)"는 파일 시스템을 디렉토리 트리 구조에 연결하여 사용할 수 있도록 해주는 기능입니다. 이는 특정 장치나 파일 시스템을 하나의 디렉토리에 연결(mount)하여 운영체제가 해당 데이터를 인식하고 사용할 수 있도록 하는 과정입니다.

마운트는 기능일까, 애플리케이션일까?

마운트는 리눅스 커널에 포함된 기본 기능이며, mount라는 이름의 명령어를 통해 조작할 수 있습니다. 별도의 애플리케이션이 아니라 리눅스의 파일 시스템 구조에서 필수적으로 사용되는 내장된 기능입니다.

마운트의 필요성과 배경

리눅스와 유닉스 계열 운영체제는 하나의 통합된 트리 구조로 된 파일 시스템을 사용합니다. 즉, 외부 저장소(예: USB, 하드디스크, 네트워크 공유 폴더 등)를 사용하려면 이 트리 구조의 특정 지점에 연결해주어야만 합니다.

반면, 윈도우는 C:, D:와 같은 드라이브 문자로 디스크를 구분하지만, 리눅스는 이처럼 명시적인 구분 없이, 마운트를 통해 파일 시스템 트리에 통합합니다.

자주 사용되는 마운트 사례

  • USB 장치 연결: USB를 연결하면 /media/사용자명/디스크이름과 같은 경로로 자동 마운트됩니다.
  • 추가 하드디스크 마운트: NAS 환경 등에서 다수의 디스크를 수동 또는 자동 마운트하여 사용합니다.
DB 마스터-슬레이브 구조

마스터-슬레이브(Master-Slave) 구조

마스터-슬레이브 구조는 데이터베이스 복제(replication) 방식 중 하나로,
하나의 마스터 DB가 쓰기 작업을 처리하고,
여러 슬레이브 DB가 읽기 작업을 처리하도록 구성된 구조입니다.

주요 특징

  • 마스터 DB

    • 모든 쓰기 요청(INSERT, UPDATE, DELETE)을 처리
    • 데이터의 원본 역할
    • 변경 사항을 슬레이브 DB로 복제

  • 슬레이브 DB

    • 마스터 DB로부터 데이터를 복제
    • 읽기 전용(SELECT)으로 동작
    • 여러 개의 슬레이브로 읽기 부하 분산 가능

복제 방식

  • 비동기 복제 (Asynchronous Replication)

    • 마스터가 쓰기 작업을 완료한 후 슬레이브로 데이터 전파
    • 성능은 우수하지만 복제 지연(replication lag) 발생 가능

  • 동기 복제 (Synchronous Replication)

    • 슬레이브가 데이터를 반영해야 마스터가 쓰기 작업 완료
    • 데이터 일관성은 높지만 성능 저하 가능

사용 용도

  • 읽기 요청이 쓰기 요청보다 많은 시스템에서 사용
  • 예: 웹 서비스, 콘텐츠 제공 플랫폼 등
  • 읽기 부하를 분산시키기 위함

장점

  • 읽기 성능 향상: 슬레이브 DB를 통해 읽기 요청 분산
  • 확장성: 슬레이브 DB를 추가하여 수평 확장 가능
  • 데이터 백업 용도: 슬레이브 DB를 백업에 활용 가능

단점

  • 복제 지연: 비동기 복제 시 데이터 불일치 발생 가능
  • 단일 장애점(SPOF): 마스터 DB 장애 시 전체 시스템 영향
  • 복잡한 관리: 복제 설정, 장애 감지, 모니터링 필요

마스터 DB 장애 시 슬레이브 승격

마스터 DB가 장애를 일으키면, 슬레이브 DB를 마스터로 승격(promotion) 하여 시스템을 유지할 수 있습니다.
이를 장애 복구(failover) 라고 합니다.

장애 복구 절차

  1. 슬레이브 승격

    • 슬레이브 DB 중 하나를 마스터로 지정
    • 쓰기 작업이 가능하도록 설정 변경

  2. 복제 재구성

    • 다른 슬레이브들이 새로운 마스터를 따라 복제

  3. 애플리케이션 연결 갱신

    • 새로운 마스터로 쓰기 요청을 보내도록 연결 정보 수정

고려 사항

  • 자동화 필요

    • 수동 처리 시 복구 지연 발생
    • HA(High Availability) 솔루션 활용 권장
      예: MySQL MHA, PostgreSQL Patroni

  • 데이터 일관성 보장

    • 비동기 복제 환경에서는 슬레이브가 최신 상태가 아닐 수 있음
    • 승격 시 데이터 손실 위험 존재

  • 복구 이후 처리

    • 장애 발생 전 마스터가 복구되면 다시 슬레이브로 구성하거나 재승격 필요
    • 다운타임 및 운영 이슈 발생 가능

  • 동기 복제 활용 고려

    • 데이터 손실 방지를 위해 유리
    • 단, 시스템 성능 저하 가능

문제점과 해결책

문제: 마스터 DB가 단일 장애점(SPOF)이 되는 구조

해결 방안

  • 다중 마스터 구조(Multi-Master Replication)

    • 여러 마스터를 운영하여 쓰기 작업 분산
    • 하나의 마스터 장애 시 다른 마스터가 처리 가능

  • 클라우드 기반 솔루션 사용

    • 예: AWS RDS, Google Cloud SQL
    • 자동 장애 복구, 백업, 고가용성 기능 제공
    • SPOF 문제 완화 가능
DB 클러스터 구조

클러스터 구조란?

클러스터 구조는 여러 데이터베이스 노드가 하나의 논리적 데이터베이스로 동작하도록 구성된 시스템입니다.
노드들은 데이터를 공유하거나 복제하며, **고가용성(HA)**과 확장성을 제공합니다.

주요 특징

  • 노드 간 협력: 여러 노드(서버)가 데이터를 공유하거나 복제하며 하나의 시스템처럼 동작
  • 고가용성: 특정 노드 장애 시 다른 노드가 서비스를 이어 받아 중단 최소화
  • 확장성: 읽기/쓰기 부하를 여러 노드에 분산해 성능 향상

복제 방식

  • 공유 디스크 클러스터

    • 모든 노드가 단일 저장소(디스크)를 공유
    • 예: Oracle RAC

  • 복제 기반 클러스터

    • 각 노드가 독립된 데이터 사본을 가지며 복제로 동기화
    • 예: MySQL Galera, PostgreSQL 클러스터

동시성과 일관성 문제

문제 발생 상황

  • 비동기 복제
    • 마스터 노드에 쓰기 후, 슬레이브 노드로 데이터 전파에 시간 지연 발생
    • 이 사이에 슬레이브에서 읽기 요청 처리 시 오래된 데이터(stale read) 반환 가능

예시

사용자 A가 계정 정보를 업데이트한 직후 조회하면,
슬레이브가 아직 데이터를 반영하지 않아 이전 정보가 조회될 수 있음

해결책

  • 동기 복제

    • 모든 노드에 쓰기 반영 완료 후 응답
    • 데이터 일관성 보장, 하지만 쓰기 지연 증가

  • 읽기 일관성 정책

    • 강한 일관성: 항상 최신 데이터 제공 (예: 마스터 노드에서만 읽기)
    • 결정적 일관성: 시간이 지나면 모든 노드가 일관된 데이터 유지
    • 세션 일관성: 동일 세션 내에서는 항상 최신 데이터 제공
    • 쿼럼 기반 읽기/쓰기: 일정 수 이상의 노드에서 응답을 받아 일관성 확보 (예: Cassandra)
    • 스마트 라우팅: 쓰기 직후에는 마스터 노드로 읽기 라우팅

클러스터 구조가 선택되는 이유

  • 고가용성: 단일 노드 장애에도 서비스 지속 가능
  • 확장성: 대규모 트래픽 처리 가능
  • 지리적 분산: 글로벌 사용자에게 낮은 지연 시간 제공
  • 비즈니스 유연성: 약간의 데이터 불일치는 허용되며 성능을 우선시하는 서비스에서 유용

대규모 서비스에서의 DB 구조와 극복 방안

구조 예시

  • 샤딩(Sharding) + 복제

    • 데이터를 샤드(파티션)로 나누고, 각 샤드에 마스터-슬레이브 구조 적용
    • 예: Instagram은 PostgreSQL을 샤딩해 사용자 데이터를 분산 저장

  • 멀티-마스터 클러스터

    • 모든 노드가 쓰기/읽기 가능
    • 예: Google Spanner (분산 트랜잭션 및 동기 복제 지원)

  • NoSQL 데이터베이스

    • MongoDB, Cassandra, DynamoDB 등 클러스터 구조에 최적화
    • 예: Netflix는 Cassandra를 사용해 글로벌 사용자 데이터 분산 저장

  • 캐싱 레이어

    • Redis, Memcached 등을 사용해 데이터베이스 부하 감소
    • 예: Twitter는 Redis로 타임라인 데이터를 캐싱

  • CQRS + 이벤트 소싱

    • 읽기/쓰기 DB를 분리하여 각각 최적화
    • 이벤트 소싱으로 변경 이력을 저장하고 읽기 전용 뷰 생성
    • 예: Uber는 이벤트 기반 아키텍처 사용

문제 극복 방안

  • 자동 장애 복구

    • Kubernetes, ZooKeeper 등을 이용한 자동 복구 구조 구현

  • 지리적 분산

    • 다중 리전 DB 클러스터 + CDN으로 글로벌 지연 최소화
    • 예: AWS Aurora Global Database

  • 모니터링 및 최적화

    • Prometheus, Grafana 등을 통해 실시간 성능 모니터링
    • 쿼리 최적화 및 인덱싱으로 성능 개선

  • 하이브리드 접근

    • 관계형 DB + NoSQL DB 병행 사용으로 워크로드 맞춤 처리

  • 비동기 처리

    • Kafka, RabbitMQ 등의 메시지 큐 사용으로 쓰기 작업을 비동기 처리

대표적인 클러스터 구현 예시

  • MySQL Galera Cluster

    • 동기 복제 기반, 모든 노드가 쓰기/읽기 가능

  • PostgreSQL + Patroni

    • 리더(마스터)와 팔로워(슬레이브)로 구성, 동기/비동기 복제 지원

  • MongoDB Replica Set

    • 프라이머리(마스터)와 세컨더리(슬레이브) 구성, 자동 승격 지원

  • Cassandra

    • 모든 노드가 동등한 피어(peer)로 동작, 분산 저장

장점

  • 고가용성: 노드 장애 시 다른 노드가 자동으로 서비스 유지
  • 확장성: 노드 추가로 수평 확장 가능
  • 데이터 일관성: 동기 복제로 최신 데이터 유지 가능

단점

  • 구성 복잡성: 설정, 관리, 모니터링이 복잡함
  • 성능 오버헤드: 동기 복제로 인한 쓰기 지연
  • 비용 증가: 다수 노드 운영으로 하드웨어 및 클라우드 비용 상승
Stateful Firewall (스테테이트풀 방화벽)

스테이트풀 (Stateful) 방화벽

스테이트풀 방화벽은 네트워크 연결의 상태를 추적하여 트래픽을 필터링하는 방화벽입니다. 이전에 설정된 연결의 컨텍스트를 기반으로 트래픽을 검사하며, 단순히 패킷 헤더 정보만 확인하는 스테이트리스 (Stateless) 방화벽과 달리 연결의 시작부터 종료까지 상태를 기억하고 관리합니다.

작동 원리

  1. 연결 추적 (Connection Tracking):

    • 새로운 연결이 시작되면 관련 정보를 상태 테이블 (Connection Table) 에 기록합니다.
    • 기록 정보: 출발지/목적지 IP 주소, 포트 번호, 프로토콜, 연결 상태 등

  2. 패킷 검사 (Packet Inspection):

    • 방화벽을 통과하는 패킷이 상태 테이블에 기록된 활성 연결의 일부인지 확인합니다.

  3. 정책 적용 (Policy Enforcement):

    • 새로운 연결:
      • TCP SYN 패킷과 같은 새로운 연결 시작 패킷은 설정된 보안 정책 (규칙)에 따라 허용 또는 차단됩니다.
      • 허용된 연결 정보는 상태 테이블에 기록됩니다.
    • 기존 연결:
      • 상태 테이블에 기록된 활성 연결의 일부인 패킷은 해당 연결 시작 시 적용된 정책을 기반으로 자동으로 허용됩니다.
      • 여기에는 해당 연결에 대한 응답 트래픽도 포함됩니다.
    • 유효하지 않은 패킷:
      • 상태 테이블에 없는 연결에 속하거나 연결 상태와 맞지 않는 패킷은 차단될 수 있습니다.

주요 특징 및 장점

  • 향상된 보안성: 연결 상태 기반 필터링으로 비정상적인 연결 시도 및 위장된 패킷 탐지/차단에 효과적입니다. (예: 내부 시작 연결 응답만 허용, 외부 무작위 패킷 차단)
  • 동적 규칙 적용: 새로운 연결 허용 시 응답 트래픽을 위한 별도 규칙 불필요 (방화벽이 연결 상태 기억 후 자동 허용).
  • DoS/DDoS 공격 방어에 유리: 비정상적인 연결 시도 추적 및 제한을 통해 서비스 거부 공격 완화에 도움을 됨.
  • 로그 기록 및 감사 용이: 연결 상태 정보 기록을 통한 네트워크 활동 추적 및 보안 감사 용이.

주요 단점

  • 성능 저하 가능성: 연결 상태 추적 및 관리를 위한 추가 처리 부하 발생 (최신 기술로 성능 저하 최소화).
  • 복잡성: 스테이트리스 방화벽 대비 설정 및 관리 복잡성 증가.

스테이트리스 방화벽과의 비교

특징 스테이트풀 방화벽 (Stateful Firewall) 스테이트리스 방화벽 (Stateless Firewall)
연결 상태 추적 O X
필터링 기준 연결 상태, IP, 포트, 프로토콜 등 IP, 포트, 프로토콜 등 (각 패킷 독립적)
보안성 높음 낮음
규칙 설정 연결 시작 시 규칙 적용, 응답 자동 허용 양방향 통신 위해 각각 규칙 설정 필요
성능 약간 낮을 수 있음 일반적으로 높음
복잡성 높음 낮음
DoS/DDoS 방어 유리 불리

AWS 적용 사례

보안 그룹 설정

  • 아웃바운드 규칙 (0.0.0.0/0):

    • 프로토콜: 모든 프로토콜
    • 포트: 모든 포트
    • 대상: 0.0.0.0/0 (모든 IP 주소)
    • 의미: 인스턴스에서 나가는 모든 종류의 요청을 모든 IP 주소로 허용합니다.

  • 통신 흐름:

    • 인스턴스에서 보내는 요청: 아웃바운드 규칙이 0.0.0.0/0으로 설정되어 있어 인스턴스는 어떤 IP 주소의 어떤 서비스로든 요청을 보낼 수 있습니다.
    • 응답 트래픽: 스테이트풀 방화벽인 보안 그룹의 특성 덕분에, 인스턴스가 외부로 보낸 요청에 대한 응답 트래픽은 별도의 인바운드 규칙 없이 자동으로 허용됩니다. 이는 보안 그룹이 연결 상태를 기억하기 때문입니다.
ALB vs NLB 요약 정리

✅ ALB vs NLB 요약 정리

🌐 ALB (Application Load Balancer)

  • 계층: L7 (Application Layer)
  • 프로토콜: HTTP, HTTPS, gRPC
  • 기능:
    • 경로/호스트/헤더 기반 라우팅
    • SSL/TLS 종료
    • WebSocket, HTTP/2 지원
    • Sticky Session (고정 세션)
    • 애플리케이션 수준 Health Check
  • 사용 예: 마이크로서비스, 경로별 API 서버, WebSocket 기반 실시간 앱

🌐 NLB (Network Load Balancer)

  • 계층: L4 (Transport Layer)
  • 프로토콜: TCP, UDP, TLS
  • 기능:
    • 고정 IP 제공 (Elastic IP)
    • 소스 IP 보존
    • TLS 종료 또는 패스스루
    • 초고속, 초저지연 성능
    • 네트워크 수준 Health Check
  • 사용 예: 게임 서버, IoT, 실시간 트래픽 처리 시스템

🔍 주요 차이점 비교표

항목 ALB NLB
계층L7 (Application)L4 (Transport)
프로토콜HTTP, HTTPS, gRPCTCP, UDP, TLS
라우팅 기준URL, Host, 헤더, 쿼리IP, 포트
고정 IP불가가능 (Elastic IP)
소스 IP 보존불완전 (X-Forwarded-For)완전 지원
TLS 종료지원선택 사항
세션 유지가능 (Sticky Session)불가
성능낮음 (기능 많음)매우 높음 (수백만 RPS)
사용 목적정밀 HTTP 라우팅초고속 네트워크 트래픽

💡 선택 가이드

상황추천 로드밸런서
경로/도메인 기반 라우팅 필요✅ ALB
WebSocket, HTTP/2 필요✅ ALB
SSL 인증서 중앙 관리✅ ALB
고정 IP 주소 필요✅ NLB
낮은 지연, 높은 성능 필요✅ NLB
게임 서버, TCP 서비스 운영✅ NLB

📌 실사용 시나리오 비교

항목ALBNLB
/api, /user URL 구분OX
TCP 포트 3306 접속 전달XO
HTTPS 요청 처리OO (선택)
고정 IP를 통한 접근XO
마이크로서비스 API 라우팅OX
대규모 TCP 기반 채팅 서버XO
암호화 방식 & SSL/TLS 정리

대칭키 방식 (Symmetric Key Encryption)

  • 동일한 키로 암호화 및 복호화를 수행

  • 통신 흐름

    1. 클라이언트가 서버에 요청
    2. 서버는 대칭키를 클라이언트에 전달
    3. 이후 클라이언트는 이 키로 요청을 암호화해 서버에 전달
    4. 서버도 동일한 키로 복호화/응답

  • 장점

    • 구현이 간단하고 빠름

  • 단점

    • 키 전달이 안전하지 않으면 중간자 공격에 취약
    • **안전한 키 교환 방식(DH 등)**과 결합 필요

비대칭키 방식 (Asymmetric Key Encryption)

  • 공개키(Public Key)로 암호화, 개인키(Private Key)로 복호화

  • 서버는 개인키 보유, 클라이언트는 서버의 공개키 이용

  • 클라이언트가 요청을 공개키로 암호화하면, 서버만 복호화 가능

  • 장점

    • 키가 노출되지 않고 안전함

  • 단점

    • 연산 비용이 높고 느림

SSL / TLS 암호화 통신

  • HTTPS에서 사용되는 보안 통신 프로토콜
  • 실제 데이터 전송에는 대칭키 사용
  • 대칭키는 안전한 방식으로 **키 교환(협상)**하여 공유됨

TLS 핸드셰이크 흐름

  1. ClientHello: 클라이언트가 암호화 알고리즘 목록과 랜덤값 전송
  2. ServerHello: 서버는 선택한 암호화 방식, 인증서(공개키 포함), 랜덤값 전송
  3. 인증서 검증: 클라이언트가 인증서의 유효성을 CA를 통해 확인
  4. 세션키 협상: Diffie-Hellman(ECDHE 등)을 사용해 대칭키 생성
  5. 암호화 시작: 양측 모두 동일한 대칭키를 공유한 뒤, 데이터 암호화 통신 시작

왜 TLS는 이렇게 동작할까?

  • 성능 문제: 비대칭키 방식은 연산이 복잡하여 대용량 데이터에 부적합
  • 보안 문제: 대칭키는 빠르지만 키 전달이 안전해야 함
  • TLS는 비대칭키로 안전하게 대칭키를 교환한 후, 대칭키로 본격적인 통신을 진행하여 성능과 보안을 동시에 확보

TLS 1.2 vs 1.3 간단 비교

항목 TLS 1.2 TLS 1.3
키 교환 방식 RSA, DH, ECDHE 혼용 ECDHE 전용 (Perfect Forward Secrecy)
핸드셰이크 단계 상대적으로 복잡 단순화 및 0-RTT 지원
암호 알고리즘 다양한 알고리즘 지원 안전한 알고리즘만 사용

정리

  • 대칭키: 빠르지만 키 유출 위험 → 주 통신용으로 사용
  • 비대칭키: 안전하지만 느림 → 키 교환용으로 사용
  • TLS: 두 방식의 장점을 조합해 안전하고 빠른 통신을 구현

임용진

네트워크 - 라우팅 프로토콜 vs 라우티드 프로토콜

라우팅 프로토콜 (Routing Protocol)

  • 라우터 간에 경로 정보를 교환하여 최적의 경로를 동적으로 결정하는 프로토콜
  • 라우팅 테이블을 자동으로 생성/갱신
  • 네트워크 구조 변화에 자동 대응

분류 방식

방식 설명 대표 프로토콜
거리 벡터 거리(홉 수) + 방향 RIP, IGRP
링크 상태 전체 구조 파악 후 최적 경로 계산 OSPF, IS-IS
경로 벡터 경로 벡터 정보(AS 정보 등) 기반 BGP

라우티드 프로토콜 (Routed Protocol)

  • 실제 데이터를 목적지로 전달하는 프로토콜
  • 라우팅 프로토콜이 만든 경로를 따라 사용자 데이터(IP 패킷 등)가 전달
  • 라우터가 처리할 수 있는 트래픽의 종류를 의미하기도 한다.

대표 프로토콜

  • IPv4, IPv6
  • AppleTalk (구버전)
  • IPX (Novell NetWare에서 사용)

라우팅 vs 라우티드 프로토콜 차이

구분 라우팅 프로토콜 라우티드 프로토콜
역할 최적 경로를 결정 데이터를 전달
작동 주체 라우터 간 정보 교환 라우터가 패킷 전달
데이터 처리 라우팅 정보만 처리 사용자 데이터 처리
예시 RIP, OSPF, EIGRP, BGP IPv4, IPv6, IPX, AppleTalk

정리

  • 라우팅 프로토콜: 길 찾는 앱 (예: 구글 지도)
  • 라우티드 프로토콜: 실제로 달리는 자동차 (예: 택시)
마스터-슬레이브 구조란?

클라우드 인프라와 시스템 아키텍처를 다루는 엔지니어에게 있어, 마스터-슬레이브 구조는 고성능·고가용성 시스템을 설계하는 데 핵심 개념 중 하나 주로 데이터베이스, 메시지 큐, 파일 시스템, 캐시 시스템 등 다양한 영역에서 활용

개요

마스터-슬레이브(Master-Slave) 구조는 중앙 제어 노드(Master)와 하위 종속 노드(Slave) 간의 명확한 역할 분담을 통해 시스템의 확장성과 신뢰성을 확보하는 방식

역할 기능 설명
마스터 노드 주요 연산(쓰기/제어)을 수행하고 슬레이브로 데이터 또는 명령을 전파
슬레이브 노드 마스터의 상태를 복제하거나 명령을 수신하여 일부 기능을 수행 (주로 읽기 연산)

핵심 포인트

1. 부하 분산 (Load Balancing)

  • 읽기/쓰기 트래픽을 분리하여 병목 현상 완화
  • 슬레이브 노드를 수평 확장(horizontal scaling)하여 읽기 성능 극대화
  • 클라우드 환경에서는 Auto Scaling Group과 연계하여 슬레이브 확장 자동화 가능

2. 고가용성 (High Availability)

  • 마스터 장애 시 슬레이브를 프로모션(Promotion) 하여 서비스 지속 가능
  • 클라우드에서는 RDS Read Replica → Multi-AZ Failover, 또는 Heartbeat + VIP 구성으로 장애 대응

3. 데이터 복제 및 일관성 (Replication & Consistency)

  • 비동기 복제: 성능 우위, 데이터 지연 발생 가능
  • 동기 복제: 일관성 보장, 성능 부담
  • 실시간 모니터링 및 replication lag 체크는 필수
  • 예: SHOW SLAVE STATUS (MySQL 기준)

4. 운영 및 유지보수 용이성

  • 슬레이브 노드를 활용해 백업 시 서비스 영향 최소화
  • 슬레이브에 대해 보고서/분석 쿼리 분리 가능
  • 무중단 배포(Rolling Update) 전략과 결합 시 유용

클라우드 환경에서의 적용 예시

클라우드 서비스 이름 특성
AWS RDS Read Replica / Aurora Replicas 자동 복제, 장애 전환 지원
GCP Cloud SQL Read Replica SLA 기반 고가용성
Azure SQL Database Geo-Replication 지리적 이중화, DR 대응

실제 서비스에서는 리더-팔로워(Leader-Follower) 또는 Primary-Replica 용어도 혼용되어 사용

TTL이란?

TTL (Time To Live)

**TTL(Time To Live)**은 IP 헤더에 포함된 필드로, 네트워크에서 데이터 패킷이 얼마나 오래 살아있을 수 있는지를 지정합니다. TTL은 패킷이 라우터를 지날 때마다 1씩 감소하며, 0이 되면 삭제되어 더 이상 전달되지 않습니다.

TTL의 주요 역할

  1. 무한 루프 방지
    • 잘못된 라우팅 설정으로 패킷이 무한히 순환하는 것을 방지
    • TTL이 0에 도달하면 패킷은 삭제되고, 송신자는 ICMP Time Exceeded 메시지를 받음
    • 이를 통해 라우팅 오류나 순환 문제를 진단 가능

TTL 값의 설정

  • TTL 값 범위: 0 ~ 255
  • 운영 체제 또는 장비에 따라 초기 TTL 값은 다름 (예: 64, 128, 255)
  • 예시:
    • TTL = 64: 최대 64개의 라우터 통과 가능
    • TTL = 128: 최대 128개의 라우터 통과 가능

TTL 활용 예시

1. Ping

  • 네트워크 연결 상태 점검
  • 응답 패킷의 TTL 값을 통해 네트워크 거리, 지연 등을 확인 가능

2. Traceroute

  • TTL 값을 점차 증가시키며 라우터마다 ICMP Time Exceeded 메시지를 수신
  • 네트워크 경로 추적에 사용됨

TTL 필드 작동 원리

  1. 초기 TTL 설정: 출발지에서 패킷에 TTL 설정
  2. 라우터 통과 시 TTL 감소: 라우터 한 개 지날 때마다 TTL -1
  3. TTL = 0 도달 시:
    • 패킷 삭제
    • 송신자에게 ICMP Time Exceeded 메시지 전송

TTL 값 예시

TTL 값 설명
64 최대 64개 라우터 통과 가능
128 최대 128개 라우터 통과 가능

TTL과 네트워크 문제 해결

  • ping, traceroute 도구를 활용하여 TTL 기반 네트워크 진단 가능
  • 경로 추적, 지연 구간 확인, 라우팅 오류 점검 등에 활용됨

요약

  • TTL은 패킷의 생존 시간을 설정하는 IP 헤더 필드
  • TTL은 라우터 통과 시 1씩 감소, 0이 되면 패킷은 삭제
  • TTL은 무한 루프 방지, 네트워크 경로 추적, 오류 진단에 유용
TCP 3-Way Handshake와 HTTP 통신 흐름

웹에서 데이터를 주고받을 때는 먼저 클라이언트(브라우저)와 서버 간의 TCP 연결이 선행되고, 그 위에서 HTTP 요청/응답이 이루어집니다.

1️⃣ TCP 연결 수립 - 3-Way Handshake

클라이언트가 서버와 통신을 시작하기 위해 먼저 TCP 연결을 요청합니다. 이 연결은 세 번의 패킷 교환을 통해 이루어지며, 이를 3-Way Handshake라고 부릅니다.

  1. 클라이언트 → 서버: SYN
  • 클라이언트가 연결 요청을 보냅니다.
  • 이 요청에는 SYN 플래그와 클라이언트의 초기 시퀀스 번호(Seq = x)가 포함됩니다. SYN, Seq = x
  1. 서버 → 클라이언트: SYN + ACK
  • 서버는 클라이언트의 요청을 수락하고, 자신의 초기 시퀀스 번호(Seq = y)와 함께 응답합니다.
  • 동시에 클라이언트의 시퀀스 번호에 대한 응답(ACK = x + 1)도 포함합니다. SYN, Seq = y, ACK = x+1
  1. 클라이언트 → 서버: ACK
  • 클라이언트는 서버의 응답을 확인하고 마지막으로 ACK 패킷을 보냅니다.
  • 이 패킷은 ACK = y + 1을 포함합니다. ACK, Seq = x+1, ACK = y+1

이 세 단계를 마치면 TCP 연결이 성립되며, 양방향 통신이 가능한 상태가 됩니다.

2️⃣ HTTP 요청 - 클라이언트가 서버에 요청 보내기

TCP 연결이 성립되면, 클라이언트는 그 위에서 HTTP 요청을 보냅니다.
예를 들어, 사용자가 브라우저에 https://example.com을 입력하면 다음과 같은 HTTP 요청이 발생합니다

GET / HTTP/1.1 Host: example.com

HTTP 요청은 다음 정보를 포함합니다:

  • HTTP 메서드: 요청의 목적 (GET, POST, 등)
  • URL: 요청 대상 리소스
  • HTTP 헤더: 부가 정보 (예: User-Agent, Cookie)

3️⃣ HTTP 응답 - 서버가 요청 처리 후 응답 반환

서버는 클라이언트의 요청을 처리한 후, HTTP 응답을 반환합니다.

HTTP/1.1 200 OK Content-Type: text/html

HTTP 응답은 다음과 같은 정보를 포함합니다:

  • 상태 코드: 요청 결과 (200 OK, 404 Not Found, 등)
  • 본문(Body): 요청한 리소스 (HTML, JSON, 이미지 등)
  • 헤더: 응답 관련 메타데이터
공인IP & 사설IP & NAT

공인 IP 주소 (Public IP Address)

  • ISP(인터넷 서비스 제공자)가 할당하는 인터넷 연결이 가능한 IP 주소
  • 전 세계적으로 고유하며 인터넷 상의 장치 식별에 사용
  • 예시: 112.169.33.198

사설 IP 주소 (Private IP Address)

  • 내부 네트워크 전용 IP 주소 (인터넷 연결 불가)
  • 전 세계적으로 고유할 필요 없음 (중복 사용 가능)
  • 사설 IP 주소 대역:
    • A Class: 10.0.0.0 ~ 10.255.255.255
    • B Class: 172.16.0.0 ~ 172.31.255.255
    • C Class: 192.168.0.0 ~ 192.168.255.255

NAT (Network Address Translation)

  • 사설 IP → 공인 IP 변환으로 인터넷 접속 가능하게 하는 기술

NAT 동작 방식

  1. 출발지 주소 변환: 내부 → 인터넷
    예: 192.168.10.27 → 112.169.33.198
  2. 목적지 주소 변환: 인터넷 → 내부
    예: 112.169.33.198 → 192.168.10.27

예시 구조

장치 인터페이스 IP 주소 설명
PC - 192.168.10.27 내부 클라이언트
R1 (라우터) F0/0 192.168.10.1 내부 인터페이스
R1 (라우터) F0/1 112.169.33.198 공인 IP 주소
인터넷 - - 외부 네트워크

IP 주소 사용 시 주의사항

  1. 중복 금지: 동일 네트워크 내 IP 중복 시 통신 장애 발생
  2. 잘못된 대역 사용 금지: 예) 172.32.0.0/16은 사설 대역 아님

요약

  • 공인 IP: ISP 제공, 인터넷 연결 가능
  • 사설 IP: 내부 네트워크용, NAT로만 인터넷 접속 가능
  • NAT: 사설 IP를 공인 IP로 변환해 인터넷 통신 가능하게 함
  • IP 주소는 중복 없이, 정확한 대역으로 설정 필요
UFW vs nftables 정리

UFW vs nftables

항목 UFW nftables
기본 성격 사용자 친화적 방화벽 관리 도구 리눅스 커널 방화벽 프레임워크
핵심 목적 iptables를 간단히 제어 iptables를 완전히 대체하는 통합 방화벽 시스템
관리 대상 주로 단순 서버 복잡한 대규모 환경
주요 특징 쉬운 명령어, 빠른 설정 고성능, 복잡한 조건 제어 가능
학습 난이도 매우 쉬움 (초보자 친화적) 중급 이상 권장 (구조와 문법 이해 필요)

장단점 비교

UFW

  • 장점
    • 명령어가 직관적이고 쉬움
    • 빠르게 포트를 열고 닫을 수 있음
    • 초보자도 쉽게 방화벽을 구축 가능
    • Ubuntu, Debian 기본 통합
  • 단점
    • 복잡한 방화벽 정책 작성이 어려움
    • 대규모 IP/포트 관리 비효율적
    • 정책 자동화에 약함
    • 실제 동작은 iptables를 간접 조작

nftables

  • 장점
    • IPv4, IPv6 통합 관리 가능
    • set, map 등을 사용해 대량의 IP/포트 고속 처리 가능
    • 완전한 상태 기반 방화벽 구축 가능
    • 대규모, 고성능 환경에 최적화
    • 하나의 룰셋으로 전체 방화벽 관리 가능
  • 단점
    • 초보자에게 진입장벽이 높음
    • 설정을 잘못하면 네트워크 차단 위험
    • 직접 룰을 작성하고 관리해야 함

사용 추천 상황

상황 UFW 추천 nftables 추천
리눅스 초보자 ✅ ❌
단순한 서버 방화벽 설정 ✅ ❌
포트 몇 개만 빠르게 열고 싶을 때 ✅ ❌
대규모 서버 환경(10대 이상) ❌ ✅
IP별로 세밀한 통제가 필요할 때 ❌ ✅
자동화, 스크립트 관리가 필요한 경우 ❌ ✅
IPv4, IPv6 통합 관리가 필요한 경우 ❌ ✅
성능과 확장성이 중요한 환경 ❌ ✅
iSCSI란?

iSCSI?

  • 정의: IP 네트워크를 통해 SCSI(스토리지 명령어) 명령을 전송하는 스토리지 네트워크 프로토콜
  • 역할: 서버와 스토리지 간의 통신을 가능하게 하며, 서버는 원격 스토리지를 로컬 디스크처럼 인식
  • 동작 방식: TCP/IP 위에서 동작하며, 일반적으로 포트 3260번을 사용

iSCSI 구성 요소

구성 요소 설명
iSCSI Initiator 클라이언트. iSCSI Target에 접속해 데이터를 요청함 (예: 서버 OS에서 동작)
iSCSI Target 스토리지 제공자. 디스크를 네트워크를 통해 공유함 (예: SAN 장비, NAS 등)

iSCSI의 종류 (구성 방식 기준)

구분 설명
소프트웨어 Initiator OS에 내장되거나 드라이버 형태로 제공됨 (예: Windows iSCSI Initiator)
하드웨어 Initiator 전용 네트워크 어댑터(HBA)를 사용하여 오프로드 성능 향상
Target 구성 리눅스, Windows, SAN 장비 등 다양한 환경에서 Target 구성 가능

iSCSI 사용 이유

이유 설명
1. 비용 절감 전용 Fibre Channel 대신 일반 이더넷 장비를 사용하므로 저렴함
2. 유연성 IP 기반 네트워크만 있으면 어디서든 접근 가능
3. 확장성 스토리지 추가 및 확장이 쉬움
4. 관리 용이 기존 TCP/IP 인프라로 관리 가능
5. 고가용성 다중 경로(MPIO) 구성으로 장애 대비 가능

사용 예시

  • 가상화 환경 (예: VMware, Hyper-V)에서 VM 저장소로 사용
  • 클러스터 시스템에서 공유 스토리지 구성
  • 백업 및 DR(재해 복구) 시스템 구축 시
정적 라우팅(Static Routing) vs 동적 라우팅(Dynamic Routing)

1. 정적 라우팅 (Static Routing)

정의

  • 관리자가 수동으로 라우팅 경로를 설정하는 방식
  • 네트워크 변화에 자동 대응 불가 → 변경 시 수동 수정 필요

특징

  • 관리자가 ip route 명령어 등으로 직접 경로 지정
  • 경로가 고정됨
  • 라우팅 테이블이 변경되지 않음

장점

  • 설정이 간단하고 예측 가능함
  • 리소스를 거의 사용하지 않음 (CPU, 메모리 부담 ↓)
  • 보안성이 높음 (의도한 경로로만 통신)

단점

  • 네트워크 장애나 변경에 자동 대응 불가
  • 큰 네트워크에선 관리 부담 증가
  • 관리자가 실수할 경우 경로 오류 발생 가능

사용 예시

  • 소규모 네트워크 (ex. 가정용, 실습망, IoT 환경)
  • 라우팅 경로가 거의 바뀌지 않는 안정적인 환경
  • 백업 라우팅 구성 (failover 경로로 사용)

2. 동적 라우팅 (Dynamic Routing)

정의

  • 라우터끼리 정보를 교환하여 자동으로 최적 경로를 결정하는 방식

특징

  • 라우터 간 라우팅 프로토콜 사용 (ex. RIP, OSPF, EIGRP, BGP)
  • 네트워크 구조 변경 시 자동으로 경로 재계산.

장점

  • 확장성 좋음: 대규모 네트워크에서 유리
  • 장애 복구 빠름: 링크 장애 시 자동 우회
  • 관리 편리: 수많은 경로를 자동으로 유지

단점

  • 리소스 사용: CPU, 메모리, 네트워크 트래픽 증가
  • 복잡한 설정: 프로토콜 이해와 튜닝 필요
  • 초기 수립 시간이 비교적 오래 걸릴 수 있음

사용 예시

  • 기업 및 캠퍼스 네트워크
  • 클라우드 네트워크, ISP 간 BGP 연결
  • 라우터가 자주 추가/제거되는 환경

비교

항목 정적 라우팅 (Static) 동적 라우팅 (Dynamic)
설정 방식 수동 자동
관리 편의성 불편 편리
네트워크 변경 대응 수동 수정 필요 자동으로 반영
리소스 사용 거의 없음 많음 (CPU, 메모리 등)
보안성 높음 상대적으로 낮음
사용 환경 소규모, 단순 네트워크 중대형, 복잡한 네트워크

결론 및 선택 기준

  • 정적 라우팅: 네트워크 구조가 단순하고 자주 변하지 않는 환경에 적합
  • 동적 라우팅: 장비나 연결이 자주 바뀌고, 장애 복구가 중요한 환경에 적합

대부분의 실무 환경에서는 혼합 방식으로 구성되어 있음 (정적 + 동적 라우팅)

김성휘

클라우드 내부망과 외부망

내부망

  1. 정의 : 클라우드 서비스 제공자(나)가 제공하는 네트워크 안에서 같은 데이터 센터(공유기, 랜카드...) 또는 VPC(가상 사설망) 내의 자원끼리 통신하는 전용 네트워크
  2. 특징
  • 보안성 높음 : 외부 인터넷을 거치지 않기 때문에 패킷 노출 위험도 낮음
  • 속도 안정적 : 인터넷을 우회하지 않고 클라우드 데이터센터 내부망을 사용하므로 지연이 낮고 속도가 빠름
  • 과금 방식 : 내부 트래픽은 대부분 무료 또는 저렴한 과금
  1. 주 용도
  • 클라우드 서버 간 통신
  • 스토리지와 인스턴스 간 통신
  • 보안이 중요한 데이터 전송
  • 시스템 간 API 호출

외부망

  1. 정의 : 클라우드 자원(서버, 스토리지 등)이 인터넷을 통해 외부 사용자와 통신하는 네트워크
  2. 특징
  • 접근성 뛰어남 : 인터넷이 연결된 곳이라면 어디든 접속 가능. 웹사이트, 모바일 앱, API등이 이 경로를 통해 서비스 제공
  • 보안성 낮음 : 외부 인터넷을 통해 연결되므로, 해킹·DDoS 등 위험 노출이 큼. 보안 그룹, 방화벽, VPN, 암호화 등이 필수
  • 속도 및 지연 다양 : 인터넷 환경, 지역, 네트워크 상태에 따라 속도가 달라짐
  1. 주 용도
  • 웹사이트, 앱 서비스 제공
  • 외부 API 통신
  • 사용자 요청 처리
  • 파일 다운로드/업로드 서비스
로드밸런싱의 종류와 특징

Round Robin

  1. 동작 방식
  1. 사용자가 서버에 요청을보냄
  2. 로드밸런서는 준비된 서버 목록을 순서대로 돌며 요청을 배분
  3. 마지막에 배분된 서버 다음 서버부터 다시 요청을 넘김
  4. 서버 수만큼 순환을 반복
  1. 장점
  1. 구현이 매우 간단함
  2. 공평한 분배로 서버가 비슷한 성능일 때 효율적으로 작동
  3. 별다른 계산 없이 순차적 요청 분배
  1. 단점
  1. 각 서버의 부하 상태를 고려하지 않음
  2. 서버 처리 속도가 느릴수록 과부하 발생 가능
  3. 가중치가 없는 순수한 Round Robin은 비균형을 초래할 수 있음
  1. 한줄 요약

차례로 순환 배분하는 방식, 간단하지만 서버 부하를 고려하지 않으므로 상황에 따라 가중치를 주는 방식을 통해 개선 가능

Weighted Round Robin

  1. 동작 방식

RoundRobin과 다르게 서버마다 가중치를 설정해 서버의 성능이나 처리 능력에 맞춰 비율적으로 요청을 배분

  1. 장점
  1. 서버 성능을 고려해서 부하를 균형 있게 분배
  2. 느린 서버는 적게, 빠른 서버는 많이 -> 리소스 낭비 방지 가능
  3. 시스템 전체 성능이 고르게 유지됨
  1. 단점
  1. 가중치를 미리 정확히 설정해야 함(잘못된 설정은 오히려 부하 쏠림 현상 발생)
  2. 서버 성능이 동적 변화할 경우 가중치가 고정되어 비효율
  3. 일반 Round Robin 보다 구현이 복잡
  1. 한줄 요약

서버 성능을 고려해 요청을 비례 분배한는 방식으로 공평성과 효율을 챙길 수 있지만, 조건에 따라 역효과가 일어날 수 있다

Least Connection

  1. 동작 방식

현재 연결된 요청이 가장 적은 서버에 새로운 요청을 할당하는 방식

  1. 장점
  1. 서버 부하가 실시간으로 반영, 연결이 적은 서버에만 요청을 주기 때문에 부하 분산이 자연스럽고 효율적
  2. 서버 성능이 동일하지 않아도 부하 균형 유지 가능
  3. 고정 가중치 없이도 자동 최적화 됨
  1. 단점
  1. 연결 수만 보고 판단 -> 요청 처리 시간은 고려하지 않음
  2. 연결 해제가 늦은 경우 서버 상태를 완벽하게 반영하지 못함
  3. 세션 지속성이 필요할 경우 복잡해질 수 있음
  1. 한줄 요약

현재 연결 수가 가장 적은 서버에 요청을 배분하여, 부하를 실시간으로 고르게 유지하는 로드밸런싱 방식

IP Hash

  1. 동작 방식
  1. 클라이언트의 IP 주소를 해시함수로 변환
  2. 나온 해시 값에 따라 서버를 선택
  3. 같은 IP는 항상 같은 서버로 요청을 보냄
  1. 장점
  1. 같은 사용자가 항상 같은 서버에 배정되 세션 지속성 보장받음
  2. IP만으로 서버를 결정해 구현 방법 간단
  3. DB없이 고정 분배가 가능, 중앙 세션서버 필요없음
  1. 단점
  1. 일부 IP 대역이 몰리면 특정 서버 과부하
  2. 서버 추가/삭제하면 해시 분포가 바뀌어 기존 연결이 다른 서버로 바뀌어 세션이 끊길 수 있음
  3. 프록시 환경에서 IP가 같으면 여러 사용자가 같은 서버로 몰릴 위험
  1. 한줄요약

IP Hash는 클라이언트 IP를 해시 계산하여 특정 서버에 고정 분배하는 방식으로, 세션 유지에 유리하지만 서버 추가/삭제 시 분배 불균형이 생길 수 있다!

Response Time

  1. 동작 방식
  1. 로드밸런서는 서버들의 응답 속도를 주기적으로 체크.
  2. 사용자의 요청이 도착하면 최근 응답이 가장 빠른 서버로 요청을 보냄
  1. 장점
  1. 실시간 서버 성능 반영 현재 가장 여유 있는 서버에 요청 전달
  2. 부하 분산 최적화 바쁜 서버는 자동으로 요청이 줄고, 한가한 서버가 더 많은 요청을 받음
  3. 특별한 설정 필요 없음 단순히 응답 속도를 기반으로 판단
  1. 단점
  1. 응답 시간은 네트워크 지연, 일시적 장애에 영향을 받아서 부정확할 수 있음
  2. 실제로는 짧은 응답이 무거운 연산을 준비 중일 수도 있음
  3. 지속적인 서버 상태 모니터링 필요
  1. 한줄 요약

서버 응답 속도를 기준으로 가장 빠른 서버에 요청을 분배하는 방식, 실시간 부하에 민감하게 반응하지만 네트워크 상태나 측정 정확도에 영향을 받을 수 있음

Failover

  1. 동작 방식
  1. 서버, 데이터베이스, 네트워크를 모니터링해서 정상 작동 중인지 확인
  2. 서버가 다운되거나 응답 없을 때 미리 대기 해둔 서버로 서비스 트래픽이 자동 전환
  3. 장애가 발생해도 정상 서비스처럼 동작
  1. 장점
  1. 장애가 발생해도 중단 없는 서비스
  2. 다운 타임 최소화
  3. 관리자가 없어도 자동 전환
  1. 단점
  1. 항상 대기 상태의 서버가 필요해 비용이 추가 발생
  2. 전환 과정이 순간적이지 않음, 복구 시간 존재
  3. 복잡한 환경 구성 필요
  1. 한줄 요약

서버 장애 발생 시 자동으로 예비 서버로 전환하여, 서비스가 중단되지 않게 유지하는 고가용성(HA) 기술

L4와 L7의 로드밸런싱

L4 로드밸런싱

  1. IP주소와 포트 번호를 기준으로 트래픽을 분배
  2. 클라이어느 요청을 해석하지 않고, 패킷 레벨에서 속도와 성능이 빠름
  3. 주로 TCP, UDP 연결을 기반으로 처리
  4. 라운드로빈, 헤시기반, 세션유지
  5. LVS (Linux Virtual Server), HAProxy(TCP 모드), Nginx(stream모드)
  6. 장점
  1. 빠르고 가벼움
  2. 트래픽의 세부 내용 파악 불필요
  3. 성능에 최적화 7.단점
  4. 애플리케이션 레이어 이해 불가
  5. URL, 쿠키, 헤더 기반 라우팅 불가능

L7 로드밸런싱

  1. 요청 내용을 읽고 URL, 쿠키, 헤더, 메소드 등 기준으로 로드밸런싱
  2. 요청을 분석하여 경로, 컨텐츠 기반 라우팅 가능
  3. 다양한 정책적 제어 : 캐시, 압축, SSL 종료 등
  4. Nginx, HAProxy(HTTP모드), Envoy, Traefik, AWS ALB
  5. 장점
  1. URL, 헤더, 쿠키 기반 라우팅 가능
  2. 세밀한 정책 설정 가능
  3. 인증, 압축, 캐싱 등 추가기능 제공
  1. 단점
  1. L4보다 복잡하고 느릴 수 있음
  2. CPU 사용량이 더 많음

한줄 요약

L4 로드밸런싱은 단순한 서버 분산이 필요할 때, L7은 컨텐츠 기반 라우팅이나 보안 정책이 필요할 경우 사용

Keepalived

Keepalived란?

Linux 기반 서버에서 고가용성과 로드밸런싱을 위해 사용되는 서비스 원래는 Linux Virtual Server 를 제어하기 위한 도구였지만, VirtualIP 를 관리하면서 Failover + Health Check 기능을 제공해 고 가용성 클러스터를 쉽게 구축 가능

주요 기능

  1. VRRP : Active/Backup 구조의 IP Failover 제공 ( Master가 죽으면 Backup이 VIP를 인계)
  2. Health Check : 서버 사애 체크 기능 장애 발생시 VIP를 다른 서버로 넘김
  3. LVS 로드밸런싱 : Layer 4 로드밸런싱 구성 가능

Keepalived 로드밸런싱 구조

  1. Active-Passive 방식(HA)
  1. Master 서버에만 VIP가 붙어 서비스
  2. Master가 죽으면 Backup 서버가 인계받아 즉시 서비스
  3. 단순 장애 대응용
  1. LVS기반 로드밸런싱
  1. Keepalived + ipvsadm 조합
  2. VIP를 사용해 여러 리얼 서버로 트래픽 분산
  3. Round Robin, Least Connection, Source Hash 등 다양한 방식 제공
  4. 주로 Layer4 로드밸런서로 사용

장점

  1. 가벼움
  2. 설정이 비교적 쉽과 직관적
  3. VRRP로 자동 Failover 시스템
  4. LVS를 통한 고성능 Layer4 로드밸런싱
  5. haproxy 같은 Layer7 로드밸서와 병행 사용 가능

주의점

  1. 자체적으로 Layer7 로드밸런싱은 불가능
  2. VRRP 우선순위, 스크립트 설정 잘못하면 IP 충돌 가능
UFW 방화벽

UFW

  • Uncomplicated Firewall의줄임말로 리눅스 시스템에서 방화벽 설정을 간단하게 관리할 수 있도록 만들어진 도구
  • 보통 iptables를 기반으로 작동하지만, 훨씬 더 직관적이고 사용하기 쉬운 명령어 인터페이스를 제공

특징

  1. 간단한 명령어 인터페이스 : iptables 보다 직관적인 명령어 제공
  2. 서비스 이름 사용 가능 : 포트번호 대신 서비스명으로도 설정 가능
  3. IPv4 및 IPv6 모두 지원 : 두 프로토콜을 모두 제어 가능
  4. 로그 기록 기능 : 방화벽 이벤트를 로깅하여 모니터링 가능
  5. 애플리케이션 프로파일 연동 : 설치된 애플리케이션에 맞춘 방화벽 예외 설정 가능

장점

  1. 초보자 친화적 : 복잡한 iptables보다 명령어가 훨씬 직관적
  2. 빠른 설정 : 몇 줄의 명령어로 서버 보안을 빠르게 구성 가능
  3. 시스템 통합성 : Ubuntu와 같은 배포판에 기본 탑재되어 있고, 자동으로 시스템 시작 시 동작
  4. 로깅 기능 제공 : 트래픽 기록으로 문제 추적 및 보안 모니터링 가능

단점

  1. 고급 기능 부족 : 세부적인 패킷 조작, 연결 추적 등 고급 기능은 iptables보다 제약이 있음
  2. GUI 없음 : 기본적으로 CLI 기반이므로 GUI 방화벽 설정을 원하는 사람에겐 불편
  3. 복잡한 조건 제어 어려움 : 예: 특정 시간대에만 허용하는 규칙 등은 구현이 어려움
  4. 다중 인터페이스 지원 제한 : 복잡한 네트워크 환경(예: 여러 NIC 카드 설정)에선 관리가 까다로움
  5. 특정 배포판 의존성 : Ubuntu 계열에 특화되어 있고, 다른 리눅스에서는 iptables나 firewalld가 더 일반적임

한줄 요약

리눅스 초보자나 작은 서버를 운영할 때, 빠르게 방화벽을 구성하고 싶을 때 용잏함

Kubernetes

이정민

Kubernetes를 설치하려면 왜 이러한 구성 요소들과 설정이 필요한 걸까 ?
단계 목적 필요 이유
방화벽 해제 네트워크 포트 차단 해제 API 서버, etcd, kubelet 등의 통신 포트를 방화벽이 차단하면 클러스터 구성 실패
swap 비활성화 메모리 swap 기능 비활성화 kubelet이 swap된 메모리를 감지하면 리소스 관리 오류 발생
iptables 설정 네트워크 필터링 기능 활성화 Pod 간 또는 서비스 간 패킷 라우팅 처리를 위한 iptables 커널 모듈 필요
containerd 설치 container runtime 환경 구성 Kubernetes가 Pod를 실행하기 위해 container runtime 필요 (Docker 대신 containerd 권장)
CRI 활성화 kubelet과 containerd 간 연동 설정 kubelet이 containerd와 연동하여 Pod를 실행하려면 CRI 인터페이스 활성화 필요
패키지 저장소 등록 kubernetes 패키지 설치 경로 구성 yum을 통해 kubeadm, kubelet, kubectl을 설치하려면 공식 저장소 등록 필수
SELinux 완화 설정 kernel 보안 정책 완화 SELinux가 enforcing 모드일 경우 일부 Kubernetes 기능이 차단됨 (파일 접근 등)
필수 패키지 설치 cluster 초기화 및 조작 도구 설치 kubeadm으로 초기화, kubelet으로 실행, kubectl로 클러스터 조작 수행
클러스터 초기화 control plane 컴포넌트 배포 etcd, kube-apiserver, scheduler, controller-manager 구성
CNI 플러그인 설치 Pod 네트워크 구성 Kubernetes는 기본 네트워크 미제공 → Calico, Flannel 등을 통해 Pod 간 통신 가능하게 구성
Calico란 무엇인가 ?

Calico란 무엇인가 ?

역할: Kubernetes에서 Pod 간 네트워크 통신과 네트워크 보안 정책을 구현하는 CNI 플러그인으로 기본적으로 자체적인 Pod 네트워크 기능을 제공하지 않기 때문에 CNI 플러그인의 설치가 Kubernetes에서 필수

Calico의 주요 기능

기능 명칭 기능 설명 예시
Pod 네트워크 구성 기능 각 Pod에 고유 IP 주소를 할당하고, Pod 간 통신 경로를 설정하는 기능 아파트 입주자에게 주소를 배정하고 도로를 연결하는 작업
네트워크 정책 기능 특정 Pod 간 통신을 허용하거나 차단하는 보안 정책 설정 기능 특정 집에 자물쇠를 설치하여 허가된 사람만 출입 가능하게 하는 것
고급 라우팅 기능 (BGP) BGP 프로토콜을 활용한 외부 네트워크 라우팅 기능 교통체증을 피하기 위해 우회도로를 활용하는 고속 경로 설정

Kubernetes Dashboard 접속 문제와 Calico의 관계

대표적인 문제 현상

  • 흰 화면 또는 빈 페이지 출력
  • 404 또는 타임아웃 에러
  • Dashboard Pod는 정상이나 웹 접속 실패

이러한 현상은 대부분 Calico의 설치 실패 또는 Pod 간 네트워크 단절의 원인

문제 원인 분석

원인 명칭 상세 설명 점검 방법
Calico 설치 실패 YAML 파일 오류, 이미지 다운로드 실패, 네임스페이스 문제 등으로 인해 Pod 미기동 상태 kubectl get pods -n kube-system 명령어로 calico 관련 Pod 상태 확인
Pod 간 통신 불능 상태 iptables 설정 또는 커널 모듈 누락으로 인해 Pod 간 트래픽이 차단됨 ping, curl 명령어로 Pod 간 직접 통신 확인
Kernel 네트워크 설정 누락 br_netfilter, ip_forward 설정이 누락되면 Kubernetes 네트워크 트래픽 처리 실패 sysctl 명령어로 커널 파라미터 값 확인
DNS 해석 실패 CoreDNS Pod의 장애로 인해 Cluster 내부 DNS 해석 불가 kubectl get pods -n kube-system에서 coredns 상태 확인

문제 해결을 위한 점검 항목

  1. Calico YAML 파일 적용 여부

    • calico.yaml, calico-custom.yaml이 모두 적용되었는지 확인

  2. 커널 네트워크 설정 값 확인

    sysctl net.bridge.bridge-nf-call-iptables
sysctl net.ipv4.ip_forward

  3. Calico Pod 상태 점검

    kubectl get pods -n kube-system

  4. SELinux 상태 점검

    getenforce
    • Enforcing 상태라면 Permissive로 변경 권장

예시

Kubernetes 내부 네트워크는 아파트에 입주한 세대(Pod)마다 인터넷 회선을 설치하는 과정과 같으며 Calico는 이 회선을 연결해 주는 통신사(CNI Provider) 역할

통신사가 없다면 전화도 인터넷도 안 되는 것처럼 CNI 없이 Pod 간 통신은 불가능

Dashboard나 Metrics Server는 Pod 간 HTTP 통신이 기본 전제이기 때문에 Calico가 정상적으로 설치되지 않으면 동작 자체가 불가능

요약

  • Calico는 Kubernetes Pod 간 네트워크 연결을 위한 핵심 구성 요소
  • 네트워크 정책 기능을 통해 Pod 수준의 보안 제어 가능
  • CNI 플러그인 설치 여부는 Kubernetes 기능 정상 작동의 전제 조건
  • Dashboard, Metrics Server, Ingress 등은 모두 Pod 간 통신을 기반으로 동작하므로 Calico의 정상 동작 여부가 클러스터 품질에 직접적인 영향을 미침

Cloud

이정민

Cloud & Software Load Balancer 비교 및 설정 방법

Cloud Load Balancer

1. Elastic Load Balancer (ELB)

  • 역할: L4(TCP)·L7(HTTP) 트래픽 모두 분산

  • 특징

    • HTTP(S), TCP, SSL 지원
    • 간단한 설정으로 빠르게 시작 가능
    • 대상(Target) → 인스턴스(EC2) 단위 등록

  • 사용 예시

    • 레거시 웹 애플리케이션 앞단에 기본적인 요청 분산
    • 특별한 HTTP 헤더·경로 기반 분기가 필요 없는 경우

  • 장점 / 단점

    • 구성 단순·빠른 배포
    • HTTP 레벨 정책 부족, 세부 튜닝 제한

  • 설정 방법

    1단계: 기본 구성

    • 이름: my-classic-lb
    • VPC: ap-northeast-2 기본 VPC
    • 가용영역: ap-northeast-2a, ap-northeast-2c (퍼블릭 서브넷 선택)

    2단계: 보안 설정

    • SSL 인증서: ACM에서 발급된 인증서 선택
    • 보안 정책: ELBSecurityPolicy-2016-08 선택
    • SSL 포트: 443

    3단계: 보안 그룹

    • 이름: my-clb-sg
    • 설명: Security group for Classic Load Balancer 인바운드 규칙:
    • HTTP(80) - 0.0.0.0/0
    • HTTPS(443) - 0.0.0.0/0 아웃바운드 규칙:
    • 모든 트래픽(0-65535) - 0.0.0.0/0

    4단계: 리스너 및 라우팅

    • 리스너 1: HTTPS:443 → HTTP:80
    • 리스너 2: HTTP:80 → HTTP:80 (선택사항: HTTPS 리다이렉트)

    5단계: 상태 검사 구성

    • 프로토콜: HTTP
    • 포트: 80
    • 경로: /health.html
    • 응답 제한 시간: 5초
    • 간격: 30초
    • 비정상 임계값: 2
    • 정상 임계값: 10

    6단계: EC2 인스턴스 등록

    • 인스턴스 선택
    • 교차 영역 로드 밸런싱 활성화
    • Connection Draining 활성화 (300초)

2. Application Load Balancer (ALB)

  • 역할: L7 전용 HTTP/HTTPS 분산

  • 특징

    • 경로 기반(Path), 호스트 기반(Host) 라우팅
    • WebSocket, HTTP/2 지원
    • 인증(OIDC), redirection·rewrite

  • 사용 예시

    • /api/* 는 API 서버, /static/* 는 정적 콘텐츠 서버로 분기
    • 도메인별( app.example.com, api.example.com) 트래픽 분리

  • 장점 / 단점

    • 세밀한 HTTP 레벨 제어, A/B 테스트 지원
    • TCP 레벨보단 약간의 latency 증가, 과금이 ELB보다 높을 수 있음

  • 설정 방법

    1단계: 기본 구성

    • 이름: my-application-lb
    • 체계: 인터넷 경계
    • IP 주소 유형: IPv4

    2단계: 네트워크 매핑

    • VPC: ap-northeast-2 기본 VPC
    • 매핑: ap-northeast-2a, ap-northeast-2c (퍼블릭 서브넷)
    • 가용영역당 서브넷 1개 선택

    3단계: 보안 설정

    • SSL 인증서: ACM 인증서 선택
    • 보안 정책: ELBSecurityPolicy-2016-08
    • ALPN 정책: HTTP1 및 HTTP2 지원

    4단계: 보안 그룹

    • 이름: my-alb-sg
    • 설명: Security group for Application Load Balancer 인바운드 규칙:
    • HTTP(80) - 0.0.0.0/0
    • HTTPS(443) - 0.0.0.0/0 아웃바운드 규칙:
    • 모든 트래픽(0-65535) - 0.0.0.0/0

    5단계: 리스너 및 라우팅

    • HTTPS:443 리스너 추가
    • HTTP:80 리스너 추가 (HTTPS로 리다이렉트 규칙 설정)

    6단계: 대상 그룹 구성 [웹 서버 그룹]

    • 이름: web-target-group
    • 프로토콜 버전: HTTP1
    • 프로토콜: HTTP:80
    • 대상 유형: 인스턴스
    • 경로 패턴: /web/*
    • 상태 검사:
      • 프로토콜: HTTP
      • 경로: /health.html
      • 포트: traffic-port
      • 정상 임계값: 5
      • 비정상 임계값: 2
      • 제한 시간: 5초
      • 간격: 30초
      • 성공 코드: 200

    [API 서버 그룹]

    • 이름: api-target-group
    • 프로토콜 버전: HTTP1
    • 프로토콜: HTTP:8080
    • 대상 유형: 인스턴스
    • 경로 패턴: /api/*
    • 상태 검사:
      • 프로토콜: HTTP
      • 경로: /api/health
      • 포트: traffic-port
      • 정상 임계값: 5
      • 비정상 임계값: 2
      • 제한 시간: 5초
      • 간격: 30초
      • 성공 코드: 200
    # 웹 서버 구성 예시 (경로별 라우팅 테스트용)
location /web {
  return 200 "Web Server Response";
}

location /api {
  return 200 "API Server Response";
}

3. Network Load Balancer (NLB)

  • 역할: L4 전용 초고속 분산 (TCP·UDP)

  • 특징

    • 초당 수백만 건, 수 밀리초 이하 지연
    • 고정 IP(Elastic IP) 할당 가능
    • TLS 종료는 지원하지만 L7 기능(경로·호스트)은 불가

  • 사용 예시

    • 게임 서버, 실시간 스트리밍, VoIP 등 초저지연이 필수인 서비스
    • 외부 시스템과 고정 IP로 통신해야 하는 환경

  • 장점 / 단점

    • 지연·처리량 최적화, 대규모 TCP 연결 처리
    • HTTP·HTTPS 고급 라우팅 기능은 불가

  • 설정 방법

    1단계: 기본 구성

    • 이름: my-network-lb
    • 체계: 인터넷 경계
    • IP 주소 유형: IPv4

    2단계: 네트워크 구성

    • VPC: ap-northeast-2 기본 VPC 매핑:
    • ap-northeast-2a: 퍼블릭 서브넷 선택, EIP 할당
    • ap-northeast-2c: 퍼블릭 서브넷 선택, EIP 할당
    • 교차 영역 로드 밸런싱 활성화

    3단계: 보안 설정

    • TLS 리스너의 경우:
      • 인증서: ACM 인증서 선택
      • 보안 정책: ELBSecurityPolicy-TLS-1-2-2017-01

    4단계: 리스너 구성

    • TCP/TLS:443 리스너 추가
    • 기본 작업: game-server-group으로 전달

    5단계: 대상 그룹 설정

    • 이름: game-server-group
    • 프로토콜: TCP
    • 포트: 443
    • 대상 유형: 인스턴스
    • 등록된 대상에 대한 IP 주소 유형: IPv4
    • 상태 검사:
      • 프로토콜: TCP
      • 포트: traffic-port
      • 정상 임계값: 5
      • 비정상 임계값: 3
      • 간격: 10초
      • 제한 시간: 6초

    6단계: 대상 등록

    • 인스턴스 선택
    • 포트 재정의: 443
    • 등록 보류 중인 대상 포함

Cloud Load Balancer 비교

항목 ELB ALB NLB
계층 L4/L7 L7 L4
프로토콜 HTTP/HTTPS, TCP, SSL HTTP/HTTPS, WebSocket, HTTP/2 TCP, UDP, TLS
라우팅 단순 라운드로빈 경로·호스트·헤더 분기 IP·포트 기반
고급 기능 거의 없음 인증·rewrite·WAF 연동 고정 IP, 대규모 동시 연결
과금 모델 처리량 기반 처리량+요청 수 기반 처리량 기반
추천 용도 레거시/간단 웹 마이크로서비스/API 실시간·저지연

Software Load Balancer

1. HAProxy

  • 레벨: L4(TCP) & L7(HTTP)

  • 특징

    • 다양한 분산 알고리즘(Round Robin, LeastConn, Source)
    • ACL(Access Control List), SSL Termination·Passthrough
    • 내장 통계 대시보드 (:8080 포트)

  • 예시 설정

    frontend http_front
    bind *:80
    mode http
    default_backend web_back

backend web_back
    mode http
    balance leastconn
    server web1 10.0.0.1:80 check
    server web2 10.0.0.2:80 check

  • 장점 / 단점

    • 경량·고성능, 설정 유연
    • 설정 문법이 다소 복잡할 수 있음

2. NGINX

  • 레벨: L7(HTTP) 기본, L4(TCP/UDP) 지원 가능

  • 특징

    • HTTP reverse proxy·정적 파일 서비스 강점
    • 설정 간결(nginx.conf), 다수 커뮤니티 모듈

  • 예시 설정

    upstream web {
    server web1.example.com;
    server web2.example.com;
}

server {
    listen 80;
    location / {
        proxy_pass http://web;
    }
}

  • 장점 / 단점

    • 설정 직관적·문서 풍부, 정적 콘텐츠 처리 우수
    • 순수 OSS 버전은 일부 고급 기능(health check, sticky) 제약

Software Load Balancer 비교

항목 HAProxy NGINX
계층 L4/L7 L7 기본, L4 옵션
분산 알고리즘 다양(LeastConn 등) Round Robin, IP Hash
헬스체크 지원 제한적(모듈 필요)
SSL 처리 Termination/Passthrough Termination
모니터링 내장 대시보드 외부 툴 연동

실습 전 환경 설정

  1. 운영체제: Rocky/CentOS 8+, Ubuntu 24.04+

  2. 패키지 설치

    # HAProxy
sudo yum install -y haproxy     # Rocky/CentOS
sudo apt install -y haproxy     # Ubuntu/Debian

# NGINX
sudo yum install -y nginx       # Rocky/CentOS
sudo apt install -y nginx       # Ubuntu/Debian

  3. 방화벽: 80, 443, 8080 포트 허용

Cloud Load Balancer와 Software Load Balancer의 주요 차이점

  1. 구축/관리 방식
  • Cloud LB: AWS가 관리하는 완전 관리형 서비스로, 설정이 간단하고 유지 보수가 쉬움
  • Nginx/HAProxy: 직접 서버에 설치하고 관리해야 하며, 설정과 유지 보수에 전문성이 필요함
  1. 확장성/가용성
  • Cloud LB: AWS가 자동으로 확장과 고가용성을 보장
  • Nginx/HAProxy: 직접 확장성과 고가용성 구성을 해야 함
  1. 특징과 용도
  • Cloud LB:
    • ELB: 기본적인 로드밸런싱
    • ALB: 경로 기반 라우팅, 마이크로서비스에 적합
    • NLB: 초고속 TCP 트래픽 처리
  • Nginx: HTTP reverse proxy, 정적 파일 서비스에 강점
  • HAProxy: 다양한 로드밸런싱 알고리즘, 상세한 트래픽 제어 가능
  1. 비용
  • Cloud LB: 트래픽 사용량에 따른 과금
  • Nginx/HAProxy: 서버 비용만 발생
NAT 인스턴스란 무엇이고 NAT 게이트웨이와 무슨 차이가 있을까 ?

AWS NAT 인스턴스란?

  • 정의
    • NAT 인스턴스는 AWS VPC 내부의 Private subnet 리소스가 인터넷으로 아웃바운드 트래픽을 보낼 수 있도록 하는 EC2 인스턴스
  • 주요 용도
    • 프라이빗 서브넷의 서버가 직접 퍼블릭 IP를 갖지 않고도 인터넷 접근이 필요할 때 사용
  • 작동 원리
    1. Private subnet에 있는 인스턴스가 NAT 인스턴스의 Private IP로 패킷 전송
    2. NAT 인스턴스가 소스 IP를 자신의 Public IP(Elastic IP)로 변환(Masquerade)
    3. 응답을 받아 원래 클라이언트 IP로 다시 전달

NAT 인스턴스 vs NAT 게이트웨이 상세 비교

항목 NAT 인스턴스 NAT 게이트웨이
관리 부담 운영자가 OS 패치, 스케일링, 장애 처리 직접 수행 AWS가 완전 관리(패치·스케일링 자동)
가용성 싱글 AZ 대상, 장애 시 직접 복구 또는 이중화 구성 필요 AZ 내 자동 복구, 멀티-AZ 배포 시 고가용성
성능 인스턴스 타입(t2.micro/t3.large 등)에 종속, 최대 대역폭 한계 최대 10Gbps 이상 자동 확장
설정 편의성 EC2 생성·보안 그룹·소스/대상 체크 해제 직접 구성 콘솔/CLI 몇 클릭으로 생성·라우트 테이블만 연결
비용 구조 EC2 요금 + EIP 요금 시간당 약 0.045 USD + 처리 GB당 약 0.045 USD (서울 리전 기준, 대략)
모니터링·로그 CloudWatch 커스텀 설정 필요 VPC Flow Logs, CloudWatch 지표 기본 제공
한계 Auto Scaling 직접 구축 필요 단일 AZ당 NAT 게이트웨이 1개 필요(멀티-AZ 구성 시 AZ별 생성)

예시

  • 편의점 무인 결제 기기
    • Private 서버: 계산대 없이 거래만 하는 소비자
    • NAT 인스턴스: 사람이 결제 도와주는 알바생 → 교육·교대·인사관리 필요
    • NAT 게이트웨이: 완전 무인 결제 시스템 → 설치만 하면 24시간 자동 운영

언제 NAT 인스턴스를 선택할까 ?

  • 초소규모 테스트·개발 환경
  • 커스텀 NAT 동작이 필요할 경우

언제 NAT 게이트웨이를 선택할까 ?

  • 트래픽이 일정 수준 이상 지속적으로 발생할 경우
  • 고가용성·자동 확장이 필수인 프로덕션 환경
  • 운영 부담 최소화가 목표인 경우

김동욱

Amazon EBS와 S3에 대하여

1. 기본 개념

Amazon EBS (Elastic Block Store)

  • EBS는 블록 스토리지 서비스로, 주로 EC2 인스턴스와 연결하여 사용됩니다.
  • 데이터를 블록 단위로 저장하며, 운영 체제나 데이터베이스와 같은 영속적인 저장에 적합합니다.
  • EBS 볼륨은 단일 EC2 인스턴스에 연결되어 사용됩니다.

Amazon S3 (Simple Storage Service)

  • S3는 객체 스토리지 서비스로, 파일을 저장하는 데 주로 사용됩니다.
  • 객체 단위로 데이터를 저장하며, 웹에서 파일 저장, 백업 및 대용량 데이터 관리를 위한 서비스입니다.
  • 웹 접근을 통해 언제 어디서나 데이터를 다룰 수 있습니다.

2. 주요 차이점

항목 Amazon EBS Amazon S3
스토리지 유형 블록 스토리지 (Block Storage) 객체 스토리지 (Object Storage)
연결 방식 EC2 인스턴스와 연결하여 사용 인터넷을 통해 접근 가능 (EC2와 독립적 사용)
데이터 저장 방식 데이터를 블록 단위로 저장 데이터를 객체 단위로 저장
사용 목적 운영 체제나 데이터베이스의 디스크 저장 파일 저장, 백업, 웹 애플리케이션 파일
데이터 접근 EC2 인스턴스에서만 접근 가능 웹 API나 AWS 서비스에서 언제 어디서나 접근 가능
내구성 고가용성을 제공하나 내구성은 디스크 손상 시 낮을 수 있음 내구성 보장 (데이터 복제)
확장성 크기와 성능을 조정 가능하나 EC2에 의존 자동 확장 및 무제한 저장 용량
가격 용량 및 IOPS에 따라 요금 부과 저장 용량 및 요청 수에 따라 요금 부과
성능 고성능 (IOPS, 데이터 전송 속도) 대용량 처리에 최적화, 성능보다 내구성 및 확장성 강조
사용 예시 데이터베이스 저장, EC2 서버의 운영 체제 및 애플리케이션 파일 백업, 대용량 파일 저장, 웹 애플리케이션

3. 사용 사례

Amazon EBS 사용 사례

  • EC2 인스턴스의 디스크: EBS는 EC2 인스턴스의 운영 체제와 애플리케이션을 저장하는 데 사용됩니다.
  • 성능이 중요한 워크로드: 높은 IOPS가 필요한 데이터베이스나 운영 체제, 애플리케이션에 적합합니다.
  • 영속적인 스토리지: EC2 인스턴스가 종료되더라도 데이터를 영구적으로 저장합니다.

Amazon S3 사용 사례

  • 대용량 파일 저장: 이미지, 비디오, 백업 데이터 등 파일을 저장하는 데 적합합니다.
  • 정적 웹사이트 호스팅: S3는 정적 웹사이트(HTML, CSS, JavaScript 파일 등) 호스팅이 가능합니다.
  • 데이터 백업: 데이터를 백업하거나 아카이브하는 용도로 사용됩니다.
  • 무제한 스토리지: S3는 데이터를 무제한으로 저장할 수 있습니다.

4. EBS와 S3의 선택 기준

내구성

  • S3는 11 9의 내구성을 제공하여, 데이터 손실 확률이 매우 낮습니다. 반면, EBS는 EC2 인스턴스와 연결되어 있어 인스턴스나 볼륨 장애 시 데이터 손실 가능성이 있습니다.

성능

  • EBS는 고성능이 필요한 워크로드에서 유리합니다. 특히 고속 읽기/쓰기 작업을 자주 수행해야 하는 데이터베이스에 적합합니다.
  • S3는 대용량 처리에 최적화되어 있으며, 내구성 및 확장성이 강조됩니다.

확장성

  • S3는 무제한 저장 공간을 제공하며, 자동 확장 기능이 있어 대용량 데이터를 쉽게 처리할 수 있습니다.
  • EBS는 수동으로 확장이 필요하며, EC2 인스턴스와 연결되어 있기 때문에 EC2에 의존적입니다.

비용

  • S3는 저렴한 비용으로 무제한 저장이 가능하지만, EBS는 IOPS와 용량에 따라 추가 비용이 발생합니다.

5. 결론

  • EBS는 EC2 인스턴스와 연결하여 운영 체제나 데이터베이스를 저장하는 데 적합합니다. 고속 입출력 성능과 영속적인 데이터 저장이 필요할 때 유용합니다.
  • S3는 파일 저장, 백업, 웹사이트 호스팅 등 객체 단위의 데이터를 다룰 때 적합합니다. 확장성과 내구성이 뛰어난 서비스입니다.

따라서, 두 서비스를 혼합하여 사용할 수도 있습니다. 예를 들어, EC2 인스턴스의 데이터를 저장하는 데는 EBS를 사용하고, 대용량 파일 저장이나 백업은 S3에 저장하는 방식으로 활용할 수 있습니다.

Amazon EFS (feat.S3와의 차이)

EFS (Elastic File System)

특징:

  • 파일 시스템 기반 (File system-based) 스토리지: NFS (Network File System) 프로토콜을 기반으로 여러 EC2 인스턴스에서 동시에 공유하여 사용할 수 있는 파일 시스템입니다.
  • 탄력적인 용량 확장: 파일 추가 및 삭제에 따라 자동으로 용량이 늘어나거나 줄어듭니다.
  • 높은 가용성 및 내구성: 여러 가용 영역에 데이터를 분산 저장하여 높은 가용성과 내구성을 제공합니다.
  • 간편한 관리: 용량 관리나 성능 조정에 대한 부담이 적습니다.

실제 사용 예시:

  • 여러 웹 서버 간 콘텐츠 공유: 여러 대의 웹 서버가 동일한 웹사이트 콘텐츠 (이미지, HTML 파일 등)에 접근해야 할 때 EFS를 사용하여 공유합니다.
  • 개발 환경 공유: 여러 개발자가 동일한 소스 코드나 개발 도구에 접근하여 작업해야 하는 환경에서 사용됩니다.
  • 머신러닝 워크로드: 대규모 데이터셋을 여러 머신러닝 인스턴스에서 공유하여 학습 작업을 수행합니다.
  • 콘텐츠 관리 시스템 (CMS): 워드프레스, Drupal 등 CMS에서 업로드되는 미디어 파일들을 공유하는 데 사용됩니다.
  • 컨테이너 기반 애플리케이션: Docker 컨테이너와 같은 환경에서 여러 컨테이너가 공유해야 하는 데이터를 저장하는 데 사용됩니다.

S3와의 주요 차이점

  • 접근 방식: EFS는 파일 시스템으로 마운트하여 로컬 디스크처럼 사용하지만, S3는 객체 스토리지로 API를 통해 접근해야 합니다. 이는 애플리케이션의 데이터 접근 방식에 큰 영향을 미칩니다. 기존 파일 시스템 기반 애플리케이션은 EFS를 사용하기 편리하지만, S3를 사용하려면 객체 스토리지에 맞게 애플리케이션을 수정해야 할 수 있습니다.
  • 동시 쓰기: EFS는 여러 인스턴스에서 동시에 안전하게 파일을 읽고 쓸 수 있도록 설계되었습니다. 반면, S3는 동시 쓰기에 대한 일관성 보장을 위해 주의가 필요하며, 일반적으로 읽기 작업에 더 최적화되어 있습니다.
  • 사용 사례: EFS는 공유 파일 시스템이 필요한 워크로드에 적합하고, S3는 대량의 데이터를 저장하고 효율적으로 접근하는 워크로드에 적합합니다.

요약

특징 S3 (Simple Storage Service) EFS (Elastic File System)
스토리지 유형 객체 기반 파일 시스템 기반
데이터 공유 읽기 중심 동시 읽기 및 쓰기
주요 사용처 백업, 웹 호스팅, 미디어 저장 다중 EC2 공유 파일 시스템
접근 방식 HTTP/HTTPS NFS 프로토콜
확장성 무제한 자동 확장/축소
가용성 높음 (리전 전체) 높음 (여러 가용 영역)
공유 불가 여러 EC2에서 동시 공유
AWS 라우팅 테이블 설정

AWS 라우팅 테이블 규칙

AWS 라우팅 테이블 설정은 Amazon Virtual Private Cloud (VPC) 내의 서브넷이나 게이트웨이에서 나가는 네트워크 트래픽의 경로를 결정하는 규칙을 정의하는 것입니다. 라우팅 테이블은 목적지 IP 주소 범위(Destination)와 해당 트래픽이 전달될 대상(Target)의 목록을 포함합니다.

주요 개념

  • 라우팅 테이블: VPC 내의 서브넷 또는 게이트웨이와 연결되어 네트워크 트래픽의 흐름을 제어하는 규칙의 집합입니다.
  • 경로(Route): 라우팅 테이블 내의 각 규칙을 의미하며, 목적지(Destination)와 대상(Target)으로 구성됩니다.
    • 목적지(Destination): 트래픽이 향해야 하는 IP 주소 범위 (CIDR 형식)입니다.
    • 대상(Target): 목적지로 향하는 트래픽을 실제로 보낼 AWS 리소스 (예: 인터넷 게이트웨이, NAT 게이트웨이, 가상 프라이빗 게이트웨이, EC2 인스턴스, VPC 피어링 연결 등)입니다.
  • 기본 라우팅 테이블(Main Route Table): VPC를 생성할 때 자동으로 생성되는 라우팅 테이블입니다. 명시적으로 다른 라우팅 테이블과 연결되지 않은 모든 서브넷은 기본 라우팅 테이블과 암묵적으로 연결됩니다.
  • 사용자 지정 라우팅 테이블(Custom Route Table): 사용자가 직접 생성하는 라우팅 테이블입니다. 특정 서브넷과 명시적으로 연결하여 트래픽 라우팅을 세밀하게 제어할 수 있습니다.
  • 서브넷 연결(Subnet Association): 라우팅 테이블을 특정 서브넷과 연결하는 행위입니다. 하나의 서브넷은 하나의 라우팅 테이블에만 연결할 수 있지만, 여러 서브넷이 동일한 라우팅 테이블에 연결될 수 있습니다. 연결된 서브넷은 라우팅 테이블 규칙이 적용되는 출발지이자 적용 범위 입니다.
  • 로컬 라우팅(Local Route): VPC 내의 통신을 위한 기본 경로입니다. VPC CIDR 블록 내의 모든 트래픽은 명시적인 다른 경로가 없는 경우 로컬로 라우팅됩니다.

AWS 라우팅 테이블 설정 방법

AWS 콘솔, AWS CLI, 또는 SDK를 사용하여 라우팅 테이블을 생성하고 설정할 수 있습니다. 주요 설정 단계는 다음과 같습니다.

  1. 라우팅 테이블 생성: VPC를 선택하고 라우팅 테이블의 이름과 태그를 지정하여 새로운 라우팅 테이블을 생성합니다.
  2. 경로 추가: 생성한 라우팅 테이블에 필요한 경로를 추가합니다. 각 경로는 목적지 CIDR 블록과 해당 트래픽을 보낼 대상을 지정합니다.
    • 인터넷으로 향하는 트래픽: 목적지를 0.0.0.0/0 (IPv4) 또는 ::/0 (IPv6)으로 설정하고, 대상을 해당 VPC에 연결된 인터넷 게이트웨이 (IGW)로 지정합니다. 이는 퍼블릭 서브넷을 만들기 위한 기본적인 설정입니다.
    • 프라이빗 서브넷에서 인터넷으로 향하는 트래픽: 목적지를 0.0.0.0/0 또는 ::/0으로 설정하고, 대상을 NAT 게이트웨이 또는 NAT 인스턴스로 지정합니다.
    • 다른 VPC와의 통신: 목적지를 피어링된 VPC의 CIDR 블록으로 설정하고, 대상을 VPC 피어링 연결 (peering connection)로 지정합니다.
    • 가상 프라이빗 네트워크 (VPN) 연결: 목적지를 VPN 연결을 통해 연결된 네트워크의 CIDR 블록으로 설정하고, 대상을 가상 프라이빗 게이트웨이 (VGW)로 지정합니다.
    • AWS Direct Connect 연결: 목적지를 Direct Connect 연결을 통해 연결된 네트워크의 CIDR 블록으로 설정하고, 대상을 가상 프라이빗 게이트웨이 또는 Direct Connect 게이트웨이로 지정합니다.
    • VPC 엔드포인트: 특정 AWS 서비스로 향하는 트래픽을 인터넷을 거치지 않고 VPC 내에서 라우팅하도록 설정할 수 있습니다. 이때 목적지는 해당 서비스의 접두사 목록이 되며, 대상은 VPC 엔드포인트가 됩니다.
  3. 서브넷 연결 편집: 생성하거나 기존의 라우팅 테이블을 특정 서브넷과 연결합니다. 각 서브넷은 하나의 라우팅 테이블과 연결되어야 합니다. 어떤 라우팅 테이블과도 명시적으로 연결되지 않은 서브넷은 기본 라우팅 테이블과 자동으로 연결됩니다.
  4. 경로 전파 (Route Propagation): 가상 프라이빗 게이트웨이 또는 Transit Gateway와 연결된 라우팅 테이블의 경우, 연결된 네트워크에서 학습된 경로를 자동으로 라우팅 테이블에 추가하도록 설정할 수 있습니다.

라우팅 테이블 설정의 중요성

  • 네트워크 연결성 확보: VPC 내의 인스턴스, 인터넷, 다른 네트워크와의 통신 경로를 정의하여 연결성을 확보합니다.
  • 보안 강화: 트래픽이 특정 경로를 통해서만 이동하도록 제어하여 네트워크 보안을 강화할 수 있습니다. 예를 들어, 퍼블릭 서브넷과 프라이빗 서브넷의 트래픽 경로를 분리할 수 있습니다.
  • 네트워크 격리: 서로 다른 서브넷 간의 통신을 제어하거나 특정 네트워크와의 통신을 차단하여 네트워크 격리를 구현할 수 있습니다.
  • 비용 최적화: VPC 엔드포인트를 사용하여 AWS 서비스와의 통신 비용을 절감할 수 있습니다.

AWS 사용자 지정 라우팅 테이블 활용 사례

AWS 사용자 지정 라우팅 테이블은 기본 라우팅 테이블 외에 사용자가 직접 생성하고 관리하는 라우팅 테이블입니다. 이를 통해 VPC 내의 특정 서브넷 또는 트래픽 흐름에 대해 세밀한 라우팅 규칙을 정의하여 다양한 네트워크 요구 사항을 충족할 수 있습니다.

인터넷 게이트웨이(IGW)를 통한 특정 서브넷의 인터넷 접근 제어

  • 퍼블릭 서브넷 분리: 특정 서브넷의 인스턴스만 인터넷과 통신하도록 허용하고 싶을 때, 해당 서브넷에 연결된 사용자 지정 라우팅 테이블에 인터넷 게이트웨이로 향하는 경로(0.0.0.0/0 대상: IGW)를 추가합니다. 다른 서브넷은 인터넷 게이트웨이 경로가 없는 사용자 지정 라우팅 테이블에 연결하여 인터넷 접근을 차단할 수 있습니다.

NAT 게이트웨이를 통한 프라이빗 서브넷의 아웃바운드 인터넷 접근

  • 보안 강화된 인터넷 접근: 프라이빗 서브넷의 인스턴스는 인터넷으로부터 직접적인 인바운드 연결을 받지 않아야 하지만, 소프트웨어 업데이트나 외부 서비스 접근을 위해 아웃바운드 인터넷 연결이 필요할 수 있습니다. 이때, 해당 서브넷에 연결된 사용자 지정 라우팅 테이블에 NAT 게이트웨이로 향하는 경로(0.0.0.0/0 대상: NAT 게이트웨이)를 추가합니다.

VPC 피어링을 통한 다른 VPC와의 통신 제어

  • 특정 서브넷 간 통신: VPC 피어링 연결을 통해 여러 VPC를 연결했을 때, 모든 서브넷 간의 통신을 허용하는 대신 특정 서브넷끼리만 통신하도록 제어할 수 있습니다. 각 서브넷에 연결된 사용자 지정 라우팅 테이블에 통신이 필요한 상대방 VPC의 특정 서브넷 CIDR 블록을 대상으로 VPC 피어링 연결을 지정하는 경로를 추가합니다.

VPC 엔드포인트를 통한 특정 AWS 서비스 접근 제어

  • 인터넷을 거치지 않는 안전한 서비스 접근: S3, DynamoDB와 같은 AWS 서비스에 VPC 내의 인스턴스가 접근할 때, 인터넷 게이트웨이를 거치지 않고 안전하게 통신하도록 VPC 엔드포인트를 설정할 수 있습니다. 이때, 해당 서브넷에 연결된 사용자 지정 라우팅 테이블에 해당 서비스의 접두사 목록을 대상으로 VPC 엔드포인트를 지정하는 경로를 추가합니다.

네트워크 방화벽 또는 침입 탐지/방지 시스템(IDS/IPS) 통합

  • 보안 검사 경로 강제: 보안 강화를 위해 VPC 내의 모든 또는 특정 서브넷의 트래픽이 네트워크 방화벽 또는 IDS/IPS 장비를 거치도록 강제할 수 있습니다. 사용자 지정 라우팅 테이블을 생성하고, 대상 IP 범위를 0.0.0.0/0으로 설정한 후 해당 보안 장비의 네트워크 인터페이스(ENI)를 대상으로 지정합니다.
AWS VPC, Subnet, NAT Gateway 개념 정리

1. VPC (Virtual Private Cloud)

  • VPC는 AWS 클라우드 내에서 논리적으로 분리된 네트워크 공간이다.
  • 동일 VPC 내의 리소스들은 기본적으로 내부 IP를 통해 서로 통신할 수 있다.
  • VPC 내 리소스가 인터넷과 통신하려면 **인터넷 게이트웨이(IGW)**를 생성하고 VPC에 연결(Attach)해야 한다.

2. 서브넷 (Subnet)

2.1 퍼블릭 서브넷 (Public Subnet)

  • 라우팅 테이블에 0.0.0.0/0 경로가 **인터넷 게이트웨이(IGW)**를 향함.
  • 서브넷 내 EC2 인스턴스는 직접적으로 인터넷 통신이 가능하다.
  • 공인 IP(또는 탄력적 IP)를 갖는 경우 외부에서 접근 가능.
  • 기본적으로 인스턴스는 공인 IP + 사설 IP를 모두 가진다.

2.2 프라이빗 서브넷 (Private Subnet)

  • 라우팅 테이블에 인터넷 게이트웨이(IGW) 경로가 없음.
  • EC2 인스턴스는 직접 인터넷에 접근할 수 없으며, 사설 IP만 가진다.
  • 같은 VPC 내 퍼블릭 서브넷이나 다른 프라이빗 서브넷과는 내부 통신 가능.

2.3 서브넷의 공용/사설 구분 기준

  • 서브넷 생성 시 "퍼블릭/프라이빗"을 직접 지정하지는 않음.
  • 서브넷에 연결된 라우팅 테이블에 IGW로 가는 경로(0.0.0.0/0)가 있는가?에 따라 구분됨.

3. 탄력적 IP (Elastic IP, EIP)

  • AWS에서 제공하는 고정(static) 공인 IPv4 주소.
  • 일반적인 EC2 인스턴스는 중지 후 시작 시 공인 IP가 변경됨.
  • 탄력적 IP는 사용자가 명시적으로 해제하지 않는 한 고정됨.
  • EC2, NAT Gateway 등에서 고정 공인 IP 필요 시 사용.

4. NAT Gateway (Network Address Translation Gateway)

  • 프라이빗 서브넷의 인스턴스들이 아웃바운드 인터넷 통신을 가능하게 해주는 서비스.
  • 인터넷으로 나가는 요청은 가능, 반대로 들어오는 요청은 불가능 (SSH 등 인바운드 불가).
  • 공인 IP가 없고 IGW가 연결되지 않은 인스턴스의 인터넷 접근을 중계하는 역할.

4.1 구성 조건

  • 퍼블릭 서브넷에 NAT Gateway 생성 필요.
  • NAT Gateway 생성 시 반드시 탄력적 IP(EIP) 할당이 필요함.
  • 프라이빗 서브넷의 라우팅 테이블에 0.0.0.0/0 → NAT Gateway 경로를 추가해야 함.

5. 요약 비교

항목 퍼블릭 서브넷 프라이빗 서브넷
IGW 경로 포함 예 아니오
인터넷 직접 접근 가능 불가능
외부에서 접근 가능 (EIP 필요) 불가능
NAT Gateway 필요 여부 X 필요 (아웃바운드 통신 시)
공인 IP 가질 수 있음 가질 수 없음
AWS Security Group vs AWS WAF(Web Application Firewall)

AWS 보안그룹 vs AWS WAF

1. 보안그룹 (Security Group)

  • EC2, RDS 등 리소스에 붙는 가상 방화벽
  • 인바운드/아웃바운드 트래픽을 포트/IP/프로토콜 기준으로 제어
  • 상태 저장 방식

2. AWS WAF (Web Application Firewall)

  • CloudFront, ALB, API Gateway 앞단에 배치되는 웹 방화벽
  • SQLi, XSS 등 애플리케이션 계층 공격 방지
  • IP 차단, Rate 제한, 패턴 필터링
  • 상태 비저장 방식

3. 실사용 예시

보안그룹

  • SSH는 사무실 IP만 허용
  • 웹은 80/443 전체 허용
  • DB는 내부 웹 서버 SG만 허용

WAF

  • /login 경로에 Rate 제한
  • SQL Injection 탐지 및 차단
  • 중국 IP 차단

4. 비교 요약

항목 보안그룹 (SG) AWS WAF
적용 대상 EC2, RDS 등 CloudFront, ALB, API Gateway
제어 대상 TCP/UDP 포트, IP 주소, 프로토콜 등 네트워크 수준 HTTP/HTTPS 요청, URL, 헤더, 쿼리 문자열 등 애플리케이션 요청
계층 네트워크 계층 (L3~L4) 애플리케이션 계층 (L7)
상태 상태 저장 (Stateful) 상태 비저장 (Stateless)
주요 기능 포트/IP/프로토콜 제어 패턴 기반 HTTP 필터링, Rate 제한, IP 차단
사용 위치 서브넷 내 리소스 웹 서비스 앞단 (프록시 역할)
역할 네트워크 접근 제어 (접속 허용 / 차단) 웹 요청 검사 및 필터링 (공격 탐지 / 차단)
요약 네트워크 레벨 방화벽 애플리케이션 레벨 방화벽
가비아에서 도메인을 구매 후 AWS Route53에서 호스팅을 관리하는 과정과 장점

가비아에서 도메인을 구매 후 AWS Route53에서 호스팅을 관리하는 과정과 이유

가비아에서 도메인을 구매했다면 해당 도메인이 글로벌 네임서버에 “등록”이 되고, 이후 해당 도메인의 DNS 정보를 관리할(호스팅) 네임 서버를 연결할 수 있음 (네임 서버 예: 가비아, AWS Route 53)

  1. 도메인 등록기관 (Domain Registrar): (예: 가비아)

    • 도메인 이름 자체를 사고파는(정확히는 일정 기간 동안 사용 권한을 빌려주는) 역할을 합니다.
    • example1212.shop이라는 도메인을 "소유"할 수 있도록 국제적인 관리 기관(ICANN 등)에 등록해 줍니다.
    • 가장 중요한 역할 중 하나는 해당 도메인의 DNS 정보를 관리할 네임 서버(Name Server)가 무엇인지 지정하는 기능을 제공하는 것입니다. 이 네임 서버 정보가 글로벌 DNS 시스템에 "위임(Delegation)"됩니다.

  2. DNS 호스팅 서비스 (DNS Hosting Service): (예: AWS Route 53, 가비아 자체 DNS 서비스, Cloudflare 등)

    • 실제로 도메인 이름(example1212.shop)과 하위 도메인(www.example1212.shop, book.example1212.shop)에 대한 **IP 주소 매핑 정보(A, CNAME, MX 등 각종 레코드)**를 저장하고 관리하며, 이 정보를 DNS 쿼리에 응답하는 역할을 합니다.
    • 당신이 Route 53에서 생성한 "호스팅 영역"이 바로 이 DNS 호스팅 서비스의 일부입니다.

왜 AWS Route 53의 네임 서버를 가비아에 등록해야 하는가? (필요한 이유)

  1. 권한 위임 (Delegation of Authority):

    • 당신이 가비아에서 example1212.shop 도메인을 구매했다면, 가비아는 이 도메인의 소유권을 등록해 준 것입니다. 이 시점에는 가비아의 기본 네임 서버가 이 도메인의 DNS 정보를 관리하고 있을 수 있습니다.
    • 하지만 당신은 이제 이 도메인의 DNS 정보를 AWS Route 53에서 관리하고 싶습니다. 즉, example1212.shop에 대한 모든 DNS 쿼리가 Route 53으로 오도록 "권한을 위임"해야 합니다.
    • 이 위임은 도메인 등록기관(가비아)의 도메인 관리 페이지에서 "네임 서버 변경" 옵션을 통해 이루어집니다. 가비아에서 제공하는 기본 네임 서버 주소 대신, Route 53이 당신에게 할당해준 4개의 네임 서버 주소(ns-928.awsdns-52.net., ns-1484.awsdns-57.org., 등)를 입력해야 합니다.
    • AWS에서는 각 지역의 배치된 네임 서버가 엣지 서버와 같은 역할을 하여 보다 빠르게 DNS 서비스를 제공할 수 있습니다.

  2. 글로벌 DNS 조회 과정:

인터넷 사용자가 book.example1212.shop을 입력했을 때 일어나는 과정은 다음과 같습니다:

a. **사용자 PC의 DNS 리졸버:** `book.example1212.shop`의 IP 주소를 모릅니다.

b. **루트 DNS 서버:** `.shop` 도메인을 관리하는 TLD(Top-Level Domain) 서버의 주소를 알려줍니다.

c. **TLD 서버 (.shop):** `.shop` 도메인을 관리하는 레지스트리 서버로 요청을 전달합니다. 이 서버는 `example1212.shop` 도메인의 정보를 어디서 찾아야 할지 알아야 합니다.

d. **레지스트리 서버:** 이 레지스트리 서버는 **가비아에 등록된 정보**를 확인합니다. 만약 당신이 가비아에 Route 53의 네임 서버를 등록했다면, 레지스트리 서버는 "아, `example1212.shop`의 모든 DNS 정보는 `ns-928.awsdns-52.net.` 같은 AWS 네임 서버들이 가지고 있구나!"라고 알고 해당 AWS 네임 서버들의 IP 주소를 사용자 PC의 DNS 리졸버에게 알려줍니다.

e. **AWS Route 53 네임 서버:** 사용자 PC의 DNS 리졸버는 이제 직접 AWS Route 53의 네임 서버에 `book.example1212.shop`의 IP 주소를 묻습니다.

f. **IP 주소 응답:** Route 53 네임 서버는 당신이 생성한 호스팅 영역 내의 레코드(`book` -> `100.1.1.1`)를 찾아 `100.1.1.1`을 응답해 줍니다.

g. **웹사이트 접속:** 사용자 PC는 `100.1.1.1`로 접속하여 웹페이지를 로드합니다.

요약

  • 가비아 (도메인 등록기관)의 역할: example1212.shop 도메인 소유권을 등록하고, 이 도메인의 DNS 정보를 누가 관리할 것인지 (즉, 네임 서버 주소)를 설정하는 곳입니다.
  • AWS Route 53 (DNS 호스팅 서비스)의 역할: 실제로 example1212.shop 도메인과 그 하위 도메인들의 IP 주소 매핑 정보(A, CNAME 등)를 저장하고 관리하는 곳입니다.

따라서, 가비아에서 도메인을 구매했고 해당 도메인에 대한 호스팅을 AWS에서 하고 싶다면, 반드시 가비아의 도메인 관리 페이지에서 네임 서버 설정을 AWS Route 53에서 제공하는 네임 서버 주소로 변경해야 합니다. 그래야만 전 세계 DNS 시스템이 example1212.shop에 대한 쿼리를 Route 53으로 정확하게 전달할 수 있고, 당신이 Route 53에 설정한 레코드들이 유효하게 작동할 수 있습니다.

이 과정을 "네임 서버 위임" 또는 "DNS 이관"이라고 부릅니다.

김성휘

예약 인스턴스

개념

  1. EC2 인스턴스를 일정 기간 예약해서 할인을 받는 요금 모델
  2. 지속적으로 EC2를 사용하는 워크로드에 매우 유리
  3. 실제 인스턴스를 생성하지는 않고, 해당 인스턴스를 운용할 때 할인 적용권을 미리 사는 것

주요 특징 | :--------------- | :--------------------------| | 계약기간 | 1년 또는 3년 | | 할인율 | 온디맨드 대비 최대 72%까지 절감 가능 | | 지불 옵션 | 전액 선납(All Upfront), 부분 선납(Partial), 무선납(No Upfront) | | 유형 | Standard RI (고정형), Convertible RI (변경 가능형) | | 확장성 | 무제한 | | 적용 대상 | 인스턴스 유형, 리전, OS, 테넌시 등에 따라 할인 적용 |

사용 예시

  1. 항상 돌아가는 웹 서버, API 서버, DB 서버
  2. 사내 VPN, 보안 서버, CI/CD 빌드 서버
  3. 예측 가능한 트래픽 환경 (고정 시간 서비스)

장점 vs 단점 | :------장점------- | :------단점-------| | 최대 72% 비용 절감| 장기 고정 계약 필요 | | 항상 켜진 서버에 적합 | 유휴 리소스에선 손해 | | 높은 예측성 | 사용량 예측 실패 시 낭비|

주의할 점

  1. EC2 인스턴스를 미리 정의된 시간표(스케줄)에만 사용하도록 예약 구매하는 방식
  2. 예를 들어, “매주 월~금 오전 9시부터 오후 5시까지만” 사용하도록 설정할 수 있음
  3. 지속적이진 않지만 정기적인 사용 패턴이 있는 경우에 유리
Amazon CloudFront

개념

  1. 작동방식

CloudFront는 사용자에게 가장 가까운 엣지 로케이션에서 콘텐츠를 제공하여 지연을 줄이고 응답 속도를 빠르게 만듬 최초 요청: 엣지 로케이션에 캐시가 없으면 **원본 서버(S3, EC2, ELB 등)**로부터 콘텐츠를 가져와 사용자에게 전달하고 캐시에 저장 이후 요청: 캐시에 저장된 콘텐츠를 반복해서 제공(캐시 만료 전까지)

  1. 원본 서버

CloudFront는 아래와 같은 리소스를 원본 서버로 설정 가능

  1. Amazon S3 버킷
  2. EC2 인스턴스
  3. ALB / NLB
  4. 외부 서버 (예: Nginx, Apache 등)
  1. 주요 구성 요소 | 구성 요소 | 설명 | | ------------------ | ---------------------------- | | Origin | 콘텐츠의 실제 저장소 (예: S3, EC2) | | Edge Location | 사용자 근처의 콘텐츠 캐싱 서버 | | Distribution | 콘텐츠 전송을 위한 CloudFront의 설정 단위 | | Behavior | 특정 경로나 요청에 대한 캐시/처리 정책 | | TTL (Time to Live) | 캐시된 객체의 유효 시간 |

CloudFront의 장점

장점 설명
빠른 전송 속도 사용자 위치에 가까운 엣지 로케이션에서 콘텐츠 제공
보안 통합 AWS WAF, Shield와 통합하여 DDoS 방어 가능
HTTPS 지원 SSL 인증서(ACM과 통합)로 HTTPS 제공
스마트 캐싱 경로별 TTL 설정, 쿠키/헤더 기반 캐시 정책
비용 최적화 자주 요청되는 콘텐츠는 캐시로 처리되어 원본 부하 감소

CloudFront 설정 흐름 요약

  1. 원본(Origin) 설정 (예: S3 버킷, EC2 등)
  2. 배포(Distribution) 생성
  3. 캐싱 동작(Behavior) 설정 (경로, TTL 등)
  4. 도메인 연결 및 HTTPS 인증서(ACM) 설정
  5. 사용자 요청 → 가장 가까운 엣지 서버 → 캐시 또는 원본 응답

CloudFront와 다른 CDN 비교

항목 CloudFront Cloudflare Akamai 등
AWS 연동성 매우 뛰어남 낮음 낮음
보안 통합 WAF, IAM, ACM 통합 자체 보안 서비스 별도 요금
자동 확장성 자동 엣지 확장 제한적 고정 요금제
요금 사용량 기반 (트래픽 + 요청 수) 무료/유료 혼합 고정 계약

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors