2021.03.17

IDG 블로그 | 퍼블릭 클라우드에서는 느슨한 결합이 더 좋은 이유

David Linthicum | InfoWorld
‘상태 유지(State Retention, Stateful)는 수년 동안 개발 세계에서 논란거리였다. 게다가 모두가 더 적은 자원으로 상태를 유지할 방법을 찾지 않는가?

퍼블릭 클라우드를 사용하면 기본적으로 스토리지와 컴퓨트, 데이터베이스, 개발의 소비 모델이 바뀐다. 하지만 상태 유지의 필요성이 변하는 것은 아니다. 상태 유지에 대한 전통적인 접근법은 클라우드에서도 잘 통했지만, 좀더 효율적인, 그리고 여러 애플리케이션에 걸쳐 적용할 수 있는 방안이 있지 않을까?
 
ⓒ Getty Images Bank

스테이트풀 애플리케이션은 상태에 관한 것을 기억할 수 있어서 여러 세션에 걸쳐서 유지된다. 애플리케이션은 세션 중단에서 복구할 수 있으며, 사용자를 원래 위치로 데이터를 잃지 않고 돌려보낼 수 있다. 핵심 가치는 애플리케이션이 상태를 인지한다는 것이고, 상태는 사람이든 기계이든 여러 인터랙션 패턴에 걸쳐서 내구성을 갖는다. 

AWS 같은 일부 퍼블릭 클라우드 서비스 업체는 이 상태를 특별하게 다루는 기능이 있다. AWS는 클라우드 네이티브 서비스인 스텝 펑션(Step Functions)를 제공하는데, 이 서비스는 스테이트풀 시스템과 태스크를 기반으로 하면서 AWS 람다 서버리스 배치 시스템과 함께 동작하도록 만들어졌다. 스텝 펑션을 사용하면, 태스크는 워크플로우 내의 스테이트이거나 다른 AWS 서비스에서 수행하는 단일 작업 단위이다. 이를 통해 애플리케이션이 순서대로, 그리고 예상대로 실행되도록 해준다.

다른 클라우드 서비스 업체도 비슷한 기능이 있다. 일부는 전통적인 개발 접근법을 기반으로 하고, 일부는 스텝 펑션 같은 구체적인 서비스이다. 상태 유지 기법이나 기술에 대한 박사 논문도 많고, 코볼부터 Node.js까지 상태 추적을 유지하는 최상의 방법을 제시하는 글도 수없이 많다.

상태 유지를 이용하는 대부분 메커니즘은 좀 더 긴밀하게 결합되어 있다. 하지만 최근의 경향은 좀 더 느슨하게 결합된 상태 유지 접근법과 메커니즘으로 바뀌고 있다. 상태를 유지해야 하는 애플리케이션과 실제로 상태 유지를 수행하는 메커니즘 간에 의존성이 적다는 의미이다.
클라우드에서 느슨하게 결합된 상태 유지가 중요한 이유는 다음과 같다.
 
  • 애플리케이션마다 맞춤형 상태 유지 메커니즘을 구축한다면, 보통은 매번 메커니즘을 다시 만들어야 한다.
  • 긴밀하게 결합되어 상태를 유지하는 애플리케이션은 보통 더 많은 자원을 사용하고, 그래서 매월 요금도 더 나온다.
  • 클라우드 내에서, 또는 클라우드 간에 많은 애플리케이션이 함께 동작하면서 애플리케이션 간에 상태를 유지해야 할 필요성이 커지고 있다.

희소식은 느슨하게 결합된 상태 유지는 실제로 수행하기 쉽다는 점이다. 상태 유지가 애플리케이션 외부에서 일어나고, 비록 애플리케이션이 제대로 동작하기 위해 상태 유지 메커니즘에 의존한다 해도 긴밀하게 결합되어 있지 않기 때문이다.

그럼 어떻게 해야 하는가? 풀 롤백이나 롤포워드 복구를 제공하는 데이터베이스나 기타 스토리지 장비를 이용하는 방법도 있고, 상태가 필요한 어떤 애플리케이션에서도 액세스할 수 있는 데이터 지향 서비스나 마이크서비스를 사용해 상태를 유지할 수도 있다. 세션 데이터를 트랜잭션이나 분석용으로 저장하는 것은 물론, 애플리케이션 간에도 상태를 유지할 수 있다는 것이다.

어떤 개발 툴을 사용하고 어떤 플랫폼에 애플리케이션을 배치하느냐에 따라 이미 이런 종류의 느슨하게 결합된 상태 메커니즘이 갖춰져 있을 수도 있다. 아니면 서드파티 제품이나 서비스를 찾아야 할 수도 있다.

애플리케이션을 퍼블릭 클라우드에 배치할 때, 결합되지 않은 상태 유지가 가장 좋다. 엄청난 노력을 들이지 않아도 구현할 수 있으며, 애플리케이션을 훨씬 더 유용하게 만들면서 클라우드 비용도 줄일 수 있다. editor@itworld.co.kr


2021.03.17

IDG 블로그 | 퍼블릭 클라우드에서는 느슨한 결합이 더 좋은 이유

David Linthicum | InfoWorld
‘상태 유지(State Retention, Stateful)는 수년 동안 개발 세계에서 논란거리였다. 게다가 모두가 더 적은 자원으로 상태를 유지할 방법을 찾지 않는가?

퍼블릭 클라우드를 사용하면 기본적으로 스토리지와 컴퓨트, 데이터베이스, 개발의 소비 모델이 바뀐다. 하지만 상태 유지의 필요성이 변하는 것은 아니다. 상태 유지에 대한 전통적인 접근법은 클라우드에서도 잘 통했지만, 좀더 효율적인, 그리고 여러 애플리케이션에 걸쳐 적용할 수 있는 방안이 있지 않을까?
 
ⓒ Getty Images Bank

스테이트풀 애플리케이션은 상태에 관한 것을 기억할 수 있어서 여러 세션에 걸쳐서 유지된다. 애플리케이션은 세션 중단에서 복구할 수 있으며, 사용자를 원래 위치로 데이터를 잃지 않고 돌려보낼 수 있다. 핵심 가치는 애플리케이션이 상태를 인지한다는 것이고, 상태는 사람이든 기계이든 여러 인터랙션 패턴에 걸쳐서 내구성을 갖는다. 

AWS 같은 일부 퍼블릭 클라우드 서비스 업체는 이 상태를 특별하게 다루는 기능이 있다. AWS는 클라우드 네이티브 서비스인 스텝 펑션(Step Functions)를 제공하는데, 이 서비스는 스테이트풀 시스템과 태스크를 기반으로 하면서 AWS 람다 서버리스 배치 시스템과 함께 동작하도록 만들어졌다. 스텝 펑션을 사용하면, 태스크는 워크플로우 내의 스테이트이거나 다른 AWS 서비스에서 수행하는 단일 작업 단위이다. 이를 통해 애플리케이션이 순서대로, 그리고 예상대로 실행되도록 해준다.

다른 클라우드 서비스 업체도 비슷한 기능이 있다. 일부는 전통적인 개발 접근법을 기반으로 하고, 일부는 스텝 펑션 같은 구체적인 서비스이다. 상태 유지 기법이나 기술에 대한 박사 논문도 많고, 코볼부터 Node.js까지 상태 추적을 유지하는 최상의 방법을 제시하는 글도 수없이 많다.

상태 유지를 이용하는 대부분 메커니즘은 좀 더 긴밀하게 결합되어 있다. 하지만 최근의 경향은 좀 더 느슨하게 결합된 상태 유지 접근법과 메커니즘으로 바뀌고 있다. 상태를 유지해야 하는 애플리케이션과 실제로 상태 유지를 수행하는 메커니즘 간에 의존성이 적다는 의미이다.
클라우드에서 느슨하게 결합된 상태 유지가 중요한 이유는 다음과 같다.
 
  • 애플리케이션마다 맞춤형 상태 유지 메커니즘을 구축한다면, 보통은 매번 메커니즘을 다시 만들어야 한다.
  • 긴밀하게 결합되어 상태를 유지하는 애플리케이션은 보통 더 많은 자원을 사용하고, 그래서 매월 요금도 더 나온다.
  • 클라우드 내에서, 또는 클라우드 간에 많은 애플리케이션이 함께 동작하면서 애플리케이션 간에 상태를 유지해야 할 필요성이 커지고 있다.

희소식은 느슨하게 결합된 상태 유지는 실제로 수행하기 쉽다는 점이다. 상태 유지가 애플리케이션 외부에서 일어나고, 비록 애플리케이션이 제대로 동작하기 위해 상태 유지 메커니즘에 의존한다 해도 긴밀하게 결합되어 있지 않기 때문이다.

그럼 어떻게 해야 하는가? 풀 롤백이나 롤포워드 복구를 제공하는 데이터베이스나 기타 스토리지 장비를 이용하는 방법도 있고, 상태가 필요한 어떤 애플리케이션에서도 액세스할 수 있는 데이터 지향 서비스나 마이크서비스를 사용해 상태를 유지할 수도 있다. 세션 데이터를 트랜잭션이나 분석용으로 저장하는 것은 물론, 애플리케이션 간에도 상태를 유지할 수 있다는 것이다.

어떤 개발 툴을 사용하고 어떤 플랫폼에 애플리케이션을 배치하느냐에 따라 이미 이런 종류의 느슨하게 결합된 상태 메커니즘이 갖춰져 있을 수도 있다. 아니면 서드파티 제품이나 서비스를 찾아야 할 수도 있다.

애플리케이션을 퍼블릭 클라우드에 배치할 때, 결합되지 않은 상태 유지가 가장 좋다. 엄청난 노력을 들이지 않아도 구현할 수 있으며, 애플리케이션을 훨씬 더 유용하게 만들면서 클라우드 비용도 줄일 수 있다. editor@itworld.co.kr


X