마이크로서비스 및 마이크로서비스 아키텍처

마이크로서비스란 무엇입니까?

마이크로서비스는 복잡한 클라우드 기반 애플리케이션의 구성 요소로 사용할 수 있는 가볍고 느슨하게 결합된 모듈입니다. 개별 마이크로서비스는 독립적으로 작동할 수 있지만, 통합 인터페이스에서 느슨하게 결합되어 있습니다.

마이크로서비스 아키텍처는 모놀리식 아키텍처의 더 전통적인 개발 모델의 현대적이고 유연한 대체로 간주됩니다.

모놀리식 아키텍처에는 각 애플리케이션에 할당된 하나의 물리적 또는 가상 서버가 있으며 이러한 서버는 항상 실행 중입니다. 애플리케이션 확장 및 가용성은 고정 엔터티인 기본 하드웨어에 전적으로 의존합니다.

이와는 대조적으로, 마이크로서비스는 워크로드 요구를 지원하는 동적 리소스 확장으로 단일 서버 또는 다중 서버에서 다양한 인스턴스를 운영할 수 있습니다. 개별 마이크로서비스는 종종 휴대성과 확장성을 개선하기 위해 컨테이너화됩니다.

마이크로서비스의 다양한 특성

개발 프로세스로서 마이크로서비스 프레임워크는 공통적이지만 보편적이지 않은 특정한 특성을 갖습니다.

이러한 특성에는 다음이 포함됩니다.

• 구성 요소. 마이크로서비스는 일반적으로 개별 소프트웨어 구성 요소로 구성되며 이는 개별적으로 교체 및 업그레이드가 가능합니다. 이 아키텍처는 클라우드 관리 기술에 영향을 미칩니다. 각 마이크로서비스가 개별적으로 프로비저닝, 모니터링 및 업그레이드되기 때문입니다.
• 서비스. 구성 요소는 요청 시 전달할 수 있지만 요청이나 호출 사이에 지속적으로 활성화될 수 없는 서비스들로 구성됩니다.
• 독립 배포. 대부분의 경우, 개별적인 서비스 구성 요소는 마이크로서비스 프레임워크 내에서 서로 독립적으로 작동합니다. 하나의 구성 요소가 변경되거나 업데이트되면, 특히 더 전통적인 모놀리식 아키텍처와 비교했을 때, 다른 서비스 및 구성 요소에 거의 영향을 미치지 않습니다.
• 보안. 마이크로서비스 간의 통신은 전송 중 맬웨어 및 침입으로부터 데이터를 보호하기 위해 종종 상호 전송 계층 보안(mTLS)으로 암호화됩니다.
• 컨테이너화. 마이크로서비스는 종종 추가적인 휴대성과 확장성을 위해 컨테이너에 배포됩니다.

마이크로서비스 및 클라우드 애플리케이션의 이점

마이크로서비스는 클라우드에서 아키텍처의 타고난 유연성 때문에 계속해서 인기를 얻고 있습니다. 실제로 인텔에서 실시한 최근 연구에 따르면 모든 새로운 클라우드 네이티브 애플리케이션과 SaaS 솔루션의 83 퍼센트가 마이크로서비스를 사용하고 있습니다.¹

마이크로서비스의 가장 큰 이점 중 하나는 배포의 속도와 유연성입니다. 클라우드 애플리케이션 및 워크로드가 규모 및 범위의 측면에서 지속적으로 증가함에 따라 새로운 요구를 수용하기 위해 모놀리식 아키텍처를 조정하는 것은 점점 더 어렵고 시간이 많이 소요됩니다. 마이크로서비스는 세분화되어있으므로 이들의 개발, 배포 및 유지를 분산 모델에서 관리할 수 있습니다.

예를 들어, 다양한 독립 개발 팀은 하나 또는 그 이상의 마이크로서비스를 책임질 수 있습니다. 책임의 분배는 각 부서의 비즈니스 기능에 따라 DevOps 기능의 재편성을 용이하게 합니다. 이는 전체 개발 프로세스의 현대화와 사일로의 제거로 이어질 수 있습니다.

마이크로서비스는 몇 가지 배포 과제를 야기하기도 합니다. 개별 모듈은 요청을 이행하기 위해 서로 다른 시스템에서 실행될 수 있으며, 이로 인해 한 모듈에서 그 다음 모듈로의 성능이 일관되지 않을 수 있습니다.

마찬가지로 수요가 급증할 때 지연 시간이 일부 마이크로서비스의 문제가 될 수 있습니다. 이러한 문제는 종종 최대 수요 수준을 수용하도록 리소스를 오버프로비전하여 해결할 수 있습니다.

마이크로서비스가 세분화 되어 있으므로, 하나의 모듈에 영향을 미치는 서비스의 실패는 다른 모듈에 거의 또는 전혀 영향을 주지 않습니다. 이것은 이점이지만, 서비스 실패로 인해 문제가 발생할 수도 있습니다.

예를 들어, 실행이 중단된 후 실패한 서비스를 디버깅하는 것이 어려울 수도 있습니다. 한 가지 해결책은 인프라를 조정하고 모든 프로세스와 데이터 흐름을 사전에 모니터링하는 것입니다. 이러한 모니터링 프로토콜은 하드웨어 사용 원격 분석 수집기와 성능 모니터링 장치(PMU)를 활용할 수 있습니다. 이러한 장치는 인텔® 기술 기반 클라우드 플랫폼에 구축되어 있습니다.

마이크로서비스 아키텍처 작동 방식

마이크로서비스 아키텍처에서는, 복잡한 애플리케이션이 독립적으로 개발 및 운영할 수 있는 개별 기능으로 세분화됩니다. 개별 마이크로서비스는 종종 API를 통해 서로 통신하며, 느슨하게 연결되어 있지만 각 마이크로서비스는 별도로 개발, 배포 및 업데이트할 수 있습니다.

마이크로서비스 배포는 종종 세 가지 패턴 중 하나를 따릅니다.

1. 클라우드 네이티브. 구축된 일부 대용량 애플리케이션과 서비스는 마이크로서비스로 시작하여 클라우드에 남습니다. International Data Corporation(IDC)에 따르면, 마이크로서비스의 약 56 퍼센트가 클라우드 네이티브이며, 나머지 44%는 레거시 애플리케이션으로 시작되었습니다.²
2. 리팩터링 및 시프트. 이러한 배포는 온-프레미스 또는 에지의 데이터 센터에서 시작되며 클라우드 기반 마이크로서비스 아키텍처에 적응하도록 리팩터링됩니다. 리팩터링은 모놀리식 아키텍처와 관련된 데이터베이스 및 기타 리소스 재매핑을 포함할 수 있으므로 해당 마이크로서비스와 페어링됩니다.
3. 리프트 앤 시프트. 일부 조직은 간단한 "리프트 앤 시프트" 전환 과정에서 리팩토링 없이 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션합니다.

마이크로서비스 및 DevOps

마이크로서비스 아키텍처의 세분화된 특성으로 인해 DevOps 팀은 종종 애플리케이션 개발에 부서간 업무 접근 방식을 채택합니다.

하나의 스택에서 소프트웨어 애플리케이션을 개발하는 대신, 예를 들어, 한 팀은 펌웨어 작업에 배정하고, 다른 팀은 미들웨어 작업에, 세 번째 팀은 사용자 인터페이스에 배정하면 마이크로서비스 개발 노력은 비즈니스 역량을 중심으로 조직될 가능성이 더 높습니다.

어떤 면에서는, 개발 프로세스와 DevOps 팀의 조직 구성은 장벽과 사일로를 넘어 느슨하게 상호 작용하는, 준독립적이고 자체 포함하는 마이크로서비스 구조 자체를 모방할 수도 있습니다.

마이크로서비스 확보

마이크로서비스가 서로 상호 작용하도록 설계되는 경우가 많기 때문에 상호 작용의 양 끝 또는 두 지점 사이에서 데이터가 전송되는 동안 이를 보호하는 것이 중요합니다.

상호 전송 계층 보안(mTLS)을 통한 암호화는 각 엔드포인트 및 전송 중인 데이터에 대한 침입 및 맬웨어 위험을 줄이는 데 도움이 되는 공통 솔루션입니다. mTLS의 목표는 각 마이크로서비스의 모든 요청을 암호화하는 것입니다. 이같은 보안에 대한 전체론적인 접근 방식은 각 마이크로서비스, 사용자 및 연결 상태를 독립적으로 검증하고 승인해야 하는 제로 트러스트 환경의 기초를 형성합니다.

그러나 각 개별 마이크로서비스에 인증과 암호화를 반드시 포함시킬 필요는 없습니다. 여러 개발자들은 중복을 피하기 위해 서비스 메시를 대신 배포합니다. 메시는 마이크로서비스 아키텍처 내의 인프라 계층 또는 프록시 인스턴스로서 역할을 하여 통신을 확보, 제어 및 모니터링하도록 지원합니다.

보안 프로토콜은 상당한 컴퓨팅 능력을 필요로 할 수 있으며, 이로 인해 리소스가 묶이고 마이크로서비스 제공 속도가 느려질 수 있습니다. 암호화 알고리즘을 가속화하고 지연 속도를 줄이는 데 도움이 되도록 마이크로서비스 개발자는 인텔® DPT(인텔® Data Protection Technology)를 배포할 수 있습니다.

인텔® DPT에는 인텔® Advanced Encryption Standard – New Instructions(인텔® AES-NI) 및 인텔® Secure Key 지침뿐만 아니라 신속한 암호화 키 생성을 위한 인텔® DRNG(인텔® Digital Random Number Generator)이 포함됩니다.

이러한 고급 알고리즘 보호 기능은 인텔® 제온® 스케일러블 프로세서의 내장 보안 기능을 위해 최적화됩니다. 예를 들어, 인텔® AVX-512(인텔® Advanced Vector Extensions 512) 및 대칭 암호화, 보안 해싱 및 기능 스티칭 같은 알고리즘 혁신은 암호화의 성능을 상당히 향상합니다.

이러한 기능과 기타 하드웨어 지원 보안 기능은 인텔® 제온® 스케일러블 프로세서로 구동되는 인스턴스의 주요 클라우드 서비스 공급업체에서 사용할 수 있습니다.

마이크로서비스 아키텍처 예제 및 진화하는 프레임워크

클라우드 애플리케이션이 규모 및 범위 측면에서 계속 성장함에 따라, 개발자들은 복잡한 다기능 애플리케이션을 구축하고 변화하는 사용 모델을 수용할 수 있도록 신속하게 확장하는 데 점점 더 많이 마이크로서비스에 의존하고 있습니다.

모든 마이크로서비스 기반 배포의 경우, 일반적으로 느슨하게 연결된 여러 구성 요소 서비스가 별도로 실행됩니다. 이러한 모듈 구성 요소는 함께 작동하여 통합된 사용자 환경 또는 애플리케이션을 만듭니다.

그룹 특성에 따라 사용자 경험을 차별화할 수 있는 일부 마이크로서비스 기반 애플리케이션에서 마이크로서비스를 사용하는 이점은 코드를 공유하고 재사용할 수 있다는 점입니다. 이 접근 방식을 사용하면 동일한 서비스의 여러 인스턴스를 구축하고 유지 관리할 필요가 없습니다. 차별화된 경험 중 하나에 맞춤화가 필요할 경우, 추가 마이크로서비스를 통합할 수 있습니다.

예를 들어, 인기 있는 라이드쉐어링 애플리케이션은 마이크로서비스를 기반으로 하지만 운전자와 승객은 차별화된 사용자 경험을 누릴 수 있습니다. 운전자 관리, 위치 추적, 승객 프로필 및 결제 처리는 각각의 모바일 장치에서 사용자와 운전자 인터페이스를 함께 지원하는 서로 다른 마이크로서비스입니다. 모든 인터페이스가 동일한 브랜드를 공유하지만 일부 기능은 각 그룹별로 다를 수 있습니다.

마이크로서비스 아키텍처는 또한 전자상거래 스토어를 위한 공통 환경입니다. 제품 권장 사항 및 체크 아웃 프로세스를 개별 마이크로서비스로 개발하여 배포할 수 있지만 쇼핑객은 온라인 스토어의 브랜드 환경과 인터페이스 내에서 두 가지 프로세스를 모두 경험하게 됩니다.

마이크로서비스 사용 시기

마이크로서비스 접근 방식은 가장 복잡한 솔루션을 구성 요소 부분으로 세분화하여 애플리케이션을 마이그레이션하고 확장하는 데 도움이 될 수 있습니다. 각 마이크로서비스는 독립적으로 개발하여 배포되므로 다양한 마이크로서비스는 느슨하게 통합된 엔티티로 함께 작동합니다.

조직은 새로운 클라우드 솔루션 개발할 때 마이크로서비스를 사용할 가능성이 가장 큽니다. 또한 기존의 모놀리식 아키텍처가 변화하는 요구 사항을 충족하기가 너무 어려워질 경우에도 마이크로서비스를 배포할 수도 있습니다.

마이크로서비스 아키텍처로의 전환은 DevOps 팀 자체의 조직과 구조의 변화를 가져올 수 있습니다. 팀은 시간이 경과함에 따라 기술 스택의 기능 계층을 모방하는 사일로 대신 비즈니스 기능에 새롭고 교차 기능적인 초점을 맞출 수 있습니다.