똥선생의 네트워크 기술노트

Route Map과 PBR (Policy-Based Routing) 이란

똥선생 — Sun, 24 Aug 2025 17:10:49 +0900

1. Route Map

Cisco IOS, Juniper 등 라우터에서 제공하는 정책 기반 설정 도구
Access-list와 비슷하게 match 조건과 set 동작으로 이루어짐
라우팅 테이블 처리보다 먼저 이루어짐.

구조:

route-map my_route_map permit 10
    { match statements }
    { match statements }
    { set statements }
route-map my_route_map deny 20
route-map my_route_map permit 30
# match 조건을 따로 작성하지 않을 경우에는 match any가 적용된다.
# route-map의 마지막에는 deny any가 생략 되있다.

match: 어떤 패킷/라우트가 대상인지 정의
set: 매칭되면 어떤 동작을 할지 지정 (next-hop 변경, metric 변경 등) (설정 수정을 하는 작업이다, permit에서만 사용)
match <조건> <조건> <조건> 일 경우 or 연산이고
match <조건>
match <조건>
match <조건> 일 경우 and 연산이다.
match <조건>에 적용되는 것들을 set <동작> 하고 permit 한다.
seq number 순서대로 정책 적용이 된다.
패킷을 필터링 하는것은 하드웨어로 처리가 되지만,
route-map은 네트웍을 필터링 하는 것이기 때문에 소프트웨어 적으로 필터링 된다.
이름이 같으면 다 같은 route map이다.
route-map의 마지막에는 ACL과 같이 deny any가 생략 되있다.

Route Map 사용처 3가지

1.Redistribution route filtering

- route-map을 통해 Route filetering과 modify가 가능하다.

- OSPF ~ BGP간등에 redistribution 할때, 특정네트웍을 filtering 한다던지 modify할 수 있다.

2.PBR (Policy-Based Routing)

- route 경로를 변경 한다던지 Null0로 가게 만들어 드랍 시킬 수 있다.

3.BGP

- BGP는 Bestpath를 선출하기 위한 조건은 다양한 값들을 사용한다.(bandwidth x)

- 업데이트를 주거나 받을때 조건들을 변경해서 주어야 한다.

- 그 때 route map이 자주 사용된다.

2. PBR (Policy-Based Routing)

기본 라우팅은 라우팅 테이블(RIB) 만 참고해서 목적지 IP 기반으로 경로를 결정.
무조건 인바운드 쪽에서 적용해야 한다.
하지만 PBR은 관리자 정책에 따라 목적지 이외의 조건(출발지, 프로토콜, 포트, ACL 등)으로 라우팅 가능.
예시:
- 특정 VLAN에서 오는 트래픽은 인터넷 회선 A로,
- 다른 VLAN은 인터넷 회선 B로 보내는 경우
구현 방식:
- PBR을 적용할 인터페이스에 route-map을 붙여서 동작시킴
- set ip next-hop 또는 set interface 같은 동작으로 경로 지정
route map 안에 있는 ACL은 network 필터링을 하는데, PBR에 사용되는 ACL은 패킷 필터링이다.

관계

PBR은 route-map을 이용해서 구현됨.
즉,
- Route map 자체는 정책 정의 도구
- PBR은 그 도구를 활용해 트래픽 라우팅 정책을 실제로 적용하는 기능

예시

! ACL로 트래픽 정의 (예: 192.168.1.0/24에서 오는 트래픽)
access-list 101 permit ip 192.168.1.0 0.0.0.255 any

! route-map 작성
route-map PBR-TEST permit 10
 match ip address 101
 set ip next-hop 10.10.10.1   ! 특정 게이트웨이로 보냄

! 인터페이스에 적용
interface GigabitEthernet0/0
 ip policy route-map PBR-TEST

이렇게 하면 192.168.1.0/24 대역에서 나오는 트래픽은
라우팅 테이블을 보지 않고 무조건 10.10.10.1로 전달돼요.

이중 회선(dual ISP) 환경

기업에서 인터넷 회선 두 개(예: KT, SKB) 를 사용한다고 가정
일반적으로 라우팅 테이블은 라우팅 프로토콜 or Static 기반으로 하나의 기본 경로(default route) 만 선택
하지만 PBR을 쓰면:
- 일반 사용자 트래픽 → KT 회선
- 서버 트래픽(예: DMZ 웹서버) → SKB 회선
- 이렇게 출발지 네트워크별로 다른 ISP로 보낼 수 있음

PBR을 지양해야 하는 경우

라우팅 프로토콜로 해결 가능한 경우
- OSPF area, BGP local-pref/AS-path-prepend, metric 조정으로 가능하면 그게 더 안정적
- Control plane에서 조정하는 게 운영/확장성에 유리
규모가 큰 환경(대규모 ISP/데이터센터)
- 수백~수천 개 정책을 PBR로 처리하면 성능 저하 + 관리 복잡성 폭발
- 일부 장비는 PBR이 FIB에 하드웨어 처리 안 되고 소프트웨어 처리(CEF bypass) → CPU 부하↑
장애 분석 시
- 라우팅 테이블 보고 정상인데, 실제 트래픽이 안 가는 경우 → 알고 보니 PBR 때문에 경로가 바뀌는 경우가 많음
- 즉, 트러블슈팅 난이도 상승

IPsec VPN 알아보기#2 주요 보안 기능과 동작 흐름

똥선생 — Fri, 22 Aug 2025 15:21:26 +0900

IPSec(IP Security)에서는 두 가지 주요 보안 기능이 적용돼요:

무결성/인증 (데이터가 변조되지 않았는지, 발신자가 맞는지 확인)
암호화 (데이터를 제3자가 읽지 못하게 보호)

여기에 사용되는 암호화 방식은 크게 세 가지로 나눌 수 있습니다:

1. 대칭키 암호화 (Confidentiality - 기밀성)

데이터를 암호화할 때 속도가 빠른 블록 암호/스트림 암호를 주로 사용합니다.

암호화와 복호화에 사용되는 키가 같습니다.

DES (과거 사용, 현재는 보안에 취약)
3DES (DES를 3번 적용, 오래됐지만 일부 레거시 환경에서 사용)
AES (가장 많이 사용됨, 128/192/256bit 키 길이 지원 → IPSec 표준 암호화 방식)
ChaCha20 (일부 환경에서 AES 대체로 사용)

2. 해시 기반 무결성 검증 (Integrity & Authentication)

데이터 변조 여부를 확인하기 위해 HMAC(Hash-based Message Authentication Code)를 사용합니다.

본래 해시라는 것은 대용량 데이터를 다운받고 무결성을 체크하는 용도로 사용됨.

데이터에다 뒤에 키값까지 붙여서 해시를 하는 개념을 만듬.

키값을 알아야 무결성이 정상체크 되기 때문에 변복조에 안전하게됨.

무결성과 패킷에 대한 인증이 같이 이루어짐.

HMAC-MD5 (128비트, 현재는 보안상 권장 X)
HMAC-SHA1 (160비트, 점점 사용 줄어듦)
HMAC-SHA2 (SHA-256, SHA-384, SHA-512) → 현재 가장 권장되는 방식

3. 키 교환 및 인증 (Key Exchange & Authentication)

세션 키를 안전하게 교환하기 위해 비대칭키 암호화/디피-헬만 키 교환이 쓰입니다.

1.한쪽에서 공개키, 사설키를 생성하고 공개키를 다른쪽에 제공합니다.

2.위 그림,사설키로 데이터를 암호화하여 공개키로 복호화 하는 방식은 주로 인증을 위해 사용합니다.

(해커가 공개키를 제공 받아 데이터를 복호화 할 위험이 있기 때문)

3.실제 데이터 전송 암호화를 위해서는 공개키로 데이터를 암호화 하고 사설키로 복호화 합니다.

Diffie-Hellman (DH group 1~31 등급) → 키 교환용
RSA / ECDSA → 인증서 기반 인증
IKEv2에서 ECDH(Elliptic Curve Diffie-Hellman) 많이 사용 (보안성과 효율성↑)

정리하면:

무결성 검증 → HMAC-SHA2 (과거: HMAC-MD5, HMAC-SHA1)
데이터 암호화 → AES, 3DES (과거: DES)
키 교환/인증 → Diffie-Hellman, RSA, ECDH

IPSec 동작 흐름

IKE(Internet Key Exchange) 는 IPSec에서 암호화/인증을 하기 전에, 두 장비가 서로 약속(협상)하고 세션 키를 안전하게 교환하는 프로토콜이에요.
쉽게 말하면 “IPSec 통신을 시작하기 전에 보안 규칙을 정하고 열쇠를 맞추는 절차” 라고 보면 돼요.

나머지는 기존에 학습하였고, IKE 2단계의 프로토콜에 대해 알아보자.

두 가지 프로토콜

IPSec은 또 두가지 보안 프로토콜을 제공하는데, 인증에 대해서만 검사하는 인증헤더 프로토콜(AH: Authentication Header Protocol)과 페이로드 전체를 보호하여 기밀성을 제공하는 보안 페이로드 캡슐화(ESP: Encapsulating Security Payload)가 그것들입니다.

AH(Authentication Header)

말그대로 헤더 인증. 인증과 무결성을 할 수 있는 기술이다.

발신지 호스트를 인증하고 IP패킷의 무결성을 보장합니다. 인증을 위해서 해쉬함수와 대칭키가 사용되어 Message Digest를 생성하고 헤더에 삽입합니다. AH는 인증과 무결성을 보장하지만 비밀은 보장해주지 않습니다.

때문에 보통 ESP를 추가하여 암호화까지 이루어지게 합니다.

Next Header : IPSec 다음에 오는 페이로드의 헤더를 말합니다. TCP인지 UDP인지 또는 ICMP인지 의미합니다.

Payload Length : 인증헤더의 길이를 말하며 4바이트 배수가 됩니다.

Security Parameter Index : 32비트 보안 매개변수 색인(SPI) 필드는 Security Association에 대한 식별자입니다.

Sequence Number : 32비트 순서번호인데 이것은 replay attack을 방지합니다.

Authentication Data: 헤더를 포함하여 전체 페킷에 대한 데이터를 인증 데이터로 만드는데, 이때 IP 헤더의 변경될 수 있는 데이터는 제외하고 인증데이터를 만들게 됩니다. 예를 들어 TTL같은 변경이 될 수 있는 데이터는 인증 데이터를 만들때 포함하지 않습니다. 만들면 AH의 Authentication Data필드에 삽입됩니다.

ESP(Encapsulating Security Payload)

AH가 지원하는 인증+무결성에, 암호화까지 할 수 있는 기술이다.

ESP 헤더의 각각 필드는 32비트입니다.

눈에 익은 필드들이 몇개 보이지요? 대부분은 AH의 필드와 유사합니다. 또 payload를 암호화하고 있네요.

Authentication Data : AH와는 다르게 인증데이터가 IP헤더를 포함하지 않습니다. ESP헤더까지만 인증데이터로 만들고 ESP Trailer에 붙이게 됩니다.

ESP가 인증+무결성+암호화까지 한번에 지원하는 프로토콜이지만, AH는 ESP보다 나중에 나온 프로토콜인 만큼 필요성에 의해 만들어 졌습니다.

정리해보면,

AH는 무결성과 인증을 지원하고 추가 IP헤더까지 포함 시킬 수 있습니다.

암호화는 ESP를 이용하여 ESP+AH 구조로 사용하게 됩니다.

ESP는 무결성+인증+암호화까지 하게되고 추가 IP헤더는 포함 시킬 수 없습니다.

AH와 ESP의 대한 차이는 다음의 표로 간략하게 정리하였습니다.

Services	AH	ESP
Access Control	O	O
Message Authentication (Message Integrity)	O	O
Confidentiality	X	O
Replay Attack Protection	O	O
Entity Authentication (Data Source Authentication)	O	O

참고블로그

https://reakwon.tistory.com/108

IPsec VPN 알아보기#1 두가지 모드

똥선생 — Tue, 19 Aug 2025 23:22:30 +0900

IPsec VPN 알아보기#1

VPN = 인터넷 위에 비밀 통로
- 원래 인터넷은 모든 데이터가 그냥 흘러다니는 길과 같아요.
- VPN은 그 위에 내 것만 지나가는 비밀 터널을 만드는 거예요.
IPsec = 터널 안에서 보안 지켜주는 약속
- 두 지점(회사 ↔ 지사, 집 ↔ 회사)이 통신할 때
- 서로 "우리끼리만 알아볼 수 있게 암호 걸자" 하고 약속하는 게 IPsec이에요.
- 그래서 누가 중간에서 훔쳐봐도 못 알아봐요.
- IP계층(네트워크 계층)을 안전하게 보호하기 위해서 IPSec이라는 보호 기법을 사용합니다.
- TLS와 같은 안전한 통신 기법만 있으면 되지, 왜 굳이 IPSec이 필요하느냐에 대한 물음을 갖을 수 있습니다. TLS는 TCP 프로토콜만을 보호합니다.
- 때문에 UDP까지 보호를 해주기 위해서는 더 낮은 계층에서 보호 해주는 것이 효과적 일 겁니다.
동작 방식
- 먼저 서로 인사(IKE) → 암호 방식 정하기
- "너 진짜 우리 회사 맞아?" (인증) → PSK(비밀번호)나 인증서 사용
- 약속 끝나면 데이터를 보낼 때마다 포장지(라벨)를 씌워서 암호화함
- 받는 쪽은 같은 열쇠로 풀어서 원래 데이터 확인
두가지 모드
- IPSec에는 두 가지 모드가 있는데, IP의 내용(payload)만을 보호하느냐, 아니면 헤더까지 모두 보호하느냐에 따라서 전자는 전송 모드(Transport Mode), 후자는 터널 모드(Tunnel Model)라고 합니다.
- end-to-end 끼리 IPSec통신하려고 한다 -> 전송 모드
- 일정 구간에서만 IPSec통신하려고 한다 -> 터널 모드
먼저, end-to-end 끼리 IPSec통신하는 전송모드는 전송 계층와 네트워크 계층 사이에 전달되는 payload를 보호합니다. 중간에 IPSec 계층이 있기 때문에 IPSec헤더가 붙고, 이후에 네트워크 계층에서는 이것이 모두 상위층에서 보낸 데이터(payload)로 취급이 되므로 IP 헤더가 붙고 아래 계층으로 전달되지요.

전송모드는 host-to-host( end-to-end)간 데이터 보호가 필요할때 사용이 됩니다. 아래는 전송모드의 데이터 전송 흐름을 보여줍니다.왼쪽 컴퓨터(host)는 IPSec을 적용하여 데이터를 보냅니다. 네트워크를 통해서 오른쪽 컴퓨터로 데이터가 도착합니다. 자, 이 사이에서 다른 사람이 데이터를 가져가도 IPSec에 대한 보호가 이루어져있으므로 볼 수 없고 라우터를 거쳐 두 당사자만 데이터를 보호할 수 있지요. 그래서 종단 간의 보호(End-To-End Protection, E2EP)가 이루어 질 수 있습니다.

터널 모드(Tunnel Mode)

아래는 그 흐름을 보여주는데, 전송모드와는 다르게 호스트 A는 별다른 IPSec의 조취를 취하지 않습니다. 하지만 Router A에서 IPSec을 적용하고 새로운 IP 헤더를 추가합니다. 이 헤더에는 목적지 라우터의 주소가 있어서 Router B로 보냅니다. Router B는 이후에 적절한 조취를 취하고 새로운 IP헤더와 IPSec헤더를 제거한 후 Host B에게 전달합니다. 마치 RouterA, RouterB가 터널 역할을 하는 것 같네요.

한마디로 정리하면:
IPsec VPN은 인터넷 위에 비밀 터널을 만들고, 그 안에 들어가는 데이터를 전부 잠가서 안전하게 전달하는 기술이에요.

참고 블로그

https://reakwon.tistory.com/108

이더넷케이블로 데이터와 전원까지 공급 PoE(Power over Ethernet)

똥선생 — Sat, 16 Aug 2025 21:06:55 +0900

PoE는 VoIP(Voice over Internet Phone)의 전원 공급 문제를 해결하기 위해 처음 발명되었습니다. 기존 전화기는 음성 통화를 전송하는 구리선에서 직접 전원을 공급받을 수 있습니다. 그러나 점점 인기를 얻고 있는 VoIP는 기존 회선에 연결되지 않고 대신에 회사의 근거리 통신망(LAN)인 이더넷 케이블을 통해 전화를 겁니다. 이더넷 케이블은 전원을 공급하지 않으므로 VoIP는 어댑터를 통해 주 전원 공급 장치에 연결되어야 합니다. 건물이 정전되면 전화가 중단되기 때문에 이는 종합적으로 충분하지 않습니다.

1. PoE(Power over Ethernet)란?

데이터와 전원을 하나의 이더넷 케이블로 동시에 전송하는 기술
즉, 전원 어댑터 없이 네트워크 장비(IP 카메라, 무선 AP, VoIP 전화기 등)를 동작시킬 수 있음

2. 동작 원리

일반 UTP 케이블(보통 Cat5e 이상)의 4쌍(8가닥) 중 일부 또는 전체를 사용해 전력을 공급
데이터와 전력은 서로 간섭 없이 전송되도록 설계

PoE기능을 지원하지 않는 장비 쪽에는 PoE Injector를 사용합니다.

3. 전원 전송 방식

IEEE 표준에서 2가지 방식 사용:

Alternative A → 데이터 전송에 쓰이는 선(1, 2, 3, 6번 핀)으로 전력도 함께 전달
Alternative B → 데이터에 사용하지 않는 선(4, 5, 7, 8번 핀)으로 전력 전달
(기가비트 이더넷에서는 모든 쌍을 데이터에 사용하므로, 전력도 함께 전송 가능)

4. PoE 장점

전원 콘센트가 없는 장소에서도 장비 설치 가능
케이블 수 줄어듦 → 설치 비용 절감
중앙에서 전원 관리 가능 (PoE 스위치로 원격 On/Off 제어

5. PoE 주의사항

케이블 품질 중요 → 최소 Cat5e 권장
장비의 PoE 규격 호환성 확인 필요 (예: PoE+ 장비는 일반 PoE에서 전력 부족할 수 있음)
고전력 장비(PTZ 카메라, LED 조명 등)는 PoE++ 필요
부팅시에만 더 높은 W를 요구하는 장비가 있을 수 있음.

MPLS (Multiprotocol Label Switching)와 MPLS-VPN

똥선생 — Sat, 16 Aug 2025 12:25:46 +0900

MPLS (Multiprotocol Label Switching)

1. 개념

MPLS는 전통적인 IP 라우팅처럼 패킷의 IP 헤더만 보고 경로를 결정하지 않고, 라벨(label)이라는 짧은 식별자를 붙여서 고속으로 패킷을 전달하는 기술입니다.
OSI 3계층(IP)과 2계층(Ethernet, Frame Relay, ATM 등) 사이에 존재하는 “2.5 계층” 기술로 불립니다.

2. 동작 방식

패킷이 네트워크에 들어올 때, Ingress 라우터가 패킷에 라벨(Label)을 붙입니다.
중간 라우터들은 IP 주소를 다시 조회하지 않고, 라벨 값만 보고 전송(next hop) 합니다.
마지막 Egress 라우터가 라벨을 제거하고, 원래 IP 패킷을 목적지로 전달합니다.

3. 특징

고속 패킷 전달 (라우팅 테이블 탐색 대신 라벨 스위칭)
트래픽 엔지니어링 (특정 경로로 유도 가능 → QoS 향상)
다양한 프로토콜 지원 (IP, Ethernet, ATM 등 → “Multiprotocol”)

MPLS-VPN

1. 개념

MPLS 위에서 동작하는 가상사설망(VPN) 기술입니다.
기업 지사나 데이터센터가 물리적으로 떨어져 있어도, MPLS 네트워크를 통해 마치 하나의 사설망처럼 안전하게 연결할 수 있습니다.
흔히 통신사(ISP)가 제공하는 서비스형 VPN이 MPLS-VPN입니다.

2. 주요 방식

L3 MPLS-VPN (가장 일반적)
- 서비스 제공자의 라우터가 고객의 라우팅 정보를 저장하고 관리 (VRF: Virtual Routing and Forwarding 사용)
- 서로 다른 고객 간 트래픽이 논리적으로 분리됨.
L2 MPLS-VPN
- MPLS를 이용해 고객의 Layer2 프레임을 그대로 전달 (예: VPLS, VPWS)
- 고객이 직접 라우팅 관리.

3. 동작 구조 (L3 VPN 기준)

각 고객은 PE(Provider Edge Router)에 연결.
PE는 고객별로 VRF 테이블을 따로 유지 → 고객 네트워크가 논리적으로 격리됨.
PE 간에는 MPLS 라벨을 사용해 패킷을 전달 → 고객 입장에서는 투명하게 연결된 것처럼 보임.

요약

MPLS: 패킷에 라벨을 붙여서 빠르고 효율적으로 전달하는 네트워크 전송 기술.
MPLS-VPN: MPLS 네트워크를 기반으로 여러 고객(기업)의 VPN을 안전하게 제공하는 서비스.

VRF란?

VRF는 라우터 안에서 라우팅 테이블을 가상적으로 분리하는 기술입니다.
즉, 하나의 물리적인 라우터 장비에서 여러 개의 독립된 라우팅 환경을 동시에 운영할 수 있게 해줍니다.

핵심 개념

라우팅 테이블 분리
- 일반적으로 라우터는 단 하나의 라우팅 테이블을 갖습니다.
- VRF를 사용하면 여러 개의 라우팅 테이블을 생성하여 서로 다른 네트워크가 독립적으로 동작합니다.
주소 공간 중복 가능
- VRF 환경에서는 서로 다른 고객이나 서비스가 동일한 IP 주소 대역을 사용해도 충돌이 없습니다.
- 예:
  - 고객 A VRF: 10.1.1.0/24
  - 고객 B VRF: 10.1.1.0/24
  - 같은 라우터에서 문제 없이 공존 가능.

VPN 구현 기반 기술
- MPLS-VPN 같은 서비스에서 VRF가 핵심 역할을 합니다.
- 서비스 프로바이더는 고객별 VRF를 생성해서, 각 고객이 자기 전용 라우터를 쓰는 것처럼 보이게 합니다.

비유

VRF를 쉽게 이해하려면 아파트 우편함을 생각하면 됩니다.

아파트(라우터)는 하나지만, 세대별로 우편함(VRF)이 따로 있어서 서로의 편지(라우팅 정보)가 섞이지 않습니다.

사용 사례

서비스 프로바이더: 고객별 네트워크 분리 (MPLS VPN)
엔터프라이즈: 내부 부서/서비스별 네트워크 격리 (예: HR망, Finance망)
보안 목적: 특정 트래픽을 별도 라우팅 처리

정리해드리면 MPLS VPN과 VRF는 밀접하게 연결되어 있지만, 같은 개념은 아니고 역할이 달라요.

1. VRF (Virtual Routing and Forwarding)

라우터 안에서 라우팅 테이블을 가상으로 분리하는 기술.
즉, 하나의 라우터 장비에 여러 개의 독립된 라우팅 테이블을 두는 것.
고객 A, 고객 B가 같은 라우터를 사용하더라도 서로의 경로 정보를 보지 못하게 격리 가능.

2. MPLS VPN (주로 L3VPN)

서비스 프로바이더(통신사)가 MPLS 라벨 스위칭을 이용해 고객의 사설망을 서로 연결해주는 서비스.
이때 고객별로 트래픽과 경로를 분리하기 위해 PE 라우터(Provider Edge) 에서 VRF를 설정함.
즉, 고객 A → VRF A, 고객 B → VRF B 이런 식으로 매핑됨.
PE ↔ PE 간에는 MPLS 라벨 스위칭과 MP-BGP (Multiprotocol BGP) 로 VRF에 있는 라우팅 정보가 전파됨.

3. 관계를 비유하자면

VRF = “독립된 라우팅 테이블(가상 공간)”
MPLS VPN = “이 VRF들을 MPLS 백본망 위에서 서로 연결해주는 서비스”

MPLS L3VPN 동작 흐름 (CE–PE–P–PE–CE)

1. CE → PE (고객 라우터 → 서비스 프로바이더 엣지 라우터)

고객 CE 라우터가 자신의 프라이빗 라우팅 정보(예: 10.1.0.0/16)를 PE 라우터에 광고함.
PE 라우터는 이 경로를 받아서 해당 고객 전용 VRF 테이블에 저장.
- 고객 A → VRF-A
- 고객 B → VRF-B
따라서 고객 A와 고객 B의 경로는 서로 완전히 분리됨.

2. PE → P → PE (서비스 프로바이더 망 내부 전달)

PE 라우터는 VRF에서 받은 고객 라우팅 정보를 MP-BGP를 통해 다른 PE 라우터와 공유.
이때 경로 정보는 MPLS 라벨이 두 겹으로 붙어서 전송됨.
- 외부 라벨(Transport Label) : P 라우터들이 목적지 PE까지 트래픽을 전달하는데 사용.
- 내부 라벨(VPN Label) : 목적지 PE 라우터가 어느 VRF로 패킷을 전달해야 할지 식별하는 데 사용.
중간의 P 라우터들은 단순히 MPLS 라벨 스위칭만 수행하고, 고객 경로는 전혀 모름.

3. PE → CE (다른 지역 고객 라우터로 전달)

목적지 PE 라우터는 두 겹의 MPLS 라벨을 보고,
- 외부 라벨은 벗겨내고
- 내부 라벨로 어떤 VRF에 전달할지 결정.
해당 VRF에서 고객의 라우팅 테이블을 확인하고 CE 라우터로 패킷을 전달.

핵심 정리

VRF : PE 라우터에서 고객별 경로를 분리하는 기술.
MPLS VPN : 이 VRF들을 MPLS 라벨과 MP-BGP를 이용해 서비스 프로바이더 망 안에서 연결해주는 서비스.
즉, MPLS VPN이 "VRF들을 서로 연결해주는 방식"이라고 보면 됨.

P 라우터의 역할

P 라우터는 고객 경로를 보지 않고, Transport 라벨만 보고 동작.
각 P 라우터에는 LFIB(Label Forwarding Information Base) 라는 라벨 전환 테이블이 있음.
- 들어온 라벨(= Incoming Label)을 보고
- 바꿔야 할 라벨(= Outgoing Label)로 교체한 뒤
- 다음 홉(Next Hop)으로 포워딩.

P 라우터 LFIB:
Incoming Label 100 → Outgoing Label 200 (다음 홉: P2)
Incoming Label 200 → Outgoing Label 300 (다음 홉: PE2)

P 라우터는 고객 라우팅 정보(IP Prefix)를 모른다.
오직 라벨 전환(Lookup & Swap) 만 수행한다.
덕분에 프로바이더 코어망이 단순해지고, 확장성이 커진다.
MPLS에서 P 라우터는 IP 목적지 주소 자체는 모르지만,
라벨이 어떤 목적지 PE 라우터로 가야 하는지에 대한 정보는 알고 있어요.

즉, MPLS 코어(P 라우터)는 일종의 **“택배 물류센터”**처럼 동작한다고 보면 돼요.
택배 물류센터는 “집 주소”를 모르고, 그냥 “택배 바코드(라벨)”만 보고 다음 허브로 넘기는 거랑 똑같습니다

매트로 이더넷(Metro Ethernet)이란?

똥선생 — Sat, 16 Aug 2025 00:58:02 +0900

기업의 네트워크 환경이 점점 복잡해지면서 빠르고 안정적인 데이터 전송이 필수적이 되었습니다. 그중 매트로 이더넷(Metro Ethernet)은 도심 지역이나 대규모 캠퍼스 네트워크에서 많이 활용되는 솔루션으로 주목받고 있습니다.

메트로 이더넷은 MAN(Metropolitan Area Network)을 통해 점대점(point-to-point) 또는 멀티포인트 연결 서비스를 제공하는 이더넷 전송 네트워크입니다. 이더넷은 LAN 기술로 시작되었지만 저속 WAN 기술을 대체하게 되었습니다.

1. 매트로 이더넷이란?

매트로 이더넷(Metro Ethernet, MetroE)은 도시 규모(Metropolitan Area)에 걸친 이더넷 기반 통신망을 의미합니다.
즉, 기업이나 기관이 사용하는 LAN(Local Area Network)을 도심 내 여러 지점과 연결해 MAN(Metropolitan Area Network)처럼 확장한 형태라고 이해하면 쉽습니다.

기존의 WAN(Wide Area Network) 기술인 MPLS, 프레임 릴레이, ATM과 달리, 매트로 이더넷은 이더넷 기술을 기반으로 하기 때문에 설치가 간단하고 비용 효율적입니다.

출처https://www.juniper.net/kr/ko/research-topics/what-is-metro-ethernet.html

2. 매트로 이더넷의 특징

이더넷 기반: LAN에서 사용하던 친숙한 이더넷 기술을 그대로 사용
높은 대역폭: 10Mbps~100Gbps까지 지원 가능
확장성 용이: 새로운 지점 연결 시 구조 변경 없이 쉽게 확장 가능
비용 효율적: 기존 WAN 대비 설치 및 유지 비용 절감
QoS 지원: 음성, 영상, 데이터 트래픽을 구분하여 품질 보장 가능

3. 매트로 이더넷의 구성

매트로 이더넷은 크게 사용자 구간과 서비스 제공자 구간으로 나눌 수 있습니다.

UNI(User Network Interface)
- 고객 단말 장치와 연결되는 인터페이스
- 예: 기업 사무실 LAN → 매트로 이더넷 포트
ENNI(External Network-to-Network Interface)
- 서비스 제공자 망 간 연결 지점
- 예: ISP 간 트래픽 교환
Metro Core
- 도심 내 고속 백본 네트워크
- 대규모 데이터 전송과 안정성을 담당

4. 매트로 이더넷의 서비스 유형

E-Line (Point-to-Point)	두 지점을 직접 연결, 데이터 전송 전용
E-LAN (Multipoint-to-Multipoint)	여러 지점 간 상호 연결 가능, 가상 LAN 환경 제공
E-Tree (Rooted Multipoint)	중앙 서버와 여러 지점 간 연결, 트래픽 단방향 흐름 관리

5. 매트로 이더넷의 장점

간편한 설치: LAN 기술 그대로 사용 가능
유연한 확장: 새로운 지점을 추가해도 기존 네트워크 구조 변경 불필요
높은 성능: 대역폭을 자유롭게 할당 가능
비용 절감: 전용 회선이나 복잡한 WAN 장비 필요 없음
QoS 지원: 음성, 영상 등 트래픽 우선 순위 조정 가능

6. 활용 사례

기업 지점 연결
- 서울 본사와 전국 지사를 고속 LAN처럼 연결
캠퍼스 네트워크
- 대학, 병원 등 대규모 캠퍼스 내부와 외부 지점 연결
데이터 센터 간 연결
- 여러 데이터 센터를 안정적이고 빠르게 연결
클라우드 서비스 연결
- 온프레미스와 클라우드 간 고속 데이터 전송

7. Q-in-Q란 무엇인가?

Q-in-Q는 802.1Q 터널링(VLAN 태깅 중첩) 기술을 의미합니다.
기존 VLAN 태그(802.1Q)는 한 번만 붙여서 LAN 트래픽을 구분할 수 있지만, Q-in-Q는 외부 VLAN 태그(S-VLAN, Service VLAN) 위에 내부 VLAN 태그(C-VLAN, Customer VLAN)를 추가로 붙여 여러 계층의 VLAN을 구분할 수 있습니다.

즉, 고객 트래픽을 그대로 유지하면서 서비스 제공자 네트워크 안에서 별도의 VLAN 영역으로 감싸서 전송하는 방식입니다.

────────────────────────

매트로 이더넷과 Q-in-Q의 연관성

매트로 이더넷에서는 여러 고객이 하나의 도심 통신망을 공유하게 됩니다.
이때 각 고객의 LAN 트래픽이 겹치지 않도록 구분해야 하는데, Q-in-Q가 핵심 역할을 합니다.

고객별 VLAN 유지
- 고객 A, 고객 B 각각의 VLAN을 그대로 유지하면서 매트로 네트워크를 통해 전송
서비스 제공자 VLAN 추가
- 고객 트래픽 위에 S-VLAN 태그를 추가해 서비스 제공자망에서 식별 가능
대규모 확장 가능
- 일반 VLAN 4096개 제한을 넘어서도 여러 계층의 태깅으로 수만 개 VLAN 처리 가능

Q-in-Q 동작 예시

고객 LAN: C-VLAN 10, 20, 30
서비스 제공자망: S-VLAN 100, 200

매트로 이더넷 스위치가 들어오는 트래픽을 처리할 때,

고객 VLAN 10 → S-VLAN 100 안에 태깅
고객 VLAN 20 → S-VLAN 200 안에 태깅
고객 VLAN 30 → S-VLAN 200 안에 태깅

이렇게 하면 고객별 VLAN 충돌 없이 통합 매트로 네트워크를 운용할 수 있습니다.

────────────────────────

Q-in-Q 장점

고객 트래픽 분리 및 보안 강화
VLAN 수 제한 문제 해결
매트로 이더넷에서 여러 고객 트래픽 공유 가능
서비스 제공자망 관리 단순화

────────────────────────

정리하면, 매트로 이더넷이 여러 고객을 한 네트워크로 연결하는 통신망이라면, Q-in-Q는 그 안에서 고객 트래픽을 안전하고 효율적으로 분리하는 기술입니다.

와이어샤크를 통한 프로토콜 분석 - HTTP 요청-응답

똥선생 — Fri, 15 Aug 2025 19:25:58 +0900

IT 개발자나 네트워크 엔지니어에게 필요한 와이어샤크를 실습하면서 배워보려고 한다.

여러 매체를 통해 배웠고, 그 중 잘되있다고 생각하는 곳은 한빛미디어 네트워크 기초 강의이다.

https://www.youtube.com/watch?v=I_aCbbzORms

유튜브 링크

https://github.com/kangtegong/self-learning-cs2

실습 자료

한빛미디어의 강의를 바탕으로 배운것들을 정리해본다.

1. HTTP 요청과 응답의 개념

HTTP(HyperText Transfer Protocol)는 웹에서 **클라이언트(브라우저)**와 서버가 정보를 주고받을 때 쓰는 약속(프로토콜)입니다.

1.1 HTTP 요청(Request)

클라이언트 → 서버로 보내는 메시지로,
"서버야, 이 정보를 좀 줘" 또는 "이 작업 좀 해줘"라고 요청하는 것.

구성 요소:

요청 라인(Request Line)
- 예: GET /index.html HTTP/1.1
  - GET → 요청 메서드
  - /index.html → 요청 대상 경로
  - HTTP/1.1 → HTTP 버전
헤더(Header)
- 클라이언트 정보, 요청 조건, 인증 토큰, 데이터 형식 등을 포함
  - 예: User-Agent: Chrome/119, Accept: text/html
본문(Body) (필요할 때만)
- 주로 POST, PUT 요청에서 서버로 데이터를 전송할 때 사용
  - 예: JSON, 폼 데이터 등

1.2 HTTP 응답(Response)

서버 → 클라이언트로 보내는 메시지로,
"네가 요청한 자료 여기 있어" 또는 "요청이 실패했어"를 알려주는 것.

구성 요소:

상태 라인(Status Line)
- 예: HTTP/1.1 200 OK
  - 200 → 상태 코드 (성공, 실패 등 표시)
  - OK → 상태 메시지
헤더(Header)
- 서버 정보, 콘텐츠 형식, 캐시 정보 등을 포함
  - 예: Content-Type: text/html; charset=UTF-8
본문(Body)
- 실제 데이터(HTML, JSON, 이미지 등)

http-request-response.pcapng

1번 패킷의 HTTP 메시지

요청을 보낸 호스트는 info.cern.ch

요청을 보낸 경로는 /

요청에 사용된 HTTP 메서드는 GET이라는 것을 알 수 있다.

[참고]

\r과 \n
• \r은 캐리지 리턴(Carriage Return) - 커서를 현재 행의 앞으로 이동
• \n은 라인 피드(Line Feed) - 다음 행으로 커서를 이동
• \r과 \n을 같이 사용
• 커서의 위치가 행의 앞으로 이동한 뒤 다음 행으로 이동하게 되며, 행바꿈(줄바꿈)을 표현

2번 패킷을 보자

2번 패킷은 메시지 본문이 포함되어 있다.

Content-Type은 html이다.

3번 패킷은 웹사이트 안에서 Browse the first website라는 링크를 클릭했을 때의 패킷.

- 요청을 보낸 호스트는 info.cern.ch이고, 요청을 보낸 경로는 /hypertext/WWW/TheProject.html
- 요청에 사용된 HTTP 메서드는 GET
- Referer 헤더를 통해 이전에 요청을 보낸 자원이 http://info.cern.ch확인

3번 패킷에 대한 응답 메시지는 5번 패킷이다.

2번 패킷과 마찬가지로 HTML 문서를 응답 받게 된다.

[k8s] 데브옵스 한방정리

똥선생 — Fri, 15 Aug 2025 19:19:18 +0900

데브옵스를 구성하는 오픈소스들

DevOps가 개발에서 운영까지 원할한 흐름을 만드는 건데, 중간에 가장 중요한 역할을 하는게 CI/CD.

CI는 통합된 소스를 가지고 빌드/테스트를 자동화 시키는 기능을 만드는 거고, CD는 배포를 자동화 시키는 기능

그래서 결국 개발을 해서 커밋을 하는 순간, 운영 환경에 App이 자동으로 배포가 되는 파이프라인이 만들어 지는데, 세부적으로 나누면 위 그림처럼 8가지 단계가 있습니다.

계획/개발, 빌드/테스트, 릴리즈/배포, 그리고 운영/모니터링 인데, 이걸 각 단계를 대표적으로 사용하는 오픈소스를 가지고 얘기를 해보겠습니다.

[계획] 단계부터 시작합니다.

강사님이 개발할 당시에는 redmine을 많이 썻다고 하는데, 지금은 Jira나 notion을 많이 사용.

기능은 비슷한데, UI가 요즘 스타일로 많이 세련되 졌고요.

개발 일정을 공유하거나 이슈 사항들을 기록해야 되기 때문에 이런 툴을 사용.

협업은 서로 메신저를 통해서 개발에 관련된 대화를 하는 걸 말하는데, 사실 카톡이나 사내 메신저를 써도 되는 부분이긴 하지만 그래도 슬렉을 쓰는 가장 큰 이유가 하나 있습니다. (마지막에)

다음으로 [개발]인데

인텔리제이나, OpenJDK, 그리고 Spring Boot는 이전에 내용이 있었고, 밑에 JUnit은 테스트 코드를 작성할 때 필요해요.

보통 개발할때 if문 3~4개에 for문도 여러개 섞어서 복잡한 로직을 만들어 내죠. 이게 처음 만들 때는 집중해서 만들기 때문에 로직이 이해 되는데, 하루만 지나도 이 로직이 이해가 안되기 시작해요. 아무래 내가 짠 코드라도 다시 이해하는게 힘들어 지는데, 이럴때는 차라리 입력값을 넣어서 돌려보고, 결과값을 보는 게 로직을 이해하는 데 쉽거든요.

그래서 바로 이런 테스트 코드를 만들어 놓는 게 좋고, 혹시라도 다른 사람이 이 로직을 수정하더라도, 테스트 코드를 돌려봐서 기대했던 값이 잘 나오면 안심을 할 수가 있죠. 그래서 코드를 개발할 때 조금만 고생해서 이렇게 테스트 코드도 같이 만들어 놓습니다.

다음으로 코드 분석 이라고 해서 FindBug나 PMD는 내가 짠 코드 패턴에 혹시 모를 버그가 있는지를 체크해줘요. 그래서 잘못된 로직을 짜지 않도록 도와주는데, 이런거 뿐만아니라 개발자간에 미리 코딩 스타일을 정해 놓거나, 개발 편의를 위해서 사용하는 툴 들은 엄청 많습니다.

다음으로 [빌드]를 볼께요.

빌드 대상은 소스와 컨테이너고 Gradle과 도커가 사용됩니다. 소스 빌드로 현재 Maven보단 Gradle을 많이 쓰지만 저장소 자체는 메이븐 저장소에서 라이브러리를 가져 오는 거고요.

이제 다음으로 [테스트] 예요.

테스트를 해야되는 요소에는 크게 3가지가 있는데, 기능이랑 성능 그리고 커버리지예요.

각각 Junit, Jmeter, JACOCO라는 툴 들이 쓰이고. 각자 개발단계에서 테스트 코드를 만들고 실행을 해봤더라도 코드들이 병합되고 나서 또 다른 결과가 나올 수 있기 때문에, 빌드 단계에서 이 JUnit을 실행시켜서 자동으로 테스트를 한번 더 돌려 보는 거예요.

그래서 위치는 이렇게 빌드에 연결되서 테스트가 같이 실행되는 거고, 테스트 이후에 Jacoco라는 툴을 돌리면 이 테스트를 돌렸을 때 사용된 로직들이, App 전체에서 어느정도 범위를 테스트 해본 건지, 커버리지를 결과를 알려줍니다.

그래서 내가 돌려본 테스트 케이스들이 전체 로직에서 많은 부분을 차지할 수록, 이 App에 대한 신뢰도가 높다고 판단을 해요.

그리고 JMeter는 성능 테스트를 하는 툴 인데, 이건 자동화 기능은 아니고, 여기 개발환경이나 검증환경을 대상으로 진행 합니다. 통상 별도의 성능 테스트 전문 인력이 날잡아서 수동으로 진행하고요.

이제 다음으로 [릴리즈]와 [배포] 입니다.

릴리즈는 배포 가능한 패키지를 만드는 과정이에요.

도커 빌드를 하기 위해서는 Dockerfile이라는 스크립트를 작성해야 되고, 또 쿠버네티스에 배포를 하기 위해서 yaml 파일들을 사전에 만들어 놔야 되는데 이렇게 배포를 하기 위한 별도의 패키지를 만드는 게 릴리즈고, 이 파일들도 변경관리가 되야 하기 때문에 작성한 내용들을 이렇게 Github에 올려 놓습니다.

이제 다음 단계로 [운영]입니다.

이건 실제 운영환경을 구성하는 요소와 툴 들이라고 보시면 되요. 여기서 Nginx와 Istio는 네트워크 트래픽 관리에 대한 도구에요.

운영을 구성하는 환경들은 다 표현하기 힘들 정도로 많지만, 이정도로만 합니다.

이렇게 인프라 환경 안에서 설치되고, 운영자는 이 툴들이 정상적으로 잘 돌아가고 있는지 확인해야 하는 역할을 하죠.

그리고 마지막으로 [모니터링]인데,

모니터링 요소는 주로 자원 사용량이나 App로그 그리고 트래픽 흐름을 많이 봐요. Grafana 나 Loki 그리고 Prometheus는 Sprint1에서 사용을 해봤고. 이게 자원 사용량이랑 App로그를 보기 위한 툴이였죠?

그리고 Jaeger랑 Zipkin은 트래픽 흐름을 보기 위한 도구예요. 이제 마이크로서비스 환경이 많아졌기 때문에 서비스들 간에 트래픽이 어떻게 흘러가는지 추적을 하는게 중요해 졌습니다. 그래서 이런 오픈소스들을 설치해야 되고

위치는 운영과 똑같이 인프라 환경 내에 설치가 되요. 이 App들은 다 쿠버네티스 클러스터 위에서 Pod로 띄어 진다고 보시면 됩니다.

그럼 여기까지가 모니터링까지 다 설명을 드린거고,

아까 [Slack을 쓰는 이유]에 대해 설명하면

딴게 아니라 이렇게 연결되는 그림들이 있어야 되서 그래요. 이렇게 슬렉은 데브옵스에 중요 포인트 차지하고 있는 툴들이랑 연동이 할 수가 있거든요.

통상 메신저에는 개발자나, 데브옵스 엔지니어 혹은 운영자들이 모여 있는 방이 각각 있을 텐데, 슬렉을 쓰면 이 파이프라인에서 발생하는 알람들을 필요한 방에 울리도록 설정할 수가 있는거죠. 그래서 이게 협업을 위한 여러 메신저들 중에서, 그래도 슬렉을 쓰면 좋은 점 이었습니다.

자 그럼 여기까지가 데브옵스를 구성하는 오픈소스들에 대한 설명이였는데, 현재는 이렇게 데브옵스가 복잡해 졌습니다. 그래서 기업에서는 데브옵스 엔지니어를 별도로 뽑을 수 밖에 없는 거고요.

뭔가 많아 보이지만, 그래도 차근차근 하나씩 구성하다 보면 생각보다 금방 파이프라인이 만들어 지기도하고 여기 있는걸 한번에 다 만들 필요는 없어요. 배포를 한다고 처음부터 helm이나 argoCD를 적용할 필요는 없는 거고 Kubectl 배포부터 일단 연결을 해 놓은 다음에 하나씩 장비를 업그레이드 하는 마음으로 바꿔 나가면 되거든요.

쿠버네티스 어나더클래스 DevOps 전체 구성도

DevOps에서 가장 중요한 것 (개발->빌드->실행파일)

DevOps에 엮인 IT 직군들

DevOps 외 다른 Ops들

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

AWS 3 Tier Architecture 구축해보기 2-11

똥선생 — Wed, 13 Aug 2025 18:48:55 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

1. DB 스냅샷 백업

데이터베이스 스냅샷을 S3에 보관

KMS 생성하기

• KMS 키를 사용하여 RDS 스냅샷을 S3로 내보내기 위해 KMS 생성하기

• KMS > 키 생성 > 다음과 같이 설정하기 - 키 유형: 대칭 - 키 사용: 암호화 및 해독

- 별칭: ddong-snapshot-key

- 키 관리자: admin

- 키 사용자: admin

정책 생성하기

• 람다 함수를 실행시키기 위해서는 2가지 권한이 필요함

1. S3로 스냅샷 내보내기

• RDS 스냅샷을 S3로 내보내기 위한 권한

2. Lambda 역할 • Lambda 함수가 실행되기 위해 필요한 권한

• ‘iam:PassRole’ 권한을 통해 2번째 역할인 ‘S3 로 스냅샷 내보내기’ 역할을 맡을 수 있도록 허용하기

1) S3로 스냅샷 내보낼 때의 정책 생성하기

• IAM > 정책 생성 > JSON 클릭 > 정책 편집기에 다음을 붙여넣기 > 다음과 같이 설정 > 정책 생성 - 정책 이름: ddong-RDS-S3

backup을 저장할 s3 버킷은 미리 만들어야합니다.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "s3:PutObject", 
                "s3:ListBucket", 
                "s3:GetBucketLocation", 
                "s3:GetObject", 
                "s3:AbortMultipartUpload", 
                "s3:ListMultipartUploadParts", 
                "s3:DeleteObject" 
            ], 
            "Resource": [ 
                "arn:aws:s3:::my-backup-bucketname", 
                "arn:aws:s3:::my-backup-bucketname/*" 
            ] 
        }, 
           { 
            "Effect": "Allow", 
            "Action": [ 
                "kms:Encrypt", 
                "kms:Decrypt", 
                "kms:DescribeKey", 
                "kms:CreateGrant" 
            ], 
            "Resource": "arn:aws:kms:ap-northeast-2:767828741563:key/9fc3667b-7028-4b75-9816-ab9405a6b398" 
        }, 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "rds:DescribeDBSnapshots", 
                "rds:ListTagsForResource", 
                "rds:StartExportTask" 
            ], 
            "Resource": "*" 
        } 
    ] 
}

역할 생성하기

IAM > 역할 > 역할 생성 > AWS 서비스 선택 > 사용 사례: Lambda > 다음과 같은 권한 정책 추가하기 > 역할 이름: ddong-RDS-S3-Role > 역할 생성

ddong-RDS-S3, AWSLambdaBasicExecutionRole

ddong-RDS-S3-Role의 신뢰관계 다음과 같이 설정하기

{ 
"Version": "2012-10-17", 
"Statement": [ 
{ 
"Effect": "Allow", 
"Principal": { 
"Service": "export.rds.amazonaws.com" 
}, 
"Action": "sts:AssumeRole" 
} 
] 
}

Lambda 함수 역할 생성하기

• lambda 함수를 사용하기 위한 역할을 생성하기

- 위에서 역할 생성을 했던 방식대로 아래와 같이 역할을 생성하기

- 역할 이름: ddong-administratorAccess

- 권한 추가: AdministratorAccess

람다 함수 작성하기

1) 람다 함수 생성하기

• Lambda > 함수 생성 > 새로 작성 > 다음과 같이 설정하기

- 함수 이름: CreateRdsSnapshotAndExport

- 런타임: Python 3.8

- 기존 역할 사용 클릭

- 위에서 생성한 역할인 ‘ddong-administratorAccess’ 선택하기

2) RDS 스냅샷 생성 후 S3 Standard에 저장하는 람다 코드 작성하기

• 코드 > 코드 소스 > 다음과 같이 코드 작성 > Deploy > Test

- 코드: S3 버킷과 경로는 매일 백업되는 날짜와 시간에 맞춰서 동적으로 생성됨

테스트 진행 시에는 다음과 같이 특정 날짜를 하드코딩해 일별로 S3에 저장되도록 하 기

import boto3 
import datetime 
 
def lambda_handler(event, context): 
    rds = boto3.client('rds') 
     
    # 하드코딩된 날짜를 2025년 8월 12일로 설정 
    fixed_date = datetime.datetime(2025, 8, 12) 
     
    snapshot_id = f"snapshot-{fixed_date.strftime('%Y-%m-%d')}" 
    db_instance_identifier = "ddong-rds-instance" 
 
    # 스냅샷 생성 
    print("before") 
    try: 
        rds.create_db_snapshot( 
            DBSnapshotIdentifier=snapshot_id, 
            DBInstanceIdentifier=db_instance_identifier 
        ) 
    except Exception as e: 
        print(f"Error creating snapshot: {e}") 
        raise 
 
    print("after") 
    try: 
        # 스냅샷이 사용 가능해질 때까지 대기 
        waiter = rds.get_waiter('db_snapshot_available') 
        waiter.wait(DBSnapshotIdentifier=snapshot_id) 
    except Exception as e: 
        print(f"Error waiting for snapshot: {e}") 
        raise 
 
    # 고유한 export_task_id 생성 (시간까지 포함하여 고유하게 생성) 
    now = datetime.datetime.now() 
    export_task_id = f"export-task-{fixed_date.strftime('%Y-%m-%d')}{now.strftime('%H-%M-%S')}"
    s3_bucket_name = "ddongbackupbucket-x" 
    s3_prefix = f"August/12/" 
 
    try: 
        # 스냅샷을 S3로 내보내기 
        rds.start_export_task( ExportTaskIdentifier=export_task_id, SourceArn=f"arn:aws:rds:ap-northeast-2:767xxxxxxxx:snapshot:{snapshot_id}", S3BucketName=s3_bucket_name, IamRoleArn="arn:aws:iam::767828xxxxxx:role/ddong-RDS-S3-Role", S3Prefix=s3_prefix, KmsKeyId="arn:aws:kms:ap-northeast-2:76782xxxxx:key/9fc3667b-7028-4b75-9816-ab9405a6b398")
    except Exception as e: 
        print(f"Error during export: {e}") 
        raise 
    return { 
    'statusCode': 200, 
    'body': f"Snapshot {snapshot_id} exported to S3://{s3_bucket_name}/{s3_prefix}" 
    }

EventBridge 구성하기

• EventBridge를 사용하여 Lambda 함수를 정기적으로 실행하도록 규칙을 설정하기

• 새벽 2시에 람다 함수를 작동시키는 것이지만, 테스트 시에는 테스트하는 시간에 맞게 변경함.

1) EventBridge 설정하기

• Amazon EventBridge > 규칙 > 규칙 생성 > 다음과 같이 생성하기

- 규칙이름: ddong-Eventbridge

- 규칙유형: 일정

테스트용으로 1회실행해보겠다.

AWS 3 Tier Architecture 구축해보기 2-10

똥선생 — Tue, 12 Aug 2025 23:11:37 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

https://velog.io/@tak980418/CICD%EB%A5%BC-%EA%B5%AC%EC%84%B1%ED%95%B4%EB%B3%B4%EC%9E%90-1-PLAN

참고 블로그

1. 모니터링

1) SNS 설정하기 (Web)

SNS > 주제 > 주제 생성 > 다음과 같이 설정하기

Web ASG를 대상으로 경보 생성하도록 설정하기

• CloudWatch > 경보 > 경보 생성 >지표 선택

• ‘EC2 > Auto Scaling 그룹별’ 선택 > Web 서버 ASG의 CPUUtilization 선택하기 > 지표 선택

2) Amazon Q Developer 구성하기 ( 구 Chatbot)

허용하기

새 채널 구성 > 다음과 같이 설정하기

- 구성 이름: ddong-slack-channel

퍼블릭 채널은 slack에서 만들기.

SNS 주제의 리전 1: 도쿄

SNS 주제의 주제 1: ddongTopic

3) 경보 확인하기 (Web)

한 Web서버에 들어가서 스트레스 주기

• EC2 > 서버 하나 선택 > 연결 > Session Manager > 연결

• stress 다운받기

sudo yum update

sudo yum install stress

Web 서버에stress 주기

stress -c 2 -t 6000

Cloudwatch에서 경보 확인 가능

Slack에서도 알람이 오게됨

와이어샤크를 통한 프로토콜 분석 - 3way, 4way handshake

똥선생 — Sun, 10 Aug 2025 23:35:32 +0900

IT 개발자나 네트워크 엔지니어에게 필요한 와이어샤크를 실습하면서 배워보려고 한다.

여러 매체를 통해 배웠고, 그 중 잘되있다고 생각하는 곳은 한빛미디어 네트워크 기초 강의이다.

https://www.youtube.com/watch?v=I_aCbbzORms

유튜브 링크

https://github.com/kangtegong/self-learning-cs2

실습 자료

한빛미디어의 강의를 바탕으로 배운것들을 정리해본다.

3-Way Handshake

3-Way Handshake는 TCP 연결을 맺을 때 클라이언트와 서버가 서로의 통신 준비 상태를 확인하고 동기화(Synchronization) 하는 과정입니다.

TCP가 신뢰성 있는 연결 지향 프로토콜이기 때문에 이 과정이 꼭 필요합니다.

3-way-handshake.pcapng

1번 데이터

1번 데이터의 목적지를 보니 HTTP 통신임을 확인 할 수 있다.

첫 번째: SYN (Synchronize)

클라이언트 → 서버
연결 요청 메시지 전송
SYN 플래그 = 1
클라이언트는 자신의 초기 시퀀스 번호(ISN, 예: Seq = x)를 보냄
의미: “저 연결하고 싶어요, 그리고 제 시퀀스 번호는 x입니다.” (랜덤값)

1번 데이터 flag

두 번째: SYN + ACK

서버 → 클라이언트
클라이언트의 SYN 요청에 대한 응답
SYN = 1, ACK = 1
서버도 자신의 초기 시퀀스 번호(ISN, 예: Seq = y)를 보냄
ACK 번호 = 클라이언트 ISN + 1 (Ack = x+1)
의미: “좋아요, 연결할게요. 제 시퀀스 번호는 y(랜덤값)이고, 당신 번호 x는 받았어요.”

2번 데이터 flag

1번 데이터의 +1 값

세 번째: ACK

클라이언트 → 서버
서버의 SYN+ACK에 대한 확인 응답
ACK = 1
ACK 번호 = 서버 ISN + 1 (Ack = y+1)
의미: “네, 서버 번호 y 받았고 저도 준비됐습니다.”

3번 데이터 flag

ACK 의 +1 값

4-Way Handshake

TCP는 양방향 연결이라서, 종료도 양쪽 방향을 각각 닫아야 하기 때문에 3번이 아니라 4번의 단계가 필요합니다.

connection-close.pcapng

첫 번째: FIN (Finish)

클라이언트 → 서버
클라이언트가 데이터 전송을 마쳤음을 알림
FIN = 1, Seq = u
의미: "저 이제 보낼 데이터 없어요."

1번 데이터

두 번째: ACK

서버 → 클라이언트
FIN을 잘 받았음을 확인
ACK = 1, Ack = u+1
의미: "네, 알겠습니다. 하지만 저는 아직 보낼 게 있어요."

세 번째: FIN

서버 → 클라이언트
서버도 더 이상 보낼 데이터가 없을 때 FIN 전송
FIN = 1, Seq = v
의미: "저도 이제 끝났습니다."

네 번째: ACK

클라이언트 → 서버
서버의 FIN을 확인
ACK = 1, Ack = v+1
의미: "네, 연결 완전히 종료합니다."

TCP 재전송

2번 과정에서 패킷이 유실됬다고 가정. 192.168.0.1의 확인 응답 번호를 10.10.10.1는 알지 못함.

4번 과정에서 동일한 확인 응답 번호를 요청하며, 첫번째 중복 ACK 발생.

5번 과정에서 10.10.10.1이 확인응답번호가 아닌 다른 순서번호를 보낸다고 가정 (TCP 파이프라인에 의해)

TCP 파이프라인(TCP pipelining)은 TCP 연결 위에서 여러 개의 데이터 요청·응답을 순차적으로가 아니라 겹쳐서 처리하는 방식을 말합니다.
쉽게 말하면, 한 번에 하나씩 요청하고 응답을 기다리는 대신, 여러 요청을 연속으로 보내놓고 순차적으로 응답을 받는 기법

192.168.0.1은 확인 응답 번호를 받지 못했기 때문에 6번 과정에서 두번째 중복 ACK 보내게됨.

7번 과정에서도 TCP 파이프라인에 의해 다른 순서번호를 보냈다고 가정.

8번 과정에서 세번째 중복 ACK 발생.

9번 과정에서 10.10.10.1은 ACK를 중복 3번 받았기 때문에 빠른 재전송 발생.

tcp-retransmission.pcapng

와이어샤크를 통한 프로토콜 분석 - IPv4 단편화 + ICMP + UDP

똥선생 — Sun, 10 Aug 2025 22:48:11 +0900

IT 개발자나 네트워크 엔지니어에게 필요한 와이어샤크를 실습하면서 배워보려고 한다.

여러 매체를 통해 배웠고, 그 중 잘되있다고 생각하는 곳은 한빛미디어 네트워크 기초 강의이다.

https://www.youtube.com/watch?v=I_aCbbzORms

유튜브 링크

https://github.com/kangtegong/self-learning-cs2

실습 자료

한빛미디어의 강의를 바탕으로 배운것들을 정리해본다.

와이어샤크를 통해 다양한 프로토콜을 분석해보자.

1. IPv4 단편화

IPv4 단편화(fragmentation)는 IP 패킷이 네트워크를 통과할 때, 해당 네트워크의 최대 전송 단위(MTU, Maximum Transmission Unit)보다 커서 한 번에 전송할 수 없을 경우 패킷을 여러 조각으로 나누어 전송하는 과정을 말합니다.

네트워크 장비(라우터, 스위치)나 링크 종류에 따라 MTU 크기가 다름
예:
- Ethernet MTU: 1500 바이트
- PPPoE MTU: 1492 바이트
큰 패킷이 MTU 제한을 초과하면 그냥은 전송 불가 → IPv4는 패킷을 쪼개어(fragment) 전송

단편화 동작 과정

원본 패킷이 MTU보다 큼
- 예: MTU=1500인데, IP 헤더(20바이트) + 데이터 합이 4000바이트라면 단편화 필요.
라우터 또는 송신자가 패킷을 여러 조각으로 나눔
각 조각에는 IP 헤더 + 일부 데이터 포함
수신 측에서 Identification 필드를 기반으로 원래 패킷으로 재조립(reassembly)

★요즘 대부분의 네트워크에서는 IPv4도 DF(Don’t Fragment) 비트를 켜고 PMTUD(Path MTU Discovery) 방식으로 동작하는 게 사실상 표준입니다.

PMTUD 동작 방식

송신자가 DF=1로 패킷 전송 (즉, 단편화 금지)
경로 중간의 라우터가 MTU보다 큰 패킷을 받으면 전송 불가 → ICMP Type 3 Code 4 ("Fragmentation Needed") 메시지를 송신자에게 보냄
송신자는 이 ICMP 메시지를 보고 패킷 크기를 줄여서 재전송
결국 해당 경로에서 전송 가능한 최대 MTU 크기를 알아내서 계속 그 크기로 전송

현실에서는?

대부분의 OS / 네트워크 장비: IPv4 전송 시 기본적으로 DF 비트를 켜고 PMTUD 사용
클라우드 환경(AWS, Azure, GCP): 거의 다 DF+PMTUD 사용
기업망: 대역폭 효율과 보안을 위해 PMTUD 선호
단, 일부 방화벽/ISP가 ICMP를 막아 PMTUD가 실패하는 경우가 있어, 이럴 때는 MSS Clamping 같은 우회 기법을 씀

ipv4-fragmentation.pcapng

(와이어샤크를 설치하고 깃허브 실습자료에서 자료를 받아 열기)

10.0.0.1 -> 10.0.0.2 IMCP

10.0.0.1 <- 10.0.0.2 IMCP

IPv4 헤더의 단편화 관련 필드

Identification: 같은 패킷 조각임을 식별하는 ID

1~7번 데이타의 Identification값이 같음.

8~14번 데이타의 값이 같음.

같은 단편화 데이터임을 알 수 있다.

Flags:
- DF(Don’t Fragment): 1이면 단편화 금지
- MF(More Fragments): 마지막 조각이 아니면 1, 마지막 조각이면 0

1~6번 데이터는 끝에 1

7번 단편화의 끝 데이터는 0으로 표기

Fragment Offset: 원래 데이터에서의 시작 위치 (8바이트 단위)

1번 데이터는 시작이므로 0

2번 데이터

7번 데이터 ( 값이 점차 증가)

2. ICMP

ICMP(Internet Control Message Protocol)는 IPv4와 IPv6에서 모두 쓰이는 네트워크 제어/진단용 프로토콜입니다.
쉽게 말하면, IP 통신 중 발생하는 상황을 알려주는 "메신저" 역할을 합니다.

오류 보고
- 목적지 도달 불가(Destination Unreachable)
- 단편화 필요(DF 설정 시)
- 시간 초과(Time Exceeded)
네트워크 진단
- ping: 호스트가 살아있는지 확인 (ICMP Echo Request / Echo Reply)
- traceroute: 경로 추적 (ICMP Time Exceeded 활용)
경로 MTU 발견 (PMTUD)
- DF 비트 켜고 패킷 전송 → MTU 초과 시 "Fragmentation Needed" ICMP 메시지 수신

7번 데이터 (요청)

14번 데이터 (응답)

ipv6-fragmentation.pcapng 파일 오픈하여 UDP 데이터그램을 보자.

[] 대괄호에 있는 속성은 와이어 샤크가 임의로 만든 것이고, 실제 필드는 4개

TCP보다는 훨씬 간단한 구조이다.

AWS 3 Tier Architecture 구축해보기 2-9

똥선생 — Sun, 10 Aug 2025 12:58:19 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

https://velog.io/@tak980418/CICD%EB%A5%BC-%EA%B5%AC%EC%84%B1%ED%95%B4%EB%B3%B4%EC%9E%90-1-PLAN

참고 블로그

1. CI/CD구축하기

서버 배포 파이프라인의 구성

1. GitHub 리포지토리 생성 + .yml 파일 준비
2. S3 버킷 생성
3. CodeBuild 프로젝트 생성
4. CodeDeploy 애플리케이션 & 배포 그룹 생성
5. CodePipeline 생성 (Source → Build → Deploy 연결)
6. 서버 배포 하기

1. GitHub 리포지토리 생성 + .yml 파일 준비

YAML 구성

GitHub Actions는 GitHub 레포지토리에 저장되있는 파일을 통해 Workflow를 실행합니다.

따라서 GitHub Actions를 통한 CI/CD Workflow를 구성하기 위해서는 파일을 작성해 GitHub저장소에 저장해야 합니다.

아래와 같은 경로로 파일,폴더를 만들어 GitHub 저장소에 저장해주세요.

콘솔로도 가능하고 드래그&드롭으로도 가능

appspec.yml 파일 만들기

version: 0.0 
os: linux 
files: 
  - source: / 
    destination: /usr/share/nginx/html/  
# HTML 파일을 복사할 배포할 웹 서버의 경로 
hooks: 
  BeforeInstall: 
    - location: scripts/before_install.sh 
      timeout: 300 
      runas: root 
  AfterInstall: 
    - location: scripts/update_metadata.sh 
      timeout: 300 
      runas: root

buildspec.yml 파일 만들기

version: 0.2 
 
phases: 
  install: 
    runtime-versions: 
      nodejs: 12 # 예: Node.js가 필요하다면, 해당 부분은 필요에 따라 수정 
    commands: 
      - echo "Nothing to install" 
 
  pre_build: 
    commands: 
      - echo "Nothing to pre-build" 
 
  build: 
    commands: 
      - echo "Build started on `date`" 
      - echo "No build step required for static HTML" 
 
  post_build: 
    commands: 
      - echo "Build completed on `date`" 
 
artifacts: 
  files: 
    - '**/*'

before_install.sh 파일 만들기

기존 웹 서버에는 /usr/share/nginx/html/경로에 index.html 파일이 있음

이 index.html을 배포하기 위해서는 기존의 index.html을 삭제하고, 다시 배포해 야 함

따라서 before_install.sh을 만들어 기존 파일을 삭제하는 스크립트를 실행하기

#!/bin/bash 
# 기존 index.html 파일 삭제 
if [ -f /usr/share/nginx/html/index.html ]; then 
    rm /usr/share/nginx/html/index.html 
fi

update_metadata.sh 파일 만들기

HTML 파일에 메타데이터를 삽입하는 로직을 추가하기

배포 프로세스 중에 update_metadata.sh 스크립트가 실행되어 index.html 파일 을 동적으로 생성하고,

이 파일에 EC2 인스턴스의 실제 메타데이터 값을 삽입함

#!/bin/bash 
 
# IMDSv2 토큰 발급 
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
 
# 메타데이터 조회 with 토큰 
REGION_AZ=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/placement/availability-zone) 
INSTANCE_ID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/instance-id) 
PRIVATE_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/local-ipv4)
 
# index.html 파일 생성 
cat <<EOF > /usr/share/nginx/html/index.html 
<!DOCTYPE html> 
<html> 
<head> 
    <title>Web Server2</title> 
    <style> 
        body { 
            font-family: Arial, sans-serif; 
            font-size: 50px; 
            margin: 0; 
            padding: 20px; 
        } 
        h1 { 
            font-weight: bold; 
            font-size: 50px; 
            margin: 0 0 20px 0; 
            color: blue; 
        } 
        .info { 
            font-weight: normal; 
            font-size: 40px; 
            line-height: 1.5; 
        } 
        .info br { 
            margin-bottom: 10px; 
        } 
    </style> 
</head> 
<body> 
    <h1>Web Server V2</h1> 
    <div class="info"> 
        Region/AZ: $REGION_AZ<br> 
        Instance ID: $INSTANCE_ID<br> 
        Private IP: $PRIVATE_IP<br> 
    </div> 
</body> 
</html> 
EOF

2. S3 버킷 생성

S3에서 버킷을 생성 한다. 이름은 고유해야한다.

CodeBuild가 S3 버킷에서 소스 아티팩트를 다운로드할 때 접근할 수 있도록 S3의 정책 먼저 생성하기

s3-> 버킷 정책

{
"Version": "2012-10-17",
"Statement": 
{
"Effect": "Allow",
"Principal": {
"Service": "codebuild.amazonaws.com"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::<본인-S3-Bucket-Name>",
"arn:aws:s3:::<본인-S3-Bucket-Name>/*"
]
}

3. CodeBuild 프로젝트 생성

GitHub 내 계정과의 연결을 만들어 준다.

나머지 설정 마무리

생성후 빌드. 정상확인

IAM 정책 추가

이전에 생성한 codebuild-codeBuild-service-role 역할에 권한 추가하기

codebuild-codeBuild-service-role 선택 > 서비스 역할 > 권한 탭 > 권한 추가 > 인라인 정책 생성 > JSON > 다음 코드 입력 > 정책 이름 > 정책 생성

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codedeploy:*",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:GetBucketLocation",
                "s3:PutObject"
            ],
            "Resource": "*"
        }
    ]
}

IAM 사용자, 역할 차이

IAM 사용자 (User)

사람(또는 애플리케이션)을 위한 고정된 신원(identity)
AWS 계정 내에서 지속적으로 존재하는 사용자 계정
로그인용 아이디와 암호(비밀번호)를 가질 수 있고, 액세스 키도 발급 가능
주로 개발자, 운영자 등 실제 사람이 AWS 콘솔이나 CLI/API 사용 시 할당
권한(Policy)을 붙여서 그 사용자만의 권한 부여

특징

고유한 자격 증명(ID, PW, 액세스 키)을 가짐
AWS 계정 내에 영구적으로 존재
직접 로그인 및 AWS 자원 접근 가능

[IAM 역할 (Role)]

사람, 서비스, 애플리케이션 등에 임시로 권한을 위임하기 위한 신원
고정된 신원은 아니고, 필요할 때 “역할을 맡는(Assume 하는)” 형태
로그인용 계정 정보(비밀번호)가 없음 → 직접 로그인 불가
AWS 서비스(예: EC2, Lambda), 또는 다른 계정의 사용자에게 권한 위임 시 사용
임시 보안 토큰을 통해 권한을 획득해 일정 시간만 권한을 가짐

특징

직접 로그인 불가, 역할 위임용
EC2 인스턴스, Lambda 함수 등에 역할 부여해서 권한 위임 가능
타 AWS 계정 사용자도 역할을 맡을 수 있음(크로스 어카운트 권한 위임)
보안상 권장되는 권한 위임 방법 (액세스 키 노출 위험 ↓)

AWS 서비스(CodeBuild, CodePipeline 등)와 외부 코드 저장소(GitHub)을
안전하게 연결해 주는 브리지 역할을 추가해야 합니다.

codebuild-codeBuild-service-role에서 codeconnections:UseConnection 권한을 추가해줍니다.

인라인 정책 설정 클릭

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "codeconnections:UseConnection",
            "Resource": "arn:aws:codeconnections:ap-northeast-2:<<MY UUID를 넣으세요>>"
        }
    ]
}

해당 정책 추가.

[UUID 확인법]

(AWS 콘솔 → Developer Tools → Connections → 해당 연결 클릭 → ARN에 표시)

권한 추가된것을 확인.

4. CodeDeploy 애플리케이션 & 배포 그룹 생성

CodeDeploy를 사용하여 애플리케이션을 배포하기 전에 배포 그룹을 생성해야 하기 때문에, 배포 그룹도 생성해줍니다.

CodeDeploy 에이전트는 테라폼으로 구축 시 설치되게끔 구성함

배포 그룹 생성 완료.

5. CodePipeline 생성 (Source → Build → Deploy 연결)

CodePipeline > 파이프라인 > 파이프라인 생성

- 실행모드: 대기

대기 중인 순서대로 실행을 하나씩 처리하도록 설정함.

현재 소스 코드는 git에서만 가져오며, 배포 또한 각 서버에 배포 되어 있도록 설정되어 있기 때문에 병렬이 아닌 대기로 선택함

pipeline IAM 역할에 권한 추가

IAM 콘솔 → Roles → codepipeline-role 선택
권한(permissions) 탭에서 Add permissions → Attach policies
AWSCodeDeployFullAccess 권한 추가

6. 서버 배포 하기

코드를 commit하면 자동으로 AWS CodePipeline이 작동됨

서버 한 개씩 배포되는 것으로 설정.

서버 한 개 배포시 다음과 같은 과정에 거쳐 진행됨.

CodeDeploy EC2 배포 이벤트 순서

BeforeBlockTraffic
- 기존 인스턴스에 새 트래픽이 들어오기 전에 실행
- 로드 밸런서에서 인스턴스 연결을 끊기 전에 필요한 작업 수행
BlockTraffic (자동 수행)
- 로드 밸런서에서 인스턴스 분리
AfterBlockTraffic
- 트래픽 차단 직후 실행
- DB 연결 종료, 세션 저장 등 안전 종료 처리
BeforeInstall
- 새 버전을 설치하기 전에 실행
- 이전 파일 삭제, 백업, 환경변수 설정
Install (자동 수행)
- S3나 GitHub에서 새 애플리케이션 파일 다운로드 후 지정 경로로 복사
AfterInstall
- 설치 직후 실행
- 권한 변경, 의존성 설치, 설정 파일 수정
ApplicationStart
- 애플리케이션 시작
- 서비스 재시작, 서버 실행 명령어
ValidateService
- 애플리케이션 정상 동작 여부 확인
- 헬스 체크 스크립트 실행
BeforeAllowTraffic
- 트래픽 허용 전 마지막 준비 작업
AllowTraffic (자동 수행)
- 로드 밸런서에서 인스턴스 연결
AfterAllowTraffic
- 트래픽 허용 직후 실행
- 모니터링 시작, 알림 전송 등

+ 참고용

CodeDeploy에서는 S3파일을 다운로드하고 ALB에 속해있는 EC2에 배포할 수 있는 권한이 필요합니다.

따라서 역할을 생성하여 이후 CodeDeploy 구성시 해당 역할을 사용할 수 있도록 할 계획입니다.

역할에는 앞서 말한것 처럼

1. EC2에 배포 할 수 있는 권한,

2. S3파일을 다운로드 할 수 있는 권한이 존재해야 합니다.

다음을 누르게 되면, 보이는 것 처럼 CodeDeploy에 대한 권한이 기본적으로 들어가 있습니다.

저희는 S3 파일을 다운로드 할 수 있는 권한만 추가해주면 되겠습니다.

S3 파일을 다운로드 할 수 있는 권한은 생성 후 추가해줄 것이기 때문에, 일단 해당 역할을 생성해줍니다.

생성한 역할을 클릭하면 다음과 같은 화면이 나오게 됩니다.

여기서 S3ReadOnlyAccess 권한 추가를 통하여 S3에 대한 읽기 권한을 추가해 줍니다.

3) ASG에 속해있는 EC2

EC2에서는 CodeDeploy를 위한 역할을 설정해주어야 합니다.

여기부분은 이미 terraform으로 적용되있으니 흐름만 이해해주세요.

권한에 AmazonEC2RoleForCodeDeploy를 추가해줍니다.

해당 정책을 추가해주는 이유는 결국 EC2에 S3에 존재하는 파일을 읽어 가져와야 하기 때문입니다.

해당 정책은 +로 코드를 보면 S3 버킷 읽기 권한을 가지고 있습니다.

이후 역할 이름을 적절히 작성 한 뒤, 역할을 생성해 주시면 되겠습니다.

해당 역할은 이후 ASG에속한 EC2의 생성 시 사용할 예정입니다.

생성된 역할을 시작템플릿에 적용하고, 롤링업데이트로 기존EC2들을 버전 업데이트를 해야합니다.

기존 ASG에 연결된 EC2에 해당 역할이 적용되있으니, 추가로 적용할 필요는 없습니다.

AWS 3 Tier Architecture 구축해보기 2-8

똥선생 — Sat, 9 Aug 2025 12:59:48 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

https://velog.io/@tak980418/CICD%EB%A5%BC-%EA%B5%AC%EC%84%B1%ED%95%B4%EB%B3%B4%EC%9E%90-1-PLAN

참고 블로그

1. 인프라 정상 접속 확인하기

route53에서 발급받은 값을 도메인 사이트에서 입력했더라도 적용까지 하루 이틀 소요됩니다.

1) Web, WAS, DB 접속 확인하기

# Web 서버 접속하기

도메인으로 https 보안 접속하기

새로고침하여 ALB가 정상 작동하는지 확인

# WAS 서버 접속하기

# DB 서버 접속하기

2. CI/CD 구축 계획 수립

CI/CD는 지속적 통합(Continuous Integration) 과 지속적 배포(Continuous Deployment)를 합친 말로, 소프트웨어 개발과 배포를 자동화하고 효율화 하는 방식입니다.

서버 배포 파이프라인의 구성

1. GitHub 리포지토리 생성 + .yml 파일 준비
2. S3 버킷 생성
3. CodeBuild 프로젝트 생성
4. CodeDeploy 애플리케이션 & 배포 그룹 생성
5. CodePipeline 생성 (Source → Build → Deploy 연결)
6. 서버 배포 하기

현재 프로젝트는 GitHub를 원격저장소로 활용하고 있다고 가정합니다.

비교적 간단한 워크플로우를 구성합니다.

AWS 3 Tier Architecture 구축해보기 2-7

똥선생 — Wed, 6 Aug 2025 22:57:29 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

저번 시간 테라텀 코드를 apply 하였다. 콘솔로 접속하여 제대로 실행됬는지 확인 해보자.

1. 구축 결과 확인하기

1) VPC

2) 인터넷 게이트웨이

3) NAT Gateway

4) 서브넷, 라우팅 테이블

• Public subnet 2개, Private subnet 6개

5)ALB, ALB SG

6) 시작 템플릿

7) Target Group

8)Auto Scaling Group, Auto Scaling Group SG

9) DB SG, DB Subnet Group

10) RDS 파라미터 그룹, RDS

11) Output

Terraform으로 구축완료시 다음과 같이 rds-endponit와 web-alb-dns확인하기

2. ROUTE53 도메인 등록하기

AWS에서 서버를 구축하고 외부에서 도메인으로 접속하려면, Route 53을 통해 도메인을 호스팅(관리)하는 것이 일반적인 방법입니다.

1)여러 사이트에서 도메인 구입 가능. 비교 후 구입

Route 53 > 호스팅 영역 > 호스팅 영역 생성 > 구매한 도메인 이름

2)Name Server 등록하기

생성된 호스팅 영역에는 NS와 SOA가 자동으로 생성됨.

값/트래픽 라우팅 대상을 구매한 도메인 사이트 가서 입력해주면됨.

3) Alias 레코드 등록

Application Load Balancer에 연결된 경우

Route 53에서는 Alias 레코드를 사용해야 합니다:

Alias – AWS 리소스로 트래픽 라우팅

즉, ALB로 트래픽 라우팅 해줌.

AWS 3 Tier Architecture 구축해보기 2-6

똥선생 — Wed, 6 Aug 2025 21:43:30 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main

참고 깃허브

현재까지 인프라 구축을 위한 terraform 코드 작성은 완료되었고, AWS에 적용시켜보겠다.

IAM -> 사용자 -> 본인 계정 선택 -> 액세스 키 만들기 클릭

생성된 액세스 키 및 비밀 액세스 키를 기록해둡니다.

2. AWS CLI 설치 (윈도우 경우, amazon ec2면 이미 설치)

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

일반적으로 Terraform으로 AWS에 리소스를 적용하려면 AWS CLI는 "직접적으로는 필수는 아니지만", AWS 자격 증명 설정을 위해 거의 항상 함께 사용됩니다.

Terraform이 AWS 리소스를 조작하려면

Terraform은 AWS API를 통해 리소스를 생성/변경/삭제합니다. 이때 AWS 인증 정보 (Access Key / Secret Key) 가 필요합니다.

이를 설정하는 방법은 여러 가지가 있는데:

가장 일반적인 사용 흐름으로는
AWS CLI 설치
aws configure 입력해서 Access Key, Secret Key, Region 입력
terraform init && terraform apply
이 흐름에서는 AWS CLI가 자격증명 파일을 만들어주는 도구 역할을 합니다.

로컬 개발 환경 (Windows on-premise 등)에서는 AWS CLI 설치 후 aws configure 사용하는 방식이 가장 편하고 안전합니다.

환경변수 설정도 가능하지만, 반복성과 관리 편의성은 CLI 방식이 더 좋습니다.

Terraform 자체는 AWS CLI 없이도 동작합니다.

하지만 자격 증명 설정을 위해 AWS CLI 설치가 거의 필수처럼 사용됩니다.

3. AWS configure

테라폼에서 사용할 tf 파일에 IAM key를 작성하는 방식은 보안상 올바르지 않습니다.

aws configure를 이용해 민감한 정보를 로컬에서 받아올 수 있게 명령어로 aws key를 등록합니다.

aws configure

AWS Access Key ID [None]: Own Access key
AWS Secret Access Key [None]: Own Secret Key
Default region name [None]: ap-northeast-2
Default output format [None]:

4. main.tf 설정 추가

terraform provider, region를 명시합니다.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.7.0" # 로컬에 설치한 최신 버전으로 변경
    }
  }
}
provider "aws" {
  region     = "ap-northeast-2"
}

terraform providers 명령어 사용하여 version 조회

터미널에서 프로젝트 디렉터리 안에서 위 명령어를 실행한 후 terraform.lock.hcl 파일에서 확인 ( terraform init 되있어야함)

현재 기준 6.7.0입니다.

예시 출력

Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/aws]

5. Terraform 실행

1) terraform init

.tf 파일이 위치한 디렉토리에서 실행해주세요

기본 설정 구성 및 필요한 모든 파일과 설정을 저장하기 위한 .terraform 디렉토리를

생성합니다.

2) terraform plan

테라폼 설정 파일에 정의된 변경 사항을 미리 예측하고 검토하는데 사용됩니다.

3) terraform apply

'terraform apply' 명령어는 terraform 설정 파일에 정의된 인프라 변경 사항을 실제

클라우드 환경에 적용하는데 사용됩니다.

terraform apply -> yes -> 구축 완료

참고로 AWS RDS는 요금이 많이 청구되기 때문에 쓰지 않을때에는 일지정지를 해주세요.

- 포털에서 인프라 확인

다음 글에서 AWS Console에 접속하여 인프라가 정상 구축되었음을 확인합니다.

4) terraform destroy

Terraform으로 생성한 리소스 삭제

해당 명령어로 생성한 모든 인프라 리소스를 제거합니다.

나중에 삭제하실때 위 명령어로 하시면 됩니다.

AWS 3 Tier Architecture 구축해보기 2-5

똥선생 — Tue, 5 Aug 2025 07:21:02 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

1.web-user-data.sh 스크립트 작성

#!/bin/bash
# Amazon Linux 2 userdata script for setting up Nginx with ProxyPass
# Update packages
sudo yum update -y
# Install Nginx
sudo yum install -y nginx
# Start and enable Nginx
sudo systemctl start nginx
sudo systemctl enable nginx
# Install SSM Agent
sudo yum install -y amazon-ssm-agent
# Start and enable SSM Agent
sudo systemctl start amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
# Configure ProxyPass in Nginx

# 도메인servername으로 접근해오는 트래픽을 ALB로 proxy해줌.
cat << EOF > /etc/nginx/conf.d/proxy.conf
server {
listen 80;
server_name ddongteacher.xyz;
# Proxy path configuration (e.g., /app)
location /app {
proxy_pass http://${alb_dns}/;
}
# Log settings (optional)
error_log /var/log/nginx/mark_error.log;
access_log /var/log/nginx/mark_access.log combined;
}
server {
listen 443;
server_name ddongteacher.xyz;
# Proxy path configuration (e.g., /app)
location /app {
proxy_pass http://${alb_dns}/;
}
# Log settings (optional)
error_log /var/log/nginx/mark_error.log;
access_log /var/log/nginx/mark_access.log combined;
}
EOF
# 토큰 생성
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
# 메타데이터 사용하여 각 정보 조회
RZAZ=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
IID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/instance-id)
LIP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  -s http://169.254.169.254/latest/meta-data/local-ipv4)
  
# HTML 파일에 정보 삽입
cat << EOF > /usr/share/nginx/html/index.html
<!DOCTYPE html>
<html>
<head>
<title>Web Server</title>
<style>
body {
font-family: Arial, sans-serif; /* 폰트 스타일 */
font-size: 50px; /* 기본 폰트 크기 */
margin: 0;
padding: 20px; /* 내용과 화면 가장자리 사이에 간격 추가 */
}
h1 {
font-weight: bold; /* h1 태그는 볼드체 */
font-size: 50px; /* h1 태그의 폰트 크기 */
margin: 0 0 20px 0; /* 제목 아래에 여백 추가 */
}
.info {
font-weight: normal; /* 정보 텍스트는 일반 두께 */
font-size: 40px; /* 정보 텍스트의 폰트 크기 */
line-height: 1.5; /* 줄 간격 설정 */
}
.info br {
margin-bottom: 10px; /* <br> 태그 아래 마진 추가 */
}
</style>
</head>
<body>
<h1>Web Server</h1> <!-- 제목은 볼드체로 왼쪽 상단에 표시 -->
<div class="info">
Region/AZ: $RZAZ<br>
Instance ID: $IID<br>
Private IP: $LIP<br>
</div>
</body>
</html>
EOF
# Nginx 재시작
sudo systemctl restart nginx

2.app-user-data.sh 스크립트 작성

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install nginx, php (Amazon Linux 2 version)
bash
# Update packages
sudo yum update -y
# Install Apache and PHP
sudo yum install -y nginx php php-mysqlnd
# Enable necessary Apache modules
sudo systemctl start nginx
sudo systemctl enable nginx
# Install SSM Agent
sudo yum install -y amazon-ssm-agent
# Start and enable SSM Agent
sudo systemctl start amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
# Install MySQL client
sudo yum install -y mariadb105
echo "rds = ${rds_endpoint}"
echo "${host}"
# RDS 에 접속하여 쿼리 실행
mysql -h "${host}" -P 3306 -u "${username}" -p${password} "${db}" -e "CREATE
TABLE IF NOT EXISTS info (
name VARCHAR(50) PRIMARY KEY,
email VARCHAR(50),
age INT
);"
mysql -h "${host}" -P 3306 -u "${username}" -p${password} "${db}" -e "INSERT
INTO info (name, email, age) VALUES ('mk', 'mk@google.com', 23);"
cat << EOF > /usr/share/nginx/html/test.php
<!DOCTYPE html>
<html>
<head>
<meta charset="utf8">
</head>
<body>
<?php
phpinfo();
?>
</body>
</html>
EOF
cat << EOF > /usr/share/nginx/html/db.php
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<h1>DB page</h1>
<?php
// 데이터베이스 연결
\$conn = new mysqli("${host}", "${username}", "${password}", "${db}",
3306);
// 연결 확인
if (\$conn->connect_error) {
die("Connection failed: " . \$conn->connect_error);
}
\$sql = "SELECT name, email, age FROM info";
\$result = \$conn->query(\$sql);
if (\$result->num_rows > 0) {
// 결과 행을 출력
while(\$row = \$result->fetch_assoc()) {
echo "Name: " . \$row["name"] . " - Email: " . \$row["email"] . "
- Age: " . \$row["age"] . "<br>";
}
}
else {
echo "0 results";
}
// 연결 닫기
\$conn->close();
?>
</body>
</html>
EOF
# Restart Nginx
sudo systemctl restart nginx

AWS 3 Tier Architecture 구축해보기 2-4

똥선생 — Tue, 5 Aug 2025 05:23:33 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

Main.tf 작성하기(4)

1.Route 53, ACM

# ACM 흐름
# aws_acm_certificate → 인증서 요청 (DNS 인증 방식)
# data "aws_route53_zone" → 해당 도메인의 호스팅 영역 정보 조회
# aws_route53_record  → 인증에 필요한 CNAME 레코드 자동 생성
# aws_acm_certificate_validation → DNS가 제대로 설정됐는지 확인 → 인증 완료

# ACM 인증서 생성
resource "aws_acm_certificate" "example" {
domain_name = "ddongteacher.xyz"
# 인증서를 발급받을 도메인 이름
# 도메인은 구해오셔야함.
validation_method = "DNS"
#도메인 소유권을 DNS 레코드를 통해 검증함
# aws_acm_certificate가 실행되면 AWS가 검증용 CNAME 레코드를 생성하라고 알려줌.
# 도메인 등록업체(예: Route 53) DNS에 해당 CNAME 레코드를 추가해야 함.
# ACM이 그 DNS 레코드를 확인한 후 인증서를 발급함.
# 이후 이 인증서는 ALB(로드밸런서)나 CloudFront 등에 붙여서 HTTPS 사용 가능.
# DNS 검증은 한 번 설정하면 이후 자동 갱신되므로 추천 방식입니다.
# 인증서는 무료이며, 자동으로 만료 전에 갱신됩니다 (DNS 설정이 살아 있다면).
}
# ACM 검증
resource "aws_acm_certificate_validation" "example" {
certificate_arn = aws_acm_certificate.example.arn
}
data "aws_route53_zone" "example" {
name = "ddongteacher.xyz"
private_zone = false
}
# ACM 검증을 위한 CNAME 레코드 생성
resource "aws_route53_record" "example" {
for_each = {
for dvo in aws_acm_certificate.example.domain_validation_options :
dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.example.zone_id
}

#Route 53에서 도메인 ddongteacher.xyz를 ALB로 연결하는 A 레코드를 만드는 설정
resource "aws_route53_record" "web" {
zone_id = data.aws_route53_zone.example.zone_id
#"ddongteacher.xyz" 도메인을 Route 53에서 이미 호스팅하고 있어야 함
name = "ddongteacher.xyz"
type = "A" # ALIAS 레코드는 A 또는 AAAA 타입을 사용합니다.
alias {
#이건 "ALIAS 레코드"라고 해서 Route 53에서만 지원하는 특별한 A 레코드입니다.
#ALB 같은 AWS 리소스는 IP가 자주 바뀌기 때문에 DNS 이름으로 연결할 수 있게 해줍니다.
name = aws_lb.alb-web.dns_name
#name: 연결할 대상의 DNS 이름 → ALB의 DNS 이름 (예: my-alb-123456.ap-northeast-2.elb.amazonaws.com)
zone_id = aws_lb.alb-web.zone_id
#ALB가 소속된 Route 53 존 ID (ALB 마다 고유)
evaluate_target_health = true
}
# ttl = 86400 # ALIAS 레코드에는 필요하지 않지만, 일관성을 위해 기재 가능
}

#ddongteacher.xyz 라는 도메인을 Route53에서 관리하고 있고,
#사용자가 이 도메인으로 접속하면,
#트래픽이 ALB(aws_lb.alb-web) 으로 전달됩니다.
#ALB 뒤에는 EC2, ECS, 또는 Lambda 등이 붙어 있을 수 있습니다.

2. Output

특정 값이나 속성을 테라폼 실행 결과의 출력으로 내보내기 위해 사용

output "web-alb-dns" {
value = aws_lb.alb-web.dns_name
}
output "rds-endpoint" {
value = data.aws_db_instance.my_rds.endpoint

AWS 3 Tier Architecture 구축해보기 2-3

똥선생 — Tue, 5 Aug 2025 05:20:35 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main

참고 깃허브

Main.tf 작성하기(3)

1. Target Group

# TG-Web
resource "aws_lb_target_group" "tg-web" {
name = "ddong-tg-web"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.vpc.id
health_check {
path = "/"
matcher = "200-299"
# health check 위해 기대되는 http 응답 코드 범위(200~299: 성공적인 응답)
interval = 5 # 5 초마다 health check 수행
timeout = 3 # 3 초 내에 반환하지 않으면 실패로 간주
healthy_threshold = 3
# 성공적인 health check 횟수(연속적으로 건강한 것으로 간주되기 위함)
unhealthy_threshold = 5
# 실패한 health check 횟수(연속적으로 비건강한 것으로 간주되기 위함)
}
}
## HTTPS 프로토콜을 사용하므로 이를 받아줄 리스너
## default action 으로 404 페이지 출력
resource "aws_lb_listener" "myhttps" {
load_balancer_arn = aws_lb.alb-web.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-2016-08"
certificate_arn = aws_acm_certificate.example.arn
# By default, return a simple 404 page
default_action {
type = "fixed-response" # 고정된 응답을 반환
fixed_response {
content_type = "text/plain"
message_body = "404: page not found - MK"
status_code = 404
# 요청이 왔는데 매칭되는 rule이 없다면
#그냥 404: page not found - MK 라는 텍스트를 응답으로 보내요.
}
}
}
## HTTPS 리스너 규칙 생성
## Target 그룹으로 포워딩
# ALB 요청 흐름 구조
# 클라이언트 요청
#     ↓
# ALB (aws_lb)
#     ↓
# Listener (aws_lb_listener)
#     ↓
# Listener Rule (aws_lb_listener_rule)
#     ↓
# Target Group (aws_lb_target_group)
#     ↓
# EC2 등 실제 서버
resource "aws_lb_listener_rule" "https-rule" {
listener_arn = aws_lb_listener.myhttps.arn
# 어떤 리스너에 규칙을 붙일지 지정 (여기선 HTTPS 443 포트 리스너)
priority = 100
# 규칙의 우선순위 (낮을수록 먼저 평가됨)
condition {
path_pattern { # 요청의 경로 패턴에 따라 규칙을 적용할지 결정
values = ["*"] # 모든 경로(*)에 대해 이 규칙을 적용
# (이 리스너로 들어오는 모든 요청에 대해 이 규칙이 적용)
}
}
action {
type = "forward"
target_group_arn = aws_lb_target_group.tg-web.arn
}
}
## HTTP 프로토콜 리스너(모든 HTTP 트래픽을 HTTPS 로 리디렉션)
## default action 으로 404 페이지 출력
resource "aws_lb_listener" "myhttp" {
load_balancer_arn = aws_lb.alb-web.arn
port = 80
protocol = "HTTP"
# By default, return a simple 404 page
default_action {
type = "redirect" # 트래픽을 다른 위치로 리디렉션
redirect {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301" # 301 상태 코드는 영구적인 리디렉션
}
}
}
# TG-WAS
resource "aws_lb_target_group" "tg-was" {
name = "ddong-tg-was"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.vpc.id
health_check {
path = "/"
matcher = "200-299"
interval = 5
timeout = 3
healthy_threshold = 3
unhealthy_threshold = 5
}
}
resource "aws_lb_listener" "alb_listener-was" {
load_balancer_arn = aws_lb.alb-was.arn
port = "80"
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.tg-was.arn
}
}

2. Auto Scaling Group, Auto Scaling Group SG

# ASG-Web
resource "aws_autoscaling_group" "asg-web" {
name =  "ddong-asg-web"
desired_capacity = 2
max_size = 4
min_size = 2
target_group_arns = [aws_lb_target_group.tg-web.arn]
health_check_type = "EC2"
vpc_zone_identifier = [aws_subnet.web-sub1.id, aws_subnet.web-sub2.id]
tag {
key = "asg-web-key"
value = "asg-web-value"
propagate_at_launch = true
# ASG 에서 생성된 EC2 인스턴스에 태그를 자동으로 적용할지에 대한 여부 지정
}
launch_template {
id = aws_launch_template.template-web.id
version = aws_launch_template.template-web.latest_version
}
instance_refresh {
strategy = "Rolling"
preferences {
min_healthy_percentage = 50
}
triggers = ["tag"]
# Terraform은 기본적으로 리소스의 설정(속성값)이 바뀔 때만 변경 작업을 합니다.
# 그런데 외부 환경이나 코드 외의 조건에 따라 강제로 실행하고 싶을 때가 있어요.
# 이때 triggers를 써서 "이 값이 바뀌면 무조건 다시 실행해라" 라고 알려줍니다.
}
}
# ASG-Web-SG
resource "aws_security_group" "asg-sg-web" {
name = "ddong-asg-sg-web"
description = "ASG Security Group"
vpc_id = aws_vpc.vpc.id
ingress {
description = "HTTP from ALB"
from_port = 80
to_port = 80
protocol = "tcp"
security_groups = [aws_security_group.alb-sg-web.id]
}
ingress {
description = "SSH From Anywhere or Your-IP"
# 원격으로 서버 접속해 SW 업데이트, 구성 변경 등
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "ddong-asg-sg-web"
}
}
# ASG-WAS
resource "aws_autoscaling_group" "asg-was" {
name = "ddong-asg-was"
desired_capacity = 2
max_size = 4
min_size = 2
target_group_arns = [aws_lb_target_group.tg-was.arn]
health_check_type = "EC2"
vpc_zone_identifier = [aws_subnet.was-sub1.id, aws_subnet.was-sub2.id]
tag {
key = "asg-app-Key"
value = "asg-app-Value"
propagate_at_launch = true
}
launch_template {
id = aws_launch_template.template-was.id
version = aws_launch_template.template-was.latest_version
}
instance_refresh {
strategy = "Rolling"
preferences {
min_healthy_percentage = 50
# 인스턴스 갱신 중에 항상 최소 50%의 인스턴스가 정상 상태를 유지하도록 설정
}
triggers = ["tag"]
}
}
# ASG-WAS-SG
resource "aws_security_group" "asg-sg-was" {
name =  "ddong-asg-sg-was"
description = "ASG Security Group"
vpc_id = aws_vpc.vpc.id
ingress {
description = "HTTP from ALB"
from_port = 80
to_port = 80
protocol = "tcp"
security_groups = [aws_security_group.alb-sg-was.id] # was alb sg 에서 오는 트래픽
}
ingress {
description = "SSH From Anywhere or Your-IP"
from_port = 22
to_port = 22
protocol = "tcp"
security_groups = [aws_security_group.asg-sg-web.id] # web asg sg 에서 오는 트래픽
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "ddong-asg-sg-was"
}
}

3.DB SG, DB Subnet Group

# DB-SG
resource "aws_security_group" "db-sg" {
name = "ddong-db-sg"
description = "DB Security Group"
vpc_id = aws_vpc.vpc.id
ingress {
from_port = 3306
to_port = 3306
protocol = "tcp"
security_groups = [aws_security_group.asg-sg-was.id]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "ddong-db-sg"
}
}
# DB-Subnet-Group
resource "aws_db_subnet_group" "db-sub-grp" {
name = "ddong-db-sub-grp"
subnet_ids = [aws_subnet.db-sub1.id,aws_subnet.db-sub2.id]
tags = {
Name = "ddong-db-sub-grp"
}
}

4.RDS 파라미터 그룹, RDS

# RDS 파라미터 그룹
resource "aws_db_parameter_group" "mk-par-grp" {
name = "ddong-par-grp"
family = "mysql8.0"
description = "Example parameter group for mysql8.0"
parameter {
name = "character_set_server"
value = "utf8mb4"
}
#MySQL 서버의 기본 문자셋을 utf8mb4로 설정
#(4바이트 UTF-8: 이모지 등도 저장 가능)
parameter {
name = "collation_server"
value = "utf8mb4_unicode_ci"
#기본 collation (문자 정렬 방식)을 utf8mb4_unicode_ci로 설정
#(문자 비교 시 대소문자 구분 없이 유니코드 기준으로 정렬)
}
}
# RDS
## RDS 데이터 소스 정의
data "aws_db_instance" "my_rds" {
db_instance_identifier = aws_db_instance.rds-db.identifier
}
resource "aws_db_instance" "rds-db" {
allocated_storage = 20
db_name = "ddongdb"
engine = "mysql"
engine_version = "8.0"
storage_type = "gp3" // General Purpose SSD (gp3)
instance_class = "db.t3.micro"
username = "ddong"
password = "ddong1234567890"
parameter_group_name = aws_db_parameter_group.mk-par-grp.name
multi_az = true
db_subnet_group_name = aws_db_subnet_group.db-sub-grp.name
vpc_security_group_ids = [aws_security_group.db-sg.id]
skip_final_snapshot = true
identifier = "ddong-rds-instance" // RDS 인스턴스의 이름 지정
}

AWS 3 Tier Architecture 구축해보기 2-2

똥선생 — Mon, 4 Aug 2025 04:01:00 +0900

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main

참고 깃허브

Main.tf 작성하기(2)

1. ALB, ALB SG

# ALB
resource "aws_lb" "alb-web" {
name = "ddong-alb-web"
internal = false
load_balancer_type = "application" # Application Load Balancer
security_groups = [aws_security_group.alb-sg-web.id]
subnets = [aws_subnet.pub-sub1.id, aws_subnet.pub-sub2.id]
}
resource "aws_lb" "alb-was" {
name = "ddong-alb-was"
internal = true
load_balancer_type = "application"
security_groups = [aws_security_group.alb-sg-was.id]
subnets = [aws_subnet.was-sub1.id, aws_subnet.was-sub2.id]
}
# ALB SG
resource "aws_security_group" "alb-sg-web" { # Web ALB SG
name = "ddong-alb-sg-web"
description = "ALB Security Group"
vpc_id = aws_vpc.vpc.id
ingress {
description = "HTTP from Web Tier"
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
description = "HTTPS from Web Tier"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "ddong-alb-sg-web"
}
}
resource "aws_security_group" "alb-sg-was" { # WAS ALB SG
name = "ddong-alb-sg-was"
description = "ALB Security Group"
vpc_id = aws_vpc.vpc.id
ingress {
description = "HTTP from Internet"
from_port = 80
to_port = 80
protocol = "tcp"
security_groups = [aws_security_group.asg-sg-web.id]
# asg-security-group-web 이라는 SG 에 속한 인스턴스만이 이 포트를 통해 ALB 에
# 접근할 수 있도록 제한하기
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "ddong-alb-sg-was"
}
}

2. SSM 접속 위한 IAM

resource "aws_iam_role" "ec2_ssm_role" {
name = "ddong-EC2SSM"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}
]
})
}
# IAM 역할 정책 연결
resource "aws_iam_role_policy_attachment" "ec2_ssm_policy_attachment" {
for_each = toset([
"arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess",
"arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore",
"arn:aws:iam::aws:policy/service-role/AWSCodeDeployRole"
])
role = aws_iam_role.ec2_ssm_role.name
policy_arn = each.key
}
# EC2 인스턴스 프로파일 생성
## EC2 인스턴스를 구분하고 그 인스턴스에 권한을 주기 위한 개념
# 인스턴스 프로파일이 지정된 EC2 는 시작 시 역할 정보를 받아오고 해당 역할로 필요한
# 권한들을 얻게 됨
resource "aws_iam_instance_profile" "ec2_ssm_instance_profile" {
name = "ddong-EC2SSM-Instance-Profile"
role = aws_iam_role.ec2_ssm_role.name
}

3. 시작 템플릿

# Launch template- Web
resource "aws_launch_template" "template-web" {
name = "ddong-launch-template-web"
image_id = "ami-0fc8aeaa301af7663" # 최신 amazon linux2 ami-id
#ami-id는 계속 바뀌기 때문에 확인필요
instance_type = "t2.micro"
# 인스턴스 안에서 메타데이터 사용가능
metadata_options {
http_endpoint = "enabled"
# 인스턴스 메타데이터에 HTTP 엔드포인트를 사용하도록 설정
# 메타데이터 서비스 사용 허용할지 여부
# enabled: curl 명령으로 메타데이터를 조회 가능
http_tokens = "required"
# http_tokens: 메타데이터 요청에 대해 토큰을 필요로 함 (보안 강화)
http_put_response_hop_limit = 1
# 메타데이터 서비스에 대한 PUT 응답의 네트워크 홉 제한을 1 로 설정
# (메타데이터 서비스로의 PUT 요청이 다른 중간 네트워크 장치를 거치지 않고 바로
# 인스턴스로 전달됨. 이를 통해 외부에서의 비정상적인 접근을 방지할 수 있음)
# 직접적인 내부 요청만 허용해서 보안 강화됨
instance_metadata_tags = "enabled"
# 인스턴스에 붙인 태그 정보도 메타데이터로 조회 가능
}
network_interfaces {
device_index = 0 #첫 번째 네트워크 인터페이스(0)를 지정
security_groups = [aws_security_group.asg-sg-web.id]
}
iam_instance_profile {
//EC2 인스턴스에 IAM Role을 붙일 수 있도록 해주는 "껍데기 역할"
//EC2는 직접 Role을 붙이지 못하고, 반드시 이 "Instance Profile" 을 통해 역할을 위임받습니다.
name = aws_iam_instance_profile.ec2_ssm_instance_profile.name
}
user_data = base64encode(templatefile("web-user-data.sh",{
# 사용자 데이터 스크립트는 인스턴스가 처음 시작할 때 실행됨.
# 이 스크립트는 "web-user-data.sh" 파일을 사용하고, 이 파일은 ALB 의 DNS 이름을
# 인자로 받아 인코딩된 형태로 제공
# "web-user-data.sh" 파일은 Terraform 코드가 실행되는 로컬 디렉터리 안에 있어야 합니다.
alb_dns = "${aws_lb.alb-was.dns_name}"
}))
depends_on = [
aws_lb.alb-web # alb-web 리소스가 생성된 후에 실행되도록 설정
]
tag_specifications {
resource_type = "instance"
tags = {
Name = "ddong-web-instances"
}
}
}
# Launch Template - WAS
resource "aws_launch_template" "template-was" {
name = "ddong-launch-template-was"
image_id = "ami-0fc8aeaa301af7663" # 최신 amazon linux2 ami-id
instance_type = "t2.micro"
network_interfaces {
device_index = 0
security_groups = [aws_security_group.asg-sg-was.id]
}
iam_instance_profile {
name = aws_iam_instance_profile.ec2_ssm_instance_profile.name
}
## 인스턴스 안에서 메타데이터 사용가능
metadata_options {
http_endpoint = "enabled"
http_tokens = "required"
http_put_response_hop_limit = 1
instance_metadata_tags = "enabled"
}
## 인스턴스가 올바른 데이터베이스와 연결되도록 환경 변수를 설정
user_data = base64encode(templatefile("app-user-data.sh",{
host = "${local.host}"
rds_endpoint = "${data.aws_db_instance.my_rds.endpoint}"
username = "${"ddong"}"
password = "${"ddong1234567890"}"
db = "${"ddongdb"}"
}))
depends_on = [
aws_db_instance.rds-db
]
tag_specifications {
    //태그를 어떤 AWS 리소스에 붙일지 정의하는 블록
resource_type = "instance"
// EC2 인스턴스에 적용됨을 의미
tags = {
Name = "ddong-was-instances"
}// EC2 인스턴스를 콘솔이나 CLI에서 볼 때:
// 이름(Name)이 "ddong-was-instances" 라고 표시됩니다.
}
}
## locals 블록을 사용하여 로컬 변수를 정의
## 코드 내에서 재사용할 값을 정의
## 지역 변수를 선언하는 곳이에요.
# 한 번 정의하면, 같은 .tf 파일이나 다른 블록에서 local.변수명으로 사용할 수 있어요.

locals {
rds_endpoint = "${data.aws_db_instance.my_rds.endpoint}"
# AWS RDS 인스턴스의 엔드포인트 값을 할당받기
# (이 값은 보통 RDS 인스턴스에 접속하기 위한 주소와 포트 번호 포함)
host = replace(local.rds_endpoint, ":3306", "")
# local.rds_endpoint 에서 포트 번호 (:3306)를 제거하여 생성
}

AWS 3 Tier Architecture 구축해보기 2-1

똥선생 — Sun, 3 Aug 2025 19:58:51 +0900

지금까지 위 3-Tier를 구현 하였다. 더나아가 실무에 가깝고 aws의 여러 기능을 추가한 아키텍처를 찾는 도중 깃허브에 올라온 아키텍처를 찾았다.

https://github.com/estrellaSia/AWS_3Tier_Infra_Data_Pipeline/tree/main
참고 깃허브

위 깃허브는 aws 다양한 서비스를 학습하기 좋았다.

팀프로젝트를 진행하신 것 같아보이고, 따라해보며 aws 실습을 해보면 좋을것이다.

기존 아키텍처를 삭제 한 후 깃허브를 따라 해당 아키텍처를 구현해보겠다.

큰 틀은 Terraform 을 이용해 구현한다.

현재까지 따라 완성한 구성도는 아래와 같다.

1.Terraform 환경 구성(Windows, VS Code)

VS Code 설치

VS Code설치가 완료되었으면, 추가적으로 필요한 Extensions 도구들을 추가로 설치해 준다.

이 중 HashiCorp Terraform을 설치해준다.

이제 확장자명이 (. tf)인 파일을 하나 생성한 후 임의의 코드를 작성해보면 하이라이트 및 자동완성 등 효율적으로 코드를 작성하기 위한 기능들이 정상적으로 동작하는 것을 확인할 수 있다.

Terraform 프로그램도 따로 설치필요하다.

Terraform 설치

https://developer.hashicorp.com/terraform/install

Terraform 설치 후 압축을 풀어준 후 나온 파일을 C드라이브 하단의 임의의 폴더(C:\Terraform)를 생성한 후 넣어준다.

해당 경로에 terraform.exe 파일을 넣었으면 어느 경로에 있더라도 사용할 수 있도록 환경 변수를 등록해 준다.

앞서 terraform.exe 파일을 넣어두었던 폴더 경로를 새로 추가해준 후 확인을 눌러 적용한다.

2.Network Architecture

Main.tf 작성하기

1)VPC 구성

resource "aws_vpc" "vpc" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
# Amazon 의 DNS 서버가 VPC 내부에서 DNS 쿼리를 해석할 수 있도록 함
enable_dns_hostnames = true
# VPC 에서 인스턴스에 대해 DNS 호스트 이름을 할당할 수 있는지 여부를 결정
tags = {
Name = "ddong-vpc"
}
}

resource "aws_vpc" "vpc" {
...
}
resource: Terraform에서 실제 리소스를 생성할 때 사용하는 블록입니다.
"aws_vpc": AWS의 VPC 리소스를 의미합니다.
"vpc": 이 리소스를 Terraform 내부에서 참조할 때 사용할 이름입니다.

cidr_block
생성할 VPC의 IP 주소 범위 (CIDR)입니다.

enable_dns_support = true
true면 Amazon DNS 서버가 VPC 내부에서 DNS 쿼리를 해석할 수 있도록 허가합니다.
보통 VPC 안의 EC2 인스턴스에서 도메인 이름을 사용하려면 이 옵션을 켜야 합니다.

enable_dns_hostnames = true
true면 VPC에서 생성된 인스턴스들에 DNS 호스트 이름 (예: ip-10-0-0-1.ap-northeast-2.compute.internal)을 할당할 수 있습니다.
이것도 일반적으로 DNS 사용을 위해 켜놓는 게 좋습니다.

tags = {
Name
}
VPC 리소스에 태그를 붙입니다.

Name이라는 키에 변수 값을 넣습니다.

2) 인터넷 게이트웨이

resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.vpc.id # igw 를 해당 vpc 에 attatch
tags = {
Name = "ddong-igw"
}
}

3) NAT 게이트웨이

resource "aws_eip" "eip1" {
domain = "vpc" # 해당 EIP 가 VPC 내에서만 사용 가능하도록 설정
}
resource "aws_eip" "eip2" {
domain = "vpc"
}
resource "aws_nat_gateway" "nat-gw1" {
allocation_id = aws_eip.eip1.id # EIP 할당
connectivity_type = "public" # NATGW 에 대한 연결 유형
subnet_id = aws_subnet.pub-sub1.id # NATGW 를 생성할 서브넷
tags = {
Name = "ddong-nat-gw1"
}
depends_on = [aws_internet_gateway.igw]
# 리소스 간 생성 순서 보장(IGW 생성 후 NATGW 생성되게)
}
resource "aws_nat_gateway" "nat-gw2" {
allocation_id = aws_eip.eip2.id
connectivity_type = "public"
subnet_id = aws_subnet.pub-sub2.id
tags = {
Name = "ddong-nat-gw2"
}
depends_on = [aws_internet_gateway.igw]
}

4)서브넷, 라우팅 테이블

# Public Subnet, Public Routing Table
resource "aws_subnet" "pub-sub1" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.1.0/24"
availability_zone = "ap-northeast-2a"
map_public_ip_on_launch = true # 퍼블릭 IP 주소를 자동으로 할당
tags = {
Name = "ddong-pub-sub1"
}
}
resource "aws_subnet" "pub-sub2" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.2.0/24"
availability_zone = "ap-northeast-2c"
map_public_ip_on_launch = true
tags = {
Name = "ddong-pub-sub2"
}
}
resource "aws_route_table" "pub-rt" {
vpc_id = aws_vpc.vpc.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id # 모든 트래픽은 IGW 로 향하게 설정해 인터넷 연결
}
tags = {
Name = "ddong-pub-rt"
}
}
resource "aws_route_table_association" "pub-rt-asso1" {
# public subnet 들을 public rt 에 연결
subnet_id = aws_subnet.pub-sub1.id
route_table_id = aws_route_table.pub-rt.id
}
resource "aws_route_table_association" "pub-rt-asso2" {
subnet_id = aws_subnet.pub-sub2.id
route_table_id = aws_route_table.pub-rt.id
}
# Private Subnet, Private Routing Table
resource "aws_subnet" "web-sub1" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.4.0/22"
availability_zone = "ap-northeast-2a"
map_public_ip_on_launch = false
tags = {
Name = "ddong-web-sub1"
}
}
resource "aws_subnet" "web-sub2" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.8.0/22"
availability_zone = "ap-northeast-2c"
map_public_ip_on_launch = false
tags = {
Name = "ddong-web-sub2"
}
}
resource "aws_subnet" "was-sub1" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.12.0/22"
availability_zone = "ap-northeast-2a"
map_public_ip_on_launch = false
tags = {
Name = "ddong-was-sub1"
}
}
resource "aws_subnet" "was-sub2" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.16.0/22"
availability_zone = "ap-northeast-2c"
map_public_ip_on_launch = false
tags = {
Name = "ddong-was-sub2"
}
}
resource "aws_subnet" "db-sub1" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.20.0/22"
availability_zone = "ap-northeast-2a"
map_public_ip_on_launch = false
tags = {
Name = "ddong-db-sub1"
}
}
resource "aws_subnet" "db-sub2" {
vpc_id = aws_vpc.vpc.id
cidr_block = "10.0.24.0/22"
availability_zone = "ap-northeast-2c"
map_public_ip_on_launch = false
tags = {
Name = "ddong-db-sub2"
}
}
resource "aws_route_table" "pri-rt1" {
vpc_id = aws_vpc.vpc.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_nat_gateway.nat-gw1.id
# 모든 트래픽은 NAT GATEWAY1로 가라
}
tags = {
Name = "ddong-pri-rt1"
}
}
resource "aws_route_table" "pri-rt2" {
vpc_id = aws_vpc.vpc.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_nat_gateway.nat-gw2.id
# 모든 트래픽은 NAT GATEWAY2로 가라
}
tags = {
Name = "ddong-pri-rt2"
}
}
resource "aws_route_table_association" "pri-rt-asso1" { # WEB
subnet_id = aws_subnet.web-sub1.id
route_table_id = aws_route_table.pri-rt1.id
}
resource "aws_route_table_association" "pri-rt-asso2" {
subnet_id = aws_subnet.web-sub2.id
route_table_id = aws_route_table.pri-rt2.id
}
resource "aws_route_table_association" "pri-rt-asso3" { # WAS
subnet_id = aws_subnet.was-sub1.id
route_table_id = aws_route_table.pri-rt1.id
}
resource "aws_route_table_association" "pri-rt-asso4" {
subnet_id = aws_subnet.was-sub2.id
route_table_id = aws_route_table.pri-rt2.id
}

AWS 3 Tier Architecture 구축해보기 1-4

똥선생 — Sun, 3 Aug 2025 13:13:39 +0900

참고 블로그 https://seongnyeon.tistory.com/104

5. Tier3: Database Tier(Data Storage & Retrieval)

모든 Application은 중요한 데이터들을 저장할 공간이 필요하고, Application Servers는 필요한 작업을 수행하고 Web Tier와 사용자에게 적절한 콘텐츠와 서비스를 제공하기 위해 데이터베이스를 읽고 쓸 수 있어야 한다. 그렇기 때문에 MySQL을 사용하는 RDS를 생성할 것이다.

5.1. DB Security Group 생성

Application Server에서 Database로 접속해야 하기에, 첫 번째로 보안그룹을 생성 후 Application Servers로부터 오는 inbound traffic을 허용 해준다.

inbound/outbound 규칙에서 Application Server와 요청을 주고 받을 수 있도록 MYSQL/Aurora(포트번호: 3306)을 추가해준다.

5.2. Application Sever Security Group 규칙 추가

appServer 보안 그룹에도 위와 같이 MYSQL/Aurora를 inbound/outbound에 추가해준다.

5.3. DB Subnet Group 추가

5.4. RDS 생성

VPC 선택 후 앞서 생성한 Database Subnet Group 할당 / 퍼블릭 액세스는 허용하지 않는다.

사전에 생성한 DB 보안 그룹을 할당

5.5. DB 접속

DB가 생성된 이후 (시간소요), App Server로부터 커넥션을 establish 하기 위해서는 Database Endpoint가 필요하다.

Bastion Host에서 SSH를 통해 App server에 접속한 상태에서 mysql command를 사용해 접속이 되는지 확인한다.

[ec2-user@ip-10-0-138-143 ~]$ mysql -h dong-webapp-db.cdq2ms2mynwg.ap-northeast-2.rds.amazonaws.com -P 3306 -u admin -p

위와같이 Application Server로부터 Database에 성공적으로 접속한 모습을 확인할 수 있다.

AWS 3 Tier Architecture 구축해보기 1-3

똥선생 — Sun, 3 Aug 2025 12:37:37 +0900

참고 블로그 https://seongnyeon.tistory.com/104

3. Tier2: Application Tier (Backend)

3.1. Application Server Launch Template 생성

백엔드 서비스가 사용할 EC2 인스턴스를 정의하기 위한 template를 생성한다.

이전에 만들었던 webServer-template와 동일한 설정으로 생성을 할 것이다.

Web Server로부터 Application Server로 ping을 보낼 수 있도록 webServer Security Group으로부터 ICMP-IPv4를 허용해준다.

이후에 Application Server로부터 Database에 접속을 하여야 하기 때문에 각각의 인스턴스로부터 mySQL 패키지를 install 해준다.

“Advanced details” 아래에 “사용자 데이터” 필드에 아래 스크립트를 추가해준다.

#mysql 설치
sudo dnf install mariadb105

3.2. Auto Scaling Group(ASG) 생성

3.3. Application Load Balancer(ALB) 생성

Web Tier 에서 Application Tier로 트래픽을 라우팅 하는 새로운 ALB를 생성해준다.

*이번에는 로드 밸런서 체계에서 반드시 “Internal”을 선택 해주어야 한다. 또한 새로운 target group(ksn-appServer-tg)을 생성해준다.

EC2, Load Balancer, VPC 같은 AWS 서비스에서 자주 나오는 개념인 "Internal"과 "Internet-facing"의 차이는 외부 인터넷과의 연결 유무입니다.

Internet-facing Load Balancer

퍼블릭 서브넷에 배치
외부 사용자가 인터넷을 통해 직접 접속 가능
예: 쇼핑몰 홈페이지, 블로그 등

Internal Load Balancer

프라이빗 서브넷에 배치
같은 VPC 안의 EC2 등에서만 접근 가능
예: 내부 API, DB 연동, 마이크로서비스 간 통신

3.4. Web 서버로부터 연동 확인

Application Server가 실행중이므로 Connectivity를 검증하기 위해서 Web Server로부터 Application Server로 Ping을 날린다.

우선, SSH로 Web Server EC2로 접속한 뒤, App Server EC2 중 하나로 private IP 주소로 ping을 날릴 것이다.

정상적으로 작동한다면 위와 같은 결과를 볼 수 있을 것이다.

4. Bastion Host 생성

Application Tier를 잠재적인 외부 액세스로 부터 보호하기 위해서 ASG 외부의 Web Tier에 EC2 instance(Bastion Host)를 생성할 것이다. 위 서버는 App Server의 Gateway로 사용될 것이다.

Public Subnet을 선택해주어야 한다. 또한 보안 그룹을 생성해 오직 내 IP를 통해 접속하는 SSH를 추가해준다.

4.1. Application Server Security Group 설정

appServer 보안 그룹에 inbound rules에서 SSH가 오로지 Bastion Host Server로부터만 접속이 가능하도록 설정을 해준다.

기존 SSH 정책을 삭제하고 아래 같이 Bastion Host Server의 보안그룹을 추가한다.

4.2. Connection Test

Bastion Host를 통해서 Application Server에 접속이 가능한지 테스트한다.

Application Server로 SSH 하기 위해서는 키페어가 BastionHost에 존재해야 한다.
private키 파일을 로컬 PC에서 Bastion에 업로드

먼저 로컬에서

Git for Windows 설치:
https://git-scm.com/download/win
설치 후 Git Bash 실행
편의상 privatekey를 C드라이브 폴더로 옮겨주세요
Git Bash에서 Windows 드라이브 경로 쓸 때는 이렇게 씁니다:
/c/Study_Ubuntu.pem
scp -i [접속할bationhost의 keypair] [복사할keypair] ec2-user@<EC2-Public-IP>:~
scp -i /c/Study_Ubuntu.pem /c/Study_Ubuntu.pem ec2-user@52.79.230.224:~

bastion에 들어가서 확인, private 키가 잘 들어갔다.

bastion에서 private ec2에 접속한다.

sudo ssh -i "Study_Ubuntu.pem" ec2-user@10.0.138.143

이렇게 Application Tier가 구축된 것을 확인할 수 있다.

AWS 3 Tier Architecture 구축해보기 1-2

똥선생 — Sun, 3 Aug 2025 10:39:32 +0900

참고 블로그 https://seongnyeon.tistory.com/104

2. Tier1: Web Tier (Frontend)

2.1. Web Server Launch Template 생성

ASG가 Public Subnet에서 EC2 인스턴스를 동적으로 사용하는데 필요한 Template를 생성할 것이다.

AMI: Amazon Linux 2023 kernel-6.1 AMI / Instance Type: t2.micro / Key Pair

새로운 보안 그룹을 생성한 뒤, inbound SSH, HTTP, and HTTPS rules을 추가해준다.

Apache Web Server와 basic HTML web page를 실행하기 위해 유저 데이터 섹션에 아래 스크립트를 추가해준다.

#!/bin/bash

#install apache
sudo yum -y install httpd

#enable and start apache
sudo systemctl enable httpd
sudo systemctl start httpd


# 퍼블릭 IP 가져오기
PUBLIC_IP=$(curl -s http://checkip.amazonaws.com)

# HTML 파일 작성
sudo tee /var/www/html/index.html > /dev/null <<EOF
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Welcome to My EC2</title>
  <style>
    body {
      font-family: sans-serif;
      background-color: #f5f5f5;
      text-align: center;
      padding-top: 100px;
    }
    h1 {
      color: #333;
    }
    .ip {
      font-size: 1.5rem;
      color: #007acc;
    }
  </style>
</head>
<body>
  <h1>Welcome to my EC2 Apache Server!</h1>
  <p>Your server is running on:</p>
  <p class="ip">http://$PUBLIC_IP</p>
</body>
</html>
EOF

Apache 웹서버가 설치되며 간단하게 자신의 IP를 출력해주는 index 페이지가 출력된다.

2.2. Auto Scaling Group(ASG) 생성

웹의 고가용성을 보장하기 위해서 public subnet 여러 AZ에서 EC2 인스턴스를 동적으로 프로비저닝 하는 ASG를 생성할 것이다.

사전에 만들어 놓은 템플릿 사용

두 개의 퍼블릭 서브넷 선택

2.3. Application Load Balancer (ALB) 생성

incoming HTTP 트래픽을 적절한 targets(EC2)으로 분배하기 위해서 ALB를 생성한다.

HTTP 트래픽을 기준으로 로드 밸런서를 하기 때문에 ALB를 선택한다.

로드 밸런서 체계에서 “Internet-facing”을 선택한다. 그러면 HTTP/S 요청들을 listen 할 수 있게 된다. 또한 ALB에서 EC2 instance로 라우팅 하기 위해서 HTTP protocol과 포트 번호 80번 및 target group을 설정해준다.

ASG interface에서 ALB를 생성하면 자동으로 default security group이 ALB로 attach 되기 때문에, ASG 설정을 완료한 뒤 load balancer로 돌아가 알맞은 Security Group이 Attached 되었는지 확인해야 한다.

EC2 인스턴스의 스케일 업 또는 스케일 다운 크기 조정 정책을 설정해준다.

CPU 사용률이 50%를 넘을 시 자동으로 instance를 더 생성하게 설정해준다.

2.4. Web Server 접속 확인

ASG 설정 및 생성이 완료된 뒤, ALB가 traffic을 잘 라우팅 하는지 확인하기 위해서 퍼블릭 DNS를 통해 EC2 Launch Template에서 생성한 웹사이트가 접속이 가능한지 확인한다.

AWS 3 Tier Architecture 구축해보기 1-1

똥선생 — Sat, 2 Aug 2025 23:03:20 +0900

3 Tier Architecture 는 가장 기본적인 구조로, 클라우드를 어느정도 배웠다면, 실습하기에 좋다.

기존에 여러 블로그에 작성되있는 3 Tier 게시물을 참고하여 살을 덧붙여 보겠다.

참고 블로그https://seongnyeon.tistory.com/104

1. Network Architecture

- 1개의 VPC

- 2개의 AZ에 각각 1개의 Public Subnet (Web Tier)

- 2개의 AZ에 각각 1개의 Private Subnet(Application Tier)

- Internet Gateway에 연결하기 위한 1개의 Public Route Table

- Application Tier Private Subnets과 NAT Gateway에 연결하기 위한 1개의 Private Route Table

1.1. VPC 설정

우선, VPC 콘솔에서 VPC 생성을 해준다. ‘VPC and more’ 옵션과 이름을 설정한 뒤, CIDR 블록은 10.0.0.0/16으로 설정해준다.

Application 가용성을 높여주기 위해서 두 개의 가용영역(us-east-1a and us-east-1b)을 사용할 것이다. 위 가용영역에 2개의 퍼블릭 서브넷과 2개의 프리이빗 서브넷을 생성해줄 것이다..

NatGateway는 별도로 생성해줄 예정이다.

1.2. Network Preview (AWS 제공)

Preview를 확인하고 VPC 생성을 마친다.

1.3. Public IPv4 주소 자동 할당

기본적인 네트워크 환경 구성이 완료된 뒤, 인터넷을 통해 리소스에 접속할 수 있도록 두 개의 Public Subnets에서 Public IPv4 주소 자동 할당 활성화를 해주어야 한다.

1.4. 기본 라우팅 테이블 설정

VPC가 생성되면 default route table이 ‘main table’로 설정된다.

그렇기 때문에 public-rtb를 main table로 사용하기 위해 위 설정을 해준다.

1.5. NAT Gateway 설정

1.6. Private Route Table 구성

VPC 구성 시 6개의 서브넷을 만들었기 때문에 기본적으로 route table 또한 6 개가 생성이 된다.

4개의 private subnet중 하나의 private subnet(for the Application Tier Subnets)만 필요하다.

임의의 private route table을 하나 선택한 후, 서브넷 연결을 편집 해준다. (-subnet-private1,-subnet-private2,subnet-private-3,-subnet-private4)

또한 private route table 라우팅에 NAT gateway를 반드시 포함 시켜주어야 한다.

public route table 또한 위와 같이 설정해준다.

[k8s] Application 기능으로 이해하기-PVC/PV, Deployment, Service, HPA

똥선생 — Thu, 3 Jul 2025 18:08:48 +0900

Kubernetes는 다양한 리소스를 통해 컨테이너 기반 애플리케이션을 유연하게 관리합니다. 하지만 처음 접하면 각각의 개념이 따로 노는 것처럼 느껴질 수 있죠. 이 글에서는 기능 관점에서 Kubernetes의 핵심 리소스들을 연결 지어 설명해볼게요.

PVC & PV: 애플리케이션이 데이터를 저장하는 공간

컨테이너는 기본적으로 휘발성입니다. 재시작하거나 재배포되면 내부 데이터가 사라지죠. 이럴 때 **Persistent Volume(PV)**와 **Persistent Volume Claim(PVC)**을 사용하면 안정적인 저장소를 확보할 수 있습니다.

PV (PersistentVolume)
클러스터에서 미리 만들어 놓은 물리적 또는 가상 저장소입니다. (예: NFS, AWS EBS, Ceph 등)
PVC (PersistentVolumeClaim)
사용자가 필요한 스토리지의 용량과 접근 모드를 정의해 PV를 요청하는 객체입니다.

비유하면,

PV는 "빈 창고", PVC는 "이런 창고가 필요해요!"라고 요청하는 양식입니다.
PVC를 내면 Kubernetes가 조건에 맞는 PV를 찾아 연결해줍니다.

테스트 환경에서 통상 노드를 임시 스토리지 볼륨으로 많이 사용합니다.

이때 hostPath를 쓰거나 PV의 local 속성을 쓰는데, 그러다보니 이 기능들이 임시저장 용도 인줄 오해하는 사람들이 많아요.

PVC, PV

이번엔 볼륨에 Secret이 아닌 PVC를 연결합니다. 그러면 PVC에 resource, accessModes와 같은 속성이 있고 PV에도 비슷한 내용이 있는데, 이번 강의에서는 이 내용이 실제 볼륨 속성으로 적용되지는 않아요. 필수 값이라서 넣은 것.

근데 쓰이진 않더라도 이 두 속성이 같은 값으로 들어가져 있긴 해야되요. 현재 이 두 오브젝트는 selector랑 label로 연결이 되어 있지만, 두 속성의 내용이 같지 않으면 연결이 안되거든요.

이제 본격적으로 배울 내용으로 local 이라는 속성이 있고, 내용으로는 path가 들어가는데 이 속성이 어떻게 노드를 스토리지로 사용할 수 있게 되는지 설명을 드릴게요.

local을 쓰면 필수로 nodeAffinity라는 속성을 꼭 사용하게 되어 있고, 이게 어느 노드에 Pod를 생성 할 건지를 정하는 속성인데 좀 복잡해 보일순 있지만, PV의 local을 쓸 때, 사용하는 루틴이라고 생각을 하시고 색이 있는 내용만 잘 보면 어떻게 쓰는지 직관적으로 알 수가 있죠.

우리가 마스터 노드를 만들 때, 기본적으로 Node라는 오브젝트가 만들어지고 label이 달려 있어요. 만약에 여러 워커노드를 만든다면, 각각 label이 달려 있을 거구요. 이 nodeAffinity 속성이 있는 PV에 연결된 Pod는 이 노드 위에 만들어지게 됩니다.

테스트 환경에서 별도의 스토리지를 구축하기가 번거롭기 때문에 쿠버네티스 노드중에 한 곳을 임시 스토리지로 정해놓고 쓰는거고 쿠버네티스가 노드의 path와 컨테이너 path를 연결을 해줘요. 그리고 마스터 노드의 이 path를 만들어 놓고 Pod가 다른 노드에 생성되면 안되니까 nodeAffinity라는 속성이 꼭 필요합니다.

그리고 근본적으로 이렇게 PVC와 PV를 써서 별도의 스토리지 공간을 만들어 놔야 되는 이유는, App이 컨테이너 안에다가만 파일을 저장해 놓으면 Pod가 죽었을 때, 파일도 같이 삭제가 되서 그래요. 물론 그래도되는 임시파일이면 상관이 없는데 영구적으로 보관해야 되는 파일이면 Pod가 죽었다 다시 만들어지더라도 기존의 파일들을 그대로 볼 수 있어야 겠죠?

그래서 PVC, PV를 사용하면 컨테이너 path 에다가 파일을 만들면 실제 파일은 노드에 저장이 되고 이 파일은 Pod가 죽더라도 데이터는 유지가 되기 때문에 새 Pod가 만들어지면 쿠버네티스가 기존과 똑같이 path를 연결하고 새로 만들어진 App은 기존의 파일들을 그대로 볼 수가 있게 됩니다.

사실 PVC와 PV를 설명 드리려고 이 속성을 쓴 거지 더 쉬운 방법이 있어요!

바로 Pod에 볼륨으로 hostPath 라는 속성을 쓰는 건데, 이렇게 똑같이 path를 지정할 수 있는 내용이 있고요. Pod에 nodeSelector라는 속성을 주면 똑같이 노드를 지정할 수가 있거든요. 그래서 이렇게 쓰는게 더 간결하기도 하고 더 많이 써요

주의사항이 있습니다.

이건 쿠버네티스 문서 내용을 그대로 가지고 온 거고요. 이렇게 [가능하면 hostPath를 사용하지 않는 게 좋다] 라는 경고가 있거든요. 테스트용으로 쓰기 편해서 이 속성을 저장 용도 라고 생각하기 쉬운데, 원래는 노드에 있는 정보를 App이 조회하는 용도로 쓰는 거에요.

예를 들어, 우리가 지금까지 Grafana에서 Loki를 통해서 모든 App들의 로그를 봤었잖아요? 실제 Pod들의 log는 노드에 이 path로 저장이 되고 있고, Loki의 promtail이라는 Pod가 hostPath로 이 경로를 조회하고 있었기 때문에 우리는 모든 Pod의 log들을 Loki를 통해서 볼 수 있었던 거예요. 그래서 여기에 필요한 파일 또는 디렉토리 범위만 정하고 ReadOnly로 마운팅 하라고 써있는 거구요.

그래서 hostPath는 노드의 정보를 이용해야 되는 기능의 App인 경우에 사용하라는 거고, 그래도 테스트 환경에서는 간단하게 쓸 스토리지가 있으면 편하기 때문에 임시 저장용으로 많이 써요

쿠버네티스 개념적으로 Pod를 만드는 주체는 개발자예요. 볼륨 솔루션들에는 여러가지가 있고 각각의 기능에 따라서 써야되는 속성도 달라지기 때문에, 개발자가 Pod를 만들면서 이것까지 신경쓰는건 좀 아니라고 생각을 한거죠. 그래서 인프라 담당자가 볼륨 솔루션들을 관리하는 컨셉으로 PV라는 오브젝트를 만드는 거고요. PVC는 Pod에서 필요한 자원을 요청하는 용도로 개발자가 만드는데, 이렇게 인터페이스 역할을 해주는 게 있어야지 PV 에 솔루션이 변경되더라도 Pod까지 손을 대는 일은 없어지게 됩니다.

그래서 PVC와 PV라는 오브젝트가 있는 건데, 현재는 모두가 쿠버네티스를 다 아는 게 아니기 때문에 개발자와 인프라 담당자 할 것 없이 그냥 쿠버네티스를 아는 사람이 다 하고 있어서 이런 컨셉이 와닿지는 않을 거예요 :)

2. Deployment: 애플리케이션 실행의 설계도

컨테이너 이미지를 그냥 실행할 수도 있지만, 실제 운영 환경에서는 신뢰성 있게 배포, 재시작, 롤백 등을 자동으로 처리해줄 무언가가 필요하죠.
그 역할을 하는 게 바로 Deployment입니다.

원하는 수의 Pod을 유지하도록 보장
변경 시 롤링 업데이트 지원
장애 시 자동으로 새로 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: web
          image: myapp:latest

Deployment

RollingUpdate만을 가지고 Recreate와 Blue/Green에 가까운 효과를 낼 수가 있습니다. 강의 영상에서 저도 종종 사용하는 방법을 공유 드려요.

3. Service: 외부와의 연결 통로

Pod은 IP가 계속 바뀌기 때문에 직접 접근하기 어렵습니다. 이때 Service를 통해 안정적인 접근점을 제공합니다.

주요 기능

내부 혹은 외부 클라이언트가 특정 포트를 통해 애플리케이션에 접근 가능
Pod의 IP가 바뀌어도 항상 고정된 DNS 주소 제공
여러 Pod에 로드밸런싱 가능

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Service

쿠버네티스에서 Service에 대한 개념을 잡는게 가장 어려운데, 이유는 이 Service가 해주는 역할이 많아서 그래요.

4. HPA (Horizontal Pod Autoscaler): 자동 확장 관리

서비스에 트래픽이 몰릴 때, 수동으로 Pod 수를 늘리기보다 자동으로 늘어나는 기능이 있으면 좋겠죠?
바로 이걸 해주는 것이 HPA입니다.

CPU 또는 메모리 사용률 기준으로 Pod 수 자동 조절
트래픽 감소 시 자동 축소

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deploy
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA

CPU에 대한 [이상적인 스케일링] 그래프는 사실 "쿠버네티스를 쓰면 자동으로 스케일링도 해주고 좋아요"라는 홍보를 할 때나 볼 수 있는 내용입니다.

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

[k8s]Application 기능으로 이해하기 - Configmap, Secret

똥선생 — Wed, 2 Jul 2025 22:48:51 +0900

애플리케이션을 Kubernetes 위에 올려 운영하다 보면, 외부 설정 값이나 민감한 정보를 컨테이너 내부에 직접 하드코딩하지 않고 전달해야 하는 상황이 많습니다. 이때 유용하게 사용하는 리소스가 바로 ConfigMap과 Secret입니다.

이 둘은 기능이 비슷해 보이지만, 목적과 사용 방식에 약간의 차이가 있습니다. 각각 어떤 역할을 하고 어떻게 쓰는지 정리해볼게요.

ConfigMap: 환경 설정을 위한 일반적인 Key-Value 저장소

ConfigMap은 애플리케이션이 필요로 하는 설정 값들을 외부에서 주입하기 위한 리소스입니다.
예를 들어, DB 연결 정보(host, port), 외부 API 주소, 기능 플래그 등을 담는 데 사용하죠.

주요 특징

Key-Value 쌍으로 데이터를 저장
민감하지 않은 정보를 저장하는 데 적합
환경 변수, 커맨드라인, 마운트 방식으로 컨테이너에 주입 가능

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: mysql-service
  DB_PORT: "3306"

Secret: 민감한 정보를 안전하게 관리

Secret은 이름 그대로 비밀번호, 인증 토큰, TLS 인증서 등 민감한 데이터를 관리하기 위한 리소스입니다.
ConfigMap과 구조는 비슷하지만, base64로 인코딩된 형태로 저장되며 접근 제어가 좀 더 엄격합니다.

주요 특징

민감한 정보를 base64로 인코딩하여 저장
RBAC으로 접근을 제한 가능
컨테이너 내에 환경 변수나 볼륨 마운트로 전달 가능

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=   # base64 인코딩된 'admin'
  password: c2VjcmV0   # base64 인코딩된 'secret'

ConfigMap과 Secret 생성 예

kubectl create configmap app-config --from-literal=DB_HOST=mysql
kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password=secret

Deployment에 주입 예

env:
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: DB_HOST
- name: DB_USER
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: username

Configmap, Secret 개념 설명

Configmap과 Secret은 Pod에 바로 연결되고요. Object에 속성들을 보면 둘 다 데이터를 담을 수 있어요. 그래서 사용자가 데이터를 넣고 Pod에 값을 주입 시킬 수가 있는데, Pod에 연결되는 속성 이름을 보면 어떤 방식으로 들어가는지 알 수 있습니다.

envFrom은 Pod안에 환경변수로 들어가게 하는 속성이고, 그래서 Configmap을 연결하고 Pod 안에 들어가서 env라는 명령을 쳐보면, 이 Configmap의 data가 주입 된 걸 볼 수가 있어요.

Volume은 Pod와 특정 저장소를 연결하는 속성이고, Secret을 연결하고 Pod 안에 들어가서 마운팅 된 Path를 조회해보면, 이 Secret의 stringData가 있는 걸 볼 수가 있고요.

특별히 어려운 내용은 없죠?

아무리 처음 쿠버네티스를 공부하시는 분이더라도 환경변수와 마운팅의 개념은 기존에도 써왔기 때문에 쉽게 이해할 수 있어요. 그리고 Secret은 이름 부터가 뭔가 비밀스럽게 데이터를 처리해 줄 것 같은 느낌이 있으니까. 쿠버네티스에서 데이터에 어느 정도 보안을 적용해주는 가보다 생각할 수 있죠.

Configmap 기능 설명

Configmap의 데이터가 Pod에 환경변수로 들어간다고 얘기했는데, 환경변수에 들어가는 값은 다양하고요. Data에 내용을 보면 Key, Value 형식으로 spring-profiles-active에 dev가 있죠? 환경 변수로 흔히 들어가는 값인데, 인프라에 다양한 환경 개발/검증/운영 등에 환경이 있고, 이 App이 어느 환경에서 돌아가는 건지 App이 기동되는 시점에 알려주기 위한 변수에요.

다음 환경변수에는 Application Role이라는게 있고. 말 그대로 이 App에 역할을 지정하는 건데, 예를 들어 한 App에 3가지 기능이 있는데, App 하나만 띄어서 모든 기능을 다 쓰기도 하고요. 스케일링 모드라고 해서 이 App을 기능별로 3개를 띄우고 부하가 많은 기능만 별도로 더 띄워요. 요즘은 마이크로 서비스 아케텍쳐를 반영해서 이렇게 만들어진 오픈소스도 많습니다.

밑에 postgresql-filepath는 또 다른 예인데, 이건 여기 Secret 데이터로 연결할 파일에 경로에요. 이 경로는 Pod에 mountPath에서 정하거든요. 그리고 이 경로 DB 정보를 환경변수로 주면, App은 기동 될 때 이걸 읽어서 DB에 접속할 수 있도록 로직이 되있는데, 이 경로를 이렇게 환경변수로 입력해야 Pod에서 이 경로를 바꾸게 됐을 때 App을 다시 빌드해서 새 이미지를 만들지 않고, Configmap만 수정해서 App이 변경된 경로를 인식할 수 있도록 할 수 있겠죠?

이렇게 외부에 변경되는 환경이 생길 때, 그걸 App에 전달해 주기 위한 값들도 있는거고, App 내부적으로 기동되는 시점에 이 환경변수 값에 따라 다르게 처리되는 로직이 있어야 되요.

자 그럼 이제 이 내용을 Pod랑 연결을 하고 Pod가 생성됐을 때 상황을 얘기 해볼께요. 처음에 Configmap에 있는 data의 모든 내용이 컨테이너 내부 환경에 환경변수로 주입이 됩니다. 그리고 이 이미지를 만들 때 이런 자바파일 실행 명령을 넣어놨거든요. 이미지를 만드는건 sprint2에서 배울꺼고 이 명령이 컨테이너 생성 후에 자동으로 동작하게 되고, 이때 환경변수 값이 들어가는데, 만약에 환경변수로 spring-profiles-active가 없었다면 null값이 들어가게 되요.

Secret 기능 설명

동작 확인

영역 파괴의 주범 ConfigMap

기존 VM환경이랑 쿠버네티스 환경의 배포 차이를 보면서 영역 파괴의 주범인 ConfigMap에 대한 얘기를 해볼께요.

각 환경마다 Pod가 만들어지고, 이 Pod에 들어가는 컨테이너는 dockerhub에서 모두 같은 이미지를 다운 받았어요. 하지만 환경마다 다른 값을 주려고 각각에 Configmap을 만들죠. 그리고 이미지 안에 변수값을 받아서 실행하는 명령어가 들어 있어요.

이제 개발환경을 보면 이렇게 spring으로 개발을 하고 여기서 [개발자]가 Properties 파일들이 만들고 관리를 해요. 그리고 Github로 소스를 커밋하면, 여기서부터는 [데브옵스 엔지니어]가 Jenkins에서 이 소스를 받아서 파이프라인을 구성하는데, 소스 빌드와 컨테이너 빌드 과정에서 컨테이너 이미지가 도커 허브로 올라가요. 그리고 컨테이너 빌드 후에 개발환경을 바로 이어서 배포를 할 수 있고, qa와 prod는 필요할 때 배포 버튼을 따로 누르게 구성해 놨다고 해보겠습니다.

그럼 VM 환경의 배포는 어떤지 보겠습니다.

개발 환경과 CI/CD 환경은 비슷하고, [인프라 담당자]가 환경별로 서버를 세팅해 놓습니다. 각 환경별로 OpenJDK도 설치해 놓고요. 이 과정에서 VM 내부에서 사용할 환경변수들을 관리를 하죠.

그리고 배포는 이렇게 되는데, Jar 패키지 파일을 VM 환경에 복사 해놓고, 실행 명령을 직접 날리는데 이때 [데브옵스 관리자]이 App에 환경이나 목적에 맞는 변수를 넣어요. 그리고 환경이나 목적에 맞게 변수값이 채워진 스크립트를 실행시킵니다.

그래서 여기까지 보면 쿠버네티스 환경 이전에는 각자의 영역에서 담당자들이 관리하는 환경변수들이 있었는데, 쿠버네티스가 나오고 이 ConfigMap에서 모든 역할을 다 할 수가 있게 된 거죠. 그래서 ConfigMap을 담당하는 사람이 다른 영역을 넘나들 수 있게 되고 이런 소지를 주는 Configmap을 좀 과격한 표현으로 영역 파괴의 주범이라고 표현을 한 건데.

물론 이 전체를 혼자 다하는 슈퍼 개발자도 있겠지만, 프로젝트가 클 수록 각 영역에 담당자들이 있고요. 현재 이 모두가 쿠버네티스를 다 다룰 줄 아는게 아니기 때문에 만약 개발자가 쿠버네티스를 잘하면, 이 Properties 값들 중에 Pod를 재생성하기만 하면, 다시 빌드하지 않고 바로 반영될 수 있는 값들을 많이 집어넣겠죠? 그러다가 다른 영역에 있는 값들도 넣으면서 일을 주도하게 될꺼예요.

하지만 다른 담당자 입장에서는 본인의 영역을 침범 당한다고 생각할 수 있는데, 참 별거 아닌 기능이지만, 여러 영역에 걸쳐 있는 기능이기 때문에 의견을 잘 조율을 해서 써야 되는 점 주의하시길 바랄께요.

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

[k8s] Application 기능으로 이해하기-Pod(probe)

똥선생 — Wed, 2 Jul 2025 21:20:40 +0900

Pod (probe) - 프로브 기본 개념

Kubernetes에서는 Pod의 상태를 주기적으로 검증하기 위해 probe라는 메커니즘을 사용합니다. 이 기능을 통해 컨테이너의 상태를 API 호출로 확인할 수 있어, 시스템의 가용성과 신뢰성을 높여줍니다

1. Pod란?

정의:

Pod는 Kubernetes에서 가장 작은 배포 단위입니다.
1개 이상의 **컨테이너(Container)**를 감싸고 있으며, 이 컨테이너들은 **동일한 네트워크(IP)**와 스토리지 볼륨을 공유합니다.

왜 Pod가 필요할까?

Docker 같은 환경에서는 컨테이너 단위로 실행했지만, Kubernetes에서는 컨테이너를 Pod로 감싸 관리합니다.
→ 관리 단위를 컨테이너보다 한 단계 높게 만든 개념입니다.

주요 특징

한 Pod 안의 컨테이너들은 로컬호스트(127.0.0.1) 로 서로 통신 가능
보통은 1컨테이너 = 1Pod를 사용하지만, sidecar 패턴(예: log 수집기) 등으로 여러 컨테이너도 가능

2. Probe란?

정의:

Probe는 Kubernetes가 Pod 안의 컨테이너 상태를 검사하는 방법입니다.
애플리케이션이 잘 시작되었는지, 외부 요청을 받을 준비가 되었는지, 정상 동작 중인지를 자동으로 확인합니다.

Probe의 종류

startupProbe
readinessProbe
livenessProbe

probe에는 3가지 종류가 있고 모두 /ready라는 url을 8080포트에 10초 간격으로 날리는데, 각각 성공이랑 실패에 대한 수치는 위 그림처럼 되어있다고 가정.

1. startupProbe – 시작 안정성 확인

Pod이 생성되면 가장 먼저 시작되어 /ready 같은 헬스 체크 API를 호출합니다.
기본적으로 periodSeconds 간격으로 실행되며, 지정된 횟수(failureThreshold)만큼 실패하면 아직 준비되지 않은 것으로 간주합니다.
만약 그 이전에 성공 응답이 오면 초기화가 완료된 것으로 인식하고 종료됩니다.

2. readinessProbe – 외부 트래픽 수용 여부 판단

이 Probe가 성공하면 해당 컨테이너는 서비스 요청을 받을 준비가 됐다고 간주되고,
이 상태에 돌입한 이후부터는 외부 요청이 유입될 수 있게 됩니다.

3. livenessProbe – 지속 동작 상태 확인

앱이 계속해서 정상 동작 중인지 주기적으로 검증하고,
지정된 횟수(failureThreshold) 만큼 실패할 경우 Kubernetes가 해당 Pod를 재시작합니다.

컨테이너 안에 있는 App에서는 /ready라는 url이 사전에 만들어져 있어야 되고 Pod가 만들어지자마자 이 probe 기능들은 동작.

App은 처음 기동 중인 상태가 있고, 이때 쿠버네티스가 startupProbe 기능을 동작 시키면서 오브젝트 속성에 있는 대로 10초에 한 번씩 /ready라는 api를 App에 날린다.

기동 중일 때는 응답을 받을 수 없으니까 계속 실패가 될꺼고 10번 실패하기 전에 한번이라도 응답이 오면 성공으로 간주.

startupProbe 가 성공하면, 쿠버네티스는 startupProbe 기능을 중지 시키고 livenessProbe랑 readinessProbe기능을 동작 시킨다.

그리고 또 설정 한대로 두 probe는 /ready라는 api를 10초 간격으로 반복해서 날리는데 App이 살아있는 동안에는 계속 200 OK 결과를 리턴 해주면서 이 두 probe 동작은 반복

각각의 역할은 다른데,

readinessProbe는 성공했을 때 외부 트래픽을 Pod가 받을 수 있는 상태로 만들어 주면서 서비스가 활성화 되고요. livenessProbe는 app이 살아 있는지를 계속 체크하는 역할.

livenessProbe는 만약 App에 장애가 발생하게 되면, API는 실패를 하게 되고 설정에 따라 두 번을 실패하게 되면 쿠버네티스는 App을 재기동 시킵니다.

실제 흐름 정리

Pod 생성 → startupProbe 가 먼저 실행, /ready 호출 시작
앱이 초기화되지 않아 계속 실패하지만, 성공 응답이 오면 이를 종료
이후 readinessProbe, livenessProbe가 일정 간격(periodSeconds)으로 /ready 호출
readinessProbe가 성공하면 외부 트래픽 수용 가능
livenessProbe 실패 시 앱 재시작 트리거

Probe 설정 세부 팁

startupProbe 실패로 인한 무한 재시작 회피
- 초기화 시간이 길면 실패 임계치와 주기를 충분히 여유 있게 잡아야 합니다.
불필요한 재시작 방지
- readiness와 liveness의 주기를 차별화하여, 잠깐 부하가 걸릴 때 useless 리스타트를 막을 수 있습니다.
다양한 검사 방법 지원
- HTTP(GET), TCP 소켓 연결, 커맨드 실행(ExecAction) 등 probe 방식 다양화 가능

Pod (probe) - 실습 로그 분석

이제부터 실습 후 로그를 함께 분석해보자.

먼저 App이 초기화 되기 시작했고, Spring이랑 Servlet을 초기화 과정이 있다고 하자. 다음으로 Database를 연결하는데 실제 DB가 있는 건 아니고 그냥 코드에 로그만 찍어 놓은 것이다. 그리고 이렇게 App이 기동되는 동안 startupProbe는 계속 실패하며 startupProbe가 찍히는 주기는 설정 해놓은대로 5초 간격이다. 그리고 기동이 완료되면 startupProbe는 성공을 합니다.

근데 이 로그들은 startupProbe가 찍히는 걸 보여드리기 위해서 임의로 코드를 구성했기 때문에 로그가 보이는 것이다. 무슨 말이냐면, 실제 App 상황에서는 쿠버네티스는 Pod가 생성되자마자 startupProbe를 작동 시키기 때문에 사실 처음부터 API는 실패 되고 있었다.

이렇게 App이 기동 되기 전에는 API를 받지 못하기 때문에 실제로는 startupProbe에 로그가 찍힐 수가 없고, 만약에 Was로 tomcat을 썼다면 startupprobe가 찍히는 건 access.log 에서만 볼 수 있게 된다.

그래서 이 로그는 임의로 코드를 구성한 학습적인 상황

이제 기동이 완료가 됐고, [ConfigMap data is loading]은 사용자가 App이 기동 된 후에 외부에 데이터를 가져와서 추가적으로 시스템을 초기화 시키려는 상황. 그리고 밑에 livenessProbe랑 readinessProbe도 찍히기 시작했다.

이때 readinessProbe는 실패했고, livenessProbe만 성공을 했다.

그림 제일 하단에 livenessProbe랑 readinessProbe는 계속 찍히고 있는데, 이제 둘 다 성공을 했다. 그리고 호출 주기는 10초.

근데 여기 보면 readinessProbe가 한번 실패를 했다.

이건 사용자 초기화 구간에는 readinessProbe가 실패 하도록 일부러 만든 것. 그래서 의도 한대로 현재 기능이 정확하게 동작을 해준 것이다.

실습·시나리오 기반 이해

초기화 단계에서 startupProbe만 실행되고 실패 발생
이후 앱이 정상 기동되면 startupProbe가 성공하고 종료
ConfigMap 같은 외부 데이터를 로드하는 과정에서는 readinessProbe를 일부러 실패시키며 외부 요청을 차단
데이터 로드 완료 후 readinessProbe도 성공 → 요청 수용
그 동안 livenessProbe는 계속 동작하며 앱의 실행 상태를 감시

왜 이렇게 구성하나?

앱 초기화 과정 중에는 외부 요청을 받지 않는 것이 안전합니다.
완전히 초기화된 상태에서만 클라이언트 트래픽을 허용하면서,
동작 중 문제가 생길 경우 자동으로 재시작할 수 있도록 하는 흐름이 필요합니다.

기존에는 L4 로드밸런서나 Nginx 등을 써야 했지만, Kubernetes에서는 probe를 통해 이 모든 과정을 제어할 수 있습니다.

Pod (probe) - Application 동작 중심의 프로브 이해

쿠버네티스는 근본적으로 Application을 편하게 관리하기 위하여 만들어 진 것이다.

App 초기화, User 초기화, App기동 및 App 장애처리까지 자동화를 지원한다.

Pod (probe) - API 날려보며 프로브 동작 확인하기

그리고 API를 날려보면서 앞에 설명한 기능들을 확인.

정상상태에서 Pod 삭제시
1. livenessProbe is Succeed
2. readinessProbe is Succeed
바로 파드가 다시 업됨
1. startupProbe 는 내부적으로 실행 중 하지만 로그가 찍히는 건 나중부터
2. 스프링 애플리케이션 시작 중
3. App 초기화 완료
4. 완료(startupProbe 이때부터 찍히기 시작)
데이터베이스 연결 완료
App 시작됨
startupProbe 성공이 찍힘 → 더 이상 시도 안함
이제 readinessProbe 는 실패 livenessProbe 는 성공
ConfigMap 로딩완료
Data 로딩 완료
Started AppApplication in 60.11 sec → 완전히 시작됨
readinessProbe , livenessProbe 둘 다 성공

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

[k8s] 쿠버네티스 첫 오브젝트 잘 끼우기

똥선생 — Tue, 1 Jul 2025 21:07:54 +0900

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

Object 그려보며 이해하기

인프런 강의 카페 실습 자료실 링크 (link)

이 단계에서는 위 강의 자료실에 실습으로 사용될 yaml 파일을 읽어보면서 오브젝트들을 하나씩 그려보고, 각 오브젝트들에 대한 역할이나 기능들을 정리한다.

위쪽부터 Namespace를 보면 Namespace는 Object들을 그룹핑 해주는 역할
Deployment는 Pod를 만들고 업그레이드를 해주는 역할
Deployment는 이 Namespace에 소속
한 namespace 안에서 이 이름은 중복이 되면 안됨.
replicas는 pod 갯수를 조정
strategy는 업데이트 방식 조정, RollingUpdate는 deployment 기능의 핵심
emplate 부터가 이 내용대로 pod가 만들어진다고 보면 된다.
nodeSelector는 pod를 띄울 노드를 선택하는 거고 containers라는 속성이 있고 그 밑에 옵션들이 쭉 있다.

Pod란? – 쿠버네티스의 기본 단위

Pod는 쿠버네티스(Kubernetes)에서 배포 가능한 가장 작은 컴퓨팅 단위입니다. 한 개 이상의 컨테이너(보통은 하나)를 하나의 논리적 단위로 묶은 것으로, 쿠버네티스에서 애플리케이션을 실행할 때 가장 기본이 되는 단위입니다.

왜 Pod인가?

Docker 컨테이너만으로는 다중 애플리케이션 간의 협업, 자원 공유, 네트워크 일관성 등을 관리하기 어렵습니다. 이를 해결하기 위해 쿠버네티스는 Pod라는 추상화 계층을 제공합니다.

Pod는 하나의 애플리케이션 인스턴스라고 볼 수 있으며, 그 안에는 다음 요소들이 포함됩니다:

하나 이상의 컨테이너
공유 스토리지 (볼륨)
고유 IP 주소
설정 정보 (환경변수, ConfigMap 등)

그리고 밑에 envFrom가 있고 configmap과 연결이 되어 있는데, Application에 환경 변수랑 관련된 부분이고 configmap은 그 값을 제공해 주는 역할
그 밑에 프로브들이 3개가 있는데 startupProbe는 App이 잘 기동이 됐는지 체크를 하고 있다가 기동이 안 되면 App을 재기동
잘 됐으면 이 밑에 readinessProbe랑 livenessProbe를 시작
readinessProbe는 App에 트래픽을 연결 할 건지를 결정하는 속성
livenessProbe는 App이 정상이 아니면 재시작을 시킬 건지 판단하는 속성
resources는 pod에 CPU랑 memory를 할당을 시킬 거고 최대 limit까지 쓸 수 있다는 설정이 있는데 이걸 설정하지 않으면 pod가 노드의 자원들을 모두 사용
volumeMounts에서 mountPath는 pod 내부에 만들어지는 디렉토리, 이 이름이랑 volumes에 이 이름이 매칭이 되서 실제 persistentVolumeClaim이라는 object랑 연결
그리고 secret-datasource도 name으로 연결이 되면서 secret object랑 연결

다음으로 Service를 보자.
namespace에 속한 object고 name이랑 labels이 있고, 그리고 밑에 selector랑 ports, type이 있는데, 이 Service의 역할은 pod한테 트래픽을 연결
위에서 namespace안에는 이름이 중복되면 안 된다고 했었는데, 확히는 같은 종류의 object끼리에 해당 되는 말이다. 그래서 Service랑 Deployment는 서로 다른 object라 이름이 같아도 된다.
ConfigMap을 보면 pod의 환경변수 값을 제공하는 역할 이렇게 metadata 3세트랑 그리고 data가 있는데 이게 아까 언급했던 환경변수로 들어갈 값의 내용
그리고 밑에 Secret도 ConfigMap이랑 비슷한데 pod에 좀 더 중요한 값을 제공하는 역할

그리고 PersistentVolumeClaim이 있고 pod에서 pv를 지정할 때 사용을 하는데, 밑에 저장 공간을 얼마나 사용할지 그리고 이 저장 공간의 accessModes로 읽기/쓰기가 가능하다는 옵션,
그리고 PersistentVolume인데, 실제 Volume을 지정하는 역할
object들은 크게 두 분류로 나뉘어요. Namespace랑 PersistentVolume은 Cluster Level의 Object
Deployment랑 Service들은 Namespace Level에 Object라고 해요.
그리고 각 object들은 자신의 level이 있기 때문에 Deployment는 PV처럼 Cluster level에 만들어 질 수가 없다.
다시 PV로 돌아와서 , local이 중요한데 path를 volume으로 사용하겠다는 내용
그리고 그 대상 노드는 밑에 nodeAffinity가 있는데, 좀 복잡해 보이지만, nodeSelector랑 똑같이 결국 Master Node를 지정한다는 내용, 그래서 여기에 path가 사전에 없으면 PV를 만들 때 문제가 생기기 때문에 디렉토리를 미리 만들어 준 것.

마지막으로 HPA인데, 부하에 따라 pod를 늘려주고 줄여주는 스케일링 역할
scaleTargetRef로 그 스켈링 대상을 지정을 하고, min/maxReplicas는 최소 두 개의 pod를 유지를 하고 있다가 부하가 생기면 최대 4개까지 늘어나도록 설정을 한 것.
그리고 metrics라는 설정은 pod의 cpu가 평균 40%가 늘어나면 스케일 아웃
그리고 밑에 behavior는 pod가 한번 증가를 한 후에 600초, 그러니까 10분 동안 또 pod가 추가적으로 늘어나지 않게 하는 설정
pod가 2개에서 3개로 늘어나자마자 부하가 더 증가한다고 해서 바로 4개로 늘리고 싶진 않을 때 이런 설정을 함.
그리고 마지막으로 namespace에 대한 기능을 하나는 namespace를 삭제하면 이 안으로 만든 모든 object가 같이 삭제가 된다. PV는 namespace에 속하지 않기 때문에 별도로 한번 더 삭제를 해 줘야 된다.

UTP 케이블의 종류와 특징

똥선생 — Tue, 1 Jul 2025 18:00:48 +0900

이더넷 케이블(Ethernet Cable)이란?

이더넷 케이블은 근거리 통신망(LAN) 환경에서 가장 널리 사용되는 유선 네트워크 케이블입니다. 흔히 랜선, UTP 케이블이라고도 불리며, RJ-45 커넥터를 통해 컴퓨터, 공유기, 스위치 등 네트워크 장비를 서로 연결합니다.

주요 특징

**4쌍(총 8가닥)**의 연선(Twisted Pair) 구성
TIA/EIA-568 표준 기반으로 제작 (T568A, T568B)
주로 RJ-45 단자 사용
크로스 케이블, 다이렉트 케이블로 구분 (현재 대부분의 장비는 양단 다이렉트 케이블로 제작시에도 정상 작동)
케이블의 성능은 Category(Cat) 등급으로 표현 (Cat 5e, 6, 7 등)

구조와 배열

8가닥의 선은 4쌍으로 나뉘며, 각각 꼬여있어 노이즈 방지 효과를 줍니다.
꼬임이 유지되지 않으면 신호 손실이 커지고 속도 저하가 발생할 수 있습니다.
케이블 단자 연결 방식:
- 다이렉트 케이블: 동일한 배열 (T568B-T568B)
- 크로스 케이블: 교차 배열 (T568A-T568B)

최근 대부분의 장비는 Auto MDI/MDI-X 기능을 통해 크로스/다이렉트를 자동 인식합니다.
즉, 양쪽 모두 다이렉트 케이블로 제작하는 것이 보편적입니다.

차폐 방식에 따른 분류

비차폐	UTP	가장 일반적인 형태, 차폐 없음
호일 차폐	FTP	전체를 알루미늄 호일로 차폐
브레이딩 차폐	STP	금속 망으로 차폐하여 노이즈 방지 강화
이중 차폐	S/FTP	페어마다 호일, 외부는 금속망으로 이중 차폐

경험상 보편적인 네트워크 환경에서는 UTP를 사용합니다.
고속 네트워크 환경(Cat.7 이상)에서는 STP 혹은 S/FTP 형태를 사용하는 경우가 있습니다.

카테고리별 성능 비교

⚠ Cat 6e는 공식 규격이 아닌 비공식 마케팅 명칭입니다.

PoE(Power over Ethernet)

이더넷 케이블을 통해 **데이터와 전원(48V DC)**을 동시에 전달하는 기술입니다.

PoE 지원 장비: IP 카메라, VoIP 전화기, 무선 AP 등
Cat.5 이상 케이블에서 사용 가능

랜 케이블 직접 제작

필요한 도구: RJ-45 단자, 케이블, 스트리퍼, 크림퍼(랜툴)

피복 제거 후, 8가닥 배열을 정렬
T568A 또는 T568B 배열에 따라 자르기
RJ-45 단자에 삽입 후 크림핑

Cat.7 이상 케이블은 구조상 DIY가 어렵고, 사전 제작된 제품 사용 권장

요약

항목	설명
커넥터	RJ-45 (8P8C)
내부선	4쌍(8가닥) Twisted Pair
케이블 유형	UTP, FTP, STP, S/FTP 등
배선 방식	다이렉트(T568B-T568B), 크로스(T568A-T568B)
성능 기준	Cat 5e ~ Cat 8
전원 전송	PoE 가능 (Cat 5 이상)

사설망(Private Network)와 전용 회선, 그리고 VPN의 탄생

똥선생 — Tue, 1 Jul 2025 17:15:50 +0900

사설망(Private Network)와 전용 회선, 그리고 VPN의 탄생

인터넷의 급속한 확산은 IPv4 주소의 빠른 고갈을 불러왔습니다. 약 43억 개에 달하는 IPv4 주소는 처음엔 충분해 보였지만, 가정과 기업, 모바일 디바이스의 수요가 폭증하면서 점차 부족해지기 시작했죠. 이 문제를 해결하기 위해 등장한 것이 바로 사설망(Private Network) 입니다.

사설망이란?

사설망은 IPv4 주소 중 일부를 특정 용도로 제한하여 내부망에서만 사용할 수 있도록 한 네트워크 대역입니다. 대표적인 사설 IP 주소 대역은 다음과 같습니다:

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

사설망의 핵심 장점은 단지 공인 IP를 아낄 수 있다는 것에 그치지 않습니다. 외부 인터넷과의 분리로 보안성이 강화되고, 내부 시스템을 독립적으로 운영할 수 있기 때문입니다. 데이터베이스, 서버, 프린터 등 외부에 노출될 필요가 없는 자원들은 사설 IP를 활용해 네트워크를 구성하게 됩니다.

전용 회선(Leased Line)의 등장

사설망이 널리 활용되면서, 서로 떨어진 지역 간의 사설망을 안전하게 연결할 수 있는 기술적 필요성이 높아졌습니다. 이때 등장한 것이 전용 회선입니다. 이는 통신사업자의 네트워크 중 일부를 전용으로 임대하여 본사와 지사를 안전하게 연결하는 방식입니다.

공인 인터넷을 거치지 않기 때문에 보안성이 뛰어남
사설 IP 기반으로 통신 가능

하지만 가장 큰 단점은 바로 비용입니다. 회선 자체의 설치, 유지관리, 대역폭 사용량에 따라 발생하는 고비용은 기업에 상당한 부담으로 작용합니다.

VPN(Virtual Private Network)의 탄생

고비용의 전용 회선을 대체할 수 있는 방법으로 VPN이 등장했습니다.

“VPN은 공공망(인터넷)을 이용해 사설망처럼 안전하게 통신할 수 있게 해주는 기술”입니다.

VPN의 핵심 목적 2가지

공인 인터넷을 사용하면서도 사설망과 사설망을 연결
인터넷이라는 불안정한 매체를 통해 암호화된 안전한 통신 제공

이를 위해 캡슐화(Encapsulation), 암호화(Encryption), 터널링(Tunneling) 기술이 사용됩니다. 이 과정에서 외부에서는 내부 데이터의 내용을 확인할 수 없고, 오로지 인증된 사용자와 장비만이 터널을 통해 통신할 수 있습니다.

VPN의 분류

VPN은 다양한 기준으로 분류할 수 있지만, 가장 실무적인 기준은 접속 방식입니다.

분류 기준종류

접속 방식	Site-to-Site / Client-to-Site
프로토콜	IPSec / SSL / PPTP / L2TP 등
통신 계층	L2 / L3 / L4 / L7 기반

여기서는 가장 많이 사용되는 두 가지 방식인 IPSec VPN과 SSL VPN을 중심으로 살펴봅니다.

IPSec VPN (Site-to-Site)

사용 용도: 본사-지사 간 네트워크 연결
암호화 계층: L3 (Network Layer)
터널링 프로토콜: IPSec
특징: 라우팅 중심, 네트워크 전체를 터널로 연결

이 방식은 두 개 이상의 사설망을 안전하게 연결하는 데 사용되며, 외부에서 들어오는 사용자의 개별 인증은 필요하지 않습니다. 네트워크 간 트래픽 자체를 암호화하고, 내부 자산을 통째로 공유해야 할 때 주로 사용됩니다.

SSL VPN (Client-to-Site)

사용 용도: 외부 사용자(직원)가 사내망 접속 시
암호화 계층: L4~~L7 (Transport~~Application Layer)
터널링 프로토콜: SSL 또는 TLS
특징: 웹브라우저 기반 접근, 사용자 인증 필수

SSL VPN은 유연성이 높고 접근이 쉬워 재택근무, 출장 중 원격 접속에 가장 널리 사용됩니다. 보통 사용자는 웹 브라우저나 전용 클라이언트를 통해 사내 시스템에 접속하고, 접근 권한은 사전에 부여된 인증 정보에 따라 달라집니다.

정리하며

항목	전용 회선	VPN
비용	좋지 않음 (그림보다 비싸면)	비교적으로 저렴
보안성	최고	다양한 것이 담당가능
구성 난이도	높음	조금 느려도 간단
접근성	제한적	높음 (여러 것이 가능)

VPN은 사설망을 외부 환경에서도 안전하게 사용할 수 있게 만들어 주는 핵심 인프라이며, 보안과 효율을 동시에 추구하는 현대 네트워크 환경의 필수 구성요소입니다.

[k8s] 쿠버네티스(v.1.27.2) 쉽고 빠르게 설치하자

똥선생 — Tue, 1 Jul 2025 11:29:29 +0900

쿠버네티스(v.1.27.2) 쉽고 빠르게 설치하는 방법

Virtualbox 설치 (link)
Vagrant 설치 (link)

Vagrant 스크립트 실행 (윈도우 > 실행 > cmd > 확인)

# Vagrant 폴더 생성
C:\Users\사용자> mkdir k8s
C:\Users\사용자> cd k8s

# Vagrant 스크립트 다운로드
C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/Vagrantfile

# Rocky Linux Repo 세팅
C:\Users\사용자\k8s> curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/rockylinux-repo.json
C:\Users\사용자\k8s> vagrant box add rockylinux-repo.json

# Vagrant Disk 설정 Plugin 설치 
C:\Users\사용자\k8s> vagrant plugin install vagrant-disksize

# Vagrant 실행 (VM생성)
C:\Users\사용자\k8s> vagrant up

MobaXterm 설치 (link)
Master 원격 접속 : 192.168.56.30:22 (root/vagrant)
Pod 확인
```
kubectl get pods -A
```
대시보드 접속 URI : https://192.168.56.30:30000/#/login
- FAQ : virtualbox 설치 안될 때 (link), vagrant up 안될 때 (link), dashboard 관련 (link), virtualbox Host-Only Network cidr 변경 (link)
- Cafe : 쿠버네티스 빠른 설치 카페 참조 (link)

쿠버네티스 무게감 있게 설치하는 방법 1/2

먼저 설명에 시작은 내 PC에 Virtaulbox랑 Vagrant를 설치한 상태고요. 제가 만든 Vagrant 설치 스크립트를 받으면 위에 내용이 나와요. 그리고 이 스크립트는 크게 [Virtualbox로 Rocky Linux를 생성]하는 파트랑 [kubernetes를 설치]하는 파트로 구분되는데 먼저 Virtualbox로 VM을 생성하는 걸 설명 드릴께요.

우측 스크립트를 위에서 부터 보면, OS를 [rocky linux 8]버전으로 설치하라는 내용이고, 처음 설치할 때는 이 이미지를 다운 받는데 시간이 좀 걸려요. 그리고 [master-node]는 Virtualbox 입장에서 생성된 VM에 이름을 붙여주는 부분인데, Virtualbox UI 상으로 봤을 때 보이는 이름 이예요. 그리고 밑에 hostname 을 지정하는 부분이 있고, [k8s-master] 라고 넣으면, 나중에 원격접속으로, 리눅스에 들어 갔을 때, 나오는 호스트 이름입니다.

그리고 밑에 [private_network]는 virtualbox에 Host-Only Network 라고 해서, 내 PC 에서만 사용할 수 있는 네트워크망을 만들어 주고, 스크립트에서 IP를 주면 내 Linux에 그 IP가 할당됩니다. 그래서 우리는 내 PC에서 이 IP로 원격 접속을 하면 Linux OS에 들어갈 수 있게 되는 거고. 브라우저를 통해서 kubernetes dashboard에 접속 할 수도 있게 되요. 이렇게 이 스크립트 한 줄로 Host-Only Network가 만들어지고 IP가 할당 되는데, 스크립트에 넣지 않아도 Vagrant가 기본적으로 만들어주는 네트워크가 있어요.

바로 NAT 라는 네트워크고 입니다. IP도 알아서 할당 돼요. 이 NAT의 역할은 내 VM을 외부 인터넷이랑 연결 시켜줍니다. 그래서 이따가 쿠버네티스를 설치할 때 필요한 패키지들을 받는데 사용하고요

실제 내 PC에 할당된 Network는 공유기에서 할당 받은 상태죠. 제 PC의 경우 [192.168.219.100]의 주소를 할당 받았고요. 제 공유기는 192.168.219까지는 고정이고, 뒤에 4번째 자리는 1~255까지 만들 수 있는데 자동으로 100이 할당 된 거예요.

근데 Host-Only Network를 보면 디폴트로 192.168.56까지 고정이고, 네 번째는 1~255까지 만들 수 있는 네트워크 입니다.

네트워크를 생성할 때 cidr 을 정하면, 이렇게 지정한 범위 내에서 IP가 할당 되는데, 네트워크 원리는 잘 몰라도, 최소한 대역들이 겹치면 안된다는 건 알고 계셔야 돼요. 겹치게 되면 내 공유기랑 Virtualbox가 똑같은 IP 를 만들 수 있게 돼서 IP 충돌이 나요. 근데 이 공유기 환경이 개인 마다 다른 부분이라서 혹시 원격 접속이 안되시는 분은 본인에 Network 대역을 확인해 보시고요. 부득이한 경우 Host-Only Network에 cidr 을 수정해 주면 돼요.

이번엔 자원(resource)을 볼께요.

스크립트를 보면 VM에는 Memory는 4G고 CPU는 4Core를 잡았어요. 제 PC에 자원을 보면 제 PC는 4Core, 16G Memory거든요. 여기서 분명 Memroy는 내 자원에서 나눠 주는 거라 VM에 자원 할당한 게 이해 되는데, CPU를 이렇게 다 줘버리면 내 PC는 괜찮을까 걱정되는 분이 계실 거예요.

근데 이 두 자원의 속성을 보면 Memory는 서로 할당된 공간을 침범하면 안돼요. A프로그램이 쓴 메모리 공간에 B프로그램이 침범해서 내용을 바꿔버리면 안되잖아요? 그래서 꼭 자원을 철저하게 분할해서 써야 되는 성격이라면, CPU는 필요로 하는 순간에 서로 나눠 쓰는 자원이예요. 그래서 현재 이 CPU 할당에 의미는 내 PC CPU가 필요할 때는 4 Core를 다 쓸 수도 있고. VM에서도 필요할 때도 최대 4Core를 다 쓸 수 있도록 설정 한 건데, 만약 둘 다 CPU가 필요한 상황이라면 이 4core 자원을 나눠쓰고요. 대신 처리속도는 좀 느려지지만 문제는 없어요.

참고로 쿠버네티스 설치 문서에 권고하는 CPU는 2Core 이상입니다.

이 CPU와 Memory에 대해서 제가 4 Core를 준 이유와 각자가 작업 유형에 맞게 변경을 하시라고 자세히 설명 드렸지만, 이 두 자원에 대한 성격은 쿠버네티스에도 Pod에 자원을 할당하거나 Pod가 늘어나는 설정을 할 때, 정말 중요하게 고려해야 되는 포인트라서 이 자원에 성격을 자세히 얘기 해봤어요.

쿠버네티스 무게감 있게 설치하는 방법 1/2 [구간별상태확인]

설치를 진행하고 실행하는 동안 다양한 오류가 발생할 수 있는데,

해당 챕터부터는 내용이 방대하여 인프런 강사님의 카페글을 통해 확인해주시면 됩니다.

https://cafe.naver.com/f-e/cafes/30725715/articles/24?boardtype=L&menuid=13&referrerAllArticles=false&page=2

쿠버네티스 무게감 있게 설치하는 방법 2/2

쿠버네티스 설치는 확실히 쿠버네티스 문서(link)를 보는게 좋습니다.

쿠버네티스 무게감 있게 설치하는 방법 2/2 [구간별상태확인]

설치를 진행하고 실행하는 동안 다양한 오류가 발생할 수 있는데,

그전에 구간별 상태를 점검해야 합니다.

해당 카페글을 통해 대부분 처리가 가능합니다.

https://cafe.naver.com/f-e/cafes/30725715/articles/28?menuid=13&referrerAllArticles=false&page=2\

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

[k8s] 쿠버네티스 컨테이너 한방 정리

똥선생 — Tue, 1 Jul 2025 07:51:50 +0900

기술의 흐름으로 이해하는 컨테이너

쿠버네티스는 이제 [컨테이너]랑 [가상화] 그리고 [데브옵스]속에 깊숙히 자리잡고 있습니다. 그래서 이 세 가지를 알아야 쿠버네티스를 더 잘 알 수 있게 되는데, 이 단어들은 정말 큰 개념이라서 그냥 용어 설명으로는 이해하기 힘들어요. 그래서 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.

Kubernetes = 컨테이너 오케스트레이션 플랫폼

Kubernetes는 단순한 컨테이너 실행을 넘어서 자동 배포, 확장, 장애 복구, 상태 관리를 책임지며, 클러스터 내 컨테이너들의 상태를 선언적 방식으로 유지합니다.
즉, “원하는 상태”를 정의하면 Kubernetes가 자동으로 맞춰 줍니다.
Kubernetes는 마치 **“연주자(컨테이너)들이 지휘자(k8s) 아래 협연하는 오케스트라”**와 같습니다:
개별 컨테이너는 연주자처럼 작동하고, Kubernetes는 전체 조화를 책임지는 지휘자 역할을 합니다

클러스터 아키텍처

Control Plane (마스터 노드)

API Server: 사용자 요청과 kubectl 명령을 받음
Scheduler: Pod를 어느 노드에 배치할지 결정
Controller Manager: 정의된 상태를 지속적으로 유지하기 위한 루프 수행
etcd: 클러스터 상태를 저장하는 키-밸류 DB

Worker Node

kubelet: Pod의 상태를 감지하고 컨테이너 런타임에게 실행을 요청
kube-proxy: 네트워크 라우팅 및 로드 밸런싱 담당
Container Runtime: Docker, containerd, CRI-O 등 컨테이너 실행 환경

1. 컨테이너(Container)

정의

컨테이너는 **애플리케이션과 실행 환경(라이브러리, 설정 등)**을 하나의 패키지로 묶어서 어디서든 실행 가능하게 해주는 기술입니다.
가볍고 빠르게 실행되며, 서버 간 **이식성(portability)**이 뛰어납니다.

기술 흐름 속에서 바라본 컨테이너

컨테이너는 가볍고 빠른 격리 환경을 제공하는 기술로, OS의 격리·자원 제어 핵심 기능(namespace, cgroup, chroot)을 활용합니다.
이러한 리눅스 커널 기능을 모아 ‘LXC(Linux Container)’라는 초기 컨테이너 기술이 탄생했고, 이후 Docker 같은 사용 편의성이 뛰어난 도구들이 등장하며 널리 보급되었습니다

특징

OS 커널을 공유해서 가볍고 빠름
빠른 시작, 빠른 종료
독립적 실행 → 충돌 없이 여러 개 실행 가능
대표 도구: Docker, Podman

비유

“컨테이너는 도시락”
애플리케이션이 음식이라면, 컨테이너는 그 음식이 망가지지 않도록 담긴 도시락통입니다. 어떤 식탁(서버)에서도 열면 바로 먹을 수 있죠.

2. 가상화(Virtualization)

정의

하나의 물리 서버(하드웨어) 위에서 **여러 개의 가상 머신(운영체제 포함)**을 실행시켜 마치 여러 대의 서버처럼 활용하는 기술입니다.

종류

서버 가상화 (ex. VMware, Hyper-V, KVM)
데스크탑 가상화
네트워크/스토리지 가상화

특징

VM은 **자기만의 운영체제(게스트 OS)**를 갖고 있음
자원(메모리, CPU 등)을 분할해 사용
보안적으로 격리성이 높음

3. 데브옵스(DevOps)

정의

DevOps = Development(개발) + Operations(운영)
개발자와 운영팀이 협업하여, 빠르고 안정적인 서비스 배포를 목표로 하는 문화이자 방법론입니다.

핵심 목표

자동화: 테스트, 배포, 모니터링 등을 자동화
지속적 통합/배포(CI/CD): 빠르게 코드 수정 → 테스트 → 배포
협업과 커뮤니케이션 향상
인프라를 코드로 관리(Infrastructure as Code)

주요 도구

CI/CD 도구: Jenkins, GitHub Actions, GitLab CI
컨테이너/오케스트레이션: Docker, Kubernetes
IaC: Terraform, Ansible
모니터링: Prometheus, Grafana

비유

예전에는 개발자와 운영팀이 따로 놀았는데, 데브옵스는 둘이 한 팀이 되어 “기계처럼 매일 안정적으로 배포하는 시스템”을 만드는 것이라고 보면 됩니다.

1. Linux OS 흐름

컨테이너를 잘 알기 위해서는 Linux에 대해서 먼저 알 필요가 있습니다.최초에 OS로 unix가 있었고, 한참 시간이 지나고 linux가 나왔어요. 그리고 이 linux를 기반으로 현재까지도 엄청 많은 배포판들이 만들어지고 있습니다.

하지만, 다행이도 우리는 이 두 가지 배포판만 알고 있어도 충분해요.debian이랑 redhat 계열인데, debian linux는 커뮤니티용이라고 해서 무료고요. redhat linux는 redhat 이라는 기업에서 만들었고, 유료에요.

쿠버네티스를 설치할 때도 이렇게 이 두가지 배포판을 기준으로 설치 가이드를 제공합니다. 데비안과 레드햇 계열에 대한 자세한 얘기는 강의 중에 설명드리고, 여기선 기업용으로 쓰는 redhat에 대해 좀 얘기를 해볼께요.

redhat에서 linux 배포판이 만들어지는 순서가 있어요. 최초에는 fedora linux라고 해서 새로운 기능을 개발하는 버전이 있고, 이건 무료고요. 이 기능들이 안정화되면 redhat linux로 이름을 바꿔서 릴리즈를 합니다. 기업은 이걸 설치하면 유지보수 비용을 내야되는 유료 버전이고, redhat enterprise linux 앞자만 따서 RHEL, 렐 이라고도 통상 불러요. 그래서 이걸로 기업들이 설치를 하면 유지보수 비용을 내야 되는 유료 버전 이고, 그리고 이걸 복사해서 만든 게 centOS 배포판 이예요. rhel이랑 똑같이 안정화 버전인데, 무료로 쓸 수 있습니다.

기업에서는 주로 redhat 계열을 많이 쓰고, 특히 centOS의 점유율이 높은데 centOS 8은 2021년에 지원을 종료 했고, centOS 7은 2024년도에 지원이 종료가 되거든요. 이 centOS가 종료되는 배경을 좀 말씀을 드리면 시장 점유율이 ubuntu가 압도적이고. 다음은 centOS랑 debian이 2, 3위를 왔다갔다 해요. redhat은 2%지만, 이 수치가 그래도 기업 배포판 중에 1위고요. 이 1위가 된 배경에는 사람들한테 centOS를 무료로 쓰게 해주면서 자연스럽게 redhat을 선택하게 하는 그런 전략이 있었거든요. 근데 현재 redhat은 IBM에 인수가 된 상태예요. 그리고 IBM의 새로운 전략은 centOS에 점유율을 rhel로 당기려는거 같아요.

왜나하면 현재 redhat 배포판을 만드는 순서가 이렇게 변경됐거든요.

처음엔 마찬가지로 fedora를 통해서 기능 개발을 하고, centOS대신 centOS Stream이라고해서 이 기능들을 테스트하는 배포판이 생겼어요. 테스트 배포판(테스트베드)이라고 생각을 하면 되는데 여전히 무료지만, 이 배포판에서는 바이너리 호환성 보장 안될 수 있다는 얘기를 해요. 무슨 내용인지 몰라도 이제 쓰면 안되나 싶은 생각이 들죠?

그리고 테스트 과정이 끝나면, 안정화 버전인 Redhat Linux가 됩니다. 이렇게 배포판을 만드는 프로세스가 바꿨어요. 그래서 기존에 centOS를 쓰던 기업들은 앞으로 고민을 좀 해봐야 되는 게 지금 상황이고요. 아래와 같이 4가지 방법이 있는데 아래와 같습니다.

이렇게 4가지 선택지 중에 전 4번을 선택을 했습니다.

그리고 AlmaLinux와 RockyLinux 중에서 Rocky Linux를 선택한 이유는 아래와 같아요.

구글 트렌드에서 키워드 검색량 확인 (link)
CentOS 공동설립자 중 한명 만들었음 (link)
클라우드 서비스에서 VM 생성을 Rocky Linux로 하는 사례들 확인
Github Watch/Fork/Start 비교 (rocky link), (alma link)

2. Container 흐름

자, 이제 컨테이너에 대해서 얘기를 해 볼꺼예요. 지금까지 봐듯이 linux는 꾸준히 발전을 했고, 내부적으로도 많은 코어 기술들이 개발이 됐는데 그중 하나가 격리 기술이예요.

chroot라고 해서 사용자 격리를 시작으로 파일이나 네트워크를 분리하는 기술들이 만들어 졌고요. 한참 지난 후에 cgroup이라고해서 각각에 App마다 cpu나 memory를 할당을 할 수 있게 됐어요. namespace는 보통 App 하나가 하나의 프로세스를 차지하거든요. 이 프로세스를 격리 시켜주는 기술이 만들어 지면서 우리는 이제 각각의 App을 소위 말하는 [독립적인 환경]에서 실행을 시킬 수 있게 됩니다.

그리고 다음으로 이 기술들을 집약해서 정리한게 LXC라고 해서 linux container에 줄임말 이예요. 이 컨테이너의 어머니이자, 최초의 컨테이너죠. 그리고 이 기술을 기반으로 만들어진 이번엔 컨테이너에 대명사죠. Docker, 요즘은 위세가 많이 죽긴 했어요.

이전까지 컨테이너 기술은 저 같은 평범한 개발자들이 쓰기엔 좀 어려웠다면 docker는 이걸 누구나 쓰기 쉬운 형태로 만들었습니다. 요즘 잘 정리된 블로그 몇 개만 봐도 대강 이해해서 내 OS에 컨테이너를 띄울 수 있죠.

docker가 나오고 rkt라고 rocket이라는 컨테이너가 나와요. docker가 보안에 안 좋은 점이 좀 있는데, 이 부분을 공략을 하면서 더 안정적인 컨테이너를 강조를 했고 실제 docker보다 성능도 더 좋다고 해요. docker가 보안에 안 좋은 점은 root권한으로 설치하고 실행을 해야 되기 때문인데, 현재는 rootless 설치 모드가 생겨서 보안이 강화가 됐습니다.

한편 쿠버네티스는 점점 표준으로 정착이 되고 있고, 현재는 컨테이너간의 싸움 중입니다. 초반에 docker가 보안에 약하다는 것 까지는 사실 docker 대세에 크게 문제가 없었거든요. 시간이 지나면 충분히 보완 될꺼라는 기대도 있었고 실제로 보완이 됐죠. 근데 docker 위세가 조금씩 꺽이기 시작한 이유가 뭐냐면, 쿠버네티스에서 docker가 빠진 다는 얘기가 계속 있었어서 그래요. 그 이유는 docker가 쿠버네티스와 인터페이스가 잘 안 맞아서 그렇거든요. 물론 처음엔 docker를 메인으로 쿠버네티스가 만들어졌죠. 근데 쿠버네티스가 표준화가 될 수록 docker가 걸림돌이 되고 있는 상황이예요. 이제 누가 쿠버네티스랑 호환성이 좋은지가 컨테이너를 선택하는 중요한 결정요소가 됐습니다.

그 이후에 나온 대표적인 컨테이너가 containerd랑 cri-o고요. containerd는 docker에서 컨테이너를 만들어주는 기능이 분리된 거예요. docker가 설치할 땐 간단해 보여도 엄청 많은 기능들이 녹아진 엔진이거든요. 그 큰 엔진에서 containerd 프로젝트만 분리 되서 나왔고 CNCF에 기부 됩니다.

번외로, docker는 현재 mirantis라는 회사에 인수된 상태예요. docker를 정말 많이 쓰지만 기술 투자 대비해서 수익이 큰 편은 아니었던 거 같아요. 그래서 mirantis라는 회사에 인수가 됐고 이 mirantis는 openstack 프로젝트를 하고 있는 회사 거든요. 이 openstack이 뭐냐면, kubernetes 이전에, 가상화에 대세라고 하긴 좀 그렇고, 가장 큰 가능성으로 가상화 시장을 선도한게 openstack 이예요. 저도 개인적으로 한 3년 정도 openstack 관련된 일을 했었고, 그래서 다음 가상화를 설명하는 강의에서 최대한 재미있게 얘기를 해 드릴께요. 여튼 docker가 mirantis에 인수된 이후부터 이 kubernetes 인터페이스를 잘 맞추려고 하고 있기 때문에 쿠버네티스에서 docker는 빠지진 않게 됩니다.

3. Container Orchestration과 Container 흐름

강의 영상에서 컨테이너 오케스트레이션(쿠버네티스)과 컨테이너(컨테이너 런타임) 간에 한 단계 더 깊은 흐름을 이야기 합니다.

가장 핵심은 쿠버네티스의 kubelet 변화와 그리고 이에 따른 컨테이너 런타임들 간의 흐름이예요. 바로 CRI가 어떤 배경에서 만들어졌고, 쿠버네티스 버전이 올라가면서 CRI가 어떤 방향으로 바뀌는지, 그리고 그에 따른 컨테이너 런타임들 간의 변화를 설명드립니다.

그리고 컨테이너에서 절대 빼놓으면 안되는 OCI가 있습니다. 컨테이너 표준인데, 컨테이너 런타임들은 이걸 잘 지키고 있기 때문에, 우리는 런타임을 바꾸더라도 기존에 만들었던 이미지를 그대로 사용할 수 있어요

해당 블로그 내용은 [쿠버네티스 어나더 클래스] 인프런 강의를 정리한 것입니다.

강의 링크 : https://inf.run/NzKy

광케이블(Fiber Optic Cable) 종류와 특징

똥선생 — Mon, 30 Jun 2025 17:46:59 +0900

광케이블(Fiber Optic Cable)

광케이블은 유리 또는 플라스틱으로 만든 가는 섬유(광섬유)를 다수 묶어 구성한 케이블로, 빛을 이용해 데이터를 전송하는 고속 통신 매체입니다. 주로 장거리 통신과 대역폭이 높은 네트워크 환경에서 사용됩니다.

광케이블의 주요 용도

고속 TCP/IP 네트워크 (10Gbps 이상) (1Gbps급에서는 UTP or 광케이블 선택)
SAN(Storage Area Network) 환경에서 서버와 스토리지 간 연결
데이터 센터, 금융 네트워크, 통신사 간선망 등

광케이블의 구조

코어(Core)	빛이 전송되는 중심부. 유리 또는 플라스틱 소재
클래드(Cladding)	코어 주변에 위치한 보호층. 빛이 코어를 벗어나지 않도록 반사
버퍼 코팅(Buffer Coating)	물리적 손상으로부터 광섬유를 보호하는 플라스틱층

전송 속도 및 거리 비교

광케이블은 구리 케이블보다 100배 이상 빠른 속도를 제공할 수 있습니다.
최대 전송 속도: OM5 기준 100Gbps 이상
신호 손실률: 100m 전송 시, 광섬유는 약 3% / 구리 케이블은 최대 94% 손실 발생

광케이블 유형

▸ 싱글 모드 (Single-mode)

코어 직경: 약 9μm
전송 거리: 수 km 이상 장거리 전송 가능
색상: 노란색
용도: 장거리 고속 통신망, 통신사 백본망 등

▸ 멀티 모드 (Multi-mode)

코어 직경: 50 또는 62.5μm
전송 거리: 수백 미터 이내 단거리 전송에 적합
색상: 주황색, 아쿠아(하늘색 OM3), 녹색(OM5)
용도: 사무실, 데이터센터 내부, LAN 등

멀티 모드 케이블 종류 비교

유형	색상	코어 크기	전송 속도	최대 거리	주요 용도
OM1	주황색	62.5μm	1Gbps	300m	LAN, 일반 사무용 네트워크
OM2	주황색	50μm	1Gbps	600m	사설 네트워크, 일반 데이터 전송
OM3	아쿠아	50μm	10Gbps	300m (100Gbps: 100m)	데이터센터, 고속 전산망
OM4	아쿠아	50μm	10Gbps	550m (100Gbps: 150m)	금융, 클라우드 인프라
OM5	연두색	50μm	최대 100Gbps	장거리 고속	고밀도 데이터센터, 차세대 네트워크

OM1

재킷 색상 – 주황색
코어 크기 – 62.5um
데이터 속도 - 850nm 파장에서 1Gb
거리 – 최대 300미터
사용 용도– 단거리 네트워크, LAN(Local Area Networks) 및 사설 네트워크

OM2

재킷 색상 – 주황색
코어 크기 – 50um
데이터 속도 - 850nm 파장에서 1Gb
거리 – 최대 600미터
사용 용도– 단거리 네트워크, LAN(Local Area Networks) 및 사설 네트워크

OM3

재킷 색상 – 아쿠아
코어 크기 – 50um
데이터 속도 – 850nm 파장에서 10Gb
거리 – 최대 300미터
MPO 커넥터를 사용하여 최대 100미터까지 40GB 또는 100GB 실행 가능
사용 용도 - 대규모 사설 네트워크, 데이터 센터, 전산실

OM4

재킷 색상 – 아쿠아
코어 크기 – 50um
데이터 속도 - 850nm 파장에서 10G
거리 – 최대 550미터
MPO 커넥터를 사용하여 최대 150미터까지 100GB 실행 가능
사용 용도 – 고속 네트워크, 데이터 센터, 금융 센터 및 기업 캠퍼스

OM5

재킷 색상 - 그린
완벽하게 호환되며 OM3 및 OM4 케이블링과 연결 가능
850nm에서 953nm 사이의 더 넓은 범위의 파장을 활용.
SWDM(Short Wavelength Division Multiplexing)을 지원하도록 설계됨
40Gb/s 및 100Gb/s 전송 가능
사용 용도 – 더 긴 링크 거리와 더 빠른 속도가 필요한 고속 네트워크 및 데이터 센터.

요약

구분	싱글 모드	멀티 모드
코어 크기	약 9μm	50 / 62.5μm
거리	수 km 이상	수백 m
속도	매우 빠름	빠름
색상	노란색	주황색 / 하늘색 / 연두색
용도	통신사 / 장거리	LAN / 데이터센터 / 사무실

참고블로그

https://ilovestorage.tistory.com/14

L4 스위치이야기#3 포트도 NAT된다? Port Translation과 SSL Offload

똥선생 — Mon, 30 Jun 2025 14:05:09 +0900

L4 스위치이야기#3 포트도 NAT된다? Port Translation과 SSL Offload

L4 스위치를 다뤄본 분들이라면 대부분 IP NAT는 익숙하실 겁니다. 그런데, 포트(Port)도 NAT 대상이 될 수 있다는 점은 다소 낯설 수 있습니다. 특히 L4 스위치의 Virtual Server에 설정된 포트와 실제 서버가 사용하는 포트가 다를 때, 이 둘 사이를 연결하기 위한 기술이 바로 Port Translation입니다.

Port Translation이란?

L4 스위치에서 **Virtual Server에 설정된 포트(Service Port)**와 서버의 실제 서비스 포트가 서로 다를 경우, 트래픽이 스위치를 통과하면서 포트를 바꿔주는 작업이 필요합니다. 이 과정을 Port Translation이라고 합니다.

일반적으로는 Virtual Server와 서버 모두 같은 포트(예: 80번 HTTP)를 쓰는 것이 관리나 직관성 측면에서 편리합니다. 하지만 서비스 환경이 단순하지 않을 경우, 포트를 다르게 가져가야 할 필요가 생기죠.

예를 들어:

서버에서 80 포트를 이미 사용 중인데, 또 다른 웹서비스를 열고자 할 때
외부에서는 80 포트로 접속하게 하되, 실제 서버는 8080 포트로 운영하고 싶을 때

이럴 때 L4 스위치는 사용자의 요청을 받아 80 포트 → 8080 포트로 변환하여 내부 서버로 전달합니다.

트래픽 흐름 예시:

① 사용자 요청: 15.15.15.15 → 123.111.43.1:80 (L4 스위치 VIP:80)

② 서버 수신: 15.15.15.15 → 192.168.1.11:8080 (서버 포트로 변환됨)

이처럼 사용자 입장에선 전혀 알 수 없지만, 내부에서는 다른 포트로 통신이 이뤄지고 있는 것이죠.

SSL Offload – Port Translation이 반드시 필요한 대표 사례

요즘 대부분의 웹서비스는 HTTPS로 동작합니다. 이는 단순히 HTTP 위에 보안 계층을 추가한 구조로, 데이터가 암호화되어 전송됩니다. 이 과정에서 중요한 역할을 하는 것이 SSL/TLS Handshake입니다.

그런데 말입니다…
이 암호화/복호화 작업, 생각보다 서버 자원을 굉장히 많이 소모합니다. CPU가 많이 바쁘죠. 특히 대규모 트래픽을 처리하는 서비스라면, 매 요청마다 암호화를 수행하는 것은 큰 부담이 될 수밖에 없습니다.

그래서 등장한 개념이 바로 SSL Offload입니다.

SSL Offload란?

SSL Offload는 서버 대신 L4 스위치가 SSL 통신을 담당하는 방식입니다. SSL 인증서를 서버가 아닌 L4 스위치에 탑재하고, 클라이언트와 스위치 사이에서만 암호화를 수행합니다. 이후, 내부 서버와는 **평문 HTTP 통신(포트 80)**으로 연결하게 되죠.

이때 필요한 것이 바로 Port Translation입니다. 왜냐하면 사용자는 **443 포트(HTTPS)**로 요청을 보냈지만, 서버는 80 포트로 서비스를 제공하고 있으니까요. 따라서 스위치는 443 → 80 포트 변환이 필수인 것이죠.

흐름 요약:

① 사용자 요청: 123.111.43.1:443 (암호화된 HTTPS 요청)

② L4 스위치: SSL 복호화 + 포트 변환

③ 서버 수신: 192.168.1.11:80 (평문 HTTP 요청)

L4 스위치에서의 SSL Offload 설정

F5 등에서 이 기능을 활성화하려면 SSL 인증서를 업로드한 후, Virtual Server에 SSL Profile을 적용해야 합니다. Profile은 인증서, 개인키, 체인을 포함하며, 해당 설정이 적용된 Virtual Server는 클라이언트와 직접 SSL Handshake를 수행할 수 있게 됩니다.

마무리 정리

Port Translation은 Virtual Server의 포트와 실제 서버 포트가 다를 때 사용된다.
SSL Offload는 서버의 암호화 부담을 줄이기 위한 기술이며, Port Translation을 수반한다.
F5 등 주요 L4 스위치 장비에서는 SSL 인증서를 Virtual Server에 적용해 SSL Offload를 구성한다.

L4 스위치이야기#2 트래픽 흐름과 L4·L7 로드밸런싱의 차이

똥선생 — Mon, 30 Jun 2025 13:23:48 +0900

L4 스위치이야기#2 트래픽 흐름과 L4·L7 로드밸런싱의 차이

이번 글에서는 L4 스위치로 들어오는 트래픽의 흐름이 어떻게 구성되는지,
그리고 그에 따라 L4 로드밸런싱과 L7 로드밸런싱이 어떻게 다르게 작동하는지를 설명합니다.

L4 스위치, 단순 포워딩을 넘어선 제어 장치

L4 스위치는 기본적으로 Layer 4(TCP/UDP) 정보를 기반으로 트래픽을 분산시키는 장비지만,
필요에 따라 Layer 7(HTTP, DNS, FTP 등) 프로토콜까지 파악하고 제어할 수 있습니다.

L4 기반: IP + 포트 정보를 기반으로 처리 (빠름)
L7 기반: HTTP Header 등 콘텐츠 정보까지 확인하여 분산 (정교함)

이 차이에 따라 Virtual Server의 타입도 달라집니다:

L4 Virtual Server (Performance Type)
L7 Virtual Server (Standard Type)

Layer 4 vs Layer 7 – 계층 이해하기

계층기능주요 예시

Layer 4	TCP/UDP 포트를 기반으로 연결 생성 및 로드밸런싱	TCP 80, UDP 53 등
Layer 7	사용자 요청의 콘텐츠 분석 및 조건 기반 분산	HTTP 헤더, URL, User-Agent 등

L4 vs L7의 3-Way Handshake 처리 차이

TCP를 사용하는 경우, 연결을 맺기 위해 3-way handshake가 필요합니다:
SYN → SYN/ACK → ACK

이 과정에서 L4 스위치의 Virtual Server Type에 따라 다음과 같이 동작이 달라집니다:

L4 Virtual Server (Performance Type)

L4 스위치는 패킷을 그대로 전달만 함 (포워딩 중심)
사용자와 서버가 직접 3-way handshake를 수행
트래픽은 L4 스위치를 통과만 하고, 내부는 간섭하지 않음

장점: 빠르고 부하가 적음
단점: 콘텐츠 기반 조건 처리 불가능 (ex. 특정 URL 기반 분기 불가)

활용 예시:

단순 웹 서버 부하 분산
높은 성능이 필요한 환경

L7 Virtual Server (Standard Type)

L4 스위치가 사용자와 먼저 3-way handshake
이후 서버와 별도로 다시 3-way handshake 수행
중간에서 HTTP 등 프로토콜 헤더를 분석 및 가공 가능
→ 즉, 프록시(Proxy) 역할 수행

장점: 헤더 기반 로직, 조건 분기 가능
단점: 비교적 무거운 처리, 리소스 사용 증가

활용 예시:

HTTP Header 분석 후 URL 경로 분기
브라우저 종류(User-Agent)에 따라 다른 페이지 제공

실제 사례: User-Agent 기반 분기

고객 요청:
“사용자가 사용하는 브라우저 종류(IE, Chrome, Firefox) 에 따라 웹 페이지를 다르게 보여주고 싶습니다.”

해결 방법 (L7 기반):

HTTP 헤더의 User-Agent 필드를 분석
브라우저 조건에 따라 각기 다른 Pool Member로 전달

이처럼 L7 로드밸런싱은 내용 기반 판단이 필요한 서비스 분기에 매우 유용합니다.

정리

구분L4 로드밸런싱L7 로드밸런싱

계층 기준	Layer 4 (TCP/UDP)	Layer 7 (HTTP 등)
3-way handshake	사용자 ↔ 서버	사용자 ↔ L4 ↔ 서버
콘텐츠 분석	불가	가능 (헤더, URL 등)
처리 성능	빠름 (가볍고 고성능)	느림 (복잡하지만 정밀)
활용	단순 서버 분산	조건 기반 트래픽 분기

L4 스위치 이야기#1 로드밸런싱의 핵심을 이해하자

똥선생 — Mon, 30 Jun 2025 11:53:49 +0900

L4 스위치 이야기#1 로드밸런싱의 핵심을 이해하자

이번 글부터는 로드밸런싱 구조에서 핵심 역할을 맡는 **L4 스위치(Layer 4 Switch)**에 대해 알아보겠습니다.
이 장비는 단순히 트래픽을 나누는 역할을 넘어서, TCP/UDP 같은 Layer 4 프로토콜의 정보,
또는 HTTP 등 Layer 7 프로토콜의 헤더 정보까지 분석해 더 정교한 부하 분산이 가능합니다.

이번 문서에서는 실무에서 자주 활용되는 기능 위주로 설명드리며, 네트워크 엔지니어는 물론 서버, 개발 직군에게도 도움이 되는 관점을 담았습니다.

L4 스위치란 무엇인가?

L4 스위치는 네트워크 구조에서 **서버 부하 분산(로드밸런싱)**을 담당하는 대표 장비입니다.
외부에서 들어오는 요청을 서버가 직접 받는 것이 아니라, 먼저 L4 스위치가 요청을 수신하고,
그 후 내부 서버 중 하나로 적절히 전달해주는 역할을 합니다.

여기서 중요한 점은, 이 장비가 단순 트래픽 릴레이가 아니라
**TCP/UDP 포트나 IP 주소를 기준으로 NAT(주소 변환)**까지 수행할 수 있다는 것입니다.

연결(Connection)을 관리하는 L4 스위치

L4 스위치는 단순 트래픽 전달 외에도 논리적 연결(Connection)을 직접 관리합니다.

클라이언트가 서버에 접속할 때 수행하는 3-Way Handshake 역시 L4 스위치를 거쳐 이루어짐
연결이 종료되면 4-Way Handshake를 통해 세션 종료 및 연결 제거
사용되지 않는 세션은 일정 시간이 지나면 자동으로 삭제
(이때 Reset 플래그가 포함된 패킷으로 재접속 유도 가능)

이러한 연결 정보는 L4 스위치가 ‘세션 상태를 기억한다’는 의미에서 Stateful하게 동작함을 보여줍니다.

왜 L4 스위치가 필요한가?

예를 들어 웹 서버 하나에 공인 IP 123.111.43.2가 설정되어 있다고 가정해 봅시다.
사용자가 많아지면 이 서버의 처리 능력만으로는 부족해져, 또 다른 서버 123.111.43.3을 추가합니다.

문제는 이제 사용자들이 두 개의 IP 중 어떤 것을 이용해야 하냐는 점이죠.
서버가 2대일 땐 안내 공지를 통해 유도할 수도 있겠지만, 3대, 4대... 계속 서버가 늘어난다면?

>> 이때 필요한 것이 바로 L4 스위치를 이용한 로드밸런싱입니다.

구조의 변화: L4 스위치 중심 설계

서버마다 공인 IP를 가질 필요 없이, 이제는 **L4 스위치가 하나의 공인 IP(VIP)**만 가지고 모든 요청을 받습니다.

사용자는 123.111.43.1로 접속
이 IP는 L4 스위치에 할당
스위치는 내부 서버로 요청을 전달 (서버는 사설 IP 사용)

이러한 구조의 장점은 단순한 부하 분산뿐 아니라 보안 강화입니다.
외부에서 서버의 사설 IP를 알 수 없기 때문에 DDoS 공격 등의 위협을 막는 효과도 기대할 수 있습니다.

L4 스위치와 포트 정보 – Layer 4의 핵심

여기서 "왜 L4(Layer 4) 스위치인가?"라는 의문이 생길 수 있습니다.
바로, **OSI 7계층 중 4계층(Transport Layer)**에서 사용되는 Port 정보를 기반으로 작동하기 때문입니다.

웹 서비스: TCP 80번 포트
파일 전송: TCP 21번
DB 연결: TCP 3306번 등

IP 주소만 가지고는 어떤 서비스로 연결할지 판단할 수 없기에,
IP + Port 조합이 반드시 필요합니다. 이 포트 정보를 기준으로 요청을 처리하는 것이 L4 스위치의 핵심 역할입니다.

L4 스위치 구성 요소 용어 정리

구성 요소설명

Virtual Server	외부 사용자가 접근하는 가상의 서비스 단위 (IP + Port)
VIP (Virtual IP)	Virtual Server가 사용하는 공인 IP 주소
Pool	Virtual Server와 연결된 실제 서버 집합
Pool Member	Pool에 속한 각각의 서버 (IP + Port 조합)

하나의 Virtual Server는 하나 이상의 Pool을 가질 수 있고,
각 Pool은 여러 개의 Pool Member로 구성됩니다.
IP는 같아도 포트가 다르면 서로 다른 Pool Member로 간주합니다.

요약

항목내용

L4 스위치의 역할	서버 부하 분산, 연결 관리, NAT 수행
핵심 기준	TCP/UDP의 포트 정보 (Layer 4)
장점	서버 보안 향상, 구조 단순화, 확장성 우수
실무 활용	VIP → Pool로 요청 분산, 상태 기반 세션 관리(Stateful)

로드 밸런싱(Load Balancing), 서버 부하를 나누는 기술

똥선생 — Mon, 30 Jun 2025 11:46:28 +0900

로드 밸런싱(Load Balancing), 서버 부하를 나누는 기술

'부하 분산'이란 말을 들으면 어렵게 느껴질 수도 있지만, 사실 일상에서도 쉽게 찾아볼 수 있는 개념입니다.
예를 들어, 팀장이 몰려드는 업무를 팀원들에게 적절히 분배하는 것도 일종의 부하 분산이죠.
컴퓨터 네트워크에서도 이와 비슷한 원리로, 요청을 여러 서버나 장비에 나눠 처리하는 방식을 **로드 밸런싱(Load Balancing)**이라고 합니다.

로드 밸런싱이란?

“Load Balancing은 둘 이상의 서버나 컴퓨팅 자원에 트래픽이나 작업 부하를 균등하게 분배하여 성능과 가용성을 높이는 기술입니다.”

즉, 한 대의 서버가 모든 요청을 처리하다가 병목이 생기지 않도록, 여러 대의 서버에 요청을 나누어 분산하는 것입니다.
이를 통해 서비스 속도는 빨라지고, 서버 과부하로 인한 장애 가능성도 줄어듭니다.

네트워크에서의 로드 밸런싱

네트워크에서는 여러 종류의 부하 분산이 존재합니다:

Layer 2 기반 VLAN 분산
Layer 3의 라우팅 기반 분산
서버에 대한 로드 밸런싱

이 문서에서는 **서버 부하 분산(Server Load Balancing)**에 초점을 맞춰 설명드리겠습니다.

서버 부하 분산(Server Load Balancing)이란?

서버 부하 분산은 외부에서 들어오는 요청들을 로드 밸런서를 통해 여러 서버에 나누는 구조를 의미합니다.

사용자는 특정 웹사이트(naver.com 등)에 접속 요청
요청은 서버가 직접 받지 않고, 먼저 로드 밸런서를 거침
로드 밸런서는 그 요청을 내부 여러 서버 중 하나에 전달

이때 사용되는 장비는 주로 L4/L7 스위치 또는 소프트웨어 로드 밸런서이며,
클라우드 환경에서는 흔히 “Load Balancer”라는 이름으로 불립니다.

현업에서는 이를 줄여서 보통 LB라고 부르기도 합니다.

로드 밸런싱 방식 (Load Balancing Method)

서버의 성능과 상태에 따라 요청을 효율적으로 분산하기 위해 다양한 방식들이 사용됩니다. 대표적인 방법은 다음과 같습니다:

Round Robin (라운드 로빈)

가장 간단한 방식으로, 서버에 순차적으로 요청을 분배합니다.
서버 A → B → C → 다시 A... 순서대로 요청이 분산되며, 서버 간 성능 차이를 고려하지는 않습니다.

Least Connection (최소 연결 방식)

현재 **접속(Connection)**이 가장 적은 서버에 우선적으로 요청을 전달합니다.

예를 들어, 서버 A에 10개, 서버 B에 3개가 연결되어 있다면, B가 덜 바쁘다고 판단하고 B에 요청을 보냅니다.
실시간 부하를 기준으로 분산하는 방식이라 가변적인 트래픽에 대응하기 좋습니다.

Ratio (가중치 방식)

서버의 처리 능력에 따라 가중치를 설정하여 분산합니다.

예를 들어,

성능이 낮은 서버: 10%
나머지 3대 서버: 각 30%씩
이런 식으로 요청의 비율을 조절합니다. 이 방식은 서버 간 성능 차이가 클 때 유용합니다.

Fastest (응답 속도 기준)

응답 시간이 가장 빠른 서버에 우선 요청을 보냅니다.

서버 A가 5개 요청을 받았고, 5개 응답을 빠르게 반환했다면 여유 있는 서버로 판단
반면 서버 B는 10개 요청 중 5개만 응답했다면 과부하 상태로 간주

서버의 실제 반응 속도까지 반영하는 지능적인 방식입니다.

정리하며

방식기준특징

Round Robin	순서	가장 단순함
Least Connection	연결 수	실시간 부하 반영
Ratio	성능 가중치	서버별 비율 설정 가능
Fastest	응답 속도	실제 반응에 기반

이 외에도 다양한 알고리즘들이 있지만, 위 4가지는 대부분의 벤더나 솔루션에서 공통적으로 지원하는 방식입니다.
특히 F5, Alteon, Cisco, Piolink 등 다양한 로드 밸런서 벤더들도 기본적으로 이 방식을 제공합니다.

OSI 7 계층, 왜 IT엔지니어에게 필수인가?

똥선생 — Mon, 30 Jun 2025 11:24:44 +0900

OSI 7 계층, 왜 엔지니어에게 필수인가?

인터넷 강의를 듣고, 메시지를 주고받고, 웹사이트를 여는 모든 네트워크 활동은 하나의 규칙에 기반하고 있습니다. 바로 OSI 7 Layer 모델입니다.
실제로 IT 인프라를 다루는 사람이라면 OSI 계층 모델에 대한 이해는 선택이 아닌 필수입니다.

기업의 신입사원 면접에서도 빠지지 않고 나오는 질문 중 하나가 "OSI 7 Layer에 대해 설명해보세요"일 정도죠.
하지만 처음 이 개념을 접할 때는, 이름만으로도 어렵고 외울 게 많은 구조로 느껴지기 마련입니다.

이번 글에서는 OSI 7 Layer 중 실무에 꼭 필요한 핵심 계층들만 골라 쉽게 풀어보겠습니다.
(Layer 5~6은 생략하고 설명합니다.)

OSI 7 Layer란?

OSI(Open Systems Interconnection) 모델은 국제 표준화 기구(ISO)에서 제안한 네트워크 통신 구조입니다.
복잡한 통신 과정을 7개의 계층으로 나누어 각 단계의 역할을 정의하고, 서로 독립적으로 설계될 수 있게 한 것이죠.

상위 계층: 소프트웨어 중심, 실제 사용자와 가까움
하위 계층: 하드웨어 중심, 물리적 전송과 관련

각 계층은 아래 계층의 기능을 활용하고, 위 계층에 기능을 제공하는 방식으로 연결됩니다.

출처: https://westahn.com/osi-7-%EA%B3%84%EC%B8%B5%EC%9D%B4%EB%9E%80/

OSI 7계층의 핵심 계층 요약

7계층 – Application Layer

사용자가 직접 사용하는 소프트웨어 계층입니다. 우리가 웹사이트를 열 때 사용되는 HTTP, 이메일을 보낼 때의 SMTP, 도메인을 찾을 때의 DNS 등이 여기에 해당합니다.

HTTP, FTP, SMTP, DNS 등
제 사용자와 가장 가까운 계층

4계층 – Transport Layer

데이터를 신뢰성 있게 주고받을 수 있도록 연결을 관리하는 계층입니다.
TCP(연결형), UDP(비연결형)와 같은 프로토콜이 이곳에 속하며, 패킷의 전송 여부를 확인하거나 재전송도 처리합니다.

TCP, UDP
연결 설정, 세션 유지, 흐름 제어

3계층 – Network Layer

목적지까지 데이터가 어떤 경로로 가야 하는지 결정하는 계층입니다.
IP 주소와 라우팅 개념이 등장하며, 서로 다른 네트워크 대역 간의 통신을 가능하게 만듭니다.

IP, ICMP, Routing
주소 지정과 경로 선택

2계층 – Data Link Layer

같은 네트워크 내에서의 통신을 관리하는 계층입니다. MAC 주소를 통해 같은 대역 내 장치들끼리 정확히 연결되도록 하며, 오류 검출도 담당합니다.

Ethernet, MAC
동일 네트워크에서의 데이터 전송

1계층 – Physical Layer

네트워크의 가장 바닥에 위치한 계층으로, 전기적 신호나 광신호를 실제로 전달하는 역할을 합니다.
케이블, 커넥터, 허브 같은 물리적 장비들이 여기에 포함됩니다.

UTP 케이블, 광케이블 등
신호의 물리적 전송

어렵다면? 택배에 비유해보자

OSI 7 Layer는 추상적이라 느껴지기 쉽습니다. 그래서 현실적인 택배 시스템에 빗대어 설명해보겠습니다.

택배 발송 이야기

나는 신천동 100번지에서, 방배동 400번지 친구에게 중요한 문서를 보내려고 합니다.
문서는 회사 양식에 따라 작성하고, 받은 후 연락을 달라는 쪽지를 동봉합니다.
내가 직접 제1택배센터(신천동 200번지)에 가서 접수하면, 이 택배는 중간에 제2택배센터, 제3택배센터를 거쳐 방배동 너네 집(400번지)에 도착합니다.
수신자는 이를 받고 쪽지를 확인한 뒤 전화로 수신 확인을 줍니다.

데이터가 전달되는 방식

이 택배 과정을 OSI 7 계층으로 바꾸면 다음과 같습니다:

Application Layer
웹페이지를 HTTP로 작성하고 헤더에 정보를 담음
→ 문서를 규칙에 맞게 작성하는 단계
Transport Layer (TCP)
신뢰 가능한 연결을 만들기 위해 3-Way Handshake를 수행
→ 쪽지를 동봉해 수신 확인 요청
Network Layer (IP)
IP 주소를 통해 발신자(10.10.1.1)와 수신자(10.10.4.2)를 지정
→ 출발지와 도착지 주소 기재
Data Link Layer (Ethernet)
MAC 주소를 통해 실제 전달 경로를 정하고, 오류 검사 정보 추가
→ 택배 센터 주소와 번지로 중간 경로 설정
Physical Layer
데이터가 전기 신호로 바뀌어 케이블을 타고 이동
→ 택배가 실제로 트럭에 실려 이동
도착지 처리
최종 수신자가 MAC과 IP를 확인하여 자신이 맞음을 확인하고,
TCP 세션을 완성한 후 HTTP 데이터를 열람함
→ 수신자가 택배를 열고 문서를 확인

OSI 7 Layer, 왜 중요한가?

이 모델을 이해하면 네트워크 문제의 원인을 정확히 진단할 수 있습니다.

케이블 이상? → 물리 계층
IP 충돌? → 네트워크 계층
웹 페이지 안 열림? → 응용 계층

문제가 어느 구간에서 발생했는지 파악하기 쉬워지고,
각 계층별 장비 및 설정도 이해할 수 있어 네트워크 설계와 보안 설정에 큰 도움이 됩니다.

[k8s] 쿠버네티스로 편해진 IT 인프라 구축

똥선생 — Sun, 29 Jun 2025 19:39:55 +0900

해당 글은 일프로 님의 인프런 강의 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2의 내용을 정리한 글입니다.

해당 글에 사용된 내용, 사진 및 그림은 모두 강의와 강의 자료에 포함된 내용입니다.

네트워크 엔지니어로 근무하면서 부족하다고 생각되는 부분을 공부하고 있다.

그 중 쿠버네티스는 인프라 환경에서 굉장히 중요한 입지를 가지고 있고, 각 경계를 허무는 역할을 한다고 한다.

IT에 관련된 대부분의 기업이 쿠버네티스와 컨테이너에 진입을 했다.
쿠버네티스가 나온 지 10 년도 안 됐는데, 현재 이렇게 많은 제품들이 쿠버네티스 생태계 위에서 돌아간다.
이미 많은 회사들은 컨테이너가 미래에 인프라가 될 거라는 걸 예상했고 너도나도 이 시장의 넘버원이 되려고 뛰어 들었다.
그 결과 정말 짧은 시간만에 쿠버네티스 기반의 IT 생태계가 이렇게 폭발적으로 커졌다.
CNCF landscape 중 선별 기준CNCF 멤버/비멤버 제품 : 깃허브 Stars 높음 추가, 강사님 임의 추가CNCF 프로젝트 : Graduated Projects (Github Stars 낮음 제외), Incubating Projects (Github Stars 높음 추가), Sandbox Projects (X), Archived Projects (X)
참고 링크 : CNCF (link), CNCF landscape (link)
눈에 잡히는 IT생태계를 정리를 해 보면 위와 같다.
CNCF (Cloud Native Computing Foundation)**는 클라우드 네이티브 기술의 발전과 표준화를 지원하는 오픈소스 재단
위 제품들은 정말 많은 오픈 소스들 중에 대표이고 일단 처음엔 여기에만 집중해도 충분

쿠버네티스 기능으로 편해진 서비스 안정화

실제 프로젝트를 할 때 구조적인 문제

개발과 모니터링 시스템이 서로 엮일 수 밖에 없는 구조
1-1. 쿠버네티스와 모니터링을 통해 개발과 모니터링 시스템을 분리
개발에서는 한 번도 사용하지 않은 개발 시스템을 위한 모니터링 시스템을 만드는 구조
2-1. 이미 존재하는 오픈 소스를 통해 개발 초기부터 모니터링 시스템 사용 가능
애플리케이션 오픈 시 개발 프로젝트와 서로 다른 범위의 애플리케이션들을 모니터링 하게 되는 구조
3-1. 개발 도중 기능이 추가/삭제되면서 발생하는 애플리케이션의 변경 사항을 자동으로 반영

쿠버네티스 대표 기능

테스트 애플리케이션은 [Sprint1] 실무에서 느껴 본 쿠버네티스가 정말 편한 이유 > 쿠버네티스 대표 기능를 토대로 진행

파드를 이중화한 상태
서비스는 자체적으로 파드가 두 개 있으면 트래픽을 두 pod로 분산
오토 스케일링의 경우 최소 2, 최대 4이며 CPU를 기준으로 평균 40%가 넘으면 적용

Traffic Routing

while true; do curl http://192.168.56.30:31221/hostname; sleep 2; echo '';  done;

2초 간격으로 꾸준히 트래픽을 발생시키는 명령어

각 파드가 트래픽을 고르게 가져가고 있음

파드를 하나 강제로 삭제한다고 하더라도 자동으로 이를 복구함

Self-Healing

curl 192.168.56.30:31221/memory-leak

강제로 메모리 릭 발생

쿠버네티스에서 메모리 릭이 발생한 파드를 재시작(1)한 것을 확인할 수 있음

그라파나에서 CPU 사용량이 폭증한 시간대 확인

발생한 파드와 시간대를 토대로 문제 로그 확인 가능
로그를 통해 OOM 발생 이후 쿠버네티스가 자동으로 재시작하는 것을 확인할 수 있음

AutoScaling

curl 192.168.56.30:31221/cpu-load

기존 상태

증가한 트래픽에 따라 Auto Scaling이 적용되어 파드 수가 2 -> 4개로 증가

트래픽이 감소하면 다시 파드 수가 4 -> 2로 감소

RollingUpdate

성공 시

kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-update

트래픽이 계속 발생하고 있는 환경에서 이미지 업데이트 수행

이미지 버전을 변경하면서 아직 기동되지 않은 새 버전이 아닌 이전 버전 파드에 트래픽 분산

새 버전이 기동된 이후 이전 버전에 대한 파드 삭제

새 버전 파드에 트래픽 분산
- 이 모든 과정 중 트래픽은 꾸준히 들어오고, 모든 트래픽은 정상적으로 처리됨

실패 시

kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-error

새 이미지가 정상적인지 확인한 뒤 기존 이미지를 바꾸기 때문에 실패하더라도 쿠버네티스가 이를 처리해줌
- 문제가 발생한 이미지 버전은 정상적으로 동작하지 않기 때문에 이전 이미지 파드에서 트래픽 처리

kubectl rollout undo -n default deployment/app-1-2-2-1

이미지 업데이트를 취소시키면 문제가 되는 파드를 삭제
- 이 모든 과정 중 트래픽은 꾸준히 들어오고, 모든 트래픽은 정상적으로 처리됨

쿠버네티스 서비스 안정화

서비스 오픈 당일
- 오픈 이전 사용자 트래픽을 예상하고 성능 테스트를 해 애플리케이션의 자원 할당을 결정
  - 모든 기능에 대한 성능 테스트는 현실적으로 불가능
  - 오픈 전후로 주요 로직이 변경될 수도 있음
  - 오픈 당일에는 사용자가 예측 불가능하게 서비스를 호출하므로 성능 테스트처럼 정상적인 케이스만 요청되지 않음
  - 이를 대비하기 위해 여유 자원을 미리 준비한 상황이라고 가정
수동 설정 시
1. 서버 증설이 필요한 경우 VM 관리자가 네트워크, 스토리지 등을 준비해 트래픽을 분산할 수 있도록 준비
2. 웹 관리자가 트래픽이 분산될 수 있도록 새로운 애플리케이션의 IP 세팅
  2-1. 기존 웹 서버에 영향을 주는 작업은 해당 작업으로 인해 문제가 발생할 수 있으므로 진행하기 까다로움
  2-2. 수동으로 작업하다 보니 설정 과정에서 문제가 생길 수 있음
3. 새로운 애플리케이션 IP 세팅 완료
4. 모니터링 담당자가 새로운 애플리케이션의 메트릭을
자동 설정 시
1. 서버 증설이 필요한 경우 쿠버네티스 관리자가 쿠버네티스에게 증설 요청
2. VM에서 수행했던 작업들을 모두 자동으으로 안전하게 적용
  2-1. 개발 기간 ~ 성능 테스트를 하면서 자동화된 동작에 문제가 없음을 확인
  2-2. 파드 안에 설정이 모두 있기 때문에 스케일링된 파드 중 단 하나만 문제가 생기는 경우는 존재하지 않음
이러한 차이점으로 인해 쿠버네티스 환경이 관리자 입장에서 빠른 의사결정과 실행을 할 수 있도록 지원해준다고 볼 수 있음

쿠버네티스 인프라 환경 관리 코드화

인프라 형상 관리
- Dockerfile과 같은 컨테이너 런타임에서 어떤 컨테이너를 생성할지 설정 파일로 명시
- 쿠버네티스 파드 관리를 yaml로 처리할 수 있음
- 이를 통해 History 관리가 편해짐
인프라 작업 추적 가능
- 인프라 환경 관리를 코드로 수행하면서 형상 관리가 가능해졌으므로 이 작업을 수행한 시점 및 인원을 추적할 수 있음
인프라 환경별 파일 생성
- 실제 배포 환경이 세팅되지 않더라도 인프라 환경 파일 처리 가능
- 코드를 복붙해 간편하게 처리 가능
- 단순 반복이 줄어듦
새 인프라 작업시 이전 경험을 녹인 코드를 활용할 수 있음

목적지를 바꾸는 이유? – Destination IP NAT 쉽게 이해하기

똥선생 — Sun, 29 Jun 2025 10:18:50 +0900

목적지를 바꾸는 이유? – Destination IP NAT 쉽게 이해하기

네트워크에서 통신이 제대로 이루어지려면, 어디로 보내는지가 명확해야 합니다.
이때 활용되는 기술이 바로 Destination IP NAT, 즉 목적지 IP를 변환하는 방식입니다.

출발지 IP를 바꾸는 Source NAT와 달리, Destination NAT는 어떤 IP로 접근했을 때, 그 요청을 어디로 전달할지를 명확하게 정해줘야 합니다.
그렇기 때문에 사전에 정해진 IP 목록을 바탕으로 목적지 IP를 정확히 지정해야 하며, NAT 장비의 인터페이스 IP를 활용하는 경우는 거의 없습니다.

Destination NAT는 ‘정확한 목적지 지정’이 핵심

Source NAT는 ‘어떤 IP든 통신이 되면 OK’라면,
Destination NAT는 ‘정확한 곳에 도달해야 OK’인 기술입니다.

예를 들어, 하나의 IP를 두 개의 목적지로 동시에 연결할 수 없습니다.
‘어디로 갈지 모르겠는’ 상황은 곧 연결 실패로 이어지기 때문이죠.

그래서 Destination IP NAT를 제대로 이해하려면,
먼저 어떤 방식으로 IP가 변환되는지를 유형별로 구분해 알아야 합니다.

목적지 IP 변환 유형 2가지

1. 일대일 변환 (1:1 Mapping)

가장 기본적인 방식입니다.
하나의 공인 IP → 하나의 내부 IP로 매칭되며, 주로 외부에서 내부 사설 네트워크로 접근할 때 사용됩니다.

예를 들어, 외부 사용자가 123.123.123.1로 접속하면, 이 요청을 내부의 10.10.10.10으로 정확히 전달하도록 설정하는 것이죠.

가정에서도 흔히 사용되는 ‘포트 포워딩’ 기능도 일대일 NAT의 일종입니다.
하나의 공인 IP에 여러 포트를 지정해 각각 다른 내부 IP로 전달할 수 있어 유용하죠.

2. 일대다 변환 (1:N Mapping)

이 방식은 하나의 IP를 다수의 서버 중 하나로 변환해주는 형태입니다.
주로 로드밸런싱을 구현할 때 사용되며, 대표적인 장비로 L4 스위치가 있습니다.

사용자는 특정 VIP(가상 IP)로 접속하지만, 실제로는 여러 대의 서버 중 하나가 요청을 처리합니다.
Round Robin, Least Connection 같은 방식으로 목적지 IP가 선택되어 요청이 분산되죠.

실제 적용 사례로 보는 Destination IP NAT

사례 1. L4 스위치 기반의 서버 로드밸런싱

가장 대표적인 Destination IP NAT 사례입니다.
외부 사용자가 L4 스위치의 VIP로 접속하면, 요청은 실제 서버 중 하나로 NAT되어 전달됩니다.

VIP: 123.111.43.1:80
실제 서버들: 192.168.1.11:80, 192.168.1.12:80

이 경우 NAT는 일대다 변환으로 구성되며, 로드밸런싱 방식에 따라 어떤 서버가 응답할지가 결정됩니다.

L4 스위치를 사용하는 이상, 대부분 Destination NAT는 ‘기본 전제’이므로 따로 언급되지 않는 경우도 많습니다.

사례 2. 대외망과의 연동

두 번째 사례는 타사 네트워크(대외망)와의 통신에서 자주 발생하는 형태입니다.
특히 여러 대외망과 접속해야 할 때, 라우팅 테이블이 점점 복잡해지는 것을 방지하기 위해 사용됩니다.

기존 방식에서는 대외망이 하나 생길 때마다 새 라우팅을 추가해야 했지만,
Destination IP NAT를 활용하면 NAT 전용 IP 대역(예: 10.10.20.x)을 정해두고, 모든 대외망 IP를 이 대역으로 변환시켜 사용할 수 있습니다.

덕분에 라우팅 테이블은 간결해지고, 대외망이 추가되더라도 복잡한 설정 없이 빠르게 연동이 가능합니다.

사례 3. 공인망에서 내부망(사설 IP)으로 접속

외부 인터넷에서 DMZ 혹은 내부망에 위치한 사설 IP 장비로 접근할 때도 Destination IP NAT가 필요합니다.

예를 들어:

외부 사용자가 125.209.222.142로 접속
공유기는 이를 내부 장비 10.10.10.10으로 NAT
요청은 내부 장비에 전달되고, 응답은 세션을 따라 다시 외부로 전달

이 과정에서 출발지 IP는 유지한 채, 목적지만 변환하는 것이 핵심입니다.

보안 DMZ와 Destination IP NAT

기업 네트워크에서는 DMZ(비무장지대)라는 별도 네트워크 영역을 구성하는 경우가 많습니다.
DMZ는 외부에서도 접근이 가능하면서 내부망과도 연결된 중간 구간입니다.

이곳에 설치된 VPN, 웹하드 등 서비스는 외부 사용자의 접속이 전제되므로, 공인 IP로의 접근을 사설 IP로 NAT해줘야 합니다.
예: 공인 IP로 들어온 HTTPS 요청 → 사설 IP로 NAT + 443 포트 허용

정리: Source NAT vs Destination NAT

구분Source IP NATDestination IP NAT

대상	출발지 IP	목적지 IP
목적	사설 → 공인 변환 등	공인 → 사설 변환 등
사용 예시	인터넷 접속, 대외망 통신	L4 로드밸런싱, 외부 → 내부 접근
변환 방식	인터페이스 IP, IP Pool	일대일, 일대다 (VIP)

마무리하며

NAT는 단순한 이론이 아니라 실무 경험이 중요한 기술입니다.
Source IP NAT와 Destination IP NAT 두 가지 핵심 개념만 정확히 이해하고, 실제 사례 중심으로 학습한다면
복잡한 네트워크 환경에서도 충분히 유연하게 대응할 수 있습니다.

출발지 IP를 바꾸는 이유? Source IP NAT 이해하기

똥선생 — Sun, 29 Jun 2025 10:15:35 +0900

출발지 IP를 바꾸는 이유? – Source IP NAT 이해하기

우리가 인터넷을 이용하거나 다른 네트워크와 연결할 때, '내가 누구인가(IP 주소)'를 숨기거나 바꿔야 할 때가 있습니다. 그때 사용하는 것이 바로 Source IP NAT입니다.
출발지 IP, 즉 송신자의 IP 주소를 다른 주소로 바꾸는 방식인데요, 단순히 바꾸는 것이 아니라 왜, 어떻게, 무엇으로 바꾸는지가 매우 중요합니다.

출발지 IP는 왜 바꿔야 할까?

기본적으로 NAT는 네트워크 간 통신을 원활하게 만들기 위해 등장한 기술입니다.
Source IP NAT의 목적은 단순합니다. 기존 IP로는 통신이 불가능하거나 문제가 생길 수 있기 때문입니다.
예를 들어, 내부망에서 외부망으로 접속할 때 사설 IP를 공인 IP로 바꾸지 않으면 응답을 받을 수 없게 되죠.

하지만 단지 IP를 바꾸는 것만으로는 충분하지 않습니다. 어떤 IP로 바꿀지를 제대로 선택해야 통신이 정상적으로 이루어집니다.

Source IP NAT 시 사용 가능한 IP 2가지

1. NAT 장비의 인터페이스 IP (Outgoing Interface IP)

가장 대표적인 방식은 NAT 장비 자체의 외부 인터페이스 IP를 사용하는 것입니다.
이 방법은 설정이 간단하면서도 직관적입니다. 외부로 나갈 때 장비의 외부 인터페이스 IP로 출발지 IP를 바꾸면, NAT 장비가 응답 패킷도 다시 내부로 잘 전달할 수 있죠.

공인 IP가 아닌 사설망 간 통신에서도 동일하게 사용할 수 있으며, 해당 인터페이스의 IP가 외부 네트워크에서 인식 가능한 주소라면 문제 없이 통신이 가능합니다.

2. IP Pool (사전에 등록된 NAT 전용 IP 모음)

또 다른 방식은 NAT 장비에 따로 지정해둔 IP Pool을 이용하는 것입니다.
IP Pool은 NAT 장비가 보유하고 있는 여러 개의 IP 중, 특정 범위를 정해두고 그 중 하나를 출발지 IP로 사용하는 방식입니다.

같은 네트워크의 IP를 사용할 수도 있고,
완전히 다른 네트워크 대역의 IP를 지정할 수도 있습니다.

단, IP Pool에 포함된 IP는 반드시 다른 장비가 사용 중이지 않아야 하며,
NAT 장비가 직접 ARP 응답을 하지 않는 경우, 외부 장비는 이 IP가 NAT 장비에 속한지 인식하지 못할 수도 있다는 점도 주의해야 합니다.

본격적인 사례로 보는 Source IP NAT

사례 1. 외부 인터넷 접속

가장 흔한 Source IP NAT 활용 사례입니다.
기업 환경에서는 방화벽이, 가정에서는 공유기가 이 역할을 맡습니다.
내부 단말의 사설 IP를 공인 IP로 바꾸어 외부로 나갈 수 있도록 하고, 세션을 기억하여 응답도 다시 내부로 돌려보냅니다.

이 방식 덕분에 우리는 오늘도 사설 IP를 가진 PC, 스마트폰으로 자유롭게 웹사이트에 접속할 수 있습니다.

사례 2. L4 스위치의 3-Way Handshake 보완

조금 복잡한 예지만, 매우 실무적인 사례입니다.
L4 스위치는 클라이언트와 서버 사이에서 로드밸런싱을 수행하지만, 서버의 게이트웨이가 L4 스위치가 아닐 경우, 3-Way Handshake가 꼬일 수 있습니다.

클라이언트 → L4 스위치 → 서버
서버 → (잘못된 경로) → 클라이언트

이런 문제를 막기 위해, L4 스위치가 서버에 보내는 패킷의 출발지 IP를 자신의 IP로 NAT하는 방식이 사용됩니다.
이렇게 하면 서버는 응답을 반드시 L4 스위치로 보내게 되어 정상적인 세션이 형성될 수 있습니다.

사례 3. 대외망 연동 (타사 네트워크와의 통신)

자주 사용되지는 않지만 보안과 충돌 방지를 위해 필수적인 상황입니다.
예를 들어, 한 유통회사가 금융 결제망과 전용회선으로 연결되어 있다고 가정합시다.
두 네트워크가 **동일한 IP 대역(예: 10.10.10.x/24)**을 사용하고 있다면 통신이 불가능합니다.

이때 방화벽은 내부 단말의 출발지 IP를 **다른 IP 대역(예: 172.16.1.1)**으로 바꾸어 NAT를 실시합니다.
이 방식은 IP 충돌 방지뿐 아니라, 자사 내부 IP를 외부에 노출하지 않기 위한 보안적 이유로도 자주 사용됩니다.

보너스 사례: VM의 NAT 모드

VirtualBox나 VMware에서 흔히 볼 수 있는 NAT 모드도 Source IP NAT의 일종입니다.
Guest OS가 자체 네트워크 대역을 사용하되, Host의 IP로 NAT를 수행하여 외부와 통신하는 구조입니다.

Source IP NAT 정리

외부 인터넷 접속	사설 IP → 공인 IP로 변환	방화벽, 공유기
L4 정합성 유지	클라이언트 IP → L4 IP로 변환	L4 스위치
대외망 충돌 방지	중복된 IP → NAT로 변환	방화벽
가상화 환경	VM IP → Host IP로 변환	VirtualBox 등

가장 많이 쓰이는 형태는 역시 인터넷 접속을 위한 NAT입니다. 우리가 인터넷을 쓰는 거의 모든 순간이 이 사례에 해당한다고 보시면 됩니다.
나머지 사례들은 실무에서 네트워크를 다룰 때 꼭 알아야 할 중요한 케이스들입니다.

다음 글에서는 **Destination IP NAT(DNAT)**를 다루며, 서버 접근 시 어떻게 목적지 IP가 바뀌는지 구체적인 예제를 통해 살펴보겠습니다.

왜 아직도 IPv4를 쓸 수 있을까? NAT와 사설망 이야기

똥선생 — Sun, 29 Jun 2025 10:07:44 +0900

왜 아직도 IPv4를 쓸 수 있을까? — NAT와 사설망 이야기

사라졌어야 할 IPv4, 왜 여전히 우리 곁에 있을까?

2011년, 인터넷 주소 관리기구 IANA는 중요한 발표를 했습니다. "IPv4 주소가 모두 소진되었습니다."
IPv4는 약 43억 개의 주소만을 제공하는 제한된 체계입니다. 인터넷의 급격한 확산으로 이미 10년도 전에 전 세계에 배정 가능한 주소가 바닥났죠.

그런데 이상하지 않으신가요?
그 이후로도 우리는 큰 불편 없이 인터넷을 잘 사용해오고 있습니다. 어느 날 갑자기 "이제 인터넷에 접속할 수 없습니다!"라는 뉴스가 나온 적도 없죠.

그 비밀은 바로 **사설망(Private Network)**과 NAT(Network Address Translation) 덕분입니다.

사설망과 사설 IP의 등장

사설망은 공인 IP 대신 내부적으로만 사용하는 사설 IP 주소를 기반으로 운영됩니다. RFC 1918과 RFC 4193 표준에 따라 정해진 사설 IP 대역은 다음과 같습니다:

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

이러한 사설 IP는 외부 인터넷에서는 인식되지 않으며, 내부망에서만 자유롭게 사용할 수 있습니다.
가정용 공유기에서 자동으로 할당받는 IP 주소도 바로 이 사설 IP입니다. 기업에서는 네트워크 장비나 컴퓨터에 사설 IP를 부여하고, 게이트웨이를 통해 외부와 연결합니다.

사설 IP만으로는 인터넷에 나갈 수 없다

문제는 여기서 시작됩니다.
사설 IP는 외부 인터넷에서 절대 사용할 수 없습니다. 만약 사설망에서 그대로 공인망으로 나간다면?
인터넷 상에는 동일한 사설 IP를 쓰는 수많은 네트워크가 있기 때문에, 응답 패킷이 어디로 돌아가야 할지 알 수 없습니다.

이 문제를 해결하기 위해 IP 주소 변환 기술, 즉 NAT가 등장했습니다.

NAT: 사설망과 공인망을 이어주는 다리

NAT(Network Address Translation)는 네트워크 장비가 IP 주소와 포트 번호를 재작성하여 사설망과 공인망 간 통신을 가능하게 해주는 기술입니다.
간단히 말하면, 내부 IP를 외부 IP로, 다시 외부 IP를 내부 IP로 바꾸어주는 역할을 합니다.

예를 들어, 집에서 인터넷을 사용하는 컴퓨터는 공유기(NAT 장비)를 통해 외부 웹사이트에 접속합니다. 이때 공유기가 사용자의 사설 IP를 자신의 공인 IP로 변환하여 요청을 보냅니다. 응답이 돌아오면 다시 사설 IP로 되돌려 사용자에게 전달하죠.

두 명 이상이 동시에 나가면 어떻게 될까?

하나의 공인 IP를 여러 사용자가 공유할 경우, 동일한 포트를 사용하는 경우가 생길 수 있습니다.
예를 들어, 두 사용자가 동시에 9999번 포트로 요청을 보낸다면, NAT 장비는 누가 누구인지 구분할 수 없게 됩니다.

이럴 때 사용되는 방식이 바로 **PAT(Port Address Translation)**입니다.
PAT는 각 사용자의 출발지 포트를 임의로 변경하여 트래픽을 구분합니다. 예를 들어 사용자 A는 10000번, 사용자 B는 20000번으로 변환하여 통신하면 충돌이 발생하지 않죠.

공인망만의 문제가 아니다: 사설망 간 통신

NAT는 공인망과 사설망 사이에서만 쓰이는 기술이 아닙니다.
예를 들어, 기업 간 비공개 네트워크(대외망)에서 전용 회선을 통해 통신할 경우에도 서로의 내부 IP가 겹칠 수 있습니다.
이 경우에도 NAT를 사용해 IP를 변환하고, 필요시에는 목적지 IP(DNAT)까지 바꾸어야 합니다.

NAT는 어디서 어떻게 동작하는가?

대부분의 NAT는 네트워크의 출입구에 해당하는 세션 장비가 담당합니다. 공유기, 방화벽, VPN 장비, L4 스위치 등이 이에 해당하죠.
이 장비들은 세션 테이블을 만들어 어떤 IP와 포트를 어떻게 변환했는지를 저장해둡니다.

이렇게 저장된 세션 정보 덕분에 나중에 응답이 들어왔을 때 해당 세션을 찾아 다시 올바른 사용자에게 전달할 수 있게 됩니다. 이러한 특성을 우리는 Stateful이라고 부릅니다.

다양한 NAT의 형태

NAT는 사용하는 방식에 따라 여러 이름으로 불립니다:

구분설명

Static NAT	IP 1:1 변환
Dynamic NAT	IP Pool 기반 다대다 변환
PAT (또는 NAPT)	포트까지 변환하는 방식
SNAT	출발지 IP 변환
DNAT	목적지 IP 변환

벤더에 따라 용어도 조금씩 다릅니다.
예를 들어 Juniper 장비에서는 MIP, DIP, VIP라는 이름을 쓰고, Fortinet에서는 IP Pool과 Virtual IP라고 부릅니다.

하지만 결국 이 모든 용어가 의미하는 바는 단 하나입니다:
IP 주소(또는 포트)를 변환하여 네트워크를 연결한다는 것.

NAT를 제대로 이해하려면?

NAT는 용어만으로는 이해하기 어렵습니다. 실무에서 접하면서 ‘아, 이런 게 SNAT였구나’, ‘이게 바로 DNAT 상황이네’ 하고 체감하는 순간이 와야 확실히 정리됩니다.

제가 추천드리는 방법은 딱 두 가지입니다:

SNAT와 DNAT의 실제 사례를 반복해서 학습하세요.
용어는 실전에 익숙해진 후, 정리 차원에서 다시 정리하세요.

다음 글에서는 Source IP NAT(SNAT)와 Destination IP NAT(DNAT)를 더 구체적으로 다루며, 실무에서 어떤 방식으로 활용되는지 사례를 통해 쉽게 설명드릴 예정입니다.

SNMP란 무엇인가?#2

똥선생 — Sun, 29 Jun 2025 09:45:26 +0900

실무에서 SNMP를 활용한 네트워크 모니터링 방법

이번에는 SNMP를 실제 현업에서 어떻게 활용하는지, 즉 SNMP 기반의 네트워크 모니터링 솔루션인 NMS(Network Management System)의 활용 방안에 대해 알아보겠습니다.

1. NMS 운영을 위한 기본 조건

네트워크 장비를 효과적으로 모니터링하려면 몇 가지 전제 조건을 충족해야 합니다.

네트워크 연결 환경 확보

가장 먼저, NMS 서버와 모니터링 대상 장비 간의 SNMP 패킷이 문제없이 오갈 수 있는 네트워크 환경을 구성해야 합니다. 즉, NMS 서버에서 보낸 SNMP 요청이 장비에 도달하고, 응답이 다시 NMS로 돌아올 수 있도록 방화벽, 라우터 등 중간 장비들의 설정이 적절히 되어 있어야 합니다.

보안 장비 정책 조정

NMS와 장비 간의 통신을 가로막는 방화벽이나 기타 보안 장비의 정책을 미리 확인하고, UDP 포트 161, 162에 대한 허용을 설정해두어야 합니다.

모니터링할 OID 선정

모든 OID를 수집하는 것은 비효율적입니다. 장비의 상태를 가장 잘 보여주는 핵심 OID를 선별해 모니터링하는 것이 중요합니다. 특히 트래픽 정보는 장애 예측 및 대응에 필수적인 요소로, 반드시 포함시켜야 할 항목입니다.

2. 네트워크 장비 모니터링 조건

경로 상 라우팅 설정

NMS가 다양한 네트워크에 걸친 장비들을 모니터링하려면, 중간 경로의 백본 스위치, 라우터, 방화벽에 적절한 라우팅 설정이 필요합니다. 또한 모니터링 대상 장비 측의 네트워크에서도 NMS가 위치한 네트워크로의 경로가 설정되어 있어야 양방향 통신이 가능합니다.

방화벽 정책 허용

출발지(NMS IP), 목적지(장비 IP), 그리고 SNMP가 사용하는 포트(UDP 161, 162)에 대한 허용 규칙을 설정해야 합니다. 이를 설정하지 않으면 SNMP 요청이 차단될 수 있습니다.

장비 SNMP 기능 활성화

장비 내 SNMP 설정은 종종 간과되지만 매우 중요한 요소입니다. SNMP 버전(v1/v2/v3) 선택, Trap 기능 활성화 여부, 그리고 NMS의 접근을 허용할 IP 지정(ACL 설정 등)을 반드시 확인해야 합니다.

3. NMS에 장비 등록하는 절차

네트워크 환경이 준비되었다면, 이제 NMS에 장비를 등록하고 데이터를 수집하는 단계로 넘어갑니다.

장비 IP 등록: NMS에서 대상 장비의 IP를 입력하여 SNMP 요청을 전송합니다.
OID 응답 수신: 장비로부터 기본적인 OID 응답을 받아옵니다.
모니터링 대상 OID 선택: 사용자가 필요한 OID를 선택해 장비를 등록합니다.
객체 생성: 장비는 NMS에서 하나의 객체(Object)로 관리됩니다.
모니터링 수행: 등록된 객체를 통해 실시간으로 상태를 확인할 수 있습니다.

4. 주요 모니터링 요소

공통 항목

장비 정보(벤더, 설명, 호스트 이름, 가동 시간 등)
CPU/메모리 사용량
FAN 상태 및 온도
ICMP Ping 응답 상태
SNMP 응답 여부
트래픽 처리량

이 중에서도 CPU, 메모리, 트래픽 정보는 장애 판단의 핵심 지표로 사용되며, 실제 장애 발생 시 가장 먼저 확인하는 항목입니다.

장비별 주요 항목

장비 종류중요 모니터링 요소

스위치 / 라우터	인터페이스 상태, 업링크 트래픽, 전체 트래픽 처리량
L4 스위치	세션 수, 메모리/디스크 상태, 세션 상태 요약
방화벽 / VPN	세션 정보, SNMP 상태, 인터페이스 및 트래픽 모니터링 등

5. 모니터링 주기 설정

OID 수집 주기는 1분(60초) 혹은 **5분(300초)**이 일반적입니다.

주기가 짧으면 실시간성이 높지만, 네트워크 부하가 커질 수 있습니다.
주기가 길면 자원은 적게 소모되나, 장애 감지 속도가 느려질 수 있습니다.

장비의 중요도와 네트워크 규모에 따라 적절한 주기를 설정해야 합니다.

이처럼 SNMP와 NMS를 활용하면 네트워크의 상태를 효율적으로 관리하고, 장애를 신속히 탐지 및 대응할 수 있습니다. 실무에서 반드시 숙지해야 할 중요한 요소이니, 기본 원리부터 실전 적용까지 체계적으로 이해하시기 바랍니다.

SNMP란 무엇인가?#1

똥선생 — Sun, 29 Jun 2025 09:40:37 +0900

네트워크 장비들의 주요 성능과 기능을 모니터링(관제)하고 장애 발생 시 이를 관리자에게 전달하거나 장비에 문제가 생기지 않아도 먼저 관리자에게 특이점을 보고할 수 있는 프로토콜이 있습니다. 바로 **SNMP(Simple Network Management Protocol)**입니다.

SNMP란 무엇인가?

SNMP는 "간이 망 관리 프로토콜(Simple Network Management Protocol)"로, 네트워크 장비(라우터, 스위치, 서버, 프린터 등)의 성능, 상태, 설정 정보를 수집하고 제어하는 데 사용하는 인터넷 표준 프로토콜입니다. SNMP를 활용하면 관리자나 모니터링 시스템(NMS)이 장비를 직접 확인하지 않고도 다양한 정보를 수집하고 문제를 탐지할 수 있습니다.

SNMP는 UDP 포트 161을 사용하며, 정보를 주고받는 방식은 가볍고 빠릅니다.

SNMP 구성 요소

SNMP는 크게 두 가지 역할로 구성됩니다:

▶ Manager (NMS: Network Management System)

정보를 수집하고 모니터링하는 주체
SNMP 메시지를 통해 장비 상태를 요청하거나 설정 변경 명령을 보냅니다

▶ Agent

정보를 제공하는 장비 측
장비 내에 동작하는 SNMP Daemon이 정보 요청에 응답하거나 장애 발생 시 직접 메시지를 보냅니다

SNMP 버전별 특징

버전특징

v1	가장 초기 버전. 커뮤니티 값을 평문 전송해 보안에 취약
v2c	대량 정보 요청 가능. 하지만 여전히 커뮤니티 값 평문 전송
v3	인증 및 암호화 추가 (Username + Password 기반 보안 강화)

커뮤니티 값은 NMS와 장비 간 인증을 위한 문자열입니다. 일종의 비밀번호 역할을 하며, 이 값이 일치하지 않으면 장비는 정보를 제공하지 않습니다.

SNMP 메시지의 종류

▶ Get

장비의 정보를 요청합니다
GetRequest / GetNextRequest / GetBulkRequest 종류가 있으며, 후자로 갈수록 대량 요청에 유리합니다

▶ Set

장비 설정을 변경합니다
실무에서는 자주 사용되지는 않지만, 자동화 설정에 활용되기도 합니다

▶ Trap

장비가 스스로 보내는 경고 메시지입니다
장애 발생 시 즉시 NMS로 전송되며, UDP 포트 162를 사용합니다

SNMP의 핵심: OID (Object Identifier)

장비의 각각의 정보는 **OID(Object ID)**라는 고유 번호로 식별됩니다.

예시:

1.3.6.1.2.1.1.3.0 → 장비의 Uptime
1.3.6.1.4.1.9.9.109.1.1.1.1.5 → Cisco 장비의 CPU 5분 평균 사용률

OID는 트리 구조로 구성되어 있으며, 각 숫자는 특정한 의미를 갖습니다. OID는 다음과 같이 나뉩니다:

▶ Public OID

모든 벤더에서 공통으로 사용하는 정보 (ex. 시스템 정보, 인터페이스 상태 등)

▶ Private OID

특정 벤더 전용 정보 (ex. Cisco 장비의 전력 상태, CPU 온도 등)

MIB (Management Information Base)

OID들의 집합을 MIB라고 부릅니다. 각 벤더는 자사 장비에 맞는 MIB 파일을 제공하며, NMS는 이 파일을 읽어 어떤 정보를 어떤 OID로 가져와야 하는지 인식합니다.

MIB를 쉽게 탐색하려면 MIB Browser를 사용하면 됩니다. 대표적인 무료 도구: iReasoning MIB Browser

PC도 SNMP로 관제 가능?

그렇습니다. SNMP는 라우터, 스위치 같은 네트워크 장비뿐 아니라 프린터, 서버, 심지어 개인용 PC까지 지원됩니다. PC에서도 SNMP Agent를 활성화하면, CPU/메모리 사용량 등 주요 정보를 NMS가 수집할 수 있습니다.

SNMP는 단순히 정보를 모으는 수준을 넘어, 네트워크의 현재 상태를 종합적으로 관제하고 문제를 조기에 인지하게 해주는 핵심 기술입니다. NMS 솔루션과 함께 활용하면, 장애 대응 능력을 획기적으로 높일 수 있습니다.

다음 글에서는 실제 SNMP 환경 구축과 실무 적용 사례에 대해 다뤄보겠습니다.

EIGRP 라우팅 프로토콜 한방에 끝내기

똥선생 — Thu, 27 Mar 2025 23:56:58 +0900

EIGRP(Enhanced Interior Gateway Routing Protocol)란?
EIGRP(Enhanced Interior Gateway Routing Protocol)는 Cisco에서 개발한 고급 동적 라우팅 프로토콜로, IGRP(Interior Gateway Routing Protocol)를 개선한 버전입니다. 하이브리드 라우팅 프로토콜이라고도 불리며, 거리 벡터(distance vector)와 링크 상태(link state) 라우팅 프로토콜의 장점을 결합한 구조를 가지고 있다.

distance verctor 라우팅 프로토콜이며, link state의 특징을 몇가지 가지고 있다.

Cisco 독점 프로토콜 (기존) → 2013년 표준화 (RFC 7868)

1. EIGRP의 주요 특징

1) 빠른 컨버전스(Fast Convergence)

DUAL(Diffusing Update Algorithm)을 사용하여 최적의 경로를 신속하게 찾고, 기존 경로에 장애가 발생할 경우 대체 경로(Feasible Successor)를 빠르게 적용함.
RIP보다 빠른 경로 재탐색 속도를 보장.

DUAL 알고리즘(Diffusing Update Algorithm)이란? 맨 밑에서 설명합니다.

2) 부분적인 업데이트(Partial & Bounded Updates)

전체 네트워크가 아닌 변경이 발생한 부분에만 업데이트 전송.
네트워크 대역폭 절약 및 효율적인 라우팅 테이블 관리.

3) VLSM & CIDR 지원

서브넷 마스크 가변 길이(VLSM, Variable Length Subnet Mask) 및 클래스 없는 라우팅(CIDR, Classless Inter-Domain Routing) 지원.

4) 멀티 프로토콜 지원

IPv4뿐만 아니라 IPv6, AppleTalk, IPX 같은 여러 프로토콜을 지원.

5) 수학적 거리 정보(메트릭) 활용

EIGRP 메트릭 공식은 대역폭(Bandwidth), 지연시간(Delay), 신뢰성(Reliability), 부하(Load) 등의 요소를 기반으로 최적 경로를 결정.

6) 계층적 라우팅(Hierarchical Routing) 지원

자동 요약(Auto-Summary) 기능을 제공하지만, 필요시 비활성화 가능(Manual Summarization).

2. EIGRP의 동작 원리

EIGRP는 다음과 같은 주요 요소를 통해 동작합니다.

1) 네이버(Nighbor) 관계 설정

동일한 AS(Autonomous System, 자율 시스템) 번호를 가진 라우터들끼리 Hello 패킷을 교환하여 이웃 관계 형성.

2) DUAL 알고리즘

라우팅 루프 방지를 위해 **최단 경로(Successor)와 후보 경로(Feasible Successor)**를 계산하여 백업 경로를 미리 확보.
이를 통해 장애 발생 시 빠른 대체 경로로 전환 가능.

3) 라우팅 테이블 & 토폴로지 테이블 활용

라우팅 테이블(Routing Table): 실제로 패킷이 전달될 최적 경로 저장.
토폴로지 테이블(Topology Table): 모든 가능한 경로 및 백업 경로 저장.
네이버 테이블(Neighbor Table): 인접 라우터 목록 저장.

4) EIGRP 패킷 유형

Hello 패킷: 네이버 관계 설정(멀티캐스트 224.0.0.10)
Update 패킷: 라우팅 정보 업데이트(변경된 경로만 전송)
Query 패킷: 대체 경로 요청
Reply 패킷: Query에 대한 응답
ACK 패킷: 패킷 수신 확인 응답

3. EIGRP 메트릭 공식

EIGRP는 다음 공식으로 경로 메트릭을 계산합니다.

Metric=256×[(K1×Bandwidth)+(K3×Delay)]Metric = 256 \times [(K1 \times Bandwidth) + (K3 \times Delay)]

Bandwidth: 최소 링크 대역폭 (Kbps 단위)
Delay: 누적 지연 시간 (마이크로초 단위)
K 값 (K1 ~ K5): 기본값은 K1=1, K3=1, 나머지는 0

❗ 기본적으로 Cisco에서는 대역폭(Bandwidth)과 지연시간(Delay)만 고려하고, 신뢰성(Reliability) 및 부하는 사용하지 않음.

4. EIGRP의 장점과 단점

장점

빠른 컨버전스 및 백업 경로 지원
효율적인 네트워크 트래픽 관리 (부분 업데이트)
라우팅 루프 방지 (DUAL 알고리즘 사용)
VLSM 및 CIDR 지원
IPv4 및 IPv6 지원

단점

OSPF에 비해 설정이 비교적 복잡할 수 있음
네트워크 규모가 매우 클 경우 OSPF보다 효율성이 떨어질 수 있음

5. EIGRP 기본 설정 (Cisco IOS)

아래는 EIGRP를 구성하는 기본적인 설정 방법입니다.

EIGRP 검증 명령어

show ip eigrp neighbors → 네이버 관계 확인
show ip eigrp topology → 토폴로지 테이블 확인
show ip route eigrp → EIGRP 라우팅 테이블 확인

6. EIGRP vs. OSPF 비교

중소규모 네트워크에서는 EIGRP가 유리하고,
대규모 네트워크에서는 OSPF가 더 적합합니다.

DUAL 알고리즘?

DUAL(Diffusing Update Algorithm)은 EIGRP(Enhanced Interior Gateway Routing Protocol)의 핵심 라우팅 알고리즘으로, 빠른 컨버전스와 루프 방지를 위해 사용됩니다.

EIGRP는 DUAL 알고리즘을 활용하여 네트워크의 **최단 경로(Successor)와 대체 경로(Feasible Successor)**를 계산하고, 장애가 발생할 경우 빠르게 새로운 경로를 적용합니다.

DUAL 알고리즘의 주요 개념

1) Successor (최단 경로)

현재 가장 좋은 경로(최소 메트릭 값)로, 실제 패킷이 전달되는 경로.
라우팅 테이블에 저장됨.

2) Feasible Successor (대체 경로)

Successor가 장애가 발생할 경우 즉시 대체될 수 있는 경로.
Feasible Distance(FD)보다 낮은 Advertised Distance(AD)를 가진 경로만 Feasible Successor로 선택됨.
DUAL 알고리즘 덕분에 경로 장애 시 네트워크 재탐색 없이 빠르게 전환 가능.

3) Feasible Distance(FD, 실행 거리)

현재 라우터가 네트워크까지 가기 위해 사용하는 총 비용(메트릭).

4) Advertised Distance(AD, 광고 거리)

이웃 라우터가 해당 네트워크까지 가는 데 사용하는 비용.
AD < FD 조건을 만족하는 경로만 Feasible Successor로 사용 가능.

DUAL 알고리즘 동작 과정

1. 네트워크 초기 설정

EIGRP가 동작하면 라우터는 이웃 라우터들과 Hello 패킷을 교환하여 Neighbor 관계를 형성하고, 라우팅 정보를 수집함.

2. Successor와 Feasible Successor 선정

각 라우터는 **Successor(최적 경로)**를 결정하고 라우팅 테이블에 저장.
Feasible Successor(대체 경로)가 존재하면 즉시 백업 경로로 설정.

3. 장애 발생 시 대체 경로 전환

Successor 경로가 끊어지면 Feasible Successor가 있으면 즉시 대체하여 컨버전스 시간을 줄임.
Feasible Successor가 없다면 Query 패킷을 보내 새로운 경로를 탐색.

DUAL 알고리즘의 장점

빠른 컨버전스 → Feasible Successor 덕분에 네트워크 장애 발생 시 신속한 경로 변경
라우팅 루프 방지 → Feasible Distance(FD)와 Advertised Distance(AD)를 비교하여 루프 발생 차단
효율적인 트래픽 관리 → 변경된 네트워크만 업데이트하여 대역폭 절약

DUAL 알고리즘 예제

아래와 같은 **4개의 라우터(R1, R2, R3, R4)**가 연결된 네트워크를 가정합니다.

R1에서 R4로 가는 경로 선택

R1에서 R4로 가는 가능한 경로:
1. R1 → R2 → R3 → R4 (비용: 10 + 20 + 5 = 35)
2. R1 → R4 (비용: 15)

EIGRP는 가장 낮은 비용(메트릭)이 있는 경로를 선택
➡ 따라서 R1은 **R1 → R4 (비용 15)를 Successor(주 경로)**로 선택
➡ **R1 → R2 → R3 → R4 (비용 35)는 Feasible Successor(백업 경로)**로 저장

링크 장애 발생 (R1 → R4 경로 다운)

만약 R1 ↔ R4 링크가 끊긴다면?
일반적인 라우팅 프로토콜(OSPF, RIP 등)은 새로운 경로를 계산하는 데 시간이 걸림.
하지만 EIGRP(DUAL)는 Feasible Successor(백업 경로)를 즉시 사용하여 빠르게 수렴.

➡ 즉, R1은 기존에 저장된 R1 → R2 → R3 → R4 (비용 35) 경로를 즉시 사용하여 빠른 장애 복구가 가능!

핵심 요약

DUAL 알고리즘은 Successor(주 경로)와 Feasible Successor(백업 경로)를 유지
백업 경로를 미리 계산하므로 장애 발생 시 빠르게 대체 경로로 전환 가능
EIGRP는 다른 라우팅 프로토콜보다 빠른 수렴(Convergence) 속도를 가짐

이처럼 DUAL 알고리즘 덕분에 EIGRP는 빠르고 안정적인 라우팅을 제공할 수 있습니다!

DUAL 알고리즘은 빠른 컨버전스와 네트워크 안정성을 보장하는 EIGRP의 핵심 기술입니다. Feasible Successor 개념을 활용하여 장애 발생 시 신속하게 우회 경로를 설정하는 것이 가장 큰 장점입니다.

라우팅 프토토콜의 종류 알아보기.

똥선생 — Sun, 23 Mar 2025 17:35:02 +0900

라우팅 프로토콜은 네트워크에서 라우터들이 목적지까지 최적 경로를 찾기 위해 사용하는 규칙과 절차를 말해요.

크게 두가지로 나뉜어요.

1. IGP (Interior Gateway Protocol)

→ 하나의 AS( Autonomous System ) 내부에서 사용하는 라우팅 프로토콜

특징 :

AS(Autonomous System) 내부에서 라우터들끼리 경로 교환
조직 내부, 기업 네트워크, ISP 내부 네트워크에서 사용
빠른 수렴 속도 (변경사항 빨리 반영)
최적화된 경로 찾기 위주

참고- RIP와 IGRP는 classful 방식을 사용하기 때문에 오늘날 사용하지 않는다.

classful 방식?

각각의 앞 주소만 보고도 어떤 클래스인지 알 수 있는 구조화된 방식으로 Subnet mask가 필요 없는 주소방식으로 Routing을 하여 알려주던 것

2. EGP (Exterior Gateway Protocol)

→ 다른 AS( Autonomous System ) 간에 사용하는 라우팅 프로토콜

특징:

다른 AS 간 경로 정보 교환
전 세계 인터넷의 라우팅 핵심
정책 기반 라우팅 → 단순히 빠른 경로보다 비즈니스/정책 기준 경로 선택
확장성 매우 높음
수렴 속도 느림 → 안정성 중요

라우팅 프로토콜의 동작 원리에 따라 Link State , Distance Vector로 나눌 수도 있다.

○링크 상태 (Link State) 프로토콜

동작 원리:

각 라우터는 자신의 링크 상태(인접 라우터와의 연결 상태)를 모든 라우터에게 전파합니다.
라우터는 받은 정보를 통해 전체 네트워크 맵을 구성하고, 최단 경로를 Dijkstra 알고리즘을 사용해 계산합니다.
네트워크의 변경사항이 발생하면 빠르게 업데이트합니다.

대표 프로토콜:

OSPF (Open Shortest Path First)
IS-IS (Intermediate System to Intermediate System)

장점:

빠른 수렴 속도 (네트워크 변경이 빠르게 반영됨)
루프 방지: 네트워크 상태를 정확하게 반영하므로 루프가 발생하지 않음
대규모 네트워크에 적합 (분할된 네트워크 영역을 효율적으로 관리 가능)

단점:

메모리/CPU 사용량이 많음 (네트워크 맵을 구성해야 해서)
라우터들이 모든 라우터에게 정보를 전파해야 하므로, 초기 설정이 복잡하고 많은 대역폭을 사용함

○디스턴스 벡터 (Distance Vector) 프로토콜

동작 원리:

각 라우터는 자신의 라우팅 테이블을 인접 라우터에게 주기적으로 전송합니다.
라우터는 자신이 알고 있는 경로와 인접 라우터로부터 받은 경로를 비교하고, 가장 짧은 경로를 선택합니다.
홀수/짝수 방식으로 라우팅 정보를 갱신합니다. (예: RIP는 30초마다 테이블 갱신)

대표 프로토콜:

RIP (Routing Information Protocol)
EIGRP (Enhanced Interior Gateway Routing Protocol) → 하이브리드 프로토콜이지만, 원리는 거리 벡터 방식에 기반

장점:

설정이 간단하고 구현이 쉬움
소규모 네트워크에서 효율적
대역폭 소모가 적음 (정보를 주기적으로 전파)

단점:

수렴 속도 느림 (경로 변경 시 반영이 늦음)
루프 발생 가능 (루프 방지 기법이 있지만, 여전히 발생할 가능성 있음)
최대 홉 수로 제한이 있을 수 있음 (예: RIP는 최대 15홉)

링크 상태 vs 디스턴스 벡터 비교:

쉽게 기억하기:

링크 상태 = 모든 라우터에게 정보를 주고받고 전체 네트워크 맵을 구성
디스턴스 벡터 = 인접 라우터와 정보를 교환하며 경로를 찾음, 비교적 단순하고 작은 네트워크에 적합

ping 도달은 되는데 traceroute가 안되는 이유는?

똥선생 — Tue, 18 Mar 2025 11:16:36 +0900

ping은 되는데 traceroute가 안되는 이유는 둘이 사용하는 프로토콜과 방식이 다르기 때문

1. 중간 라우터의 ICMP/UDP 차단

Traceroute는 중간 라우터에서 TTL이 0이 될 때 "Time Exceeded" 메시지(ICMP)를 보내줘야 함.
일부 방화벽이나 라우터 설정에서 ICMP Time Exceeded 메시지 또는 UDP 포트를 차단하는 경우가 많습니다.
반면, Ping의 ICMP Echo Reply는 열려 있는 경우가 있어서 ping은 성공.

2. 관리자 정책에 의한 차단

많은 기업, 기관, 또는 클라우드 서버에서는 네트워크 보안 정책상 트레이서트(특히 UDP) 요청을 차단하는 경우가 있습니다.
특히 외부에서 라우터 정보가 노출되지 않도록 막아두는 경우.

3. NAT(Network Address Translation) 환경

NAT나 방화벽이 ICMP 패킷은 허용하되, 특정 포트에서 오는 UDP 패킷(Traceroute에서 사용)을 막을 수 있습니다.

결론

ping은 되는데 traceroute가 안되는 이유는 둘이 사용하는 프로토콜과 방식이 다르기 때문.

Ping은 단순히 ICMP Echo Request로 목적지까지 연결만 확인하는 반면, Traceroute는 여러 라우터에서 TTL 초과 메시지를 받아야 하기 때문에 중간 라우터나 방화벽 설정에 따라 쉽게 차단될 수 있습니다.

해결방안

Traceroute 옵션 변경 (ICMP 기반 트레이서트 시도)
예: traceroute -I (Linux에서 ICMP로 사용)

번외,

tracert와 traceroute 차이

네트워크 장비(스위치,라우터 등)는 리눅스계열이라 traceroute 사용,,

traceroute 작동원리

Traceroute의 작동 원리는 네트워크 경로를 TTL(Time To Live) 값을 활용해 **패킷이 목적지까지 가는 경로 상의 모든 라우터(홉)**를 하나하나 확인하는 방식입니다.

TTL(Time To Live): 패킷이 네트워크를 지날 때 라우터마다 TTL 값이 1씩 감소.
TTL 값이 0이 되면, 해당 라우터는 패킷을 버리고 ICMP "Time Exceeded" 메시지를 보냄.

Traceroute의 단계별 동작

참고 : 챗gpt

CCNP 온라인으로 시험 보기(OnVCE) #2 + 꿀팁

똥선생 — Wed, 12 Mar 2025 22:55:33 +0900

https://kujung.tistory.com/entry/CCNP-%EC%98%A8%EB%9D%BC%EC%9D%B8%EC%9C%BC%EB%A1%9C-%EC%8B%9C%ED%97%98-%EB%B3%B4%EB%8A%94-%EB%B2%95-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0OnVCE-%EA%BF%80%ED%8C%81-1

CCNP 온라인으로 시험 보기 사전접수(OnVCE)

CCNP는 당일 시험도 가능합니다,.온라인으로도 볼 수 있기 때문이죠. 준비물은 필요합니다.마이크, 웹캠, 신분증(여권 추천) 노트북 한대면 모두 충족 되기 때문에 편합니다. 방법도 어렵지 않

kujung.tistory.com

사전 접수 먼저 해주세요.

먼저 중요한거 말씀드릴게요,

준비물

마이크, 웹캠, 신분증(여권 추천)

웹사이트, 기타 프로그램 모두 꺼주시구요, 책상은 비워져 있는 상태로 신분증만 올려 놓아주세요.

신분증은 여권 추천드릴게요 (감독관이 외국분이심)

여권이 아니라면 2장 정도 더 찍어야 되서 귀찮아요.

책상 치우기 귀찮으시면 부엌 식탁이나, 펴는 책상으로 바닥에 앉아서 보시는거 추천드릴게요.

시험 당일날에는 시험 시간 30분 전부터 체크인 가능하오니, 반드시 30분전에 체크인 해주세요. 돌발 상황이 발생 할 수 있으니 미리 하세요.

체크인 링크는 메일로 오는데, 혹여나 모르겠으면 대시보드 -> 스케쥴 화면에서 들어갈 수 있어요.

밑으로 드래그 쫙

VIEW 클릭 후 체크인 버튼으로 가능, 리스케쥴도 가능해요.

리스케쥴은 편하게 할 수 있어요. 시험 당일에 체크인하고서도 리스케쥴 하고싶다고 말하면 가능합니다.

체크인 하게 되면, 사전 테스트 했던 것 똑같이 하게 되고

왼쪽 , 오른쪽, 앞, 뒤 사진 및 셀카 및 신분증 사진 찍으라고 합니다.

그리고 감독관이랑 연결되어, 간단한 확인을 하게 됩니다.

테이블을 보여달라 하구요, 물건이 있으면 치우라고 합니다.

주변환경을 보여달라고 하구요.

핸드폰 멀리 치우라고 합니다.

행운을 빈다는 말과 함께 시험 시작하게 됩니다.

결과는 5분정도 이내에 나오는 것 같구요

대시보드 -> 스케쥴

view 클릭

Status 확인 하시면됩니다,

하루 정도 지나면 메일로도 옵니다.

합격을 기원합니다..

CCNP 온라인으로 시험 보기(OnVCE) #1 사전접수

똥선생 — Wed, 12 Mar 2025 22:40:16 +0900

CCNP는 당일 시험도 가능합니다,.

온라인으로도 볼 수 있기 때문이죠.

준비물은 필요합니다.

마이크, 웹캠, 신분증(여권 추천)

노트북 한대면 모두 충족 되기 때문에 편합니다.

방법도 어렵지 않습니다.

하지만 모든게 영어이고 해외 사이트이기 때문에 처음에 저는 힘들었습니다.

경험을 토대로 공유 하겠습니다.

알아 보시죠.

https://cp.certmetrics.com/cisco/en/home/dashboard

Certmetrics Candidate Portal

L o a d i n g

cp.certmetrics.com

위 사이트에 들어가 회원가입 및 로그인 해주세요.

(회원 가입을 하게 되면 메일로 인증 코드가 간다.

똥선생은 naver.com , gmail.com 메일로 여러 차례 계정 생성 시도를 했었으나,

메일 코드는 오는데, 코드를 입력해도 틀리다고 가입이 안됬었다.

여러차례 삽질하다가 계정 비밀 번호를 아주 판타스틱하게 어렵게 했더니 가입에 성공한 사례가 있다.)

로그인 됬으면 왼쪽에 SCHEDULE -> Schedule an Exam and/or Manage Pearson VUE ... 클릭

위 화면이 나오고,, 밑으로 드래그 쭉

해당 검색하는 곳에 과목 코드를 입력

오른쪽 SCHDULE 클릭

OnVue 클릭 -> next

약관 모두 체크 해주고 Agree

날짜와 시간 선택 해줍니다.

시간은 Explore more times 누르면 선택 가능합니다.

새벽 시간도 가능합니다.

이후로는 결제 해주시고,

시험 보기전에 사전 테스트 있습니다. (메일로도 내용이 옴,)

OnVue도 미리 깔고, 웹캠, 네트워크, 마이크, 실행 중인 프로그램 등등 점검 하게 됩니다!

시험 당일날도 똑같이 하오니, 사전 테스트는 반드시 해놓으시기 바랍니다 ^^

https://kujung.tistory.com/entry/CCNP-%EC%98%A8%EB%9D%BC%EC%9D%B8%EC%9C%BC%EB%A1%9C-%EC%8B%9C%ED%97%98-%EB%B3%B4%EA%B8%B0OnVCE-2-%EA%BF%80%ED%8C%81

CCNP 온라인으로 시험 보기(OnVCE) #2 + 꿀팁

https://kujung.tistory.com/entry/CCNP-%EC%98%A8%EB%9D%BC%EC%9D%B8%EC%9C%BC%EB%A1%9C-%EC%8B%9C%ED%97%98-%EB%B3%B4%EB%8A%94-%EB%B2%95-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0OnVCE-%EA%BF%80%ED%8C%81-1 CCNP 온라인으로 시험 보기 사전접수(OnVCE)CCNP

kujung.tistory.com