1. 서울 리전 개설 1년,
모범 아키텍처 설계 전략

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

3. 2016년 1월

4. 2017년 1월

5. AWS Well Architected Framework

6. https://d0.awsstatic.com/International/ko_KR/whitepapers/Well-Architected_Whitepaper.pdf

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

8. Well Architected 프레임워크
아키텍처에 대한 모범사례 및 지침을 고객들과 공유하기 위한 방법론
Security
(보안)
Reliability
(안정성)
Performance
Efficiency
(성능)
Cost
Optimization
(비용 효율)
Operational
Excellence
(운영 고도화)

9. Well Architected 프레임워크의 5가지 영역
§ 보안 (Security) : AWS 클라우드 상의 데이터 및 자산을
안전하게 보호하기 위한 best practice 가 적용되어 있습니까?
§ 안정성 (Reliability) : 시스템 아키텍쳐가 장애, 업무 증가 및
기타 이벤트에 능동적으로 대처할 수 있습니까?
§ 성능 효율화 (Performance Efficiency) : 시스템 리소스들이
최적의 성능을 낼 수 있도록 설계되어 있습니까?
§ 비용 최적화 (Cost Optimization) : 비용을 줄일 수 있는
방법들을 고려하고 있습니까?
§ 운영 고도화(Operational Excellence) : 운영중인 시스템을
모니터링 하고, 지원체계를 끊임없이 개선할 수 있습니까?

10. 클라우드 디자인 원칙
필요한 용량을 “추측”하지 마십시오!
운영환경의 규모에 맞게 테스트를 수행 하십시오!
아키텍처에 대한 변경/실험을 자동화 하십시오!
Data-driven 아키텍처를 디자인 하십시오!
Game Days 등을 통해 지속적으로 개선 하십시오!

11. 보안

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

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

14. 2016년 1월

15. 2017년 1월

16. 2016년 1월

17. 2017년 1월

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

19. 안정성

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

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

22. 2016년 1월

23. 2017년 1월

24. 2016년 1월

25. 2017년 1월

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 데이터베이스나 미디어
트랜스코딩, 머신러닝과 같은 전문성이 필요한 기술도 클라우드 서비스 형태로 제공.
§ Multi Region 또는 CDN 사용
여러 리전에 서비스를 배포하여 고객에게 최소의 비용으로 최고 품질의 서비스를 제공.
§ 서버 없는 아키텍쳐를 사용
클라우드에서는 서버운영 부담 없이 서버리스(Serverless) 아키텍쳐를 손쉽게 구성할 수 있고,
이를 통하여 서버 운영의 부담을 줄이고 사용량 또한 줄일 수 있음.
§ 더 자주 새로운 아이디어를 실험
가상화되고 자동화된 자원들을 통해 여러 종류의 인스턴스, 스토리지, 구성을 사용하여 빠르게
실험을 진행할 수 있음.

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

30. 2016년 1월

31. 2016년 1월

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)

37. 2016년 1월

38. 2016년 1월

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

40. 운영

41. 운영 영역 - 디자인 원칙
§ 코드로 운영작업 수행
§ 공통적인 반복 프로세스 또는 절차가 있는 경우 자동화를 고려. 예를 들어, 구성 관리, 변경 및
이벤트에 대한 응답 자동화를 고려.
§ 운영 프로세스를 비지니스 목표에 맞게 조정
§ 비지니스 목표를 달성하기 위한 모니터링 매트릭 설정 및 수집. 신호 대 잡음 비율을 줄이기
위한 반복적인 노력 필요.
§ 정기적으로, 작게, 점진적으로 변경
§ 변경 작업은 큰 배치가 아닌 작은 단위로 수행해야 하며, 작업에 영향을 주지 않고 롤백 할 수
있어야 함.
§ 유지 보수 또는 서비스 구성요소의 교체를 위해 중단없이 변경사항을 적용할 수 있도록 운영
절차를 마련.
§ 예기치 않은 이벤트에 대한 대응 테스트
§ 이벤트에 대응하는 절차를 테스트하고 이해하여, 실제 이벤트 발생 시 이를 준수하는 것이
중요.

42. 운영 영역 - 정의
§ 준비 (Preparation)
§ 운영 (Operations)
§ 대응 (Reponses)

43. 운영 영역 – 주요 서비스
§ 준비
§ Operational Checklist, Security Checklist, 등등
§ AWS Config, AWS Service Catalog 등을 통해 리소스와 설정에 대한 인벤토리 관리
§ 오토 스케일링 및 SQS 등을 통해 워크로드를 자동화
§ 운영
§ AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline 등을 이용하여 애플리케이션
코드 변경 관리
§ AWS 환경에 가해진 변경들을 추적하고 감사하기 위해서 AWS CloudTrail 사용
§ 대응
§ 효과적이고 자동화된 대응을 위해 CloudWatch의 모든 기능 사용
§ CloudWatch Alarm을 사용하여 Alerting/Notification을 위한 Thresholds 설정
§ 알림에 대한 트리거와 자동화된 대응을 위해 CloudWatch Events 사용

44. 운영 영역 – 준비(Prepare)

45. 운영 영역 – 운영(Operate)

46. 운영 영역 – 대응(Respond)

47. 고객사 예

48. 고객사 사례
ARC 203 : Achieving Agility by Following Well-Architected Framework Principles
§ Cloud Journey
§ 2013 – Introduced well-architected design
§ 2014 – Launched well-architected product
§ 2015 – All products followed well-architected framework

49. 고객사 사례 #1
EC2-Classic, Elastic Load Balancing,
Amazon S3, Amazon SimpleDB
MySQL on EC2
“Root” credentials
Single-AZ
Internally developed tooling
Backups sent to data center
Manual AMI creation
Cloud Infrastructure 2012

50. 고객사 사례 #1
Cloud Infrastructure 2014
Cloud native services: VPC, Auto Scaling,
Amazon Route 53, Amazon CloudFront
RDS-MySQL
Least-privileged access: IAM
Multi-AZ
Cloud native tooling: AWS CloudFormation
Automated AMI process: Ansible
Adopted DevOps principles: Created CI/CD
pipelines

51. 고객사 사례 #1
Existing Products: Desired Changes
Area 2012 2015 – Well architected
EC2 Classic VPC
Relational database MySQL on EC2 RDS for MySQL
Auto Scaling Zero Everything
Elastic Load Balancing External only Everything
CloudFormation Zero 95%
AMI creation Manual Automated: Ansible
Application deployment Manual AWS CodeDeploy

52. 고객사 사례 #1
Existing Products: Measured Improvements
Area 2012 2015 – Well architected
Security Root API key IAM, Network ACL, Egress filtering
Single point of failure 10+ 1
Time to create separate environment 1 month < 2 hours
Longest code deployment time 2 weeks < 4 hours
Typical code deployment time 15 minutes < 1 minute

53. 고객사 사례 #1
More valuable lessons learned
바퀴를 재발명 하지 마라
변화를 두려워 하지 마라
아키텍처의 한계를 알아라
적절한 크기를 단계마다 선택하라
It’s a journey, not a destination
시간을 절약하기 위한 시간 투자
자동화를 통한 신속한 변경 및 개선
함께할 수 있는 사람이 필요

54. 고객사 사례 #2
§ 로그 저장/분석 하지 않음
§ 키/자격증명 주기적인 변경 없음
§ 자격증명을 스크립트나 애플리케이션에
하드코딩
Before

55. 고객사 사례 #2
§ 로그 캡춰, ElasticSearch 활용하여 분석
§ 키/자격증명 주기적인 변경 없음
§ Role based access control &
STS(Security Token Service) 사용
After

56. 고객사 사례 #2
§ AWS 서비스 리미트 모름
§ 복구 계획 없음
§ 기술적인 이슈 에스컬레이션 경로 없음
Before

57. 고객사 사례 #2
§ AWS 서비스 리미트 모니터링 및 관리
§ 복구 계획 없음
§ AWS Support APIs 활용
After

58. 고객사 사례 #2
§ On-premise 경험으로 인스턴스 유형
선택
§ Auto Scaling 없음
§ 캐쉬 솔루션 사용하지 않음
Before

59. 고객사 사례 #2
§ 벤치마팅을 통해 인스턴스 유형 선택
§ Auto Scaling 없음
§ 캐쉬 솔루션으로 ElastiCache Redis 사용
After

60. 고객사 사례 #2
§ 사용량 제한 없음
§ CDN 사용하지 않음
§ AWS Support TA (Trusted Advisor)
리뷰하지 않음
Before

61. 고객사 사례 #2
§ 사용량 제한 없음
§ Amazon CloudFront CDN 사용
§ 매주 AWS Support TA 리뷰
After

62. 클라우드 디자인 원칙
필요한 용량을 “추측”하지 마십시오!
운영환경의 규모에 맞게 테스트를 수행 하십시오!
아키텍처에 대한 변경/실험을 자동화 하십시오!
Data-driven 아키텍처를 디자인 하십시오!
Game Days 등을 통해 지속적으로 개선 하십시오!

63. 감사합니다