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.

마이크로서비스

'마이크로서비스'에 최적화된 C++용 비동기 프레임워크 '유저버' 베타 버전 출시

효율적인 I/O 인터랙션를 구현하고 싶은 C++ 개발자가 있다면 오픈소스 프레임워크 ‘유저버(userver)’를 이용해보자. 비동기식 마이크로서비스를 쉽고 빠르게 구축할 수 있을 것이다.    유저버는 비동기 프레임워크로 C++ 기반 마이크로서비스, 서비스, 유틸리티를 빠르고 쉽게 만들 수 있도록 여러 추상화 기술을 제공한다.  아직 베타 상태이긴 하지만 현재 유저버 개발팀은 효율적인 I/O 인터랙션에 초점을 맞춰 유저버 기술을 발전시키고 있다. 또한 C++의 빠른 속도는 가져가면서 파이썬의 단순함과 고 언어의 코루틴(Coroutine) 특징을 유저버에 접목하고 있다.  유저버를 사용하면 실행 스레드가 일시 중단되는 경우가 거의 없어진다. 대신 스레드는 다른 작업을 처리하고 즉시 실행이 보장될 때만 작업 처리로 돌아간다. 개발자는 간단한 소스 코드를 얻고 OS에서 CPU를 많이 소비하는 상황을 피하면서 적은 수의 실행 스레드를 통해 CPU를 효율적으로 활용할 수 있다. 그 외 유저버에서 눈에 띄는 기능은 다음과 같다.    캐시, JSON/YAML/BSON, 분산 잠금, 메트릭, 통계, 작업에 관한 고급 구성요소 집합  즉각적인 서비스 구성 변경을 수행하는 기능  포괄적인 비동기와 저수준 동기화 기본 요소 및 OS 추상화 집합  몽고DB, 포스트그레, 레디스 및 기타 데이터베이스용 비동기 드라이버 HTTP, GRPC 및 TCP를 포함한 데이터 전송 프로토콜 그리고 구성 및 취소를 포함한 작업용 비동기 드라이버 유저버 개발팀은 베타 버전 기술을 공개하면서 "인턴이나 학생들도 유저버로 일주일 만에 새 마이크로서비스를 작성하고 프로덕션에 배포할 수 있었다"라며 유저버 개발 프로세스의 단순성을 강조했다. 유저버 문서는 공식 홈페이지에서 확인할 수 있다. 유저버 라이선스는 아파치 2.0이 적용됐다. ciokr@idg.co.kr

C++ 비동기 프레임워크 유저버 2022.08.04

블로그 | 앱 현대화, 필수 점검 목록을 의심하자

애플리케이션 현대화를 정의해 달라고 하면, 사람마다 대답이 다르다. 하지만 모두가 동의하는 내용을 일반화해 보면, “애플리케이션 현대화는 비즈니스를 운영하는 기존 애플리케이션과 데이터 세트를 가져다 더 유용하고 생산적이고, 사용자, 특히 고객에게 더 매력적으로 만드는 것”을 말한다. 고객 경험을 개선하는 역량은 비즈니스를 촉진한다.   일부는 애플리케이션 현대화를 “호박에 줄 긋기”로 보기도 하지만, 그런 목적은 아니다. 애플리케이션 현대화는 현대적으로 보이도록 만드는 것이면 안 된다. 애플리케이션이 실제로 현대적인 것이 되어야 한다. 애플리케이션 현대화는 내부 아키텍처와 퍼블릭 클라우드 플랫폼 인프라, 애플리케이션 기능, 구현 기술의 현대화는 물론, 사용자와 기계 간의 인터페이스의 변화를 의미한다. 또한 전통적인 폭포수 방식 개발 과정을 애자일 및 데브옵스로 바꾸는 것도 필요하다. 귀중한 레거시 애플리케이션을 개선해 퍼블릭 클라우드로 이전한다는 것은 좋은 생각이지 않은가? 물론이다. 하지만 개발자와 클라우드 아키텍트가 끝없는 점검 목록으로 현대화에 접근하는 경우가 많다. 때로 이 점검 목록이 너무 지나쳐 비즈니스 가치라는 현대화 프로젝트의 목표와 목적을 놓치고 만다. 프로세스부터 방법론까지 애플리케이션 현대화에 대한 정보는 차고 넘친다. 그리고 많은 개발팀이 레거시 애플리케이션을 정말로 현대적으로 만들어 준다는 점검 목록을 하나하나 표시하는 것으로 현대화를 시도한다. 컨테이너화, 마이크로서비스, 데이터 증강, 내부 아키텍처 증강 등등 유행하는 개념을 추구하는데, 이런 개념은 종종 대규모 수술을 필요로 한다. 그리고 그저 체크박스에 표시하기 위해 수많은 복잡성을 감당하고 그에 따른 비용을 들이다 보면, 애플리케이션 자체를 위험에 빠뜨릴 수도 있다. 두 가지 실용적인 문제를 생각해 보기 바란다. 첫째, 원조 레거시 애플리케이션을 버리고 새로 시작하는 것이 더 말이 되는 티핑 포인트가 있다. 필자는 항상 고쳐 쓰는 것을 선호한다. 하지만 새로...

마이그레이션 현대화 마이크로서비스 2022.06.27

블로그 | 변경할 수 있는 클라우드 솔루션을 구축하는 방법

필자가 일찌감치 배웠던 것 중 하나는 변경하기 쉬운 시스템을 설계하는 것이다. 그 방법은 클라우드이든 아니든, 시스템의 구성 요소를 구획화하는 것이다. 그래야 각 구성 요소를 그 자체로 구성하거나 변경할 수 있다. 단순한 비유를 들자면, 자동차의 부품을 교체할 수 있기 때문에 자동차 전체를 재개발하지 않고도 각 부품을 교체하거나 업데이트할 수 있다는 것을 생각하면 된다.   다른 접근법은 서비스와 마이크로서비스를 이용해 일부 애플리케이션의 동작과 데이터를 중앙화하고 재사용하는 것이다. 이 방식은 한 곳에서 특정 서비스를 업데이트하면, 해당 서비스를 사용하는 모든 시스템의 동작이 바뀌는 방식이다. 예를 들어, 세금 계산 방식을 교체하거나 데이터베이스 모델을 변경하거나, 심지어 특정 구성 요소의 기반 기술을 업데이트하는 식이다. 이를 통해 지연이나 추가 비용, 위험성 없이 비즈니스의 필요에 맞춰 시스템을 쉽게 변경할 수 있는 역량을 확보할 수 있다. 이 접근법의 문제는 복잡하고 실행하기 어렵다는 것이 아니다. 이 새로운 시스템을 클라우드에서 설계하고 구축하는 책임을 맡은 사람의 많은 수가 전반적인 설계에서 시스템을 쉽게 변경할 수 있는 역량에 우선순위에 두지 않는 것이다. 이유는 이해한다. 예산은 빠듯하고 시간은 짧다. 여러 장애물이 길을 막을 때는 좋은 시스템 설계의 베스트 프랙티스가 뒷자리로 밀려나기 쉽다. 유연한 시스템을 설계하는 데 들이는 노력과 돈이 나중에 기업에 100배의 이익으로 돌아온다는 예를 제시하기는 쉽지만, 당장의 압박이 클 때는 강하게 주장하기 어렵다. 그럼에도 어떤 비즈니스의 요구라도 해결할 수 있도록 동적이고 변경 가능한 시스템을 설계하는 것이 베스트 프랙티스임은 확실하다. 이 문제를 어떻게 풀어야 할까? 이 문제는 기술의 문제이자 사람과 문화의 문제다. 실제로 시스템이 베스트 프랙티스를 사용해 설계된다는 기대치를 세우는 문제다. 게다가 기업은 설계자와 개발자가 쉽게 변경할 수 있는 클라우드 기반 시스템을 설계하고 구축할...

아키텍트 구획화 업데이트 2022.05.16

구글, 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

API, 통합, 마이크로서비스를 통해 혁신을 이끌어내는 방법

소비자 기대 수준이 급격히 변화하여 더 밀접하게 연결된 디지털 세계를 최소한의 기본 전제로 요구하고 있습니다. 디지털로의 전환은 단순한 성장 전략이 아니라 생존 전략입니다. 그리고 생존을 위해서는 혁신을 실현할 방법을 찾아야만 합니다.  혁신을 이끄는 데 있어 핵심은 꼭 맞는 툴과 아키텍처를 활용한 비즈니스의 디지털 전환입니다. 기존 시스템의 전면적인 개보수 및 재구축 작업없이도 연결성과 민첩성을 높일 수 있어야 합니다. 직원을 재교육하거나 새로 채용할 필요도 없어야 합니다. 이와 같은 전환은 기업이 완벽히 통합되고 연결되어야 가능합니다. 그리고 그 연결은 API, 통합, 마이크로서비스를 바탕으로 성립됩니다. 이 가이드에서는 혁신을 이끌어내고 기업의 IT 기능을 현대화하기 위해 필요한 것은 무엇인지 짚어 보겠습니다. 이 모든 요소를 충족하는 최신화된 플랫폼을 찾고 계신다면, 발빠르게 움직이는 글로벌 기업들이 이미 활용하고 있는 Software AG의 webMethods를 추천합니다. 주요 내용 - API를 체계적으로 관리하세요 - 마이크로서비스가 미래입니다 - 통합솔루션과 함께 진정한 IoT 서비스를 시작하세요 - DevOps not DevOops! - 커넥터를 활용해 연결성을 향상하세요

API 마이크로서비스 통합 2022.03.29

2021년 연간 API & 통합 보고서 - API, 통합, 마이크로서비스 관련 통계

2021년 연간 API & 통합 보고서는 950명의 IT 분야 의사결정권자를 대상으로 한 설문조사 결과를 분석한 것입니다. 해당 보고서에 따르면, 약 99%의 기업들이 이미 통합 시스템을 사용하고 있으며, 그 중 온프레미스와 클라우드를 아우르는 하이브리드 통합 시스템을 사용하는 경우가 가장 많은 것으로 나타났습니다. 이처럼, 통합에 대한 수요는 끊임없이 증가하고 있으며 기업은 더욱 고도화된 솔루션 채택을 위해 박차를 가하고 있습니다. API, 통합 및 마이크로서비스 시스템을 각각 별개의 기술적 도구로 인식하는 관점은 더 이상 유효하지 않으며, 기업의 미래는 세가지 니즈를 한 번에 충족하는 번들 솔루션에 있습니다.   이 보고서를 통해 API, 통합 및 마이크로서비스에 관한 기업들의 인식과 도입 현황을 파악할 수 있으며, 해당 기술 도입에 따라 기업들이 얻은 이점과 이와 반대로 그들이 주로 겪고 있는 도전과제 등을 확인하실 수 있습니다. <33p> 주요 내용 - IT 선도 기업은 API 도입을 기업 운영의 핵심으로 인식 - 통합 시스템 : 하이브리드가 미래 - 어느새 주류로 자리잡은 마이크로서비스 - 번들 솔루션 : 더 빠른 혁신을 위한 기회

API 마이크로서비스 통합 2022.03.29

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

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

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

IDG 블로그 | “과유불급” 서비스 중심 클라우드 개발의 함정

서비스 지향 개발은 사람들이 알고 있는 것보다 오래된 주제다. 물론 마이크로서비스 같은 것은 비교적 최신 트렌드이지만, 개발자들은 오랫동안 애플리케이션과 오케스트레이션을 구축하는 데 여러 서비스를 사용해 왔다. 직접 개발하지 않은 기존 서비스는 물론 직접 개발한 새로운 서비스도 사용했다. 이런 서비스를 마이크로서비스라고 부르든, 아니면 세밀화된 서비스나 유틸리티 서비스, 공통 애플리케이션 API라고 부르든 상관없다. 서비스를 이용한다는 것은 보통 서비스 지향 아키텍처를 사용한다는 의미이다. 즉, 새로운 컴포넌트 또는 기존 컴포넌트를 이용해 애플리케이션을 구축하는 데만 집중한다는 것이다.   기술적으로는 단일 애플리케이션 내에서 사용할 수 있는 서비스 수와 해당 서비스의 역할을 제한하는 경우가 많다. 과거에는 자잘한 서비스를 너무 많이 사용하는 것이 성능 문제를 일으키기도 했기 때문이다. 자잘한 서비스란 예를 들어, 데이터베이스를 특정 데이터 종류로 업데이트하는 것만 수행하는 별도의 서비스와 같은 것이고, 이런 서비스를 같은 애플리케이션 내에서 너무 자주 사용하는 것이 문제의 소지가 되는 것이다. 요즘에는 저렴한 컴퓨팅과 네트워킹, 스토리지로 이런 문제를 떠넘기기 때문에 성능 문제를 숨길 수 있다. 비효율성은 여전하지만, 성능 문제를 지워버릴 수 있는 첨단 애플리케이션 처리 성능으로 추상화되어 버린다. 따라서 할 수만 있다면, 서비스를 사용하는 것은 이제 아무런 문제가 되지 않는다. 그보다는 얼마나 많은 서비스를 사용할 것인지, 처음부터 서비스를 사용해야만 하는지가 문제가 된다. 필자가 흔히 보는 서비스 과용은 주로 마이크로서비스와 관련된 것으로, 애플리케이션이 너무 복잡해질 정도이다. 이렇게 너무 많은 서비스를 사용하면, 핵심 개발자의 원래 의도가 무엇인지를 해독할 수 없게 된다. 마찬가지로 흔한 일은 애플리케이션의 단 한 가지 측면이 서비스로 탈출하는 것이다. 해당 서비스는 처리 과정 동안 단 한 번 사용되고 다른 애플리케이션도 사용하지 않...

마이크로서비스 복잡성 SOA 2022.02.09

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

쿠버네티스 컨테이너 오케스트레이션 시스템은 개발자 사이에서 전기를 맞았다. 그러나 클라우드 네이티브 컴퓨팅 재단(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

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너 2021.11.16

"마이크로서비스 기반의 앱을 위한 데브섹옵스 구현" NIST 새 가이드

미국 연방정부도 민간 기업과 마찬가지로 클라우드, 데브섹옵스(Devsecops), 그리고 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 기반 아키텍처로 전환하는 중이다. 미국표준기술연구원(NIST)은 업계가 모범사례를 채택할 수 있도록 표준과 가이드를 제공한다.    이를 위해 NIST는 지난 9월 서비스 메시(Service Mesh)를 사용한 마이크로서비스 기반 애플리케이션을 위한 데브섹옵스 구현을 발표했다(800-204C). 이 문서는 데브섹옵스 구현, 그리고 마이크로서비스 아키텍처에 클라우드 네이티브 애플리케이션을 호스팅하기 위한 서비스 메시를 사용한 참조 플랫폼 사용에 관한 포괄적인 가이드다. 이는 현재 초안 형식이며, 전 미공군 최고 소프트웨어 책임자인 니콜라스 챌라인과 서비스 메시 분야 선두업체인 테트레이트(Tetrate)의 협업으로 작성됐다. 이 가이드는 성공적인 데브섹옵스 구현을 위한 구성 요소라고 할 수 있는 프리미티브(primitive) 개념을 사용했다. 데브섹옵스 프리미티브는 민첩한 개발을 위한 마이크로서비스 기반 애플리케이션에 가장 적합하다. 또한 데브섹옵스가 클라우드 네이티브 애플리케이션에 필요한 비즈니스 민첩성 요구사항을 촉진한다는 개념도 지원한다. 다음은 NIST 가이드의 각 세션의 내용을 분석했다.   데브섹옵스 프리미티브 구현을 위한 참조 플랫폼 이 가이드는 컨테이너 오케스트레이션과 관리 플랫폼 맥락에서 참조 플랫폼을 다룬다. 예를 들어 분류된 또는 연결이 끊긴 엄격한 환경(물리적) 또는 AWS, 애저와 같은 클라우드 서비스 제공업체(CSP) 환경과 같은 가상화된 환경 등 물리적 또는 가상 기반 인프라 위에 구축하는 방식이다. 가이드는 컨테이너 오케스트레이션 및 리소스 관리 플랫폼 사용을 권장한다. 가장 인기 있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 대표적이다. 쿠버네티스는 컨테이너화된 애플리케이션을 호스팅하는 팟(pod)을 기반으로 물리적 ...

데브섹옵스 NIST Devsecops 2021.10.29

클라우드 네이티브 앱과 마이크로서비스가 개발 프로세스에 미치는 영향

필자는 객체 지향 프로그래밍, 3계층 웹 플랫폼, 서비스 지향 아키텍처(SOA), 그리고 데이터센터에 가상 서버를 호스팅하던 시절에 실무 개발자와 최고 기술 책임자로 종사했다.   그 시절 이후 너무 많은 것이 변했다.   앞서가는 소프트웨어 개발 부서는 마이크로서비스를 개발하고 클라이언트 측 자바스크립트를 사용해서 풍부한 프런트 엔드 사용자 경험을 실현한다. 호스팅 옵션은 대폭 증가해서 이제 서비스형 플랫폼(PaaS), 서비스형 컨테이너(CaaS), 서버리스 함수를 비롯한 다양한 아키텍처를 포함한다. 개발자들이 만드는 애플리케이션은 실시간 데이터 스트림을 활용하고 머신러닝 모델과 연결되고 SaaS 및 엔터프라이즈 시스템과 접속한다.     개발 툴도 많이 발전했다. 툴은 전 세계 곳곳에 분산된 개발 부서가 독립적으로 작업하고 빈번하게 변경 사항을 릴리스하고 신속하게 문제에 대응할 수 있게 해준다. 지속적 통합과 지속적 배포(CI/CD), 지속적 테스트, 코드형 인프라(IaC), AI옵스(AIops)를 통해 통합, 배포, 인프라 구성, 모니터링을 자동화할 수 있다.   이 변화에는 애자일의 지속적 계획 도입, 시프트-레프트 테스트 구현, 보안 위험에 대한 선제적 대처, 사이트 안정성 엔지니어링 등 문화적, 실무적 변화도 포함된다.   한층 더 깊게 들어가서 클라우드 네이티브 애플리케이션과 마이크로서비스를 구축하고 배포할 때 개발 프로세스를 어떻게 변경해야 하는지에 관한 최선의 방법을 알아보기 위해 여러 전문가들의 의견을 구했다.   빠른 속도에 필요한 것은 조율과 운영 인식 다수의 작고 원자적인, 또는 자주 배포되는 마이크로서비스 구축을 목표로 하는 개발 부서에 대한 필자의 첫 번째 우려는 이들의 배포 속도가 협업과 안전 가드레일을 감안하지 않는 경우다.   빅판다(BigPanda) CTO 제이슨 워커에게 마이크로서비스를 성공적으로 구축, 배포, 강화하는 개발 부서에 관한 경험을 들어봤다...

클라우드네이티브애플리케이션 마이크로서비스 서비스지향 2021.10.06

“IT 혁신의 목적지, 비즈니스 혁신의 출발점” 애플리케이션 현대화의 4대 요소와 실행 전략 - IDG Tech Dossier

비즈니스 혁신을 뒷받침해야 하는 기업의 IT 환경은 개발부터 인프라, 심지어 조직 문화까지 전방위적인 변화가 일어나고 있다. 변화의 핵심은 애플리케이션 개발을 더욱 신속하게 진행하고 업데이트 빈도를 늘리는 동시에 품질을 높이고 비즈니스 요구에 더욱 민첩하게 대응하는 것, 즉 애플리케이션 현대화이다. 애플리케이션 현대화의 4가지 핵심 요소인 컨테이너와 컨테이너 오케스트레이션, 클라우드 네이티브와 마이크로 서비스 아키텍처, 데브옵스과 CI/CD, 서버리스 컴퓨팅의 개념과 기본 구성 및 방법론을 살펴보고, 레드햇이 제안하는 구축 방안과 핵심 솔루션을 소개한다. 주요 내용 - 애플리케이션 현대화 기반 다지기 - 클라우드만큼의 민첩성과 효율성 구현하기 - 개발과 운영의 융합으로 지연없는 앱 개발 - 극한의 자원 최적화 구현하기 - 준비된 애플리케이션 현대화 솔루션 레드햇 오픈시프트

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

글로벌 칼럼 | 마이그레이션을 도중에 멈추면 안 되는 이유

애플리케이션 마이그레이션을 계획 중인가? 아마 온프레미스 애플리케이션을 클라우드로 이전하거나 모놀리식 애플리케이션을 서비스 지향 아키텍처나 마이크로서비스 아키텍처로 옮길 생각일 것이다.   이런 마이그레이션은 전력을 다해야 하는 일이다. 시간과 자원은 물론, 마음가짐과 기업의 역량을 모두 투여해야 한다.    하지만 마이그레이션은 완료하기가 쉽지 않다. 마이그레이션은 장기간의 점진적인 변화이고, 통상적으로 소비된 노력이 실현된 혜택과 바로 일치하지는 않는다. 혜택은 투자가 이루어지고 난 시점보다 훨씬 이후에 찾아온다. 때에 따라 좋아지기 전에 난관에 부딪히기도 한다.   그래서 마이그레이션을 도중에 종료하려는 유혹을 뿌리치기는 쉽지 않다.   도대체 마이그레이션을 도중에 종료하고 싶은 사람이 있기는 할까? 말도 안 되는 것처럼 보이지만 실제로 일어난다. 모놀리식 애플리케이션으로부터 서비스 지향 아키텍처로 이동한다고 하자. 마이그레이션을 시작한 지 얼마 되지 않아 중단한다면 애플리케이션은 마이그레이션 이전보다 훨씬 좋지 않은 상태로 남는다.   그렇다면 마이그레이션을 도중에 중단하려는 유혹을 어떻게 뿌리칠 것인가? 기대를 관리하는 것, 그리고 진정한 ROI를 이해하는 것이 핵심이다.     고통의 계곡   중대한 마이그레이션을 시작할 때, 특히 모놀리식 애플리케이션에서 마이크로서비스로 마이그레이션하는 등의 복잡한 마이그레이션을 시작한다면, 궁극적으로 얻게 될 혜택에 대한 일정한 기대가 있기 마련이다. 보통은 혜택이 투입된 시간과 노력에 상응할 것이라고 기대한다. ROI가 마이그레이션 노력을 정당화시킬 것이라고 생각한다.   그러나 이는 마이그레이션의 가치와 혜택을 판단하는 1차원적 시각이다. 단순 ROI 계산은 마이그레이션에 투여된 시간과 노력이 어떻게 혜택으로 변환되는지에 관한 이해를 충분히 포착하지 못한다. 일반적으로 <그림 1>에서 보듯이 혜택과...

마이그레이션 현대화 마이크로서비스 2021.09.02

IDG 블로그 | 클라우드 네이티브의 코드 재사용이 철칙은 아니다.

코드 재사용은 필자가 초급 코볼 프로그래머였던 1980년대 이후로 개발자에게는 전쟁터의 함성 같은 것이었다. 우리는 여러 번 호출할 수 있는 함수를 정의했고, 구조적 프로그래밍의 시대가 시작됐다.   그때 이후 우리는 C나 객체 지향 C++ 같은 언어를 편력하며 재사용이 좋다는 관념을 확실히 했다. 그 다음은 분산 객체와 SOA(Service Oriented Architecture) 서비스로 흘러가면서 재사용은 하나의 애플리케이션 단위를 벗어나 성장했고, 느슨하게 연결되고 서로 다른 플랫폼에 있는 재사용할 수 있는 서비스로 발전했다. 지금은 클라우드 서비스나 API라는 개념, 그리고 새로운 차원의 세밀한 공유를 제공하는 마이크로서비스란 매력적인 개념도 있다. 재사용 또는 공유라는 개념은 클라우드와 비 클라우드 개발자 모두에게 새로운 의미를 갖는다. 2022년 현재 많은 개발자 DRY(Don’t Repeat Yourself)란 약어를 애플리케이션과 시스템을 구축하고 배치하는 새로운 슬로건으로 삼고 있다. 하지만 DRY는 말처럼 쉽지 않다.  필자는 오랫동안 서비스 기반 애플리케이션을 구축하면서 두 가지 서로 다른 실수를 저질렀다. 너무 많이 재사용하는 실수와 충분히 재사용하지 않는 실수이다. 과도한 재사용이란 같은 서비스를 반복적으로 사용함으로써 생산성이 감소하거나 심한 경우 생산성을 해칠 경우를 말한다. 애플리케이션의 요구를 만족하기 위해서는 추상화하고 일부 기능을 변경해야 하는 서비스를 재사용이란 개념을 고집해 그대로 이용한다면, 이런 결과를 낳을 수 있다. 예를 들어, 모든 고객의 정보가 있는 고객 신용 데이터에 액세스하는 서비스를 사용하지만, 해당 애플리케이션의 용도에서는 응답이나 데이터 스트림에서는 공통 데이터가 필요 없어 삭제해야 하는 경우가 있다. 이런 경우에도 억지로 재사용하는 경우가 많다. 애플리케이션 개발은 재사용되는 서비스의 혼합물이 되고 있으며, 반드시 재사용해야 하거나 그렇지 않거나 가리지 않는다. 게다가 이런...

클라이드네이티브 마이크로서비스 재사용 2021.07.21

'레거시와 클라우드의 연결' 꾀하는 모던 APM의 중요성

엔터프라이즈 애플리케이션 개발, 운영, 배포 방식은 세대를 거듭하면서 더 효율적이고 빠른 방향으로 발전하고 있다. 최근 추이는 서버리스(serverless) 환경에서의 데브옵스(DevOps) 파이프라인 운영을 목표로 삼는 것이다. 이와 관련해 레거시 시스템을 컨테이너 기반 환경으로 옮겨 애플리케이션 현대화의 첫 삽을 뜨고, 이후 신규 개발 시스템을 마이크로서비스 아키텍처 환경에서 클라우드 네이티브 방식으로 개발하고 운영하는 로드맵을 따르는 곳이 많다. 이런 흐름 속에서 APM(Application Performance Management)은 어떤 역할을 하면서 가치를 인정받고 있을까?   복잡성 높을 수록 모니터링 중요성도 커져  APM의 등장 배경을 보면 예나 지금이나 도전 과제가 비슷하다. 쓰리 티어(3 Tier) 구조의 웹 기반 컴퓨팅이 자리를 잡았을 때를 떠올려 보자. 눈에 보이던 것들이 보이지 않게 되면서 복잡성이 커졌다. 계층화된 컴퓨팅 환경에서 일관성 있게 성능을 보장하려면 가시성을 확보해야 한다. 이를 해결하기 위해 등장한 것이 APM이었다. 지금은 어떠한가? 모놀리식 구조의 스택이 마이크로서비스 아키텍처 환경으로 바뀌면서 기능은 더 작은 단위로 쪼개졌고, 인프라와 플랫폼의 추상화 수준은 더욱 높아졌다. 마이크로서비스 환경 구축 시 현장에서 복잡성과 가시성 문제를 호소하는 이유다. 이 문제 역시 해결책은 APM에서 찾을 수 있다.    동적 환경 모니터링까지 소화하는 APM  LG CNS의 APM 솔루션인 TunA와 같은 현대화된 APM은 마이크로서비스 아키텍처 환경에 대한 모니터링까지 기술적, 기능적으로 고려한다. 컨테이너 플랫폼에 배포, 운영하는 애플리케이션은 동적인 특성을 띤다. 안정화를 거친 후 큰 변화 없이 운영하는 모놀리식 구조의 애플리케이션과는 아주 다르다. 생성과 소멸을 빠른 주기로 반복하며, 필요에 따라 자유롭게 사내와 사외 컨테이너 환경 사이를 이동하기도 한다. 쉽게 말해 애플리케이...

LG CNS APM 마이크로서비스 2021.07.08

“하이브리드 클라우드 구축의 새로운 길을 연다” 구글 안토스 기반 마이그레이션 전략과 국내 사례 - IDG Summary

클라우드는 탁월한 유연성과 민첩성뿐만 아니라 인공지능이나 머신러닝 등 최첨단 기술의 요람 역할로도 주목받고 있다. 하지만 많은 기업이 모험성 강한 전면적인 클라우드 도입보다는 온프레미스 환경과 클라우드를 함께 사용하는 하이브리드 클라우드이다. 구글 안토스는 첨단 퍼블릭 클라우드의 쿠버네티스와 마이크로서비스 아키텍처를 온프레미스 환경에서도 손쉽게 구현하고, 이렇게 구현된 두 환경을 하나의 플랫폼으로 온전하게 통합할 수 있도록 해준다. 안토스의 주요 특징과 기술 요소, 마이그레이션 전략을 살펴보고, 국내 최초의 안토스 기반 하이브리드 클라우드 구축 사례를 소개한다. 주요 내용 - 하이브리드 클라우드 구축의 과제 : 위험성, 기존 환경, 인력 - 진정한 하이브리드 멀티클라우드 통합 관리 솔루션 “구글 안토스” - 기존 환경 활용을 극대화하는 안토스 핵심 요소 - 국내 최초 안토스 사례 : 생산 제품 검증 자동화 시스템 - 하이브리드 클라우드의 성패를 결정하는 경험과 기술력

안토스 하이브리드클라우드 쿠버네티스 2021.07.08

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

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

Copyright © 2022 International Data Group. All rights reserved.