Sketch of ConvBridge - aragorn/home GitHub Wiki

• 원시데이터 저장소, 데이터변환기 API, 검색엔진에 내장된 데이터수집 프로그램으로 실시간 데이터 연계 시스템을 구성한다.
• 동일한 인터페이스를 활용하여 이기종 데이터저장소 간의 Extract, Transform, Load 기능을 제공한다.
• 데이터변환기 API, 데이터수집 프로그램을 하나로 묶어 ConvBridge 라 부른다.

데이터변환기 API는 임의의 백엔드 스토리지에 대한 데이터 변환 기능을 구현한다.

소스 데이터를 효과적으로 연계하기 위해 전체 목록, 변경내역 목록 등 2가지 방식의 목록을 제공하고, 이를 이용해 이기종 DB 사이의 데이터연계를 구현한다.

전체 목록은 특정 데이터베이스에 대한 자료를 빠짐없이 모두 나열할 수 있는 인터페이스를 제공한다. 전체 목록을 나열하기 위해 API 호출을 여러차례 수행해야 할 수 있으며, 일반적으로 여러차례 수행하여야 한다. 여러차례 API를 호출하는 과정에서 각 데이터의 일관성(Consistency) 문제가 발생할 수 있으며, RDBMS에서 일반적으로 제공하는 특정 시점의 snapshot을 제공하지 않는다.

변경내역 목록은 mysql binlog 와 같은 시간순서에 따른 데이터 CRUD를 빠짐없이 모두 나열할 수 있는 인터페이스를 제공한다. 변경내역 목록은 각 데이터변경 이벤트에 대해 일련번호를 부여하고, 이 일련번호 순서에 따라 데이터 변경 결과를 접근할 수 있다.

전체 목록과 변경내역 목록, 2가지를 이용하여 이기종 DB 사이의 데이터연계를 구현하게 되며, 데이터 연계 도중에는 연계된 DB의 데이터 정합성이 일시적으로 깨어질 수 있으나, 결국 시간이 지나 정합성을 맞출 수 있게 되는 Eventual Consistency 모델을 따르게 된다.

이러한 데이터 변환기 API를 'Converter'라고 이름 짓는다.

• 정적(static) 연계 : 소스 데이터의 전체 목록을 이용해 데이터 연계하는 것을 가리킨다.
• 동적(dynamic) 연계 : 소스 데이터의 변경내역 목록을 이용해 데이터 연계하는 것을 가리킨다.
• next_url : 목록을 나열하는 API에서 이후 호출할 API 주소를 next_url 이라 한다.

REST(Representational State Transfer) 방식의 API를 구현한다.

그러나, 일반적인 RESTful API와 달리, 데이터 입력/수정에 대응하는 API를 제공하지 않는다. ConvBridge는 그 특성상 소스 데이터의 변경 내역을 읽기전용 방식으로 제공하며, 소스 데이터에 대한 수정이나 입력 기능을 제공하지 않는다. 소스 데이터에 대한 수정, 입력은 해당 소스 DB에서 직접 제공하는 것을 사용하면 된다.

API의 URL에서 다음의 항목을 명시적으로 키워드로 구분하여 드러낸다.

1. 원출처 데이터의 이름
2. 목록나열 방식 : static or dynamic
3. API 리비전
   서비스 중인 기존 코드는 테스트 없이 수정/배포하기 어렵다. 따라서, 구현된 코드는 revision 단위로 배포하고, 사용하지 않는 revision의 코드는 운영자가 점검하여 서비스에서 제거한다. 사용하지 않아야 하는 revision이 사용 중인 경우에도 운영자가 적극적으로 API 사용자와 협의하여 사용하지 않도록 전환한다. 이러한 revision 체계를 통해, API 개선을 빠르게 진행하고, 배포 과정에서 호환성 충돌 문제를 회피한다.
4. 데이터 조회 방식
   소스 데이터를 목록 형태로 접근하는 list, ID를 파라메터로 지정하여 특정 문서를 조회하는 each, 2가지 조회 방식을 제공한다. each의 경우, 일반적인 데이터 연계 과정에서 사용되지 않고, 데이터확인, 제한된 데이터 조회, 디버깅 등 용도로 사용된다.
5. 변환된 데이터 형식의 이름

http://cb.dev.example.com/v1/blog/r123/static/list.breeze2 http://cb.dev.example.com/v1/blog/r123/static/list.xml http://cb.dev.example.com/v1/blog/r123/static/each.xml http://cb.dev.example.com/v1/blog/current/static/list.breeze2 http://cb.dev.example.com/v1/blog/r123/dynamic/list.breeze2 http://cb.dev.example.com/v1/blog/current/dynamic/list.breeze2

데이터 조회 방식에 따라 아래와 같은 파라미터를 사용한다. 파라미터가 입력되지 않은 경우, next_url만을 출력하게 되고, 데이터는 출력하지 않는다. 이 경우 출력되는 next_url은 정적 데이터 연계의 경우, 전체목록의 첫번째 목록에 해당하고, 동적 데이터 연계의 경우 최신 목록에 해당한다.

• list : from, count, to
  소스데이터 목록의 각 entry에 일련번호를 부여하고, 이 순서에 따라 데이터를 접근하게 된다. 이러한 목록의 일련번호를 sequence id라 통칭한다. from 파라미터의 값인 일련번호는 대소비교가 가능한 값이면 충분하며, 실제 이 값을 해석하는 것은 API 내부 구현체이다. 외부에서는 이 값을 해석할 필요가 없다. to 파라미터는 데이터 연계 프로세스의 종료조건을 가리키며, from의 값이 to의 값보다 커지는 경우, 연계를 종료하면 된다.
• each : docid=xx docid=x1,x2,x3,x4 docid=x1&id=x2&id=x3 파라로 지정한 특정한 문서를 조회한다. TODO - 파라미터의 이름과 값 등 형식은 추후 결정.

데이터 연계 프로세스를 단순화하기 위해 목록 접근 API의 경우, 연속된 이후 API 호출의 URL을 제공한다. API 클라이언트 입장에서는 제공되는 이후 API 호출 URL만을 반복적으로 계속 따라가는 것으로 해당 목록을 모두 접근할 수 있게 된다. 이때, API는 빠짐없이 모든 데이터를 접근할 수 있다는 특성을 보장하게 된다.

API 클라이언트가 목록의 다음 호출 링크를 이용하게 되면, API 호출 파라메터의 세부 내용에 대해 관여하지 않게 되는 장점이 있다.

API에서 변환하여 제공하는 데이터의 형식으로는 다음의 것들이 있다.

• custom json - 검색엔진으로 데이터를 연계하기 위해 사용한다.
• source tag - 검색엔진으로 데이터를 연계하기 위해 사용한다.
• mysql - MySQL 데이터베이스로 자료를 연계하기 위해 사용한다.

API 서버는 단일 서버가 아니라 여러 서버로 구성될 수 있다. 이때, 특정 서버에 장애가 발생하는 경우, API 클라이언트가 해당 요청을 다른 서버에 재시도하여 오류를 복구하게 된다. API 클라이언트는 next_url을 참조하여 이후의 API 요청을 수행하게 되는데, API 서버는 복수의 next_url을 제공하며, 이 next_url 은 어느 것을 선택하여 호출하여도 동등한 결과를 내보내어 준다. API 클라이언트는 복수의 next_url에 대해 임의의 순서로 요청을 시도하면 되고, 모든 next_url에 대해 호출실패하는 경우, 반복적으로 요청을 재시도 한다.

API 서버는 복수의 next_url을 리스트 형으로 내보내어 준다. 1개의 null을 list 항목으로 갖는 경우, next_url이 비어있는 것이다. 리스트 자체가 존재하지 않고 null이 되는 경우는 없어야 한다.

"next_urls" : ["http://host1/path/api", "http://host2/path/api"] - 정상적인 경우
"next_urls" : [null] - 정상적으로 next_url이 비어 있는 경우
"next_urls" : null - 없는 경우임. API서버는 이러한 응답을 하지 않음.

API 서버는 정적 API를 통해 해당 데이터를 처음부터 끝까지 중복없이, 빠짐없이 접근할 수 있는 인터페이스를 제공한다. 이때, API 클라이언트는 여러차례 API 서버를 호출하게 되며, 각 응답결과는 데이터 일관성이 유지되지 않을 수 있다. 데이터 일관성이 깨어진 경우, 동적 데이터연계를 통해 데이터 변경 부분을 반영하는 경우, 시간이 지나 일관성이 유지될 수 있다.

정적 데이터 연계의 경우, 초기 호출 URL 이후 next_url을 반복적으로 호출하여 전체 데이터를 접근할 수 있으며, next_url이 빈 값이 되는 경우, 전체 데이터를 모두 접근한 것이며, 정적 데이터 연계가 완료된 것이다.

API 상세 파라미터에서 정적 색인의 경우, 최초 시도시 from=seqid1&to=seqid2&count=100 과 같은 next_url을 제공한다. API 서버는 파라미터에서 전달되는 to 값에 해당하는 범위까지 데이터를 제공하고, 그 이후에는 next_url을 빈 값으로 응답한다.

동적 데이터 연계의 경우, 초기 호출 URL 이후 next_url을 반복적으로 호출하여 최신 데이터를 접근할 수 있다. 그러나 정적 데이터 연계와 달리, 완료시점이 없으며, 동적 데이터 연계를 유지하려는 경우, 무한히 next_url을 계속 접근하여야 한다. 동적 데이터 연계를 일시적으로 중단하는 경우, API 클라이언트는 이 next_url을 기억해 두고, 데이터 연계를 재개할 때 다시 호출하면 된다.

정적 데이터 연계의 경우, 어떤 url에 대해 1회의 데이터 연계가 완료되는 시점이 존재한다. 이 경우, next_url이 빈 값이 된다. 데이터 연계가 완료되는 시점은 더이상 데이터가 존재하지 않는 경우이거나, from 파라미터의 값이 to 파라미터의 값보다 커지는 경우이다. from, to 파라메터의 값을 세부적으로 살펴보면, 전체 데이터의 양과 현재 진행 정도를 추정할 수 있다.

동적 데이터 연계의 경우, 최근 데이터까지 모드 연계가 완료되는 시점이 일시적으로 존재한다. 이 경우를 판단할 수 있는 응답을 API 서버에서 제공할 수 있다. TODO

• http://en.wikipedia.org/wiki/Eventual_consistency
• http://en.wikipedia.org/wiki/Representational_state_transfer
• http://ko.wikipedia.org/wiki/REST