📚 배운 것
AWS Auto Scaling
호눅스 마스터 클래스에서 AWS의 Auto Scaling을 배웠다. 기억에 남는 내용을 정리하고자 한다.
스케일링의 종류 : 수평, 수직 확장
- 수평 확장 : AWS는 수평 확장만 제공한다.
- 수직 확장 : AWS 기본 제공되지 않는다. 하고 싶다면 직접 커스텀하여 CloudWatch 모니터링 스크립트를 작성해 사용할 수 있다.
왜 오토 스케일링이 중요하고 사용할까?
IT 회사의 서버 사용은 일정하지 않다. 회사마다 유형이 다르다. 클라우드 이전에는 자원을 효과적으로 사용하지 못했다. AWS 오토 스케일링 이후 사용자는 자유롭게 서버를 늘리고 줄일 수 있다.
Auto Scaling 구성 요소와 원리
Auto Scaling는 ELB(탄력적 로드 밸런싱) + CloudWatch(모니터링) 기술이 함께 작동한다.
CloudWatch의 모니터링 결과를 통해 서버를 늘리고 줄일 수 있다.
보통 하나의 ec2 평균 cpu 40% 이상되면 ec2를 늘린다.
ELB(Elastic Load Balancing)
- ELB는 리전 기반 서비스이다.
- 리전 서비스로 최상단에 있어 보이지만 사실 ELB 구현체는 각 AZ의 ec2로 구현되어 있다.
- 트래픽이 증가하면 AWS에서 ELB를 스스로 오토스케일링(증가시켜)하여 사용한다.
- ELB의 종류는 L4, L7이 있다. (최신 L7를 사용하도록 권장한다. 기능이 더 많다)
- AWS의 ACM 서비스를 사용해 무료 인증서 발급 및 연결이 가능하다. -> https를 손쉽게 사용할 수 있다.
-> 클라이언트가 서버 진입로는 ELB에서 받는다. 이를 https로 받는다. 이때 외부로 받는 https를 변환하여 내부에서는 http로 보내주는 기능이 있다. 이는 https의 's'를 디코딩하는데 부하를 줄일 수 있다. (한 마디로 외부에선 https로 받고 ELB가 이를 내부에서 사용할 땐 http로 바꾸는 기능이 있다.)
코드 스쿼드에서의 마지막 프로젝트
2022년 1월 3일 부터 시작한 코드스쿼드가 6월을 끝으로 마친다.
어느덧 마지막 프로젝트(3주)가 시작됐다. 시간이 정말 빠르다. 나는 6개월 동안 무엇을 했을까?
JK가 1월과 지금을 되돌아본다면 많은 성장이 있을 거라고 말해줬다. 6개월 과정을 되돌아 보려니 꽤 많은 시간이 걸릴 거 같아 다음으로 미루자. 오늘따라 유독 아쉬운 맘이 든다. 적적하고 슬프다. 이것도 마음이니 스~윽 느껴본다.
마지막 프로젝트는 github의 Issues와 유사한 웹 애플리케이션을 개발한다. FE 팀원은 비비, 럼카이다. BE는 혼자 하게 되었다. 코드스쿼드하며 처음으로 혼자하게 된 프로젝트다. 혼자도 좋지만 혼자는 싫기에(?) 근처에 있던 노리와 나단과 함께 요구사항 분석을 해보았다.
잡담을 시작으로 아이스 브레이킹을 하고 그라운드 룰 정하는 것은 익숙하다. 즐겁다.
events 기반 요구사항 분석은 잘하고 있는지 모르겠지만, 삽질 중이다.
마지막 즐겨보자.!
👍 Keep
- 팀원과 능동적으로 일 나누기(팀원 1: 저는 Issues 템플릿 만들게요. 팀원 2: 제가 Labels 만들게요. 팀원 3: 저 일 좀 시켜주세요. 뭐하죠?)
- 긍정적인 말하기 e.g. 오~ 깃 이모지 졸귀탱
🔥Problem
- 아침 10시부터 저녁 10시까지 집 밖을 나가지 않았다. 회고 작성 후 저녁에 산책 다녀와야겠다.!
🚒 Try
- 적어도 한 시간마다 자리에 일어나 스트레칭 필수
댓글