[CS] Network / VPC

Jung·2021년 10월 30일
4

CS

목록 보기
2/2
post-thumbnail
post-custom-banner

AWS를 사용하면서 알아야 할 VPC에 대해 적어보려고 한다.

VPC (Virtual Private Cloud)

VPC는 사용자가 정의하는 가상의 네트워크다. VPC를 통해 인스턴스가 속하는 네트워크를 구분하여 각 네트워크에 맞는 설정을 부여할 수 있다. VPC 없이 인스턴스를 생성한다면 아래와 같이 인스턴스끼리 구분 없이 복잡하게 연결되어 있어 복잡할 것이다.


VPC가 없는 구조

VPC를 적용한 구조

PPT로 그림 만드느라 고생...

VPC의 핵심 개념

Virtual Private Cloud(VPC) — 사용자의 AWS 계정 전용 가상 네트워크

서브넷 — VPC의 IP 주소 범위

라우팅 테이블 — 네트워크 트래픽을 전달할 위치를 결정하는 데 사용하는 라우팅이라는 이름의 규칙 집합

인터넷 게이트웨이 — VPC의 리소스와 인터넷 간의 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이

VPC 엔드포인트 - 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 필요로 하지 않고 AWS PrivateLink 및 VPC 엔드포인트 서비스에 VPC를 비공개로 연결할 수 있다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않는다. VPC와 기타 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않는다.

CIDR 블록 — 클래스 없는 도메인 간 라우팅이다. 인터넷 프로토콜 주소 할당 및 라우팅 집계 방법이다. 자세한 내용은 이곳에서 확인하기.


VPC는 사용자의 AWS 계정 전용 가상 네트워크다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. EC2 인스턴스 같은 AWS 리소스를 VPC에서 실행할 수 있다. IP 주소 범위와 VPC 범위를 설정하고 서브넷을 추가하고 보안 그룹을 연결한 다음 라우팅 테이블을 구성한다.

서브넷은 VPC의 IP 주소 범위다. 지정된 서브넷으로 AWS 리소스를 시작할 수 있다. 인터넷에 연결되어야 하는 리소스에는 퍼블릭 서브넷을 사용하고, 인터넷에 연결되지 않는 리소스에는 프라이빗 서브넷을 사용하는 것이 좋다.

각 서브넷에서 AWS 리소스를 보호하기 위해 보안 그룹 및 네트워크 액세스 제어 목록(ACL, Access Control List)을 포함한 다중 보안 계층을 사용할 수 있다.

VPC를 구축하기 위해서는 VPC의 IP 범위를 RFC1918이라는 사설 IP 대역에 맞추어 구축해야 한다. 사설 IP는 인터넷에서 공인된 IP 주소를 사용하지 않고, 사적인 용도로 임의 사용하는 IP 주소다.

VPC에서 사용하는 사설 IP 대역
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

참고
Amazon VPC 작동 방식 - Amazon Virtual Private Cloud. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/how-it-works.html.

Great, Harry The. “[AWS] 가장쉽게 VPC 개념잡기.” Medium, 해리의 유목코딩, 14 Feb. 2020, https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098


서브넷 (Subnet)

서브넷이란 하나의 IP 네트워크 주소를 지역적으로 나누어 여러 개의 서로 연결된 지역 네트워크로 사용할 수 있도록 하는 방법이다. (네트워크의 논리적인 분할)

A Class

A클래스의 첫번째 옥텟의 비트가 0으로 고정된다.

0xxx xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그렇기 때문에 표현할 수 있는 범위는 아래와 같다.

0000 0000.0000 0000.0000 0000.0000 0000 ~ 0111 1110.1111 1111.1111 1111.1111 1111

그래서 십진수로 표현하면 0.0.0.0 ~ 127.255.255.255이다.
이 IP 클래스는 대규모 네트워크에 적합하다.
네트워크 주소는 처음 8비트까지이고, 나머지 24비트는 호스트 주소를 의미한다.

B Class

B클래스는 첫번째 옥텟의 두번째 비트까지 10으로 고정된다.

10xx xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1000 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1011 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 128.0.0.0 ~ 191.255.255.255이다.
네트워크 주소는 처음 16비트까지이고, 나머지 16비트는 호스트 주소를 의미한다.

C Class

C클래스는 첫번째 옥텟의 세번째 비트까지 110으로 고정된다.

110x xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1100 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1101 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 192.0.0.0 ~ 223.255.255.255이다.
네트워크 주소는 처음 24비트까지이고, 나머지 8비트는 호스트 주소를 의미한다.

D Class

D클래스는 첫번째 옥텟의 네번째 비트가 1110으로 고정된다.

1110 xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1110 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1110 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 224.0.0.0 ~ 239.255.255.255이다.
멀티캐스트용 대역으로 IP주소에 할당되지 않는다.

E Class

E클래스는 첫번째 옥텟의 네번째 비트까지 1111으로 고정된다.

1111 xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx

그래서 표현할 수 있는 범위는 아래와 같다.

1111 0000. 0000 0000. 0000 0000. 0000 0000 ~ 1111 1111. 1111 1111. 1111 1111. 1111 1111

그래서 십진수로 표현하면 240.0.0.0 ~ 255.255.255.255이다.
예약된 주소 대역으로 IP주소에 할당되지 않는다.

D클래스와 E클래스는 특정 용도로 사용하기 때문에 실제 IP주소에 할당되지 않는다.

클래스 등급이 낮아지면서 호스트 주소 부분이 점점 줄어들고 있는것을 알 수 있다.

이 중 특정 주소 대역은 사설 IP로 사용된다.

VPC에서 사용하는 사설 IP 대역
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

(아까 위에서 설명한 사설 IP 대역이랑 같다.)

각 클래스로 나눠진 네트워크를 운영중인 서비스의 규모에 맞게 분할하여 사용하기 위한 기술이다. 따라서 이런 기술을 통해서 A Class 네트워크와 같은 매우 큰 네트워크를 작게 나눠서 사용하면서, 낭비되는 IP주소 자원을 최소화하려는 것이 주된 목적이다.

참고
Heyhyo. “[Network]서브넷(Subnet).” Hyo Note, TISTORY, 31 Aug. 2018, https://hyoje420.tistory.com/32.

heyoon2j. “Subnet 이란?” { BLog: "heyoon2j" }, TISTORY, 7 Dec. 2019,
https://yoonix.tistory.com/11.

Reakwon. “[네트워크] IP 클래스와 서브넷마스크, 서브넷마스크 계산방법.” REAKWON, TISTORY, 19 May 2020, https://reakwon.tistory.com/69.


서브넷 마스크 (Subnet Mask)

네트워크 범위를 제한하거나 네트워크 범위를 알기 위한 마스크다. IP 주소에 대한 네트워크 아이디와 호스트 아이디를 구분하기 위해서 사용된다.

C클래스 대역을 사용해서 호스트를 255개를 수용할 수 있는 것도 너무 많이 남을 때가 있다. 또는 B클래스 대역을 C클래스 대역으로 쓰고 싶을 때가 있다. 네트워크 주소를 조금 더 효율적으로 할당하고자 나온 것이 서브넷 마스크다. 서브넷 마스크로 만들어진 네트워크를 서브넷이라고 한다.

128.255.11.11는 B클래스 주소다. 128.255까지가 네트워크 주소이고 나머지 2옥텟이 호스트 주소다.

💡 128.255.11.11을 255.255.255.0이라는 서브넷 마스크를 씌우면 어떻게 될까 🤔

서브넷 마스크는 비트로 보는 것이 편하다.

255.255.255.0 ➡️ 1111 1111.1111 1111.1111 1111.0000 0000

여기서 서브넷 마스크 비트가 1인 것은 전부 네트워크 주소가 되고, 반대로 서브넷마스크 비트가 0인 것은 호스트 주소가 된다.

⏬ 서브넷 마스크 적용 ⏬

128.255.11.11 ➡️ 1000 0000.1111 1111.0000 1011.0000 1011

따라서 255.255.255.0이라는 서브넷 마스크를 씌우면 128.255.11이 네트워크 주소가 되고 나머지 11이 호스트 주소가 된다.

서브넷마스크의 표기방식은 주소/서브넷마스크 주소 또는 주소/비트수로 표현할 수 있다. 128.255.11.11/255.255.255.0 또는 128.255.11.11/24로 표현이 가능하다.


💡 128.255.11.11을 255.255.255.224의 서브넷마스크를 적용하면 어떻게 될까 🤔

비트로 풀어보면

255.255.255.224 ➡️ 1111 1111.1111 1111.1111 1111.1110 0000

⏬ 서브넷 마스크 적용 ⏬

128.255.11.11 ➡️ 1000 0000.1111 1111.0000 1011.0000 1011

하위 5비트 0 0000을 호스트 주소로 적용시킬 수 있으니까(서브넷마스크 비트가 0인 것이 호스트 주소) 128.255.11.0 ~ 128.255.11.31 까지가 같은 네트워크고, 128.255.11.11은 이 네트워크에 속하는 것을 알 수 있다.

전부 계산해보면 아래와 같다.

  • 128.255.11.0 ~ 128.255.11.31
    네트워크 주소 128.255.11.0, 브로드캐스트 주소 128.255.11.31

  • 128.255.11.32 ~ 128.255.11.63
    네트워크 주소 128.255.11.32, 브로드캐스트 주소 128.255.11.63

  • 128.255.11.64 ~ 128.255.11.95
    네트워크 주소 128.255.11.64, 브로드캐스트 주소 128.255.11.95

  • 128.255.11.96 ~ 128.255.11.127
    네트워크 주소 128.255.11.96, 브로드캐스트 주소 128.255.11.127

  • 128.255.11.128 ~ 128.255.11.159
    네트워크 주소 128.255.11.128, 브로드캐스트 주소 128.255.11.159

  • 128.255.11.160 ~ 128.255.11.191
    네트워크 주소 128.255.11.160, 브로드캐스트 주소 128.255.11.191

  • 128.255.11.192 ~ 128.255.11.223
    네트워크 주소 128.255.11.192, 브로드캐스트 주소 128.255.11.223

  • 128.255.11.224 ~ 128.255.11.255
    네트워크 주소 128.255.11.224, 브로드캐스트 주소 128.255.11.255

  • 네트워크 주소: 해당 네트워크의 첫번째 IP주소로, 하나의 네트워크를 통칭한다. IP주소와 서브넷마스크의 AND 연산을 통해 구할 수 있다.

  • 호스트 주소: 특정한 하나의 네트워크 내에서 서로를 구분하기 위한 주소다.

  • 브로드캐스트 주소: 해당 네트워크에 속하는 모든 IP 주소 가운데 맨 마지막 IP주소로, 네트워크에 있는 모든 클라이언트들에게 데이터를 보내기 위함이다.

사실 A, B, C클래스 대역은 각각 255.0.0.0, 255.255.0.0, 255.255.255.0의 서브넷마스크가 적용되었다.
이것을 default subnet mask라고 한다.

참고
Reakwon. “[네트워크] IP 클래스와 서브넷마스크, 서브넷마스크 계산방법.” REAKWON, TISTORY, 19 May 2020, https://reakwon.tistory.com/69.


라우팅 테이블

라우팅 테이블(Routing Table)은 컴퓨터 네트워크에서 목적지 주소를 목적지에 도달하기 위한 네트워크 노선으로 변환시키는 목적으로 사용된다. 각 라우터의 라우팅 테이블은 모든 목적지 정보에 대해 해당 목적지에 도달하기 위해서 거쳐야 할 다음 라우터의 정보를 가지고 있다.

VPC 내에는 서브넷이 있으며 각 서브넷은 각각 다른 네트워크 대역을 가지고 있다. 각각의 서브넷은 서로 다른 네트워크 영역이기 때문에 하나의 서브넷이 다른 서브넷으로 가기 위해서는 라우팅(Routing)이 필요하다.

이미지 출처
VPC의 라우팅 테이블 - Amazon Virtual Private Cloud. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Route_Tables.html.

모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 라우팅이 포함되어 있다. 이 라우팅은 기본적으로 모든 라우팅 테이블에 추가된다. VPC에 하나 이상의 IPv4 CIDR블록이 연결되어 있는 경우, 라우팅 테이블에 각 IPv4 CIDR 블록의 로컬 경로가 포함된다. IPv6 CIDR 블록을 VPC와 연결한 경우, 라우팅 테이블에 IPv6 CIDR 블록의 로컬 경로가 포함된다. 서브넷 라우팅 테이블이나 기본 라우팅 테이블에서 이러한 라우팅을 수정하거나 삭제할 수 없다.

VPC 내부(모든 서브넷)에 대해서는 라우팅이 자동으로 생성된다. 별도의 설정 없이 하나의 서브넷에서 다른 서브넷으로 통신이 가능하다는 말이다. 이는 사용자가 따로 설정할 필요가 없고, 보이지 않는 암시적 라우터인 VPC Router를 통해 가능하다. 서브넷 내의 모든 리소스는 자신이 소속된 서브넷이 아닌 다른 서브넷으로 향하고자 할 때 VPC Router를 거쳐야 한다.

VPC에는 암시적 라우터가 있으며 라우팅 테이블을 사용하여 네트워크 트래픽이 전달되는 위치를 제어한다. VPC의 각 서브넷을 라우팅 테이블에 연결해야 한다. 테이블에서는 서브넷에 대한 라우팅을 제어한다 (서브넷 라우팅 테이블). 서브넷을 특정 라우팅 테이블과 명시적으로 연결할 수 있다. 그렇지 않으면 서브넷이 기본 라우팅 테이블과 암시적으로 연결된다. 서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만 여러 서브넷을 동일한 서브넷 라우팅 테이블에 연결할 수도 있다.

위 사진에서 서브넷의 라우팅을 보여주고 있다. 해당 서브넷에 로컬 라우팅이 지정되어 있는 것을 확인할 수 있다. 나머지 서브넷에도 사진과 같은 라우팅 테이블을 보유하고 있기 때문에 VPC 내 서브넷에 할당된 리소스라면 어느 서브넷이든 다른 서브넷의 리소스와 자유롭게 통신이 가능하다.

또한 라우팅 테이블은 로컬 라우팅 뿐만 아니라 서브넷에 소속된 리소스(EC2, RDS 등)가 외부 인터넷망으로 나갈 수 있는 라우팅을 가질 수 있다. 이를 인터넷 게이트웨이(Internet Gateway)라고 한다. 그림에서 igw-***으로 나와있는 것이 바로 인터넷 게이트웨이다.

참고
VPC의 라우팅 테이블 - Amazon Virtual Private Cloud. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Route_Tables.html.

환영 도움되는 네트워크 엔지니어. “VPC와 Network 쉽게 이해하기 #2.” 네트워크 엔지니어 환영의 AWS 기술블로그, TISTORY, 1 Sept. 2021, https://aws-hyoh.tistory.com/53.


인터넷 게이트웨이

인터넷 게이트웨이는 수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC와 인터넷 간에 통신할 수 있게 해준다. 인터넷 게이트웨이에는 인터넷 라우팅 가능 트래픽에 대한 VPC 라우팅 테이블에 대상을 제공하고, 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)를 수행하는 두 가지 목적이 있다.

이름에서 알 수 있듯 서브넷 내 리소스(EC2, RDS 등)가 인터넷과 통신하고자 할 때 반드시 거쳐야 하는 관문이 인터넷 게이트웨이다. 인터넷 게이트웨이 없이는 외부 인터넷으로 들어갈 방법은 없다!
인터넷 게이트웨이만 생성하면 외부 인터넷과 통신할 수 있는 것은 아니고 VPC에서 리소스가 외부 인터넷과 통신하고자 할 경우 갖춰야 할 조건은 아래와 같다.

  1. 인터넷과 통신하고자 하는 리소스가 공인 IP를 보유할 것
  2. 리소스가 소속된 서브넷의 라우팅 테이블에 0.0.0.0/0 목적지로 갖는 인터넷 게이트웨이가 있을 것
  3. 네트워크 ACL과 보안 그룹 규칙에서 허용할 것

이미지 출처
Amazon Virtual Private Cloud - Docs.aws.amazon.com. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/example-vpc-share.html.

AWS에서는 공인 인터넷과 통신 가능한 서브넷을 Public Subnet, 공인 인터넷이 차단된 사설 IP만 할당된 서브넷은 Private Subnet이라고 한다.

Name이 -인 3개의 서브넷을 가진 라우팅 테이블의 라우팅 설정은 아래와 같다.

인터넷 게이트웨이가 설정되어 있으므로 이 라우팅 테이블은 Public 서브넷에 관한 라우팅 테이블이다.

Name이 my-route01인 하나의 서브넷을 가진 라우팅 테이블의 라우팅 설정은 아래와 같다.

여기서는 인터넷 게이트웨이 대신 NAT 게이트를 설정했다.

NAT 게이트웨이가 설정되어 있으므로 이 라우팅 테이블은 Private 서브넷에 관한 라우팅 테이블이다

참고
환영 도움되는 네트워크 엔지니어. “VPC와 Network 쉽게 이해하기 #2.” 네트워크 엔지니어 환영의 AWS 기술블로그, TISTORY, 1 Sept. 2021, https://aws-hyoh.tistory.com/53.


NAT 게이트웨이

NAT 게이트웨이는 NAT(네트워크 주소 변환) 서비스다.
프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

NAT(Network Address Translation): 비공인 네트워크(사설 IP 네트워크)에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하는 방법

NAT 게이트웨이를 만들 때 다음 연결 유형 중 하나를 지정한다.

  • 퍼블릭 - (기본값) 프라이빗 서브넷의 인스턴스는 퍼블릭 NAT 게이트웨이를 통해 인터넷에 연결할 수 있지만 인터넷에서 원치 않는 인바운드 연결을 수신할 수 없다. 퍼블릭 서브넷에서 퍼블릭 NAT 게이트웨이를 생성하고 생성 시 탄력적 IP 주소를 NAT 게이트웨이와 연결해야 한다. 트래픽을 NAT 게이트웨이에서 VPC용 인터넷 게이트웨이로 라우팅한다. 또는 퍼블릭 NAT 게이트웨이를 사용하여 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다. 이 경우 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅한다.

  • 프라이빗- 프라이빗 서브넷의 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다. 트래픽을 NAT 게이트웨이에서 Transit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅할 수 있다. 탄력적 IP 주소를 프라이빗 NAT 게이트웨이에 연결할 수 없다. 프라이빗 NAT 게이트웨이를 사용하여 VPC에 인터넷 게이트웨이를 연결할 수 있지만 프라이빗 NAT 게이트웨이에서 인터넷 게이트웨이로 트래픽을 라우팅하는 경우 인터넷 게이트웨이가 트래픽을 삭제한다.

NAT 게이트웨이는 인스턴스의 소스 IP 주소를 NAT 게이트웨이의 IP 주소로 바꾼다. 퍼블릭 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 탄력적 IP 주소다. 프라이빗 NAT 게이트웨이의 경우 이것은 NAT 게이트웨이의 프라이빗 IP 주소다. 인스턴스에 응답 트래픽을 전송할 때 NAT 디바이스는 주소를 원래 소스 IPv4 주소로 다시 변환한다.

나는 서브넷 c를 Private 서브넷으로 설정하고 서브넷 c의 라우팅 설정에서 NAT 게이트웨이를 지정했다. 이 NAT 게이트웨이는 퍼블릭 유형이고 생성할 때 탄력적 IP 주소도 할당했다. 그리고 VPC에서 Private 서브넷 c가 아닌 나머지 3개의 Public 서브넷에서 서브넷 a를 선택해 NAT 게이트웨이를 생성했다.

참고
Nat 게이트웨이 - Amazon Virtual Private Cloud. https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-gateway.html.


AWS RDS Proxy

RDS Proxy를 사용하여 Amazon RDS DB 인스턴스와 Amazon Aurora DB 클러스터에 대한 연결 관리를 간소화할 수 있다.

RDS Proxy는 클라이언트 애플리케이션과 데이터베이스 사이의 네트워크 트래픽을 처리한다. 데이터베이스 프로토콜을 이해하여 능동적으로 수행한다. 그런 다음 애플리케이션의 SQL 작업과 데이터베이스의 결과 집합을 기반으로 동작을 조정한다.

RDS Proxy는 데이터베이스의 연결 관리를 위한 메모리 및 CPU 오버헤드를 줄인다. 애플리케이션이 많은 연결을 동시에 열 때 데이터베이스에 필요한 메모리 및 CPU 리소스가 더 적다. 또한 오랫동안 유휴 상태를 유지하는 연결을 닫았다가 다시 여는 데 애플리케이션의 로직이 필요하지 않다. 마찬가지로, 데이터베이스 문제의 경우 연결을 다시 설정하는 데 더 적은 애플리케이션 로직이 필요하다.

Amazon RDS Proxy를 사용하면 애플리케이션이 데이터베이스 연결을 풀링하고 공유하도록 허용하여 확장 기능을 향상시킬 수 있다. RDS Proxy는 애플리케이션 연결을 유지하면서 예비 DB 인스턴스에 자동으로 연결하여 데이터베이스 장애에 대한 애플리케이션의 복원력을 높인다. RDS 프록시를 사용하면 데이터베이스에 대해 AWS Identity and Access Management(IAM) 인증을 사용하고 AWS Secrets Manager에 자격 증명을 안전하게 저장한다.

RDS Proxy를 사용하면 연결을 초과 구독하거나 빠른 속도로 새 연결을 생성할 경우, 발생할 수 있는 예기치 않은 데이터베이스 트래픽 급증을 처리할 수 있다.

참고
RDS Proxy 개념 및 용어 - Docs.aws.amazon.com.
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/rds-proxy.howitworks.html

Amazon RDS 프록시 사용 - Docs.aws.amazon.com. https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/rds-proxy.html.



기타 용어 정리

라우터

라우터는 네트워크 간에 데이터 패킷을 전송하는 네트워크 장치다. 패킷의 위치를 추출하여, 그 위치에 대한 최적의 경로를 지정하며, 이 경로를 따라 데이터 패킷을 다음 장치로 전달한다. 이때 최적의 경로는 일반적으로는 가장 빠르게 통신이 가능한 경로이므로, 이것이 최단 거리 일수도 있지만, 돌아가는 경로라도 고속의 전송로를 통하여 전달이 되는 경로가 될 수 있다. 간단히 말해 서로 다른 네트워크 간에 중계 역할을 해준다.

CORS

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여 하나의 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.

교차 출처 요청의 예시: https: //domain-a.com의 프론트 엔드 JavaScript 코드가 XMLHttpRequest를 사용하여 https: //domain-b.com/data.json을 요청하는 경우.

보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 예를 들어, XMLHttpRequest와 Fetch API동일 출처 정책을 따른다. 즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 한다.

multipart/form-data

파일 업로드를 구현할 때, 클라이언트가 웹브라우저라면 폼을 통해서 파일을 등록해서 전송하게 된다. 이때 웹 브라우저가 보내는 HTTP 메시지는 Content-Type 속성이 multipart/form-data로 지정되며, 정해진 형식에 따라 메시지를 인코딩하여 전송한다. 이를 처리하기 위한 서버는 멀티파트 메시지에 대해서 각 파트별로 분리하여 개별 파일의 정보를 얻게 된다.

이미지 파일을 전송한다고 해서 png나 jpg 파일 자체가 전송되는 것이 아니다. 이미지 파일도 바이너리 데이터로 이뤄져 있기 때문에 이미지 파일을 스펙에 맞게 바이너리 데이터로 생성하여 HTTP request body에 담아 서버로 전송하는 것이다.

HTTP 메시지 구조

요청 시 start-line = request-line,
응답 시 start-line = status-line
(이미지 출처: 김영한님 HTTP 강의)

HTTP는 4개의 파트로 나눌 수 있다. 여기서 Message Body에 들어가는 데이터 타입을 HTTP Header에 명시해줄 수 있다. 이 때 명시할 수 있도록 해주는 필드가 바로 Content-Type이다. 추가적으로 Content-Type 필드에 MIME(Multipurpose Internet Mail Extensions) 타입을 기술해줄 수 있는데, 여러 타입 중 하나가 바로 multipart이다.

온프레미스

온프레미스란 필요한 시스템을 구축하기 위해서 값비싼 하드웨어와 애플리케이션을 구매하여 기업 상황에 맞게 커스터마이징 하는 것을 의미한다. 즉, 데이터센터나 서버 룸과 같은 특정 공간에 IT 인프라를 구축하여 소프트웨어를 사용하는 방식으로, 인프라를 구축하기 위한 시간도 수개월 이상 걸리며 초기 도입 비용, 운영 및 관리를 위한 유지보수 등 비용이 많이 드는 단점이 있다. 일반적으로 온프레미스 시스템을 구축하는데 시간이 수개월 이상 걸렸고 비용 또한 많이 들어, 퍼블릭 클라우드가 나올 당시만 해도 온프레미스 환경이 금방이라도 모두 사라질 것 같았지만 보안 적인 이유로 비즈니스에 중요하고 보안이 필요한 서비스와 데이터는 온프레미스 환경에서, 덜 중요한 것은 퍼블릭 클라우드 환경을 사용하는 하이브리드 IT 인프라가 대세를 이루고 있다.

참고
Lena. “HTTP Multipart/Form-Data 이해하기.” 레나참나, 13 Jan. 2021,
https://lena-chamna.netlify.app/post/http_multipart_form-data.

“온프레미스.” 온프레미스 - 해시넷, http://wiki.hash.kr/index.php/%EC%98%A8%ED%94%84%EB%A0%88%EB%AF%B8%EC%8A%A4.

profile
97kim.github.io
post-custom-banner

2개의 댓글

comment-user-thumbnail
2021년 11월 1일

:)

1개의 답글