오픈API와 오픈 플랫폼의 구성요소 [3부] - 오픈 플랫폼의 구성요소
상태바
오픈API와 오픈 플랫폼의 구성요소 [3부] - 오픈 플랫폼의 구성요소
  • 이상익 이사
  • 승인 2019.12.09 04:34
  • 조회수 10369
  • 댓글 0
이 콘텐츠를 공유합니다

[1부] 오픈 API 란 무엇인가
[2부] 오픈 API 디자인과 문서화
[3부] 오픈 플랫폼의 구성요소

 

1, 2부에 걸쳐서 웹 API가 무엇이며, 어떻게 디자인 하고 문서화 하는지 알아보았다. 오픈 웹 API를 배포하고 서비스를 실행할 수 있는 오픈 API 플랫폼에 대하여 알아보려 한다.

오픈 API 플랫폼은, 오픈 API가 배포되어 요청/응답 처리하는 front-end 영역과 API 서비스 로직이 실행되고 back-end 시스템과 연계하는 midlle-end 영역으로 나눌 수 있다.

 

APIM(API Management)

오픈 플랫폼의 Front-end 에 위치하여 API 사용자로부터의 API 요청을 처리하는 API Gateway와 API 이해관계자들간의 의사소통 창구의 역할을 API Portal로 구성되며, 이렇게 만들어진 오픈 API를 별도의 오픈 API Store 에 판매할 수도 있다.

투이톡_오픈api_1.jpg
[그림 1] APIM 아키텍처 구성요소 / 출처: www.apiacademy.co

 

API Gateway

API 처리 요청에 대한 Proxy 로서 API 서버(혹은 AP 서버) 호출 대행 접점이다. API 처리를 위한 일종의 고도화된 웹서버 인 셈이다. 따라서 웹서버를 굳이 두지 않아도 되고 회사의 아키텍처 표준이 있을 경우 웹서버를 앞 단에 둘 수도 있으나 이 경우 API Gateway 솔루션에서 제공하는 보안, 성능 처리 등의 유용한 기능 일부를 제한 받을 수 있다. 그렇다면 API Gateway 의 기능은 어떤 것들이 있을까?


1. 보안

 - API 호출 제어: 북한, 중국 등 서비스 대상 외 국가 혹은 부정업체로부터의 호출을 제외하거나(Blacklist 방식), 계약된 업체나 사용자로부터만 호출을 허용하는 방식(Whitelist 방식)이 있다.

- API 인증: API Key 방식, OAuth2.0 인증 등을 통한 API 사용 인증 처리로써 API Portal 에서 발급받은 Key, Credential 등을 활용한다.

- API 전송 데이터 위변조 방지: 클라이언트와 서버 간 상호 통신 중 해커에 의해 중요한 파라미터를(예: 계좌번호) 위변조 하여 부정 사용되는 것을 막기 위한 처리로써 파라미터와 함께 전송하는 해쉬코드를 통하여 확인한다.

- SQL Injection, XSS, CSRF, XML 방화벽 등 웹 어플리케이션 방화벽 기능<-자막처리

 

2. 성능

- 지능형 부하분산: 백엔드의 복수의 API 서버에 트랜잭션을 분산 처리하여 동시 처리율을 높일 수 있는 설정 선택 가능하다. 또한, API 서버 등의 장애 발생 시 자동 fail-over 처리, 관리자에 의한 설정으로 fail-back 처리 – 제외된 API 서버의 재참여 – 설정 등이 가능하다(가용성).

- 유량제어: API 별로 호출할 수 있는 최대 횟수, 동시 호출 개수 등을 설정하여 특정 API의 과도 사용으로 인한 시스템 자원의 고갈 및 타 사용자 및 API 의 성능에 영향을 주지 않도록 조절할 수 있다. 어플리케이션 레벨의 QoS(Quality of Service) 라고 볼 수 있다.

- 캐싱: 반복된 조회 API 의 값을 캐싱하여 처리 성능을 향상

- API Orchestration: 다수의 API를 조합하여 새로운 복합 API 조합 가능하나, 단순한 조합이 아니라면 API 서버에서 기능을 구현하는 것이 복잡한 룰을 처리하고 모니터링 하기 용이하다.

 

API Portal

API 소비자와 제공자가 소통할 수 있는 통로이며, API 제공자는 API portal을 통하여 API Gateway에 인증 Key, 사용기관 등을 설정할 수 있다. API는 일반적으로 프로그램에서 호출되므로 개발자들이 API 사용 허가를 요청하고, 서버에서 제공하는 API 스펙을 확인하고 간결하게 사전 테스트 해볼 수 있는 기능이 제공되는 공간이다. 또한 API 사용 현황에 대한 간단한 모니터링, 기간 별 과금 정보를 확인하고 API 제공자와 조율할 수 있다.


- Documentation: API 목록, 사양(Specification)을 등록, 검색, 확인할 수 있다. 또한, 샘플 데이터를 통해서 간단히 API 동작을 테스트하고 피드백을 남길 수 있다. 이를 위하여 앞서 살펴보았던 RAML, OAS 3.0, Swagger 등을 활용한다.

- Registration: API 사용자, 관리자 등을 역할 기반으로 등록하고 사용기관에서 자체적으로 관리할 수 있는 기능을 제공한다(접근제어). API Key, Credential을 요청, 발급받고 관리가 가능하다.

- Analysis: API 사용 현황을 API 사용자 측에서 확인할 수 있는 그래프 혹은 표 등을 제공하며, API 사용에 대한 과금 정책 및 기간별 사용 현황 분석 및 금액을 확인할 수 있다.

- Community: API 생태계를 지원하기 위하여 API 관련 개발자들 간의 소통 통로로서, FAQ, Q&A 질의 대응, 신규 API 디자인 등을 위한 개발자 커뮤니티 게시판 등을 제공한다.

 

API Platform으로의 확장

API Portal, API Gateway 만 있으면 오픈 API 플랫폼이라고 할 수 있을까? APIM은 단지 외부와 연결할 수 있는 기본적인 통로일 뿐이다. 오픈 플랫폼이란 여러 이해관계자가 다방향으로 소통하고 새로운 서비스가 창출될 수 있어야 할 것이다. 이를 위해서 서비스 융합(convergence), 서비스 조합(orchestration)을 할 수 있는 레이어들이 필요하다.


- Business Service Layer: 금융, 유통, 물류, 제조, 통신 등 업계에서 활용되는 통상적인 비즈니스 기본 컴포넌트(예: 은행의 경우 계좌관리)를 조작할 수 있는 기능과 이를 활용한 핀테크 업체와의 융합 서비스 컴포넌트(예: P2P 투자자/대출자관리)의 서비스 흐름을 구현할 수 있는 어플리케이션, 데이터 처리 레이어이다. 일반적으로 API 서버라고 불리우며 이 레이어와 이를 실행하고 관리할 수 있는 Framework Layer가 있어야 다양한 서비스 융복합을 할 수 있다.

- Management Layer: API 사용자에 대한 빌링, 정산, 플랫폼 모니터링 및 관리 포털 기능 등을 제공한다.

- Framework Layer: API의 서비스 로직을 프로그래밍하고 배포, 온라인/배치 실행, 개발표준 관리, 공통 라이브러리, 플랫폼 보안 기능 등을 제공하는 플랫폼 코어 프레임워크 영역이다.

- Integration Layer: 플랫폼 제공자의 Back-end 시스템과 다양한 통신 방식으로 거래 연계, 전문변환, 모니터링 한다.

- Analytics Layer: 플랫폼에 축적된 다양한 데이터를 분석, 시각화 하고 CX 에 활용할 수 있도록 데이터를 가공하여 제공한다.
 

투이톡_오픈api_2.jpg
[그림 2] 오픈 API Platform 아키텍처 예시

플랫폼 성격에 따라 기능을 세분화 혹은 통합하여 Layer를 조정하거나 선별 적용할 수 있다.

 

오픈 API 플랫폼 고려사항

 

1. 중소 규모의 핀테크 업체와 비용 절감

중소 규모의 핀테크 업체와 서비스 개발을 하고 플랫폼을 통하여 이윤을 창출하려면 일종의 박리다매 형태로 플랫폼이 운영되는 경우가 많다. 즉, 고가의 솔루션, 인프라를 투입하기에는 채산성이 맞지 않기 때문에, 오픈소스 솔루션을 적극 도입하여 구매 및 유지보수 비용을 대폭 없애고, 워크로드에 유연한 인프라 가상화, 퍼블릭 클라우드를 활용하여 플랫폼 수요가 폭발적이거나 외면당했을 경우에 투자 비용을 절감할 수 있도록 플랫폼을 구축해야 한다. 오픈소스 기술 전문가의 육성, 확보가 쉽지 않은 과제이긴 하다.


2. platform 보안 개인정보

오픈 플랫폼 서비스는 기존 다른 곳에서 이미 제공되고 있는 서비스가 아닌 경우가 대부분이기 때문에, 플랫폼 참여업체의 개인정보 보유, 활용에 따른 정보보안 법, 규정에 위배되지 않는지 검토하고 이에 대한 대책을 적용하는 것이 중요하다. 다수의 참여자를 연결하는 오픈 플랫폼의 특성상, 보안이 뚫리면 플랫폼 내부뿐만 아니라 연결된 시스템으로까지 보안침해사고가 전파되기 용이하므로, 보안 가이드를 세밀하게 정립하고 참여자와의 계약 형태에 따라 이를 준수할 것을 요구하고 상시 감시하는 활동이 필요하다.


3. 플랫폼 운영 거버넌스, 인력 확보

오픈 API 플랫폼은 특성상 자체 완결형이 아니라 수많은 다양한 시스템과의 연계, 서비스 조합이 필요한 공간이다. 하지만 지향하는 플랫폼 비즈니스과는 무관하게 기존의 시스템 운영 방식과 유사하게 조직, 인력 구성을 하는 경향을 볼 수 있다. 디지털 트랜스포메이션의 비전에 따라 플랫폼의 방향성은 정해지지만 외부 참여자에 따라 플랫폼 비즈니스는 어떻게 확장되어 갈지는 미리 규정하기 힘들다. 세상의 의미있는 서비스를 발굴하여 자신의 비즈니스를 충돌시키고 새로운 플랫폼 서비스를 재창조하는 비즈니스 DMZ(demilitarized zone) 영역인 것이다. 열린 사고와 잡다할 정도로 다양한 비즈니스, 기술 경험을 가진 인력과 이를 뒷받침 할 수 있는 플랫폼 거버넌스가 필수적이라 하겠다.

 

- 끝 -

 

 

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.