初ブログです。
マイクロサービスについて以下の書籍を読んでみたんだけど、いくつか疑問に思うことがあるので そのことについて話したいと思う。
マイクロサービスが生まれた経緯、思想、メリットも大体分かった。 だが、以下の３点については実際の実装イメージがつかなかった。
- UI合成
- DB分割
- 認証
UI合成
UI合成とは、１つの画面に各マイクロサービス側で用意されたUIを提供すること。
疑問
- javascriptやcssの競合はないのか？
- 実際に合成はどうやるのか？iframeを使うのか?
- 各サービスでUIは必要なのか？
javascriptやcssの競合はないのか？
各マイクロサービスでUIを用意するということは、javascriptもcssも用意するという認識でいるが、 例えば、バージョン違いのプラグインを利用していたらどうなるのか。 表示が崩れたり、動作しなかったりしない？ そもそも、iframeで表示するから関係ない？
実際に合成はどうやるのか？iframeを使うのか?
UI合成の概念は分かったが、実際どうやって組み込むのか。 地道に、各サービスからhtmlを取得して、DOM操作による表示？
各サービスでUIは必要なのか？
折角、各サービスで独立しているのにUIのデザインなどを合わせないといけなくなる。 最近だとSPAが流行っているので、サービス側はデータのみ返却するだけでいいのでは？
実際はどうなの？
DB分割
マイクロサービスの設計思想だと、データベースは各サービスで分けることになっている。 つまり、１サービス＝１データベース。 別のサービスからは別サービスのデータベースを直接見ずに、WebAPI経由で取得することになる。
疑問
- データベースのインスタンスはどこに作るの？
データベースのインスタンスはどこに作るの？
業務でAWSを利用しており、DBはRDS（Aurora）を使っている。 マネージドサービスを利用することで、運用コストを抑えられる。
この状況で、サービスごとにDBインスタンスを作成するとコストが膨大になる気がする。 少なくともRDSは他のサービスと比べて、比較的高価。
自前でEC2等でサーバを立ち上げて、DBサーバをインストールして運用してる？
本当はデータベース自体は分けない？
実際はどうなの？
認証
スケールアウトを想定し、セッション情報はサーバに持つことは避けたい。 memcachedやRedisのようなキャッシュサーバに保存するシーンも増えてきた。 最近では、jwt（ジョット）というトークンの仕組みが出ててきた。
これは、セッション情報をBase64エンコードやハッシュなどを組み合わせて１つのトークンを生成し、認証に利用する。 これを使うと、アプリサーバにもキャッシュサーバにも情報は保存する必要がない。 セッション情報は、生成したトークンに含まれることになる。
これらはログイン認証後に発行され、以降のリクエストで必要になる。（リクエストヘッダなどに設定）
疑問
- ログイン不要のサービスからの認証はどうする？
ログイン不要のサービスからの認証はどうする？
バッチから各サービスのWebAPIを叩く場合の認証はどうする？ もちろん、バッチなのでログイン情報とかはないので、トークンもない。
あくまでも想定ですが、 バッチからのリクエスト専用のトークンを予め生成し、アプリケーションで持っておく。 ログイン認証後とバッチの認証トークンを以下のように区別する。
ログイン認証後のリクエスト時 Authorization: Bearer ABCD1234
バッチ Authorization: Bearer Batch-EFGH5678←「EFGH5678」は予め生成したトークン。リクエスト時に「Batch-」を付与。
認証チェック時にトークンを「-」でsplitし、配列の１番目が「Batch」の場合はバッチからのリクエストとして扱う。
なので、ログイン不要なリクエストが発生する機能ごとに、トークンを発行しておくことになる？
実際はどうなの？
終わりに
積極的にマイクロサービスを推進している立場として、ぜひとも理解しておきたい内容ですので、 実際に経験されている方からのアドバイスをいただけたら幸いです。
