상명대학교 /?서광규?교수
마이크로서비스는 소프트웨어 개발을 가속화하고 개선하는 혁신적인 방법으로 주목받고 있다. 마이크로서비스 용어는 개별적으로 개발하고 있고 종종 특정 기능에 초점을 맞추는 응용 프로그램의 하위구성 요소를 말한다. 마이크로서비스는 컨테이너와 유사하지만 동일하지 않다. 마이크로서비스는 컨테이너에서 실행할 수 있지만 그 반대로는 실행할 수 없다. 마이크로서비스는 응용 프로그램의 전반적인 생태계 또는 아키텍처의 일부로 API를 통해 서로 통신한다.
마이크로서비스는 몇 가지 장점이 있다. 즉, 빠르게 변경할 수 있고, 재사용할 수 있으며, 확장성을 높이고 다른 코팅언로로 구성할 수도 있다. 전체 프로그램이 아닌 하나 또는 두 개의 마이크로서비스만 조정해야 하는 경우 응용 프로그램을 쉽게 업데이트할 수 있다. 이들은 변경을 용이하게 하게 추적하며 문제를 해결하고 내결함성을 촉진하고 성능을 향상시키는 데 도움을 줄 수도 있다.
기술의 모든 요소와 마찬가지로 마이크로서비스에도 보안 위험이 있는데, 마이크로서비스 내에서는 응용프로그램 취약성이 가성의 벽 뒤에 샌드박스화(sandbox)되어 있어서 보안측면의 장점도 있다. 그러나 취약성은 여전히 존재할 수 있으며 다양한 마이크로서비스가 복잡성을 증가시키고 특히 응용 프로그램에서 여러 개발자와 메소드를 사용하는 경우 보안을 강화하기 더 어려워질 수 있다.
본 고에서는 클라우드의 보안, 개인정보보호 및 표준화 측면에서 마이크로서비스에 대하여 살펴보기로 한다. 본 고는 마이크로서비스 기반의 솔루션을 구축할 때 반드시 고려해야 할 요소들을 설명하고자 한다.
마이크로서비스 아키텍처
마이크로서비스에 대한 여러 가지 설명이 있지만, 간단하게 설명하면 하나의 거대한 단일체로서의 응용프로그램을 제작하는 대신, 애플리케이션을 구성하는 각각의 요소들을 따로 개발해 조합하는 방식이라 할 수 있다. 즉, 마이크로서비스는 응용 프로그램의 각 요소가 개별적, 독립적으로 설계 및 개발되는, 분할적 구조의 소프트웨어 아키텍처라 할 수 있다. 이렇게 제작된 개별 요소는 API를 통해 하나로 통합된다. 즉 여러 개의 레고 조각에 해당하는 앱이나 서비스를 API라는 요소를 통해 하나의 통일된 앱으로 조립하는 것처럼 통합할 수 있다.
응용프로그램 기능을 서비스 단위로 분할한다는 개념은 SOA에서의 개념과 비슷하다. SOA와 마이크로서비스는 개념적으로 유사하기는 하나, SOA는 단일의 프로그래밍 언어와 개발 환경에 국한되어 있고 전통적인 인프라 요소를 사용했다는 점에서 마이크로서비스와 구분된다. 이에 비해 마이크로서비스는 더 작고 독립적인 프로세스로 구성된, 더욱 애자일한 애플리케이션 개발 방법론이라 할 수 있다. 마이크로서비스 아키텍처 하에서 앱을 구성하는 각 서비스들은 각기 다른 프로그래밍 언어를 이용할 수 있으며, 그럼에도 불구하고 표준 API와 가상 또는 공용 클라우드 환경 등 차세대 인프라를 통해 서비스간 커뮤니케이션이 가능하다.
마이크로서비스 아키텍처를 이해하기 위해서는 모놀리식 아키텍처 스타일 (Monolithic Architectural Style)과 반대 개념을 고려해야 한다. 응용프로그램이 커지고 복잡해지면서 모놀리식 아키텍처의 장점인 “통짜 구조”가 발목을 잡는 경우가 많아진다. 즉, 빌드, 배포, 서버 기동 시 시간이 오래 걸리고, 한 두 사람의 실수는 전체 시스템의 빌드 실패를 유발하여 프로젝트가 커질수록 협업하기 어려우며 컴포넌트들이 서로 로컬 콜 (call-by-reference) 기반으로 강하게 결합(tightly coupled)되어 유연성이 떨어지고, 코드가 너무 커져서 유지보수 어렵게 된다. 특히 배포가 잦은 시스템에 더욱 불리하며 경직성이 증가한다. 이러한 문제점을 해결할 수 있는 것이 마이크로서비스 아키텍처이다.
[그림 1] 모놀리식 아키텍처 VS 마이크로서비스 아키텍처
* 출처: https://www.redhat.com/ko/topics/microservices
모놀리식 아키텍처 또는 중앙 집중형 아키텍처에서 분산형 아키텍처로 전환하려면 몇 가지 주의가 필요하다. 과거에는 보안이 모든 서비스 요청을 수신하는 단일 지점에 집중되었다. 마이크로서비스 아키텍처에서 리소스는 서로 상호 연결되는 여러 액세스 지점을 통해 제공되어 고유한 솔루션을 형성한다. 모놀리식 보안 서비스는 마이크로서비스보다 상대적으로 구현하기 쉽다. 모놀리식 서비스는 명확한 경계를 가지고 있으며 상호 작용을 캡슐화한다. 이렇게 하면 시스템의 내부 계층 내에서 보안 취약성이 제거된다. 예를 들어, 마이크로서비스 기반 시스템에서 간단한 루틴 완료를 위해서는 마이크로서비스가 네트워크를 통해 서로 통신해야 한다. 이렇게 하면 시스템에 대한 더 많은 데이터 및 정보(엔드 포인트)가 노출되어 공격 포인트가 확장된다. 동일한 네트워크에서 다른 서비스 간의 통신도 주의를 기울여야 하며, 이것도 주요 과제 중 하나이다.
마이크로서비스 기반의 시스템 개발을 위한 팀 구성은 일반적으로 팀과 서비스로 세분되며, 이들 팀은 일반적으로 서비스의 구현과 제공을 담당한다. 이러한 유형의 구현을 위해, 팀들은 마이크로서비스와 상호 연결의 목적으로 조정되어야 하며, 따라서 통신 수행에 사용되는 프로토콜을 동기화하거나, 액세스 표준을 준수해야 한다. 서비스가 상호 연결되고 상호 작용하는 방식을 정의하는 것이 보안의 핵심이다. 이러한 네트워크 복잡성으로 인해 발생하는 보안 과제는 전체 애플리케이션의 디버깅, 모니터링, 감사 및 컴플라이언스 분석에 있어 점점 더 큰 어려움을 겪고 있다. 마이크로 서비스는 응용프로그램 소유자가 제어하지 않는 클라우드에 구현되는 경우가 많으므로 전체 애플리케이션에 대한 전체 뷰를 구축하기가 어렵다.
마이크로서비스 아키텍처에서 응용프로그램은 기본적으로 워크플로우 모음이다. 이러한 워크플로우는 최종 대상이 되기 전에 데이터를 처리하고 수정하는 다양한 수준의 서비스를 작성할 수 있다. 서비스에 필요한 것은 데이터 스트림과 관련된 메타 데이터를 인증하고, 시간 및 재개방 기간 동안 유효성을 관리하는 방법이다.
보안은 마이크로서비스 아키텍처에서 신중하게 고려해야 하는 중요한 과제이다. 서비스는 신뢰 관계를 형성하는 다양한 방식으로 서로 통신한다. 일부 시스템의 경우 사용자가 마이크로서비스 간에 발생하는 서비스 통신의 모든 체인에서 식별되어야 한다. 마이크로서비스는 독립적이고 모듈 간에 의존성을 유발하지 않지만, 클라우드 서비스상에서 큰 문제는 가용성을 보장하는 것이다. 데브옵스(DevOps)는 현재 클라우드 환경 및 마이크로서비스 아키텍처와 협력하고 있으며 코드 컴파일부터 테스트 및 운영 환경의 가용성에 이르기까지 지속적인 통합을 제공하고 있다.
서비스 가용성을 마이크로서비스 아키텍처의 사용에 의해 촉진되는 보안 요구 사항으로 제시한다. 이러한 접근 방식은 일반적으로 전체 솔루션을 작은 조각으로 조각화하는 방식으로 작동한다. 이러한 조각들이 특정 기능(마이크로서비스)을 가진 코드의 일부임을 고려하면, 조각 고장이 발생할 경우 모든 시스템 리소스를 사용할 수 없게 되는 것은 아니다. 가용성에는 소프트웨어 버전 구현, 소프트웨어 충돌 복구, 침입, 포인트를 초과하는 인프라 기능 사용 불가 등과 같은 몇 가지 중요한 사항을 준수해야 한다.
서비스 검색의 문제는 통신을 용이하게 하기 위해 서비스 소비자가 실시간으로 서비스 제공 업체를 찾을 수 있도록 하는 것이다. 도커(컨테이너)는 민첩성과 새로운 서비스를 쉽게 제공할 수 있다. 컨테이너를 사용하면 마이크로서비스를 패키지로 만들어 단일 이미지에 종속성 옆에서 사용할 수 있으므로 서비스 가용성이 시기 적절하게 향상되어 다운 타임이 최소화되는데 이 모드를 코드 이식성이라고 한다.
클라우드 개인정보보호(Privacy) 측면에서 마이크로서비스
개인정보보호는 클라우드 채택에 장애가 되어 왔다. 마이크로서비스로의 마이그레이션은 이 아키텍처에서 제안된 규모 이득으로 인해 이러한 장애물을 극복하는 데 도움이 되었다. 일반적으로, 프라이버시는 존재나 뷰를 숨기는 조건이나 상태를 의미한다. 데이터 및 파일과 같은 기밀 정보가 사용되는 장소에서는 이러한 상태에 도달해야 한다. 클라우드 데이터 스토리지에서는 데이터, 사용자 ID 및 제어를 얻기 위해 개인 정보가 필요하다.
여러 ID공급자와 서비스 공급자가 협력하여 서비스를 제공하는 클라우드의 대규모 시나리오에서는 데이터의 교환이 매우 중요하다. 그러므로 신원 관리는 사용자의 민감한 데이터를 관리하기 위해 모델과 개인정보보호 메커니즘을 제공해야 한다.
클라우드 서비스는 비즈니스 고객에게 데이터에 필요한 보호 수준을 선택할 수 있는 다양한 옵션을 제공하는데, 가장 일반적인 방법은 암호화이다. 고객은 선호하는 암호화 유형을 선택하여 자신이 제어하는 안전한 장소에 암호화 키를 저장하고, 개인 정보 보호를 위해 잘 참조된 모델이 사용된다.
[그림 2] 클라우드 프로비저닝 구조
* 출처: K, El Makkaoui, A. Ezzati, A. Beni-Hssane, and C. Motamed, “Data confidentiality in the world of cloud,” J. Theor. Appl. Inf. Technol., vol. 84, no. 3, pp. 305?314, 2016.
그림 2에서 제안된 모델에 따르면, 보안 및 프라이버시 모델은 물리 및 환경 보안, 클라우드 인프라 보안, 네트워크 보안, 데이터 및 액세스 제어, 권한 관리의 5개 계층으로 나뉘며 이에 대한 보안 이슈는 다음과 같다.
1) 물리적 환경적 보안
클라우드 제공자의 물리적 액세스를 보호하기 위해 채택된 정책 계층
2) 클라우드 인프라 보안
클라우드 인프라 보안을 통해 문제를 해결하고, 특히 가상화 환경을 사용
3) 네트워크 보안
브라우저와 해당 연결로 구성된 최종 사용자가 클라우드에 연결할 매체를 지정
4) 데이터
계층은 데이터 개인 정보 보호, 무결성, 기밀성 및 지리적 위치를 다룸
5) 접근 제어 및 권한 관리
적절한 권한을 부여한 사용자만 데이터를 사용하거나 수정할 수 있도록 클라우드 서비스 공급자가 사용하는 정책 및 프로세스로 여기에는 식별 및 인증 문제가 포함
클라우드 표준화(Standard) 측면에서 마이크로서비스
중앙 집중식 구조에서 표준화는 매우 자연스러운 방법이지만, 마이크로서비스 구현에서는 이러한 철학이 변경된다. 팀들은 또한 표준에 대한 다른 접근법을 선호한다. 이들은 정의된 표준 집합을 종이에 적어 사용하기보다는 다른 개발자들이 직면한 표준과 유사한 문제를 해결하는 데 사용할 수 있는 유용한 도구를 생산한다. 이러한 도구는 대개 구현에서 수집되고 때로는 키트를 사용하여 독점적이지는 않지만 광범위한 그룹과 공유되며 사실상 선택한 버전 제어 시스템이 되었다. 오픈 소스 관행은 사내에서 점점 더 보편화되고 있다.
마이크로서비스는 필요한 기능을 수행하기 위한 것으로 독립적으로 진화하며 아키텍처, 기술, 플랫폼을 선택할 수 있으며 자체 릴리스 라이프 사이클 및 개발 방법에 따라 독립적으로 관리, 구축 및 확장할 수 있다. 이 접근 방식은 "스마트 엔드 포인트"를 만들고 중간 계층을 데이터 전송 기능을 가진 네트워크 리소스로 처리함으로써 SOA 및 ESB의 구성 및 그에 따른 당면 과제를 제거한다.
모놀리식 아키텍처에서 개발된 응용프로그램은 주소 확인, 제품 카탈로그, 고객 신용 확인 등의 다양한 기능을 수행한다. 마이크로서비스 아키텍처 패턴을 사용하면 주소 확인, 고객 신용 확인 등과 같은 특정 기능을 함께 제공한다. 마이크로서비스 아키텍처 기반 응용프로그램 개발 접근 방식은 모놀리식 응용프로그램 및 서비스의 당면 과제를 해결한다.
마이크로서비스는 다음과 같이 구현되고 문서화된다.
1) 아키텍처 뷰/다이어그램
- UML
- 표준 모델링 언어(예: RAML 및 YAML)
- 특수하게 설계된 모델링 언어(예: MLAT)
- 표준 사양 언어(예: 자바 스크립트(Node.js), JSON 및 Ruby)
- 특별히 설계된 사양 언어(예: Jolie)
- 알고리즘을 위한 Pseudocode
2) REST
REST는 일련의 아키텍처 원칙으로 구성되며, 이를 따르면 잘 정의된 인터페이스 설계를 생성할 수 있다. REST는 다른 서비스(웹 서비스)에 서비스를 제공하고 메시지를 완전히 사용하기 위해 자주 적용된다. 아키텍처 스타일을 더 잘 이해하기 위해서는 (i) 특징, (ii) 운영 및 (iii) 표현의 세 가지 중요한 개념을 강조하는 것이 중요한다. 리소스는 URI(고유 식별자)를 통해 고객이 사용할 수 있는 정보이며, 리소스를 표현의 소스로 정의할 수도 있다. 표현은 요청된 리소스의 상태를 설명하는 데이터 집합입니다.?URI는 표기법 패턴이 있어야 하고 설명이 있어야 하며 이전에 정의된 계층 구조가 있어야 한다. 하나 이상의 URI에서 동일한 리소스를 식별할 수 있지만 URI는 하나의 리소스만 식별한다.
3) API
API는 다음과 같은 보안 메커니즘을 갖는다.
(i) 강력한 비밀 번호 보호 기능을 갖춘 API 사용자 등록을 포함한 기본적인 인증
(ii) 메시지 수준 보안, 웹 서명 및 웹 암호화와 같은 현대적 보안 메커니즘
(iii) 백엔드 인증을 위한 토큰 기반 API, 공용 키 인프라 및 전송 계층 핸드셰이크 프로토콜과 같은 세 번째 보안 요소로서 API와 백엔드 서비스 내의 보안 메커니즘
결언
마이크로서비스 아키텍처는 소프트웨어 개발을 위한 아키텍처 스타일로 성장하고 있다. 이러한 아키텍처 스타일에서, 소프트웨어 솔루션에 의해 제공되는 서비스들은 작은 부분들로 나뉘고 일부 기능성의 특정한 서비스에 초점을 맞춘다. 소형 소프트웨어 구성 요소의 구축과 함께 마이크로서비스를 개발하는 접근 방식은 마이크로 서비스와 확장 용이성을 통해 구현되는 소프트웨어의 복원력을 높이는 등 기존 단일 아키텍처에 비해 여러 가지 장점이 있다.
마이크로서비스 아키텍처를 사용하는 소프트웨어의 개발에서 좋은 결과를 얻기 위해서는 반드시 고려하여야 할 중요한 측면이 있다. 본 고에서는 마이크로서비스를 기반으로 한 솔루션 개발을 위해 고려해야 할 요소를 제시하고 이를 설명하였다.
- 이 문서는 「W. H. C. Almeida, L. de A. Monteiro, R. R. Hazin, A. C. de Lima, F. S. Ferraz, "Survey on Microservice Architecture - Security, Privacy and Standardization on Cloud Computing Environment,”ICSEA 2017 : The Twelfth International Conference on Software Engineering Advances, pp. 119-205.」를 토대로 작성되었음.
참고문헌
1. https://www.techrepublic.com/article/10-tips-for-securing-microservice-architecture/
2. http://www.itworld.co.kr/news/102054
3. https://www.redhat.com/ko/topics/microservices
4. W.H. C. Almeida, L. de A. Monteiro, R. R. Hazin, A. C. de Lima, F. S. Ferraz, "Survey on Microservice Architecture - Security, Privacy and Standardization on Cloud Computing Environment,”ICSEA 2017 : The Twelfth International Conference on Software Engineering Advances, pp. 119-205.
5. K. El Makkaoui, A. Ezzati, A. Beni-Hssane, and C. Motamed, “Data confidentiality in the world of cloud,”J. Theor. Appl. Inf. Technol., vol. 84, no. 3, pp. 305?314, 2016.