Microservices 채택: 구현 시작하기

조직이 애플리케이션과 웹사이트를 구축할 때 Microservices 를 채택하고 4계층 아키텍처를 사용해야 하는 이유에 대해 많이 이야기해 왔습니다. Microservices를 통해 아키텍트, 개발자, 엔지니어는 분산된 환경과 디바이스 전반에서 새로운 애플리케이션 기능과 더 나은 성능에 대한 수요에 발맞출 수 있습니다. Microservices는 독립적이고 유연하며 복원력이 뛰어나고 배포가 용이하며 조직적으로 통합되고 쉽게 구성할 수 있는 기술을 제공합니다.

목차

1. Microservices의 설계, 개발 및 채택에 대한 참고 자료
2. Microservices 프로세스 및 도구
2-1. Open Source 소프트웨어
2-2. 외부 및 내부 통신 프로토콜
 2-3. 데이터 저장소
2-4. 모니터링
2-5. 지속적 배포 및 DevOps
2-6. Microservices 결론

1. Microservices 의 설계, 개발 및 채택에 대한 참고 자료

Microservices 아키텍처의 구현에 대해 이야기하기 전에 유용하다고 생각한 몇 가지 참고 서적을 공유하고자 합니다. 이 책들은 특별히 ‘Microservices’에 관한 책은 아니지만, Microservices 아키텍처의 핵심 구성 요소인 설계 및 개발 프로세스와 최신 애플리케이션 개발에 대한 접근 방식을 설명합니다.

  • Enterprise Integration Patterns: Messaging 솔루션 설계, 구축 및 배포
    by Gregor Hohpe, Bobby Woolf
    이 책은 애플리케이션을 배포하고 지속적으로 통합하기 위한 시스템을 계획하고 설계하는 모범 사례를 살펴봅니다. 저자는 기술 어휘와 가시적인 표기법 프레임워크를 사용하여 JMS, MSMQ, TIBCO ActiveEnterprise, Microsoft BizTalk, SOAP, XSL을 비롯한 다양한 기술 전반에 걸친 대규모 통합 솔루션을 설명합니다.
  • The Modern Firm: Organizational Design for Performance and Growth
    by John Roberts
    이 책은 Microservices 지향 애플리케이션 개발 프로세스에 가장 적합한 비즈니스 및 팀 구조에 초점을 맞춘다는 점에서 다른 책과 차별화됩니다. 이 책은 성과와 성장에 기여하는 루틴, 프로세스 및 기업 문화를 탐구합니다.
  • Release It! Design and Deploy Production-Ready Software
    by Michael T. Nygard
    기업이 직면하는 가장 큰 어려움 중 하나는 새로운 기능이나 제품을 배포하기까지 너무 오래 기다린다는 것입니다. 이 책은 Microservices 및 지속적 통합(CI)과 같은 최신 모범 사례를 사용하여 새로운 코드와 디자인을 Production에 사용할 준비가 되면 릴리스하는 개념을 설명합니다.

2. Microservices 프로세스 및 도구

핵심 Microservices는 전체 애플리케이션 개발 및 제공 아키텍처의 일부일 뿐입니다. 또한 서비스 간 통신, 트래픽 모니터링, 장애 탐지 및 기타 기능을 위한 도구도 선택해야 합니다. 다음은 Microservices 환경으로 전환하는 데 도움이 될 수 있는 몇 가지 유형의 소프트웨어와 특정 도구입니다.

2-1. Open Source 소프트웨어

Microservices 기반 애플리케이션을 구축하는 경우, 최고의 코드 대부분이 Open Source라는 것을 알게 될 것입니다. 이러한 코드의 대부분은 Google, LinkedIn, Netflix, Twitter와 같이 최고 수준의 기술 인력을 보유한 회사에서 작성했거나 상당한 확장 또는 기여를 하고 있습니다. 이러한 회사의 특성상 이러한 프로젝트는 일반적으로 유연성과 확장성을 염두에 두고 구축됩니다. 이 모든 것이 소프트웨어 개발 환경을 하드웨어는 말할 것도 없고 소프트웨어 구매에만 대규모 팀과 많은 돈이 필요했던 10년 또는 15년 전과는 매우 다르게 만듭니다. 구매 주기가 길어지거나 공급업체가 필요한 기능을 통합할 때까지 기다릴 필요가 없습니다. 소프트웨어를 직접 변경하고 확장할 수 있습니다.

2-2. 외부 및 내부 통신 프로토콜

API로 많은 Microservices를 구축할 것이므로, 처음부터 API가 어떻게 소비될 것인지 고려해야 합니다. Edge 및 Public 서비스에 액세스할 때, 사람들은 종종 JSON을 허용하고 JavaScript 또는 Python과 같은 다른 언어를 사용하여 API를 소비하고 상호 작용할 수 있는 브라우저를 사용합니다. XML은 JSON을 대신할 수 있지만 처리하기가 더 어렵고 따라서 무게가 더 무겁습니다. 어쨌든 Edge 및 Public 서비스의 경우 객체에 통신 프로토콜이 있는 안정적인 API가 필요합니다.

그러나 애플리케이션 컨텍스트 내에서 Microservices 간의 고속 통신을 위해서는 JSON이나 XML 모두 충분히 효율적이지 않습니다. 이 경우 보다 압축된 Binary 인코딩 데이터가 필요합니다. 일반적으로 사용되는 도구로는 Google의 Protocol Buffers와 Apache의 Thrift 및 Avro가 있습니다. 더 새로운 프로토콜은 Real Logic Limited의 Simple Binary Encoding으로, 프로토콜 버퍼보다 약 20배 빠른 것으로 알려져 있습니다.

Binary 인코딩을 사용한다는 것은 Microservices API를 사용하기 위한 라이브러리가 있어야 한다는 것을 의미합니다. API가 이미 자체적으로 설명되어 있다고 생각하기 때문에 라이브러리를 직접 작성하고 싶지 않을 수도 있습니다. 하지만 라이브러리를 직접 작성하는 사람(예: 소비 애플리케이션 개발자)은 일반적으로 Microservices를 개발자만큼 잘 이해하지 못하며 오류 처리와 같은 작업을 올바르게 수행할 가능성이 낮다는 점이 위험합니다. 결국 자신이 작성하지 않은 라이브러리를 채택하고 유지 관리하도록 권장 받게 됩니다.

2-3. 데이터 저장소

현재 애플리케이션 뒤에 Monolithic 데이터 저장소가 있는 경우, Microservices로 전환할 때 이를 분할해야 합니다. 한 가지 지침은 데이터베이스 리팩토링입니다. Refactoring Database: Evolutionary Database Design(Scott W. Ambler, Pramod J. Sadalage)을 참고하세요. SchemaSpy를 사용하여 스키마를 분석하고 분리할 수 있습니다. 목표는 각 Microservices에 대해 Microservices에 필요한 테이블의 구체화된 보기를 한 번에 하나씩 결정하고, 이를 결합된 데이터베이스에서 Microservices 별 데이터 저장소로 전송하는 것입니다. Monolithic 데이터베이스가 각각 하나의 서비스에서만 액세스하는 별개의 데이터 집합으로 밝혀지는 경우가 많기 때문에 이 작업이 예상대로 항상 어려운 것은 아닙니다. 이 경우 데이터베이스를 분할하는 것은 매우 쉬우며 점진적으로 분할할 수 있습니다.

또한 시간이 지남에 따라 데이터베이스를 점진적으로 분할할 수도 있는데, 이를 Polyglot 지속성이라고 합니다. 이를 위한 한 가지 도구는 staash(storage tier as a service, STaaS의 의미)라는 Netflix OSS 프로젝트입니다. 이 프로젝트는 Frontend에 RESTful API를 제공하고 Cassandra 및 mySQL 데이터베이스와 모두 통신하는 Java 애플리케이션입니다. 따라서 데이터 액세스 계층을 개발하기 위한 표준 프로토타입 라이브러리로 사용할 수 있습니다. Backend에 새 데이터베이스를 추가하고 Frontend에 새 HTTP를 추가할 수 있으며, mySQL 및 Cassandra 기능과 필요한 모든 구성 요소들이 이미 통합되어 있는 단일 패키지로 staash를 사용할 수 있습니다.

분산 데이터 저장소의 일관성 문제가 걱정된다면, 분산 시스템이 네트워크 파티션에 얼마나 잘 반응하는지 테스트하는 표준 방법이 되고 있는 Kyle Kingsbury의 Jepsen 테스트에 대해 알아보세요. 대부분의 분산 데이터베이스는 테스트에 실패하고 흥미로운 오류가 발견됩니다. 이 테스트는 일반적이지만 실제로는 올바르지 않은 관행을 식별하고 제거하는 데 도움이 될 수 있습니다.

2-4. 모니터링

Microservices 배포를 모니터링하는 것은 서비스 구성이 매우 빠르게 변화하기 때문에 어렵습니다. 새로운 서비스가 계속 추가되고, 수집해야 할 새로운 지표가 추가되고, 새 버전이 배포되고, 서비스 인스턴스가 확장 및 축소되는 등의 일이 계속 발생합니다. 이러한 환경에서는 자동화된 임계값 분석 도구가 ‘정상’ 트래픽의 모습을 파악할 수 있는 기준 데이터가 충분하지 않습니다. 특히 이전에 본 적이 없는 새로운 Microservices를 시작할 때 이 도구는 많은 허위 경보를 생성하는 경향이 있습니다. 문제는 변경이 너무 빈번하여 모든 것이 항상 비정상적으로 보이는 환경에서 상태 변화에 적절하게 반응하는 시스템을 구축하는 것입니다.

Microservices 아키텍처에는 서비스가 통신할 때 복잡한 패턴의 원격 호출도 포함됩니다. 따라서 요청 흐름의 End to End 추적이 더 어려워지지만 추적 데이터는 문제를 진단하는 데 필수적입니다. A 프로세스가 B를 호출하고, B가 C를 호출하는 등의 과정을 추적할 수 있어야 합니다. 이를 위한 한 가지 방법은 전역 고유 식별자(GUID)와 트랜잭션 ID로 HTTP 헤더를 측정하는 것입니다.

2-5. 지속적 배포 및 DevOps

Microservices 아키텍처에서는 작은 소프트웨어 변경 사항을 매우 자주 배포하게 됩니다. 시스템을 중단시킬 가능성이 가장 높은 변경 사항은 새 코드를 배포하는 것이 아니라 테스트 중에 해당 기능을 사용하던 제한된 수의 클라이언트가 아닌 모든 클라이언트를 대상으로 기능을 켜는 것입니다. 예를 들어, 어떤 기능으로 인해 약간의 성능 저하가 발생하는 경우 테스트 중에는 악영향을 느끼지 못할 수 있지만, 약간의 지연이 모든 클라이언트에 확대 적용되면 갑자기 시스템이 다운될 수 있습니다. 이러한 상황에 대처하려면 문제를 신속하게 감지하고 이전 구성으로 Roll Back해야 합니다.

문제를 빠르게 감지하기 위해 일반적으로 1~5분 간격이 아닌 5~10초 간격으로 상태 확인을 실행할 수 있습니다. 1분에 한 번씩 측정하는 빈도로 보면 지표에 나타난 변화가 실제로 문제를 나타내는지 확인하기까지 5분이 걸릴 수 있습니다. 자주 측정해야 하는 또 다른 이유는 대부분의 사람들이 집중력이 짧기 때문입니다. 최근 연구에 따르면 주의가 산만해지기 전 사람들의 평균 집중 시간은 8초로, 2000년의 12초에서 감소한 것으로 나타났습니다. 요점은 사람들이 이벤트에 적시에 대응하기 위해서는 이벤트 발생과 보고 사이의 지연 시간이 평균 집중 시간보다 짧아야 한다는 것입니다. 반면 집중 시간이 짧다는 장점은 10초 동안의 서비스 중단도 사용자가 알아차릴 가능성이 적다는 것입니다.

작동 중인 구성으로 쉽게 Roll Back하려면 기능을 활성화하기 전에 이전 구성을 중앙 위치에 기록해 두세요. 이렇게 하면 누구나 필요한 경우 작동 중인 코드로 되돌릴 수 있습니다.

2-6. Microservices 결론

Microservices를 도입하려면 코드 베이스는 물론 조직의 문화와 구조에도 큰 변화가 필요합니다. 이 포스트에서는 외부 및 내부 커뮤니케이션 프로토콜, Open Source 소프트웨어, 데이터 스토리지, 모니터링, 지속적 배포 및 DevOps에 대한 몇 가지 제안 사항과 모범 사례를 공유했습니다. 아직 Microservices 아키텍처로의 전환을 시작하지 않았다면 지금이 바로 시작해야 할 때입니다. 전환은 점진적으로 이루어질 수 있으며 하룻밤 사이에 이루어질 필요는 없다는 점을 기억하세요.

NGINX Plus를 사용해 Microservices로의 전환에 박차를 가해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.