2016년 1월 7일 AWS Cloud행사에서 양승도 솔루션즈 아키텍트 께서 발표하신 “고급 클라우드 아키텍처 방법론 “ 발표자료입니다.

1. 클라우드 아키텍처 방법론
양승도 | 솔루션즈 아키텍트

2. I need your help !
원활한 세션 진행을 위해서
QR Code 스캐너 앱을 설치해 주세요!

4. AWS Well Architected Framework

5. http://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf

6. Agenda
Well Architected 프레임워크?
일반적인 디자인 원칙
Well Architected 프레임워크의 4가지 영역
보안
안정성
성능 효율성
비용 최적화
고객사 예
부록 : 클라우드 애플리케이션 디자인 원칙

7. Well Architected 프레임워크
Reliability (안정성)
- 장애 복구 능력
- 자원 동적 할당
- 오류 회피
Performance (성능)
- 자원의 효율적인 사용
- 비지니스 요구에 능동적 대응
- 신기술을 통한 효율성
Cost Optimization (비용)
- 비용의 투명성
- 불필요한 비용 요소 제거
- 관리형 서비스를 통한 최적화
Security (보안)
- 위험요소 제거
- 대응 전략
- 데이터/자산을 안전하게 보호
4 가지 영역
아키텍처에 대한 모범사례 및 지침을 고객들과 공유하기 위한 방법론

8. 일반적인 디자인 원칙

9. 디자인 원칙 #1
필요한 용량을 “추측” 하지 마십시오.
§ 시스템 용량을 과도하게 산정하여 자원을
낭비
§ 시스템 용량이 부족하여 성능 문제 발생
§ 필요한 만큼의 자원을 할당
§ 업무량의 변화에 따라 능동적으로 대응

10. 디자인 원칙 #2
프로덕션 시스템 스케일로 테스트 시스템을 구성하십시오.
§ 프로덕션과 동일한 테스트 환경을 구성하
는 것은 거의 불가능
§ 그로인해, 필요한 수준의 테스트 부족
§ 프로덕션과 동일한 테스트 환경을 빠르게
구축
§ 테스트 후 빠르게 제거
§ 사용한 시간에 대한 비용 지불

11. 디자인 원칙 #3
아키텍처 변경에 대한 위험(Risk)을 낮추십시오.
§ 제한된 테스트 환경
§ 여러 팀이 테스트 환경 공유
§ 충분한 테스트 불가능
§ 테스트 환경 구축 자동화
§ 팀별 별도의 테스트 환경
§ 충분한 테스트를 통한 잠재적인 문제요소
제거

12. 디자인 원칙 #4
아키텍처에 대한 변경/실험을 자동화 하십시오.
§ 변경에 대한 이력관리 힘듬
§ 성능 및 문제에 대한 분석 어려움
§ 아키텍처에 대한 배포 자동화
§ 쉬운 아키텍처 복제

13. 디자인 원칙 #5
지속적으로 아키텍처를 개선하십시오.
§ 지속적인 아키텍처 개선 어려움
§ 변경에 따른 Risk
§ 지속적인 실험
§ 새로운 기술 도입
§ 아키텍처 개선

14. Well Architected 프레임워크의 4가지 영역
§ 보안 (Security) : AWS 클라우드 상의 데이터 및 자산을 보호
하기 위한 best practice 가 적용되어 있습니까?
§ 안정성 (Reliability) : 시스템 아키텍쳐가 장애 복구, 업무 증
가 및 유사시 피해를 최소화 할 수 있습니까?
§ 성능 효율화 (Performance Efficiency) : 시스템 리소스
들이 최적의 성능을 낼 수 있도록 설계되어 있습니까?
§ 비용 최적화 (Cost Optimization) : 비지니스 업무를 수
행함에 있어 비용을 줄일 수 있는 방법들에 대한 고려가 이루어
지고 있습니까?

15. 보안

16. 보안 영역 – 디자인 원칙
§ 모든 영역에 보안을 적용
인프라 전체에 적용되는 방화벽보다는, 각각의 리소스에 대한 방화벽 사용 및 보안 제어를 설
정. (모든 가상 머신, 로드 밸런서, 네트웍 서브넷)
§ 추적 로그를 수집
모든 활동과 변경 사항들에 대한 로그를 수집하여 감시.
§ 보안 이벤트에 대한 대처를 자동화
지속적인 모니터링을 수행하고, 이벤트 혹은 조건에 따른 대처를 자동화.
§ 클라우드 상에서 수행되고 있는 시스템의 보호에 집중
AWS의 공유 보안 모델에 따라, AWS는 인프라 및 서비스에 대한 보안을 제공. 고객은 AWS에
서 운영되고 있는 어플리케이션, 데이터 및 운영 체제의 보안에 집중.
§ 보안에 대한 best practice를 자동화
최적화된 이미지들을 사용하고, 전체 인프라를 템플릿을 통하여 관리.

17. 보안 영역 - 정의
§ 데이터 보호 (Data Protection)
§ 권한 관리 (Privilege Management)
§ 인프라 보호 (Infrastructure Protection)
§ 감시 제어 (Detective Controls)

20. 보안 영역 – 주요 서비스
§ 데이터 보호
§ 전송 및 보관시 암호화 : ELB, EBS, S3 및 RDS
§ 암호화 키 생성 및 관리 : KMS(AWS Key Management Service) , AWS CloudHSM
§ 권한 관리
§ 사용자/권한 관리 : IAM
§ 인증 강화 : MFA(Multi Factor Authentication)
§ 인프라 보호
§ 논리적으로 격리된 네트워크 : VPC
§ 감시 제어
§ API 호출 기록 : AWS Cloudtrail
§ 인벤토리 변경 이력 관리 : AWS Config
§ 자원 모니터링 : Amazon CloudWatch
§ 로그 수집 : ELB, S3, CloudFront, VPC Flow Logs

21. 안정성

22. 안정성 영역 – 디자인 원칙
§ 복구 절차를 테스트
다양한 형태의 장애상황을 만들고 복구하는 시나리오를 자동화하여 복구시 문제를 미리 파악
하여 대처.
§ 문제 발생시 자동으로 복구될 수 있도록 구성
중요 요소들에 대한 모니터링을 수행하여, 임계치에 도달하였을 때 자동으로 필요한 절차를 수
행하도록 시스템을 구성. 이를 통해 장애에 대한 감지, 추적, 조치 뿐만 아니라 더 나아가서 장
애를 사전에 예방.
§ 시스템의 가용성을 높이기 위하여 수평 확장이 가능하도록 구성
하나의 큰 자원을 사용하는 것보다, 여러 개의 작은 자원들을 사용하는 것이 장애 발생시 피해
를 최소화. 이 때, 여러 개의 작은 자원들은 공통된 장애 요소를 가지고 있지 않도록 구성.
§ 필요한 용량을 추측하지 마십시오
시스템의 용량을 초과하는 부하가 유입되는 경우 (종종 DDoS의 목적)에도 자원의 고갈로 인
해 문제가 발생하지 않도록 동적으로 구성.

23. 안정성 영역 - 정의
§ 기본 요건 (Foundation)
§ 변경 관리 (Change Management)
§ 장애 관리 (Failure Management)

26. 안정성 영역 – 주요 서비스
§ 기본 요건
§ AWS IAM을 통하여 AWS 서비스 및 자원들에 대한 접근을 제어
§ Amazon VPC를 통해서 AWS 서비스 및 자원들을 독립된 네트웍 공간에 안전하게 운영
§ Service limit 관리
§ 변경 관리
§ AWS CloudTrail을 통하여 AWS의 API 호출에 대한 기록을 보관
§ AWS Config를 통하여 AWS 자원 및 구성에 대한 인벤토리를 관리
§ 지속적으로 구성 변경을 관리
§ 장애 관리
§ AWS CloudFormation을 사용하여 원하는 AWS 자원들을 자동 생성하는 템플릿을 구성
§ Auto Recovery 기능을 통한 자동 복구 설정
§ Auto Scaling Group을 활용하여 Self Healing 설정

27. 성능 효율화

28. 성능 효율화 영역 – 디자인 원칙
§ 최신 기술을 쉽게 사용
구현하기 어려운 최신 기술도 클라우드에서는 쉽게 사용할 수 있음. IT 팀이 새로운 인프라 기
술을 익히기보다는 서비스 형태로 사용하는 것이 유리. NoSQL 데이터베이스나 미디어 트랜스
코딩, 머신러닝과 같은 전문성이 필요한 기술도 클라우드 서비스 형태로 제공.
§ 세계 시장으로 빠르게 진출
여러 리전에 서비스를 배포하여 고객에게 최소의 비용으로 최고 품질의 서비스를 제공.
§ 서버 없는 아키텍쳐를 사용
클라우드에서는 서버운영 부담 없이 서버리스(Serverless) 아키텍쳐를 손쉽게 구성할 수 있고,
이를 통하여 서버 운영의 부담을 줄이고 사용량 또한 줄일 수 있음.
§ 더 자주 새로운 아이디어를 실험
가상화되고 자동화된 자원들을 통해 여러 종류의 인스턴스, 스토리지, 구성을 사용하여 빠르게
실험을 진행할 수 있음.

29. 성능 효율화 영역 - 정의
§ 컴퓨트 (Compute)
§ 스토리지 (Storage)
§ 데이터베이스 (Database)
§ 용량-시간의 Trade-off

32. 성능 효율화 영역 – 주요 서비스
§ 컴퓨트
§ 오토 스케일링 등의 방법을 사용하여 수요에 맞는 인스턴스 갯수를 유지하도록 관리
§ 스토리지
§ Amazon EBS : Magnetic, General Purpose SSD, PIOPS SSD
§ Amazon S3 : S3, S3-IA, Glacier 그리고 RRS(reduced-redundancy storage) 및 라이프사
이클 관리 기능 사용
§ 서버 없이 컨텐츠를 전송할 수 있는 기능을 통하여 성능이 유지되도록 관리
§ 데이터베이스
§ 관리형 데이터베이스 서비스 : Amazon RDS, Amazon DynamoDB, Amazon Redshift,
Amazon ElastiCache
§ Amazon RDS는 다양한 기능(PIOPS, 읽기 복제본)을 제공하여 성능을 최적화
§ 용량-시간의 트레이드오프
§ AWS Region, CloudFront 등을 활용
§ 제약이 없는, 많은 용량을 사용하여 프로세싱 시간을 절약

33. 비용 최적화

34. 비용 최적화 영역 – 디자인 원칙
§ 비용을 업무/부서별로 투명하게
§ 클라우드를 통하여 IT 비용을 개별 업무/부서별로 쉽게 나눌 수 있음. 보다 정교하게 투자 회
수율 (Return on Investment)를 측정할 수 있고, 결과적으로 비용 최적화.
§ 비용 절감을 위하여 관리 서비스를 이용
§ 대용량 메일 발송이나 데이터베이스를 관리하는 등의 운영 부담을 줄여 클라우드 스케일로 최
적화
§ CAPEX 를 OPEX 로 전환
§ 데이터센터 및 서버들에 대한 불투명한 투자보다는, 사용할 때 사용한 만큼만 지불하는 방식
으로 전환하여 위험 요소를 낮추고 비용을 효과적으로 관리
§ 개발/테스트 환경의 경우 사용되지 않는 시간에 리소스를 중단하여 75%까지 비용을 절감
§ 규모의 경제를 통한 혜택
§ 백만 이상의 고객들의 사용을 통하여 얻어지는 규모의 경제를 통하여 비용이 절감

35. “Friends don’t let friends build data centers.”
- Charles Phillips, CEO, Infor

36. 비용 최적화 영역 - 정의
§ 필요한 만큼만 사용 (Matched supply and demand)
§ 비용 효율적인 자원 (Cost-effective resources)
§ 비용 인지 (Expenditure awareness)
§ 지속적인 최적화 (Optimizing over time)

39. 비용 최적화 영역 – 주요 서비스
§ 필요한 만큼만 사용
§ 오토 스케일링을 통하여 필요한 만큼의 자원만 사용
§ 비용 효율적인 자원 사용
§ RI와 선납금 옵션 또는 Spot 인스턴스를 통하여 비용을 절감
§ AWS Trusted Advisor를 사용하여 AWS환경에 대한 검토를 수행하고 비용 절감 가능성을
탐색
§ 비용 인지
§ Amazon CloudWatch 알람 및 Amazon Simple Notification Service (SNS)를 활용하여 비
용 관리 프로세스 수립
§ 지속적인 최적화
§ AWS 블로그의 ‘What’s new’ 섹션을 통하여 새로 발표된 기능과 서비스들을 확인
§ AWS Trusted Advisor를 통하여 비용 절감 요소를 탐색

40. 고객사 예

41. 보안
§ AWS Root 계정을 안전하게 관리(MFA 사용)
§ 데이터가 인터넷을 통해 전송될 때 암호화
§ SSL 사용
§ VPN 연결
§ AWS 보안 credential 이 애플리케이션 소스코드에 하드코딩
§ 저장된 데이터가 암호화 되어 있지 않음

42. 안정성
§ Service Limit 관리 : notification 등
§ Auto Scaling, Load Balancing, EC2 Auto Recovery 적용
§ Business support plan 가입
§ DR(Disaster Recovery) 정책 미수립

43. 성능 효율화
§ CDN을 이용하여 이미지에 대한 캐싱 사용
§ 벤치마킹, Load Test 수행을 기반으로 인스턴스 종류 선택
§ 스토리지 및 데이터베이스에 대한 성능/용량 분석 미비
§ 새로운 기능/서비스에 대한 검토 미비

44. 비용 최적화
§ Tagging 을 이용하여 부서별/사용자별 사용량 관리 정책 수립
§ 사용되지 않는 인스턴스 Stop
§ TA(Trusted Advisor) 리뷰 정책 미비
§ 실제 사용량 대비 과도한 사이징
§ 새로운 서비스/기능에 대한 검토 미비

45. 부록 : 애플리케이션 디자인 원칙

46. 클라우드 애플리케이션 디자인 원칙
§ 장애를 대비한 아키텍처를 디자인 하십시오 !
§ 느슨한 결합구조의 아키텍처가 여러분을 자유롭게 합니다 !
§ 탄력적인 아키텍처를 구현 하십시오 !
§ 모든 계층에서 보안을 구축하십시오 !
§ 제약조건을 두려워 마십시오 !
§ 병렬적으로 생각하십시오 !
§ 다양한 스토리지 옵션을 고려하십시오 !

47. 감사합니다 !