AWS 에서 웹 어플리케이션 배포하는 방법.

1. EC2
2. Elastic Beanstalk
3. ECS
4. EKS

이 중 그나마 간편하고, 빠르게 배포하는 방법은 1번 아니면 2번 일 것이다. 빠르게 웹 공유가 필요하여 간만에 Elastic Beanstalk 를 썼는데 완전 삽질스.

일단 2024년 10월 1일 이후로는, EC2 Auto Scaling 서비스의 시작 구성이 사라지고, 시작 템플릿으로 대체되기 때문에, EB 환경을 새로 생성한다면 시작 템플릿(launch template) 옵션을 선택해야 한다. 환경 설정 중 선택만 해주면 된다.

• RootVolumeType : gp3 (범용3 SSD)
• IMDSv1 : disable

와~ gp3 선택하지 않은 죄로 삽질 무지하게 했다.

Creating Auto Scaling launch configuration failed Reason: Resource handler returned message: "The Launch Configuration creation operation is not available in your account. Use launch templates to create configuration templates for your Auto Scaling groups. (Service: AutoScaling, Status Code: 400, Request ID: 67f0a370-3fa3-42f9-bfc1-4ebdc96b3378)" (RequestToken: e7362a93-5127-6af3-e9a5-90b793868367, HandlerErrorCode: GeneralServiceException)

CloudFormation 스택 템플릿에 보면 Launchconfiguration 이 구동되는지 Launchtemplate 이 구동되는지 확인할 수 있다. 어차피 에러나면 딱히 확인할 필요는 없지만...

간만에 EB 구동 정리나...

• 미리준비 : VPC / 서비스 역할 / EC 키페어 / EC2 인스턴스 프로파일
• 수동설정 : 루트볼륨유형 gp3 / 인스턴스 유형

EC2 인스턴스 프로파일 이란걸 썼었는지 기억도 안난다.

서비스 역할에 필요한 정책 (EC2, ELB, EC2 Auto Scaling API 호출에 필요)

• AWSElasticBeanstalkEnhancedHealth
• AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

EC2 인스턴스 프로파일 정책

• AWSElasticBeanstalkWebTier
• AWSElasticBeanstalkWorkerTier
• AWSElasticBeanstalkMulticontainerDocker

나머지 환경 속성이나 기타 등등은 구동 확인 후 수정 가능하다.

말 그대로 인스턴스를 미리 예약(구매)하는 것이다. 내가 사용할 인스턴스를 1년 이상 약정하고 그 만큼의 할인 혜택(최대75%)을 받는 것이다. 인스턴스 서비스를 제공하는 Amazon EC2, RDS, ElastiCache, OpenSearch, Redshift 등이 대상이다. 일단 인스턴스를 미리 생성해서 사용하다가, CPU/MEM 등이 적절한 인스턴스 사양을 찾아 최대한 빨리 RI 를 적용하는 것이 이득이다. 1년도 사용하지 않을 계획이라면 쳐다도 보지 않는 것이 좋다;

RI 설정

해당 서비스의 대시보드에 들어가면 좌측 메뉴에 예약 인스턴스(Reserved Instance), 예약 노드 등이 있는데 이곳에서 RI 를 생성하면 된다. 부수적인 옵션이 각각 있지만, 공통적으로 사용할 인스턴스 사양, 결제방법 등이 중요하다.

결제방법 (1년/3년)

• 선결제 없음 : 매달 할인 받은 금액으로 결제
• 부분 선결제 : 반 선결제 하고, 매달 할인 받은 금액 결제
• 전체 선결제 : 즉시 전체 결제하고 1년/3년 사용

전체 선결제는 즉시 결제이므로 3가지 결제방법 중 할인율이 가장 크다. 선결제 없음은 초기 비용이 발생하지 않지만 3가지 결제방법 중 할인율이 가장 적다. 1년/3년을 무조건 사용할 예정이라면 전체 선결제를 선택하면 되고, 그 안에 사양 업그레이드 등 변화가 예상되는 경우는 선결제 없음을 선택하는 것이 좋다. 사용하던 하지 않던 구매하는 순간 요금은 발생되므로 주의해야... 해당 RI 가 만료되면 온디맨드 요금으로 변경되므로, 수동 재계약. (예약 구매 가능)

EC2 RI 사용 예)

예1) 1일부터 c5.xlarge 를 이용해오다, 15일에 해당 서비스의 ri 를 구매할 경우
 - 적용시간부터 ri 요금이 적용된다.

예2) 1일부터 c5.xlarge 를 이용해오다, 15일에 c5.2xlarge 로 교체할 경우 (인스턴스 크기 유연성: 같은 리전의 정규화 시간당 유닛만큼 할인)
 - 15일부터 사용하는 c5.2xlarge(16) 의 요금중, 기존 사용중인 c5.xlarge 의 정규화 시간당 유닛(8)만큼 할인 받고, 나머지 c5.xlarge(8) 의 온디맨드 요금 발생

예3) RI 구매했지만 서비스를 그만 사용할 경우
 - Marketplace 에 등록하여 남은 사양만큼을 타인에게 판매.

표준 타입이 아닌 컨버터블 타입의 RI 를 사용한다면, 다른 인스턴스 패밀리(m, x, r...), 운영 체제 또는 테넌시를 변경할 수 있는 여러가지 옵션들이 있으며 다른 RI 와 병합도 가능하다. (비싼 요금에서 싼 요금으로의 변경은 불가능하다...) 컨버터블 타입의 경우, 요구조건이 까다로워서 AWS 문서를 확인하는 편이 확실할 듯 하다. EC2 가 아닌 다른 대부분의 다른 서비스 RI 는 수정/삭제가 불가능하므로, 마찬가지로 주의해서 생성해야 한다. RDS, ElastiCache, OpenSearch, Redshift...

요금 비교

권한이 있다면(ViewBilling,ViewAccount, ...), 비용(Cost) 대시보드에서는 최근 사용해 온 서비스 들로부터 RI 권장사항도 확인할 수 있다. 또는, 본인이 사용하는 서비스의 인스턴스 사양의 온디맨드 요금과 예약 인스턴스 요금을 구글에서 검색해 본다.

예) ec2 ri 요금

3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:

내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.

개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.

Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.

그랬더니 답변이 정말 개허접스럽게 왔다.

A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?

ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.

사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우  할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만... 

내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ

AWS 에서 VPC 마법사로 생성할 수 있는 VPC 시나리오로 다음의 4가지를 제공한다.

public 서브넷만 있는 VPC

public 및 private 서브넷이 있는 VPC

public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

private 서브넷만 있고 VPN 액세스를 제공하는 VPC

이 4가지의 VPC 구성을 알고나면 어떤 커스텀 VPC 구성도 가능하다. 하나씩 살펴보자.

1. public 서브넷만 있는 VPC

위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

ec2 : 10.0.0.6 (EIP: 198.51.100.2)

router : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

internet gateway

ec2 가 인터넷에 오픈되어 있는 웹서비스 등에 알맞는 구성이다. 서브넷은 모두 private 형태이므로 외부와의 통신이 가능하려면 internet gateway 를 두어야 하며, 나가는 트래픽에 대하여 routing table 에 올바르게 설정해야 한다. 10.0.0.0/16(local) 은 해당 vpc 의 다른 서브넷으로의 통신을 가능하게 하며, 0.0.0.0/0(igw-id) 는 외부 모든 트래픽은 igw-id 로 보낸다는 설정이다. 외부에서 해당 서비스(EC2 등) 에 접근할 수 있도록 Public IP 주소도 연결해야 한다. Public IP 주소가 없다면 외부로부터 요청을 받을 수가 없을 것이고, router 에 igw 로의 설정이 없다면 외부로 응답이나 요청을 할 수 없을 것이다. 보안적인 측면에서 보안그룹(security group) 과 network acl 로도 ip/port 에 대하여 허용/거부를 설정할 수 있는데 network acl 은 보통 다 열어놓고 보안그룹만 이용한다. 모든 포트가 차단된 상태에서 웹서비스시 80, 443 포트로 들어오는 요청은 모두 열어주고, 22 포트는 개발자 ip 정도만 열어주는 형태를 추천한다. 이것이 일반적인 public 서브넷의 형태이다. 

2. public 및 private 서브넷이 있는 VPC

위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(nat-gw-id)

internet gateway

nat gateway

프론트엔드와 백엔드로 나누어 일반적으로 웹서버만 public 서브넷에 두고 DB 는 private 서브넷에 두어, 외부에서는 웹서버와 접근 가능하게 하고 DB 는 웹서버에서만 접근 가능하게 하는 구성이다. 굳이 노출할 필요없는 백엔드를 외부와 차단시키는 것에 중점을 둔 구성이다. public/private 구분을 위해 igw(인터넷 게이트웨이) 로 향하지 않도록 router 를 하나 더 추가해야 한다. 옵션이지만 private 서브넷에서 일방적으로 외부와 통신을 해야 한다면 nat 게이트웨이를 생성하고 router 에 nat 게이트웨이로 트래픽을 보내도록 routing 을 추가한다. igw 가 public 서브넷과 외부와의 양방향 통신이 가능하게 한다면, nat 게이트웨이는 public 서브넷에 위치하면서 private 서브넷에 대하여 외부로 단방향 통신(요청/응답) 이 가능하게 하며 응답을 받을 수 있도록 public IP 할당이 필요하다. 외부에서는 여전히 nat 게이트웨이로 서브넷과 통신할 수 없다. (nat 게이트웨이는 유료) 웹서버의 보안그룹 설정은 시나리오1과 동일, DB 보안그룹 설정은 웹서버 보안그룹ID 로부터 오는 해당 DB 전용포트만 열어주면 된다. 예로 mysql 의 경우 3306 포트.

3. public 및 private 서브넷이 있고 VPN 액세스를 제공하는 VPC

위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

public subnet : 10.0.0.0/24

private subnet : 10.0.1.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

ec2(db) : 10.0.1.5~7

router1 : 10.0.0.0/16(local), 0.0.0.0/0(igw-id)

router2 : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

internet gateway

vpn (virtual private gateway, customer gateway)

시나리오2번과 비슷하지만 private subnet 을 외부는 여전히 차단하고 특정 네트워크(customer gateway)와만 통신할 수 있도록 하는 구성이다. vpn 이라고 하는 가상 비공개 네트워크를 구현하여 vpn 에 연결되어야만 private subnet 과의 통신이 가능하다. vpc 콘솔에서 private 서브넷과 연결할 네트워크(customer gateway) 를 ip 와 함께 지정하고 virtual private gateway 생성, 그리고 그 둘을 이어주는 Site-to-Site VPN 연결을 구성하면 된다. (vpn 도 역시 유료) 서브넷의 보안그룹 설정은 vpn 으로 연결되는 네트워크 ip 대역으로부터 필요한 포트만 열어주면 된다.

4. private 서브넷만 있고 VPN 액세스를 제공하는 VPC

위 그림에는 다음 정보가 포함된다.

vpc : 10.0.0.0/16

private subnet : 10.0.0.0/24

ec2(web) : 10.0.0.5~7 (EIP: 198.51.100.1~3)

router : 10.0.0.0/16(local), 0.0.0.0/0(vgw-id)

vpn (virtual private gateway, customer gateway)

시나리오3번에서 public 서브넷만 제외한 구성이다. public 서브넷이 없으므로 igw 도 없다. vpn 과 연결된 특정 네트워크에서만 private 서브넷과 통신이 가능하며, 외부가 차단된 구성이다보니 서비스보다는 사내 인트라넷이나 개발 서버 등이 필요할 때 사용 가능한 구성이다.

이 중에 그나마 유용하게 쓸 수 있는 것이 2번이나 3번 시나리오 이다. 내가 선호하는 구성은 소규모 웹서비스의 경우 2번과 흡사하게. 더 큰규모의 웹서비스는 3번 시나리오에서 public subnet 에는 elb 만 두고 모든 자원을 private 서브넷으로, private 서브넷은 vpn 연결로 관리하는 것이 즐겨 사용하는 시나리오 이다. ^^

Linux 상에서의 Minikube 도 설치 방법이 여러가지이다. 우선 하이퍼바이저 상에서 Minikube 를 구동할 것인지, 호스트에서 직접 구동할 것인지를 선택해야 한다. 하이퍼바이저를 이용한다면 리소스를 더 알뜰히 사용할 수 있겠지만, 모든 리눅스에서 하이퍼바이저를 사용할 수는 없다. Widnows 편에서 말했듯이 CPU 의 가상화(VT-x/AMD-v) 지원과 Bios 에서 가상화 활성화 상태를 확인해야 하는데, 요즘 많이들 사용하는 클라우드 컴퓨팅 서비스(EC2, GCE) 등에서는 대부분 HVM 가상화를 사용하고 있고, 그 자체가 이미 VM 이므로 그들은 Bios 에 접근을 할 수 없다. 결국 클라우드 컴퓨팅에서는 하이퍼바이저를 사용할 수 없으므로 과감히 VM 사용을 포기한다.ㅠ 현재 상황이 Linux 에서 VM 을 돌리기 위해 멀쩡한 PC 들에 Linux 를 까기는 좀;; 아무튼 현재 상황에서는 Linux 에서 VM 없이 호스트에서 Minikube 를 직접 구동시켜는 방법을 사용해야 하며, VM 없이 Minikube 를 시작하는 명령은...

 # minikube start --vm-driver=none 

하지만 EC2 Linux 에서도 minikube 를 정상적으로 구동하기 위해 체크해야 할 것들이 있다.

Minikube 구동시 체크사항

1. 2cpu, 2GB 메모리, 20GB 디스크 이상의 사양.
   EC2 에서 free-tier 인 t2.micro 는 1cpu, 1G 메모리로, minikube 를 구동할 수 없다. 최소 t2.medium 사양(2cpu, 4GB mem)이 필요하다.
   
   
2. docker 설치(Container Runtime)와 cgroup driver 매칭
   docker 가 반드시 필요하며(docker.io 나 docker-ce), 설치 후 docker info | grep -i cgroup 명령으로 cgroup driver 가 cgroupfs 인지 systemd 인지 확인해야 한다. minikube 구동 후에 kubelet 의 cgroup driver 와 일치하지 않는 다면 관련글을 참고하여 일치시킨다. VM 에서 구동시에는 docker 가 자동 설치되며 자동 매칭을 해준 부분이다.
   
   
3. 구동 실패시 클러스터 삭제
   minikube start 로 클러스터가 생성되다가 에러가 발생하면 캐싱으로 인해 에러가 반복될 수 있다. 다시 구동하기 전에는 minikube delete 명령으로 생성된 클러스터를 제거해 준다.

EC2 에서 발생할 수 있는 에러 메시지

- virtualbox 미설치 메시지

- 가상화 비활성화 메시지

- docker 미설치 메시지

- cgroup driver 불일치 메시지

EC2 (ubuntu) 에서 minikube 구동 성공