​

​

'클라우드'를 넘어서 '클라우드 네이티브'로..

​

​

'클라우드'는

서버나 스토리지 등의 인프라 자원을 고가용성 그리고 유연성에 맞춰서 빌려 쓰는

서비스형 인프라 중심의 클라우드 컴퓨팅이었다면,

​

'클라우드 네이티브'는

빠르게 변하는 고객들의 대응과 요구에 신속하게 맞추기 위한

유연하고 확장적인 개발 체계가 필요하게 됨에 따른 유연성, 확장성, 이식성 등

클라우드 컴퓨팅의 장점을 최대한 활용하면서 애플리케이션을 개발할 수 있는 사상, 기술, 컨셉

이라고 볼 수 있습니다.

​

결국 클라우드 자체는 인프라에 포커스된 개념이라면,

클라우드 네이티브는 개발 방식, 애플리케이션을 구현하는 방식에 포커스가 된 개념인데

현재 이 둘을 단순하게 나누기가 쉽지만은 않은 것 같습니다.

​

지금은 개발자도 클라우드와 인프라에 대해 잘 알아야 될 것이고,

인프라 유지, 운영 담당자들도 개발 사이드에서 일어나는

클라우드 네이티브 동향과 기술에 대해 잘 알아야 하기 때문에 복잡도는 더욱 높아지고

이 부분에서 공공기관을 비롯한 많은 전산 담당자들도 어려움을 느끼고 계십니다.

​

​

물리적인 온프레미스 환경에서 기존 애플리케이션이 있었다면

이것을 그대로 들어서 클라우드에 올리는 'Lift & Shift' 방식이

Cloud-Ready 애플리케이션화 입니다.

​

IaaS 를 빌려 쓰면서 클라우드에 올리는 방식으로

'21~'22년도에 이루어진 '행정·공공기관 클라우드 전환 사업'이 주로 이 방식으로 이루어졌습니다.

​

지금은 더 나아가 IaaS 뿐만 아니라

컨테이너, MSA, DevOps를 활용하여

'Cloud-Friendly', 'Cloud-Native' 로 가는 부분에 대한 고민과 니즈도 점점 커지고 있습니다.

​

​

​

왜 '클라우드 네이티브'인가?

​

​

클라우드는 미국이나 영국에서 2008년, 2010년부터 시작이 된 개념인데

우리나라에는 비교적 늦게 들어온 편입니다.

​

우리나라에서 클라우드가 폭발적으로 성장할 수 있었던 이유는

'Covid19'가 계기가 되었으며,

​

20년 가까운 기간동안 해외에서 진화돼온 내용과 기술이

우리나라에서는 불과 3~4년만에 압축적으로 일어나고 있습니다.

​

컨테이너, MSA, DevOps 라는 개념이 도입되면서 클라우드 네이티브 시대가 본격화 되었는데

​

클라우드 네이티브의 본격화 촉발에는

멀티 & 하이브리드 클라우드가 한 축을 담당한 것으로 볼 수 있습니다.

​

​

클라우드가 발전하는 과정에서 멀티 & 하이브리드 클라우드가 대세가 되면서

독립적이고 이식이 쉬운 애플리케이션을 어떻게 만들어낼 수 있는지​에 대한 관심사가

클라우드 네이티브로 연결되었다고 보입니다.

더불어 클라우드 환경이 가지는 유연함과 신속함 속에서 DevOps가 이루어지며

운영과 수정과 업데이트가 실시간으로 일어나는 환경들이

클라우드 네이티브를 가속화시키는 요인이 되었다고도 볼 수 있습니다.

​

​

​

​

클라우드 네이티브의 주요 특징

​

클라우드 네이티브의 주요 특징으로는,

이러한 속도감 있고 확장성 있는 대응은

현재 기업과 공공기관을 비롯한 고객들이 요구하는 현존하는 니즈입니다.

실시간 발생하고 있는 이러한 고객의 요구에 대응하기 위해서는 클라우드 네이티브로 가지 않을 수 없습니다.

​

​

비즈니스 로직과 UI, DB와 애플리케이션의 서비스들이

하나로 묶여서 돌아가는 것이 모노리틱(Monolithic) 이라고 한다면,

​

마이크로 서비스 아키텍처(MSA)는

​

조회, 등록, 접수, 수정 등 각각의 서비스를 작게 쪼개서(microservice)

소규모의 독립적인 서비스로 구분하여 구성이 되고

이것들을 API 호출하는 방식의 클라우드 환경에 최적화된 느슨한 결합을 통해

모노리틱 방식의 무거운 배포, 장애문제 처리와 운영의 어려움 등을 개선한다고 볼 수 있습니다.

​

​

​

그러면 MSA의 장점은 무엇일까요?

​

어떤 애플리케이션을 기준으로,

프로세스가 진행되는데 제일 끝단의 B에서 장애가 났다고 한다면

모노리틱 시스템에서는 이것이 전체 시스템의 장애로 이어지게 됩니다.

​

모든 애플리케이션의 프로세스와 데이터들이 다 결합이 되어 있기 때문입니다.

​

장애처리를 위해 B를 수정하여 다시 올리면 다른 부분에서도 장애가 날 수 있다보니

실시간으로 내가 운영 중인 환경에서 장애를 처리하는 것은 매우 어렵습니다.

​

그런데 마이크로 서비스 단위로 애플리케이션을 개발을 하게 된다면,

​

마이크로서비스의 A,B,C,D 중에 B 서비스의 장애가 발생했다면

A, C, D 서비스는 제공 중인 상태에서 B 부분의 장애만 처리함으로써

​

다른 서비스에 영향을 주지 않는 상태에서

지속적인 운영 환경이 이루어질 수 있다는 것이

MSA의 가장 큰 장점이라고 볼 수 있습니다.

​

​

컨테이너의 발명 이전에는 화물선에 화물 적재 시에

화물이 파손되기도 하고 어디에 무엇이 실렸는지 확인하기도 어렵고

세계 각지에서 화물을 실어내기에 충분한 양을 담보하지 못하고 시간 또한 많이 소요되었습니다.

​

그런데 컨테이너 라고 하는 혁신적 발명품이 도입되고

전 세계 물류의 표준화가 이루어지면서

화물 운송량의 5배 이상 증가, 체류 시간 75% 절감, 해상운송비 60% 절감을 이룰 수 있었습니다.

​

​

IT 분야에서도 컨테이너가 마찬가지 역할을 한다고 볼 수 있습니다.

​

더 많은 서비스를 배포할 수 있고, 더 빠른 속도로 그리고 더 저렴한 비용으로

배포할 수 있는 환경이 컨테이너 기반의 플랫폼입니다.

​

레거시 환경은 물론이고 가상화된 환경과 비교시에도

컨테이너는 매우 큰 차이점을 가지는데요,

컨테이너 엔진 위에 올라가 있는 애플리케이션들은

빈과 라이브러리 등 앱이 개발된 환경이 라이브러리를 포함하고 있습니다.

그래서 어느 곳에서도 그대로 실행이 가능하게 됩니다.

​

결국 이 컨테이너는 어떤 서버, 어떤 클라우드에 상관없이

컨테이너 오케스트레이션을 할 수 있는 플랫폼 위에서는

A 클라우드든 B 클라우드든 온프레미스든 프라이빗 클라우드이든 상관없이 동작한다

라는 점이 매우 큰 장점이라고 생각할 수 있습니다.

​

​

한국 뿐만 아니라 유럽, 아프리카 등 배포가 필요한 경우

글로벌 환경에서도 하드웨어로부터 독립된 빠르고 쉬운 배포가 가능합니다.

​

​

또한 서비스 트래픽 증가 시에도

기존에는 서버 단위의 증설할 수 밖에 없었는데

서비스 단위 컨테이너 증설을 통해 빠르게 대응이 가능한 확장성 확보가 가능합니다.

​

​

​

개발 언어가 다수인 경우에도

컨테이너 베이스 플랫폼에서는

API 호출 방식으로 컨테이너 안에 실행 환경이 모두 포함되어 있기 때문에

다양한 DB, 다양한 개발 언어가 혼재된 상태에서도 동작될 수 있습니다.

​

운영하는 과정에서 실시간으로 고객의 니즈를 다시 개발에 반영하고

개발된 부분이 실시간으로 배포되는 환경을 구현하기 위한 철학·조직·문화를 말하는데,

​

개발자는 운영 환경에 더 관심을 기울어야 하고,

운영 담당자도 개발 사이드에 관심을 가져야 하는 상황이 발생함에 따라

자동화된 운영 모니터링, 형상관리를 할 수 있는 플랫폼의 지원도 필요할 것으로 보입니다.

​

​

​

고객의 요구사항과 시장 트렌드는 너무나 빠르고 급격하게 변화하고 있으며,

기존 방식의 [개발-배포-운영]의 긴 라이프 사이클로는 고객 대응이 늦어질 수 밖에 없고

서비스 품질과 시장 경쟁력 저하를 불러오게 됩니다.

​

이에 대한 효과적인 대응을 위해서는 애플리케이션의 혁신이 되어야 합니다.

​

​

클라우드 네이티브로의 전환은 필연적이며 시간 문제입니다.