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

I need your help !

원활한 세션 진행을 위해서QR Code 스캐너를 준비해 주세요!

2016년 1월

2017년 1월

AWS Well Architected Framework

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

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

Well Architected 프레임워크아키텍처에 대한 모범사례 및 지침을 고객들과 공유하기 위한 방법론

Security(보안)

Reliability(안정성)

Performance Efficiency

(성능)

Cost Optimization(비용 효율)

Operational Excellence

(운영 고도화)

Well Architected 프레임워크의 5가지 영역§ 보안 (Security) : AWS 클라우드 상의 데이터 및 자산을

안전하게 보호하기 위한 best practice 가 적용되어 있습니까?

§ 안정성 (Reliability) : 시스템 아키텍쳐가 장애, 업무 증가 및기타 이벤트에 능동적으로 대처할 수 있습니까?

§ 성능 효율화 (Performance Efficiency) : 시스템 리소스들이최적의 성능을 낼 수 있도록 설계되어 있습니까?

§ 비용 최적화 (Cost Optimization) : 비용을 줄일 수 있는방법들을 고려하고 있습니까?

§ 운영 고도화(Operational Excellence) : 운영중인 시스템을모니터링 하고, 지원체계를 끊임없이 개선할 수 있습니까?

클라우드 디자인 원칙

필요한 용량을 “추측”하지 마십시오!

운영환경의 규모에 맞게 테스트를 수행 하십시오!

아키텍처에 대한 변경/실험을 자동화 하십시오!

Data-driven 아키텍처를 디자인 하십시오!

Game Days 등을 통해 지속적으로 개선 하십시오!

보안

보안 영역 - 디자인 원칙§ 모든 영역에 보안을 적용

인프라 전체에 적용되는 방화벽보다는, 각각의 리소스에 대한 방화벽 사용 및 보안 제어를설정. (모든 가상 머신, 로드 밸런서, 네트웍 서브넷)

§ 추적 로그를 수집모든 활동과 변경 사항들에 대한 로그를 수집하여 감시.

§ 보안 이벤트에 대한 대처를 자동화지속적인 모니터링을 수행하고, 이벤트 혹은 조건에 따른 대처를 자동화.

§ 애플리케이션, 데이터의 보호에 집중AWS의 공유 보안 모델에 따라, AWS는 인프라 및 서비스에 대한 보안을 제공. 고객은AWS에서 운영되고 있는 애플리케이션, 데이터 및 운영 체제의 보안에 집중.

§ 보안에 대한 best practice를 자동화최적화된 이미지들을 사용하고, 전체 인프라를 템플릿을 통하여 관리.

보안 영역 - 정의

§ 데이터 보호 (Data Protection)

§ 권한 관리 (Privilege Management)

§ 인프라 보호 (Infrastructure Protection)

§ 감시 제어 (Detective Controls)

2016년 1월

2017년 1월

2016년 1월

2017년 1월

보안 영역 – 주요 서비스§ 데이터 보호

§ 전송 및 보관시 암호화 : 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

안정성

안정성 영역 - 디자인 원칙§ 복구 절차를 테스트

다양한 형태의 장애상황을 만들고 복구하는 시나리오를 자동화하여 복구시 문제를 미리파악하여 대처.

§ 문제 발생시 자동으로 복구될 수 있도록 구성중요 요소들에 대한 모니터링을 수행하여, 임계치에 도달하였을 때 자동으로 필요한 절차를수행하도록 시스템을 구성. 이를 통해 장애에 대한 감지, 추적, 조치 뿐만 아니라 더 나아가서장애를 사전에 예방.

§ 시스템의 가용성을 높이기 위하여 수평 확장이 가능하도록 구성하나의 큰 자원을 사용하는 것보다, 여러 개의 작은 자원들을 사용하는 것이 장애 발생시피해를 최소화. 이 때, 여러 개의 작은 자원들은 공통된 장애 요소를 가지고 있지 않도록 구성.

§ 고정적이지 않고, Dynamic 한 아키텍처 구성시스템의 용량을 초과하는 부하가 유입되는 경우 (종종 DDoS의 목적)에도 자원의 고갈로인해 문제가 발생하지 않도록 동적으로 구성.

안정성 영역 - 정의

§ 기본 요건 (Foundation)

§ 변경 관리 (Change Management)

§ 장애 관리 (Failure Management)

2016년 1월

2017년 1월

2016년 1월

2017년 1월

안정성 영역 – 주요 서비스§ 기본 요건

§ 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 설정

성능

성능 영역 - 디자인 원칙§ 최신 서비스/기능 사용

구현하기 어려운 최신 기술도 클라우드에서는 쉽게 사용할 수 있음. IT 팀이 새로운 인프라기술을 익히기보다는 서비스 형태로 사용하는 것이 유리. NoSQL 데이터베이스나 미디어트랜스코딩, 머신러닝과 같은 전문성이 필요한 기술도 클라우드 서비스 형태로 제공.

§ Multi Region 또는 CDN 사용여러 리전에 서비스를 배포하여 고객에게 최소의 비용으로 최고 품질의 서비스를 제공.

§ 서버 없는 아키텍쳐를 사용클라우드에서는 서버운영 부담 없이 서버리스(Serverless) 아키텍쳐를 손쉽게 구성할 수 있고,이를 통하여 서버 운영의 부담을 줄이고 사용량 또한 줄일 수 있음.

§ 더 자주 새로운 아이디어를 실험가상화되고 자동화된 자원들을 통해 여러 종류의 인스턴스, 스토리지, 구성을 사용하여 빠르게실험을 진행할 수 있음.

성능 영역 - 정의

§ 컴퓨트 (Compute)

§ 스토리지 (Storage)

§ 데이터베이스 (Database)

§ 용량-시간의 Trade-off

2016년 1월

2016년 1월

성능 영역 – 주요 서비스§ 컴퓨트

§ 오토 스케일링 등의 방법을 사용하여 수요에 맞는 인스턴스 갯수를 유지하도록 관리

§ 스토리지§ 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 등을 활용§ 제약이 없는, 많은 용량을 사용하여 프로세싱 시간을 절약

비용

비용 영역 - 디자인 원칙§ 비용을 업무/부서별로 투명하게

§ 클라우드를 통하여 IT 비용을 개별 업무/부서별로 쉽게 나눌 수 있음. 보다 정교하게 투자회수율 (Return on Investment)를 측정할 수 있고, 결과적으로 비용 최적화.

§ 비용 절감을 위하여 관리 서비스를 이용§ 대용량 메일 발송이나 데이터베이스를 관리하는 등의 운영 부담을 줄여 클라우드 스케일로

최적화

§ CAPEX 를 OPEX 로 전환§ 데이터센터 및 서버들에 대한 불투명한 투자보다는, 사용할 때 사용한 만큼만 지불하는

방식으로 전환하여 위험 요소를 낮추고 비용을 효과적으로 관리§ 개발/테스트 환경의 경우 사용되지 않는 시간에 리소스를 중단하여 75%까지 비용을 절감

§ 규모의 경제를 통한 혜택§ 백만 이상의 고객들의 사용을 통하여 얻어지는 규모의 경제를 통하여 비용이 절감

“Friends don’t let friends build data centers.”

- Charles Phillips, CEO, Infor

비용 영역 - 정의

§ 필요한 만큼만 사용 (Matched supply and demand)

§ 비용 효율적인 자원 (Cost-effective resources)

§ 비용 인지 (Expenditure awareness)

§ 지속적인 최적화 (Optimizing over time)

2016년 1월

2016년 1월

비용 영역 – 주요 서비스§ 필요한 만큼만 사용

§ 오토 스케일링을 통하여 필요한 만큼의 자원만 사용

§ 비용 효율적인 자원 사용§ RI와 선납금 옵션 또는 Spot 인스턴스를 통하여 비용을 절감§ AWS Trusted Advisor를 사용하여 AWS환경에 대한 검토를 수행하고 비용 절감 가능성을탐색

§ 비용 인지§ 비용 분류를 위해 Cost Allocation Tags 사용§ Amazon CloudWatch Billing Alert 를 설정하여 비용 관리 프로세스 수립

§ 지속적인 최적화§ AWS 블로그의 ‘What’s new’ 섹션을 통하여 새로 발표된 기능과 서비스들을 확인§ AWS Trusted Advisor를 통하여 비용 절감 요소를 탐색

운영

운영 영역 - 디자인 원칙§ 코드로 운영작업 수행

§ 공통적인 반복 프로세스 또는 절차가 있는 경우 자동화를 고려. 예를 들어, 구성 관리, 변경 및이벤트에 대한 응답 자동화를 고려.

§ 운영 프로세스를 비지니스 목표에 맞게 조정§ 비지니스 목표를 달성하기 위한 모니터링 매트릭 설정 및 수집. 신호 대 잡음 비율을 줄이기

위한 반복적인 노력 필요.

§ 정기적으로, 작게, 점진적으로 변경§ 변경 작업은 큰 배치가 아닌 작은 단위로 수행해야 하며, 작업에 영향을 주지 않고 롤백 할 수

있어야 함.§ 유지 보수 또는 서비스 구성요소의 교체를 위해 중단없이 변경사항을 적용할 수 있도록 운영절차를 마련.

§ 예기치 않은 이벤트에 대한 대응 테스트§ 이벤트에 대응하는 절차를 테스트하고 이해하여, 실제 이벤트 발생 시 이를 준수하는 것이

중요.

운영 영역 - 정의

§ 준비 (Preparation)

§ 운영 (Operations)

§ 대응 (Reponses)

운영 영역 – 주요 서비스§ 준비

§ 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 사용

운영 영역 – 준비(Prepare)

운영 영역 – 운영(Operate)

운영 영역 – 대응(Respond)

고객사 예

고객사 사례

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

고객사 사례 #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

고객사 사례 #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

고객사 사례 #1

Existing Products: Desired Changes

Area 2012 2015 – Well architectedEC2 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

고객사 사례 #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

고객사 사례 #1

More valuable lessons learned

바퀴를 재발명 하지 마라

변화를 두려워 하지 마라

아키텍처의 한계를 알아라

적절한 크기를 단계마다 선택하라

It’s a journey, not a destination

시간을 절약하기 위한 시간 투자

자동화를 통한 신속한 변경 및 개선

함께할 수 있는 사람이 필요

고객사 사례 #2

§ 로그 저장/분석 하지 않음

§ 키/자격증명 주기적인 변경 없음

§ 자격증명을 스크립트나 애플리케이션에하드코딩

Before

고객사 사례 #2

§ 로그 캡춰, ElasticSearch 활용하여 분석

§ 키/자격증명 주기적인 변경 없음

§ Role based access control & STS(Security Token Service) 사용

After

고객사 사례 #2

§ AWS 서비스 리미트 모름

§ 복구 계획 없음

§ 기술적인 이슈 에스컬레이션 경로 없음

Before

고객사 사례 #2

§ AWS 서비스 리미트 모니터링 및 관리

§ 복구 계획 없음

§ AWS Support APIs 활용

After

고객사 사례 #2

§ On-premise 경험으로 인스턴스 유형선택

§ Auto Scaling 없음

§ 캐쉬 솔루션 사용하지 않음

Before

고객사 사례 #2

§ 벤치마팅을 통해 인스턴스 유형 선택

§ Auto Scaling 없음

§ 캐쉬 솔루션으로 ElastiCache Redis 사용

After

고객사 사례 #2

§ 사용량 제한 없음

§ CDN 사용하지 않음

§ AWS Support TA (Trusted Advisor)리뷰하지 않음

Before

고객사 사례 #2

§ 사용량 제한 없음

§ Amazon CloudFront CDN 사용

§ 매주 AWS Support TA 리뷰

After

클라우드 디자인 원칙

필요한 용량을 “추측”하지 마십시오!

운영환경의 규모에 맞게 테스트를 수행 하십시오!

아키텍처에 대한 변경/실험을 자동화 하십시오!

Data-driven 아키텍처를 디자인 하십시오!

Game Days 등을 통해 지속적으로 개선 하십시오!

감사합니다