Ashburton Grove

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를 설명할 때 여러 개념들이 등장하지만 여기서는 확장성과 가용성에 대해 다루어본다.

확장성과 가용성을 설명하기전, 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에서는 의사결정이 발생할 경우, 개발 서비스를 시작하려면 긴 시간이 필요함.

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

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 별로 설정할 수 있는 제약사항이 많으므로 이를 보완하고 원하는 환경을 구동하는게 관건.