Offcanvas

How To / 가상화 / 개발자 / 데이터센터 / 애플리케이션 / 클라우드

기고 | 마이크로서비스 확장을 위한 7가지 비법

2018.05.21 Christian Beedgen  |  InfoWorld


#5 여러 다양한 방식의 테스트를 수용한다
마이크로서비스는 테스트가 아주 어렵다. 특히 지속적인 배포 모드를 도입한 이후에는 더 그렇다. 이 문제를 극복하기 위해 통합과 유닛 테스트에 많은 투자를 했고, 지금도 그렇게 하고 있다. 우리는 각각의 개별적인 상황에 따라 몇 가지 방법으로 테스트를 한다.

이 가운데 하나는 이른바 ‘로컬 배포’이다. 대부분의 서비스를 노트북 컴퓨터에 실행시켜 완전하게 운영되는 시스템을 구현하는 방법이다. 그러나 현재 16GB의 RAM을 장착한 노트북 컴퓨터가 한계이다. 즉 쉽게 확장을 할 수 없다.

두 번째 방법은 ‘개인 배포'이다. 우리 회사 직원들은 모두 각자의 AWS 계정을 가지고 있다. 또 배포 도구가 자동화되어 있기 때문에 약 10분 정도면 AWS에 수모 로직의 완전한 인스턴스를 구현할 수 있다. AWS를 중심으로 클라우드가 크게 보급된 것이 이점이 되는 경우이다.

세 번째 방법은 우리가 개발한 ‘스텁빙(Stubbing)’ 모듈에서 이름을 딴 '스텁본(Stubborn)’이라는 방법이다. 스텁본을 이용해 진짜 서비스 같이 동작하는 마이크로서비스 스텁을 작성하고, 이를 진짜 서비스처럼 서비스 검색 서비스에 게시한다. 하지만 실제는 우리기 제어하는 일을 하는 더미(가짜) 서비스이다. 이런 서비스를 모두 실행시키는 것보다 훨씬 가볍다.

검색 구성요소를 작업하고 있다고 가정하자. 항상 어떤 고객이 있는지 파악하는 서비스가 필요하다. 또 사용자와 파티션에 대해 파악하는 서비스가 필요하다. 그러나 모든 기능이 탑재되어 있고 복잡한 진짜 ‘버전'은 사실 필요 없다. 사용자가 있는 것처럼, 다시 말해 진짜처럼 행동하는 무언가만 있으면 된다. 우리는 스텁본을 이렇게 활용하고 있다.

#6 보안을 중시한다
GDPR, HIPAA, PCI 등 자격과 인증 준수를 중요하게 생각하는 고객들이 늘어나고 있는 추세이다.

이런 점을 감안, 시작부터 보안을 구현해야 한다. 우리의 배포 도구는 ‘모델’ 기반이다. 이 모델은 클러스터와 마이크로서비스 같은 것들을 이해하는 것은 물론, 서로 통신하는 방식도 이해한다. 이 모델을 토대로 꽤 튼튼한 보안 통제 체계를 만들 수 있었다.

예를 들면, 네트워크 수준에서 누가 누구와 통신하는지 파악해 엄격한 방화벽 규칙을 생성할 수 있다. 이는 AWS가 우리를 위해 힘든 일 중 일부를 맡아주고 있는 부분이기도 하다.

클라우드를 기반으로 구축을 할 경우 보안 측면에서 장점이 많다. 수작업으로 이런 작업은 할 수 없다. 모든 것을 자동화시켜야 한다. 스크립트를 작성하기 시작하고 모든 것을 자동화하고 나면, 어느 순간 모든 것을 ‘기본값’으로 쉽게 연결할 수 있게 된다.

그러나 아키텍처와 코드가 보안의 전부는 아니다. 이와 관련된 많은 프로세스가 있고, 이것들이 중요하다. 구체적으로 설명하면, 고객들이 감사 보고서를 확인할 수 있어야 한다. 통제(제어, 관리) 측면에서 감사가 요구하는 것을 파악하고, 이에 대해 테스트를 하면, 이를 장점으로 바꿀 수 있다. 이후 감사자가 이에 대해 테스트를 하는 순간 '좋은 습관’이 만들어진다.

#7 조직의 특정 필요사항에 부합하도록 내부 위키를 관리한다
규모 조정이란 많은 정보를, 그것도 아주 빠르게 축적하는 것을 의미한다. 많은 개발 팀이 정보나 베스트 프랙티스를 찾기 위해 내부 위키 페이지를 사용한다. 하지만 조직 구성원 누구나 수정할 수 있도록 개방해 놓는 경우가 많다. 이 경우 엉터리 정보들로 엉망이 될 수 있다. 이런 유형의 콘텐츠는 관리와 유지보수가 힘들다. 따라서 큐레이터를 지정해 조직의 위키에 대한 유지관리를 책임지도록 만들어야 한다.

큐레이터 지정이 지나친 ‘중앙집중화’이고, 특정 직원에게 지나치게 큰 부담을 안기는 것이 아닐까 걱정할 수도 있다. 그러나 여러 개발자들로 하여금 집단으로 위키의 지속적인 업데이트를 책임지도록 동기를 부여하기란 아주 어렵다. 또한 IT 분야 종사자들은 하고 있는 일이 너무 많은 경우가 많고 신생업체의 경우는 특히 그렇다. 그러나 경영진과 관리진은 이런 자료나 베스트 프랙티스의 관리를 중요하게 취급해야 한다.

위키 큐레이터는 큐레이션하는 콘텐츠에 대해 전략적으로 행동해야 한다. 모든 것을 포함시키지 말고, 개발자들이 정말 이해해야 하는 핵심 개념만 유지한다. 콘텐츠가 지나치게 많으면 압도를 당하고, 결국 제대로 활용하지 않는다.

마이크로서비스를 '분할 정복’
마이크로서비스의 중심에는 ‘분할 정복’이라는 개념이 도사리고 있다. 개발해야 하는 분산형 시스템은 복잡해질 것이다. 이런 문제를 극복하는 방법 중 하나는 특정 부분의 복잡성을 제한하려 시도하는 것이다. 여기에서 소개한 7가지 팀을 적용하면 쉽게 변화를 극복할 수 있다.

시스템과 인적 시스템 모두를 확장하는 최고의 방법 중 하나는 마이크로서비스를 도입하는 것이다. 특히 기능적인 요구 사항과 비기능적인 요구사항으로 인한 복잡성이 폭증하고 있다는 점을 감안하면 더 그렇다. 모놀리식에서 마이크로서비스로 이동하는 것이 힘들어 보일 수도 있지만, 개발자의 아이디어와 협력을 결집할 수 있다면, 그 변화를 충분히 관리하고, 더 나아가 조직의 확장 프로세스를 능률화할 수 있다. 이는 개발자의 부담을 크게 덜어줄 것이다. 또 궁극적으로 고객 필요 사항을 더 효과적으로 충족하는 더 효율적인 시스템이 탄생한다.

*Christian Beedgen은 수모 로직의 공동 설립자이자 CTO이다.
editor@itworld.co.kr

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.