Software Design 2020年1月号より「マイクロサービスアーキテクチャ」
表題の特集を読みました。ページ数は少ないので、さっくりまとめられていいですね。自分はマイクロサービスについては初心者です。
全体として
マイクロサービスはどれくらいの大きさになるのかというのは、初心者の自分が最初に思い付いた疑問です。
特集を通読すると、若干の幅があるように感じます。一番細かく刻んでいるのは、第1章の増田さんだと思います。例えば、「顧客管理」では大きすぎであり、「顧客識別情報」「取引履歴」「連絡先」等々への分割を試みるべきとしています。
この段階で、新たに二つの疑問が生じました。一つは、「マイクロサービスに階層はあるのか？」というものです。説明を読んでいると、なんとなく階層はないようなイメージがあります。まぁ、階層化できるくらい強い依存があるのなら、最初から一つでいいような気もする・・・のでしょうか？
もう一つの疑問は、「マイクロサービスはいくつまでならバラして大丈夫なのか？」というものです。大丈夫というのは、メリットがデメリットを上回っているのか、に置き換えていいです。
メリットは以下が挙げられていました。
- 変更にかかる時間が短くなること、コストが下がること
デメリットには以下が挙げられていました。
- 通信のオーバーヘッドが発生すること
- 障害発生時の原因追跡や復旧が難しくなること
- 全体像を理解するのが難しくなること
なんとなくですが、二桁後半あたりから、人間の頭では全体像を理解できなくなってきそうな気がしますね。
以下、各章を見ていきます。
第1章 マイクロサービスって何？ アプリケーションを「ばらばら」にする理由
アプリケーションをいくつかのサービスに分割します。分割というのは、実行環境を分けることです。そうして分割されたサービスをマイクロサービス（複数形でマイクロサービシズ）としています。
マイクロサービスが低コストになった理由に、実行環境の仮想化や、クラウド上で実行できるサービスの拡充が挙げられていました。これについては、自分の理解が不十分な気がしています。テスト*1・デプロイが簡単・自動になったからコストが下がったという理解であっているのでしょうか？
マイクロサービスのサービスの結びつきとして、「同期・非同期」および「直列・並列」の2軸で説明されていたのは、非常にわかりやすいと感じました。
第2章 ひとつひとつのサービスはどのように作れば良い？ モノリシックなサービスを上手に切り分けるコツとは
まず、どう分けるか？どれくらいの大きさで分けるか？という話がありました。ここについては分かりやすく、特に変だなというところはありませんでした。
非同期的なサービスでも、アクターモデルとイベントモデルの2つがあると述べられています。個人的には、イベントモデルに若干かすったことがある程度で全然わからんのですが、とにかくパフォーマンスを上げる、もしくはスケールさせるために同期を捨てている、という感覚は持っておきたいと思いました。
面白かったのは、サービス間の（通信）プロトコルが何が適しているかというトピックで、HTTP（REST）がトップだったことです。すごいぞHTTP。ちなみに次におすすめされていたのは「クラウドサービスの独自プロトコル」でした。マネージドサービスで、非同期的なイベントモデルを扱うのに適しています。逆に言うと、シンプルな同期的な結合であった場合は、慣れ親しんだHTTPで問題ないということですね。
一つ気になったのは、購入キャンセルの例で
購入キャンセルのイベントに対して各サービスの動作がきちんと整合していなければなりません。システムとして全体の状態を管理してトランザクションするしくみになっている必要があるでしょう。
とあるのですが、そのトランザクションの仕組みをどう確保するかは相当大事なのでは・・・と思いました。直後に書いているRedisのPub/Sub機能とかはイベントモデルを実現する手段に過ぎないようですし。
第3章 サービス同士はどのようにつなげればいい？ 作って学ぶBackends For Frontends
いくつかのマイクロサービスから返ってきた結果をまとめ、クライアントに返すBFF（Backends For Frontends ）が紹介されています。ここらへんからマニアックになっていきます。
Server Side Rendering は名前くらいは聞いたことありますが、マイクロサービスの文脈で語られるのだなと思いました。多分他の背景もあるような気がします。しかし、Next.jsをVueのライブラリだと思っていた自分には全然わからない。
第4章 複雑なマイクロサービスをどのように管理すればよい？ サービスメッシュを実現するIstioとOpenShift Service Mesh
サービス個別に監視ツールを導入したとき、システム全体の監視はどうするのかという問題があります。サービスメッシュとは、新設したサービスメッシュ層で監視に必要な情報（ログ）を収集する仕組みになります。
正直難しすぎてよく分かりませんでした。ただ、数が増えて全体的な監視が難しくなった時の解決策として、最近注目されているようです。
おわりに
自分みたいな何もわからない人から、ガチ勢まで読ませる内容だと思います。
一点気になったのは、字数を収めるために、日本語が若干おかしいような印象を受ける文がいくつかあったかなということです。削りに削って、いま自分が読んでいる文章があるのだなと察せられます。
*1:特にエンドツーエンド
