IT의 중심에서

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

API 중심의 데이터 아키텍쳐 2

지난 주 글에 이어서 두번째 글입니다.
엔터프라이즈 기업환경에서 고비용의 ETL솔루션을 쓰는 것은 당연한 선택입니다.
API, Input Buffer와 RDB등의 기술아키텍쳐는 기존 기술과도 닮아 있어 사실 특별한게 아닙니다.

하지만 트래픽이 많은 사업환경에서 라이센스 비용은 굉장히 큰 부담일 수 밖에 없습니다.
Apigee가 만든 nucleus를 살펴보면 앱개발, API 비즈니스 환경이 오픈소스, 대용량 데이터, 다양한 데이터의 수집과 전송에 초점이 맞추어져 있다는 것을 알 수 있습니다.

Apigee의 이런 시도는 현재 제휴와 협업이 활발한 실리콘밸리의 비즈니스 환경을 짐작해 볼 수 있습니다.
제 눈에는 몇가지 특이한 점이 보이는데요.
다음에 설명드릴 기회가 있지 않을까 싶습니다.


※ 원문 : API-Centric Data Architectures-2 (2014.06.25)
※ 저자 : Anant Jhingran

이전 글에서 우리 비즈니스에서 운영되는 데이터 구조를 만들기 위해 어떻게 API를 이용하고 있는지 말씀드렸습니다.
우리의 목표는 우리의 고객들이 디지털 전쟁에서 승리하도록 돕는 것입니다.
즉, API와 앱 개발자들을 도우기 위한 다양한 방법을 우리가 알고 있어야 한다는 뜻입니다.
그래서, 우리는 3가지 관점에서 자가운용이 가능한 nucleus라는 단위 시스템을 만들었습니다.

1. 데이터 로딩이 가능한가?
– Apigee 고객지원 파트가 고객 트래픽과 티켓시스템을 연결하고 싶어할 수도 있습니다. 이 경우 티켓정보를 nucleus에 추가할 수 있어야 합니다.

2. 단순, 복잡한 모델의 운영 및 분석이 가능한가?
– 민감하게 관리해야할 고객민원 지표의 추출 및 가공이 가능해야 합니다.

3. 원시데이터나 복잡한 쿼리, 모델들을 추출할 수 있는가?
– 지난 90일 간의 Top 10 트래픽 증가률을 별도로 추출하여 계산할 수 있어야 합니다.

또다른 숙제는 과거가 아니라 미래를 대표하는 API 와 데이터 중심의 아키텍쳐를 만드는 것이었습니다.
계속하자면 다음과 같습니다.

1. 예를 들면 ‘ETL을 쓰지 않는다.’ 그래서 우리는 전혀 ETL을 쓰지 않았습니다.

2. ‘모든 것은 API로 만든다.’ 그래서 우리는 모두 그렇게 만들었습니다.

3. ‘이 시스템을 모두 Apigee stack 에 기반해서 만든다.’
우리는 고객들과 우리 자신을 위해 ‘올바로 데이터와 API를 다루는 대표 사례’가 되려고 했습니다.
이또한 우리는 거의 성공했습니다. ‘거의’라고 한 이유는 Piper모듈 내의 Buffer Queue가 Amazon SQS로 Apigee stack이 아니기 때문입니다.

Nucleus 아키텍쳐

Apigee nucleus Architecture

Apigee nucleus Architecture

내부를 설명드리겠습니다.

1. 다양한 모델들(고객민원, 제품사용량 등)이 돌아가는 Apigee Insights engine이 중심에 있습니다.
이 아키텍쳐에서 Insights의 인스턴스는 Weissman 이라고 부릅니다.

2. 람다 아키텍쳐 관점에서 생각한다면, 우리는 서비스 레이어에 RDB를 사용하고 있습니다.
Postgres에 대한 우리의 사랑이 여기에 잘 나타나있습니다. 서비스 레이어의 인스턴스를 Maester라고 부릅니다.

3. Weissman과 Maester에는 Piper라고 불리는 모듈을 통해 데이터가 유입되고 나가게 됩니다.
데이터 버퍼로는 Amazon SQS를 사용하고 있습니다.

4. ingest 는 Apigee내 모든 사람을 위해 독립적으로 운용되는 서비스입니다.
Apigee내 모든 사람들은 API를 이용해 Piper로 데이터를 전송할 수 있습니다. (물론 올바른 key값이 있어야 합니다.)
API가 요청하는 시점에 Weissman과 Maester내에서 Subject Area 가 자동으로 만들어지게 됩니다.

5. POST API 는 이렇습니다. : https://nucleus.apigee.net/ingest/send
Payload 내에는 Weissman 과 Maester에서 해야하는 일에 대한 스키마가 포함되어 있습니다.
대쉬보드와 사전 고객대응을 위한 어플리케이션들로부터 데이터를 수집하는 것은 독립 서비스로 운영됩니다.
API 호출은 이렇습니다. : https://nucleus.apigee.net/api/account/{acct-key}.

nucleus 는 모두 node.js로 만들어졌습니다.
그리고 Github 상의 Volos, Trireme and lembos 모듈을 통해 열심히 알리고 있습니다.
다음 블로그에서 우리는 nucleus 내의 5가지 컴포넌트를 살펴보겠습니다.
우리는 우리 회사를 위해 우리 제품을 사용하는 것을 좋아하고 있습니다.
하지만, Dog Fooding이라는 용어는 별로 좋아하지 않습니다.

이 글을 도와주신 Apigee 개발팀 내 Jeff West, Ben Tallman, Randy Solton, and Yegor Pomortsev 에 대해 많은 감사를 드립니다.

PS)

  • Dog Fooding, 개발자가 자기가 개발한 모듈을 테스트하거나 사용해보는 것.
  • Volos, API 디자인패턴을 추가할 수 있게 만든 모듈셋
  • Lembos, Node.js를 이용해서 Hadoop기반의 MapReduce를 실행하게 해주는 Java Library
  • Trireme, JVM내에서 Node.js 스크립트를 실행시켜 주는 모듈
  • Advertisements

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

    1. 이현웅
      2014년 7월 14일

      항상 좋은 글을 올려주셔서 감사합니다.

      • subokim
        2014년 7월 14일

        도움이 되신다니 감사합니다. (_ _)

    답글 남기기

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

    WordPress.com 로고

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

    Twitter 사진

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

    Facebook 사진

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

    Google+ photo

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

    %s에 연결하는 중

    정보

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

    내비게이션

    누적 조회수

    • 956,079 Visits

    페이스북 페이지

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