IAM
-
IAM이란??
유저와 그룹을 생성하여 AWS의 각 리소스에 대해 접근제어와 권한관리를 제공한다.
권한은 단순히 리소스의 전체권한을 부여하는 것이 아닌 세부권한(ex. Full, Delete, Read Only 등..)을 부여하여 각 유저에게 분명하게 필요한 것들만 줄 수 있다. -
IAM User vs Role
IAM User는 특정 그룹 혹은 인원에게 필요한 만큼의 권한을 부여받아 특정 리소스 및 콘솔에만 접근 할 수 있도록 제한한다.
IAM Role은 한 유저한테만 권한을 부여하는 것이 아닌, AWS 리소스(EC2) 혹은 다른 AWS계정 등 서비스블록으로 리소스 엑세스 권한을 부여하는 것이다. 예를 들어 여러 EC2중 하나만 S3에 접근하도록 권한을 부여하고 싶다면 Role을 만들어서 EC2에 부여할 수 있는 것이다.
(이해는 가지만, 직접 해본적이 없기 때문에 간단하게 한번 해볼 필요가 있다.)
언제 t2.micro에서 업데이트 해야 하는지??
EC2의 t2 인스턴스는 기본수준의 CPU성능을 넘어간 brust성능을 제공하는 Brustable 인스턴스이다.
순간 성능은 CPU 크레딧에 의해 달려있는데, CPU 크레딧은 Launch될때 기본 제공되고, 매 1시간마다 제공되어 적립된다. 마치 사람처럼 쉬는시간에 체력을 보충했다가 일하러 가는것과 유사하다. 이런 특징때문에 마이크로서비스, 소형 데이터베이스, 웹 서버에 유용하며 사용자의 방문이 일정하지 않은 서비스에 유용하다.
만약, 사용자가 예상 밖으로 많이 몰리는 경우에(ex. 특가할인 이벤트)는 Auto Scaling을 통해 어느정도 트래픽을 해결 할 수 있을 것이다. 하지만, 우리 서비스의 인기가 더욱 높아져서 지속적으로 유저가 유입되어 t2 크레딧 정책을 맞지 않아진다면 인스턴스를 업데이트를 해야할 것이다.
그때를 예상하고 어떤 인스턴스로 업데이트 해야할지는 전문가와 같이 상담하는게 최고겠지만(...) 내가 지금 생각할 수 있는 최선의 방법은 CloudWatch의 트래픽 및 CPU Usage 분석을 통해 인스턴스 타입 자체를 바꿀지, 성능만 업데이트 해야할지 고민해야 할 것 같다. 이를 위해선 오랜 로그가 필요할 것이다.
추가로, t2 크래딧 무제한 기능이 있는데, 이건 보지 못해서 내일 출근길에 한번 봐야겠다
(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html)
당장의 결론은 명확한 기준은 없고 트래픽에 관련된 데이터를 일정기간 동안 로깅해서 가격을 잘 따져봐서 업데이트 해야한다로...😢
Auto Scaling 뭐야?
Auto Scaling이란, 갑작스러운 트래픽이 증가하여 서버가 과부하 되는것을 방지하기 위해 등록한 트리거에 의해 EC2 인스턴스를 유연하게 Scale Out(생성), Scale In(제거) 하여 서비스를 확장하는 기능이다.
AWS Auto Scaling은 인스턴스의 개수 제한 및 Health Check를 할 수 있으며, 여러 그룹을 만들어서 아키텍처에 필요한 부분에 각기 다른 옵션으로 Scaling 할 수 있는 기능들을 제공한다. 또한, 다중 AZ 영역에서 EC2를 생성할 수 있어서 가용성도 높다.
보통 로드 밸런서와 함께 사용되며, ASG(Auto Scaling Group)은 확장된 EC2 인스턴스를 자동으로 로드 밸런서에 연결해준다.
ASG(Auto Scaling Group) 설정
Auto Scaling을 그룹화하여 만들 수 있기 때문에 여러 그룹을 만들어서 개별적으로 사용할 수 있다.
그룹 설정하기 이전에 생성될 EC2에 대한 옵션을 만들어어야 한다. 각 그룹들은 이 옵션을 기반으로 EC2를 만들기 때문이다.
EC2 생성 옵션은 EC2 인스턴스 생성과 동일하게, AMI 선택 (보통 배포될 서버 혹은 웹 어플리케이션 AMI를 만들어서 적용) 및 EC2 user data, Security Group 설정 등 옵션값들을 적용하여 만든다.
이렇게 만들어진 EC2 옵션값을 이용하여 ASG 정책을 설정하는데, 이 그룹 정책에서 실제 Scaling에 필요한 정책들을 설정한다.
그룹 사이즈(인스턴스의 개수 범위),
subnet AZ,
로드 밸런싱 여부,
Health Check,
Scale 트리거(With CloudWatch),
Notification 등
이렇게 설정한 그룹 정책들은 ASG가 실행되고 트리거에 의해 자동으로 실행된다.
AWS Console을 보면서 자세한 설명은 구글에 넘쳐나므로 패스!!
추가로 Stress 테스트를 완성 못했는데 완성해보자!!
Load Balancer가 트래픽을 자동으로 hold할 수 있는지 알아보라는 암묵적인 과제가 생겼다
S3
S3는 시간관계상 빠르게 지나갔다. 이전에도 React 어플리케이션 배포, 사진 데이터 관리때 사용해봤었기 때문에 조금은 익숙하긴 했다.
S3를 써야하는 이유는
1. 홈페이지에서 99.999999999%(ㄷㄷ)의 내구성을 제공하도록 설계되어 있다고 광고를 하며
2. 저장 용량이 상당히 저렴하고 (1GB에 $0.0023, EBS보다 저렴)
3. 자동 엔드포인트 생성
4. 메타데이터 관리 (메타데이터는 해당 데이터를 구분할 수 있는 정보)
5. EBS보다 더 나은 확장성
6. 정적 웹 서비스 제공 (React 어플리케이션 배포하는데 큰 도움이 되었었다)
7. 기타 (기억이 안남)
라고 말씀 해주셨다.
S3는 당장 우리 프로젝트에서 사용되진 않지만, 이후에 사용될 가능성이 S3의 내구성과 동일하기 때문에 강의를 통해 좀 더 알아보자!!
3-Tier Architecture
커스텀 VPC를 이용해 클라우드 상에서 개별적인 가상 네트워크를 구축하여 서비스들을 모듈화 하는 구조이다.
서브넷에 Public, Private으로 분리하여 각 서브넷에 서버, DB, LB를 나누고 IGW, RT, NAT RT까지 구축은 했는데, 통신이 안됬다 ㅠㅠ
아마 VPC를 명확하게 모르고 진행한 탓인것 같으며, 실제로 네트워크에 대해 잘 이해하고 있는 분들이 구축을 한다고 하니 좋은 경험이었다고 생각하고 나중에 기회가 됬을때 좀 더 공부해보자!!
마무리
머리속은 다 아는데 말로 표현하려니 역시 힘들다. 어디부터 어디까지 설명해야 하는지 감도 안왔고..
말로 표현을 못한다는건 제대로 알지 못하는 거라고 하던데, 다음주는 미리 간단하게 정리 하면서 채워나간후 발표해야겠다.
그리고 이것저것 찾아보면서 우리 프로젝트(모바일 - React Native)는 이번주 학습한것과 맞지 않다는걸 알았다.
실제로 모바일 벡엔드는 GCP Firebase Project, AWS amplify(AWS AppSync에서 업데이트)와 서버리스로 구축하는게 효과적이라고 하며, 실제 우리 프로젝트에서도 많은 데이터가 오가지 않기 때문에 해당 서비스들로 이전하는데 깊이 고민해봐야겠다.
