Jinlib

Amazon RDS

Jinlib — Thu, 9 Jun 2022 20:05:07 +0900

RDS overview

정의:
AWS의 데이터베이스를 위한 관리형 데이터베이스(Relational Database Service) + 여러 기능

유형
1. PostgresQL 포스트그레스큐엘
1. MySQL
1. MariaDB
1. Oracle
1. MS SQL Server
1. Aurora(AWS Proprietary database)

기능(왜 자체 DB 배포안하고 RDS를 사용할까?)
1. Automated 프로비저닝
1. Automated OS Patch
1. Automated 백업 + 타임스탬프
  1. 매일 DB 전체 백업, 5분마다 일일 트랜잭션 로그 백업 ⇒ 어떤 지정 시점으로 DB 복원 가능
1. 모니터링 대시보드를 통한 DB 성능 모니터링
1. 읽기 성능 향상을 위한 읽기 복제(Read Replicas)
1. 재해복구를 위한 Multi AZ
1. 업그레이드를 위한 유지보수
1. 확장성(Storage Auto Scaling)
  1. RDS DB 인스턴스를 동적으로 증가 할 수있다.
  1. 임계치를 선택해서 가용영역이 10%이하로 떨어지거나, 이 상황이 5분이상 진행되면, 자동으로 스토리지를 수정할 수 있다.
  1. 이렇게 워크로드를 예측할 수 없는 경우에 유용하다.
1. gp2 or io1을 통한 백업
1. 그러나! SSH를 통한 접근이 안된다.
RDS Read Replicas for read scalability
한개의 RDS에 너무 많은 요청을 받게 되면 최대 다섯개까지 읽기 복사(Read Replicas) 가 가능하다.
동일 가용영역(AZ), 리전 걸쳐서 생성이 가능하다.
두 읽기 전용 복제본 사이에 비동기식 복제가 발생한다. 비동기식이란 결국 읽기(Read)가 일관적으로 유지된다는 것을 뜻함. 애플리케이션에서 데이터를 복제하기 전에 읽기 전용 복제본을 읽어들이면 모든 데이터를 얻을 수 있다는 것을 의미한다.
Read Replicas Use Case
예를 들어서 평균적인 로드를 감당하고 있는
생산 데이터베이스가 있다고 해 봅시다
생산 데이터베이스에서는 메인 RDS 데이터베이스 인스턴스에 대한 읽기 및 쓰기가 수행됩니다 이때 새로운 팀이 와서 여러분의 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 한다고 해 보죠 보고 애플리케이션을 메인 RDS 데이터베이스 인스턴스에 연결하면 오버로드가 발생하고 생산 애플리케이션의 속도가 느려질 텐데 이런 현상은 피하고자 합니다 이때 여러분이 해결사로 나서서 새로운 워크로드에 대한 읽기 전용 복제본을 생성하는 겁니다 읽기 전용 복제본을 생성하면 메인 RDS DB 데이터베이스 인스턴스와 읽기 전용 복제본 간 비동기식 복제가 발생합니다 그다음 보고 애플리케이션이 생성한 읽기 전용 복제본에서 읽기 작업과 분석을 실행하게 되는 거죠 이 경우 생산 애플리케이션은 전혀 영향을 받지 않으니 완벽합니다 읽기 전용 복제본이 있는 경우에는 SELECT 명령문에만 사용하는 점을 명심해야 합니다 SELECT는 SQL의 키워드로 읽기를 의미하죠 따라서 데이터베이스 자체를 바꾸는 INSERT, UPDATE, DELETE 같은 키워드는 사용이 불가능합니다 읽기 전용 복제본은 읽기를 위함일 뿐이니 말이죠

Read Read Replicas - Network Cost

Read Replicas - Muli AZ(Avaliability Zone)
목적: 마스터 데이터베이스의 인스턴스 혹은 스토리지에 장애가 발생할 때 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 자동으로 조치를 취해주는것

RDS Security - 암호화 Encryption
- At rest encryption
AWS의 키 매니지먼트 서비스인 AWS KMS를 통해서 마스터 데이터베이스와 읽기 전용 복제본을 암호화할 수 있다. 또한 Oracle과 SQL 서버에서 TDE라고 하는 투명한 데이터 암호화 또한 가능하다.
- In-flight encryptio
  - SSL 인증서가 필요한 전송 중에서 RDS 암호화를 제공한다.
  - DB를 연결할때 신뢰성있는 인증서와 함께 SSL를 제공함
첫 번째 RDS 백업 암호화
- 만약, 암호화 되지 않은 RDS 데이터베이스에서 스냅샷을 생성하면 스냅샷 자체는 암호화 X
- 반면, 암호화된 RDS 데이터베이스에서 스냅샷을 생성하면 모든 스냅샷이 기본으로 암호화됨 (단, 기본 값은 아니다)
두 번째, 네트워크 보안
- 네트워크 보안의 RDS 데이터베이스는 일반적으로 프라이빗 서브넷에서 배포된다. 즉, 데이터베이스가 WWW에 노출되지 않도록 해야 합니다.
- RDS 보안은 RDS 인스턴스에 연결되어 있는 보안 그룹(Security Group)을 활용해 실행
세 번째, Access Management
- AWS RDS를 관리하는 사람만 제어할 수 있다. 데이터 생성, 삭제, read replicas 생성 등.
- DB 로그인을 하기 위해 Login OR IAM 기반 인증을 할 수 있다. 즉, DB 보안은 주로 데이터베이스 안에서 이루어지는것.

AWS Aurora

Aurora는 AWS의 사유 기술

사용법: Aurora는 호환 드라이버가 있어 Postgres와 MySQL 데이터베이스에 연결하면 실행가능

성능: 클라우드에 최적화 서비스로 RDS의 MySQL에서는 x5, Postgres에서는 x3 이상 향상된 성능

속도: 최대 15개의 read replicas 갖고 있을 수 있고, 복제속도도 훨씬빠르다(MySQL은 최대 5개 읽기복제)

비용: 비용이 20% $\uparrow$ , But, 규모 면에서 효율적 ⇒ 경제적.

하나의 마스터(상단의 M)와 여러개의 읽기 전용 복제본(상단의 R) 그리고 스토리지가 위처럼 작은 블록별로 자가 복구와 자동 확장이 실행된다.

AWS Aurora DB Cluster

공유된 스토리지 볼륨: 10GB에서 64TB로 자동 확장되는 기능을 갖고 있다.

마스터: 유일하게 스토리지에 기록할 수 있는 역할(Writer Endpoint 를 제공)
- 라이터 엔드 포인트(Writer Endpoint)는 DNS 이름으로 늘 마스터를 향해서 마스터 장애 시에도 클라이언트가 라이터 엔드 포인트와 통신해 올바른 인스턴스로 자동으로 리디렉션 시켜준다.
- 읽기 전용 복제본에 오토 스케일링 적용 가능(최대 15개의 읽기 전용 복제본 + 사용자 지정 읽기 수 지정)

Painpoint

오토 스케일링으로 애플리케이션이 읽기 전용 복제본의 URL을 추적하는 것이 어려워지면서 연결하기 어려워짐.

Solution: 리더 엔드포인트(Reader Endpoint)

Reader Endpoint는 라이터 엔드 포인트와 동일한 기능이 있는데 로드 밸런싱의 연결을 돕고 모든 읽기 전용 복제본에 자동으로 연결한다.

클라이언트가 Reader Endpoint에 연결할 때마다 읽기 전용 복제본 중 하나가 연결하는 식으로 로드밸런싱한다.

한 가지 알아야 할 것은 로드 밸런싱은 명령문 수준이 아니라 연결의 수준에서 발생한다.

More Features of Aurora

자동 장애 조치

백업 및 복원

격리(Isolation), 보안(security)

산업 규정 준수 기능(Industry compliance)

푸시 버튼식 오토 스케일링

자동 패치 w/ zero downtime

고급 모니터링

정기 유지 보수

백트랙(Backtrack): 언제든지 데이터를 복원할 수 있는 기능

Aurora Security

RDS와 같은 엔진을 쓰기 때문에 Postgres와 MySQL 선택 가능

KMS를 통한 미사용 데이터 암호화

자동 백업, 스냅샷, 복제본 암호화

SSL을 통한 전송 암호화

MySQL, Postgres와 동일한 프로세스입니다

IAM 토큰을 사용한 인증

보안 그룹을 통한 인스턴스 보호

SSH 연결 미지원

Aurora Advanced

PainPoint

리더 엔드 포인트에서 너무나도 많은 읽기 요청이 있어서 Amazon Aurora의 CPU 사용량이 증가하였다.

Solution: Replicas Auto Scaling을 사용한다.

위처럼 오토 스케일링 복제본을 설정할 수 있다. 이를 통해 Amazon 오로라 복제본이 추가되고 이후, 자동으로 Reader Endpoint가 이 새로운 Replica을 포함할 수 있도록 확장될 수 있다.

이 새 복제본은 트래픽을 수신하기 시작하고 전체 CPU 사용량을 낮추기 위해 좀 더 분산된 방식으로 읽기를 수행합니다. 이것이 오토 스케일링 복제본입니다

위처럼 2개는 r3.large 인스턴스를 사용하고 나머지 2개는 r5.2xlarge인 더 큰 인스턴스를 사용한다고 할때,

처음에는 Reader Endpoint로 Client의 요청을 모두 대응 하지만 Custom Endpoint를 추가로 만들어서 분석 쿼리를 실행하도록 한다. 이를 통해서 더 강력한 인스턴스를 적절한 일을 시키도록 한다.

추가적으로 성능이 더 좋은 r5.2xlarge인 애들을 토대로

Aurora Serverless

자동화된 데이터베이스 인스턴스화와 실제 사용을 기반으로 한 오토 스케일링을 제공

드물거나 간헐적이거나 예측할 수 없는 워크로드가 있을 때 유용 ⇒ 용량 계획을 수행할 필요가 없다.

비용절감: 스핀 업 상태인 오로라 인스턴스를 토대로 초당 비용을 지불하기 때문에 비용면에 효율적

클라이언트는 오로라에서 관리하는 Proxy Fleet과 통신하고 백엔드에서는 서버리스 방식으로

워크로드를 기반으로 많은 오로라 인스턴스를 생성한다. 그래서 미리 용량을 프로비저닝할 필요가 없다.

Aurora Multi-Master

Writer 노드에 대한 빠른 장애 조치를 원할때, 즉 Writer 노드에 대한 높은 가용성을 원하는 경우에 쓰인다.

오로라 클러스터에 있는 모든 노드가 Read와 Write 작업을 하는데, 만약 쓰기 노드가 하나만 있고 다운돼서실패하게 되면 Read Replicas을 새로운 마스터로 승격시킨다.

여기 오로라 인스턴스가 세 개 있습니다

서로 복제를 수행하고 있죠

공유 스토리지 볼륨이 있고

클라이언트는 데이터베이스 연결을 여러 개 갖습니다

모든 오로라 인스턴스는 쓰기 작업을 수행할 수 있고

만일 어떤 오로라 인스턴스가 실패하면

라이터 노드에 대한 즉각적인 장애 조치를 제공하는

다른 노드로 자동 장애 조치를 수행할 수 있습니다

이는 시험에서 출제될 사용 사례와 시나리오의 종류입니다

Gloal Aurora

오로라 리전 간 읽기 전용 복제본이 있다면
- 재해 복구 유용
- 간단한 구현

오로라 글로벌 데이터베이스
- 모든 읽기 및 쓰기가 발생하는 하나의 기본 리전이 있지만
- 최대 5개의 보조 읽기 전용 리전을 설정 가능(보조 리전당 복제본 지연시간(lag)이 1초 미만)
- 최대 16개의 읽기 전용 복제본을 가질 수 있습니다
  ⇒ 전 세계의 읽기 전용 복제본에 대한 지연 시간(latency)을 줄일 수 있다
- 어떤 리전에서 데이터베이스의 중단이 발생하더라도 RTO가 있으므로 복구 시간은 1분 미만이 될 것이다.

Aurora Machine Learning

SQL 인터페이스를 통해 애플리케이션에 ML 기반 예측을 추가할 수 있는 개념

오로라와 다양한 AWS 머신 러닝 서비스 간의 간단하고 최적화된 안전한 통합입니다

지원되는 두 서비스
- 백엔드에서 모든 종류의 머신 러닝 모델을 사용할 수 있는 SageMaker
- 감정 분석을 수행할 때 쓰는 Amazon Comprehend가 있죠

Usecase

사기 탐지, 광고 타겟팅 감정 분석

제품 추천입니다

Amazon ElastiCache

RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있죠

또한, ElastiCache는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 한다

캐시란 무엇일까요?

캐시는 높은 성능과 낮은 지연 시간을 가진 인 메모리 데이터베이스입니다

그리고 일래스틱 캐시를 사용하면 읽기 집약적인 워크로드의 부하를 줄이는데 도움이 됩니다.

이 개념은 일반적인 쿼리가 캐시 되어 데이터베이스가 매번 Query 날리지 않고 캐시는 이러한 쿼리 결과를 검색할 때 사용할 수 있는 것입니다

애플리케이션의 State를 Amazon 일래스틱 캐시에 저장해 애플리케이션을 Stateless 만들 수 있도록 합니다

RDS와 같은 장점을 갖기 때문에 AWS는 동일한 유지 보수를 수행합니다

운영 체제, 패치, 최적화, 설정, 구성, 모니터링, 장애 회복 그리고 백업을 수행

일래스틱 캐시를 사용할 때 애플리케이션에 관한 몇 가지 어려운 코드 변경을 요청할 수도 있습니다

단순한 활성화가 아니라 데이터베이스 쿼리 전과 후에 캐시를 쿼리하도록 애플리케이션을 변경해야 하죠

이제 일래스틱 캐시 사용을 위한 아키텍처를 살펴보겠습니다

여러 가지 중에서 예시를 하나 들어보죠

일래스틱 캐시와 RDS 데이터베이스 그리고 애플리케이션이 있고

애플리케이션은 일래스틱 캐시를 쿼리합니다

쿼리가 이미 생성됐는지

이미 생성되어 일래스틱 캐시에 저장됐는지 확인하는 것은

캐시 히트(cache hit)고

이는 일래스틱 캐시에서 바로 응답을 얻어서

쿼리하기 위해 데이터베이스로 이동하는 동선을 줄여줍니다

캐시 미스(cache miss)의 경우에는 데이터베이스에서 데이터를 가져와서

데이터베이스에서 읽습니다

동일한 쿼리가 발생하는 다른 애플리케이션이나 인스턴스에서는

데이터를 캐시에 다시 기록하여

다음에는 같은 쿼리로 캐시 히트를 얻도록 합니다

이는 RDS 데이터베이스에서 부하를 줄이는데 도움을 주는데

데이터를 캐시에 저장하기 때문에

캐시 무효화 전략이 있어야 하며

가장 최근 데이터만 사용하는지 확인해야 합니다

이것이 캐싱 기술 사용과 연관된 어려움이라고 할 수 있죠

다른 아키텍처는 사용자 세션을 저장해 애플리케이션을

무상태로 만드는 것입니다

사용자가 애플리케이션의 모든 계정에 로그인하면

애플리케이션이 일래스틱 캐시에 세션 데이터를 기록하는 것입니다

사용자가 애플리케이션의 다른 인스턴스로 리디렉션 되면

애플리케이션은 일래스틱 캐시에서

직접 세션 캐시를 검색할 수 있습니다

그래서 사용자는 계속 로그인한 상태로 한 번 더 로그인 할 필요가 없죠

사용자의 세션 데이터를

일래스틱 캐시에 기록해서 애플리케이션을

무상태로 만든 것입니다

레디스와 멤캐시트의 차이를 전반적으로 이해하는 것도

시험에 출제될 수 있습니다

레디스(Redis)는 자동 장애 조치로 다중 AZ를 수행하는 기술이며

읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높습니다

약간 RDS와 비슷합니다

그리고 지속성으로 인해 데이터 내구성도 있으며

백업과 기능 복원 기능도 있습니다

RDS와 많이 유사합니다

멤캐시트(Memcached)는 데이터 분할에 다중 노드를 사용하고

이를 샤딩(sharding) 이라고 합니다

가용성이 높지 않고

복제도 발생하지 않습니다

지속적인 캐시가 아닙니다

백업과 복원 기능도 없죠

그리고 다중 스레드 아키텍처로

몇몇 샤딩과 함께 캐시에서 함께 실행되는

여러 인스턴스가 있습니다

여기서 기억해야 할 것은

레디스는 고가용성과 백업

읽기 전용 복제본 등이 있고

멤캐시트는 데이터를 손실할 수 없는

단순한 분산 캐시입니다

가용성이 높지 않고 백업과 복원 기능도 없습니다

바로 이것이 두 기술의 가장 큰 차이점입니다

여기까지입니다 즐거우셨길 바랍니다

다음 강의에서 뵙겠습니다

ElastiCache - Cache Security

모든 캐시는 IAM 인증을 지원하지 않는다.

일래스티 캐시에서 정의할 IAM 정책은 AWS API 수준 보안에만 사용된다

즉 캐시 생성, 캐시 삭제 같은 종류의 작업을 의미합니다

그러나 캐시 내의 모든 작업은 IAM을 사용하지 않습니다

레디스를 인증하려면 레디스 AUTH를 사용하여 레디스 클러스터를 생성할 때 비밀번호나 토큰를 설정할 수 있다.

이렇게 하면 캐시에 들어갈 때 비밀번호를 사용할 수 있습니다 이는 캐시에 사용할 수 있는 보안 그룹에 대한

추가적인 수준의 보안입니다.

전송 중 암호화를 위해 SSL 보안을 지원할 수 있습니다
- 반면 멤캐시트는 좀 더 높은 수준인 SASL 기반 인증을 지원합니다

상당히 고급이라 다른 종류의 인증 메커니즘이죠

캐시의 보안을 살펴보면

EC2 인스턴스에는 자체 보안 그룹도 레디스에

액세스할 수 있는 자체 보안 그룹이 있습니다

그래서 일래스티 캐시를 사용하여 보안 그룹 수준의 보안을 수행할 수 있죠

다음 전송 중 암호화를 위해 SSL 암호화가 있습니다

또 인증을 위해 일래스티 캐시에서 레디스 종류의 캐시를

사용할 때 레디스 AUTH를 가질 수 얻을 수 있습니다

Patterns for ElastiCache

일래스티 캐시에 데이터를 불러오는 패턴에는 세 가지가 있습니다

레이지 로딩
1. 모든 읽기 데이터가 캐시되고 데이터가 캐시에서 부실해질 수 있습니다

라이트 스루
데이터를 오래된 데이터가 없는 데이터베이스에 기록될 때마다 캐시에 데이터를 추가하거나 업데이트하는 겁니다 그리고 이전에 보셨듯 일래스티 캐시를 세션 저장소로 쓸 수 있고 Time To Live(TTL) 속성으로 세션을 만료시킬 수 있습니다

캐싱은 아주 어려워서

컴퓨터 과학 분야에서 유명한 인용구가 있습니다

'컴퓨터 과학에는 어려운 일이 두 개가 있다

바로 캐시 무효화와 이름을 짓는 일이다'

이렇듯 캐싱은 아주 복잡한 주제며 제가 보여드린 건 아주 간단한 개요입니다

어쨌든 레이지 로딩의 전략을 설명드리겠습니다

일래스티 캐시에 캐시가 히트하면 애플리케이션이

캐시로부터 데이터를 받습니다

만일 캐시 미스가 있으면

데이터베이스에서 데이터를 읽고 캐시에 씁니다

이전에 이미 봤던 것들이죠

캐시 히트가 없을 때만 발생하기 때문에 레이지 로딩이라고 합니다

그런 다음 데이터를 Amazon 일래스티 캐시에 불러옵니다

이제 레디스의 사용 사례에 대해 얘기해 볼텐데요

시험을 위해 알아두셔야 할 부분이 있습니다

게임 리더보드 생성에 대한 겁니다

매우 복잡합니다

게임의 어느 시점에서든

누가 1위고 누가 2위고

3위인지 가려내는 개념입니다.

그래서 레디스에는 고유성과 요소 순서를 모두 보장하는

Sorted set 이라는 기능이 있습니다

요소가 추가될 때마다

실시간으로 순위가 매겨진 다음 올바른 순서로 추가됩니다

레디스 클러스터가 있는 경우

실시간으로 1위, 2위, 3위 플레이어가 있는

실시간 리더보드를 생성한다는 개념인 거죠

그리고 모든 레디스 캐시는 동일한 리더보드를 사용할 수 있습니다

즉 레디스로 Amazon

일래스티 캐시와 통신할 때

클라이언트는 이 실시간 리더보드에 액세스할 수 있고

애플리케이션 측에서 이 기능을 프로그래밍할 필요가 없습니다

실시간 리더보드에 액세스하기 위해

레디스의 정렬된 집합을 활용할 수 있습니다

다음은 적어도 한 번은 봐야 할 표준 포트 리스트입니다. 암기할 필요는 없지만(시험을 위해 암기할 필요는 없습니다), 그러나 중요 포트(HTTPS - 포트 443)와 데이터베이스 포트(PostgreSQL - 포트 5432)를 구별할 수 있어야 합니다.

중요 포트:

FTP: 21

SSH: 22

SFTP: 22(SSH와 동일)

HTTP: 80

HTTPS: 443

vs RDS 데이터베이스 포트:

PostgreSQL: 5432

MySQL: 3306

Oracle RDS: 1521

MSSQL 서버: 1433

MariaDB: 3306(MySQL과 동일)

Aurora: 5432(PostgreSQL 호환 시) 또는 3306(MySQL 호환 시)

MySQL 데이터베이스를 온프레미스에서 RDS로 이전해 둔 상태입니다.

여러 애플리케이션과 개발자들이 이 데이터베이스와 상호작용을 하고 있습니다.

각 개발자들은 기업의 AWS 계정 내에 IAM 사용자를 가지고 있습니다.

각 개발자들을 위해 DB 사용자를 생성하는 대신, 이들에게 MySQL RDS DB 인스턴스로의 액세스를 부여하기 위해서는 어떤 접근법을 취해야 할까요? ⇒ IAM 데이터베이스 인증 활성화하기

암호화되지 않은 RDS DB 인스턴스로는 암호화된 읽기 전용 복제본을 생성할 수 없습니다.

Amazon SQS

Jinlib — Thu, 9 Jun 2022 20:04:22 +0900

What is the AWS SQS?

SQS. Simple Queue Service의 약자로 사용되는 AWS 서비스이다.

SQS는 애플리케이션을 구성하는 다양한 컴포넌트가 서로에게 메시지를 전송할 수 있도록 돕는

고가용성, 고탄력성 관리형 메시지 서비스이다. 수십만 건의 메시지를 불과 수초만에 처리할 수 있다.

큐를 모아놨다가 Pooling처리를 실행하는 서비스

256K까지 가벼운 데이터만 이용 가능, 60초에서 14일간만 메시지를 저장할 수 있다

Request큐와 Response큐를 사용해 송수신 큐잉을 구현

여러개의 서버, 데이터센터에 큐를 저장하는 고가용성 서비스

여러 사용자가 쓸 수 있는 유연함

메세징이 증가해도 높은 Throughput을 유지함

큐의 종류

표준큐 : 순서대로 처리 + 반드시 한번은 실시함.

FIFO : 큐에 들어온 순서대로 처리

SQS의 특성

메세지 사이즈
- 최대 메시지 사이즈는 256KB.
- Extended Client Library 이용시 2GB까지의 메시지 송수신 가능

메세지 보존기간
- 삭제되지 않은 메시지는 기본값으로 4일간 보존
- 유지 기간은 60초에서 14일 사이에 변경 가능

In Flight메세지
- 큐당 최대 120,000 In Flight (받은 메시지 & Visibility Timeout내) 메시지

SQS의 추가 옵션

짧은 폴링(Short Polling) : 큐가 빈 경우에도 즉시 리턴 (ReceiveMessageWaitTimeSeconds 속성이 0)

긴 폴링(Long Polling) : 큐가 빈 경우에 타임아웃까지 기다림 (ReceiveMessageWaitTimeSeconds 속성이 0 보다 큰 값)

데드 레터 큐 : 계속 남은 메시지를 별도 큐로 이동하여 정상적으로 처리하지 못한 메시지를 격리가능

Visibility timeout : 새 메시지를 지정된 시간 동안 보이지 않게 한다.
- Visibility timeout을 설정함으로써 우선 처리하고 싶은 수신 인스턴스 지정 가능.

디커플링 아키텍처

정의 : 컴포넌트간의 상호의존을 줄인 구성으로 각각의 컴포넌트 변경이나 장애의 영향을 줄인다.

1 서버리스

서버리스 설계로 디커플링 아키텍쳐가 사용되며 마이크로서비스화된 애플리케이션을 구축

과거 SOA 방식에서 보다 작은 프로세스 단위의 서비스를 API로 연계한 마이크로 서비스로 설계할수 있음

SOA 방식
- 한 가지 기능을 갖춘 큰 서비스 단위로 컴포넌트를 분할하는 설계 방식

마이크로 서비스
- SOA보다 더 작은 기능 단위의 프로세스로 서비스화한 구성
- 각 프로세스에서는 1개의 작은 태스크를 서비스로 제공하고 프로세스 간 통신은 API를 이용한다.

Amazon SQS 대기열 지표를 기반 최적화

Problem

대상 추적용 ApproximateNumberOfMessagesVisible과 같이 CloudWatch Amazon SQS 지표를 사용할 때의 문제는 대기열의 메시지 수가 대기열에서 메시지를 처리하는 Auto Scaling 그룹의 크기에 비례하여 변경되지 않을 수 있다는 것

해결 방법은 인스턴스당 백로그 지표와 목표값을 사용하여 인스턴스당 허용 백로그를 유지하는 것입니다. 이 값은 다음과 같이 계산할 수 있습니다.

인스턴스당 백로그: 인스턴스당 백로그를 계산하려면 ApproximateNumberOfMessages 대기열 속성을 사용하여 SQS 대기열의 길이(대기열에서 검색할 수 있는 메시지 수)를 확인합니다. 이 값을 플릿의 실행 용량(Auto Scaling 그룹에서 상태가 InService인 인스턴스 수)으로 나눠서 인스턴스당 백로그를 산출합니다.

인스턴스당 허용되는 백로그: 목표값을 계산하려면 먼저 애플리케이션에서 허용할 수 있는 지연 시간을 확인하세요. 그런 다음 이 허용 지연 시간 값을, EC2 인스턴스가 메시지를 처리하기 위해 소요하는 평균 시간으로 나눕니다.

예제로 설명하기 위해 현재 ApproximateNumberOfMessages가 1,500개이고 플릿의 실행 용량이 10이라고 가정해 보겠습니다. 각 메시지의 평균 처리 시간 0.1초이고 가장 긴 허용 지연 시간이 10초인 경우, 인스턴스당 허용 가능한 백로그는 10/0.1인 100입니다. 즉, 목표 추적 정책의 목표값은 100입니다. 인스턴스당 백로그가 현재 150(1500/10)인 경우 플릿이 확장되고 5개의 인스턴스를 추가하여 목표값 비율을 유지합니다.

다음 절차에서는 사용자 지정 지표를 게시하고 이러한 계산에 따라 Auto Scaling 그룹을 조정하도록 구성하는 대상 추적 조정 정책을 생성하는 방법을 보여줍니다.

이러한 구성을 위해 세 가지 방법을 사용할 수 있습니다.

SQS 대기열의 메시지를 처리하기 위해 EC2 인스턴스를 관리하는 Auto Scaling 그룹.

Auto Scaling 그룹의 EC2 인스턴스당 대기열의 메시지 수를 측정하여 Amazon CloudWatch로 전송되는 사용자 지정 지표.

사용자 지정 지표와 설정된 목표값에 따라 크기를 조정하도록 Auto Scaling 그룹을 구성하는 대상 추적 정책. CloudWatch 경보는 조정 정책을 호출합니다.

다음 다이어그램은 이 구성의 아키텍처를 보여 줍니다.

Amazon LB

Jinlib — Thu, 9 Jun 2022 20:04:05 +0900

1. Classic Load Balancers(v1)

Supports TCP(Layer 4), HTTP & HTTPS(Layer 7)

상태확인은 TCP 또는 TCP or HTTP 기반으로 한다.

fixed hostname

위와 같이

Time-out 시간

몇번 간격으로 health check을 할것인지?

응답이 이상한게 몇번이면 Unhealthy로 판단할것인지?

응답이 정상인게 몇번이면 healthy로 판단할것인지?

2. Application Load Balancer (v2)

7계층 HTTP 전용 Load Balancers

머신간 다수 HTTP 애플리케이션 라우팅에 사용된다.

같은 머신에 여러 어플리케이션을 Load Balancing (ex Dokcer AWS ECS)

HTTP/2 & WebSocket 지원

HTTP → HTTPS로 트래픽 자동 리다이렉트 지원

고정 호스트 네임

어플리케이션 서버는 클라이언트의 IP를 직접적으로 보지 못한다.
- 대신, X-Forwarded-For에 클라이언트 IP가 삽입된다.
- X-Forwarded-Port에 클라이언트 Port가 삽입된다.
- X-Forwarded-Proto에 클라이언트 프로토콜이 삽입된다.

3. Network Load Balancer(v2)

layer 4 로드밸런스 ⇒ TCP UDP 기반 트래픽을 인스턴스로 전달

초당 수백만 건의 요청을 처리함

ALB보다 지연시간이 짧음 ~100ms ↔ ALB ⇒ 400ms

외부 AZ 당 1개의 고정 IP를 노출하기 때문에 NLB자체 IP를 가져오는 대신 Elastic IP를 사용한다.

2개의 엔트리 포인트를 사용하고자 할때 유용
- ex) 애플리케이션 전용 특정 IP 지정시, NLB가 해당 트래픽을 EC2로 보낸다.

Extreme 성능, TCP or UDP 수준의 트래픽을 원할때 사용한다.

NLB는 AWS 프리티어를 제공 X

고정 IP가 없고 고정 호스트 이름이 있다.

Network Load Balancer - Target Groups

EC2 인스턴스
- 대상그룹에 EC2 인스턴스를 등록하면 NLB에서 트래픽 전송방법을 파악
()고정아이피와는 다르게

고정 IP와 개인 IP를 지정해서 NLB에 트래픽을 보내도록 하는것
- 자체 데이터 센터에 서버가 있는경우에는 가급적이면 개인IP가 있는 서버 로드 밸런서를 사용한다.

NLB + ALB(Aplication Load Balancer)
- NLB기능을 활용해서 고정 IP를 가지기 위해
- HTTP 관련 기능 ALB를 활용할수 있다.

4. Gateway Load Balancer

배포 및 확장, AWS의 가상 어플라이언스의 서드파티 fleet 관리에 사용된다.

모든 트래픽이 방화벽을 통과하게 하거나 침입탐지 방지 시스템, 일부 페이로드를 수정하는 네트워크 수 잇게한다.

Network Layer(layer3)에서 작동한다.

2가지 기능
- Transparent 네트워크 게이트웨이: VCP의 모든 트래픽이 GWLB가 되는 단인 엔트리와 출구를 통과
- Load Balancer: 트래픽을 분산해서 로드 밸런서가 된다.

시험볼때는 6081포트의 GENEVE 프로토콜을 사용한다.

5. Sticky Sessions

로드밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는것을 의미

원리 클라이언트에서 로드밸런서로 쿠키가

쿠키 다른 eC2인스턴스

사용자의 로그인과 같은 중요한 세션데이터를 잃지 않기위해 동일한 백엔드를 이용하고자 한다.

Cookie Names?

커스텀 쿠키
- 대상으로 생성된 사용자 정의 쿠키
- 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
- 각 대상 그룹별로 개별적으로 사용해야한다.(AWSALB, 이런걸 ㅅ쓰면안됌

애플리케이션 쿠키
- Load balancer 자체에서 생성됨
- AWSALBAPP

기간 기반 쿠키
- load

6. Cross-Zone Load Balancing(교차 영역 로드 밸런싱)

클라이언트가 두 교차영역

각 로드 ㅗ든 인스턴스에 전반적으로 고르게 부ㄴ포됌

클라이언트는 50%를 1 AZ에 보내고 각 ALB는 가용영역에 상관없이 10개의 인스턴스에 분포함

두번째 ALB를 보면 전체 인스턴스에 수신한 것이 10%인데

ALB

Cross-Zone Laod Balancing이 항상 ON 상태이다(비활성화 못한다)

데이터가 한 AZ에서 다른 AZ로 이동하면, 비용을 지불해야한다.(ALB는 활성화가 되어있으므로 데이터 전송에 대한 돈 지불할 필요가 없다.

NLB

Cross-Zone Laod Balancing이 기본적으로 비활성화 상태이다

활성화하면 AZ간 데이터 전송에 비용을 지불해야한다.

CLB

Cross-Zone Laod Balancing이 기본적으로 비활성화 상태이다

활성화한다해도 AZ간 데이터 전송에 비용을 지불 X

7. SSL/TLS

SSL을 사용하면 클라이언트와 Load Balancer 사이에서 전송 중인 트래픽을 암호화 할 수 있다.(in-flight 암호화)

SSL은 Secure Sockets Layer 연결을 암호화하는데에 사용된다.

TLS는 SSL의 최신버전으로 Transport Layer 보안 (요즘 사용됨)

공용 SSL 인증서 를 사용하면 클라이언트와 로드밸런스 사이에 암호화를 할 수 있다.

애플리케이션 로드 밸런서 (ALB)와 네트워크 로드 밸런서 (NLB)의 어떤 기능을 통해 하나의 리스너에서 여러 SSL 인증서를 로드할 수 있을까요? • Server Name Indication (SNI)

8. Connection Draining

불리는 이름들..
- CLB에서는 Connection Draining이라고 불린다.
- ALB, NLB에서는 Deregistraion Delay라고 불린다.

기능
- 인스턴스가 de-registering, 혹은 Unhealthy인 상태에 있을 때 인스턴스에 어느 정도의 시간을 줘서, 활성을 완료할 수 있도록 하는 기능

과정
- Elastic Load Balancing은 Deregistraion 프로세스를 완료하기 전 300초 동안 대기
  - Elastic Load Balancing이 대기하는 시간을 변경하려면 등록 취소 지연 값을 업데이트
- 등록 취소하는 대상 초기 상태는 draining
- draining이 경과한 후 등록 취소 프로세스가 완료되며 대상 상태는 unused
  - ASG의 일부인 경우 종료 및 대체되는 시점 ⇒ 5xx 에러발생

9. Auto Scaling Group?

애플리케이션에 받는 부하가 많아진다면, 빠르게 서버를 증설해준다(스케일 아웃)

반대로, 받는 부하가 적어서 리소스가 낭비된다면, 서버를 줄어들게 한다(스케일 인)
- 일정량만 증가시키거나 줄어들게 만들수있는데, 이로써 ASG에 실행되는 머신의 최대, 최소 숫자 설정가능하다.

Auto Scaling Alarms

몇가지 metric으로 작동하는데, metric 설정을 통해서 Trigger를 줘서 (ex 평균 CPU사용량이 70% 이상 시) 스케일 아웃, 스케일 인을 할 수 있다.

ASG의 장점

인스턴스가 종료될 경우 ASG가 인스턴스 종료 사실을 파악할 것이고 자동으로 새 인스턴스를 생성해서 교체해 준다.

로드 밸런서가 특정 인스턴스를 unhealthy이라고 표시한 경우 ASG는 해당 인스턴스가 unhealthy이니 종료하고 새 인스턴스를 생성해 교체하는 판단을 내린다. ⇒ ASG는 재시작이 필요 없고 인스턴스의 중단없이 문제가 있는 인스턴스를 종료한 후 새 인스턴스를 생성해 교체한다.

Auto Scaling Group(ASG) - Dynamic Scaling 정책

타겟 트래킹 스케일링
1. 가장 간단한 방식
1. example: ASG의 평균 CPU 사용률을 추적해서 40%에 머물 수 있도록 해라!(

Simple / Step 스케일링
1. 전체 ASG의 CPU 사용률이 70%를 초과하는경우 2 unit를 높여라
1. 반면, 30%떨어지면 1 unit를 제거해라

스케줄 액션
1. 특정시간에 맞춰서 스케일링하는 방식
1. 금요일 오후 5시에 큰 이벤트가 예정되어있으니, 최소 10개이상 늘릴수 있도록 해라

예측 스케일링
1. 과거 전력을 통해서 예측 스케일링 서비스를 제공함.

CPU 사용량(CPU Utilization): 평균 CPU

타겟당 요청 수(Request Count Per Target):

Average Network In/Out:

Amazon EC2 Overview

Jinlib — Thu, 9 Jun 2022 20:03:19 +0900

Amazon EC2(Elastic Compute)

1. 아마존 머신 이미지(Amazon Machine Image, AMI)

정의: 아마존 일래스틱 컴퓨트 클라우드(EC2) 안에 가상 머신을 생성하기 위해 사용되는 특수한 유형의 가상 어플라이언스이다. 주로 인스턴스를 Launch할때 필요한 정보를 제공한다.

어플라이언스(Appliance)?

요약: 각종 기업용 소프트웨어를 서버와 스토리지 하드웨어에 최적화된 통합 장비. OS, 관련 소프트웨어 설치 및 설정 등을 안해도 전원을 접속하면 바로 사용할 수 있는 정보기기를 의미한다.

기존(As-is): 과거에는 하드웨어, 운영체제, 소프트웨어를 각각 구매한 후 설정하여 사용하는 것이였다.

신규(To-be): 클라우드를 통해서 하드웨어 제약을 없애고, AMI를 통해서 특정 목적에 따라 최적의 성능을 낼 수 있도록 운영체제, 소프트웨어가 다 설치된 바로 사용가능한 기기 개념

2. EC2 인스턴스 스토어(Instance Store)

인스턴스의 로컬 저장소

임시 데이터 저장소

(Default) 데이터 복제 미 지원

Snapshot 미 지원

SSD OR HDD

3. Amazon EBS 볼륨

블록 스토리지

API를 이용하여 생성, 연결, 수정

워크로드에 따라 스토리지 및 컴퓨팅을 선택 할 수 있다.

하나의 EBS 볼륨은 하나의 인스턴스에만 연결

Magnetic(st1, sc1) 및 SSD(gp2, io1) 기반 볼륨 유형을 선택할 수 있다.

Snapshot 기능 지원을 통해서 특정 시점을 백업할 수 있다.

4. EC2 Instance Life Cycle

1) Running(실행중)

인스턴스 동작 중 상태를 의미하며 (과금 O)

2) Stopped(정지됨)

인스턴스 중지 상태. EBS볼륨을 루트로 사용하는 인스턴스만 가능하다. (과금 X, But, EBS 과금)

3) Hibernated(최대절전모드) 링크

(1) RAM에 쌓인 프로세스들을 EC2와 연결된 루트 EBS 볼륨에 암호화된 상태로 저장하여 재실행시 작업을 이어서 할 수 있다. (과금X, But, EBS과금, Elastic IP 주소 과금)

단, 사용된 AMI, 루트 EBS 볼륨은 암호화 체크 필요
1. 인메모리 상태로 프로세스를 루트 EBS 볼륨에 저장.
1. 인스턴스 종료
1. 인스턴스 재 실행시 작업중이던 프로세스 이어서 작업

4) Terminated(종료됨)

인스턴스가 완전히 제거된 상태

시작이나 정지가 불가능

과금 안됨

5. EC2 인스턴스 타입 링크

1) 인스턴스 패밀리

M	범용	C	컴퓨팅	I	고 I/O 스토리지	P	범용 GPU	F	성능 가속
T	버스팅용	R	메모리	D	고밀도 스토리지	G	그래픽

2) 인스턴스 세대

마치 i7-8세대, 9세대 이런것처럼 해당 인스턴스의 세대로 보면된다.

3) 추가 기능

g	AWS Gravition 프로세서	d	빠른, 로컬 NVMe 스토리지	e	Enhanced performance
a	AMD EPYC 프로세서	n	최대 100 Gbps 네트워크 대역폭	s	Reduce Power Instance

4) 인스턴스 사이즈

c4.8xlarge ≈ 2 x c4.4xlarge ≈ 4 x c4.2xlarge ≈ 8 x c4.xlarge
- 큰 인스턴스 1개(c4.8xlarge): $1,164.43
- 작은 인스턴스 8개(c4.xlarge): $1,186.16
  * 온디멘드, EBS 30gb 적용시 한달 가격

6. Amazon EC2 인스턴스 선택 요령

1) 구성 아키텍쳐 파악

(1) 구성하고자 하는 아키텍쳐가 있는가?

ex) MSA(MicroService Architecture)

각 인스턴스가 모두 고성능일 필요가 없을것이다. 그럴 경우에는 여러개의 작은 범용 인스턴스로 구성하면서 일부 고성능을 요하는 작업에만 c (고 컴퓨팅) 혹은 R(고 메모리) 인스턴스를 배치하는것이 좋을것이다.

2) 가용 비용(Price) 파악

(1) Cost Explorer

예를 들어, On-premise에서 Migration을 진행한다고 했을때, 같은 스펙의 CPU Core, MEM을 넣으면 알아서 알려준다. 또한 지난 n년 동안 시스템 모니터링 데이터를 통해서 월별 얼마나 리소스를 사용하는지 또한 입력하면 얼마정도 나오는지도 알려준다.

(2) AWS Compute Optimizer

최적의 AWS 리소스를 권장하는 ML기반 서비스

최적 EC2 인스턴스 및 EC2 오토스케일링 그룹 구성

3) 워크로드 주기, 특성 파악

(1) 온디맨드(On-demand)

초단위로 쓴만큼 비용지불(장기 약정X). 갑작스럽거나 예측할 수 없는 워크로드에 용이

(2) 예약인스턴스(Reserved Instance)

1,3년 약정으로 대폭할인. 예측 가능한 안정적인 워크로드에 용이

(3) 세이빙플랜(Saving Plan)

예약 인스턴스와 같은 할인. +a 유연성

(4) 스팟인스턴스(Spot Instance)

여분의 EC2 용량으로 On-demand 가격에서 최대 90% 할인 제공.

내결함성, 유연성, 상태 비저장 워크로드

Amazon ELB overview

Jinlib — Thu, 9 Jun 2022 19:59:29 +0900

Background Knowledge

1. 확장성 & 고가용성(Scalability & High Availability)

1) 확장성

애플리케이션과 시스템이 조정한다면 더 많은 양을 처리할수 있다는 의미

(1) 수직 확장성

인스턴스의 사이즈를 늘리는것. ex RAM 1GB PC 1개를 4GB인 PC로 바꾸는거

데이터베이스와 같은 상황에서 주로 사용한다.

한계: 하드웨어 제한.

(2) 수평 확장성( = Elasticity)

인스턴스의 ‘수'를 늘리는것. ex RAM 1GB PC 1개를 → 개로 해서 효율성 늘리는것.

2) 고 가용성

데이터 센터에서의 손실에서 살아남도록 하는것이며, 즉, 무중단 시스템을 만드는것. (수평확장과 함께 사용되는 개념이기도 한다.)

Multi AZ

Auto Scaling Group multi AZ

Load Balancer multi AZ

2. 로드 밸런싱(Load Balancing)

로드밸런서는 서버 or 서버셋으로 들어오는 트래픽을 백엔드서버나 서버들로 전달하는 역할을 한다.

위처럼 유저가 Elastic Load Balancer에 접근하면 End-point는 다를지라도 같은 것을 보고 있게 한다.

1) 로드밸런싱이 필요한 이유?

트래픽 부하를 다수의 다운스트림 인스턴스로 분산하기 위해

애플리케이션에 하나의 single-point (DNS)만 노출시키기 위해

다운스트림 인스턴스의 장애를 원활히 처리하기 위해

인스턴스의 상태를 정기적으로 체크하기 위해

웹사이트에 SSL termination(HTTPS)를 제공하는 암호화된 트래픽을 갖기 위해

클라우드 내에서 개인 트래픽과 공공 트래픽을 분리하기 위해

고 가용성으로 Multi AZ를 갖기 위해

AWS Elastic Load Balancer

1. AWS ELB는 무엇인가?

네트워크 트래픽 분산을 통한 애플리케이션 확장성 개선

L4 Switch와 같은 관리형 로드 밸런서(managed load balancer)
- AWS가 관리하며, 어떤 경우에도 작동할 것을 보장
- AWS가 업그레이드, 유지관리, 고가용성을 책임
- 로드밸런서의 작동 방식을 수정할 수 있다.

자체 로드 밸런서를 쓰는것 보다 저렴

다수의 AWS 서비스들과 통합.

작동이 어케되는가?

인스턴스 상태를 확인할 수 있는데, 프로토콜, 포트, 엔드포인트로

200으로 응답안하면 좋지 않다고 체크하고

ELB가 그쪽으로 안보냄

Elastic Load Balancing은 등록 취소 중인 대상으로 요청을 전송하는 것을 중지합니다. 기본적으로 Elastic Load Balancing은 등록 취소 프로세스를 완료하기 전에 300초 동안 대기하는데, 이는 대상에 대해 진행 중인 요청을 완료하는 데 도움이 될 수 있습니다. Elastic Load Balancing이 대기하는 시간을 변경하려면 등록 취소 지연 값을 업데이트합니다.

등록 취소하는 대상의 초기 상태는 draining입니다. 등록 취소 지연이 경과한 후 등록 취소 프로세스가 완료되며 대상 상태는 unused입니다. 대상이 Auto Scaling 그룹의 일부인 경우 종료 및 대체될 수 있습니다.

2.AWS의 4가지 ELB

CLB, Classic Load Balancer (v1, 2009)
- HTTP, HTTPS, TCP, SSL 지원

ALB, Application Load Balancer (v2, 2016)
- HTTP, HTTPS, WebSocket
- ALB는 URL Path, Hostname, HTTP 헤더 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅할 수 있다.
- 쿠키 이름(AWSALB, AWSALBAPP, AWSALBTG)

NLB, Network Load Balancer(v2, 2017)
- TCP, TLS(secure TCP), UDP

GWLB, Gateway Load Balancer(v3, 2020)

Amazon EC2 EBS

Jinlib — Thu, 9 Jun 2022 19:59:16 +0900

1. EBS Volume Types

EBS 볼륨 타입에는 크게 3가지가 존재한다.

gp2/gp3(SSD)
1. 범용 SSD 볼륨
  1. 짧은 지연시간, 효율적인 비용
  1. 시스템 부팅디스크, 가상 데스크톱, 개발, 테스트 환경등 다양한 환경에서 사용
1. gp2 ↔ gp31GB ~ 16TB
  1. gp2: old, Linked IOPS, 처리량
    1. 기본: 3,000 IOPS
    1. size와 IOPS가 연결되어있어서 최대 16,000 IOPS 선택
    1. IOPS = 3 * GB ⇒ 5,334GB = 16,000 IOPS(max)
  1. gp3: 최신, 독자적 IOPS, 처리량 설정
    1. 기본: 3,000 IOPS + 125MB/s 처리량(Throughput)
    1. 고급: 16,000 IOPS + 1000MB/s 처리량(Throughput)

io1/io2(SSD): Provisioned IOPS(PIOPS) SSD
1. 매우 높은 성능을 자랑하는 EBS
  1. mission-critical
    1. Multi-Attach를 자랑한다. 여러 인스턴스 연결 가능
  1. low-latency, high-throughput: 16,000 IOPS 이상을 자랑함
  1. 주로 데이터베이스 워크로드에 적합
1. io1 ↔ io2(4GB ~ 16TB)
  1. io1
    1. IOPS : 최대 32,000 IOPS & 64,000 IOPS(Nitro EC2전용)
    1. 독자적인 스토리지 크기 증가
  1. io2 Block Express(4GB ~ 64TB)
    1. io2는 io1과 같은 비용으로 내구성+GB당 IOPS 수가 더 높으므로 io2 필수선택
    1. latency: 밀리초 미만
    1. IOPS:GB비율이 1,000:1일때 최대 256,000 IOPS 제공

st1/sc1(HDD)
1. st1
  1. 저비용의 HDD 볼륨
    1. 처리량 최적화 HDD, 잦은 접근, 처리량이 많은 워크로드에 주로 쓰인다.
    1. 크기: 125MB ~ 16TB
    1. 주로 빅데이터, DW, Log Processing에 적합
    1. 처리량: 500MB/s & IOPS: 500
1. sc1(HDD)
  1. 가장 비용이 적은 볼륨
    1. 접근 빈도가 낮은 워크로드에 주로 쓰임(아카이브)
    1. 처리량: 250MB/s & IOPS: 250

볼륨을 어떤걸 선택해야할까?

Size

Throughput

IOPS(I/O Ops Per Sec)

단, boot vloumes에는 오직 gp2/gp3 and io1/io2 인스턴스만 사용가능하다.

+) EBS Muli-Attach - io1/io2 군

원래는 EBS 볼륨은 한개의 인스턴스만 연결할 수가 있는데,

io1/io2를 사용하면 같은 AZ내에서 여러 인스턴스를 연결할 수 있다.

EBS 볼륨 암호화

암호화되면?
- 인스턴스와 볼륨이 모두 암호화
- 모든 스냅샷들도 암호화

스냅샷에 생긴 볼륨들도 암호화
- 암호화가 지연시간에 미치는 영향 X
- KMS

암호화되지 않는 스냅샷을 복사할때 암호화됨

EBS 볼륨이 암호화되는 과정

EBS 볼륨 스냅샷 생성

스냅샷을 복사하여 복사한 EBS 스냅샷 암호화 옵션 선택 (스냅샷에서 새 EBS 볼륨생성시에도 암호화)

암호화된 EBS 볼륨 스냅샷으로 원본 인스턴스에 연결 가능

3 STEP SQLD 시험 합격 공부법

Jinlib — Tue, 1 Mar 2022 23:30:28 +0900

긴말필요없다. 그냥 아래 순서대로 진행하자

Step 01 시험 막판 정리 강의 듣고 노트 정리

(1) SQLD 최종 정리강의 1편 - SELECT문장 ~ 트랜잭션 관리 언어(TCL)

55분 강의 링크

(2) SQLD 최종 정리강의 2편 - 윈도우 함수 ~ 인덱스(Index)

40분 강의 링크

Step 02 노랭이 1회독 + 꿀팁 강의

(1) SQL 자격검정 실전문제 풀기(통칭 노랭이)

(2) 노랭이 풀다가 아래 페이지 체크해두고 풀때 강의한번 보기

p44, p50, p55, p58, p60, p68, p78, p94, p95, p98, p101, p103, p104, p108, p115, p116
위 페이지 풀때 강의 보고 풀기 강의링크

SQL 문제풀이

www.youtube.com

Step 03 기출문제 풀기

카페 링크

데이터 전문가 포럼 네이버 카페 들어가기 -> 복원 완료 기출문제 메뉴 들어가기 -> 복원된 기출문제 확인

몰랐던것들 확인하고 문제와 답을 암기하도록 한다.

출처: https://jonhyuk0922.tistory.com/115

[통계] 통계학 Overview

Jinlib — Sun, 27 Feb 2022 00:18:14 +0900

서론

MLOps를 공부하면서 우연히 빅데이터 분석 프로젝트 T/F팀에 소속되어 기획부터 배포까지 경험할 수 있게 되는 기회가 생겼다.
그런데, 문제정의를 하는 단계에서 부터 먹먹함을 가지고 있었다. '이거 제대로 하고 있는거 맞아?', '타당성 충분한가?', '이걸로 설득시킬 수 있어?' 이런 자문자답이 불가능하여 통계학을 놓으면 안되겠다는 생각을 하게 되었고, '이렇게 쉬운 통계학' 이라는 책을 시작으로 공부하기로 하였다.
공부방법은 간단하다. 개인적으로 책의 내용 + 인터넷 서칭하며 공부하고 공부한 내용을 백지에 게시글에 다시 작성하는식으로 검증하는 방식이다.
그럼 시작해보도록 하겠다.

본론

먼저 통계학을 시작하기 전에 통계학의 '맵'을 그리려고한다.
통계학은 대표적으로 4가지로 설명할 수 있다.

1) 기술 통계학
2) 다변량 분석
3) 추측 통계학
4) 베이즈 통계학

이다. 물론 응용 통계학(보험통계학, 의학통계학 등)쪽도 있는데 이부분은 다루지 않도록 하겠다.
각각에 대해서 overview 형태로 쭉 훑고 깊게 들어가는것이 좋다고 생각한다.

1) 기술 통계학(Descriptive Statistics)

기술통계학의 기본은

의사결정 하기 위해서 많은 데이터 중에서 대표하는 값을 찾자!

에서 시작된다고 생각한다. 예를 들어서 1000여명의 영업팀이 이번 한달 야근 얼마나 했나? 를 알아보고자 할때 20, 85, 17, 1, 10...시간으로 데이터가 있다고하자 이런 엄청나게 많은 데이터로는 어떠한 인사이트나 추이를 파악할 수 없다.
이를 계산하기 위해서 나온 개념으로 '대푯값' 이 있다.
이 대표값에는 일반적으로 3가지가 있다.

평균
중앙값
최빈값

먼저 평균같은 경우에는 (전체 데이터의 합)/(데이터의 수) 를 통해서 구할 수 있다.
이를 통해서 1000여명의 영업팀의 야근시간이 이번달에은 평균 40시간, 저번달에는 평균 60으로 지난달에는 일이 많았구나 식으로 알아볼 수 있는 것이다.

중앙값은 전체 데이터를 오름차순으로 정렬했을때 가운데가 되는 값을 의미한다.
최빈값은 전체 데이터에서 같은 값을 가지는 수를 계산해보았을때 가장 많은 빈도수를 가진 값을 의미한다.

그러나 이에 맹점을 가지고 있는것이 있으니, 가령 영업팀의 평균야근시간이 저번달보다 20시간이 감소했다 한들, 이상하게 지난달보다 오히려 일부 직원들의 야근시간이 증가했다고 해보자. 이러한 점에 있어서 나온 개념이 바로 분산(dispersion)다.

데이터의 분포도를 보기 위해서는 대표적으로 3가지가 있다

표준편차
사분위수
범위

먼저, 표준편차라 함은 평균과 얼마만큼 떨어져 있는 계산 값이다.
일반적으로 편차(Variance) 개념으로 사용되는값이 시그마제곱 = (각 데이터와 평균과의 차이의 제곱) / (데이터의 수)로 분포를 계산할 수 있고,
여기서 표준편차(Standard deviation)은 시그마라고 불리며 편차를 루트씌운 값과 같다. 이 값을 통해서 데이터가 평균과 얼마나 떨어져 있는지 분포도를 계산할 수 있따.
두번째로 사분위수는 전체 데이터가 있으면, 그 데이터의 25%(1분위수), 50%(2분위수=중앙값), 75%(3분위수)에 해당하는 값을 계산하는것이다.
(3) 범위는 최대값과 최소값을 계산하는것이다.

일반적으로 (2)과 (3)을 묶어서 박스플롯, 수염플롯이라는 의미로 같이 시각화하는데 사용하곤 한다.

2) 추측 통계학(Inferential Statistics)

다변량 분석에 들어가기 전에 추측 통계학부터 보도록 하겠다.

추측 통계학의 기본은

전체 데이터(모집단)를 수집할 수 없을때, 일부 데이터(표본)를 수집하여 전체 데이터의 성질을 추측하겠다.

에서 시작된다고 볼 수 잇다. 전체 데이터를 수집할 수 없을때에는 표본을 수집하여 기술 통계학에서 썻던것처럼 대푯값을 쓴다면, 새로운 데이터가 축적될때마다, 혹은 새로운 표본을 수집할때마다 대푯값이 달라질 수 있다. 이에 대한 고민을 해결하고자. 나온개념이 추측 통계학이다.

예를 들어 제약회사에서 신약을 개발하였다고 하자, 이 약이 효능이 있는지 검증을 해야할것이다. 이럴떄 추측 통계학은 2가지 순서로 진행된다.

가설 설정(통계적 추정)
가설 증명(가설 검정)

가설 설정(통계적 추정)

제약 직원이 '이 신약을 효과가 있을거야!' 라고 가설A를 세웠다고 해보자.
이를 증명하기위해서 가설A의 옳고 그름을 판단하기에는 매우 어렵다. 반면, 추측 통계학을 이용한다고 하면, 가설A를 역으로 '이 신약을 써도 효과가 없을거야!'라고 가설 B를 세워서 가설B가 틀렸다!라고 것을 증명함으로써 간접적으로 증명시킬수 있다.
여기서 통계학 용어를 잠깐 설명하자면, '이 신약은 효과가 있을꺼야!'라고한 가설 A를 대립가설 이라고 하고, 이 신약을 써도 효과가 없을거야!'라고한 가설B를 귀무가설(null-hypothesis) 이라고 한다.

가설 검정

가설 증명한다는 것은 말그대로 귀무가설을 기각(틀렸다!) 시킨다는 의미이다. 그럼 어떻게 기각시킬까?
이떄는 정규분포의 개념을 이용한다.

전체데이터의 분포를 정규분포 형태로 나타낼때는 젤라뽀를 눕힌 모양으로 나타낸다. 가장 가운데에는 평균값. 그리고 평균값을 기준으로 값이 좌/우로 분포되어있는 형태를 띌것이다. 여기서 가설B인 귀무가설을 기각시킬때에는 젤라뽀의 가장 외곽 부분에 포함되면 기각!이라고 말하고, 가설B가 틀렸으니, 가설 A는 옳을 가능성이 높다 라고 판단할 수 있는것이다.

여기서 가장 외곽 부분이 평균과 얼마나 떨어져 있냐에 따라서 3가지 룰이 있는데,

평균 +- 1 * 표준편차 = 68.3%
평균 +- 2 * 표준편차 = 95.4%
평균 +- 3 * 표준편차 = 99.7%

순으로 계산하곤한다. 여기서 기각되는 조건에 따라 p value < 0.05 라는 의미를 쓰곤하는데 왼쪽에 쓴 저 의미는 99.5%의 신뢰도를 가진다고 말한다.

+) 정규분포가 다 통하나?

모든 데이터들이 정규분포를 띄는것이 아니다.

i) 지수분포

예를들어 '회사의 상품별 매출 동향' 같은 주제의 데이터는 정규분포가 아닌 '지수분포'를 띌것이다. 왜냐하면, x축이 상품들이고 y축이 매출이라 하고 가장 잘팔리는 상품군으로 나열되었을때, 지수함수 형태를 띄기 때문이다.
이처럼 잘 안팔리는 상품군은 '롱테일(long-tail)'이라고 불리며 향후 AI 서비스 적용시 주의해야할 사항으로 나오는 개념이기도 하다.

ii) 균등분포

예를들어16까지 있는 주사위를 돌려서 어떤 값이 나오는지 데이터를 쌓았다고 생각해보자.
이를 그래프로 나타내면 16까지 비슷한 확률을 가지므로 균등한 모양의 그래프가 나올것이다.

3) 다변량 분석

2개 이상의 변량(변수)를 다루어서 '예측'을 하자!

라는 개념이다. 예를 들어 한 초등학교 학급의 키와 몸무게 데이터를 모아서, x축을 키, y축을 몸무게라고 하여 분포도를 그려보았을때, 키가 증가할수록 몸무게 또한 증가하는 추세를 보임을 알 수 있었고 이를 직선그래프로 표현한다고 하자. 이처럼 표현하면, 어떤 학생이 키가 00이라고 했을때 이 직선그래프를 토대로 몸무게를 예측할 수 있다. 이 예는 선형 회귀(linear regression)의 한 예시 인데, 이처럼 2개 이상의 변량을 통해서 예측을 하는데 초점이 맞춰진 통계학을 의미한다.

단 여기서도 조심해야할 것이 있다.

가령 학교 전체 학생의 발사이즈와 해당 학생의 초등 수학 올림피아드 성적과 비례 관계를 형성하는 데이터가 생겼다고 해보자. 이는 사실상 초등학교 학년이 올라가면서 생김에 따라 생기는 관계로 사실상 유의미한 상관관계를 띈다고 말할 수 없다. 이를 유사상관이라고 말한다.

4) 베이즈 통계학

기존 통계학은 발생빈도를 '예측' 할 수 있는 경우에만 사용이 가능했다. 이말인 즉슨, 데이터가 적거나 심할경우 데이터가 없을경우 추측이 어렵다는 단점이 존재한다.
이를 해결하기 위해 베이즈 통계학이라는 개념이 나오기 시작했다.
베이즈 통계학은 표본이 적더라도 추정할 수 있는데 어떤 데이터가 들어올때마다 확률이 바뀌는 통계학이다.
대표적인 예로 몬트홀 문제라고 볼 수 있다.

Spark 환경설정

Jinlib — Wed, 23 Feb 2022 15:48:50 +0900

Apple M1 환경

brew 업데이트

terminal 환경에서

brew update

Python 다운로드 혹은 업그레이드

terminal 환경에서

# 파이썬 3.9버전 다운로드
brew install python@3.9
# 파이썬 3.9버전 업그레이드
brew upgrade python@3.9

JAVA 11 다운로드

brew tap adoptopenjdk/openjdk
brew search jdk
brew install --cask adoptopenjdk11

JAVA 다운로드 확인

/usr/libexec/java_home -V
vi ~/.zshrc # 이곳에 위 자바 홈 추가
java --version

brew install scala
brew install apache-spark
brew install --cask anaconda

spark 테스트

터미널 창에 pyspark

위와 같이 뜨면 성공!~

만약, 에러시,
https://itholic.github.io/etc-sparkdriver-retires-err/

윈도우10 환경

1. 자바 설치

반드시 java 8 혹은 java 11을 설치햐야 한다.

2. 스파크 설치

WInRAR 설치
Spark 3.x 버전 설치

3. 컴퓨터에 Hadoop이 있다고 속이기

1) 다음 경로에 폴더 생성

C:\winutils\bin
C:\tmp\hive

2) 파일 다운로드 & 이동

C:\winutils\bin에 https://sundog-spark.s3.amazonaws.com/winutils.exe들어가서 다운받기

3) 테스트

cmd화면에서

cd C:\\winutils\\bin
winutils.exe chmod 777 \\tmp\\hive

오류없이 실행되면 끝

4) 환경변수 설정

윈도우 - 설정 - 시스템 - 정보 - 고급 시스템 설정 - 환경변수 설정

JAVA_HOME
c:\jdk
SPARK_HOME
C:\spark
PYSPARK_PYTHON
anaconda cmd 창 들어가서
python -> import sys -> sys.executable 입력
HADOOP_HOME
winutils 위치
PATH
PATH라고 등록된 환경변수 안으로 들어가서
NEW 클릭후
%JAVA_HOME%\bin
%SPARK_HOME%\bin
%HADOOP_HOME%\bin

5) 파이스파크 설치

관리자 아나콘다 프롬프트에서

pip install pyspark

6) 테스트

이후 cmd 창에서

pysprk 
rdd =sc.textFile("README.md")
rdd.copunt()

결과값으로 109나오면 성공

출처: https://wind010.hashnode.dev/setting-up-anaconda-and-pyspark-on-m1-mac

[Troubleshooting] Ports are not available: listen tcp 0.0.0.0:xx: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

Jinlib — Tue, 22 Feb 2022 10:57:45 +0900

에러내용

Error invoking remote method 'docker-start-container': Error: (HTTP code 500) server error - Ports are not available: listen tcp 0.0.0.0:50079: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

필자의 경우에는 50079였는데, 어느 포트에서 저 에러가 났을때, 아래 를 수행한다면 해결될것으로 본다.

※ 진리의 재부팅은 한번 해보고 안되면 아래를 수행하자.

솔루션

1. 어느 포트들이 Block 되어 있는지 확인

netsh interface ipv4 show excludedportrange protocol=tcp

2. 포트가 범위 중 하나에 있는 경우 winnat를 중지합니다.

net stop winnat

3. 필요한 포트 동적 예약 금지합니다(예: 50079):

netsh int ipv4 add excludedportrange protocol=tcp startport=50079 numberofports=1

4. winnat 다시 시작:

net start winnat