[2주차] AWS ELB, EC2, CodeDeploy에 대한 이해

이 문서는 [월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z에서 사용할 GitHub Action에 대한 안내서입니다.

개요

본 문서에서는 정적 페이지와 동적 페이지를 포함하고 있는 Next를 배포하기 위해 ELB, EC2 기반의 아키텍처를 설계해보겠습니다.

사전 지식

본 문서를 제대로 읽기 위해서는 아래 선수 지식이 필요합니다.

• Unchaptered (Blog) | [1주차] AWS CloudFront, S3에 대한 이해

• Dusunax.log (Blog) | [2주차] Next에 대한 이해

본 문서에서는 스토리지, 컴퓨트의 정의 및 조합에 대한 기본적인 시야를 얻고자 합니다.

1. 다양한 부품

2. 스토리지 vs 컴퓨트

다양한 부품

컴퓨터에는 CPU, Disk, 모니터, 마우스 등의 다양한 부품이 있습니다.
이런 부품들을 2종류로 구분하며, “서버로서 기능하기 위한 최소단위”를 고민해보았습니다.
 

1. CPU 등의 컴퓨트 장비
   서버가 연산 처리를 하기 위해서 필요한 장비
   (e.g. CPU, GPU, REM, MEM, S1/S2/S3 Cache)

2. Disk 등의 스토리지 장비
   서버가 프로그램을 설치하기 위해 필요한 공간
   (e.g. HDD, SSD)

실제로 PC, 노트북, 서버를 구성할 때 컴퓨트 장비의 비용이 더 높습니다. 따라서 AWS에서 서비스를 선택할 때의 비용 순서도 일반적으로 다음과 같습니다.

1. 컴퓨트 + 스토리지 일체형 서비스

2. 컴퓨트 서비스

3. 스토리지 서비스

일반적으로 알고 있는 서버리스 서비스들이 [1번 유형]에 해당하며, 실제로 30% 이상 더 비싼 비용을 지불합니다.

컴퓨트 vs 스토리지

어떻게 선택하는가?

다양한 변수에 의해 비용이 천차만별이지만, 일반적으로 다음이 비용 부담이 커집니다.

• 스토리지(A 유형) < 컴퓨트(B 유형) < 스토리지 + 컴퓨트(C유형)

특히 AWS는 사용한 부분만큼 비용이 지불되는 구조(On-demand)이기 때문에, 이를 사용 유형에 따라서 분리하는 것이 좋습니다.

분리형 예시

가장 대표적인 예시가 프론트엔드는 CloudFront, S3를 통해 배포하고 백엔드는 EC2, EBS를 통해 배포하는 사례입니다.

인프라 아키텍처 설계 접근법

Next SSR

Next는 그 사용 사례에 따라서 CSR, SSR, SSG 등 수많은 랜더링 방식을 가지고 있습니다. 따라서 다양한 랜더링 유형에 맞춰서 적합한 인프라 아키텍처가 존재할 것입니다.

저희는 정적 페이지와 동적 페이지를 가지고 있는 SSR 방식의 Next를 배포할 것입니다. 즉, 정적 콘텐츠와 동적 콘텐츠를 모두 제공할 것입니다.

1. 동적 콘텐츠를 제공할 방법을 찾는 것(우선)

2. 사이트를 HTTPS로 만드는 거

3. 정적 콘텐츠를 캐싱할 방법을 찾는 것(선택)

동적 콘텐츠를 제공할 방법?

“AWS에서 동적 콘텐츠 제공하기”라고 검색하면 CloudFront를 활용한 동적 콘텐츠 전송 사례가 노출됩니다.

1. AWS (Blog) | Amazon CloudFront를 활용한 동적 콘텐츠 전송 성능 개선하기

2. AWS (Blog) | Amazon CloudFront 동적 콘텐츠 전송

3. AWS (Blog) | AWS CloudFront를 사용하여 동적 콘텐츠 전송하기(Dynamic Content Delivery)

1번은 CloudFront를 거쳐서 S3로 동적 콘텐츠를 저장하는 것으로 보입니다.

2번 CloudFront를 거쳐서 글로벌 서비스에서의 사용자 경험(UX, User Experience)를 개선한 사례로 보입니다.

3번 CloudFront를 거쳐서 정적 콘텐츠와 동적 콘텐츠를 캐싱하는 것으로 사용자 경험(UX)를 개선한 사례로 보입니다.

하지만 셋 모두 Next를 배포하는 기본 사례에 적합하지 않습니다.

컴퓨팅 서비스

저희는 현재 “서버”가 필요한 것이기 때문에 “AWS 컴퓨팅 서비스”로 검색어를 변경해보겠습니다.

대분류를 먼저 결정해야 하기 때문에 ChatGPT를 통해서 아래 5종류를 문의해보겠습니다.

저희는 현재 배포를 처음 하기 때문에 가장 자유롭고 간단한 인스턴스를 고르겠습니다.

인스턴스가 사례가 제일 많고 개발자가 간섭할 수 있는 범위도 매우 넓습니다.
컨테이너나 서버리스의 경우, 추상화가 많이 되어 있기 때문에 처음에는 많이 난해합니다. 엣지 및 하이브리드의 경우, 일반적인 서버로서 사용하기에 흔한 사례가 아닙니다.

EC2에 대한 이해

역시 “AWS EC2란”이라고 검색해보았습니다.

글을 조금 읽다보면, VPC에 배포된 EC2의 기본 아키텍처라고 나오는 것을 알 수 있습니다.

Region, AZ(Availability Zone), VPC(Virtual Private Cloud), Subnet(Public Subnet), IGW(Internet Gateway), SG(Security Group), EBS(Elastic Block Storage) 등 너무 많은 리소스들이 많아서 한 번에 이해할 수가 없습니다.

그래서 이 내용을 3종류로 구분해보겠습니다.

1. 리소스 레벨(Resource Level) 및 물리적 주소지(Region, AZ)

   AWS 리소스의 레벨 유형

2. 네트워크 리소스(Network Resource)
   서버에 할당되는 IP 주소와 인터넷 공급과 관련된 리소스들

3. 컴퓨팅 리소스(Computing Resource)
   서버가 가동되기 위한 리소스들

각각의 내용들에 대해서 접근해보겠습니다.

리소스 레벨 및 물리적 주소지

모든 AWS 리소스는 리소스 레벨과 그 유형에 맞는 물리적 주소지가 제한되어 있습니다.

1. 리소스 레벨

2. 물리적 주소

리소스 레벨

1. 클라우드 레벨
   AWS 클라우드 내에 생기는 리소스
   기본적으로 모든 영역에서 해당 리소스에 접근할 수 있습니다.
    

2. 리전 레벨(Region Level)
   특정한 리전 내에 생기는 리소스
   기본적으로 동일한 리전 내에서 해당 리소스에 접근할 수 있습니다.
    

3. VPC 레벨
   특정한 VPC 내에 생기는 리소스
   기본적으로 동일한 VPC 내에서 해당 리소스에 접근할 수 있습니다.
    

4. 서브넷 레벨(Subnet Level)

   특정한 Subnet 내에 생기는 리소스
   기본적으로 동일한 Subnet 내에서 해당 리@소스에 접근할 수 있습니다.

물리적 주소

AWS에서는 리전과 가용 영역이라는 2가지 물리적 주소 단위가 있습니다.

1. 리전(Region)
   AWS의 데이터 센터가 위치한 지리적인 지역
   여러 개의 Availability Zone으로 구성

2. 가용 영역(AZ, Availability Zone)
   리전 내에서 물리적으로 분리된 데이터 센터
   가용성 및 내구성을 강화하기 위해서 최소 2~3개 이상의 가용 영역을 사용하는 것을 권장하고 있음

작성일(2024.04.16) 기준, AWS 글로벌 인프라 맵에는 현재 33개국 105개의 가용영역과 605개의 PoP가 있습니다.

리전과 가용 영역에 대한 조금 더 긴 설명을 보고 싶다면, hudi.log (Blog) | [AWS] 리전(Region)과 가용영역(Availability Zone)을 참고해주세요.

결론

AWS의 모든 서비스는 크게 2가지 제약사항을 가지게 됩니다.

리소스 레벨은 서비스가 어느 정도로 광범위한 서비스에서 제공되는 지를 의미합니다.

• PoP, REC를 기반으로 전세계에 웹 사이트를 배포하기 위해 사용한 CloudFront는 클라우드 레벨의 서비스입니다.

• 웹 사이트의 원본을 저장하기 위해 사용한 S3는 리전 레벨의 서비스입니다.

• 이번 시간에 사용할 EC2 인스턴스는 서브넷 레벨의 서비스입니다.

물리적 주소(소속)는 서비스가 어느 지역에서 제공되는 지를 의미합니다.

• 지난 실습과 이번 실습에서는 버지니아 북부(us-east-1) 리전을 선택했습니다.

• 그 중에서도 버지니아 북부 a/c/(us-east-1 a/c) 가용 영역을 선택했습니다.

결론

클라우드를 사용할 때는 반드시 아래의 내용을 짚어가면서 하는 것이 좋습니다.

1. 리소스 레벨 파악하기

2. 물리적 주소 기억하기

대부분의 클라우드의 버그는 리소스간 접근이 불가능하거나 그 권힌 없는 경우가 대부분이기 때문입니다. 따라서, 습관적으로 사용하는 리소스에 대해서 2가지를 파악하는 습관을 가져봅시다.

네트워크 리소스(Network Resource)

2주차에 실습 할 네트워크를 이해하기 위한 절차를 총 12단계로 구성하였습니다.

해당 내용들은 여러 차례에 걸쳐서 공부함으로써 네트워크에 대한 이해도를 높이고 실습을 진행하셨으면 좋겠습니다

1. 목적

2. 사전 지식

3. IPv4

4. CIDR Block

5. VPC

6. 서브넷(Subnet)

7. 인터넷 게이트웨이(IGW, Internet Gateway)

8. 라우팅 테이블(RTB, Routing Table)

9. 라우팅 우선순위(심화)

10. 적절한 네트워크 대역폭, CIDR Block 선택하기(심화)

11. 네트워크 주소 변환(NAT, Network Address Translation)

12. 네트워크 설계하기

목적

네트워크를 이해하기 위한 필수 지식에 대한 내용을 포함하였습니다. 이 지식이 부족하더라도 AWS 기본 네트워크(e.g. VPC)에서 간단한 Next MVP를 배포할 수 있습니다.

하지만 개인적으로 아래와 같은 문제점이 있습니다.

1. 프로덕션 레벨의 제품을 배포하기 위한 규정 준수가 불가능함

2. 네트워크 레벨의 버그가 발생했을 때, 스스로 버그를 해결할 수 없음

3. 누군가 “서버로 들어가는 요청이 어떻게 흘러가나요?”라는 물음을 하면 답할 수 없음

반대로 이번 [네트워크] 챕터를 제대로 이해하시면 아래 내용을 얻을 수 있습니다.

1. 프로덕션 레벨에 걸맞는 서버 구성이 가능함

2. 네트워크 레벨의 버그가 발생했을 때, 스스로 버그를 해결할 수 있음

   1. React에서 Spring, Next로 요청을 보냈는데 요청이 닿지 않는 경우

   2. Next 웹 페이지에서 Next 서버 측으로 요청을 보냈는데 요청이 닿지 않는 경우

3. 서버로 들어가는 요청의 네트워크 흐름을 비교적 정확하게 대답할 수 있습니다.

4. CS & Network 이론을 실무와 결합하여 사고할 수 있습니다.

따라서 Next를 통해서 풀스텍 엔지니어를 지향하신다면 [네트워크] 챕터를 복습할 뿐만 아니라, 추가적인 내용을 학습하는 과정이 유의미하다고 생각합니다.

사전 지식

인터넷 초기에는 모든 사용자에게 공개 IPv4 주소를 할당해줬습니다.
하지만 사용자가 급격히 증가하면서 사용 가능한 공개 IPv4 주소가 부족해질 것이 우려되는 목소리가 많이 나왔습니다. 이에 따라서 비공개 IPv4 주소를 사용한 사설 네트워크망에 대한 논의가 나왔습니다.

아래는 VPC와 연관된 RFC 문서를 최신순으로 나열한 것입니다.

1. RFC 5735, Special Use IPv4 Addresses

2. RFC 1918, Address Allocation for Private Internets

3. RFC 1519, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy

4. RFC 1486, Guidelines for Management of IP Address Space

5. RFC 1174, IAM Recommended Policy Change to Internet “Connected” Status

IPv4

IPv4 주소는 일반적으로 255.255.255.255의 형태로 구성되어 있습니다. 각 자리수는 십진수의 숫자 255로 표기되며, 이는 2진수 숫자 11111111(1, 8개)로도 표기됩니다.

2진수 00000001은 10진수 1
2진수 00001111은 10진수 15
2진수 00111111은 10진수 63

또한 IPv4 주소는 할당 받은 위치에 따라서 공개/비공개로도 구분됩니다.

• 공개 IP 주소
  공용 인터넷에서 할당받은 IP 주소

• 비공개 IP 주소
  사설 네트워크망에서 할당 받은 IP 주소

CIDR Block

CIDR Block은 사설 네트워크 망을 구축하기 위한 핵심 이론입니다. 일반적으로 192.168.0.0/16으로 표기됩니다.

CIDR Block은 범위의 시작점이 될 IPv4 주소와 서브넷 마스크로 구성됩니다. 즉, 위 이미지에서는 “192.168.0.0부터 시작해서 255.255.0.0 범위 만큼의 사설 네트워크 망을 만들 거야!”라고 적혀있는 것입니다.

과거와 현재

초창기 CIDR Block은 클래스 기반으로 사설 네트워크 망을 구축하였으나, 현재는 클래스리스 기반(RFC 1519)으로 구축되어 있습니다.

주요한 차이점은 사설 네트워크망을 구축하는 엔지니어가 “유연하게” IPv4 주소 할당 계획을 세울 수 있다는 점입니다.

서브넷 마스크(Subnet Mask)

위 CIDR Blcok 설명을 보면 2가지 의문이 생깁니다.

1. 255.255.0.0 이 왜 ~/16으로 변경되는거지?

2. 255.255.0.0 만큼의 범위가 무슨 말이지?

1번 의문의 정답은 2진수 변환에 있습니다.
10진수 255.255.0.0은 2진수 11111111.11111111.00000000.0000000입니다.
위 2진수 묶음에서 1의 숫자는 총 16개이고 이를 CIDR Block에서 표기할 때, ~/16이라고 표현합니다.

192.168.0.0/16이라고 써진 CIDR Block을 본다면, 아래를 알 수 있다.
- 시작이 되는 IPv4 : 192.168.0.0
- 서브넷 마스크 : 255.255.0.0

2번 의문의 정답은 별도의 계산 공식이 구글에 많이 나와 있습니다만, 실제로는 CIDR BLock Calculator를 많이 사용합니다. 해당 사이트에 CIDR Block을 적어보면 65,536개의 비공개 IPv4 주소를 할당할 수 있음을 알려줍니다.

단, 여기서 AWS VPC에서는 일반적으로 최소 5개의 비공개 IPv4 주소를 자동으로 할당합니다. 따라서 65,536 - 5개의 IPv4 주소가 사용 가능합니다.

조금 더 자세한 내용은 Inpa Dev (Blog)| 🌐 CIDR 개념 쉽게 이해해보자 & 계산법을 참고해주세요.

VPC

VPC는 논리적으로 격리된 가상 네트워크를 의미합니다.
이 리소스를 통해서 공개 IPv4 주소가 없는 수많은 서버들에게 비공개 IPv4 주소를 할당하여 시작할 수 있습니다.

아래는 VPC의 서비스 레벨과 물리적 주소입니다.

• 서비스 레벨 : 리전

• 물리적 주소 : 선택한 리전 (스터디 중에는 us-east-1)

서브넷(Subnet)

Subnet은 VPC 안에서 다시 한 번 논리적 주소 범위를 구분 짓습니다. 이 리소스를 통해서 서버의 유형 별로 서로 다른 서브넷을 씀으로써, 보안을 강화할 수 있습니다.

격리의 개념
단일 함수에 단일 기능을 담는 것처럼, 네트워크에서도 단일 격리 공간에 단일 서버를 배포하는 개념이 존재합니다.

즉 하나의 서비스를 제공하기 위해 Next 서버가 2종류가 존재한다면, 서브넷도 최소 2개가 있어야 할 것입니다.

아래는 서브넷의 서비스 레벨과 물리적 주소입니다.

• 서비스 레벨 : 가용 영역

• 물리적 주소 : 선택한 VPC와 가용 영역 (스터디 중에는 us-east-1a 혹은 us-east-1c)

인터넷 게이트웨이(IGW, Internet Gateway)

앞서 리소스 레벨을 설명할 때, 아래와 같은 내용이 있었습니다.

즉, 특정한 서브넷 안에 서버(EC2)가 배포되고 나면 외부에서는 접속할 수 없음을 의미합니다. 따라서 “AWS 서브넷에 인터넷 연결”로 검색해보겠습니다.

인터넷 게이트웨이를 사용하여 인터넷 연결에 따르면, 주요한 특징은 다음과 같습니다.

1. (퍼블릭) 인터넷의 리소스와 (VPC) 서브넷 하위의 리소스 간 통신 ㅣ지원

   1. 인터넷의 리소스는 IPv4, IPv6를 사용하여 서브넷의 리소스에 접근 가능

   2. 서브넷 리소스는 IPv4, IPv6를 사용하여 인터넷의 리소스에 접근 가능

      1. 이때, IPv4 주소는 VPC 라우팅 테이블에서 NAT(Network Address Translation)도 수행됨

      2. 단, IPv6는 주소 자체가 퍼블릭이므로 NAT이 수행되지 않음

라우팅 테이블(RTB, Routing Table)

퍼블릭 인터넷과 서브넷 리소스를 상호 연결하기 위해서 인터넷 게이트웨이가 필요함을 알았습니다. 그리고 이 과정에서 라우팅 테이블이라는 단어가 나왔습니다.

“AWS 라우팅 테이블이란?”이라고 검색을 해보니, 라우팅 테이블 구성이라는 내용이 나옵니다. 여기서 서브넷 라우팅 테이블을 읽어보지만 이해가 되지 않습니다.

애초에 라우팅이 뭔지 모르기에, 공식 블로그의 라우팅 설명를 참조하면 아래와 같습니다.

• 라우팅은 네트워크에서 경로를 선택하는 프로세스이다.

• 라우팅 테이블은 클라우드 리소스들에 대한 라우팅이 기록된 표이다.

이제 서브넷 라우팅 테이블 설명에 포함된 예시를 통해서 개념을 더 짚어보겠습니다.

• 10.0.0.0/16

  10.0.0.0 ~ 10.0.255.255 범위에 해당하는 IPv4는 Local로 보낸다.

  Local은 해당 네트워크(VPC)에 직접 연결된 인터페이스를 의미

• 2001:db8:1234:1a00::/56

  2001:0db8:1234:1a00:0000:0000:0000:0000 ~ 2001:0db8:1234:1aff:ffff:ffff:ffff:ffff 범위에 해당하는 IPv6는 Local로 보낸다.

• 172.31.0.0/16 (Skip)

  172.31.0.0 ~ 172.31.255.255 범위에 해당하는 IPv4 주소는 pcx-11223344556677889으로 보낸다.

  pcx-는 피어링과 관련된 내용이고 2주차에서는 다루지 않습니다.

• 0.0.0.0/0

  모든 IPv4 트래픽은 igw-12345678901234567으로 보낸다.

  igw-는 인터넷 게이트웨이(IGW)의 약칭인 관리형 접두사입니다.

• ::/0

  모든 IPv6 트래픽은 eigw-aabbccddee1122334으로 보낸다.

  eigw-는 송신 전용 인터넷 게이트웨이(EIGW, Egress-only Internet Gateway)의 약칭인 관리형 접두사입니다. 2주차에서는 다루지 않습니다.

즉, 라우팅 테이블은 라우팅들이 정리된 표입니다.

라우팅 우선 순위(심화)

당연히 라우팅이 표 형태로 무분별하게 적혀있으므로 우선 순위가 결정이 되어야 합니다.

적절한 네트워크 대역폭, CIDR Block 선택하기(심화)

이런 우선 순위로 인해 네트워크 레벨의 버그가 일어나는 것을 최소화 하기 위해서, 사설 네트워크망(VPC)을 위해서 사용 가능한 IPv4 대역이 존재합니다.

RFC 1918, Address Allocation for Private Internets - section 3을 보면, 총 3개의 IP 주소 대역을 추천합니다.

1. 10.0.0.0/8

   범위 : 10.0.0.0 ~ 10.255.255.255
   숫자 : 16,777,216

2. 172.16.0.0/12

   범위 : 172.16.0.0 ~ 172.31.255.255
   숫자 : 1,048,576

3. 192.168.0.0/16

   범위 : 192.168.0.0 ~ 192.168.255.255
   숫자 : 65536

실제로 사용 중인 PC의 터미널(e.g. cmd)에서 ipconfig을 입력해보면, 시작 IPv4 / 서브넷 마스크 /기본 게이트웨이를 알 수 있습니다.

이를 통해 컴퓨터 내부에는 CIDR Block이 존재하고 인터넷 연결을 위한 IGW와 유사한 것이 존재함을 알 수 있습니다.

네트워크 주소 변환(NAT, Network Address Translation)

퍼블릭 인터넷과 서브넷 리소스를 상호 연결하기 위해서 인터넷 게이트웨이가 필요함을 알았습니다. 그리고 이 과정에서 네트워크 주소 변환이라는 단어가 나왔습니다.

설명의 편의를 위해서 대다수의 내용을 생략하고 “이해”에만 초점을 두겠습니다.
따라서 정확한 내용이 아니며, “개념 및 원리”정도만 이해하시길 바랍니다.

IP 계층의 통신은 기본적으로 출발지 IP(Source IP)와 목적지 IP(Destination IP)로 구성됩니다. 인터넷과 서버가 직접 연결되어 있다면 이런 흐름으로 요청과 응답을 주고 받을 것입니다. 네트워크 요청에 대한 응답은 출발지 IP와 목적지 IP가 뒤집혀서 발송하게 됩니다.

하지만 실제로는 퍼블릭 인터넷과 네트워크 리소스는 직접 연결되지 않습니다.
즉, 여러 단계를 거쳐서 통신하게 되고 적절한 네트워크 응답을 위해서 출발지 IP를 적절하게 변경해주어야 합니다. 이 과정을 네트워크 주소 변환(NAT, Network Address Translation)이라고 부릅니다.

네트워크 설계하기

최초에 VPC에 배포된 EC2의 기본 아키텍처에서 설명한 네트워크 설정은 말 그대로 기본적인 구조입니다.
프로덕션 레벨에서 사용 가능하게 VPC 3-Tier 아키텍처와 유사하게 아래와 같은 네트워크 구성을 완료했습니다.

• Region | us-east-1

• Availability Zone | us-east-1a / us-east-1c

• VPC CIDR Block| 192.168.0.0/16

• Subnets| 2ea Public Subnet / 2ea Private Subnet

  • Public Subnet(with IGW) | 192.168.xxx.xxx/22

  • Private Subnet(without IGW) | 192.168.xxx.xxx/21

• IGW |
  us-east-1a에 위치한 Public Subnet에 배포
  서버에 HTTPS 요청을 전달하기 위해서 인터넷 연결

• NAT |
  us-east-1a에 위치한 Private Subnet에 배포
  서버에서 라이브러리 설치를 위해서 인터넷 연결

• RTB | 2ea

  • Public Routing Table (with Public Subnet) | IGW으로 라우팅 연결
    서버에 HTTPS 요청을 전달하기 위해서 인터넷 연결

  • Private Routing Table (with Public Subnet) | NAT으로 라우팅 연결
    서버에서 라이브러리 설치를 위해서 인터넷 연결

컴퓨팅 리소스(Computing Resource)

2주차에 실습을 하기 위한 컴퓨팅 리소스를 이해하기 위한 절차를 총 N단계로 구성하였습니다.

해당 내용들을 여러 차례에 대해서 공부함으로써 컴퓨팅에 대한 이해도를 높이고 실습을 진행하셨으면 좋겠습니다.

목적

정적 웹 콘텐츠를 제공하기 위해서 1주차에 사용한 CloudFront, S3는 요청이 늘더라도 유연하게 대처할 수 있습니다. 또한 대다수의 사용에 서비스 장애가 발생하지 않습니다.

하지만 서버는 요청이 늘어나면 다운이 되며, CloudFront에 대해서 서비스 장애가 높은 빈도로 발생합니다.

단적으로 하나의 S3와 하나의 EC2의 장애 발생 가능 시간은 다음과 같이 큰 차이가 있습니다.

1. 하나의 S3 / 99.99% 가용성 : 8.6s의 장애 발생 가능

2. 하나의 EC2 / 99.5% 가용성 : 7m 12s의 장애 발생 가능

하나의 EC2에서 Next 서버를 운영하는 것은 안정적이지 않습니다. 이를 위해 여러 가지 이론 및 솔루션이 필요합니다. 이번 [컴퓨팅] 챕터에서는 해당 내용들을 학습할 예정입니다.

확장성, 가용성, 내구성 기본 개념

서버에서는 크게 3가지 개념을 다루고 있습니다.

1. 확장성(Scalability)

   변화하는 요청에 따라서 시스템이 자유롭게 크기 조정을 할 수 있는 능력

2. 가용성(Availability)
   시스템이 항상 응답 가능한 성태를 유지할 수 있는 지표
   가용성이 높을 수록, 서비스 전체가 다운되지 않음을 의미함

3. 내구성(Durability)
   데이터가 손실되지 않고 안전되게 저장되는 정도

S3와 EC2+EBS(gp2/gp3) 기본 사용 사례를 비교하면 다음과 같습니다.

1주차, 2주차 모두 S3 및 EBS를 데이터 저장으로 사용하지 않습니다.

자동 확장 및 가용성 부분에 따라서, EC2가 S3보다 훨씬 불안정함을 알 수 있습니다.

저희는 [컴퓨팅 리소스] 챕터를 통해서 이런 부분들을 보완해볼 예정입니다.

가용성 계산하는 법
사용하기를 원하는 AWS 리소스 이름 + SLA로 검색하면 됩니다.
EC2 SLA로 검색한 후에 사용하려는 사례의 가용성 %를 꼭 확인하세요.

해당 가용성이 얼마 만큼의 장애가 발생할 수 있는지를 확인하려면 SLA Calculator로 검색하여 수치를 확인해보세요.

EC2에 대한 이해

다시 AWS EC2를 검색해서 Amazon EC2의 기능 부분을 보면 처음 보는 내용들이 몇 개 나옵니다. 그 중에서 저희 실습 때, 사용하는 부분만 언급하겠습니다.

• 인스턴스 | 가상 서버를 의미

• AMI(Amazon Machine Images) | 서버 실행에 필요한 운영체제와 추가 프로그램을 포함한 인스턴스용 구성 탬플릿

• 인스턴스 타입 | CPU, vCPU, MEM, Storage, Networking or Graphics HW

  아래 내용을 포함하여 다양한 인스턴스 유형이 있습니다만.
  저희는 기본으로 제공되는 t2 패밀리와 그 다음 세대(성능이 개선된) t3 패밀리만을 사용하 것입니다.

  • AWS (Youtube) | AWS re:Invent 2020: Selecting the right Amazon EC2 instance for your workloads

  • AWS (Youtube) | AWS re:Invent 2021 - Selecting and optimizing Amazon EC2 instances

• 리전, 가용영역

  • us-east-1

  • us-east-1a, us-east-1c

• VPC, Subnet

  • [네트워크 챕터]에서 생성한 VPC 및 Private Subnet(us-east-1a)선택

• 보안 그룹

  • 아래의 두 트래픽에 대한 허용(Allow) 규칙을 선언

    • EC2 인스턴스에 들어오는 트래픽(인바운드 트래픽)

    • EC2 인스턴스에서 나오는 트래픽(아웃바운드 트래픽)

EBS에 대한 이해

앞서 말했듯 EC2는 컴퓨팅 리소스입니다.
따라서 필수 프로그램을 설치하기 위한 스토리지가 필요합니다.

AWS에서는 다양한 스토리지 리소스들이 존재하지만, 기본이 되는 EBS(Elastic Block Storage)를 사용하였습니다.

더 자세한 내용은 아래 동영상의 1분 50초대에 나오는 AWS EBS 설명을 참고해주세요.

• AWS (Youtube) | 모든 기업을 위한 AWS 스토리지 서비스 쉽게 알아보기 - 신석주, 솔루션즈 아키텍트, AWS

EC2의 가용성을 개선하는 방법

EC2는 특정한 가용 영역, 서브넷 내에 생성됩니다.

따라서 여러 개의 가용 영역에 배포하는 것으로 가용성 수치를 높일 수 있습니다.

이 경우, 여러 개의 서버에 요청을 분산하는 서비스가 필요합니다.

이를 로드 밸런싱이라고 하며 “AWS 로드밸런싱 서비스”라고 검색하시면 ELB를 발견하실 수 있습니다.

ELB(ALB, L7)

ELB는 다양한 로드 밸런서 유형을 제공하고 있습니다.

저희는 가장 범용적인 사례인 ALB(Application Load Balancer)를 선택할 것입니다.

ALB는 OSI 7계층 중 7계층인 어플리케이션 계층(Application Layer)에서 작동하는 로드밸런서입니다.

따라서 L7 계층에서 접근 가능한 데이터를 기준으로 부하 분산을 진행합니다.

오토 스케일링 그룹(ASG, Auto Scaling Group)

또한 EC2의 확장성을 보완하기 위해서 Auto Scaling Group을 사용하겠습니다.

결론

EC2는 S3에 비해서 확장성, 가용성이 부족합니다.

따라서 ASG와 함께 사용하여 확장성을 보완하여야 합니다.

또한 다양한 가용 영역에 대해서 선택하여 가용성을 보완하여야 합니다.

기타

위에서 기본적인 인프라 구성에 대해서 배웠습니다.

이에 추가적으로 배포 자동화 서비스를 써야 합니다.

CodeDeploy

AWS CodeDeploy 공식문서에 따르면, CodeDeploy는 다음과 같이 소개되고 있습니다.