IBM Distinguished Engineer, CTO of Cloud Architecture, Cloud Lab Services
원문 (영어)본 시리즈의 1부는 마이크로서비스 기반의 코드 구조 변경이 왜 필요한 이유와 관련 권장 사항을 소개했습니다. 그리고 2부는 마이크로서비스 방식의 데이터 리팩토링으로 해결할 수 있는 문제의 종류를 설명했습니다. 본 시리즈의 마지막 편으로, 단일체로 구성된 앱을 마이크로서비스로 변환하는 4단계 로드맵에 대한 조언을 드립니다.
“처음부터 한번에 마이크로서비스로 전환하려던 고객들 중 성공한 사례는 거의 없었습니다. 이에 반해, 좀 더 점진적인 단계를 거쳐 마이크로서비스로 전환한 고객들은 대부분 성공했습니다.”
원고 (영문)
1단계: 매크로서비스(Macroservices)
마이크로서비스로 가는 여정의 첫번째 단계는 매크로서비스입니다. 대부분 고객들의 기존 “SOA 서비스”가 바로 매크로서비스입니다. RESTful 프로토콜로 웹서비스가 구현되어 있다 하더라도 일반적으로 SOAP를 사용해 서비스가 구현되어 있는 것을 볼 수 있습니다.
매크로서비스의 시작은 공통의 프로토콜로 서비스에 접근하는 것이며, REST를 사용합니다 (간단하게 설명하기 위하여 메세징 시스템을 이용한 비동기 서비스는 다루지 않았습니다). 따라서 만일 현재의 웹서비스가 REST를 지원한다면 첫번째 단계는 이미 완료된 것입니다.
하지만 앱이 웹서비스 없이 단일체로 되어있다면 비지니스 로직을 RESTful 웹 서비스로 분리할 수 있는지에 대한 확인이 필요합니다. 만일 웹 서비스는 있으나 SOAP 기반이라면 기능 중심의 SOAP 인터페이스를 엔티티 중심의 REST 인터페이스로 리팩토링해야 합니다.
REST로의 리팩토링이 완료되면 REST 서비스를 기록하고 카탈로그화하는 것이 가능한지 확인합니다. Swagger와 같은 형식이 도움이 되며, 특히 Bluemix의 API Management를 함께 사용하면, Swagger 문서로 RESTful 서비스를 바인딩하고 호출하는 개별 Bluemix 서비스 타일을 생성할 수 있습니다.
Bluemix의 API Management
API 공유 지원용 셀프 서비스 포털로 API 버전 관리, 수명주기 관리, 사용량 분석을 수행합니다. 비지니스 서비스 사용 및 관리 관련 정책을 시행합니다.
Overview | Usage details
2단계: 미니서비스(Miniservices)
REST로 가기로하고 인터페이스 문서화가 끝나면, 서비스 분할을 시작합니다. 최대한 기능별로 분할하고 서비스당 하나의 컨테이너가 되도록합니다. 본 시리즈 1부에 있는 분할 가이드라인을 지키는 것을 기억하시기 바랍니다.
이렇게 하는데 시간이 걸릴 수 있습니다. 마이크로서비스 아키텍쳐에 필요한 운영 레벨의 규칙들이 있는데, 많은 조직들은 경우 이를 적용할 준비가 되어 있지 않습니다. “한 서비스를 한 컨테이너에 담는다”는 전략을 실행하기 위해서 Cloud Foundry나 Bluemix의 Docker와 같은 기술을 도입해야 할 수도 있습니다. 따라서 많은 경우 이 단계는 시간을 두고 천천히 수행하기를 원할 수 있습니다.
마찬가지로 “한 서비스를 한 컨테이너에 담는다”는 전략을 실행하기 위해서 WebSphere® ND와 같은 전통적 미들웨어를 WebSphere Liberty로 바꾸어야 할 수도 있습니다. 서두르지 말고 모니터링과 로깅에 적합한 인프라를 설정하십시오. Bluemix상의 Monitoring and Analytics 서비스나 타사 서비스인 New Relic 을 사용할 수 있습니다. 무엇이 되었건 서비스가 어떻게 사용되고 그 성능은 어떤지 추적하기 위해서는 한가지 방법으로 표준화 하는 것이 좋습니다
Bluemix의 Monitoring and Analytics
앱의 성능과 상태에 대한 가시성을 확보할 수 있습니다. 코드의 각 행단위 진단과 내재된 분석은 문제를 빨리 발견하고 해결할 수 있도록 지원합니다.
Overview | Usage details
3단계: 마이크로서비스 (Microservices)
서비스를 어떻게 배포하는지 뿐 아니라 어떻게 구축할지를 해결해야만 전체 마이크로서비스 아키텍쳐가 완성됩니다. 본 단계에서는 지속적인 통합과 배포 (CI/CD) 파이프라인을 각 서비스에 대해 독립적으로 갖춥니다. IBM Devops 서비스인 Delivery Pipeline 같은 도구가 이 과정을 지원합니다.
Bluemix의 Delivery Pipeline
앱의 구축, 테스트 및 배포를 자동화합니다.
Overview | Usage details
이 시점에서 마이크로서비스의 독립적 확장성에 대해 생각해 볼 수 있습니다. Bluemix 컨테이너 서비스인 Container Groups나 Auto-Scaling 서비스가 도움이 될 것입니다. 자동 확장 (Auto-Scaling)은 미리 정해놓은 확장 정책에 따라 애플리케이션의 인스턴스가 동적으로 조정되는 것을 말합니다.
Bluemix의 컨테이너 서비스 및 자동 확장 (Auto-Scaling) 서비스
확장성과 신뢰성이 필요한 앱은 IBM Containers를 사용해 컨테이너를 생성하거나 Auto-Scaling을 통해 동적 확장을 합니다.
IBM Containers | Auto-Scaling
4단계: 대규모 마이크로서비스
마지막 단계는 완전히 확장된 마이크로서비스입니다. 많은 경우 이 단계는 수행할 필요 자체가 없습니다. 제 경험으로 보면 많은 프로젝트는 많지 않은, 보통 10개 미만의 마이크로서비스로 구성됩니다.
이 단계는 서비스를 찾는 방법, 즉 어떻게 서비스를 검색하고 라우팅 규칙은 어떻게 설정하는가 하는 부분을 다룹니다. Bluemix의 Service Discovery 서비스를 활용할 수 있습니다. Service Discovery를 사용하면 마이크로서비스를 하드코딩된 네트워크 주소가 아닌 논리적 이름으로 찾을 수 있으며, 비정상적인 마이크로서비스를 자동으로 제거할 수 있습니다.
Bluemix의 Service Discovery
마이크로서비스의 동적 등록 및 검색을 지원합니다.
Overview | Usage details
또한 Bluemix의 Active Deploy처럼 좀 더 고급의 확장 및 배포 옵션을 사용할 수 있습니다.
Bluemix의 Active Deploy
다운타임이 없이 신규 소프트웨어를 배포하고, 구동되고 있는 앱이나 컨테이너 그룹을 업데이트합니다. 문제가 있을 경우 기존 버전으로 빠르게 되돌아 갈 수 있습니다.
Overview | Usage details
마지막으로 다운스트림 서비스에 문제가 생겼을 경우 어떤 일이 발생할 수 있는 지 생각해 봐야 합니다. 이런 경우 Netflix Hystrix 같은 것을 Bluemix의 IBM Container에 실행할 수 있습니다.
결론
현재의 앱에서 마이크로서비스까지 가는 로드맵을 살펴보았으며, 여러분도 이 여정을 시작할 수 있습니다. 각 단계는 다른 단계를 기반으로 구축이 되며, 필요하다면 마지막 단계까지 도달하지 않았더라도 거기서 멈추면 됩니다.
다만 제가 저번 글에서 언급한 경고를 기억하시기 바랍니다. 단지 있어보이려고 마이크로서비스를 도입하는 것은 안됩니다. 해결하고자 하는 문제가 마이크로서비스 아키텍쳐랑 잘 맞아야 합니다. 그리고 앱에 비지니스 가치를 높여주는 전체 프로세스의 일환으로 마이크로서비스를 도입해야 합니다
관련 문서
- All parts in the “Refactoring to microservices” series
- Microservices in action, Part 1: Introduction to microservices
- Microservices in action, Part 2: Containers and microservices — a perfect pair
- Microservices TV on developerWorks
- Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Approach (IBM Redbooks®)
[출처] https://developer.ibm.com/kr/cloud/bluemix/2016/05/23/cl-refactor-microservices-bluemix-trs-3/
