20240728 TIL

✅ 오늘 배운 것

오늘은 멘토님과 멘토링하면서 CI/CD 자동배포 및 도메인 연결에 대해서 작업했다. 

오늘 다룰 것으로 예상되는 부분은 다음과 같다: 

1. ECS에서 EC2 컨테이너 실행

2. 실행한 EC2 컨테이너를 Route53 등을 이용해서 사전에 구매한 도메인 주소 할당

 

✅ 멘토링에서 배운 것

이전에 블로그에 올린 질문 관련

EBS, 그리고 이와 관련된 개념인 RAID (raid 0, 1, 5, 10 전략 & hotswap(빈 disk 하나 둬서 장애에 대비하는 전략))를 말씀해주셨다. EBS는 Elastic Block Store의 약자로, 찾아보니 EC2 인스턴스에 사용될 스토리지 볼륨을 제공해주는 서비스라고 한다. 그리고 RAID 중에서는 RAID 10 전략이 제일 많이 사용된다고 하셨다. 왜냐하면 데이터 스트라이핑(striping)과 미러링(mirroring)을 동시에 사용하는 전략이기 때문이다. 

 

참고로 데이터 스트라이핑과 미러링을 구성하려면 디스크가 최소 N(N>=2)개 이상 필요하다. 스트라이핑의 경우, RAID를 구성하는 모든 디스크에 데이터를 분할하여 저장하는 방식으로, 전체 디스크를 모두 동시에 사용하기 때문에 성능은 단일 디스크의 N배가 된다고 한다. 미러링은 이와는 다르게 모든 디스크에 데이터를 복제하여 기록한다. 그래서 우선은 디스크 1개에서 장애가 발생해도 데이터를 복구할 수 있다는 장점이 있으며, read 작업을 할 때 성능이 N배가 된다고 한다. 

 

RAID 전략 중에 가장 많이 사용하는 것은 RAID 10번 전략인데, 이는 4개의 디스크로 미러링과 스트라이핑을 동시에 하는 전략이다. 이렇게 하면 디스크가 1개 손상되어도 데이터를 복구할 수 있고, 또한 읽기나 쓰기의 성능도 2배가 되어서 많이 사용한다고 한다. 

 

IAM은 하나 혹은 여러 AWS 세부 서비스를 사용할 때 효과적으로 역할과 권한을 분리하기 위한 용도이다. 

ECS에서 EC2에 접근하는 게 아니었다. EC2에서 ECS에 접근하는 거였다!!

가장 많이 쓰는 EC2 스팟 인스턴스는 t3.micro이다. 이유는 가격이 싸기 때문. 그러므로 t2.micro 대신 t3.micro를 쓰자. (b/c 더 용량이 큰데 가격이 더 싸고, 여러 AWS 리전 중에서는 t3.micro 인스턴스가 있는 리전은 많은데 t2.micro 인스턴스는 리전에 따라 없는 곳도 있다. 이럴 경우 실행이 안 될 수 있기 때문에 t3.micro를 권하셨다.)

 

ECS 클러스터 네트워크 관련 내용

awsvpc로 하면 인스턴스와 컨테이너 모두가 각각 퍼블릭 ip를 할당받는다. 그래서 싼 인스턴스를 쓸 경우 하나의 인스턴스에 하나의 컨테이너밖에 올리지 못할 수 있다. 반면 bridge 모드를 쓰면 하나의 인스턴스에 여러 개의 컨테이너를 할당받을 수 있다. 반면 bridge 모드로 하면 컨테이너는 퍼블릭 ip를 할당받지는 않는다. bridge 모드는 이 인스턴스를 공유기처럼 쓰기 때문에 인스턴스 밖에서는 접근이 안 되고, 그래서 컨테이너를 띄울 때 항상 포트 번호를 지정하도록 한다. 

 

서버 지식 관련 내용

로드밸런서의 경우는 ELB, ALB 등의 관련 키워드가 있다. 로드밸런서의 역할이란 가령 가령 서버 인스턴스가 여러 개 떴을 경우, 여러 서버들에게 요청을 나눠서 보내주는, 말 그대로 서버들에게 가해지는 부하(로드)를 밸런싱해주는 역할을 한다. 

 

그 외에도 멘토링을 하면서 fargate가 아닌 EC2 인스턴스를 사용해서 ECS 클러스터에 등록하려고 했는데 여러 문제가 발생했다. 

 

가령 컨테이너의 용량이 인스턴스의 용량을 초과하는 문제도 있었다. 이 경우 EC2의 시작 템플릿에서 필요한 CPU의 개수와 메모리 용량을 기존에 3Gib로 되어 있었던 것을 400MB로 바꾸어서 해결하였다.

 

또한 오토스케일링 그룹에서 ec2 인스턴스를 1개만 띄우도록 기본으로 설정해 두었었는데, 알고보니 오토스케일링 그룹에서는 기본으로 롤링 업데이트 방식을 사용하고 있었다. 이 방식에서는 최소 2개 이상은 띄워져 있어야 서버가 시작할 수 있었다. 왜냐하면 서버를 기본적으로 2개 시작해 두고 1개를 kill 한 다음 나머지 1개만 정상 실행시켜 두고, 만약 잘 실행되고 있던 1개의 서버가 죽거나 업데이트를 해야 하는 상황이면 그때 나머지 1개를 실행시켜두는 방식이 롤링 업데이트 방식이었기 때문이다. 이것 역시 EC2의 오토스케일링 그룹에서 인스턴스의 개수를 1개에서 2개로 바꿔주니 해결되었다.

 

그리고 이 모든 상황은 cloudformation, autoscaling group 등의 로그를 통해 파악할 수 있었다. 나는 기존에는 cloudwatch를 통해서만 로그를 볼 수 있는 것인 줄 알고 cloudwatch에 로그가 안 떠서 어디를 찾아봐야하나 싶었는데, 알고보니 오토스케일링 그룹 관련 로그는 EC2>autoscaling group 부분에서 뜨고, cloudformation이라는 로그를 볼 수 있는 또 다른 서비스가 있었다. 정말 AWS의 세계는 알면 알수록 크고 심오한 것 같다...

---

삽질을 계속하다 문득 월요일부터는 잠시 뒤로 미뤄놓았던 프론트엔드 관련 이슈를 처리해야 한다는 판단이 들었다. 그래서 오늘 안으로는 ECS를 통해 인스턴스를 띄워야 하는데, 그러려면 EC2 옵션을 통해서는 오늘 안에 배포가 어려울 수도 있다고 생각했다. 그래서 fargate 옵션을 사용하기로 했다. 어차피 나중에 다시 바꾸면 되니까!

 

 

 

 

참고한 블로그

https://velog.io/@ghldjfldj/AWS-EBSAMISG

https://devocean.sk.com/blog/techBoardDetail.do?ID=163608