마이크로 서비스 아키텍처를 위한 Frontend 개발패턴

 그 동안 마이크로 서비스 아키텍처 관련 내용을 소개하고 관련 솔루션을 준비하면서 항상 아쉬운 부분이 있었습니다. 우선 기존에 다루었던 마이크로 서비스관련  목록을 다시 나열해 보겠습니다.

• 모놀리틱 시스템에서   MSA 전환

• 도메인 주도 설계

• 마이크로 서비스의 장단점

• API 서버

• Event 기반의 Microservices 

 

주로 마이크로 서비스 아키텍처 자체 및 비즈니스 로직이 구현에 대한 글들이 많습니다. 그러나 실제 적용하기 위해서 일반 개발자나 현업이 생각해 보는 부분은 UI 즉 frontend 구현에 대한 고민입니다.

 일반적으로 마이크로 서비스 방식에서 각 채널 별 Frontend 관련 개발 패턴은 API기반인 JSON  형태 데이터를 AJAX  방식 호출을 통해 Single Page Application( SPA)을 구성하는 개발방식을 그동안 지향하였습니다. 그에 따른 Angular.js나 Ember.js와 같은 JavaScript MVC framework 사용을 추천한 상황이고요.

 하지만 현실적으로 AJAX로 도배된 상태로 전 사이트를 구축하기 도 힘들고 모든 서비스를 ajax 호출하는 client 구현 및 이용은 어려운 점이 많습니다.

즉 MSA방식을 통한 비즈니스 로직이나 업무로직은 이상적으로 구축할 수 있으나 실제 각 front-end 쪽은 MSA 방식을 지향하는 현실적인 최적의 구축 방안이 많이 부족한 상태입니다.

 Baas(Backend as a Service) 관련 솔루션이나 API 구축 업체는 각 채널에서는 HTTP를 넘나드는 Direct Public API 방식의 호출을 지향하고 있지만 다음과 같은 문제점을 가지고 있습니다.

 

 Stateless 방식 API

 - MSA에서 API Gateway 서버나 Baas 단에서는 상태를 유지하지 않기 때문에 매번 Security Key 과 같은 고유 키 값을 전송

 - 웹에서 session 유지 기능을 구현하기 어려운 점이 있어서 매번 API 호출 시 사용자 id를 넘기거나 위 기능을 할 수 있는 비즈니스 로직을 별도로 개발하는 문제가 발생

 

보안문제

 - 무상태(stateless)로 해당 비즈니스 로직을 처리해야 하기 때문에 서비스 개발 시 그 수간 필요한 모든 데이터를 입력 받아서 처리

 - 특정 사용자 아이디나 주요 키값 등이 노출되어 보안상 문제가 발생

 - ex) 나의 결제내역 API 호출 시 나의 ID를 의미하는 user id 또는 그에 대응되는 사용자 고유 키값을 넘기는데 이 부분은 Http Proxy등을 통해 변조될 가능이 높음.

 

서비스의 결합의 성능 문제

 - 개별단위로 된 API를 조합해서 filtering 된 데이터를 이용하고자 하는 경우 client 단에서 모든 데이터를 처리하면 성능이 늦어진다.

 - 개별적 API 를 결합하여 서비스하는 경우 저 사양 client channel (ex 모바일 웹) 문제점 발생

 

최적화

 - 각 채널 별 최적의 UI 용 최적의 데이터 구성의 어려움.

-   UI 관련 최적화된 기능 구현을 위한 로직 구현의 어려움.

 

 

 

 

BFF : Backend for Frontend

 

BFF는 Bank of America, ThoughtWorks 등 Cloud 서비스 관련 전문가인 Phil Calcado 에 의해 최초 정의된 용어로 Backend for Fronted 의 약자입니다.

즉 frontend 만을 위한 backend 시스템 패턴으로 이해할 수 있으며, UI 및 API Data 연계를 위한 중앙통제 성격의 backend 기능만을 구현하여 각 채널 별 UI 시스템 구성을 최적화 할 수 있도록 해주기 위한 구축 패턴으로 이해하면 되겠습니다.

BFF 패턴을 적용하는 장점은 위에 언급된 Direct API 호출 client 구현의 문제점을 대부분 해결할 수 있는데 있습니다.

필요한 데이터를 API 호출을 통해 이용하고 session관리가 가능하며 각 UI 채널을 위한 최적의 Presentation 코드등 (HTML,CSS,JSON등)을 관리하고 UI 비스를 담당하는 역할로 볼 수 있습니다.

위의 경우와 같이 필요한 데이터는 필요 API를 호출할 수 있으며 미리주요 코드성 데이터등을 적재(load)하여 성능을 개선하거나 UI 개발의 확장성을 높일 수 있습니다.

따라서 새로운 서비스 채널이 생기면 사용자 접점의 frontend 개발을 BFF 방식으로 처리하고 손쉽게 시스템을 확장할 수 있는 장점을 가지고 있다. 물론 비즈니스 로직은 MSA 기반의 API로 되어 있다면 재활용 성을 극대화 하여 생산성을 향상시킬 수 있습니다.

 

구현 기술

MSA의 API구현을 개발자가 원하는 기술로 구현할 수 있듯이 BFF의 backend 서비스는 어떠한 기술을 써도 상관이 없습니다.

database 나 각종 Middleware에 대한 기술 종속성이 없으므로 frontend관련 기술에 집중할 수 있으며 기존 WAS(Web Application Server)처럼 방대한 구축을 하지 않아도 가벼운 web server 로 구축이 가능한 장점을 가지고 있습니다.

 

 실제 기술 

 - J2EE의 JSP.Servlet 으로만 구현

 - NodeJS를 통한 구현

 - PHP 기술로 구현

 

어떠한 기술을 이용해도 상관없지만 사실 어떠한 기술이 최적화되어 잘 사용될 수 있을지는 또 다른 문제이긴 합니다.

 구현되는 API를 호출하고 session 관리 등을 하기 위해서는 생각하지 못한 고려사항들이 아직 많이 남아있습니다. 실제 저희 회사 시스템 일부 및 다른 기업의 웹서비스 구축에서 BFF 패턴을 이용해 보았지만 아직도 더 많은 연구를 통해 저희 솔루션(DBridge 및 coreFRAME)에 적용되고 확장해야 할 부분이  많아 남아있는 상태입니다.

 

이 BFF 패턴도 MSA 와 마찬가지로 아직 효과적 UI Channel을 구성하기 위한 하나의 패턴으로 좀더 다듬어 져야 할 문제점을 가지고 있지만, 몇몇 국내 기업들이 Cloud 기반 또는 PaaS 기반의 변화에 대한 움직임을 보이면서 2~3년내 IT 산업 변화에 대응하며 준비되어야 할 기술로 판단됩니다.

You never change things by fighting the existing reality.

To change something, build a new model that makes the existing model obsolete. 

Buckminster Fuller