(5) Amazon VPC -2

안녕하세요, levin 입니다.
AWS study 다섯 번째 시간, VPC 두번 째 내용 입니다.

[네트워크 접속 제어 목록(NACL)]

소스, 대상 주소 CIDR , 프로토콜, 포트 기반의 인바운드 및 아웃바운드 규칙을 제공한다는 측면에서 보안그룹과 같은 방화벽 기능을 수행하며, 각 VPC에서 는 삭제할 수 없는 기본 NACL이 있다.
보안그룹과 다른점으로는 서브넷 내의 인스턴스 간 트래픽을 제어할 때는 사용할 수 없으므로 보안그룹을 사용해야 한다.

• 기본 NACL에는 IPv6 CIDR가 없고, 두개의 인바운드 규칙이 미리 채워진채 제공된다.(ALL allow, All deny)
• 목록에서 가장 낮은 번호의 규칙으로부터 먼저 처리된다.

[퍼블릭IP주소]

다른 사용자가 인터넷을 통해 인스턴스에 직접 접속할 수 있도록 하려면 퍼블릭 IP가 필요하며, 이를 위해서는 해당 인스턴스가 포함된 VPC에 인터넷 게이트웨이를 연결해야 한다. 서브넷에 인스턴스를 시작할 때 자동으로 퍼블릭IP가 생성되도록 할 수 있지만, 생성 옵션을 선택하지 않고 인스턴스를 생서하면 임의의 퍼블릭IP를 할당 받는데 이건 인스턴스 종료 시 같이 삭제되며 재시작시 새로운 퍼블릭IP 를 할당받아서 문제가 될 수 있다.

[탄력적 IP]

위에서 말한 퍼블릭 IP의 지속성 문제에 대해 해결할 방법이기도 하다.
AWS가 사용자 계정에 할당하는 퍼블릭 IP 주소이며 할당되면 사용자가 직접 해제하지 않는 한 해당 주소를 독점적으로 사용할 수 있다.
EIP를 생성하면 사용자가 직접 ENI 와 연결해야하고 연결한 후에는 ENI를 삭제하거나 해제하지 않는 한 연결이 계속 유지 된다.
EIP는 리전 단위로 제공되므로 리전을 벗어나지 못하지만, 리전 내에선 사용자 계정이 보유한 IP를 불러오기 해서 사용 가능하다.

[네트워크 주소 변환]

ENI와 퍼블릭IP 주소를 연결한 뒤에도 ENI는 프라이빗IP 주소를 유지하게 되며, ENI와 퍼블릭IP 주소를 연결하더라도 새로운 주소로 ENI의 환경을 재설정하지 않는다. 대신 인터넷 게이트웨이가 퍼블릭 IP 주소를 ENI의 프라이빗 IP 주소로 맵핑하게 되며, 이러한 프로세스를 네트워크 주소변환 NAT (Network Address Translation) 라 부른다.
NAT 작업은 인스턴스가 퍼블릭 IP 주소를 지닌 경우, 인터넷 게이트웨이에서 자동으로 이뤄지며, 이러한 동작은 사용자가 바꿀 수 없다.

• NAT 게이트웨이 : AWS 에서 관리하는 NAT 디바이스로서 인터넷 게이트웨이처럼 하나의 NAT 게이트웨이로 어떠한 형식의 요청도 처리할 수 있다. 단일 유형의 NAT 게이트웨이만 제공되만, 사용자는 별도의 관리 또는 접속 작업을 할 필요가 없으며, 자동으로 모든 대역폭의 요구에 대응하므로 용량 관리 문제를 신경 쓸 필요가 없다.
  사용자는 NAT 게이트웨이를 생성할 때 EIP를 할당해야 하며, 인터넷 접속이 가능하도록 퍼블릭 서브넷에 생성한다. 그러면 AWS가 해당 서브넷에 있는 프라이빗 IP주소를 NAT 게이트웨이에 할당한다. 중복 구현을 위해 다른 AZ에 NAT 게이트웨이를 추가로 생성할 수 있다.
• NAT 인스턴스 : 리눅스 기반 AMI로 생성된 일반적인 EC2 인스턴스의 일종이며, 일반 인스턴스 생성 방법과 동일하다. NAT 게이트웨이 와의 차이점에는 처음부터 적절한 스펙을 가진 인스턴스 유형을 선택해서 생성 해야된다는 점, ENI를 지니므로 보안그룹을 적용해야 하고 사용자가 직접 퍼블릭IP도 할당해야 한다. 이점에는 이 NAT 인스턴스를 사용자가 점프 호스트로 사용할 수 있다는 점.
  큰 단점으로는 AZ 장애 발생 시 다른 NAT 인스턴스로 대체하는 것과 같이 간단하게 문제를 해결할 수 없다는 점이다.

[VPC 피어링]

AWS 네트워크를 통해 하나의 VPC에 포함된 인스턴스가 다른 VPC에 포함된 인스턴스와 소통할 수 있다. 이는 서로 다른 리전에 있는 인스턴스 간의 소통이 필요할 때 사용하거나 사용자의 계정과 다른 AWS 계정의 인스턴스와 연결할 때 사용할 수 있다.
두 VPC 사이에 피어링 설정을 해야하며 각 하나의 VPC 피어링 설정을 할 수 있다. (해당 vpc 끼리는 CIDR 겹치지 않는 전제)

[하이브리드 클라우드 네트워킹]

기업 데이터 센터와 관련된 리소스의 경우, 프라이빗 속성을 지니고 인터넷과도 연결성이 없도록 설계한다. AWS 의 VPC와 온프레미스 연결 서비스에는 세 가지가 있다.

• VPN : VPG 라 부르는 VPC 리소스를 구성한 뒤, 온프레미스 라우터 또는 방화벽 등 고객 게이트웨이를 구성하면 되며, 이를 통해 VPG로 암호화 VPN 터널이 생성된다. VPG는 AES 256비트 및 128 비트 암호를 지원한다.
  여러개의 VPC와 연결하려면 각 VPC에 VPG와 VPN터널을 생성해야 한다. 대량의 VPC를 온프레미스에 연결할 때나 다수의 온프레미스를 하나의 VPC에 연결해야 할 때 작업이 많아지고 , 많아짐에 따라 문제 발생 가능성이 커질 수 있다.
• AWS Transit Gateway : 위에 언급된 문제 발생이 커질만 한 경우에 적합하다. Direct Connect 링크와 VPN을 사용해서 다수의 VPC 및 다수의 온프레미스 네트워크를 연결할 수 있도록 해주는 고가용성 서비스다. 연결 작업은 간소화 하고, VPC 와 온프레미스에 대한 트래픽은 매우 세밀하게 제어할 수 있도록 돕는다.

[AWS Transit Gateway 활용 방법]

• 중앙화 라우터 : 사용자의 모든 VPC 및 온프레미스 트래픽을 제어하는 데 활용할 수 있다. 중앙화 라우터 모델로 사용할 때는 하나의 Transit Gateway 라우트 테이블에 다른 모든 리소스를 연결한다. Transit Gateway로 VPC와 온프레미스 네트워크를 연결할 때는 VPG를 사용하지 않는 대신 Transit Gateway 가 온프레미스 라우터 또는 방화벽의 VPN 연결을 종료하고, BGP를 통해 라우트 정보를 넘겨받는다. 이 라우트 정보는 Transit Gateway 라우트 테이블에 보관되고, VPC 와 연결된 라우트 정보 또한 Transit Gateway 라우트 테이블에 저장된다. 이와 같이 동적으로 라우트 테이블에서 라우트를 학습하고 저장하는 과정을 라우트 전파 라고 부른다.

• 격리 VPC : Transit Gateway는 부착된 리소스와 연결되는 다수의 Transit Gateway 라우트 테이블을 지닐 수 있으므로, 하나의 Transit Gateway에 다수의 격리 VPC를 생성할 수 있다. 격리 VPC는 사용자가 여러 개의 VPC를 보유한 상황에서 온프레미스 네트워크와는 연결성을 유지하면서도 VPC 간에는 서로 격리성을 유지하려 할 때 유용하다.

• Transit Gateway 피어링 : Transit Gateway를 이용하면 서로 다른 리전 간의 피어링도 가능하다. 다른 리전에 리소스가 산재한 경우에도 Transit Gateway를 이용해 VPN연결 및 VPC 피어링 연결의 수를 줄이면서 리전 간 피어링을 구성할 수 있다.

• 멀티캐스트 : AWS Transit Gateway는 VPC 간의 멀티캐스트도 지원한다. 각 멀티캐스트 도메인에서 인스턴스의 ENI를 지정해 멀티캐스트 소스로 사용할 수 있으며, 이를 멀티캐스트 그룹이라 부른다. 또한 멀티캐스트 그룹 주소 및 EC2 인스턴스를 지정해 멀티캐스트 트래픽을 수신할 수 있다. 이 때, 어떤 EC2 인스턴스든 멀티캐스트를 수신할 수 있지만 멀티캐스트 송신은 Nitro 인스턴스만 가능하다.

• 블랙홀 라우트 : 특정 라우트를 차단하고 싶다면 Transit Gateway 라우트 테이블에 블랙홀 엔트리를 추가하면 되며, 이렇게 추가된 블랙홀 라우트는 미리 지정된 라우트의 트래픽을 전부 차단한다. 블랙홀 라우트는 위협 요소로 알려진 IP 주소 등을 영구적으로 차단할 때는 물론 아직 연결 상태가 유지된 VPC의 트래픽을 일시적으로 차단할 때도 유용하다.

[AWS Direct Connect]

사용자 AWS 리소스에 대한 프라이빗, 저지연성 연결을 제공한다.
AWS 리소스 접속 시 인터넷을 우회해서 접속할 수 있는 방법을 제공해 문제 발생 가능성은 낮추고 광대역 인터넷을 사용할 수 있도록 해준다.
대량의 데이터를 전송할 때, 또는 실시간 데이터를 전송할 때 특히 유용하며 법규에 의해 퍼블릭 인터넷으로 데이터를 정송해서는 안될 때도 유용하다. Direct Connect를 이용해서 특정 리전에 있는 EC2 및 RDS 인스턴스, S3 버킷 등 모든 리소스에 퍼를릭이 아닌, 프라이빗 인터넷망으로 접속할 수 있다.

• 전용 연결 타입 : 물리적인 단일 연결. Direct Connect지점에 자체 장비를 추가해야 하며 각 연결 지점은 AWS 리전과 연결돼 있으며, 연결 지점을 통해 해당 리전에 있는 AWS 리소스에 접속할 수 있다.
• 호스트 연결 타입 : 50 Mbps ~ 10 Gbps 연결을 지원. Direct Connect 연결 지점에서 사용자의 데이터 센터 또는 사무실을 잇는 라스트 마일 연결을 제공한다.

[Direct Connect Gateways]

리전 내 여러 VPC를 하나의 연결 지점에서 접속할 수 있도록 해주는 글로벌 리소스.
AWS 측에서는 Transit Gateway 또는 VPG가 Direct Connect Gateway로서 역할을 담당하고, 사용자 측에는 Direct Connect Gateway가 사용자의 온프레미스 장비로 BGP 세션을 유지하며 IPv4 및 IPv6 라우트 프리픽스를 전파 및 수신한다.

[가상 인터페이스]

Direct Connect 연결 방식에 따라 하나 이상의 가상 인터페이스를 생성해서 사용하게 되며, AWS에는 세가지 가상 인터페이스가 있다.

• 프라이빗 가상 인터페이스 : 단일 VPC 내, EC2 또는 RDS 인스턴스 등과 같은 리소스의 프라이빗IP 주소에 연결할 수 있다.

• 퍼블릭 가상 인터페이스 : 퍼블릭 앤드포인트를 지닌 S3 또는 DynamoDB 와 같은 AWS 서비스의 퍼블릭 IP 주소에 연결할 수 있으며, 온프레미스 애플리케이션을 퍼블릭 엔드포인트를 이용해서 AWS 서비스에 연결하려는 경우 유용하다.

• 트랜싯 가상 인터페이스 : 하나 이상의 AWS Transit Gateway에 연결한다. Transit Gateway는 다수의 VPC 에 흩어져 있는 리소스를 연결할 때 주로 사용하며, 1Gbps 이상의 속도를 제공한다.

1 Gbps 이상의 속도를 지닌 Direct Connect 링크는 여러 개의 가상 인터페이스와 연결해서 사용할 수 있으며, 이보다 낮은 속도의 링크는 하나의 가상 인터페이스 연결만 지원한다.

[고성능 컴퓨팅]

집약적인 워크로드를 다수의 인스턴스를 이용해서 동시에 병렬적으로 처리하는 연산 패러다임이다. 이 때 인스턴스는 HPC 클러스터를 이루게 되며, 인스턴스 간의 상호작용 수준에 따라 두 개의 카테고리로 나뉜다.

• Loosely Coupled : 개별 인스턴스가 독립적으로 처리할 수 있도록 다시 세분화되며, 이미지 프로세싱 등의 업무에 주로 활용된다. 또 다른 활용 사례인 DNA 염기배열 분석의 경우, 게놈을 개별 요소로 세분화한 뒤, 이들 게놈 요소를 또 다른 노드에 추가해 새로운 분석을 시행할 수 있다. 하나의 인스턴스와 완전히 별개의 요소로 작동하며, 고속의 통신 등을 필요로 하지 않으므로, 별개의 클러스터 플레이스먼트 그룹에 배치할 수 있다.

• Tightly Coupled : 개별적으로 분리하기도 어렵고, 처리를 위해 상당한 수준의 컴퓨팅 파워가 필요하다. 이런 작업을 처리하려면 여러 개의 인스턴스가 단일 슈퍼컴퓨터와 같이 작동할 수 있어야 하므로 인스턴스는 고속의 네트워크로 서로 연결돼 있어야 한다. 결국 이를 위해 여러 개의 인스턴스를 긴밀하게 연결해서 동일 클러스터 플레이스먼트 그룹에 배치하는 작업이 필요하다. 예로는 머신러닝, 기상 예측 등이 있다.
  개별 인스턴스의 성능 저하 문제가 클러스터 전체로 이어지지 않도록,
  Tightly Coupled는 거의 동일한 사양으로 구성하는 경우가 많다. 또한 개별 인스턴스의 실패가 다른 인스턴스에 영향을 주지 않도록, 개별 인스턴스의 시뮬레이션 상태 또는 단계를 정기적으로 저장해서 실패 상황에 대비한다.

[Elastic Fabric Adapter]

전통적인 TCP/IP 네트워크 연결성을 지원하는 특수한 형태의 ENA이며, Libfabric API를 이용해 OS의 기본 TCP/IP 스택을 우회해 EFA에 직접 접속할 수 있도록 해주므로 HPC 애플리케이션을 위한 높은 처리량 및 저지연성을 제공한다.
EFA 트래픽은 라우팅으로 제어할 수 없으므로, HPC 애플리케이션에 EFA를 적용할 때는 모든 인스턴스가 동일 서브넷 내에 있도록 해야 한다. 또한 클러스터 내 모든 EFA는 동일한 보안 그룹에 부착돼야 하며, 보안 그룹은 유입 및 유출되는 모든 트래픽을 허용해야 한다. 아울러 인스턴스는 동일 클러스터 플레이스먼트 그룹에 넣어서 네트워크 전송 지연을 최소화 하는 것이 좋다.

[AWS ParallelCluster]

Linux 기반 HPC 클러스터를 자동으로 관리하며, 클러스터 인스턴스 프로비저닝 작업을 수행하고, 15GB의 공유 파일시스템을 자동으로 생성한다. 공유 파일시스템은 마스터 인스턴스에 부착된 EBS 볼륨에 저장되며, NFS를 통해 다른 인스턴스에 저장된 파일을 공유할 수 있다. NFS 외에도 EFS 또는 FSx를 연결해 공유 파일시스템으로 활용할 수 있다.
또한 AWS Batch를 이용해 배치 스케줄러를 생성한다. 사용자가 배치 스케줄러에 HPC 컴퓨팅 잡을 제출하면, ParallelCluster가 작업에 맞춰 자동으로 클러스터의 확대 또는 축소한다.