Ashburton Grove

Cloud Native :  클라우드의 주요 특징과 장점을 극대화하는 방법론들의 총칭을 의미함.
(CI/CD, DevOps, Microservices, Container 개념들이 유기적으로 돌아가는 서비스를 제공하는 것)

전통적 IT 구조의 조직은 cloud native 적용에 다양한 커스터마이징이 필요.
IT 서비스 의존성이 높은 기업(스타트업 등)은 자연적으로 cloud native 하게 갖춰져 가는 경우가 많다.

1. MSA

 작은 서비스 여러개를 엮어 활용하는 구조

2. Container

 서비스가 인프라 레벨로 들어간 것. 가상화 기술 영역 중 가장 경량화된 최신 기술.

 가장 가볍고 빠르게 활용이 가능한 가상화 기술을 의미한다.

  MSA 구조를 사용하기 위해 최종적으로 고려되는 가상화 기술.

위 그림과 같이 운영체제(OS)위에 컨테이너 관리 SW가 존재한다.

컨테이너 관리 SW를 쓰게되면 사용자는 사용되는 클라우드가 Public, Private 인지 신경쓰지 않아도 되는 장점이 있다.

Hybrid cloud를 구성할 떄, 컨테이너 관리 SW(플랫폼)이 있으면 MSA가 Public과 Private을 마음대로 사용 가능하기에 
장기적인 관점에서 cloud native하다는 것은 컨테이너를 사용하는 것이라 보면 된다.

-> Multi/Hybrid cloud 사용자 관점에서는 어느 클라우드 환경의 자원을 쓰는지 상관없이(Public / Private), 동일한 인터페이스로 서비스를 활용 가능함. 컨테이너 개념을 통해 장기적으로는 클라우드의 대세는 Multi /Hybrid cloud로 나아갈 것.

3. DevOps (Development + Operation)

개발과 운영이 유기적으로 하나로 돌아가는 현상을 의미한다.
지속적인 개발, 운영, 피드백 반영, 적용을 위해 개발팀과 운영팀을 하나로 합치는 개념. 

DevOps는 아래와 같은 특징들을 가지고 있다.
1) 지속적으로 피드백을 바로 반용해서 새로 개발에 반영하도록 함
2) 조직 입장에 대응력을 높이며 신기능 추가 및 개선을 할 수 있는 환경 가능

4. CI/CD (Continuous Integration / Continuous Deployment)

지속적인 통합과 배포 

현업에서 요청한 서비스를 각 팀, 부서 별로 개발하다보면 통합(integration)의 필요성이 증대되는 경우가 많다.
여기서, 통합이란 API로 통신하면서 서비스가 유기적으로 돌아갈 수 있도록 프로토콜을 맞추는 작업을 의미함.

이러한 통합 과정을 원활하게 수행하기 위해서 활용되는 DevOps와 CI/CD는 개선사항을 빠르게 반영하고 다시 운영에 들어갈 수 있도록 한다. (비즈니스 요구사항을 맞춰주는 개발 속도와 대응력을 높임)

1. 클라우드 도입시 고려사항

1) 클라우드 도입 이유
 

 트렌드, 해외사업확장, 신규 업무 시작, 비용적인 이유, DT,  단순히 기술적 이점 이외에도 조직의 체질 개선, 클라우드 환경을 선호하는 기술 인력을 위한 인재 확보 차원 등이 있다. 

 또한 클라우드 도입을 통해 기능적 장점(필요할 때 빠르게 사용가능), 운영적 장점(자동화를 통한 관리 포인트의 감소)을 얻을 수 있다.

 클라우드 신규 도입(클라우드 환경에 최적화하여 신규 서비스를 개발)은 상대적으로 높은 수준의 난이도를 요구하지 않는다. (자동화를 통해 관리 포인트들이 줄어들었으므로) 하지만 기존 legacy 환경에서 운영되던 프로그램을 클라우드로 이관하는 이슈는 다른 차원의 난이도로 볼 수 있다.

2) 클라우드 도입의 선택지
 

 외산 클라우드가 더 최신 기술, 많은 선택지를 제공할 수는 있으나, 저렴한 비용과 수월한 지원을 보장하는 국산 cloud도 좋은 선택지가 될 수 있음. 클라우드 도입에 있어 원하는 것이 무엇인지 정확한 기준이 있어야 알맞은 선택이 가능하다.

 예를 들어 Private cloud의 경우, 공개된 무료 오픈소스부터 기존 대형 클라우드 회사들이 제공하는 기술, Public Cloud 회사가 제공하는 Private형 솔루션 등 다양한 형태가 존재한다.
 (보통 Public cloud로 클라우드를 경험한 뒤, Private cloud로 이관하여 사용량 산정 및 사용처를 점검하는 형태를 취함,)
 

 클라우드 도입에 있어 중요한 결정사항들은 아래와 같다.
1. Public / Private 중 어느 것을 선택할 것인가
2. 구체적인 서비스는 무엇을 쓸 것인가
3. IaaS / PaaS / SaaS 중 어느 것을 쓸 것인가

3) 장기적 관점에서의 도입 계획

 각각 클라우드 서비스(Public, Private, Hybrid 등)로 공유되는 특징과 함께 차이점에서 발생하는 장단점 파악이 중요하다.   또한 조직에 상황(신규도입, 이관)에 따라 도입 계획이 달라질 수 있다. 다만 향후 클라우드 도입이 더욱 확장되고 조직의 대응력이 높아지면 Multi/Hybrid cloud를 주로 사용하게 될 가능성이 높다.

2. 클라우드 이관시 고려사항

이관(Migration) : 기존 IT환경에서 운영되던 것(AS-IS)이 새로운 IT(TO-BE)환경으로 넘어가는 것을 의미함. 여기에서 TO-BE는 클라우드 환경을 의미한다. 

 기업 내 legacy 시스템이 오래되었거나 여러 개 존재하는 경우, 클라우드로 일부분을 이관시켜보면서 클라우드의 장점이 실제로 발현되는지 확인해보는 경우가 일반적이다.
(클라우드를 도입하려는 기업은 기존 on-premise 환경에서 클라우드로 이관(off-premise)하는 상황을 가장 많이 대면함.
 이관은 기존 환경에서 구동되는 어플리케이션에 대한 이해가 필수적으로 요구되기에, 어려움을 수반한다.

 클라우드 이관에는 표준이 없다. 각  클라우드의 특징과 이관하고자하는 어플리케이션의 특징을 이해하고 이관에 대한 순서 및 전략을 세워야 한다. 이관 전략을 위해 고려해야할 사항은 어플리케이션 간 의존성, 전환 편리성 등이 있다.

1) 클라우드 이관 방법

클라우드 이관 방법에는 아래와 같이 2가지 방법이 존재한다.

Lift  and Shift :  가장 원론적인 이관 방법, 기존 인프라 환경을 클라우드에 그대로 옮기는 것.
① 어플리케이션 구조 변경이 없기에 빠른 이전 가능
② 가장 리스크가 적고 빠른 방법
③ MSA에 최적화되어 있지 않아 클라우드의 장점 활용이 어려움
④ 클라우드의 장점을 포기하게 되고 성능 저하, 비용 추가 등의 문제를 내포함

Re-Architect : 기존 서버 환경의 어플리케이션을 클라우드에 최적화하여 재구성한 다음에 옮기는 것
① 클라우드의 장점을 극대화하기 때문에 가장 이상적인 이관 방법론
② 기존 어플리케이션의 이해도가 낮을수록 시간과 비용이 어느 정도 소요될지 가늠하기 어려움
③ 리스크 측면에서 상당히 난이도가 올라가는 방법

실제 이관 프로젝트에서는 아래와 같이 두가지 방법을 혼용하는 경우가 많음. 

① Lift and Shift 의 방법으로 프로젝트를 진행한다.

② Lift and Shift로 리스크(성능적 개선이 어렵거나, 클라우드에서 기능제공이 어려운 이슈 등)들을 조금씩 해결하고 테스트를 마침.

③ Lift and Shift를 위해 점진적 이관을 진행

④ Re-Architect를 통해 최적화를 완성.

이를 도식화시켜보면 아래 그림과 같다.

Cloud는 Pay per Use가 기본 사상.

* Pay per Use : 사용량 기반, 사용한 만큼 비용을 지불한다.

비용 체계를 정의하기 위해서는 무엇을 사용한 만큼 비용을 청구할 것인지를 정의해야 한다. 이를 Price Factor라 칭한다.

(cloud에서는 서버가 켜져 있는 시간, 사용자 수에 따른 과금, 용량에 따른 과금 등등 여러 기준이 존재한다.)

cloud 종류에 따른 비용체계는 아래와 같다.

SaaS : 특징(사용자 수, 용량, 서버 호스트 수 등)에 따라 다양한 과금 체계가 존재함.
PaaS / IaaS : 인프라 관점에서 사용량 및 사용시간 등에 따라 과금하는 것이 일반적.

AWS를 예시로 들면, 비용 체계는 크게 3가지가 존재한다.

1. 온디맨드 (On-Demand)

사용량에 따라 과금하는 가장 기본적인 모델
1) 실시간은 아니며, 시간당 과금 체계로 구성됨
2) 가장 cloud 형식에 맞는 과금 방식

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

정액제 개념, 일정 사용량을 예약하고 확정해서 돈을 내고 사용하는 방식
1) 1년/3년 등의 연 단위 계약을 통해 구매(분납 가능함)
2) 예약인 만큼 상당한 할인이 들어가는 경우가 많음. 온디맨드 방식보다 상당히 저렴한 금액으로 cloud 활용 가능

변동성이 큰 비용체계는 public cloud의 장점이나 사용량등이 정확히 예측 가능하다면, 전통적 IT나 private cloud가 더 유리하다.  cloud 사용량이 많은 경우, public cloud를 기반으로 일부는 예약 인스턴스로 구성하여 특정 서비스를 정액제로 가져가는 경우가 많다. 또는 처음에는 온디맨드를 이용하다가 사용 추이가 어느 정도 파악되면 예약 인스턴스를 사용하여 비용 절감을 하는 경우도 존재함.

3. 스팟 인스턴스 (Spot Instance)

 순간적으로 필요한 부분을 대기해두고 공용 자원을 저렴하게 사용하는 방식. 공용 자원은 수요와 공급에 따라 가격이 변동하는 특징을 가진다.

1) 온디맨드보다 저렴하게 이용이 가능함.
2)  단, 필요한 때에 자원 확보가 안되는 경우엔 사용이 어려움.
-> 사용자가 대기할 수 있는 경우, 예약 인스턴스와 스팟 인스턴스를 혼합하여 활용하는 경우가 많음.

cloud를 도입하면서 어느 부분을 고정비, 온디맨드형 변동비, 스팟 인스턴스 형으로 구성하여 가져갈 것인지는 충분한 고민이 필요하다. (어떤 서비스를, 어떤 인프라를 통해, 어떤 비용으로 구성할 지가 어렵다. 이번 차세대 프로젝트에서도 이에 관한 논의가 가장 길었었고..)

마지막으로 cloud의 비용적인 측면에서의 장,단점을 정리하면 아래와 같다.

비용적인 장점
1) 비즈니스 확장을 통해 얻을 수 있는 이득(이점) 대비 저렴한 비용으로 infra 환경을 제공받을 수 있음.
2) 서비스하는 업무가 유동적이거나 확장시점을 예측할 수 없을 때 cloud 사용이 합리적임.

비용적인 단점
1) 사용량이 고정적이며 큰 변화도 없고, 투자가 필요 없는 업무에 cloud를 적용하는 것은 비용적 측면에서 최소한 손해를 볼 여지가 있음.
2) 비용적 장점이 있더라도, 보안 등 조직에서 고려하는 여러 사유로 cloud 도입이 꺼려지는 측면이 있을 수도 있다.


* 기존 서버(On-premise) 방식은 1회성 구매 후 유지보수 등의 일부 비용만 발생함(cloud에 비해 상대적으로 저렴한 비용)

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

(이슈 발생시 누가 책임지는지, 어떤 식으로 처리할 것인지..)

MicroService Architecture를 설명하기 위해서는 Monolithic Architecture의 개념에 대해 이해가 필요하다.

1. Monolithic Architecture

cloud 등장 이전, 전통적인 IT 환경에서 쓰이는 아키텍처는 Monolithic Architecture라 칭함.
일반적으로 대규모 프로젝트(3~5년 이상의)는 완전무결한 구조로 가고자 하는 니즈가 많다.

완전무결한 구조를 위해 cloud 이전 IT 프로젝트에서는 단일구조 형식을 선호하게 되었음.

* Monolithic Architecture의 특징
1) 단일화된 통합 데이터베이스를 사용
2) 서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)

* Monolithic Architecture의 단점
1) 기술이 끊임없이 바뀌는 환경에서 기존 framework에 의존성이 생기며, 잠재적인 이슈가 발생할 가능성이 커짐.
2) 기능이 많아지고 규모가 커져 복잡해질수록 지속적인 통합/배포(CI/CD) 및 유지보수가 어렵다.
3) SPOF(Single Point of Failure, 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용불가)가 발생

4) 빠르게 변하는 트렌드를 따라잡기 어렵다. (서비스 수정 시, 배포등을 위해 전체 재기동 등의 이슈가 발생할 가능성이 높음)

-> 위 단점을 해결하고자 전용망과 고가의 HW 구입, 안정적인 유지보수를 제공하는 기업용 SW를 통해 서비스를 개발함
(장애 가능성을 원천적으로 최소화하기 위한 노력)

위와 같은 Monolitic 구조를 어떻게 보완할지에 대한 대응 방안이 바로 MSA

2. MSA(Mirco Service Architecture)

MSA는 기존 IT 체계에서 사용하던 Monolithic Architecture의 단점을 보완하기 위하여 등장하였다.
아마존, 넷플릭스와 같이 cloud 환경을 성공적으로 활용하는 회사들이 공통적으로 도입하고 있는 아키텍처.
서비스들이 다중 복합적으로 구성되어서 사용자에게 하나의 서비스 화면을 만들어주는 형태의 구조.

(아래 아마존 홈페이지 캡처본에서 붉은 테두리로 표기된 각각의 항목이 하나의 서비스) 

각 서비스들은 API를 통해 데이터를 송수신하며, 분업을 극대화시킨 구조이다,

Monolithic Architecture과 MicroService Architecture를 그림으로 비교하면 아래와 같다.

파란원으로 표기된 Business Logic는 서비스와 동일한 개념이다.

* MSA의 구성원칙
1) 단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐.
2) 독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포할 수 있음.
3) 느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화함. (서비스 간의 통신은 API를 통해서 진행)
4) 높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능함. (각각 서비스는 변경도 되고 끊임없이 바뀌지만 별도의 다운타임 없이 사용자에게  서비스를 제공해 주는 구성이 가능함.)
5) 팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영이 가능. (DevOps와 이어짐)

* MSA의 장점
1) 서비스별 독립적인 배포가 가능함.
2) 스케일링(Scailing, 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장) 가능
3) 장애 대응 용이(전체 서비스 제공에 미치는 영향을 최소화)

-> 일부 서비스에 이슈가 발생할 경우, 이슈가 발생한 서비스만 내리고 나머지 서비스는 제공하므로서, 사용자 입장에서는 이슈가 있었는지도 모를 정도로 유연하게 대응이 가능함.
4) 다중언어(Polyglot, 각 서비스마다 다양한 언어/환경 구성 가능) 지원 -> 신기술 적용이 용이

* MSA의 단점

1) 유지보수가 어려움 

(여러 서비스가 합쳐진 통합테스트를 진행하게 될 경우, 통합된 시스템이 아니므로 유지보수의 난이도와 복잡도가 크게 증가한다.)

2) 애매한 업무분장(도메인) (각 서비스별 업무분장, 도메인을 제대로 정하지 않을 경우, 업무에 비효율성을 초래)

* 왜 MSA 쓰는지?

cloud는 가상화 기능을 사용하게 되고 가상화 기능의 특성상,  물리서버보다 장애에 취약함.
물론 cloud 업체들이 보완기능을 제공하고 있지만, 전통적인 IT 환경보다는 장애 가능성이 더 높다.

-> 장애 취약점을 보완하기 위해 MSA를 활용하기 시작.

Managed Service : As A Service 에 내재화된 개념, 관리 및 서비스의 영역

As a Service : 사용자가 어떤 것을 선택하느냐
- 선택에따라 클라우드 업체의 관리 및 서비스 제공 범위가 달라짐

왜 Managed Service 라는 용어가 등장했나?
- Platform Layer(기업용 SW(DB, Middleware 등) 때문,
 기업용 SW는 어플리케이션, 서비스 구축 뿐만 아니라 전통적인 IT 환경에서 운영할 수 있는 관리자 확보도 매우 중요함.

(관리 인력을 구하기도 어렵도, 비용도 만만 찮음. 실력있는 DBA를 구하기가 얼마나 어려운지 생각해보면..)

Managed service 라는 것은 2010년대 후반부터 시작했으며 2020년대 각광을 받음.

DB를 cloud로 제공하는 회사들은 DBA가 하는 부분까지 직접 Managed Service로 제공하면서, cloud의 장점을 극대화시킴
(PaaS Lock-in 효과로 인해 IaaS를 적용해 기업용 SW적용하는 경우가 많았음.)

cloud는 운영,관리 부분을 cloud 회사가 상당 부분 대신해준다는 장점을 극대화 한다는데서 시작되었다. 그런데 제약이 발생하면 cloud를 이용하는 장점이 줄어든다. 그래서 등장한게 Managed Service의 개념

(사용자는 설치, 운영 및 유지보수를 모두 서비스로 제공받아 사용함.)

예를 들어 Snowflake, mongoDB, okta는 cloud운영하지않고, 기업용 sw만 패키징해서 제공하고 있다.
즉, cloud환경에  sw 설치, 기업들에게 cloud형태로 서비스를 제공(구독형)

( OS, 미들웨어 등 IaaS 위에 독립적인 PaaS 레벨의 서비스를 제공)

* Managed Service 특징
- 사용자는 한 번의 클릭으로 DB를 자동 구성하여 실제 DB에 담아서 이용할 data와  어플리케이션의 연동만 처리

* Managed Service가 생긴 이유

oracle, tmax, redhat같이 기업용 SW만 개발하는 회사들이 인프라 환경이 cloud환경으로 변하면서, cloud vender를 지원할 필요가 생기게 되었다. 여기서 지원이란 cloud 회사 플랫폼 위에서 SW를 제공하거나 자체 서비스를 개발 후 고객이 원하는 환경을 만들어 운영하는 방법이 있음. (HW처럼 활용하는 형태로)

* 장점
- 한 번의 클릭으로 바로 사용할 수 있는 서비스가 제공되어 빠르게 업무 도입 가능
- 관리 및 유지보수가 가능한 기술력 또는 인력이 없더라도 사용 가능
- 다양한 API를 지원하여 개발, 테스트 및 배포 프로세스를 쉽고 빠르게 확보할 수 있음.

* 단점
- Lock-in 효과가 여전히 있음. (선택지가 넓어지긴 했지만)
(snowflake는 AWS, MS, Google만 가능. 국내 업체는 서비스 제공이 안됨)
- Managed 되고 있는 영역에 대해 접근이 제약적임

Cloud는 일정 부분의 영역이 자동화되서 제공되는 특징이 있다.

Cloud는 제공받는 서비스 영역에 따라 구분을 지을 수 있다.

(IaaS > PaaS > SaaS 순으로 확장되며, 해당 순서대로 Cloud 기술 및 서비스가 진화하였음.)

1. 제공받는 서비스에 의한 구분

1) IaaS (Infrastructure as a Service, 아이아스)

Cloud 회사들이 보유한 물리서버를 가상화로 제공받는 구조.

Infrastructure 레벨을 제공하는 서비스로,  아래 그림과 같이 하드웨어 부분을 제공하는 방식을 의미함.

IaaS에서는 인프라 자체 구축을 위해서는 다양한 요소들이 고려되어야 함.

(냉각 환경, 전력 환경, 전용선/전용망, 네트워크 회선, 관리 인력 등)

일반적으로 적은 OS가 제공되며, 사용자는 OS와 어플리케이션을 직접 관리해야하는 단점이 존재.

ex) AWS EC2

2) PaaS (Platform as a Service, 파스)

사용자가 응용 프로그램을 작성할 수 있도록 플랫폼 및 환경을 제공하는 방식
IaaS 보다 제공하는 영역이 한 단계 더 높다. (아래 그림 참고)

Cloud 업체가 기업용 S/W(DB, Middleware, WAS 등)를 설치해서 서비스로 제공해주는 형태이다.

OS, 서버, 네트워크 등의 관리/운영 Cloud 업체가 해주기에, 사용자는 어플리케이션 활용 자체에만 집중하면 된다.

(소수의 인력으로 구성된 스타트업 등은 Time to Market에 유리)

IaaS는 사용자가 원하는 S/W를 별도 구매해 언제든지 설치 가능함. 이에 반해, PaaS는 서비스에 따라 각 클라우드 회사별로 제약이 존재할 수 있음.

위 특성상, PaaS를 쓰면서 한번 개발된 어플리케이션은 다른 플랫폼으로 이관이 어렵다. 즉 사용자 편의성이 존재하는 만큼, Lock-in이 생길 수 있다는 단점이 있음.

ex) AWS Elastic Beanstalk, AWS RDS, Salesforce

3) SaaS (Software as a Service, 사스)

사용자의 별도 설치 없이 클라우드를 통해 어플리케이션이 제공됨.

아래 그림처럼 응용프로그램을 포함한 모든 단계를 Cloud 회사가 지원해주는 방식을 의미.

이메일, 네이버mybox, Google Drive도 넓게보면 SaaS의 일종
(자원이나 스토리지 공간을 할당 받는 과정을 사용자가 볼 수 없음.)
SaaS는 Cloud에서 제공해주는 S/W만 잘 쓰면 된다. (이를 제외한 나머지 이슈들은 신경을 쓸 필요가 없음.)

SaaS는 인터넷을 통해 접속해야만 쓸 수 있기에, 다른 IaaS, PaaS에 비해 보안에 취약하다는 이슈가 있음.

ex) Office365, Google Drive, 사내 이메일 시스템 

IaaS, PaaS, SaaS가 서로 다른 이유는 기업마다 보유하고 있는 인력과 집중하는 분야가 서로 차이가 있기 때문이다.

예를 들어 개발인력이 최소화된 경우, Time to Market이 빠른 경우에는 SaaS가 유리하지만 기업환경에 맞춘 커스텀마이징은 어렵다는 단점이 있다. 
개발인력 및 유지보수인력이 어느정도 있다면 PaaS가 유리하며, 보안과 기술 내재화가 중요한 경우 특히 클라우드를 인프라 레벨까지 최적화해서 쓰려면 IaaS를 선택해야한다. 
결국 Cloud 도입 방식은 정형화되어 있지 않으며 프로젝트 및 기업별로 조건 및 환경이 각각 다르므로 이에 맞게 선택하는게 제일 중요하며, 난제이기도 하다.

2. 운영 주체 및 형태에 따른 구분

1) Public Cloud

대다수의 클라우드 회사들이 제공하는 형식이다.
누구나 비용을 지불하면 서비스를 사용가능 하며 사용량 예측이 힘든 서비스에서 주로 사용

* 장점
- 초기투자 비용이 많이 발생하지 않고 사용한만큼만 비용이 청구된다.
- 필요할 때 사용량을 쉽게 늘릴 수 있음.
- 서비스를 여러 지역에 분산시켜 관리가 가능함.
- Time to Market이 빠르다.(스타트업 입장에서 유리)
- 인프라 관리보다 비즈니스에 더 집중할 수 있다.

* 단점
- 모든 기술 스택(Stack)에 대한 제어가 불가능.
- 데이터 보안을 위한 추가적인 기술 투자 필요.

대표적인 성공사례 : 아마존, 넷플릭스

2) Private Cloud

기업 내부 등에서 보안등의 이슈로 인하여 private 하게 구축하고자 하는 Cloud를 의미.
클라우드의 기술적, 비용적 장점을 기업 내부 환경에서 똑같이 적용한다.
Public Cloud를 쓰기 어렵거나(금융권 같은 특정 내부 사용자만을 대상으로 하거나) 전통적 IT 환경과 Public Cloud 장점을 누리기 위해 등장한 개념.

* 장점
- 모든 기술 스택(Stack)에 대한 제어가 가능함
- HW 제어 및 SW 커스터마이징이 가능 (정전 발생시 예비 전력 전환, DR전환 등)
- 경험 및 기술이 축적되면 Cloud의 상당 부분을 기업이 내재화할 수 있음. 
- 오랜 시간이 니자면 훨씬 더 저렴하게 높은 보안의 서비스를 구축 가능함.

* 단점
- 서버 및 가상화 SW등 초기 투자 비용이 높다.
- 모니터링과 관리를 위해 기술 투자가 지속적으로 발생함.

(지속적인 투자를 해야 Public Cloud의 장점을 계속 가져갈 수 있음)

대표적인 성공사례 : Facebook

3) Hybrid Cloud

Public Cloud와 Private Cloud를 같이 운영하는 모델. 여러 Cloud를 혼용해서 장점을 극대화하기 위해 운용하는 방식.
여러 Public Cloud를 동시에 쓰는 Multi Cloud도 Hybrid 유형에 해당됨.

* 장점
- 높은 보안이 필요한 서비스는 Private으로, 사용량 변동이 심한 서비스는 Public 으로 사용 가능.
- 필요한 경우에 따라 서비스가 사용하는 cloud를 변경 가능

* 단점
- 운영 난이도가 높다. (기술력, 기획(자사 서비스에 대한 분석 등)이 중요함)
- Public Cloud 에 있는 data 반출 요금이 발생하므로, 서비스에 대한 확실한 분리가 필요

- Private Cloud 와 Public Cloud를 통합해서 관리하는데 추가적인 기술 투자가 필요

Hybrid cloud를 잘 활용하는 기업이 AT&T, Walmart
- 새로 나오는 서비스는 Public Cloud를 적극 활용, 기존 서비스는 Private Cloud를 운영하는 혼합 환경으로 구성

클라우드도 가상화 개념만 제외한다면 전통적인 개념의 서버와 사용적인 측면에서는 기술적으로 동일함.

전통적 IT에서는 의사결정이 발생할 경우, 개발 서비스를 시작하려면 긴 시간이 필요함.

긴 시간이 필요한 이유는 아래의 절차를 거쳐 진행하기 때문.

1. IT확장, DT, 신규 서비스 개발 등의 사업적 의사결정으로 새로운 SW/HW 필요성 인식

2. 여러 업체들의 spec 및 가격 비교

3. SW/HW 주문 및 배송

(1~3 단계 이후에 프로젝트가 가능함)

4. 각 기업에 맞게 환경 설정 및 개발 작업 진행 (보통 차세대, 신규 프로젝트는 3년정도 소요)

이와 같은 전통적인 방식을 사용하게 된 건 클라우드와 같은 서비스가 없었기 때문

 (클라우드와 달리 필요한 시기에 탄력적으로 새로운 자원을 빨리 사용하기 어렵다.)
구매한 HW, SW는 감가상각이 발생하고 EOS가 되면 차세대는 계속 진행해야되는 필요성이 발생. 또한 이를 관리하는 인력이 계속 필요함.

전통적인 IT와 클라우드의 차이점은 크게 3가지로 분류할 수 있다.

1. Self-service

Self-service 란 필요할 때 스스로 찾아쓰는 것. 스스로 청구하고 구입하고 활용하는 것 -> Cloud

Self-service 의 특징

1. 빨리 시작 할 수 있다. ('Time to Market' 이 빨라짐)

(Time to Market : 한 제품의 제품 개발 컨셉의 개발부터 제품을 만들어 시장에서 판매가 가능할 때까지 걸리는 시간)
2. 작게 시작 할 수 있다. (기존 HW 는 한꺼번에 구매를 해야하므로 잘못된 선택에 대한 Risk가 있음)
(구독서비스와 같은 개념, 유연한 선택이 가능)

전통적인 IT (직접 환경 구축시) 의 특징

1. NAS HW 구매, 직접 구축
2. 이슈발생, 업그레이드시 직접 수정
3. 관리기술을 배우거나 관리업체를 찾는 이슈가 있음.

2. Pay Per Use

전통적 IT는 일회성으로 HW/SW를 구매하고 장애 대응 및 업그레이드 보장을 위한 유지보수 비용을 지급.
이에 반해, 클라우드는 필요할 때 self-service 로 구매, 사용하는 만큼 비용을 낸다.
(클라우드라고 전통적인 방법보다 무조건 저렴한 건 아님. 자세한 내용은 후술.)

전통적 IT의 특징
1. HW/SW 소유권은 기업이 가지게 됨 (검토 및 제안요청서 -> 심의 및 입찰 -> 제품 구매 라는 구매 과정을 거치게된다.)
2. 제품을 수령한 이후 연단위의 유지보수 비용이 발생. (통상 도입가의 20% 가 유지보수 비용으로 발생)

3. HW/SW에 대한 관리, 유지보수 인력이 필요,

유지보수 계약이 없다면, 
1. 문제 발생 시 판매사 측에서 원인 분석과 해결을 하지 않음.
2. 필요로 할 경우 유지보수 비용이 소급 적용되어 청구됨.
-> 유지 보수 비용은 어쩔 수 없이 생기는 이슈가 발생.
(도입하는 고객사에서 직접 해결 할 수 있다면 발생하지 않겠으나, 그러긴 쉽지 않다.)

클라우드IT의 특징
1. 사용하지 않는 기간에 대한 유지보수 비용을 낼 필요가 없다. (사용량에 대해서만)
2. 사용기간, 사용용량, 사용건수 등 서비스의 특징에 따라 비용이 산정.
    일부 클라우드 환경은 Lock-in 효과를 위해 클라우드 밖으로 데이터 이동시 추가비용을 청구하는 경우가 있음.

Pay Per Use 장점
1. 사용한만큼만 과금되어 사용량의 변화가 많은 경우, 순간적인 사용량이 많은 system이라면 비용 절약이 가능함.
(전통적인 IT는 최대치를 기준으로 HW/SW를 구매해야함, 즉각적인 확장 및 증설이 불가능하므로)
2. 유지보수 비용 등 추가적인 비용이 거의 발생하지 않으므로 숨겨진 비용이 줄어든다. (관리인력에 대한 비용 등)
3. 많은 비용을 선투자하지 않고 새로운 제품, 서비스를 제공 가능. -> 비용에 있어서 탄력성을 제공 (스타트업 등에게 유리)
4. 스타트업 이외에도 규모가 있는 회사에서 신규 프로젝트를 실행할 경우, 비교적 적은 예산과 간단한 절차 안에서 Cloud 도입 가능. 

 (기존 절차는 '전체 비용 산정 -> 신규 기획 -> 예산심의 -> 프로젝트 실행' 의 단계로 이루어짐, 클라우드 방식을 도입하면 부서 내 예산으로 짧게 서비스를 시작해 볼 수 있음.)

Pay Per Use 단점
1. 사용량 변화가 많지않고 추가할 기능이 없다면, 클라우드보다는 자체 서버를 구축하는게 더 저렴
    (운영방법을 메뉴얼화 하고 단순 관리 운영 인력만 배치하면 됨)
2. 많은 클라우드 서비스를 이용하게된다면 비용최적화 방법을 고민해야함.
3. 새로운 자원 요청이 가능하므로, 정밀한 권한과 자원관리가 필요 (클라우드에서 중요한 이슈는 '보안')

3. API 

클라우드에서 자원을 할당받고 서비스들 간의 자원을 요청하거나 통신하는 규약으로 API를 도입함.

API(Application Programming Interface)

- 어플리케이션이 통신할 수 있는 모듈.

- 사용자 입장에서 프로그램에 있는 정보를 받기 위해 호출하는 인터페이스.

  정보를 요청시 원하는 format으로 받아올 수 있게 하는 모듈.

- 프로그램에 정보를 요청하고 회신받을 수 있는 형태의 규약을 의미함. 

  현재 프로그램과 프로그램 사이의 규약으로 확대되는 추세.

클라우드에서의 API

- 클라우드의 여러 서비스들과 어플리케이션들이 서로 상호작용하기 위해 활용되는 매개체.

- API를 통해 추가자원을 할당, 해소할 수 있음.

클라우드가 보편화되면서 정보를 지속적으로 요청받고 할당받는 자동화 환경이 중요해졌음.

-> API를 통해 자동화된 환경을 구축. (최근 트렌드)

API는 사용자와 정보 제공자 간의 계약, 사용자가 필요한 정보를 정보 제공자가 어떠한 방식으로 제공할 수 있는지, 그 방법을 제공. (현재 정부에서 제공하는 공공데이터가 그러함.)

API의 종류
접근방식에 따라 구분을 짓는다. 정보를 요청하고 받는 과정인데, 권한에 따라 정보를 주어야한다.
1. Private API : 다양한 어플리케이션과 시스템의 통합을 위해 사용하는 것. 

    단체 내부에서 권한을 받은 주체들(Entity)만 사용 가능
ex) 기업 내부의 정보나 환경에서 신규입사자들이 새로운 자원을 할당받는 경우
2. Partner API : API를 특정 비즈니스 파트너와 공유하는 것. 
   외부에 공개할 수 없지만 비즈니스 파트너나 협력사들을 대상으로 시스템적으로 정보를 주고 받기 위해 만든 것
3. Public API : 모든 사람들에게 제공하는 공공데이터 등 외부에 공개가능한 API
ex) 공공데이터 포털, 구글 어스 지도 api
각각의 접근방식은 사용자별로 API 호출 권한을 부여하여 더 세밀한 권한을 관리한다.

API의 특징 및 장단점
특징
1. 데이터의 처리(내부적으로 가공하는 방법 등) 부분을 변경하더라도 API 자체를 변경하지 않아도 됨.
   클라우드나 인프라가 변경되더라도 호출하는 형태의 규약만 맞춰주면 유기적으로 소통이 가능함. 
2. 호출시 로그가 기록됨. 호출 로그 분석을 통해 필요한 인프라 환경 확장, 새로운 과금 방식의 서비스 등 비즈니스 전략 수립이 가능함. API의 사용량 및 처리속도에 대한 모니터링 후, 필요한 자원을 부족한 API에 할당하여 성능 관리가 가능함.
장점
1. 특정 목적을 가진 API들로 나눠서 만들고 책임관리가 용이함. 
    (API 개발자와 정보개발자 간의 명확한 책임관리가 생기고 커뮤니케이션이 단순화됨)
2. 기본적인 HTTP/HTTPS 프로토콜을 사용하므로, 모든 개발 언어와 플랫폼(OS)에서 사용 가능함. 

    복잡한 환경으로 특정 플랫폼이나 언어에 의존성이 필요없는 프로토콜로 사용 가능 
3. API가 어떤 동작을 하는지 쉽게 문서화화여 관리가 용이함
    규약적으로 정리된 문서를 보고 필요한 자원을 바로 얻을 수 있음.

단점
1. 규제, 작성문법 등의 표준이 존재하지 않음. (표준화된 규약, 문법, 규제 등이 존재하지 않음)

    API를 개발할 때 표준을 정하고 규약을 잘 정해야 함. 
2. 한번 정의한 API는 지속적으로 지원해야 하므로, 여러 버전의 API를 지원해야 함.
3. Public, Partner API를 한 번 정하면 이를 수정하기가 어렵다. (영향도 파악도 쉽지 않다.)

현재 많은 디지털 트랜스포메이션이라는 이름 하에 클라우드를 도입하고 있음.

장단점을 고려하여, 회사의 상황과 전략에 따라 클라우드 도입을 고민해보아야 한다

재직 중인 회사에서 클라우드를 도입함에 따라, 클라우드에 대한 강의를 듣고 강의 요약 노트를 만들어 보고자 한다.

가상화 : 하나의 컴퓨터에서 여러 OS를 가동시킬 수 있게 도와주는 SW 기술,

           한 개의 컴퓨터에 있는 자원을 여러 개로 나누거나, 여러 컴퓨터의 자원을 하나로 합치는 기술

-> 가상화 기술이 클라우드의 시작

클라우드 : 큰 서버에서 나눠진 가상화된 자원을 사용자가 필요할 때마다 할당받아 사용

* 클라우드 기술의 장점

1. 시스템의 확장성 및 유연성의 향상

2. 시스템 확장에 빠른 대응이 가능 (서버 신규 도입시 필요한 절차를 생각해본다면..)

3. 물리적인 비용의 절감 (2와 연결)

* 클라우드 기술의 단점

1. 성능면에서 다소 손해를 볼 수 있다.

(가상의 자원으로 나누는 만큼, bottleneck 현상이 발생할 수도)

-> 성능저하를 최소화하기 위해 container 기술이 등장

* 가상화 기술의 종류

1. Host 가상화 

초창기 가상화기술. Vmware Fusion, Parallels, Virtual Box 등의 가상 PC가 대표적인 사례

운영체제를 다양하게 선택할 수 있다는 장점이 있지만, 너무 많은 Layer로 구성되어 있어 성능면에서 손해가 크다.

2. Hypervisor 가상화

가상화 SW와 OS 영역을 합쳐 Hypervisor Layer를 만듦. 해당 Layer는 하드웨어와 맞물려서 작동

현 클라우드 기술의 근간이며 대표적인 사례로는 아마존의 xen, MS의 Hyper-V가 있다.

하드웨어를 직접 제어하므로 효율적인 리소스 사용이 가능하지만, 자체적인 머신 관리 기능이 없어 관리를 위한 별도의 프로그램이 필요하다. cloud 서비스를 제공하는 회사들은 관리를 위한 별도의 프로그램을 제공하는데 초점을 두고 있다.

(Hypervisor를 자체적으로 만들고 제공하고 있음.)

3. Container 가상화

더 가볍고 경량화된 애플리케이션을 운용하기 위해 등장한 가상화 기술.

OS위에 바로 올리므로, 다른 가상화 방식보다 성능 저하가 적고 빠른 운영이 가능하다.

또한 동일 OS를 사용하므로 라이브러리, 패키지 등 애플리케이션 운영에 필요한 기술들을 바로 적용 가능.

다만, container 별로 설정할 수 있는 제약사항이 많으므로 이를 보완하고 원하는 환경을 구동하는게 관건.