마이크로서비스란?
간단히 "마이크로서비스"라고도 불리는 마이크로서비스 아키텍처는 서로 구별되고 독립적인 모듈식 서비스로 소프트웨어를 구축하는 접근 방식입니다.
최근 몇 년 동안 마이크로서비스는 애플리케이션 설계 및 구축에 있어 인기가 높은 옵션이 되었습니다. 개발 팀은 독립적인 테스트, 유지 관리 및 구축이 가능하도록 앱을 더 작고 느슨하게 결합된 조각(마이크로서비스)으로 나눔으로써 구축 방법을 보다 자율적이고 창의적으로 제어할 수 있게 되었습니다.
이 게시물에서는 마이크로서비스 아키텍처가 무엇인지 살펴보고, 장단점을 분석하고, 마이크로서비스의 미래를 전망해보겠습니다.
우선은 다른 개발 방법들을 이해하고 오늘날 마이크로서비스가 이들과 어떻게 다른지 살펴볼 필요가 있습니다.
모놀리식 아키텍처란?
앱 개발 초기에는 전체 소스 코드가 단일 단위로 구축되었는데, 이를 "모놀리식" 접근 방식이라고 합니다. 당시에는 기존 앱을 약간만 변경해도 자체적인 품질 보증 프로세스에서 새로운 도매 버전을 업데이트해야 했기 때문에 앱 구축 시간이 길어지고 여기에 참여하는 팀들의 업무량이 늘어났습니다. 이러한 업데이트로 인해 오류가 발생하기라도 하면 전체 앱을 오프라인으로 전환해서 분해하고 수정해야 했습니다.
비즈니스 영역이 여러 개인 성장 기업의 경우에는 모놀리식 아키텍처에 결함이 있으면 서비스 전반에 걸쳐 다운타임이 발생할 수 있으며, 이는 감당하기 어려운 위험 요소가 됩니다.
모놀리식과 마이크로서비스 비교
모놀리식 앱은 단일 중앙 장치의 형태로 구축이 되기 때문에 모든 기능이 동일한 런타임 환경을 공유합니다. 반면에 마이크로서비스는 기능이나 비즈니스 영역에 따라 환경을 분류하고 별도의 개발 팀이 각 서비스에 대한 소유권을 갖습니다.
SOA(Serivce-Oriented Architecture)란?
SOA는 이러한 비효율성을 해결하기 위해 등장했습니다. SOA는 비즈니스 프로세스 언어(예: BPEL)를 사용해 비즈니스 로직을 제공하는 ESB(Enterprise Service Bus)를 통해 커뮤니케이션이 가능하도록 별도의 구성 요소로 앱을 구성합니다. 한편, 각각의 서비스는 특정한 비즈니스 프로세스를 중심으로 구성되며 ESB를 통해 공유가 가능하도록 XML 기반의 공통 통신 프로토콜(예: SOAP)을 준수합니다.
SOA에서는 개발자가 필요에 따라 각 서비스를 구축, 테스트 및 개선할 수 있지만, SOAP 프로토콜과 XML 페이로드에 대한 부담으로 인해 모든 사용 사례에서 이 테크놀로지를 지원하는 데는 제약이 따릅니다. 또한 ESB는 시스템의 SPOF(Single Point Of Failure)이기도 합니다. ESB에 문제가 발생하면 전체 앱 제품군에 차질이 발생하여 개발 주기 단축의 이점이 희석될 수 있습니다.
SOA와 마이크로서비스 비교
SOA 구성 요소는 ESB를 사용해 서로 커뮤니케이션을 하기 때문에 SPOF가 발생할 수 있지만, 마이크로서비스는 API를 사용해 서로 커뮤니케이션합니다.
API가 적합한 영역
2014년, James Lewis와 Martin Fowler가 기본 포지셔닝에 대한 글 “마이크로서비스”를 게시한 이후 마이크로서비스의 인기는 치솟았습니다. 이 글에서는 마이크로서비스 아키텍처를 명확하게 정의하고 이것이 SOA에서 어떻게 진화했는지 그 맥락을 설명하고 있습니다. ESB의 대안인 마이크로서비스 구성요소는 API를 통해 서로 커뮤니케이션을 하기 때문에 타사 앱과의 통합도 가능합니다.
같은 해에 Spring Boot가 발표되었는데, 이는 마이크로서비스를 생성하고 애플리케이션 개발 주기를 단축하는데 사용되는 Java 기반의 오픈 소스 프레임워크로 정의할 수 있습니다. 후속 릴리스인 Spring Cloud 1.0은 Spring 및 Java 개발 커뮤니티가 Netflix가 초기에 옹호했던 아키텍처 원칙에 접근할 수 있도록 함으로써 마이크로서비스의 인기를 확고히 했습니다.
마이크로서비스와 API 비교
마이크로서비스는 기능을 타사 시스템으로 오프로드할 수 있는 선택권을 제공하는 방식의 앱 개발 아키텍처입니다. API는 이러한 마이크로서비스가 서로 정보를 공유할 수 있도록 해줍니다. 그리고 내부 및 외부 개발자가 마이크로서비스의 데이터에 액세스하거나 해당 기능을 사용할 수 있는 통로 역할을 합니다.
오늘날 업계를 선도하고 있는 많은 기업들이 마이크로서비스를 사용해 비즈니스를 구축하고, API 경제 및 개발자 커뮤니티를 활용해 고도로 통합된 고급 서비스를 제공하고 있습니다. 예를 들어 승차 공유 앱은 결제를 위해 Stripe API를, 매핑 테크놀로지를 위해 Google Maps를, 문자 전송을 위해 Twilio를 사용할 수 있습니다.
마이크로서비스 아키텍처는 API를 사용하여 개발자에게 기능을 오프로드하고 업계 전문가의 서비스로 앱을 강화할 수 있는 기회를 제공합니다. 위의 마이크로서비스 아키텍처 예제에서 회사는 Okta의 Authentication 및 Authorization API를 사용해 앱에 보안 아이덴티티 및 액세스 관리를 포함시킬 수 있습니다.
마이크로서비스 아키텍처의 작동 방식
범용되는 모델이나 스타일은 없지만 많은 마이크로서비스들이 다음과 같은 공통적인 특징을 가지고 있기 때문에 비슷한 방식으로 작동합니다.
- 여러 구성 요소: 이 구조에서는 전체 애플리케이션에 영향을 미치지 않고 각각의 서비스를 독립적으로 구축, 개선 및 재배포할 수 있습니다.
- BU(Business Unit)를 중심으로 구성: 구조적으로 볼 때 마이크로서비스는 보통 비즈니스 기능과 우선 순위를 중심으로 구성이 됩니다. 각 팀은 특정 제품 또는 서비스의 작동에 대한 소유권을 갖게 되며, 이를 위해 여러 팀의 테크놀로지를 혼합해 하나로 통합합니다. 이것이 각각의 팀이 전체 앱 제품군에서 하나의 기능에 집중하는 모놀리식 개발과 대비되는 부분입니다.
- 간단한 라우팅: 마이크로서비스는 요청을 수신 및 처리하고 응답을 내보내는 간단한 수단으로서 API를 사용합니다. 따라서 메시징 라우팅 및 비즈니스 규칙 적용을 위해 고급 시스템에 종종 의존하는 EBS를 사용할 경우 발생하는 복잡한 문제를 피할 수 있습니다.
- 분산형 마이크로서비스는 다양한 테크놀로지와 플랫폼을 하나로 통합한다는 점에서 중앙 집중식 거버넌스에 적합하지 않습니다. 마이크로서비스 개발자들은 사람들이 문제 해결에 사용할 수 있는 유용한 툴을 개발하는 것을 목표로 삼는 경우가 많기 때문에 보통은 분산형 거버넌스를 선호합니다. 또한 마이크로서비스는 각각의 서비스가 자체 데이터베이스를 관리하는 분산형 데이터 관리를 선호합니다.
마이크로서비스의 장점
마이크로서비스 아키텍처는 다음과 같이 개발 프로세스에 다양한 이점을 제공합니다.
- 민첩성: 소규모의 독립적인 개발자 팀이 각 서비스에 대한 소유권을 갖습니다. 따라서 각 팀은 자율적으로 행동하고 자신들이 담당하고 있는 서비스에 대한 업데이트를 신속하게 발행하여 개발 주기를 단축할 수 있습니다.
- 확장성: 작은 구성 요소들이 하나의 네트워크를 이루고 있기 때문에 지원하는 애플리케이션 기능에 대한 수요를 충족하도록 각각의 서비스를 독립적으로 확장할 수 있습니다. 덕분에 팀들은 기능의 비용을 정확하게 측정하고, 인프라 요구를 중심으로 계획을 수립하고, 서비스 활동이 급증하는 경우에 가용성을 보장할 수 있습니다.
- 전문성: 각각의 마이크로 서비스는 특정한 기능 세트를 제공하고 특정한 문제를 해결하도록 설계되었습니다. 결론적으로, 마이크로서비스를 설계하는 데 통일된 접근 방식은 없습니다. 개발자는 각각의 문제를 해결하기에 가장 적합한 툴을 자유롭게 선택할 수 있습니다.
- 구축 용이성: 마이크로서비스는 모듈식이고 CI(Continuous Integration)/CD(Continuous Delivery)를 지원하기 때문에 코드를 업데이트하고, 새로운 아이디어를 실험하고, 새로운 기능을 출시하고, 문제가 발생할 경우 업데이트를 롤백하는 것이 비교적 쉽습니다.
- 유연성: 개발자는 특정 기능을 위해 개발된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있고, 공개 API를 사용해 타사(예: Twilio, Okta, Stripe)의 기능을 자유롭게 통합할 수 있습니다. 그 결과, 개발자는 코드를 처음부터 작성하지 않고도 새로운 기능을 개발할 수 있습니다.
- 진화: 마이크로서비스 아키텍처는 계속 진화하고 있다는 점에서 앱에 액세스할 수 있는 디바이스 유형을 완전히 예측할 수 없는 시스템에 적합합니다. 많은 앱들이 처음에는 모놀리식 아키텍처를 기반으로 했다가 API를 통해 상호 작용하는 마이크로서비스로 점차 개선됩니다.
마이크로서비스의 단점
마이크로서비스는 많은 이점이 있지만, 다음과 같은 어려움도 있다는 것을 인식해야 합니다.
- 유지 관리: 한 서비스에 장애가 발생한다고 전체 시스템에 영향이 미치는 것은 아니지만, 각각의 서비스가 개별적으로 위험에 빠집니다. 따라서 마이크로 서비스 앱에서 오류를 신속하게 감지하고 가능한 신속하게 서비스를 복원하기 위해서는 지속적인 모니터링이 필요합니다. 각 서비스에 대해 스트레스 테스트를 수행하는 것이 복원력 및 모니터링 기능을 테스트하는 데도 좋습니다.
- 보안성: 각 서비스는 개별적으로 취약점을 가지고 있기 때문에 앱이 진정으로 안전하려면 각 마이크로서비스를 효과적으로 보호해야 합니다. 이는 Okta Advanced Server Access 같은 제품을 사용해 권한 인증을 지원하면 앱 배후에서 인프라를 보호할 수 있다는 의미입니다.
- 아이덴티티 및 액세스 관리: 마이크로서비스에서는 사용자가 단일 서비스가 아닌 여러 API에 로그인합니다. 이러한 사용자 아이덴티티는 종종 서로 다른 디렉터리에 존재하기 때문에 모순된 데이터가 포함된 중복 프로필이 생길 수 있습니다. 사용자는 이렇게 분산된 구성 요소에서 권한 인증을 받아야 합니다. 그리고 각 마이크로서비스는 독립적으로 작동해야 하지만, 각 구성 요소가 아이덴티티를 자체적으로 보호하는 것은 위험한 방법입니다.
마이크로서비스의 미래에 대한 전망
마이크로서비스 아키텍처가 진화를 거듭하면서 다음과 같이 세 가지 이점이 점차 부각되고 있습니다.
서버리스 아키텍처
오늘날 개발자들은 서버 용량, 리던던시 및 런타임 환경에 대해 걱정할 필요 없이 주문형 코드를 실행하는 서버리스 공급업체를 이용해 코드를 구축할 수 있습니다. 덕분에 대대적인 선행 투자 없이도 새로운 서비스를 신속하게 개발, 테스트 및 구축할 수 있습니다. AWS Lambda 및 Google Cloud Functions는 현재 개발자에게 이러한 서비스를 제공하고 있습니다.
에지 컴퓨팅
에지 컴퓨팅은 성능을 개선하고, 지연 시간을 줄이며, 향상된 처리 능력을 토대로 마이크로서비스 애플리케이션을 보다 효율적으로 실행하는 것을 목표로 삼고 있습니다. 에지 컴퓨팅은 SPA(Single Page Application) 같은 최신 테크놀로지와 Cloudflare 및 Fastly 같은 콘텐츠 구축 네트워크 공급업체를 활용하여 고객 가까이에서 서비스를 제공하고 있습니다.
창의성을 발휘할 수 있는 기회 확대
마이크로서비스 아키텍처는 커뮤니티 개발 및 반복 작업에 적합한 것이 입증되었습니다. 공개 API 시장이 성장을 거듭하고 서로 다른 서비스에서 재사용이 가능한 코드가 더 많이 작성됨에 따라 새롭고 흥미로운 기능을 앱에 내장하는 데 사용할 수 있는 리소스에 액세스하려는 개발자가 증가할 것으로 기대하고 있습니다.
마이크로서비스 시작하기
마이크로서비스를 시작하기 위한 정해진 방법은 없지만, Okta는 앱을 구축하고 보호하는 데 도움이 되는 포괄적인 리소스 라이브러리를 제공하고 있습니다.
아래에서 마이크로서비스 아키텍처와 그 보안 방법에 대해 자세히 알아보십시오.
- Okta 개발자 블로그 (마이크로서비스 튜토리얼 및 가이드)
- GitHub (프로젝트 및 예제 앱)
- 마이크로서비스 아키텍처를 위한 보안 패턴 (블로그 게시물)
- 고급 서버 액세스 (제품 페이지)
