2020.08.14

"아직 늦지 않았다"··· 윈도우 서버 2008 마이그레이션 가이드

Andy Patrizio | Computerworld
이제 기존 서버를 마이그레이션할 때가 됐다. 간단한 작업은 아니다. 

1월 14일, 마이크로소프트가 윈도우 서버 2008과 2008R2 지원을 공식 종료했다. 취약점이 발견되더라도 더 이상 패치나 픽스가 배포되지 않는다는 의미다. 단, 정말 심각한 문제라면 예외가 적용된 사례도 있긴 했다.  

어쨌든 앱을 마이그레이션해야 할 때다. 이 프로세스는 간단하진 않다. 서버 2008은 CPU 코어가 2~4개이던, 그리고 64 비트 컴퓨팅이 초기 단계이던 시절에 등장했다. 당시 클라우드는 아직 꿈 같은 이야기였다. 단일 테넌트(single-tenant), 단일 스레드(single-thread) 앱을 클라우드로 옮기기 쉽지 않다고만 해도 충분할 이해할 것이다. 이는 경우에 따라 적합하지 않거나 아예 불가능할 수도 있다. 
 
ⓒGetty Images

물론 윈도우 서버 2019(최신 버전) 혹은 서버 2016으로 충분히 마이그레이션 할 수 있다. 마이크로소프트는 원활한 전환을 위해 여러 지원을 아끼지 않고 있다. 

시장조사업체 AVOA의 애널리스트 팀 크로포드는 네트워크 월드(Network Word)와의 인터뷰에서 “서버 2008 마이그레이션을 주저하게 만드는 두 가지 이유가 있다. 첫째, 맞춤형 앱이 WS 2008의 특정 기능들을 사용하고 있거나 둘째, WS 2008과만 호환되는 애플리케이션 버전을 사용하고 있기 때문이다”라고 말했다.

윈도우 서버 전문가이자 마이크로소프트 MVP로 활동하는 컨설턴트 데이트 카울라도 여기에 동의했다. 그는 “아주 오래된 코드들을 많이 봐왔다”라면서, “모두가 마이크로소프트의 최신 기술을 이용한다면 좋겠지만 실제는 그렇지 않다. 대부분의 기업은 4~6년 정도 뒤쳐진 기술을 이용하고 있다”라고 설명했다.

긴 여정
서버 2008의 앱을 2016/2019로 마이그레이션 하기로 했다면, 이는 아주 복잡한 일이 될 것이다. 마이크로소프트조차 앱과 데이터를 서버 2012로 마이그레이션하는 중간 단계가 필요하다고 말한다. 2016/2019는 2008이 아닌 2012 서버부터 마이그레이션 도구를 지원하기 때문이다.

마이크로소프트에 따르면 윈도우 서버 2016/2019에 새 가상머신(VM)을 스핀업하고, 기존 앱을 새 VM으로 마이그레이션해 호환성을 테스트하는 것이 일반적인 마이그레이션 프로세스다. 마이크로소프트는 구 버전 운영체제의 서버 기능을 모든 최신 버전들과 호환되도록 만들었기 때문에 큰 문제는 없을 것으로 판단한다고 언급했다.

카울라는 이를 ‘이중 도약(double hop)’ 마이그레이션이라고 표현했다. 즉, 앱을 2012로 마이그레이션해 패칭한 다음, 두 번째 업그레이드를 실시한다. 그러나 같은 하드웨어에서 수행되는 것은 아니다. 그는 “하이퍼-V(Hyper-V)나 VM웨어(VMware)에서 실행하라. 가상화를 마치고 나면 더 많은 옵션을 사용할 수 있다”라고 전했다.

이어서 그는 “서버 2008에서 하이퍼-V 가상화가 처음 제대로 시도됐다. 이는 문제가 없었다. 기존 가상화 시스템과 새로운 가상화 시스템 사이의 기술을 활용해 좋은 성과를 거뒀다”라고 덧붙였다.

윈도우 서버 2008은 비스타 코드 베이스에, 2016/2019는 윈도우 10 코드 베이스에 기반을 두고 있다. 마이크로소프트 MVP이자 고가용성 솔루션 전문 컨설팅 업체인 MPECS의 공동 설립자 필립 엘더는 가장 어려웠던 것은 서버 2003에서 2008로의 마이그레이션이었다고 말했다. 서버 2003은 윈도우 XP에 토대를 두고 있는 데, XP와 비스타 사용자 모드, 커널 모드 사이의 변경이 극적이었기 때문이다.

엘더는 “비스타에서 윈도우 7, 윈도우 8, 윈도우 10으로의 변화는 반복적이어서, 비스타에 있는 좋은 코드의 기본 구조가 각 에디션으로 그대로 옮겨졌다”라고 설명했다.

마이크로소프트는 서버 2008 고객이라면 윈도우 서버 2012 R2 설치가 필요한 온프레미스 서버에 아래의 가이드라인을 적용해야 한다고 권고했다.

• 인-플레이스 업그레이드(In-place upgrades)는 빌드 종류가 동일해야 한다(예: 32비트는 32비트, 64비트는 64비트 아키텍처).
• 사용자는 서버 2012 R2에서만 업그레이드된 서버 코어 설치판을 전체 데스크톱 서버로 전환할 수 있다. 윈도우 서버 2016 이후 에디션은 서버 코어를 전체 데스크톱으로 전환하는 것을 지원하지 않는다. 따라서 윈도우 서버 2016으로 업그레이드하기 전에 전환하는 것이 좋다.
• 인-플레이스 업그레이드는 동일 언어로만 지원된다.


마이크로소프트에 따르면 마이그레이션하기 가장 어려운 윈도우 서버 애플리케이션은 32비트 커널 모드 드라이버를 가진 32비트 애플리케이션이다. 윈도우/윈도우 서버 32비트 버전은 32비트 드라이버, 그리고 윈도우/윈도우 서버 64비트 버전은 64비트 드라이버가 필요하다. 64비트 운영체제에 32비트 드라이버를 혼용할 수 없고, 그 반대도 마찬가지다.

윈도우 서버 2008 R2 이후 서버 에디션들은 모두 64비트다. 그렇다면 32비트 커널 모드 드라이버를 가진 구형 32비트 앱이 있다면 앱의 64비트 버전을 새로 개발해야 한다. 그러나 구형 32비트 앱에 32비트 드라이버가 필요하지 않다면? 그냥 ‘작동’할 가능성이 높다. 

'흐린' 하늘
많은 워크로드를 클라우드로 옮기면서 일부 애플리케이션과 데이터는 온프레미스에 유지하려는 기업이 많다. 온프레미스 유지 여부를 결정하는 기준은 통상 데이터의 민감성과 사용량이다. 클라우드는 사용한만큼 비용을 내기 때문에 사용량이 많은 애플리케이션은 많은 비용을 지불할 수 있다. 

마이크로소프트는 클라우드 마이그레이션에서 가장 중요한 것은 조직 변화 관리라고 강조했다. 여기에는 사람(역할/책임), 프로세스(애플리케이션 개발 및 운영 워크플로우), 기술(클라우드 기반 도구와 기능 활용)이 해당된다. 앱에 앞서 명확한 비전과 경영진의 지원을 바탕으로 전략을 수립해야 한다는 것이다. 

또한 비즈니스 위험과 기술적 복잡성에 따라 워크로드의 우선순위를 정하라고 마이크로소프트는 조언했다. 기업은 클라우드 마이그레이션 전문가 조직(CoE)을 통해 IT 인프라와 운영, 데이터베이스 관리, 아키텍트, 보안/컴플라이언스, 네트워킹, 스토리지, 애플리케이션 개발, 현업 부문을 아우르는 크로스 펑셔널 팀을 구성하고 거버넌스와 표준, 자동화 정책, 워크로드 우선순위 등을 설정해야 한다. 

기업은 ‘파도처럼(in waves)’ 클라우드 마이그레이션을 실행해야 한다. 마이크로소프트는 심층적인 기술 평가 및 마이그레이션에 관해 반복적인 접근방식을 취하라고 권고했다. 이는 초기 마이그레이션 단계에서는 보수적인 접근방식을 취한다는 것을 의미한다. 하지만 애플리케이션 소유자가 클라우드 마이그레이션을 이해할수록 프로세스가 개선돼 더욱 속도를 낼 수 있다. 

카울라에 따르면 앱 마이그레이션의 문제점 중 하나는 아이덴티티다. 온프레미스 아이덴티티를 클라우드에서 관리할 수 있을까? 그는 데이터센터에서 작동한다면 클라우드에서도 작동될 확률이 99%라고 주장했다. 그렇지 않은 경우 VM에서 앱을 실행할 수 있는 옵션이 항상 있다.

그러나 엘더는 마이크로소프트의 메시지가 ‘모든 것을 클라우드’에서 ‘하이브리드’로 바뀌었다고 언급하면서 조금 더 주의할 필요가 있다고 전했다. 그는 “클라우드 환경에서 작동하지 않는 앱이 너무 많다는 게 현실이다. 따라서 마이크로소프트는 고객으로 하여금 어떻게 하면 앱을 클라우드로 가져올 수 있는지 파악할 시간을 줘야 한다. 개인적으로 볼 때 많은 기업들에게 가장 적절한 방법은 하이브리드일 것”이라고 진단했다.

기술 아키텍트 겸 마이크로소프트 MVP 디디에르 반호예는 IaaS, PaaS 또는 컨테이너화된 제품에서 서버 2008 앱을 서버 2019로 옮기는 옵션들이 있지만, 클라우드를 제대로 활용하려면 마이그레이션이 필요하다고 설명했다. 

이어서 그는 “그대로 들어서 옮기는 방식(Lift and Shift)도 있지만, 이는 클라우드를 제대로 활용할 수 있는 방법이 아니다. 앱에 탄력성을 구현해야 한다. 그리고 이는 컨테이너가 아닌 VM이 될 것이다. 그다음 최신 OS 버전에서 실행되도록 앱을 현대화할 수 있다. 물론 VM에 아직 남아있을 것이다. 이때의 이점은 과거보다 더 쉽고 빠르게 메모리, CPU, 스토리지를 조정할 수 있다는 것이다. 그러나 온프레미스 가상화가 얼마나 잘됐는지, 아직 하드웨어인지 여부에 따라 달라진다”라고 말했다.

까다로운 항해
비교적 원활하게 클라우드로 옮길 수 있는 오래된 앱들이 대다수는 아니더라도 꽤 된다. 그러나 실수할 수 있는 부분도 일부 존재한다. 

카울라는 “개인적인 경험에 비춰볼 때 자체 개발한 오라클 앱의 마이그레이션이 특히 까다롭다”라며, “이들은 파워빌더(PowerBuilder)로 작성됐으며, 기업들은 닷넷(.Net)으로 현대화를 시도한다. 그런데 이것 때문에 어려워진다. 아직 파워빌더가 사용되고 있기 때문이다. 이는 모두가 갖는 문제점 중 하나다”라고 지적했다.

엘더는 구형 데이터베이스와 앱이 까다로울 수 있다고 언급했다. 내부 액세스 권한을 위해 액티브 디렉토리(Active Directory) 사용자 ID가 필요할 수 있기 때문이다. 

그는 닷넷 앱은 특정 버전의 닷넷 프레임워크가 필요하며, 새 버전의 닷넷이 배포될 때마다 이 버전을 대상으로 앱을 테스트해야 한다고 덧붙였다. 이 경우 기업들은 앱 업체가 승인한 닷넷 버전만 사용할 수 있다.

두 사람 모두 언급한 또 다른 문제는 앱의 컨테이너화를 시도하는 것이다. 컨테이너는 운영체제의 축소된 버전이다. 서버 2019는 컨테이너를 염두에 두고 고안됐지만 윈도우 서버 2008용으로 코딩 된 앱은 그렇지 않다. 엘더는 “서버 2008 코드를 가져와 컨테이너화 하는 것은 불가능하다. 이를 300MB OS로 구현할 수 없다”라고 말했다.

카울라는 “컨테이너에 배치하기 위해서는 앱을 다시 작성해야 한다. 컨테이너의 작동 방식은 일회용 미니 웹서버와 비슷하다. 수동으로 설치하지 않고도 배포할 수 있도록 앱을 작성하면 컨테이너에서 훨씬 더 잘 작동할 것이다. 다시 말하지만 앱에 따라 다를 수 있다”라고 설명했다.

반호예에 따르면 구형 앱에 문제가 있다면 이는 데이터 지속성 때문이다. 데이터 지속성은 상태 유지가 필요한(stateful) 앱에서 사용된다. 이는 각 클라이언트 세션에 대한 데이터를 저장하고, 다음 클라이언트 요청에서 해당 데이터를 사용한다. 컨테이너는 상태 유지가 필요 없으며(stateless), 데이터를 저장하지 않는다. 

이어서 그는 “일반적으로 GUI와 하드웨어 종속성을 가진 스테이트풀 앱보다 스테이트리스 앱이 더 낫다. 아예 쓰지 말라는 이야기가 아니라 더 복잡하고 모든 것을 다 다룰 수 없다고 말하는 것이다. 앱에 리팩토링과 재설계가 필요할지도 모른다”라고 말했다.

이전 버전과 다른 윈도우 서버 2019의 하이브리드, 보안, 인프라, 애플리케이션 플랫폼의 기능은 이곳을 참조하라. 윈도우 서버 2016을 지원하는 서버 애플리케이션, 윈도우 서버 2019를 지원하는 서버 애플리케이션에 대한 표는 각각의 링크에서 확인할 수 있다.

물론 아직 늦은 것은 아니다. 서버 2012 지원은 2023년 10월 10일자로 종료되기 때문이다. ciokr@idg.co.kr



2020.08.14

"아직 늦지 않았다"··· 윈도우 서버 2008 마이그레이션 가이드

Andy Patrizio | Computerworld
이제 기존 서버를 마이그레이션할 때가 됐다. 간단한 작업은 아니다. 

1월 14일, 마이크로소프트가 윈도우 서버 2008과 2008R2 지원을 공식 종료했다. 취약점이 발견되더라도 더 이상 패치나 픽스가 배포되지 않는다는 의미다. 단, 정말 심각한 문제라면 예외가 적용된 사례도 있긴 했다.  

어쨌든 앱을 마이그레이션해야 할 때다. 이 프로세스는 간단하진 않다. 서버 2008은 CPU 코어가 2~4개이던, 그리고 64 비트 컴퓨팅이 초기 단계이던 시절에 등장했다. 당시 클라우드는 아직 꿈 같은 이야기였다. 단일 테넌트(single-tenant), 단일 스레드(single-thread) 앱을 클라우드로 옮기기 쉽지 않다고만 해도 충분할 이해할 것이다. 이는 경우에 따라 적합하지 않거나 아예 불가능할 수도 있다. 
 
ⓒGetty Images

물론 윈도우 서버 2019(최신 버전) 혹은 서버 2016으로 충분히 마이그레이션 할 수 있다. 마이크로소프트는 원활한 전환을 위해 여러 지원을 아끼지 않고 있다. 

시장조사업체 AVOA의 애널리스트 팀 크로포드는 네트워크 월드(Network Word)와의 인터뷰에서 “서버 2008 마이그레이션을 주저하게 만드는 두 가지 이유가 있다. 첫째, 맞춤형 앱이 WS 2008의 특정 기능들을 사용하고 있거나 둘째, WS 2008과만 호환되는 애플리케이션 버전을 사용하고 있기 때문이다”라고 말했다.

윈도우 서버 전문가이자 마이크로소프트 MVP로 활동하는 컨설턴트 데이트 카울라도 여기에 동의했다. 그는 “아주 오래된 코드들을 많이 봐왔다”라면서, “모두가 마이크로소프트의 최신 기술을 이용한다면 좋겠지만 실제는 그렇지 않다. 대부분의 기업은 4~6년 정도 뒤쳐진 기술을 이용하고 있다”라고 설명했다.

긴 여정
서버 2008의 앱을 2016/2019로 마이그레이션 하기로 했다면, 이는 아주 복잡한 일이 될 것이다. 마이크로소프트조차 앱과 데이터를 서버 2012로 마이그레이션하는 중간 단계가 필요하다고 말한다. 2016/2019는 2008이 아닌 2012 서버부터 마이그레이션 도구를 지원하기 때문이다.

마이크로소프트에 따르면 윈도우 서버 2016/2019에 새 가상머신(VM)을 스핀업하고, 기존 앱을 새 VM으로 마이그레이션해 호환성을 테스트하는 것이 일반적인 마이그레이션 프로세스다. 마이크로소프트는 구 버전 운영체제의 서버 기능을 모든 최신 버전들과 호환되도록 만들었기 때문에 큰 문제는 없을 것으로 판단한다고 언급했다.

카울라는 이를 ‘이중 도약(double hop)’ 마이그레이션이라고 표현했다. 즉, 앱을 2012로 마이그레이션해 패칭한 다음, 두 번째 업그레이드를 실시한다. 그러나 같은 하드웨어에서 수행되는 것은 아니다. 그는 “하이퍼-V(Hyper-V)나 VM웨어(VMware)에서 실행하라. 가상화를 마치고 나면 더 많은 옵션을 사용할 수 있다”라고 전했다.

이어서 그는 “서버 2008에서 하이퍼-V 가상화가 처음 제대로 시도됐다. 이는 문제가 없었다. 기존 가상화 시스템과 새로운 가상화 시스템 사이의 기술을 활용해 좋은 성과를 거뒀다”라고 덧붙였다.

윈도우 서버 2008은 비스타 코드 베이스에, 2016/2019는 윈도우 10 코드 베이스에 기반을 두고 있다. 마이크로소프트 MVP이자 고가용성 솔루션 전문 컨설팅 업체인 MPECS의 공동 설립자 필립 엘더는 가장 어려웠던 것은 서버 2003에서 2008로의 마이그레이션이었다고 말했다. 서버 2003은 윈도우 XP에 토대를 두고 있는 데, XP와 비스타 사용자 모드, 커널 모드 사이의 변경이 극적이었기 때문이다.

엘더는 “비스타에서 윈도우 7, 윈도우 8, 윈도우 10으로의 변화는 반복적이어서, 비스타에 있는 좋은 코드의 기본 구조가 각 에디션으로 그대로 옮겨졌다”라고 설명했다.

마이크로소프트는 서버 2008 고객이라면 윈도우 서버 2012 R2 설치가 필요한 온프레미스 서버에 아래의 가이드라인을 적용해야 한다고 권고했다.

• 인-플레이스 업그레이드(In-place upgrades)는 빌드 종류가 동일해야 한다(예: 32비트는 32비트, 64비트는 64비트 아키텍처).
• 사용자는 서버 2012 R2에서만 업그레이드된 서버 코어 설치판을 전체 데스크톱 서버로 전환할 수 있다. 윈도우 서버 2016 이후 에디션은 서버 코어를 전체 데스크톱으로 전환하는 것을 지원하지 않는다. 따라서 윈도우 서버 2016으로 업그레이드하기 전에 전환하는 것이 좋다.
• 인-플레이스 업그레이드는 동일 언어로만 지원된다.


마이크로소프트에 따르면 마이그레이션하기 가장 어려운 윈도우 서버 애플리케이션은 32비트 커널 모드 드라이버를 가진 32비트 애플리케이션이다. 윈도우/윈도우 서버 32비트 버전은 32비트 드라이버, 그리고 윈도우/윈도우 서버 64비트 버전은 64비트 드라이버가 필요하다. 64비트 운영체제에 32비트 드라이버를 혼용할 수 없고, 그 반대도 마찬가지다.

윈도우 서버 2008 R2 이후 서버 에디션들은 모두 64비트다. 그렇다면 32비트 커널 모드 드라이버를 가진 구형 32비트 앱이 있다면 앱의 64비트 버전을 새로 개발해야 한다. 그러나 구형 32비트 앱에 32비트 드라이버가 필요하지 않다면? 그냥 ‘작동’할 가능성이 높다. 

'흐린' 하늘
많은 워크로드를 클라우드로 옮기면서 일부 애플리케이션과 데이터는 온프레미스에 유지하려는 기업이 많다. 온프레미스 유지 여부를 결정하는 기준은 통상 데이터의 민감성과 사용량이다. 클라우드는 사용한만큼 비용을 내기 때문에 사용량이 많은 애플리케이션은 많은 비용을 지불할 수 있다. 

마이크로소프트는 클라우드 마이그레이션에서 가장 중요한 것은 조직 변화 관리라고 강조했다. 여기에는 사람(역할/책임), 프로세스(애플리케이션 개발 및 운영 워크플로우), 기술(클라우드 기반 도구와 기능 활용)이 해당된다. 앱에 앞서 명확한 비전과 경영진의 지원을 바탕으로 전략을 수립해야 한다는 것이다. 

또한 비즈니스 위험과 기술적 복잡성에 따라 워크로드의 우선순위를 정하라고 마이크로소프트는 조언했다. 기업은 클라우드 마이그레이션 전문가 조직(CoE)을 통해 IT 인프라와 운영, 데이터베이스 관리, 아키텍트, 보안/컴플라이언스, 네트워킹, 스토리지, 애플리케이션 개발, 현업 부문을 아우르는 크로스 펑셔널 팀을 구성하고 거버넌스와 표준, 자동화 정책, 워크로드 우선순위 등을 설정해야 한다. 

기업은 ‘파도처럼(in waves)’ 클라우드 마이그레이션을 실행해야 한다. 마이크로소프트는 심층적인 기술 평가 및 마이그레이션에 관해 반복적인 접근방식을 취하라고 권고했다. 이는 초기 마이그레이션 단계에서는 보수적인 접근방식을 취한다는 것을 의미한다. 하지만 애플리케이션 소유자가 클라우드 마이그레이션을 이해할수록 프로세스가 개선돼 더욱 속도를 낼 수 있다. 

카울라에 따르면 앱 마이그레이션의 문제점 중 하나는 아이덴티티다. 온프레미스 아이덴티티를 클라우드에서 관리할 수 있을까? 그는 데이터센터에서 작동한다면 클라우드에서도 작동될 확률이 99%라고 주장했다. 그렇지 않은 경우 VM에서 앱을 실행할 수 있는 옵션이 항상 있다.

그러나 엘더는 마이크로소프트의 메시지가 ‘모든 것을 클라우드’에서 ‘하이브리드’로 바뀌었다고 언급하면서 조금 더 주의할 필요가 있다고 전했다. 그는 “클라우드 환경에서 작동하지 않는 앱이 너무 많다는 게 현실이다. 따라서 마이크로소프트는 고객으로 하여금 어떻게 하면 앱을 클라우드로 가져올 수 있는지 파악할 시간을 줘야 한다. 개인적으로 볼 때 많은 기업들에게 가장 적절한 방법은 하이브리드일 것”이라고 진단했다.

기술 아키텍트 겸 마이크로소프트 MVP 디디에르 반호예는 IaaS, PaaS 또는 컨테이너화된 제품에서 서버 2008 앱을 서버 2019로 옮기는 옵션들이 있지만, 클라우드를 제대로 활용하려면 마이그레이션이 필요하다고 설명했다. 

이어서 그는 “그대로 들어서 옮기는 방식(Lift and Shift)도 있지만, 이는 클라우드를 제대로 활용할 수 있는 방법이 아니다. 앱에 탄력성을 구현해야 한다. 그리고 이는 컨테이너가 아닌 VM이 될 것이다. 그다음 최신 OS 버전에서 실행되도록 앱을 현대화할 수 있다. 물론 VM에 아직 남아있을 것이다. 이때의 이점은 과거보다 더 쉽고 빠르게 메모리, CPU, 스토리지를 조정할 수 있다는 것이다. 그러나 온프레미스 가상화가 얼마나 잘됐는지, 아직 하드웨어인지 여부에 따라 달라진다”라고 말했다.

까다로운 항해
비교적 원활하게 클라우드로 옮길 수 있는 오래된 앱들이 대다수는 아니더라도 꽤 된다. 그러나 실수할 수 있는 부분도 일부 존재한다. 

카울라는 “개인적인 경험에 비춰볼 때 자체 개발한 오라클 앱의 마이그레이션이 특히 까다롭다”라며, “이들은 파워빌더(PowerBuilder)로 작성됐으며, 기업들은 닷넷(.Net)으로 현대화를 시도한다. 그런데 이것 때문에 어려워진다. 아직 파워빌더가 사용되고 있기 때문이다. 이는 모두가 갖는 문제점 중 하나다”라고 지적했다.

엘더는 구형 데이터베이스와 앱이 까다로울 수 있다고 언급했다. 내부 액세스 권한을 위해 액티브 디렉토리(Active Directory) 사용자 ID가 필요할 수 있기 때문이다. 

그는 닷넷 앱은 특정 버전의 닷넷 프레임워크가 필요하며, 새 버전의 닷넷이 배포될 때마다 이 버전을 대상으로 앱을 테스트해야 한다고 덧붙였다. 이 경우 기업들은 앱 업체가 승인한 닷넷 버전만 사용할 수 있다.

두 사람 모두 언급한 또 다른 문제는 앱의 컨테이너화를 시도하는 것이다. 컨테이너는 운영체제의 축소된 버전이다. 서버 2019는 컨테이너를 염두에 두고 고안됐지만 윈도우 서버 2008용으로 코딩 된 앱은 그렇지 않다. 엘더는 “서버 2008 코드를 가져와 컨테이너화 하는 것은 불가능하다. 이를 300MB OS로 구현할 수 없다”라고 말했다.

카울라는 “컨테이너에 배치하기 위해서는 앱을 다시 작성해야 한다. 컨테이너의 작동 방식은 일회용 미니 웹서버와 비슷하다. 수동으로 설치하지 않고도 배포할 수 있도록 앱을 작성하면 컨테이너에서 훨씬 더 잘 작동할 것이다. 다시 말하지만 앱에 따라 다를 수 있다”라고 설명했다.

반호예에 따르면 구형 앱에 문제가 있다면 이는 데이터 지속성 때문이다. 데이터 지속성은 상태 유지가 필요한(stateful) 앱에서 사용된다. 이는 각 클라이언트 세션에 대한 데이터를 저장하고, 다음 클라이언트 요청에서 해당 데이터를 사용한다. 컨테이너는 상태 유지가 필요 없으며(stateless), 데이터를 저장하지 않는다. 

이어서 그는 “일반적으로 GUI와 하드웨어 종속성을 가진 스테이트풀 앱보다 스테이트리스 앱이 더 낫다. 아예 쓰지 말라는 이야기가 아니라 더 복잡하고 모든 것을 다 다룰 수 없다고 말하는 것이다. 앱에 리팩토링과 재설계가 필요할지도 모른다”라고 말했다.

이전 버전과 다른 윈도우 서버 2019의 하이브리드, 보안, 인프라, 애플리케이션 플랫폼의 기능은 이곳을 참조하라. 윈도우 서버 2016을 지원하는 서버 애플리케이션, 윈도우 서버 2019를 지원하는 서버 애플리케이션에 대한 표는 각각의 링크에서 확인할 수 있다.

물론 아직 늦은 것은 아니다. 서버 2012 지원은 2023년 10월 10일자로 종료되기 때문이다. ciokr@idg.co.kr

X