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.

컨테이너

하이브리드 멀티클라우드를 위한 스토리지 현대화 전략 - IDG Tech Webinar

클라우드를 사용하지 않는 기업은 있어도 한 곳만 사용하는 기업은 없다는 말이 있다. 그만큼 하이브리드 멀티클라우드는 이른바 ‘뉴 노멀’이 되었다. 문제는 이런 환경을 제대로 활용하기 위해서는 기업의 IT에도 많은 변화가 필요하다는 것. 온프레미스부터 여러 퍼블릭 클라우드로 애플리케이션과 데이터가 흩어져 있기 때문에 기존의 구축 및 배치 방식으로는 IT의 임무를 제대로 달성하기 어렵다. 특히 온프레미스와 클라우드 간의 잦은 데이터 이동이 일상화되고 있는 상황에서 스토리지 역시 적지 않은 변화가 필요하다.  이번 웨비나는 민첩성부터 데이터 보호, 클라우드, 신기술 지원 등 스토리지의 핵심 요소를 살펴보고, 하이브리드 클라우드를 향한 기업의 여정에서 현대화된 스토리지가 어떤 역할을 하며, 또 이를 위해서는 어떤 스토리지가 필요한지 알아본다.  주요 내용 하이브리드 멀티클라우드 환경로의 전환 흐름 스토리지 소프트웨어의 중요성 하이브리드 멀티클라우드 환경을 위한 스토리지 소프트웨어 IBM Spectrum Virtualize의 특징과 구현 형태 IBM FlashSystem 제품군과 특징

하이브리드 컨테이너 멀티클라우드 2020.04.03

IDG 블로그 | 라즈베리 파이, 새로운 프라이빗 클라우드

라즈베리 파이는 작고 다재다능하고 저렴한 컴퓨터로 어디에나 쓸 수 있다. 이제는 프라이빗 클라우드로도 사용할 수 있다. 라즈베리 파이는 진짜 라즈베리 파이보다 더 싸다는 농담이 있다. 물론 파이 하나 먹는데 50달러나 100달러를 낼 사람은 없겠지만, 라즈베리 파이는 작은 크기에 네트워킹 기능을 갖추고 오픈소스 소프트웨어를 구동하는 매우 능력 있는 컴퓨터를 전문가는 물론 애호가에게도 부담없는 금액에 제공한다.   필자는 라즈베리 파이를 IoT 디바이스로 몇 년째 사용하는데, 데이터를 모으고 저장하고 처리하고 전송할 수 있으며, 필요하면 데이터에 반응할 수도 있다. 그래서 많은 사람이 라즈베리 파이를 모터사이클 주행 안전기 프로젝트와 기타 완전히 새로운 IoT/엣지 개발 프로젝트 등에 사용하고 있다. 그런데 라즈베리 파이의 사정이 좀 바뀌었다. 필자는 k3s 프로젝트를 행복한 마음으로 보고 있는데, 이 프로젝트는 “자원이 극히 제한된 환경”에서 사용할 경량화된 쿠버네티스 배포판을 만든다. 오픈소스이고 ARM 프로세서에 최적화되어 있다. 무엇보다도 k3s는 라즈베리 파이 전용으로 만들어진 쿠버네티스 배포판이기 때문에 라즈베리 파이 기반 쿠버네티스 클러스터를 실현할 수 있다. 물론 그만큼의 제약도 있다. 클라우드 아키텍트는 이 기술을 이용해 쿠버네티스 클러스터를 중앙집중화된 클라우드에서 구동하는 컨테이너에 배치하는 것이 아니라 데이터 소스와 좀 더 가까이 있는 소형 컴퓨터에 배치할 수 있다. 애플리케이션은 퍼블릭 클라우드 플랫폼과 수백 수천 대의 k3s 구동 라즈베리 파이 사이에 뿌려지겠지만, 클러스터는 여전히 긴밀하게 통합되어 있다. 이는 분명 수천 가지 사용례를 가진 엣지 컴퓨팅의 한 형식이 될 것이다. 이 아키텍처 패턴이 필자를 놀라게 한 것은 저렴한 엣지 기반 디바이스가 경량화된 프라이빗 클라우드처럼 동작한다는 것이다. 이들 디바이스는 자원을 필요한 만큼 프로비저닝하고 컨테이너와 쿠버네티스 같이 많이 사용되는 플랫폼을 사용한다....

배포판 컨테이너 프라이빗클라우드 2020.03.16

비자가 컨테이너 보안 솔루션을 "자체적으로" 구축한 방법

금융 서비스 시장의 대기업인 비자(Visa)도 다른 많은 대기업과 마찬가지로 컨테이너화(containerization) 기술을 도입했다. 컨테이너화는 레거시 모놀리식 앱을 사용하는 기업이 클라우드 인프라에서 대규모로 관리, 업데이트, 배포하기가 더 용이한 마이크로서비스 기반 애플리케이션 아키텍처로 전환할 수 있게 해준다.   비자의 보안 팀은 여러 상용 솔루션을 조합해 이를 자체 환경에 맞춰 운영하느라 리소스를 소비하는 대신 기본으로 돌아가 보안 정책 시행, 사고 탐지 및 교정을 위한 지속적 모니터링 솔루션을 자체적으로 개발했다.  비자는 이 프로젝트로 우수한 보안에 수여되는 CSO50 상을 수상했다. 매시업(Micro-services based Adaptive Security Hardening and Usage Platform, MASHUP)으로 불리는 이 솔루션은 파일시스템 액세스 컨트롤, SE리눅스(SELinux) 정책, 그리고 cgroups(control groups)와 같은 기존 컨테이너 오케스트레이션 플랫폼에 이미 있는 기본 기능을 활용하며 주로 오픈소스 툴과 라이브러리를 기반으로 만들어졌다. 만들기 대 구매하기 비자가 기존 공급업체의 상용 솔루션을 구매하는 대신 자체 보안 플랫폼을 만들기로 한 데는 여러 가지 이유가 있다. 첫째, 컨테이너 기반 인프라와 컨테이너화된 앱을 위한 보안 솔루션을 제공하는 공급업체의 상당수가 신생 업체라는 점이다. 신생 업체의 경우 대규모 조직이 기대하는 성숙도 표준을 아직 충족하지 못하는 경우가 많다. 또한 컨테이너를 위한 모니터링 및 보호 기능이 일부 조직에는 불필요한, 훨씬 더 넓은 범위의 기능 집합에 포함된 제품도 있다. 비자는 10%의 필요한 기능을 위해 나머지 90%의 불필요한 기능까지 함께 구매하기는 원하지 않았다. 비자가 솔루션을 직접 만들기로 한 또 다른 중요한 이유는 개발 유연성(flexibility)과 민첩성(agility)이다. 플랫폼에 대한 통제권을 온전히 손에 쥔다는...

Visa 컨테이너 비자 2020.03.12

실험 단계 넘어 주류로 진입하는 컨테이너

에디슨이 전구를 발명할 당시 가장 어려운 문제는 램프와 소켓을 결합하고 분리하는 것이었다. 이런 불편을 개선한 에디슨 스크류는 오늘날까지 거의 모든 전구를 책상 램프든 샹들리에든 대부분의 조명기구에 돌려서 끼울 수 있는 표준이 되었다.  10년 전 솔로몬 하익스의 도커 컨테이너 발명도 비슷한 효과를 낳았다. 어떤 리눅스 앱이든 패키징을 한번 하면 모든 리눅스 운영체제의 모든 도커 컨테이너에 연결할 수 있고, 번거로운 설치가 필요 없다. 더 좋은 건 여러 컨테이너화된 앱이 운영체제의 단일 인스턴스에 연결되고, 각 앱은 다른 앱과 안전하게 격리되어 도커 API를 통해 OS와만 통신할 수 있다는 점이다.  이 공유 모델은 물리적 컴퓨터에서 클라우드와 같은 방식으로 애플리케이션을 배포하고 확장하기 위한 기존의 수단인 가상머신보다 훨씬 가벼운 스택을 제공했다. 실제로 가볍고 휴대성이 뛰어나기 때문에 개발자는 노트북에서 여러 컨테이너화된 앱을 작업하고, 테스트 및 배포를 위해 선택한 플랫폼에 업로드할 수 있다. 또한 일반적으로 부팅 시 1분 정도 걸리는 가상머신과는 달리 컨테이너화된 앱은 눈 깜짝할 사이에 시작한다. 그러나 컨테이너의 실제 영향을 파악하려면 애플리케이션 아키텍처의 마이크로서비스 모델을 이해해야 한다. 많은 애플리케이션이 API를 통해 서로 통신하는 작은 단일 목적의 서비스로 세분화되어, 각 마이크소서비스를 독립적으로 업데이트하거나 확장할 수 있는 장점이 있다(전체 변경 사항을 가져와 수정해야 하는 전통적인 모놀리식 애플리케이션에 비해 편리하다). 알고보니, 마이크로서비스와 컨테이너는 서로 완벽하게 잘 맞는다.  그러나 컨테이너화된 마이크로서비스를 애플리케이션으로 함께 사용하려면 어떻게 해야 할까? 바로 여기에서 최소한 더 큰 마이크로서비스 애플리케이션에 쿠버네티스가 역할을 한다. 이 오픈소스 오케스트레이션 엔진을 사용해 마이크로서비스 기반 애플리케이션을 배치, 관리, 확장하고 가용성을 보장할 수 있다. 또한 필요한 경우 ...

가상머신 컨테이너 캠도커 2020.03.11

“기업 78%가 도입” 쿠버네티스의 성공 비결

컨테이너 오케스트레이션 플랫폼 쿠버네티스가 첫 커밋 후 1년 만인 2015년 중반에서야 1.0에 도달했다는 사실은 믿기 힘들다. 이제 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 설문조사 대상 기업 중 78%가 활용하고 있기 때문이다. 미친 듯이 빠른 도입이다. CNCF 2018년도 보고서에 따르면, 불과 1년 전에 쿠버네티스 활용 기업 비율은 58%였다.  애플리케이션 개발 방식 개선에 나선 기업 입장에서 컨테이너가 얼마나 큰 힘을 발휘하는지 알 수 있는 대목이다. 또 광범위한 기술 도입에 오픈소스가 얼마나 중요해졌는지도 알 수 있다.     쿠버네티스 커뮤니티 쿠버네티스 인기의 비결은 잘 알려져 있다시피 커뮤니티이다. 필자가 2016년 지적한 것처럼, 쿠버네티스는 최초의 컨테이너 오케스트레이션 솔루션은 아니다. 최초 출시의 영광은 메조피어와 도커가 누리고 있다. 또 시중에 나와 있는 유일한 오픈소스 컨테이너 오케스트레이션 툴도 아니었다. 오히려 비결은 개방성이었다. 오픈소스이면서도 통제 방식이 폐쇄적이어서 장래의 기여자들(그리고 경쟁자들)을 좌절시키는 경우가 있다. 그러나 구글은 색다른 전술을 취했다. 이에 대해 당시에 필자는 다음과 같이 적은 바 있다.   “[쿠버네티스, 도커, 그리고 아파치 메조 간에] 커뮤니티 결과가 이렇게 크게 다른 것을 무엇으로 설명할까? 한마디로 구글이다. 아니면 구글의 상대적인 부재라고 할 수도 있다. 다른 오케스트레이션 프로젝트는 저마다 한 업체의 영향을 크게 받는 데 반해, 쿠버네티스는 구글의 독창적인 엔지니어링은 물론, 지속적인 개발에 대한 구글의 무간섭 방식의 덕을 보고 있다.” 5년이 지난 지금 구글은 여전히 쿠버네티스에 가장 큰 기여자이며, 그 뒤를 VM웨어와 레드햇이 따르고 있다. 그러나 쿠버네티스에 오직 구글뿐이었던 시절은 지나갔다. 이제는 어림도 없다. 2,000곳 이상의 업체에 퍼져 있는 3만 5,000명이 넘는 기여자들이 1...

커뮤니티 컨테이너 도커 2020.03.10

“데스크톱용 컨테이너가 온다” 윈도우 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

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

필드에서 바로 적용 가능한 애플리케이션 현대화 방법론

애플리케이션 현대화 기업들은 시장 출시 시간 단축과 애플리케이션 현대화의 압력에 직면해 있습니다. 또한 기존의 자산을 현대화하기 위한 최적의 접근 방식도 결정해야 합니다. 컨테이너, 쿠버네티스 및 마이크로서비스는 속도와 단순성을 제공할 수 있음을 입증하였으며 신속하게 도입되고 있습니다. IBM과 함께라면 이 모든 과정이 간편해집니다. 본 백서에서는 필드에서 바로 적용 가능한 IBM의 애플리케이션 현대화 접근방법론을 단계적으로 설명합니다. <32p> 주요 내용 - 애플리케이션 현대화의 개념 이해 - 애플리케이션 현대화로 가는 여정의 모든 팁 - 현대화 과정과 단계별 설명 : 애플리케이션 인벤토리부터 리팩토링, 클라우드 전환까지 - IBM의 독자적인 접근 방법론

마이그레이션 컨테이너 현대화 2020.02.13

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

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

백업 컨테이너 도커 2020.01.20

'빅 3 구도는 바뀌지 않는다'··· 2020년 클라우드 시장 및 기술 전망

클라우드의 지배력이 점점 더 막강해지면서 빅 3 클라우드 업체는 새로운 기술을 활용하고자 인재와 노하우 확보에 박차를 가하고 있다. 클라우드 생태계는 광범위하고 복잡하지만 새로운 공통적인 트렌드가 등장했으며 이 가운데 상당수는 향후 10년 동안 해당 산업에 지속해서 중요한 영향을 끼칠 것으로 예상된다.   포레스터의 부사장 겸 수석 분석가 데이브 바톨레티는 자신의 연례 클라우드 전망에서 클라우드 시장 전체(SaaS, PaaS, IaaS)가 2020년에 미화 2,994억 달러 규모까지 성장하리라 예측한 방법에 관해 간략히 설명했다. 클라우드 시장 성장을 견인할 주요 동인과 앞으로 클라우드 부문에서 고려해야 할 사항을 살펴보자. 곧 들이닥칠 또다른 클라우드 패권? 퍼블릭 클라우드 시장은 오랫동안 빅 3의 경쟁 구도로 비쳤으며 적어도 북미에서는 아마존웹서비스(AWS)의 지배력이 약화되거나 제4의 업체가 등장할 기미는 보이지 않는다. 각 업체가 수치를 다르게 제시하기 때문에 퍼블릭 클라우드 시장에 대한 실질적인 수치를 파악하기는 어렵지만 시너지 리서치(Synergy Research)는 AWS가 약 40%의 시장 점유율로 확실한 시장 리더이며 마이크로소프트 애저와 구글 클라우드가 30%와 10%로 그 뒤를 따르고 있는 것으로 추정했다. 현재 디 인포메이션(The Information)의 보고서에 따르면, 구글 클라우드는 현재 모기업인 알파벳(Alphabet)의 투자를 계속해서 받게 되면 최소한 경쟁업체 가운데 한 곳을 따라잡을 것이다. 하지만 구글의 대변인은 <컴퓨터월드UK>에 “2018년부터 등장한 이런 예측은 정확하지 않다”라고 일축했다. 이런 보고서가 과장되었거나 목적이 단순히 새로운 CEO 토마스 쿠리안이 경쟁업체들과 싸우도록 하는 것일지라도 구글 클라우드는 한동안 3위에 머물렀으며 이전 CEO 다이앤 그린의 관리하에서는 그 격차가 줄어들 기미가 보이지 않았다. 지난해 세간의 이목을 끈 여러 차례의 ...

레드햇 구글 CFF 2020.01.09

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

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

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

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

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

복구 백업 컨테이너 2019.12.20

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

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

Copyright © 2022 International Data Group. All rights reserved.