GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。
経緯
突然なんですが、PJ内で色々ありまして、急遽設計を大幅に変更することになった。
我々のチームではよくあることだが、チーム全員がいい意味でまとまっているので今回もなんとかなりそうかなと思っています。その変更は以下のような感じ。
※なぜこうなったかは今回はなしで。
要は
- Meta data
- jsonファイルを1行ずつ分割
- 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のコンテナにデータが作成されたらそれを1行ずつ読んで、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にpublishする