AWS - EC2

date

Aug 10, 2023

slug

ec2-1

author

status

Public

EC2 (Elastic Compute Cloud)

클라우드 공간에 크기가 유연하게 변경되는 가상 서버 기능을 제공합니다.

인스턴스라고도 불리우며 클라우드 공간에 가상 서버를 만들어 AWS에서 제공하는 다양한 애플리케이션을 돌릴 수 있습니다.

네트워크 트래픽 상황에 맞게 자동으로 몸통을 부풀렸다 줄였다 유연하게 대처합니다.

가상 서버이기 때문에 디스크 용량뿐 아니라 CPU, 메모리 및 네트워크 등 다양한 설정이 있습니다.

우리가 사용하는 컴퓨터나 랩톱과 마찬가지로 여러 가지 설정을 상황에 맞게 설정해줘야 합니다.

초기 개발 단계에는 프리티어 옵션을 많이 사용합니다. - 공짜 리소스 사용하는 대신 최저 사양 환경에서 개발을 진행하는 것입니다. EC2는 인스턴스가 실행되고 있을 때만 돈을 지불합니다.

돈을 지불하는 방법에는 여러 가지가 존재합니다.

온디맨드

시간당 정해진 금액을 지불하면서 사용합니다.(가장 짧은 시간은 60초)

소프트웨어 검증 및 테스트 단계에서 많이 사용됩니다.

짧고 불규칙한 주기 내에서 테스트가 이루어질 때 사용하면 좋습니다.

온디맨드 지불 방식은 유연성이 있어 이러한 불확실한 상황에 사용하기 좋습니다.

개발 기간이 비교적 짧으며, 개발이 끝나는 시간을 미리 알 수 없을 때 유용합니다. 사용하는 만큼 돈을 지불하기 때문에 개발 초기 단계(EC2인스턴스에서 애플리케이션을 처음 테스트 할 때)에서 사용하는 것이 이상적입니다.

리저브드

저렴한 비용으로 인스턴스를 사용할 수 있게 합니다. 1-3년 정도 싸게 임대해 사용할 수 있게 해주는 지불 방식입니다.

개발 시작과 끝을 미리 알고 있을 때 유용합니다. 선불로 비용을 부담하여 추가적으로 지정된 컴퓨팅 시스템을 사용할 수 있습니다. 개발 중에 요구 조건이 자주 변경되지 않고 개발 시간을 잘 알고 있다면 리저브드 지불 방식 사용을 권장합니다. 리저브드의 단점은 온디맨드와 달리 인스턴스의 크기를 늘리거나 줄일 수 없습니다.

인스턴스를 처음 생성할 때 지정했던 크기 및 설정을 그대로 가지고 사용해야 합니다.

리저브드 지불 방식은 비용 측면에서 큰 장점을 가지고 있기 때문에 많은 사람이 선호합니다.

스팟

인스턴스 가격을 입찰하여 구매할 수 있는 독특한 개념입니다.

리저브드보다 훨씬 할인율이 높으며 돈을 거의 들이지 않고 인스턴스를 구축할 수 있습니다.

그러나 이런 스팟 지불 방식에도 단점은 있습니다.

EC2인스턴스는 AWS 클라우드 시장 경제를 따르기에 인스턴스 사용 비용에 변덕이 생길 수 있습니다.

우리가 입찰가에 내놓은 금액과 맞아떨어진다면 인스턴스가 실행되고, 그렇지 않다면 인스턴스가 꺼지게 됩니다.

스팟 지불 방식은 인스턴스의 시작과 끝이 그다지 중요하지 않다고 판단되는 곳에서 매우 유용하게 쓸 수 있습니다.

EBS

EC2의 스토리지

파일 및 오브젝트를 보관할 수 있는 스토리지 볼륨을 만들어줍니다.

EC2인스턴스에 부착되어 사용됩니다. EBS가 없다면 EC2는 아무것도 할 수 없습니다.

EC2에 부착된 EBS 디스크 볼륨에 파일 시스템이 생성됩니다. 이를 통해 인스턴스에 접근할 수 있을 뿐 아니라 로컬 디스크에 파일을 옮기는 작업도 가능하게 됩니다.

EC2 인스턴스가 종료되어도 EBS안에 들어있는 데이터는 여전히 존재합니다.

EBS는 가용 영역을 설정해줘야 합니다. AWS를 사용할 때 리전으로 리소스가 분리되어 있습니다. 그 리전 안에서 가용 영역으로 범위를 또 나누게 됩니다. 특히 EC2인스턴스같이 서버 혹은 네트워크를 다룰 때 가용 영역이라는 개념이 종종 등장합니다. 그러므로 EC2를 더 깊게 다루기에 앞서 가용영역을 이해해야 합니다.

가용영역

하나의 리전 안에는 여러 개의 가용 영역이 존재할 수 있습니다.

우리가 사용하고 있는 지역을 서울이라고 가정했을 때 그 안을 리전A, 리전B로 세분화할 수 있습니다.

가용영역은 메인 서버에서 만들어지는 일종의 복사본이라고 이해하면 됩니다.

왜 존을 따로 나눠 사용해야 할까요? - 재해 복구 때문입니다.

나머지 가용역역으로부터 백업을 받아 인스턴스가 돌아가는데 지장이 없게 해주는 것입니다.

EBS타입

EBS볼륨 타입은 SSD와 HHD 두 가지로 나뉩니다. 각각의 볼륨 타입은 다른 퍼포먼스 성능 그리고 그에 따른 비용이 다르게 책정됩니다.

SSD

빈번한 읽기/쓰기, 입출력의 비중이 매우 클 때 사용되면 좋을 EBS볼륨 타입입니다.

SSD는 General Purpose SSD와 Provisioned IOPS SSD 두 가지로 나뉩니다.

Magnetic / HDD

SSD는 IOPS가 주된 관심사였다면 HDD는 처리량을 따져야 합니다.

따라서 방대한 스트리밍 워크로드를 신경 써야 한다면 HDD는 탁월한 선택입니다.

Throughput Optimized HDD(st1) 빅데이터 데이터 웨어하우스, 로그 프로세싱처럼 실시간으로 대용량의 데이터를 처리할 때 주로 사용됨. 부트 볼륨으로 사용할 수 없는 것이 치명적인 단점

CDD HDD 파일 서버 처럼 input/Output이 매우 드문 경우 사용됨. st1과 마찬가지로 부트 볼륨으로 사용할 수 없으나 가격이 매우 저렴한 것이 장점

Magnetic 디스크 용량당 가장 싼 비용으로 사용할 수 있음. st1, sc1과는 달리 HDD군에서 부트 볼륨으로 사용할 수 있음. 앞서 언급했듯이 가격이 싸기 때문에 비용을 따져야 할 때 고려 되는 옵션

ELB

서버를 다루다 보면 네트워크 트래픽이 한쪽으로 심하게 몰려 서버 다운이나 예상치 못한 문제가 발생합니다.

EC2는 ELB를 사용하여 서버 트래픽을 원할하게 해줍니다.

서버의 과부하를 책임지는 ELB

들어오는 양에 비해 나가는 양이 급격히 감소되는 병목 현상 발생시 데이터 양은 많으나 처리 양에는 한계가 있다.

서버에 장애가 발생해 다운 현상 까지 이르게 될 수 있는데 이를 방지하기 위해 등장한 개념이 ELB입니다.

ELB는 무언가를 균형 있게 잡아준다는 의미입니다. ELB는 서버의 흐름을 어느 한쪽으로 치우치지 않고 인스턴스에 공평하게 배분하도록 합니다. 결국 앞서 언급한 병목 현상을 방지하게 합니다. 이는 서버의 원할한 작동 및 빠른 속도를 유지할 수 있게 해주는 원동력이 됩니다.

EC2를 논할 때 인스턴스의 건강 상태를 따져야 하는데 건강하지 않은 인스턴스는 병목 현상이 종종 일어나 서버 과부하로 문제가 발생합니다. 이러한 인스턴스는 갑작스러운 셧다운이나 타임아웃 에러가 생길 수 있습니다.

이는 서버를 운영하는 엔지니어나 프로그램을 사용하는 사람들에게도 문제를 안겨주게 됩니다.

ELB는 건강하지 않은 인스턴스를 건강하게 해주는 의사 역할을 한다!

다양한 ELB 타입

어떤 상황에서 어떤 ELB타입을 사용해야 하는지 이해하는 것은 실제 애플리케이션 구현뿐 아니라 AWS 자격증 시험을 준비하는 분도 꼭 숙지해야 하는 내용입니다.

애플리케이션 로드 밸런서(ALB)

네트워크 일곱 번째 OSI 레이어에서 작동됩니다.

네트워크에는 총 일곱 개의 레이어가 존재하고, 각각의 레이어가 서로 소통하며 네트워크 흐름이 형성됩니다. 일곱 번째 레이어는 유저와 가장 가까이 위치한 애플리케이션 레이어 이며 이 레이어에 ALB가 존재합니다. 이는 HTTP, HTTPS와 같은 네트워크 트래픽을 제어할 때 적합한 밸런서가 됩니다.

ALB가 네트워크 요청을 받게 되면 EC2인스턴스에 지정된 역할에 근거해 데이터의 흐름을 관리하는 것입니다.

ALB의 중요한 기능은 고급 설정을 통해 원하는 서버로 직접 라우팅할 수 있습니다.

ALB는 인스턴스에 서버 흐름을 디폴트로 배분하는 대신 개발자가 직접 개입해 서버 흐름을 설정할 수 있도록 하는 라우팅 커스터마이징 기능을 제공합니다.

네트워크 로드 밸런서

OSI 일곱 번재 레이어에서 작동했던 ALB와는 달리 네트워크 로드 밸런서는 Transport Layer인 네 번째 레이어에서 작동합니다. 참고로 Transport Layer는 TCP/IP모델을 포함하고 있으며 상당히 안정적으로 호스트에 메시지를 전달하는 기능을 수행합니다. TCP 트래픽을 관리하기 때문에 초당 수백만 개 혹은 그 이상의 요청이 들어올 수 있으며 NLB는 극도의 퍼포먼스를 자랑해 미세한 지연으로 엄청한 요청들을 처리할 때 유용하게 사용됩니다.

주로 개발 환경이 아닌 프로덕션 환경에서 방대한 데이터 처리시 빛을 발휘합니다.

클래식 로드 밸런서

앞서 언급한 두 ELB보다 성능이 뒤처지고 거의 사용되지 않는 레거시 입니다.

기능은 흥미로우니 짚고 넘어가겠습니다.

레거시임에도 다른 ELB보다 시험에 가장 자주 등장합니다.

ALB에서 제공하는 레어이7의 HTTP/HTTPS 라우팅 기능, NLB에서 제공하는 TCP 트래픽 요청 라우팅 기능은 모두 CLB로 처리가 가능합니다.

치명적인 단점이 있으니, 요청과 네트워크의 연결에 근거해 서버 트래픽을 제어할 수 있으나 네트워크 호스트가 누구인지 알 수 없습니다. 믿어도 되는 호스트인지 아닌지, 안전한 연결을 해도 되는지 아닌지에 대한 판단을 할 수 없습니다.

ELB에서 흔히 일어날 수 있는 에러

애플리케이션이나 서버에서 특정 시간 내에 응답을 받지 못할 경우 생기는 Load Balancer Error: 504 error입니다. 이 에러가 그 유명한 Gateway Time Out 입니다. ELB를 사용해 네트워크 흐름 원할하게 함에도 왜 타임아웃 에러가 발생할까요?

이 문제는 서버 레이어, 데이터베이스 레이어에서 발생하기에 상대적으로 쉽게 해결할 수 있습니다.

로드 밸런서에는 최대 접속 시간 제한이라는 설정이 있는데, 기본값은 60초로 지정되어 이씅며 로드 밸런서가 60초동안 아무런 데이터도 전달받지 못할 경우 연결을 자동으로 종료하고 타임아웃 에러를 생성합니다.

현재 돌아가는 애플리케이션의 규모가 크다면 최대 접속 시간 제한을 한 번 변경해보세요. 로드 밸런서가 기다려줄 수 있는 시간을 조금이라도 늘리는 것입니다.

그렇지 않다면 직접 애플리케이션을 수정해서 서버로 전송되는 데이터의 양을 조정하거나 서버에서의 응답 시간을 최적화시켜야 합니다.

X-Forwarded-For 헤더

자격증 시험 준비시 숙지해야 할 내용.

이 헤더는 HTTP/HTTPS 요청을 로드밸런서에서 받을 때 출처에 대한 정보를 담고 있습니다.

로드 밸런서 public IP address가 152.12.3.225라고 가정해봅니다.

이는 중간 DNS 요청에 의해 로드밸런서에 보내지며 앞서 받은 퍼블릭 IP 주소를 10.0.0.23 private IP address로 인식합니다. private IP address에 대한 정보를 최종적으로 EC2인스턴스에 보내지게 되는데 안타깝게도 EC2인스턴스는 private IP address밖에 이해할 수 없습니다. 그리고 private IP address에는 출처에 대한 정보가 들어있지 않습니다. 그러므로 이를 알기 위해 X-Forwarded-For헤더를 통해 기존 public IP address를 찾을 수 있습니다. 152.12.3.225는 10.0.0.23의 헤더 정보를 가지고 알아낼 수 있습니다.