GYAO의 ts입니다.
우리 팀은 올 퍼블릭 클라우드에서 Microservice Architecture을 채택한 차기 백엔드를 설계 중입니다.

경위

갑작스럽습니다만, PJ내에서 여러가지 있어, 급히 설계를 대폭 변경하게 되었다.
우리 팀에서는 자주 있는 일이지만, 팀 전원이 좋은 의미로 정리되어 있기 때문에 이번에도 무척 꽤 그럴까라고 생각하고 있습니다. 그 변화는 다음과 같은 느낌.
※왜 이렇게 된지는 이번에는 없이.



요점은

Meta data

json 파일을 한 줄씩 분할

AzureFunction에서 Servicebus에 topic으로 publish

AzureFunction이 subscribe하고 DocumentDB에 저장합니다.

DocumentDB에 대해서는 rest로 검색시킨다

Log data

Sevicebus에 topic으로 데이터를 publish.

AzureFunction이 subscribe하고 DocumentDB에 저장합니다.

MachineLearning의 input data resource는 DocumentDB를 지정. 정기적으로 캡처.

학습 결과는 rest로 제공.

같은 흐름이다.

여기 에서 쓴 디자인과는 크게 변화했다. . .

대개 Azure 일색이 되어 왔다. Apigee만 떠 있기 때문에 아마 AzureAPIManagement라든지 될까. 그대로 Apigee에서도 재미 있다고 생각하지만.

Blob 컨테이너

Blob의 컨테이너에 데이터가 생성되면 그것을 한 줄씩 읽고 servicebus에 publish한다.


json:testLines.json

{ "original_id" : "1", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }
{ "original_id" : "2", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }
{ "original_id" : "3", "b":false , "c":0 , "d":1 , "e":2 , "f":0.345 , "g":"あ" , "h":"い" }

여기서 original_id가 문서의 식별자가 되지만 DocumentDB에 저장할 때 id라는 이름이 있으면 DocumentDB의 key로 등록되어 버리므로 그것은 피하고 싶다 (이쪽에서 key는 발행하고 싶다). 그래서 id라는 요소가 없는지 Functions로 체크할 필요가 있다.

다음 번

AzureFunctions를 사용하여 위의 json을 읽고 Servicebus에 게시