아마존 클라우드 AWS. 효율적인 설계를 위한 Architecting on AWS.
퍼블릭 클라우드 하면 Amazon, Google, Microsoft 이 세 회사가 떠오른다.
이 세 곳 중에 어느 클라우드가 좋을까 여러 글을 찾아보았다.
모두 장단점이 있지만, 결국 개발자 입장에서 제일 편한 AWS를 쓰기로 마음을 먹었다.
Microsoft의 azure는 말로는 다 쉽게 된다는데,
막상 실제로 하려면 참조 자료도 별로 없고 원하는 데로 되질 않는다.
구글 클라우드 플랫폼은 꽤 안정적으로 보이긴 하지만,
이미 너무 많은 구글 제품을 쓰고 있는 나는 좀 다른 걸 써 보고 싶었다.
사실 더 큰 이유는 구글 클라우드를 쓰기로 마음먹고 개발한 것이 아니므로
이대로 구글에 배포하면 구글에서 제공하는 좋은 자원을 제대로 활용하지 못하기 때문이다.
그래서 결정한 AWS.
좀 써보니 라이브러리도 잘 되어있고 마음에 든다.
그러나 글로만 배운 것은 한계가 있는 법.
춤을 직접 춰봐야 늘지 글로 배워봤자 얼마나 배우겠는가?
기술도 마찬가지로 직접 써봐야 익숙해지고 는다.
그래서 실습과 교육이 적절히 이루어진 Architecting on AWS교육을 듣게 되었다.
교육이 재미있고 지루할 틈 없이 지나가서 아주 만족스럽다.
분기별 한 번씩은 열릴 예정이라고 하니,
AWS에 관심을 가진 사람은 한번 들어볼 만하다.
Architecting on AWS 메모와 팁
보안
설계
- private subnet에서 밖으로 나갈 땐 Network address translation (NAT) 서버를 이용한다.
- 서버에 바로 접속을 허용하지 말고, Bastion 서버를 통과해서만 접속이 가능하도록 한다.
- EIP를 이용하는 것 보다 ELB를 이용하는편이 보안에 좋다.
권한
- 마스터 유저는 사용하지 말고, IAM(Identity and Access Management)를 이용해 각각의 권한을 지닌 사용자를 만들어 쓴다.
- 항상 권한을 가질 필요가 없다면, STS(Security Token Service)f를 이용해 사용자가 필요한 임시 권한을 주었다가 회수한다.
- 유저는 Role을 가지거나 User Group에 속해서 권한을 가지는 경우가 있는데, STS를 통해 Role을 지닌 유저 키를 받아오면 보안에 더 좋다.
좋은 클라우드 설계를 위한 안티패턴과 패턴
안티패턴/ 패턴
- 수동 프로세스 / 자동 프로세스
- 밀결합(Thightly-coupled) / 소결합(Loosely-coupled)
- 세션 사용(Stateful) / 세션 미사용 (Stateless)
- 수직적 확장 / 수평적 확장
자동 구성 도구(Bootstrapping)
- 스크립트 (Bash, 파워쉘)
- 구성관리 도구(Chef, Puppet)
- Amazon OpsWorks
- http://169.254.169.254/latest/meta-data/
AWS 제품 소개 / 팁
네트워크
Router 53
서버 부하가 많이 걸리면 DNS(Router 53)에 Round-robin 설정 후,동일 도메인 (예:dorajistyle.pe.kr)에 서브도메인(Record Type A)으로 각 서버의 ip를 설정한다.
www.dorajistyle.pe.kr은 CNAME타입으로 dorajistyle.pe.kr에 연결한다.
그러나 이 방법은 서버를 추가할 때마다 매번 설정을 변경해야 하는 불편함이 있다.
ELB를 사용하면 이런 불편함을 줄일 수 있다.
Router 53에는 Alias type이 있어서 value에 도메인을 넣으면 alias된다.
elb주소를 alias하려면 dorajistyle.pe.kr의 alias로 ELB주소를 붙인다.
ELB
ELB 참조 시, IP 어드레스를 절대로 사용하지 말고 A레코드를 항상 사용한다.CloudFront
약정 할인 되고, 유일하게 네고가 가능한 서비스다.월 10테라 이상이면 CloudFront가 S3보다 저렴하다.
정적(static) 컨텐츠 뿐 아니라 동적(dynamic) 컨텐츠도 캐쉬 가능하다.
그러나 동적 컨텐츠를 캐쉬하게 되면 비용적인 부담이 생길 수 있다.
스토리지
Amazon EBS
내구성이 필요하고 공유 가능한 스토리지를 원한다면 사용한다.Amazon RDS
데이터베이스DynamoDB
NoSQL 데이터베이스S3
Eventually Consistent기 때문에 수정 결과가 바로 반영되지 않을 수 있다.RRS(Reduced Redundancy Storage, RRS)
표준 스토리지보다 중복 수준을 낮추어 비용을 절감한다. 내구성 99.99%
S3는 Request당 과금하기 때문에, S3에 올리고, 그것을 가공해서 다시 S3에 올릴때도 비용이 발생한다.
한번의 Request에 여러 개의 파일을 묶어서 업로드가 가능하다.
배치
SNS
Http, Email, SMS, 모바일 푸쉬 등 여러 대상에 Push한다.SQS
단순 큐.큐에 있는 것을 처리하는 EC2서버는 ELB에 물려 있을 필요가 없다.
EC2서버가 항상 SQS 큐를 바라보기 때문에 큐 자체가 ELB역할을 하기 때문이다.
SWF
여러가지 작업을 실행할 때 여러개의 큐를 생성할 필요 없는 여러 작업의 워크플로우(BUS)순차적으로 이루어져야 하는 경우에 유리하다.
CloudFormation
현재 구성을 JSON형식으로 정의한다.다른 환경에서 같은 환경을 구축하려고 할 때 유용하다.
CloudInit
EC2 인스턴스를 생성할 때 userdata에 스크립트를 넣으면 첫번째 부팅시 사용자 데이터를 스크립트로 인식하여 실행한다.#!(리눅스)
<script> (윈도우)
AMI
Ami에서 aws cli로 s3에서 원하는 부분 복사가 가능하다.관리
CloudWatch
Metric 측정 도구이다.5분 단위로 측정은 무료, 1분 단위로 측정하면 인스턴스당 $3.5
커스텀 측정치는 측정치당 월 $0.50
CloudWatch
지정된 범위가 침해되면, 경보를 발생하여 지정된 액션을 실행한다.* SMS 통지
* 이메일 전송
* AutoScaling
* 인스턴스 정지
5분 주기면 무료이고, 1분 주기로 체크하면 과금이 된다.
Auto Scaling
보일러 온도 조절기를 생각하면 편하다.desired capacity : 초기에 띄울 인스턴스 갯수
min : 최소 인스턴스 갯수
max : 최대 인스턴스 갯수
AZ-a,b : 어느 존에 인스턴스를 띄을 것인가? (desired capacity/AZ 해서 각 AZ에 인스턴스를 띄워준다.)
서버 갯수가 고정인 경우라도 Auto Scaling을 쓰면 안정성이 향상된다.
(예 : desired capacity = 1 max = 1 AZ-a,b)
어플리케이션 서버에 문제가 생기면 자동으로 새로 띄워준다.
AZ에 문제 발생시 문제가 없는 AZ에 인스턴스를 띄워준다.
사람이 직접 실행하거나, CloudWatch알람을 걸어서 자동으로 실행할 수 있다.
예)
인스턴스가 가동하기까지 준비시간이 필요하므로, 스케일 아웃은 미리 하고, 스케일 인은 보수적으로 한다.
인스턴스가 생성되면 기본 한시간 비용은 나오기 때문에, 스케일 아웃과 스케일 인이 너무 빈번하게 일어나면 좋지 않다.
트리거: CPULoad
측정치 (M) : 평균 CPU사용량
5분간 M > 80% 이면 스케일 아웃
20분간 M < 40% 이면 스케일 인
오토 스케일링 시나리오
Service - EC2 선택ELB 생성 TCP프로토콜 + 80 포트, Health Check Interval은 적절한 값(예: 0.1)으로 설정한다.
Launch Configuration 생성
Security Group에 HTPP Rule을 추가한다.
Auto Scailing Group 생성
서브넷은 1개 이상 추가한다.
설정에서 Receive traffic from Elastic Load Balancer(s)에서 로드 발란서를 선택한다.
Keep this group at its initial size에 체크하고 생성한다.
인스턴스에 우클릭해서 오토 스케일링으로 생성된 인스턴스에 태그 부여.
설정 버튼에서 aws:autoscaling:groupName을 선택한다.
SNS토픽을 생성 한다.
E-mail Subscription을 생성한다.
Auto Scaling 연동 설정한다.
CloudWatch로 CPU Alert 생성한다.
Create Alarm > AutoScaling 검색 > CPUUtilization
Define Alarm Threshold 를 잘 설정한다.
(예) 부하가 50이상일 때 >= 50)
Auto Scaling Policy를 생성 생성한다.
해당 알림에 따라 실행할 동작 지정한다.
비용
네트웍 비용은 나가는 것을 기준으로 한다.On-demand instances 소매가
Reserved instances 약정할인 (선납금을 조금 내고 조금 할인 받거나, 많이 내고 많이 할인 받는다.
Spot instances 남는 인스턴스를 경매 방식으로 구입해서 사용한다. (가격변동이 있다.) 경매에 지면 자동으로 꺼진다.
일반적인 백그라운드 프로세싱에 사용한다.
하나의 ELB에 여러개의 ASG(Autoscaling Group)을 붙일 수 있다. 예를 들면 하나는 온디멘드, 다른 하나는 스팟 인스턴스 그룹으로 만들어 두면 하이브리드 구성이 가능하다.
링크
아키텍팅
http://aws.amazon.com/ko/architecture/http://prezi.com/cxpwi_og7lht/aws-regions-and-availability-zones/
http://translate.google.com/translate?hl=ko&sl=ja&tl=ko&u=http%3A%2F%2Faws.clouddesignpattern.org%2Findex.php%2F%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
보안
http://blogs.aws.amazon.com/securityAWS Elastic Beanstalk
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.platforms.htmlhttp://docs.aws.amazon.com/elasticbeanstalk/latest/dg/createdeployPythoncustomcontainer.html
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers.html
최적의 비용 계산기(기술지원 신청하면 사용 가능)
http://aws.amazon.com/support/trustedadvisorby 月風
