マイクロサービス・アーキテクチャ
rtok.icon マイクロサービス・アーキテクチャはマシンごとに機能を分割し、それぞれのマシン間のやりとりによって一つのサービスを実現するためのアーキテクチャである。
概要
ビジネスロジックを組み合わせて処理を行う
構成する機能は別のマシン(仮想マシンも含む)に分かれていて通信で値を投げ合う(独立した機能と呼ぶ)
モノリシック・アーキテクチャと対比される
背景
頻繁な変更や機能追加に対応できるようにする必要がある
kimitoboku.icon アジャイルと相性がいいかは,ステージによる,初期からマイクロサービスで開発するのは基本的に難しい.マイクロサービスで開発出来るのは,現在作りたい物の必要な機能を正しく分割出来るくらいまで,システムについて熟知出来た後からなので,マイクロサービスになってからはアジャイルとの相性はいいが,アジャイルで初めてマイクロサービスとの相性はよくない.最初からマイクロサービスで設計しようとすると,ウォーターフォールのくらい設計してから作り始めないと厳しい 採用事例 Amazon, Netflix LINE クックパッド Gunosy
kimitoboku.iconクックパッドはマイクロサービスに取り組んではいるが,本体は巨大なモノリシックのRoRアプリケーション 実装
仮想マシンではオーバヘッドが大きくなる(ホストOS↔ゲストOS+ハイパーバイザー↔アプリケーション) kimitoboku.icon仮想マシンの方がオーバーヘッドが大きくなるはか仮想マシンの実装次第なんですが,このマイクロサービスの文脈の場合は,Dockerの1コンテナ1プロセスという設計がうまく合致しているための方がDockerが選ばれる理由なんじゃないかと思います. kimitoboku.icon最近は,マイクロサービスが増えた結果,RESTでは厳しくなってきているので,マイクロサービスをまとめるためにGraphQLなども使われる 利点
サービスごとに開発チームが得意な言語(開発環境)で開発できる
サービスごとに仕様変更を持ちかけるだけでOK
システム障害の特定が容易
サービスを堅牢でセキュアにしやすい
バグが入りにくい
avashe.icon個々のサービスについてはそうかもしれないけど、実際にはそう簡単ではなくて、SLO達成の舞台がノードからネットワークに移るのでChaos Engineeringが必要になってきますよねrtok.icon rtok.iconChaos Enginnering含めた想定外の事象に対処する方法に関してそれなりに知見がある人がいないとできなさそうということか。
avashe.iconスケールすればネットワークと分散システムの知識は避けられないと思います。私も弱いのでやっていきたい。rtok.icon 実情
従来のモノリシック・アーキテクチャからマイクロサービスにするのはかなり大変
新しいサービスの開発ではマイクロサービス的にやるのはあり
参考