마이크로서비스로 모놀리스 이동

거석을 가져다가 용기에 넣으면 바로 보일라!라는 환상적인 믿음이 있습니다. 현대 건축은 규모와 속도의 이점을 갖습니다.

실제로 KubeKon 2018 설문 조사 에서는 응답자의 약 55%가 "기존 앱의 VM 대체 수단으로" 컨테이너를 활용한다고 답했으며, 실제로 이런 일이 일어나고 있다고 밝혔습니다. 다른 조사에서는 상당량의 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계층 아키텍처 접근 방식을 사용하면 컨테이너화 작업에 제약을 주지 않고도 두 가지 모두를 제공할 수 있습니다.