[AWS] 알아두어야 할 CS 개념

Computing

클라우드의 가상 서버를 작동하는 것.

AWS Batch로 배치 작업을 실행할 수도 있고, Elastic Beanstalk로 웹 앱을 실행하고 관리할 수 있다.

Lambda는 이벤트에 대한 응답으로 코드를 실행한다.

따라서, Computing이란 컴퓨터(서버)가 어떤 앱(코드)를 실행하는 것을 의미한다.

Cost management

클라우드 서비스의 가상 서버나 서비스를 이용하면 이용료가 청구된다. 

Cost Explorer나 Budgets 및 비용 및 사용 보고서를 참고하여 고효율 저비용으로 관리하는 것이 비용 관리이다. 

Database

데이터 저장소.

 

1. 관계형 데이터베이스 - Aurora, RDS

데이터의 종속성을 관계로 표현하는 데이터베이스로, 테이블 구조를 이룬다.

- 데이터의 분류, 정렬, 탐색 속도가 빠름

- 데이터 무결성 보장 (ACID 속성 제공)

   => Atomicity: 완벽하게 실행하거나, 전혀 실행되지 않아야 함

   => Consistency: 트랜잭션이 커밋되면 데이터가 스키마를 준수해야 함

   => Isolation: 동시에 일어나는 트랜잭션들이 각기 별도로 실행되어야 함

   => Durability: 시스템장애 시 마지막으로 알려진 상태로 복구되어야 함

- 스키마 수정이 어려움

- 데이터베이스 부하 분석이 어려움

 

2. NoSQL 데이터베이스 - DynamoDB

특정 데이터 모델에 대해 특정 목적에 맞추어 구축되는 데이터베이스.

- 유연성: 유연한 스키마

- 레코드는 JSON 문서로 저장됨

- 확장성: 분산형 하드웨어 클러스터를 이용해 확장하도록 설계됨(단순한 up-scaling x)

- 고성능: 특정 데이터 모델 및 액세스 패턴에 대해 최적화

- 고기능성: 각 데이터 모델에 최적화된 API 제공

- key value, document, graph, in memory, search로 유형이 나뉜다.

 

3. 문서 데이터베이스 - DocumentDB

JSON 유사 형식의 문서로 데이터를 저장 및 쿼리하도록 설계된 NoSQL 데이터베이스 유형.

- 데이터 모델을 변경해도 스키마를 업데이트하거나 데이터베이스를 중단할 필요가 없음

- 유연한 인덱싱

- document 모음에 대한 분석 지원

 

4. 인 메모리 캐싱 시스템 - ElastiCache

데이터베이스가 데이터를 하드 디스크가 아닌 메인 메모리에서 검색하는 것을 말한다. 

 

- 데이터베이스 쿼리 요청과 관련한 지연 시간 단축

- 성능 개선

- 비용 절감

- 예측 가능한 성능

- 데이터베이스 핫스팟 제거

- 읽기 처리량 증가

Disaster recovery

DR은 장애나 재난으로부터 대응하고 복구하는 과정을 일컫는다.

인프라나 서비스에 장애가 발생하더라도 동적으로 컴퓨팅 리소스를 요구에 맞게 충족시켜야 한다 (탄력성이라 한다).

https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html

Disaster recovery

  : 단발성 이벤트를 측정함

Availability (가용성)

  : 일정 구간의 시간 동안의 중간값을 측정한다. (사용가능한 시간 / 전체 시간)

    request로 측정할 수도 있다. (성공한 response 수 / 유효한 request 수)

=> DR과 availability는 데이터에 접근하는 방법이 다르다. 

 

Disaster란?

 - 자연 재해. 홍수나 지진.

 - 기술적 실패. 전원이나 네트워크 연결 문제

 - 인위적인 행위. 설정값 오류나 권한 설정 실수

=> production환경 데이터 공격은 다른 리전에 있는 백업 데이터로 복구할 수 있다.

 

RTO (Recovery Time Objective)

: 최대한 수용 가능한 지연 시간

 

RPO (Recovery Point Objective)

: 최대한 수용 가능한 양의 데이터 복구에 걸리는 시간

 

DR 전략 (아래로 갈수록 비싸고 안전함)

1) backup & restore: 이벤트 발생 후 데이터를 복구함

=> snapshot이나 backup 서비스를 사용한다. S3는 Replication이 존재한다.

2) pilot light: 이벤트 발생 후 자원을 스케일링함

=> RPO를 줄이기 위해 지속적으로 데이터를 복제한다. Replication서비스나 global db, table을 사용하면 된다.

3) warm standby: 이벤트 발생 후 자원을 더 빨리 스케일링함

=> Auto scaling 서비스

4) multisite active: 서비스가 다운되지 않음. 엄청 비쌈

=> 자원 이중화

High availability

서버와 네트워크 등의 시스템이 오랜 기간 동안 지속적으로 정상 운영이 가능한 것을 의미한다.

Management and governance

https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-lens/management-and-governance-lens.html

마이그레이션 할 때 쓰이는 6가지 패턴들 (6 Rs)

- Retire: 안씀

- Retain / Revisit: 비지니스에 꼭 필요한 것만 먼저 이전하고 나머지는 나중에 이전

- Re-purchase: SaaS 모델을 쓰다가 이전할 때

- Re-platform: 아키텍처는 유지하되 서비스는 최적화된걸로 변경

- Re-host: 변경없이 바로 호스팅

- Re-factor / Re-architect: monolithic한 아키텍처를 마이그레이션 할 때

 

Microservices and component decoupling

마이크로서비스는 빠르게 소프트웨어를 배포할 수 있는 아키텍처적 접근이다. 마이크로서비스 접근법을 사용하면 소프트웨어는 잘 정의된 API로 소통하는 작은 서비스들로 구성된다. 애자일한 접근법이 적합하다.

 

3가지 패턴

1) API Driven

2) Event driven

3) Data streaming

 

Component decoupling

컴포넌트 패턴을 사용해서 분야별로 컴포넌트를 나누고, 컴포넌트 간 서로를 알지 못하게 한다. 컴포넌트들은 하나의 컴포넌트 클래스에 두지만, 컴포넌트 클래스는 컨테이너 역할만 수행한다.

Migration and data transfer

마이그레이션

: 한 운영환경으로부터 다른 운영환경으로 옮겨가는 과정

Networking, connectivity, and content delivery

- AWS Cloud Front

=> CDN (Content delivery network) 서비스.

=> S3의 파일을 주고 받을 수 있다.

- AWS WAF

=> Web access control list 관리할 수 있고, 리퀘스트에 따라 요청을 필터링할 수 있다.

=> IP를 제한할 수도 있다.

=> AWS Shield Advanced 구독하면 AWS DDoS Response Team의 지원을 받을 수 있다.

Security

https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/welcome.html

AWS Security Best Practices - AWS Security Best Practices

Identity & Access Management

=> 권한 관리

Detection & Incident Response

=> 보안 사고 대응

Infrastructure Protection

=> WAF 보안 자동화, DDoS 공격 방어

Data Protection

=> key 관리, 암호화, 데이터 분류 등

Compliance

=> 법률, 정책

 

Serverless design principles

1. 수요에 맞게끔 컴퓨팅 서비스를 사용해라 (커스텀 환경 지양)

2. 단일 목적, 무상태의 함수를 만들어라 (SRP)

3. push 기반, event 기반 파이프라인을 디자인해라

4. 프론트엔드에 로직을 넣어라

5. 서드 파티 서비스를 활용해라 (커스텀 환경 지양)

 

Storage

S3(Simple Storage Service)

=> bucket에 데이터를 저장

 

AWS Storage Gateway

1) 파일 게이트웨이

- S3 버킷을 공유하여 NFS나 SMB 프로토콜로 접근할 수 있게 함

- 파일을 S3 객체로 변환

 

2) 볼륨 게이트웨이

- S3를 캐시 볼륨이나 저장 볼륨으로 사용함

- 캐시 스토리지로 사용할 경우 액세스 지연 시간을 줄일 수 있고, 기존 파일 저장소 크기의 최소 20%가 되어야 함

- 업로드 버퍼로 사용한다면 버퍼 데이터를 SSL연결을 통해 S3에 암호화되어 저장함.

 

- 저장 볼륨은 기본 데이터를 로컬에 저장하지만, AWS에도 저장하여 지연 시간 단축시킴.

- 비동기 방식으로 S3에 백업됨

- 온프로미스 방식(on-promise)

 

3) 테이프 게이트웨이

- 데이터 아카이브 솔루션

- VTL(가상 테이프 라이브러리) 인터페이스로 가상 테이프 카트리지에 데이터 저장함.

 

캐시 스토리지: 업로드 버퍼에서 S3로 업로드될 때까지 대기중인 데이터 저장소
업로드 버퍼: 데이터 업로드 전 게이트웨이에 스테이징 영역 제공하여 복구 시점을 생성하는 데 중요한 역할 수행.
=> 데이터를 게이트웨이에 쓸 때 데이터를 위 두개 모두로 복사한 후 작업 완료를 승인함.

 

 

 

(참고)

https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html

Implementing Microservices on AWS - Implementing Microservices on AWS

https://lipcoder.tistory.com/entry/13%EC%9E%A5-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%ED%8C%A8%ED%84%B4-Component-Pattern

13장. 디커플링 - 컴포넌트 패턴 (Component Pattern)