Jins' Dev Inside

RDS는 AWS를 사용해서 웹서비스를 한다면 반드시 알아두어야할 서비스이다.

Amazon RDS는 클라우드에서 RDB의 사용을 설정, 관리 및 확장할 수 있게 도와주는 서비스이다. Amazon Aurora, PostgreSQL, MySQL, MariaDB, ORACLE, MSSQL 등을 지원한다.

RDS는 백업, Software patching, automatic failure detection, recovery 를 지원한다.

RDS의 기본적인 요소는 DB Instance이고, 이는 클라우드에 있는 독립적인 DB 환경이다. 

DB Instance는 정의하는 DB Instance class에 따라 Capacity(Memory) 등이 결정된다. (5Gb ~ 6Tb)

RDS 세팅을 하기 위해선 다음 과정을 거친다.

(1) AWS 접속

(2) IAM 계정 생성(Recommand) - Amazon에서는 RDS의 사용에 있어서 AWS 계정이 아닌 IAM 계정 사용을 권고한다. IAM User 계정을 만들고 그룹에 관리자 권한을 준다. 

이후 계정에 대해 Access Key를 발급받고, 그룹에 계정을 추가한 후 Security Credentials 탭에서 password를 설정한다.

(3) RDS의 DB Instance는 endpoint를 갖고 있으며 Application은 이 Endpoint로 접속하여 사용할 수 있는 구조로 되어있다.

(4) 필요한 기능에 맞게 설정한 후 Endpoint로 연결해서 사용하면 된다.

RDS에서는 이중화를 통해 장애에 대응할 수 있는 다중 사용 영역 복제와 고성능 I/O를 제공하는 Provisioned IOP Storage를 제공한다.(추가 요금 발생) 

RDS의 Instance 설정으로 License, DB Engine, DB Instance class, Storage Type, Allocated Storage, Network, Backup, Maintenance 등의 설정이 가능하다.

DB Instance를 생성하면 Instance의 Security group을 변경, MySQL Type의 Security group을 생성한다. 

RDS가 DB Instance를 Provisioning 한 이후에는 MySQL Client 또는 Utility로 Instance에 연결할 수 있다. 

연결 문자열에는 Host parameter로 DB Instance의 Endpoint DNS, Port parameter로 포트번호를 지정한다.

(ex) myinstance.123456.us-east-1.rds.amazonaws.com

> Mysql –h myinstance.123456.us-east-1.rds.amazonaws.com –p 3306 –u root -p

 Amazon RDS 는 몇가지 형태의 스토리지 옵션을 제공하며, 서버 엔지니어는 목적에 맞는 스토리지를 선택해서 사용해야 한다.

만약 인프라를 직접 설정해야한다면 종류를 잘 알아두지 않으면 불필요한 추가비용을 감당하게 될 수도 있다.

- 마그네틱(표준) : 보통 수준의 I/O 요구 사항에 대해서 적합한 비용효율적인 표준스토리지로, 크기 범위는 DB 인스턴스 엔진에 따라서 5Gb ~ 3Tb 정도이며, 경량화되어있기 때문에 현업에서는 주로 개발 및 검증용으로만 사용한다.

- 범용(SSD) : gp2라 불리고 SSD 이기 때문에 엑세스 속도가 매우 빠르며 지연시간이 한자릿수의 ms 단위이다. 중소규모의 운영용 DB에 이상적이다.

- 프로비저닝된 IOPS : 성능에 민감하고 I/O 집양적인 워크로드 및 DB 워크로드를 충족하게끔 설계되어있다. 주로 Massive 한 규모의 운영용 DB로 최적이다.

Scalability 와 Elasticity 는 클라우드 환경에서의 중요한 개념이고 면접에서도 심심치않게 등장하는 질문이다.

Scalability 는 Cloud 에서 workload 가 증가할 시 부하를 감당할 수 있을만한 Resource Capacity를 갖고 있느냐에 대한 내용이다. 

예상되는 요청에 대해서 아키텍쳐적인 관점에서 Scalable 하다는 것은 예상치를 충분히 감당할만한 Resource를 갖고있다는 의미가 된다. 

반면에 Elasticity는 막대한 양의 resource 용량에 대해서 순간적으로 할당하거나 해제하는 능력에 대한 성질이다. 즉 요구에 걸맞는 resource를 얼마나 빠르고 효과적으로 할당하는지를 말한다.

서버는 많은 양의 요청을 처리하기 위해 충분한 Scalability 를 갖추고 있어야 하며, 그를 위한 Scale Out 이나 Scale Up 등을 통해 리소스를 확보한다. 

이처럼 Scalable 한 시스템을 구축하기 위해서는 Elasticity 를 갖고 있어야 하며, 클라우드 환경에서는 리소스 추상화를 통해 빠른 할당과 회수를 가능하도록 환경을 구축하는 것이 중요하다.

VPC(Virtual Private Cloud)란 AWS 계정 전용 가상네트워크로 AWS클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. 

위의 그림은 흔하게 볼 수 있는 AWS 를 이용한 웹서비스 아키텍처의 모습으로, 여러대의 EC2 를 각각의 Private Network 로 묶고, 각 VPC 를 Router 를 통해서 인터넷에 연결시키는 모습이다.

위와 같이 VPC의 구성 시 웹서비스 아키텍처에 필요한만큼 서비스를 구성할 수 있으며, IP 주소 범위, 서브넷, 라우팅 테이블, 네트워크 게이트웨이 및 보안 설정과 같은 서비스를 제공한다.

VPC 내부의 각 Instance 들은 Private IP와 Public IP를 갖으며 이는 main routing table에 의해 게이트웨이를 거쳐 인터넷과 연결하며 이 부분을 EC2 네트워크 엣지라 한다.

 기본 VPC 구축 시, 인터넷 게이트웨이가 포함되며 각각 기본 Subnet은 Public subnet으로 구성이 된다. Internet에 붙어야 한다면 Public을, 연결되지 않는다면 Private subnet을 사용해도 무방하다. 

 이 때, 기본이 아닌 VPC 구축 시 Private IP만 존재하고 Public IP가 없기 때문에 서로는 통신할 수 있으나 Internet에 연결할 수 없다. 이 때 게이트웨이를 추가하고 EIP(Elastic IP)를 연결하여 인터넷 사용이 가능하다.

따라서 위의 그림과 같은 아키텍처를 만들기 위해서는 각 VPC 를 Private으로 구성하고 앞에 NAT 역할을 위해 Public 연결을 지원하는 EIP를 가진 게이트웨이를 두거나 VPC 자체를 Public 으로 구성하는 설계 2가지가 가능하다.

VPC의 Subnet에서는 방화벽과 ACL(네트워크 접근 제어 목록) 을 통한 보안 계층을 지원한다.

VPC에서 Instance 시작시 다음과 같은 장점이 있다.

(1)  인스턴스 시작 및 중지에 상관없이 유지되는 고정 IP

(2)  다수의 IP 할당 가능

(3)  네트워크 인터페이스 및 보안 그룹 설정 가능

(4)  Instance의 Inbound traffic 제어 (Ingress Filtering) 및 Outbound traffic 제어(Egress Filtering) 가능

(5)  ACL을 통한 접근 제어 가능

실무에서 클라우드를 사용하게 된다면 VPC를 구성하지 않는 경우는 거의 없다고 봐도 무방하다. 간단한 개념이고 설정도 쉽지만 잘 숙지해놓자.

 Amazon S3(Simple Storage Service)는 파일을 저장하기 위한 스토리지로, REST API 를 인터페이스로 제공되는 File System 이라고 할 수 있다.

마치 Dictionary 혹은 Hash Table 자료구조 처럼 Key 를 갖고 있으며 해당 Key 에 대한 파일을 Object 형태로 제공하는 구조로 되어있다.

이런 형태의 Object storage는 파일 1개당 1byte부터 5TB 까지의 용량의 저장이 가능하다. 

Directory와 유사한 개념으로 Bucket이라는 개념을 갖으며 S3에 대한 데이터 신뢰도는 3Copy 사용시 99.99%를 보장한다.

 앞서 언급한대로 S3 에 접근하기 위한 인터페이스로는 File IO가 아닌 REST/HTTP 프로토콜을 지원한다.

즉, 웹사이트에 접근하듯 HTTP url 로 원격저장소의 파일에 접근할 수 있다. 예를 들어 다음 주소를 봐보자.

http://mybucket.s3.amazonaws.com/photos/garden.jpg

위와 같은 주소에서 mybucket은 버킷 이름을, photos/gargen.jpg는 해당 사진 파일에 대한 Key를 의미한다.

얼핏보면 흔한 홈페이지의 주소로 보이지만, 위의 주소는 S3 저장소에 저장되어 있는 사진 저장소의 garden.jpg 파일을 나타낸다. 즉, 해당 주소로 접근함으로써 우리는 garden.jpg 파일을 다운로드받을 수 있다. 마치 "내문서" 의 garden.jpg 처럼 말이다! 

접근할 수 있는 형태로 AWS는 2가지 방식을 지원한다.

- 경로 방식

 http://s3.amazonaws.com/버킷이름/키이름

- 가상 호스팅 방식

 http://버킷명.s3.amazonaws.com/키이름

> 여기서 Region이 설정되어 있다면 s3를 s3-regioncode 와 같이 바꿔주면된다. 예를들어 서부 유럽의 경우 s3-eu-west-1이 된다.

그 외에도 S3 는 파일시스템 이상으로 제공하는 부가기능으로써 다음과 같은 특징을 갖는다.

(1) Retaining (저장 기간이 지나면 자동으로 삭제), Versioning (파일에 대한 버전 관리), Encryption (Http/Server/Client 단의 암호화) 등과 같은 파일시스템 관리 서비스를 제공한다.

(2) S3는 데이터의 Prefix를 이용해 Partitioning을 수행하는데 이를 통해서 파일을 분산 저장한다. 이는 파티션 당 물리적인 IO를 줄임으로써 성능의 향상을 가져온다.

(3) S3는 Multipart uploading과 Singlepart uploading 방식을 모두 지원한다.

여기서 싱글파트 업로드 방식은 클라이언트가 서버로 하나의 파이프를 통해 파일을 전송하는 방식이고, 멀티파트 업로드 방식은 클라이언트 서버 간의 여러 개의 파이프로 파일을 블록 단위로 쪼개서 전송하는 방식이다. 

멀티파트로 전송하게 되면 성능이 향상되고 블록 전송 실패시 해당 블럭만 재전송함으로써 에러 처리에도 뛰어남과 효율성을 보인다.

(4) S3 는 EC2 Repository 에 대한 Access 를 제공하는 서비스이기도 하다. EC2 또는 웹의 어디에서나 Data를 저장하고 관리할 수 있도록 지원하고, 웹 규모의 컴퓨팅 작업을 수행할 수 있도록 설계되어 있다.

또한 EC2의 AMI(Amazon Machine Image) 저장을 위해 S3가 사용되며 AMI를 통한 인스턴스 실행, 저장 및 복구 등 비즈니스 지속성을 달성 가능하다. EC2는 스냅샷(백업 사본) 역시 S3를 사용해서 저장하고 관리 및 확장한다.

(5) S3는 정적 저장소이기 때문에 설계 시에 Application 이 사용하는 Region 과 Bucket Region 은 같게 맞춰주는 것이 성능 측면에서 좋다.

S3를 이용하여 App 설계 시 고려 사항에 대해 Amazon은 3가지 정도로 제시한다.

(1)  Internal Errors 에 대한 재시도

Internal Error 가 발생했다면 이것은 Amazon S3 환경 내 오류로 요청을 재시도 할 것을 권고한다.

(2)  Slowdown 오류에 대한 어플리케이션 튜닝

Slowdown 은 리소스 초과에 대한 보호 매커니즘이 자주 요청될 때 발생하는 현상으로 요청 빈도를 줄이면 오류가 사라진다.

(3)  오류 격리

HTTP 오류코드보다 Amazon S3 오류코드가 많은 정보를 내포하므로 격리해서 이 오류 로그를 활용한다.

도커(Docker)란 리눅스(Linux) 기반의 컨테이너 런타임 오픈소스로 가상화 기술을 이용한 경량화된 컨테이너를 통해 환경을 격리시켜주고 관리해주는 솔루션이다.

 VM처럼 Docker Engine이 Host 위에서 Container들을 가상화 시켜 관리해주며 이런 환경을 Image 화 함으로써 격리된 환경에서의 모든 어플리케이션들과 리소스들, 그 Dependencies를 전부 포함한 격리된 환경을 구성하고 구조할 수 있다.

(여기서 Host 라 함은 대부분의 OS를 말하고, 그 위에 새로운 환경을 만들어낸다고 생각하면 처음에 이해하기 쉽다. 쉽게 이해해서 OS 안에서 새로운 OS를 구축하는데 그 방법이 VM 보다 훨씬 더 가볍게 이루어진다는 뜻이다.)

여기서 운영체제의 가상화에 대해 간단히 언급하자면 기존의 하드웨어 Machine 에 OS를 탑제하는 것을 가장 간단한 형태의 가상화(Virtualization) 이라고 한다. 

조금 더 경량화된 방식이자, OS 위에서 가상 머신을 돌리기 위한 방법이 반가상화(Paravirtualization) 라 하여, Host OS 위에 Guest OS 형태로 OS 를 별도의 소프트웨어 처럼 동작시키는 방안이 있다. 대부분의 VM Software 들... Virtual Machine 이나 VM Ware 는 반가상화 방식이다.

Docker 는 반가상화 방식보다 경량화된 Container 를 이용하며, 이는 Guest OS 조차 필요없는 운영체제 레벨의 가상화를 구현한다. 그대신 OS 레벨에서의 지원이 필요하기 때문에 아직은 Linux 만 제공되고 있다.

 도커는 Linux 커널이 제공하는 컨테이너 기술(LXC)을 이용하며, 격리된 Container 에서 독립적 작업을 할 수 있게 추상화해준는데, 이 Container 들을 관리해주는 것이 바로 Docker Engine 이다.

(Docker 의 자세한 기술 스택은 추가로 포스팅 하겠다.)

 이렇게 이미지화 한 Container Image들은 Git의 VCS(Version Control System) 처럼 관리 및 배포할 수 있다.(Docker Hub) 이렇듯 설치 및 이용이 빠르고 협업에 있어 손쉬운 패키징이 가능한 장점이 있다. 

이러한 장점들 때문에 Cloud 환경에서 여러대의 서버를 대상으로 환경을 구축하는 것이 매우 편리하며, 각 Instance 에 대한 환경의 일관성이 보장되기 때문에 서버 인스턴스들에 대한 효율적인 모니터링이 가능하다.

 컨테이너들의 효율적인 배포 및 관리와 모니터링 등을 할 수 있게 해주는 것을 Container Orchestration 이라 하며, 이들은 컨테이너의 배치 및 복제, 컨테이너 그룹에 대한 로드밸런싱,  장애 복구(Fail Over), Scaling, Access Control 등의 기능을 갖는다. 다음과 같은 툴들이 대표적이다.

- Kubernetes : 구글에서 만들었으며 최근 각광 받고 있는 Orchestration Tool 이다. VM 환경, Public Cloud 등 다양한 환경에서 작동이 가능하며 손쉽게 접할 수 있도록 지원한다.

- Docker Swarm : 여러개의 Docker 호스트를 클러스터링 하여 단일 Docker Host 를 운영하는 방식이며, 설정 및 운용이 간편하다. 하지만 Kubernetes 만큼 다양한 기능을 제공하진 않는 것으로 보인다.

- Apache Mesos : 확장성이 뛰어나며 다른 아파치 재단의 Hadoop, Hypertable, Spark 와 같은 시스템과 연동하여 쓰기 좋게 되어있다. 

요즘 정말 많이 볼 수 있고, 많은 IT 트렌드 기술들이 Docker 를 응용하여 나은 성능과 효율성을 가져가고 있다. 이미 자리잡은 핵심 기술인 만큼 심도 있게 공부해둘 필요가 있다.

* AWS 의 Cloud 서비스 관련해서는 사실 AWS 공식 홈페이지가 제공하는 Document 가 워낙 잘 설명이 되어있기 때문에, 본 포스팅과 더불어 참조하는 것이 좋습니다.

 아마존 클라우드를 사용하는 대부분의 기업에서 S3 와 더불어 CDN 을 목적으로 사용하는 솔루션이 Cloudfront 이다.

 Cloudfront 는 .html, .css, .js 및 이미지 파일 등의 정적 및 동적 컨텐츠를 사용자에게 더 빨리 배포할 수 있도록 지원하는 웹서비스이다.

사용자가 서비스하는 콘텐츠를 요청하면 엣지 로케이션에 있는 자원을 이용할 수 있도록 Contents Delivery 도 수행하는 역할을 한다. 이처럼 Cloudfront는 컨텐츠를 가장 적은 Hop으로 접근할 수 있는 위치로 라우팅시켜줌으로써 지연속도를 줄이고 빠른 로딩을 제공한다.

전형적인 CDN 으로써의 역할을 하지만, S3 가 일반적으로 "REST API 로 접근할 수 있는 리소스 저장소" 의 역할에 충실한 반면 Cloudfront 는 이를 직접 CDN 을 구성하게끔 만들어주는 Bridge 와 같은 역할을 하며 AWS 의 Lambda 와 같은 서비스와도 연계가 될 수 있고, 비용적인 측면에서도 좀 더 저렴한 부분이 있다.

 Nginx를 사용해서 이런 식의 Proxy를 구현할 수도 있다. NginX 서버에서 요청을 받아 가까운 Edge Location 으로 라우팅을 해주고 컨텐츠 자체를 Dynamic Caching 해주면 비슷한 역할을 하는 서버 인스턴스로 구현이 가능하다. (개인적인 생각으로는 아마 Cloudfront 도 이렇게 내부적으로 동작할 가능성이 커보인다.)

 클라우드를 처음 접했을 때 가이드 문서에서 가장 헷갈리고 이해 못했던 부분이 바로 High Availability 라는 부분이었다.

물론 주니어여서 와닿지 않은 부분도 있었지만 이 부분은 서버 개발자로써 연마해나갈 수록 이해의 폭이 달라지는 내용이었던 것 같다.

 HA(High Availability) 란 서버와 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말한다.

 일반적으로 1년 동안의 기간에 계획된 이벤트를 제외하고 장애시간을 5분 이내로 허용한다는 의미의 5 Nines, 즉 99% 의 매우 높은 수준을 목표로 한다. 이를 위해서는 시스템의 모든 부분이 미리 잘 설계되어야 하며, 실제로 사용되기 전에 완전히 테스트가 이루어져야 한다.

 서버 & 클라우드에서 고가용성을 유지하기 위한 대표적인 전략 중 하나는 Cluster를 구조하는 것으로, 이를 통해 한쪽에 장애가 발생하더라도 다른 서버들이 업무를 대신 수행함으로써 시스템 장애를 손쉽게 복구할 수 있다.

 독립적인 디스크를 RAID 형태로 배치하는 디스크 미러링, 여분의 네트워크나 SAN(Storage Area Network)의 완비 등이 요구된다.

HA Cluster 는 주기적으로 heartbeat를 네트워크에 보냄으로써 health check를 모니터링한다.

 장애 복구를 위해 최대한 빠르게 실패를 전달하고, 다른 한 개의 노드에서, 그리고 그마저도 실패하면 전체 노드가 발생한 장애에 대해 시도하는 방식으로 복구를 시도한다. 

서버개발자에게 매우 중요한 내용이지만, DevOps 가 아닌 Develop 에 집중하는 엔지니어라면 잘 모를 가능성이 크다. 개발자이면서도 운영 및 인프라 전반에 대해 포괄적인 지식이 필요해보인다.

Cloud Layer는 계층적으로 서비스를 3가지의 종류로 나눈다.

다음 그림을 보면 이해가 간편하다. 다음 그림은 IT 프로비저닝 리소스들 별로 계층화하여 서비스별로 그루핑하여 잘 나타낸 그림이다.

-      IaaS : 위의 그림의 두번째 서비스를 말하며, Infrastructure As A Service 의 줄임말이다. Memory, Processor, Storage(File System), Network 등과 같은 하드웨어 레벨의 클라우드 서비스를 제공하는 계층을 말한다.

     인스턴스, Storage(Data), 게이트웨이 레벨의 서비스들을 제공하는 형태를 들 수 있다. 이 때 사용자는 직접 어플리케이션과 비즈니스에 필요한 데이터, OS 및 런타임/미들웨어들을 직접 선택할 수 있다. 그 외에 가상화나 서버 리소스, 보안적인 부분은 벤더에게 위임하게 된다. AWS 가 초창기부터 프로비저닝하는 방식이고 Microsoft, Google 등 후발주자들도 따라가는 추세이다.

-      PaaS : 위의 그림에서 세번째 서비스를 말하며, Platform As A Service 의 약자이다. 개발자가 개발을 할 수 있는 Cloud Platform 을 제공하는 형태를 말한다. 스토리지, 인스턴스 네트워크 등 Infrastructure 들에 대한 Platform 을 제공함으로써, 하나의 서버 형태로 사용가능하도록 한다. 사용자의 어플리케이션은 비즈니스를 위한 데이터와 연동하여 이 플랫폼을 이용하여 원하는 결과를 도출해낸다. 주로 Microsoft Azure 가 초창기에 이런 형태의 서비스를 많이 제공했으며 Machine Learning 플랫폼, Container 관리 플랫폼 등이 있다. 

-      SaaS : 위의 그림에서 네번째 서비스를 말하며, Software As A Service 의 약자이다. System에 설치없이 Cloud 에서 이용할 수 있는 S/W 레벨을 제공하는 형태를 말한다. 대표적으로 Google Docs 와 같은 소프트웨어 서비스들이 있으며, 이런 개별 소프트웨어들이 클라우드 환경에서 사용할 수 있도록 제공된다.

멀티 테넌시(Multi Tenancy) : 다중 소유 라는 뜻으로, 자주 언급되는 단어임에도 생각보다 정리가 잘 되어있는 곳이 별로 없어서 정리해보았다.

 소프트웨어 멀티 테넌시란 소프트웨어 아키텍처의 한 종류로 하나의 Software Instance 가 하나의 서버 위에서 여러 개의 Tenant 를 서비스 한다는 의미이다.

여기서 테넌트란 소프트웨어 인스턴스에 대해 공통이 되는 특정 접근 권한을 공유하는 사용자들을 말한다. 멀티 테넌트 구조에서 Software 들은 모든 테넌트들에 대해 인스턴스의 일부분을 단독적으로 제공하기 위하여 설계되어 있다.

이는 개개의 소프트웨어 들이 각기 다른 테넌트들을 위해 서비스되는 멀티 인스턴스 구조와 상반된다.

 멀티 테넌시 환경에서 복수의 고객들은 동일한 데이터 스토리지 매커니즘과 함께 동일한 하드웨어의 동일한 OS에서 실행되는 동일한 Application 을 공유한다. 이는 구성 요소가 이양됨으로써 각 고객이 별도의 VM에서 구동되는 것처럼 보이게 하는 가상화와의 차이점이다.

 Multi Tenancy 란 하나의 소프트웨어를 여러 사용자가 함께 사용하는 것을 말한다. 사용자들은 프로그램을 수정하는 것이 아니라 서비스 제공자가 제공하는 설정 기능을 통해 자신에 맞게 커스터마이징해서 이용한다.

하나의 시스템으로 여러 고객이 사용하는데 고객마다 관리할 필요가 없기 때문에 관리비용도 적게 들고 유지보수가 간편하다. 하지만 하나의 DB로 관리한다는 것은 그만큼 위험도가 높다는 뜻이다.

 클라우드 컴퓨팅의 기본이 아키텍쳐를 공유하는 멀티 테넌시 시트템이다 라는 의견이 있으나 보안 문제가 우려가 되기 때문에 강력한 데이터 암호화 같은 기술이 병행되어야 한다. 많은 경우에 멀티 테넌시 시스템의 예시는 SaaS 의 형태라고 생각하면 된다. 

(SaaS 에 대해선 다음 링크 참조 : http://jins-dev.tistory.com/entry/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B3%84%EC%B8%B5-%EB%B0%8F-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%93%A4%EC%97%90-%EB%8C%80%ED%95%9C-%EC%86%8C%EA%B0%9C-IaaS-PaaS-SaaS?category=759992)

설명이 매우 추상적이라서 보충하자면 일반적인 멀티 테넌시란 하나의 소프트웨어 인스턴스로 여러 고객에게 서비스를 제공하기 위한 아키텍쳐 그 자체를 말한다. 

이 개념이 클라우드 컴퓨팅에 적용되면서 제공하는 서비스가 가상머신이라면, 서비스 Provider 는 하나의 컴퓨터에 여러 개의 독립된 가상 머신을 만들어 다수의 테넌트에게 이 컴퓨팅 리소스를 서비스 할 수 있게 된다. 그리고 이게 클라우드 서비스 개념의 출발이다.

 클라우드에서 공유 인프라 구축은 까다로운 문제이다. 전통적인 데이터센터 구조는 실 사용량에 비해 과도한 인프라가 구축되어 있어 리소스 활용률이 낮으며 이 때문에 클라우드 컴퓨팅을 통해 개별 어플리케이션, 그룹 또는 고객 간의 리소스가 공유되는 Multi tenant 환경을 이해하는 것이 중요하다.

 많은 기업들(Client)이 보안과 QoS(Quality Of Service) 를 염려하여 클라우드 인프라 구축 및 서비스에 대한 계약을 망설이고 있다. 이러한 이유로 개발된 Secure Multi tenant architecture의 멀티 테넌시의 4대 요소는 다음과 같다.

(1)   가용성 : 공유 인프라 한대에 장애가 발생하는 경우 다른 클라이언트에 영향을 줄 수 있기 때문에 장애가 발생할 수 있는 상황에서도 필요한 컴퓨팅, 네트워크 및 스토리지 리소스를 이용할 수 있도록 이중화 및 기타 메커니즘을 제공한다.

(2)   안전한 분리 : 한 테넌트는 어떤 상황에서도 다른 테넌트의 VM, 네트워크 또는 스토리지 리소스에 접근할 수 없어야 한다. 각 테넌트는 안전하게 분리되어 있어야 한다.

(3)   서비스 보장 : 정상적으로 운영되는 동안이나 장애가 발생했을 때나 특정 테넌트에서 비정상적인 부하가 발생했을 때에도 컴퓨팅, 네트워크, 스토리지가 분리되어 성능이 보장되어야 한다.

(4)   관리 : 모든 리소스를 빠르게 프로비저닝, 관리 및 모니터링할 수 있는 기능이 매우 중요하다. 관리를 단순화 함과 동시에 고객이 특정 벤더에 얽매이지 않도록 하는 것이 중요하다. 타사 어플리케이션 벤더 도 전체 환경에 대한 관리를 제공할 수 있도록 모든 단계에서 API 통합 지점과 Work flow를 상세히 기술하는 것이 중요하다.

Public Cloud에서 대부분의 서비스 제공자(Provider)들은 Multi tenant 모델을 사용한다. 하나의 서버 인스턴스의 사용을 제공하고 유지보수 및 배포가 용이하며 비용면에서 효율적이다.

이 때 public cloud provider는 당연히 각 Client에게 Hypervisor 레벨로의 접근을 허용하지 않으며 당연히 host-level 의 utility 들(예를 들어 안티바이러스 등의 보안 프로그램들 또는 백업 프로그램들)의 설치 및 사용이 허용되지 않는다.

이러한 특성은 보안상의 영향 뿐 아니라 잠재적인 WAN / Cloud 에서의 Failure 을 포함한다.

 또한 Public Cloud Provider 들은 그들의 하드웨어를 소유하고 Software들을 제어할 수 있기 때문에 Tenant 들의 동의를 구하지 않고도 저수준의 업데이트를 하는 것이 가능하다. 일반적으로는 OS 에 대한 업그레이드 이전에 광범위한 테스트가 수반되나 이런 종류의 업데이트가 Client 들의 소프트웨어에 영향이 미치지 않는다고 장담할 수 없다.

 퍼블릭 클라우드 사용시 비용은 예측할 수 없는 경우가 많다. CPU, 메모리, I/O, 네트워크 리소스 등과 같은 경우 너무나도 많은 변수가 존재하며 이를 대응하기 위해서 효율적인 모니터링 툴이 필요하다.

최근 대세라고 할 수 있는 클라우드 기술의 중요한 개념들을 포스팅합니다. :)

 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드를 나누는 기준은 서비스 제공주체(Cloud Service Provider) 가 된다.

 Private Cloud 는 자체적으로 데이터 센터 안에 클라우드 환경을 구축해서 사용하는 방식이다.

회사 내 IT 리소스들을 이용하려는 사용자가 자유롭게 어플리케이션을 개발, 운용할 수 있는 환경을 제공하는 것이 목표이며 기존 IT 인프라를 재활용하고 IT 서비스를 원하는대로 직접 구성 및 제공함에 있어 내부 효율성이 뛰어나다.

 또한 내부 통제가 가능하고 보안성 자체가 확보 가능하다.

 Public Cloud 는 서비스 제공업체(Vendor)가 구축한 서버, 스토리지 등 IT 인프라를 기업들이 사용료를 내고 이용하는 방식이다. 이를 통해 서비스 엑세스 비용이 절감되며 구현속도와 서비스적인 융통성이 향상된다.

즉 사설 클라우드가 자체적으로 필요한 부분을 보유 및 구축하고 재사용한다면 공용 클라우드는 서비스 제공자가 구축한 서비스를 구매하는 방식으로 구성된다. 

사설 클라우드는 기존 IT 인프라를 활용가능하다. 소규모더라도 구축 비용이 높고 공용 클라우드는 대규모에 적합하며 구축 비용 자체가 낮다. 

또한 사설 클라우드는 자체 보안시스템을 운용해야 하나 공용 클라우드는 보안 시스템 역시 제공이 된다.

 Hybrid Cloud 는 Public Cloud 와 Private Cloud의 이점을 모두 제공한다. 최근에는 VM의 공유 및 사설과 공용 간의 동기화 등으로 인해 하이브리드 클라우드 생태계가 발달함에 따라 점점 구분이 모호해지고 있다.