60년대와 70년대에는 모놀리식 아키텍처 모든 기능을 하나의 응집력 있는 단위로 결합해야 하는 제한된 컴퓨팅 리소스로 인해 애플리케이션 개발에 선호되었습니다.
특히 인터넷과 분산 시스템의 등장으로 점점 커지는 애플리케이션의 규모와 복잡성에 비해 모놀리식 구조가 너무 제한되기 시작한 90년대 후반과 2000년대까지였습니다.
이로 인해 다음과 같은 보다 모듈화된 접근 방식이 개발되었습니다. 서비스 지향 아키텍처(SOA) 그리고 나중에, 마이크로서비스 아키텍처(MSA), 이는 결국 2010년대 초반에 두드러지게 나타났습니다.
즉, 이는 마이크로서비스의 기본 개념과 사용법에 대한 간략한 설명일 뿐입니다. 이제 마이크로서비스가 모놀리식 아키텍처를 대체하는 방법, 마이크로서비스의 작동 방식 및 마이크로서비스의 몇 가지 예에 대해 논의해 보겠습니다. 그런 다음 마이크로서비스 배포의 주요 측면과 마이크로서비스를 배포하려는 경우 수행할 작업에 대해 논의하겠습니다.
마이크로서비스란 무엇입니까? 어떻게 작동하나요?
앞서 언급했듯이 마이크로서비스는 애플리케이션 복잡성과 크기를 증가시키는 솔루션으로 등장하여 기업이 기능을 독립적으로 배포할 수 있는 서비스로 나눌 수 있게 해줍니다.
"마이크로서비스"라는 용어는 마틴 파울러(Martin Fowler) 및 제임스 루이스(James Lewis)와 같은 업계 전문가에 의해 대중화되었으며, 이들은 2014년 블로그 게시물을 통해 공식적으로 이를 소개했습니다. 그들의 작업은 독립적으로 배포 가능한 서비스, 분산형 데이터 관리 및 기술 불가지론의 필요성을 포함한 주요 원칙과 특성을 정의했습니다.
그 이후로 마이크로서비스는 주요 아키텍처 선택이 되었으며, Docker와 같은 컨테이너화 기술, Kubernetes와 같은 오케스트레이션 도구, 서버리스 컴퓨팅 플랫폼 등이 있습니다. 그렇다면 마이크로서비스는 어떻게 작동할까요?
마이크로서비스는 어떻게 작동하나요?
마이크로서비스 아키텍처의 핵심은 대규모 애플리케이션을 각각 특정 비즈니스 기능을 담당하는 더 작고 별개의 서비스로 분할하는 것입니다. 이러한 서비스는 종종 REST API, gRPC 또는 RabbitMQ나 Apache Kafka와 같은 메시지 브로커를 통해 네트워크를 통해 서로 통신합니다.
Martin Fowler와 James Lewis의 정의에 따르면 마이크로서비스에는 모두 다음과 같은 네 가지 주요 특성이 있습니다.
- 단일 책임: 각 마이크로서비스는 특정 작업이나 기능을 수행하도록 설계되어 전문화가 가능하고 복잡성이 줄어듭니다.
- 독립: 마이크로서비스는 서로 독립적으로 개발, 배포 및 확장될 수 있으므로 유연성과 탄력성을 제공합니다.
- 분산형 데이터 관리: 마이크로서비스에는 중앙 집중식 단일 데이터베이스가 필요하지 않은 자체 데이터베이스가 있는 경우가 많습니다.
- 기술 불가지론: 팀은 다른 서비스 선택에 얽매이지 않고 각 서비스에 가장 적합한 기술을 선택할 수 있습니다.
이 접근 방식은 모든 애플리케이션 구성 요소가 하나의 응집력 있는 단위로 긴밀하게 통합되는 기존의 모놀리식 아키텍처와 대조됩니다.
마이크로서비스 배포의 주요 단계
마이크로서비스 아키텍처는 높은 확장성, 유연성, 효율성, 오류 격리 등과 같은 수많은 이점을 제공하지만 마이크로서비스를 효과적으로 배포하는 방법을 알고 성공하려면 상당한 계획이 필요합니다.
그렇기 때문에 마이크로서비스 배포 시 주요 개념, 단계 및 마이크로서비스 모범 사례에 대한 포괄적인 아이디어를 갖는 것이 성공적인 마이크로서비스 아키텍처에 필수적입니다. 이제 마이크로서비스 배포의 주요 단계와 각 단계에 수반되는 내용을 살펴보겠습니다.
마이크로서비스 배포 계획 및 준비
모든 좋은 일에는 계획과 인내심이 필요하며, 마이크로서비스를 성공적으로 배포하려면 상당한 계획과 인내심이 필요합니다. 그렇기 때문에 마이크로서비스 모범 사례를 따르고 마이크로서비스를 배포할 때 필요한 모든 것을 계획하고 준비하는 것이 중요합니다.
앞서 언급했듯이 마이크로서비스의 주요 원칙과 특징 중 하나는 단일 책임 원칙. 이 원칙에 충실하고 각 마이크로서비스가 하나의 기능과 기능에 집중하고 책임을 지도록 하면 팀이 독립적으로 서비스를 개발, 배포 및 확장할 수 있습니다.
또한 이 원칙의 하위 범주는 다음과 같습니다. 느슨한 결합 설계 원리. 즉, 각 서비스는 통신을 위해 독립적으로 작동할 수 있으며 다른 서비스에 최소한으로 종속됩니다. 결과적으로, 한 서비스에 대한 변경이나 업데이트가 다른 서비스에 영향을 주지 않고 독립적인 마이크로서비스 확장이 가능해집니다.
이렇게 하면 시스템의 한 부분에서 발생한 문제나 오류가 연쇄 반응을 유발하여 시스템 전체에 오류가 발생하고 전체 서비스가 중단되는 계단식 오류의 위험이 줄어듭니다.
중요한 마이크로서비스 방식 중 하나는 느슨한 결합 설계 원칙의 확장으로 마이크로서비스를 배포할 때 각 서비스에 대한 전용 데이터 스토리지를 갖는 것입니다. 이렇게 하면 충돌을 방지하고 더 나은 서비스 확장성을 얻을 수 있습니다.
또한 모든 서비스가 직접적인 종속성 없이 통신할 수 있도록 하려면 메시지 브로커와 같은 비동기식 마이크로서비스 통신 패턴이 필요합니다.
퍼즐의 마지막 조각은 마이크로서비스를 위한 CI/CD(지속적 통합 및 지속적 전달) 파이프라인을 구현하는 것입니다. 이러한 파이프라인을 통해 팀은 다음을 통해 새로운 기능이나 수정 사항을 배포할 수 있습니다. CI/CD 도구 Jenkins 및 GitLab과 같이 조직은 새로운 기능을 자주 출시하면서 시스템 안정성을 유지할 수 있습니다.
이제 마이크로서비스 배포에 필요한 계획과 준비에 대한 전반적인 아이디어를 얻었으므로 마이크로서비스 배포 전략에 대해 이야기해 보겠습니다.
마이크로서비스 배포 전략
마이크로서비스를 배포할 때 배포 전략 선택은 서비스 기능, 트래픽, 인프라 설정, 팀 전문 지식 및 비용 고려 사항에 따라 달라집니다. 그러나 일반적으로 마이크로서비스 배포 전략은 다음과 같습니다.
- 컨테이너당 서비스 인스턴스: 이 접근 방식에서 각 마이크로서비스는 자체 컨테이너에서 실행되므로 호스트 모델당 여러 인스턴스보다 더 나은 격리를 제공합니다. 컨테이너는 손쉬운 확장을 촉진하고 리소스 할당을 개선합니다.
- 가상 머신당 서비스 인스턴스: 각 서비스는 별도의 가상 머신(VM)에서 실행되므로 컨테이너보다 훨씬 더 강력한 격리 기능을 제공합니다. 이렇게 하면 보안과 안정성이 향상되지만 일반적으로 더 많은 오버헤드가 발생합니다.
- 단계적 출시: 처음에는 소규모 사용자 하위 집합에 마이크로서비스 버전을 배포하여 전체 출시 전에 안정성을 테스트합니다. 이 접근 방식은 문제가 발생할 경우 영향을 최소화하고 빠른 롤백을 허용하여 시스템 무결성을 유지합니다.
- 블루-그린 배포: 이 방법은 두 개의 동일한 프로덕션 환경을 사용합니다. 한 환경은 라이브 트래픽을 제공하고 다른 환경은 다음 릴리스 테스트에 사용됩니다. 블루-그린 배포를 통해 두 환경 간에 트래픽을 원활하게 전환할 수 있으므로 간편한 롤백과 가동 중지 시간 없는 업데이트가 가능합니다.
- 단계적 릴리스: 이 전략에는 다양한 사용자 세그먼트 또는 환경에 대한 업데이트를 점진적으로 출시하는 것이 포함됩니다. 생산에 이르기 전에 내부 환경에서 시작하여 잠재적인 문제의 폭발 반경을 제한하고 팀이 단계적으로 문제를 해결할 수 있도록 하는 경우가 많습니다.
- 서버리스 배포: 이 접근 방식은 확장 및 리소스 할당을 처리하여 인프라 관리를 자동화하는 AWS Fargate 및 Google Cloud Run과 같은 서버리스 플랫폼을 활용합니다. 서버리스 배포를 사용하면 기본 서버를 관리할 필요가 없으므로 마이크로서비스 자체에 집중할 수 있습니다.
마이크로서비스를 배포하기 위해 위의 마이크로서비스 중 하나를 선택했다면 마이크로서비스 조정 도구가 필요합니다.
마이크로서비스 오케스트레이션
다양한 마이크로서비스 배포 전략 중 하나를 선택한 후에는 마이크로서비스 오케스트레이션을 위한 일종의 지휘자가 필요합니다. 다음과 같은 마이크로서비스 오케스트레이션 도구 쿠버네티스, 마이크로서비스 배포, 마이크로서비스 확장, 마이크로서비스 모니터링, 컨테이너화된 마이크로서비스 관리를 자동화하는 데 도움이 됩니다.
예를 들어 Airbnb는 Kubernetes를 사용하여 엔지니어가 수동 감독 없이 수백 가지 변경 사항을 마이크로서비스에 배포할 수 있도록 합니다. Kubernetes와 같은 마이크로서비스 오케스트레이션 도구의 중요한 기능 중 하나는 내장된 로드 밸런싱입니다.
유능한 로드 밸런싱 기능을 사용하면 들어오는 트래픽을 마이크로서비스의 여러 인스턴스에 분산하는 데 도움이 됩니다. 이를 통해 단일 인스턴스가 병목 현상을 일으키는 것을 방지하고 수요 급증을 처리하는 시스템의 능력을 향상시킵니다.
Kubernetes는 실패한 컨테이너가 자동으로 교체되고 다시 시작되는 자가 복구 기능을 통해 마이크로서비스를 관리하는 데 중요한 역할을 합니다. New York Times는 이 기능을 활용하여 사용자 경험에 영향을 미치거나 가동 중지 시간을 겪지 않고 마이크로서비스를 유지합니다.
또한 Kubernetes는 ConfigMap 및 Secret을 사용하여 데이터베이스 자격 증명이나 API 키와 같은 구성 및 비밀로 마이크로서비스 보안을 향상합니다. 이는 민감한 고객 및 사용자 정보를 다루는 Uber와 같은 회사 및 서비스에 특히 중요합니다.
마지막으로, Kubernetes와 같은 마이크로서비스 조정 도구는 단계적 릴리스와 같은 롤링 업데이트 및 롤백을 포함하는 마이크로서비스 전략에 특히 유용합니다. 롤링 업데이트를 사용하면 이전 버전의 일부 인스턴스를 계속 실행하여 서비스 중단 없이 새로운 마이크로서비스 버전을 배포할 수 있습니다.
마이크로서비스 조정 도구를 설정한 후에는 구축하고 자동화해야 합니다. CI/CD 파이프라인 마이크로서비스 배포를 위한 것입니다.
마이크로서비스 배포를 위한 CI/CD 파이프라인
앞서 설명한 것처럼 마이크로서비스를 위한 지속적 통합 및 지속적 전달 파이프라인은 마이크로서비스 배포의 중요한 측면입니다. CI/CD 파이프라인의 CD 파이프라인은 CI/CD 파이프라인의 테스트 및 통합 단계를 통과하자마자 코드 변경 사항을 프로덕션에 자동으로 배포하는 역할을 합니다.
그런 다음 CI/CD 파이프라인의 CD 부분이 작동하여 코드 변경이 테스트 및 통합 단계를 통과할 때마다 서비스가 Kubernetes 클러스터와 같은 마이크로서비스 조정 도구에 배포됩니다.
또한 단위 테스트, 통합 테스트 및 엔드투엔드 테스트가 파이프라인에 통합되므로 테스트 및 통합 단계는 모두 CI/CD 파이프라인에 의해 자동으로 수행됩니다.
이를 통해 팀은 시스템 안정성을 유지하면서 각 단계에서 업데이트를 검증할 수 있습니다. 또한 다양한 테스트에도 불구하고 코드 변경에 문제가 있는 경우 자동 롤백을 통해 이전 안정 버전으로 되돌릴 수 있습니다.
마지막으로, 마이크로서비스 모범 사례에 따라 마이크로서비스용 CI/CD 파이프라인을 구현하면 조직이 더 빠르게 개발하고, 수동 오류를 줄이고, 고품질 표준을 유지하는 데 도움이 됩니다.
Spotify, Expedia, iRobot, Lufthansa, Pandora 등과 같은 많은 회사에서는 CircleCI, AWS CodePipeline 및 GitLab과 같은 CI/CD 도구를 통해 마이크로서비스용 CI/CD 파이프라인을 사용하여 배포 프로세스를 자동화하고 일관된 코드 품질을 보장하며 시스템 안정성을 유지하면서 새로운 기능을 신속하게 제공합니다.
마이크로서비스 통신 패턴
마이크로서비스가 서로 통신하는 방식은 마이크로서비스의 기능, 전체 아키텍처, 원하는 확장성 및 안정성에 전적으로 의존합니다. 일반적으로 두 가지 주요 종류의 마이크로서비스 통신 패턴이 사용됩니다. 동기식 그리고 비동기식 마이크로서비스 통신 패턴.
동기식 마이크로서비스 통신 패턴에서 서비스는 실시간으로 상호 작용합니다. 즉, 서비스가 요청을 보내고 진행하기 전에 응답을 기다립니다. 가장 일반적으로 사용되는 동기식 마이크로서비스 통신 패턴은 다음과 같습니다. REST(표현 상태 전송) API, gRPC(Google 원격 프로시저 호출), 그리고 GraphQL.
일반적으로 이러한 종류의 마이크로서비스 통신 패턴은 실시간 데이터 처리와 즉각적인 응답이 필요한 산업 및 기업에서 사용됩니다. 금융, 의료, 전자상거래와 같은 산업에서는 동기식 통신 패턴을 사용하여 트랜잭션, 데이터 검색 또는 상호 작용이 즉각적으로 이루어지도록 하고 원활하고 응답성이 뛰어난 사용자 경험을 유지하는 경우가 많습니다.
즉, 동기식 마이크로서비스 통신 패턴은 실시간 응답 및 단순성과 같은 이점을 제공하지만 긴밀한 결합으로 인한 잠재적인 병목 현상, 높은 부하에서 낮은 확장성, 느린 응답 시간, 트래픽이 많은 인스턴스에서 높은 대기 시간과 같은 특정 단점도 있습니다.
반면, 비동기식 마이크로서비스 통신 패턴은 앞에서 논의한 느슨한 결합 원칙을 기반으로 하기 때문에 일반적으로 마이크로서비스에 더 적합합니다.
이러한 유형의 마이크로서비스 통신 패턴은 Kafka 또는 RabbitMQ와 같은 브로커를 통해 메시지를 보내고 받을 수 있도록 하여 서비스를 분리합니다. 버퍼 역할을 하는 큐에 메시지를 보내면 서비스는 동기식 통신 패턴에서처럼 응답을 기다리지 않고 독립적으로 통신합니다. 이 버퍼를 사용하면 다른 서비스에서 원하는 속도로 메시지를 처리할 수 있으므로 발신자가 수신자를 기다리지 않고 작업을 계속할 수 있습니다.
비동기식 마이크로서비스 통신 패턴은 마이크로서비스 배포를 위한 분리된 구조를 제공할 뿐만 아니라 동기식 마이크로서비스 통신 패턴이 제공하는 것과 동일한 실시간 응답도 제공합니다.
이는 특정 작업이 발생할 때 서비스가 이벤트를 내보내 통신하기 때문에 비동기 이벤트 기반 마이크로서비스 통신 패턴의 이벤트 기반 아키텍처 때문입니다. 다른 서비스는 이러한 이벤트를 구독하고 그에 따라 반응할 수 있습니다. 이를 통해 서비스 간 직접적인 결합 없이 실시간으로 변화에 반응하는 응답성이 뛰어난 시스템이 가능합니다.
게다가 비동기식으로 게시-구독(Pub/Sub) 마이크로서비스 통신 패턴에 따라 서비스(게시자)는 주제에 메시지를 보내고 다른 서비스(구독자)는 해당 주제를 수신하여 업데이트를 받습니다. 이 모델은 여러 서비스에 동시에 메시지를 브로드캐스팅하는 여러 가입자를 지원합니다.
마지막으로 이벤트 중심 패턴과 유사하게 비동기식 안무 기반 사가 마이크로서비스 통신 패턴은 이벤트를 사용하여 서로 통신하기도 합니다. 그러나 이 패턴에서는 특정 순서가 적용됩니다. 즉, 이벤트가 다음 단계와 특정 서비스 활성화를 트리거한다는 의미입니다.
여기서 차이점은 이벤트 중심 패턴에는 특정 순서나 작업 흐름이 없으며, 안무 기반 사가 패턴에서는 특정 프로세스와 순서가 아닌 여러 서비스가 이벤트에 반응할 수 있다는 것입니다.
사용하는 비동기식 마이크로서비스 통신 패턴 유형은 마이크로서비스의 작업과 전반적인 기능에 따라 다릅니다. RabbitMQ 및 Amazon SQS와 같은 메시지 대기열은 일반적으로 주문 처리 및 알림 시스템을 위한 작업 예약, 작업 부하 분산, 전자 상거래에 사용됩니다.
Apache Kafka 및 AWS EventBridge와 같은 이벤트 중심 메시지 브로커는 일반적으로 대규모 이벤트 스트림을 실시간으로 처리하고 금융 서비스 및 AWS 환경과 같은 영역의 마이크로서비스 간 이벤트 라우팅에 사용됩니다.
Google Cloud Pub/Sub 및 Redis Streams와 같은 게시-구독(Pub/Sub) 메시지 브로커의 경우 이러한 메시지 브로커는 일반적으로 실시간 분석, 이벤트 수집, 실시간 알림 및 채팅 애플리케이션을 위해 분산 시스템 전반에서 확장 가능한 메시징에 사용됩니다.
마지막으로 안무 기반 사가 메시지 브로커는 주로 전자 상거래 주문 처리, 여행 예약 시스템 및 중앙 제어 없이 여러 서비스에서 복잡하고 다단계 트랜잭션을 조정해야 하는 사용 사례에 사용됩니다.
마이크로서비스 서비스 검색
요구 사항에 맞는 통신 패턴을 설정하고 구현한 후에는 먼저 서비스가 서로를 찾을 수 있는지 확인해야 합니다. 앞서 언급했듯이 Kubernetes와 같은 마이크로서비스 조정 도구는 마이크로서비스 검색에서 중요한 역할을 합니다.
이는 Kubernetes DNS가 제공하는 내장 서비스 검색을 통해 수행됩니다. 이는 서비스가 클러스터 내에서 위치를 확장하거나 변경함에 따라 IP 주소와 DNS 레코드를 동적으로 업데이트합니다.
라우팅 책임이 로드 밸런서에 위임되고 로드 밸런서가 레지스트리를 쿼리하고 트래픽을 적절한 인스턴스로 전달하므로 이 마이크로서비스 서비스 검색 방법을 서버 측 검색이라고 합니다.
반면, 서비스 또는 API 게이트웨이가 Consul 또는 Eureka와 같은 서비스 레지스트리를 쿼리하여 사용 가능한 인스턴스를 찾는 마이크로서비스 서비스 검색을 위한 클라이언트 측 검색 방법도 있습니다.
마이크로서비스 배포에 가장 적합한 서비스 검색 방법을 선택하는 것은 시스템 요구 사항과 규모에 따라 다릅니다.
클라이언트 측 마이크로서비스 서비스 검색을 통해 클라이언트는 통신하는 인스턴스를 완전히 제어할 수 있습니다. 이를 통해 더 많은 사용자 정의가 가능해질 뿐만 아니라 중앙 집중식 검색 서비스가 필요하지 않으므로 복잡성도 줄어듭니다.
예를 들어 Netflix의 마이크로서비스 배포에서는 로드 밸런싱을 위해 Eureka 및 Ribbon과 함께 클라이언트 측 마이크로서비스 서비스 검색을 사용하므로 클라이언트가 대기 시간 및 서버 로드와 같은 기준에 따라 최상의 인스턴스를 선택할 수 있습니다.
그러나 중앙 집중식 서비스 검색은 효율성을 향상시키고 분산 시스템 전체에서 일관된 로드 밸런싱을 허용하므로 서버 측 마이크로서비스 서비스 검색은 대규모 환경에 더 적합합니다.
Kubernetes, AWS Elastic Load Balancing 및 API 게이트웨이(Kong, NGINX 등)와 같은 서버 측 마이크로서비스 서비스 검색 솔루션은 트래픽을 효율적으로 라우팅하고 고가용성을 유지하는 데 도움이 되며 Airbnb, Pinterest, Expedia, Lyft 등과 같은 회사에서 사용됩니다.
마이크로서비스 보안
모놀리식 아키텍처는 대부분 MSA보다 열등하지만 모놀리식 아키텍처가 우위를 점한 한 가지 측면은 보안이었습니다. 마이크로서비스는 느슨한 결합 원리를 기반으로 구축되고 본질적으로 분산되므로 단일하고 일반적인 보안 조치를 구현할 수 없습니다.
각 서비스는 독립적으로 보호되어야 하기 때문에 마이크로서비스에서는 공격 표면이 훨씬 크기 때문에 추가적인 보호 조치가 필요합니다. 이를 위해 OAuth2 및 JWT(JSON Web Tokens)와 같은 표준이 일반적으로 인증 및 권한 부여에 사용됩니다.
또한 API 게이트웨이는 진입점에서 인증 및 권한 부여를 시행하므로 마이크로서비스 전반의 보안을 관리하는 데 자주 사용됩니다. 또한 게이트웨이 API는 속도 제한, 로깅 및 모니터링을 구현하여 추가적인 마이크로서비스 보안 계층을 제공할 수도 있습니다.
이는 주요 진입점을 보호하지만 서비스 간 통신을 처리하려면 더 많은 마이크로서비스 보안 조치가 필요합니다.
여기서 서비스 메시는 네트워크 마이크로서비스 보안 계층을 추가하고 서비스 간 트래픽을 암호화하며 상호 TLS와 같은 정책을 시행하는 역할을 합니다. 이러한 서버 메시는 기본적으로 마이크로서비스 보안을 크게 향상시키는 포괄적인 엔드투엔드 암호화를 설정합니다.
마이크로서비스 확장
MSA의 가장 큰 장점 중 하나이자 모놀리식 아키텍처를 대체하기 위해 개발된 이유는 바로 높은 확장성입니다. 일반적으로 마이크로서비스 확장은 수직 및 수평의 두 가지 방식으로 발생할 수 있습니다.
기본적으로 수직적 마이크로서비스 확장(확장)은 기존 인스턴스에 CPU나 메모리와 같은 리소스를 더 추가하는 것입니다. 또는 수평적 마이크로서비스 확장(수평 확장)을 통해 부하를 분산하고 용량을 늘립니다.
구현 측면에서 볼 때, 수직적 마이크로서비스 확장은 더 큰 서버로 업그레이드하거나, 클라우드 인스턴스에서 메모리 또는 처리 능력을 늘리거나, 더 많은 스토리지를 추가하여 단일 인스턴스를 수정하기만 하면 되기 때문에 둘 중 더 쉽습니다.
이러한 유형의 확장은 일반적으로 RAM 또는 CPU 성능을 높이면 쿼리 성능과 데이터 처리(예: 메모리 내 캐싱을 담당하는 서비스)를 향상시킬 수 있는 경우에 사용됩니다.
즉, 수직적 마이크로서비스 확장은 더 쉽고 즉각적인 성능 향상을 제공하지만 단점도 있습니다. 수직적 확장은 서버의 하드웨어 용량에 의해 제한되므로 수직적 확장을 계속하려면 어느 시점에서 수평적 확장으로 전환해야 합니다.
또한 하드웨어 및 대규모 인스턴스에는 일반적으로 가격이 높기 때문에 수직 확장에는 비용이 많이 듭니다. 마지막으로, 확장된 인스턴스에 장애가 발생하면 부하를 처리할 추가 인스턴스가 없기 때문에 서비스가 완전히 다운됩니다.
수평적 마이크로서비스 확장의 경우 단일 인스턴스의 리소스를 업그레이드하는 대신 해당 서비스의 새 인스턴스를 배포합니다. 이러한 인스턴스는 독립적으로 작동하지만 여전히 동일한 서비스와 동일한 워크로드의 일부를 처리합니다.
수직적 확장과 달리 수평적 마이크로서비스 확장은 무제한입니다. 즉, 증가하는 워크로드와 트래픽 급증을 처리하기 위해 원하는 만큼 많은 인스턴스를 추가할 수 있어 더 큰 확장성을 제공할 수 있습니다.
게다가 인스턴스가 여러 개 있으므로 하나가 다운되면 다른 인스턴스가 요청을 계속 처리할 수 있으므로 모든 계란을 한 바구니에 담는 것이 아닙니다. 마지막으로, 수평적 확장은 더 작고 저렴한 여러 인스턴스를 사용하여 더 안정적이고 강력한 성능을 형성할 수 있으므로 장기적으로 훨씬 더 비용 효율적입니다.
즉, 수평적 확장과 더 많은 인스턴스 추가에는 더 많은 로드 밸런서, 마이크로서비스 서비스 검색 메커니즘 및 마이크로서비스 조정 도구가 필요하므로 마이크로서비스 아키텍처가 훨씬 더 복잡해집니다.
수평적 확장은 웹 서비스, 전자상거래나 소셜 미디어 플랫폼과 같은 애플리케이션과 같은 사용 사례에 더 적합하며, 트래픽 변동이 심하고 요청량이 많은 경우가 많습니다.
즉, 두 유형의 확장 모두 마이크로서비스에서 지원되고 많은 경우에 필요하기 때문에 실제로는 둘 중 하나의 경우가 아닙니다. 일반적으로 소규모 조직에서는 구현 및 관리가 훨씬 간단하기 때문에 수직적 확장을 사용하지만, 시간이 지남에 따라 애플리케이션이 성장함에 따라 과도한 수요를 처리하기 위해 수평적 확장이 도입됩니다.
마지막으로, 클라우드 플랫폼은 실시간 수요에 따라 인스턴스를 자동으로 추가하거나 제거하는 자동 확장 서비스를 제공하므로 조직이 수직적 확장과 수평적 확장의 균형을 맞추는 데 큰 도움이 됩니다.
마이크로서비스 모니터링
이 단계에서는 마이크로서비스 배포가 거의 완료되었습니다. 남은 것은 일관되고 안정적으로 작동하는지 확인하는 것입니다. 이는 다음과 같은 마이크로서비스 모니터링 도구가 있는 곳입니다. 프로메테우스와 그라파나 들어가다.
이러한 도구는 팀이 리소스 사용량, 대기 시간 및 오류율을 추적할 수 있도록 서비스 지표에 대한 실시간 통찰력을 제공합니다. 또한 이러한 도구는 서비스 전반의 요청 흐름을 시각화하는 데 도움이 되고 문제 진단에 큰 도움이 될 수 있는 분산 추적(Jaeger, Zipkin 등)도 제공합니다.
마지막으로, 마이크로서비스의 분산 설계로 인해 오류가 서비스 전체에 걸쳐 연쇄적으로 발생할 수 있으므로 로그 집계는 마이크로서비스 모니터링에서 중요한 방식입니다. 로그를 중앙 집중식 플랫폼에 통합하고 실시간 경고를 설정하면 항상 문제보다 두 단계 앞서서 문제가 사용자에게 영향을 미치기 전에 사전에 대응할 수 있습니다.
최종 생각
마이크로서비스의 세계는 확실히 이해하기 어려운 곳이지만, 마이크로서비스 배포의 기본 사항과 주요 단계를 이해하면 전체 프로세스가 훨씬 쉬워집니다. 또한, 시간이 지나면서 훨씬 더 많은 기능을 갖춘 점점 더 많은 도구를 사용할 수 있게 되어 마이크로서비스 배포가 그 어느 때보다 간단해졌습니다.
FAQ
마이크로서비스에 일반적으로 사용되는 배포 전략은 무엇입니까?
마이크로서비스 배포에는 다양한 전략이 있지만 가장 일반적으로 사용되는 배포 전략에는 컨테이너당 서비스 인스턴스, 단계적 릴리스, 블루-그린 배포, 서버리스 배포가 포함되며, 각 전략은 서로 다른 수준의 격리, 유연성 및 확장성을 제공합니다.
마이크로서비스 조정에서 Kubernetes는 어떤 역할을 합니까?
마이크로서비스는 Kubernetes와 같은 마이크로서비스 오케스트레이션 도구를 사용하여 컨테이너화된 서비스의 배포, 확장 및 관리를 자동화하고 로드 밸런싱, 자동 크기 조정 및 자가 복구 기능을 제공하여 탄력적이고 효율적인 마이크로서비스를 보장합니다.
마이크로서비스 환경에서 보안을 어떻게 보장할 수 있나요?
분산 특성으로 인해 마이크로서비스는 모놀리식 아키텍처보다 보안 측면에서 더 복잡합니다. 마이크로서비스의 보안에는 요청 인증 및 권한 부여, 서비스 간 통신 암호화, 중앙 집중식 보안 관리를 위한 Istio와 같은 서비스 메시 및 API 게이트웨이 구현이 포함됩니다.
