토폴로지로 이해하는 Amazon 4부

minseok·2023년 10월 14일
0
post-thumbnail

인스턴스의 네트워킹 패턴

인스턴스에 설치된 애플리케이션은 데이터를 인스턴스에 연결된 ENI로 전달한다.
데이터를 받은 ENI는 자신에게 할당된 IP를 출발지로 지정하고 데이터를 받을 IP를 목적지로 지정해 네트워크 패킷으로 전송한다.




인스턴스 기본 통신 요건

인스턴스는 기본 ENI와 IP를 이미 소유한 하나의 객체이지만, 기본 ENI 이외 또 다른 ENI와 IP를 연결할 수 있다.

IP + ENI + INSTANCE

IP : 정적(static) Public IP를 탄력적 IP(Elastic IP), 동적 퍼블릭 IP는 퍼블릭 Public IP라 한다.
프라이빗(private) IP는 정적 IP만 존재하며 기본 프라이빗 IP, 보조 프라이빗 IP 두 종류가 존재

ENI는 기본 프라이빗 IP와 반드시 연결돼 있고 1개 이상의 보조 프라이빗 IP를 추가 할당할 수 있다.
탄력적 IP와 퍼블릭 IP도 필요할 때만 사용한다.

IP, ENI, INSTANCE가 결합하면 VPC에서 트래픽 전송을 위한 준비가 된 것




컴퓨팅 기본 3요소의 독립 형태

IP

4가지 IP(퍼블릭 IP, 탄력적 IP, 기본 프라이빗 IP, 보조 프라이빗 IP)중 탄력적 IP
연결되지 않을 독립 상태로 존재할 수 있음

퍼블릭 IP, 프라이빗 IP는 반드시 ENI를 동반해야 함 (수명주기가 같다.)
퍼블릭 IP는 탄력적 IP처럼 Amazon IP4 Pool에 할당하지만 계정이 마음대로 보유할 수 없다.
ENI는 기본 프라이빗 IP가 반드시 설정돼 있어야 한다. (ENI와 기본 프라이빗 IP는 1대1 관계)

만약 ENI에 프라이빗 IP가 4개 연결된 상태라면 기본 프라이빗 1개, 보조 프라이빗 3개



탄련적 IP를 연결하는 대상은 ENI가 아닌 ENI에 할당된 프라이빗 IP이다.
퍼블릭 IP는 인스턴스와 같은 컴퓨팅 서비스가 필요하여 독립 ENI에 할당할 수 없다.

기본 ENI에만 퍼블릭 IP를 할당할 수 있다.




퍼블릭 IP 자동 할당

인스턴스 생성 시점에 퍼블릭IP를 소유하는 방법은 동적 퍼블릭 IP를 할당하는 방법뿐이다.
탄력적 IP는 인스턴스 생성 이후에만 연결이 가능


인스턴스 생성 시 연결하려는 서브넷에 따라 인스턴스의 퍼블릭 IP 자동 할당 디폴트값이 변경된다.

인스턴스의 설정 기본값은 서브넷의 자동 할당 IP 설정값에 의존한다.

퍼블릭 서브넷의 모든 인스턴스가 반드시 퍼블릭 IP를 사용할 의무는 없으므로
퍼블릭 IP 자동 할당은 사용하지 말자

동적 퍼블릭 IP가 없는 인스턴스의 성질

  • 생성 시점부터 동적 퍼블릭 IP가 없었던 인스턴스는, 탄력적 IP연결/해제, ENI연결/분리가 자유롭다. (기본 ENI는 연결/분리 불가)
  • 탄력적 IP는 프라이빗 IP와 쌍을 이루므로 모든 프라이빗 IP에 연결할 수 있다.

퍼블릭 IP는 계정과 무관하며 Amazon IPv4 Pool에 직접 할당한 IP다.
인스턴스 상태가 바뀔 때(Running <--> Stooped), 탄력적 IP 할당/해제 시점마다 기존 퍼블릭 IP가 릴리스되거나 새로운 퍼블릭 IP가 ENI에 할당한다.



RDS

  • RDS는 VPC기반, RDS ENI, 퍼블릭 엑세스 3개의 특징을 가진다.
  • 여러가지 AWS 데이터베이스(DynamoDB, RDS, ElastiCache...)에서 퍼블릭 엑세스 기능은 RDS에만 존재한다.(외부에서 접속이 불필요하다면 프라이빗 서브넷에 생성)

RDS 서브넷 그룹의 특징

AWS에는 서브넷 그룹을 사용하는 서비스가 존재 (대표적 RDS, RedShift)
하지만 용어만 같을 뿐 서비스마다 서브넷 그룹의 특징이 서로 다르다.

서브넷 그룹은 말 그대로 서브넷의 모음, RDS를 생성하려면 반드시 서브넷 그룹을 1개 지정해야 한다.

서브넷 그룹은 RDS 인스턴스가 놓일 서브넷의 집합, RDS 인스턴스가 한 가용 영역에서 서비스를 지속할 수 없으면 서브넷 그룹에 속한 다른 가용 영역에서 서비스를 지속

RDS 서브넷 그룹 특징

  • 서브넷 그룹은 VPC에 종속되며 최소 2개 이상의 가용 영역을 지정해야 함

서브넷 그룹에 들어가 만들면 가용 영역 2개 이상을 선택해야 RDS를 생성할 수 있다.

데이터 베이스 서비스마다 서브넷 그룹 생성 양식(조건)이 다르다.
Elasti Cache, DynamoDB... 모두 다르며 Elasti Cache 탭에서 만든 서브넷 그룹은 다른 데이터 베이스에 사용할 수 없다.

RDS 서브넷 그룹의 역할

RDS는 서브넷 그룹의 멤버(서브넷)중 하나를 RDS 인스턴스 생성 위치로 선정한다.
생성 단계에서 인스턴스를 구동할 특정 가용 영역을 선택했다면 그 가용 영역의 서브넷 중
한 곳에 인스턴스가 생김
(해당 가용 영역의 서브넷이 2개 이상일 때 임의 선택은 불가)

가용 영역을 미지정하면 서브넷 그룹이 포함하는 임의 가용 영역을 선택

단일 RDS 인스턴스에 서브넷 그룹을 지정하는 이유는?

다중 AZ 옵션으로 다른 가용 영역(AZ)에 예비 복제본을 생성, 읽기 복제본을 둬 장애 상황에 대비하도록 한다.

서브넷 그룹 변경

RDS 가동 중 서브넷 그룹 변경이 가능, Aurora를 제외한 모든 엔진이 서브넷 그룹 변경을 지원

서브넷 그룹 변경 조건

  • 다른 VPC의 서브넷 그룹으로만 변경할 수 있음
  • 현재 구동 중인 RDS 인스턴스의 가용 영역이, 변경 대상 서브넷 그룹에도 포함
  • 단일 RDS 인스턴스만 그룹 변경이 가능 (다중 AZ 인스턴스는 추가적인 절차 필요)

기존 RDS 인스턴스의 퍼블릭 액세스옵션이 켜진 상태라면 서브넷 변경 전 조건을 확인

  • 변경 대상 VPC에 인터넷 게이트웨이 연결
  • DNS 확인, DNS 호스트 이름 활성화 필요

결론적으로 서브넷 그룹을 변경하는 것 = VPC를 변경하는 것



다중 AZ 배포

RDS는 Aurora와 Aurora 이외의 엔진 유형(MySQL, MariaDB, PostgreSQL...)으로 구분
AWS가 제공하는 모든 RDS는 엔진 유형, 템플릿에 따라 방식의 차이는 있지만
모두 다중 AZ를 사용해 장애 대비가 가능

  • Aurora는 서브넷 그룹의 멤버 서브넷에 읽기나 쓰기 노드를 중복으로 둬 데이터 가용성을 높임
  • Aurora 이외 엔진은 기본 인스턴스에 장애가 발생하면 보조 AZ의 인스턴스로 장애 조치돼 서비스 지속이 가능
profile
즐겁게 개발하기

0개의 댓글