DBridge for serverless architecture

Serverless Architecture

최근 Software 업계에서는 MSA(Micro Service Architecture)가 떠오르면서 이를 구현하는 방법으로써 Serverless architecture(서버리스 아키텍처)라는 주제가 아주 핫합니다. 이미 관련 서적과 컨퍼런스도 활발하게 생겨나고 있으며, 오픈소스 프레임워크와 함께 많은 유명한 업체들이 AWS, Azure, Google cloud 등의 프레임워크 서비스를 내놓고 있고 사용자 그룹이 형성되는 등 업계의 관심이 뜨겁습니다. 

Serverless에 대해 아직 명확하게 정의된 개념은 없지만 Martinfowler의 블로그를 인용한다면 아래와 같이 정리될 수 있을것 같습니다.

What is Serverless?

1. Serverless was first used to describe applications that significantly or fully depend on 3rd party applications / services (‘in the cloud’) to manage server-side logic and state. These are typically ‘rich client’ applications (think single page web apps, or mobile apps) that use the vast ecosystem of cloud accessible databases (like Parse, Firebase), authentication services (Auth0, AWS Cognito), etc. These types of services have been previously described as ‘(Mobile) Backend as a Service’, and I’ll be using ‘BaaS’ as a shorthand in the rest of this article.
2. Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party. (Thanks to ThoughtWorks for their definition in their most recent Tech Radar.) One way to think of this is ‘Functions as a service / FaaS’ . AWS Lambda is one of the most popular implementations of FaaS at present, but there are others. I’ll be using ‘FaaS’ as a shorthand for this meaning of Serverless throughout the rest of this article.

위 인용구의 정리에 따르면 BaaS와 FaaS를 합쳐 놓은것을 Serverless라고 표현합니다. FaaS의 대표적인 예로는 AWS Lambda가 있지요.

본 포스팅에서는 CyberX의 기업용 Open API Server Solution인 DBridge를 통해 API Gateway로 활용하여 FaaS를 구현할 수 있는 가능성을 보여드리도록 하겠습니다.

Architecture Diagram

전자상거래 시스템을 구현한다고 가정해 보겠습니다. 전통적인 아키텍처는 아래와 같은 간단한 구조를 이루고 있을것입니다.

클라이언트의 요청은 하나의 서버가 클라이언트의 모든 요청에 대한 처리를 담당합니다. 이런 구조는 애플리케이션이 복잡해질수록 서버단의 로직복잡도가 늘어나게 되고 하나의 로직이 다른 로직에 미치는 영향에서 자유롭지 못합니다.

많은 다른 Serverless 프레임워크의 FaaS처럼 DBridge또한 각각의 로직을 작은 단위로 분리할 수 있습니다.

즉 위 그림과 같이 DBridge 서버와의 통신을 통해 로직을 실행하고 그 결과를 받아서 클라이언트 단에서 처리가 가능해 집니다. 이 경우 앱이나 다른 stand alone application같은 경우에 별도의 서버 인스턴스가 필요없어질 수 있습니다. 즉 application을 위한 서버를 각각 별도로 운영하지 않고도 DBridge만으로 서버단의 로직을 처리할 수 있습니다.

DBridge

DBridge는 기업내 다양한 데이터 소스와 연계하여 Enterprise 환경에 최적화된 Public/Private API 서비스를 개발 및 관리 할 수있는 솔루션 입니다. JSON, XML, SOAP등 다양한 통신 protocol을 지원하며 인증키 및 IP제한, SSL등의 기능으로 데이터 통신 보안기능 및 다양한 인증기능을 제공합니다.

DBridge의 여러가지 기능 중 권한 혹은 인증키를 통한 보안, RESTful API 생성 등의 OPEN API 서비스에 관련된 기능을 통해 API Gateway로의 역할이 가능하며, RESTful API를 통한 function(DBridge에서는 이를 Business Object라고 정의합니다)접근을 통해 비지니스 로직을 함수단위로 나누어서 FaaS와 같이 사용하는것을 가능하게 해줍니다.

Example

이제 간단하게 DBridge에서 현재 시간을 반환해주는 Business Object를 보여드리겠습니다.

미리 생성해 놓은 Business object의 정보를 보여주는 화면입니다. JSON형식 뿐 아니라 XML, HTML, SOAP등 여러가지 형식으로 데이터를 반환받을 수 있어 유연한 사용이 가능합니다.

정보화면의 아래로 가면 실제로 어떤모양으로 데이터를 받을 수 있는지 테스트가 가능합니다. 여기에선 JSON과 XML형식으로 테스트를 진행했습니다.

URL을 curl을 통해 조회해보면, 역시 데이터를 잘 반환하는 것을 확인할 수 있습니다.

본 포스팅에서는 데모이기 때문에 편의상 보안에 대한 아무런 설정이 없이 진행이 되고 있습니다. 하지만 실제 사용시에는 보안이 아주 중요한 이슈가 됩니다. DBridge는 기업의 내부에서 인증된 사용자만 API를 이용할 수 있도록 인증키방식과 IP방식을 사용하여 보안을 제공하며, 이는 위와같은 간단한 UI로 설정할 수 있습니다.

Business Object의 로직을 작성할 수 있는 화면입니다. Java와 JavaScript를 이용해서 작성이 가능합니다.

맺음말

지금까지 DBridge를 Serverless Architecture의 관점에서 간단히 소개했습니다. 많은 기능을 포함한 솔루션을 하나의 포스팅에서 다 설명하기엔 부족하지만, 서버리스 아키텍처의 관점에서 가능성을 전달하기엔 충분하지 않았나 생각됩니다. 은탄환은 없다는 말처럼 단점도 함께 가지고있는 구조이지만, 복잡한 애플리케이션을 단순화시키고 재사용 및 유지보수에 유리한 확실한 장점도 있기때문에 목적에 맞게 잘 사용한다면 아주 강력하고 편리하게 사용될 수 있을것이라 생각됩니다.

혹시 이 포스팅을 보시고 dBridge에 더 많은 관심이 생기셨다면 여기를 통해 더많은 정보를 얻으시기 바랍니다.

참조

[1] http://martinfowler.com/articles/serverless.html