안녕하세요? 이번 글은 Bluemix를 이용하여 간단한 클라우드 애플리케이션을 디자인하고 만들어 가는 과정을 내용으로 연재되고 있습니다. 아래와 같은 순서로 진행되고 있으므로 참고 부탁 드립니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

마이크로 서비스 아키텍쳐 설계

지난 글에서는 요건에 대한 Usecase와 간단하게 나마 Wireframe을 작성해 보았습니다. 이번 글에서는 이 애플리케이션을 구성할 서비스 아키텍쳐 설계에 대해 이야기 해보려고 합니다.

애플리케이션 아키텍쳐란?

아키텍트(Architect)라는 말은 흔히 설계자, 건축가를 나타내는 단어입니다. 그런 건축가들은 건물을 설계하면서 그 건물의 용도와 건축주의 요건에 맞춰 건물의 모양이나 장식 그리고 내부 구조를 결정합니다. 이때 그냥 머릿속에 떠오르는데로 아무렇게나 만드는 것이 아니라 건물이 가지고 있는 전체적인 분위기나 특징을 결정한 후 그에 맞춰 설계를 하게 되는데 이와 같은 양식을 아키텍쳐(Architecture)라고 부릅니다. 예를 들면 로마네스크 양식, 고딕 양식, 비잔틴 양식 등이 있습니다.

애플리케이션을 만드는 것은 이와 같이 건축에 비유되곤 합니다. 전체적인 애플리케이션 설계를 담당하는 사람을 아키텍트라고 부르고, 아키텍트는 이 애플리케이션을 어떤 형식으로 설계할지를 고민하고 적절한 아키텍쳐를 결정하게 됩니다.

초창기 웹 애플리케이션이 생겨날 때를 생각해 봅시다. 그 때는 단지 HTML로 작성된 문서를 웹 브라우저를 통해 단순히 보여주는 것이 목적이었습니다. A태그에 연결된 문서의 링크를 작성하는 모습으로 구성하게 됩니다. 궂이 이름을 붙이자면 Hyper Linked Documents Service 정도가 될듯 합니다.

시간이 약간 지나 사람들은 서버에서 제공하는 많은 문서 중 자신이 원하는 것만을 얻고 싶어했고, 그에 따라 사용자의 입력이 단순히 링크 클릭이 아닌 폼(Form)을 구성하여 필요한 정보를 입력하면 그에 맞는 내용을 동적으로 제공하는 서비스가 나타나게 됩니다. 그리고 좀 더 시간이 지나 제공하는 서비스가 많아지고 사용자의 요건 또한 복잡해지게 되어 이를 구현하는데는 많은 생각과 노력이 필요하게 되었습니다.

당연하게도 이와 같은 상황이 반복되는 가운데 등장한 것이 애플리케이션 프레임워크(Application Framework)이며 이러한 프레임웤 기반의 애플리케이션이 다양한 개발 방법론으로 만들어지고 운영되고, 일반화되면서 애플리케이션 아키텍쳐(Application Architeuture)으로 자리잡게 됩니다.

마이크로 서비스 아키텍쳐란?

이제 요즘과 같은 클라우드 시대에 대해 이야기 해 볼 차례입니다.

과거 물리 서버 환경에서는 설계 단계부터 전반적인 서비스에 대한 수요 예측 및 이에 대응되는 운영 환경을 구성했기 때문에 서비스 사용자나 사용 요청 증가에 따른 서버 성능 및 용량 증가가 쉽지 않았습니다. 또한 확장을 한다고 해도 빠른 시간안에 물리 서버를 늘이고 애플리케이션을 배포하는 것이 사실상 불가능 했습니다.

클라우드 인프라를 적용하면 이러한 가상화 기술을 이용하여 빠른 배포와 관리를 통해 앞서 문제를 해결 할 수 있다고 합니다. 그렇다면, 기존 애플리케이션을 클라우드 인프라 환경에서 실행하도록만 하면 모든 문제가 해결되는 것일까요? 절반은 맞지만 절반은 아니라고 할 수 있습니다. 기본적으로 클라우드가 가진 확장성을 이용하면 물리 서버 환경에서 발생하던 문제는 해결이 가능합니다만, 그 애플리케이션을 무작정 확장 할 경우는 문제가 발생합니다.

예를 들어 모노리스 아키텍쳐(Monolithic Architecture) 애플리케이션을 클라우드 서버 환경에서 실행한다고 가정해 봅시다. 이 애플리케이션이 가진 다양한 기능 중에 특정 기능에 대한 요청이 집중되어 시스템에 부하가 발생하는 경우 고정된 리소스의 물리 서버는 순간적인 대응이 어렵습니다. 클라우드 인프라의 경우는 스케일링 기능을 이용하여 손쉽게 대응이 가능한데 그 스케일링이 적용되는 단위가 애플리케이션 전체라는 점이 문제가 됩니다. 필요한 부분은 일부분인데 늘어나는 것은 전체가 되다보니 효율이 떨어지게 됩니다. 또한 특정 기능에서 발생하는 오류로 인해 애플리케이션 실행이 안되는 경우는 스케일링으로도 대응이 불가능하게 되어 버립니다.

기존의 애플리케이션 아키텍쳐에서는 클라우드가 가진 장점이 희석되고 근본적은 문제가 해결되지 않기에 애플리케이션도 변화된 환경에 발맞추는 것은 당연한 현상일 것입니다.

결과적으로 물리서버 대비 저렴한 사용료, 빠른 동적 자원 할당, 손쉬운 네트워크 구성 및 자동 스케일링과 같은 클라우드 인프라 환경의 특징과 장점을 더 적극적으로 활용하기 위해 제안된 아키텍쳐가 마이크로 서비스 아키텍쳐라고 볼 수 있습니다.

마이크로 아키텍쳐 및 인프라에 대한 조금 더 자세한 내용은 마이크로서비스를 위한 인프라스트럭처를 참고하시기 바랍니다.

마이크로 서비스 아키텍쳐 설계

마이크로 서비스 아키텍쳐를 설계해야겠다고 마음을 먹고 가장 먼저 고민하는 부분은 서비스를 어떻게 나누어야 하는지일 것입니다. 어떻게 서비스를 구성해야 잘 만들어진 마이크로 서비스 아키텍쳐가 되는 것일까요?

다음은 서비스를 분리하고 구성하는 단계를 알아 보겠습니다.

  • 기능으로 구분

모든 경우에 해당하는 것은 아니지만 일반적으로 애플리케이션이 제공 하는 기능을 기준으로 서비스를 구분합니다.

애플리케이션의 요건에 맞춰 구분된 기능을 서비스로 나누어 볼 수 있습니다. 모노리스의 경우 데이터를 중심으로 기능이 구성되므로 데이터를 기준으로 제공가능한 기능으로 구분하기도 합니다.

  • 데이터의 분산

보통의 애플리케이션을 설계하는 경우 애플리케이션을 통해 처리할 데이터를 기반을 한 설계를 진행합니다. 즉, 필요한 업무에 필요한 정보를 Database 테이블로 설계하고 이를 서비스나 업무 화면으로 노출하는 방식으로 작성됩니다. RDB와 같은 경우는 서로 관계를 중요시한 형태이며 따라서 하나의 덩어리로 구성 될 수 밖에 없는 구조가 됩니다.

마이크로 서비스 아키텍쳐의 경우는 데이터를 서비스별로 분산하는 형태로 바라보아야 합니다. 큰 덩어리의 데이터가 아니라 작은 데이터를 저장하고 서로의 관계를 느슨한 형태로 정의하는 방식을 선택 하게 됩니다. 다만, 무조건 RDB를 지양하는 것이 아니라 서비스의 특성과 목적에 맞춰서 데이터를 분산하는 형태가 되어야 할 것입니다.

  • 독립 UI 사용 여부 결정

앞서 기능이나 데이터로 구분된 서비스 중 독립적인 UI가 필요한 것과 아닌 것으로 다시 구분해야 합니다.

서비스도 일종의 단순한 기능의 애플리케이션이므로 이를 위한 UI를 제공하는 방식으로 서비스의 결과만 공유하게 하는 방식으로 할지 아니면 API와 같이 기능 수행을 중심으로 할지를 결정해야 합니다.

  • 서비스 기능 노출 및 연동 방법 구성

이 부분이 마이크로 서비스 아키텍쳐에서 가장 중요합니다.

서비스 기능 노출은 이 서비스가 어떤 기능을 제공하며 그 기능을 제공하는 방법을 정의하여 노출하는 것입니다. 보통은 REST 방식의 API를 노출하는 방식을 이용하며, 비동기 방식으로 처리하기 위한 Message나 Event Broker를 구성하여 서비스별 통신을 하는 형태로 구성하기도 합니다. 만약 앞서 이야기한 것과 같이 UI를 제공하는 서비스의 경우는 Callback URL을 이용하는 방식을 이용하기도 합니다.

애플리케이션 서비스 설계

이제 우리 애플리케이션으로 다시 돌아 봅니다. 방문자 출입 관리 요건을 위한 애플리케이션은 어떤 형태의 서비스 아키텍쳐를 설계해야 할까요?

사실 요건으로 제시한 기능이 크지 않고 단순하기 때문에 궂이 마이크로 서비스 아키텍쳐가 아닌 클라우드 환경 이해에서 언급했던 클라우드 애플리케이션을 위한 12가지 요소를 어느 정도 만족하는 형태로 설계하는 것이 좀 더 적합한 방법으로 볼 수 있습니다.

그럼에도 불구하고 궂이 마이크로 서비스로 구성을 하려는 것은, 마이크로 서비스 아키텍쳐로 설계 구현시 어떤 부분을 더 생각해야 하는지 고민 할 수 있으며, 아주 작은 모습에서 시작하지만 향후 확장도 가능한 형태로 될 수 있게 하는 것에 의미를 두고자 하기 때문입니다.

방문자 애플리케이션은 다음과 같은 서비스로 구분했습니다.

  • 방문 정보 서비스
  • 임시 출입 카드 서비스
  • 사용자 정보 서비스
  • 사용자 인증 서비스

그리고 UI가 아닌 서비스로, API로 노출하는 형태로 결정했습니다. Backing 서비스가 독립적인 기능을 가지고 있긴 하지만 업무 흐름상 별도의 UI를 가진 형태가 아니기 때문이므로 분리하지 않았습니다. 다음은 서비스 아키텍쳐를 그림으로 그려본 내용입니다.

서비스 아키텍쳐

서비스는 REST 방식으로 노출하고 UI 서비스에서 AJAX 방식으로 호출하는 구조입니다. 다만, 사용자 인증 서비스의 경우는 보안 관계로 UI 서비스 내부의 인증 모듈을 통해 호출하는 방식으로 구성합니다.

각각의 서비스는 자신을 통해 제공하는 정보를 별도로 관리하며, 이를 위해 방문정보, 출입카드정보, 보안기록정보는 NoSQL DB로 구성합니다. 직원정보의 경우는 보통 LDAP이나 별도로 구성된 시스템이 있기 마련이라 DB 대신 구성하기 보다는 Dummy 데이터를 제공하는 형태로 작성합니다.

그리고 여기 인증정보 저장소라는 중요한 정보가 남아 있습니다. 일반적으로 서버 애플리케이션은 사용자 인증이 통과하면 정보를 session에 저장하여 필요할 때마다 꺼내서 사용하는 방식을 이용합니다. 그리고 session 정보 여부를 두고 사용자 인증이 통과했는지를 판단하고 관리합니다. 모노리스의 경우 고민할 것도 없는 내용이지만, 각각 서비스를 분리한 형태인 마이크로 서비스에서는 어떻게 관리해야 할까요?

결국 특정 서비스의 세션이 아닌 애플리케이션에서 공통으로 사용할 수 있는 별도 서비스를 이용 할 수 밖에 없습니다. 그리고 될 수 있으면 session 처럼 아무 곳에서나 손쉽게 사용하고 빠르게 접근 할 수 있는 형태를 선택하게 됩니다. 사용자 인증이 성공하면 이를 인증 정보를 저장소에 넣어 놓고 이에 대응되는 Key를 생성하게됩니다. 이 key를 이용하여 다른 서비스에서도 정상 인증상태 및 인증 정보를 알 수 있게 합니다.

실제 구현에 대한 부분은 다음 글에서 좀 더 자세하게 다루도록 하고, 다음은 서비스별로 제공하는 API를 정의해 볼 차례입니다.

서비스 API 작성

서비스 API 설계는 다음과 같은 목표를 두고 진행했습니다.

  • 서비스는 API를 구성하여 기능을 제공한다.
  • API는 Spec 및 Version 관리를 통해 관리해야 한다.
  • API를 사용하려면 반드시 호출 오류 뿐만 아니라 예상한 데이터가 아닌 경우에 대해 예외 처리를 해야 한다.
  • Data Access는 서비스 API를 통해서만 제공한다.

위와 같은 형식으로 관리되려면 일정한 형태로 API를 표현해야 하는데 swagger.io에서 contribute하는 OpenAPI Specification을 이용하면 API Spec 정보를 JSON 이나 YAML 편집기인 Swagger Editor의 경우 YAML로 편집하도록 되어 있습니다. Open API Specification에 대한 자세한 내용은 swagger.io 홈페이지를 참고 하시기 바랍니다.

Swagger Editor로 각 서비스별로 작성한 API는 다음과 같습니다.

  • 사용자 서비스
    SMV API

  • 인증 서비스
    SMV API

  • 방문 정보 서비스
    SMV API

  • 임시 출입증 서비스
    SMV API

작성된 API Spec 파일은 https://github.com/mc500/smv/tree/master/api에서 확인 할 수 있습니다.

지금까지 애플리케이션에 대한 서비스 아키텍쳐와 API에 대해 설계해 보았습니다. 다음 글에서는 실제 서비스를 클라우드 애플리케이션으로 구성하는 서버 환경을 IBM PaaS 클라우드 플랫폼인 블루믹스(Bluemix)를 이용하여 구성하는 내용을 다루어 보도록 하겠습니다.


  1. 클라우드 환경 이해
  2. 애플리케이션 구상 및 요건 정의
  3. 요건에 대한 Usecase 및 Wireframe 작성
  4. 마이크로 서비스 아키텍쳐 설계
  5. 애플리케이션 서버 환경 준비
  6. 애플리케이션 로컬 개발 환경 준비
  7. 애플리케이션 프로토타입 작성 Part1
  8. 애플리케이션 프로토타입 작성 Part2
  9. 애플리케이션 프로토타입 작성 Part3
  10. 애플리케이션 DevOps 환경 구성

참고

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다