2021.10.06

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

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

빠른 속도에 필요한 것은 조율과 운영 인식

다수의 작고 원자적인, 또는 자주 배포되는 마이크로서비스 구축을 목표로 하는 개발 부서에 대한 필자의 첫 번째 우려는 이들의 배포 속도가 협업과 안전 가드레일을 감안하지 않는 경우다.
 
빅판다(BigPanda) CTO 제이슨 워커에게 마이크로서비스를 성공적으로 구축, 배포, 강화하는 개발 부서에 관한 경험을 들어봤다. 워커는 “가장 큰 영향은 속도다. 개발-테스트-배포 주기 시간이 비약적으로 줄어든다. 애자일 부서는 클라우드 기반 서비스를 클라우드에서 개발하고 입력에는 마이크로서비스 생태계를 활용함으로써 매우 빠른 속도로 움직일 수 있다”고 말했다.
 
워커는 부서가 빠른 속도로 작업하면서도 궤도를 유지하고 비즈니스 가치를 제공하는 데 도움이 되는 작업 환경이 필요하다고 말했다. 워커가 제안하는 모범 사례는 다음과 같다.

• 각 부서가 비즈니스 목표에서 이탈하지 않도록 모든 단계의 리더가 전략적 목표를 이해하고 정렬시켜야 한다.

• 스크럼 마스터는 애자일 메트릭을 채택하고 스토리를 정확히 채점하고 지속적으로 부서 속도를 측정하고 장기적 계획을 위해 변동성을 기록하고 수용해야 한다.

• 모듈형 부서가 각기 제멋대로 활동하면서 비호환성이 발생하지 않도록 지식 관리 프로세스와 정확한 최신 문서 제공이 소프트웨어 개발 수명 주기 안에 기본적으로 포함되어야 한다.

• 조치 가능한 모니터링 전략이 필요하다. 합성 및 클라이언트 텔레메트리를 전체적인 서비스 성능에 대한 거시적 지표로 사용할 수 있으며 모니터링에서 신호 대 잡음비를 측정해야 한다.
 

코드 리팩터링으로 마이크로서비스 강화할 것

객체 지향 프로그래밍과 SOA에서 중요한 코딩 영역 중 하나는 코드 리팩터링이다. 코드 리팩터링은 개발자가 여러 고려 사항과 성능 요소 또는 기술 부채 문제를 더 잘 이해하게 되면서 코드의 구조를 개선할 수 있게 해준다.
 
리팩터링은 모놀리식 애플리케이션을 마이크로서비스로 변환하기 위한 핵심 기법이다. 리팩터링 전략에는 프레젠테이션 계층 분리, 비즈니스 서비스 추출, 데이터베이스 리팩터링이 포함된다.
 
프로젝트 앤 부서(Project and Team)의 전략 자문 위원인 로빈 예맨은 대규모 정부 및 방위 시스템 분야에서 경력의 대부분을 쌓았다. 로빈은 “복잡한 레거시 시스템 구축 또는 업데이트에서 애자일 활용을 막는 가장 큰 기술적 장벽은 소프트웨어 아키텍처의 많은 종속성이다. 이로 인해 여러 부서가 코드를 주고받아야 하고 지연이 발생한다”고 말했다.
 
로빈은 종속성을 줄이는 데 리팩터링의 초점을 맞춰야 한다면서 “클라우드 네이티브 애플리케이션과 마이크로서비스를 활용하기 위한 대규모 레거시 시스템의 소프트웨어 아키텍처 리팩터링은 시스템과 이 시스템을 지원하는 부서 사이의 종속성을 줄여준다”고 말했다.
 
또한 리팩터링은 다음과 같은 방식으로 마이크로서비스를 개선한다.

•    비즈니스 모델이 발전할 때 도메인 모델 업데이트
•    단일 책임 원칙에 부합하도록 서비스 축소
•    이벤트 기반 아키텍처의 측정 개선
•    관찰 가능성 및 오류 검증 강화
•    데브옵스 파이프라인 또는 컨테이너 구성에 대한 변경 처리
 
노블9(Nobl9)의 COO인 킷 머커는 클라우드 네이티브 애플리케이션 및 마이크로서비스로 전환 중인 조직을 대상을 “모든 것을 다시 쓸 수는 없고 전환을 단계화해야 한다. 최선의 방법은 구현 방법에 대해 중립적이며 클라우드 네이티브 구현으로 전환하는 동안에도 사용자가 서비스에 대해 받는 인상을 관리하는 명확한 서비스 수준 목표를 설정하는 것”이라고 조언했다.
 

마이크로서비스 설계 패턴 채택

설계 패턴은 항상 공통적인 문제 집합을 중심으로 코드를 구조화하는 데 사용됐다. 예를 들어 객체 지향 설계 패턴의 범주는 생성(creational), 행위(behavioral), 구조(structural)이며, 소프트웨어 설계의 일반적인 문제를 해결하는 데 사용된다. SOA 설계 패턴은 10년 이상 전부터 존재했고, 현재의 REST API, 클라우드 API 설계 패턴의 시초다.
 
마이크로서비스 설계 패턴 사용은 장기적인 성공을 위해 필수적이다. 기술 조직은 장애 격리, 지속적 제공, 탈중앙화된 관리 모델을 지원하는 독립적이고 탄력적인 자동 프로비저닝 서비스를 목표로 한다. 개발 부서가 설계 패턴을 사용한 개발에서 공통의 언어와 마이크로서비스 아키텍처, 구현 전략을 사용하지 않는다면 그 목표를 달성하기가 어렵다.
 
프리브옵스(PrivOps) 공동 창업자이자 CTO인 타일러 존슨은 마이크로서비스 개발이 복잡성을 줄이기 위한 핵심 전략이라면서 “클라우드 네이티브 애플리케이션을 기술하는 한 가지 방법은 ‘상호작용하는 복잡한 분산 시스템 집합’이다. 이 복잡성이 금방 관리하기 어려울 정도로 커질 수 있다. 표준화된 데브섹옵스 툴과 API, 데이터 모델이 포함된 표준화된 모듈형 마이크로서비스 아키텍처가 필요한 이유”라고 말했다.
 
부미(Boomi)의 글로벌 설계자이자 수석 기술자인 마이클 바크맨은 합성 마이크로서비스 설계 패턴을 사용하면 개발자가 사용자 경험에 집중할 수 있다고 말했다. 이 설계 패턴은 개발자가 멀티클라우드 서비스 및 SaaS 플랫폼 API에 연결되는 애플리케이션을 만들 때 특히 중요하다.
 
바크맨은 “합성은 추상화된 뷰를 통해 표시되는 엔드포인트 모음이다. 개발자는 서비스 카탈로그로 가서 합성을 호출하고 내부적으로 어떤 일이 벌어지는지에 관해서는 신경쓰지 않아도 된다. 최종 사용자에게 더 근접해지고 있으며 스택의 최상위에서 합성 서비스를 통해 신뢰할 수 있는 경험을 실현하고 있다”고 말했다.
 
요약하면, 클라우드 네이티브 애플리케이션 및 마이크로서비스를 구축하려면 개발 부서가 협업, 코드 리팩터링, 재사용 가능하고 안정적인 서비스 개발과 같은 장기적인 소프트웨어 개발 측면에 뛰어나야 한다. 이러한 서비스를 대규모로 개발 중인 부서가 많으므로, 앞서 소개한 모범 사례를 배우고 수정하고 성숙시키는 것이 중요하다. editor@itworld.co.kr 


2021.10.06

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

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

빠른 속도에 필요한 것은 조율과 운영 인식

다수의 작고 원자적인, 또는 자주 배포되는 마이크로서비스 구축을 목표로 하는 개발 부서에 대한 필자의 첫 번째 우려는 이들의 배포 속도가 협업과 안전 가드레일을 감안하지 않는 경우다.
 
빅판다(BigPanda) CTO 제이슨 워커에게 마이크로서비스를 성공적으로 구축, 배포, 강화하는 개발 부서에 관한 경험을 들어봤다. 워커는 “가장 큰 영향은 속도다. 개발-테스트-배포 주기 시간이 비약적으로 줄어든다. 애자일 부서는 클라우드 기반 서비스를 클라우드에서 개발하고 입력에는 마이크로서비스 생태계를 활용함으로써 매우 빠른 속도로 움직일 수 있다”고 말했다.
 
워커는 부서가 빠른 속도로 작업하면서도 궤도를 유지하고 비즈니스 가치를 제공하는 데 도움이 되는 작업 환경이 필요하다고 말했다. 워커가 제안하는 모범 사례는 다음과 같다.

• 각 부서가 비즈니스 목표에서 이탈하지 않도록 모든 단계의 리더가 전략적 목표를 이해하고 정렬시켜야 한다.

• 스크럼 마스터는 애자일 메트릭을 채택하고 스토리를 정확히 채점하고 지속적으로 부서 속도를 측정하고 장기적 계획을 위해 변동성을 기록하고 수용해야 한다.

• 모듈형 부서가 각기 제멋대로 활동하면서 비호환성이 발생하지 않도록 지식 관리 프로세스와 정확한 최신 문서 제공이 소프트웨어 개발 수명 주기 안에 기본적으로 포함되어야 한다.

• 조치 가능한 모니터링 전략이 필요하다. 합성 및 클라이언트 텔레메트리를 전체적인 서비스 성능에 대한 거시적 지표로 사용할 수 있으며 모니터링에서 신호 대 잡음비를 측정해야 한다.
 

코드 리팩터링으로 마이크로서비스 강화할 것

객체 지향 프로그래밍과 SOA에서 중요한 코딩 영역 중 하나는 코드 리팩터링이다. 코드 리팩터링은 개발자가 여러 고려 사항과 성능 요소 또는 기술 부채 문제를 더 잘 이해하게 되면서 코드의 구조를 개선할 수 있게 해준다.
 
리팩터링은 모놀리식 애플리케이션을 마이크로서비스로 변환하기 위한 핵심 기법이다. 리팩터링 전략에는 프레젠테이션 계층 분리, 비즈니스 서비스 추출, 데이터베이스 리팩터링이 포함된다.
 
프로젝트 앤 부서(Project and Team)의 전략 자문 위원인 로빈 예맨은 대규모 정부 및 방위 시스템 분야에서 경력의 대부분을 쌓았다. 로빈은 “복잡한 레거시 시스템 구축 또는 업데이트에서 애자일 활용을 막는 가장 큰 기술적 장벽은 소프트웨어 아키텍처의 많은 종속성이다. 이로 인해 여러 부서가 코드를 주고받아야 하고 지연이 발생한다”고 말했다.
 
로빈은 종속성을 줄이는 데 리팩터링의 초점을 맞춰야 한다면서 “클라우드 네이티브 애플리케이션과 마이크로서비스를 활용하기 위한 대규모 레거시 시스템의 소프트웨어 아키텍처 리팩터링은 시스템과 이 시스템을 지원하는 부서 사이의 종속성을 줄여준다”고 말했다.
 
또한 리팩터링은 다음과 같은 방식으로 마이크로서비스를 개선한다.

•    비즈니스 모델이 발전할 때 도메인 모델 업데이트
•    단일 책임 원칙에 부합하도록 서비스 축소
•    이벤트 기반 아키텍처의 측정 개선
•    관찰 가능성 및 오류 검증 강화
•    데브옵스 파이프라인 또는 컨테이너 구성에 대한 변경 처리
 
노블9(Nobl9)의 COO인 킷 머커는 클라우드 네이티브 애플리케이션 및 마이크로서비스로 전환 중인 조직을 대상을 “모든 것을 다시 쓸 수는 없고 전환을 단계화해야 한다. 최선의 방법은 구현 방법에 대해 중립적이며 클라우드 네이티브 구현으로 전환하는 동안에도 사용자가 서비스에 대해 받는 인상을 관리하는 명확한 서비스 수준 목표를 설정하는 것”이라고 조언했다.
 

마이크로서비스 설계 패턴 채택

설계 패턴은 항상 공통적인 문제 집합을 중심으로 코드를 구조화하는 데 사용됐다. 예를 들어 객체 지향 설계 패턴의 범주는 생성(creational), 행위(behavioral), 구조(structural)이며, 소프트웨어 설계의 일반적인 문제를 해결하는 데 사용된다. SOA 설계 패턴은 10년 이상 전부터 존재했고, 현재의 REST API, 클라우드 API 설계 패턴의 시초다.
 
마이크로서비스 설계 패턴 사용은 장기적인 성공을 위해 필수적이다. 기술 조직은 장애 격리, 지속적 제공, 탈중앙화된 관리 모델을 지원하는 독립적이고 탄력적인 자동 프로비저닝 서비스를 목표로 한다. 개발 부서가 설계 패턴을 사용한 개발에서 공통의 언어와 마이크로서비스 아키텍처, 구현 전략을 사용하지 않는다면 그 목표를 달성하기가 어렵다.
 
프리브옵스(PrivOps) 공동 창업자이자 CTO인 타일러 존슨은 마이크로서비스 개발이 복잡성을 줄이기 위한 핵심 전략이라면서 “클라우드 네이티브 애플리케이션을 기술하는 한 가지 방법은 ‘상호작용하는 복잡한 분산 시스템 집합’이다. 이 복잡성이 금방 관리하기 어려울 정도로 커질 수 있다. 표준화된 데브섹옵스 툴과 API, 데이터 모델이 포함된 표준화된 모듈형 마이크로서비스 아키텍처가 필요한 이유”라고 말했다.
 
부미(Boomi)의 글로벌 설계자이자 수석 기술자인 마이클 바크맨은 합성 마이크로서비스 설계 패턴을 사용하면 개발자가 사용자 경험에 집중할 수 있다고 말했다. 이 설계 패턴은 개발자가 멀티클라우드 서비스 및 SaaS 플랫폼 API에 연결되는 애플리케이션을 만들 때 특히 중요하다.
 
바크맨은 “합성은 추상화된 뷰를 통해 표시되는 엔드포인트 모음이다. 개발자는 서비스 카탈로그로 가서 합성을 호출하고 내부적으로 어떤 일이 벌어지는지에 관해서는 신경쓰지 않아도 된다. 최종 사용자에게 더 근접해지고 있으며 스택의 최상위에서 합성 서비스를 통해 신뢰할 수 있는 경험을 실현하고 있다”고 말했다.
 
요약하면, 클라우드 네이티브 애플리케이션 및 마이크로서비스를 구축하려면 개발 부서가 협업, 코드 리팩터링, 재사용 가능하고 안정적인 서비스 개발과 같은 장기적인 소프트웨어 개발 측면에 뛰어나야 한다. 이러한 서비스를 대규모로 개발 중인 부서가 많으므로, 앞서 소개한 모범 사례를 배우고 수정하고 성숙시키는 것이 중요하다. editor@itworld.co.kr 


X