Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
가상화ㆍ컨테이너 / 개발자 / 클라우드

“마이크로소프트 365도 옮겼다” 윈도우 앱을 컨테이너로 옮기는 방법

Simon Bisson | InfoWorld 2022.08.22
마이크로소프트 플랫폼 상에서 구축 작업을 하는 개발자라면 누구나 알고 있는 오랜 격언은 “어떤 마이크로소프트 제품이 전성기를 맞이할 준비가 되었는지 파악하려면, 그 제품이 마이크로소프트의 주력 애플리케이션이나 서비스에 사용되는지 여부를 보면 알 수 있다”는 것이다. 

즉, 올리언스(Orleans) 분산 애플리케이션 프레임워크는 헤일로(Halo)의 대부분을 구동했을 때, 플루이드 프레임워크(Fluid Framework)는 팀즈(Teams) 내에 들어갔을 때 등등이 본격적으로 사용할 때가 되었다는 의미이다. 최근에 승인 도장을 받은 서비스는 애저 쿠버네티스 서비스(Azure Kubernetes Service, AKS) 상의 윈도우 컨테이너다. 마이크로소프트는 코로나19 대유행에 따른 급속한 업무 패턴의 변화를 고려한 확장성 및 유연성 제고를 위해 마이크로소프트 365 플랫폼의 대부분을 AKS로 옮기는 작업에 지난 1년 정도를 보냈다.  
 
ⓒ Getty Images Bank
 

마이크로소프트 365, 클라우드 네이티브 컨테이너로 이전

마이크로소프트 365 규모의 서비스를 컨테이너로 옮기는 과정은 복잡했다. 오피스 온라인(Office Online) 단일 테넌트 시스템을 멀티 테넌트 가상화 아키텍처로 옮기는 일은 특히 CI/CD로의 이전을 동반한 경우 충분히 어려웠다. 제일 먼저 이전한 것은 컨테이너로의 이전에 필요한 아키텍처 개선의 많은 부분이었다. 무엇보다도 애플리케이션 VM에서 마이크로소프트 그래프(Microsoft Graph)로 옮기는 것이 중요했다. 그러나 많은 서비스, 특히 테넌트를 구성하는 서비스와 시스템 사이의 네트워킹을 지원하고 가용성을 관리하는 용도의 서비스는 여전히 커스텀 방식이었다. 

이 접근법은 일관성 부재로 이어졌다. 애플리케이션 빌드는 특정 플랫폼을 목표로 해야 했다. 그 결과, 아키텍처의 비효율성이 발생했다. 서로 다른 VM을 호스팅하려면 서로 다른 서버 종류가 필요했기 때문이다. 마이크로소프트 365 서비스를 호스팅한 데이터센터의 복잡성과 비용이 커지면서 서비스 운영 비용이 늘어났다. 최적의 활용을 위한 서버 간 로드 이동이 용이하지 않아 하이퍼스케일 환경이 갖는 비용 상의 이점이 축소되었다. 

서비스를 쿠버네티스 상에 구축하려면 기존의 모놀리식 서비스를 다시 생각해서 확장 가능한 마이크로서비스로 작동하도록 리팩터링해야 한다. 그러나, 윈도우 컨테이너를 사용할 수 있었기 때문에 이미 사용 중이던 것을 전혀 잃지 않았다. AKS 컨테이너 호스트는 윈도우 API에 접근 권한이 있는 적절한 닷넷 툴과 서비스로 프로비저닝할 수 있었다. 이들 호스트 기능은 컨테이너 간에 공유되지만 컨테이너 격리 덕분에 안전하게 접근할 수 있다. 

동시에, 컨테이너 인스턴스는 VM보다 크기가 작기 때문에 같은 수의 물리 호스트에서 더 많은 애플리케이션을 실행할 수 있다. 따라서, 전체적인 비용이 낮아지고 보다 효율적인 애저 하드웨어 사용이 가능해진다. 마이크로소프트의 내부 회계 시스템에 따라 각 그룹은 클라우드 사용 예산을 세워야 한다. 그래야 절약된 부분을 서비스 내의 다른 곳에 투자할 수 있다. 

마이크로소프트 365를 클라우드 네이티브 아키텍처로 이동하는 장점은 이 밖에도 많다. 모든 개발자가 동일한 API를 공유하므로 테스트와 변화 관리가 단순해지고 개발팀이 CI/CD를 애플리케이션 운영 모델의 일환으로 사용할 수 있게 되면서 플랫폼 운영을 코드와 분리시키고 서비스에서 사용하는 AKS 기능을 관리한다. 이제 새로운 애플리케이션은 구축 후 먼저 테스트 클러스터에 배포된다. 그 다음에 내부 사용자와 외부 내부자를 위한 초기 채널에 배포된 후 프로덕션 단계로 이동한다. 
 

자체 코드를 컨테이너화하는 방법 

일반 기업은 어떻게 하면 자체 코드를 마이크로소프트 코드처럼 컨테이너와 AKS로 옮길 수 있을까? 확실히 변화의 많은 부분은 조직적이어야 한다. 먼저 전용 인프라, 플랫폼, 애플리케이션팀에 이미 성숙한 데브옵스 프랙티스가 자리잡고 있어야 한다. 그 다음으로 필요한 것은 해당 코드를 리프트 앤 시프트 방식으로 이전하고 컨테이너 환경에서의 작업 지원에 필요한 변화를 만드는 것이다. 모놀리식 애플리케이션은 컨테이너 기반 환경, 특히 플랫폼 운영의 많은 부분이 자동화되어 있고 그 때 그 때 확장되며 플랫폼 수준 서비스 메시를 사용해 선언 네트워킹 및 보안을 관리하는 AKS와 같은 환경에서는 제대로 동작할 가능성이 낮다.  

다행히 마이크로소프트 윈도우 컨테이너팀은 최근 마이크로소프트 365와 같은 작업 경험을 바탕으로 설명서를 발표했다. 이 문서는 애플리케이션을 윈도우 서버 환경(가상화된 환경도 포함)에서 컨테이너로 옮길 때 고려해야 할 점을 설명하고 있다. 익숙한 API와 라이브러리에 접근한다고 해도 컨테이너로 작업하는 것은 서버로 작업하는 것과는 다르다.

컨테이너화의 장애물 중 많은 것은 이미 상식이다. 컨테이너는 대화형 애플리케이션 용도로 적합하지 않고 GUI 지원이 없다. 호스트 OS는 윈도우 서버 코어의 한 버전이므로 코드는 그에 맞게 작동하도록 설계해야 한다. 이를테면 자동 설치(Silent Install)만 지원하거나 RDP 접근을 허용하지 않는 것이다. UI가 없으면 코드는 예컨대 윈도우 관리 센터와 함께 사용할 엔드포인드를 제공하는 대체 관리 API가 필요하다. 

이와 비슷하게, 코드가 설정을 비롯한 데이터를 컨테이너 내부에 저장하는 일이 없도록 조치해야 한다. 컨테이너는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 요구에 따라 생성되고 소멸되는, 상태가 유지되지 않고(Stateless) 금방 사라지는 아이템으로 취급해야 한다. 

만일 AKS를 대상으로 한다면, 애저 파일(Azure Files) 또는 블롭(Blob)과 같은 애저 스토리지 인스턴스를 사용해 컨테이너의 상태와 데이터를 보관하는 방안을 고려해야 한다. 그러면 결제 프로세스를 처리하는 컨테이너가 고장나도 대체 컨테이너가 사용자 모르게 세션 상태를 이어받아 계속 진행할 수 있다. 마찬가지로, 수요에 따라 추가 컨테이너가 필요한 경우 애플리케이션 상태와 설정이 준비되는 대로 이어받을 수 있다. 

다른 한계도 있다. 코드는 윈도우 서버 2016 이후 버전에서 실행되어야 하므로 구형 애플리케이션은 호환성 작업이 필요할 수 있다. 닷넷 프레임워크의 구형 버전도 마찬가지다. 마이크로소프트가 지원되는 버전의 컨테이너 이미지를 제공하지만, 코드가 최신 버전 하에서 실행되는지 확인하는 편이 좋다. 최신 버전은 설계상 마이크로서비스 아키텍처를 지원하고 용량이 상대적으로 작으므로 동일한 호스트에 더 많은 컨테이너를 실행할 수 있다. 액티브 디렉토리 역할이나 윈도우 서버 인프라 기능에 대한 의존성을 피하는 것이 중요하다. 컨테이너는 다른 것이 아닌 애플리케이션을 위한 것이다. 
 

클라우드 서비스의 이점을 최대한 활용하라 

AKS나 애저 컨테이너 인스턴스(Azure Container Instances) 아니면 심지어 애저 컨테이너 앱(Azure Container Apps)으로 옮길 계획이라면, 애플리케이션 내 어디에서 다른 애저 서비스를 사용할 수 있는지 고려할 필요가 있다. 데이터베이스나 다른 애플리케이션에 의존성이 있다면, 애플리케이션을 호스팅할 가상 서버를 설정하는 것보다 해당 용도에 맞는 애저 서비스를 사용하는 것이 더 쉬울 것이다. 아니면 클라우드 최적화 버전과 업체 지원 버전을 애저 마켓플레이스(Azure Marketplace)에서 찾아볼 수도 있다. 마찬가지로, 액티브 디렉토리를 접근 통제용으로 사용한 경우, 컨테이너와 호환되는 애저 액티브 디렉토리 API 사용을 고려하는 것이 좋다. 

마이크로소프트의 컨테이너화 설명서에는 컨테이너에서 지원되지 않는 온프레미스 서비스의 적합한 대안이 나와 있다. 이들 대안으로 전환하려면 시간이 걸리고 추가 개발 작업이 필요한데 구형 애플리케이션에서는 문제가 될 수 있다. 아무리 클라우드 네이티브와 컨테이너로 옮기고 싶어도 비경제적이거나 너무 복잡한 경우도 있다. 

컨테이너화는 새로운 클라우드 네이티브 애플리케이션을 구축하는 용도, 컨테이너를 CI/CD 파이프라인의 엔드포인트로 취급하는 용도, 애플리케이션을 구성하는 서비스의 확장과 오케스트레이션을 위해 쿠버네티스를 사용하는 용도로 쓸모 있는 기술이다. 마이크로소프트가 직접 경험한 것을 미루어 볼 때 가상 인프라에서 클라우드 네이티브로 옮기는 것이 가능하다는 것을 알 수 있다. 또한, 마이크로소프트 설명서에는 필요한 변화를 만드는 방법이 소개되어 있다. 쉽지는 않지만 마이크로소프트 365가 입증한 것처럼 그로 인해 얻을 수 있는 장점은 필요한 엔지니어링 노력을 들일 만한 가치가 충분하다.
 editor@itworld.co.kr
 Tags 마이크로소프트365 마이그레이션 리팩터링 애저클라우드 API
Sponsored
IDG 설문조사

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

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

Copyright © 2022 International Data Group. All rights reserved.