클라우드도 가상화 개념만 제외한다면 전통적인 개념의 서버와 사용적인 측면에서는 기술적으로 동일함.
전통적 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를 한 번 정하면 이를 수정하기가 어렵다. (영향도 파악도 쉽지 않다.)
현재 많은 디지털 트랜스포메이션이라는 이름 하에 클라우드를 도입하고 있음.
장단점을 고려하여, 회사의 상황과 전략에 따라 클라우드 도입을 고민해보아야 한다
'IT > Cloud' 카테고리의 다른 글
| 클라우드의 주요개념 (0) | 2023.06.19 |
|---|---|
| MicroService Architecture(MSA) (1) | 2023.05.19 |
| Managed Service (0) | 2023.05.15 |
| 클라우드의 종류 (0) | 2023.05.15 |
| 클라우드의 개요 (0) | 2023.04.25 |