마이크로서비스란 무엇인가요?

마이크로서비스의 이점

마이크로서비스는 변화하는 비즈니스 요구 사항에 적응할 수 있는 클라우드 네이티브 애플리케이션을 구축하기 위한 프레임워크를 제공합니다. 애플리케이션의 아키텍처에서 얻을 수 있는 이점은 무궁무진합니다.

민첩성

마이크로서비스 아키텍처는 독립적인 개발 및 구축에 적합합니다. 코드 한 줄을 변경하면 전체 애플리케이션을 업데이트해야 하는 모놀리식 애플리케이션과 달리, 개발자는 분산 시스템에 영향을 주지 않고 서비스를 수정하거나 교체할 수 있습니다. 개별 서비스를 구축하는 기능을 사용하면 애플리케이션에 새로운 기능을 추가하거나 변경 사항을 쉽게 롤백할 수 있습니다.

확장성

전체 애플리케이션을 대규모로 확장하는 것은 최적화되지 않습니다. 마이크로서비스를 사용하면 확장이 필요한 구성 요소만 확장할 수 있습니다. 개발자는 필요에 따라 개별 서비스를 처리할 수 있으므로 궁극적으로 부하가 많은 상황에서 성능을 개선하고 리소스를 효율적으로 사용하며 인프라 비용을 절감할 수 있습니다.

선택

마이크로서비스 아키텍처에서 클라우드 네이티브 애플리케이션은 공통 스택과 데이터베이스를 공유하지 않습니다. 개발자는 선호하는 도구와 기술을 선택하여 개별 서비스의 고유한 요구 사항을 충족할 수 있습니다.

통합

개발자는 어떤 언어로든 마이크로서비스를 작성할 수 있으며, 어떤 언어로든 프로그래밍된 마이크로서비스에 연결할 수 있습니다. 또한 마이크로서비스는 모든 플랫폼에서 실행할 수 있으므로 레거시 시스템과 통합할 수 있습니다.

코드 재사용

개발자는 마이크로서비스 아키텍처를 통해 여러 애플리케이션에서 재사용할 수 있는 모듈식 서비스를 구축할 수 있습니다. 프로그래머는 재사용 가능한 컴포넌트로 작업함으로써 개발 시간을 단축하고 '한 번 쓰고 자주 재사용하는' 문화에 투자하여 코드 품질을 개선할 수 있습니다.

내결함성

마이크로서비스 아키텍처는 복원력을 촉진합니다. 자율적으로 작동하도록 설계된 서비스에서는 모놀리식 애플리케이션에서 발생하는 경향처럼 단일 서비스 장애로 인해 애플리케이션이 종료되는 경우는 거의 없습니다.

협업

마이크로서비스 아키텍처를 사용하면 팀이 여러 서비스를 동시에 작업할 수 있으므로 시장 출시 시간이 단축됩니다. 개발자는 다른 팀과 조율할 필요 없이 의사 결정을 내리지만, 마이크로서비스는 각 팀이 전체의 일부를 개발하고 유지 관리할 책임이 있으므로 팀 간 협업을 촉진하기도 합니다. 이를 통해 비즈니스 목표에 더 잘 부합하고 리소스를 더 효율적으로 사용할 수 있습니다.

지속적인 반복

마이크로서비스로 구축된 애플리케이션은 진화하도록 설계되었습니다. 개발자는 핵심 마이크로서비스를 최소 실행 가능한 제품으로 빠르게 구축하고 팀이 추가 서비스를 완료함에 따라 애플리케이션을 업그레이드할 수 있습니다. 새로운 기술이 등장할 때마다 디자인에 통합할 수 있습니다. 마이크로서비스 기반 애플리케이션은 이론적 완성을 향해 지속적으로 발전하고 있습니다.

마이크로서비스 사용 시기

컨테이너 기반 마이크로서비스는 많은 이점을 제공하지만 항상 선택하기에 적합한 애플리케이션 아키텍처는 아닙니다. 소프트웨어 엔지니어링 결정을 내릴 때는 애플리케이션의 목표와 애플리케이션의 수명을 고려할 때 예상되는 개발 장애물 및 요구 사항을 고려하세요. 마이크로서비스는 복잡한 애플리케이션에서 가장 잘 작동합니다. 마이크로 서비스 사용을 고려할 수 있는 시나리오는 다음과 같습니다:

대규모 애플리케이션

크고 복잡한 애플리케이션을 구축하는 경우 마이크로서비스를 사용하면 애플리케이션을 관리 가능한 부분으로 나누어 개발, 구축 및 유지 관리가 더 쉬워집니다.

타임라인의 복잡성

마이크로서비스 아키텍처는 개발 속도가 서로 다른 독립적인 서비스를 수용할 수 있습니다. 서비스에 예기치 않은 지연이 발생하더라도 애플리케이션 개발 일정에 영향을 주지 않고 프로젝트를 계속 진행할 수 있습니다.

잦은 업데이트

마이크로서비스 아키텍처는 개발자가 애플리케이션 대신 독립적인 서비스를 통해 모듈을 수정할 수 있으므로 잦은 업데이트가 필요한 애플리케이션에 이상적입니다.

높은 확장성

애플리케이션이 대량의 트래픽을 처리해야 하거나 대규모로 확장해야 하는 경우 마이크로서비스가 필수적입니다. 전체 애플리케이션을 확장하는 것이 아니라 애플리케이션의 특정 부분을 확장해야 하는 경우에 특히 유용합니다.

여러 팀

동일한 애플리케이션에 대해 여러 개발팀이 작업하는 경우 마이크로서비스를 사용하면 민첩성과 효율성을 유지할 수 있습니다. 각 팀은 나머지 애플리케이션에 대한 걱정 없이 자신에게 적합한 기술 스택을 사용하여 마이크로서비스를 개발할 수 있습니다.

분산형 아키텍처

분산형 아키텍처로 애플리케이션을 구축하려는 경우, 마이크로서비스는 자율적이며 서로 다른 클라우드 서비스 제공자 사이에서도 서로 다른 위치에 구축할 수 있습니다.

하이브리드 클라우드

일부 서비스는 온프레미스에서 지속적으로 실행하고 다른 서비스는 클라우드에서 실행하는 하이브리드 클라우드 아키텍처를 계획하고 있다면 마이크로서비스가 애플리케이션의 복잡성을 관리하는 데 도움이 될 수 있습니다.

마이크로서비스 기반 앱 빌드 및 구축

마이크로서비스 아키텍처는 신중한 계획이 필요합니다. 개발자는 프로덕션 환경에 공통된 특정 기술 및 관행을 통해 마이크로서비스 기반 애플리케이션을 효과적으로 개발, 유지 관리 및 운영할 수 있습니다.

DevOps

CI/CD를포함한 DevOps 관행은 마이크로서비스의 아키텍처 접근 방식에 필수적입니다. 모놀리식 애플리케이션과 달리 마이크로서비스는 본질적으로 수많은 움직이는 부품과 독립적인 기술 스택이 있는 복잡한 분산 시스템입니다. 이러한 복잡성 때문에 개발팀과 운영팀 간의 빈번한 협업을 통해 구성 요소가 원활하게 통합될 수 있도록 해야 합니다.

DevOps 관행은 전체 소프트웨어 개발 수명 주기동안 팀을 효과적으로 하나로 모으는 데 필요한 협업, 커뮤니케이션 및 자동화 도구를 제공합니다.

지속적인 제공

지속적인 배포는 마이크로서비스와 함께 진행되며, 개발자는 지속적인 통합 서버, 배포 파이프라인 및 자동화된 테스트 프레임워크와 같은 인프라 자동화 도구를 사용하여 CI/CD 프로세스를 간소화함으로써 소프트웨어 업데이트를 자주 그리고 안정적으로 릴리스할 수 있습니다.

각 서비스가 다른 마이크로서비스와 독립적으로 업데이트 및 릴리스될 수 있도록 하려면지속적인 배포가 특히 중요합니다.

REST

마이크로서비스는 마이크로서비스와 통신하며, 대부분 웹 애플리케이션 내에서 통신하므로 REST는 상호 보완적입니다. REST(Representational State Transfer)는 RESTful API를 구축하기 위한 아키텍처 설계 패턴으로, 서비스가 XML, HTML, JSON과 같은 표준 형식의 HTTP를 통해 통신할 수 있도록 합니다. 하지만 Rest API는 여러 가지 이유로 마이크로서비스 기반 앱의 기본이 됩니다.

Rest API는 가볍고 플랫폼에 구애받지 않으므로 기반 기술에 관계없이 마이크로서비스가 통신할 수 있는 표준화된 인터페이스를 제공합니다. 요청에는 요청을 완료하는 데 필요한 정보가 포함되어 있기 때문에 Rest API는 서버에 컨텍스트를 저장할 필요가 없습니다. 성능 저하 없이 대량의 요청을 처리할 수 있으며, REST 기반 마이크로서비스 아키텍처의 서비스는 독립적으로 진화하여 상태 비저장 방식으로 효율적으로 통신할 수 있습니다.

컨테이너

마이크로서비스는 팀에게 서비스의 언어와 프레임워크를 선택할 수 있는 옵션을 제공하지만, 동일한 CD 파이프라인에서 다양한 언어로 작업하는 데는 어려움이 따릅니다. 컨테이너는 각 마이크로서비스가 코드베이스, 데이터베이스 및 종속성으로 패키징된 독립된 단위가 되므로 서비스 간의 차이를 추상화합니다. 이제 균질화된 CD 파이프라인은 각 컨테이너에 대해 일관된 테스트를 수행할 수 있습니다.

컨테이너로 분리된 서비스는 서로 간섭하지 않고 상호 작용할 수 있으며, 일단 구축되면 컨테이너는 가볍고 이식 가능한 런타임 환경을 제공하여 서비스가 여러 플랫폼에서 일관되게 작동할 수 있게 해줍니다. 컨테이너화된 마이크로서비스를 관리하는 데는 Docker 및 Kubernetes와 같은 도구가 널리 사용됩니다.

쿠버네티스 오케스트레이터

Kubernetes와 같은 오케스트레이션 도구는 기본 인프라를 추상화하고 여러 서버에 걸쳐 컨테이너 관리, 구축 및 확장을 자동화할 수 있습니다. 또한 확장성을 통해 개발자와 운영자가 선호하는 오픈소스 및 상용 소프트웨어 도구를 사용할 수 있어 컨테이너 관리의 수작업을 줄일 수 있습니다.

서버리스

서버리스 컴퓨팅은 마이크로서비스를 구축하기 위한 또 다른 옵션입니다. 서버리스 아키텍처는 서비스형 기능(FaaS) 플랫폼을 사용하여 더 작은 단위로 구축하고 온디맨드 방식으로 대규모로 확장할 수 있습니다. 서버리스 아키텍처는 공급업체 종속성을 높일 수 있지만 운영 비용, 복잡성, 엔지니어링 리드 타임을 줄일 수 있습니다.

마이크로서비스 모범 사례

마이크로서비스 아키텍처를 설계하려면 신중한 계획과 고려가 필요합니다. 성공적인 마이크로서비스 기반 애플리케이션을 구축하려면 개발자는 다음 모범 사례를 준수해야 합니다:

• 도메인 중심 디자인: DDD(도메인 중심 디자인)는 비즈니스 도메인과 애플리케이션의 동작에 초점을 맞춘 디자인 접근 방식입니다. 개발자가 애플리케이션을 더 작고 관리하기 쉬운 구성 요소로 분할하여 빌드, 구축 및 유지 관리를 더 쉽게 할 수 있도록 도와줍니다.
• 서비스 경계: 마이크로서비스 아키텍처를 설계할 때는 명확한 서비스 경계를 정의하는 것이 필수적입니다. 각 마이크로서비스에는 잘 정의된 책임이 있어야 합니다.
• 소규모 서비스: 단일 책임에 집중하여 서비스를 '마이크로'로 유지하세요. 이 기본 원칙을 잊어버리면 관리 효율성이 떨어집니다.
• API 디자인: 마이크로서비스는 API를 통해 통신하므로 권한이 부여된 애플리케이션, 사용자 및 서버로 데이터 액세스를 제한하는 일관되고 확장 가능하며 안전한 API를 사용하세요.
• 분산형 데이터 관리: 마이크로서비스 애플리케이션에는 다양한 스토리지 및 데이터베이스 옵션이 필요합니다. 각 마이크로서비스에는 자체 데이터스토어가 있어야 합니다. 이 접근 방식을 사용하면 데이터 불일치를 방지하고 각 마이크로서비스를 자율적으로 확장할 수 있습니다. 개발팀은 각 서비스별로 프로젝트에 가장 적합한 데이터베이스를 선택할 수 있습니다.
• CI/CD 파이프라인: CI/CD를 구현하면 버그를 빠르게 발견하고 수정하는 데 도움이 되며, 이는 마이크로서비스 아키텍처에서 관리해야 하는 코드베이스가 여러 개일 때 특히 유용합니다.
• 의도적인 복원력: 종속성 실패로 인한 종료로부터 애플리케이션을 보호하세요. 가능하면 마이크로서비스 간에 원격 프로시저 호출(RPC)을 사용하지 말고, 회로 차단기와 같은 기능을 통합하여 연쇄적인 장애를 방지하세요.
• SOP: 코딩 규칙, 디렉토리 구조 및 통신 프로토콜을 정의하는 표준 운영 절차를 개발합니다. 일련의 표준을 따르면 일관되고 관리하기 쉬운 마이크로서비스를 만들 수 있습니다.

마이크로서비스 도입

수많은 기업이 모놀리식 애플리케이션을 해체하고 마이크로서비스 기반 아키텍처로 리팩토링하여 대규모 확장성, 비즈니스 민첩성, 재정적 이점을 활용하고 있습니다.

마이크로서비스로 전환할 계획이 있는 조직은 먼저 DevOps를도입하여 직면하게 될 복잡성을 관리할 수 있도록 준비해야 합니다. 기본적으로 프로젝트를 매핑할 때 아래에 설명된 단계를 예상하세요.

비즈니스 역량 파악

마이크로서비스 아키텍처로 마이그레이션하는 첫 번째 단계는 애플리케이션이 지원해야 하는 비즈니스 기능 또는 기능을 파악하는 것입니다. 이를 통해 애플리케이션의 범위를 정의하고 개발을 위해 우선순위를 정해야 하는 기능과 이러한 마이크로서비스를 설계하고 서로 통합하는 방법에 대한 결정을 내릴 수 있습니다.

모놀리식 애플리케이션 분해

대부분의 조직은 도메인 중심 설계 또는 기능 기반 분해를 사용하여 모놀리식 애플리케이션을 분해합니다.

애플리케이션의 비즈니스 기능을 파악한 후에는 각 마이크로서비스의 서비스 경계를 정의하여 각 마이크로서비스가 뚜렷하고 잘 정의된 책임을 갖도록 합니다. 비즈니스 기능, 데이터스토어, 외부 시스템 간의 종속성을 매핑해야 합니다. 한정된 컨텍스트와 종속성을 기반으로 모놀리식 애플리케이션을 대체할 마이크로서비스를 정의합니다.

단일 비즈니스 기능에 초점을 맞춘 각 마이크로서비스에는 명확한 인터페이스가 있어야 합니다. 데이터 엔티티에 액세스하는 방법을 검토하고, 마지막으로 서비스 간의 종속성을 줄이기 위해 데이터를 분할하는 방법을 고려하세요.

서비스 인터페이스 정의

각 마이크로서비스에 대한 서비스 인터페이스를 구현하여 인터페이스가 마이크로서비스의 고유한 책임을 반영하도록 하세요. Restful API 또는 메시징 프로토콜과 같은 다양한 기술을 사용하여 서비스 인터페이스를 정의할 수 있습니다.

서비스 구현 및 테스트

요구 사항과 전문 지식에 따라 서비스를 구현할 프로그래밍 언어와 프레임워크를 선택하세요. 새로운 인터페이스, 통신 프로토콜, 데이터스토어를 테스트하는 등 필요에 따라 설계를 반복합니다.

서비스 컨테이너화

서비스를 구현하고 테스트한 후에는 Docker 또는 Kubernetes와 같은 컨테이너 기술을 사용하여 서비스를 컨테이너화할 수 있습니다. 컨테이너화를 통해 서비스를 독립적으로 구축하고 관리할 수 있습니다.

구축 및 오케스트레이션 자동화

Kubernetes 또는 Docker Swarm과 같은 도구를 사용하여 서비스 오케스트레이션을 자동화하세요. 서비스 구축을 효율적으로 간소화할 뿐만 아니라 Kubernetes 또는 Docker를 통한 자동화로 애플리케이션의 안정성과 가용성을 향상시킬 수 있습니다. 두 플랫폼 모두 서비스 인스턴스가 실패하거나 응답하지 않을 때 이를 감지하고 문제를 해결하기 위한 조치를 취할 수 있습니다. 예를 들어, Kubernetes는 장애가 발생한 인스턴스를 다시 시작하거나 다른 노드로 일정을 재조정할 수 있으며, Docker는 장애가 발생한 컨테이너를 다른 노드로 자동으로 마이그레이션할 수 있습니다.

서비스 모니터링 및 관리

모놀리식 애플리케이션을 분해하는 작업은 한 번으로 끝나는 것이 아닙니다. 애플리케이션과 사용자의 요구 사항이 진화함에 따라 유지 관리 및 업데이트가 필요합니다. 새로운 마이크로서비스를 모니터링하고 응답 시간 및 리소스 사용률과 같은 주요 메트릭을 추적하세요.

마이크로서비스 보안

고도로 분산된 클라우드 네이티브 마이크로서비스 애플리케이션은 보안이 복잡해집니다. 단일 진입 지점 대신 수백 개는 아니더라도 수십 개의 잠재적 취약 지점이 존재하며, 각 지점을 보호해야 합니다. API와 코드 종속성은 최신 애플리케이션의 확장되는 공격 표면에서 두 가지 위험 요소에 불과합니다.

웹 애플리케이션 및 API 보안

최신 애플리케이션은 표준 웹 요청, 모바일 디바이스 API 호출, 클라우드 이벤트, IoT 디바이스 원격 측정 통신, 클라우드 스토리지 등 다양한 소스로부터 입력을 소비합니다. 또한 단일 클라이언트의 웹 요청(예: 남북 트래픽)이 내부 마이크로서비스 간 수백 개의 API 호출(예: 동서 트래픽)을 생성할 수 있습니다.

API 중심 웹 애플리케이션의 복잡성으로 인해 모든 유형의 환경 또는 클라우드 아키텍처에서 모든 유형의 워크로드에 적합한 확장 가능하고 유연하며 다층적인 전략이 필요합니다. 클라우드 네이티브 애플리케이션의 프론트엔드 웹 인터페이스를 보호하는 것만으로는 충분하지 않습니다. 클라우드 네이티브 애플리케이션에는 클라우드 네이티브 API에 대한 애플리케이션 계층 보호가 필요합니다. 웹 애플리케이션 및 API 보안(WAAS) 은 필수입니다.

코드 종속성 및 소프트웨어 구성 분석

오픈 소스 소프트웨어 구성 요소는 클라우드 네이티브 애플리케이션의 약 70%를 차지합니다. 이렇게 하면 개발 속도가 빨라지지만 많은 오픈 소스 패키지와 그 종속성에는 취약점이 있습니다. 또한 종속성 기반 OSS 패키지의 각 버전은 중요한 기능을 변경할 수 있습니다. 완전한 가시성이 없으면 취약점이 탐지되지 않습니다.

독립형 소프트웨어 구성 분석(SCA) 도구는 개발 수명 주기에서 오픈 소스 위험을 너무 늦게 발견하기 때문에 항상 해결할 수 없는 취약점이 백로그에 쌓이게 됩니다. SCA와 IaC 보안을 위한 별도의 도구는 상호 연결된 위험에 대한 맥락과 지식 없이 시끄러운 알림을 발생시킵니다. 런타임 및 워크로드 범위가 없으면 공백이 발생할 수밖에 없으므로 통합 클라우드 네이티브 보안으로클라우드 네이티브 애플리케이션을 보호하는 것이 가장 좋습니다.

코드 투 클라우드 CNAPP

전체 클라우드 네이티브 애플리케이션의 중요한 위험을 식별하고 우선순위를 지정하는 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP)은 여러 유형의 보안을 통합하여 클라우드 보안 상태 관리(CSPM), 클라우드 워크로드 보호, 클라우드 인프라 권한 관리(CIEM), Kubernetes 보안 상태 관리(KSPM), 코드 기반 보안, WAAS, SCA 등 포괄적인 코드 투 클라우드 보호 기능을 제공 합니다.

컨테이너, 마이크로서비스, 서버리스 기능 등 클라우드 네이티브 기술을 사용하는 애플리케이션의 빠른 개발 요구 사항을 가장 잘 보호하는 방법을 모색하는 클라우드 보안 리더는 CNAPP 도입을 고려해야 합니다.

마이크로서비스 FAQ