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

가상화ㆍ컨테이너

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 블로그 | 클라우드 네이티브에 전부를 걸어야 하는가

클라우드 네이티브(Cloud Native) 데이터베이스, 클라우드 네이티브 보안, 클라우드 네이티브 거버넌스, 클라우드 네이티브 스토리지, 클라우드 네이티브 AI 등등 클라우드 서비스 업체가 제공하는 모든 것이 클라우드 네이티브이다. 필자는 클라우드 네이티브 애플리케이션을 이렇게 정의한다. “호스팅되는 퍼블릭 클라우드에 내재적인 시스템을 이용하는 애플리케이션”   일반적인 권고는 “클라우드 네이티브는 좋고, 네이티브가 아닌 리프트 앤 시프트는 나쁘다”이다. 물론 맞는 말이다. 네이티브 서비스를 이용함으로써 네이티브 프로비저닝 시스템과 네이티브 관리 및 모니터링은 물론 네이티브 디렉토리 서비스를 사용하는 네이티브 보안을 포함한 핵심 시스템의 이점을 누릴 수 있다. 네이티브가 아닌 애플리케이션을 퍼블릭 클라우드에서 사용하는 것은 슈퍼카를 비포장도로에서 모는 것과 같은 일이다. 요즘은 이 네이티브 서비스 개념을 새로운 플랫폼인 컨테이너 오케스트레이션, 즉 쿠버네티스에 적용하고 있다. 쿠버네티스는 크고 쓸만한 네이티브 시스템의 생태계로, 데이터베이스, 스토리지, 보안, 거버넌스, 데브옵스 등 많은 것을 담고 있다. 이와 관련해 두 가지 학설이 있다. 첫째, 네이티브는 옳다. 이들 툴은 더 나은 성능을 제공할 가능성이 크다. 쿠버네티스 네이티브 스토리지 시스템은 수천 노드와 분당 수천 건의 동시 운영 환경으로 확장할 수 있다. 이는 ‘내재적’이라는 특성 덕분으로, 네이티브 인터페이스를 사용하는 네이티브 쿠버네티스 애플리케이션에서 사용하기 때문이다. 그런데 바깥 세상으로 나가서 데이터베이스나 스토리지, 보안 등을 다루는 비 네이티브 시스템과 동작하면, 커뮤니케이션 번역만으로도 상당한 지연이 발생한다. 이런 생각 때문에 쿠버네티스 네이티브가 항상 더 낫고, 보통은 더 선호된다. 두 번째 학설은 네이티브에 ‘올인’함으로써 너무 많은 복잡성이 더해진다는 것이다. 이점이 없는 것은 아니지만, 쿠버네티스 네이티브 시스템으로 이전하는 것은 최소한 두 가지를 의...

복잡성 컨테이너 오케스트레이션 2019.11.04

'쿠버네티스, 도커, 컨테이너, 오케스트레이션'의 의미와 차이점

소프트웨어 개발의 최신 동향을 관심 있게 지켜본 사람이라면 틀림없이 여러 번 접했을 두 가지 용어가 있다. 바로 도커(Docker)와 쿠버네티스(Kubernetes)다. 도커와 쿠버네티스는 사실상 ‘컨테이너(container)’와 ‘오케스트레이션(orchestration)’의 약칭이다.   도커 컨테이너는 개발과 테스트를 거쳐 생산 단계로의 애플리케이션 이동 과정을 단순화했다. 반면, 도커와 쿠버네티스는 둘 다 애플리케이션의 구축 및 배치 방식을 새롭게 바꿨다. 즉, 하나의 스택이 아닌 마이크로서비스들의 모음 방식인 것이다. 도커와 쿠버네티스가 중요한 이유는 무엇인가? 도커와 쿠버네티스는 소프트웨어 개발을 어떻게 바꾸고 있나? 그 과정에서 각자 어떤 역할을 하나? 이 질문들에 대해 다음과 같이 답변해 보고자 한다. 도커와 컨테이너 컨테이너는 리눅스, 윈도우 등 최신 운영체제에서 지원된다. 운영체제와 격리되어 있으며 자체 완비된 초소형 환경에서 소프트웨어가 실행되게 하는 것이 컨테이너이다. VM에 비유되곤 했으나 VM은 아니다. VM에 비해 훨씬 군살이 적고 시작과 중단 속도가 빠르며 유연성과 이동성 역시 훨씬 뛰어나다. 불과 몇 초 안에 스핀 업과 다운은 물론 확장이 가능하기 때문에 클라우드와 같은 탄력적인 환경에서 앱을 실행하기 쉽게 만들어 준다.  컨테이너화된 앱이 리눅스 등의 운영체제에 지원되기 시작한 지는 오래되었지만 컨테이너 작업이 사용자 친화적이라고 보기는 어려웠다. 반면, 오픈소스에서나 상업화된 형태에서나 도커라는 소프트웨어는 컨테이너를 사용자 친화적이고 개발자 친화적으로 만들어준다. 도커는 앱들을 컨테이너 이미지에 넣은 후 조직 등 어느 곳에서도 손쉽게 배치하여 재사용할 수 있도록 컨테이너용 공통 도구와 은유 방식을 제공한다. 즉, 컨테이너 이미지를 만들어 버전을 매긴 후 공유 및 이동은 물론 도커와 호환되는 호스트에 실행 컨테이너로 배치하는 작업을 눈 깜짝할 사이에 하게 해 주는 것이 도커다.  도커와 컨...

리눅스 운영체제 컨테이너 2019.11.04

쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해

소프트웨어 개발의 최신 경향을 쫓다 보면, 분명 두 가지 용어를 만나고 또 만날 것이다. 바로 도커(Docker)와 쿠버네티스(Kubernetes) 인데, 본질적으로는 컨테이너와 오케스트레이션을 가리키는 말이다. 도커 컨테이너는 애플리케이션을 개발과 테스트를 거쳐 프로덕션으로 이전하는 과정을 최적화해 주며, 도커와 쿠버네티스 둘은 애플리케이션을 구축하고 배치하는 방식을 재창조해 획일적인 단일체 소프트웨어 스택이 아니라 마이크로서비스의 모음으로 바꿔준다. 도커와 쿠버네티스가 왜 중요하며, 이 둘이 소프트웨어 개발을 어떻게 바꾸고 있으며, 이 과정에서 각각이 맡은 역할이 무엇인지 살펴보자.     도커와 컨테이너 리눅스와 윈도우, 그리고 기타 현대적인 운영체제가 지원하는 컨테이너는 소프트웨어가 자체 보유한 작은 환경에서 실행될 수 있도록 해 준다. 이 환경은 시스템의 나머지 부분과 격리된다. 컨테이너는 가상머신과 비슷하지만, 가상머신이 아니다. 컨테이너는 가상머신보다 더 날렵하며 기동과 정지도 더 빠르고 유연성과 이동성도 더 뛰어나다. 컨테이너는 단 몇 초 만에 확장하고 축소할 수 있으며, 클라우드와 같은 탄력적인 환경에서 애플리케이션을 더 쉽게 구동할 수 있다. 리눅스와 기타 운영체제가 컨테이너화된 애플리케이션을 지원하는 것은 오래 된 일이다. 하지만 컨테이너를 사용하는 것은 그리 사용자 친화적이지 않았다. 오픈소스이기도 하고 상용 소프트웨어이기도 한 도커는 기존의 컨테이너를 사용자 친화적이고 개발자 친화적인 환경으로 만든 주역이다. 도커는 컨테이너를 위한 공통 툴 세트를 제공해 애플리케이션을 컨테이너 이미지로 패키징해 기업 내에는 물론 다른 곳에도 쉽게 배치하고 재사용할 수 있다. 쉽게 말해 도커는 컨테이너 이미지를 생성하고 관리하고 공유하고 여러 곳으로 옮기고 도커 호환 호스트에 배치해 컨테이너를 구동하는 작업을 똑딱이 단추를 풀고 잠그는 것만큼 간단한 것으로 만들어 버린다.   도커와 컨테이너를 사용해야 할 때 도커와 ...

컨테이너 오케스트레이션 도커 2019.10.31

앱 중심 미래를 향해 가는 쿠버네티스…OAM과 Rudr로 멀티클라우드 분산 앱 확장

쿠버네티스는 클라우드의 큰 성공 사례다. 무에서 시작해 불과 몇 년 만에 애플리케이션 개발의 슈퍼스타로 떠올랐다. 쿠버네티스가 빠른 속도로 성장하자 개발자들은 쿠버네티스 호스팅 애플리케이션을 구축하고 관리하기 위한 더 나은 방법을 찾고 있다. 쿠버네티스를 위한 확장은 풍부하다. 헴(Helm)과 같은 툴을 사용하면 클러스터에 리소스를 손쉽게 배포할 수 있고, CNAB(Cloud Native Application Bundle)는 애플리케이션과 모든 종속성을 즉시 배포 가능하도록 래핑한다. 하위 수준에서는 드래프트(Draft)와 같은 서비스가 기본적인 서비스를 설계하고 빌드하는 데 도움이 된다. 코드를 빌드해서 익숙한 컨테이너를 사용해 배포할 수 있고, 각 요소를 손쉽게 쿠버네티스 애플리케이션으로 조합할 수 있다. 애저 쿠버네티스 서비스를 사용해서 관리를 자동화할 수도 있다. 서비스 인프라를 백그라운드에 두고 있다는 점을 고려하면(구글의 보그(Borg) 작업), 쿠버네티스와 이를 둘러싼 각종 툴이 기본적으로 운영에 초점을 두는 것은 지극히 자연스럽다. 분산 시스템 운영은 오랜 과제이며, 보그에서 메소스(Mesos), 도커 스웜과 쿠버네티스에 이르기까지 전반적인 데이터센터 OS 추세에는 데브옵스 중에서 ‘데브’보다 ‘옵스’ 측면이 훨씬 더 크다.   이 상황을 넘어 쿠버네티스의 데브 측면을 강화하려면 어떻게 해야 할까? 생태계를 구축하고, 마이크로서비스 원칙을 기반으로 하는 분산 애플리케이션을 구축하기 위한 패턴과 방법을 코드화하는 측면에서는 많은 일이 이뤄졌다. 이제 이 모든 조각을 모아서 전체 그림에서 빠진 조각이자 개발자에게 필수적인 조각, 즉 쿠버네티스에 대한 애플리케이션 중심의 시야를 확보해야 한다.   OAM(Open Application Model) 마이크로소프트와 알리바바 클라우드는 최근 현대적인 분산 애플리케이션을 구성하는 다양한 계층과 역할 간의 경계에 대한 이해를 바탕으로 마이크로서비스 기반 애플리케이션 구축과 관리에 초점...

컨테이너 애저 알리바바 2019.10.24

IDG 블로그 | 서버리스 시스템도 설계가 중요한 이유

어딘가에서는 개발자가 계획이나 설계없이 즉석에서 서버리스 애플리케이션을 구축하기로 한다. 좋지 않은 생각이다. 참 재미있는 일이다. 일단 우리는 애플리케이션 개발에서 일부 핵심 과정을 제거했다. 스토리지나 컴퓨트 같은 자원을 프로비저닝하는 일이 대표적인 예다. 그런데 개발자들은 여기서 얻은 자유를 비논리적이고 아직도 이해하기 힘든 결정에 갖다 바친다.   계획과 설계가 안중에 없을 때도 있다. 서버리스 컴퓨팅이 셀프 프로비저닝 방식이고, 애플리케이션은 즉석에서 동적으로 설계하고 디자인할 수 있기 때문이다. 인프라 계획을 세우지 않아도 된다면, 안될 것도 없는 일이다. 하지만 다시 생각해야 봐야 할 세 가지가 있다. 우선, 우리는 여전히 애플리케이션의 효율성에 중점을 두어야 한다. 서버리스라도 마찬가지다. 자원은 서버리스 애플리케이션의 프로파일을 기반으로 자동으로 할당되거나 서버리스 시스템이 필요하다고 생각하는 대로 할당된다. 만약 애플리케이션의 자원 요청이 언제 어떻게 이루어질지를 엉망진창으로 설계한다면, 서버리스 시스템은 자원을 과잉 할당할 가능성이 크고, 결국 비용은 커지고 효율은 나빠질 것이다. 애플리케이션의 상태에 반응하는 시스템은 설계 패턴을 기반으로 가정을 세워야 한다. 4세대 언어의 세상과 마찬가지로개발 플랫폼의 강력함은 개발자가 너무나 쉽게 자기 발등을 찍을 수 있다는 것을 의미한다. 서버리스도 마찬가지다. 둘째, 애플리케이션은 관리가 필요하기 때문에 여전히 관리 지점을 구축해야 한다. 이는 애플리케이션 안으로 향하는 API를 설계해야 하고, 모니터링을 위한 외부 관리 툴로의 데이터도 설계해야 한다는 의미이다. 이런 인터페이스 없이도 애플리케이션을 관리할 수는 있겠지만, 장기적으로 잘 관리하기는 어렵다. 이를 위해서는 서버리스 시스템과 클라우드옵스의 프로세스 및 툴셋을 함께 동작하도록 할 설계와 접근법이 필요하다. 셋째, 설계 단계부터 보안이 필요하다. 설계와 계획이 없는 애플리케이션은 덜 안전한 애플리케이션이 된다. 기초...

설계 프로비저닝 서버리스 2019.10.23

프라이빗테크놀로지, SDP 플랫폼 이지스 커넥트 출시 통해 보안 시장 출사표

프라이빗테크놀로지(Pribit)가 이지스 커넥트(Aegis Connect)를 출시하면서 본격적으로 소프트웨어 정의 경계(Software Definded Perimeter, SDP) 시장에 진출한다.  SDP는 미국방성이 상업적 용도로 정의한 아키텍처로, 물리적으로는 존재하지만 인증되지 않은 상태에서는 보이지 않아 접근 자체가 불가능하게 만드는 기술이다.  프라이빗테크놀로지는 이 SDP 기술을 애플리케이션과 네트워크 레벨에 적용했다. 프라이빗테크놀로지 김영랑 대표는 "SDP는 기술이라기보다는 표준이다. SDP 플랫폼인 이지스 커넥트(Aegis Connect)는 제로 트러스트(Zero Trust) 모델을 기반으로 킬체인(Kill Chain) 기술을 접목해 공격 표면을 최소화함으로써 알려지지 않은 보안 위협으로부터 원천적으로 봉쇄한다"고 말했다.  김영랑 대표는 "기업에서 사용하는 각종 단말은 기존의 안티바이러스 및 악성코드 탐지 기술로 보호받고 있으나 발견되지 않은 위협이 잠재된 제로 트러스트 상태이며, 네트워크 또한 TCP/IP 기술의 보안 취약점으로 인해 제로 트러스트 상태다"라고 전제하면서, "애플리케이션 레벨의 SDP로 인가된 애플리케이션만 접속을 허용해 안전하지 않은 비인가된 애플리케이션 접속을 원천적으로 차단하고 네트워크 레벨의 SDP를 통해 비인가된 터널의 데이터 패킷 전송을 차단한다"고 설명했다.     김 대표는 "네트워크가 상시적으로 위협에 시달리고 있는데, TCP/IP 기술을 사용하는 한 기존 경계 기반 보안 솔루션으로는 공격을 막지 못한다"면서, "SDP는 레거시 경계 기술을 업그레이드하기 위한 차세대 네트워크 보안 기술이다"고 전했다.  이지스 커넥트는 다양한 인터넷 환경에서 보안이 강화된 프라이빗 터널을 형성해 주요 자원을 권한없는 사용자와 알려지지 않은 악성코드에 감염된 단말로부터 완벽하게 격리한다. 또한 악의적인 공격자들이 탐지할 수 없도록 해 네트워크 상에 흩어져 있는...

SDP 이지스커넥트 프라이빗테크놀로지 2019.10.17

모비젠, SK브로드밴드 ‘차세대 IDC 네트워크 통합 관리 시스템 구축 사업’ 협력

모비젠은 SK브로드밴드에서 추진 중인 ‘차세대 IDC 네트워크 통합 관리 시스템 구축 사업’에 주 사업체로 선정돼 시스템 구축에 착수한다고 밝혔다. 이번 사업은 SK브로드밴드의 IDC에서 운용 중인 기존 네트워크 관리 시스템(Network Management System)을 빅데이터 분석 기반으로 고도화함으로써 차세대 IDC 서비스 품질관리를 위한 통합 NMS 플랫폼을 구축하기 위해 추진됐다. 기존의 네트워크 관리 시스템은 IDC 서비스를 이용하는 기업 고객들에게 서비스 성능과 트래픽을 모니터링하는 기본적인 운용 및 관제 중심의 환경을 제공해왔으며, 서울 가산동에 구축 중인 대규모 데이터센터를 비롯한 향후 시스템 및 고객 확대를 고려해 패키지 플랫폼의 개발 계획을 수립했다. SK브로드밴드는 이번 사업을 통해 IDC 네트워크 운용자가 빅데이터를 활용한 네트워크 운용은 물론 대용량 데이터를 실시간으로 분석할 수 있는 환경을 제공함으로써 IDC 고객 서비스 품질을 강화할 수 있을 것이라 기대하고 있다.  이번 사업은 2019년 7월부터 2019년 12월까지 6개월간 진행될 예정이며, SK브로드밴드는 이번 사업을 시작으로 ▲빅데이터의 분석을 위한 신규 기능 강화 ▲운영(DevOps) 환경 구축 ▲고객 서비스 자동화 환경 구축을 포함한 장기적인 계획을 추진해 나간다는 전략이다. 모비젠은 지난 수년간 SK브로드밴드의 네트워크 관리 시스템 구축 및 개선 프로젝트에 참여한 바 있다. 이번 사업에서는 자사의 빅데이터 솔루션 ‘아이리스(IRIS)’를 적용해 기존 네트워크 관리 시스템을 빅데이터 기반의 통합 플랫폼으로 고도화할 계획이다. 특히, 애플리케이션의 향후 확장 가능성을 고려해 컨테이너 기술(Docker Container)을 적용하는 것이 특징이다. 컨테이너 기술은 애플리케이션의 구동 환경을 가상화하는 기술이다. 운영체제 상에서 직접 애플리케이션의 실행 환경을 가상화하기 때문에 가상머신(VM)에 비해 가볍고 빠르다는 장점이 있으며, 데이터센터, 클라...

sk브로드밴드 모비젠 2019.10.17

대세로 부상한 "마이크로서비스"란 무엇인가

거의 모든 컴퓨터 시스템은 ‘공유되는 자원’을 사용해 여러 작업을 수행한다. 컴퓨터 프로그래밍의 질문 중 하나는 이러한 작업을 수행하는 코드 비트가 서로 얼마나 엮여야 하는가에 관한 것이다. 그리고 점점 더 인기를 얻고 있는 해답은 마이크로서비스 개념이다. 즉, 전체 시스템을 구성하는데 다른 마이크로서비스들과 상호 작용하는 작고 분리된 기능성 덩어리를 이용하는 개념이다. 이렇듯 분리된 구성요소를 갖는다는 개념이 완전히 새로운 것은 아니지만, 마이크로서비스가 구현되는 방식은 현대적이고 클라우드에 기반한 애플리케이션을 위한 자연스러운 토대를 만든다. 마이크로서비스는 또한 데브옵스 철학과 잘 들어맞는다. 새로운 기능성을 빠르고 지속적으로 출시하도록 장려하는 것이다.   마이크로서비스란? 마이크로서비스의 ‘마이크로’는 작은 애플리케이션들을 의미한다. 나름 사실에 기반한 설명이기는 하지만 그것들을 이해하는 더 좋은 방법은 그것들이 한 가지 특정한 일을 하거나 특정한 문제를 해결하기 위해 필요한 만큼만 커야 한다는 것이다. 즉 기술적이기보다는 개념적으로 접근하는 것이 바람직하다. “마이크로서비스는 데이터 액세스나 메시징과 같은 수평적 계층이 아니라 비즈니스 기능을 중심으로 설계되어야 한다”라고 설명된다. 그것들은 비교적 안정적인 API를 통해 다른 마이크로서비스 및 외부 사용자들과 통신해 더 큰 애플리케이션을 만든다. 따라서, 개별 마이크로서비스의 기능성은 시스템의 나머지 부분에 영향을 미치지 않고 조정되거나 급격하게 업그레이드될 수 있다. 이는 다시 데브옵스 부문들이 어떻게 운영하려고 하는지와 관련이 있다. 더 큰 애플리케이션의 특정 기능이 독립적으로 작동하는 코드의 분리된 조각으로 세분화되면 CI/CD(지속적 통합 및 지속적 전달)의 데브옵스 더욱 쉽게 작동할 수 있다. 또한, 잘 정의된 API는 마이크로서비스들을 자동으로 테스트하기 쉽게 만든다. 마이크로서비스 아키텍처 vs 모놀리틱 아키텍처  마이크로서비스가 ‘마이크로서비스 ...

컨테이너 마이크로서비스 콘테이너 2019.10.15

구글 고의 위력을 보여주는 10가지 오픈소스 프로젝트

세상에 나온지 10년째인 구글 고(Go) 프로그래밍 언어는 그동안 확고한 입지를 다졌다. 구글 고가 큰 인기를 끈 이유는 가볍고 빠른 컴파일 속도와 함께 동시 및 분산(즉, 클라우드) 애플리케이션 개발을 쉽게 해주는 풍부한 라이브러리와 추상화에 있다. 그러나 프로그래밍 언어의 성공을 판가름하는 진정한 척도는 개발자들이 그 언어로 만드는 프로젝트다. 구글 고는 네트워크 서비스, 소프트웨어 인프라 프로젝트, 다양한 종류의 컴팩트하고 강력한 툴을 위한 빠른 개발에서 가장 유력한 언어임을 입증했다.   여기서 소개하는 오픈소스 프로젝트는 모두 구글 고로 작성되었으며, 이 중 상당수는 구글 고 언어 자체보다 더 유명해졌다. 10가지 모두 각각의 영역에서 중대한 성과를 거뒀다. 여기 나온 모든 프로젝트는 깃허브에 호스팅되므로 구글 고 언어에 대해 알아보고자 하는 사람이라면 누구나 코드를 살펴볼 수 있다.   도커(Docker) 도커만큼 구글 고의 성공을 잘 보여주는 사례를 찾기는 어렵다. 소프트웨어 컨테이너화 기술인 도커는 약 1년 전부터 대규모 분산 소프트웨어 프로젝트에서 구글 고의 적합성을 보여주는 대표적인 사례로 부상했다. 도커 팀은 종속성 없는 정적 컴파일, 강력한 표준 라이브러리, 완비된 개발 환경, 최소한의 번잡함으로 여러 아키텍처에 맞는 빌드 기능 등 많은 혜택을 제공한다는 이유로 구글 고를 선택했다.   쿠버네티스(Kubernetes) 도커를 필두로 다른 여러 클라우드 지향 컨테이너 프로젝트 역시 구글 고로 만들어졌다. 구글의 컨테이너 오케스트레이션 프로젝트인 쿠버네티스와 그 하위 구성 요소 및 생태계의 대부분도 구글 고로 만들어졌다. 대표적인 예가 기본적인 쿠버네티스만 필요하고 그 외에는 일체 필요 없는 사람들을 위한 초경량 쿠버네티스 스핀오프인 k3s다. 구글은 쿠버네티스를 만들 때 C/C++, 자바, 파이썬을 포함한 다른 언어도 고려했다. 그러나 쿠버네티스의 공동 창립자이자 전 기술 리드이며 현재 VM웨어의 수석 엔지...

프로그래밍 라이브러리 컨테이너 2019.10.11

IDG 블로그 | 클라우드 보안, 컨테이너 취약점 노린 공격을 막아라

보안 전문업체 스카이박스 시큐리티(Skybox Security)가 2019년 취약점 및 위협 트렌드 보고서를 발표했다. 이름에서 알 수 있듯이 이 보고서는 2019년 상반기 동안 보안 공격에 이용된 컴퓨터 취약점을 분석했다.   이번 보고서에서 주목할만한 것은 클라우드 컨테이너의 취약점이 빠르게 증가하고 있다는 것이다. 수많은 기업이 컨테이너 및 컨테이너 오케스트레이션을 도입하는 상황에서 나쁜 소식이 아닐 수 없다. 보고서에 따르면, 2019년 상반기 컨테이너 소프트웨어의 취약점은 전년 동기 대비 46% 증가했다. 2년 전과 비교하면 무려 240%나 늘어났다. IT 책임자가 해야 할 일은 무엇일까? 과거 어느 때보다 많은 컨테이너가 사용되고 있다는 것은 분명한 사실이다. 컨테이너의 이런 성장세는 계속될 것이며, 따라서 어떤 시스템의 취약점이라도 크게 부풀려질 것이다. 희소식이 있다면, 올 상반기에 밝혀진 7,000개 이상의 취약점 중 악용된 것은 약 650개로 일부에 불과하다는 것. 더구나 대규모 공격에 악용된 취약점은 1%도 되지 않는다. 물론 새로운 컨테이너가 끊임없이 프로덕션 환경에 배치되고 있기 때문에 1%라도 걱정하지 않을 수 없다. 이 문제의 핵심에는 날로 높아지는 클라우드 컴퓨팅 플랫폼의 복잡성이 있다. 클라우드는 현재 퍼블릭 클라우드는 물론 프라이빗 클라우드, 전통적인 컴퓨팅 플랫폼까지 수많은 환경에서 구동하는 컨테이너로 구성되어 있다. 컨테이너가 오케스트레이션과 페더레이션으로 옮겨가면서 복잡성과 함께 보안 위험도 높아질 가능성이 크다. 이기종 인프라를 줄여서 복잡성을 줄이는 방안을 선택하기 어렵다면, 필자가 제안하는 대응 방안은 다음과 같다 -    배치된 컨테이너 기반 애플리케이션에 제대로 된 암호화가 적용된 경우가 드물다. 컨테이너 간은 물론이고 컨테이너와 외부와의 연결도 마찬가지다. 암호화 자체는 복잡성을 높이는 요인일 뿐만 아니라 성능에도 영향을 미치겠지만, 대부분 위험 요소를 막을 수 있...

취약점 암호화 페더레이션 2019.10.07

RPA, AI, 데이터옵스 등 2020년 주시해야 할 기술 8가지

기술 변화의 속도가 거의 모든 산업에 지대한 영향을 미쳤다. 최근에는 새롭게 부상하는 기술에 보조를 맞추는 것만으로 부족하다. 여기에 앞서 나가야 한다. 특히 앞으로는 새롭게 진화한 데이터 활용 방식이 기업의 중심 무대를 차지할 전망이다. 기업은 더 나은 비즈니스 의사결정을 내리기 위해 신속하면서도 효율적으로 데이터를 활용하는 방법을 찾으려 시도하고, 점점 더 많은 기업들이 인공지능과 엣지 컴퓨팅, 소프트웨어 로봇 분야의 혁신을 경쟁 우위로 활용하려 시도할 것이다. 이렇게 새롭게 부상하는 트렌드를 예상하지 못한 기업들은 빠르게 도태되는 위험을 직면하게 된다. 우리는 기업들이 투자해야 할 분야에 대한 이해를 돕기 위해, 여러 기술 전문가들에게 디지털 트랜스포메이션을 추진하는 다양한 기업들에 영향을 초래할 확률이 높은 기술에 대해 물었다. 이 분야의 전문가들은 주시해야 할 기술 분야를 선정했으며, 이런 파괴적 혁신 기술 도입이 갖는 의미에 대한 통찰력을 제시했다.   로봇 프로세스 자동화(RPA) 아주 단순한 개념이 기업에 큰 혜택을 전달하고 있다. 판에 박힌 비즈니스 프로세스를 소프트웨어 로봇에 맡겨 자동화한다는 개념이다. 로봇 프로세스 자동화(RPA)로 불리는 기술이며, 이미 조기 도입한 기업의 워크플로우 능률화에 긍정적인 영향을 끼쳤다. 많은 이들이 예상했던 것보다 빠른 시기에 이런 영향이 발생했다.   보스턴 소재 앱네타(AppNeta)의 매트 스티븐스 CEO는 “로봇 프로세스 자동화의 발전 속도가 빠르고, 기능적인 효용도 우수하다. 이렇게 빨리 이 정도 수준의 인텔리전스와 기능이 구현될 것으로 예상하지 못했었다”라고 말했다. 가트너에 따르면, 전세계적으로 RPA 시장은 다른 엔터프라이즈 소프트웨어보다 훨씬 더 빠르게 성장하고 있다. 구체적으로 올해 RPA 시장의 매출은 13억 달러에 도달할 전망이다. 지난해의 경우, 63% 성장한 8억 4,600만 달러 시장이었다.  레이저피체(Laserfiche)의 토마스 펠프스 ...

UC 엣지 컴퓨팅 데이터옵스 2019.08.29

VM웨어 가상화 기술의 미래··· "보안·클라우드에 6조 원 투자"

VM웨어의 VM월드(VMworld) 사용자 컨퍼런스에서는 클라우드가 핵심 주제가 될 전망이다. VM웨어는 48억 달러를 들여 클라우드 개발 업체 피보탈(Pivotal)과 보안 업체 카본 블랙(Carbon Black)을 인수한다.   이미 VM웨어는 최근 열린 분기 실적 발표회에서 피보탈과 클라우드 파운드리(Cloud Foundry) 하이브리드 클라우드 개발 기술을 27억 달러에 인수할 계획이라고 밝혔다. 또한 프리딕티브 시큐리티 클라우드(Predictive Security Cloud)와 다른 엔드포인트 보안 소프트웨어를 포함한 카본 블랙의 보안 기술을 확보하는 데도 21억 달러를 책정했다. 전문가들은 구체적인 실제 인수 금액은 변경될 가능성 있다고 분석했다. VM웨어는 그동안 이들 기업과 긴밀한 관계를 맺어 왔다. 예를 들어 카본 블랙 기술은 VM웨어의 앱디펜스(AppDefense) 엔드포인트 시큐리티 제품의 일부로 사용되고 있다. 피보탈도 VM웨어, 델 제품과 긴밀하게 통합돼 있으며, 지난 2013년 VM웨어의 모회사인 델에서 분사한 바 있다. 실적 발표회 당시 VM웨어 CEO 팻 겔싱어는 "이번 인수는 오늘날 모든 기업이 가장 중요하게 생각하는 핵심 기술 2가지를 확보하기 위한 것이다. 하나는 현대적인 기업용 애플리케이션을 만드는 것이고, 다른 하나는 기업 워크로드와 고객을 보호하는 것이다. 이번 인수를 통해 우리는 구독과 SaaS 사업 성장을 가속하고 고객의 디지털 트랜스포메이션을 지원하는 역량을 크게 확장할 수 있을 것으로 기대한다"라고 말했다. 피보탈 인수에 대해서는 전체 컴퓨터 스택을 확보할 적기라고 판단했다.  겔싱어는 "앞으로 우리는 기업 고객이 클라우드 환경을 구축, 실행, 관리할 수 있도록 우리만으로 독자적으로 지원하는 업체로 자리매김해 나갈 것이다. 이제 기업 고객은 이에 필요한 모든 기술을 한 업체로부터 지원받을 수 있다. 이번에 인수한 기술은 VM웨어 핵심 플랫폼에 통합된다. 곧 열리는 VM월드 행사에서 더 자...

VM월드 가상화 보안 2019.08.28

VM웨어, 쿠버네티스 네이티브 전략 발표…관리자와 개발자 모두를 위한 vSphere 환경

VM웨어가 자사의 기존 vSphere 고객이 좀 더 쉽게 쿠버네티스 컨테이너를 구축하고 관리할 수 있도록 돕는 새로운 구상인 VM웨어 탄주(Tanzu)를 발표했다. 수많은 신기술과 VM웨어의 기존 기술로 구성된 탄주 플랫폼은 쿠버네티스 컨테이너 환경에서 신속하게 소프트웨어를 구축하고자 하는 기업을 대상으로 한 일군의 제품과 서비스를 생성한다. VM웨어는 쿠버네티스가 애플리케이션의 다양성을 수용할 수 있는 인프라 계층으로 부상했다고 본다. 2018년부터 2023년까지 5억 개의 새로운 논리 앱이 만들어져 모든 환경에 걸쳐 다양한 애플리케이션의 필요에 부응할 것이며, 새로운 툴과 플랫폼, 더 많은 개발자, 민첩한 개발 방법론, 그리고 더 코드 재사용이 이루어질 것으로 보고 있다.   CEO 팻 겔싱어는 “우리는 탄주를 개발 세상과 운영 세상을 이으려는 고객을 위한 포괄적인 환경으로 본다. 초강력 엔터프라이즈급 쿠버네티스 플랫폼이 될 것이다. 쿠버네티스는 이런 변화에서 중심 툴이며, VM웨어는 이를 위해 많은 작업을 하고 있다”고 밝혔다. 겔싱어는 VM웨어가 쿠버네티스 기술에 투자한 것을 강조했는데, 헵티오(Heptio), 비트나미(Bitnami)에 이어 피보탈(Pivotal)까지 인수했다. 이로써 VM웨어는 세 손가락에 드는 쿠버네티스 오픈소스 기여자가 됐다. 원대한 탄주 계획의 핵심은 프로젝트 퍼시픽(Project Pacific)이란 기술로, 쿠버네티스를 VM웨어의 주력 가상화소프트웨어인 vSphere에 추가해준다. 쿠버네티스를 vSphere 제어판에 내장함으로써 컨테이너와 가상머신의 융합을 단일 플랫폼에서 구현할 수 있다. 프로젝트 퍼시픽은 또한 컨테이너 런타임을 하이퍼바이저에 추가해 준다. 이렇게 쿠버네티스를 내장함으로써 VM웨어의 베어메탈 하이퍼바이저인 ESXi는 쿠버네티스 팟의 가장 뛰어난 특성과 가상머신을 결합해 핵심 워크로드를 위한 고성능 런타임을 제공할 수 있다. 여기에 더해 프로젝트 퍼시픽은 가상머신과 컨테이너 전체에 가상 네트...

VMworld vSphere 쿠버네티스 2019.08.27

글로벌 칼럼 | '분리된 시스템 지급'이 보안에 별 도움 안되는 이유

필자가 많이 받는 질문 중 하나가 직원에게 업무용과 기타용 2개 시스템을 지급하는 것에 대한 의견이다. 잠긴 시스템에서 업무를 처리하고 회사에 과도한 위험을 발생시키지 않으면서, 다른 시스템에서는 일상적인 일을 처리하는 방식이다.   사실 이는 전혀 새로운 아이디어가 아니다. 이런 방식은 컴퓨터의 역사만큼이나 오래됐고 필자 역시 수십 년 동안 이런 '적색/녹색 시스템(red/green systems)'에 관해 이야기했다. 서로 완전히 분리된 2개의 별도 시스템을 사용하면 사이버 보안이 개선되고 때에 따라 크게 보안을 강화할 수 있다. 그러나 이는 매우 많은 돈이 드는 컴퓨터 보안 방식이다. 하드웨어와 소프트웨어 라이선스, 지원 비용, 지원 문제 등이 모두 2배가 되기 때문이다. 이런 방식은 보안이 삼엄한 곳과 일부 금융사에서 실제로 사용된다. 하지만 비용만 보더라도 2개의 물리적으로 분리된 시스템 개념은 실효성이 없다. IT 보안팀은 한번 랜섬웨어 공격을 당해 복구하는 비용을 고려하면 2개 시스템을 구매해 지원하는 것이 더 저렴하다고 쉽게 주장할 것이다. 그러나 경영진에게 '가상의 상황'에 대비해 지원 비용을 2배로 늘리자고 설득하는 것은 모든 기업에서 가능할 리 없다. 해커는 비즈니스 시스템을 노린다 적색/녹색 시나리오가 효과가 없는 더 근본적인 이유는 오늘날의 해킹 방식이 이러한 분리를 무력화하는 경우가 많기 때문이다. 즉, 비즈니스 시스템을 직접적으로 공격하며 현업 직원을 의도적으로 노려 적색/녹색 시스템의 보안 이점이 퇴색시키는 것이다. 좋은 예가 BEC(Business Email Compromise) 피싱 사기다. 누군가 현업 직원에게 신뢰하는 누군가로 가장해 돈이나 송장을 요청하면 피해자는 비즈니스 계정에서 이를 지불한다. 피해자에게 개인용 이메일 계정이나 소셜 미디어를 통해 접근하지 않는다. 모두가 비즈니스 시스템을 통해 이뤄진다. 피해자가 신뢰하는 사람의 해킹된 이메일 계정을 사용해 실행된 BEC 사기 사고는 점점 더 흔해지고 ...

보안 망분리 쿠베스 2019.08.26

VM웨어, 2020년 회계연도 2분기 실적 발표…“지난해 매출 비해 12% 증가”

VM웨어가 2020년 회계연도 2분기 실적을 발표했다. VM웨어의 2020년 회계연도 2분기 총 매출은 24억 4,000만 달러로 지난해 같은 기간에 비해 12% 증가했다. 이 가운데 라이선스 매출은 10억 1,000만 달러로 지난해 같은 기간에 비해 12% 상승했다. 영업 이익은 5억 2,300만 달러로 3% 증가했다. VM웨어는 이번 실적과 함께 피보탈 소프트웨어와 카본 블랙의 인수 합의를 추진 중임을 발표했다. 피보탈과 카본 블랙은 각각 현대적인 접근법의 앱 구축과 엔터프라이즈 워크로드·클라이언트 보호라는 주요 IT 전략 우선순위 두 가지를 반영하는 기업이다.  VM웨어는 피보탈을 인수하면서 VM웨어의 쿠버네티스 포트폴리오와 피보탈의 차세대 개발자 플랫폼을 결합해 통합된 현대적 앱 포트폴리오를 제공할 계획이다. 또한, 카본 블랙을 인수해 VM웨어의 내재적 보안 자산을 카본 블랙의 보안 솔루션 일체와 결합해 차세대 보안 클라우드를 실현할 수 있을 예정이다. VM웨어는 두 기업을 포트폴리오에 추가함으로써 고객이 어떤 클라우드, 어떤 디바이스에서도 모든 앱에 대한 구축, 운영, 관리, 연결, 보호를 수행할 수 있도록 지원하는 소프트웨어 솔루션을 제공하고자 한다. VM웨어 팻 겔싱어 CEO는 “이번 인수는 오늘날 비즈니스에서 필수적이라 할 수 있는 현대적인 엔터프라이즈급 애플리케이션 구축과 엔터프라이즈 워크로드·클라이언트 보호라는 두 가지 중요한 기술적 우선순위가 반영된 것”이라며, “이러한 일련의 활동을 통해 VM웨어의 구독 및 SaaS 오퍼링 부문이 눈에 띄게 성장하고 있으며, 고객의 디지털 트랜스포메이션을 지원하는 역량 또한 확대되고 있다”고 말했다. VM웨어와 피보탈은 VM웨어가 피보탈 A주(Class A)를 주당 15달러에 현금 매입하고, 델 테크놀로지스가 보유한 피보탈 B주(Class B)에 대해서는 피보탈 B주 보통주 한 주당 VM웨어 B주 보통주 0.0550주의 비율로 VM웨어 B주와 교환하는 방식으로 피보탈을 인수한다는 내용의 ...

VM웨어 2019.08.23

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.