- 데브옵스, CI/CD 등 개발자 트렌드 및 스프링 프로그래밍 모델 소개
 |
||
| ▲ 피보탈 ‘스프링원 투어 2018’이 서울에서 개최됐다. | ||
[컴퓨터월드] 피보탈이 지난달 전 세계 ‘스프링(Spring)’ 프레임워크 개발자들을 위한 개발자 커뮤니티 이벤트 ‘스프링원 투어 2018(SpringOne Tour 2018)’을 개최했다.
스프링원 투어는 피보탈의 스프링 전문가들을 만나 모던 애플리케이션 개발과 데브옵스, CI/CD, 클라우드 등을 지원하기 위한 최신 기술에 대한 인사이트를 얻을 수 있는 자리다. LA, 뉴욕, 보스탠, 댈러스, 시카고, 샌프란시스코 등 개발자 커뮤니티가 활성화된 전 세계 주요 도시에서 순차적으로 개최됐으며, 국내에서는 지난달 8일 서울에서 스프링 프레임워크에 관심있는 개발자들을 초청해 진행됐다.
리액티브 스프링 with 스프링 부트 2.0
 |
||
| ▲ 마크 헤클러 피보탈 수석 테크놀로지스트 겸 개발자 애드보킷 | ||
‘스프링원 투어 2018 서울’의 첫 번째 세션에서는 마크 헤클러(Mark Heckler) 피보탈 수석 테크놀로지스트 겸 개발자 애드보킷(Advocate)이 연사로 나섰다. 마크 헤클러는 ‘리액티브 스프링 with 스프링 부트 2.0(Reactive Spring with Spring Boot 2.0)’이라는 제목으로 스프링 프레임워크 5.0의 새로운 기능과 최적화된 프로그램 구축 방법을 공유했다. 스프링 프레임워크 5.0은 리액티브 프로세싱과 새로운 유형의 웹 엔드포인트, 함수형 리액티브 엔드포인트를 지원하기 위한 MVC 유형의 컴포넌트 모델을 통합한다.
리액티브 프로그래밍은 복수의 애플리케이션들이 하나의 단위로 통합돼 주변 환경의 변화에 능동적으로 반응하며 변화하는 마이크로 아키텍처 스타일이다. 일반적으로는 보다 손쉽게 비동기성 논블록킹 작업을 수행함으로써 더 적은 자원으로 더 많은 트래픽을 안정적으로 처리할 수 있도록 한다.
리액티브 방법론에서는 단일 서버에 과도한 부하가 몰리더라도 동시에 처리 가능한 프로세스만을 수행하며, 이것이 완료된 후 다음 프로세스를 로드하는 식으로 작동한다. 이 과정에서는 서브스크립션이 느리다는 것에 의미가 없으며, 항시 유지 가능한 서비스를 가능하도록 한다. 이는 클라우드에 보다 적합한 방식이며 개발자에게 더 많은 통제력을 줄 수 있다.
피보탈은 개발자들이 보다 쉽게 리액티브 프로그래밍을 할 수 있도록 프로젝트 리액터(Project Reactor)를 진행해왔다. 이는 기존의 스프링 개발자들이 가진 경험을 리액티브 프로그래밍에서도 그대로 사용할 수 있도록 지원하기 위한 것이다. 프로젝트 리액터는 리액티브 라이브러리인 ‘리액터(Reactor)’를 스프링 프레임워크에 적용하며, 리액터를 위한 스프링 웹 환경인 스프링 리액티브 웹(Spring Reactive Web)을 제공한다. 리액터는 스프링에서 리액티브 프로그래밍을 구현하기 위한 핵심 요소다.
마크 헤클러 수석 테크놀로지스트는 “프로젝트 리액터는 레드햇이나 트위터와 같은 기업들과 협력해 진행하지만, 세부적인 아이디어에는 차이가 있다”면서, “상호 간에 호환성은 있어야 하지만 인터페이스를 어떻게 제공할 것인가에 대해서는 각자의 방법을 고수하고 있으며, 피보탈의 방법은 기존 스프링 개발자들이 자신의 역량을 리액티브 스택에서 그대로 활용할 수 있도록 하는 것”이라고 설명했다.
클라우드 네이티브 스프링
 |
||
| ▲ 조쉬 롱 피보탈 개발자 애드보킷 | ||
두 번째 세션은 자바 챔피언이자 피보탈 개발자 애드보킷인 조쉬 롱(Josh Long)이 ‘클라우드 네이티브 스프링(Cloud-Native Spring)’을 주제로 연단에 올랐다. 해당 세션에서는 스프링 부트 2.0의 핵심 내용을 포함한 ‘스프링 클라우드.넥스트(Cloud.next)’와 모던 마이크로서비스 개발 지원 방법에 대해 다뤘다.
조쉬 롱 개발자 애드보킷은 모던 마이크로서비스는 분산 시스템이며 매우 약하고 불안정하게 구성된다는 점을 지적했다. 하지만 스프링 프레임워크 5.0이 제공하는 리액티브 프로그래밍은 이를 지원할 수 있다. 리액티브 프로그래밍은 더 많은 시간과 재활용 가능한 스레드를 사용해 모던 마이크로서비스가 가지고 있는 문제를 해결한다.
하지만 모든 마이크로서비스의 문제를 리액티브 프로그래밍만을 이용해 해결할 수는 없다. 가령 크립토그래피(Cryptography)와 같은 암호화를 수행한다거나 비트코인 채굴 등을 수행할 경우에 리액티브 프로그래밍만으로 안정적이고 최적화된 마이크로서비스를 구현할 수는 없다는 설명이다.
이어서 조쉬 롱 개발자 애드보킷은 스프링 리액티브 웹을 활용한 라이브 코딩을 진행하며 참가자의 이해를 도왔다. 현장에서 실시간으로 예약 SW를 개발하는 과정을 시연하며 스프링 프레임워크 5.0의 리액티브 프로그래밍 개념에 대해 소개했으며, 모든 레이어에 대한 흐름을 제어하고 인풋/아웃풋 수행 시 가장 효율적으로 HW 자원을 사용하는 방법을 공유했다.
피보탈과 협력해 성숙한 클라우드 활용 지원
 |
||
| ▲ 조원우 메가존클라우드 대표 | ||
다음 세션은 조원우 메가존클라우드 대표가 연사로 나서, 메가존이 생각하는 클라우드 사업의 비전과 목표에 대해 공유했다.
오늘날 메가존클라우드의 가장 큰 목표는 ▲더 많은 SW를 클라우드에서 제공하고 ▲개발자 커뮤니티 협업 네트워크를 구축하며 ▲고객사의 지속적인 디지털 혁신을 선도하는 것 등이다. 그동안 메가존은 클라우드 기반의 서비스가 기업에게 유리하고, 디지털 기반의 서비스를 하는 기업들의 요구가 높아져 클라우드 사업이 발전할 것이라는 예측을 바탕으로 빠르게 성장해왔다. 실제로 지난 2012년부터 AWS에 대한 서비스를 시작한 것도 클라우드 전환을 원하는 고객의 요구에 의한 것이었다는 설명이다.
최근 5년간 메가존의 영업 활동은 “왜 클라우드를 활용해야 하는가”라는 고객들의 질문에 답하는 일에 집중돼있었다. 이커머스나 게임사 등을 중심으로 이와 같은 의문이 꾸준히 제기돼왔다. 하지만 지난해부터는 질문의 방향성이 변화해, 이제는 산업 분야와 기업의 규모를 가리지 않고 모두 “어떻게 하면 클라우드를 잘 쓸 수 있는가”에 대해 묻기 시작했다.
이러한 질문을 가지고 있는 기업들에게 명확한 답변을 제공하기 위해 메가존클라우드는 피보탈과의 협력을 추진했다. 현재 메가존은 인프라·플랫폼·애플리케이션·데이터 등 다양한 서비스 모델을 보유하고 있지만, 보다 성숙한 클라우드 활용에 대한 요구와 플랫폼에 대한 대안으로 피보탈을 제시하겠다는 전략이다. 조 대표는 피보탈과의 협력으로 도조(Dojo), PAS(Pivotal Application Service), PKS(Pivotal Container Service) 등을 활용함으로써 고객들의 요구애 부응하고 상호간의 성장을 도모하겠다고 밝혔다.
스프링 클라우드 게이트웨이
 |
||
| ▲ 정윤진 피보탈 수석 테크놀로지스트 | ||
네 번째 세션은 정윤진 피보탈 수석 테크놀로지스트가 ‘스프링 클라우드 게이트웨이(Cloud Gateway)’에 대한 발표에 나섰다.
스프링 클라우드에는 굉장히 많은 변화가 실시간으로 일어나고 있으며, 늘 새로운 주제들이 화제로 떠오르고 있다. 기존에 스프링 프레임워크만 사용하던 개발자들은 편의성 때문에 스프링 부트를, 클라우드 앱 개발에 대해 고민하다가 스프링 클라우드를 사용하게 된다. 스프링 클라우드 게이트웨이는 스프링 프레임워크 5.0, 스프링 부트 2.0 이상을 사용해 개발자 친화적인 API 게이트웨이 패턴을 구현할 수 있도록 돕는다.
최근에는 마이크로서비스에도 많은 변화가 일어나고 있다. 예전에는 MVC 기반의 서버사이드 애플리케이션과 각각의 마이크로서비스들이 통신해야했다. 여러 개로 분리된 서비스에 접근하기 위해 각각의 서비스 앞에 도메인을 붙이는 등 별개의 접근 방식을 활용했지만, 클라이언트 숫자가 늘어나고 모바일 디바이스가 폭발적으로 증가하다보니 이제 편리하지 않은 방법이 됐다. 이러한 경우에 API 게이트웨이는 모든 요청을 받아서 목적에 따라 분류하는 교통정리 역할을 수행할 수 있다.
API 게이트웨이는 서비스 내의 모든 트래픽이 통과하는 매우 중요한 역할을 수행하기에 시스템 전체의 보안과도 밀접한 관련을 맺고 있으며, 전체 서비스에 유입된 트래픽을 관리하고 대기시간(latency)를 확인할 수 있도록 적절한 모니터링을 수행할 수 있어야 한다.
가장 유명하고 많이 사용되는 API 게이트웨이는 넷플릭스가 만든 줄(Zuul)이다. 넷플릭스 역시 전체 서비스에서 발생하는 모든 트래픽을 관리하는 API 게이트웨이의 중요성을 인식하고 있기에 기존에 활용하던 상용 게이트웨이 대신 줄을 개발했다.
스프링 클라우드에도 줄이 탑재돼있다. 하지만 넷플릭스가 개발한 다양한 도구들은 그들의 문제를 해결하기 위해 개발하고 오픈소스로 공개한 것이므로, 엄밀히 따져서 스프링 생태계 바깥에서 개발된 것이다. 이에 따라 피보탈의 스프링 팀에서는 스프링 프레임워크 5.0과 스프링 부트 2.0, 프로젝트 리액터를 활용해 API 게이트웨이를 만들었다. 여전히 줄을 사용하는 개발자들이 많기에 서비스는 당분간 지속할 예정이지만, 장기적인 관점에서는 스프링 클라우드 게이트웨이로 전환할 것을 권하고 있다.
스프링 클라우드 게이트웨이는 다양한 패턴에 적용할 수 있다. 애플리케이션 앞단에 직접 게이트웨이를 넣거나, 백엔드 서비스가 깨지기 쉬운 경우 DB 앞에 위치시켜 직접 호출 대신 사용할 수도 있다. 또한 클라이언트에서 백엔드로 직접 요청을 보내지 말아야 할 때 징검다리 역할로도 사용할 수 있다. 이 경우 인증 과정을 게이트웨이에서 처리하도록 하거나, 게이트웨이로 특정 요청이 넘어가지 않도록 막아낼 수 있다. 특히 마이크로서비스로 전환하기 위해 애플리케이션의 기능을 분리해내고 싶을 경우, 게이트웨이를 통해 모든 요청을 받고 각각의 서비스로 전달해주는 역할로도 활용 가능하다.
클라우드 이벤트 주도 아키텍처 with 스프링 클라우드 스트림 2.0
 |
||
| ▲ 제이쿱 필리먼 피보탈 수석 테크놀로지스트 | ||
오후 첫 번째로 ‘클라우드 이벤트 주도 아키텍처 with 스프링 클라우드 스트림 2.0(Cloud Event Driven Architectures with Spring Cloud Stream)’에 대한 발표가 진행됐다. 이벤트 주도는 클라우드 네이티브 및 마이크로서비스와 같은 분산형 아키텍처의 등장으로 어느 때보다 중요성이 높아지고 있으며, 데이터 연동을 위한 스트리밍을 포함해 다양한 사용 사례를 다루어야 하는 폭넓은 분야다.
연사로 나선 제이쿱 필리먼(Jakub Pilimon) 피보탈 수석 테크놀로지스트는 가장 먼저 이벤트 스토밍(Event Storming)에 대해 설명했다. 이벤트 스토밍은 특정 이슈에 대한 모든 관계자들이 함께하는 협업 방법으로, IT 조직에서 비즈니스의 문제가 무엇인지 발견하는 과정이다. 비즈니스에 가장 적합한 SW를 개발하기 위해서는 도메인에 대한 지식이 필요하며, 이것은 비즈니스 조직과의 협업을 통해서만 획득할 수 있다.
이벤트 스토밍을 통해 얻을 수 있는 가장 큰 효과는 비즈니스 조직과 IT 조직이 활용하는 공통된 언어를 발견할 수 있다는 점이다. 비즈니스 조직과 IT 조직은 같은 분야에서 근무하고 있더라도 같은 용어에 대해 서로 다른 정의를 내릴 수 있다. 좋은 SW를 개발하기 위해서는 해당 용어에 결합된 맥락(context)을 파악할 수 있어야 하며, 이를 위해서는 하나의 단어가 하나의 정의만을 가져야 한다.
공통된 용어가 정리되고 나면 트리거와 이벤트 사이의 연관성을 파악해 이벤트끼리의 관계도를 그리는 과정이 필요하다. 예를 들어 고객이 출금을 하려는 요청이 들어왔다면, 계좌에 있는 잔고를 파악하고 월별로 한도가 초과되지는 않았는지 확인해야 한다. 이처럼 예상되는 비즈니스 케이스를 찾고 관계되는 이벤트들을 찾아 연결함으로써 서로의 연관성을 파악할 수 있다. 이 과정에서는 앞서 파악한 공통된 용어가 사용돼야 한다.
이어서 제이쿱 필리먼 수석 테크놀로지스트는 라이브 코딩을 통해 이벤트 주도 개발의 다양한 유형 및 속성에 대해 설명하고, 이를 지원하기 위해 피보탈이 제공하는 스프링 포트폴리오의 다양한 메시지 지향 컴포넌트들에 대해 소개했다.
스프링, 함수, 서버리스 그리고 당신
 |
||
| ▲ 네이트 슈타 피보탈 솔루션 아키텍트 | ||
여섯 번째 세션은 네이트 슈타(Nate Schutta) 피보탈 솔루션 아키텍트가 ‘스프링, 함수, 서버리스 그리고 당신(Spring, Functions, Serverless and You)’을 주제로 서버리스(severless), 쿠버네티스(Kubernetes), 함수(function) 등을 포함한 다양한 개념에 대해 설명하는 시간을 마련했다.
네이트 슈타 솔루션 아키텍트는 가장 먼저 서버를 대하는 개념이 시간이 지남에 따라 변화하고 있다고 설명했다. 과거에 서버는 IT 조직이 부품을 구해다가 직접 조립해 만드는 DIY 상품에 가까웠다. 여기에는 많은 시간과 역량이 요구됐고, 수주에서 수개월, 길게는 1년 이상을 투자해야만 새로운 서버 리소스를 생성할 수 있었다. 이 시대에 서버는 IT 조직의 애완견과 같은 존재였다. 서버마다 별명이 붙여졌고, 많은 시간과 노력과 에너지를 투자해서 보살펴야 했다. 서버는 비싸고 제약이 많았으며, 자체 개발한 OS를 구동해야 했다.
하지만 오늘날 서버는 더 이상 애완견이 아니다. 이제 서버는 가축에 가깝다. 자체 개발된 HW와 커스텀 OS보다는 범용 제품이 사용되며, 고장난 서버를 고치기보다는 새로운 서버를 구입한다. 이제 각각의 서버는 독립된 별명보다는 수많은 서버 중 하나에 불과한 번호가 붙여지며, 시간과 노력을 들여 관리하기보다는 자동화된 SW로 관리된다.
이처럼 IT 업계는 계속 진화하고 새로운 형태의 서비스들이 등장하고 있다. 이 중 가장 최근에 등장한 것이 바로 서버리스다. 물리적인 서버가 어딘가에 있지만, 사용자는 이런 것들이 마치 없는 것처럼 신경 쓰지 않아도 된다.
레이어를 구분해서 보자면 ▲HW ▲IaaS ▲컨테이너 ▲플랫폼 ▲서버리스 순으로 나열할 수 있다. 전자에 가까울수록 사용자가 얻을 수 있는 통제력은 높아지지만, 운영에 신경써야 할 요소들이 많아진다. 반대로 후자에 가까울 수롱 운영상의 편의성은 극대화되지만 IT 자원에 대한 통제력은 일부 포기해야 한다.
네이트 슈타 솔루션 아키텍트는 비즈니스 문제를 해결하기 위해 최적의 레이어를 선택하는 것이 중요하며, 가능한 한 많은 워크로드를 서버리스에 가깝게 배치하라고 조언했다. 기업이 추구해야 할 것은 고객들의 고충을 해결하고 가치를 제공하는 것이므로, 인프라에 너무 많은 역량을 소모하는 것은 합리적이지 않다는 설명이다.
스프링 부트 & 스프링 클라우드 on 피보탈 애플리케이션 서비스
 |
||
| ▲ 정윤진 피보탈 수석 테크놀로지스트 | ||
다음 세션은 다시 정윤진 피보탈 수석 테크놀로지스트가 연단에 올라 ‘스프링 부트 & 스프링 클라우드 on 피보탈 애플리케이션 서비스(Spring Boot & Spring Cloud on Pivotal Application Service)’를 주제로 발표에 나섰다.
분업화된 비즈니스 조직에는 병목현상이 존재한다. 한 개발자가 자신의 개발이 끝나서 QA 팀에 보내면, 그것이 검수를 거쳐 다시 돌아올 때까지 다른 업무를 수행하며 기다려야 한다. 그러다가 QA팀에서 결과물을 돌려주면 하던 일을 멈추고 다시 해당 SW를 손봐서 QA팀에 넘긴다. 이런 기나긴 과정들이 팀 간의 병목현상을 야기하고 기업의 효율성을 떨어트린다. 기업에서는 하나의 SW를 개발하고 서비스하기 위해 설계(design)-개발(develop)-점검(test)-배포(deploy)-운영(operate)-지원(support) 등 여섯 가지 역할을 나눠서 운영한다. 결국 운영하는 서비스는 하나인데 왜 이렇게 복잡하게 일을 해야 하는가?
넷플릭스는 이러한 문제를 클라우드 플랫폼에서 해결했다. 넷플릭스는 오퍼레이션 팀을 클라우드 팀으로 통합하고, 기존에 오퍼레이션 팀이 하던 업무를 AWS에 이관했다. 대신 클라우드 팀은 넷플릭스 서비스 개발자들이 손쉽게 활용할 수 있는 다양한 도구들을 만들기 시작했다. 많은 개발자들은 설계-개발-점검까지는 본인의 영역이라고 생각하지만, 배포-운영-지원은 본인의 영역이 아니라고 생각한다. 이에 따라 넷플릭스의 클라우드 팀은 배포-운영-지원을 간단한 도구로 만들어놓고 개발자들이 손쉽게 본인이 개발한 SW에 적용할 수 있도록 했다. 이것이 넷플릭스가 주장하는 풀 사이클 개발자 전략이다. 이러한 컨셉은 마이크로서비스, 데브옵스를 실천하는 좋은 방법 중 하나다.
이미 시장에는 피보탈 애플리케이션 서비스(PAS)를 지원할 수 있는 다양한 방법들이 있다. 가령 서버리스를 고려한다면 오토스케일링 조차 고민할 필요가 없다. 개발자 친화적인 도구들을 충분히 활용한다면 생산성을 높이고 전체 시스템에 대한 이해를 높일 수 있다.
피보탈의 스프링 팀에서 계속해서 강조하는 것은 이미 다른 사람이 해놓은 일들을 반복적으로 수행하며 역량을 낭비할 필요가 없다는 것이다. 새로운 DB를 만들기 위해 부품 구입부터 해야 한다면 너무 어렵고 지난한 일이 될 것이다. 보일러 플레이트(Boilerplate)를 새롭게 만들기보다, 스프링 클라우드에 이미 탑재돼 있는 많은 기능과 구성요소들을 활용해 보다 편리하게 애플리케이션을 개발하고 운영하는 것이 합리적이다.
쿠버네티스 상에서 개발자 워크플로우 생성을 위해 스피내커 사용하기
 |
||
| ▲ 폴 자코스키 피보탈 수석 테크놀로지스트 | ||
이날 행사의 마지막 세션은 ‘쿠버네티스 상에서 개발자 워크플로우 생성을 위해 스피내커 사용하기(Using Spinnaker to Create a Development Workflow on Kubernetes)’라는 주제로 폴 자코스키(Paul Czarkowski) 피보탈 수석 테크놀로지스트가 발표했다.
피보탈 쿠버네티스 서비스(PKS)는 지난 1월 공개된 피보탈 클라우드 파운드리(Pivotal Cloud Foundry, PCF)에서 추가됐으며, PCF를 구축한 도구를 유사하게 사용해 개발했다. PKS는 모니터링과 자동화된 상태 확인 등을 통해 클라우드 상에서 컨테이너 워크로드를 안정적으로 배포하고 실행할 수 있도록 돕는다.
운영 플랫폼으로써 쿠버네티스는 높은 유연성을 제공한다. 모든 애플리케이션은 쿠버네티스에서 동작할 수 있다. 하지만 여러 장소에서 HW 인프라가 돌아가고 저장소도 여러 곳으로 나뉘게 되면 관리상의 어려움이 발생할 수 있다. 이는 간단한 애플리케이션 배포조차 복잡하고 어렵게 만들 수 있다.
PKS는 쿠버네티스를 활용한 이점을 확보하면서도 배포 상의 어려움 등을 극복할 수 있도록 한다. 또한 넷플릭스에서 개발한 스피내커(Spinnaker)를 활용하면 애플리케이션 테스트와 빌드, 쿠버네티스로의 배포(continuous delivery)를 손쉽게 수행할 수 있다.
이어서 폴 자코스키 수석 테크놀로지스트는 라이브 코딩을 통해 스피내커를 활용한 애플리케이션 빌드·배포 과정을 단계적으로 소개했다. 특히 쿠버네티스에 대한 개념 설명과 구성요소들에 대한 소개를 통해 참가자들의 이해를 도왔다.
김성수 기자 kimss56@itdaily.kr
