블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

API 플랫폼에 대한 소개

아키텍쳐 /대용량 아키텍쳐 | 2013.10.30 01:02 | Posted by 조대협

API Platform

조대협


근래에 들어서 모바일 애플리케이션의 발전과 SNS의 발전과 더불어서 Open API 에 대한 관심도가 급격하게 높아졌다. Open API, API를 내부 사용자뿐만 아니라 외부 개발자에게까지 공개해서, 외부 개발자가 API를 이용해서 새로운 서비스를 만들도록 하는 모델이다. 근래에 들어서는 API만 전문적으로 개발 및 서비스를 해서 이를 통해서 수익을 창줄하는 비지니스 모델까지 생겨나고 있다. 이런 배경으로 API 관리에 대한 중요성이 대두되었는데, API에 대한 쉬운 관리, 모니터링 및 유료화 그리고, API에 대한 편리한 사용법, 샘플 코드 및 메뉴얼 제공하는 시나리오가 필요하게 되었는데, 이를 하나의 플랫폼 형태로 묶어 놓은 것을 API 플랫폼이라고 한다.

API 플랫폼은 크게, API에 대한 단일 진입 포인트 역할을 하는 게이트 웨이와, API 문서나 샘플 코드들을 제공하는 API 포탈, 그리고 API 서비스 상황을 모니터링할 수 있는 관리 모니터링 기능으로 분리된다.

제품군으로는 크게 두 가지 종류로 나뉘어 지는데, 예전 SOA(Service Oriented Architecture) ESB (Enterprise Service Bus) 를 게이트웨이로 사용하면서 발전해온 SOA 진영쪽 제품과, 처음부터 API 플랫폼으로 디자인되서 서비스되는 이 양쪽으로 나뉘어 진다. 전자의 경우에는 MuleSoft WSO2 API 플랫폼이 대표적인 예이고, 후자의 경우에는 apigee,3scale,Mashery,Layer 7(CA) 등이 있다. 전자의 경우에는 ESB를 기반으로 하기 때문에, API에 대한 워크 플로우 기능이 매우 강력하다. 워크플로우 기능이란, 메세지를 변경하거나 라우팅 또는 다른 기능을 추가하는 부분이 매우 강력하다.반면 포탈이나 모니터링 기능들은 후자에 비해서 약하다. 후자의 경우에는 워크 플로우 기능은 약한 반면, 유료화 모델이나 다양한 사용자 계층 지원 그리고 무엇보다 포탈이 매우 강력하다.

Apigee Mashery 같은 경우는 설치형이 아니라 클라우드 형으로 서비스를 제공하는데, 개발사나 개발자가 API를 개발하고, API 서비스는 클라우드에 설치된 이 API 플랫폼을 통해서 하면, 이 플랫폼이 중간에 Gateway 역할로써 API에 대한 워크플로우 기능 및 모니터링 기능등을 제공하면서 함께, 포탈등의 부가 기능을 제공한다.

예전에 미국 캘리포니아 실리콘 밸리에 있는 apigee 를 방문할 일이 있었다. 긴 시간은 아니었지만, 서비스와 인력들에 대해서 이야기를 나눌 기회가 있었는데, 재미있는 점은 인력 구성원의 많은 인원들이 기존의 SOA 회사 출신(BEA)으로 이루어져 있다는 것이다. API 서비스의 근간은 SOA를 기반으로 하고 있으며, 기술 역시 SOA ESB와 연관된 기술을 많이 사용함으로 이해할 수 있었다. 회사의 분위기는 여타 실리콘 밸리의 회사와 같이 매우 젊고 활기에 차있었다.

API 플랫폼을 서비스로 제공하는 만큼 운영에 대해서 많이 신경을 쓰고 있었는데, 실제로 플랫폼을 서비스로 제공하면서 얻는 노하우는 대단하리라고 본다.

 

주요 기능



API 인증

먼저 API를 사용하려면, API를 호출하는 클라이언트가 인증이 된 사용자인지 아닌지를 구분할 수 있는 인증 Authentication 기능이 필요하다. 앞에서 REST API 보안에서 설명한것 처럼, API Key를 발급하거나 OAuth 기반의 인증을 제공할 필요가 있다. 근래의 API Platform OAuth 기반 인증을 제공하는 것이 일반적인 흐름이다.

사용자 인증

사용자 인증은 API 인증을 받기 위한 Key OAuth 인증을 받거나, 또는 API 포탈에 접속해서 메뉴얼을 보거나 Admin 으로써, API에 대한 모니터링을 하기 위해서 필요한 시나리오이다. 사용자를 API를 사용하는 일반 사용자, 내부 관리자 또는 일반 사용자/Silver/Gold 등의 레벨로 나눠서 서비스를 하는 등의 다양한 서비스 시나리오에 대한 사용자 관리 기능을 제공한다.

SLA management

SLA Service Level Agreement의 약자로, 서비스에 대해서 약속한 수준의 비기능 요건을 만족해주는 것을 이야기 한다. 쉽게 이야기 해서, API 제공자별로 하루에 5000건의 call을 제공하기로 했으면, 5000건 까지만 제공한다던지, API 사용자별로 하루에 1000건의 call을 제공한다던지의 계약 레벨별로 서비스 수준을 조정해줄 수 있는 기능을 제공한다.

Mediation

Mediation은 들어온 API 호출에 대해서 변형을 가하는 것이다.예를 들어 원래 API가 주문 API였다면, 나중에, 주문 API에 포인트 적립 API를 추가해준다거나 API version에 따라서 라우팅을 해주거나 하는 등의 기능을 한다. 이렇게 원래 호출 내용에 대해서 변경을 가하는 것을 Mediation이라고 한다. 그러면 몇가지 Mediation 패턴에 대해서 소개한다. 이런 Mediation 패턴은 앞서 설명한 Workflow 기능에서 제공되며, 이 챕터의 뒤에서 소개할 SOA 아키텍쳐의 ESB의 부분을 참고하면 좋다.

아래는apigee 플랫폼에서 workflow를 적용하는 UI 화면의 일부이다. 보통 workflow IDE같은 개발환경에서 순서도 같은 흐름에 노드를 추가하는 환경으로 적용한다.



출처 : https://blog.apigee.com/detail/api_platform_update_api_proxy_editor_traffic_composition_reports_updated_policies

 

Routing

들어온 메세지에 대해서 라우팅 작업을 한다. 예를 들어서 결재 시나리오에서 API request 필드에 국가 필드가 나뉘어져 있으면, 국가 필드에 따라서 API를 그 국가의 서버로 라우팅을 하거나, 헤더에 정의된 API버전에 따라서 구 API서버나 새로운 버전의 API서버로 라우팅 하는 시나리오를 예로 들 수 있ㄷ.

Function adding

이 기능은 기존에 있던 API 기능에 새로운 기능을 추가하는 것이다. 예를 들어 기존 구매 프로세스에서 포인트 적립 기능을 추가해주는 것등을 할 수 있다. 기존의 클라이언트나 서버의 구현의 변동없이 새로운 기능을 추가할 수 있다.

Message Transformation

메세지 변경은 들어온 메세지를 다른 포맷으로 변경해주는 것이다. 단순하게는 JSON XML로 변경해준다거나 필드가 틀린것을 맵핑 해준다거나 두 필드를 한필드로 합친다거나 반대로 한필드를 여러 필드로 나눈다거나 하는 등의 기능을 제공 한다.

Monitoring

모니터링은 API 서비스 사업자로써 아주 중요한 위치를 차지하는데, API의 사용량, 어떤 API가 많이 사용되는지, 국가별, APP별 통계량이나 평균 응답 시간등에 대한 리포트는 서비스의 정상적인 상태 체크 뿐만 아니라 향후 API 서비스 개발에 유용하게 사용될 수 있다. 아래는 apigee에서 제공하는 API Traffic 모니터링 화면이다.



출처 : http://apigee.com/docs/enterprise/content/monitor-performance-your-api

 

Monetization

Monetization은 쉽게 이야기 해서 유료화 모델이다. API의 과금 정책 월단위, 사용자 단위, 호출 단말건,호출 건수별 등 다양한 정책을 적용할 수 있다. 이에 더해서 이벤트 가격 적용, 또는 사용자 수나, API 호출 수를 구간 별로 나눠서 금액을 책정하는 등의 다양한 가격 정책을 적용할 수 있는데, 이를 Charging이라고 하며, Charging을 하기 위해서는 누가? 어떤 디바이스가 언제? 어떤 API를 호출했는지 등의 Charging을 하기 위한 기초 로그 데이타를 수집하고, Charging이 끝난후에, 신용카드등을 통해서 Payment를 하게 되면, 서비스 국가에 따라서 세금을 내는 Taxation 그리고 세금을 땐 수익을 다시 API 제공자에게 분배 하는 정산 (Pay out)등의 인프라를 제공한다.

Portal

포탈은 API 사용자가 로그인을 한 후, API에 대한 사용법이나 샘플 또는 테스트 등을 할 수 있는 기능등을 제공한다. API를 만드는 것도 중요하지만 편이성을 제공해서 API사용자가 잘 사용할 수 있데 하는 것이 중요하다.

단순하게 메뉴얼 뿐만 아니라 API사용자 입장에서 얼마나 API를 사용했는지 어떤 API가 많이 호출되었는지등의 자료는 API 사용자 입장에서도 과금에 관련되고 또 향후 서비스 개선을 위한 중요한 자료이기 때문에, API 포탈의 기능은 매우 중요하다.

외부 API 사용자를 위한 기능도 있지만, API를 판매하지 않고, 내부에서 다른 부서에 API를 제공하기 위해서도, 쉽게 API를 사용할 수 있게 함으로써 개발 생산성을 높일 수 있다.

만약에 API 메뉴얼 또는 테스트 사이트를 제공하고 싶은 경우에는 Swagger 라는 오픈소스를 참고해보기를 권장한다. https://github.com/wordnik/swagger-core

Swagger API에 대한 메뉴얼 자동 생성 및 테스트 사이트 생성 기능을 제공한다. 아래는 Swagger에 의해서 생성된 API 메뉴얼 사이트 인데, API에 대한 사용법 및 샘플 데이타를 제공하고, 무엇보다 테스트 호출을 날려볼 수 있는 기능을 제공한다.



출처 : http://swagger.wordnik.com

API Governance

이런 API Platform을 사용함으로써 얻게 되는 부가적인 이득은 API 에 대한 관리이다.

내부적으로 API를 사용하면 가장 크게 문제가 되는 것은 API에 대한 관리인데, 여러 부서가 일을하는 경우, API 의 메세지 포맷이나 API URL Naming convention이 다른 일이 발생한다. 특히 SOA 시절의 WSDL 기반의 WebService를 사용하면 최소한의 표준 준수가 가능했으나 (WebService 자체가 표준이다.) REST/JSON의 경우 WSDL과 같은 메세지 포맷에 대한 표준 자체가 없기 때문에 자유도가 증가하여 표준화가 매우 어렵다.

예를 들어 A부서는 version URI에 넣어서 http://myapi/adduser/version3 와 같은 식으로 서비스하거나, B부서는 version HTTP header에 넣어서 http://myapi/addorder URI로 제공하고http headerx-myapi-version:3 식으로 넣어서 같은 회사인데도 API 메세지 포맷에 대한 통일 성을 읽어 버릴 수 있다.

API플랫폼을 사용하면, 서비스 되는 API는 모두 API 플랫폼을 통해야 함으로 API 플랫폼 관리 조직이 API가 표준에 맞지 않으면 API 플랫폼을 통해서 서비스 하는 것을 거부할 수 있으므로, API 표준 준수를 강요할 수 있는 강제성을 통한 통제성을 확보함으로써 API를 중앙에서 집중 관리할 수 있는 장점이 생긴다.

 

Windows Azure AppFabric Service Bus

Azure 클라우드에는 AppFabric이라는 또 하나의 서비스가 있습니다. 간략하게 설명하자면 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합입니다. 그 중에서 이번에는 Service Bus에 대해서 설명해보겠습니다.
사실 이 Service Bus를 이해하는데 다소 시간이 걸렸습니다. 왜냐하면 제 기술적인 백그라운드가 SOA이고, 그 중 가장 중요한 컴포넌트 중 하나가 Enterprise Service Bus (ESB)니까요. 그런데 Azure의 Service Bus 개념은 약간 다릅니다. Internet Service Bus (ISB)라는 개념으로 설명을 하더군요.
Enterprise Service Bus가 Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing 및 Transformation에 집중을 한다면,
Internet Service Bus는 Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있습니다. 보안과 Message Routing,Transformation은 AppFabric내의 다른 서비스 (ACS와 WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 합니다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 하지요.

Message Relay
앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이 입니다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있습니다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 합니다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 거지요.
여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 있을까요? 보통 J2EE의 WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있는데요. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용합니다.
원리인 즉, 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭습니다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입니다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없습니다. 예전 웹로직 할 때 봤던 아키텍쳐인데 여기서 보니 또 새롭네요..
 

Direct Connection
다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 느립니다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋습니다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없습니다. (NAT에 의해서 변경이 되기 때문에)
이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려줍니다. 이 기법은 주로 인터넷 메신져에서 많이 사용하는데요. 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 합니다.

Message Buffer
위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService나 REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하지요. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용하네요. 
 


어쨌든 간에, 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었습니다. 그게 Message Buffer라는 것인데, 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받습니다. 다른 플랫폼들은 Message Buffer에 REST (XML/HTTP)를 이용해서 접근합니다.
 
일단 이렇게 해서 타 플랫폼과의 상호 운용성을 확보해주는 방법인데, Native WCF를 써서 SOAP이나 REST를 쓰는 것에 비해서 어떤 장점이 있는지는 좀 봐야 알 수 있을 것 같습니다.

Message Exchange Pattern 변환
먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus는 API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.
조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.
http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원
처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.
Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있습니다.
쉽게 정리해서 보자면 “클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 입니다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘입니다.
대략 AppFabric의 모듈 중 하나인 Azure Service Bus에 대해서 살펴봤고, 다음 글에서는 AppFabric의 Work Flow 모듈과 보안 모듈(ACS)에 대해서 살펴보겠다.
 


대충 위와 같은 개념인데, ACS가 계정에 대한 통합 역할을 하는 셈입니다.
ACS는 SAML등과 같은 표준을 지원하기는 하지만 Active Directory를 잘 지원합니다. 기업의 계정 시스템이 Active Directory 기반이라면 아주 쉽게 통합이 된다는 겁니다.
그 외에도 Facebook, Open ID와 같은 SNS 기반의 ID 체계와도 통합 로그인을 할 수 있는 Feature를 제공하고 있습니다.
ACS에 대한 내용은 나중에 좀 더 알아보도록 하겠습니다.

 


Oracle Coherence나 Open source memcached와 같은 메모리 그리드 솔루션은 아키텍쳐를 그리는 데 상당한 효과를 발휘한다. 메모리 그리드랑, 간단하게 이야기 하면 Java의 HashTable이 무제한 용량으로 확대 가능하고, 어느 server instance에서도 접근이 가능하며, 장애시 Fail over를 통해서 고가용 서비스가 가능한 솔루션을 이야기 한다.
물론 Oracle Coherence가 .NET도 지원하기는 하는데, 이왕이면 MS도 이런게 있었으면 했는데, 새 윈도우즈 Server에 나왔다.
AppFabric이라는 일종의 윈도우즈 미들웨어인데, 일단  데이타 그리드의 성격을 가지고 무제한 클러스터링이 가능하다.. (물론 열어봐야 알겠지만..)

데이타 그리드로써도 의미가 있지만, ASP.NET은 기본적으로 Http Session Clustering을 지원하지 않았기 때문에, 이 Data Grid를 이용하면 WebLogic이나 WebSphere와 같은 Session Clustering을 지원할 수 있다. (그것들 보다 지능적이게 만들려면 개발은 좀 들어가겠지만...)

아울러 AppFabric은 ESB Feature를 제공하는데, WCF (Windows Communication Foundation - 일종의 통신 Framework)과 WF (Workflow Foundation - 워크 플로우)를 통해서 비지니스 프로세스를 그리고 배포할 수 있다.  WF와 WCF 기반의 코딩이 들어가야 하는 미들웨어성에 가까운데, 대신 코딩을 하는 만큼 오히려 성능이나 아키텍쳐 구성에는 유리한면이 있을듯 하다.
Oracle Service Bus가 높은 가격과 고수준의 XQuery/XSL 기술이 있어야 한다면, 상대적으로 좀더 Flexible하게 고성능 ESB를 디자인할 수 있을듯.
기본적으로 IIS는 Java의 WAS처럼 Thread Base 모델이 아니라 Process Base 모델이기 때문에, Hot Deploy나, 장애 전파 영향도는 낮을 듯 하다.

AppFabric이 나오면서 기존의 ESB 역할을 해주던, BizTalk의 Postion이 애매해지는데, David Chappel의 AppFabric WhitePaper를 보면

As the figure shows, an activity in the workflow service can issue a request to BizTalk Server. This might be done using a Web service or in some other way; BizTalk Server provides adapters for several different communication styles. However it’s accomplished, the request can then be handled by business logic running in BizTalk Server. This logic is implemented as an orchestration, and it knows how to carry out the next step in this process. Here, for instance, the orchestration uses another BizTalk adapter to communicate directly with the ERP application. Any response can be sent back through the same components.

출처 : http://download.microsoft.com/download/7/F/8/7F8BD8A0-EB05-4DB5-A5A4-DD1D3C909A0A/Introducing_Windows_Server_AppFabric.pdf


AppFabric이 전통적인 ESB 역할을 하면서 Service Orchestration등을, BizTalk는 EAI 또는 SOA에서 Service Enablement Layer처럼, Legacy 시스템들을 Itnegration해서 Expose하는 역할로 포지셔닝이 된다. (참고 : http://wm.microsoft.com/ms/msdn/windowsserver/WFDemoFinalHighRes.wmv )


일단 1 core에 몇천만원이나 하는 Service Bus보다, MS의 AppFabric은 단돈 몇백만원에 OS에 포함되어 있고, 개발 용이성도 높으니, REST와 함께해서 아키텍쳐를 한번 조합해봤으면 좋겠는데..

혹시.. 사이트에 좀 불러주실분...??? 손!! :)