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

가상화ㆍ컨테이너

"미라이, SD-WAN까지 찾고 있다"…팔로알토 유닛42 보고서

광범위한 DDoS 공격을 하기 위해 수십만 대의 인터넷 연결 기기를 해킹한 소프트웨어인 미라이(Mirai)는 이제 IoT 제품을 뛰어넘어 SD-WAN(Software-Defined WAN) 장비의 취약점을 악용하려는 코드를 포함하고 있다.     VM웨어의 SD-WAN 어플라이언스의 SDX 제품군은 이 취약점을 수정했지만, 미라이의 저작자는 보안 카메라와 셋톱 박스를 확보한 것 이상으로 취약한 엔터프라이즈 네트워킹 장비를 찾아내고 있다.  최근 미라이에 대한 보고서를 발표한 팔로알토 네트웍스 유닛42의 위협 연구 부국장 젠 밀러오즈본은 "가능한 한 많은 장비를 수집하는 미라이를 보게 될 것이라고 추정한다"고 말했다. 전에 없던 SD-WAN 악용  밀러오즈본에 따르면, SD-WAN 어플라이언스에 대한 익스플로잇은 그 성격이 미라이에서 벗어난 것이지만, 저작자의 작업 방식이 바뀐 것은 아니다.  이 아이디어는 봇넷에 무엇이든지 관계없이 장치를 추가한다는 사실이다. SD-WAN 장비에서 표적이 된 것은 SD-WAN 기능과 관련해 취약점이 있는 특정 장비다.   책임감 있는 공개, 익스플로잇의 실행 차단  유닛42 보고서에 따르면, 이 취약점은 지난해 독립 연구원에 의해 발견된 것으로, VM웨어는 이를 책임감 있게 공개하고 최신 소프트웨어 버전으로 수정했다. 그럼에도 불구하고 최근 이 취약점을 악용하려는 미라이의 새로운 변종이 발견됐다.  이 저작자는 새로운 대상을 추가하기 위해 주기적으로 미라이를 업데이트하고 있다. 기본적인 자격 증명(아이디와 비밀번호)을 실행하는 장비를 표적으로 삼는 본연의 전술은 다양한 범위에서 다양한 장비의 취약점을 악용할 수 있다.   유닛42는 "악성 소프트웨어의 업데이트된 변종에는 총 8가지의 새로운 미라이 익스플로잇이 포함됐다"고 전했다.   VM웨어 SD-WAN의 수정된 버전은 SD-WAN Edge 3.1.2이다. VM웨어 보안 권고...

팔로알토 미라이 SD-WAN 2019.07.01

IDG 블로그 | 서버리스가 전혀 맞지 않는 애플리케이션

간단히 말해 서버리스 시스템은 기업이 인프라 문제를 처리해야 하는 수고를 없애준다. 스토리지나 컴퓨트 서버의 프로비저닝과 운영을 신경 쓰지 않아도 된다. 실제로 서버리스 컴퓨팅을 “노옵스(No-Ops)”라고 부르는 경우도 많다. 하지만 실제로는 “알옵스(Reduced-Ops)이고, 혹자는 “썸옵스(Some-Ops)”라고 하기도 한다. 분명한 것은 서버리스의 목표가 단순성을 높이고 전혀 새로운 클라우드 기반 서버리스 애플리케이션의 구축과 배치를 훨씬 더 생산적이고 민첩하게 수행하는 것이다.   하지만 서버리스가 언제 어디에나 좋은 것은 아니다. 실제로 오랜 시간 억지로 적용하면 시험 운영보다 더 많은 오류가 발생하는 것으로 보인다. 서버리스는 특히 스테이트풀(Stateful) 애플리케이션에는 최악의 아이디어이다. 스테이트리스(Stateless) 애플리케이션은 모든 트랜잭션을 처음부터 완료된 것처럼 수행한다. 현재의 트랜잭션에 사용하는 이전에 저장된 정보 같은 것은 없다. 반대로 스테이트풀 애플리케이션은 한 세션의 동작으로부터 클라이언트 데이터를 저장해 다른 세션에 사용한다. 이렇게 저장된 데이터를 흔히 애플리케이션의 상태, 즉 스테이트(State)라고 부른다. 스테이트풀 애플리케이션이 서버리스에 맞지 않는 이유는 분명하다. 서버리스 애플리케이션은 여러 서비스, 즉 기능으로 구성되어 있는데, 이들 기능은 짧게 실행되고 스테이트가 없다. 전통적인 의미의 트랜잭션에 이를 적용하면, 서버리스 애플리케이션은 실행된 이후에는 아무 것도 유지하지 않는 것이다. 서버리스 시스템은 애플리케이션 개발과 배치에 이런 방식으로 접근한다. 특정 기능을 실행하는 데 필요한 자원만을 할당해 처리한 다음에는 자원을 다시 공유 풀에 반환한다. 서버리스 시스템과 서버리스 개발자 모두에게 상태를 유지하는 것은 너무나 복잡한 일이다. 이런 식으로 애플리케이션은 실행 서비스로 깔끔하게 나뉘어 있으며, 서로 간에 독립적이고 느슨하게 연결되어 있다. 서버리스 시스템 상에서 스테이...

서버리스 스테이트풀 스테이트리스 2019.06.19

서비스 메시의 의미와 서비스 메시 프로젝트들

IT에서 디지털 트랜스포메이션이라는 깃발 아래에 일어나고 있는 변화 가운데 하나는 대규모의 모놀리식 애플리케이션을 마이크로서비스(microservices)로 쪼개는 일이다. 마이크로서비스는 격리 가능하고 한 서버에서 다른 서버로 손쉽게 이동이 가능한, 모든 서비스 코드와 종속성이 포함된 소프트웨어 패키지인 컨테이너에서 실행되는 작은 개별적 기능 단위다.   이와 같이 컨테이너화된 아키텍처는 손쉽게 확장이 가능하고 클라우드에서 실행할 수 있으며 개별 마이크로서비스는 신속한 롤아웃과 반복이 가능하다. 그러나 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 이러한 마이크로소프트 간의 통신은 점점 더 복잡해진다. 서비스 메시(service mesh)는 최근 부상하는 아키텍처 형식으로, 관리 및 프로그래밍 오버헤드를 낮추는 방식으로 마이크로서비스를 동적으로 연결하는 데 목표를 둔다. 서비스 메시란 무엇인가 가장 넓은 의미에서 레드 햇(Red Hat)의 설명을 옮기자면 "서비스 메시는 애플리케이션의 여러 부분에서 상호 데이터를 공유하는 방법을 통제하는 수단"이다. 그러나 이 설명은 지나치게 포괄적이기도 하다. 설명만 보면 대부분의 개발자가 클라이어언트-서버 애플리케이션에서 익숙한 미들웨어와 거의 비슷하다. 서비스 메시의 고유한 부분은 분산 마이크로서비스 환경의 특성을 포용한다는 점이다. 마이크로서비스로 빌드된 대규모 애플리케이션에는 특정 서비스의 여러 인스턴스가 다양한 로컬 또는 클라우드 서버에서 실행될 수 있다. 움직이는 부분이 많은 만큼 개별 마이크로서비스가 통신야 하는 상대방 서비스를 찾기도 당연히 더 어렵다. 서비스 메시는 매 순간 서비스를 찾고 연결하는 과정을 자동으로 처리하므로 인간 개발자와 개별 마이크로서비스에서 직접 이 작업을 할 필요가 없다. 서비스 메시는 OSI 네트워킹 모델 7계층을 위한 SDN(Software-Defined Networking)과 같다고 생각하면 된다. 네트워크 관리자가 물리적 네트워크 연결을 ...

쿠버네티스 서비스메시 2019.06.18

IDG 블로그 | 서버리스 성공을 위한 3분 가이드

시장 분석회사 마켓앤마켓(Markets and Markets)에 따르면, 2018년 서버리스 아키텍처 시장은 약 42억 5,000만 달러 규모로 추정된다. 그리고 2023년에는 시장 규모가 149억 달러에 이를 것으로 예상했다. 서버리스 사용이 이처럼 확산하는 이유는 무엇일까? 빠른 배치와 클라우드옵스의 단순화 및 자동화, 데브옵스 프로세스와의 통합, 그리고 비용 측면의 장점 등을 들 수 있다.   그렇긴 하지만, 서버리스를 사용하고자 하는 사람 대부분이 어떻게 해야 하는지를 잘 모른다. 많은 사람이 전통적인 온프레미스 애플리케이션을 가져다 마우스 드래그로 서버리스에 보낼 수 있다고 생각한다. 하지만 현실은 훨씬 더 복잡하다. 실제로 서버리스 애플리케이션 개발은 전혀 새로운 애플리케이션을 맞추는 것과 비슷하다. 여러 가지 요소를 고려해야 하지만, 주된 작업은 서버리스에 맞춰 애플리케이션을 새로 설계하는 것이다. 특정 설계 패턴에 최적화되어 있는 컨테이너나 다른 실행 아키텍처에 맞춰 설계해야 하는 것처럼, 서버리스도 예외가 아니다. 가장 흔한 실수는 제대로 최적화되지 않은 애플리케이션을 강제로 서버리스에 맞추는 것이다.   개발자가 서버리스를 반기는 이유 서버리스 컴퓨팅의 3대 문제점과 해결 방법 IDG 블로그 | 서버리스 컴퓨팅을 시작하기 전에 알아야 할 것 서버리스 설계를 위한 몇 가지 팁은 다음과 같다. -    애플리케이션을 독립적이고 수명이 짧은 서비스로 분해해야 한다. 서버리스 시스템은 애플리케이션의 구성요소를 별도의 기능으로 실행한다. 많은 경우, 이는 자연스럽지 않은 동작이다. -    결로넞긍로 서버리스 애플리케이션 역시 스테이트리스(Stateless)라야 한다. 이는 API 관리와 같은 서비스를 지원하는데, 서버리스 애플리케이션의 성공에 핵심적인 요소이다. -&...

아키텍처 가이드 서버리스컴퓨팅 2019.06.13

스파이런트, 표준 기반 NFV 클라우드 테스트 플랫폼 출시

스파이런트 커뮤니케이션은 유럽전기통신표준화기구(ETSI)의 GS NFV-TST 001에 명시된 네트워크 가상화(이하 NFV) 성능을 보장하는 테스트 솔루션 ‘스파이런트 클라우드슈어(CloudSure)’를 출시했다고 밝혔다.  스파이런트 클라우드슈어는 성능 벤치마크 및 검증이 가능하고, 서비스 제공업체들의 NFV 구축을 지원하며, 성능 저하 없이 유연하고 민첩한 서비스의 이점을 누릴 수 있도록 설계됐다. NFV는 네트워크 기능 가상화 인프라(이하 NFVi) 및 가상 네트워크 기능(VNF)의 기능을 구현하여 여러 가지 문제를 해결할 수 있는 복잡하고 어려운 기술의 집합이다. 스파이런트 클라우드슈어는 테스트 패키지의 형태로 가치를 제공하며, 서비스 공급업체들의 고유한 NFV 구축에 맞게 용이한 구성과 사용자 정의가 가능한 템플릿들로 구성돼 있다.  스파이런트 클라우드슈어는 그래픽 사용자 인터페이스(GUI)와 자동화 유저들을 위한 애플리케이션 프로그래밍 인터페이스(API)를 통해 구성할 수 있으며, 이 때 스파이런트 테스트센터 버츄어(Spirent TestCenter Virtual) 포트 및 스파이런트 클라우드스트레스(Spirent CloudStress) 에이전트는 클라우드 성능을 평가하기 위해 현실적인 다차원 워크로드를 생성하게 된다. 스파이런트의 클라우드 및 IP 비즈니스 총괄 매니저 아비테시 카스투아는 “스파이런트 클라우드슈어는 운영자의 주요 NFV 문제를 해결하는 테스트 프레임워크를 통해 가상 인프라의 성능을 측정하는 새로운 접근방식을 채택하고 있다”며, “ETSI GS NFV-TST 001에 따라 NFV 에코시스템의 벤치마킹 및 검증에 초점을 두고, 클라우드 성능 비교, 클라우드 워크로드 마이그레이션 및 용량 계획과 같은 다른 클라우드 테스트 과제를 해결할 수 있는 독특하고 유연하며 적응 가능한 프레임워크”라고 설명했다.  클라우드 테스트는 일반적으로 수백 개...

스파이런트 2019.06.10

IDG 블로그 | “컨테이너 세금”에 주의하라

컨테이너는 애플리케이션을 클라우드에 배치하는 참신하고 편리한 방법이지만, 추가 비용이 있다는 것을 잊어서는 안된다.   컨테이너는 애플리케이션 개발에서 있어서 몇 가지 기본적인 특징과 이점이 있다. 이점은 다음과 같다. -    컨테이너 추상화를 통해 복잡성을 줄여준다. 애플리케이션의 기반 플랫폼이 아니라 컨테이너를 다루면 된다. -    자동화를 통해 이식성을 극대화한다. 한 번 작성해서 여러 곳에서 실행할 수 있는 것이다. -    컨테이너 외부에 대해 더 나은 보안과 거버넌스를 제공한다. -    컨테이너의 핵심 아키텍처 양식이 분산화이기 때문에 분산 컴퓨팅 역량을 개선할 수 있다. -    정책 기반의 최적화를 제공하는 자동화 서비스를 제공한다. -    쿠버네티스 같은 컨테이너 오케스트레이션을 사용할 수 있다. -    컨테이너를 지원하는 수많은 서비스 및 솔루션 업체의 생태계를 이용할 수 있다. 컨테이너의 문제는 모두가 컨테이너를 사용하고자 하지만, 아무도 컨테이너를 구축하고 배치하는 데 드는 추가 비용을 모른다는 것이다. 실제로 필자는 새 애플리케이션이나 기존 애플리케이션을 컨테이너로 옮기거나 구축하는 데 평균 35% 추가 비용이 드는 것으로 보고 있다. 도대체 어디에 이런 비용이 드는 것일까? 주요 항목은 다음과 같다. 첫째, 컨테이너 설계에 손이 많이 간다. 따라서 초기 설계나 컨테이너로 옮기고자 하는 기존 애플리케이션의 리팩터링에 더 많은 시간을 사용하는 것이 합리적이다. 둘째, 툴 비용이 더 든다. 컨테이너 기반의 툴은 무료 툴 외에 데이터베이스 액세스나 보안, 거버넌스를 제공하는 툴이 전통적인 툴보다 50% 정도 더 비싸다. 물론 유용한 툴은 중요하지만, 비용도 고려해야 할 것이다. 마지막, 컨테이너는 운영과 유지보수 비용이 더 든...

아키텍처 컨테이너 추가비용 2019.06.05

통합 클라우드 스택을 기반으로 '패스트 팔로워'에서 '퍼스트 무버'로 전환한다...티맥스

티맥스는 5월 23일 기자간담회를 통해 기존 인프라 중심의 클라우드를 넘어선 플랫폼과 서비스 중심의 통합 클라우드 스택을 발표하면서 22년간 쌓아온 플랫폼 기술과 클라우드 기술로 세상에 없는 새로운 클라우드 시대의 ‘퍼스트무버’로 변모할 것이라고 밝혔다.  이를 위해 티맥스는 약 5년 전부터 클라우드 기술을 연구해왔다. 현재 티맥스 연구원 800여 명 가운데 700명이 클라우드 인프라, 클라우드 플랫폼, 클라우드 서비스와 관련된 연구를 하고 있다. 이 연구 성과가 바로 통합 클라우드 스택이라는 이름으로 올해 하반기에 발표될 예정이다.  티맥스는 축적한 미들웨어와 데이터베이스 기반의 플랫폼 기술을 클라우드의 핵심 요소인 가상화, 통합, 자동화 기술과 융합해 플랫폼스페이스(PlatformSpace)라는 진화된 클라우드 플랫폼과 서비스형 플랫폼(PaaS) 기술을 선보였다. 플랫폼스페이스는 통합 UI(사용자 인터페이스) 플랫폼과 통합 미들웨어 플랫폼, 통합 데이터베이스 플랫폼, 신기술인 빅데이터/인공지능(AI) 플랫폼을 포함해 총 4개 플랫폼을 완전히 융합함으로써, 클라우드 앱을 손쉽게 개발할 수 있는 환경을 제공한다. 올 7월에 일반에 공개할 플랫폼스페이스는 클라우드 기반의 다양한 서비스와 앱을 자동화된 툴을 이용한 애자일 방식으로 개발하고 운영하는 환경을 제공하며, 클라우드오피스 및 협업 기능과 함께 ERP 등의 B2B 앱도 통합해 활용할 수 있는 앱 플랫폼 역할을 수행한다.  지난해 출시한 독자 운영체제인 티맥스OS는 특정 운영체제에 종속적인 앱의 한계를 극복해 PC, 모바일, 서버 등 모든 IT 기기 간의 자유로운 연결과 융합이 가능한 클라우드OS로 진화했다. 또한 이를 기반으로 한 클라우드 앱을 쉽게 만들 수 있는 앱 플랫폼을 출시했다.  이를 통해 티맥스 측은 2030년 티맥스데이터가 20조 원, 티맥스오에스가 80조 원 정도의 매출을 달성해, 그룹사 전체 매출 100조 원을 목표로 했다...

티맥스 클라우드 2019.05.23

새로운 애저 서비스의 핵심은 쿠버네티스와 코스모스 DB

마이크로소프트는 스스로 세 클라우드 회사라고 지칭하기 시작했다. 엑스박스 게이밍 클라우드, 마이크로소프트 365 업무 생산성 서비스, 그리고 가장 중요한 애저가 바로 그 세 클라우드이다. 아마존 웹 서비스(AWS)에 이은 업계 2위의 애저는 초거대 규모의 클라우드로, 미처 따라잡기 힘든 속도로 서비스를 속속 출시하고 있다. 이 속도는 마이크로소프트 3대 개발자 행사에서 더욱 잘 드러나는데, 개발자라면 쏟아져 나오는 발표 내용을 철저히 살펴 봐야 핵심 요소들을 파악할 수 있다.   마이크로소프트가 확실히 주력하고 있는 것은 서버리스 애플리케이션 구축 플랫폼으로서의 애저이다. 이를 통해, 가상머신을 지정할 필요가 없고 초 단위 CPU 사용 시간 별로 비용을 청구하는 인프라 서비스를 제공한다. 애플리케이션에는 머신러닝, 분석, 저장, 연산 등이 가능하도록 매우 다양한 플랫폼 서비스가 자리하고 있다.  상황이 흥미로워지는 곳은 2가지가 만나는 지점이다. 즉, 단일 애저 리전 내에서나 애저 퍼블릭 클라우드 전체에 걸쳐 코드의 확장성을 개선하기 시작하는 지점이다. 분산 애플리케이션은 수작업 구축이 쉽지 않다. 마이크로소프트는 익숙한 도구와 새로운 기능을 모두 활용하여 확장성 자동화 방식을 더 많이 제공한다.   쿠버네티스에서의 이벤트 주도 규모 조정  애저는 다른 대형 퍼블릭 클라우드처럼 쿠버네티스에 크게 의존한다. 하이퍼스케일 연산 작업 시에는 분산 애플리케이션의 관리와 조율이 필수적이다. 이 때, 애플리케이션을 고립된 컨테이너로 제공하면 구축 시스템으로부터 완전한 인프라를 제공하는 절차가 단순해진다. 단, 쿠버네티스는 복잡할 수 있다. 간단한 이벤트 주도 애플리케이션용으로 사용할 때 특히 그렇다. 자바스크립트로 조율되는 쿠버네티스를 갖춘 브리게이드(Brigade)를 쓰는 방법이 있다. 단, 이벤트를 트리거시키거나 요구에 따라 새로운 서버리스 기능을 시작하기 위해 애저의 이벤트그리드(EventGrid)와 같은 도구를 사용 중이...

컨테이너 애저 코스모스 2019.05.10

IDG 블로그 | 쿠버네티스로 클라우드 복잡성 줄이는 방법

쿠버네티스는 보안이나 인프라용으로는 너무 과하게 사용하지만, 자동화용으로는 너무 적게 사용한다. 정말 필요한 사람들이 그 잠재력을 제대로 알지 못한다. 한참 전에 필자는 쿠버네티스가 컨테이너 오케스트레이션 전쟁의 승자라고 선언한 바 있다. 물론 필자의 예견이 맞아서 좋지만, 클라우드 업계의 많은 사람이 쿠버네티스를 모든 문제를 해결하는 최종 병기 기술의 틀에 끼워 넣고 있다. 이 때문에 모든 보안 문제, 모든 인프라 문제를 해결하는 데 쿠버네티스를 과용하고 있으며, 심지어 차기 전략 아이템을 찾고 있는 IT 업체를 위한 완결판 전략이 되기도 한다. 모든 것이 쿠버네티스인 것이다.   클라우드 컴퓨팅 실전 전문가로서, 그리고 쿠버네티스를 온프레미스 환경에서 퍼블릭 클라우드에서 이용하는 사람으로 필자는 쿠버네티스의 장점은 모두 사실이라고 말할 수 있다. 하지만 마찬가지로 필자는 사람들이 쿠버네티스를 2020년에 직면하게 될 핵심적인 문제, 즉 클라우드 복잡성을 해결하는 데 도움이 되는 기술로 고려하지 않는다는 사실도 말할 수 있다. 클라우드 복잡성을 유발하는 원인은 크게 두 가지이다. 첫 번째는 클라우드 플랫폼을 선택할 때 이기종 기술의 과용하는 것이다. 멀티클라우드는 좋은 개념이긴 하지만, 수천 가지 네이티브 API를 두세 가지 인수로 하나의 통일된 플랫폼으로 넣는 것은 개발자는 물론 운영팀의 일을 몹시 힘들게 만든다. 두 번째, 적절한 계획없이 클라우드 솔루션을 배치하는 것이다. 최소한의 위험으로 멀티클라우드 솔루션을 배치하는 데는 최소한의 이해가 필요하다. 현재 무엇을 하고 있고 어떤 방법으로 어디로 가려는지 잘 알고 있어야 한다. 대부분 기업은 이런 질문에 대답하지 못하고 반동적인 상태에서 계속 운영한다. 이런 클라우드 복잡성에 대한 해결책도 두 가지이다. 우선, 추상화가 있다. 최소 공통분모 접근법으로 추상화 계층을 사용해 클라우드 네이티브 툴과 인터페이스를 직접 처리하는 복잡성을 제거하는 것이다. 두 번째는 자동화이다. 인터페...

복잡성 컨테이너 쿠버네티스 2019.05.03

도커 엔터프라이즈 3.0, 안전한 쿠버네티스 스택 통합

도커는 안전한 쿠버네티스 스택을 통합한 도커 엔터프라이즈 3.0을 베타 버전으로 발표했다. 또한 도커 엔터프라이즈의 매니지스 서비스 옵션도 공개했다. 도커 엔터프라이즈는 컨테이너 기반 애플리케이션을 구축하고 실행하고 공유하는 엔드 투 엔드 플랫폼으로 자리 잡고 있다. 새 버전의 도커 쿠버네티스 서비스(Docker Kubernetes Service, DKS)는 쿠버네티스 컨테이너 오케스트레이션을 개발자의 데스크톱에서 프로덕션 서버로 통합한다.   DKS는 쿠버네티스 YAML, 헬름 차트, 도커 컴포즈 툴을 이용해 멀티컨테이너 애플리케이션을 생성할 수 있다. 또한 쿠버네티스 애플리케이션을 하이브리드 및 멀티클라우드 배치 환경에 설치하고 환경을 구성하는 자동화된 방법을 제공한다. 이외에도 보안, 액세스 제어, 라이프사이클 관리 등의 기능을 갖추었다. 도커 엔터프라이즈 고객은 오케스트레이션을 위해 도커 스웜을 사용할 수도 있다. 매지니드 서비스 옵션인 Docker Enterprise-as-a-Service는 캡제미니(CapGemini)와 협력관계를 통해 도커 엔터프라이즈를 온프레미스 또는 퍼블릭 클라우드에 서비스로 배치할 수 있다. 매니지드 서비스는 온디맨드 방식의 확장과 사용량 기반의 과금을 이용한다. 이외에 도커 엔터프라이즈 3.0의 주요 특징은 다음과 같다. - 도커 데스크톱 엔터프라이즈(Docker Desktop Enterprise)는 도커 허브 생태계 액세스와 통합된 이미지 레지스트리를 제공하는 일련의 자동화 툴이 특징이다. 기업용 쿠버네티스 환경으로의 배치도 지원한다. - 도커 애플리케이션(Docker Applications)는 어떤 인프라에도 배치할 수 있는 단일 패키지로 멀티컨테이너 애플리케이션을 정의한다. 개발자와 운영팀은 관련 컨테이너 그룹을 정의해 특정 애플리케이션 상에서 협업할 수 있다. 이 기능은 CNAB(Cloud Native Application Bundle) 표준을 기반으로 한다. 도커 컴포즈, 헬름 차트, 쿠버네티스...

컨테이너 도커 쿠버네티스 2019.05.02

VM웨어, 데이터센터와 엣지 인프라 혁신 위한 ‘VM웨어 클라우드 온 델 EMC’ 공개

VM웨어가 미국 라스베이거스에서 개최된 ‘델 테크놀로지스 월드(Dell Technologies World) 2019’에서 온프레미스 데이터센터 및 엣지 환경을 위한 서비스형 인프라(IaaS)를 제공하는 ‘VM웨어 클라우드 온 델 EMC(VMware Cloud on Dell EMC)’를 발표했다. VM웨어 클라우드 온 델 EMC는 VM웨어 v스피어, vSAN, NSX가 제공하는 고성능 컴퓨팅, 스토리지, 네트워크 소프트웨어를 델 EMC의 하이퍼컨버지드인프라(HCI) 솔루션 V엑스레일(VxRail)과 결합한 것이다. VM웨어가 통합 관리를 전담하고 기업은 비즈니스 혁신과 차별화에 집중할 수 있다. VM웨어는 멀티 클라우드 환경에 대응하기 위한 투자를 지속하고 있으며, 데이터센터에서 클라우드, 엣지를 아우르는 하이브리드 클라우드 전반의 운영 환경을 개선하고 있다. VM웨어 클라우드 온 델 EMC는 퍼블릭 클라우드가 제공하는 단순성, 민첩성, 경제성의 이점을 온프레미스 인프라의 보안 및 관리 편의성, 고성능과 결합해 민첩성과 효율성을 극대화함으로써 향상된 고객 경험을 제공한다.  VM웨어 마크 로마이어 클라우드 플랫폼 비즈니스 부문 총괄 사장은 “VM웨어 클라우드 온 델 EMC는 인프라를 도입, 구축, 관리하는 방식을 혁신함으로써, 데이터와 애플리케이션을 온프레미스에 유지하고 관리해야 하는 기업에 완전히 새로운 클라우드 경험을 제공한다”며, “VM웨어 클라우드 온 델 EMC는 클라우드, 데이터센터, 엣지 전반에 일관된 인프라와 운영 환경을 지원하며, VM웨어가 제공하는 엔드투엔드 인프라 관리 서비스를 더함으로써 기업은 혁신을 가속화하고 비즈니스 가치를 실현할 수 있다”고 말했다. VM웨어와 델 테크놀로지스가 공동 개발한 VM웨어 클라우드 온 델 EMC는 V엑스레일과 긴밀하게 결합된 VM웨어의 컴퓨팅, 스토리지, 네트워크 인프라 소프트웨어로 구성돼 있다. VM웨어 클라...

VM웨어 델 EMC 2019.04.30

도커를 더 강력하게 만드는 오픈소스 툴 12가지

도커(Docker) 관련 툴이 수없이 쏟아지고 있다. 눈 깜짝할 사이에 흥미로운 것을 몇 가지 놓칠 정도다. 특히 도커는 개발 프로젝트와 배포에 충분히 사용할 만한 컨테이너 오케스트레이션을 제공한다. 서드파티 툴의 생태계도 풍부하다. 여기 도커에서 영감을 받았거나 혹은 도커를 더 강력하게 만드는 12가지 오픈소스 툴을 소개한다. 다이브 도커 이미지는 마치 샌드위치 같다. 많은 레이어가 층층이 쌓여 있다. 불투명한 '포장지에 싸인' 샌드위치가 더 정확할 수도 있다. 즉 얼마나 많은 레이어가 있는지 알 수 없거나 포장지 내부에 들어있는 것이 무엇인지 알 수 없는 경우가 있다. 이때 다이브(Dive)를 이용하면 대화식 UI를 통해 도커 이미지 속 레이어를 가시적으로 확인할 수 있다. 각 레이어에 있는 구성요소를 보고, 각 레이어가 어떻게 추가 삭제됐는지도 알 수 있다. 또한 이미지의 사용된 공간과 중복된 공간도 분석할 수 있다. 심지어 CI(continuous integration) 파이프라인에 분석 결과를 넘겨 사용된 공간이 너무 많은 이미지를 빌드 프로세스에서 걸러내는 것도 가능하다. 도커 컴포즈 UI 도커 컴포즈 UI(Docker Compose UI)는 도커 컴포즈에 웹 기반 UI를 추가한 MIT 라이선스 프로젝트다. 파이썬의 플라스크(Flask) 프레임워크를 이용해 개발했다. 컨테이너는 로컬 혹은 원격 호스트에서 실행할 수 있다. 도커 컴포즈 UI 자체는 도커 컨테이너 내에서 편리하게 사용할 수 있다. 단, 도커 컴포즈 UI를 지원하는 일부 데모 프로젝트는 배포 포트 충돌 문제 때문에 확장에 제한이 있을 수 있다. 도클리 도커 작업 대부분은 CLI나 터미널 인터페이스로 처리하는데, 이 기본 도커 CLI는 다른 CLI 프로그램과 크게 다를 바 없이 불편하다. 이때는 도클리(Dockly)가 해법이다. 도커용 풀스크린 터미널 인터페이스를 제공한다. 실행중인 모든 컨테이너에 대한 텍스트 모드 대시보드를 제공하고 컨테이너 로그와 사용 현황을 ...

오픈소스 도커 2019.04.19

How To : 컨테이너 보안을 개선하는 방법

가트너가 컨테이너 보안(container security)을 올해 가장 우려되는 10가지 요소 가운데 하나로 지정했다. 그만큼 주의를 기울이고 견실한 보안 구현 계획을 마련하는 것이 좋다는 의미다. 컨테이너는 약 10년 전에 처음 등장했지만 가벼움과 재사용 가능한 코드, 유연한 기능, 낮은 개발 비용 등의 장점에 힘입어 갈수록 인기를 얻고 있다. 이번 기사에서는 데브옵스/빌드 환경을 보호하는 데 필요한 툴, 컨테이너 자체를 위한 툴, 그리고 모니터링/감사/규정 준수를 위한 툴을 살펴볼 것이다. 물론 어느 한 가지 툴로 모든 작업을 할 수는 없다. 기본적인 단계부터 시작하자 1. 클라우드 업체가 제공하는 툴 확인 첫 번째 단계는 현재 사용 중인 클라우드 업체가 제공하는 기본 보안 툴에 대해 알아보는 것이다. 애저 보안 센터(Azure Security Center), 구글 쿠버네티스 엔진(Google Kubernetes Engine), 구글 클라우드 보안 커맨드 센터(Google Cloud Security Command Center), 아마존 인스펙터(Amazon Inspector) 등이 포함된다. 애저 보안 센터와 같은 일부 보안 툴은 컨테이너 전용이 아닌 범용 보안 툴이다. 2. 네이티브 도커 관련 보안 기능 익히기 여기에는 리소스 오남용 방지를 위한 정책을 사용하고 액세스 제어 그룹을 설정하고 불필요한 루트 액세스 권한을 제거하는 작업이 포함된다. 3. 깃허브 오픈소스 프로젝트  코드에서 보안 모범 사례를 확인하는 벤치 시큐리티(Bench Security)와 같은 프로젝트, 그리고 seccomp(secure computing mode)와 같은 리눅스 네이티브 툴은 저렴한 비용으로 이용할 수 있다. 다른 오픈소스 툴에 대해서는 후설할 것이다. 알고 익혀야 할 소프트웨어가 많아서 부담이 되겠지만 특히 관심을 기울여야 할 몇 가지 공통적인 기능이 있다. 사용자와 최종적으로 빌드하려는 앱, 두 가지 모두에 대한 ID 및 인증, 그리고 이 액세스 권한...

컨테이너 보안 2019.04.17

한국 HPE, HPE 고객 협업사례 발표

한국 HPE는 국내 HPE 고객들과의 성공적인 협업사례를 발표했다. HPE는 HPE 심플리비티(SimpliVity) 및 HPE 그린레이크(GreenLake)의 성공적인 고객 협업사례를 소개해, HPE 제품들이 금융권 및 제조기업의 다양한 업무영역에 효율적으로 적용될 수 있다는 것을 설명했다.   먼저 HPE는 신한은행과 SK E&S, 네패스, 대우조선해양 등에 적용된 HPE 심플리비티 협업사례를 선보였다. HPE 심플리비티는 하이퍼컨버지드 인프라 솔루션으로, 컴퓨팅과 스토리지, 스위치 등 데이터센터 주요 요소를 한 노드에 통합시켜 엔터프라이즈급 성능과 가용성을 제공한다. 데이터 가상화 플랫폼인 HPE 심플리비티는 내장된 하드웨어 I/O가속기로 엔터프라이즈급 성능을 구현하고, 실시간 중복제거와 압축, 로컬 및 원격지 백업을 지원해, 데이터 효율성과 데이터 보호 측면에서 차별화된 성능을 제공한다.  HPE는 블록체인 개발을 위한 신한은행의 클라우드 도입을 돕고자 HPE 심플리비티를 제공했다. 이를 통해 신한은행은 HCI 기반의 컨테이너 서비스를 클라우드에 적용 및 구축할 수 있는 데브옵스 환경을 구현해, 기존 대비 개발 환경에 소요되는 시간을 30% 절감시켰다. 또한 설치 시간을 3배 단축시켜, 블록체인 기반 비즈니스의 요청에 따라 관련 인프라를 제공해 서비스 적시 출시가 가능했다. SK E&S는 실제와 동일한 업무환경 하에서 철저한 PoC를 통해 VDI 환경에 최적인 솔루션을 탐색했으며, HPE 심플리비티의 고성능 및 고집적 데이터 효율에 주목했다. PoC 결과 타 솔루션 대비 배포성능 및 VM 집적도에서 우수한 결과를 보였으며, 특히 높은 중복제거율(46:1)과 기본으로 제공되는 파일단위 백업을 통해 비용 절감 효과도 기대할 수 있게 되었다.  HPE는 HCI 전용 컴퓨팅 노드를 제공하여 VDI 도입 효과를 극대화시켰고, 이를 기반으로 SK E&S의 공유오피스 환경에 적합한 VDI 인프라를 제공하고 ...

HPE 2019.04.16

"포괄 관계→사업 모델별 협력"··· VM웨어, 파트너 정책 '전면 개편'

VM웨어가 2020년 초 새로운 파트너 프로그램을 내놓을 것이라고 공식 발표했다. 기존 파트너 정책에 대한 '완전한 재정비'가 될 것이라고 설명했다. '파트너 커넥트(Partner Connect)'로 알려진 이 새로운 전략은 파트너 업체와 VM웨어가 포괄적인 관계를 맺는 대신, 구체적인 비즈니스 모델에 따라 협력하는 것이 핵심이다. 최근 미국 캘리포니아에서 열린 파트너 리더십 서밋 행사에서 VM웨어는 이 새로운 파트너 정책이 유연성에 염두고 두고 만들어졌다고 설명했다. 등급은 파트너(Partner), 어드밴스드 파트너(Advanced Partner), 프린서플 파트너(Principal Partner) 등 3개 단계로 구성된다. VM웨어의 호주 및 뉴질랜드 상용 비즈니스 및 채널 책임자 케리 앤 터너에 따르면, 이것은 기존 파트너 정책의 일부 수정이 아니라 전면적인 개편이다. 파트너가 원하는 비즈니스 방식과 파트너 지원 정책을 일치시키기 위해 노력의 일환이기도 하다. 그는 "지난 8년간 파트너 정책을 조금씩 수정해 왔다. 그러나 이번에 만든 새 정책은 파트너가 VM웨어 기술을 이용해 성공적인 비즈니스를 만들 수 있는 진화된 프로그램이자 플랫폼이다"라고 말했다. VM웨어의 부사장 겸 전 세계 채널 책임자 제니 플린더스는 "새 파트너 정책은 기존 파트너의 의견을 반영해 만든 새로운 협력 방식이다. 앞으로 이 VM웨어 파트너 커넥트는 모든 비즈니스 모델을 지원하는 단일 파트너 프로그램이 될 것이다. 이 새로운 정책을 통해 공동 판매와 투자가 더 간편해지고, 차세대 VM웨어 기술을 이용해 고객에 더 뛰어난 가치를 제공하는 것이 가능해질 것이다"라고 말했다. 현재 VM웨어의 파트너 프로그램에 영향을 받는 기업은 전 세계적으로 7만 5,000개가 넘는다. 이번 개편에서 가장 눈에 띄는 것은 MSC(Master Service Competency) 인증과 VMC(VMware Cloud on AWS)에...

파트너 채널 가상화 2019.04.08

유클릭, GPU 가상화 솔루션 전문 기업 ‘비트퓨전’과 파트너 계약 체결

유클릭은 GPU 가상화 솔루션 전문기업인 비트퓨전과 파트너십 계약을 체결하고 ‘플렉스다이렉트(FlexDirect)’를 국내 시장에 공급한다고 밝혔다.  비트퓨전의 플렉스다이렉트는 고가의 GPU 자원을 가상화 기술로 경제성과 효율성 높게 사용할 수 있도록 돕는 솔루션이다. 일반 서버 가상화와 비슷하게 물리적으로 흩어져 있는 GPU 서버 자원을 하나의 GPU 풀(Pool)로 구성해 데이터 과학자나 개발자의 필요에 맞게 자원을 할당한다. 이에 따라 기업은 여러 사업부에서 추진 중인 AI와 첨단 분석 프로젝트를 더 빠르고 효율적으로 지원할 수 있다.  유클릭 김광정 상무는 “플렉스다이렉트를 이용하면 한 개의 GPU를 15%, 20%, 30% 등 다양한 크기로 유연하게 나눠 사용할 수 있어 AI 개발 및 관련 서비스 적용을 위해 GPU 자원을 더 정교한 단위로 활용할 수 있다”며 “따라서 자원의 낭비 없이 전사 측면에서 GPU 자원의 경제성을 크게 높일 수 있는데 같은 2~4배까지 비용을 줄일 수 있다”고 말했다.  플렉스다이렉트를 이용하면 기업은 사용 중인 모든 GPU 자원을 하나로 통합할 수 있다. 대다수의 기업들이 AI, 머신 러닝 관련 서비스를 구축하기 위해, AWS, 애저, 구글 클라우드 플랫폼 등의 공용 클라우드의 GPU 인스턴스와 사내에 구축한 GPU 서버 클러스터 인프라 및 개발자용으로 배포한 GPU 기반 워크스테이션 등을 다양한 환경에서 개발과 모델 트레이닝을 진행한다.  플렉스다이렉트는 이더넷, 인피니밴드, RoCE 등 다양한 네트워크 연결로 사내와 공용 클라우드 환경에 있는 다양한 GPU 자원을 하나의 풀로 묶는다. 그리고 데이터 과학자, 개발자의 요구에 맞춰 실시간으로 GPU 자원을 배치한다. 이를 통해 기업은 GPU 자원의 사용률을 극대화 해 비용을 줄이면서도 개발 기간을 단축하는 효과를 거둘 수 있다.  유클릭은 이번 제휴를...

gpu 유클릭 2019.04.08

마이크로서비스 필수 통합 패턴의 이해 : 능동형 합성과 반응형 합성

마이크로서비스 아키텍처는 독립적이고 세분화된, 자율 서비스 모음 형태의 소프트웨어 애플리케이션 빌드를 촉진한다. 따라서 실제 비즈니스 사용례를 구축하는 경우 애플리케이션을 구성하는 마이크로서비스는 서로 커뮤니케이션해야 한다. 세분화된 서비스가 확산되면서 마이크로서비스 통합과 서비스 간 커뮤니케이션 구축은 마이크로서비스 아키텍처 구현에서 가장 어려운 부분 중 하나가 됐다.   마이크로서비스 아키텍처의 난제를 이해하기 위해 먼저 아주 가까운 과거부터 살펴보자. 마이크로서비스 이전의 서비스 지향 아키텍처(SOA)와 웹 서비스 시대에는 모든 서비스 합성과 통합이 구현된 중앙 엔터프라이즈 서비스 버스(Enterprise Service Bus, ESB) 아키텍처가 사용됐다. 예를 들어, <그림 1>에서 볼 수 있듯이 모든 서비스는 ESB와 통합되고 선택된 비즈니스 기능이 API 관리 계층을 통해 소비자에게 노출됐다. ESB는 개별 API, 데이터, 시스템을 통합하기 위해 필요한 모든 기능을 제공했다.   그러나 마이크로서비스 아키텍처로 접어들자 방대한 비즈니스 로직과 모놀리식 통합 계층을 그대로 두고서는 자율성, 협소한 비즈니스 기능 집합 지향성과 같은 마이크로서비스의 근본적인 개념을 구현하기가 매우 어려워졌다. 따라서 중앙 ESB를 통합 버스로 사용하는 방법은 실용성이 떨어진다. 마이크로서비스 아키텍처에서 마이크로서비스는 스마트 엔드포인트와 단순 파이프 스타일을 사용하여 통합되며, 여기서 모든 인텔리전스는 엔드포인트에 위치하고 엔드포인트 간 상호 연결은 단순 메시징 인프라를 통해 이뤄진다. <그림 2>에서 볼 수 있듯이 파악된 비즈니스 기능을 위한 마이크로서비스를 설계할 수 있으며, 이들은 다양한 비즈니스 사용례를 실현하기 위해 상호 커뮤니케이션해야 한다.   모놀리식 앱과 중앙 ESB를 해체하고 이 기능을 각 서비스로 분담하는 것은 말로는 간단하지만 사실 여러 난관이 있다. 따라서 일반적인 마이크로서비스 ...

아키텍처 통합 ESB 2019.03.29

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

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

Copyright © 2022 International Data Group. All rights reserved.