.jpg)
마이크로서비스, 개발 과정에 유연성 더해줘 속도와 확장성 증가
성공적으로 도입하기 위해서 필요한 기술들 있어...API는 생혈
[보안뉴스 문가용 기자] 현재 기업 내에서 독자적으로 앱을 개발하는 IT 부서들은 마이크로서비스(microservice)라는 아키텍처를 적극 도입하고 있다. 웹 서버 기업인 NGINSX에 따르면 이미 마이크로서비스 도입에 집중 투자를 하고 있는 기업이 68%나 된다고 한다. 클라우드 개발업체들 중 마이크로서비스를 이미 사용하고 있거나 올해 안에 사용할 예정인 곳은 90%나 되었다.
이처럼 뜨거운 마이크로서비스 아키텍처란 무엇인가? 작지만 독립적인 기능을 수행하는 서비스들을 조립해 좀 더 큰 앱이나 소프트웨어를 만들어내는 것이다. 앱을 통째로, 처음부터 만들어내는 기존 방식과 정확히 반대된다고도 볼 수 있다. 작은 기능들을 ‘조립’하는 것이다 보니 재활용, 재조립, 재구성이 가능해 개발 과정에 속도와 유연성이 함께 더해진다.
하지만 가트너에 의하면 마이크로서비스가 만능은 아니다. “마이크로서비스 아키텍처의 유연성은 정말로 대단합니다. 그러나 모든 환경에서 그러한 장점을 발휘하는 건 아닙니다. 개발진을 이끄는 위치에 있는 분들은 마이크로서비스의 장점과 단점을 낱낱이 알고 있어야 할 겁니다. 마이크로서비스가 제대로 기능을 하려면 몇 가지 전제조건이 갖춰져야 합니다.” 가트너가 말하는 전제조건에는 몇 가지 기술들이 포함되는데, 그 중 7가지를 여기에서 소개해본다.
콘테이너(container)
마이크로서비스를 도입하는 가장 큰 이유 중 하나가 유연성이다. 그래서 많은 기업들이 마이크로서비스의 애플리케이션들을 콘테이너 상에서 구축한다. 현재 가장 많이 활용되는 콘테이너 기술은 도커(Docker)다. 콘테이너 기술이란 애플리케이션과 그에 종속되는 모든 요소들을 하나로 패키지화 하는 것을 말한다. 이렇게 함으로써 회사 입장에서는 해당 애플리케이션을 언제 어디서나 배포할 수 있게 되고, 데이터센터에서 다른 클라우드 서비스로도 간편하게 이동할 수 있게 된다. 콘테이너 기술 시장은 2016년에 7천 620억원 규모로 자라났고, 2020년에는 2조 7천억원 규모로 성장할 것으로 보인다.
오케스트레이션(orchestration)
애플리케이션을 간편하게 패키징 하는 것이 콘테이너라지만, 그 콘테이너도 수가 많아지면 관리가 힘들어지게 된다. 그래서 대두되는 게 오케스트레이션 기술 및 툴들이다. 가장 인기가 많은 콘테이너 관리 툴 혹은 오케스트레이션 툴로는 도커의 스웜(Swarm)이나 구글의 쿠버네츠(Kubernetes), 아파치의 메소스(Mesos), 주키퍼(ZooKeeper) 등이 있다. 4만 5천 여개의 콘테이너 환경을 조사했을 때, 쿠버네츠가 43%, 메소스가 9%, 스웜이 7%를 차지하고 있었다.
클라우드 컴퓨팅
유연성에 대한 추구를 계속하다보니 발생하는 현상이, 마이크로서비스 아키텍처를 클라우드 상에서 구축하는 것이다. 아마존, 애저, 구글 앱 엔진, 블루믹스 등 대형 클라우드 서비스들은 이미 마이크로서비스를 지원할 수 있는 체계를 갖추고 있다. 레드햇(Red Hat)의 오픈쉬프트(OpenShift)나 오픈스택(OpenStack)과 같은 오픈소스 플랫폼들도 마이크로서비스와 콘테이너 기술을 지원한다. 이와 맞물려 FaaS(function as a service : 서비스형 기능)라고도 불리는 서버 없는 컴퓨팅 서비스도 유행처럼 번지고 있다. 가트너에 의하면 공공 클라우드 서비스 시장은 2017년에 18% 성장할 것으로 보인다.
지속적인 통합 툴과 지속적인 배포 툴
마이크로서비스 애플리케이션을 활용하는 기업들이 늘어나면서 ‘지속적인 통합’과 ‘지속적인 배포’도 중요한 개념으로 자리 잡기 시작했다. 줄여서 CI(continuous integration)와 CD(continuous delivery)라고도 한다. CI는 새로운 코드를 공유된 저장소에 적어도 하루에 한 번 자동으로 주입시키는 것을 말한다. 보통은 하루에 한 번 이상의 주기로 설정된다. CD는 소프트웨어 패키지를 온라인 샵과 같은 배포 환경으로 자동으로 옮기는 기술이다. CI와 CD는 보통 함께 사용된다. 젠킨스(Jenkins), 허드슨(Hudson), 셰프(Chef) 등의 툴이 유명하다.
애플리케이션 모니터링
마이크로서비스 애플리케이션을 개발하고 배포하는 기술 외에 애플리케이션의 성능에 초점을 맞춘 모니터링 기술도 반드시 필요하다. 하지만 현존하는 애플리케이션 모니터링 툴들은 대부분 ‘워터폴(waterfall)’ 방식으로 만들어졌다. 즉, 현재의 데브옵스나 마이크로서비스 환경과 궁합이 좋지 않다는 것이다. 그나마 전문가들이 권장하는 툴은 프로메테우스(Prometheus), 다이나트레이스(Dynatrace), 앱다이내믹스 마이크로서비스 iQ(AppDynamics Microservices iQ), 인스타나(Instana)가 있다.
API
애플리케이션 프로그래밍 인터페이스의 준말인 API는 마이크로서비스 아키텍처의 생혈과 같은 존재다. 각각의 마이크로서비스들은 API를 가지고 있는데, 이 API를 통해 다른 마이크로서비스와의 ‘교류’와 ‘상호작용’을 한다. API가 있기 때문에 서비스를 잘게 쪼개는 게 가능하다는 것이다. 기업들은 API를 외부인에게 적극 노출시켜 제3자가 독자적인 앱 개발 등을 통해 자신들이 제공하는 서비스를 활용할 수 있도록 해준다. 이래서 등장하기 시작한 게 API 관리 솔루션이다.
REST
표현 상태 전송(Representational State Transfer)의 준말인 REST는 마이크로서비스들 사이의 통신과 교류, 상호작용이 문제가 됨에 따라 대두가 되고 있는 기술이다. 사용이 매우 간편해 개발자들 사이에서 인기가 높다. 마이크로서비스들이 HTTP를 통해 곧장 상호 통신할 수 있도록 해주며, 요청과 응답은 XML, HTML, JSON과 같은 표준 포맷으로 처리된다. 또한 마이크로서비스 애플리케이션들이 대부분 웹 애플리케이션이기 때문에 웹 기술 의존도가 높은 REST는 당연한 선택이었다.
[국제부 문가용 기자(globoan@boannews.com)]
성공적으로 도입하기 위해서 필요한 기술들 있어...API는 생혈
[보안뉴스 문가용 기자] 현재 기업 내에서 독자적으로 앱을 개발하는 IT 부서들은 마이크로서비스(microservice)라는 아키텍처를 적극 도입하고 있다. 웹 서버 기업인 NGINSX에 따르면 이미 마이크로서비스 도입에 집중 투자를 하고 있는 기업이 68%나 된다고 한다. 클라우드 개발업체들 중 마이크로서비스를 이미 사용하고 있거나 올해 안에 사용할 예정인 곳은 90%나 되었다.
[이미지 = iclickart]
이처럼 뜨거운 마이크로서비스 아키텍처란 무엇인가? 작지만 독립적인 기능을 수행하는 서비스들을 조립해 좀 더 큰 앱이나 소프트웨어를 만들어내는 것이다. 앱을 통째로, 처음부터 만들어내는 기존 방식과 정확히 반대된다고도 볼 수 있다. 작은 기능들을 ‘조립’하는 것이다 보니 재활용, 재조립, 재구성이 가능해 개발 과정에 속도와 유연성이 함께 더해진다.
하지만 가트너에 의하면 마이크로서비스가 만능은 아니다. “마이크로서비스 아키텍처의 유연성은 정말로 대단합니다. 그러나 모든 환경에서 그러한 장점을 발휘하는 건 아닙니다. 개발진을 이끄는 위치에 있는 분들은 마이크로서비스의 장점과 단점을 낱낱이 알고 있어야 할 겁니다. 마이크로서비스가 제대로 기능을 하려면 몇 가지 전제조건이 갖춰져야 합니다.” 가트너가 말하는 전제조건에는 몇 가지 기술들이 포함되는데, 그 중 7가지를 여기에서 소개해본다.
콘테이너(container)
마이크로서비스를 도입하는 가장 큰 이유 중 하나가 유연성이다. 그래서 많은 기업들이 마이크로서비스의 애플리케이션들을 콘테이너 상에서 구축한다. 현재 가장 많이 활용되는 콘테이너 기술은 도커(Docker)다. 콘테이너 기술이란 애플리케이션과 그에 종속되는 모든 요소들을 하나로 패키지화 하는 것을 말한다. 이렇게 함으로써 회사 입장에서는 해당 애플리케이션을 언제 어디서나 배포할 수 있게 되고, 데이터센터에서 다른 클라우드 서비스로도 간편하게 이동할 수 있게 된다. 콘테이너 기술 시장은 2016년에 7천 620억원 규모로 자라났고, 2020년에는 2조 7천억원 규모로 성장할 것으로 보인다.
오케스트레이션(orchestration)
애플리케이션을 간편하게 패키징 하는 것이 콘테이너라지만, 그 콘테이너도 수가 많아지면 관리가 힘들어지게 된다. 그래서 대두되는 게 오케스트레이션 기술 및 툴들이다. 가장 인기가 많은 콘테이너 관리 툴 혹은 오케스트레이션 툴로는 도커의 스웜(Swarm)이나 구글의 쿠버네츠(Kubernetes), 아파치의 메소스(Mesos), 주키퍼(ZooKeeper) 등이 있다. 4만 5천 여개의 콘테이너 환경을 조사했을 때, 쿠버네츠가 43%, 메소스가 9%, 스웜이 7%를 차지하고 있었다.
클라우드 컴퓨팅
유연성에 대한 추구를 계속하다보니 발생하는 현상이, 마이크로서비스 아키텍처를 클라우드 상에서 구축하는 것이다. 아마존, 애저, 구글 앱 엔진, 블루믹스 등 대형 클라우드 서비스들은 이미 마이크로서비스를 지원할 수 있는 체계를 갖추고 있다. 레드햇(Red Hat)의 오픈쉬프트(OpenShift)나 오픈스택(OpenStack)과 같은 오픈소스 플랫폼들도 마이크로서비스와 콘테이너 기술을 지원한다. 이와 맞물려 FaaS(function as a service : 서비스형 기능)라고도 불리는 서버 없는 컴퓨팅 서비스도 유행처럼 번지고 있다. 가트너에 의하면 공공 클라우드 서비스 시장은 2017년에 18% 성장할 것으로 보인다.
지속적인 통합 툴과 지속적인 배포 툴
마이크로서비스 애플리케이션을 활용하는 기업들이 늘어나면서 ‘지속적인 통합’과 ‘지속적인 배포’도 중요한 개념으로 자리 잡기 시작했다. 줄여서 CI(continuous integration)와 CD(continuous delivery)라고도 한다. CI는 새로운 코드를 공유된 저장소에 적어도 하루에 한 번 자동으로 주입시키는 것을 말한다. 보통은 하루에 한 번 이상의 주기로 설정된다. CD는 소프트웨어 패키지를 온라인 샵과 같은 배포 환경으로 자동으로 옮기는 기술이다. CI와 CD는 보통 함께 사용된다. 젠킨스(Jenkins), 허드슨(Hudson), 셰프(Chef) 등의 툴이 유명하다.
애플리케이션 모니터링
마이크로서비스 애플리케이션을 개발하고 배포하는 기술 외에 애플리케이션의 성능에 초점을 맞춘 모니터링 기술도 반드시 필요하다. 하지만 현존하는 애플리케이션 모니터링 툴들은 대부분 ‘워터폴(waterfall)’ 방식으로 만들어졌다. 즉, 현재의 데브옵스나 마이크로서비스 환경과 궁합이 좋지 않다는 것이다. 그나마 전문가들이 권장하는 툴은 프로메테우스(Prometheus), 다이나트레이스(Dynatrace), 앱다이내믹스 마이크로서비스 iQ(AppDynamics Microservices iQ), 인스타나(Instana)가 있다.
API
애플리케이션 프로그래밍 인터페이스의 준말인 API는 마이크로서비스 아키텍처의 생혈과 같은 존재다. 각각의 마이크로서비스들은 API를 가지고 있는데, 이 API를 통해 다른 마이크로서비스와의 ‘교류’와 ‘상호작용’을 한다. API가 있기 때문에 서비스를 잘게 쪼개는 게 가능하다는 것이다. 기업들은 API를 외부인에게 적극 노출시켜 제3자가 독자적인 앱 개발 등을 통해 자신들이 제공하는 서비스를 활용할 수 있도록 해준다. 이래서 등장하기 시작한 게 API 관리 솔루션이다.
REST
표현 상태 전송(Representational State Transfer)의 준말인 REST는 마이크로서비스들 사이의 통신과 교류, 상호작용이 문제가 됨에 따라 대두가 되고 있는 기술이다. 사용이 매우 간편해 개발자들 사이에서 인기가 높다. 마이크로서비스들이 HTTP를 통해 곧장 상호 통신할 수 있도록 해주며, 요청과 응답은 XML, HTML, JSON과 같은 표준 포맷으로 처리된다. 또한 마이크로서비스 애플리케이션들이 대부분 웹 애플리케이션이기 때문에 웹 기술 의존도가 높은 REST는 당연한 선택이었다.
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-17] 
.jpg)
.jpg)
