마이크로서비스와 함께 모놀리스 이전하기

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

모놀리스를 컨테이너에 넣기만 하면 짠! 확장성과 속도라는 현대적 아키텍처의 이점을 누릴 수 있다는 허황된 믿음이 있습니다.

실제로 KubeCon 2018 설문조사에 따르면, 컨테이너를 "기존 애플리케이션의 VM 대체재로" 활용한다고 답한 응답자의 약 55%가 바로 이러한 방식으로 사용하고 있는 것으로 나타났습니다. 다른 설문조사에서도 상당수의 엔터프라이즈급 Java 애플리케이션이 컨테이너에서 실행되고 있는 것으로 나타났습니다. 2018년 Diamanti 설문조사에 따르면, 대다수(54%)는 클라우드 네이티브 애플리케이션에 컨테이너를 사용하고 있었지만, 약 3분의 1(31%)은 레거시 애플리케이션을 현대화하는 데 컨테이너를 사용하고 있었습니다.

일반적으로 언급되는 이유는 운영 측면과 관련이 있습니다. 관리해야 할 구성 요소가 폭발적으로 늘어남에도 불구하고 컨테이너가 더 간편하게 관리할 수 있는 것으로 여겨지기 때문입니다. 성능과 라이선스 비용 역시 컨테이너 도입을 추진하기로 결정하는 데 영향을 미치는 경우가 많습니다.

하지만 이러한 전환은 레거시 앱을 패키징해 컨테이너에 넣는 것만큼 간단하지 않습니다.

현실적으로 모놀리식 애플리케이션, 즉 기존의 클라이언트-서버 및 웹 애플리케이션에는 컨테이너로 그대로 이전해 운영상의 이점을 누리기 어렵게 만드는 몇 가지 특성이 있습니다. 컨테이너와 마이크로서비스가 반드시 함께 사용되는 것은 아니지만, 둘 다 현대적인 애플리케이션의 가용성을 뒷받침하는 '장애를 전제로 한 설계' 원칙을 지향합니다. 이 원칙은 한 컨테이너에 장애가 발생하면 이를 대체할 다른 컨테이너를 시작하기만 하면 된다는 의미입니다. 모든 컨테이너는 가축처럼 취급되므로 어느 것을 사용해도 차이가 없습니다.

의도적으로 현대적으로 설계된 무상태 애플리케이션 아키텍처에서는 그렇습니다. 하지만 전통적인 상태 저장형 애플리케이션 아키텍처에서는 그렇지 않습니다.

클라이언트-서버와 그 후속 형태인 3계층 웹 앱은 일반적으로 상태 저장 방식입니다. 이들은 클라이언트와 앱 간의 상호 작용에 관한 특정 정보를 세션에 유지합니다. 이 세션은 앱 또는 웹 서버의 메모리에 저장될 수도 있고, 별도의 데이터베이스에 저장될 수도 있습니다. 데이터가 어디에 저장되든, 바로 이 데이터 때문에 앱이 상태 저장 방식이 됩니다. 이 데이터는 앱 운영과 관련이 있으며 매우 중요합니다. 여기에는 장바구니, 마지막으로 방문한 페이지 및 기타 앱별 정보가 포함됩니다.

해당 정보가 저장된 웹/앱 서버가 갑자기 사라지면 고객 경험에 부정적인 영향을 미칠 수 있다는 점은 쉽게 상상할 수 있습니다. 장바구니가 사라지고, 이전에 있던 페이지로 다시 이동해야 하며, 사실상 처음부터 다시 시작해야 합니다.

이러한 동작은 애플리케이션의 상태 저장 방식 운영을 배제하는 현대적인 아키텍처 원칙과 정면으로 배치됩니다. 문제가 발생했을 때 한 인스턴스를 다른 인스턴스로 원활하게 대체할 수 있는 것은 현대적인 앱과 서비스가 무상태로 작동하기 때문입니다. 이는 "장애를 전제로 한 설계"가 작동하는 기반입니다. 여기에 상태를 다시 도입하면 모든 것이 순식간에 무너집니다.

앱은 계속 작동하지만 사용자는 이도 저도 못하는 상태에 놓입니다. 사용 흐름은 중단되고, 진행 중이던 트랜잭션은 허공으로 사라져 다시는 찾을 수 없게 됩니다.

이 문제로 인해 애플리케이션 서비스가 상태를 유지해야 할 필요성이 대두되었습니다. 클라이언트가 특정 앱/웹 서버에 연결되면 세션이 유지되는 동안 계속해서 동일한 앱/웹 서버에 연결해야 했습니다. 요청이 매번 동일한 서버로 라우팅되도록 쿠키 지속성과 기타 메커니즘이 개발되었습니다. 상태를 보존하기 위해서였습니다.

현실적으로 완전히 새롭게 시작하는 스타트업이 아니라면, 현재 기존 애플리케이션과 최신 애플리케이션을 모두 운영하고 있을 것입니다. 이 주제에 대한 조사 결과는 다양하지만, "레거시 애플리케이션 63% / 신규 애플리케이션 37%"라는 비율은 시간이 지나도 대체로 일관되게 유지됩니다. 즉, 레거시 아키텍처와 최신 아키텍처를 동시에 지원해야 합니다.

상태 저장형과 무상태형 간의 차이를 해결하지 않았다면, 모놀리스를 단순히 컨테이너로 옮기는 것만으로는 도움이 되지 않습니다.

아키텍처 계층화

모놀리식 애플리케이션을 컨테이너화된 환경으로 마이그레이션하는 가장 좋은 방법, 또는 적어도 가장 쉬운 방법은 컨테이너 클러스터의 무상태 혼란 속에서도 상태를 계속 유지할 수 있도록 하는 것입니다. 이를 위해서는 N-S 트래픽과 E-W 트래픽이 만나는 인그레스, 즉 클러스터 경계에서 지능적인 처리가 필요합니다.

2계층 접근 방식은 기존 운영 방식과 현대적인 운영 방식을 모두 지원할 뿐만 아니라, 기존의 상태 저장형 애플리케이션을 컨테이너화된 환경으로 마이그레이션하는 것도 지원합니다. F5 Container Ingress Services(CIS)를 활용하면 NetOps는 컨테이너화된 환경으로 마이그레이션되는 상태 저장형 애플리케이션의 요구 사항을 지속적으로 지원할 수 있습니다. 이러한 연결성을 통해 지속성을 사용하는 기존 로드 밸런싱 방식이 계속 작동하면서 요청을 적절한 컨테이너 또는 기존 환경으로 직접 전달할 수 있습니다.

한편, BIG-IP는 최신 앱 및 API에 대한 요청을 컨테이너 클러스터 내부의 인그레스 컨트롤러로 동시에 전달하여 필요한 만큼 많은 스테이트리스 컨테이너에 분산할 수 있습니다.

전환에는 시간이 필요합니다

실제로 대부분의 조직은 모놀리식 아키텍처부터 모바일, 마이크로서비스에 이르기까지 서로 확연히 다른 애플리케이션 아키텍처를 최대 5개까지 지원하고 있습니다. 이와 동시에 그만큼 다양하고 상이한 네트워크 및 운영 모델까지 지원하면 운영팀에 과도한 부담이 가중되고, 최신 아키텍처와 환경으로 전환함으로써 얻을 수 있는 이점이 상쇄될 수밖에 없습니다. 전략적인 2계층 접근 방식을 활용하면 조직은 대부분이 컨테이너화된 환경으로 전환하는 동안 두 모델의 운영상 및 비즈니스상 이점을 모두 최대한 확보할 수 있습니다.

리팩터링 옵션

이러한 전환을 수월하게 하는 방법 중 하나는 공유 세션을 활용할 수 있도록 레거시 앱을 리팩터링하는 것입니다. 이러한 세션은 웹/앱 서버와 분리된 위치(일반적으로 일종의 데이터베이스)에 저장되며, 올바른 세션 ID가 있으면 어떤 웹/앱 서버에서든 액세스할 수 있습니다. 세션 ID는 계속 추적해야 하지만, 일반적으로 웹/앱 서버의 상태와 관계없이 유지되는 쿠키를 통해 처리할 수 있습니다. 레거시 앱에서 아직 공유 세션 모델을 사용하지 않는다면, 전체 앱의 플랫폼을 전환하는 것보다 공유 세션 모델을 사용하도록 리팩터링하는 편이 비교적 수월합니다.

결국 이러한 전환에는 시간이 걸립니다. 오늘날에도 거의 모든 조직이 여전히 멀티 클라우드 모델로 운영되고 있기 때문입니다. 따라서 가용성과 보안 같은 핵심 고객 요구 사항을 훼손하지 않으면서 이점을 극대화할 수 있는 아키텍처 옵션을 찾아 활용하는 것이 중요합니다. 2계층 아키텍처 접근 방식을 사용하면 컨테이너화 작업을 제약하지 않으면서 두 가지를 모두 충족할 수 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물