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.

오케스트레이션

블로그 | 클라우드에 살아 있는 전통적인 아키텍처의 문제

많은 기업의 클라우드 컴퓨팅 경험이 해를 거듭하면서 일부 전통적인 IT 아키텍처 개념이 다시 튀어나오기 시작했다. 이들 개념이 클라우드 배치를 가능하게 만들 수도 있고, 아니면 망가뜨릴 수도 있지만, 오늘날 클라우드 컴퓨팅 시스템을 설계하고 구축하고 배치하는 사람들은 까맣게 잊어버린 것들이다. 어떻게 이런 일이 일어나는 것일까?   두 가지 요인이 있다. 첫째, 특정 클라우드 서비스 업체가 진행하는 아키텍처 자격 인증 과정이 일반적이고 기본적인 아키텍처 교육의 많은 부분을 빼먹는다. 둘째, 많은 현대적인 툴이 클라우드 아키텍처 솔루션을 둘러싼 세부 사항에 대해 생각할 필요가 없게 만들기 때문이다. 모든 클라우드 아키텍트는 가장 최적화된 클라우드 컴퓨팅 아키텍처를 만들기 위해 핵심 IT 아키텍처 개념을 온전하게 이해할 필요가 있다. 단일 클라우드이든 멀티클라우드이든 마찬가지다. 많은 사람이 쉽게 간과하는 개념 세 가지를 소개한다. 추상화. 추상화는 매우 복잡한 것들을 다룬다. 엉성하게 설계된 데이터베이스나 과도하게 복잡한 네트워크 설계, 지나치게 까다롭게 만든 애플리케이션 같은 것들이다. 추상화는 이런 자원을 사용하는 사람이나 애플리케이션을 위해 한층 더 단순화된 시야를 그 위에 올려준다. 클라우드 시스템에서 추상화의 가장 좋은 예는 데이터 가상화일 것이다. 어떤 종류의 물리 데이터 스토리지 시스템이라도 그 위에 추상화 계층이나 가상 데이터 구조를 배치하면, 데이터베이스가 얼마나 엉망으로 설계되었든지, 얼마나 많은 애플리케이션이 실제 데이터베이스와 밀접하게 연결되어 있든지 관계없이 자체 정의한 구조를 사용해 데이터를 이용할 수 있다. 자체 정의한 구조는 어떤 백엔드 데이터베이스 구조라도 매핑할 수 있다. 결론적으로 어떤 복잡한 혹은 대충 설계한 데이터베이스라도 물리 데이터 구조 위에 추상화 계층을 사용하는 자체 액세스 구조를 이용해 처리할 수 있다. 물리 데이터베이스를 변경하지 않고, 해당 데이터베이스와 연결된 모든 애플리케이션도 변경하지 않...

자동화 추상화 오케스트레이션 2022.07.04

컨테이너 분야의 '요즘 애들', 포드맨을 아시나요?

포드맨(Podman)은 ‘컨테이너 엔진’이다. 즉, 컨테이너 및 컨테이너 이미지를 개발, 관리, 실행하기 위한 도구다. 레드햇의 프로젝트인 포드맨은 지난 2019년 버전 1.0이 출시됐으며, 컨테이너 업계에서는 비교적 신참이다. 이후 포드맨은 약진을 거듭했으며, 오늘날의 컨테이너 세계를 만든 프로젝트인 도커(Docker)의 점진적인 쇠퇴로 이런 포드맨의 상승세가 더욱 부각되고 있다.    포드맨과 쿠버네티스 컨테이너 기반 개발을 조금이라도 안다면 ‘쿠버네티스(Kubernetes)’도 알 것이다. 컨테이너화된 애플리케이션이 점점 더 복잡해지면서 개발자는 다양한 가상머신, 심지어는 서로 다른 물리적 머신에서 실행되면서 상호작용하는 컨테이너를 조정할 수 있는 툴이 필요했다.  이런 툴을 ‘컨테이너 오케스트레이션 플랫폼’이라고 하는데, 그중 쿠버네티스가 가장 유명하다. 쿠버네티스는 오픈 컨테이너 이니셔티브(Open Container Initiative; OCI) 이미지 사양을 충족하는 모든 컨테이너에 사용할 수 있으며, 포드맨의 컨테이너도 마찬가지다. 쿠버네티스의 중요한 특징으로 ‘포드(pod)’ 개념이 있다. 포드란 쿠버네티스가 관리할 수 있는 최소의 컴퓨팅 단위인 하나 이상의 컨테이너를 임시로 그룹화한 것이다. 포드맨 역시 이름에서 알 수 있듯이 포드 개념을 기반으로 한다. 포드맨 포드에도 단일 네임스페이스, 네트워크, 보안 컨텍스트로 그룹화된 하나 이상의 컨테이너가 포함돼 있다. 이런 유사점 때문에 포드맨과 쿠버네티스는 자연스럽게 어울린다. 처음부터 레드햇의 목표는 포드맨 사용자가 쿠버네티스로 컨테이너를 오케스트레이션하는 것이었다. 포드맨 vs. 도커 컨테이너 세계에서 틀림없이 들어봤을 또 다른 거물급 이름은 도커다. 도커는 최초의 컨테이너 엔진은 아니지만, 여러 면에서 컨테이너화를 정의했다. 도커의 작동 방식 중 대부분이 컨테이너 기반 개발의 사실상 표준이고, 많은 사람이 컨테이너를 ‘도커’라고 부를 정도다. 도커...

컨테이너 도커 포드맨 2022.06.24

메르세데스 벤츠가 900개의 쿠버네티스 클러스터를 운영하는 이유

독일 자동차 회사 메르세데스 벤츠(Mercedes-Benz)의 기술팀은 지난 7년 동안 수백 개의 개별 개발팀을지원하기 위해 자체 개발한 쿠버네티스 클러스터 900개를 구축했다. 이로써 메르세데스 벤츠는 확장 가능하고 관리가 용이하다는 최신 인프라 플랫폼을 갖추게 됐다.   메르세데스 벤츠는 2014년 구글이 컨테이너 오케스트레이션 시스템인 쿠버네티스를 오픈소스화한 후 2015년부터 애플리케이션 배포 목적으로 쿠버네티스를 활용하기 시작했다. 이후 메르세데스 벤츠의 IT 전문 자회사인 메르세데스 벤츠 테크 이노베이션(Mercedes-Benz Tech Innovation)은 내부 전문 역량을 개발해 사업부와 연동되어 각자 고유한 기술 수요가 있는 수백 개의 애플리케이션팀을 지원하고 있다. 메르세데스 벤츠 테크 이노베이션 데브옵스 엔지니어 젠스 에랏은 최근 개최된 쿠버콘(KubeCon) 유럽 행사에서 “단일 공유 쿠버네티스 클러스터는 우리의 수요에 맞지 않고 우리의 요구사항에 맞는 업체 배포판도 없다는 사실을 알고 있었다. 대신 우리는 전문 기술을 갖춘 엔지니어가 있었다”라며, “동일한 데브옵스팀이 구축하고 개발한 100% 오픈소스 소프트웨어 플랫폼을 구축했고, 라이선스 문제도 기술 지원도 없었다”라고 밝혔다. 현재 메르세데스 벤츠는 네 곳의 글로벌 데이터센터에서 900개의 온프레미스 쿠버네티스를 운영 중이다. 2021년 말부터 버전 1.23을 실행 중인 오픈스택(OpenStack)을 사용한다.  이런 쿠버네티스 자산은 클라우드 서비스 업체와 비교하면 아주 큰 규모는 아니다. 하지만 클라우드 네이티브 컴퓨팅 재단(CNCF)의 2019년 조사에 따르면, 50개 이상의 클러스터를 사용하는 조직의 비율은 10%에 불과하다. 또한, 메르세데스 벤츠의 쿠버네티스 자산 규모는 쿠번콘 유럽에서 함께 기조 연설을 했고 이 기사 작성 시점 현재 210개의 클러스터를 운영 중인 CERN의 쿠버네티스 환경보다 거의 다섯 더 크다. 메르세데스 벤츠를 쿠버네티...

쿠버네티스 오케스트레이션 벤츠 2022.06.23

"우리 기업에 맞는 RPA를 찾아라" 자동화ㆍ오케스트레이션 툴 10가지

IT 프로세스 자동화의 효과는 따로 설명이 필요 없다. 작업을 자동화하는 것은 인건비를 들여 반복적인 작업을 수행하는 방식에 비해 비용이 덜 들고 더 효율적이며 예측 가능하다. 기업 내부적으로 자동화 툴을 개발할 수도 있지만 쉽지 않은 일이므로 자동화를 본격적으로 도입하기 위해서는 상용 소프트웨어를 사용해야 할 수 있다.   IT 시스템 관리, 물리/가상 머신 프로비저닝, 서버 구성 관리, 정책 이탈 식별 등은 자동화하기 쉬운 작업에 속하며, 지금은 많은 IT 시스템이 상용 플랫폼 없이도 비교적 쉽게 자동화할 수 있는 기능을 내장하고 있다. 또한 지난 10년 동안 다양한 시스템의 자동화가 가능해졌다. 예를 들어 윈도우 파워셸과 파이썬은 학습 난이도가 비교적 낮아 관리자가 자동화 작업을 시작하는 데 도움이 된다. 그러나 더 복잡한 자동화는 다르다. 자동화를 구축하기 위한 전반적인 기술적 역량을 확보하기 쉽지 않고 자동화되는 프로세스를 이해하기도 어려워 DIY 방식 자동화의 걸림돌이 될 수 있다. 따라서 많은 기업에서 자동화를 진전시키기 위해서는 오케스트레이션이 필요하다. 오케스트레이션은 자동화 작업을 언제, 어떻게 실행할 것인지 정의하고 작업 실행 성능을 모니터링하고 워크플로우 기반 의사 결정 트리를 통해 더 진보된 자동화를 구현하는 복합적인 프로세스다. 오케스트레이션은 변경 관리 프로세스를 강화하는 데도 도움이 된다. 변경 사항을 테스트 그룹에 적용하고 동료 평가를 거쳐 더 폭넓게 적용하고 필요한 경우 되돌릴 수도 있기 때문이다. 오케스트레이션을 통해 적용된 변경은 비즈니스 또는 규정 요구사항을 충족하기 위해 감사, 보고하기도 쉽다. 기업마다 상황은 다르고, 보안과 워크로드, 필요한 시야의 다양한 조합에 따라 적절한 자동화 및 오케스트레이션 플랫폼을 위한 요구사항이 결정된다. 어떤 툴이 있고, 이 툴이 조직에 어떤 가치를 제공할 수 있을까? 적절한 툴을 찾는 과정에 도움이 되도록 10가지 제품을 정리했다.   액티브배치 액티브배...

RPA 자동화 오케스트레이션 2022.06.21

컨테이너 및 쿠버네티스 기반의 워크로드 채택 현황

애플리케이션들은 점차 개별 기능 단위로 구축되고 있으며, 각 기능은 컨테이너로 제공이 가능합니다. 이는 모든 애플리케이션에서 관리 대상이 더 많아졌다는 사실을 의미합니다. 복잡한 상황을 해결하기 위해, 컨테이너가 어디에서, 어떻게 실행되어야 하는지를 관할하는 정책 기반의 자동화 솔루션이 필요합니다. 쿠버네티스는 확장 가능한 오픈소스 컨테이너 오케스트레이터로서, 이런 과제 해결을 목적으로 합니다. Pulse와 Red Hat은 컨테이너/쿠버네티스에 어떤 워크로드를 배포하고 있는지, 그리고 주요 비즈니스 목적과 목표 달성을 돕는 쿠버네티스 오퍼레이터와 헬름 차트의 사용을 비롯, 하이브리드 및 멀티 클라우드 전반의 워크로드 배포 방식과 그 이유를 파악하고자 다양한 산업 소속의 대기업 IT 리더 200명을 대상으로 설문조사를 실시했습니다. 주요 내용 - 쿠버네티스 및 컨테이너 워크로드의 효과 - 쿠버네티스 및 컨테이너 워크로드/애플리케이션 활용 현황 - 스테이트리스, 스테이트풀 워크로드 비율 - 애플리케이션 현대화 과정의 과제 

컨테이너 쿠버네티스 오케스트레이션 2022.05.02

쿠버네티스 보안 강화를 위한 NSA/CISA 가이드 분석

쿠버네티스는 컨테이너 오케스트레이션을 위한 사실상의 표준이다. 기업의 88%가 컨테이너 오케스트레이션에 쿠버네티스를 사용하고, 그중 74%가 프로덕션 환경에 사용한다는 조사 결과도 있다. 그러나 보안은 여전히 중대한 우려 사항으로, 기업의 94%가 지난 12개월 사이 쿠버네티스 환경에서 한 번 이상 보안 사고를 겪은 것으로 나타났다.    조직이 안전하게 쿠버네티스를 사용하기 위해서는 쿠버네티스를 도입할 때 업계 베스트 프랙티스와 가이드를 따르는 것이 중요하다. 미국 국가안전국(NSA)과 사이버 보안 인프라 보안국(CISA)이 최근 발행한 쿠버네티스 강화 가이드(Kubernetes Hardening Guidance)는 좋은 참고 자료다.  그 외에 쿠버네티스를 위한 유용한 보안 가이드와 서적으로는 인터넷 보안 센터(CIS) 쿠버네티스 벤치마크, 미국 국방부 쿠버네티스 보안 기술 구현 가이드(STIG), 그리고 아쿠아 시큐리티(Aqua Security)의 리즈 라이스와 마이클 하우젠블라스가 쓴 쿠버네티스 보안(Kubernetes Security)이 있다.  쿠버네티스 보안 강화 가이드는 쿠버네티스 보안 위험의 일반적인 발생지를 세 가지로 분류한다. 공급망 위험, 악성 위협 행위자, 내부자 위협이다. 또한 위협 모델링, 쿠버네티스 포드 보안, 네트워크 분리 및 강화, 인증과 권한 부여, 로그 감사, 업그레이드, 애플리케이션 보안 베스트 프랙티스와 같은 중요 영역에 걸쳐 세부적인 내용을 제공한다.  가이드의 도입부에는 쿠버네티스의 핵심 아키텍처 구성요소에 대한 설명이 나와 있다. 중심에는 클러스터가 있고 제어 플레인, 노드, 노드에 위치하는 포드와 같은 클러스터의 핵심 구성요소가 포함된다. 쿠버네티스가 어떻게 기능하고 구성요소가 어떻게 상호작용하며, 궁극적으로 이를 어떻게 보호해야 하는지를 이해하려면 이와 같은 핵심 구성요소를 이해해야 한다.    제어 플레인(Control Plane)&nb...

쿠버네티스 컨테이너 오케스트레이션 2021.08.25

엔터프라이즈 데이터 오케스트레이션 : 데이터 전략 및 인프라의 핵심 요소

데이터의 양과 중요성이 증가함에 따라 데이터 관리의 복잡성도 증가합니다. 특히 데이터가 엔드 포인트에서 엣지, 코어 및 클라우드 데이터 센터에 이르기까지 모든 곳에 분산되면서, 현대의 분산된 엔터프라이즈에는 데이터 이동 및 오케스트레이션을 위한 새로운 방법이 필요합니다. 데이터 오케스트레이션은 더욱 정교해져야 합니다. 데이터 수명 주기의 모든 차원과 데이터를 효과적으로 활용하는 조직의 능력에 미치는 영향을 고려해야 합니다. 특히 데이터 사용 방법, 이동 방법, 대규모로 관리하는 방법을 이해하여 데이터를 사용할 수 있게 만들고 보호하며 분석 및 활용할 수 있도록 만들어야 합니다. <12p> 주요 내용 - 더욱 정교해져야 하는 데이터 오케스트레이션 - 데이터가 사용되는 방식 : 데이터 수명 주기 - 엔터프라이즈 전체에서의 데이터 이동 - 대규모 데이터 오케스트레이션 요구 사항

오케스트레이션 수명주기 마이그레이션 2021.07.30

IDG 블로그 | 쿠버네티스가 답이 아닐 때

쿠버네티스는 많은 환경에서 견실한 해법을 제공하는 강력한 최신 기술이다. 내로라하는 기업이 모두 쿠버네티스 관련 기술을 선택한 것으로 보일지 모르겠지만, 모든 애플리케이션에 맞는 기술은 아니다. 어떤 기술이 이렇게 많은 지지자를 확보하면, 해당 기술을 사용하는 것이 이미 정해진 결론이 되기도 한다. 하지만 바로 이때 실수가 생기고 프로젝트가 탈선한다.   클라우드 기반 플랫폼으로 이전하려는 기업 대부분은 컨테이너와 쿠버네티스 사용을 생각한다. 클라우드를 사용하는 기업의 많은 수가 이미 쿠버네티스를 사용하고 있다. 쿠버네티스는 마이크로서비스를 포함해 분산 시스템을 좀 더 쉽게 관리하고 확장할 수 있는 많은 자원을 제공한다. 또한 오케스트레이션 시스템으로, 프로세스와 서비스를 묶어 좀 더 크고 통일적인 솔루션으로 구축할 수 있다. 공식 쿠버네티스 문서화 웹 사이트에 제시된 것처럼, “쿠버네티스는 복구성 있는 분산 시스템을 구동하는 프레임워크를 제공한다. 쿠버네티스는 애플리케이션의 확장과 페일오버를 관리하며, 배치 패턴 등을 제공한다.” 자동화와 오케스트레이션은 쿠버네티스를 이용하는 주된 이유 중 하나이다. 그런데 자동화와 오케스트레이션은 종종 혼동되기도 한다. 자동화는 소프트웨어나 하드웨어가 특정 작업을 수행하는 데 인력의 개입을 줄이거나 제거해 비즈니스 프로세스를 더 효율적으로 만드는 것이다. 예를 들어, 자동화는 어떤 프로세스에서 특정 원료의 공급이 일정 수준 이하인 것을 발견하면 자동으로 원재료를 재주문하는 프로세스를 실행할 수 있다. 이와는 달리 오케스트레이션은 워크플로우를 자동화한다. 오케스트레이션은 정해진 순서와 활동이 지켜지도록 하는 것이 주된 역할이며, 워크플로우의 일부인 단일 작업의 자동화를 시작할 수도 있다. 오케스트레이션은 쿠버네티스의 강력한 무기로, 서로 다른 시스템에 걸쳐 데이터베이스를 액세스해야 하는 서비스를 가능하게 해준다. 지금의 문제는 많은 개발자와 아키텍트가 오케스트레이션 엔진을 사용해 프로세스를 자동화하려고 쿠...

쿠버네티스 마이크로서비스 컨테이너 2021.01.27

IT 관리 - 하이브리드 클라우드 조정 및 단순화

이미 여러 클라우드 서비스를 사용하고 있으시다면, 클라우드의 무한한 가능성을 실현해 줄 미래 지향적이고 효과적인 전략을 제시하고 있나요? 귀사의 전략 혁신을 가속화하고, 성공적인 IT 운영의 기본 요소인 가시성, 거버넌스, 자동화 기능을 실현해 주고 있나요? IBM의 멀티클라우드 솔루션을 사용하면 온프레미스에서 에지까지 귀사의 여러 클라우드 환경을 효율화 및 조정, 최적화하고 비용을 절감하는 동시에 여러 비즈니스 이점을 실현할 수 있습니다. 지능적인 운영, 애플리케이션, 멀티클라우드 관리 솔루션이 어떻게 민첩성과 유연성을 향상시키는 방법을 확인하시기 바랍니다. <8p> 주요 내용 - 멀티클라우드를 효과적으로 관리하는 방법 - 멀티클라우드 관리: IT 관리의 핵심 요소 - 멀티클라우드 솔루션의 중요 3대 기능 - 멀티클라우드 관리: IBM이 제공하는 지원

멀티클라우드 오케스트레이션 온프레미스 2021.01.11

IDG 블로그 | 3년 뒤의 클라우드 보안

최근 몇 년 동안 클라우드 보안은 온프레미스 보안보다 뛰어났다. 날로 강화되는 자동화와 상호호환성으로 클라우드 보안은 베스트 프랙티스 자리를 확실히 굳힐 것이다. 가트너는 2020년 한 해 동안 퍼블릭 IaaS 워크로드는 전통적인 데이터센터의 워크로드보다 보안 사고를 최소한 60% 더 적게 겪을 것이라고 밝혔다. 필자가 여러 해 전 이런 이야기를 하면, 많은 사람이 코웃음을 쳤다. 하이퍼스케일 업체와 서드파티 보안 서비스 업체 모두 자사 연구개발 예산의 70~80%를 퍼블릭 클라우드를 지원하는 데 사용하고 있다. 클라우드 보안 기술 대부분의 품질과 기능성이 전통적인 온프레미스 보안 시스템보다 뛰어난 것은 당연한 일이다. 그렇다면 클라우드 보안은 앞으로 어떤 모습일까? 필자가 생각하는 향후 3년의 클라우드 보안 지형은 다음과 같다.  모든 것의 자동화. 현재는 일부 보안 시스템이 기존 프로세스를 자동화하지만, 5년 이내에 자동화는 한 단계 더 발전할 것이다. 잠재적인 위협에 대한 극히 역동적인 인터랙션이 자동으로 일어날 것이며, 머신러닝 시스템을 기반으로, 공격을 찾고 막기 위해 수많은 클라우드의 수많은 자원을 오케스트레이션해 이용할 것이다.  이를 통해 클라우드 보안은 수동적인 상태에서 능동적인 상태로 바뀔 것이다. 더는 공격이 일어나길 기다리지 않고, 공격이 임박했는지를 탐색해 첫 침입 시도가 있기 전에 자동화된 방어 기술로 공격자를 막을 것이다. 경우에 따라서는 자동화된 반격을 실행할 역량도 갖추게 될 것이다. 인터클라우드 보안에 중점. 멀티클라우드 세상이 되면서 각 퍼블릭 클라우드의 네이티브 보안 시스템을 사용하는 것은 너무나 손이 많이 가는 방법이며, 사고로 이어질 수 있는 복잡성과 혼란을 야기한다는 사실을 알게 됐다.  필자가 전에도 분명히 말했듯이, 멀티클라우드는 클라우드에 관한 문제가 아니다. 멀티클라우드는 클라우드 사이에 있는 기술에 대한 문제이다. 이 기술은 네이티브 인터페이스에 액세스하지만, 논리적으로는...

클라우드보안 자동화 인터클라우드 2020.11.09

“데이터센터에 필요한 것은 더 빠른 스위치와 지능” 옴디아 조사

데이터 소비의 증가로 IT 관리자의 요구사항도 변하고 있다. 옴디아(Omdia, 구 HIS markit)의 조사에 따르면, 데이터센터 관리자가 필요로 하는 것은 모든 종류의 지능화인 것으로 나타났다.   옴디아는 최근 북미 지역에 사무실과 데이터센터를 두고 있는 지원 100명 이상 기업 140곳의 IT 책임자를 대상으로 설문 조사를 실시해 네트워킹 기술에서 가장 필요로 하는 것이 무엇인지를 물었다. 응답자들은 2019년~2021년 사이에 데이터센터 사이트의 수가 두 배, 그리고 데이터센터 내에 배치하는 서버의 수가 두 배로 증가할 것이라고 예상했다.  보고서는 “기업의 온프레미스 데이터센터는 계속 번창하고 있다”라며, “2018년 조사에서도 응답자들은 기업 데이터센터 성장 단계가 계속될 것이라고 답했으며, 이번 조사에서도 확인됐다. 온프레미스 데이터센터는 클라우드 아키텍처로 계속 혁신하고 있으며, 기업이 멀티클라우드 환경을 구축하고 컴퓨팅을 엣지로 이전하면서 자체 데이터센터는 ‘1등 시민’으로 대접받고 있다”라고 분석했다. 하지만 조사 결과는 서버 장비보다는 네트워킹의 필요성을 더 강조한다. 응답자의 60%가 같은 기간에 이더넷 스위치, 파이버 채널 스위치, 네트워크 분석, 네트워크 자동화에 대한 투자가 증가할 것이라고 예상한다. 데이터센터 이더넷 스위치 포트의 설치 기반은 27% 증가하고 100GbE 이상의 고속 이더넷이 더 큰 비중을 차지할 것이다.  응답자 65%가 빠른 속도, 개방성과 상호호환성, 애플리케이션 인지 기능을 데이터센터 이더넷 스위치를 구매할 때 고려하는 요소라고 답했다.  오픈 컴퓨트 프로젝트 인증 스위치를 사용하는 응답자의 비율도 크게 증가했다. OCP 스위치를 도입한 응답자는 2019년 60%에서 76%로 증가했다. OCP 인증 베어메탈 스위치는 현재 엣지코어나 델타 네트웍스, 멜라녹스/엔비디아 등 여러 업체에서 구매할 수 있다. 점점 더 많은 데이터센터 트래픽이 중앙 데이터센터에서 엣...

이더넷스위치 옴디아 설문조사 2020.07.24

모놀리스로부터 마이크로서비스로의 이전을 위한 개발자 가이드

클라우드 네이티브 개발은 컨테이너 및 오케스트레이션 기반의 클라우드 배포를 통해 마이크로서비스를 이용하려는 조직에게 그 중요성이 점차 커지고 있습니다. 하지만 시간 및 비용상 요건으로 인해 모든 레거시 애플리케이션을 완전히 재작업하기란 거의 불가능합니다.  Red Hat의 단계별 클라우드 마이그레이션 접근 방식은 기존의 기능과 데이터를 최대한 다시 사용합니다. 이 프로세스는 기존 워크로드를 현대식 배포 플랫폼으로 이전하고, 궁극적으로 새로운 프로세스, 제품, 기술을 적용해 애플리케이션을 현대화합니다. 이와 함께 MicroProfile 사양을 구현하는 Thorntail, Spring Boot, Node.js 및 Eclipse Vert.x 등의 플랫폼으로 개발자가 제어하고 선택하여 클라우드에 마이크로서비스를 구현할 수 있습니다. <9p> 주요 내용 - 마이크로서비스로 리팩토링하기 위한 기능 분석  - Red Hat Runtimes  - 마이크로서비스를 위한 오픈소스 기술 선택 

클라우드네이티브 마이크로서비스 컨테이너 2020.07.02

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

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

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

Cloud Paks : 비즈니스 애플리케이션을 클라우드로 빠르고 안전하게 전환하는 개방형 솔루션

신규 클라우드 네이티브 애플리케이션을 구축하거나 클라우드 환경을 지원하기 위해 기존 애플리케이션을 현대화하는 두 가지 전략 모두, 특정 기술이나 업체에 종속되지 않으면서 가치 대비 소요 시간을 단축할 수 있으려면, 이동이 가능하고 개방된 방식으로 진행해야 합니다. 이 때문에 현재 기존 기업 워크로드의 80%는 아직 클라우드로 이전되지 못했으며, 기업들은 클라우드에서의 이동, 연결 및 관리에 어려움을 겪고 있습니다. Cloud Paks는 최신 Kubernetes 기반 오케스트레이션 플랫폼에서 우수한 컨테이너 기반 엔터프라이즈 소프트웨어를 실행하는 강력하면서도 간편한 방법을 제공합니다. 이 문서에서는 이 모델이 제공하는 부가적인 가치를 중심으로, 기본적으로 적용된 개방형 기술에 대한 전반적인 세부사항을 포함한 개념으로 Cloud Paks을 설명합니다. 주요 내용 - 더 많은 워크로드를 더 빨리 클라우드와 AI로 이전하는 IBM의 해결책 - 컨테이너 형태로 엔터프라이즈 소프트웨어 배치 및 관리 간소화 - 프로덕션 환경에 적합한 이미지 구축 - 손쉽게 사용 가능한 완전한 모듈형 기능

자동화 인공지능 컨테이너 2019.12.19

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

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

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

IDG 블로그 | 클라우드 네이티브에 전부를 걸어야 하는가

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

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

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

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

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

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

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

Copyright © 2022 International Data Group. All rights reserved.