Skip to main content

NHN Cloud VPC별 시나리오

ghdwlsgur
ghdwlsgur
Blog Owner

오늘은 NHN Cloud의 MSP 파트너 교육을 통해서 학습한 내용들이 모두 실무에서 활용 가치가 높아 오래 기억하기 위해 개념과 실습 과정들을 정리해보았습니다. 하루종일 받은 교육이라 정리하는 데에도 꽤 오랜 시간이 걸렸네요 그러니 알차게 읽어주세요 ㅎㅎ 평소 AWS에서만 줄곧 다루던 서비스들을 이젠 NHN Cloud 서비스로 다루니 비슷하면서도 색 다른 점도 많은 것 같네요. 먼저 NHN Cloud의 거버넌스 설정인 조직과 프로젝트 개념부터 시작하겠습니다.

조직​

  • 비용 청구의 단위이기 때문에 비용 청구를 고려하여 구성
  • 기본적으로 조직은 결제 수단을 등록한 회원당 3개까지 제공
  • 프로젝트는 유사한 작업/프로젝트 단위로 Cloud 서비스를 효율적으로 사용하고 관리하기 위해 사용하며, 프로젝트 단위로 Cloud 서비스를 활성화하고 이에 따라 과금합니다.
  • 회사의 프로젝트와 유사한 개념으로 볼 수 있고 하나의 조직에서 여러 개의 프로젝트를 만들 수는 있으나 여러 조직에서 동일한 프로젝트를 만들고 조직 단위로 참여할 수는 없습니다.
  • 하나의 프로젝트를 여러 조직의 멤버는 참가할 수 있음
  • 리소스 사용량은 프로젝트 단위로 계산
  • 기본적으로 프로젝트는 조직당 5개까지 제공

고려/주의사항​

  • 조직의 멤버가 아니더라도 프로젝트의 멤버가 될 수 있음
  • 프로젝트 멤버로 IAM 계정을 이용하려면 조직 내부 회원으로 먼저 등록한 후 프로젝트 멤버로 추가해야 함

NHN Cloud 회원​

  • 조직 관리를 위한 멤버
  • NHN Cloud 이용 약관에 동의한 NHN Cloud 회원으로 서비스 이용에 대한 책임과 의무를 가지는 멤버
  • NHN Cloud 서비스 전체에서 유효한 멤버로 소속된 조직이 삭제되어도 NHN Cloud 회원으로 존재

IAM 멤버​

  • 서비스 이용을 위한 멤버
  • NHN Cloud 이용 약관에 동의하지 않은 멤버
  • 조직 내에서만 유효한 멤버, 소속된 조직이 삭제되면 삭제되는 멤버
  • 프로젝트 멤버로 IAM 계정을 이용하려면 조직 내부 회원을 먼저 등록한 후 프로젝트 멤버로 등록할 수 있습니다.
  • 원하는 서비스만 사용하게 할 수 있도록 역할 설정 → 역할 추가
  • 역할에 대한 추가 Limit은 존재하지 않는다.
  1. 회원 ID/패스워드, Appkey 등 중요 정보 등 공용 저장소에 저장 금지
  2. 회원 ID/패스워드의 안전한 관리를 위해 주기적으로 패스워드 변경
  3. IAM 계정 또한 2차 인증을 설정하여 제공하는 것을 강력히 권고합니다.
  4. 조직 관리 - 거버넌스 설정에서 2차 인증으로 Google OTP, 이메일을 적용하여 보안을 강화할 수 있습니다.

사설IP(Private IP): 내부 네트워크상에서 사용되는 주소로 인터넷 상에서는 사용할 수 없는 IP입니다. 회사 내부 네트워크나 학교 공용 컴퓨터 등에서 사용되며, 사설 IP는 하나의 네트워크 안에서 유일합니다. 사설 IP는 같은 사설망 안에서 IP가 중복되면 안되지만 다른 사설망끼리는 IP가 중복돼도 무방합니다.

공인IP(Public IP): 공인 IP는 전세계적으로 유일한 IP입니다. 인터넷을 통한 통신을 하기 위해서는 공인 IP가 반드시 있어야합니다. 공인 IP의 경우 각 나라들마다 관리하는 기관이 있는데, 우리나라의 경우 한국인터넷진흥원에서 관리하고 있습니다.

논리적으로 격리된 가상의 사설 네트워크(Virtual Private Cloud)에서 NHN Cloud의 리소스를 운영할 수 있는 기능을 제공합니다. 각각의 VPC는 완전히 독립된 서브넷, 라우팅 테이블과 게이트웨이를 구성할 수 있으며 각각을 제어할 수 있습니다.

Subnet은 VPC의 하위 단위로 VPC 범위 내에서 용도에 맞게 네트워크 공간을 세분화하여 사용하도록 하는 것입니다. 서브넷의 경우에는 VPC 주소 범위에 포함되어야 하며 주소 길이가 같거나 작아야 하며 서브넷이 생성되면 VPC에 포함된 기본 라우팅 테이블에 자동으로 연결됩니다.

VPC를 생성하면 라우팅 테이블이 자동 생성되고 VPC 네트워크 대역으로 향하는 트래픽은 로컬 게이트웨이로 이동하게 되며 서브넷 네트워크 대역은 VPC 네트워크 대역에 속하기 때문에 VPC안 서브넷끼리는 별도의 라우팅을 잡지 않아도 통신할 수 있게 됩니다.

같은 가용성 영역에 만들어진 인스턴스 사이에서는 블록 스토리지를 공유할 수 있으나, 서로 다른 가용성 영역에서 만들어진 인스턴스끼리는 블록 스토리지를 공유할 수 없습니다.

Security Group​

보안 그룹은 ‘STATEFUL’로 동작하기 때문에 규칙으로 한 번 연결된 세션은 반대 방향의 규칙이 없더라도 허용되며 인스턴스 앞단에서 제어하고 보안 그룹 자체로 규칙을 설정하면 해당 보안 그룹에 생성된 모든 보안 규칙들이 적용됩니다.

Network ACL​

  • VPC 앞단에 위치하여 소스, 데스티네이션 주소 등을 선택 가능
  • 허용 또는 차단 정책 선택 가능, 네트워크로 유입되는 패킷을 제어
  • order 번호에 따라서 우선권을 가지고 순서대로 적용됩니다.
  • 작은 번호가 높은 우선권을 가집니다.

인스턴스 템플릿​

자주 사용하는 인스턴스 구성 요소 정보를 미리 정의해 보관하는 서비스로 Auto Scale을 사용하기 위한 스케일링 그룹을 만들 때 사용합니다. 구동 중인 인스턴스의 이미지 생성은 파일 시스템 무결성을 보장하지 않으니 인스턴스 정지 후 생성을 권고하고 보통의 경우 서버의 이미지를 생성해서 다른 리전으로 복제하여 동일한 환경의 서버를 구축하거나 다른 프로젝트에서 공유하기 위해서 사용합니다.

1. VPC별 시나리오 구성하기 (NAT 게이트웨이)​

NAT 게이트웨이를 이용하면 인터넷 게이트웨이가 연결되지 않은 인스턴스들이 인터넷에 액세스할 수 있습니다. 하지만 인터넷에서 이 인스턴스들로 연결을 시작할 수는 없습니다. 한국(판교), 한국(평촌) 리전에서만 제공하는 기능이며 아웃바운드 트래픽만 허용하는 단방향 트래픽입니다. 여러 라우팅 테이블에서 동일한 NAT 게이트웨이를 사용할 수 있으며 인터넷 게이트웨이와의 차이점은 인터넷 게이트웨이는 양방향 통신이 가능하지만 NAT Gateway는 단방향 통신만 가능합니다.

nhn-edu1

구조는 다음과 같으며 private-server의 보안 그룹은 web-server의 사설 IP에 한정하여 ssh 22번 포트를 허용해주고 각 서브넷의 라우팅 테이블은 로컬 게이트웨이와 연결되어 사설 IP로 통신할 수 있도록 합니다. 만약 22번 포트를 전체 접근으로 허용한다면 브루트 포스등 다양한 공격에 노출되게 되므로 꼭 확인된 IP만 연결하도록 합니다. 두 인스턴스 모두 nhn_temp.pem이라는 동일한 키페어를 사용하므로 web-server에서 private-server로 접속할 수 있도록 로컬 PC에 있는 키페어를 web-server 인스턴스로 rsync를 사용하여 키 페어를 전달합니다.

rsync -avz -delete -partial -e "ssh -o StrictHostKeyChecking=no -i nhn_temp.pem" nhn_temp.pem centos@125.6.44.120:~/nhn_temp.pem

키 페어를 올바르게 전달했다면 웹 서버 인스턴스에 접속한 상태에서 디비 서버의 사설 IP로 접속합니다.

ssh -i nhn_temp.pem centos@10.0.2.67

이후 yum update -y를 실행하면 에러가 발생하는데 이는 디비 서버인 private-server의 트래픽이 인터넷과 연결되지 않은 상태이기 때문에 업데이트를 진행하지 못하는 것입니다.

nhn-edu2

따라서 퍼블릭 서브넷에 NAT 게이트웨이를 생성한 후 프라이빗 서브넷의 라우팅 테이블에 외부로 향하는 0.0.0.0/0은 모두 NAT Gateway를 통해 인터넷으로 나갈 수 있게 됩니다.

nhn-edu3

업데이트를 진행하기 전에 아래 명령어를 실행하여 인터넷과의 연결을 확인하면 패킷이 잘 나가는 것을 확인할 수 있습니다.

ping 8.8.8.8

정상적으로 인터넷과 연결되어 있는 것을 확인하였다면 yum update -y를 진행하여 디비 서버의 업데이트를 진행할 수 있습니다.

2. VPC별 시나리오 구성하기 (VPC 피어링)​

피어링은 서로 다른 두 개의 VPC를 연결하는 기능이며 보통의 경우 VPC는 네트워크 영역이 다르기 때문에 서로 통신이 불가능하며 플로팅 IP를 이용하여 연결할 수 있으나 이는 네트워크 사용량에 따라 추가 과금됩니다. 따라서 두 개의 VPC를 연결하는 기능을 제공하는데 이를 피어링이라고 합니다. 피어링은 서로 다른 두 VPC만을 연결하며 전이적 연결은 지원하지 않습니다. 피어링의 종류에는 리전 피어링과 프로젝트 피어링이 있습니다.

이번 시나리오에서는 두 VPC를 연결하는 VPC 피어링을 구현하기 위해서 192.168.0.0/16 대역의 VPC와 192.168.0.0/24를 갖는 퍼블릭 서브넷, Floating IP를 갖는 퍼블릭 인스턴스를 생성해주었습니다.

nhn-edu4

두 VPC의 피어링 연결을 확인하기 위해 ICMP 프로토콜을 사용하고 VPC-demo의 web-server의 보안 그룹과 VPC-demo2의 server-vpc2 보안그룹은 모두 web-sg란 보안그룹을 설정하도록 하며 각 인스턴스의 사설 IP로 향하는 ICMP 패킷을 허용하도록 할 수도 있지만 아래 사진 처럼 보안그룹을 참조하도록 하여 두 인스턴스에서 주고 받는 ICMP 패킷을 허용하도록 해주었습니다.

nhn-edu5

여기까지 설정하면 두 VPC의 사설 IP 대역이 다르고 서로 다른 환경으로 격리된 상태이기 때문에 통신할 수는 없습니다. 따라서 피어링 게이트웨이를 생성하고 VPC-demo의 퍼블릭 서브넷과 VPC-demo2의 퍼블릭 서브넷의 라우팅 테이블을 수정하여 서로 통신할 수 있게 해줍니다.

nhn-edu6

VPC 피어링시 주의해야 할 점은 각 서브넷의 라우팅 테이블에 통신하고자 하는 대상 서브넷의 IP 대역을 입력해야 합니다. 예를 들어 VPC-demo의 web-server 인스턴스는 VPC-demo2의 server-vpc2와 통신하기 위해서 VPC-demo의 public-subnet의 라우팅 테이블에 192.168.0.0/24로 향하는 패킷은 피어링 게이트웨이를 통하도록 지정하고 VPC-demo2의 public-subnet-2의 라우팅 테이블에는 10.0.1.0/24로 향하는 패킷이 피어링 게이트웨이를 통하도록 지정해줘야 하는 것입니다. 두 서브넷에서 라우팅 테이블을 설정했다면 사설 IP 대역으로 ping을 보내 통신이 잘 이루어졌는지 확인합니다.

web-server SSH​

ping 192.168.0.27

server-vpc2 SSH​

ping 10.0.1.14

3. VPC별 시나리오 구성하기 (서비스 게이트웨이)​

서비스 게이트웨이란 VPC에서 인터넷을 경유하지 않고 서비스 게이트웨이에서 제공하는 NHN Cloud의 서비스에 연결할 수 있습니다.

서비스 게이트웨이 생성시 서비스 목록에 제공되는 서비스만 이용이 가능하며 서비스에는 아래와 같은 것들이 있습니다.

  • Server Security Check
  • Object Storage
  • CloudTrail
  • NHN Container Registry (NCR)
  • IaaS Identify

또한 특징으로는 서비스 게이트웨이의 IP 주소는 서비스 게이트웨이 생성 시 선택된 서비스와 1:1로 연결되며 서비스 게이트웨이가 생성된 VPC 내에서만 사용이 가능합니다. 또한 지정한 서브넷 내의 리소스끼리만 매핑됩니다.

Object Storage 생성​

가장 먼저 접근 정책이 PUBLIC인 Object Storage 컨테이너를 생성하고 생성한 컨테이너에 이미지 테스트 파일을 업로드 한 후 이미지 경로를 나타내는 Public URL을 복사합니다.

https://kr2-api-storage.cloud.toast.com/v1/AUTH_2d54862e17604be194f232cbce0ed12d/object-stgw/character.png

Public URL의 형식은 아래와 같습니다.

  • 프로토콜: https
  • 호스트: kr2-api-storage.cloud.toast.com
  • PATH: v1/[API 엔드포인트 설정 - 스토리지 계정]
  • 컨테이너명: object-stgw
  • 파일 경로: character.png

이번에는 서비스 게이트웨이를 생성해주겠습니다.

  • 이름: service-gateway
  • VPC: VPC-demo
  • 서브넷: public-subnet
  • 서비스: Object Storage

Public URL​

nhn-edu7

VPC-demo 안에 public-subnet에 서비스 게이트웨이를 생성했으므로 해당 서브넷에 위치한 인스턴스에서 Object Storage로 1:1 매핑되어 연결되게 됩니다. 그럼 이제 해당 인스턴스에 접속하여 이미지 컨텐츠를 다운로드 받아보겠습니다. Public URL의 경우 URL 복사를 클릭하여 스토리지 URL을 복사합니다.

wget https://kr2-api-storage.cloud.toast.com/v1/AUTH_2d54862e17604be194f232cbce0ed12d/object-stgw/character.png

위 명령어를 실행할 경우 공용 인터넷을 통하여 이미지 컨텐츠를 다운로드 받게 되지만 서비스 게이트웨이를 사용하는 목적은 사설 IP로 NHN Cloud의 외부 서비스인 Object 스토리지의 이미지 컨텐츠를 다운로드 받기 위함입니다. 즉 인터넷 게이트웨이를 통하지 않고 서비스 게이트웨이를 통해 프라이빗 통신으로 다운로드 받기 위해 위 도메인 URL의 호스트 부분을 서비스 게이트웨이의 IP로 바꾸어 재 요청합니다.

wget http://10.0.1.84/v1/AUTH_2d54862e17604be194f232cbce0ed12d/object-stgw/character.png

여기서 눈 여겨보아야 할 것은 HTTPS 프로토콜이 아닌 HTTPS 프로토콜로 요청해야 한다는 점입니다.

위 이미지 컨텐츠를 가지고 있는 Object 스토리지는 접근 제어가 퍼블릭으로 설정되어 있기 때문에 다른 인스턴스 뿐만 아니라 로컬 피씨에서도 위 이미지 컨텐츠에 접근할 수 있게 됩니다. 하지만 Object Storage의 접근 제어를 PRIVATE로 설정하였다면 인증 토큰을 필요로 하게 됩니다.

Private URL​

nhn-edu8

먼저 인증 토큰을 발급 받습니다.

인증토큰 발급 받기

curl -X POST -H 'Content-Type:application/json' \
https://api-identity.infrastructure.cloud.toast.com/v2.0/tokens \
-d '{"auth": {"tenantId": "테넌트ID", "passwordCredentials": {"username": "NHNCloudID", "password": "API비밀번호"}}}'

위 명령어를 실행할 경우 토큰을 발급 받을 수 있게 되는데 Private URL의 경우 이 토큰을 X-Auth-Token 값으로 헤더에 추가하여 요청해야만 정상적으로 이미지를 다운로드 받을 수 있습니다.

curl -O -X GET -H 'X-Auth-Token: 토큰' http://10.0.1.84/v1/AUTH_2d54862e17604be194f232cbce0ed12d/object-stgw2/Network_https1.png