2017.11.02

윈도우 서버 1709 : 컨테이너 중심의 데브옵스 지향 운영체제

Simon Bisson | InfoWorld
마이크로소프트는 윈도우 서버 배포 방법뿐만 아니라 서버의 역할에 대한 생각까지 바꾸고 있다.

올해 초에 발표된 첫 반기(연 2회) 윈도우 서버 릴리즈가 마침내 등장했다. 윈도우 서버 1709 릴리즈의 중심은 윈도우 서버의 서버 코어에 대한 대대적인 업데이트이며, 엔터프라이즈와 데이터센터 에디션에 각각 새 버전이 적용됐다. 새로운 윈도우 서버는 데브옵스 기반의 조직에 유리한 기능을 제공하고 컨테이너와 클라우드 배포 지원을 강화했다.

그러나 새 릴리즈의 이점을 활용하려면 윈도우 서버 UI는 잊고 명령줄(특히 파워셸 사용), 그리고 익숙한 RSAT 및 새로운 브라우저 기반 프로젝트 호놀룰루와 같은 원격 사용자 인터페이스를 통한 서버 관리로 전환해야 한다.

Image Credit : GettyImagesBank

갑작스러운 변화는 아니다. 마이크로소프트는 꽤 오래 전부터 서버 GUI에서 벗어날 것임을 시사해왔다. 게다가 마이크로소프트 명령줄 툴은 스크립트를 사용해서 여러 서버를 원격 관리하는 측면에서 상당한 이점을 제공한다. 파워셸과 프로젝트 호놀룰루의 혼합으로 서버 관리가 더 어려워지는 것은 아니며, 윈도우 서버의 다양한 유닉스 기반 경쟁 서버와 대등한 위치에 서게 된다. 또한 마이크로소프트는 컨테이너를 비롯해서 서버 운영체제를 사용한 새로운 작업 방법을 지원하기 위한 새로운 관리 기반도 마련했다.

윈도우 서버 1709는 새로운 연 2회 릴리즈 채널을 사용하므로 설치하려면 클린 설치를 해야 한다. 마이크로소프트는 클린 설치를 강제함으로써 장기 지원 윈도우 서버 2016의 5+5 지원 모델에서 벗어나 새로운 연 2회 릴리즈 및 18개월 지원 체계를 확고히 다지려는 것이다.

윈도우 서버 1709의 새로운 컨테이너 기능
마이크로소프트가 윈도우 서버 1709로 노리는 대상은 물론 애플리케이션과 컨테이너 개발자다. 새로운 컨테이너 기본 이미지에는 서버 코어와 나노 서버가 모두 포함된다. 서버 코어는 기존 애플리케이션을 "리프트 앤 시프트(lift and shift)" 방식으로 적용하는 시나리오에 사용되고, 나노 서버는 닷넷 코어 또는 Node.js에서의 새로운 앱 빌딩에 사용된다. 또한 컨테이너 기본 이미지는 크기가 훨씬 더 작다. 서버 코어 이미지에 비해 60%, 나노 서버에 비해 80% 작아졌다. 덕분에 이러한 이미지에 훨씬 더 빠른 속도로 새로운 컨테이너를 배포할 수 있다.

"리프트 앤 시프트" 옵션은 최소한의 작업으로 기존 코드를 컨테이너화할 수 있다는 측면에서 흥미롭다. 물론 모든 애플리케이션 데이터가 컨테이너 외부에 저장되도록 해야 하는 등 컨테이너에서 실행되도록 앱을 구축하는 데는 아키텍처 측면의 문제가 따르므로 일부 재작업은 필요하다. 그러나 실무적으로 볼 때, 특히 윈도우 서버 또는 애저의 스토리지 툴과 API를 사용한다면 변경 작업이 크게 어렵지는 않을 것이다.

윈도우 서버의 새로운 스케줄, 데브옵스 정신과 잘 맞아
6개월마다 한 번씩 릴리즈되는 새로운 윈도우 서버의 방식이 마음에 들지 않는 사람도 있을 것이다. 릴리즈를 건너뛸 수는 있지만(예를 들어 1709에서 1803을 무시하고 1809로 건너뜀), 그렇다 해도 윈도우 서버가 각 릴리즈마다 18개월 동안만 중요한 정기 업데이트를 받는다는 사실에는 변함이 없다. 윈도우 서버의 새로운 주기는 이미 애플리케이션이 전체적인 전략을 이끄는 데브옵스 기반의 프로세스로 전환한 조직에게 가장 잘 맞을 것이다.

물론 데브옵스 방식은 클라우드 우선 개발과 장단이 맞는다. 그동안 윈도우 서버는 특히 컨테이너 이미지가 사용되는 부분에서 리눅스의 빠른 개발 스케줄과 힘들게 경쟁해야 했다. 이것이 윈도우 서버 1709에 포함된 나노 서버의 주된 변화 이유다. 특히 주 운영체제 빌드가 더 경량화되고 있다면 인프라 역할을 지원하는 컨테이너 호스트에는 아무런 의미가 없다.

어쨌든 윈도우 서버의 변화는 3년 또는 5년 릴리즈에 익숙한 시스템 관리자에게 어려운 과제가 될 것이다. 이들에게는 여전히 전통적인 윈도우 서버 방식대로 계속 릴리즈되는 장기 서비스 채널(LTSC)이 있다.

레거시 애플리케이션에는 LTSC를 사용하고 새 빌드와 클라우드용으로는 윈도우 서버 1709와 그 이후 릴리즈를 사용하는 방식으로 윈도우 서버 릴리즈를 데이터센터에 혼합할 수도 있다. 윈도우 서버 1709와 그 이후 릴리즈에는 인프라 역할이 포함되지만, VM의 애플리케이션 호스팅, 그리고 컨테이너 기본 이미지로는 이러한 2년 릴리즈를 사용해야 한다. VM 호스트, 스토리지, 액티브 디렉터리에는 윈도우 서버 LTSC 인프라 서버를 계속 사용해도 무방하다. 어쨌든 인프라 서버는 일단 배포된 이후에는 보안 업데이트 수신 외에는 변경되면 안 되므로 혼합 서버 배포 방식도 괜찮다.

인프라 운영을 데브옵스에서 분리해 생각하면 이 분할 모델은 더 설득력이 있다. 데브옵스 환경에서는 기반 운영체제의 비교적 빠른 변화는 문제가 되지 않는다. 운영체제도 코드, 그리고 나머지 소프트웨어 정의 인프라와 함께 지속적인 통합 파이프라인의 한 가지 요소일 뿐이기 때문이다.

과거의 베타 및 커뮤니티 프리뷰 시스템도 사라진다. 일부 고객은 TAP 빌드를 계속 이용할 수 있지만 그 외에는 향후 릴리즈를 미리 경험하기 위해서는 모두 윈도우 인사이더 프로그램에 가입해야 한다. 새로운 연 2회 업데이트 주기에서는 윈도우 인사이더 프로그램에 참여하는 것이 과거보다 훨씬 더 중요하다. 윈도우 서버의 새로운 스케줄에 따라 각 릴리즈 배포에 앞서 애플리케이션을 인증하기 위한 빠른 테스트가 필요하기 때문이다.

그렇다 해도 테스트가 부담스럽지는 않을 것이다. 연 2회 증분 릴리즈와 대대적인 격년 제품 출시에는 큰 차이가 있다. 각 윈도우 서버 신규 빌드에 포함되는 새로운 기능의 수가 훨씬 더 적은 만큼 기존 애플리케이션에 대한 영향도 최소화될 가능성이 높다.  editor@itworld.co.kr

2017.11.02

윈도우 서버 1709 : 컨테이너 중심의 데브옵스 지향 운영체제

Simon Bisson | InfoWorld
마이크로소프트는 윈도우 서버 배포 방법뿐만 아니라 서버의 역할에 대한 생각까지 바꾸고 있다.

올해 초에 발표된 첫 반기(연 2회) 윈도우 서버 릴리즈가 마침내 등장했다. 윈도우 서버 1709 릴리즈의 중심은 윈도우 서버의 서버 코어에 대한 대대적인 업데이트이며, 엔터프라이즈와 데이터센터 에디션에 각각 새 버전이 적용됐다. 새로운 윈도우 서버는 데브옵스 기반의 조직에 유리한 기능을 제공하고 컨테이너와 클라우드 배포 지원을 강화했다.

그러나 새 릴리즈의 이점을 활용하려면 윈도우 서버 UI는 잊고 명령줄(특히 파워셸 사용), 그리고 익숙한 RSAT 및 새로운 브라우저 기반 프로젝트 호놀룰루와 같은 원격 사용자 인터페이스를 통한 서버 관리로 전환해야 한다.

Image Credit : GettyImagesBank

갑작스러운 변화는 아니다. 마이크로소프트는 꽤 오래 전부터 서버 GUI에서 벗어날 것임을 시사해왔다. 게다가 마이크로소프트 명령줄 툴은 스크립트를 사용해서 여러 서버를 원격 관리하는 측면에서 상당한 이점을 제공한다. 파워셸과 프로젝트 호놀룰루의 혼합으로 서버 관리가 더 어려워지는 것은 아니며, 윈도우 서버의 다양한 유닉스 기반 경쟁 서버와 대등한 위치에 서게 된다. 또한 마이크로소프트는 컨테이너를 비롯해서 서버 운영체제를 사용한 새로운 작업 방법을 지원하기 위한 새로운 관리 기반도 마련했다.

윈도우 서버 1709는 새로운 연 2회 릴리즈 채널을 사용하므로 설치하려면 클린 설치를 해야 한다. 마이크로소프트는 클린 설치를 강제함으로써 장기 지원 윈도우 서버 2016의 5+5 지원 모델에서 벗어나 새로운 연 2회 릴리즈 및 18개월 지원 체계를 확고히 다지려는 것이다.

윈도우 서버 1709의 새로운 컨테이너 기능
마이크로소프트가 윈도우 서버 1709로 노리는 대상은 물론 애플리케이션과 컨테이너 개발자다. 새로운 컨테이너 기본 이미지에는 서버 코어와 나노 서버가 모두 포함된다. 서버 코어는 기존 애플리케이션을 "리프트 앤 시프트(lift and shift)" 방식으로 적용하는 시나리오에 사용되고, 나노 서버는 닷넷 코어 또는 Node.js에서의 새로운 앱 빌딩에 사용된다. 또한 컨테이너 기본 이미지는 크기가 훨씬 더 작다. 서버 코어 이미지에 비해 60%, 나노 서버에 비해 80% 작아졌다. 덕분에 이러한 이미지에 훨씬 더 빠른 속도로 새로운 컨테이너를 배포할 수 있다.

"리프트 앤 시프트" 옵션은 최소한의 작업으로 기존 코드를 컨테이너화할 수 있다는 측면에서 흥미롭다. 물론 모든 애플리케이션 데이터가 컨테이너 외부에 저장되도록 해야 하는 등 컨테이너에서 실행되도록 앱을 구축하는 데는 아키텍처 측면의 문제가 따르므로 일부 재작업은 필요하다. 그러나 실무적으로 볼 때, 특히 윈도우 서버 또는 애저의 스토리지 툴과 API를 사용한다면 변경 작업이 크게 어렵지는 않을 것이다.

윈도우 서버의 새로운 스케줄, 데브옵스 정신과 잘 맞아
6개월마다 한 번씩 릴리즈되는 새로운 윈도우 서버의 방식이 마음에 들지 않는 사람도 있을 것이다. 릴리즈를 건너뛸 수는 있지만(예를 들어 1709에서 1803을 무시하고 1809로 건너뜀), 그렇다 해도 윈도우 서버가 각 릴리즈마다 18개월 동안만 중요한 정기 업데이트를 받는다는 사실에는 변함이 없다. 윈도우 서버의 새로운 주기는 이미 애플리케이션이 전체적인 전략을 이끄는 데브옵스 기반의 프로세스로 전환한 조직에게 가장 잘 맞을 것이다.

물론 데브옵스 방식은 클라우드 우선 개발과 장단이 맞는다. 그동안 윈도우 서버는 특히 컨테이너 이미지가 사용되는 부분에서 리눅스의 빠른 개발 스케줄과 힘들게 경쟁해야 했다. 이것이 윈도우 서버 1709에 포함된 나노 서버의 주된 변화 이유다. 특히 주 운영체제 빌드가 더 경량화되고 있다면 인프라 역할을 지원하는 컨테이너 호스트에는 아무런 의미가 없다.

어쨌든 윈도우 서버의 변화는 3년 또는 5년 릴리즈에 익숙한 시스템 관리자에게 어려운 과제가 될 것이다. 이들에게는 여전히 전통적인 윈도우 서버 방식대로 계속 릴리즈되는 장기 서비스 채널(LTSC)이 있다.

레거시 애플리케이션에는 LTSC를 사용하고 새 빌드와 클라우드용으로는 윈도우 서버 1709와 그 이후 릴리즈를 사용하는 방식으로 윈도우 서버 릴리즈를 데이터센터에 혼합할 수도 있다. 윈도우 서버 1709와 그 이후 릴리즈에는 인프라 역할이 포함되지만, VM의 애플리케이션 호스팅, 그리고 컨테이너 기본 이미지로는 이러한 2년 릴리즈를 사용해야 한다. VM 호스트, 스토리지, 액티브 디렉터리에는 윈도우 서버 LTSC 인프라 서버를 계속 사용해도 무방하다. 어쨌든 인프라 서버는 일단 배포된 이후에는 보안 업데이트 수신 외에는 변경되면 안 되므로 혼합 서버 배포 방식도 괜찮다.

인프라 운영을 데브옵스에서 분리해 생각하면 이 분할 모델은 더 설득력이 있다. 데브옵스 환경에서는 기반 운영체제의 비교적 빠른 변화는 문제가 되지 않는다. 운영체제도 코드, 그리고 나머지 소프트웨어 정의 인프라와 함께 지속적인 통합 파이프라인의 한 가지 요소일 뿐이기 때문이다.

과거의 베타 및 커뮤니티 프리뷰 시스템도 사라진다. 일부 고객은 TAP 빌드를 계속 이용할 수 있지만 그 외에는 향후 릴리즈를 미리 경험하기 위해서는 모두 윈도우 인사이더 프로그램에 가입해야 한다. 새로운 연 2회 업데이트 주기에서는 윈도우 인사이더 프로그램에 참여하는 것이 과거보다 훨씬 더 중요하다. 윈도우 서버의 새로운 스케줄에 따라 각 릴리즈 배포에 앞서 애플리케이션을 인증하기 위한 빠른 테스트가 필요하기 때문이다.

그렇다 해도 테스트가 부담스럽지는 않을 것이다. 연 2회 증분 릴리즈와 대대적인 격년 제품 출시에는 큰 차이가 있다. 각 윈도우 서버 신규 빌드에 포함되는 새로운 기능의 수가 훨씬 더 적은 만큼 기존 애플리케이션에 대한 영향도 최소화될 가능성이 높다.  editor@itworld.co.kr

X