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.

데브옵스

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

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

컨테이너 쿠버네티스 클라우드네이티브 3일 전

CI/CD 파이프라인을 보호하는 모범 사례 5가지

엔지니어의 사고는 문제 이해하기, 해결책 만들기, 그리고 프로덕션 환경에 견고하고 안전한 구현을 배포할 방법 알아내기 순서로 흐른다.   일단 해결책이 구현된 이후 보안 모범 사례를 집어넣으면 복잡하고 자원이 많이 든다.  또한 혁신을 빠르게 내놔야 한다는 압박으로 인해 데브옵스 팀이 보안 부채를 떠안고 릴리즈하는 사례가 빈번하게 발생한다. 최선의 데브섹옵스 모범 사례는 지식, 권장 사항, 보안을 개발 프로세스의 “왼쪽으로 옮겨(shift left)” 애자일 개발 팀이 마이크로서비스, 애플리케이션 또는 데이터베이스에 바로 보안을 구현해 넣도록 하는 것이다.   그러나 지속적 통합, 지속적 제공(CI/CD) 파이프라인은 어떻게 해야 할까? 코드를 빌드, 통합, 패키징해서 환경에 제공하기까지의 수작업 단계가 CI/CD 도구에 스크립팅되어 있을 때 이 자동화는 배포의 안정성을 높여준다. 견고한 CI/CD 구현을 갖춘 데브옵스 팀은 그 다음 단계로 프로덕션 환경을 위한 지속적 배포까지 고려하는 경우가 많다. 따르는 위험은 더 높지만 더 자주 배포할 수 있게 된다.   안전하고 견고한 CI/CD 파이프라인을 구축할 때 필요한 권장 사항과 모범 사례를 확인해 보자.   1. 모범적인 보안 개발 방법 구축 캡제미니(Capgemini)의 애자일 및 데브옵스 리더인 쿨비르 라이나는 가장 중요한 일을 가장 먼저 해야 한다면서 “CI/CD 파이프라인에서 자동화를 다룰 때 보안과 품질은 코드에 내장해야 하며 품질 관리 단계로 미루면 안 된다. 개발자가 적절히 코드를 린팅하기 위해서는 개발자의 통합 개발 환경에 통합된 보안 도구가 필요하다”라고 말했다.   린팅은 코딩 스타일 편차와 안전하지 않은 관행을 식별하는 도구에서 수행하는 프로세스다. 고급 정적 애플리케이션 보안 테스트(SAST) 도구는 버퍼 오버플로우, SQL 주입 결함을 비롯한 여러 문제점을 찾을 수 있다. 라이나는 SAST를 지속적 통합에 통합할 것을 권장한다. ...

AI옵스 보안자동화 CICD 3일 전

“데브옵스 플랫폼 채택의 핵심 원동력은 보안” 깃랩, 데브섹옵스 현황 조사 결과 발표

깃랩(GitLab)은 제6차 연례 글로벌 데브섹옵스(DevSecOps) 조사 결과를 발표했다.    깃랩의 2022년 글로벌 데브섹옵스 조사에 따르면, 아시아 지역이 평균보다 높은 데브옵스 플랫폼 채택률과 개발 주기 자동화 실현을 기록한 것으로 나타났다. 또한 보안 및 컴플라이언스가 지속적으로 우선순위를 차지하고 있으며, 툴체인 통합에 대한 투자와 데브옵스 채택 가속화에 따른 영향이 지속되고 있음을 알 수 있다.  이번 조사에는 전 세계 5,001명에 달하는 개발자와 운영 및 보안 실무자, 조직 리더 등이 참여했다. 한국을 포함한 아시아 지역에서는 388명이 조사에 참여했다.   지난 2년 간 폭발적으로 기술 채택이 이뤄지면서 이번 조사 결과에서는 응답자의 거의 75%가 데브옵스 플랫폼을 채택했거나 연내 채택할 계획인 것으로 나타났다. 아시아 지역의 경우 평균보다 조금 높은 78%의 기업이 데브옵스 플랫폼을 채택했거나 연내 채택할 것으로 답했다. 2022년 조사 결과에 따르면, 기업들은 보안을 최우선 투자 영역으로 간주하고 있으며, 보안 팀원의 절반 이상이 자신의 기업이 이미 시프트 레프트(Shift Left) 보안으로 전환했거나 올해 안에 전환할 계획이라고 밝혔다.  또한 툴체인 통합도 최우선 과제로 제기되었다. 응답자의 69%가 모니터링, 개발 지연, 개발자 경험에 대한 부정적인 영향 등의 문제로 인해 툴체인 통합을 원하고 있는 것으로 나타났다. 전체 지역 중 아시아가 78%로 툴체인 통합에 가장 긍정적으로 답했으며 유럽이 62%로 가장 낮은 수치를 보였다.   직장에서 가장 자주 사용하는 깃(Git) 솔루션은 깃랩 직장에서 가장 많이 사용하는 깃 솔루션이 무엇인가라는 질문에 43%가 깃랩을 사용한다고 답했으며 뒤를 이어 29%가 깃허브 액션을 사용한다고 답했다. 아시아 지역에서는 44%가 깃랩을 사용하고 41%가 깃허브 액션을 사용하며 두 솔루션을 사용하는 비중이 큰 것으로 나타났...

깃랩 데브옵스 보고서 2022.09.01

글로벌 칼럼 | 데브옵스 시대는 끝났다

소프트웨어 개발 작업이 점점 더 복잡해짐에 따라 개발(dev) 전문가와 운영(ops) 전문가를 다시 한번 분리해야 할 때가 다가오고 있다. 이번에는 과거의 실수를 반복하지 않고 해낼 수 있을까?   2000년대 후반 소프트웨어가 세상을 집어삼키기 시작하면서 애자일 방법론과 클라우드 컴퓨팅의 부상과 함께 데브옵스(Devops)가 등장했다. ‘개발’과 ‘운영’을 근사하게 결합한 데브옵스는 과거에는 분리돼 있던 소프트웨어 구축, 배포 담당인 두 그룹을 하나로 모으는 것이 핵심이다. 이에 따라 소프트웨어 엔지니어가 사용자 피드백에 대한 대응을 개선해 제품을 더 자주 업데이트해야 할 필요성이 부상했다. 많은 기업이 데브옵스를 통해 이전에는 불가능했던 속도로 문제를 해결해 나갔고, 일부 기업은 개발자에 운영 작업에 대한 책임까지 담당하는 방법으로 데브옵스를 활용했다. 풀 스택 개발자로 구성된 일종의 슈퍼 팀을 만들려고 했던 셈이다. 그러나 데브옵스 포 더미즈(Devops for Dummies)의 저자이자 아마존 웹 서비스의 커뮤니티 참여 책임자인 에밀리 프리먼은 트위터를 통해 “개발자는 대부분 운영 문제를 다루고 싶어 하지 않는다”라고 문제를 제기했다. 이 트윗을 본 많은 개발자가 수백 개 자기 생각을 답장으로 보냈다. 예를 들어 패스트푸드 회사 치포틀레(Chipotle)의 소프트웨어 엔지니어인 스콧 팬탈은 “맞다. 나 역시 개발자이고 운영 문제를 다루고 싶지 않다”라고 썼다. SUSE의 개발자 에반젤리스트인 앤드루 그레이시는 “개발자와 운영진은 서로 다른 역할을 맡아 긴밀하게 협력해야 한다. 팀 간의 공감이 가장 중요하다”라고 말했다. 더 많은 운영, 보안 문제를 소프트웨어 전체 수명 주기의 ‘왼쪽’으로 이동시켜 소프트웨어 개발자의 영역으로 옮기는 데브옵스 개념은 분명히 많은 장점이 있지만 위험한 병목 현상으로 이어질 가능성도 있다. 쿠버네티스(Kubernetes) 스토리지 전문업체 온닷(Ondat)의 제품 책임자인 제임스 브라운은 “개발자를 너무 많...

데브옵스 DevOps 2022.08.25

"머신러닝+자율기능" 데브옵스 시대, 새로운 네트워킹의 조건

디지털 트랜스포메이션을 통해 기업은 경쟁 우위 확대, 새로운 수익사업 개발, 고객 경험 개선 등을 실현하고 있다. 그러나 이 모든 것을 위해 데브옵스 엔지니어는 할 일이 많다. 업무의 중요도와 요건에 따라 이를 지원하는 클라우드 서비스 업체의 리소스를 활용하고 쿠버네티스, 마이크로서비스, 기타 클라우드 네이티브 컴퓨팅 툴을 사용해 이른바 '애자일', 즉 더 빠른 속도로 애플리케이션을 구축, 테스트, 배포해야 하는 상황이다.   엔지니어와 애플리케이션 스택이 애자일을 지향하는 만큼 네트워크도 애자일에 적합해야 하는데, 바로 멀티클라우드 환경을 위한 풀스택 자율 네트워킹이다. 이를 통해 기업은 단기간에 투자 가치를 회수할 수 있고 데브옵스 엔지니어는 생산성과 사업 성장을 극대화할 수 있는 수단을 확보할 수 있다.   레거시 네트워킹 툴의 한계 애플리케이션과 서비스의 제공 속도를 높이면 비즈니스 측면에서 많은 장점이 있지만 동시에 감수해야 할 위험과 해결해야 할 과제도 함께 늘어난다. 사용자가 성능 문제를 겪고 결과적으로 생산성이 저하된다면 혁신적인 애플리케이션도 아무 소용이 없다. 따라서 보유한 애플리케이션이 안전한 경험을 제공하는지, 기업과 직원, 고객을 위험에 드러내는지, 모든 규정 준수 요건을 충족하는지 확인해야 한다. IDC에 따르면 클라우드로 이동하는 애플리케이션이 많아지면서 올해 말이면 사상 처음으로 클라우드 투자가 비 클라우드 IT 인프라 투자를 앞지를 전망이다. 또한, 프로시모(Prosimo)의 최신 ‘멀티클라우드 인프라 상태 보고서’에 따르면 기업 91%가 복수의 클라우드를 사용할 계획이며 62%는 2년 이내에 사용할 계획이다. 클라우드 사용 규모가 커질수록 복잡성도 커지기 마련이다. 기업은 이 새로운 역동적 IT 환경을 온프레미스 데이터센터, 엣지 컴퓨팅, 클라우드 인프라에 걸쳐 일관성 있게 오케스트레이션 및 관리하는 데 애를 먹고 있다. 많은 기업이 전통적인 레거시 네트워킹 툴을 사용해 연결성 요건과 씨름해 왔지만, 효...

데브옵스 네트워킹 머신러닝 2022.08.12

깃가디언, 오픈소스 소프트웨어 위험 탐지 프로젝트 ggcanary 출범

코드 보안 플랫폼 제공업체 깃가디언(GitGuardian)이 침해된 개발자 및 데브옵스 환경을 탐지하기 위한 새로운 오픈소스 카나리아 토큰 프로젝트를 발표했다. 설명에 따르면 기업 보안 팀은 깃가디언의 카나리아 토큰(ggcanary)을 사용해서 아마존 웹 서비스(AWS)의 비밀 정보 형식으로 카나리아 토큰을 만들어 배포할 수 있으며, 공격자가 토큰을 변조하는 즉시 경보를 트리거할 수 있다. 깃가디언의 이번 발표는 소프트웨어 공급망 및 데브옵스 툴과 관련한 위험에 대처하기 위한 여러 표준과 이니셔티브가 등장하는 업계 추세를 반영한다.     ggcanary의 특징은 “고도로 민감한” 침입 탐지 보도자료에서 깃가디언은 클라우드 및 현대 소프트웨어 개발 방식의 도입이 지속되면서 기업이 모르는 사이 공격 표면이 확장되고 있다고 말했다. 또한 인터넷에 대면한 자산과 기업 네트워크가 적절히 보호되지 않을 경우 공격자는 지속적 통합 및 지속적 배포(CI/CD) 파이프라인과 같은 소프트웨어 공급망 구성요소를 진입점으로 노리게 된다고 덧붙였다.   깃가디언의 연구에 의하면 공격자가 첫 액세스 권한을 획득한 후 취하는 일반적인 행동은 횡적 이동에 사용할 수 있는 하드 코딩된 유효한 인증 정보를 찾는 것이다. 깃가디언은 ggcanary 프로젝트가 기업에서 침해를 더 신속하게 탐지하도록 설계됐다면서 다음과 같은 특징을 설명했다.   테라폼(Terraform)에 의존. 하시코프(HashiCorp)가 개발한 인기 있는 코드형 인프라 소프트웨어 툴을 사용해서 AWS 카나리아 토큰을 생성하고 관리 AWS 클라우드트레일(CloudTrail) 감사 로그를 사용해서 공격자가 카나리아 토큰에서 수행한 모든 유형의 작업을 추적하는 고도로 민감한 침입 탐지 조직의 내부 경계, 소스 코드 리포지토리, CI/CD 툴, 티켓팅, 메시징 시스템(지라, 슬랙, 마이크로소프트 팀즈 등)에 최대 5,000개의 활성 AWS 카나리아 토큰을 배포할 수 있는 확장성 A...

오픈소스 데브옵스 카나리아토큰 2022.07.29

“코드형 인프라를 완성하는 네트워크 운영 자동화” 넷데브옵스의 이해

대부분 IT 책임자는 데브옵스(DevOps), 데브섹옵스(DevSecOps) 개념에 익숙할 것이다. 여기에 넷데브옵스(NetDevOps)라는 모델이 새로 등장해 특히 네트워킹 전문가와 관련해 상당한 반향을 일으키고 있다. 새로 떠오르는 기술이 그렇듯이 넷데브옵스도 누가 정의하는가에 따라 다양하다. 그러나 기본적인 수준에서 이 용어는 데브옵스 원칙을 컴퓨터 네트워킹에 적용하는 것을 나타낸다. 가트너의 네트워킹 부문 리서치 부사장인 앤드류 러너는 “넷데브옵스가 현재 뜨거운 화두”라며, “그러나 여러 정의와 관점이 있는 만큼 가장 먼저 해야 할 질문은 넷데브옵스가 무엇이냐는 것”이라고 말했다.     넷데브옵스의 정의와 개념 가트너의 정의에 따르면 넷데브옵스는 데브옵스의 지속적 통합/지속적 제공(CI/CD) 개념을 네트워킹 작업에 적용하는 것을 의미한다. 러너는 이 모델을 나타내는 다른 용어로 넷옵스(NetOps) 2.0, 코드형 네트워크(Network as Code), 깃옵스(GitOps) 네트워킹 등이 있다고 설명했다. 시장조사 업체 기가옴(GigaOm)은 “넷데브옵스는 환경 구성 드리프트를 제거하고 이를 통해 네트워크 내에 품질과 복원력을 내장하기 위한 프로그램되고 자동화된 워크플로우를 사용한 코드형 네트워크 인프라(IaC)의 추상화, 코드화, 구현을 포괄한다”고 설명했다. 기업이 조직이 넷데브옵스를 활용하려면 스테이징, 사전/사후 검증, 프로비저닝과 같은 네트워킹 작업 테스트가 포함된 자동화된 파이프라인이 있어야 한다. 기가옴은 넷데브옵스 파이프라인은 다양한 개발 환경의 코드를 프로덕션으로 전달하고, 이 과정에서 종합적인 검증과 규정 준수 테스트를 촉발한다고 덧붙였다. 또한 기가옴은 넷데브옵스에는 지속적 모니터링, 측정, 대응도 포함되어야 하며, 이를 통해 정상 상태로부터의 구성 드리프트가 탐지되는 경우 자동으로 교정 알림이 트리거되어야 한다.   넷데브옵스의 이점 데브옵스에 뿌리를 두고 있는 만큼 데브옵스의 많은 목표를...

데브옵스 넷데브옵스 자동화 2022.07.11

애플리케이션 성능을 높이기 위한 데브옵스 베스트 프랙티스 7가지

데브옵스(DevOps)는 생산 중인 애플리케이션 배포와 신뢰성을 개선하기 위한 개발자와 운영팀 사이의 협업과 관련된 개발 문화다. 데브옵스 베스트 프랙티스의 보편적인 목적은 더욱 탄탄한 자동화를 통해 개발팀과 운영팀의 경계에서 관리되는, 오류에 취약한 수동 프로세스를 대체하는 것이다. 여기에는 CI/CD(Continuous Integration and Continuous Delivery)를 통한 배포 파이프라인 자동화, 컨테이너를 통한 구성 표준화, 코드형 인프라 구성 등이 포함된다. 운영 측면에서 애플리케이션의 신뢰성을 높이는 데브옵스 베스트 프랙티스는 앱 관측가능성(observability) 개선, 모니터링 증가, 클라우드 및 인프라 운영 자동화가 포함된다. 하지만 데브옵스 베스트 프랙티스가 애플리케이션, 데이터베이스, 데이터 파이프라인, 클라우드 인프라의 성능까지 개선할 수 있을까? 성능과 사용자 경험에 영향을 미칠 수 있는 7가지 데브옵스 프랙티스와 방법론을 살펴보자.   1. 시프트 레프트 보안 취약점은 새로운 기능과 함께 배포되곤 한다. 보안 문제로 인한 고장 또는 성능 저하는 사용자 경험에 영향을 미치며 상당한 비즈니스 문제를 야기한다. 데브옵스 베스트 프랙티스의 목적은 요구 사항에 대해 정보보안팀과 협업하고 CI/CD 파이프라인 안에서 코드 취약점을 테스트하며, 소프트웨어 개발 과정에서 다른 보안 활동을 구현해 보안을 강화하는 것이다. 아카마이 수석 개발 지원자 마이크 엘리슨은 “앱 신뢰성의 중요한 구성요소는 가용성과 웹 애플리케이션 공격, DDoS 공격에서 앱을 적절히 보호하기 위해 적절한 조치를 취하는 것이다. 이런 차이가 온라인과 오프라인 상태의 차이를 만든다”라고 말했다. 시프트 레프트(shift left)는 데브옵스에서 데브섹옵스(DevSecOps)로 전환하는 작업의 일환이다. 엘리슨은 “데브옵스에 보안을 추가하는 것의 이점이 점차 확연해지면서 궁극적으로 더욱 강력한 데브섹옵스 문화가 형성되고 있다. 개발자가 앱 보안...

데브옵스 베스트프랙티스 데브섹옵스 2022.06.29

메르세데스 벤츠가 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

CI/CD에서 한 단계 더 나아간 '지속적 배포 자동화' 5가지 준비

많은 기업이 소프트웨어 개발 워크플로우의 효율성을 높이기 위해 지속적 통합/지속적 제공(Continuous integration/Continuous Delivery, CI/CD) 파이프라인을 앞다퉈 구축했다. 그런데 여기서 더 나아가서 CI/CD 파이프라인을 사용해서 지속적으로 프로덕션에 변경 사항을 반영하는 지속적 배포(Continuous Deployment)를 자동화한 기업은 극소수다. 여기에는 그럴 만한 이유가 있다.   사실 매일 또는 매시간 프로덕션으로 코드를 프로덕션으로 푸시한다고 생각하면 오싹한 느낌이 든다. 실제로 몇 년 전에 지속적 배포의 단점에 대한 기사를 쓴 적도 있다. “책임감 있는 데브옵스 팀이 배포 빈도를 높여야 할 때”라는 기사에서는 배포 빈도가 높을수록 좋다는 전제가 과연 옳은 전제인지를 질문했다.   그러나 지난 몇 년 사이 많은 변화가 있었고, 이제 고품질의 안정적인 배포를 자동화하기 위한 기술과 방식, 툴을 채택하는 데브옵스 팀은 점점 늘어나고 있다. 지속적 제공과 지속적 배포 간의 차이점을 설명하고, 데브옵스 팀이 CI/CD 파이프라인의 지속적 배포를 자동화하기 전에 해야 할 5가지를 살펴본다.   지속적 제공 vs. 지속적 배포 캡제미니(Capgemini)의 애자일 및 데브옵스 리더인 쿨버 라이나는 지속적 제공과 지속적 배포의 차이점에 대해 “지속적 제공은 프로덕션에 이르기까지 소프트웨어 릴리즈의 종단 간 자동화 흐름이고, 지속적 배포는 지속적 통합 이후 이 흐름에서 사전에 테스트된 프로세스를 통해 프로덕션으로 소프트웨어 패키지를 푸시하는 자동화된 프로세스”라고 설명했다.   프로덕션 배포 자동화는 그 결과가 비즈니스, 고객, 최종 사용자에게 영향을 미치는 만큼 위험도 크다. 그래서 데브옵스 팀이 배포를 자동화하기로 결정하는 경우 배포 프로세스에는 지속적 테스트와 철저한 오류 처리가 포함되어야 한다. 그렇지 않으면 배포로 인해 프로덕션에서 성능 문제, 불안정한 시스템, 보안 틈새 및 ...

CI/CD 지속적배포 지속적제공 2022.06.23

깃랩, 단일 데브옵스 플랫폼 ‘깃랩 15.0 버전’ 출시

깃랩은 새로운 데브옵스 기능을 단일 플랫폼으로 제공하는 차세대 깃랩 15의 첫 번째 릴리스인 15.0 버전을 출시했다고 밝혔다. 깃랩 15는 포괄적인 데브옵스 기능을 통해 기업들이 소프트웨어를 안전하게 제공하고, 원하는 비즈니스 성과를 달성할 수 있도록 비즈니스-크리티컬 코드의 개발 및 협업을 지원한다.    새로운 릴리스는 가시성과 관측(Observability), 지속적인 보안 및 컴플라이언스, 엔터프라이즈 애자일 플래닝, 워크플로우 자동화 및 데이터 과학 작업부하 지원 등을 비롯한 솔루션 영역의 플랫폼 기능이 향상되었다고 업체 측은 설명했다. 깃랩의 제품 담당 부사장인 데이비드 디산토는 “기업들은 DIY(Do-It-Yourself) 툴체인을 제거하고, 기획에서 운영에 이르기까지 단일 애플리케이션으로 팀을 하나로 통합해 코드를 더 안전하고 빠르게 제공하고, 비즈니스 성과를 달성하는 것은 물론, 팀의 업무환경과 협업을 개선할 수 있다”고 밝혔다. 팀은 애플리케이션 및 워크플로우 방식에 대한 가시성을 확보함으로써 보다 신속하게 작업을 수행할 수 있다. 깃랩 15는 가시성을 확장하고, 기업들이 가치 제공 및 애플리케이션 상태를 파악할 수 있는 새로운 기능을 제공한다. 이러한 기능은 조직의 사일로 문제를 제거하고, 공유 및 협업을 강화할 수 있도록 해준다.  깃랩의 포괄적인 관측 및 모니터링 툴은 기업들의 사고 발생률을 낮추고, 최근 성능 저하에 대한 실행 가능한 통찰력을 제공함으로써 사고 발생 시 실시간으로 우선순위에 따라 이를 분류할 수 있도록 지원한다. 이러한 새로운 기능은 코드에서 운영환경까지 리드 타임을 단축하고, 오류 빈도 및 심각성을 줄이는 것은 물론, 개발 팀이 배포 주기를 단축하고, 사고 발생 후 복구 시간을 줄이는데 도움을 줄 수 있다.  깃랩은 최신 릴리스를 통해 전체 소프트웨어 개발 주기에 걸쳐 컴플라이언스를 강화할 수 있는 기능과 통합 보안 스캐닝 및 컴플라이언스 감사 기능을 제공함으로써 개발 ...

깃랩 데브옵스 오픈소스 2022.06.16

"클라우드의 가치를 100% 실현한다" 클라우드옵스 안내서

소프트웨어 제품의 개발에 관여한 적 있다면 ‘데브옵스’라는 말에 익숙할 것이다. 소프트웨어 개발과 IT 운영을 결합한 일련의 관행인 데브옵스는, 개발 수명 주기를 단축하고 지속 배포 및 고품질 제품을 공급하는 것을 목표로 한다. 클라우드 운영과 연관된 개념인 ‘클라우드옵스(CloudOps)’는 기업들이 애플리케이션 개발과 워크로드를 클라우드로 점점 더 이전하면서, 그리고 클라우드 비용이 한층 복잡해지면서 출현했다. 클라우드옵스가 무엇이고, 조직에게 어떤 혜택을 줄 수 있는지, 그리고 기업 내에서 클라우드옵스를 구현할 때 유념해야 할 점은 무엇인지 살펴본다.   클라우드옵스란?  클라우드옵스는 클라우드 환경에서 실행되는 IT 서비스와 워크로드의 전달, 최적화 및 성능을 관리하는 운영 프랙티스이다.  기업이 멀티클라우드, 하이브리드 클라우드, 또는 프라이빗 클라우드 전략을 운영함에 있어 클라우드옵스는 클라우드 기반 프로세스를 위한 절차 및 베스트 프랙티스를 확립하기 위해 구현된다. 이는 데브옵스에 의한 애플리케이션의 개발 및 배포와 비슷한 성격을 가진다. 클라우드 운영을 위한 다계층 프레임워크  컨설팅 기업 캡제미니 아메리카스(Capgemini Americas)의 부사장이자 클라우드 우수성 센터의 책임자인 제이슨 해치는 “기업이 자사 클라우드 생태계의 여러 측면을 전반적으로 관리하는 데 도움을 주는 여러 계층으로 된 프레임워크가 클라우드옵스(Holistic CloudOp)의 큰 그림이다”라고 설명했다. 프레임워크 계층 중 하나는 거버넌스 계층이다. 여기에는 클라우드 비용을 제어하고 예산을 관리하는, 핀옵스(FinOps)라고도 알려진 재무 업무 등의 활동을 포함한다. 해치는 “거버넌스 계층에는 무엇이 어떻게 클라우드에 배치될 수 있는지에 관한 아키텍처 표준이 담겨 있어야 한다. 또 이들 표준을 프로그램적으로 강제하는 방법을 있어야 한다”라고 말했다.   다른 프레임워크 계층으로는 클라우드에서...

클라우드옵스 데브옵스 클라우드 최적화 2022.05.27

'호환성과 일관성 모두 잡는다' 델 테크놀로지스 통합 클라우드 플랫폼의 가치 제안

“꾸준히 사업을 진행해온 기업이라면, 앱 환경이 마치 거미줄처럼 복잡할 가능성이 큽니다. 앱 환경에 사용된 코드만 해도 몇백만 줄에 이를 겁니다.”     2020 IDC 조사에 따르면 2023년까지 5억 개의 신규 앱이 클라우드 네이티브 기술로 개발될 전망이다. 또한 2020 가트너 조사에 따르면 독립 소프트웨어 벤더 중 80%가 컨테이너 기반으로 솔루션을 제공할 예정이라고 밝혔다. 그러나 많은 기업이 여전히 꼬인 앱 환경 때문에 클라우드 이전에 어려움을 겪고 있다고 델 테크놀로지스의 박성덕 상무는 한국 IDG과 주최한 클라우드 및 엣지컴퓨팅 2022에서 진단했다. 오늘날 기업의 앱 환경과 함께 델 테크놀로지스가 제안하는 현실적인 클라우드 이전 방법에 대해 살펴본다. 혼재된 앱 환경 박성덕 상무에 따르면 현대 기업의 앱 환경에는 레거시 기술과 최신 기술이 혼재할 가능성이 크다. 한편에는 상용 소프트웨어부터 닷넷 혹은 자바 프레임워크 같은 개발 도구로 개발된 레거시 앱이 존재한다. 레거시 앱 환경은 익숙하지만 유지보수가 어렵고 확장하는 데 명확한 한계가 있다.  다른 한편에는 최근 받아들이기 시작한 마이크로 서비스, 컨테이너 등과 같은 신기술을 채택한 클라우드 네이티브 앱이 있다. 클라우드 네이티브의 강점은 명확하다. 우선 개발 방식과 개발 아키텍처가 크게 개선된다. 기존의 워터폴-IT 개발 방식은 개발 기간이 길고 문제 발생 시 변경이 힘들다. 반면 클라우드 네이티브 환경에서 쓰이는 데브옵스 및 애자일 개발 방식은 피드백이 빠르고 전 개발 과정에 IT 운영팀이 참여할 수 있어 협업이 용이하다.  박성덕 상무는 “기존 개발 방식에서 채택하는 모놀리식 아키텍처도 가상화 기술로 조금 개선되기는 했다. 그러나 여전히 피드백 과정이 느리다. 클라우드 네이티브 앱 방식에서는 마이크로 아키텍처라는 작은 구성단위로 컨테이너가 묶여서 배포된다. 따라서 필요한 개별 구성 요소만 수정할 수 있어 개선 주기가 빠르다”라고 설명했다. ...

클라우드 멀티클라우드 데브옵스 2022.05.26

블로그 | 당신의 클라우드옵스 계획은 너무 늦었다

필자는 종종 워터폴 소프트웨어 개발 라이프 사이클 시대를 떠올린다. 당시엔 각 작업이 개별적으로 시작해 종료됐다. 한 작업이 끝난 결과물이 다른 문서화나 코드의 시작점이었다. 시간이 오래 걸리는 개발 방식이었고 방향을 바꾸기가 사실상 불가능했지만, 관련된 다른 계획을 세우기에는 훨씬 수월했다.   하지만 그런 시절은 끝났다. 오늘날 클라우드 개발 혹은 동시 개발 방식에서는 반복적이고 민첩하게 작업이 진행되고 언제든 방향을 바꿀 수 있다. 매우 강력한 데브옵스 툴 체인을 통해 자동화되면서 유동적인 개발 방식이 만들어졌다. 이런 변화는 올바른 방향이라고 생각한다. 하지만 동시에 일부 악화한 부분이 있다. 운영 계획이 대표적이다. 개발이 끝날 때까지 마치지 못하는 경우가 비일비재하고 아예 시작하지 못하기도 한다. 개발자는 코드와 데이터 구조를 운영팀에 넘기고 운영팀은 이를 장기적으로 잘 운영할 방법을 빠르게 찾아야 한다. 그런데 현실적으로 많은 운영 혹은 클라우드옵스 담당자가 현재 공석이다. 이 자리가 점점 기피 IT 업종이 되고 있기 때문이다. 그러나 운영 계획은 반드시 개발 과정의 초기, 최소한 설계 단계에서 시작돼야 한다(보안과 거버넌스 계획 역시 이 단계에서 함께 고민해야 하지만 여기서는 이 부분은 논외로 한다). 운영 계획을 개발 초기에 세워야 건강한 운영 관행이 시스템에 녹아들어 갈 수 있다. 새로 만든 시스템이든 클라우드로 이전한 시스템이든 마찬가지다. 이렇게 해야 프로세스와 스토리지 시스템이 장애나 성능, 사용성 등 일반적인 운영 문제를 겪을 수 있는 가능성을 줄일 수 있다. 운영 계획이 부실하거나 아예 없으면 문제에 직면할 가능성이 커지는 정도가 아니다. 개발팀에 다시 코드와 데이터 구조를 돌려보내기 전에 상당히 많은 문제에 고통받는다. 필자가 개발자와 애플리케이션 디자이너, 아키텍트 등에게 코드를 작성하거나 전환하기 전에 운영 계획을 먼저 마련하라고 하면 그들은 마치 필자가 에베레스트산을 오르라고 한 것 같은 표정으로 쳐다본다....

클라우드옵스 데브옵스 ops 2022.05.18

“여기 백엔드 개발자가 있다” 백엔드 개발자 경험을 위한 솔루션 열전

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

개발자경험 백엔드 오픈소스 2022.05.10

“운영 관리가 AI/ML의 성패를 결정한다” 머신러닝을 위한 MLOps 전략과 HPE Ezmeral MLOps - Tech Summary

AI/ML 프로젝트 중 프로덕션까지 살아남는 비중은 매우 낮다. 적절한 데이터 부족, 컴퓨팅 자원 부족 등 여러 이유가 있지만, 본질적인 이유는 AI/ML 모델 구현, 훈련, 배포, 모니터링 등 전체 생명주기를 아우르는 관리 체계 부재에서 찾을 수 있다.  HPE Ezmeral MLOps를 예로 AI/ML 프로젝트의 성공 비율을 높이는 MLOps 전략에 대해 알아보자.  주요 내용 - AI/ML 프로젝트의 성공률을 높여라 - 누구나 쉽게 활용할 수 있는 MLOps 솔루션 - 민첩성 보장하는 MLOps와 데브옵스의 통합 - HPE Ezmeral MLOps 활용 사례 - 다양한 배포 옵션으로 인프라와 MLOps 통합 - 디지털 트랜스포메이션을 가속화하는 AI의 역할 변화

MLOps Ezmeral 데브옵스 2022.05.09

“CI/CD란?” 알기 쉽게 설명한 지속적 통합과 지속적 제공

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

CI/CD 지속적통합 지속적제공 2022.04.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.