이 글은 아마존 공식문서 - AWS기초 를 거의 그대로 타이핑하면서, 단원마다 모르는 용어를 적어둔 글입니다.
1. 전체 소개
구조
AWS 기초 과정은 5가지 모듈로 진행된다. 각 모듈은 다음 형식을 따른다.
- 소개 : 집중할 원칙에 대한 간략한 설명
- 멘탈 모델 : 각 원칙에서 소개되는 개념의 이해를 돕는, 안내 멘탈 모델
- 개념 : 각 원칙의 광범위한 기초 주제를 다루는 주요 개념
- 결론 : 주요 내용의 요약
- 추가자료 : 추가링크 미 자료
5대 원칙
AWS 기초과정에서 다루는 5대 원칙은, AWS Well-Artchitected 프레임워크 에서 제공된다. Well-Architcted 프레임워크는 클라우드에서 확장 ㅏㄱ능한 어플리케이션을 구축한 10년 동안의 경험이 집약된 핵심이다.
5대 원칙은 다음과 같다.
- 보안
- 성능 효율성
- 안정성
- 운영 우수성
- 비용 최적화
2. 보안
보안 원칙은 클라우드에서 인프라를 보호하는 방법에 중점을 둔다. 보안과 규정준수는 AWS와 고객의 공동책임이다. 이러한 공동 책임 모델에서 AWS는 클라우드의 보안에 대한 책임이 있다. AWS의 책임에는 AWS 클라우드 서비스의 물리적 인프라, 소프트웨어 및 네트워킹 기능이 포함된다. 고객은 클라우드에서의 보안에 대한 책임이 있다. 고객의 책임에는 특정 클라우드 서비스의 구성, 어플리케이션 소프트웨어 및 민감한 데이터관리가 포함된다.
멘탈 모델
클라우드에서의 보안을 고려할 때는, 제로 트러스트 모델을 도입하는 것이 유용하다.
이 모델에서 모든 어플리케이션 구성 요소 및 서비스는 별개이며 잠재적으로 악의적인 엔티티로 간주된다. 그리고 기본 네트워크 패브릭,리소스에 액세스하는 모든 에이전트 및 서비스 내부에서 실행되는 소프트웨어가 포함된다.
모르는 용어 설명
-
제로트러스트
신뢰가 없다, 즉 '아무도 믿지 마라'라는 뜻이다. 기본적인 컨셉은 사용자, 단말기가 네트워크나 데이터에 접근을 요청할 때 처음부터 아무것도 신뢰하지 않는 보안전략이다. 전통적인 보안시스템과 달리, 제로트러스트의 개념에서는 보안 시스템을 통과해서 IT 시스템에 접속한 사용자나 단말기라도 신뢰하지 않는다는 것이 기본 전제이다. 제로 트러스트 개념에서는 IT시스템에 접근하기 위해서, 즉 접근 허가(인가?)를 받기 위해서는 먼저 사용자가 누구인지, 혹은 단말기가 안전한 허가를 받은 단말기인지, 그리고 어떤 접근권한을 갖고 있는지 등 모든 유효성을 다 입증한 다음에, 권한을 받아서 접근 허가를 수락하게 된다. IT 시스템에 접근하기 위해서만도 아니고, IT 시스템에 접근한 이후에 IT 시스템 안에서도 여러 시스템들이 존재하는데, 각 시스템에 접근할 때마다 앞서 언급한 모든 유효성을 다 입증해야 한다. IT 시스템 안에 존재하는 데이터를 사용할 때도 마찬가지이다.
과거의 보안 시스템이 IT 시스템의 접속을 통해, 외부로부터의 유입에 대해 방어에만 집중하고 내부의 보안이 상대적으로 허술했떤 것에 비해, 제로트러스트 모델은 외부로부터의 유입에 대한 방어와 동등한 레벨로 내부의 보안도 처리한다는 점에서, 다양해진 보안 위협으로부터 안정성 높은 보안 패러다임으로 다시 주목받게 되었다.
전통적인 보안시스템은 허가받지 않은 사용자에 대한 접근을 차단하는 것에 중점을 둔다면, 제로트러스트 모델은 차단보다는 철저한 신원인증에 초점을 둔다는 점에서 차이가 있따. 이런 신원 인증에는 기존 방식인 ID, 패스워드 이외에도 지문/홍채/얼굴인식/OTP/ 보안키 등 복합적인 방법으로 철저한 신원인증을 하는데, 이런 복합적인 신원 인증 방법을 멀티팩터인증(Multi-Factor Authentication, MFA)라고 부른다.
단말기에 대한 인증 역시, 기존에 등록한 단말기인 경우에도 그것으로 끝나는 것이 아닌 해당 단말기에 기업에서 제시한 보안 어플리케이션이나 안티바이러스 솔루션이 설치되어있는지 여부, 단말기 자체의 보안레벨등을 체크해서 허용 가능한 단말기인지 확인하는 단말기 인증 과정을 거친다.
-
악의적인 엔티티 - 번역된 예시참고
- 예를 들어, 악의적인 엔터티 가 다른 사람에게 거짓 또는 잘못된 정보를 보내 이 정보가 정확하다고 믿게 할 수 있다.
- 특히 가상 엔터티 는 가상 네트워크에 악성 메시지를 주입 하고 이러한 메시지가 다른 엔터티에서 온 것으로 믿도록 다른 사람들을 속일 수 있다.
-
네트워크 패브릭
패브릭이란 원래 실크나 면,마 같이 섬유소재를 짜서 만든 천을 의미한다. IT 환경에서는 이런 천과 직물처럼 아주 촘촘히 연결되어 있는 제품군을 '패브릭'이라고 일컫는다. 서비스와 기기들이 서로 긴밀히 연결되어 있는 것을 뜻한다.
즉, 네트워크 패브릭이란 네트워크 서비스와 관련 기기가 긴밀하게 융합되어 있는 환경을 일컫는다. 네트워크 패브릭은 네트워크 인프라를 단순화하고 비용절감을 실현하는데에 중점을 두었다. 이 환경에서 IT관리자는 I/O, 네트워크, 스위치,라우터 등 모든 네트워크 화면을 한 화면에서 통합적으로 관리할 수 있게 된다. 네트워크간 경계가 사라진 셈이다.
-
에이전트
제로 트러스트의 관점에서 보안은 모든 시스템 레벨에 보안 조치를 적용하는 것을 의미한다. 클라우드에서 제로 트러스트를 적용하여 시스템 보안을 수행하는 것과 관련된 세가지 주요 개념은 다음과 같다.
IAM(Identity and Access Management)
IAM은 시스템에서 ID 및 액세스를 추적하는 서비스이다. IAM은, IAM서비스라는 적절한 이름으로 AWS에서 관리된다. 액세스는 AWS 내에서 에이전트에 대한 액세스 경계를 적용하는 IAM 정책을 사용하여 관리된다. IAM 정책의 세가지 기본 구성요소는 다음과 같다.
- 주체 : 권한이 제공되는 대상을 지정한다.
- 작업 : 수행되는 것을 지정한다.
- 리소스 : 액세스 되는 속성?을 지정한다.
IAM에 제로 트러스트 모델을 적용하는 것은, 최소 권한 원칙을 사용 하는 것을 의미한다. 즉, 모든 에이전트에게는 기능을 수행하기 위해 필요한 가장 최소한의 권한이 부여되어야 한다.
IAM 정책은 AWS 주체 또는 AWS 리소스에 적용될 수 있다. 주체와 연관된 정책을 ID 기반 정책이라고 한다. 리소스와 연관된 정책을 리소스 기반 정책이라고 한다. 일부 서비스(예: S3, KMS, SES)에만 리소스 기반 정책이 적용 되는 것을 유의해야 한다.
주체가 특정 리소스에 대한 작업을 수행할 권한이 있는지의 여부는, 주체의 ID 기반정책이 이를 허용하는지의 여부 및 리소스의 리소스 기반 정책(있는경우)이 이를 금지하지 않는지의 여부에 따라 다르다.
이것은, IAM 권한 모델을 매우 간소화한 것임을 명심하자. 액세스 허용 여부에 영향을 주는 여러 추가저긴 정책 유형이 있다. 이러한 정책 유형으로는 권한 경계, 조직 서비스 제어 정책, 액세스 제어 목록 및 세션 정책 등이 있다.
이러한 추가 정책은 이 과정의 범위를 벗어나기 때문에 추가자료에서 나중에 확인하자.
요점
- IAM 정책은 AWS내에서 엔티티의 액세스 경계를 명시한다.
- IAM 정책은 주체, 작업, 리소스로 구성된다.
- IAM 정책을 사용하여 주체에 최소 권한을 적용할 수 있다.
- IAM에는 ID기반 및 리소스 기반 등 여러 정책 유형이 있다.
- IAM은 지정된 리소스에 적용할 수 있는 모든 정책 유형에 대한 평가를 기반으로 다시 액세스를 평가한다.
네트워크 보안
네트워크 보안에는 네트워크 및 네트워크에 엑세스할 수 있는 리소스의 액세스 및 사용성을 보호하는 시스템, 구성 또는 프로세스가 포함된다. AWS는 네트워크 수준 및 리소스 수준 모두에서 네트워크를 보호하기 위해 매우 다양한 기능을 제공한다.
네트워크 보안에 대한 제로 트러스트 접근법에는, 네트워크의 모든 레이어(가장 외부 레이어만이 아닌)에 보안 제어를 적용하는 심층적 방어 접근법이 포함된다.
네트워크 수준 보안
AWS에서 기본 네트워크 수준은 Amazon Virtual Private Cloud(VPC)이다. VPC는 리소스를 정의 및 프로비저닝할 수 있는 논리적인 네트워크이다.
VPC를 구성하는 일부 구성요소는 다음과 같다.
- 서브넷 : VPC 내부의 IP주소 범위
- 라우팅 테이블 : 트래픽이 이동하는 위치를 결정하는 규칙 집합
- 인터넷 게이트웨이 : VPC 내부의 리소스와 인터넷 사이에서 통신을 할 수 있게 해주는 구성요소
VPC에서 트래픽을 보호하려면, 리소스를 공용 리소스와 내부 리소스를 나눌 수 있다. 공격 표면을 줄이려면, 모든 인터넷 트래픽을 처리하는 Application Load Balancer(ALB)등과 같은 프록시 서비스를 이용할 수 있다. 그러면 서버와 데이터베이스 같은 모든 내부 서비스를 직접 공용 인터넷 액세스를 차단하는 내부 서브넷으로 프로비저닝할 수 있다.
VPC뿐만이 아니라, AWS Web Application Firewall(WAF)를 사용하여 네트워크에 대한 트래픽을 추가적으로 제한할 수 있다.
모르는 용어 설명
-
프로비전
'준비,대비'. 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업을 뜻한다. 예를 들면 8TB의 용량을 사용하는 서버컴퓨터에, 데이터가 폭증하여 8TB를 증설하였다가, 이후 압축알고리즘을 적용하여 공간수요가 줄어 다시 8TB를 줄이는 것. 이렇게 공간의 할당/회수를 하는 작업을 프로비저닝 이라고 한다.) https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=complusblog&logNo=220987906909
-
네트워크 레이어
OSI7계층 - 어플리케이션, 트랜스포트, 네트워크 를 뜻하는 것으로 보인다. 근데 HTTP밖에 몰라서 각각에 어떻게 보안제어를 적용하는지 모르겠음)
-
서브넷
너무 길어져서 링크로 대체
https://hyoje420.tistory.com/32
https://www.youtube.com/watch?v=o-NRjtQsJx4
3-1. 마스킹 개념을 알기
3-2. 한 사무실에 256-2 개의 주소를 할당하는기엔 사무실이 작다면? 서브넷 마스킹을 사용해서 네트워크 주소를 하나로 합치는 것.
3-3. 맨 뒤의 00000000은 한개의 주소만 구분할 수 있고, 이 값이 1000000 으로 바뀌면 2개의 주소를 구분할 수 있고, 11000000으로 바꾸면 4개의 구분을 할 수 있고... 하는 식이다.
-
라우팅 테이블
라우팅 테이블은 목적지와 목적지에 가려면 어느 인터페이스로 가야하는지에 대한 값을 갖고있다. 네트워크 상에서, 라우터가 어떤 목적지를 찾아가려고 할때 라우팅 테이블을 확인한다.
-
인터넷 게이트웨이
인터넷 게이트웨이에는 두 가지 목적이 있다. 1) 인터넷 라우팅 가능 트래픽에 대한 VPC 라우팅 테이블에 대상을 제공 2) 퍼블릭 IPv4 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)를 수행
인터넷 게이트웨이는 IPv4 및 IPv6 트래픽을 지원한다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않는다. 계정에 인터넷 게이트웨이가 있는 경우 추가 요금이 부과되지 않는다.
-
트래픽
사전적 의미에서 따온 컴퓨터 용어. 서버의 데이터 전송량을 의미한다
리소스 수준 보안
개별 AWS 리소스에도 사용자가 구성이 가능한 네트워크 보안 제어를 적용할 수 있다. 가장 일반적인 제어는 보안 그룹이다. 보안 그룹은, 리소스로 유입 및 유출되는 트래픽 흐름을 적용하기 위해 사용할 수 있는 가상 방화벽이다. 보안 그룹을 사용하면 특정 포트 또는 인스턴스에서 신뢰할수 있는 소스로부터의 트래픽만 허용할 수 있다. EC2 인스턴스, RDS인스턴스 및 Lambda 등의 리소스에 보안그룹을 연결할 수 있다.
요점
- 네트워크 보안에는, 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하도록 설계된 매커니즘이 포함된다.
- 네트워크 보안에 대한 제로트러스트 접근법에는 네트워크의 모든 레이어에 심층적인 방어를 구축하는 것이 포함된다.
- VPC 및 WAF를 사용하면, 네트워크 수준에 대한 보안 조치를 적용할 수 있다.
- 보안 그룹을 사용하면 리소스 수준에 보안 조치를 적용할 수 있다.
데이터 암호화
데이터 암호화는, 데이터의 암호를 해독하기 위해 필요한 키가 없는 제3자가, 이해할 수 없는 방식으로 정보를 암호화 하는 프로세스이다. 데이터에 제로 트러스트 모델을 적용하는 것은, 모든 곳에 있는 전송 및 저장 중 데이터를 모두 암호화 하는 것이다.
전송 중 암호화
전송중 암호화에서는 데이터가 시스템 사이에서 이동할 때 데이터를 암호화 한다. AWS내의 모든 저장소 및 데이터베이스 서비스는 전송 중 데이터 암호화를 지원하는 HTTP 엔드포인트를 제공한다. 또한, AWS는 사용자 서비스에 전송 중 암호화를 적용할 수 있는 네트워크 서비스도 제공한다. 예를 들어, Application Load Balancer를 사용하면 사용자의 엔드 포인트에 HTTPS 연결을 적용할 수 있다.
저장 중 암호화
저장 중 암호화에서는 시스템 내의 데이터가 암호화된다. 모든 AWS 저장소 및 데이터베이스 서비스는 저장 중 암호화를 지원한다. 이러한 서비스 중, 대부분은 암호화가 기본적으로 수행된다. 암호화를 위한 추가 비용 및 데이터를 암호화 하기 위한 성능 저하가 없다.
대부분의 저장소 및 데이터베이스 서비스는 Amazon Key Manager Service(KMS)와 직접 통합된다. 이는 데이터를 암호화하기 위해 고객 관리 키 (CMK)를 생성할 수 있도록 해주는 중앙 키 관리 서비스이다.
CMK를 사용하면 암호화 이상의 추가 기능이 제공된다. 추가 기능으로는 1. 사용자 지정 키 저장소 사용, 2. AWS CloudTrail 과 통합하여 암호화된 리소스에 대한 감사 추적 생성 및 자동 키 로테이션 적용 등이 있다.
요점
- 암호화는 올바른 키를 가지고 있는 당사자만 암호를 해독할 수 있는 방식으로 암호화를 하는 프로세스이다.
- 전송 중 및 저장 중 데이터를 암호화하여 데이터의 보안을 유지할 수 있다.
- AWS의 모든 저장소 및 데이터베이스 서비스는 전송중 및 저장 중 암호화를 제공한다.
- ALB 등 AWS 네트워킹서비스를 사용하면, 자체 서비스에 전송 중 암호화를 적용할 수 있다.
- CMK를 사용하면 감사 추적 생성, 자체 사용자 지정 키 사용 및 자동 키 로테이션과 같은 고급 기능을 활용할 수 있다.
모르는 용어
-
엔드포인트
커뮤니케이션의 한쪽 끝.
https://toneyparky.tistory.com/6
예를들어 OAuth에서는 3개의 엔드포인트가 있다.
- 서버에 인증되지 않은 요청 토큰을 얻기 위해 보낼 URI
- 1번에서 얻은 토큰을 승인하도록 하는 URI
- 승인된 요청 토큰을 액세스 토큰으로 교환하기 위해 요청을 보내는 URI, 보호된 자원에 대한 접근을 얻는 데 이용할 수 있다.
또다른 예시로는 API가 있다. 엔드포인트는 서비스를 사용가능하도록 하는, 서비스에서 제공하는 커뮤니케이션의 한쪽 끝. 즉 요청을 받아 응답을 제공하는 서비스를 사용할 수 있는 지점을 의미한다.
-
감사 추적
감사추적 (Adult Trail) - 컴퓨터 보안 시스템에서, 시스템 자원 사용에 대하여, 시간 순서에 따라 기록된, 사용 내역을 말한다.
이 기록에는 사용자 로그인, 파일 접근, 기타 다양한 활동 내역, 또는 실질적 또는 시도된 보안 위반사항이 합법적인지/허가를 받지 않고 발생했는지 여부가 포함된다.
결론
이 모듈에서의 학습 내용 정리
- AWS의 보안 주요사항
- 제로트러스트의 멘탈 모델
- IAM, 최소 권한 원칙
- AWS의 네트워크 보안 및 방어 원칙
- 데이터 암호화와 사용 및 미사용 데이터에 암호화 적용
3. 성능 효율성
이제 겨우 3번이라니 ..
성능 효율성 원칙은 클라우드에서 서비스를 효율적이고 확장 가능하도록 실행하는 방법에 중점을 둔다. 클라우드는 모든 규모의 트래픽을 처리할 수 있는 수단을 제공하는 반면, 이를 위해서는 확장을 염두하고 서비스를 선택 및 구성해야 한다.
멘탈 모델
클라우드에서는 성능 효율성을 고려할 때는, 서비스를 애완동물이 아닌 소라고 새악하는 것이 유용하다.
온프레미스 모델 방식에서는 서버가 비싸며 수동으로 배포 및 구성해야 하는 경우가 있다. 서버가 배송되어 데이터 센터에 물리적으로 연결 될 때까지는 몇주가 걸릴 수 있다. 이로 인해 서버는 각각이 고유하고 많은 유지관리가 필요한 애완 동물처럼 취급된다. 일부 서버에는 이름이 있는 경우도 있다.
반면, 클라우드에서는 서버는 소처럼 간주된다. 서버는 몇 초내에 자동으로 프로비저닝 될 수 있는 언제나 사용가능한 자원이다. 서비스의 작동에 필수적인 단일서버는 없다.
(*온프레미스(on-premise)는 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말한다.)
개념
서버를 소로 생각하는 것은 성능과 관련한 여러 이점이 있따. 서버관리의 "애완동물 모델"에서는, 여러 부하에 대하여 동일한 유형의 서버(또는 심지어 동일서버!)를 사용하는 것이 매우 일반적이며, 이로 인해 다른 시스템을 주문하고 프로비저닝하는 것이 매우 번거롭다. "소 모델"에서는 프로비저닝이 빠르고 저렴하며 워크로드와 가장 일치하는 서버 유형을 자유롭게 선택할 수 있다. (왠지 자랑/홍보가 되버렸음)
"소 모델" 에서는 서비스를 확장하는 것도 편리하다. 모든 서버가 호환되고 빠르게 배포할 수 있으므로, 더 많은 서버를 추가하여 용량을 빠르게 확장할 수 있다.
성능 효율성에서는 다음의 2가지 개념에 중점을 둔다.
- 셀렉트
- 확장
셀렉트
AWS에서의 셀렉트는 워크로드에 가장 적합한 서비스를 선택할 수 있는 기능이다. AWS는 24개 이상의 범주에서 175개 이상의 서비스를 제공하므로, 서비스의 선택폭이 광범위하다. 선택을 통해 성능을 goal? 하는 것은 작업에 적합한 도구를 선택할 수 있다는 의미를 갖는다.
일반적인 워크로드(부하)의 경우 컴퓨팅, 저장소, 데이터베이스 및 네트워크의 AWS 주요 4개 서비스 범주에서 선택하면 된다.
- 컴퓨팅은 데이터를 처리하는 서비스(예: 가상머신)이다.
- 스토리지(저장소)는 데이터를 정적으로 저장하는 서비스(예: 객체 저장)이다.
- 데이터베이스는 데이터를 구조화하여 저장하는 서비스 (예 : 관계형 데이터베이스) 이다.
- 네트워크는 데이터의 이동 방법과 관련한 서비스 (예 : 콘텐츠 전송 네트워크) 이다.
이 모듈에서는 첫 3가지 범주에서 올바른 선택을 하는 방법에 대해 알아보자. 다양한 네트워크 옵션 중에서의 선택과 관련한 지침은, 추가자료 섹션을 참고하자.
어느 범주에서 선택하던지 간에, 다음 3가지 사항을 고려해야 한다.
- 서비스 유형
- 관리 수준
- 구성
서비스 유형
카테고리/범주에서 선택할 때, AWS는 사용할 수 있는 서비스의 유형에 대한 다양한 옵션을 제공한다. 유형은 각 범주마다 다르다.
- 컴퓨팅 서비스
컴퓨팅 서비스를 선택할 때는, 1) VM 기반 2) 컨테이너 기반 3)서버리스 기반 컴퓨팅 중에서 선택할 수 있다.
-
VM기반 컴퓨팅은 대부분의 사용자에게 가장 익숙한 멘탈 모델이지만, 비용과 유지관리가 더 많이 필요할 수 있다.
-
컨테이너 기반 컴퓨팅을 사용하면 워크로드를 세밀하게 분할하고 빠르게 확장할 수 있지만, 추가적인 구성 및 오케스트레이션(조화/조합)이 복잡할 수 있다.
-
서버리스 기반 컴퓨팅에서는 대부분의 관리 및 확장 복잡성이 사라지지만, 하드 시스템 제한이 있고 새로운 도구 체인 및 프로세스를 도입해야할 수 있다.
- 스토리지 서비스 스토리지 서비스를 선택할 때는 1) 파일 저장 2) 블록 저장 3)객체저장 4) 아카이브 저장 중에 어떤 것이 필요한지의 여부를 결정해야 한다.
- EBS 등의 블록 스토리지는 단일 EC2 인스턴스에서 제공되는 데이터를 유지하는 데 적합하다.
- EFS 등의 파일 시스템은 동일 데이터에 다중 클라이언트 액세스를 제공하는 데 적합하다.
- S3 등의 객체 스토어는 많은 수의 클라이언트가 액세스해야 하는 데이터의 대규모 Blob에 적합하다.
- S3 Glacier 등의 아카이브 스토리지는 자주 액세스하지 않는 큰 데이터에 적합하다.
- 데이터베이스 서비스 데이터베이스 서비스를 선택할 때는 관계형 데이터베이스, 비관계형 데이터베이스, 데이터 웨어하우스 솔루션 또는 데이터 인덱싱 및 검색 솔루션이 필요한지의 여부
- 관계형 데이터베이스를 사용하면 속성의 조인 및 ACID를 수행할 수 있지만, 성능과 데이터 스토리지의 상한이 적용된다.
- 비관계형 데이터베이스는 스키마가 보다 유연하고, 관계형 데이터베이스에 비해 상한이 높지만, 조인 및 전체 ACID 기능이 일반적으로 부족하다.
- 데이터 웨어하우스 솔루션을 사용하면 페타바이트 규모의 구조화된 데이터에 빠르게 액세스 할 수 있어 라지 분석이 가능하다.
- 데이터 인덱싱 및 검색 솔루션을 사용하면 매우 다양한 리소스의 데이터를 인덱싱 및 검색할 수 있다.
관리수준
서비스 유형을 결정한 후에는 사용할 서비스의 범위를 줄여야 한다. 어떤 경우, AWS는 특정 서비스 유형에서 여러 서비스를 제공하기도 한다. 동일한 유형의 서비스 중 여러 AWS 서비스 간의 주된 차이점은, 어느정도로 관리가 되느냐이다.
컴퓨팅 서비스를 사용하며 VM 유형을 결정한 경우에는 EC2, Lightsail 및 Elastic Beanstalk 중에서 선택해야 한다. EC2를 사용하면 제어 수준이 가장 높지만 관리 수준은 가장 낮은 반면, Lightsail의 경우 매우 향상된 관리형 경험을 위한 사용자 지정이 가능하다. Elastic Beanstalk은 EC2와 Lightsail 사이의 관리 수준을 제공하며, 서비스 아키텍처를 위한 독자적인 프레임워크를 제공하지만 구성을 통해 사용자 지정하는 것이 가능하다.
스토리지 서비스를 사용하는 경우에는 지정된 유형에 1개의 서비스만 제공되는 경향이 있으므로 서비스를 편리하게 선택할 수 있다(예: 객체 저장의 경우 S3, 파일 저장의 경우 EFS).
데이터베이스 서비스를 사용하며 관계형 유형을 결정한 경우에는 RDS와 Aurora 중에서 선택해야 한다. RDS는 기본 데이터베이스에 대한 향상된 제어 수준을 제공하며 대부분의 관계형 데이터베이스에서 사용할 수 있다. Aurora는 MySQL 및 PostgreSQL 의 특정 버전에서만 동작하지만, 기본 스토리지에 대한 관리 수준이 향상되고 내장 클러스터가 지원된다.
구성
서비스를 선택한 후에는 구성 방법을 결정해야 한다. 구성은 달성하려는 특정 성능 특성에 따라 달라지며, 성능 특성은 각 서비스 범주마다 다르다.
컴퓨팅서비스에 대한 성능 특성을 평가할 때는 메모리 및 컴퓨팅 요구사항을 살펴보는 것이 좋다.
- VM기반 컴퓨팅을 사용할 때, 메모리 및 CPU는 인스턴스 크기 및 인스턴스 패밀리에 의해 영향을 받는다.
- 컨테이너 기반 컴퓨티응ㄹ 사용할 때는 메모리와 CPu 를 개별적으로 설정할 수 있다.
- 서버리스 컴퓨팅을 사용할 때는, 메모리만 직접 설정이 가능하며 컴퓨팅의 값(및 기타 시스템 리소스)은 가용 메모리의 양에 따라 선형적으로 증가한다.
워크로드에 따라, 인스턴스 스토리지와 같은 특정 리소스의 가용성 및 네트워크 용량 등을 고려해야 하는등의 추가적인 리소스 제약이 있다는 것에 유의하자
스토리지 서비스에 대한 특정 성능을 평가할 때는 대기시간, 처리량 및 IOPS 요구사항을 고려해야 한다.
- 블록 스토리지 서비스를 사용하는 경우
- 대기 시간은 선택한 볼륨 유형 (Ex. SSD / HDD) 의 영향을 받는다.
- 처리량은 대부분 볼륨 크기에 비례한다.
- IOPS는 대부분 볼륨 크기에 비례한다.
- 파일 시스템 서비스를 사용하는 경우
- 대기시간 및 IOPS는 성능모드의 영향을 받는다.
- 처리량은 프로비저닝된 처리량의 사용 여부에 영향을 받는다.
- 객체 스토어를 사용하는 경우
- 대기시간은 버킷 엔드포인트까지의 지리적 거리?에 의해 영향을 받는다.
- 처리량은 멀티파트 업로드 등과 같이 처리량에 최적화 된 API의 사용 여부에 의해 영향을 받는다.
- IOPS는 구성할 수 없다.
- 아카이브 스토어를 사용하는 경우
- 대기 시간은 버킷 엔드포인트까지의 지리적 거리 및 선택한 검색 방법에 의해 영향을 받는다.
- 처리량은 멀티파트 업로드 등과 같이 처리량에 최적화된 API의 사용 여부에 의해 영향을 받는다.
- IOPS는 구성할 수 없다.
데이터베이스 서비스의 성능 특성을 평가할 때는, 리소스 요구사항 (CPU, 메모리, 저장공간)을 고려해야 한다.
- 관계형 데이터베이스를 사용하는 경우
- 리소스 기능은 선택한 EC2 인스턴스에 의해 결정된다.
- DynamoDB와 같은 비관계형 데이터베이스를 사용하는 경우
- 리소스 기능은 프로비저닝된 용량과 같은 구성 옵션에 의해 결정된다.
- Redshift와 같은 데이터 웨어하우스 솔루션을 사용하는 경우
- 리소스 기능은 선택한 기본 EC2 인스턴스에 의해 결정된다.
- Elasticsearch Servcie와 같은 인덱싱 솔루션을 사용하는 경우
- 리소스 기능은 선택한 Ec2 인스턴스에 의해 결정된다.
모르는 용어
-
schema/스키마
데이터베이스를 구성하는 레코드의 크기, 키(key)의 정의, 레코드와 레코드의 관계, 검색 방법 등을 정의한 것.
-
블록 스토리지/블록 저장
블록(block)이란 다수의 트랜잭션을 모아서 하나로 관리하기 위한 묶음이다. 예를 들어, 비트코인의 경우 10분간 진행된 약 2,000건의 거래내역을 하나의 블록으로 묶어서 관리한다. 라이트코인의 경우 약 2분 30초 동안 진행된 거래내역을 하나의 블록으로 만들어 관리한다. 하나의 블록을 다음 블록과 이어주기 위해 해시를 이용하여 체인 구조를 만들 수 있다. 이처럼 다수의 트랜잭션을 블록으로 묶은 후 시간 순서에 따라 체인으로 엮은 것을 블록체인(blockchain)이라고 한다.
종종 "블록 레벨 스토리지"라고도 하는 블록 스토리지는 SAN(Storage Area Network) 또는 클라우드 기반 스토리지 환경에 데이터 파일을 저장하는 데 사용되는 기술입니다. 개발자들은 빠르고 효율적이며 안정적인 데이터 전송이 요구되는 컴퓨팅 상황의 경우 블록 스토리지를 선호합니다.
블록 스토리지는 일단 데이터를 블록으로 분할한 후, 해당 블록을 각각 고유 ID를 지닌 개별 조각으로 저장합니다. SAN은 가장 효율적이라면 어디에든 데이터의 해당 블록을 배치합니다. 다시 말하면 SAN은 서로 다른 시스템에 해당 블록을 저장할 수 있으며, 각 블록은 서로 다른 운영체제에서 작동하도록 구성(또는 파티션)될 수 있습니다.
블록 스토리지는 또한 사용자 환경으로부터 데이터를 디커플링함으로써 해당 데이터가 다수의 환경에서 분산될 수 있도록 허용합니다. 이렇게 되면 데이터에 대한 다수의 경로가 만들어지며, 사용자는 이를 통해 데이터를 빠르게 검색할 수 있습니다. 사용자나 애플리케이션이 블록 스토리지 시스템의 데이터를 요청하는 경우, 기반 스토리지 시스템은 데이터 블록을 재구성한 후 사용자나 애플리케이션에 해당 데이터를 제시합니다.
-
Blob
컴퓨터에서, BLOB[블랍]은 대체로 이미지나 사운드 파일과 같은 하나의 커다란 파일을 말하며, 그 크기 때문에 특별한 방법으로 다루어져야한다.
-
ACID
ACID(원자성, 일관성, 고립성, 지속성)는)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다. 짐 그레이는 1970년대 말에 신뢰할 수 있는 트랜잭션 시스템의 이러한 특성들을 정의하였으며 자동으로 이들을 수행하는 기술을 개발해 냈다.
-
관리수준
-
내장 클러스터
데이터 클러스터(data cluster)는 파일과 디렉토리(폴더)에 디스크 공간을 할당하는 단위로 파일을 저장하도록 할당될 수 있는 가장 작은 논리적 디스크 공간을 말한다. 할당단위라고도 한다. 디스크상 데이터 구조 처리의 오버헤드를 줄이기 위해 클러스터라고 불리는 인접한 섹터 집단을 할당한다.
데이터 클러스터는 컴퓨팅 분야 안에 다른 유형의 클러스터 중 하나이다. 데이터를 클러스터링한다는 것은 연속적으로 액세스하는 데이터를 밀접하게 함께 저장하여 입출력 작업을 적게 하는 것을 의미한다. 데이터 클러스터는 데이터베이스 튜닝 측면에서 매우 중요하다. 반대로 컴퓨터 클러스터는 데이터베이스 환경에서 매우 일반적이다. 즉, 클러스터라는 용어를 모호하게 만든다. 클러스터를 사용하여 데이터베이스 성능을 향상할 수 있는 한 가지 예일 뿐이다.
-
IOPS
저장장치 단위. 아이옵스는 HDD, SSD, SAN 같은 컴퓨터 저장 장치를 벤치마크하는 데 사용되는 성능 측정 단위다. IOPS는 보통 인텔에서 제공하는 Iometer 같은 벤치마크 프로그램으로 측정된다.
요점
- AWS는 원하는 결과를 달성하기 위한 다양한 서비스와 방식을 제공한다.
- AWS에서 워크로드를 구현하기 위해서는 컴퓨팅, 스토리지, 데이터베이스 및 네트워크 범주에서 서비스를 선택해야 한다.
- 각 범주 내에서는 사용 사례에 따라 적합한 서비스 유형을 선택할 수 있다. (카테고리)
- 각 유형 내에서는 원하는 관리 수준에 따라 특정 서비스를 선택할 수 있다. (상품)
- 각 서비스 내에서는 달성하려는 특정 성능 특성에 따라 특정 구성을 선택할 수 있다. (옵션)
결론
이 모듈에서 배운 것.
- AWS의 성능 효율성 원칙
- 서비스를 애완 동물이 아닌 소의 개념으로 처리하는 멘탈 모델
- 성능 목표에 따라 적합한 서비스와 구성을 선택하는 방법
- 서비스 확장 및 수직과 수평 확장 사이의 트레이드오프
후기
상기 내용 외의 안정성, 운영 우수성, 비용 최적화등의 내용은 이제 시작하는 단계에서는 필수적인 내용은 아닌 것 같아 생략한다.
모르는 단어나 용어가 많아 읽는데 꽤 시간이 걸리긴 했지만, AWS 서비스를 사용하기 전에 먼저 꼭 읽어봐야 하는 개념들이 있어 도움이 됬다.
IAM, VPC, 각 카테고리 내의 서비스가 대략 어떤 경우에 사용되는지, 아마존은 보안과 안정성을 위해 엄청나게 여러 단계의 보안을 하고 있다는 것등을 알게 되었다.
