스토리지 서비스
- 스토리지의 유형
스토리지의 종류는 세 가지,
블록 스토리지, 파일 스토리지, 객체 스토리지로 나뉜다.
- 블록 스토리지
블록 스토리지는 데이터를 블록 단위로 나누어 저장한다.
각 블록의 크기가 균일한 고로
데이터 입출력 성능이 좋다. (IOPS에 대해 신속한 검색이 가능하다.)
대용량 트랜젝션이/대규모 데이터 저장이 용이한 고로
기업들이 가장 많이 쓰는
스토리지이다.
AWS에서는 EBS라는 이름으로 제공되어
EC2에 사용할 수 있다.
하나의 EBS는 하나의 가용 영역 안에서만 쓰일 수 있으므로,
가용 영역이 다른 인스턴스에 제공되지는 않는다.
다른 리소스들과 마찬가지로 AMI로 백업하여
EC2 객체 템플릿으로 쓸 수 있다.
주의해야 할 점 하나.
동일 가용 영역 안이므로 위와 같은 연결도 가능은 하다... 만,
블록 스토리지의 활용 이유가 검색 성능 때문인데
저런 구조는 성능이 쪼개지는 관계로 보통 안 쓴다.
EBS는 SSD기반이냐, HDD 기반이냐에 따라 나뉘는데,
알다시피 SSD는 IOPS(입출력 속도)가 뛰어나고
HDD는 Throughout(처리량)이 뛰어나다.
< SSD 기반 EBS >
- 범용 SSD : 가격 - 성능간 균형, 범용적
- Provisioning된 SSD : 성능 특화, 미션 크리티컬 워크로드*에 적합
*미션 크리티컬 워크로드 : 조직의 성공, 생존, 혹은 핵심 목표 달성에 필수적인 작업이나 프로세스
<HDD 기반 EBS>
- 처리량 최적화 HDD : 빅데이터나 데이터 웨어하우스 처리에 적합
- 콜드 HDD : 성능이 가장 떨어지지만 가장 저렴함
대부분의 클라우드 스토리지는 증분식 백업 방식을 사용한다.
EBS에서는 스냅샷마다 증분식으로 저장되며,
이 방식으로 인해 스냅샷 생성 시간과 비용을 최소화할 수 있다.
이렇게 만든 EBS 스냅샷은
다른 가용 영역, 더 나아가 다른 리전에 복제할 수 있다.
이를 통해 DR 측면에서의 안정성을 확보할 수 있는거지.
< 인스턴스 스토어 >
몇몇 예외적 상황에서 임시로 사용하는 블록 스토리지.
얘는 물리적 디스크에 위치한다.
알다시피 인스턴스를 재부팅했을 때,
VM은 그때그때 여유가 있는 물리적 서버 위에서 실행된다.
따라서 인스턴스 스토어는,
다음 부팅에서 해당 인스턴스와 같은 물리적 서버에 있다는 보장이 없다.
그래서 임시 정보(버퍼, 캐시 등)을 저장하는 데 쓴다.
- 파일 스토리지
데이터를 파일 형태로 저장하는 스토리지.
가장 중요한 포인트는
블록 스토리지가 부적절한 아키텍처를 구성하는데 유리하다는 점이다.
위에서 봤던 방식, 스토리지 하나에 여러 인스턴스가 접근하는 경우이다.
블록 스토리지는 이때 성능이 저하되지만,
파일 스토리지는 그렇지 않다.
또한 다른 가용 영역의 인스턴스가 스토리지에 액세스할 수 있다.
다시말해, 공유 파일 시스템을 활용할 때 가장 적절한 스토리지 형태라고 할 수 있다.
확장성이 좋단거지.
AWS에서는 EFS라는 이름으로 서비스되며,
수천 대의 EC2 인스턴스 및 On-premise 서버의 동시 액세스가 지원된다.
- 객체 스토리지
객체 스토리지는 다양한 유형/대량의 데이터 저장을 위한 스토리지이다.
객체(Object)라는 이름은,
데이터와 메타 데이터를 하나로 묶어서 저장하는 방식 때문에 붙었다.
저장 시 객체마다 고유의 URL이 생기므로,
권한이 있는 사용자는 이를 통해 web에서 즉각적 접근이 가능하다.
AWS에서는 Simple Storage Service,
줄여서 S3라는 이름으로 서비스된다.
S3를 이해하기 위해서는 버킷의 개념을 알아야 한다.
버킷은 일종의 컨테이너로,
쉽게 말하자면 객체들을 저장하는 바구니(Bucket)이다.
버킷의 이름은 AWS 전체에서 고유해야 하고,
위에서 말했듯이 객체 수의 제한 없이 저장이 가능하다.
객체는 수정이 불가능하기 때문에,
사용자는 버킷에서 수정하고자 하는 객체를 삭제하고
새로운 버전을 저장하는 방식으로 관리하게 된다.
< S3의 특징 >
- 99.999999999%의 내구성
동일 리전 내 최소 3개의 가용 영역에 자동 복제되므로,
데이터 손실 위험이 극도로 적다.
- 무한대의 확장성
저장할 수 있는 데이터 전체 볼륨과 객체 수의 제한이 없다.
(YB 단위까지도 문제 없이 돌아가는듯)
- 비용 최적화
스토리지 클래스*와 수명주기 정책*을 통해 비용을 절약할 수 있다.
* 스토리지 클래스 : 데이터 접근 빈도에 따라 조회 성능 등을 조절하여 비용을 최적화한다.
* 수명주기 : 시간 흐름에 따라 데이터가 다른 스토리지 클래스로 이관되도록 만드는 정책
이상의 기능은 AWS 뿐만 아니라 GCP, Azure에서도 제공한다.
하지만 AWS만이 가진 기능으로 intelligent-tiering이 있는데,
쉽게 말하자면 수명주기를 자동으로 조정해 주는 모니터링 서비스이다.
한편 스토리지에 대한 접근 제어는 다음과 같은 방법으로 이루어진다.
< 버킷 정책 >
버킷에 대한 접근 권한을 정의한 것이다.
버킷의 기본 설정은 비공개, 즉 Owner Only로 되어 있다.
이를 조절하여 다른 사용자에게 액세스 권한을 부여하거나,
아예 Public으로 만들 수도 있다.
기본적으로 JSON기반 언어로 작성되나,
AWS는 Policy Generator를 통해 손쉽게 만들 수 있도록 지원한다.
< Presigned URLs >
버킷 정책 설정 없이,
URL을 가진 유저가 정해진 시간동안 접근 가능하도록 설정하는 옵션이다.
이 경우 DNS를 활용하여 특정 도메인으로 호스팅하는 것도 가능하다.
AWS에서 자체적으로 DNS 서비스인 'Route53'을 제공하기 때문이다.
버킷은 엣지 로케이션으로 캐싱하는 원본(Origin)역할도 수행한다.
지난 시간에 보았듯 엣지 로케이션으로의 캐싱이 이루어지면
사용자는 매번 버킷에 접근할 필요 없이 엣지 로케이션에서 바로 미디어를 제공받는다.
이번엔 객체 스토리지의 버전 관리 기능에 대해 알아보자.
기본은 버킷에 여러 버전의 객체를 보관하는 것이다.
다시말해, 새로운 버전을 기존 버전에 덮어쓰지 않고
버킷 내에는 이전 버전이 계속 존재하는 방법이다.
파일을 삭제했을 때도 실제 데이터가 사라지지는 않고,
삭제 마커가 붙은 채로 보관된다.
그러다 보니 용량은 좀 부족해지긴 한다.(비용도 커진다.)
추가적인 몇몇 기능에 대해 살펴보자.
객체 잠금 기능
객체 잠금은 객체의 삭제나 덮어쓰기를 막는 기능이다.게임에 나오는 아이템 잠금 같은 거다.
데이터 암호화
데이터 전송 중 / 유휴 시에 암호화함으로써 보안성을 높이는 기능이다.
전송 중에는 클라이언트측에서 암호화되어 클라우드로 옮겨진다.
유휴 시에는 서버측에서 암호화되어 저장된다.
데이터 복제
데이터를 서로 다른 리전 또는 가용 영역에서 복제하는 기술이다.
데이터 복제가 으레 그렇듯 대기시간 최소화, 백업, DR 등의 목적으로 활용된다.
데이터 업로드
데이터의 이동 속도를 높이기 위한 다양한 기술들이다.
- Multipart Upload
대용량의 객체를 분할하여 병렬적으로 업로드하는 기술이다.
각각의 부분들은 업로드 중에 다른 부분에 영향을 주지 않으므로,
장애가 발생해도 해당 부분만 복구하면 된다.
- Transfer Acceleration
업로더가 리전에 직접 접근하지 않고,
엣지 로케이션까지만 접근(인터넷 선)한 후
엣지에서 리전까지 접근(전용선)함으로써 이동 속도를 높이는 기술이다.
- Snowcone / Snowball Edge
대량의 데이터는 시간이 오래 걸리므로,
오프라인으로 클라우드에 이관하기 위한 장비들이다.
데이터베이스 서비스
SQLD에서 배웠던 걸 한번 짚고 가자.
관계형 DB : 테이블형의 고정 스키마를 가진 DB(RDB)
비관계형 DB : 데이터 유형이 고정되지 않은 동적 스키마 DB(NoSQL)
인메모리 DB : 디스크가 아닌 메모리에 데이터를 저장하는 DB
AWS의 대표적인 DB 서비스는 위의 DB 유형에 따른 세 가지를 꼽을 수 있다.
| 관계형 DB | RDS |
| 비관계형 DB | DynamoDB |
| 인메모리 DB | ElastiCache |
- RDS
RDS는 AWS에서 제공하는 관계형 데이터베이스 관리 시스템으로,
클라우드에서 관계형 데이터베이스를 설정/운영/확장할 수 있다.
클라우드에서 가능하다는 건,
데이터베이스 운영 중에도 멈춤 없이 업데이트가 가능하단거지.
MySQL, MariaDB, Oracle Database 등 기존 데이터베이스 엔진을 선택할 수 있다.
RDS는 Fail-Over를 통해 고가용성을, Read Replicas를 통해 확장성을 확보한다.
Fail-over는 장애 발생 시 자동으로 (미리 복제해 둔) 대체 인스턴스로 전환되는 기능이다.
이를 통해 서비스 중단을 최소화할 수 있겠지.
Read Replicas는 RDS에서 읽기 작업을 분산 처리하는 기능이다.
읽기 전용 테이블을 미리 복제해 두고
이 레플리카가 읽기 작업을, 원본이 쓰기 작업을 진행한다.
이 RDS의 강화 엔진으로 Aurora가 있다.
더 성능 좋고 비싸다.
- DynamoDB
NoSQL, 그러니까 비관계형 데이터베이스를 관리하는 DBMS이다.
아주 뛰어난 읽기/쓰기 기능을 지원하는데다
용량도 페타바이트 규모고 데이터 자동 복제를 통한 고가용성도 지원한다.
게다가 서버리스 서비스라서 인프라 구출이 불필요하다.
때문에 게임 등 다양한 분야에서 폭넓게 쓰인다.
데이터 모델이 매우 유연한게 특징인데
데이터를 키(파티션 키 + 정렬 키)와 값의 쌍으로 구성하여
단순하고 빠른 데이터 검색이 가능하다.
- ElastiCache
ElastiCache는 클라우드에서 인메모리 DB를 관리한다.
메모리에 DB가 저장되니 응답속도가 매우 빠르지만 영속성이 보장되지 않는다.
원본 DB에 대한 최초 접근 이후로는
App에서 이 캐시 DB를 검색해서 바로 사용자에게 전달하기에
원본 DB에 접근할 필요가 없다.
엣지 로케이션과 같은 원리.
- Data Migration Service
AWS는 DB의 운영을 중단하지 않으면서 다른 곳에 마이그레이션할 수 있는 서비스를 제공한다.
여기에는 지속적인 복제(CDC, Change data capture)에 대한 이해가 필요한데,
쉽게 말하자면 DB의 각종 변동사항을 계속 캡처하여
복제 대상에 실시간으로 적용하는 방법이다.
게다가 AWS의 스키마 컨버전 도구를 통해 이기종 DB간에도 마이그레이션이 가능해지게 된다.
마이크로 서비스
우리가 1일차에서 살펴봤듯이, 클라우드와 on-premise는 일장일단이 아니다.
현실적으로느 클라우드가 그냥 상위호환이다.
따라서 전반적인 IT 트렌드는 클라우드 네이티브(Cloud Native)라고 할 수 있다.
클라우드 네이티브로의 변경은 구체적으로 어떻게 흘러갈까?
| Traditional | Cloud - Native | |
| 구축 | 온프레미스, 데이터센터 | 클라우드 |
| 아키텍처 | 모놀리스 | 마이크로 서비스 |
| 컴퓨팅 | 물리적 서버 + 가상화 | 컨테이너 |
| 조직/프로세스 | 역할 분리 | DevOps |
| 빌드/배포 | 수작업 | CI/CD, 자동화 도구 |
여기서 나머진 배웠으니, 마이크로서비스와 컨테이너에 대해 배워 보자.
- 마이크로 서비스란
기존의 서비스 아키텍처를 Monolithic이라고 한다.
모든 기능들이 긴밀하므로 개발과 관리가 용이하다는 장점이 있다.
하지만 부분 수정이 힘들어 확장성과 유연성이 떨어진다.
따라서 대규모 서비스가 될 경우 더 많은 문제를 발생시키는 구조다.
MicroService는 정확히 반대다.
하나의 큰 애플리케이션을 작은 서비스 유닛으로 쪼개서 변경/조합이 용이하다.
당연히 관리가 어렵고 표준화가 부족해질 수 있지만,
특정 서비스만 빠르게 빌드/배포 가능하다는 점(독립성),
전체 서비스 중단 없이 업데이트가 가능하다는 점(안정성)
장애 발생 시 필요한 시간과 비용이 적다는 점(유지관리성)
기능별로 최적의 기술, 언어, 버전, DB를 사용할 수 있다는 점(기술 유연성)
측면에서 장점을 가지고 있다.
물론 서비스 구축이 어렵고 비용이 비싸기 때문에, 남용할 수는 없다.
따라서 우리는,
1. 대규모 애플리케이션을 서비스해야 하고
2. 지속적인 확장/개선을 필요로 할 때
마이크로서비스 아키텍처(MSA)를 적용해야 한다.
- 컨테이너
IT 인프라에서도 배웠지만,
컨테이너는 OS상에서 프로세스를 격리, 독립적 환경에서 실행시키는 기술이다.
컨테이너에는 애플리케이션뿐만 아니라 각종 환경이 함께 패키징되는데,
애플리케이션 코드, 런타임, 라이브러리, 구성이 다 묶여 있다.
(이 각각의 구성이 Docker file화되어 컨테이너로 묶인다.)
때문에 다른 환경에서도 테스트, 운영을 정상적으로 할 수 있다.
컨테이너의 장점은 다음과 같다.
| 이식성 | 애플리케이션과 실행 환경의 묶음 Docker / Kubernetes 등의 표준화 어떤 환경에서도 호환 가능 |
로컬에서 Docker 컨테이너로 작성한 애플리케이션을 AWS ECS, GCP GKE, Azure AKS에 배포 |
| 경량성 | VM과 달리 App마다 OS가 있지 않음 호스트 OS 커널 공유 빠른 배포와 적은 스토리지 사용량 |
하나의 물리 서버에서 수십 개의 컨테이너 실행이 가능 |
| 확장성 | 특정 서비스만 독립적으로 확장 가능 로드밸런싱을 통한 부하 균등 배분 오케스트레이션 도구를 통한 스케일링 |
갑작스러운 트래픽 증가를 대비해 몇 초 만에 컨테이너 인스턴스를 수백 개로 확장 가능 |
설명만 봐도 MSA와 찰떡이다.
컨테이너의 구성을 살펴보자.
물리적 서버 → 가상 머신 → 컨테이너 발전상.
각 컨테이너에 OS가 없어 가볍다.
이외에도 컨테이너는 가상 머신에 비해 상대 우위를 갖는 점들이 있는데,
구동 시간이 수 초로 훨씬 짧고
OS가 없어서 이미지의 크기도 작다.
- 쿠버네티스
아, 컨테이너.
아, MSA.
참 좋은데, 이거 관리 어떻게 할까?
애플리케이션을 엄청 쪼개 놓은 것까지는 좋다.
근데 이걸 관리할 수가 있어야지.
그래서 필요한 것이 컨테이너 오케스트레이션 도구이다.
컨테이너 오케스트레이션 도구는
수많은 컨테이너의 배치, 제어, 확장, 밸런싱, 보안.... 등등 모든 요소를 관리하는 툴이다.
컨테이너 패키저가 사실상 Docker 원툴인 것처럼,
컨테이너 오케스트레이션 도구도 Kubernetes 원툴이다.
쿠버네티스는 구글의 오픈소스 프로그램으로,
구글 답게 오픈소스 생태계의 각종 제품들과 결합 가능한 점이 특징이다.
쿠버네티스의 기본 구조는 Control Plane과 Data Plane으로 나뉘는데,
Control Plane은 각 컨테이너들을 어느 Pod로 보낼지를 정하고,
컨테이너 클러스터의 상태가 어떤지 감시하는 한편
클러스터들을 제어한다.
Data Plane은 Control Plane에 의해 분배된 컨테이너가 들어가는 곳으로,
각 워커노드에 배분된 Pod에서 실제로 App이 실행 및 유지관리되는 부분이다.
컨트롤 플레인의 구성 요소
API 서버(API Server): 클러스터와 사용자 간의 인터페이스 역할.
스케줄러(Scheduler): Pod가 실행될 워커 노드를 결정.
컨트롤러 매니저(Controller Manager): 클러스터의 상태를 지속적으로 감시하고 필요한 조치를 수행.
etcd: 쿠버네티스의 상태 정보를 저장하는 분산 키-값 저장소.
한편 쿠버네티스에도 단점이 있는데,
초기 설정과 운영이 복잡하다는 것이다.
이런 점을 극복하기 위해 각 클라우드 서비스들은
쿠버네티스 관리 도구(Kubernetes Service)를 제공한다.
AWS : Elastic Kubernetes Service(EKS) 얘네 참 엘라스틱 좋아한다.
Azure : Azure Kubernetes Service(AKS)
GCP : Google Kubernetes Engine(GKE)