IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

API 중심의 데이터 아키텍쳐

Apigee에 흥미로운 글이 올라와서 번역해보았습니다.
Anant씨는 IBM 정보관리 부문의 CTO였는데 Apigee로 넘어와서 데이터 관련 전략을 담당하고 있습니다.

클라우드가 기반 시스템이 되자 텍스트, 미디어, 사진 등 쌓이는 데이터가 다양해졌습니다.
그 기반에서 운영되는 DB도 다양해졌습니다.
NoSQL DB의 도입, 비정형 데이터의 증가는 복잡성을 증가시키는 새로운 고민거리일 수 밖에 없습니다.
제휴라도 하게 되면 데이터를 기술적으로 어떻게 주고받을 것인가 하는 것은 중요할 수 밖에 없습니다.
데이터 연동을 위해 제휴사가 별도의 ETL Adaptor 를 구매하는 경우가 발생되기도 합니다.
Api는 이런 환경에서 좋은 대안이 될 수 있습니다.

이런 이슈 해결을 위해 Apigee는 다음과 같이 두가지 측면에서 API 사용을 권장하고 있습니다.


※ 원문 : API-Centric Data Architectures, (2014.02.03)
※ 저자 : Anant Jhingran

우리 Apigee는 API의 힘을 믿고 있습니다.
그러나 API 는 우리 고객 및 사용자의 사업확장을 위한 것만은 아닙니다.
API는 우리 제품의 핵심이어야 하기도 합니다.
즉, 우리가 출시하는 모든 제품들은 API를 가지고 있어야 한다는 뜻입니다.
만일 그렇지 못하더라도 최소한 API는 우리 회사의 경영 방식이어야만 합니다.

우리는 이것을 시험해보기로 했습니다.
‘API 중심의 내부 아키텍쳐는 우리회사 운영을 가능하게 할 수 있을까?’

우선 우리의 상황을 정리해 보았습니다.

1) 우리는 여러가지 지표를 기반으로 Apigee를 경영하고 있습니다.
기술역량, 제품 사용률, 고객 만족도, 결함, 개발자 등은 실질적으로 Apigee를 운영하는 지표들입니다.

2) 기술지원 및 영업 프로세스는 Salesforce.com 를 이용하고 있습니다.
전체적 기술이슈들은 Jira 상에서 관리되고 있습니다.
기술 지원 이슈가 발생이 되면 Jira 를 통해 티켓이 담당자에게 발행됩니다.

3) 우리 제품은 같은 아마존 클라우드 상에서 운영되고 있지만, 배포체계는 Salesforce.com과 완전히 독립되어 있습니다.

키 맵핑

우리가 풀어야할 첫번째 숙제는 두 시스템의 키값을 매핑하는 것이었습니다.
우리는 키맵핑 API 들을 별도 레이어로 만듬으로써 서로 다른 두 시스템 간의 공통적이면서 단일화된 데이터를 얻을 수 있었습니다.

API 중심 데이터 아키텍쳐란 반드시 어느 정도의 키 매핑을 필요로 합니다.
우리는 운이 좋게도 그런 시스템을 정확하게 만들었습니다.
Apigee Edge 시스템입니다.
우리는 Apigee Edge 시스템을 통해 키맵을 유지하고 있습니다.

데이터 유입단계에서 Account-id, Org-id 매핑, Salesforce.com 데이터와 Apigee Edge 시스템간의 데이터 일관성 확보

데이터 유입단계에서 Account-id, Org-id 매핑,
Salesforce.com 서비스와 Apigee Edge 시스템간의 데이터 일관성 확보

대량 적재

우리가 직면한 두번째 도전은 언제 대량 적재를 해야 하는지, 언제 원천 시스템에 접근할 것인가 하는 것이었습니다.
복합분석을 하기 위해서는 반드시 데이터베이스 내의 데이터가 있어야 합니다.
그래서 우리는 여러 시스템으로부터 관련 정보를 수집하기 위해 Data API를 활용한 크롤러(정보 수집 로봇)를 만들었습니다.

데이터 중심의 아키텍쳐는 1건 씩 정보를 제공하는 API들로부터 대량으로 정보를 수집하기 위한 메커니즘을 필요로 하게 됩니다.
우리는 이 기능을 파이썬으로 개발했습니다.

물론, 우리는 대량 수집 방식에만 전적으로 의존하지는 않았습니다.
새로운 데이터 요소와 API 가 매일 추가되고 있기 때문입니다.
그러나, API 는 자주 버전업시킬 수 있다는 장점이 있습니다.
이 특징은 전통적인 ETL방식보다 훨씬 효율적입니다.
물론 ETL은 없어지지 않을 것입니다.
그러나, 좀 더 API 중심이 되기 위해서는 그 모습이 변할 필요가 있습니다.

현실적으로 새롭게 등장하는 시스템(기업형 시스템들은 그닥 그렇지 않지만 SaaS 시스템이라면 거의 대부분)들이 외부와 연계하기 위해 거의 데이터 API를 이용하고 있음을 고려한다면, API 중심의 데이터 아키텍쳐의 등장은 당연한 것입니다.
그리고 시간이 흐르면서 지배적인 데이터 아키텍쳐 모델이 될 것입니다.

만일 관련 데이터를 API를 통해 얻고 있다면, 매핑방법을 API로 열어두는 것도 좋습니다.
그러면 당신은 동일한 유형의 인터페이스로부터 데이터를 받거나 매핑할 수 있게 될 것입니다.

— Apigee 제품개발팀의 Jeff West와 Ben Tallman이 도와주었습니다.

Advertisements

API 중심의 데이터 아키텍쳐”에 대한 1개의 댓글

  1. 핑백: API 중심의 데이터 아키텍쳐 2 | IT의 중심에서

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2014년 7월 9일에 님이 API와 기술, 번역글에 게시하였으며 , , 태그가 지정되었습니다.

내비게이션

누적 조회수

  • 951,818 Visits

페이스북 페이지

%d 블로거가 이것을 좋아합니다: