가상화ㆍ컨테이너 / 서버 / 클라우드

“엔터프라이즈 IT를 점검하라” 2017 컨테이너 현황

David Linthicum | HPE 2017.02.28


기존 애플리케이션에 대한 질문
모든 것이 평등하다면, 컨테이너는 기존 애플리케이션과 얼마나 잘 동작하며 어울리고 있을까요? 애플리케이션 플랫폼에 지대한 영향을 받는다는 것이 정답입니다.

전통적인 메인 프레임 애플리케이션에 대한 단답형 정답은 좀 더 현대적인 언어로 재작성되지 않는 한 거의 적합하지 않다는 것입니다. 물론, 시스템들이 거의 20년 이상 지난 것임을 고려한 것입니다. 이런 유형의 워크로드에 대해서는 원래 자리에 그대로 두는 편이 더 낫습니다. 컨테이너를 포함한 이런 시스템은 우리가 위에서 프로필을 작성한 그 어떤 접근방식에 대한 후보도 아닙니다.

자바, 파이선, C++을 비롯한 다른 좀 더 동시대의 언어로 작성된 데이터베이스와 애플리케이션에 대해서는 다음과 같은 핵심적인 특성을 고려해보십시오.

- 애플리케이션이 어떻게 설계되었는가? 애플리케이션이 분산을 목적으로 작성되었고, 구성요소들의 대부분을 분리하기 쉽다면, 컨테이너용으로 훌륭한 후보입니다.

- 데이터를 어떻게 사용하고 있는가? 데이터베이스가 핵심 애플리케이션에 강 결합(Tightly Coupled)되어 있고 분리하기 힘들 경우, 컨테이너용 후보가 되기는 어렵습니다.

- 해당 애플리케이션은 어떤 보완 기술을 사용하고 있는가? 애플리케이션이 고유의 언어, 데이터베이스, 미들웨어 또는 컨테이너가 제대로 지원하지 못하는 다른 보완 기술을 활용하고 있다면, 컨테이너용 후보가 되기는 어렵습니다.

이 모든 것이 의미하는 것은 무엇일까요? 위에 나열한 제약사항들을 떠올려보면, 일반적인 결론은 소수의 기존 애플리케이션들이 컨테이너용으로 좋은 후보라는 것입니다. 이런 경험에 근거한 규칙에는 많은 예외가 있고, 독자들도 컨테이너용으로 훌륭한 후보가 될 수 있는 수 백 가지의 기존 애플리케이션 목록을 만들 수도 있겠지만, 이 일반적인 결론이 틀린 것은 아닙니다.

대조적으로, 컨테이너는 애플리케이션이 처음부터 새로 개발되었고, 이런 경우에는 시작부터 컨테이너를 염두에 두고 개발되었기 때문에, 컨테이너가 거의 언제나 좋은 생각입니다. 이런 행로에는 몇 가지 이유가 있습니다.

- 개발자는 컨테이너를 활용하도록 애플리케이션을 설계할 수 있습니다. 이는 데이터를 포함하여, 컨테이너에 쉽게 배치할 수 있는 핵심 구성요소의 분산을 의미합니다. 이런 새로운 접근방식은 개발자가 애플리케이션을 컨테이너용으로 최적화할 수 있으며 그렇게 해서 성공 가능성을 높일 수 있다는 것을 의미합니다.

- 이식성을 염두에 두고 신규 애플리케이션을 개발할 수 있습니다. 많은 기존 애플리케이션들은 고유 플랫폼의 API 호출을 내장하고 있다. 이는 호스트 플랫폼에 대한 호출을 하며, 이로 인해 해당 애플리케이션의 이동 능력이 제한되고 있다는 의미입니다. 개발자들은 전혀 새로운 애플리케이션에 접근할 때, 이런 유형의 제약사항을 회피할 수 있습니다.

컨테이너 통합과 데브옵스
2017년에는 컨테이너와 데브옵스가 공조할 필요가 있습니다. 데브옵스 조직과 데브옵스 자동화 시스템을 구축하고 있는 대다수 사람들은 그런 과정 중에 어떻게 하면 컨테이너화된 애플리케이션을 구축할 것인지를 고민하고 있습니다. 현실은 이렇습니다. 데브옵스 구축을 잘 해낸다면, 컨테이너들은 단지 처리해야 할 또 다른 보완 기술에 불과합니다. 그저 컨테이너가 지속적인 통합, 지속적인 시험, 지속적인 배포 등등과 어떻게 공조해야 할지만 고민하면 됩니다.

가장 관심을 가져야 할 한 가지는 컨테이너를 배포해야만 한다는 사실입니다. 어떤 경우에는 컨테이너를 컨테이너 클러스터에 배포해야만 하며, 이때는 컨테이너 관리자가 관리합니다. 상황에 따라 클러스터 관리자를 적절히 구성해서 컨테이너가 개선사항과 버그 수정사항을 포함한 업데이트를 받을 수 있도록 한다는 면에서 변경작업이 필요할 수 있습니다.

시험 역시 어려운 과제입니다. 여기에는 데브옵스의 제반 단계를 통과해서 이동하는 컨테이너의 이식성에 대한 시험이 포함됩니다. 일반적으로, 이는 플랫폼에 특정적인 API 호출에 대한 시험 (그리고 교정)을 의미합니다. 바로잡지 않을 경우에 따른 상충요인은 누구나 알고 있을 것입니다.

새로운 문제도 생겨납니다. 컨테이너 기반 애플리케이션은 특정업체 고유의 방향으로 이동한 결과 이식성이 떨어지는 애플리케이션이 나타나는 것입니다. 2017년에는 개방형 컨테이너 표준의 범위를 넘어서는 새로운 특징을 제공하는 컨테이너 공급업체들을 보게 될 것입니다. 이들 업체도 도커 등의 표준을 지원하겠지만, 대다수는 제각각 자사 고유의 특징을 제공할 것입니다. 데이터베이스 액세스에 대한 접근방식이 개선된다든지 하는 몇 가지 발전도 있겠지만, 애플리케이션을 다른 컨테이너 기술로 이식하기 위한 사용자의 능력을 제한할 수 있다는 의미도 됩니다.

이런 상충요소는 데브옵스로의 이동 여부와 관계없이, 많은 개발 회사에서 논의되는 문제입니다. 컨테이너 분야가 2017년에 열기를 더해갈수록, 업체고유의 방향으로 이동하는 더 많은 컨테이너 기술 공급업체를 보게 될 것입니다. 목표는 자사의 기술을 동일한 기반 기술을 활용하고 있는 다른 공급업체와 차별화하는 것입니이다. 엔터프라이즈 개발 조직이 이런 상충요소에 어떻게 접근하는지에 따라서 컨테이너를 활용할 때 “무엇이 최고인가 vs. 무엇이 이식 가능한가?” 같은 상이한 방향으로 엔터프라이즈를 이끌게 될 것입니다.

자사만의 경로를 찾으십시오
선택한 컨테이너가 소속 조직에 적합합니까? 바로 이것이 “컨테이너의 현황은 무엇인가?”를 넘어서 해야 할 핵심 질문입니다. 비즈니스 목표에 대한 자체 평가는 이것이 올바른 경로인지를 결정할 때 조직을 도울 것이고, 그 결과 목표에 가장 부합하는 보완 기술을 알아낼 수 있습니다. 그리고 그 답 중에 컨테이너가 포함될 수 있습니다.

2017년 컨테이너는 다음과 같은 몇 가지 핵심 비즈니스 우려사항을 해결할 수 있습니다.

- 핵심 애플리케이션과 처리를 플랫폼 간 또는 클라우드 간에서 이동시킬 가능성이 있다면, 컨테이너가 가장 촉망받고 있습니다. 고려해야 할 상충요소들도 있지만, 컨테이너는 이식성을 확실히 보장합니다. 그렇지만, 일반적으로 볼 때 이 이점은 기존이 아닌 전혀 새로운 애플리케이션에 가장 잘 작용합니다.

- 자사의 기술을 클라우드로 이동시키고 있는 ISV(Independent Software Vendor: 독립 소프트웨어 공급업체)와 다른 기술 공급업체들은 컨테이너가 타당한 옵션이라는 것을 알게 될 것입니다. 이들은 이 기술에 비즈니스의 사활을 걸 것이며, 컨테이너의 이식성과 확장성 특징 활용은 거의 언제나 훌륭한 아이디어라고 할 수 있습니다. 전혀 새로운 또는 기존 애플리케이션 중 어느 것을 고려한다 해도 올바른 결정입니다.

- 데브옵스로 이동하고 있다면, 컨테이너가 보완 기술로 훌륭한 선택일 수도 있습니다. 하지만, 대개는 전혀 새로운 애플리케이션에 가장 적합합니다. 컨테이너와 데브옵스 기술 공급업체들은 몇 년 동안 잘 공조하고 어울려 오고 있으므로, 사용자에게도 마찬가지일 것입니다. 반복해서 강조하지만, 기존 애플리케이션은 컨테이너와의 성공에서 경쟁자가 아닐 것입니다.

- 클라우드 컴퓨팅을 생각하고 있다면 언제나 컨테이너를 고려해야 합니다. AWS(Amazon Web Services), 구글 그리고 마이크로소프트를 포함한 모든 주요 클라우드 공급업체들이 컨테이너를 지원하고 있습니다. 그렇지만, 공급업체들의 지원 방식은 다릅니다. 컨테이너는 사용자가 작은 또는 아무 노력 없이 애플리케이션을 공급업체들 간에서 이동할 수 있게 해주거나, 최소한 그런 방식으로 판매가 이루어지고 있습니다. 이식성에 대해서는 잘 동작하고 있다는 소리도 들리겠지만, 잘 안되고 있는 것에 대한 지적도 등장할 것입니다.

많은 경우, 이 모든 질문에 대한 답은, “그때그때 다르다”는 것입니다. 기업의 비즈니스 목표 기존 애플리케이션, 그리고 기업이 어느 정도의 위험을 감수할 수 있는지에 따라 달라집니다.

물론, 많은 엔터프라이즈들이 컨테이너를 전적으로 무시할 수 있으며, 그렇게 함으로써, 비용을 줄일 수 있습니다. 이는 변화하고 있는 스킬 세트와 기술의 비용 조건을 고려한 것입니다. 그렇지만, 클라우드 또는 다른 새로운 플랫폼에서 필요로 하는 가치를 찾지 못했을 수 있습니다. 컨테이너는 지금 해결하거나 나중에 훨씬 더 커다란 비용으로 해결할 수 있는 시스템적인 문제를 해결 합니다.

2017년에 현실로 다가올 것이 몇 가지 있습니다. 첫째, 컨테이너 기술은 자리를 잡았으며 자신의 가치를 입증했습니다. 그렇지만, 컨테이너는 모든 면에서 모든 것에 대해서 동작하지는 않으며, 효용은 제각기 다를 것입니다. 둘째, 컨테이너의 기능과 한계에 대해 배워감에 따라 성공 사례만큼이나 실패 사례도 많을 것이라는 점입니다.

Sponsored

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

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

Copyright © 2024 International Data Group. All rights reserved.