클라우드 엔지니어 면접을 위한 지식들

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-04-25
2023-03-19
18980

대기업에서 처음 **AWS**를 기반으로 클라우드 인프라를 설계하고 구축했 당시만 해도 서울리전이 없어서 도쿄 리전에 인프라를 전개했었다. 그게 지금으로부터 10년 전인 것 같다. 횟수로만 따져도 10년 이상을 클라우드 환경에서 일을 한 셈이다. 지금은 DevOps 엔지니어에 가까운 것 같지만 어차피 DevOps 업무도 클라우드 환경에서 하고 있으니.

하여, 클라우드 엔지니어와 DevOps 엔지니어를 위한 지식들을 정리해보기로 했다. 내가 면접관으로써 준비하는게 아니고, 면접을 보는 입장에서 정리하는 것이다. 경력이 경력이다 보니, 솔류션 아키텍트나 테크니컬 어카운트 매니저 역할도 생각하는 중이라서 미리 정리해 두면 좋을 것 같아서다. 이번에 정리할 내용은 "네트워크"로 이외에
1. 가상화와 컨테이너
2. Storage
3. 클라우드 개요 
5. 리눅스 시스템/네트워크 관리
4. 보안
5. 데이터베이스
6. 클라우드에서의 가용성, 확장성, 안정성 
을 다룰 게획이다. 모든 글은 **AWS Cloud** 를 기준으로 한다.

## 넓고 얉게
TCP를 살펴보는데 TCP 헤더 수준에서 깊이있는 분석을 하지는 않을 것이다. 클라우드 환경에서는 인프라의 많은 구성요소들이 더욱더 추상화된다. 저수준의 인프라에는 덜 집중하고 비즈니스 애플리케이션 영역에 더 집중하는 경향을 가지고 있다.

따라서 세부 인프라 관점이 아닌 비즈니스 관점에서 접근하며, 깊이는 얕게하고 넓이 우선으로 살펴볼 것이다. 이 문서는 일종의 길잡이 역할을 할 수 있을 것이다. 자세한 내용들은 직접 학습을 해야 할 것이다.

## OSI 7 Layer
**OSI(Open Systems Interconnection)** 모델은 서로 다른 시스템 또는 장치간의 네트워크 통신을 위한 표준 모델이다. 네트워크를 구성하기 위해서는 물리적인 장치에서부터 시작해서 애플리케이션까지 다양한 구성요소들의(프로토콜, 라이브러리 등) 지원이 필요하다. OSI는 이러한 구성요소들을 7개의 계층으로 분리하여서 표준화 함으로써, 쉽게 네트워크 애플리케이션을 개발할 수 있는 환경을 제공한다.

OSI 모델은 아래와 같다. OSI 모델외에 TCP/IP 모델도 포함하고 있다.

![OSI Model](https://docs.google.com/drawings/d/e/2PACX-1vSYzk42rgGazVosiVFhjNBF--ml-mMGqjhfokzBPjVb_7oLuz64hpCrnDdIOC6Ltqpnuy0Zb_AlfeL3/pub?w=847&h=371)
1. Pysical Layer (물리 계층): 통신 채널을 위한 원시 비트 전송을 처리한다. 케이블, 무선 신호, 광섬유와 같은 물리적 매체의 사용을 포함한다. 
2. Data Link Layer (데이터 링크 계층) : 네트워크상에 인접한 두 노드 간에 오류없는 데이터 전송을 제공한다. 여기에는 흐름제어, 오류감지 및 오류 수정을 위한 프로토콜이 포함된다.
3. Network Layer (네트워크 계층) : 서로 다른 네트워크 간의 데이터 패킷의 논리적인 주소 지정 및 라우팅을 담당한다. 패킷의 주소 지정, 라우팅 전달을 위한 프로토콜이 포함된다. 유명한 TCP/IP 프로토콜 슈트의 **IP**가 네트워크 계층의 대표적인 프로토콜이다.
4. Transport Layer (전송 계층) : 최종 시스템 간에 안정적이고 투명한 데이터가 가능하도록 한다. 여기에서는 연결설정, 세션관리 및 데이터 무결성 보장을 위한 프로토콜이 포함된다. TCP와 UDP가 주요 프로토콜이다.  
5. Session Layer (세션 계층) : 응용 프로그램간의 세션 설정, 유지 관리, 종료를 처리한다. 여기에는 동기화와 체크포인트 및 복구를 위한 프로토콜이 포함된다.
6. Presentation Layer (프리젠테이션 계층) : 암호화, 압축, 데이터 표현과 같은 서로 다른 데이터 형식간의 변환을 처리한다.
7. Application Layer (애플리케이션 계층) : 이 계층은 사용자 애플리케이션과 네트워크간의 인터페이스를 제공한다. FTP, HTTP, SMTP와 같은 다양한 애플리케이션을 위한 프로토콜이 포함된다.

클라우드 엔지니어라면 전체 개념을 알고 있어야 겠고 특히 **네트워크 계층,전송 계층과 애플리케이션 계층**은 숙달하고 있어야 한다. 이 중 전송 계층과 애플리케이션 계층의 경우 클라우드 인프라 구성요소들인 Network LoadBalancer(L4 로드밸런서), Application LoadBalancer(L7 로드밸런서)과 직접적으로 관련있는 프로토콜이다. L4 로드밸런서와 L7 로드밸런서에 대한 설명은 필수 면접 질문이다.

**TCP/IP** 모델은 OSI 모델보다 오래된 모델로 미국 국방부(DoD)에서 만들었다. 두 모델의 주요 차이점은 TCP/IP가 더 간단하며 여러 OSI 게층을 하나로 합쳤다는 점이다.

#### OSI 모델의 이점 
1. 상호 운용성 : 서로 다른 시스템이 하드웨어, 소프트웨어, 네트워크 프로토콜에 관계 없이 서로 통신할 수 있도록 돕는다. 오늘날의 모든 네트워크 제조업체는 이 모델을 표준으로 채택하고 있으므로 장치간 원할한 통신이 가능하다.
2. 문제해결 : 계층으로 나누어져 있기 때문에 문제의 원일을 보다 쉽게 파악할 수 있다. 통신 애플리케이션에서 문제가 발생했을 때, 인프라 담당자와 소프트웨어 개발자, 네트워크 어드민이 서로 업무를 나눠서 협력할 수 있는 것도 OSI 모델 덕분이다.
3. 모듈식 설계지원 : 애플리케이션 개발자는 자신의 계층만 신경써서 애플리케이션을 개발할 수 있다. 또한 이미 표준화된 다른 구성요소들을 사용 할 수 있으므로 네트워크 애플리케이션 설계과 개발이 간소화되고 비용을 절감할 수 있다.

## TCP / UDP
OSI 계층은 백여개가 넘는 프로토콜을 포함하고 있다. 이들 모든 프로토콜을 암기하고 있을 필요는 없다. TCP/IP Suit에 있는 10개 정도의 프로토콜을 이해하고 있으면 된다. 가장 중요한 프로토콜인 TCP / UDP를 살펴보자. 
1. **TCP(Transmission Control Protocol)** : 네트워크를 통해서 두 개의 애플리케이션이 안정적으로 연결을 설정 및 유지하는데 사용하는 프로토콜이다. 네트워크상에서 데이터는 패킷으로 쪼개져서 전달되기 때문에 순서가 변경되거나 특정 패킷에 오류가 생길 수 있다. TCP는 오류를 확인해서 재 전송하고 순서를 관리하여 이러한 문제를 해결한다. 
2. **UDP (User Datagram Protocol)** : 송신자와 수신자사이에 신뢰할 수 있는 연결을 설정하고 않고 데이터를 전송한다. TCP와 달리 패킷의 오류검사, 재전송 등의 기능은 제공하지 않는다.

두 프로토콜의 차이점은 아래와 같다.
|           | TCP            | UDP             |
| --------- | -------------- | --------------- |
| 연결방식  | 연결형         | 비연결형        |
| 패킷교환  | 가상 회선 방식 | 데이터그램 방식 |
| 순서 보장 | 보장           | 보장하지 않음   |
| 신뢰성    | 높음           | 낮음            |
| 전송속도  | 느림           | 빠름            |

## IP
IP는 네트워크에 연결되는 장치들을 식별하기 위한 주소체계다. 모든 컴퓨터(정확히는 네트워크 인터페이스)는 고유의 번호를 부여 받으며 이를 통해서 통신을 할 수 있다.

IP는 IPv4와 IPv6의 두 가지 주요 버전이 잇다. IPv4는 가장 널리 사용하고 있는 버전으로 32비트 주소로 구성되며 IPv6는 128비트 주소를 사용하고 있다. 버전을 생략하고 IP라고 하면 일반적으로 IPv4를 의미한다.

**IP 주소 표현**. IP주소는 마침표를 구분자로 하는 4개의 숫자로 구성된 10진수 형식으로 표현한다. 각 숫자의 범위는 0에서 255이며 **192.168.5.4**와 같이 표시한다.

**IP Class**. IP는 매우 큰 주소 범위를 가지고 있기 때문에 이를 효과적으로 관리하기 위해서 IP Class로 구조화한다.

IP Class 는 A, B, C, D, E 5개의 클래스가 있으며, A 클래스, B 클래스와 같이 부른다. 각 클래스마다 서로 다른 IP 주소 범위를 가지고 있다. 일반적으로 A, B, C 3개의 클리스를 주로 사용한다.
![IP Class](https://docs.google.com/drawings/d/e/2PACX-1vTZDRoec-GsXIoTdqqJHXrcceO_9vZYDyjOLrobB28y3a2WNn5LHnggPlPWaxFHjfJXD_dJtivExMqs/pub?w=886&h=467)

* Class A : 대규모 네트워크에서 사용한다. 첫 번째 옥텟은 네트워크를 식별하는데 사용하고 나머지 세 옥텟은 네트워크 호스트에 IP를 할당하기 위해서 사용한다.
* Class B : 중형 네트워크에 사용한다. 처음 두 옥텟은 네트워크를 식별하는데 사용하고 나머지 세 옥텟은 네트워크 호스트에 IP를 할당하기 위해서 사용한다.
* Class C : 소형 네트워크에 사용한다. 처음 3 옥텟은 네트워크를 식별하는데 사용하고 나머지 세 옥텟은 네트워크 호스트에 IP를 할당하기 위해서 사용한다.
* Class D : 단일 패킷을 여러 장치에 동시에 보낼 수 있는 멀티캐스트 주소에 사용한다.
* Class E : 실험용으로 예약되어 있으며 일반 네트워크 통신에는 사용하지 않는다.

이해하기 쉽게 IP Class의 네트워크 범위를 테이블로 정리했다.
| Class | 1st octet of IP address | Defatul subnet Mask | Network / Host | Number of Networks | Maximum nodes in a network |
| ----- | ----------------------- | ------------------- | -------------- | ------------------ | -------------------------- |
| A     | 1-126                   | 255.0.0.0           | N.H.H.H        | 126                | 16,777,214                 |
| B     | 128-191                 | 255.255.0.0         | N.N.H.H        | 16,384             | 65,534                     |
| c     | 192-223                 | 255.255.255.0         | N.N.N.H      | 2,097,152          | 254                     |

**사설 IP(Private IP)** 는 공용 네트워크(Internet)이 아닌 LAN(Local Area Network)와 같은 사설 네트워크에서 사용하는 IP 주소다. 사설 IP 주소는 사설 네트워크에서만 사용할 수 있으며 인터넷에서는 라우팅 할 수 없다.

사설 IP는 IP Class 별로 예약되어 있으므로 조직의 네트워크 규모에 따라서 사용하면 된다.
| Class | start address | finish address |
| ----- | ------------- | -------------- |
| A     | 10.0.0.0      | 10.255.255.255 |
| B     | 172.16.0.0    | 172.31.255.255 |
| C     | 192.168.0.0   | 192.168.255.255 |

## CIDR
"사이더"라고 부르기도 하는 **CIDR(Classless Inter-Domain Routing)** 는 IP 주소를 할당할 수 있는 네트워크 및 호스트 주소를 정의하기 위해 사용하는 방법이다. CIDR는 네트워크 주소 범위를 편리하게 관리하기 위해서 CICR 표기법으로 표현한다.

CIDR 표기법은 네트워크 주소와 서브넷 마스크를 표현하는 방법으로, 사용하는 네트워크의 비트 수를 슬래시(/) 다음에 나타내는 형식을 가진다.

![CIDR](https://docs.google.com/drawings/d/e/2PACX-1vR-sQ2WWrACTzos5fym96YPoeiKvcb34vjojkPp76y0wjWJ9V9QfV53JKdLCPCaZxrdevZcPZKOdQ31/pub?w=465&h=135)
예를 들어 192.168.2.0/24 가 있다고 하면, 네트워크의 비트수가 24이다. 따라서 사용가능한 IP 범위는 256개로, 192.168.2.0 ~ 192.168.2.255 가 된다.

Subnet mask라고도 부르는 **NETMASK**는 IP 주소의 네트워크 부분과 호스트 부분을 정의하기 위해 사용하는 32비트 주소다. NETMASK를 이용해서 IP 주소를 네트워크와 호스트로 나눌 수 있다.

넷마스크는는 1과 0으로 구성되며, 1의 수가 주소의 네트워크의 크기를 결정한다. 예를 들어서 소규모 네트워크로 일반적으로 사용되는 24 비트 넷마스크는 11111111.11111111.11111111.00000000로 표시가 된다. 앞의 24 비트가 네트워크를 식별하는데 사용되고, 나머지 8비트는 네트워크의 개별호스트를 식별하는데 사용한다.

위의 예제의 경우 NETMASK는 255.255.255.0 이 되고 호스트의 크기가 / 24 이므로 192.168.2.0 ~ 192.168.2.255 가 된다. NETMASK는 CIDR과 함께 널리 사용된다.

## Subnet
AWS에서 네트워크를 구성하기 위해서 10.1.0.0/16 네트워크를 사용하기로 했다고 가정해보자. 이 네트워크는 16 비트를 호스트에 할당 할 수 있으므로 65,536의 호스트를 수용할 수 있는 거대한 네트워크다. 이 거대한 네트워크를 사용하는 것은 비효율적이므로 네트워크를 나눠서 사용하는데 이를 **서브넷(subnet)** 이라고 한다.

Subnet은 매우 단순한 개념이다. 거대한 건물을 하나의 방으로 구성하지 않는 것과 동일한 이유로 subnet으로 네트워크를 나눠서 사용한다. 그 이유는 아래와 같다.
 * 보안 : 이용해서 중요 장치를 경리하기 위한 서브넷을 따로 구성하고 보안장치들을 추가할 수 있다.
 * 효율성 : 대규모 네트워크를 더 작은 네트워크로 나누면 네트워크 트래픽을 더 잘 관리하고 라우팅 할 수 있으므로 네트워크 성능이 향상된다.
 * 확장성 : 서브넷을 사용하면 애플리케이션이 확장함에 따라 서브넷을 추가할 수 있으므로 네트워크를 쉽게 확장 할 수 있다.

![subnet](https://docs.google.com/drawings/d/e/2PACX-1vTp6jFd2rsrmTXWDtow9IK3QrOMPYQDPgyG7cVpap5L7O0beNS_xhItrjmjuEEsL7G8q7tSbrcfXky9/pub?w=746&h=435)

## 3-Way Handshake
TCP는 서버와 클라이언트가 서로 연결을 맺는다. 이렇게 맺어진 **가상의 전용 회선** 에서 통신을 한다. 이를 위해서는 서버와 클라이언트가 서로를 확인하고 연결을 만들기 위한 과정을 거쳐야 한다. 이 과정은 총 3번의 패킷교환으로 완성되는데, 이를 3-Way Handshake 라고 한다.

3-Way Handshake 의 과정은 아래와 같다.

![3-Way Handshake](https://docs.google.com/drawings/d/e/2PACX-1vTdfAFeoBfyjpLwgoAR-bidTIsG41mBWpDWq6D6pb-nZgTGfJku4D0j6jVpvafVyZcTFAPzXytGefpJ/pub?w=751&h=551)

1. SYN(Synchronize) : 클라이언트가 서버에 SYN 패킷을 전송하여 연결을 요청한다.
2. SYN-ACK(Synchronize-acknowledge) : 서버는 SYN-ACK 패킷을 응답하여 SYN 패킷을 수신했으며 연결을 설정할 수 있음을 알린다.
3. ACK(acknolege) : 클라이언트는 서버에 ACK 패킷을 전송하여 SYN-ACK 패킷을 수신했으며, 연결을 설정할 것임을 확인한다.

3-Way Handshake가 완료되면 클라이언트와 서버 모두 생성된 TCP 연결을 통해 데이터를 교환할 준비가 된다.

## Proxy
프록시(Proxy)는 네트워크와 네트워크 사이에서 트래픽을 중계해 주는 중계 서버다.

![Proxy](https://docs.google.com/drawings/d/e/2PACX-1vQK5KUZ5N2u-ULKSxQtNuf3o-YZD2O6bdpNaNevIApTdwdSgfp3W04nSmJnJ_fchWmOh5c_Qt5zv8Pt/pub?w=665&h=178)
Proxy는 아래와 같은 이유로 사용한다.
1. 보안 : Proxy 서버는 내부 서버 IP를 숨겨서 보호할 수 있다. 이로 인해 공격자는 서버를 특정하고 공격하기가 어려워진다. 또한 Proxy 서버에 보안솔류션을 설치하여서 다양한 방법으로 내부 네트워크를 보호할 수 있다.
2. 성능 : Proxy 서버는 웹 페이지와 같이 자주 사용하는 파일을 캐시하여서 서버의 부하를 줄이고 클라이언트의 액세스 시간을 단축할 수 있다. 또한 부하를 분산시킴으로써 전반적인 성능을 향상시킬 수 있다.
3. 컨텐츠 필터링 : 미리 정의된 규칙에 따라서 특정 리소스 또는 컨텐츠에 대한 액세스 권한을 설정할 수 있다.

Proxy는 크게 Reverse Proxy, Forward Proxy가 있다.
#### Reverse Proxy
![Reverse Proxy](https://docs.google.com/drawings/d/e/2PACX-1vRHImEsloofogYTV25KLm7muYueub5a5cooe7G5qQ3_3Z-8BGozdZjzl54dBhibJRB4Pi-3mE1WcJyC/pub?w=525&h=265)

리버스 프록시는 역방향 프록시라고 부르기도 한다. 리버스 프록시는 클라이언트의 요청을 받아서 적절한 서버로 요청을 전달하는 일을 한다. 서버의 응답은 리버스 프록시로 반환되고 다시 클라이언트로 반환한다.

리버스 프록시는 성능과 안정성을 향상시키기 위해서 웹 애플리케이션에서 자주(거의 필수로)사용한다. 클라이언트의 요청을 여러 서버로 분산시켜서 서버의 과부하를 방지하여 요청이 효율적으로 처리되도록한다. 또한 외부로 부터 내부 백앤드 서버를 숨길 수 있기 때문에 악의적인 트래픽을 차단하며, 추가적인 보안 계층을 추가할 수도 있다.

**Apache, NginX, HAProxy** 등이 대표적인 리버스 프록시 애플리케이션이다.

#### Forward Proxy
![Forward Proxy](https://docs.google.com/drawings/d/e/2PACX-1vRHImEsloofogYTV25KLm7muYueub5a5cooe7G5qQ3_3Z-8BGozdZjzl54dBhibJRB4Pi-3mE1WcJyC/pub?w=508&h=264)
포워드 프록시는 역방향 프록시의 반대다. 클라이언트와 인터넷 사이에 위치하면서, 클라이언트의 요청을 인터넷으로 전달하는 일을한다. 클라이언트가 특정 웹 사이트에 접근을 요청할 경우, 프락시 서버가 클라이언트를 대신하여 웹 서버에 요청을 하고 이를 다시 클라이언트로 보낸다.

포워드 프록시는 일반적으로 네트워크 내에서 인터넷에 대한 액세스를 제어하거나 자주 요청하는 리소스를 캐싱하여 성능을 향상시키기 위한 목적으로 사용한다.

## Load Balancer
로드 밸런서는 클라이언트의 요청을 여러 서버로 분산 전달해서 부하를 분산하는 일을하는 장치 혹은 소프트웨어다. 기본적으로 리버스 프록시와 매우 유사하며, 살제로 로드 밸런서는 리버스 프록시의 구현체라고 볼 수 있다.

![Load Balancer](https://docs.google.com/drawings/d/e/2PACX-1vSGGU0PNFm5_LXnVRHht3nnBDPw_6rsiwSTUscqjMfUcZ8R2IOCun3Z03OK8utvzZGGb9VfUBGX8TkQ/pub?w=629&h=284)
앞서 리버스 프록시 애플리케이션으로 소개한 HAProxy, NginX, Apache는 실제 로드밸런서를 구현하기 위해서 사용한다.

로드 밸런서는 다양한 프로토콜을 분산할 수 있는데, OSI 7 계층에서 어떤 계층의 프로토콜을 분산 처리하느냐에 따라서 L4 Load Balancer와 L7 Load Balancer로 나눈다. 각각 OSI 모델 계층의 이름을 따라서 네트워크 로드밸런서, 애플리케이션 로드밸런서라고 부른다.

#### L4 Load Balancer
**L4 로드 밸런서는 전송 계층의 프로토콜을 이용해서 로드를 분산**하는 네트워크 장치 혹은 애플리케이션을 의미한다.

즉 L4 로드 밸런서는 네트워크 패킷의 헤더의 Source IP, Destination IO, TCP/UDP 포트 번호와 같은 정보를 기반으로 라우팅을 결정한다.

L4는 일반적으로 SMTP, FTP, DNS와 같은 프로토콜의 부하분산에 사용한다. L4는 애플리케이션 계층을 신경쓰지 않기 때문에 HTTP의 부하분산에도 사용 할 수 있지만, HTTP는 L7 로드밸런서로 부하분산하는게 일반적이다.

L4는 애플리케이션 계층에 비해서 상대적으로 간단한 데이터를 기반으로 라우팅을 결정하기 때문에 L7 로드 밸런서에 비해서 더 빠르게 대용량의 요청을 부하분산 할 수 있다.

#### L7 Load Balancer
**L7 로드 밸런서는 애플리케이션 계층의 프로토콜을 이용해서 로드를 분산**하는 네트워크 장치 혹은 애플리케이션를 의미한다.

이론적으로는 모든 애플리케이션 프로토콜에 대한 로드 밸런서를 개발할 수 있겠지만, 실무에서 L7 로드 밸런서라고 하면 **HTTP(S)에 대한 로드밸런서**를 의미한다. 웹 기반 애플리케이션의 부하분산을 위해서 필수로 들어가는 장치다.

L7 로드 밸런서는 HTTP의 헤더와 본문정보를 이용해서 다양한 라우팅 정책을 설정할 수 있다. 즉 HOST 기반 라우팅, 컨텐츠 기반 라우팅, URL PATH 기반 라우팅, Cookie 기반 라우팅 설정이 가능하다. 또한 HTTP 메서드(GET, POST, PUT, DELETE) 기반으로도 라우팅 할 수 있다.

![L7 Load balancer](https://docs.google.com/drawings/d/e/2PACX-1vSKBzKw18UsGpCtwlQDxiNox98ps-qrJTYRPwwnL7ERHOmazXi5FNlne1VDTljNte7dRGiFdzRBC7L2/pub?w=799&h=300)

IP와 PORT를 기반으로 라우팅하는 L4 로드밸런서와 비교해서 L7 로드밸런서는 고급기능을 가지고 복잡한 기능을 수행할 수 있다. 반면 L4 로드밸런서에 비해서 오버헤드가 많기 때문에 대기시간이 늘어날 수 있다.

L7 로드밸런서는 아래와 같은 기능들을 제공한다.
1. 고급 라우팅 : HTTP 헤더, 쿠키, 본문 데이터 기반으로 트래픽을 라우팅 할 수 있다.
2. SSL temination : SSL/TLS(Secure Sockets Layer/Transport Layer Security)연결을 종료하며 클라이언트와 서버간의 트래픽을 암/복호화 할 수 있다.
3. Sesseion persistence : 클라이언트 요청이 주어지면 해당 세션이 항상 동일한 서버로 전달되도록해서 세션 지속성을 유지할 수 있다.
4. Health Check : 백앤드 서버상태를 모니터링하여 정상서버로만 트래픽을 라우팅 할 수 있다.
5. 컨텐츠 기반 라우팅 : URL 경로, 쿼리 매개변수, 응답 콘텐츠를 기반으로 라우팅 할 수 있다.
6. 다양한 로드밸런싱 알고리즘 지원 : 라운드로빈(round-robin), 최소연결(least connection), IP Hash 및 사용자 지정 알고리즘을 포함하여 다양한 방법으로 트래픽을 분산할 수 있다.
7. Contents Caching : 콘텐츠를 캐싱하여 백앤드 서버의 부하를 줄이고 성능을 향상시킬 수 있다.
8. Contents Compression : 클라이언트에 컨텐츠를 전송하기 전에 압축하여 네트워크 대역폭 사용량을 줄일 수 있다.
9. Rate Limiting : 요청속도를 관리하여 백앤드 서버의 과부하를 방지할 수 있다.
10. DDOS 보호 : 트래픽을 필터링하고 악의적인 요청을 차단하여 DDoS 공격으로 부터 백앤드 서버와 데이터를 보호할 수 있다.

## NAT
**NAT(Network Address Translation)** 은 내부 네트워크(Private Network)의 장치가 인터넷에 접근할 수 있도록 하는 네트워킹 기술이다.

내부 네트워크는 private ip를 사용하기 때문에 직접적으로 인터넷에 연결할 수 없다. NAT는 Private IP를 Public IP로 변환(translation)해주기 때문에 NAT를 이용해서 인터넷과 연결할 수 있다.

![NAT - Network Address Translation](https://docs.google.com/drawings/d/e/2PACX-1vQ88tfxJaPJAkcvcIeU2ZWlRYsH69MfVIRGGHJRwZx5IuBpYgiQNgudZ6R0tMhNQEBkKqj4ihSKrlcP/pub?w=794&h=340)

아래와 같이 3가지 NAT 방법들이 있다.
1. Static NAT: 고정된 Public IP로 NAT 된다.
2. Dynamic NAT: Public IP의 풀(pool)이 있어서, 이 중 하나를 선택해서 사용한다.
3. PAT(Port Address Translation): NAPT(Network Address Port Translation)이라고도 하며, 로컬 네트워크의 각 장치에대해서 서로 다른 포트를 할당하여 Public IP로 매핑해서 사용한다.

NAT는 제한된 수의 Public IP를 사용할 수 있지만, 여러 장치가 동시에 인터넷에 접근해야 하는 가정 및 기업 네트워크에 일반적으로 사용한다.

클라우드의 경우 내부 네트워크에 있는 장치들이 인터넷에(외부 API를 호출하거나 데이터를 가져와야 하는 등) 접근해야 할 때 주로 사용한다. 
![NAT](https://docs.google.com/drawings/d/e/2PACX-1vTwsSXl0uJvvNkft_g6D6ZRgztQVdswx4FM6dsmtSoZYZW6S8p6WCvz44ku14ynnnQKkwLX7Mu9gb7k/pub?w=919&h=314)

## Bastion
Jump server 혹은 Jump box라고 부르기도 하는 Bastion 서버는 데이터 센터나 클라우드에 구축된 사설 네트워크에 있는 서버에 안전하게 접근할 수 있도록 관리하는 전용 서버다.

AWS VPC 네트워크의 경우 Public Subnet과 Private Subnet으로 구성을 하는데, 모든 서버와 주요 리소스들은 Private Subnet에 배치한다. Private Subnet은 인터넷에서 바로 접근 할 수 없는데, 이렇게 해서 보안수준을 높일 수 있다. 하지만 보안 수준이 높아지는 반면 관라/운영상의 이유로 서버에 접근하기도 어려워진다.

아래와 같이 Public subnet에 Bastion 서버를 두는 방법으로 이 문제를 해결할 수 있다. 
![Bastion](https://docs.google.com/drawings/d/e/2PACX-1vTwsSXl0uJvvNkft_g6D6ZRgztQVdswx4FM6dsmtSoZYZW6S8p6WCvz44ku14ynnnQKkwLX7Mu9gb7k/pub?w=805&h=307)

## Network Firewall
**네트워크 방화벽(Network Firewall)** 은 미리 정의된 보안 규칙들을 내장하고 있는 네트워크 보안 장치 혹은 소프트웨어다. 네트워크 방화벽은 보호하려는 네트워크 앞에 놓여서 들어오고 나가는 네트워크 트래픽을 모니터링하면서 보안 규칙을 위반하는 트래픽을 차단한다.

네트워크 방화벽은 애플리케이션 계층(7 계층), 전송 계층(4 계층), 네트워크 계층(3 계층) 등 다양한 계층에서 작동할 수 있다. 네트워크 방화벽의 주요 기능은 아래와 같다.
1. Packet filtering : 네트워크 패킷의 헤더를 검사하고 Source IP, Target IP, Port 번호 등의 속성을 이용해서 패킷을 차단할 수 있다.
2. Stateful inspection : 네트워크의 연결상태를 추적하여 설정된 연결의 트래픽만 허용하게 할 수 있다.
3. Application-level filtering : 네트워크 패킷의 내용을 검사하는 방식으로 사용 중인 애플리케이션 또는 프로토콜 유형에 따라서 트래픽을 차단할 수 있다.
4. VPN(Virtual Private Network) 지원 : VPN 터널을 통해 내부 네트워크에 대한 보안 원격 설정을 할 수 있다. 
5. Instrusion detection and prevention : 악의적인 활동 징후가 있는지 네트워크를 모니터링하여 네트워크 공격을 감지한다.
6. NAT : 방화벽은 NAT의 역할도 함께 수행한다.

AWS 클라우드의 경우 호스트 레벨의 방화벽인 **Security Group** 을 이용하며, 기타 3rd-party 방화벽 솔류션을 이용해서 보안을 강화할 수 있다.

### DDoS
**DoS(Denail of Service)** 는 특정 서버를 공격해서 대상 서버가 서비스를 하지 못하도록 하는 공격을 의미한다. 서버가 서비스를 하지 못하게 하려면 서버가 감당할 수 없는 CPU 부하, 네트워크 대역폭 부하 및 메모리 부하를 발생시켜야 하는데 보통 서버는 상당히 강력한 커뮤팅 파워를 가지고 있으므로 분산해서 공격하는 방식을 사용한다. 즉 DDoS(Distributed Denial of Service)는 DoS의 분산버전이다. 또한 공격 진원지가 분산되기 때문에 막기가 어렵다.

![DDoS](https://docs.google.com/drawings/d/e/2PACX-1vQUmUTkEvSR6-TwbyB_Z4c-1rvqQ4itFHQL9UJ9V1KcDV1yUY2sLusXpGppyK-FPOQfr0UdefodG32q/pub?w=702&h=333)

DDoS 공격은 좀비서버라고도 하는 맬웨어에 감염된 컴퓨터 네트워크를 만들어서 공격을 한다. 이들 다수의 좀비서버는 대상 시스템에 엄청난 양의 요청 또는 데이터를 보내서 합법적인 사용자가 서비스에 접근 할 수 없게 한다.

DDoS를 막는 방법들은 아래와 같다.
1. CDN을 이용 : CDN은 여러 서버에 트래픽을 분산시켜 공격자가 단일 서버를 대상으로 공격하는 걸 어렵게 만든다.
2. 방화벽 및 침입탐지 시스템 구현
3. 네트워크 트래픽 모니터링
4. DDoS 방지서비스 사용
5. Rate Limiting 기능의 사용

AWS 클라우드에서는 AWS Shield, AWS WAF, AWS CloudFront, Autoscaling 를 이용해서 DDoS 방어 혹은 완화하는 시스템을 구축한다.

## DNS
DNS는 **Domain Name System**의 줄임말이다. 192.168.2.1과 같이 컴퓨터가 읽을 수 있는 IP주소를 www.example.com 과 같이 사람이 읽을 수 있는 이름과 맵핑하기 위해서 사용한다.

웹 브라우저에서 도메인 이름을 입력하면 브라우저는 도메인이름을 IP 주소로 변환하기 위해서 DNS 서버로 요청을 보낸다. DNS 서버는 데이터베이스에서 도메인 이름을 조회하여 IP 주소를 반환한다. 웹 브라우저는 IP 주소를 이용해서 웹 서버에 연결할 수 있다.

DNS는 인터넷 상에서 웹 사이트 및 리소스를 쉽게 액세스 할 수 있도록 도와주는 **데이터베이스 서비스**다. 다른 데이터베이스 서비스와 마찬가지로 DNS는 여러 정보들을 저장하고 있는데 이를 **레코드(Record)** 라고 한다. 주요 레코드는 아래와 같다.

1. A (Address) : IPv4 주소와 도메인 이름을 맵핑한다.
2. AAAA (IPv6 Address) : IPv6 주소와 도메인 이름을 맵핑한다.
3. CNAME (Canoncial Name) : 도메인 정식이름(canoncial name)에 대한 별칭.
4. MX (Mail Exchange) : 도메인에 대한 이메일을 처리하는 메일 서버를 지정한다.
5. NS (Name Server) : 도메인 서비스를 위한 네임 서버를 지정한다.
6. SOA (Start of Authority) : 
7. TXT (Text) : 이메일 인증에 사용하는 SPF(Sender Policy Framework)레코드와 같이 도메인과 관련된 추가적인 정보를 포함한다.
8. SPF(Sender Policy Framework) : 도메인 소유자가 도메인을 대신하여 이메일을 전송할 수 있는 서버를 지정하여 이메일 스푸핑 또는 피싱 공격을 방지하기 위해서 사용한다.

**TLD(Top-Level Domain)** 혹은 최상위 도메인은 DNS 이름에서 마지막 점(".")뒤에 오는 도메인 이름을 의미한다. TLD는 인터넷에서 가장 높은 수준의 도메인 이름을 나타낸다. 예를 들어 "example.com"에서 TLD는 ".com" 이다. ".org", ".co.kr", ".io", ".gov" 등이 TLD 이다.

TLD는 크게 일반 최상위 도메인(gTLD)와 국가 코드 최상위 도메인(ccTLD)의 두 가지 유형이 있다.

gTLD는 특정 국가나 지역에 한정되지 않는 일반적인 목적으로 사용한다. ".com", ".org", ".net", ".edu" 등이 gTLD의 예이다.

ccTLD는 국가나 지역에 따라 달라진다. 영국의 경우 ".uk", 프랑스 ".fr", 미국 ".us", 대한민국 ".co.kr"등이 있다.

**DNS 구성 요소**
DNS는 아래의 3가지 요소로 구성된다.
* 도메인 네임 스페이스(Domain Name Space) 
* 네임 서버(Name Server) : 권한 있는 DNS
* 리졸버(Resolver) : 권한 없는 DNS

네임 서버(DNS 서버와 동일)는 도메인 이름에 대한 IP 정보를 포함한 레코드를 저장하고 있는 서버다.

DNS recursive resolver이라고 부르기도 하는 **DNS Resolver** 는 DNS 이름을 IP 주소로 변환하는 역할을 하는 서버다. DNS Resolver는 클라이언트와 DNS Server의 중간에 위치하는데, 어떤 네임서버로 요청을 해야하는지에 대한 정보를 가지고 있다. 또한 캐시도 가지고 있는데, 클라이언트가 요청한 도메인 정보가 캐시에 저장되있다면, 클라이언트에게 바로 반환한다.

**DNS 작동 과정**
![DNS 작동 프로세스](https://docs.google.com/drawings/d/e/2PACX-1vSI3zug06UqV3u3svMOskLtFg3oLCXZxqrqzwg54jjUtKNFA0TdqshVrjr0KBUKyZfSjDxnWhPX3GZe/pub?w=765&h=575)
1. 웹 브라우저(Client)에 www.example.com 를 입력한다. 웹 브라우저는 Resolver Server에 www.example.com 에 대한 IP 주소를 요청한다.
2. Resolver Server는 Root Name Server에 .com TLD 네임 서버에 대한 IP 정보를 요청하고, Root Name Server는 .com TLD 서버의 IP 5.6.7.8 을 반환한다.
3. Resolver Server는 .com TLD 네임 서버에 www.example.com example.com SLD 네임 서버의 IP를 요청하고, .com TLD Name Server는 1.2.3.4 를 반환한다.
4. Resolver Server은 SLD 네임서버에 www.example.com 의 IP를 요청하고 SLD 네임 서버는 123.123.123.123을 반환한다.
5. Resolver Server는 121.123.123.123을 클라이언트에 반환하고, 클라이언트는 해당 IP로 연결을 한다.

## VPC
VPC(Virtual Private Cloud)는 AWS에서 제공하는 서비스로 가상의 네트워크를 구성할 수 있게 해준다. 사용자는 VPC를 사용해서 자체 데이터 센터로 생각 할 수 있는 논리적으로 격리된 네트워크를 만들 수 있다. 이 네트워크는 IP 주소, 서브넷, 라우팅 테이블, 인터넷 게이트웨이, NAT를 포함하여 가상 네트워크 환경을 완벽하게 제어할 수 있다.

VPC로 만든 네트워크 위에 **EC2 인스턴스(가상머신)**, 데이터베이스, 로드밸런서 등의 모든 AWS 리소스가 실행된다.

VPC 네트워크는 네트워크 구성을 위한 모든 구성요소를 포함하고 있기 때문에, 별도의 문서에서 집중적으로 다룰 것이다.

## VPN
VPC(Virtual Private Network - 가상 사설망)은 네트워크와 네트워크 혹은 사용자와 네트워크간에 암호화된 암호화된 네트워크 연결을 생성하는 기술이다. VPN은 인터넷 상에 암호화된 터널을 만들기 때문에, 안전한 데이터 통신이 가능하다.

VPN은 크게 두 가지 타입이 있다. 
1. Site-To-Site VPN : 두 개의 네트워크를 VPN 장치를 이용해서 연결한다. 네트워크 단위에서 직접 연결이 되기 때문에, 사용자는 PC에 VPN 클라이언트등을 설치할 필요 없이 다른 네트워크에 접근할 수 있다. 온-프레미스 데이터 센터를 클라우드에 연결하기 위해서 혹은 회사 네트워크를 클라우드나 온-프레미스 데이터 센터에 연결하기 위해서 사용한다.
2. Host-To-Site VPN : 개별 사용자가 자신의 PC에 설치된 VPN 클라이언트를 이용해서 네트워크에 접근한다. 원격 근무자가 안전하게 네트워크에 접근 할 수 있도록 하기 위해서 사용한다.

![VPN 종류](https://docs.google.com/drawings/d/e/2PACX-1vQIYPUadTwecsmlancsKWW_WdMQGdaMTXz9PKoFKd-UlYdihwCfuUIAsPqPIhYq5CWCeBgnSN9HAt_4/pub?w=885&h=505)

## SSL
SSL(Secure Sockets Layer)는 인터넷 데이터 통신에 사용하는 보안 및 암호화 프로토콜이다. SSL은 TLS(Transport Layer Security)로 대체되었지만 여전히 SSL을 사용한다. 보통은 SSL 혹은 SSL/TLS로 부른다.

SSL은 암호화가 필요한 여러 애플리케이션에 사용하는데, 유명한 애플리케이션은 SSH와 HTTPS다. HTTPS의 경우 웹 서버와 웨 브라우저간에 보안 채널을 통해서 암호화된 통신을 할 수 있다. 이를 통해 해커에 의한 도청, 데이터 변조 및 위조를 방지할 수 있다.

**SSL HandShake**
SSL/TLS Handshake는 TLS 암호화를 사용하기 위해서 클라이언트와 서버간 통신 세션을 시작하는 일련의 과정이다. TLS Handshake를 하는 동안 서버와 클라이언트는 서로 메시지를 교환하면서 사용할 알고리즘을 설정하고, 세션키를 생성한다. TLS Handshake는 TCP Handshake 이후에 수행된다.

아래 그림은 SSL Handshake 과정을 묘사하고 있다.

![SSL/TLS Handshake](https://docs.google.com/drawings/d/e/2PACX-1vQ_J7hl26ZBUKzXy1ZMdJgjGaUV2oHXCTjVDWcjW9hOn7PwZndRuyFYSUFt5IbCGgMB6kEDk_8oZYB8/pub?w=963&h=584)

1. 먼저 TCP 3-Way Handshake 과정을 거친다.
2. Client Hello: 클라이언트는 서버에 SSL/TLS 버전, 지원하는 cipher suites "ClientHello.random"이라고 부르는 랜덤값을 전송한다.
3. Server Hello: 서버는 SSL/TLS 버전, 선택한 sipher suite, "ServerHello.random"이라고 부르는 랜덤 값, 암호화에 사용할 퍼블릭 키(public key), 디지털 서명 정보를 응답한다.
4. Server Key Exchange: 경우에 따라 서버는 암호화 키를 설정하는데 사용할 Diffie-Hellman 공개키와 같은 추가 정보를 클라이언트에 전송한다.
5. Certificate Request(인증서 요청): 서버가 클라이언트 인증을 요청하는 경우 클라이언트의 디지털 인증서를 요청한다.
6. Server Hello Done: 서버가 Server Hello 프로세스가 완료되었음을 알리는 메시지를 전송한다.
7. Client Key Exchange: 클라이언트는 shared secret key를 생성하는데 사용할 임의의 값을 생서앟고 서버의 공개키로 암호화 한다.
8. Certificate Verification: 서버가 클라이언트의 인증서를 요청했다면 이를 서버로 전송한다. 인증서를 받은 서버는 인증서의 디지털 서명을 확인하고 신뢰할 수 있는 인증기관이 발급했는지를 확인한다.
9. Change Cipher Spec: 클라이언트와 서버가 합으된 암호를 사용하여 암호화된 통신으로 전환할 것임을 나타내는 메시지를 보낸다.
10. Finished : 클라이언트와 서버의 handshake 프로세스가 완료되고 암호화된 데이터를 교환할 준비가 되었음을 확인하는 메시지를 전송한다.

Handshake가 완료되면 클라이언트와 서버는 "shared secret key"를 이용해서 암호화된 데이터를 교환한다.

## CDN
**CDN(Content Delivery Network)** 은 전 세계 사용자에게 "위치에 상관없이 빠르고 효율적으로 콘텐츠를 제공"하기 위하여 만들어진 분산 서버 및 분산 데이터 센터다.

CDN은 여러 지역에 분산되어 있는데, 여기에 컨텐츠를 캐시하고 있다가 사용자가 요청하면 제공한다. 사용자가 CDN에 컨텐츠를 요청하면 가장 가까운 서버로 자동으로 라우팅하기 때문에 거리와 상관없이 빠르게 컨텐츠에 접근 할 수 있다. 또한 캐시 형태로 작동하기 때문에 서비스 백앤드의 부하를 줄일 수 있다.

CDN의 주요 구성요소는 아래와 같다.
1. Origin Server: Origin Server는 원본 컨텐츠가 저장된 **원본 서버**다. 사용자는 먼저 CDN에 컨텐츠를 요청하는데, 만약 CDN에 컨텐츠가 캐시되어 있지 않다면 원번 서버에서 컨텐츠를 검색해서 반환한다.
2. Edge Server: 컨텐츠를 캐시하고 제공하는 전 세계의 다양한 지역에 위치한 서버다. 사용자가 컨텐츠를 요청하면 가장 가까운 Edge Server로 라우팅하여 대기 시간을 최소화한다.
3. Caching: CDN은 대기 시간을 줄이고, 백앤드 서버의 성능을 향상시키기 위해서 Edge Server에 컨텐츠를 **임시로 저장**하는 프로세스다. 사용자가 자주 접근하는 컨텐츠는 Origin Server가 아닌 Edge Server에 캐시된 버전을 제공한다.
4. Security: 많은 CDN들이 DDoS 보호, SSL 암호화, WAF(Web Application Firewall)과 같은 보안 기능을 제공하여 웹 사이트와 사용자를 보호한다.

![CDN](https://docs.google.com/drawings/d/e/2PACX-1vRmpMZgZh7noxeQLW0EkFksJ1wXV7Nd3C_0LWharqXIGYKUCA56IRXrFxZKFNqwMxoRWXf-BihhikB7/pub?w=1206&h=634)

Cloudflare, AWS CloudFront, Google Cloud CDN, Akamai CDN 등 다양한 CDN 서비스들이 있다.

### 참고
* [클라우드 엔지니어 면접을 위한 지식들](https://www.joinc.co.kr/w/taglist?name=%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C%20%EC%97%94%EB%8B%88%EC%A7%80%EC%96%B4%20%EB%A9%B4%EC%A0%91%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EC%A7%80%EC%8B%9D%EB%93%A4) 에서 다른 글들을 읽을 수 있습니다.
* [Hands On - Amazon CloudFront CDN](https://www.joinc.co.kr/w/aws_cloudfront_howto)

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories