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.

컨테이너

다시 확인하는 도커와 컨테이너를 사용해야 하는 이유

1981년에 출간된 <나무에 젤리 못박기(Nailing Jelly to a Tree)>라는 책은 소프트웨어를 “모호해서 확실히 통제하기 어려운 것”이라고 묘사했다. 1981년 당시에는 맞는 말이었고 40년이 지난 지금도 제법 유효한 말이다. 예나 지금이나 소프트웨어는 사용자가 구매한 것이든 직접 개발한 것이든 배포와 관리, 실행이 다 어렵다.  도커(Docker) 컨테이너는 소프트웨어를 통제할 수단을 제공한다. 도커를 활용하면 애플리케이션의 배포 및 런타임 문제(네트워크 상에 노출하는 방법, 저장용량, 메모리, I/O를 관리하는 방법, 접근 권한을 통제하는 방법 등)가 애플리케이션 외부에서 처리되고 “컨테이너화”된 모든 앱에 걸쳐 일관된 방식으로 애플리케이션을 포장할 수 있다. 도커 컨테이너는 도커 런타임이 설치된 모든 OS 호환 호스트(리눅스 또는 윈도우)에서 실행할 수 있다.    도커는 이런 편리한 캡슐화, 격리, 이동성, 통제 이외에 다른 장점도 많다. 도커 컨테이너는 크기가 작고(수 MB) 즉각적으로 실행된다. 버전 작성 및 구성요소 재사용을 위한 자체 메커니즘도 내장되어 있으며, 공용 도커 허브나 사설 저장소를 통해 쉽게 공유할 수 있다.  도커 컨테이너는 또한 불변성이 있다. 이는 보안은 물론 운영 면에서도 장점이 있다. 특정 컨테이너에 대한 변경사항은 버전이 다르게 작성된 완전히 새로운 컨테이너로 배포해야 한다.  여기서는 도커 컨테이너가 어떻게 소프트웨어의 개발과 배포 모두를 수월하게 만드는지, 도커 컨테이너가 해결하는 문제는 무엇이며 어떻게 해결하는지, 도커 컨테이너가 문제의 정답일 때와 그렇지 않을 때는 언제인지 등을 알아본다.    도커 컨테이너가 없던 시절  오랜 세월 기업 소프트웨어는 보통 “베어 메탈(bare metal)”이나 가상머신(VM)에 배포되었다. 베어 메탈은소프트웨어가 설치되는 운영체제가 기반 하드웨어를 전적으로 통제하는 반면, 후자...

도커 컨테이너 마이크로서비스 2023.01.06

컨테이너, 정답이 아닐 때에도 고집할 필요는 없다

컨테이너는 클라우드로 마이그레이션하거나 클라우드를 바탕으로 설계되는 대다수 시스템에서 컨테이너는 마치 기본 설정과 같다. 다른 기술로는 달성하기 어려운 이동성과 확장성(오케스트레이션 활용)을 제공하기 때문이다. 무엇보다도 컨테이너를 중심으로 한 건강한 생태계와 정의하기 쉬운 솔루션이 강점이다. 그러나 AI나 서버리스처럼 최근 지나치게 과장된 다른 인기 기술과 마찬가지로 컨테이너가 잘못 적용된 사례를 쉽게 목격할 수 있다. 다른 기술이 훨씬 편리하고 비용 효율적인데도 기업은 흔히 컨테이너를 선택하고 만다.   사실 적합하지 않은 기술을 선택하는 것은 수백만 달러를 내버리는 것이나 마찬가지일 만큼 잘못된 결정이다. 사실 이력서에 추가할 과대평가된 기술 전문가 점수를 좇는 것이나 다름 없다. 최근 부각된 컨테이너의 중요한 단점은 일명 ‘애플리케이션 현대화’ 프로젝트에서 컨테이너 개발이 과대 적용된다는 점, 그리고 기존 애플리케이션이 지나치게 컨테이너로 마이그레이션된다는 점이다. 컨테이너가 작동하지 않아서 문제라는 것이 아니다. 다른 기술과 비교할 때 효율성이 크게 떨어질 수 있다는 점이 문제다. 대다수 기업은 워크로드의 이동성이라는 장점을 선택한다. 목표로 하는 호스트 플랫폼에서 절대로 옮길 수 없을 것 같은 워크로드를 말한다. 또한 가장 중요한 것은 컨테이너가 제공하는 장점을 진정으로 활용하기 위해서는 대다수 인스턴스 내 애플리케이션을 완전히 재설계해야 한다는 것이다. 흔히들 이 점을 놓치곤 한다. 최근의 새로운 개발에서도 같은 문제가 발견된다. 거대 기업은 컨테이너 기반 개발과 배포를 활용한 애플리케이션을 설계할 때, 기존 방식보다 4배 더 많은 예산을 쓴다. 컨테이너 기반 애플리케이션은 스토리지나 연산 등 더 클라우드에 기반한 자원을 사용하기 때문에 운영할 때도 더 많은 비용이 든다. 보안과 거버넌스도 마찬가지다. 컨테이너를 평가할 때 필요한 핵심 기준 예시를 몇 가지 살펴 보자.   가치를 다시 비즈니스로 가져오는 것에 초점...

컨테이너 애플리케이션 클라우드 2022.12.21

“배치 작업 관리의 새로운 진화” 워크로드 오토메이션에 주목해야 하는 이유 - Tech Summary

IT 환경이 여러 가지 플랫폼으로 다양해지면서 IT 운영, 특히 워크로드 관리가 모든 기업의 고민거리로 부상하고 있다. 과거에는 단순히 IT 시스템의 배치 작업(Batch Job)을 스케줄링 하거나 관리했지만, 최근엔 관여하는 영역이 크게 늘어났다. 인프라와 애플리케이션 구성, 프로비저닝, 데브옵스 수명주기 관리부터 클라우드와 데이터센터의 오케스트레이션 자동화까지 기술 범위가 확장됐다. 기업이 직면한 워크로드 관리 문제를 풀어 줄 정확한 해법을 찾기 위해 워크로드 관리를 둘러싼 기술과 시장의 변화를 살펴본다. 컨테이너 같은 신기술에 대응하면서 효율적으로 워크로드를 관리하는 대안으로 '워크로드 오토메이션'을 제시하고 기업이 시행착오 없이 워크로드 오토메이션을 도입하는 구체적인 방법과 사례를 검토한다. 주요 내용 - 워크로드 관리 트렌드 변화를 읽는 3가지 키워드 - 전통적인 배치 작업 관리의 한계  - 차세대 워크로드 관리, ‘워크로드 오토메이션’ - 효율적인 워크로드 관리는 디지털 혁신의 전제 조건

배치 컨테이너 워크로드 오토메이션 2022.12.06

“쿠버네티스 덕분에 활력 넘친다” 오픈스택 사용자 설문 보고서

오픈소스 클라우드 인프라 기술 오픈스택은 그동안 여러 차례 사망선고를 받았다. 하지만 실제로 오픈스택은 그 어느 때보다 생생하게 살아있다. 오픈스택 프로젝트는 계속 성장하고 있다. 300곳이 넘는 클라우드 데이터센터가 오픈스택을 기반 소프트웨어로 사용하고, 프로덕션 환경에서 오픈스택을 구동하는 CPU 코어의 수는 4,000만 개에 이른다. 오픈인프라 재단의 ‘2022년 오픈스택 사용자 설문 보고서(OpenStack User Survey Report 2022)에 따르면, 오픈스택 기술은 현재도 기하급수적으로 성장하고 있다. 점점 더 많은 기업이 하이브리드 클라우드 환경을 채택하고, 쿠버네티스와 오픈스택의 통합에 가치를 부여하고 있기 때문이다.   오픈스택의 핵심 서비스인 노바(프로비저닝), 뉴트론(네트워킹), 키스톤(ID 서비스), 그랜스(VM 이미지 서비스), 아이러닉(베어메탈 프로비저닝)의 도입률은 여전히 높다. 하지만 사용자가 새로운 워크로드를 위한 자체 아키텍처를 계속 개발하면서 옥타비아(로드 밸런서)나 매그넘(컨테이너 오케스트레이션) 같은 지원 서비스 역시 인기가 높아졌다. 이들 프로젝트는 하이브리드 클라우드 환경을 안정적이고 믿을 만한 방식으로 구성하는 데 도움이 될 뿐만 아니라 쿠버네티스와의 통합을 지원하기 때문이다. 단순 지원 서비스에서 프로덕션용 오픈스택 서비스로 진화한 것이다. 이번 보고서는 2021년 8월부터 2022년 8월 간의 변화를 묻는 설문에 참여한 430명의 답변을 기반으로 한다. 보고서에 따르면, 이 기간 동안 오픈스택은 새로운 기록을 세웠다. 4,000만 코어가 프로덕션에 사용되고 있는 것으로 나타났는데, 이는 2021년 조사 대비 60%, 2020년 조사 대비 166% 증가한 수치이다. 오픈스택 배치 규모는 다양한데, 100~1만 코어가 56%로 가장 많았다. 프로덕션 코어의 증가 중 많은 부분은 이른바 ‘100만 코어 클럽’에 의한 것이다. 2021년 만들어진 이 그룹은 대규모 오픈스택 구현 환경을 대표한다....

오픈스택 쿠버네티스 하이브리드클라우드 2022.12.05

쿠버네티스 발 인재난을 극복하는 4가지 전략

마이크로서비스와 컨테이너는 디지털 전환의 토대가 되는 기술로, 많은 기업이 앞다퉈 쿠버네티스와 컨테이너 관리를 도입해 마이크로서비스 및 컨테이너를 지원하고 있다. 하지만 쿠버네티스는 매우 복잡하며, 쿠버네티스 능력자 또한 매우 드물다. 발상의 전환이 필요한 상황이다.   지난 9월 쿠버네티스를 채택한 개발자 그룹을 대상으로 한 설문조사에 따르면, 애플리케이션과 운영 인프라를 최신 버전으로 업데이트하려는 기업에 쿠버네티스와 컨테이너 관리 기술 부족이 최대 난제로 꼽혔다. 설문에 응한 기업의 절반 이상이 기존 직원과 함께 쿠버네티스 및 컨테이너를 채택할 전문가를 확보하는 것이 가장 어렵다고 답했으며, 기업 35%는 외부에서 역량 있는 직원을 영입하는 데 어려움을 겪고 있다고 했다. 하지만 61% 이상의 기업이 프로덕션 환경에 쿠버네티스를 성공적으로 도입했다고 답했다. 이들 기업은 6개 이상의 워크로드 또는 애플리케이션을 멀티 클러스터 컨테이너 환경에서 실행한다.  그렇다면 이들 기업은 쿠버네티스 인력 부족을 메우고 성공적으로 쿠버네티스를 실행하기 위해 어떤 노력을 하고 있을까? 쿠버네티스 도입에 성공한 기업이 해당 전문가를 영입하고 유지하는 비결 4가지를 소개한다.  전략 1: 외부 전문가를 내부 전문 지식 구축에 보충하라 많은 기업이 글로벌 SI 업체(GSIs)의 도움을 받아 쿠버네티스 공정을 시작한다. 전체 프로젝트를 외주하기보다는 가장 성공적인 모델은 계약된 GSI 전문가가 프로젝트 애플리케이션 또는 인프라 디렉터로 활동하나, GSI 및 고객 직원과 협업하는 형태이다.  이런 디렉터이자 전문가는 프로젝트 수행과 지식 전달을 수행한다. 인터뷰에 응한 전문가들에 따르면 이런 관행은 일반화되고 있는데, 이들은 개별 프로젝트에 기술 역량을 확보하는 것은 물론, 다른 대형 고객의 베스트 프랙티스 중 프로젝트를 수행하면서 배울 수 있는 것들을 도입하는 역할을 수행한다. 전략 2: ‘오픈소스’ 문화를 자본화해 내부 직원들의 역...

쿠버네티스 컨테이너 레드햇 2022.11.23

웹어셈블리(Wasm)가 클라우드 컴퓨팅의 미래인 이유

서버에서든 엣지에서든 ‘웹어셈블리(WebAssembly; Wasm)’를 사용하면 이전보다 데이터에 훨씬 더 가깝게 실행되는 사용자 정의 로직을 생성할 수 있다. 아울러 더욱 더 유연하고 안전하며 효율적으로 수행할 수도 있다.  웹어셈블리(WebAssembly)의 줄임말인 Wasm은 웹용으로 개발됐다. 하지만 Wasm 기술은 웹 브라우저를 넘어 확장됐다. 이제 기업은 서버 쪽에서 Wasm을 실행하기 시작했다. 예를 들면 싱글스토어(SingleStore)는 자사 데이터베이스에서  Wasm을 사용하고 있다.   일각에서는 Wasm이 컨테이너 기술과 유비쿼터스 자바스크립트를 대체할 것이라고 생각한다. 믿든 믿지 않든 Wasm은 분명히 클라우드 컴퓨팅에 영향을 미치고 있다. 왜 그리고 어떻게?      Wasm은 크로스 플랫폼이다 : 클라우드 구성요소를 안전하고 간단하게 결합한다 소프트웨어 작성에는 수많은 종류의 언어가 사용된다. 그 많은 언어의 상호작용을 보장하는 것은 어렵다. Wasm은 사용자가 원하는 어떤 언어로든 작성할 수 있는 프레임워크를 제공한다. 그 다음 공통으로 시뮬레이션된 기계어 형식을 생성한다.  이 형식을 사용하면 러스트, C/C++, 고랭 등 다양한 언어로 작성된 구성요소가 서로 통신할 수 있다. 또 Wasm은 서버 측 시스템(예 : 데이터베이스 등)이 해당 모듈을 어떻게 생성했는지 확인하거나 신경 쓰지 않고도 다른 언어의 구성요소를 내장한다.  Wasm을 범용 플러그인 형식이라고, 서드파티에서 개발한 구성요소로 시스템의 기능을 강화하고 싶다고 가정해보자. Wasm을 활용하면 일반적으로 추가 기능을 통합할 때 수반되는 위험 없이 시스템에 새 구성요소를 가져올 수 있다. 예를 들어 외부 구성요소가 시스템을 충돌시킬 수도, 예기치 않은 방식으로 움직일 수도 있다. Wasm은 서로 다른 시스템과 구성요소가 상호 작용하는 매우 안전한 프레임워크를 만들어 이러한 문제를 완화한...

웹어셈블리 Wasm 클라우드 2022.11.04

2022년 쿠버네티스 보안 현황 리포트

쿠버네티스 보안 현황 리포트의 최신 버전에서는 컨테이너, 쿠버네티스, 클라우드 네이티브 보안 분야에서 새롭게 부상하는 동향을 분석합니다. 300명 이상의 DevOps, 엔지니어링 및 보안 전문가들을 대상으로 한 설문조사 결과에 기반한 이 리포트는 컨테이너 및 쿠버네티스를 수용하는 기업들이 클라우드 네이티브 환경을 보호하기 위해 DevSecOps 이니셔티브를 구현하는 방법에 대한 새로운 조사 결과를 제공합니다. 이 리포트의 결과를 벤치마킹하여 컨테이너와 쿠버네티스 전반에 보안 제어를 적용하기 위한 노력을 가속화할 수 있는 방법을 결정하는 것이 좋습니다. 컨테이너와 쿠버네티스에 사용할 수 있는 보안 이점은 선언적 구성 및 변경 불가능한 인프라에서 애플리케이션 컨테이너에 내재된 격리에 이르기까지 다양합니다. 그러나 조직은 DevOps 기반의 클라우드 네이티브 환경에서 빠르게 실행하여 상당한 이점을 누릴 수 있도록 이러한 기능을 작동시키기 위한 지식, 툴링, 프로세스가 필요합니다. <21p> 주요 내용 - 쿠버네티스, 컨테이너 보안 주요 설문결과 - 혁신을 저해하는 보안 고려 사항 - 하이브리드 클라우드 배포 전략 - 쿠버네티스 보안 활용 사례 - 오픈소스 보안 툴 - 보안 향상을 위한 4가지 팁

컨테이너 쿠버네티스 클라우드네이티브 2022.10.31

“쿠버네티스 비용 평균 40% 절감” 시스딕, ‘코스트 어드바이저’ 출시

클라우드 및 컨테이너 보안 회사 시스딕(Sysdig)이 클라우드에서의 쿠버네티스 환경 운영 비용을 절감하기 위한 새로운 도구 ‘코스트 어드바이저(Cost Advisor)’를 출시했다. 기업은 이 도구를 활용하여 쿠버네티스 비용을 모니터링하고 낮추기 위한 베스트 프랙티스를 보완할 수 있다고 업체 측은 설명했다.   클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation; CNCF)에서 실시한 설문조사 결과에 의하면 전체 응답자의 약 68%가 쿠버네티스 운영 비용이 증가하고 있다고 말했다. 아울러 약 69%의 응답자가 비용을 모니터링하거나 비용 추정치를 도출할 방법이 없다고 전했다. 컨테이너 기술 발전을 지원하기 위해 2015년 설립된 리눅스 파운데이션(Linux Foundation)의 프로젝트인 CNCF는 전 세계 178명을 대상으로 해당 설문조사를 진행했다.  시스딕은 공식 성명을 통해 “쿠버네티스 환경을 위한 비용 추정 도구가 없다면 개발자는 클라우드 리소스가 초과 또는 과소 할당됐는지 파악하기 어려워진다. 개발자에게 자체 배포 옵션이 주어지면 이 문제는 더욱더 복잡해진다"라고 설명했다. 시스딕의 엔지니어링 및 기술 부문 부사장 사로 수비아는 지난주 코스트 어드바이저를 발표한 보도 자료에서 “컨테이너와 쿠버네티스를 통해 팀은 클라우드에서 빠르게 이동할 수 있지만 이런 컨테이너화된 환경에서는 비용이 가장 해결하기 어려운 문제가 된다. 비용 데이터가 없어 클라우드 지출에 돈을 낭비하게 돼 정규직 직원 2~3명에 해당하는 손실을 보고 있는 팀도 있다”라고 말했다. 업체에 따르면 많은 엔터프라이즈 팀이 쿠버네티스 비용을 파악하기 위해 여러 정보 소스 및 정적 스프레드시트를 사용한다. 반면 시스딕은 분산된 생산 환경을 모니터링하고 문제를 해결하도록 설계된 시스딕 모니터 도구 제품군의 일부로 코스트 어드바이저를 제공한다. 이 도구는 쿠버네티스 및 다양한 클라우드 서비스에 관한 지표를 지원한다.  또...

쿠버네티스 컨테이너 클라우드 컴퓨팅 2022.10.26

컨테이너 혁명을 이끄는 쿠버네티스 배포판 6종 탐구

쿠버네티스(Kubernetes)는 대규모 컨테이너 오케스트레이션에서 개발자가 주로 선택하는 프로젝트로 자리잡았다. 구글이 만든 오픈소스 컨테이너 오케스트레이션 시스템인 쿠버네티스는 지원도 풍부하고 좋은 평판을 받으면서 꾸준히 발전하고 있다. 그러나 쿠버네티스는 무분별하게 확산되고 복잡하며 설치 및 구성이 어렵다. 또한 힘든 작업 대부분을 최종 사용자가 직접 해야 한다. 따라서 최선의 접근 방법은 쿠버네티스 하나만을 붙잡고 씨름하는 것이 아니라 지원되고 유지 관리되는 하나의 구성요소로 쿠버네티스를 포함하는 완전한 컨테이너 솔루션을 추구하는 것이다.   컨테이너 도구와 쿠버네티스를 포용하는 6가지 쿠버네티스 솔루션을 살펴본다. 여러 업체가 리눅스 커널 및 유저랜드 배포판을 제공하는 것과 유사하다. 6가지 솔루션을 선정할 때 아마존 EKS 또는 구글 쿠버네티스 엔진 같은 클라우드 전용 서비스는 제외하고, 로컬 또는 클라우드에 호스팅되는 옵션으로 실행가능한 소프트웨어 배포판에만 초점을 맞췄다.    관련 영상 : 쿠버네티스란 무엇인가? 90초 길이의 이 영상에서 쿠버네티스 개발진 중 한 명이며 헵티오(Heptio) 창업자 겸 CTO인 조 베다가 쿠버네티스 개념을 설명한다. 캐노니컬 쿠버네티스 우분투 리눅스를 만든 캐노니컬(Canonical)은 자체 쿠버네티스 배포판을 제공한다. 캐노니컬 쿠버네티스의 큰 장점은 좋은 평가를 받고 이해도가 높고 보편적으로 배포된 우분투 리눅스 운영체제를 기반으로 두고 있다는 점이다. 캐노니컬은 자사 스택이 모든 클라우드 또는 온프레미스 환경에서 동작하며 CPU 및 GPU 기반 워크로드를 모두 지원한다고 주장한다. 유료 고객은 캐노니컬 엔지니어를 통해 원격으로 쿠버네티스 클러스터를 관리할 수 있다.   또한 캐노니컬의 쿠버네티스 배포판은 축소 버전인 Microk8s에서도 제공된다. 개발자와 쿠버네티스 초보자는 노트북 또는 데스크톱에 Microk8s를 설치해서 로우 프로파일 하드웨어에서의 테스트...

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

구글 클라우드, 20가지 이상의 새 기능과 서비스로 네트워크와 보안 강화

구글 클라우드가 7계층 보안 기능을 포함해 20가지가 넘는 새로운 기능과 서비스를 발표했다. 이번 구글 클라우드 넥스트(Google Cloud Next) 행사에서 공개된 새 서비스의 중심에 있는 것은 네트워크와 보안이다. 구글 클라우드 네트워킹 총괄 책임자 무닌더 삼비는 “네트워크 패브릭을 근본적으로 향상하고 있다. 또한 기업이 더 쉽고 단순하게 기존 워크로드를 이전하고 애플리케이션을 현대화하고 안전하게 관리할 수 있도록 할 것이다”라고 강조했다.    가장 눈에 띄는 것은 강화된 PSC(Private Service Connect) 서비스이다. PSC는 암호화된 링크를 통해 그룹이나 프로젝트, 다른 조직을 묶을 수 있는 서비스로, 이제 7계층 보안과 라우팅, 원격 측정 기능이 추가되어 서비스 전반에 걸쳐 일관성 있는 정책 제어를 보장한다. 구글 클라우드의 고가용성 저지연 연결 서비스인 클라우드 인터커넥트(Cloud Interconnect)도 PSC를 지원해 온프레미스 사이트와 다른 PSC 엔드포인트를 연결한다. PSC는 컨플루언트, 데이터브릭스, 데이터스택스, 그라파나, 네오4J 등의 매니지드 데이터 및 분석 서비스와 통합된다. PSC를 이용하면, 기업 네트워크 트래픽은 구글의 백본 네트워크에서만 전달되며 인터넷에 노출되지 않는다. 기업은 구글 가상 프라이빗 클라우드(VPC) 네트워크 상에서 PSC 엔드포인트와 사설 IP 주소를 사용해 구글 클라우드와 연결한다. IDC의 데이터센터 및 멀티클라우드 네트워크 담당 리서치 부사장 브라드 케이스모어는 “PSC는 워크로드의 클라우드 마이그레이션에서 불가피한 네트워킹 및 보안 문제를 단순화하기 때문에 중요하다”고 평가했다. 구글은 컨테이너 기반 자원을 좀 더 쉽게 네트워킹할 수 있는 기술도 소개했다. 네트워크 펑션 애널라이저(Network Function Analyzer)는 기업의 여러 컨테이너 기능을 연결하고 라벨을 적용하고 트래픽을 조정할 수 있다. 삼비는 “이 기능을 이용하면 기업은 ...

구글클라우드넥스트 PSC 방화벽 2022.10.12

“크립토재커가 1달러 벌 때마다 피해자는 53달러 손해본다” 시스딕

사이버 보안 업체 시스딕(Sysdig)의 ‘2022 클라우드 네이티브 위협 보고서(2022 Sysdig Cloud Native Threat Report)’에 따르면 크립토재커가 ‘1달러’를 벌 때마다 피해자는 ‘53달러’를 잃는 것으로 조사됐다.  최근 발표된 보고서는 ‘크립토재킹’이 클라우드에서 실행되는 컨테이너 기반 기스템을 타깃으로 하는 일반적인 공격 유형이 됐으며, 지정학적 갈등(주로 러시아의 우크라이나 침공과 관련 있음)이 올해 디도스(DDoS) 공격 증가에 영향을 미쳤다고 밝혔다.  아울러 보고서는 컨테이너가 클라우드 기반 시스템에서 점점 더 많이 사용되면서 공급망 공격의 중요한 공격 벡터가 됐다고 덧붙였다. “컨테이너 이미지는 이식 가능하도록 설계됐기 때문에 한 개발자가 다른 사용자와 컨테이너를 공유하기가 매우 쉽다. 개발자가 컨테이너 이미지를 공유할 수 있도록 컨테이너 레지스트리를 배포하기 위한 소스 코드를 제공하거나, 컨테이너 레지스트리를 무료로 액세스할 수 있는 여러 오픈소스 프로젝트가 있다”라고 보고서는 설명했다.     악성 이미지가 포함된 퍼블릭 컨테이너 리포지토리 보고서는 도커 허브(Docker Hub)와 같은 퍼블릭 컨테이너 이미지 리포지토리가 합법적인 소프트웨어 애플리케이션으로 위장한 크립토마이너, 백도어 및 기타 위협 벡터를 포함하는 악성 이미지로 채워지고 있다고 언급했다.  이어 암호화폐를 채굴하기 위해 컴퓨팅 인프라를 무단으로 사용하는 크립토재킹이 (광범위하게 공격한 다음 누군가 걸려들길 기다리는) 기회주의형 공격자의 주된 동기이며, 치명적인 취약점과 취약한 시스템 구성을 악용한다고 보고서는 전했다.  시스딕의 위협 연구 부문 책임자 마이클 클라크는 “도커 허브를 분석한 결과 데이터 세트에서 발견된 총 고유 악성 이미지는 1,777개였다. 그중 608개 또는 34%의 컨테이너에 마이너 악성코드가 있었다”라고 말했다.  그에 의하면 크립토재킹이 확산되고...

컨테이너 크립토재킹 크립토재커 2022.09.30

서브시 클라우드, 연말까지 해저 데이터센터 상용화…비용 90% 절감

서브시 클라우드(Subsea Cloud)가 올해 말까지 상용 해저 데이터센터를 출시한다는 계획을 발표했다. 첫 해저 데이터센터는 미국 워싱턴주 포트 엔젤리스 근처에 구축할 예정이다. 이외에도 멕시코만과 북해에 두 곳의 해저 데이터센터를 추가로 구축할 예정이다. 참고로 서브시 클라우드는 회사명과는 달리 클라우드 서비스 업체가 아니라 코로케이션 서비스 업체이다.   서브시 클라우드에 따르면, 해저 데이터센터는 지상 데이터센터와 비교해 전력을 40% 적게 사용해 탄소 배출량을 줄일 수 있다. 또한 데이터센터를 대도시와 근접한 해안에 구축할 수 있기 때문에 속도 지연을 줄이는 데도 유리하다. 서비스 클라우드 CEO 맥시 레이놀즈는 1메가와트 용량의 컴퓨팅 자원을 지상보다 90% 저렴한 비용으로 제공할 수 있다고 강조했다. 해저 데이터센터가 완전히 새로운 개념은 아니다. 2018년 마이크로소프트가 스코틀랜드 오크니섬에 구축한  네이틱(Natik) 실험이 대표적인 예다. 하지만 서브시 클라우드는 쥘 베른이란 이름의 새 데이터센터에서 다른 접근법을 취하고 있다. 이전의 해저 데이터센터는 냉매로 질소를 가득 채운 압력 선체를 사용했지만, 쥘 베른은 일반 화물 컨테이너를 설치할 예정이다. 압력 선체와 동일한 압력이 컨테이너로 유입될 수밖에 없는데, 이렇게 흘러 들어오는 물을 냉각제로 사용하는 방식이다. 전통적인 수랭방식과는 달리 펌프가 필요없기 때문에 전력을 전혀 사용하지 않는다. 더레지스터(The Register)의 보도에 따르면, 컨테이너 한 대에는 16대의 서버 랙이 탑재되며, 최대 800대이 서버를 설치할 수 있다. 이런 컨테이너를 최대 100대까지 연결한 팟(Pod)으로 네트워크를 구성해 확장 가능한 방법으로 추가 컴퓨팅 성능을 제공할 수 있다. 팟과 육지와의 연결에는 100Gbps 접속을 사용한다. 쥘 베른 해저 데이터센터는 상용 서비스이기 때문에 모든 잠재적 고객과 협력업체에 개방되어 있다. 레이놀즈는 현재 잘 알려진 하이퍼스케일 업체 ...

해저데이터센터 서브시클라우드 하이퍼스케일 2022.09.05

“클라우드 예산 낭비 심하다” 기술 역량이 멀티클라우드의 최대 과제 : 포레스터

많은 기업이 자사가 사용하는 클라우드 서비스에 비용을 과지급하고 있는 것으로 나타났다. 포레스터 리서치가 예산 책임이 있는 IT 의사결정권자 약 1,000명을 대상으로 실시한 설문조사에서 응답자의 94%가 피할 수 있는 클라우드 비용을 지불했다고 답했다.    필요 이상의 비용을 지불하는 주된 이유는 자원 계획의 오류 때문이다. 응답자의 2/3는 예약된 클라우드 자원을 제대로 사용하지 못한다고 인정했다. 거의 60%의 IT 의사결정권자가 클라우드에는 구매해야 할 자원이 너무 많다고 답했다. 여기에 더해 기술력 부족(47%), 클라우드에서 컨테이너의 수작업 환경 구성(37%)도 문제의 원인으로 지목됐다. 포레스터는 약 기업의 1/4이 클라우드 예산을 초과해 사용하고 있는 것이라고 분석했다. 이런 조사 결과는 클라우드를 사용하는 기업에 투명한 비용 관리가 중요하다는 것을 분명히 보여준다. 특히 클라우드 사용이 증가하면서 IT 인프라는 점점 더 다루기 어려워졌다. 응답자 60%는 이미 멀티클라우드 환경을 이용하고 있다고 답했으며, 1년 후에는 이 비율은 80%까지 늘어날 것으로 보인다. 한편, 멀티클라우드와 관련된 복잡성을 해결하기 위해 기업은 중앙화와 자동화를 이용한다. 조사 결과에 따르면, 약 90%의 기업이 이미 클라우드를 위한 CoE(Centers of Excellence) 전문팀을 구성해 클라우드 서비스의 표준화와 베스트 프랙티스, 정책을 관리하고 있다.  멀티클라우드의 복잡성은 기본적으로 다양한 기술과 애플리케이션, API를 관리하고 IT 인프라의 여러 계층에 걸쳐 매끄럽게 동작하는 프로세스를 개발하는 데서 나온다. 이와 관련해 IT 의사결정권자에게 가장 큰 과제는 기술력 부족(41%), 팀별 사일로(35%), 교육 훈련의 부족(33%), 일관성 없는 워크플로우(30%)로 나타났다. 주목해야 할 것은 주된 문제가 기술보다는 기업이 보유하고 있는 노하우와 자체 프로세스와 관련된 것이라는 점이다. 기술적인 문제로는 보안이...

멀티클라욷 기술력 컨테이너 2022.08.11

크라우드스트라이크, 새 ‘위협 사냥’ 서비스 발표 및 컨테이너 가시성 개선

클라우드 기반 엔드포인트 위협 탐지‧대응(EDR) 솔루션 업체 크라우드스트라이크(CrowdStrike)가 지난 26일 새로운 클라우드 위협 사냥 서비스 '팔콘 오버워치(Falcon Overwatch)'를 공개했다. 또한 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP) 컨테이너의 가시성과 보안을 강화하는 일련의 업데이트를 발표했다.    에이전트 및 비에이전트 방식을 지원하는 ‘팔콘 오버워치’  팔콘 오버워치는 크라우드스트라이크의 클라우드 기반 공격 탐지 척도를 기준으로, 전체 제어 평면에서 점점 진화하는 클라우드 위협을 파악하는 독립형 위협 사냥 서비스다. 제어 평면은 클라우드 워크로드에 사용되는 모든 네트워크 구성 요소 및 기능을 포함한다.    팔콘 오버워치는 CNAPP의 에이전트 기반(팔콘 클라우드 워크로드 보호(Falcon Cloud Workload Protection)) 및 비에이전트(팔콘 호라이즌 클라우드 보안 상태 관리(Falcon Horizon cloud security posture management)) 솔루션을 모두 활용하여 AWS, 애저, 구글 클라우드를 비롯한 여러 클라우드에서 위협 가시성을 개선했다.  팔콘 오버워치의 부사장 파라 싱은 "팔콘 호라이즌을 활용해 12억 개 이상의 컨테이너에서 에이전트 설치가 필요 없는(agentless) 방식으로 데이터를 수집한다"라며 "한편 여러 기업의 클라우드 기반 리눅스 서버 등 엔드포인트에 설치되어 있는 에이전트에서도 다양한 데이터를 수집한다. 이렇듯 2가지 출처의 데이터를 결합하여 더 효과적으로 사이버 위협을 사냥할 수 있다”라고 설명했다.    CNAPP 업데이트로 가시성 및 보안 향상  크라우드스트라이크는 소프트웨어 컨테이너의 고객 가시성을 개선하는 일련의 업데이트도 발표했다. 특정 컨테이너가 배포되기 전에 취약점, 내장된 맬웨어 및 모르는 사이 저장된 기타 데이터(stored secrets)를...

위협사냥 사이버위협사냥 컨테이너 2022.07.29

"기본만 지켜도…" 쿠버네티스 보안 실수 7가지

가장 위험한 보안 구멍은 가장 기본적인 것일 때가 많다. 이러한 기본적인 실수만 고쳐도 쿠버네티스 보안 태세를 개선할 수 있다.  클라우드 네이티브 애플리케이션을 만들거나 또는 클라우드 네이티브 애플리케이션으로 작업할 때 대부분 ‘쿠버네티스’를 사용한다. 최근 CNCF 보고서에 따르면 기업의 96%가 쿠버네티스를 사용하거나 검토하고 있는 것으로 조사됐다. 쿠버네티스는 이미 전 세계적으로 560만 명의 사용자가 있으며, 전체 백엔드 개발자의 31%에 해당된다.    쿠버네티스 사용이 매년 늘어나고 민감한 데이터의 양도 증가하면서 공격자의 악용 동기 역시 급증한다. 완전히 새로운 환경을 보호하려는 시도는 어려워 보이겠지만, 상당수의 보안 문제는 비교적 쉽게 고칠 수 있는 기본적인 실수에서 비롯된다. 7가지 쿠버네티스 보안 실수 그리고 이를 해결하는 방법을 살펴본다.  1. 기본 구성(Default configurations) 많은 사람이 보안 관점에서 기본 클러스터 구성이 충분하다고 가정하지만 이것은 실수다. 쿠버네티스의 기본 설정은 보안 등급이 아니며, 그보다는 개발자의 유연성과 민첩성을 극대화하도록 설계됐다. 사용자는 보안을 위해 클러스터를 적절하게 구성해야 한다.  2. 여러 관리자(Multiple admins) 여러 엔지니어가 클러스터에서 일상작인 작업을 하면서 높은 권한을 가진 역할(예: 클러스터 관리자(CLUSTER_ADMIN) 등)을 쓸 수 있도록 허용하는 것은 언제나 실수다. 이 역할은 다른 역할 및 사용자를 관리하는 데만 활용돼야 한다. 클러스터 관리자 수준의 액세스 권한을 가진 여러 관리자가 있으면, 시스템에 침입하려는 해커에게 전체 클러스터 액세스 권한을 가진 계정을 ‘많이’ 제공하는 것과 같다.  3. 액세스 제한 없음(No access restrictions) 많은 관리자가 개발자의 dev/stage/prod 클러스터 액세스 유형 제한을 설정하지 않는다. 모든 개발자가 모든 다...

쿠버네티스 클라우드 네이티브 보안 태세 2022.07.28

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

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

컨테이너 도커 포드맨 2022.06.24

"쿠버네티스 사용자의 가장 큰 어려움은 보안"

쿠버네티스와 컨테이버 기반 개발의 가장 큰 우려 사항이 보안인 것으로 나타났다. 레드햇의 '2022 쿠버네티스 보안 현황 보고서(State of Kubernetes Security report for 2022)'에 따르면, 응답자의 93%가 지난 1년 사이에 운영하던 쿠버네티스와 컨테이너 개발 환경에서 보안 사고를 최소 1번 이상 경험했다고 답했다. 이 중에는 고객을 잃거나 매출에 피해를 본 경우도 있었다. 원인은 컨테이너와 쿠버네티스 관련 보안 지식의 부족, 충분치 않은 툴, 앱 개발팀과 보조를 맞추지 못하는 중앙 보안팀 등 다양하다. 기본적으로 쿠버네티스와 컨테이너가 보안이 아니라 개발자의 생산성을 위해 개발됐다는 점도 한 요인이다. 레드햇이 발행한 이 보고서는 쿠버네티스와 컨테이너, 클라우드 네이티브 보안 트렌드를 분석한 결과다. 300명 이상의 데브옵스, 엔지니어, 보안 전문가를 설문했다. 주요 내용은 다음과 같다.   응답자의 55%는 보안 문제 때문에 애플리케이션 개발 일정을 연기하기나 지연시켰다. 53%는 지난 1년 사이 쿠버네티스에서 잘못된 설정을 발견했다. 57%는 런타임에서의 보안 워크로드를 가장 우려했다. 78%는 시작 단계, 심화 단계를 포함해 데브섹옵스 정책을 보유하고 있다고 답했다. 43%는 쿠버네티스 보안에서 데브옵스가 핵심이라고 답했다. 38%는 지난 1년 사이 컨테이너와 쿠버네티스 관련된 주요 보안 취약점을 경험했다. 보고서에 따르면, 컨테이너와 쿠버네티스를 도입하고 클라우드 네이티브 생태계를 구축한 기업이 보안 전략과 툴에 투자하지 않으면, 핵심 애플리케이션이 위기에 처할 수 있다. 현재 많은 기업이 데브옵스 파이프라인에 보안 프로세스와 툴을 만드는 데브섹옵스를 도입하고 있다고 보고서는 분석했다. 쿠버네티스는 사용자가 원하는 대로 맞춤 설정할 수 있는 컨테이너 오케스트레이터다. 그러나 보고서에 따르면, 이 다양한 구성 옵션이 오히려 애플리케이션 보안에 영향을 준다. 이때 보안 툴은 쿠버네티스를 더 ...

쿠버네티스 컨테이너 2022.06.16

“기업이 원하는 IT 자동화의 3가지 방향” 앤서블 오토메이션 플랫폼 기반의 IT 자동화 완성 전략 - Tech Summary

자동화는 기업이 생산성과 효율성을 높이기 위해 모든 영역에서 진행 중인 메가 트렌드이다. 특히 IT의 경우는 디지털화로 인해 인프라의 규모가 커지고 복잡성이 높아지면서 그 어떤 분야보다 빠르게 자동화가 진행됐다. 하지만 IT 자동화에 모든 기업이 만족하는 것은 아니다. IT 인프라의 수많은 구성 요소가 개별적으로 자동화를 진행하는 파편화 문제도 있고, 자동화 과정에 시간과 비용이 과잉 투입되기도 하기 때문이다. 레드햇은 기업의 피드백을 통해 속도, 협업, 성장을 기업이 원하는 IT 자동화의 3가지 방향으로 정리하고, 기업이 원하는 자동화를 가장 효율적으로 빠르게 구현하고, 기업 내 모든 사용자가 일관된 경험을 얻을 수 있는 방안을 제시한다. IT 자동화의 완성도를 한 단계 끌어올리기 위한 조건을 살펴보고, 앤서블 오토메이션 플랫폼 2를 통해 자동화의 선순환 구조를 구현하는 방법을 알아본다. 주요 내용 - 기업이 원하는 IT 자동화의 3가지 방향 - 속도, 협업, 성장을 위한 레드햇의 접근 방법 - 생성부터 운영, 소비까지 자동화 선순환 구조 - 운영 효율부터 보안, 재택근무 지원까지 : 자동화 주요 채택 사례 - 레드햇 앤서블 오토메이션 플랫폼이 정답인 다섯 가지 이유

자동화 컨테이너 앤서블 2022.06.10

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

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

Copyright © 2023 International Data Group. All rights reserved.