GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。

経緯

前回の投稿にもあるとおり、最近は我々のチームはAzureを使い倒す形になってきたわけだが、最近はGoogle、MicrosoftやAmazonの担当者の方々もご来社いただいて、設計のアドバイスや効果的な使い方等をサポートしていただいています。

そんな中、チーム内でずっとこんなデザインで進めてきたのだが、進めていくうちにかなり変わってきた。
社内政治的なところもあるのだが、そもそもこのシステムを作って具体的に何を成し遂げるのかが社内でいまいち明らかになっておらず、
ハコはできたものの実際作るものが決まった時にどうなるかがわからない。今できることとしては

ベンダーの切り替えさえもできるように極力疎結合にデザインする
費用感を掴んでおく
拡張性、再利用性を担保する

くらいかなと。

データ連携をするある程度大きなシステムを作る際、どう作るにしてもほぼ必ず通る道はあるわけで、それを抽象化したものが、Enterprise Integration Patternsだが、何か作りたいと思った時に手持ちのコンポーネントを組み合わせて短時間で大きな成果を上げられるようなシステムを目指す。そういう意味ではLogicAppはとてもいいアプローチだと思っている。欲をいえば、コネクタをカスタマイズできるといいかと思う（特定のインターフェイスを実装することでコネクタを作成できてデプロイできるみたいな）。
LogicAppを採用すると親和性からGatewayもAzureになってくる。うまくできてるなぁ。

現在のデザイン

機能	役割	過去のハンズオン
Database	Metaデータの保存先。直にクライアントに公開していいと思っている。MLとかでごにょごにょやった結果の保存先、データを正規化してその保存先としても使える。	-
BlobStorage・DataFactory	大量データをファイルで扱うケースがあるので、Blobにコンテンツが置かれたら一定の処理が走るようにしたい（DataFactoryではなく、stream処理の方がいいかなと最近思っている）。逆にLogicAppでエクセルを吐き出して、fileストレージとして保存とかもできる。NASとして担当者が端末にマウントすれば自動レポートの生成ツールみたいなこともできる。	functionsを使用したハンズオンパート1、パート2
LogicApp	新規APIや、タイマー処理をここで構築していく。提供されているコネクタでは足りないケースがあると思うので、restAPIを別途作成して補完する方針。	AzureLogicAppsでAPI wrapper
kubernetes・swagger	restAPIの作成場所。別にここでなくてもいいのだが、チーム内で作ってきて慣れているのと、フルマネージド、高機能なので今の所GKE。	GoogleCloudで汎用Database構築4 - kubernetes & SpringBoot & intelliJ & Apache Camel - パート1、パート2、パート3
APIManagement	webserviceを束ねるGatewayとして使用。認証を一元管理する。	APIManagement + LogicApp

懸案は速度。どのくらい性能が出るかは今後ストレステスト等を行って評価していく。