[글=노규남 | KINX CTO]

거스를 수 없는 클라우드로의 흐름

몇 년 전만 해도 기업들은 클라우드를 도입할 것인가, 우리 조직에 클라우드가 적합한가를 두고 많은 논쟁을 벌였다. 그러나 지금에 와서는 클라우드 도입 자체에 대해서는 거의 이견이 없다. 대신 어떤 형태로 사용해야 하는가에 대한 논의가 활발하다.

물론 클라우드 도입에 부정적이거나, 여전히 검토만 하고 있는 조직도 있다. 지금까지 코볼(COBOL)을 쓰는 곳이 있는 것처럼, 흐름에서 한걸음 비껴간 사람들은 언제나 있기 마련이다. 그러나 시대의 흐름에 맞추지 못한다면 결국 외부의 압력에 의해 개혁을 하게 될 수밖에 없다.

일례로 금융권은 그간 IT 시스템에 대해 매우 보수적인 의사 결정을 해왔다. 그러나 카카오뱅크나 토스 등 신기술로 무장한 경쟁자들이 나타나면서 좋든 싫든 IT 시스템을 개혁하지 않을 수 없게 되었고, 이제는 금융기업들의 인프라 클라우드화에 대한 소식도 꾸준히 들려오고 있다.

이제 IT 인프라는 기업의 비즈니스에서 혈액과 같은 필수 요소가 되었으므로, 어떤 서비스나 비즈니스도 IT 시스템의 혁신 없이 경쟁력있는 사업을 영위할 수 없다. IT 인프라의 클라우드화도 이런 관점에서 피할 수 없는 방향일 것이다. 하지만 이런 개혁은 기존 시스템을 그대로 옮기는 것만으로는 충분하지않다. 신기술의 효용을 충분히 누리려면 물리 서버를 그대로 가상머신(VM)이나 컨테이너로 옮기는 것 이상의 행동이 필요하다.

 

컨테이너와 쿠버네티스, 도입이 곧 완성은 아냐

컨테이너에 대해서도 이미 유사한 논쟁이 시작된 것으로 보인다. 최근 우리 서비스가 컨테이너 환경에 적합한가를 논의하는 기업이 많아졌다. 필자의 견해로는 빠르건 늦건 컨테이너를 도입하는 건 정해진 수순이다. 단지 속도와 적용 시기, 방법이 문제가 될 뿐이다.

자체 데이터센터(IDC)나 전산실에 물리 서버의 형태로 인프라를 보유하고 있는 기업이 있다고 가정하자. 이 기업은 클라우드 도입을 검토하고 있고 더 나아가 요즘 인기 있다는 컨테이너와 쿠버네티스까지 도입하고 싶어 한다.

내부 IT 역량이 충분하지 않은 기업이라면 보통 여러 클라우드 서비스 공급자와 매니지드 서비스 공급자를 살펴본 후 몇 개 업체로부터 컨설팅을 받는다. 그 후 적합해 보이는 업체를 선택해 계약하고 도움을 받아가면서 워크로드를 옮긴다. 이것이 일반적인 기업의 클라우드 도입 수순이다. 그러면 시장의 흐름에 맞춰 클라우드와 컨테이너, 쿠버네티스까지 도입했으니 이 기업은 IT 인프라의 고도화를 이룬 것일까?

이 기업은 클라우드를 도입하고 나서 생각보다 비용이 많이 든다고 느낄 것이다. IT 조직이 마음대로 생성하는 자원을 통제하기 어렵다는 사실도 발견할 것이다. 클라우드 상의 자원이 생성과 삭제를 반복하므로 보안 면에서도 가시성을 확보하기 어려우며, 인프라의 상태와 성능을 어떻게 모니터링 할지 새롭게 배워야 한다는 점도 깨닫게 된다.

컨테이너를 도입하면 이런 문제는 더욱 심각해질 수 있다. 얼마나 많은 자원을 사용하고 있는지, 이 자원이 실제 필요한 것인지, 장애가 어디에서 발생하고 있는지, 보안 문제는 없는지, 우리 서비스가 어디에서 느려지는지 판단하기 어렵다는 사실을 절감할 것이다.

 

클라우드 네이티브, 제대로 하려면 무엇이 필요한가

일하는 방식을 바꾸지 않고 기존의 틀에 새로운 솔루션을 구겨 넣는다면 아무리 좋은 솔루션을 도입한다 해도 얻을 수 있는 이득이 제한적이다. 물리 서버를 관리하는 것처럼 VM을 다루거나, VM을 사용하던 습관대로 컨테이너를 사용해선 안 된다. 더 나아가 도커 컨테이너를 운영하는 것처럼 쿠버네티스를 운영하는 일도 바람직하지 않다.

물리 서버를 VM으로 바꾸었다면 인프라를 빠르고 유연하게 변경할 수 있다는 이점을 최대한 살리는 구조로 가야 한다. VM에서 컨테이너로 이행한다면 소스커밋-이미지 빌드-자동화된 배포로 이어지는 CD/CI(Continuous Integration/Continuous Delivery) 모델을 채택해야 장점이 극대화된다.

이를 위해서는 모든 소스를 버전 관리 시스템(Version Control System)에서 관리할 뿐만 아니라, 깃랩(GitLab) 등의 CD/CI 도구를 사용하며, 빌드된 이미지는 레지스트리에 저장하고, 쿠버네티스 상에서 자동으로 배포하는 파이프라인을 준비해야 한다. 또 쿠버네티스를 도입하더라도 보안이나 모니터링, 로그 취합 등 운영에 필수적인 기능들은 별도로 구축해야 한다.

무엇보다 이 시스템들을 충분히 활용할 수 있는 기술 역량이 내재화되지 않으면 안 된다. 이렇게 일하는 방식을 바꾸지 않은 채 솔루션만 도입한다면 한동안의 테스트 드라이브 후 예전 상태로 돌아갈 가능성이 크다. 컨설팅 업체의 도움을 받아서 구축하는 건 비용만 지불하면 되는 일이지만, 운영이나 관제 등은 조직 내부에 역량이 쌓이지 않으면 언제까지나 해결되지 않을 것이다.

 

쿠버네티스로 실현하는 멀티 클라우드 2.0

퍼블릭 클라우드의 선택지는 매우 다양하므로 기업은 가격이나 기능 등을 기준으로 원하는 벤더를 선택해 워크로드를 배치할 수 있다. 이때 특정 서비스 공급자의 기능에 너무 강하게 종속되는 상황은 여러모로 바람직하지 않다. 따라서 복수의 클라우드를 동시에 사용하면서 필요할 때 필요한 곳에 애플리케이션을 배치하는 멀티 클라우드에 대한 요구가 높아진다.

하지만 VM 단위에서의 멀티 클라우드는 여러 클라우드 서비스 각각에 대한 운용 능력 전부를 필요로 하므로 실현하기가 매우 어려웠다.

그런데 컨테이너로 워크로드를 넘기면 상황이 다르다. 쿠버네티스는 사실상 업계 표준이므로 동일한 쿠버네티스 클러스터라면 같은 방식을 적용해 여러 클라우드로 인프라를 확장, 이전할 수 있다. 쿠버네티스 환경에서 퍼블릭 클라우드 간의 기능적 차이는 사실상 없어지므로 어떤 클라우드 공급자를 선택하더라도 무방하다.

따라서 프라이빗 클라우드에서 쿠버네티스를 사용하고, 복수의 퍼블릭 클라우드에서도 동일하게 쿠버네티스를 쓴다면 인프라 비용과 운용 비용 모두를 최소화하는 멀티·하이브리드 클라우드 구성이 가능해진다.

이때 하나의 계정으로 다양한 클라우드들을 전용 회선으로 연결하는 KINX의 ‘클라우드허브’와 같은 서비스를 사용하면 클라우드 간 연결 보안성과 비용 효율을 얻으며 멀티·하이브리드 클라우드를 사용할 수 있게 된다. 이런 구성이야말로 세간에서 말하는 멀티 클라우드 2.0에 해당한다고 말할 수 있다.

중요한 점은 업계에서 수용되고 있는 표준적인 방법을 사용해야 한다는 것이다. 비표준적인 방식을 쓴다면 확장이 어려워진다. 컨테이너는 도커, 오케스트레이션은 쿠버네티스, 서비스 메시(Mesh)는 이스티오(Istio)처럼 업계에서 널리 사용되는 솔루션들을 선택한다면 벤더 락인을 피할 수 있을 뿐만 아니라 향후 클라우드 서비스 공급자를 교체할 때도 최소한의 부담으로 이전할 수 있다.

 

클라우드의 장점을 극대화하는 MSA

컨테이너와 쿠버네티스까지 적용했다면 한걸음 더 나가보자. 컨테이너 기반의 가벼운 웹 서비스로 통합한 후에도 여전히 서비스는 대용량 DB를 백엔드로 두고 앞단에 웹 애플리케이션 서버(WAS)를 두는 구조로 운영하는 기업이 많다.

이런 모놀리식 구조는 단일 애플리케이션의 볼륨이 커지면 아무리 프레임워크로 잘 정리해도 관리가 어렵고 배포도 쉽지 않다. 무엇보다도 클라우드 시대에는 기민함이 최고의 미덕인데 이런 서비스는 빠른 변경에 적합하지 않은 설계다.

이에 따라 애플리케이션을 작은 마이크로서비스로 분할하고 각 서비스 간의 통신을 통해 전체 시스템을 구성하는 마이크로서비스 아키텍처(Microservice Architecture, 이하 MSA)가 대두되었다. MSA는 SOA(Service Oriented Architecture)와 비슷하나 공통 메시지 버스인 ESB(Enterprise Service Bus)를 갖지 않아 메시지의 병목이 없다는 것이 가장 큰 개선점이다.

마이크로서비스의 단점은 작은 서비스가 늘어나므로, 그만큼 운영이 어려워진다는 것이다. 각 서비스를 관리하는데 추가적인 공수가 들어가고, 서비스 간 트래픽의 추적과 성능 관리 기능도 추가되어야 한다. 따라서 MSA를 제대로 하려면 서비스 간 호출에 대한 추적, 인증, 인가, 성능 관리, 로깅, 메트릭 관리 등의 기능을 모두 넣어야 하는데 가벼운 마이크로서비스에 이런 기능을 직접 코딩해 넣는 건 대단한 오버헤드가 된다.

이런 문제를 해결하기 위해 이스티오로 대표되는 서비스 메시가 등장했다. 이스티오는 사이드카 패턴으로 각 팟(Pod)에 프록시를 삽입하므로 애플리케이션의 수정 없이 마이크로서 비스가 서로를 호출할 때 보안, 인증, 로깅, 성능 측정 등의 기능이 자동으로 실행된다. 무엇보다도 이스티오를 사용하게 되면 마이크로서비스 간의 수많은 API 콜(call)이 단일 실패지 점(SPOF)이 되지 않도록 격리할 수 있고, 각 서비스 간의 연결에 가시성을 부여해 어디에서 부하가 발생하는지 관리할 수 있다.

반드시 서비스를 작게 분할해야만 이런 기능을 사용할 수 있는 것은 아니다. 대규모의 서비스라도 서로 API로 연동하는 구조는 이미 널리 사용되고 있으므로 이런 경우도 서비스 메시를 적용할 수 있을 것이다. 이미 대세가 된 컨테이너나 쿠버네티스에 비해 아직 이스티오의 효용에 대해서는 다양한 의견이 있다. 하지만 MSA가 추구하는 방향과 이상은 사람들의 요구에 부합하므로, 앞으로도 서비스 메시에 대한 실험은 계속될 것이다.

 

클라우드 네이티브는 일하는 방식까지 바꿔야 비로소 완성

이러한 단계까지 도달한 기업이라면 VM이 아닌 컨테이너를 쓰고 있을 것이고, 컨테이너도 단독으로 사용하지 않고 쿠버네티스 같은 오케스트레이션 툴을 이용하고 있을 것이다. 그 위에 서비스 메시까지 얹어 현대적인 애플리케이션 구조를 완성했을 수도 있다. 소스를 커밋하면 자동으로 도커 이미지가 만들어지고, 지정된 쿠버네티스 클러스터에 배포되며, 이스티오에 의해 점진적으로 트래픽을 신규 서비스로 이전할 수도 있게 된다. 처음에는 다소 힘들 수 있으나 이렇게 구축해두면 배포와 운영에 대해 들어가는 공수가 크게 줄어들게 되므로 장기적으로는 이득이다.

이런 파이프라인을 만들기 위해서 개발자는 애플리케이션을 컨테이너화해야 한다. 큰 애플리케이션을 공동으로 만들기보다는 쪼개진 작은 마이크로서비스를 하나씩 맡아서 개발해야 하는데 이런 접근은 설계 단계에서부터의 변화를 요구한다. 운영 시에도 컨테이너와 쿠버네티스에 대해 충분히 숙지하고, 물리서버나 VM과 다르다는 사실을 염두에 두어야 한다.

결국 근본적으로 조직이 일하는 방식 자체를 바꾸지 않으면 안 된다. 클라우드나 컨테이너는 그 과정에서 필요한 솔루션에 불과하다. 따라서 클라우드로의 이전을 성공적으로 수행하고 싶다면 클라이브 네이티브하게 기업의 IT 문화, 더 나아가 일하는 방식을 바꿀 생각이 있는지 자문해 봐야 한다. 클라우드 네이티브는 단순히 컨설팅을 받아서 솔루션을 도입하는 것 이상이기 때문이다.