[AWS] Region, AZ, VPC, Subnet등 구성

AWS 기초 - 2

Posted by owin2828 on 2020-01-10 14:15 · 8 mins read

들어가기 앞서

기초적인 내용을 들어가기 전에 여담으로 aws 사용에 대한 이야기를 잠깐 하고 가겠다.

퍼블릭 클라우드가 그러하듯이, aws 또한 모든것이 가상화 되어있다.
이 말은 내가 신경쓰고 관리해야할 것이 전혀 없다는 말이고 모든 것을 aws가 알아서 해주는 것이다.
하지만 이러한 이유로 하드웨어적 장애가 생겼을 때, 반대로 내가 할 수 있는 것은 전혀 없다.

무슨 말이냐면, 하드웨어적 결함으로 어떤 에러가 발생하였을 때
그게 내 문제인지, aws의 문제인지 알지 못할 수도 있다는 의미이다.
생각보다 이러한 이유가 굉장히 스트레스 받는 일이 된다고 우리팀의 시니어분께서 말씀해 주셨다.

실제로 어떤 기업의 세미나에서 aws 기반 서비스를 개발하던 중, 이런 장애를 만나서 고생한 이야기를 들었다.
장애의 원인이 본인들의 문제인지, aws의 결함인지 알지 못하여 문의로 해결을 받기까지 고생한 이야기인데,
알 수 없는 에러와 싸우며 몇날 몇일을 고생했다고 하셨다..

하지만 이런 단점에 비해 얻는 장점이 월등히 많으므로 전세계가 aws에 열광하는 것이 아닐까

각설하고 본격적으로 aws의 기초 구성에 대해 알아보도록 하자.

AWS Public Cloud의 구성

출처: https://blog.leedoing.com/46

AWS의 기본적인 구성요소의 단위는 다음과 같다.

  • region
  • AZ(Availability Zone)
  • VPC(Virtual Private Cloud)

1. region

구성요소 중 가장 큰 단위이며, 논리적인 단계이다.

2. AZ(Availability Zone)

실제 IDC 단위로써, aws 정책에 따라 하나의 region안에는 반드시 2개 이상의 AZ가 존재한다고 한다.
(그림에서도 2개의 AZ가 존재한다.)
시스템을 구성할 때 single AZ로 할 것인지, multi AZ로 할 것인지는 사용자의 선택사항이다.

multi AZ로 구성하여 data들을 이원화하여 안전하게 보관하는 것도 하나의 방법이고,
Elastic Load Balancer를 통해 각각의 AZ가 다른 일을 수행하게 하는 것도 하나의 방법이다.

3. VPC(Virtual Private Cloud)

AZ 밑의 단위로써, 논리적인 구조로 하나의 IDC 처럼 동작한다.

약간 웃긴것이 분명 public 서비스인데, private가 붙었다.
그 이유는 논리적인 하나의 IDC를 만들어서 개인이 사용할 수 있기 때문이라고 한다.

모든 리소스는 VPC에 저장되며 한 region에 5개까지 VPC를 생성할 수 있다.(필요시 제한용량 해제 신청)
물론 VPC 없이도 서버를 생성할 수 있지만, 권장되지 않는다고 한다.

계정을 생성하면 기본 VPC가 생성되고 그 안에 기본적인 구성요소들이 생성된다.

이 기본 VPC는 건들지 말자. 어떤 에러들이 발생한다고 한다.

출처: https://cloudaffaire.com/create-a-vpc-interface-endpoint/

위 그림에서도 볼 수 있듯이, VPC의 구성은 다음과 같이 이루어진다.

  • IGW(Internet Gate Way): 외부로 연결되는 인터넷 게이트웨이
  • Subnet: VPC의 가장 기본적인 하나의 단위로써, 각 서브넷은 public, private 중 설정이 가능
    private은 외부에서 접속할 수도, 외부로 나갈 수도 없음
  • ACL: 서브넷의 설정을 위한 방화벽
  • Security Group: 서브넷 하나의 보안을 설정, 주로 ACL은 두고, SG를 설정하여 보안관리
  • ELB(Elastic Load Balancing): 로드밸런싱과 보안 설정을 해줌
    private 서브넷을 만들경우, 외부와 통신이 안되는데 이때 ELB를 사용해서 외부에서 접근하도록 설정
    (로드밸런싱과 허용된 매서드만 접근이 가능해진다고 함)
    ELB의 종류는 다음과 같이 3가지 존재
    • Classic: 예전 방식
    • Application: 도메인 하위 레벨(/users 등)에 따라 다르게 웹 서버에 구성하고 이를 밸런싱
    • Network: 모든 프로토콜(http(s) + 커스터마이징 프로토콜)에 대해 밸런싱

3-1. Subnet과 EC2 인스턴스

하나의 VPC에는 여러개의 서브넷을 생성할 수 있다.(10.1.10.100 / 10.1.10.110 등..)
이때 ip를 구분하여 용도에 맞게 할당해 내부적으로 영역을 구분한다.
(x.x.x.100대 이상은 외부통신, 미만은 내부통신 같은 방식)

이렇게 만들어진 서브넷 하나에 만드는 서버를 우리가 아는 EC2라고 한다.
오브젝트를 만들고 메모리에 올려 사용하는 것을 인스턴스라 칭하므로,
가상화된 환경에 올려 사용자가 사용할 수 있도록 한 것을 EC2 인스턴스라 부른다.

3-2. Bastion

출처: https://www.youtube.com/watch?v=edi1kyxznE0

VPC를 구성할 때, 내부 서브넷들을 전부 private으로 설정하고 하나만 관리용 public 서브넷으로 설정한다.
이 public 서브넷으로 다른 private 서브넷들을 관리하며, 이러한 관리자를 bastion이라 한다.
이런 방법을 사용하려면 SG(Security Group)을 설정해 한정된 IP만 bastion에 접근하도록 허용해야 한다.

만약 전부 public으로 서브넷을 만든다면, 관리자 중 한 명만 퇴사해도 모든 서브넷의 key를 갱신해야 한다.
매 번 이렇게 서브넷을 업데이트 할 수 없으므로, 전부 private으로 설정한다.

3-3. NAT

하지만 문제는 여전히 존재한다. 전부 private으로 만들어 버렸으니, 각 서브넷의 외부와 통신이 안된다.
그럼 각 서브넷의 OS 업데이트는 어떻게 하는가?

출처: https://blog.2dal.com/2017/09/12/aws-vpc-basic/

정답은 하나의 서브넷을 public으로 설정 후 outbound는 가능하게, inbound는 불가능하게 만들면 된다.
이런 역할을 NAT이라 부르며 하나의 서브넷에 bastion과 NAT을 둘다 포함시킬 수도 있다.

이전에는 NAT 인스턴스를 생성해야 했으나, NAT gateway를 생성하여 서브넷 안에 포함시키면 작동하도록 변경되었다.

3-4. Dev, Manage, Product VPC

실제 개발 및 배포를 진행할 때는 VPC 구성을 어떻게 해야할까?
여러가지 방법이 있겠지만, aws는 각 단계별로 VPC를 따로 구성하는 것을 추천한다.

출처: https://aws.amazon.com/ko/quickstart/architecture/compliance-uk-official/

위의 그림은 aws 공식 홈페이지에서 가져온 것인데, Dev/Managemnet/Production 총 3단계로 구성되있다.
이렇게 Stage 별로 VPC를 따로 구성해서 관리하는 것이 복잡한 서브넷간 설정을 피할 수 있기 때문이다.

물론 하나의 VPC 안에서 서브넷을 나눠 그룹별로 관리할 수도 있으나, 규모가 커졌을 때 서브넷간의 복잡한 설정으로 어려움이 따르게 된다.

4. S3(Simple Storgae Service)

출처: https://www.megazone.com/techblog_191113_aws-privatelink/

S3는 단순하게는 하나의 저장소이다.
하지만 활용법에 따라 효율적인 정보의 전달이 가능한데, 이는 S3가 웹서버 역할을 제공하기 때문이다.
이는 다음의 과정을 거쳐 이루어지게 된다.

S3는 기본적으로 VPC 밖에 구성된 하나의 웹서버로써 이곳에 html 같은 정적인 파일을 주로 배치한다.
End-user에게는 이곳을 보도록 설정하고, user가 원하는 요청을 수행하도록 그 파일에 스크립트로 짜놓는다.
User가 해당 요청을 하게되면 스크립트가 브라우저에서 실행되어, VPC를 거쳐 EC2까지 요청을 전송한다.
이러한 과정을 통해 User는 VPC를 신경쓸 필요없이 S3의 html로 결과를 받을 수 있게 된다.

이러한 방식은 사실상 업계의 표준이라고 하며, 다른 오브젝트들이 이러한 S3호환 프로토콜을 제공한다.

5. RDS(Relation DB Service)

하나의 서브넷을 구현하고, 그 안에 DB 서버를 구축하여 운영하는 것이 기존의 방식이었다면,
aws에서 제공하는 Paas의 일종인 RDS를 이용하여 더 효율적인 관리를 할 수 있다.

이는 aws가 DB의 업데이트, 설치, 운영 그리고 관리까지 지원하기 때문이며, 지원하는 엔진은 다음과 같다.
MySQL/Oracle/SQL Server/PostgreSQL/MariaDB/Aurora(MySQL과 호환)

또한 RDS에서 Multi-AZ 옵션을 설정하면, 다른 AZ에 복제된 DB를 바로 사용할 수 있다.
주로 data를 백업하여 이원화하는 용도로 많이 쓰이게 된다.

Aurora는 aws에서 제공하는 자체 DB로써 장애발생 및 AZ를 이용한 자체복구등 추가 기능을 지원한다고 한다.

끝마치며

aws의 기초에 대해 유능하신 어떤 분께 배운 내용을 토대로 작성된 글이다.
인터넷을 찾아보면 훨씬 전문적이고 깊은 이해를 돕는 글들이 있지만,
이 포스팅의 목적은 최대한 간단하게, 이해가 되도록 작성하는 것이었다.

너무 긴 글이라 두개로 분리할까 고민했는데, 혹시 지치신 분들이 있다면 위로가 있기를…
다음에는 간단하게 AWS VPC를 구성하는 실습을 진행해 볼 예정이다.

이번 포스팅에는 사진에 달려있는 출처들이 reference 역할을 하기 때문에 따로 참조를 달지 않았다.

<< Previous Next >>