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.
TOPIC

가상화

“데스크톱용 컨테이너가 온다” 윈도우 10X에 거는 기대

마이크로소프트가 자사의 듀얼 스크린 윈도우 10X 운영체제용으로 새로운 컨테이너를 만들어 레거시 윈도우 애플리케이션을 구동할 수 있도록 했다. 윈도우의 미래에 미치는 영향이 클 것으로 보인다.   컨테이너의 발흥지는 리눅스이지만, 마이크로소프트는 온 마음으로 컨테이너를 받아들였다. 윈도우 서버 2016을 시작으로 마이크로소프트는 윈도우 서버 컨테이너와 하이퍼-V 컨테이너 두 종류의 도커 호환 컨테이너를 제공했다. 그리고 2014년 마이크로소프트 애저의 리눅스 지원을 발표한 운명의 날 이후로 6년이 지난 지금, 개발자들은 일상적으로 윈도우 리눅스 서브시스템이나 애저 클라우드가 지원하는 리눅스 배포판에서 도커 컨테이너에 앱을 연결한다. 하지만 데스크톱용 컨테이너라면 어떨까? 이는 윈도우가 데스크톱 애플리케이션을 통제하는 방법을 완전히 바꿔 놓을 것이며, 윈도우 앱을 모바일 앱만큼이나 쉽고 빠르게 설치할 수 있다. 실제로 이런 컨테이너가 윈도우 10X라는 독특한 운영체제용으로 개발되고 있는데, 오는 가을 신형 서피스와 함께 출시될 예정이다. 2019년 10월 발표된 윈도우 10X는 마이크로소프트 서피스 네오(Surface Neo)용으로 개발된 것으로, 서피스 네오는 태블릿 크기의 화면 두 개가 양옆으로 열리는 그림책 같은 디바이스이다. 네오의 동생격인 서피스 듀오(Surface Duo)는 윈도우 10X 대신 개조한 안드로이드 운영체제를 구동한다. (전화 기능도 포함되어 있지만, 마이크로소프트는 한사코 휴대폰이라고 부르기를 거부한다.) 게다가 지난 달 열린 365 개발자의 날 행사에서 마이크로소프트는 자사의 Xamarin.Forms용 듀얼 스크린 SDK를 두 디바이스 모두와 호환되는 앱 개발에 사용할 수 있다고 발표했다. 그렇다면 컨테이너는 어디에 사용될까? 우선 이 컨테이너는 도커 컨테이너가 아니다. 마이크로소프트는 개발자를 과거와 완전히 단절된 새로운 세계로 끌어들이려 했던 UWP((Universal Windows Platform)의 실패에서 많...

데스크톱 컨테이너 듀얼스크린 2020.03.10

IDG 블로그 | 컨테이너 기반 클라우드 개발의 “스테이트”

대부분 애플리케이션은 스테이트풀(Stateful) 애플리케이션이다. 여기서 ‘스테이트풀’이란 말은 사용자가 영화를 보다가 말고 다른 디바이스로 바꿔도 스트리밍 서비스에서 그 부분을 기억한다는 것을 의미한다. 모바일 앱이 사용자의 속성이나 최근에 열었던 파일을 저장하는 것도 마찬가지다. 애플리케이션 수준에서는 중단된 세션을 복구하는 역량을 의미한다. 데이터 손실 없이 사용자를 원래 위치로 데려다주는 것이다.   기존의 세상은 스테이트풀의 세상이다. 스테이트풀 애플리케이션은 ‘스테이트(State, 상태)’를 기억하는데, 이 스테이트는 여러 세션에 걸쳐서 지속성을 갖는다. 그래서 스테이트 데이터는 데이터베이스를 포함하는 물리 스토리지처럼 휘발성 없는 방식으로 저장한다. 그런데 컨테이너는 이 스테이트 유지에 관한 새로운 도전과 기회를 불러왔다. 컨테이너 세상은 ‘스테이트리스(Stateless)’로 알려져 있다. 컨테이너 설계의 기본 개념은 컨테이너가 인스턴스로 등장해서 프로그래밍된 대로 작업을 하고 스테이트를 유지하지 않고 사라지는 것이다. 필요할 때는 일부 외부 소스로부터 데이터를 가져와 작업할 수도 있는데, 데이터는 다른 프로세스나 서비스로부터 넘겨받고 작업이 끝난 후에는 데이터가 메모리에서 삭제되기 전에 다른 프로세스로 돌려준다. 여전히 스테이트는 유지하지 않는다. 핵심 문제는 컨테이너가 스테이트 정보를 저장할 수 없다는 것이다. 컨테이너는 원래 그렇게 만들어졌다. 영구 스토리지 개념이 없으니 스테이트를 유지하는 것은 불가능하다. 이 때문에 초기에 컨테이너는 스테이트 유지가 필요없는 워크로드 전용으로 알려졌다.. 일각에서는 여전히 컨테이너 기반 애플리케이션을 구축할 때는 ‘스테이트리스’라야 한다고 주장한다. 가장 깔끔한 접근법일 뿐만 아니라 스테이트풀 애플리케이션은 구시대 모델이라는 생각이다.  하지만 컨테이너를 사용하는 기업 개발자 대부분은 동의하지 않는다. 전통적인 애플리케이션은 컨테이너에 맞춰 설계하고 구축하지 않기 때문이다....

state 컨테이너 스테이트풀 2020.03.09

VM웨어, 2020년 회계연도 총 매출 108억 1,000만 달러 기록

VM웨어가 2020년 회계연도 연간 실적 및 4분기 실적을 발표했다.   VM웨어의 2020년 회계연도 총 매출은 108억 1,000만 달러로 지난해에 비해 12% 증가했다. 영업 이익은 14억 4,000만 달러로 전년 대비 20% 감소했다. 이 가운데 구독형 및 SaaS 매출은 44% 증가한 18억 8,000만 달러를 기록했다. 또 VM웨어의 2020년 회계연도 4분기 매출은 30억 7,000만 달러로 2019년 회계연도 4분기 대비 11% 증가했다. VM웨어 팻 겔싱어 CEO는 “VM웨어는 두 자리 수의 견고한 성장을 지속하며 2020년 회계 연도에 처음으로 100억 달러 이상의 매출을 기록했다”며, “이번 결과는 광범위한 포트폴리오와 함께 긴밀하게 고객을 지원하는 VM웨어의 전략이 유효했다는 것을 보여준다”라고 말했다. VM웨어 제인 로위 수석 부사장 겸 최고 재무 책임자는 “VM웨어가 2020년 회계연도 4분기동안 매출 1,000만 달러 이상의 기념비적인 엔터프라이즈 계약을 수주했으며, 이 가운데 상위 10개 계약에서 구독형 및 SaaS 오퍼링 부문 가치가 크게 증가했다”며, “2020년 회계연도 4분기 구독형 및 SaaS 매출이 지난해에 비해 52% 증가했으며 이 부문은 2021년 회계연도에도 성장을 지속할 것”이라고 밝혔다. editor@itworld.co.kr

VM웨어 2020.02.28

IDG 블로그 | 컨테이너가 정말로 좋은 선택일까?

451 리서치의 최신 보고서에 따르면, 애플리케이션 컨테이너 시장은 2016년 7억 6,200만 달러 규모에서 2020년에는 27억 달러 규모로 성장한다. 전체 클라우드 기술 시장에서는 작은 비중에 불과하지만, 애플리케이션 컨테이너는 2020년 40%의 높은 성장률을 기록할 것이다.   이런 성장에는 과대 포장과 실질적인 수요, 그리고 선도업체에서 이룬 약간의 성공이 뒤섞여 있다. 클라우드 컴퓨팅 기술 스택에는 컨테이너가 유효한 곳이 많다. 다시 말해, 컨테이너는 애플리케이션을 클라우드로 옮기거나 클라우드에서 완전히 새로운 애플리케이션을 구축할 때 직면하는 핵심 문제를 해결한다. 바로 이식성과 확장성, 개방성, 일관성이다. 하지만 컨테이너가 모든 문제의 해법은 아니다. 컨테이너와 컨테이너 오케스트레이션(쿠버네티스)의 가장 큰 문제는 이 기술을 잘못 적용하는 것이다. 세 가지 문제를 살펴보자. 1. 애플리케이션 아키텍처가 핵심이다. 컨테이너에 코드를 넣고 실행하는 것은 어렵지 않다. 하지만 컨테이너는 애플리케이션 아키텍처가 컨테이너를 염두에 두고 설계되었거나 컨테이너에 맞춰 변경되었을 때 가장 잘 동작한다. 컨테이너는 본질적으로 분산 처리 지향적이다. 최적의 방식으로 컨테이너를 사용하기 위해서는 보통 애플리케이션을 변경하거나 분해할 수 있어야 한다. 게다가 애플리케이션이 데이터와 긴밀하게 묶여 있다면, 애플리케이션에서 데이터를 분리하지 않는 한 컨테이너로 성공하기 어렵다. 2. 컨테이너는 전통적인 애플리케이션 개발보다 비용이 더 많이 든다. 컨테이너 기술을 활용하기 위해 필요한 애플리케이션의 변경은 이른바 “컨테이너세(Container Tax)”의 일부이다. 애플리케이션을 컨테이너에 맞춰 수정하거나 컨테이너 지향적인 새 애플리케이션을 구축하는 데 드는 추가 비용이다. 정확한 숫자를 계산하기는 어렵지만, 필자의 경험상 평균 35%는 더 든다. 물론 35%의 추가 비용은 컨테이너를 통해 얻는 이식성과 확장성, 민첩성으로 보상된다. 기업마다 환경...

확장성 컨테이너 오케스트레이션 2020.02.26

“FaaS를 넘어 엣지로” 차세대 엣지 서버리스 아키텍처의 현황과 전망

서버리스 서비스는 어디에나 있다. 새로운 프로그래밍 방식을 향한 진화의 원동력인 서버리스 환경은 애플리케이션 호스팅 플랫폼, 서버리스 데이터베이스, CDN(Contents Delivery Network), 보안 솔루션 등등 모든 형태로 구현되고 있다. 인프라 수준의 환경 구성, 확장 및 프로비저닝에 대한 우려는 사라졌으며, 분산만이 마지막 문제로 남아 있다. 이 문제의 해결책으로 등장한 것이 바로 엣지 서버리스(Edge Serverless)로, 데이터와 컴퓨트를 수많은 데이터센터에 걸쳐 분산 배포한다. 엣지 서버리스는 컴퓨팅을 사용자와 더 가까운 곳으로 가져와 지연시간을 줄일 수 있다.   엣지 서버리스는 거의 15년 전에 IaaS(Infrastructure-as-a-Service)로 시작된 클라우드 아키텍처 진화의 정점이다. 클라우드 진화의 다음 단계는 서버리스 ‘빌딩 블록’의 분산을 촉진하고 개발자가 더 쉽게 소비할 수 있도록 하는 것이다. 서버리스 아키텍처는 현재 어디에 있는지, 어디로 향하는지 좀 더 자세히 살펴보자.    계층화 아키텍처 IaaS(Infrastructure as a Service) 클라우드 컴퓨팅 혁명은 IaaS의 등장으로 본격화되었다. IaaS를 통해 기업은 로컬 인프라를 호스팅된 ‘클라우드’ 인프라로 옮겨 운영할 수 있다. 사용한 스토리지와 컴퓨팅 시간에 대해서만 비용을 지불하며, 어떠한 하드웨어나 네트워크도 설치하거나 관리할 필요가 없다. 처음에는 IaaS가 비싸 보였지만, 일반 기업은 구현할 수 없는 수준의 가용성을 보장했기 때문에 빠르게 확산됐다. 실제로 자체적으로 인프라를 구매하고 유지하는 비용이 IaaS 서비스 요금보다 비싼 경우가 많았다. 가장 큰 장점은 하드웨어 유지보수와 프로비저닝이 필요없기 때문에 개발자가 비즈니스 가치에만 집중할 수 있다는 것이다. PaaS(Platform as a Service) 그 후 서비스 업체는 클라우드 컴퓨팅을 한 단계 더 발전시켜 PaaS를 제공했다....

CDN 아키텍처 엣지 2020.02.18

쿠버네티스와 도커를 백업하는 방법

컨테이너 인프라에도 일종의 백업이 필요하다. 재해가 발생한 후 쿠버네티스와 도커가 스스로 재건되지는 않기 때문이다. 각 컨테이너의 실행 상태를 백업할 필요는 없지만 컨테이너를 실행하고 관리하는 데 사용되는 구성은 백업해야 한다. 백업해야 할 요소를 간단히 요약해 보자.   구성과 원하는 상태 정보 이미지를 만드는 데 사용되는 도커파일(Dockerfile)과 이 파일의 모든 버전 도커파일에서 생성되어 각 컨테이너를 실행하는 데 사용되는 이미지 쿠버네티스 etcd 및 기타 : 클러스터 상태에 대한 정보를 저장하는 K8s 데이터베이스 배치 : 각 배치를 설명하는 YAML 파일 컨테이너에 의해 생성 또는 변경되는 영구 데이터 영구 볼륨 데이터베이스   도커파일 도커 컨테이너는 이미지에서 실행되며, 이미지는 도커파일에서 작성된다. 적절한 도커 구성이라면 일반적으로 깃허브와 같은 리포지토리를 모든 도커파일의 버전 제어 시스템으로 사용한다. 애드혹 도커파일로 만든 애드혹 이미지를 사용해서 애드혹 컨테이너를 만들어서는 안 된다. 모든 도커파일은 현재 빌드에서 문제 발생 시 과거 버전을 가져올 수 있는 기능을 제공하는 리포지토리에 저장해야 한다. 또한 각 K8s 배치와 연결된 YAML 파일을 저장할 리포지토리도 필요하다. 이와 같은 YAML 파일은 버전 제어 시스템을 활용할 수 있는 텍스트 파일이다. 백업해야 할 대상은 이 리포지토리다. 가장 많이 사용되는 리포지토리 중 하나는 깃허브다. 깃허브는 리포지토리를 백업할 수 있는 여러 가지 방법을 제공한다. 제공된 API를 사용해서 리포지토리의 현재 백업을 다운로드하는 다양한 스크립트가 있고, 깃허브나 기타 사용 중인 리포지토리를 백업하기 위한 별도의 상용 툴도 있다. 이런 권장사항과 달리 도커파일이 더 이상 없는 이미지를 기반으로 컨테이너를 실행 중이라면, docker image history 명령, 또는 dfimage와 같은 툴을 사용해서 현재 이미지에서 도커파일을 만들 수 ...

백업 컨테이너 도커 2020.01.20

넷앱, 2020년 IT 시장 전망...“단순성 및 최적화가 핵심 키워드”

넷앱이 2020년 IT 시장 전망을 발표했다.  지난 2019년은 IT 업계와 다양한 비즈니스 사회에서도 빠른 혁신과 변화의 해였다. 하이브리드 멀티 클라우드가 엔터프라이즈 환경의 실질적인 표준 아키텍처로 자리매김하면서 광범위하게 도입되고 있는 가운데 대부분의 조직들은 인프라 현대화와 데이터 집약적인 애플리케이션 및 워크로드로 실질적인 비즈니스 가치를 창출해야 하는 어려움에 직면해 있다. 따라서 조직들은 온프레미스에서 퍼블릭 클라우드 서비스로 전환하고, 프라이빗 클라우드를 구축하며, 데이터센터의 디스크에서 플래시로 이동하는 등 이 모든 인프라 아키텍처 변경을 동시에 진행하기도 한다. 이러한 변화는 무한한 가능성이 있지만, 점점 증가하는 IT 복잡성이라는 의도하지 않은 결과를 가져오기도 한다. 2020년은 IT 구매 의사를 결정하는데 있어, 단순성(Simplicity)과 최적화(Customizable)에 대한 요구가 가장 중요한 요소일 것으로 예측한다. 벤더들은 고객에게 현대적이고 유연한 기술을 제공해, 고객들이 진화하는 비즈니스 모델의 요구사항에 맞게 대응할 수 있는지 다양한 기술 선택지를 제공하게 될 것이다. IT 부서는 유지보수와 하드웨어 등에서 발생하는 간접비용을 줄이기 위한 방법으로, 종량 과금 방식과 단순성이 투자 의사 결정에 있어 중요한 요소가 될 전망이다. 5G 기술, “AI 기반의 IoT 현실화 등 혁신 이끌어” 5G 기술의 출현으로 AI 기반의 IoT가 현실화되면서, 엣지 컴퓨팅 환경은 클라우드 기술의 출현보다 더 큰 혁신을 이끌어 낼 것이라고 업체 측은 설명했다.  5G 기술 보편화에 대비하기 위한 저비용 센서와 성숙된 AI 애플리케이션의 기술 고도화는 컴퓨트 집약적인 엣지 환경 구축을 위해 활용될 것이다. 급격한 변화와 혁신을 이끌어 낼 AI 기반의 IoT 환경을 대응하고자 고대역폭과 낮은 응답속도를 위한 IT 환경에 대한 준비가 진행될 것이다. 5G 기술은 AI 기반 IoT 환경을 위한 필수 기술 요소다. 20...

넷앱 2020.01.17

글로벌 칼럼 | 컨테이너, 백업이 필요한가

컨테이너(Containers) 백업이 항상 필요한 것은 아니지만, 값 비싼 손실을 막기 위해 도커(Docker)와 기타 컨테이너를 백업해야 하는 상황이 있다.    컨테이너가 곳곳에서 백업 관행을 깨고 있지만 데이터센터에 일어날 수 있는 최악의 상황으로부터 컨테이너 인프라의 가장 중요한 부분을 보호하기 위해 활용할 수 있는 방법이 있다.  컨테이너는 백업할 필요가 없을 것 같지만, 자세히 살펴보면 재해급 사태는 물론 이보다 덜한 여러 사고에 대비해 보호하기 위해 컨테이너도 백업하는 것이 좋다. 컨테이너의 기본 컨테이너는 가상화의 한 유형이며, 이 가운데 도커는 가장 인기 있는 컨테이너 플랫폼이다. 컨테이너는 특정 애플리케이션을 실행할 수 있는 특수한 환경이다. 가벼운 가상 머신이라고 표현할 수도 있다.  하이퍼바이저 서버의 각 VM에는 운영체제의 전체 사본이 포함되는 반면, 컨테이너는 기반 운영체제를 공유하며 각 컨테이너에는 해당 컨테이너에서 실행되는 애플리케이션에 필요한 라이브러리만 포함된다. 그 결과 단일 노드(OS와 컨테이너 런타임 환경을 실행하는 물리적 또는 가상 머신)에서 컨테이너가 점유하는 리소스는 같은 수의 VM에 비해 훨씬 적다. VM과 컨테이너의 또 다른 차이점은 기업에서는 보통 하나의 VM에 다수의 애플리케이션을 동시에 실행하는 경향이 있는 반면, 컨테이너는 일반적으로 로깅, 모니터링과 같은 하나의 작업을 수행하는 하나의 애플리케이션 구성요소를 제공하도록 설계된다는 점이다.  여러 애플리케이션 구성요소가 상호작용해야 하는 경우 각 구성요소는 일반적으로 자체 컨테이너에서 실행되면서 네트워크를 통해 통신한다. 이로써 각 애플리케이션을 개별적으로 확장하고 애플리케이션 간의 결함 및 보안 격리도 가능하다. VM은 특정 하드웨어에서 실행되는 특정 하이퍼바이저 내에서 실행되지만 컨테이너는 훨씬 더 이식성이 높다. 컨테이너는 사실상 모든 리눅스 시스템에서 실행되며 적절한 소프트웨어만 설치하면 윈도...

백업 컨테이너 쿠버네티스 2020.01.07

컨테이너화된 애플리케이션을 위한 효과적인 백업의 조건

점점 더 많은 기업이 애플리케이션의 컨테이너화를 받아들이면서 효과적인 백업 시스템의 필요성이 중요해졌다. 컨테이너는 다른 배치 모델과는 차별화되는 독보적인 특성을 가지고 있기 때문에 올바른 백업 아키텍처를 적용하지 않으면, 심각한 시스템 정지와 데이터 손실의 위험에 처할 수 있다.   IDC는 76%의 기업이 미션 크리티컬 애플리케이션에 폭넓게 컨테이너 기술을 사용하고 있으며, 개선된 보안과 운영 관리가 이런 변화의 핵심 동력이라고 밝혔다. 포트웍스의 자체 설문조사에서도 87%의 기업이 컨테이너를 사용하고, 이 중 90%가 프로덕션 환경에 컨테이너를 사용한다고 답했다. 오늘날 백업은 흔히 가상머신 수준에서 구현된다. 이 방식은 애플리케이션이 단일 가상머신에서 구동될 때는 좋다. 하지만 컨테이너화된 애플리케이션은 흔히 여러 대의 가상머신에 분산되어 있다. 반대로 단일 가상머신은 종종 여러 가지 서로 다른 애플리케이션과 관련된 컨테이너 팟을 구동한다. 이런 환경에서 현재의 가상머신 수준보다는 좀 더 정확하게 대상을 지정해야 할 필요가 있다. 간단히 말해 기업은 쿠버네티스로 구현된 자동화되고 고도로 분산된 애플리케이션 모델을 지원하는 백업 아키텍처가 필요하다. 이를 염두에 두고 컨테이너화된 애플리케이션을 위한 효과적인 백업 솔루션을 구축하는 4가지 핵심 조건을 살펴본다.   1. 컨테이너 단위의 세밀한 접근 가상머신이나 베어메탈 서버에서 구동되는 모든 것을 백업하는 것이 아니라 특정 컨테이너나 특정 노드에서 구동하는 컨테이너 그룹을 백업할 수 있는 기능이 필요하다. 이는 백업해야 하는 애플리케이션만을 선택할 수 있는 기능을 의미하는데, 같은 노드에 다른 애플리케이션이 있거나 애플리케이션이 여러 노드에 분산되어 있어도 가려낼 수 있어야 한다. 컨테이너 수준에서 백업을 하면, IT 부서는 까다로운 ETL 프로시저를 피할 수 있다. 특정 애플리케이션만을 백업하는 것은 또한 스토리지 비용을 최소화하고 RTO도 낮게 유지할 수 있다.  &...

복구 백업 컨테이너 2019.12.20

암페어, 클라우드용 80코어 ARM 프로세서 발표…단일 쓰레드로 ‘시끄러운 이웃’ 문제 해결

암페어 컴퓨팅(Ampere Computing)이 내년 중반 출시할 차세대 프로세서는 80코어 ARM 프로세서이다. 전임 인텔 사장 르네 제임스가 설립한 스타트업 암페어는 ARM 기반의 서버용 프로세서를 설계한다. 암페어가 지난 해 출시한 32코어 프로세서보다 훨씬 많은 코어를 탑재한다.    암페어 프로세서의 특징 중 하나는 멀티쓰레드 기술을 사용하지 않는다는 것이다. x86 칩과 같은 CPU 취약점을 방지하는 것은 물론, 클라우드 환경에서 이른바 ‘시끄러운 이웃’ 문제를 방지하기 위해서이다. CPU에 많은 코어와 쓰레드가 탑재되면서 AWS와 같은 퍼블릭 클라우드 서비스 사용자는 별도의 서비스를 이용하기 전에는 CPU 전체를 이용할 수 없다. 누군가 CPU 사이클을 공유하는 인스턴스에서 다른 사용자의 애플리케이션이 CPU의 L1 캐시를 많이 사용한다면, 성능에 영향을 받을 수도 있다. 암페어의 제품 담당 부사장 제프 위티치는 “단일 쓰레드의 멀티코어 CPU로 설계해 가능한 한 격리성을 제공하고자 한다”며, “의도적으로 단일 쓰레드로 만들었기 때문에 쓰레드 간에 L1 캐시나 레지스터를 공유하지 않는다”고 설명했다. 암페어는 특히 클라우드 서비스 업체와 하이퍼스케일 데이터센터 운영업체를 노리는데, 구글이나 아마존은 물론 2계층 클라우드 서비스 업체와 트위터와 우버 등이 주요 대상이다. 대상 고객의 수가 많지는 않지만, 매 분기 수천, 수만 대의 서버를 구매한다. 위티치는 “클라우드를 대상으로 하는 제품이라는 점에서 전혀 다른 접근법을 취하고 있다. 하이퍼스케일 환경에서 배치하는 서비스와 인프라는 x86이 처음 데이터센터에 배치될 때와는 완전히 다르다. 지금 중ㄷ요한 것은 멀티테넌트, QoS, 격리, 관리성 등이다”라고 강조했다. 또한 하이퍼스케일 데이터센터는 지난 10년 동안 전체 소프트웨어 환경을 최적화했지만, CPU는 최적화하지 못했다고 덧붙였다. 새로 출시할 80코어 프로세서에 대해 위티치는 각각의 코어가 이전 세대보다 더 높은 ...

멀티테넌트 멀티쓰레드 arm 2019.12.04

이벤트 중심 워크로드를 위한 쿠버네티스 자동 확장

쿠버네티스는 다양한 형태로 사용할 수 있는, 분산 시스템 구축을 위한 강력한 툴이다. 다만 한 가지 큰 문제는 설계상 쿠버네티스는 리소스 기반 확장만 제공한다는 점이다. 사실 쿠버네티스의 역사를 보면(AWS에 대응하기 위한 구글 내부의 보그(Borg) 서비스에서 시작됨) 이해하지 못할 것도 없다. 쿠버네티스가 목표로 한 애플리케이션과 서비스의 대부분은 리소스에 얽매이고 대량의 데이터를 다루며 메모리와 CPU에 의존했기 때문이다.   분산 애플리케이션이라고 해서 모두 그렇지는 않다. 많은 애플리케이션, 특히 IoT 시스템과 연동하는 애플리케이션은 이벤트에 신속하게 대응해야 한다. 여기서 가장 중요한 요소는 수요에 따라 프로세스를 트리거하는 이벤트와 메시지를 제공하는 I/O다. 이른바 서버리스 컴퓨팅과 잘 맞는 모델이다. 서버리스 모델의 대부분은 수요에 따라 새로운 컴퓨팅 컨테이너를 신속하게 가동하는 데 의존하는데, 이 모델은 자체 컨트롤러가 있는 전용 가상 인프라에서 잘 작동하지만 쿠버네티스의 리소스 중심 확장과의 호환성은 그다지 좋지 않다.   KEDA: 쿠버네티스 기반 이벤트 중심 자동 확장 마이크로소프트와 레드햇은 쿠버네티스에 이벤트 중심 확장성을 추가할 방법을 개발하기 위해 협력해왔고, 그 결과로 2019년 5월 마이크로소프트 빌드(Build) 컨퍼런스에서 오픈소스 KEDA 프로젝트를 발표했다. 이 초기 KEDA 코드는 나온 직후부터 많은 관심을 끌었는데, 최근에는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 채택을 목적으로 하는 1.0 버전이 공개됐다. KEDA는 아무 쿠버네티스 클러스터에서나 실행할 수 있으며, 확장을 이끄는 데 사용할 수 있는 새로운 메트릭스 집합을 지원한다. 이제 CPU와 메모리의 부하에만 대응하지 않고 이벤트의 수신 속도에도 대응할 수 있고, 덕분에 큐 지연과 이벤트 데이터 손실 위험이 줄어든다. 메시지 볼륨과 CPU 수요는 직접적으로 연결되지 않으므로 KE...

컨테이너 쿠버네티스 서버리스컴퓨팅 2019.11.29

“현실과 만난 쿠버네티스” 블룸버그, 뉴스 UK, 아마데우스 사례 연구

쿠버네티스(Kubernetes)는 5년 전 구글이 발표한 이후 빠른 속도로 2010년대의 가장 인기 있는 기술 중 하나로 부상했다. 현재 쿠버네티스는 마이크로서비스(컨테이너에서 실행되며, 여러 컨테이너가 모여 다양한 유형의 인프라에 이식할 수 있는 더 큰 큰 애플리케이션 역할을 할 수 있는, 독립적으로 배포 가능한 작은 서비스)로 구성된 애플리케이션을 제작하고 실행하는 데 있어 이론의 여지가 없는 선두 플랫폼이다.   쿠버네티스는 오케스트레이션 툴이다. 즉, 개발자가 탄력적인 분산 시스템 운영을 목표로 컨테이너 기반의 워크로드와 서비스를 조율하고 관리할 수 있게 해준다. 클라우드 네이티브 컴퓨팅 재단(CNCF)이 2018년 8월에 발표한 설문 조사에서 기업(5,000개 이상) 응답자 중 40%는 이미 프로덕션에서 쿠버네티스를 운용 중이다. 상당한 진척이지만, 중요한 점은 이러한 조직의 대다수가 극소수 애플리케이션만 쿠버네티스로 실행하면서 가능성을 탐색 중이라는 사실이다. 그러나 방향은 확실하다. 미래는 컨테이너 기반 마이크로서비스 애플리케이션을 향하고 있으며, 쿠버네티스는 그 중심의 플랫폼이다. 이것이 3대 클라우드 업체가 모두 쿠버네티스의 매니지드 버전을 출시하고 시스코, HPE, IBM/레드햇, 마이크로소프트, VM웨어/피보탈을 비롯한 여타 업체가 쿠버네티스를 각자의 핵심 소프트웨어 제품군에 수용한 이유다. 쿠버네티스는 규모와 관계없이 기업에서 개발자의 작업 속도를 개선하고 애플리케이션을 민첩하게 배포 및 확장하고 기술 스택을 현대화할 수 있게 해준다. 예를 들어 2000년부터 영국의 각 가정에 신선 식품을 배송해 온 온라인 소매업체 오카도(Ocado)는 물류와 창고를 관리하기 위해 자체적인 기술 플랫폼을 구축했다. 오카도는 2017년 도커 컨테이너를 쿠버네티스로 마이그레이션하기로 결정하고, 같은 해 여름에 첫 애플리케이션을 자체 프라이빗 클라우드의 프로덕션 환경에 투입했다. 오카도를 비롯한 기업이 쿠버네티스로 전환함으로써 얻는 대표적인 ...

사례 컨테이너 오케스트레이션 2019.11.28

IDG 블로그 | ‘올 컨테이너’는 나태한 클라우드 아키텍처

그랜드 뷰 리서치에 따르면, “전 세계 애플리케이션 컨테이너 시장 규모는 2018년 15억 달러이며, 2019년에서 2025년까지 연평균 26.5% 성장할 것으로 예상된다.” 다른 리서치 회사의 전망 역시 크게 다르지 않다.   굳이 애널리스트의 보고서를 볼 필요도 없다. 기업이 클라우드 기반 플랫폼으로 빠르게 이전하면서 요즘 필자가 참여하는 거의 모든 프로젝트가 컨테이너를 핵심 요소로 두고 있다. 이런 경향을 탓할 수는 없다. 이식성, 확장성, 더 나은 멀티클라우드 지원이 쿠버네티스 같은 컨테이너 기반 구현 기술에 내장되어 있기 때문이다. 하지만 필자가 이전에도 지적했듯이 컨테이너로 이전하는 데는 추가 비용이 든다. 컨테이너가 모든 애플리케이션과 데이터 워크로드에 맞는 것은 아니다. 특히 애플리케이션을 컨테이너화하고 제대로 운영하기에 충분한 인력을 확보하는 데 어려움을 겪을 것이다. 아직은 좋은 컨테이너 개발자와 설계자가 충분하지 않기 때문이다. 문제는 기술을 선택할 때 책이나 미디어에서 본 내용을 쫓아 성급하게 결정하는 경향이 있다는 것. 핵심적인 비즈니스 요구사항을 건너뛰고 컨테이너니 서버리스니 머신러닝이니 하는 유행 기술을 바로 도입하는 것이다. 실제로 IT는 주류를 벗어나서 존재하는 솔루션에 대해서는 근시안적이다. 컨테이너는 많은 워크로드에 잘 맞지만, 모든 워크로드에 맞는 것은 아니다. 애플리케이션을 컨테이너로 동작하도록 수정하는 비용이 많이 든다면, 해당 워크로드는 경제적인 관점에서 실행 가능한 선택이 아니다. 최근 IT 영역에서 컨테이너는 상당한 추동력을 얻고 있다. 그만큼 컨테이너 기반 기술을 잘못 적용할 가능성도 크다. 객관적으로 볼 때, 애플리케이션의 30% 이상을 컨테이너로 이식해야 하거나 새로 개발해야 한다면, 컨테이너와 맞지 않는 것이다. 애플리케이션의 기능을 개선하고 가치를 높이기 위해서 모든 새로운 기회를 객관적으로 봐야 한다. 새로운 기술을 이해하는 데서 핵심은 정말로 필요한지 여부이다. 목적과 보안, 거버넌...

아키텍처 마이그레이션 컨테이너 2019.11.18

"리눅스·컨테이너·쿠버네티스는 차세대 IT 표준" IBM CEO 지니 로메티

점점 더 많은 기업이 미션 크리티컬 워크로드를 클라우드로 전환하는 데 주력하고 있다.  IBM의 CEO 지니 로메티에 따르면, 기업의 디지털 혁신 노력이 새로운 장을 맞이함에 따라 리눅스, 컨테이너, 오픈소스 쿠버네티스 오케스트레이션 플랫폼의 조합이 차세대 IT 표준으로 부상했다.    로메티는 시드니에서 IBM의 클라우드 이노베이션 익스체인지(Cloud Innovation Exchange) 행사에서 ‘기업의 혁신 노력 1장’에서 기업이 워크로드의 1/5 정도를 클라우드로 이전하는 것을 목격했다고 밝혔다.  대부분 경우, 이는 ‘비교적 쉽게 클라우드로 이전할 수 있는 워크로드’거나 ‘새로운 워크로드’였다. IBM CEO 로메티는 “기업이 점점 더 많은 미션 크리티컬 워크로드를 클라우드 플랫폼으로 마이그레이션하는 데 중점을 둘 것”이라고 말했다. IBM 기업 가치 연구소(Business Institute for Business Value)가 발표한 2018년 연구에 따르면, 3/4 이상의 대기업 IT부서가 2~15개의 클라우드 환경을 관리하고 있지만 소수의 사용자만이 멀티 클라우드 환경을 관리하기 위한 멀티 클라우드 관리 전략이나 툴을 보유하고 있었다. 로메티는 “이제 5~15개의 퍼블릭 클라우드를 관리해야 한다. 기업에는 일부 전통적인 업무를 담당하는 프라이빗 클라우드가 많다. 그리고 전통적인 업무를 어디에서 처리하든 거기에는 데이터가 있다”라며 "바로 그러한 이유로 개방형 플랫폼이 필요해질 것"이라고 이야기했다.  로미티는 “이 다음 시대를 위한 플랫폼에서 이미 의사 결정은 이루어졌다”라고 말했다. 사실상 표준으로 리눅스, 컨테이너, 쿠버네티스가 부상했으며, IBM이 미화 330억 달러로 레드햇을 인수한 일은 바로 이러한 동향을 보여주는 사건이었다. “레드햇은 오픈소스의 리더지만 오픈소스 표준과 오픈소스 프로젝트의 리더기도 하다”라고 IBM CEO는 강조했다. 로메티는 “이 플랫폼 기술이 기업의 1...

레드햇 리눅스 표준 2019.11.15

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

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

Copyright © 2022 International Data Group. All rights reserved.