[SAA-C02] 1. 복원력을 갖춘 아키텍처 설계

 

1. AWS 글로벌 인프라의 이해

AWS는 전 세계 25개의 지리적 리전 내에 81개의 가용 영역을 운용하고 있어서 장애 대처에 안정적이며, 확장 가능한 방식으로 설계되었다. 

 

따라서 성능, 가용성, 보안, 확장성, 저렴한 비용 등을 장점으로 들 수 있다. 

 

 

 

 

보안

AWS의 인프라는 데이터의 기밀성, 무결성 및 가용성을 보장하기 위해 연중무휴 24시간동안 모니터링 된다. 

데이터 센터 및 리전을 상호 연결하는 AWS 글로벌 네트워크를 통해 이동하는 모든 데이터는 보안시설을 떠나기 전에 물리적 계층에서 자동으로 암호화된다. 

 

가용성

AWS는 모든 유형의 클라우드 공급업체에 가장 뛰어난 네트워크 가용성을 제공한다. 

각 리전은 완벽히 독립되어있고, 인프라에서 격리된 파티션에 해당하는 여러 AZ로 구성되어있다. 

 

성능

AWS 리전은 짧은 지연시간, 낮은 패킷 손실 및 향상된 네트워크 품질을 제공한다. 

애플리케이션 요구 사항이 무엇이든, 필요에 따라 리소스를 빠르게 구동하여 수백 개, 심지어 수천 개의 서버를 몇분만에 배포할 수 있다. 

 

국제적 입지

AWS는 어떤 공급자보다도 큰 글로벌 인프라를 갖추고 있다. 

따라서 애플리케이션 및 워크로드를 클라우드에 배포하면 주 대상 사용자에게 가장 가까운 기술 인프라를 유연하게 선택할 수 있다. 

 

확장성

AWS 글로벌 인프라는 극도로 높은 유연성과 클라우드의 무한한 확장성을 제공한다. 

작업을 할 때 비즈니스 요구사항에 따라 즉시 확장하거나 축소할 수 있으므로 실제로 필요한 양의 리소스만 프로비저닝하면 된다. 

 

유연성

AWS 글로벌 인프라는 워크로드를 실행하는 방법과 실행하는 위치를 선택할 수 있는 유연성을 제공하며, 

동일한 네트워크, 제어 플레인, API 및 AWS 서비스를 사용하여 워크로드를 실행할 수 있다. 

또한 애플리케이션을 글로벌로 실행하려는 경우 원하는 AWS 리전과 AZ를 선택할 수 있다. 

 

 

 

 

 

 

 

 

 

 

2. EC2 의 지역 및 가용 영역 선택

 

 

각 리전 : 개별 지역 내에 존재하는 지리적 위치

가용 영역 (AZ) : 리전 내에 있는 구분된 가용성 영역 , 전용선으로 연결되어 있어 마치 한 클러스터인 것처럼 동작한다. 

 

인스턴스를 실행할 때 사용자가 직접 가용영역을 선택할 수 있으며, 복수의 가용 영역에 걸쳐 인스턴스를 배포했을 때 하나의 인스턴스에 장애가 발생한 경우를 대비하여 다른 가용 영역의 인스턴스가 요청을 처리할 수 있도록 애플리케이션을 설계할 수 있다. 

 

또한 탄력적 IP 주소를 사용하여 한 가용 영역에서 인스턴스에 장애가 발생한 경우, 다른 가용 영역의 인스턴스로 주소를 신속하게 매핑함으로써 인스턴스 장애를 마킹할 수 있다. 

 

이렇게 지역별로 분리하고, 지역 내에서도 가용영역을 분리하여 강력한 내결함성과 안정성을 얻을 수 있다. 

 

 

 

 

 

 

 

 

3. Amazon CloudFront 글로벌 엣지 네트워크

전 세계에 있는 최종 유저에게 짧은 지연시간으로 콘텐츠를 전송할 수 있도록 도와준다. 

 

 

최종 사용자에게 더 짧은 대기 시간으로 콘텐츠를 전송하기 위해 Amazon CloudFront는 현재 47개국 90개 도시에서 275개가 넘는 상호 접속 위치(POP)로 구성된 글로벌 네트워크를 사용하고 있다. 

 

 

 

 

 

보안

여러 공격으로부터 네트워크 및 애플리케이션 계층을 보호한다.

또한 CloudFront를 애플리케이션과 인프라에 대한 관문으로 사용함으로써 중요한 콘텐츠, 데이터, 코드 및 인프라에서 주요 공격 지점을 차단한다. 

 

 

가용성

콘텐츠를 CloudFront 엣지 및 리전별 캐시에 저장되며, 필요한 경우에만 오리진에서 가져올 수 있다. 

이러한 방법으로 오리진에서 트래픽이 줄어들면 애플리케이션의 가용성을 향상시키는데 도움이 된다. 

 

 

엣지 컴퓨팅

CloudFront는 CloudFront 함수 및 AWS Lambda@Edge를 통해 프로그래밍 가능한 보안 엣지 CDN 컴퓨팅 기능을 제공한다. 

CloudFront 함수는 HTTP 헤더 조작, URL 리디렉션, 캐시 키 정규화와 같이 높은 확장성과 지연 시간에 민감한 작업에 적합하다.

 

 

비용 효율성

CloudFront는 종량제와 사용자 지정 요금 등 개인화된 요금 옵션을 제공한다. 

사용한 만큼 지불하기 때문에 경제적이다. 

 

 

 

 

 

 

 

 

4. 클라우드 서비스를 설계하는 방법 

 

AWS 고급 아키텍처 방법론

보안

• 전송 및 보관시 암호화
• IAM으로 권한 관리
• VPC로 인프라 보호
• CloudWatch로 감시 제어 활동

안정성

• 복구 절차 테스트 및 자동 복구 설정
• 수평 확장이 가능하도록 구성

성능 효율화

• AWS에서 최신 기술 쉽게 사용하도록 지원
• 글로벌 애플리케이션 지원 및 서버리스 아키텍쳐를 이용한 새로운 아이디어 실험

비용 최적화

• 오토 스케일링을 통한 필요한 자원만 사용
• 비용 효율적인 지원 사용

 

 

 

AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안

마이크로 서비스

: 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어있는 경우의 소프트웨어 개발을 위한 아키텍쳐 및 조직적 접근 방식.

 

마이크로 서비스 아키텍쳐는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 새로운 기능의 출시를 단축할 수 있게 한다.

 

 

 

 

모놀리식(Monolic) 아키텍쳐 vs 마이크로 서비스 아키텍쳐 

 

모놀리식 아키텍쳐의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 

따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍쳐 전체를 확장해야 한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하는게 훨씬 더 복잡해진다. 이것은 모놀리식 아키텍쳐가 애플리케이션 가용성에 대한 위험을 가중시킨다고 할 수 있다. 

 

 

마이크로 서비스 아키텍쳐의 경우 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 

서비스는 비즈니스 기능을 위해 구축되며, 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다. 

 

 

 

 

 

 

마이크로 아키텍쳐의 고려 사항

• 리소스 관리 : EC2 Container 를 사용해서 유연하고 AWS 응용이 쉬운 상태로 설계, Lambda를 사용하여 서버리스 이벤트 처리 방식의 컴퓨팅 서비스 사용
• 모니터링 : AWS CloudWatch
• 서비스 Discovery : EC2와 Route53 사용
• 배포 : Blue-green 배포, Lambda 배포 사용

 

 

 

 

 

 

 

 

 

5. 느슨한 결합을 구현하기 위한 서비스들 

 

ELB FAQ

• 로드 밸런서 선택시 : 애플리케이션에 맞는 로드 밸런서 선택
• Application Load Balancer, Network Load Balancer, Classic Load Balancer 를 적절히 사용
• Application Load Balancer : HTTP, HTTPS, Websocket 등 다양한 프로토콜 지원
• 하이브리드 로드 밸런싱 지원

 

Amazon SQS FAQ

• 메세지 대기열 시스템을 손쉽게 구축 가능, 느슨한 FIFO 대기열 사용
• Amazon SNS와 차이점 : SNS는 폴링할 필요 없이 푸시 매커니즘으로 메세지 전송, SQS에서는 폴링 모델로 메세지 교환
• Amazon Kinesis Streams와 차이점 : Kinesis는 빅데이터 스트리밍 처리시에 사용
• 메세지 전달 보장 기능 사용

 

 

 

 

 

 

 

6. 안정적이고 복원력을 갖춘 스토리지 선택하기 

 

EC2 스토리지 - Amazon EBS

 

 

Amazon EBS

: EC2에서 사용하는 일종의 하드 디스크. 

다른 물리적 하드 드라이브처럼 사용이 가능하고, 다른 인스턴스에 EBS를 분리한 후 다른 인스턴스에 연결하는 것도 가능하다. 

 

 

 

 

 

 

Amazon EC2 인스턴스 스토어

 

 

인스턴스 스토어

: 휘발성이며 인스턴스가 활성화되어 있는 동안 유지되는 스토리지

상대적으로 성능이 낮아 데이터 분석용으로 주로 사용한다. 

 

 

 

 

 

Amazon EFS

 

Amazon EFS

: EC2 인스턴스에 사용할 수 있는 간단하고 확장 가능한 파일 스토리지

파일이 추가되고 제거됨에 따라 자동으로 증가 또는 줄어든다. 저장 사용량만큼만 비용이 발생하기 때문에, 전체적인 비용을 아낄 수 있다.

 

 

 

 

 

Amazon S3

 

Amazon S3

: Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스

일반적인 파일 서버는 트래픽이 증가함에 따라 장비를 증설하는 작업을 하는데, S3는 이와 같은 것을 대행한다. 

저장할 수 있는 파일 개수에 제한이 없으며 데이터 손실이 발생할 경우 자동으로 복구하고, 정보의 중요도에 따라 보호 수준을 설정해 비용을 절감한다. 

 

 

 

주요 특징 모음

 

 

 

 

 

 

 

 

 

 

7. AWS 사용 모범 사례

 

EC2 모범 사례

• 보안 및 네트워크 :  자격 증명 연동 및 IAM 역할을 사용해서 리소스 및 API 액세스를 관리한다. 
• 스토리지 : 운영 체제에 대해 별도의 EBS 볼륨을 사용하고, 임시 데이터를 저장할 수 있는 인스턴스 스토어를 사용한다. 
• 리소스 관리, 백업 및 복구 : AWS EBS 스냅샷을 이용해 EBS 볼륨을 정기적으로 백업, 개인 AMI를 만들어 추후 인스턴스 시작을 위한 템플릿으로 구성 저장한다. 

 

 

 

RDS 모범 사례

• 메모리, CPU 사용 모니터링 필수
• DB 인스턴스 확장
• DB 작업량 늘어났을 경우 프로비저닝 된 IOPS 스토리지로 변환
• RAM을 충분히 할당하여 작업 집합이 메모리에 상주하도록 한다. 
• CloudWatch 모니터링을 사용하여 DB 인스턴스에 대한 측정치를 확인한다. 

 

 

 

 

 

 

 

8. 가격 / 비용을 비롯한 클라이언트 사양 개발 

 

Amazon EC2 요금

온디맨드

온디맨드 인스턴스에서는 실행하는 인스턴스에 따라 시간당 또는 초당 컴퓨팅 파워에 대한 비용을 지불한다. 

다음과 같은 상황에 적합하다. 

 

• 선결제 금액이나 장기 약정 없이 저렴하게 EC2를 사용하기 원하는 사용자
• 단기의 갑작스럽거나 예측할 수 없는 워크로드가 있으며, 중단되어서는 안되는 애플리케이션
• EC2에서 처음으로 개발 또는 시험중인 애플리케이션

 

 

스팟 인스턴스

Amazon EC2 스팟 인스턴스를 사용하면 온디맨드 요금보다 최대 90% 할인된 가격으로 EC2 컴퓨팅 용량을 요청할 수 있다. 

다음과 같은 상황에 적합하다. 

 

• 시작 및 종료 시간이 자유로운 애플리케이션
• 컴퓨팅 가격이 매우 저렴해야만 수익이 나는 애플리케이션
• 대량의 서버 용량 추가로 급하게 컴퓨팅 파워가 필요한 사용자

 

 

예약 인스턴스

예약 인스턴스를 사용하면 계약 기간에 따라 최대 60%까지 저렴하게 이용이 가능하다.

다음과 같은 상황에 적합하다.

 

• 수요가 꾸준한 애플리케이션
• 예약 용량이 필요할 수 있는 애플리케이션

 

 

 

 

 

 

 

 

9. 아키텍쳐적 트레이드오프 (RDS vs EC2)

 

Amazon RDS(Relational Database Service) 란? 

: Amazon RDS는 AWS 클라우드에서 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스 

• RDS 사용시 DB 관리 작업을 대신 해주기 때문에 각 서버 구성 요소를 독립적으로 확장할 수 있고, 백업 및 복구 관리, 스냅샷 관리 및 보조 인스턴스로 가용성을 향상시킬 수 있다.
• 또한 이미 친숙한 MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL server같은 DB 제품들을 사용할 수 있다. 
• VPC를 사용하여 가상 사설 클라우드에서 인스턴스를 실행할 수 있다. 
• 여러 AZ에서 DB 인스턴슬르 실행할 수 있다. (다중 AZ 배포) 이 방법을 사용하면 데이터 중복 및 장애 조치를 지원하고, 다른 가용 영역에서 자동으로 프로비저닝하고 유지한다. 

 

 

 

 

 

기존 개발 환경과의 통합 및 확장형 아키텍쳐 구축

기존 환경을 유지하며 클라우드를 추가로 통합해서 하이브리드 구성이 가능하다.

 

 

 

 

 

탄력성 및 확장성

기존 웹 애플리케이션 호스팅 아키텍쳐의 사례

 

 

기존 웹 호스팅 아키텍쳐는 구조를 presentation, application, persistent layer로 구분하는 3계층 웹 애플리케이션 모델을 중심으로 설계된다. 이 아키텍쳐는 presentation, persistent 또는 application layer 에 호스트를 더하는 방식으로 확장할 수 있게 설계되었고, 필요 성능, 장애 조치, 가용성을 갖추고 있다. 

 

 

이러한 아키텍쳐를 AWS 클라우드로 이전하는 방법은 아래와 같다.

 

 

 

기존 애플리케이션 호스팅 솔루션을 AWS 클라우드로 이전하는 것에는 어떤 가치가 있을까?

• 과도한 서버 대신 효율적인 비용으로 트래픽 최고치를 처리
• 예측하지 못한 트래픽 피크를 처리하는 확장성 솔루션
• 테스팅, 로드, 베타 및 사전 생산 환경을 위한 온디맨드 솔루션 

 

 

 

 

 

 

 

RDS의 고가용성 (다중 AZ)

다중 AZ 배포에서 Amazon RDS는 자동으로 서로 다른 AZ에 동기식 예비 복제본을 프로비저닝하고 유지한다. 

DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 향상시킬 수 있으며, DB에 인스턴스 오류 및 가용 영역 중단이 일어나는 것을 방지할 수 있다.

RDS 콘솔을 사용해 다중 AZ 배포를 간편하게 사용할 수 있다. 

 

 

 

 

 

 

 

 

Amazon CloudWatch 를 사용하여 Auto Scaling 인스턴스 및 그룹 모니터링

• 모든 EC2 지표 인스턴스를 통계로 사용하여 시스템이 예상대로 수행되는지 확인 가능
• 평균 CPU 사용률에 대해 지표를 생성하여 감시하는 것이 가능
• 무료는 5분 단위로 감시 가능, 비용을 더 지불할 경우 1분 단위로 감시 가능

 

 

 

 

Auto Scaling 그룹에 로드 밸런서 사용

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 실행중인 모든 EC2 인스턴스에 자동으로 분산한다. 

또한 단 하나의 인스턴스에도 부하가 걸리지 않도록 트래픽을 최적으로 라우팅하여 들어오는 요청을 관리할 수 있게 해준다.

 

로드 밸런서는 인스턴스가 늘어났을 경우 로드밸런서에 등록하여 자동으로 트래픽이 들어가게 하고, 제거되면 자동으로 해제하여 트래픽이 오지 않도록 한다.