2020.03.09

IDG 블로그 | 컨테이너 기반 클라우드 개발의 “스테이트”

David Linthicum | InfoWorld
대부분 애플리케이션은 스테이트풀(Stateful) 애플리케이션이다. 여기서 ‘스테이트풀’이란 말은 사용자가 영화를 보다가 말고 다른 디바이스로 바꿔도 스트리밍 서비스에서 그 부분을 기억한다는 것을 의미한다. 모바일 앱이 사용자의 속성이나 최근에 열었던 파일을 저장하는 것도 마찬가지다. 애플리케이션 수준에서는 중단된 세션을 복구하는 역량을 의미한다. 데이터 손실 없이 사용자를 원래 위치로 데려다주는 것이다.
 
ⓒ GettyImagesBank

기존의 세상은 스테이트풀의 세상이다. 스테이트풀 애플리케이션은 ‘스테이트(State, 상태)’를 기억하는데, 이 스테이트는 여러 세션에 걸쳐서 지속성을 갖는다. 그래서 스테이트 데이터는 데이터베이스를 포함하는 물리 스토리지처럼 휘발성 없는 방식으로 저장한다.

그런데 컨테이너는 이 스테이트 유지에 관한 새로운 도전과 기회를 불러왔다. 컨테이너 세상은 ‘스테이트리스(Stateless)’로 알려져 있다. 컨테이너 설계의 기본 개념은 컨테이너가 인스턴스로 등장해서 프로그래밍된 대로 작업을 하고 스테이트를 유지하지 않고 사라지는 것이다.

필요할 때는 일부 외부 소스로부터 데이터를 가져와 작업할 수도 있는데, 데이터는 다른 프로세스나 서비스로부터 넘겨받고 작업이 끝난 후에는 데이터가 메모리에서 삭제되기 전에 다른 프로세스로 돌려준다. 여전히 스테이트는 유지하지 않는다.

핵심 문제는 컨테이너가 스테이트 정보를 저장할 수 없다는 것이다. 컨테이너는 원래 그렇게 만들어졌다. 영구 스토리지 개념이 없으니 스테이트를 유지하는 것은 불가능하다. 이 때문에 초기에 컨테이너는 스테이트 유지가 필요없는 워크로드 전용으로 알려졌다..

일각에서는 여전히 컨테이너 기반 애플리케이션을 구축할 때는 ‘스테이트리스’라야 한다고 주장한다. 가장 깔끔한 접근법일 뿐만 아니라 스테이트풀 애플리케이션은 구시대 모델이라는 생각이다. 

하지만 컨테이너를 사용하는 기업 개발자 대부분은 동의하지 않는다. 전통적인 애플리케이션은 컨테이너에 맞춰 설계하고 구축하지 않기 때문이다. 예를 들어, 컨테이너용으로 리팩터링하는 애플리케이션은 보통 스테이트풀 애플리케이션이며, 스테이트 데이터에 의존한다.

이들 애플리케이션을 스테이트리스로 만드는 시도는 보통 천하장사가 헤라클레스라도 불러와야 하는 일이다. 비용도 들고 “왜 굳이 컨테이너로 옮기려 하느냐”는 지적을 받을 위험도 있다. 게다가 처음부터 컨테이너를 목표로 한 애플리케이션을 구축하더라도 비즈니스 필요성을 기반으로 볼 때 스테이트를 유지하는 것이 피할 수 없는 기본 기능일 수도 있다. 사실 스테이트를 유지해야 하는 애플리케이션을 스테이트리스로 만드는 것은 정말로 깔끔한 접근법은 될 수 없다.

컨테이너 기반 애플리케이션은 두 가지 스테이트 모델을 모두 지원할 필요가 있다. 쿠버네티스를 비롯한 여러 기술이 스테이트풀 애플리케이션을 위한 메커니즘을 제공하는 것은 좋은 일이다. 사실 많은 컨테이너 기반 시스템이 연합이나 분산 방식으로 구축한다는 점에서 ‘스테이트풀’은 이들 아키텍처의 핵심 요구사항이다.

필자는 컨테이너 기반 애플리케이션을 포함한 모든 애플리케이션은 개발자에게 ‘스테이트풀’과 ‘스테이트리스’ 두 가지 옵션 모두를 제공해야 한다고 생각한다. 스테이스리스 애플리케이션만이 유효한 접근법이라고 주장하지만, 대부분 개발자가 실제 환경에서는 진실이 아니라는 것을 알고 있다. editor@itworld.co.kr


2020.03.09

IDG 블로그 | 컨테이너 기반 클라우드 개발의 “스테이트”

David Linthicum | InfoWorld
대부분 애플리케이션은 스테이트풀(Stateful) 애플리케이션이다. 여기서 ‘스테이트풀’이란 말은 사용자가 영화를 보다가 말고 다른 디바이스로 바꿔도 스트리밍 서비스에서 그 부분을 기억한다는 것을 의미한다. 모바일 앱이 사용자의 속성이나 최근에 열었던 파일을 저장하는 것도 마찬가지다. 애플리케이션 수준에서는 중단된 세션을 복구하는 역량을 의미한다. 데이터 손실 없이 사용자를 원래 위치로 데려다주는 것이다.
 
ⓒ GettyImagesBank

기존의 세상은 스테이트풀의 세상이다. 스테이트풀 애플리케이션은 ‘스테이트(State, 상태)’를 기억하는데, 이 스테이트는 여러 세션에 걸쳐서 지속성을 갖는다. 그래서 스테이트 데이터는 데이터베이스를 포함하는 물리 스토리지처럼 휘발성 없는 방식으로 저장한다.

그런데 컨테이너는 이 스테이트 유지에 관한 새로운 도전과 기회를 불러왔다. 컨테이너 세상은 ‘스테이트리스(Stateless)’로 알려져 있다. 컨테이너 설계의 기본 개념은 컨테이너가 인스턴스로 등장해서 프로그래밍된 대로 작업을 하고 스테이트를 유지하지 않고 사라지는 것이다.

필요할 때는 일부 외부 소스로부터 데이터를 가져와 작업할 수도 있는데, 데이터는 다른 프로세스나 서비스로부터 넘겨받고 작업이 끝난 후에는 데이터가 메모리에서 삭제되기 전에 다른 프로세스로 돌려준다. 여전히 스테이트는 유지하지 않는다.

핵심 문제는 컨테이너가 스테이트 정보를 저장할 수 없다는 것이다. 컨테이너는 원래 그렇게 만들어졌다. 영구 스토리지 개념이 없으니 스테이트를 유지하는 것은 불가능하다. 이 때문에 초기에 컨테이너는 스테이트 유지가 필요없는 워크로드 전용으로 알려졌다..

일각에서는 여전히 컨테이너 기반 애플리케이션을 구축할 때는 ‘스테이트리스’라야 한다고 주장한다. 가장 깔끔한 접근법일 뿐만 아니라 스테이트풀 애플리케이션은 구시대 모델이라는 생각이다. 

하지만 컨테이너를 사용하는 기업 개발자 대부분은 동의하지 않는다. 전통적인 애플리케이션은 컨테이너에 맞춰 설계하고 구축하지 않기 때문이다. 예를 들어, 컨테이너용으로 리팩터링하는 애플리케이션은 보통 스테이트풀 애플리케이션이며, 스테이트 데이터에 의존한다.

이들 애플리케이션을 스테이트리스로 만드는 시도는 보통 천하장사가 헤라클레스라도 불러와야 하는 일이다. 비용도 들고 “왜 굳이 컨테이너로 옮기려 하느냐”는 지적을 받을 위험도 있다. 게다가 처음부터 컨테이너를 목표로 한 애플리케이션을 구축하더라도 비즈니스 필요성을 기반으로 볼 때 스테이트를 유지하는 것이 피할 수 없는 기본 기능일 수도 있다. 사실 스테이트를 유지해야 하는 애플리케이션을 스테이트리스로 만드는 것은 정말로 깔끔한 접근법은 될 수 없다.

컨테이너 기반 애플리케이션은 두 가지 스테이트 모델을 모두 지원할 필요가 있다. 쿠버네티스를 비롯한 여러 기술이 스테이트풀 애플리케이션을 위한 메커니즘을 제공하는 것은 좋은 일이다. 사실 많은 컨테이너 기반 시스템이 연합이나 분산 방식으로 구축한다는 점에서 ‘스테이트풀’은 이들 아키텍처의 핵심 요구사항이다.

필자는 컨테이너 기반 애플리케이션을 포함한 모든 애플리케이션은 개발자에게 ‘스테이트풀’과 ‘스테이트리스’ 두 가지 옵션 모두를 제공해야 한다고 생각한다. 스테이스리스 애플리케이션만이 유효한 접근법이라고 주장하지만, 대부분 개발자가 실제 환경에서는 진실이 아니라는 것을 알고 있다. editor@itworld.co.kr


X