AWS 인프라 아키텍쳐 교육

※ 본 포스팅은 Amazon Web Services 공식 교육 파트너 슈퍼트랙 - AWS 인프라 아키텍쳐 과정(3일)에서의 강의내용을 참고하여 작성하였습니다.

 

 

1일차

 

1. 교육 과정 소개 

- AWS 기초 및 기본 인프라 구성에 필요한 용어 설명

- 특장점 : Well-Architectured Framework 기능, Global infastructure 구성 가능

 

1) 인프라 단위 (큰 단위 순)

: Region(리전) > AZ(Available Zone, 가용 영역)

 

 

* Region, 리전이란?

- 쉽게 말해 지리적 위치를 말하며 AWS 서비스 이용 시 서버가 위치하는 지역을 뜻함

   ※ 서비스 하려는 지역의 주 고객이 어느 지역에 위치하는지를 고려하여 인프라를 구성해야 함 (고객과 가까운 리전이 당연히 좋음)

   ※ AWS는 지역에 따라 동일한 서비스, 상품이더라도 가격 차이가 발생한다. 해당 지역의 IDC센터의 부동산 가격, 임대 시세 등을 고려한다고 함

 

- AWS가 전 세계에서 데이터 센터를 클러스터링 하는 물리적 위치

- 각 AWS 리전(서울, 미국 동부 등)은 지리적 영역 내에서 격리되고 물리적으로 분리된 여러 개의 AZ로 구성 (최소 2개 이상의 AZ)

- AWS 데이터 센터의 위치는 비공개

- AWS 공식 홈페이지 

※ 참고 URL :  https://aws.amazon.com/ko/about-aws/global-infrastructure

 

* AZ(Available Zone), 가용영역이란?

- 여러 DataCenter의 조합, 클러스터 및 이중화 방식으로 구성 즉, 데이터센터의 클러스터로서 한 리전에는 여러 가용 영역이 존재한다.(한 리전당 최소 2개 이상의 AZ)

- AZ <-> AZ 또는 AZ 내의 Data Center끼리의 데이터 전송은 AWS 전용 네트워크를 통해 이루어짐 

  → 별도 네트워크로 이루어져 공개된 인터넷에 비해 안전하고 속도가 빠름

  → 빠르게 데이터를 백업하고 데이터를 이전할 수 있는 구조

- 각각의 다른 가용영역의 장애로 부터 격리됨

  ex) 서울리전의 2개의 AZ가 존재하는 상태에서 1개의 AZ가 장애가 발생하더라도 나머지 1개의 AZ에서 서비스가 가능한 구조이며 위험 분산이 가능하다.

- AWS 공식 홈페이지

* VPC 생성 -> 리전 선택 -> VPC를 구성 시 해당 리전에 존재하는 AZ가 자동 생성, AZ를 선택하여 네트워크 구성

- Local Zone : LA에 1개만 존재. EC2, RDS와 같은 서비스를 가장 근처의 로컬 지역에서 서비스를 받아 속도향상을 느낄 수 있도록 하는 서비스이다.

 

 

 

2019년 2월 기준 리전 맵

 

 

  ※ 장애 사례 (2019.11.22 / 서울 리전 장애)

 - 오전 시간 약 84분간 발생

 - 배달의민족, 쿠팡, 야놀자, 마켓컬리, 여러 암호화폐거래소, 신한은행 등의 사업자와 일반 사용자들에 대해 크고 작은 피해가 발생

 - 장애가 발생한 기업들의 공통점 서울 리전에만 AWS를 구축해놓은 기업 또는 사용자들

   → 당시 대안으로 얘기가 나왔던 것이 멀티클라우드

   → 일본 등 다른 지역의 AWS 리전으로 멀티 클라우드를 적용한 기업들은 해당 장애를 피할 수 있었기 때문

 

 - 일반적으로 AWS와 기업들은 SLA(서비스레벨어그리먼트) 99.95% 서비스 수준 계약을 체결 한다. (SLA 99.95%란 한 달에 4시간 이상 서비스 장애가 발생해야만 보상을 제공한다는 내용)

   → 고객에게 불리할 수 있는 조항이며, 추후 장애가 발생하지 않는다는 보장도 없다.

   → 1분 1초도 용납하지 않거나 서비스가 중지되는 사태를 멀티클라우드로 대응 가능할 것으로 보이지만, 비용적인 측면에선 부담이 된다.

 

2) Edge Location : Region과 별도의 데이터센터이며, 딱 4가지의 서비스만 Edge에서 제공

 - Cloudfront(CDN), Route53(DNS), WAF(웹방화벽, Shield(DDoS 대응)

-  엣지 로케이션(Edge Location)은 AWS의 CDN 서비스인 CloudFront를 위한 캐시 서버이다.

- Edge와 Region내의 AZ 또한 AWS 전용 네트워크를 통해 연결되어 있음

- Regional Edge Caching에서 캐싱이 만료되거나 주로 바뀌지 않는 데이터들이 Regional Edge Caching에 저장되며, 자주 바뀌는 데이터는 Edge Region에 저장

- CDN 캐시 서버는 인터넷 트래픽을 효과적으로 처리할 수 있는 지역에 POPPoint-of-Presence을 구축하며, CDN 서비스와 사용자가 직접 만나는 곳이라고 하여 엣지(Edge)라고 부르는 것이다.

  ※ 엣지 로케이션

      : AWS의 에지 로케이션은 CloudFront뿐만 아니라 DNS 서비스인 Route 53도 함께 제공

      : AWS의 에지 로케이션은 2014년 8월 기준으로 약 51개가 있으며 우리나라 서울에도 구축

- Amazon CloudFront 의 장점

  : Amazon CloudFront를 사용한다면 빠르고 안전한 콘텐츠 전송 뿐만 아니라, 높아지는 클라우드상의 데이터 전송 비용도 절감 할 수 있음

* Super POP Architecture : AWS 클라우드 구축 / 운영 Know-How가 담긴 고성능/대용량 아키텍처

* 한국내 최대 Capacity / 가장 빠르게 성장하는 글로벌 CDN 서비스

* Single-Service : (캐싱, 다이나믹 가속, HTTPS, AWS Shield Standard 등) 동일 가격 체계로 제공

* AWS Backbone 전용망 : Edge <-> Origin 가속 서비스로 활용

* 인라인 DDoS 방어 : CloudFront이용만으로 Shield Standard 무료 적용으로 Layer3&4 DDoS 방어

* 최상의 Routing : 지연시간 기준으로 최상의 라우팅 룰 적용.

--->  https://fitcloud.github.io/Service-ContentsDelivery/

 

 

2. 가장 간단한 아키텍쳐 

- S3 

- S3 Glacier

- Snowball

- Snowmodule

 

1) S3 (Simple Storage Service, Object Storage)

- S가 3개라서 S3, 만드는 순간 URL이 제공되며 이것 자체로 웹 서버를 만드는 것과 동일한 효과 - 단순한 정적 사이트를 만들때 유용

- 파일서버 구축 시 S3를 파일서버로 사용 가능, FTP 제공, 용량 무제한(대용량데이터, 내구성, 백업용, 로그수집 등)

- 클라우드 프론트로 S3 생성 시 S3에 대한 비용이 추가되지 않음.

- S3는 가용성 측면에서 여러 AZ에 걸쳐서 저장이되어 장애 대응이 가능하다.

- 객체 스토리지이기 때문에 API 호출 방식이다.

- 객체 스토리지는 파일 변경 시 해당 파일에 대한 데이터가 덮어쓰기를 한다. 그리고 이전 버전의 파일은 보관하여 버전관리를 한다.

- 파일 하나하나가 객체, 즉 object라는 개념으로 말한다. S3가 객체 스토리지이기 때문에.

- S3에서는 도메인 뒤 하위 경로에 대한 구분이 없다. 하위 경로와 상위 경로 모두 도메인 다음부터는 키로 관리한다. 왜? 파일시스템 구조가 아니기 때문에. 그렇기 때문에 인덱싱이 불가하여 API호출에 따른 요청이 증가하여 인덱싱 기능을 별도로 구현하여 사용하는 경우도 있다.

- 스냅샷 저장도 S3에 한다.

- S3로 데이터 이동 흐름

ex)업로드 시 100MB 가 넘는 파일의 경우 api를 이용한 멀티파트 업로드 기능 사용을 권고하고 있다.

 

<arn 형식>

arn : amazon resource name

arn:aws:s3:::

arn:aws:서비스이름:리전코드:계정ID:버킷이름/*

 

- CORS

: 여러개의 S3 끼리의 접근권한 관리

 

* 람다, 함수 기반, 호출을 해야 사용이 가능한데 S3를 통해 가능하다?

ex) S3의 업로드되는 순간 이벤트 트리거를 통해 람다함수를 사용 가능한다. 예로 image를 람다함수를 호출하여 image 사이즈 변경 등의 작업이 가능하다.

 

on primise -> AWS S3

: AWS Snowball - 페타바이트 규모의 데이터 전송

: AWS Snowmobile - 엑사바이트 규모의 데이터 전송

 

* 비용 (기존 스토리지 서버는 구입 후 비용 발생 없음, 네트워크 회선 관련 제외하고는. 하지만, S3는 서비스의 고객이 증가하면 비용도 증가, HTTP 요청에 대한 증가 시 비용 증가, 다른 리전 또는 인터넷으로 전송 시 비용 증가, 업로드 비용 발생없음

 

* S3 Glacier(글래셔)

- S3 비용이 비싼건 S3

저장비용이 저렴한 것은 글래셔

- 실시간 검색이 안됨

- 엑세스가 적을 수록 글래셔

- 볼트(저장소) 생성 - 아카이브(audit)

access에 대한 비용이 비싸고 access할 일이 없으면 글래셔가 낫다.

 

수명주기정책으로 S3 레벨별로 기간별 자동으로 객체를 삭제 또는 이동이 가능

 

* 특별한 리전이 존재 - 미국정부, 중국 내 중국 정부에 승인하에. (공개X)

* 인공위성 서비스 - 미국리전만 가능

비용은 리전별로 다르다. 똑같은 EC2 등 모든 서비스 관련

제일 저렴한 곳은 미국

우리나라도 비싼 편

 

 3. 컴퓨팅 계층 추가 

- EC2, EBS, EFS, FSx

 

1) EC2

 

m5.large

m : 패밀리이름

5 : 세대번호

large : 인스턴스 크기

 

계속 바뀜

 

2) EBS (Block Storage)

- Storage이며, EC2에 Attach하여 사용해야 한다. 

- EBS는 AZ안에서 중복 저장

- 자주 변경되는 데이터의 경우 Block Storage가 효율적 -> 원하는 파일시스템 정해서 사용 가능

- 파일 변경 시 해당 파일의 block 일부분만 변경

 

3) EFS 같은 경우 ext4, ntfs 등 파일시스템이 정해져 있다.

- EC2에 Attach하여 사용해야 한다. 

 

* Lustre (Linux cluster?)

t에만 있는 버스트 기능 : 시간당 CPU 크레딧을 소모하면서 성능을 늘려줌?

 

 

4. 데이터베이스 계층 추가 

- RDS, Aurora, DynamoDB(NoSQL 서비스), Data Migration Service, Snowball Edge

ex) mysql, oracle 등

* AuroraDB와 DynamoDB는 AWS에서 만든 서비스

 

* 백업, 이중화, 암호화 등을 GUI 클릭으로 구현 및 관리 가능

 

5. AWS 기반 네트워킹 1부 - VPC, ENI, EIP

VPC를 생성하여 EC2 사용 가능

 

 

 

2일차

 

1. AWS 기반 네트워킹 2부

- VGW, Direct Connect, VPC Peering, VPC Endpoint, Transit Gateway, ELB, Route53

 

1) VPC (Virtual Private Network, 가상 프라이빗 클라우드)

- VPC란 AWS 클라우드 상에서 네트워크를 구성하기 위한 기능으로서 VPC를 적용하면 각각의 VPC 별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동한다.

- VPC 구축 시에는 사설IP대역에 맞추어 구축한다. (RFC1918)

- 한번 설정된 IP대역은 수정할 수 없으며 각 VPC는 하나의 리전(서비스 지역, 서울, 싱가폴, 미국 동부 등등)에 종속된다. 각각의 VPC는 완전히 독립적이기때문에 만약 VPC간 통신을 원한다면 VPC 피어링 서비스를 고려해볼 수 있습니다.

 

2) 서브넷

 

VPC를 만들었다면 이제 서브넷을 만들 수 있습니다. 서브넷은 VPC를 잘개 쪼개는 과정입니다. 서브넷은 VPC안에 있는 VPC보다 더 작은단위이기때문에 연히 서브넷마스크가 더 높게되고 아이피범위가 더 작은값을 갖게됩니다. 서브넷을 나누는 이유는 더 많은 네트워크망을 만들기 위해서입니다.

각각의 서브넷은 가용영역안에 존재하며 서브넷안에 RDS, EC2와같은 리소스들을 위치시킬 수 있습니다.

 

3) 라우팅 테이블과 라우터

네트워크 요청이 발생하면 데이터는 우선 라우터로 향하게됩니다. 라우터란 목적지이고 라우팅테이블은 각 목적지에 대한 이정표입니다 데이터는 라우터로 향하게되며 네트워크 요청은 각각 정의된 라우팅테이블에따라 작동합니다. 서브넷A의 라우팅테이블은 172.31.0.0/16 즉 VPC안의 네트워크 범위를 갖는 네트워크 요청은 로컬에서 찾도록 되어있습니다. 하지만 그 이외 외부로 통하는 트래픽을 처리할 수 없습니다.이때 인터넷 게이트웨이를 사용합니다.

 

4) 인터넷 게이트웨이

인터넷게이트웨이는 VPC와 인터넷을 연결해주는 하나의 관문입니다. 서브넷B의 라우팅테이블을 잘보면 0.0.0.0/0으로 정의되어있습니다. 이뜻은 모든 트래픽에 대하여 IGA(인터넷 게이트웨이) A로 향하라는뜻입니다. 라우팅테이블은 가장 먼저 목적지의 주소가 172.31.0.0/16에 매칭되는지를 확인한 후 매칭되지 않는다면 IGA A로 보냅니다.

인터넷과 연결되어있는 서브넷을 퍼블릭서브넷, 인터넷과연결되어있지않는 서브넷을 프라이빗서브넷이라고합니다.

 

5) 네트워크 ACL과 보안그룹

네트워크 ACL과 보안그룹은 방화벽과 같은 역활을 하며 인바운드 트래픽과 아웃바운드 트래픽 보안정책을 설정할 수 있습니다. 먼저 보안그룹은 Stateful한 방식으로 동작하는 보안그룹은 모든 허용을 차단하도록 기본설정 되어있으며 필요한 설정은 허용해주어야합니다. 또한 네트워크ACL과 다르게 각각의 보안그룹별로도 별도의 트래픽을 설정할 수 있으며 서브넷에도 설정할 수 있지만 각각의 EC2인스턴스에도 적용할 수 있습니다.

네트워크 ACL은 Stateless하게 작동하며 모든 트래픽을 기본설정되어있기때문에 불필요한 트래픽을 막도록 적용해야합니다. 서브넷단위로 적용되며 리소스별로는 설정할 수 없습니다. 네트워크ACL과 보안그룹이 충돌한다면 보안그룹이 더 높은 우선순위를 갖습니다.

 

6) NAT게이트웨이

NAT 게이트웨이는 프라이빗서브넷이 인터넷과 통신하기위한 아웃바운드 인스턴스입니다. 프라이빗 네트워크가 외부에서 요청되는 인바운드는 필요없더라도 인스턴스의 펌웨어나 혹은 주기적인 업데이트가 필요하여 아웃바운드 트래픽만 허용되야할 경우가 있습니다. 이때 퍼블릭 서브넷상에서 동작하는 NAT 게이트웨이는 프라이빗서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷게이트웨이와 연결합니다.

 

7) 마무리

VPC의 목적은 다양할 수 있지만 일반적으로 보안을위해 AWS 리소스간 허용을 최소화하고 그룹별로 손쉽게 네트워크를 구성하기위해 많이사용합니다.이외에도 독립적인 VPC간 네트워크 통신을 위한 VPC피어링, 기존 사용하는 온프레미스와 VPC를 연결하는 AWS Diarect Connect, VPC에서 발생하는 로그를 기록하는 VPC FLow Logs와같은 서비스가 있습니다.

 

 

 

2. AWS IAM 

- IAM, TST, Cognito, Organizations

 

3. 탄력성, 고가용성 및 모니터링 

- CloudWatch, CloudTrail, VPC Flow Log, Auto Scailing

 

4. 자동화 

- CloudFormation, Quick Starts, Systems Manager, OpsWorks, Elastic Beanstalk

 

 

 

 

 

3일차

 

1. 캐싱 

- Cloudfront, DynamoDB, Accelerator(DAX), ElastiCache(DB캐싱, redis 및 memcache 서비스 제공)

 

* Cloudfront에 WAF의 Web ACL을 적용이 가능하다.

여기서 WAF란 AWS 제공 WAF인가??

 

* Origin에서 Cloudfront에 캐싱되는 데이터에 대한 비용은 청구되지 않음

 

* 주로 S3에 저장된 정적인 데이터에 대해 캐싱을 하여 동적인 데이터를 처리하는 EC2와 트래픽 부하 분산이 이루어짐

 

* Edge Location에는 구성정보만 전달이 된다 전세계 250여개에. 그리고 실제 요청이 들어올 때 근접한 Edge Location에 의해 데이터를 전송한다.

 

* TTL

: 기간 고정(만료 기간)

: 고객이 설정

: 배포를 잘 못했을 경우 -> 객체 이름 변경(파일 이름 변경, 여기서는 어플리케이션에서도 변경이 필요), 객체 무효화(마지막 수단, 비효율적, 비용이 발생), 캐시 날리기

 

* 클라우드프론트를 앞단에 두는 경우, 도메인 사용, DDoS 등 보안에 대응, 엣지 로케이션 과 오리진은 AWS Network로 연결(외부 인터넷이 아닌)이기 떄문에 속도 등 성능이 좋고 이러한 장점 때문에 동적 컨텐츠의 경우 캐싱이 되지 않음에도 불구하고 앞단에도 클라우드프론트를 적용하도록 권고하고 있다.

 

* Lambda Edge라는 서비스가 있다. 그냥 Lambda는 리전에서 실행.

 

* AWS DDoS 및 웹 보안 서비스

: WAF를 사용하게 되면 Web ACL을 설정할 수 있다. 클라우드프론트에 기능이 있는 것은 아니다.

 

* 세션 정보를 AZ 내의 EC2에 저장하면 안된다. ALB를 사용할 경우 라운드로빈 방식으로 번갈아가며 요청을 던지기 때문, 그렇기 때문에 세션은 DynamoDB나 Elasticache에 저장해야한다. 또한  스티키 세션(고정 세션)이라고 하여 특정 EC2에 고정하여 요청을 하는 방법도 있지만 장애 떄문에 권장하진 않는다. 

 

* Elasticache는 컴퓨팅 기능이 없다. 단순 데이터 저장. 그래서 어플리케이션에서 코딩을 통해 Elasticache와 Database에서 알아서 데이터를 찾아가도록 해야한다. 즉, Elasticache에 없으면 다시 Database에 요청하는 방식

 또한 Redis가 조금더 고급기능. Redis는 버전 별 기능이 다르고, Redis에서 지원하는 것과 Elasticache 지원 여부의 차이가 있을 수 있다. 버전별.

 

2. 인프라 자동화 - Cloudformation

 

* 템플릿 하나를 통으로 만드는 것은 권장하지 않음

* 스택 업데이트 시 검사 및 실행 여부 결정의 절차를 거친다.

* 권장하는 아키텍쳐 -> 계층화된 아키텍쳐 즉, 계층 별로 아키텍쳐를 구성하는 것을 권장

- 프론트엔드

- 백엔드

- 공유

- 기본 네트워크

- 자격 증명

 

배포자동화

 

* AWS System manager

ssh key pair 유출을 방지하기 위하여 브라우저 상에서 터미널로 접근하도록 하는 서비스도 잇음

 

<상위 수준 서비스>

* AWS OpsWorks : 구성 관리 서비스 (구성 서버를 쉽게 만들 수 있게 제공)

* AWS Elastic Beanstalk

 

<DIY>

AWS CloudFormation

Amazon EC2

 

3. 결합 해지된 아키텍처 구축 

- SQS, SNS (queue 서비스)

 

* 아키텍쳐 결합 해제

 

4. 마이크로 서비스 및 서버리스 아키텍처 

- ECS, ECR, Fargate, Lambda(요청이 들어오면 요청에 대해서만 처리하며, 24시간 동작 서비스에 비해 그떄 그때 처리가능하며, 비용도 그떄그때 발생한 것만), API Gateway, Step Functions(람다 구성 시 순서도를 구려줌?), EKS(elastic 쿠버네트시 서비스)

 

5. RTO/RPO 및 백업 복구 설정 

 

- AWS Storage Gateway

 

<실습>

정적 웹 사이트 호스팅 (S3 관련, 권한 대부분 있음)

AWS 상에 웹 애플리케이션 배포

가상 사설 클라우드 생성

고가용성 환경 생성(ALB)

AWS CloudFormation을 사용한 인프라 배포 자동화

AWS 관리형 서비스로 서버리스 아키텍쳐 구현

 

* Trusted Advisor - 인프라 구성 시 보안, 안정성, 비용최적화, 성능 효율성, 운영 탁월성 등 5가지 핵심 요소에 대해 간단히 테스트 해볼 수 있는 테스트이며 무료이다.