Architecting for the Cloud 백서(번역/요약)

이 포스트는 AWS 어소시에이트 시험 가이드에서 AWS Architecting for the Cloud 백서(2018/10)를 한글로 번역 및 요약한 자료입니다. 해당 포스트는 계속해서 업데이트 됩니다.

마지막 업데이트(2019/08/04)

목차

• 인트로
• 전통적인 환경과 cloud computing 환경의 차이
• 디자인 원칙
• 결론

소개

• AWS Architecting for cloud 백서 는 AWS 에서 soultion building을 하는 developer들에게 도움을 주기 위해 제작되었다.
• 이 백서는 AWS로 서비스를 디자인 할 때 필요한 key concept와 차이점을 알 수 있도록 도와준다.
• 더 많은 정보는 AWS Well-Architected Framework 백서를 참고하면 된다.

전통적인 환경과 클라우드 환경의 차이점

프로비저닝 된 리소스로서의 IT 자산

• 전통적인 computing enviorment에서는 provison된 환경이 최대 사용량을 통해 결정되었다.

• 하지만 이는 유휴 상태일 때 자원의 낭비가 있기 때문에 효율적이지 않다.
• aws에서는 이런 서버, 데이터베이스, 스토리지를 빠르게 인스턴스화하고, 변경 및 테스트를 손쉽게 할 수 있도록 지원한다.

글로벌하게 사용 가능 및 손쉬운 용량 확장

• AWS의 Global infra를 사용하여 가장 잘 맟는 AWS 지역에 어플리케이션 배포할 수 있다.
• 글로벌 애플리케이션을 AWS CDN을 사용하여 전 세계의 Enduser에게 손쉽게 전달할 수 있다.

높은 수준의 관리 서비스

• 기본적인 ec2 서비스 외에 여러 관리 및 분석, 배포 서비스에 쉽게 액세스 할 수 있다.
• 개발자가 즉시 사용 가능하기때문에 새로운 솔루션을 빠르게 제공할 수 있으며, 운영의 복잡성과 비용을 줄일 수 있다.

내장된 보안

• AWS Cloud는 IT 리소스의 구성 변경을 지속적으로 모니터링할 수 있는 관리 기능을 제공한다.
• 또한 보안에 민감한 조직의 요구사항을 충족시기키 위해 미리 보안이 잘 된 데이터 센터 및 네트워크 아키텍쳐를 사용할 수 있다.

비용 설계

• AWS는 세분화 된 청구서를 제공하므로 솔루션에 대한 모든 관련된 비용을 손쉽게 추적할 수 있다.
• 여러 비용 관련해서 자원 사용 경고 및 최적화에 대한 도움이 되는 서비스를 제공한다.

AWS 내에서의 운영 모델

• 마이그레이션 된 응용 프로그램, 리펙토링 및 rearchitected solution 들은 AWS 내에서 완전히 자동화될 수 있다.
• 이러한 전환들은 AWS 내에서 DevOps 를 더 강력하게 할 수 있으며, AWS 기존 어플리케이션 운영 체제 전환에 대한 강력한 툴과 디자인 원칙 가이드을 제공한다.

AWS Cloud 디자인 원칙

확장성

• 시간이 지남에 따라 성장할 것으로 예상되는 시스템은 확장 가능한 아키텍처 위에 구축해야 한다. 일반적으로는 IT 아키텍쳐를 2가지 방법으로 확장을 한다.

• 수직 확장 : Amazon EC2를 사용하면 인스턴스를 중지하고 RAM, CPU, I / O 또는 네트워킹 기능이 더 많은 인스턴스 유형으로 인스턴스의 크기를 조정할 수 있다. 한계 도달 가능하니 구현이 쉽고 유스 케이스가 단순한 경우에 적용한다.
• 수평 확장 : 더 많은 서버를 추가하고, 더 많은 자원 수의 증가를 통해 수평 확장이 이루어진다.

수평 확장의 예시

• 여러 노드에 부하 분산: 아마존 ELB를 사용하여 workload의 분산을 줄일 수 있으며, route 53을 활용하여 DNS 라운드 로빈을 구현할 수 있다.
• stateless components : 이전의 서버 간 상호작용을 알 수 없으며, 세션 정보를 저장하지 않는 응용 프로그램이다. 사용자 세션 정보를 로컬 파일 시스템에 저장하지 않고, Amazon DynamoDB 같은 데이터베이스에 저장하는 방법을 선택할 수 있으며, 대용량 파일의 중간 결과를 저장 시 S3나 EFS를 사용하여 stateless component의 도입을 피할 수 있다.
• stateful components : Session Affinity를 사용하여 낮은 대기시간을 구현 가능

• 분산 처리 : 오프라인 배치 처리를 AWS Batch, AWS Glue, Apache Hadoop과 같은 분산 데이터 처리 엔진을 사용하여 수평 적으로 확장 할 수 있다.

고정된 서버 대신 일회용 리소스 사용

• 기존의 인프라 환경에서는 새로운 하드웨어를 도입 할 때 비용과 시간 때문에 고정 된 리소스로 작업해야 한다. 이는 많은 시간 낭비를 불러온다. AWS는 동적으로 프로비저닝 된 클라우드 컴퓨팅의 특성 및 인프라 구조 패턴을 이용하여 이를 자동화할 수 있다.
• Bootstrapping : EC2 인스턴스 또는 Amazon RDS를 사용할 때 해당 자원을 특정한 상태로 가져오게 할 수 있는 bootstrapping을 할 수 있다.
• Golden Image: AWS 리소스 는 해당 리소스의 특정 상태에 대한 스냅 샷 생성을 골든 이미지로 가능하게 한다.
• 한마디로 외부 서버 상태를 snapshot 한 뒤 이후에 load할 수 있다. 예를 들어 기존 사내 구축 환경의 가상화 환경이 있는 경우, AWS에서 VM 가져 오기 / 내보내기를 사용하여 다양한 가상화 형식을 AMI로 변환 가능하다.
• 컨테이너 : Docker와 Kubernetes ,Amazon EKS를 사용하면 컨테이너 화 된 응용 프로그램을 손쉽게 배포, 관리 및 확장 할 수 있다.

오토메이션 — serverless 관리 및 운영 방법

• AWS 가 지원하는 관리 및 deployment tool 들: Serverless 패턴을 사용할 시 관리 및 배포 자동화를 지원한다.

• AWS Elastic Beanstalk, Amazon EC2 auto recovery , AWS Systems Manager, Auto Scaling 등이 있다. 자세한 사항은 기술 문서를 참조.
• AWS 가 지원하는 Alarm과 Event Notification Tool들 : 관리할 때 비용이나 Cpu Watch, 서버 상태 visualization 등을 지원한다.
• Amazon CloudWatch alarms , Amazon CloudWatch Events , AWS Lambda scheduled events , AWS WAF security automations 등이 있다. 자세한 사항은 기술 문서를 참조.

Loose Coupling(느슨한 결합)

• 어플리케이션의 용량이 증가함에 따라, IT 시스템의 특성은 더 작고, 느슨하게 결합된 구성 요소로 분해되는 것이 더 효율적이다.
• Well-Defined Interfaces : 다양한 구성 요소가 RESTful API와 같이 특정 기술에 의존하지 않는 인터페이스를 통해서만 서로 상호 작용할 수있게하는 것. AWS는 API Gateway 라는 기술을 통해 개발자가 어떤 규모에도 상관없이 API를 쉽게 작성, 게시, 유지 관리, 모니터링 및 보안 할 수 있도록 지원한다.
• Service Discovery : 기존의 컴퓨팅 방식은 여러 컴퓨팅 리소스 끼리 상호작용을 할 시 , 서로 연결할 때 서비스 처리를 위해 하드 코딩하는 방식을 사용해야 했다.이에 반해 Loose Coupling 방식은 이러한 연결할 때 하드코딩하지 않아도 서비스를 사용할 수 있게 한다.
• Elastic Load Balancing (ELB) : ELB 의 각 Load Balancer 는 자체 호스팅 이름을 가지고 서비스를 서로 연결해 주는 역할을 한다. 또한 Amazon Route 53과 결합되어 언제든지 추상화 또는 수정이 가능하게 된다.
• Asynchronous Integration(비동기 통합 방식) : 이 모델은 즉각적인 응답이 필요하지 않은 요청 및 요청이 등록되었음을 인정하는 상호 작용에 적합하다.

• 비동기 통합의 예시 :프론트 엔드 애플리케이션이 Amazon SQS와 같은 대기열 시스템에 작업을 삽입한 후, 백엔드 시스템은 이러한 작업을 검색하여 시스템이 처리가 가능한 속도로 작업을 처리한다.
• 사용자는 여러 업데이트 스트림이나 이벤트 알림을 AWS Lambda로 처리할 수 있기 때문에 다른 비동기식 메소드를 구현하는 데 신경을 쓰지 않아도 된다.
• 분산 시스템 모범 사례 : Amazon SQS 에서 실패한 요청은 자동으로 재시도 될 수 있으며, 나중에 처리되기 위해 대기열에 저장될 수 있다. 혹은 장애 조치 기능을 통해 본래 서비스가 장애가 있을 시 자동으로 방문자를 백업된 서비스로 라우팅할 수 있다.

서비스가 아닌 서버

• AWS는 기업이 보다 신속하게 IT 비용을 절감하는 데 도움이 되는 다양한 컴퓨팅, 스토리지, 데이터베이스, 분석, 애플리케이션 및 배포 서비스를 제공 한다.
• 미리 제공되는 Managed Services 예시: 개발자가 새로운 IT 서비스를 쉽게 도입할 수 있도록 AWS는 다양한 서비스를 제공한다.
• Amazon CloudFront , ELB, Amazon SES 등 여러 서비스를 제공한다.

• Serverless Architectures : Serverless 아키텍처는 실행중인 응용 프로그램의 운영상의 복잡성을 줄일 수 있다. 예를 들면, 코드를 AWS Lambda 컴퓨팅 서비스에 업로드 할 수 있으며, AWS 인프라를 사용하여 사용자 대신 코드를 실행할 수 있다. 또한 이러한 Serverless Architecture은 AWS 의 Identity Role과 IAM을 사용하여 각 아키텍쳐들의 연결을 조정하거나 , 보안을 향상시킬 수 있다.

AWS Databases

• AWS는 Enterprised 급의 데이터 베이스 사용 비용을 거의 Open Source 의 비용으로 사용할 수 있도록 지원한다.

데이터베이스를 선택할 때 고려해야 하는 사항

읽기 부하 정도

데이터 양과 보관 기간, 데이터 내구성

얼마나 많은 동시 사용자 지원하는지, 데이터베이스 대기시간 요구 사항 충족하는지

데이터 모델이 무엇인지, 데이터를 어떻게 쿼리할 것인지

어떤 종류의 기능이 필요한지, 기술 라이센스 비용이 얼마인지

• 관계형 데이터베이스 : Amazon RDS는 쉬운 스토리지 추가로 수직확장을 지원하며, 읽기 복제본을 만들어 수평적인 확장 또한 가능하다. 또한 고 가용성을 위한 Amazon RDS Multi-AZ 배포 기능을 사용해 가용성이 높은 DB를 운용할 수 있다.
• NoSQL 데이터베이스: 데이터 복제를 통한 읽기 및 쓰기를 수평적으로 확장할 수 있으며, Amazon DynamoDB은 다중 지역, 다중 마스터 데이터베이스를 지원하여 글로벌 응용 프로그램에 대해 신속한 읽기 및 쓰기 성능을 제공한다.
• 데이터 웨어하우스 : 대용량 데이터의 분석 및 보고를 위해 최적화 된 특수 유형의 관계형 데이터베이스. AWS 는 기존 비용의 10분의 1로 사용할 수 있도록 설계된 Amazon RedShift를 사용할 수 있다..
• 검색: 쿼리 검색을 최적화할 수 있음.
• Graph Databases

증가하는 데이터 볼륨 관리

• 데이터 볼륨 관리 방식중 하나인 Data Lake는 대량의 데이터를 중앙 위치에 저장하여 조직 내의 다양한 그룹에서 쉽게 분류, 처리, 분석 및 소비 할 수 있도록 해주는 아키텍처 방식이다. 자세한 사항은 링크 참조https://d0.awsstatic.com/whitepapers/Storage/data-lake-on-aws.pdf

단일 실패 지점 제거

• 고 가용성을 갖춘 시스템을 만들 수 있도록 아키텍처의 모든 계층에서 복구를 자동화하고 중단을 줄이는 방법을 AWS는 지원한다.
• Introducing Redundancy :아키텍쳐 내 단일 실패 지점은 중복성을 도입하여 제거할 수 있으며, 리소스에 오류가 발생하면 보조 리소스에서 장애 조치 프로세스를 통해 기능이 자동으로 복구되는 아키텍쳐를 설계할 수 있다.
• 실패 감지 : ELB 및 Route 53 같은 서비스를 이용하여 트래픽 상태 검사 및 오류를 감지할 수 있다. 또한 AutoScaling을 이용하여 자동 복구 및 Elastic Beanstic을 사용하여 비정상적인 서비스를 자동으로 교체 가능하다.
• 내구성 있는 데이터 저장소 : 아키텍처가 데이터 가용성과 무결성을 모두 보호하는 것이 중요하다. Amazon S3를 사용하면 버전 관리를 통한 버전 보존 검색 및 복원이 가능하며, 비동기 복제를 사용하여 기본 노드의 변경 사항이 바로 반영되지 않도록 할 수 있다.
• 복구가 자동화 된 다중 데이터 센터 : AWS에서는 여러 장애로 인한 서비스 중단 시나리오에서 간단하고 효율적인 복구가 가능하다.
• 예시로, 여러 대의 가용 영역에 응용 프로그램 서버를 배포하고 ELB에 연결한 후, 특정 가용 영역의 EC2 인스턴스가 상태 검사에 실패하면 ELB가 해당 노드로 트래픽을 보내지 않는다.
• 오류 격리: 특정 요청으로 인해 시스템이 장애를 일으키는 버그가 발생하면, 모든 인스턴스에 대해 동일한 요청을 반복적으로 시도하여 사용자가 인스턴스에 계단식 오류를 유발할 수 있다. 이 경우, Shuffle Sharding 방식을 사용하여 인스턴스를 그룹화하여 문제를 해결할 수 있다.

비용 최적화