개발자 / 애플리케이션

글로벌 칼럼 | 쿠버네티스가 풀지 못한 '앱 현대화' 문제의 나머지 절반

Matt Asay | InfoWorld 2020.07.30
“지루하다”라는 말은 인프라 기술에 대한 최고의 칭찬 중 하나다. 미션 크리티컬 애플리케이션에 '정신 사나운' 기술을 사용할 사람은 없기 때문이다.
 
ⓒ Getty Images Bank

지루함은 기술의 편재성과 신뢰성이 일정 수준에 도달했고 이해하기 직관적이며 쉽게 관리할 수 있다는 것을 의미한다. 쿠버네티스(Kubernetes)가 대표적이다. 기업의 78%가 프로덕션에서 사용 중인 이 솔루션은 클라우드를 실현하는, '바로 작동하는' 표준 구조로 폭넓게 인정받는 단계까지 나아갔다. 다르게 표현하면 '지루한' 기술이 됐다.

클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 쿠버네티스의 인프라 계층에서 부족한 부분을 채우기 위한 여러 프로젝트를 조율하는 가운데 이제 쿠버네티스에 관한 대화의 논점도 스택의 위 방향으로 이동하기 시작했다.

예를 들어 지난 4월 켈시 하이타워는 애플리케이션 현대화에서 쿠버네티스로는 문제의 절반밖에 해결할 수 없다고 지적했다. 그는 "인프라 계층에서 애플리케이션을 '현대화'하려는 다양한 노력이 있지만 애플리케이션 계층에서 이와 동등한 수준의 투자가 없으면 프레임워크와 애플리케이션 서버 측면에서 문제의 절반만 해결될 뿐이다"라고 말했다. 이 문제에 어떻게 대처해야 할까
 

앱과 인프라의 간극 메우기

라이트벤드(Lightbend)의 공동 창업자이자 CTO인 조나스 보네는 “인프라와 전체 애플리케이션을 빌드하는 것 사이엔 큰 간극이 있다”라고 말했다. 그는 스택에서 쿠버네티스 위에 위치하면서 인프라와 애플리케이션 사이의 복잡한 문제를 해결하는 오픈소스 프로젝트인 아카(Akka)의 참여하고 있다.

보네는 “이 큰 격차를 메우는 것은 프로그래머에게 어려운 일이다. 이 말의 실질적인 의미는 비즈니스를 위한 SLA를 제공하는 것, 분산 시스템에서 실현하기 어렵지만 쿠버네티스와 그 툴 생태계를 최대한 활용하기 위해 애플리케이션 계층에 필요한 모든 요소를 제공하는 것이다. 따라서 기업은 앱과 인프라 사이에 위치하면서 모든 부분을 조율할 요소가 필요하다"라고 말했다.

핵심은 무언가를 대체하는 것이 아니라 툴박스에 더 많은 툴을 추가하고 격리 인프라 모델과 네트워크에 의한 제약을 앱 자체로 확장해 직관적이고 유연하며, 강력하고 간편한 프로그래밍 모델을 제공하는 것이다.

테슬라 엔지니어 두 명이 지난해 컨퍼런스에서 언급한 것처럼, 테슬라는 아카와 쿠버네티스를 조합해 전력망을 구동하는 '디지털 트윈(digital twin)' 기술을 사용하고 있다. 테슬라 엔지니어 콜린 브렉은 “테슬라 마이크로서비스의 대부분은 쿠버네티스에서 실행되며, 아카와 쿠버네티스의 조합은 환상적이다"라고 말했다.

쿠버네티스는 이러한 확장에 있어서 여러 장점이 있다. 예를 들어 팟(pod) 확장이나 축소, 활성 프로브 실행, 지수 백오프로 실패한 팟 재시작 등이 대표적이다. 그 후 아카를 사용해 회로 차단이나 개별 요청 재실행, 배터리가 충전 중인지 방전 중인지와 같은 개별 엔티티 상태 모델링과 같은 세세한 문제에 대처할 수 있다.

보네에 따르면 클라우드 네이티브 스택에서, 쿠버네티스는 여전히 해결되지 않은 영역을 3가지 갖고 있다. 바로 애플리케이션 계층 구성, 스테이트풀(stateful) 사용 사례, 그리고 전송 데이터(data-in-motion) 사용 사례다. 이 3가지 문제 때문에 아카와 같은 기술이 제공하는 새로운 추상화가 주목받고 있다.
 

선언적 앱 계층 구성 사용하기

보네는 “사람들은 전통적인 (모놀리식 3계층) 설계에서 비롯된 오래된 툴과 습관, 패턴을 사용하는 경우가 많은데 이는 쿠버네티스가 제공하는 클라우드 모델을 제약한다. 컨테이너와 서비스 메시, 오케스트레이션이 가진 '훌륭한' 모델을 애플리케이션/비즈니스 로직까지 확장해야 한다. 그래야 애플리케이션을 대신해 종단 간 보장을 유지하면서 이 모델을 최대한 활용할 수 있다”라고 말했다.

추상화 수준을 높이고 선언적 모델을 제공하는 서버리스 기술이 가리키는 이와 방향도 같다. 선언적 모델에서는 상투적 요소와 인프라, 운영을 최대하고 플랫폼에 의해 관리되며 개발자는 핵심 요소인 비즈니스 로직과 워크플로우에만 집중할 수 있다.
 

스테이트풀 사용 사례를 위한 지원 개선

클라우드 생태계 대부분은 이른바 12-팩터(12-factor) 스타일 애플리케이션, 즉 스테이트리스(stateless) 애플리케이션을 다룬다. 이것으로 충분한 경우도 있지만, 규모가 어느 정도 되는 앱은 보통 스테이트리스와 스테이트풀을 함께 사용한다.

보네는 “상태를 잘 다루기 위한 개선된 툴이 더 많이 필요하다. 최근에는 데이터가 점점 중요해지고 비즈니스 가치는 대부분 스테이트풀 사용 사례에 존재한다. 정확성, 일관성, 가용성을 보장하면서 이 데이터에 빠르게 액세스할 수 있어야 한다”라고 말했다.

클라우드에서는 훌륭한 모델과 이 모델을 지원하는 툴이 없으면 커뮤니케이션, 조율, 장기적인 상태 저장 등 무엇이든 매번 모든 것을 데이터베이스로 밀어 내리는 3계층 아키텍처로 돌아갈 수밖에 없다. 따라서 스테이트리스 접근 방법을 보완하며 툴박스에서 선택의 범위를 더 넓혀주는 우수한 상태 모델도 필요하다.

현재 쿠버네티스의 스테이트풀 사용 사례 처리는 스테이트풀셋(StatefulSet) 기능에서만 지원된다. 그러나 보네에 따르면, 스테이트풀셋이 앱 개발자가 아니라 데이터베이스와 같은 인프라를 구현하는 사람을 위해 설계됐다. 그는 “여전히 큰 간극이 존재한다. 아카의 용도가 바로 여기에 있다”라고 말했다.
 

패스트 데이터 또는 전송 데이터 사용 사례 처리

쿠버네티스 생태계는 아직 스트리밍 및 이벤트 기반 사용 사례는 잘 지원하지 않는다. 보네는 "이스티오(Istio)와 같은 서비스 메시는 요청-응답 모델을 중심으로 설계돼 이런 스트리밍과 이벤트 기반 활용 사례에서는 오히려 방해 요소가 될 수 있다”라고 말했다. 스트리밍 역시 스테이트풀인 경우가 많고, 가용성을 확보하는 동시에 메모리 내의 데이터를 집계하는 단계가 포함된다. 이 부분은 앞서 살펴본 내용과 연결된다. 보네는 "K네이티브(Knative) 커뮤니티에서 이 문제를 해결하기 위한 작업이 진행되고 있지만 이제 시작 단계일 뿐이다"라고 말했다.

이러한 새로운 방향을 주도하는 주된 힘은 로우 코드/노 코드/“백 엔드에서 프론트 엔드 분리하기” 개념이며 이는 모두 서버리스 영역 아래에 속한다. 보네는 “서버리스는 쿠버네티스 모델을 애플리케이션 자체로 확장하는 문제를 해결하기 위한 진전인데 이것이 가장 중요하다. 최대한 많은 부분을 추상화해서 코딩이 아닌 선언적 구성 모델로 옮기는 것이다. 이렇게 해야 어떻게가 아닌 무엇을 정의할 수 있다”라고 말했다.
 

‘바로 작동하는’ 애플리케이션 인프라

클라우드 네이티브 스택이 쿠버네티스 인프라 위에서 계속 발전하는 과정에서 애플리케이션 계층의 이러한 개념이 특정 언어 개발자에게 어떻게 작용할지 관심을 갖고 지켜볼 만하다. 가장 까다로운 애플리케이션 아키텍처 과제의 상당수는 오랫동안 서버 측 자바 개발 영역이었지만 이제는 잼스택(Jamstack) 아키텍처로 이동하고 있다. 특히 엔드포인트가 기하급수적으로 증가하는 가운데 자바스크립트 개발자는 바로 작동하는 애플리케이션 인프라를 기대한다.

결론은 백 엔드 인프라가 중요하지 않다는 것이 아니다. 이안 매싱햄이 말한 것처럼, 프런트 엔드 개발자의 수가 백 엔드 개발자보다 훨씬 더 많고, 여기에는 그만한 이유가 있다는 사실을 인정하자는 것이다. 만들어야 할 애플리케이션의 수는 그 애플리케이션을 호스팅하기 위해 만들어야 할 인프라보다 훨씬 더 많다. 아카와 같은 오픈소스 프로젝트를 통해 두 세계를 연결하는 것이 중요한 이유다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.