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.

쿠버네티스

메르세데스 벤츠가 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의 쿠버네티스 환경보다 거의 다섯 더 크다. 메르세데스 벤츠를 쿠버네티...

쿠버네티스 오케스트레이션 벤츠 3일 전

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

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

쿠버네티스 컨테이너 2022.06.16

"쿠버네티스와 깃옵스는 빵과 버터" 구글이 깃옵스를 간소화하는 방법

구글이 컨테이너화된 애플리케이션을 대규모로, 지속적으로 구성 및 관리하는 조직을 지원하는 일련의 오픈소스 툴을 구축하고 나서면서 부상 중인 깃옵스(Gitops)에 본격적으로 뛰어들고 있다.   컨테이너 오케스트레이터인 쿠버네티스(2014년 구글에서 개발)가 클라우드 네이티브 조직의 핵심 계층이 됨에 따라 기업은 방대한 컨테이너를 관리하고 원하는 상태와 실제 상태를 조정하는 전문적 역량을 갖춰야 하는데, 그러려면 전통적으로 깊은 도메인 지식이 필요하다. 헬름(Helm) 차트를 작성하고 YAML 언어로 코딩하는 역량도 포함된다.   구글 특별 엔지니어이며 쿠버네티스의 최초 설계자 중 한 명인 브라이언 그랜트는 지난 주 블로그 글에서 “모든 규모의 기업이 쿠버네티스를 활용해 인프라에서 애플리케이션을 구축, 배포, 운영하는 방법을 현대화한다. 이들 기업에서 사용하는 개발 및 프로덕션 클러스터의 수가 증가함에 따라 점점 더 커지는 환경 전반에 일관적인 구성 및 보안 정책을 만들어 적용하기가 어려워지고 있다”라고 썼다.   깃옵스 : 깃으로 시작하는 데브옵스 깃옵스는 이와 같은 문제에 대처하기 위해 기존 데브옵스에 대한 확장으로 부상했다. 인프라를 코드로 취급함으로써 애플리케이션과 그 기반 인프라를 버전 제어 시스템(대체로 깃)에 저장할 수 있으며, 그러면 깃은 개발 팀과 운영 팀 모두를 위한 단일 진실 공급원이 된다.   이후 소프트웨어 에이전트(대부분의 경우 오픈소스 아르고(Argo) 또는 플럭스(Flux) 지속적 제공 툴)가 애플리케이션의 실제 상태가 구성 파일에 선언된 원하는 상태와 일치하는지를 확인한다. 현재 위브웍스(Weaveworks), 코드프레시(Codefresh)와 같은 업체는 기업의 도입을 용이하게 하기 위해 호스팅되는 깃옵스 플랫폼을 구축하는 방안을 모색하고 있다.   그랜트는 Infoworld와의 인터뷰에서 “자세히 보면 깃옵스는 퍼펫(Puppet)과 비슷하다. 선언적 접근 방법이며 동기화를 유지하는 ...

깃옵스 오케스트레이터 컨테이너 2022.05.27

“고갈되지 않은 하이브리드 멀티클라우드의 이점” 캐노니컬 서베이

캐노니컬은 2021년 11월 두 번째 연례 쿠버네티스 및 클라우드 네이티브 운영 보고서의 일환으로, 1,300명 이상의 IT 전문가를 대상으로 쿠버네티스와 베어메탈, VM, 컨테이너, 서버리스 애플리케이션 활용 현황을 조사했다. 이 조사에서 83%의 응답자가 하이브리드 멀티클라우드 환경을 사용한다고 답했다. 1년 전의 조사와 비교하면, 하이브리드 클라우드나 멀티클라우드를 사용하지 않는다는 응답은 22.4%에서 16.4%로 떨어졌다. 하지만 구글의 대표 소프트웨어 엔지니어인 팀 호킨은 이 숫자에 너무 기대하지 말라고 경고했다. 호킨은 “사람들은 종종 하이브리드 멀티클라우드를 구축하면서 전 세계를 연결하는 거대한 네트워크와 모든 클라우드 애플리케이션이 자원이 풍부하고 저렴한 곳에서 실행될 것이라 생각한다. 하지만 실제로는 각각의 환경을 필요한 만큼만 이용할 뿐이다”라고 지적했다. 중요한 것은 얼마나 많은 일상 운영을 특별히 고민하지 않고 서로 다른 여러 곳의 클라우드에 걸쳐 분산시킬 수 있는가이다. 캐노니컬 CEO 마크 셔틀워스는 “중견 기업 또는 대기업이 완전히 자동화된 프라이빗 클라우드를 보유하고 두 곳 이상의 퍼블릭 클라우드 서비스 업체와 관계를 유지하는 정도가 합리적이다. 이런 환경이라면 기업은 어떤 애플리케이션이든 프라이빗 클라우드와 두 곳의 퍼블릭 클라우드에서 실행할 수 있을지 고려할 수 있을 것”이라고 덧붙였다. 또한 2021년보다 더 많은 22.1%의 응답자가 개발을 촉진하고 데브옵스를 자동화하는 데 하이브리드 멀티클라우드 기술을 사용한다고 답했다. 이들 하이브리드 멀티클라우드 기술은 기존에는 시험적인 고려 대상이었지만, 지금은 서로 다른 플랫폼의 역량을 기반으로 실행 가능한 최적화 방안으로 고려되고 있다. 15%는 재해복구용으로, 또는 클라우드 백업 옵션을 확대해 비용을 절감하기 위해 하이브리드 멀티클라우드를 사용한다고 답했다. 그외의 배치 시나리오로는 애플리케이션 이전(7.4%), 미션 크리티컬 데이터베이스의 클러스터링(7.3%), 퍼블릭...

캐노니컬 설문조사 쿠버네티스 2022.05.20

도커 데스크톱에 '도커 확장' 추가…앰베서더ㆍ앵커 등 14개 툴 통합

도커가 5월 10일(현지 시각) 도커 데스크톱(Docker Desktop)에서 ‘리눅스 기본 지원’뿐만 아니라 다양한 개발자 도구를 통합하는 ‘도커 확장(Docker Extensions)’을 제공한다고 밝혔다.    도커콘 2022(DockerCon 2022)에서 발표된 ‘도커 확장’은 앰베서더(Ambassador)부터 앵커(Anchore), 아쿠아섹(AquaSec), 에버엑스(EverX), 제이프로그(JFrog), 레이어5닷아이오(Layer5.io), 옥테토(Okteto), 포테이너(Portainer), 레드햇(Red Hat), 싱크(Snyk), 수세/랜처(SUSE/Rancher), 테일스케일(Tailscale), 우피치(Uffizzi), VM웨어(VMware)까지 총 14개 파트너의 도구를 통합했다.  도구 유형은 ▲쿠버네티스 배포 간소화(VM웨어 탄주, 옥테토, 포테이너, 레드햇, 랜처), ▲보안 소프트웨어 공급망(앵커, 아쿠아섹, 제이프로그, 싱크), ▲하이브리드 개발 환경 지원(앰배서더, 테일스케일, 레이어5, 우피치)으로 구분된다. 아울러 도커 커뮤니티는 새로운 도커 익스텐션 SDK를 사용해 앞으로 더 광범위하게 확장될 수 있을 것이라고 업체 측은 덧붙였다.  도커의 CEO 스콧 존스턴은 “업무 도구가 당장 필요한 많은 개발자가 크고 복잡한 클라우드 네이티브 도구 환경으로 인해 어려움을 겪고 있다. 도커 익스텐션을 통해 개발자는 도구를 검색, 다운로드, 구성, 평가, 관리하는 데 시간을 낭비하지 않고 앱에 필요한 도구를 빠르게 검색하고 사용할 수 있다”라고 말했다.  업체에 따르면 이제 리눅스 워크스테이션에서도 도커 데스크톱을 쓸 수 있다. 맥OS 및 윈도우에서 도커 데스크톱을 사용하는 것과 같은 로컬 개발 경험을 제공한다. 존스턴에 의하면 리눅스 지원은 지난 12개월 동안 도커 커뮤니티에서 가장 많은 요청을 받은 기능이었다. 최근 자금 조달 라운드를 통해 개발을 추진할 수 있었다. 리눅스용 도커...

도커 도커 데스크톱 리눅스 2022.05.13

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

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

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

레드햇, 쿠버네티스용 애플리케이션 파운데이션 출시

레드햇이 자사의 오픈시프트 쿠버네티스 플랫폼과 함께 작동하는 애플리케이션 서비스 ‘레드햇 애플리케이션 파운데이션(Red Hat Application Foundations)’을 공개했다. 이를 통해 하이브리드 및 멀티클라우드 환경에서 컨테이너화된 애플리케이션 개발을 가속할 수 있다고 업체 측은 밝혔다.   지난 4월 25일(현지 시각) 발표된 레드햇 애플리케이션 파운데이션은 애플리케이션과 인프라 현대화의 일환으로 애플리케이션 및 데이터 서비스를 구축하고 통합하는 개발자를 위한 툴킷 역할을 한다. 업체에 따르면 이는 개발자에게 컨테이너 환경 안팎에서 애플리케이션을 연결할 수 있는 통합 솔루션을 제공한다. 아울러 애플리케이션 서비스 및 구성요소는 개발자가 클라우드 네이티브 애플리케이션 패턴을 활용하고, 하이브리드 클라우드 또는 멀티클라우드 환경에서 애플리케이션 개발을 가속화할 수 있도록 설계됐다고 업체 측은 설명했다.  마이크로서비스, API, 이벤트 기반 아키텍처를 통해 현대화 패턴을 지원하는 레드햇 애플리케이션 파운데이션에는 고성능 데이터 스트리밍, API 관리, 서비스 연결, 경량 런타임 및 프레임워크, 기타 기능 등의 구성요소가 포함돼 있다. 이는 현재 사용할 수 있으며, 레드햇 사용자라면 계정 담당자에게 연락하여 번들을 설정할 수 있다. ciokr@idg.co.kr  

레드햇 쿠버네티스 애플리케이션 파운데이션 2022.04.27

구글, CNCF에 이스티오 서비스 메시 기증 제안

구글 클라우드가 자사의 인기 오픈소스 서비스 메시 기술인 이스티오(Istio)를 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)에 기증할 것을 제안했다. 구글 클라우드의 엔지니어링 부사장 첸 골드버그는 블로그 포스트를 통해 “오늘 구글과 이스티오 운영위원회는 이스티오 프로젝트를 인큐베이션 프로젝트로 고려해 줄 것을 제안했음을 발표하게 되어 기쁘다”고 밝혔다.   2017년 출시된 이스티오는 컨테이너로 배치하고 쿠버네티스로 관리하는 애플리케이션의 네트워크 트래픽과 원격 측정, 보안을 개발자가 관리할 수 있도록 해준다. 역시 구글이 개발한 쿠버네티스는 지난 2015년에 CNCF에 기증됐다. 이스티오 외의 인기 서비스 메시 솔루션으로는 하시코프가 개발한 링커드(Linkerd)와 콘설(Consul) 등이 있다. 마이크로소프트도 2020년에 자체 오픈소스 서비스 메시 솔루션인 OSM(Open Service Mesh)를 CNCF에 이관할 것이라고 발표했다. 구글은 이스티오가 CNCF로 이관되더라도 프로젝트의 핵심 관리자이자 업스트림 코드 기여자로 계속 투자할 것이라고 밝혔다. 구글은 2019년 쿠브콘(KubeCon) 행사에서 자사의 인기 서버리스 플랫폼인 케이네이티브(Knative나 이스티오를 CNCF로 이관할 계획이 없다고 밝힌 바 있다. 하지만 전략을 바꿔 2021년 11월 케이네이티브를 기증하겠다고 제안했고, CNCF는 올해 3월에 육성 프로젝트로 승인했다. 이스티오 역시 이 과정을 거칠 것으로 보인다. 골드버그는 “이스티오는 쿠버네티스 생태계의 주요 구성 요소 중 CNCF가 관장하지 않는 마지막 기술이며, 이스티오 API는 쿠버네티스 환경에 잘 맞춰져 있다. 최근 케이네이티브를 기증한 데 이어 이스티오가 받아들여지면 재단의 지원 아래 클라우드 네이티브 스택이 완성될 것이고, 이스티오는 쿠버네티스 프로젝트와 한층 가까워질 것”이라고 강조했다. editor@itworld.co.kr

구글 CNCF 클라우드네이티브 2022.04.26

쿠버네티스 관리를 '더 쉽게' 만드는 15가지 툴

쿠버네티스는 컨테이너화된 애플리케이션을 대규모로 배포하기 위한 표준적인 방법이 됐다. 그냥 ‘표준’이라고 말하는 사람도 많다. 복잡하게 확산하는 컨테이너 배포를 길들이는 데 쿠버네티스가 도움이 된다면, 그런 쿠버네티스를 길들이는 데는 무엇을 사용해야 할까? 쿠버네티스 역시 복잡하게 얽히고 관리하기 어려워질 수 있다. 물론 쿠버네티스가 성장하고 발전하는 과정에서 많은 부분이 정리될 것이다. 그러나 일부 사용자는 쿠버네티스가 다루기 쉬워질 때까지 기다리지 않고 프로덕션 단계의 쿠버네티스에서 일반적으로 발생하는 문제에 대처하기 위한 독자적인 해결책을 내놨다.   골드핑거 : 쿠버네티스 클러스터 시각화 인간은 시각적 동물이다. 그래프와 차트를 보면 큰 그림을 쉽게 이해할 수 있다. 쿠버네티스 클러스터의 범위와 복잡성을 감안하면 가능한 모든 시각적 도움을 얻는 것이 좋다. 블룸버그 기술 사업부가 오픈소스로 공개한 골드핑거(Goldpinger)는 쿠버네티스 클러스터 내에서 실행되면서 노드 간 관계를 인터랙티브한 지도로 표시하는 간단한 툴이다. 정상적인 노드는 녹색, 비정상적인 노드는 빨간색으로 표시된다. 노드를 클릭하면 세부 내용을 볼 수 있다. 스웨거(Swagger)로 API를 맞춤 설정해서 부가적인 보고, 지표를 비롯한 다양한 요소를 통합할 수 있다. K9s : 전체 화면의 쿠버네티스 CLI UI 관리자는 ‘하나의 창’으로 구성된 유틸리티를 좋아한다. K9s는 쿠버네티스 클러스터를 위한 전체 화면 CLI(Command Line Interface) UI다. 실행 중인 파드, 로그, 배포를 한눈에 확인하고 셸에 빠르게 액세스할 수 있다. 참고로 K9s가 정상적으로 작동하려면 사용자 및 네임스페이스 수준에서 사용자에게 쿠버네티스 읽기 권한을 부여해야 한다. 캅스 : 쿠버네티스 클러스터를 위한 명령줄 쿠버네티스 팀이 개발한 캅스(Kops)는 명령줄에서 쿠버네티스 클러스터를 관리할 수 있게 해준다. AWS, GCE에서 실행되는 클러스터를 지원하며 VM...

쿠버네티스 골드핑거 2022.03.21

구글이 CNCF에 K네이티브를 기부한 이유

지난 수 년 동안 오픈소스 K네이티브(Knative) 프로젝트를 CNCF(Cloud Native Computing Foundation)에 기부할 생각이 없다고 밝혀 온 구글이 3월 2일 갑작스럽게 K네이티브를 인큐베이팅 프로젝트로 기부하겠다고 밝혔다. K네이티브는 쿠버네티스(Kubernetes)에서 서버리스 작업 부하를 구축, 배치, 관리하는 오픈소스 플랫폼이다. 구글 엔지니어 주도로 2018년에 등장한 이후 IBM, 레드햇, VM웨어, SAP 등이 기여했다. 그 이후로 K네이티브는 AWS 람다(Lambda) 또는 애저 펑션(Azure Functions) 등의 단일 클라우드 플랫폼에 얽매이지 않고 쿠버네티스에서 서버리스 애플리케이션을 구축할 수 있는 유망한 수단으로 개발되었다. 27% 도입률을 기록한 K네이티브는 최근 설문조사에 따르면 CNCF 커뮤니티에서 가장 인기 있는 비호스팅 설치형 서버리스 플랫폼이다.   인기와 성숙도가 높아지면서 구글이 K네이티브를 제공업체에 중립적인 CNCF에 넘겨주어야 한다는 요구도 증가했다. 그래서 큐브콘 2019 행사에서 구글이 오리지널 쿠버네티스 프로젝트를 성공적으로 수행했기 때문에 K네이티브나 서비스 메시 이스티오(Istio)를 CNCF에 기부할 계획이 없다고 발표했을 때 오픈소스 커뮤니티의 반응은 좋지 않았다. 2021년 말 구글은 갑자기 노선을 바꾸어 인큐베이팅 프로젝트로 CNCF에 이스티오를 제외한 K네이티브의 상표, 지적 재산권, 코드를 기부할 것이라고 발표했다.   변심의 이유 IBM은 발표 후 공개적으로 구글의 결정에 갈채를 보냈다. IBM의 엔지니어 마이클 맥시밀렌은 “CNCF에 합류함으로써 K네이티브 커뮤니티는 K네이티브가 지속적으로 성장하고 더 많은 사용자와 개발자를 유지할 수 있는 더 크고 활기찬 커뮤니티가 될 것”이라고 밝혔다. 또한 “K네이티브를 포용하게 된 CNCF는 중요한 퍼즐 한 조각을 추가했고, 현재 프로젝트 실현에 유용한 클라우드 컴퓨팅, 컨테이너 기술, 다양...

K네이티브 오픈소스 CNCF 2022.03.08

프라이스라인 CTO의 눈으로 보는 대규모 마이크로서비스 구축 및 실행

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

마이크로서비스 데브옵스 컨테이너 2022.02.25

IDG 블로그 | “개발자에 최적화된 클라우드 하나면 된다” 멀티클라우드 필요성에 대한 재고

한 클라우드 서비스 업체만 이용한다는 CEO의 선언에 속으면 안 된다. 멀티클라우드 체제는 바뀌지 않을 것이기 때문이다. 모든 중견 기업은 우연히, 혹은 의도적인 설계를 통해 멀티클라우드를 구축한다. 일반적으로 기업의 IT는 이런 방식으로 작동한다. 그래서 여러 클라우드에 대한 전문성을 쌓으면 마치 제2외국어를 배우는 것처럼 경력에 도움이 된다. 하지만 멀티클라우드를 구축하는 데 비용이 소요된다. AWS 전 임원인 팀 브레이가 최근 자신의 블로그에 작성한 것처럼, 직원의 생산성을 높이는 것이 가장 좋은 클라우드 전략이다. 이를 위한 한 가지 방법은 클라우드 서비스 업체 한 곳을 선택해 표준화하는 것이다. 하지만 단지 야망에 그칠 뿐이다.     우연에 의한 멀티클라우드 현재 많은 사용자가 멀티클라우드에서 서비스를 실행하고 있다. 비록 CIO 자신은 그렇게 생각하지 않을 지 몰라도, 수년 전부터 오픈소스가 확산되면서 이제 CIO가 기업에서 발생하는 모든 상황을 파악할 수 있는 최고의 직위는 아니다. 개발자는 애플리케이션과 인프라를 점점 더 빠른 속도로 배포해야 한다는 압력을 받고 있으며, 이를 달성하는 데 도움이 되는 모든 것을 사용할 것이다. 그 예로는 구글 빅쿼리(BigQuery)나 AWS 람다(Lambda), 마이크로소프트 애저 쿠버네티스(Kubernetes) 서비스 등 다양한 클라우드 서비스가 있다. 컴퓨팅 및 스토리지와 같은 가장 기본적인 요소도 클라우드마다 천차만별이기 때문에 개발자는 한 클라우드에 익숙해지려고 할 것이다. 이처럼 사용자는 의도와 상관없이 멀티클라우드를 도입하게 된다. 다만, 문제는 기업이 반드시 멀티클라우드를 구축해야만 하느냐인 것이다.   개발자를 위한 최적화 기업의 IT 부서는 하드웨어나 소프트웨어가 아닌 직원, 즉 개발자가 가장 가치 있는 자산이라는 사실을 종종 간과한다. 2008년 디스코스(Discourse)와 스택 익스체인지(Stack Exchange) 설립자인 제프 애트우드는 이런 실정을...

멀티클라우드 빅쿼리 람다 2022.02.10

아르고 CD에서 고위험 취약점 발견 “헬름 차트 악용”

사이버 공격자가 소프트웨어의 기밀 정보를 탈취할 수 있는 고위험 취약점이 아르고 CD(Argo CD)에서 발견됐다. 아르고 CD는 쿠버네티스로 배포되는 애플리케이션을 위한 CD(Continuous Delivery) 플랫폼이다. 해당 취약점은 현재 수정된 상태다.   아르고 CD 취약점을 발견한 보안업체 아피로(Apiiro) 연구팀에 따르면, 공격자는 악의적으로 조작된 쿠버네티스 애플리케이션 배포 구성 파일을 아르고에 공급해 중앙 리포지토리 서버의 파일과 환경설정, 비밀 토큰을 노출시킬 수 있었다. 이 경우 권한 상승 및 기업의 클라우드 인프라로 측면 이동이 발생할 수 있다.  아르고 CD는 쿠버네티스 환경에서 사용되는 오픈소스 선언형 깃옵스(GitOps) CD 툴이다. 개발자는 아르고를 사용해 중앙 Git 리포지토리 서버에 배포된 애플리케이션을 코드의 다른 상태와 동기화할 수 있다. 설명문에 따르면, 아르고 CD는 특정한 목표 환경에서 원하는 상태의 애플리케이션 배포를 자동화한다. 애플리케이션 배포는 Git 커밋에서 브랜치, 태그 또는 특정 버전의 매니페스트에 대한 업데이트를 추적할 수 있다. 아르고는 배포된 애플리케이션의 상태를 지속해서 모니터링하고 라이브 상태를 Git 리포지토리에서 원하는 상태와 비교하는 쿠버네티스 컨트롤러와 같다. 애플리케이션이 원하는 상태를 벗어나면 ‘동기화 해제’로 플래그를 지정하며, 다양한 수정 옵션을 자동 또는 수동으로 설정할 수 있다. 아르고는 다른 툴을 통한 애플리케이션 배포 정의도 지원한다. 지원하는 툴은 다양한 쿠버네티스 구성요소를 정의하는 도구인 커스터마이즈(Kustomize), 쿠버네티스 매니페스트의 작성/공유/배포를 위한 프레임워크인 케이소네트(Ksonnet), JSON의 확장이자 데이터 템플릿 정의에 사용하는 구글의 구성 언어 제이소네트(Jsonnet), 평문 YAML/JSON 매니페스트, 쿠버네티스 헬름(Helm) 차트, 그 외 플러그인으로 통합된 모든 사용자 정의 구성 관리 툴까지 다양...

쿠버네티스 아르고CD 헬름 2022.02.08

“미래 기회 위한 승부수는 클라우드 네이티브" KD운송그룹 차세대 ERP 구축 사례 - IDG Case Study

18개 운수사와 5,000여 대의 버스, 터미널, 정비소 등을 보유하고 있는 KD운송그룹은 차세대 ERP 시스템 구축 프로젝트를 성공적으로 마쳤다. 전통적인 유닉스 환경을 표준 x86 환경으로 이전하는 것은 물론, 컨테이너 기반의 클라우드 네이티브 환경으로 한 번에 전환하는 데 성공했다. 또한 DR 센터를 구축하고 운영을 자동화해 복구성과 가용성 역시 한 단계 높였다. KD운송그룹의 과감한 선택은 미래 가능성에 초점을 맞춘 것이지만, 기업의 핵심 시스템과 관련된 안정성, 운영, 비용, 기술 지원, 기반 솔루션 등 수많은 요소를 검토하고 고려한 결과이기도 하다. KD운송그룹의 치열한 고민과 실제 구축 과정을 살펴본다. 주요 내용 - 전사 종합정보시스템으로 자리 잡은 ERP - “안주보다는 혁신” 차세대 시스템 전환 단행 - 비용과 안정성을 넘어 미래 잠재력에 초점 - 구축과 운영을 보장하는 올인원 컨테이너 관리 솔루션 - 평온한 변화 속에 전사적 혁신의 기반 마련

KD운송그룹 클라우드네이티브 컨테이너 쿠버네티스 2022.02.08

“어디서나 실행 가능한 관리형 쿠버네티스” 구글 클라우드 안토스의 모든 것

구글 클라우드는 2019년 4월, 안토스(Anthos) 플랫폼을 출시했다. 당시 기업 고객이 온프레미스와 구글 클라우드, 그리고 무엇보다도 AWS, 마이크로소프트 애저와 같은 주요 퍼블릭 클라우드에서 쿠버네티스(Kubernetes) 워크로드를 실행할 수 있는 방편을 제공하겠다고 약속했다.   구글 CEO 선다 피차이는 2019년 샌프란시스코에서 열린 구글 클라우드 넥스트(Google Cloud Next)에서 안토스에 대해 개발자가 한 번의 코드 작성으로 어디에서나 실행할 수 있도록 하는 것이라고 밝혔다. 호환되지 않는 클라우드 아키텍처를 연결해 하이브리드 및 여러 퍼블릭 클라우드에 걸쳐 컨테이너화된 애플리케이션 개발, 배포, 운영을 간소화한다는 개념이다. 결정적인 멀티 클라우드 지원이 실현되기까지 다소 시간이 걸렸다. 구글은 2020년 4월 AWS를, 작년 12월에는 마이크로소프트 애저를 지원하겠다고 밝혔다. 안토스 멀티 클라우드 API를 출시하면서 진정한 하이브리드 및 멀티 클라우드 운용과 관련한 처음 약속을 지킨 것이다. 구글 클라우드 안토스는 모든 쿠버네티스 워크로드의 관리를 위한 단일 플랫폼을 제공한다. 이를 통해 기업 고객은 여러 개의 독자적인 클라우드 기술 별로 인증된 전문가에 의존하지 않고 한 가지 기술에 집중할 수 있다. 또한, 안토스는 특정 워크로드와 네임스페이스에 연결된 맞춤형 보안뿐만 아니라 여러 인프라에 걸쳐 공통적인 구성을 적용하는 기능을 통해 하이브리드 및 퍼블릭 클라우드 전반이 워크로드 실행 위치에 관계없이 일관성 있게 운영되도록 한다. 운영자는 하나의 콘솔에서 클러스터 텔레메트리와 로그 정보를 추적할 수 있다.   구글 클라우드 안토스 구성요소 안토스는 구글이 2019년 이전에 구축했던 클라우드 서비스 플랫폼(Cloud Services Platform)이 발전한 형태이다. 구글 클라우드 관리형 서비스인 구글 쿠버네티스 엔진(Google Kubernetes Engine, GKE), GKE 온프렘(On-Pre...

쿠버네티스 구글클라우드플랫폼 안토스 2022.01.27

"쿠버네티스 보급률 증가, 서버리스는 소폭 하락"…클라우드 네이티브 컴퓨팅 재단 연구

쿠버네티스 컨테이너 오케스트레이션 시스템은 개발자 사이에서 전기를 맞았다. 그러나 클라우드 네이티브 컴퓨팅 재단(CNCF)의 연구 결과에 따르면 서버리스 아키텍처의 보급은 오히려 줄어들었다. 12월 20일 공개된 클라우드 네이티브 개발 현황(The State of Cloud Native Development) 조사는 2020년 11월부터 2021년 2월까지 조사업체 슬래시데이터(SlashData)가 155개국 1만 9,000여 명의 개발자를 대상으로 이루어졌다. 조사 대상 중 3,800명 이상의 참가자가 백엔드 서비스와 사용 기술 개발 관련 질문에 응답했다.  이 연구는 2021년 1분기 쿠버네티스를 사용하는 개발자가 560만 명으로 1년 전인 2020년 1분기 390만 명보다 67% 증가했다는 내용을 담고 있다. 쿠버네티스는 모든 백엔드 개발자의 31%가 사용하고 있었고, 이 수치는 1년 동안 4% 증가했다. 엣지 개발자 사이에서의 쿠버네티스 사용률은 11% 늘어난 63%로 조사됐다. 엣지 기술은 조사 대상인 기술 부문 가운데 가장 높은 보급률을 기록했다.   그러나 서버리스 아키텍처에 종사하는 개발자 비율은 27%에서 24%로 소폭 하락했다. 서버리스 컴퓨팅은 AWS 람다 같은 서비스를 통해 연산 주기를 동적으로 배치하는 기술이다. 서버리스 컴퓨팅의 최신 경향이 ‘약세’로 나타난 이유는 특정 업체에 종속되는 것을 우려하는 현상, 그리고 서버리스 솔루션의 유연성 부족으로 관측됐다. 구글 클라우드 런의 지지율이 높아지고 있지만 여전히 AWS 람다가 서버리스 개발자 53%가 사용하는 서비스로 나타났다. 지역적으로는 북미, 동유럽, 중동, 아프리카 백엔드 개발자 사이의 클라우드 네이티브 기술 사용이 줄었다는 점이 특징이다. 보고서에 따르면, 클라우드 네이티브 개발자는 30만 명 가량 늘어난 680만 명이었고, 컨테이너 오케스트레이션 도구 사용 개발자가 460만 명, 서버리스 플랫폼 사용자가 400만 명, 둘 다를 사용하는 개발자가 180...

서버리스 쿠버네티스 컨테이너 2021.12.23

쿠버네티스 SW 공급망 보안을 강화하는 방법

현대 소프트웨어 개발 방식의 확산으로 소프트웨어 공급망을 보호하는 것이 예전보다 훨씬 더 중요해졌다. 코드는 오픈소스 라이브러리에 종속성이 있고 오픈소스 라이브러리는 다른 라이브러리에 종속성이 있고, 이런 식으로 계속 이어진다. 자신이 개발하지 않았고 컴파일하지 않았으며 대부분의 경우 출처도 알 수 없는 코드가 사슬처럼 엮여 있다.   이 코드 중에는 거의 모든 곳에 사용되는 코드도 있다. 업계를 발칵 뒤집어 놓은 로그포셸(Log4Shell) 익스플로잇은 흔히 사용되는 자바 로깅 구성요소인 로그포제이(log4j)에 있는 오래된 버그를 기반으로 한다. 결국 지금 업계는 거인의 어깨 위가 아니라, 소수의 애플리케이션 및 구성요소 유지관리자의 어깨 위에 올라가 있다. 전 세계 인프라가 이들이 한가한 시간에 선의로 하는 일에 의존해 굴러간다.   분산 개발로 위험 가중 유지관리자의 일을 깎아내리는 것이 아니다. 이들은 현대 소프트웨어 공급망의 필수적인 요소다. 소소한 모듈부터 전체 컨테이너 기반 플랫폼까지 모든 것을 제공한다. 이렇게 중요한 코드를 만들지만 그에 상응하는 인정도, 보상도 받지 못한다. 안타깝게도 지금까지 악의적 행위자가 유지관리 코드를 넘겨받아 악성코드를 추가한 사례가 여러 번 있었다. 오래 신뢰를 받아온 코드이므로, 설치할 가능성이 높다고 공격자가 판단했기 때문이다. 코드가 그룹 작업의 결과물이 되는 경우가 증가하고 있으므로 이와 같은 공격은 앞으로 더 늘어날 것이다. 이제 우리 스스로와 애플리케이션을 보호하려면 어떻게 해야 할까? 무엇보다 소프트웨어 공급망이 실제로 존재한다는 것, 그리고 코드가 서로 격리된 채 개발되던 시절이 오래전에 끝났다는 것을 이해해야 한다. 오픈소스와 서드파티 라이브러리는 현재 소프트웨어를 만드는 과정에서 필수적이며 그 중요성은 갈수록 더 커질 것이다. 소프트웨어 공급망을 보호하기 위해 취할 수 있는 조치는 무엇일까? 코드에서 라이브러리 스캔하기, 정적 및 동적 분석 사용하기, 코드에 디지털 서명 ...

쿠버네티스 보안 2021.12.21

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.