cloud를 설명할 때 여러 개념들이 등장하지만 여기서는 확장성과 가용성에 대해 다루어본다.
확장성과 가용성을 설명하기전, cloud서비스의 장점을 다시 한 번 복습하면 아래와 같다.
* 클라우드 서비스의 장점
1. 주문형 셀프 서비스 : 필요할 때 사용
2. 준비된 대규모 자원 : 이미 있는 대규모의 물리 서버(클라우드 회사의)를 활용 가능
3. 종량제 과금 : 사용 기반의 과금 체계
4. 관리편의성 : API, 직관적 UI 등
1. 확장성(Scalability)
cloud는 확장성을 제공해 주는 기반이 잘 되어있을 뿐, 실제 확장성 구현에는 여러 고민이 필요함.
특히나 최근 IT환경에서는 서비스 부하에 대응해 탄력적으로 대응할 수 있는 환경(On-Demand)이 필요하였음.
(블랙프라이데이와 같이 특정 기간에만 사용량이 크게 늘어나는 경우들..)
-> 특정 시간에만 임대할 수 있는 환경을 어떻게 구현할 수 있을까?라는 질문에 대한 답을 구하는 과정에서 '확장성'이라는 개념이 등장하게 됨.
* On-Demand : 공급이 아니라 수요가 모든 것을 결정하는 시스템 또는 전략을 의미함.
확장성에는 아래와 같이 2가지 종류가 존재.
1) 수직적 확장(Scale up)
가상화 서버를 더 큰 규모로 확장
하나의 서버에서 모든 부하를 받아야되는 구조에서 사용함.
예) 2 Core, 메모리 1GB -> 4 Core, 메모리 2GB로 변경
2) 수평적 확장(Scale out)
동일한 규모의 가상화 서버를 복제 / 추가하는 방식
부하가 분산될 수 있는 구조인 경우에서 사용함.
예) 2 Core, 메모리 1GB 한개를 3개로 늘림
cloud 환경에서는 수평적 확장을 더 선호함 (서버를 필요에 의해 늘렸다가 다시 줄이는 것이 수직적 확장보다 용이하므로)
사실 모든 서비스가 확장이 필요한 건 아님. 서비스 특성에 따라 확장하지 않고 추가되는 요구들은 차단해버리는 경우가 생길 수도 있다.
-> '서버를 어느 시점에 늘릴 것인지' 이를 자동화시켜놓는게 중요하고 어려운 이슈.
cloud가 자체적으로 확장 기술을 제공하지는 않으므로, 확장성을 자동화시키기 위해서는 cloud를 모니터링(관제)해야할 필요성이 생김. 전통적인 IT 환경보다 cloud는 불안정하기에, 관제해야하는 부분은 많다. 모니터링과 관제를 통해 쌓은 경험과 노하우를 바탕으로 CPU, Disk, 메모리 사용량에 대한 다양한 조건 설정을 찾고 자원이 적절히 분배되도록 설정해놓는게 중요하다.
2. 가용성(Availablity)
가용성이란 장애나 문제가 생겼을 때에도 서비스를 제공할 수 있는지의 여부를 의미한다.
(장애가 발생하더라도 안정적인 서비스가 제공되기를 원하므로..)
전통적인 IT환경보다 cloud 인프라가 불안하다. 그 관점에서 본다면 가용성이 확보되지 않을 수도 있음. 이를 극복하기 위해 등장한 개념이 MSA.
-> 가용성을 이해하기 위해서는 클라우드 회사가 어떤 형태로 데이터센터와 물리서버를 갖추었는지 이해하는게 중요하다.
(여기서는 AWS를 예시로 설명해보도록 한다.)
Region : 가장 큰 기준임. 클라우드의 모든 서비스가 존재하는 물리적 위치
Region 아래에는 여러 개의 가용 영역(Availability zone)이 존재, 1개의 가용 영역은 물리 데이터 센터 하나로 보면 된다.
가용영역이 여러개로 구분되어 있는 이유는, 재해 등 장애 발생시 다른 리전을 통해 서비스를 공급하기 위함.
(재난센터, 재해복구(DR)센터와 같이 전통적인 IT 환경에서도 사용하는 방식)
Availability zone : 실제 데이터가 존재하는 데이터센터
아래 그림을 보면 서울 Region에는 4개의 가용 영역이 있음을 알 수 있다. (23.06 기준)
* Edge Location : 캐시(Cache) 서버 역할 기반 CDN(Content Delivery Network) 서비스
(물리적으로 떨어진 데이터센터간의 전용망을 설치하고, 큰 용량의 콘텐츠 데이터(동영상, 음악, 사진 등)는 복구가 되도록 별도의 물리공간을 구성. 데이터센터 중간에 Caching 기능을 추가 한 것이라 보면 이해가 쉽다.)
전통적인 IT에서는 컴퍼넌트개념, MSA개념이 적용되지않은 경우가 많다. 또한 기본적으로 장애(서버가 죽는다.)가 안나는 것을 전제로 하고 있음. 하지만 cloud에서는 서버가 죽을 수도 있다라는 것을 전제로 한다.
* SLA(Service Level Agreement)
가상화를 사용하고 물리공간이 떨어진 클라우드이기에, 회사 내 자체 서버와 관리자가 있는 것보다는 대응이 미진할 수 밖에 없다. -> SLA의 등장 배경
SLA는 서비스 제공자가 이용자에게 제공하는 서비스의 수준을 정량화한 서비스 품질에 대한 보증문서를 의미한다. 특정 이슈가 발생시, 약속이 지켜지지 않은 경우 서비스 품질에 대한 보상이 기재되어 있음.
* SLA의 주요지표
1. 서비스 가용성 : 갑작스런 클라우드 서비스 장애로 인한 서비스 중단 우려를 최소화하기 위해 서비스 가용 기준 제시
2. 데이터 백업, 복구 및 보안 : 사용자의 데이터가 손상될 경우를 대비하여 서비스 제공자가 데이터의 백업 및 복구 체계를 갖추도록 백업 준수율을 제시하며, 각 고객 기업이 원하는 보안 수준을 제공함.
3. 고객 지원 및 VOC 처리 : 고객 요청 처리율, 서비스 요청 적기 처리율 등을 규정하여 고객 불만등에 대한 처리 기준을 제시함.
클라우드회사가 제공할 수 있는 최대 및 최소의 서비스 기준을 갖추어 놓은 문서가 바로 SLA
(이슈 발생시 누가 책임지는지, 어떤 식으로 처리할 것인지..)
'IT > Cloud' 카테고리의 다른 글
| 클라우드 도입, 이관시 고려사항 (0) | 2023.07.02 |
|---|---|
| 클라우드의 비용 체계 (0) | 2023.06.22 |
| MicroService Architecture(MSA) (1) | 2023.05.19 |
| Managed Service (0) | 2023.05.15 |
| 클라우드의 종류 (0) | 2023.05.15 |