マイクロサービスの間違った捉え方

  インフラ >     根本の仕組み >  

• いわゆるマイクロサービス
• 過去の事例
• 問題解決できていない例
• マイクロサービスは組織的な話
• 勘違いのマイクロサービスの設計
• マイクロサービスの切り方はサービス単位
• マイクロサービスはあくまで結果で目的ではない
• マイクロサービスは銀の弾丸ではない
• 改めて図で説明すると
• 全てのプロジェクトに合うわけではない

いわゆるマイクロサービス

マイクロサービスの設計思想の意味はいろんな記事でも書かれています

俊敏性
リリースのリスク軽減できるのでリリースサイクルを早める事ができる

柔軟性
機能毎に分けて各々に最適なツールやライブラリが使える

裁量の拡大
組織を細かく分けて裁量を任せる事ができるのでその分その機能の担当チームの自由にできる

機能の使い回し
受発注で作ったAPIを別のクライアントに提供するなど使い回しができる

耐障害性
機能を小さく分けるので、障害が起きた時でも全てがダウンではなくてその機能のみダウンと範囲を小さくできる

ざっとこういうことが他のWEBの記事でも書いています。
そして、概念だけで具体的な事例の記事は少ないのではと思います。

小松もマイクロサービスのプロジェクトを成功して記事に取り上げてもらったりもしたりして
「マイクロサービス」

がバズワードになりつつある昨今
間違って使っていたり、本末転倒になっていたりする現場もあるので今回改めて記事にしてまとめようと思いました。

過去の事例

まずは小松が過去に設計したマイクロサービスの例では比較的大きい規模のショッピングサイトで問い合わせシステム(CRM)・販売システム・倉庫の３つに分けました。

細かい事を言えば、それらの受発注データから会計システムに渡すシステムも分かれていますし分析用のログ、注文データも分けていますが、ここではそれらのサブシステムが小さすぎるので省略します。

マイクロサービスの記事にDBを分ける事について言及してない事が多いのですが、
DBを分けないと効果は半分以下になるかと思います。

DBもそれぞれ３つに分けます。

リポジトリも問い合わせシステムのフロントとバックエンド
販売システムもフロントとバックエンド
倉庫は委託している会社によって業務フローが変わるので似たようなリポジトリを２つに分けました。

倉庫に関してはデータの流れの下流で地域によって届く商品が違い、絶対にその流れが変わる事がない業務内容でした。

且つ、各倉庫を横断で検索する事がないという前提。

なので、倉庫のDBもロケーション毎に分ける事にしました。

 

問題解決できていない例

最近よくSaaSでうまくいってる会社と商談する事が多かったのですが、このDBを分けるという発想に辿り着いている会社さんはなかったです。

クライアントが100社ぐらいあり、負荷かかるのと開発に時間がかかってしまうのでマイクロサービスにしていきたいとの事だそうです。

「マイクロサービス」にすれば全てが解決できるかのように夢物語に思っている人が多いって事の証拠だと思います。

この場合はマイクロサービス云々よりも、クライアント毎にDBを作成すれば当然の事ながら負荷を下げる事ができます。

クライアント毎とは言わないまでも、クライアントのグループを作成して何等分かに分ければその分負荷を簡単に下げれます。

スキーマの変更などがあった場合は手間がかかりますが、IaCだの、プロビジョニングツールなどがあるのでそれでカバーできます。

しかし、インフラがAWSなので、各クライアント毎にDBを作ってしまうと料金が跳ね上がってしまうのだとか。。

ここでまたしてもAWSのせいでプロジェクトがダメになってしまってますね。。。

 

マイクロサービスは組織的な話

DBも分けて、リポジトリも分けて、それに合わして開発チームも分ける。

担当チームに最大限の裁量を任せる。

そうする事で、大きい組織で働く歯車のようなエンジニア組織ではなく裁量が与えられそれと伴って責任もついてくる。

技術選定などの裁量も任すと、その本人のやりがいにもつながるかと思います。

リポジトリ、DBを横断するような機能はAPIで繋ぎ込みを行う

そうする事でいわゆるマイクロサービスのメリットを享受できるかと思います。

モノシリックな環境では細かい開発の改修でも要件定義やら、リリースやらキーパーソンにお伺いをしないといけないのです。

なので、そのキーパーソンがボトルネックとなり、開発が遅れてしまうことになります。

マイクロサービスではそのキーを分散されるので開発者の人数を多めに投下できます。

一人当たりの生産性は低くなっても人数を多めに投下する事によって全体のリリースを早める事ができます

 

勘違いのマイクロサービスの設計

マイクロサービスと勘違いしているかどうかわからないですが、最近フロントをReactとかVue3とかにしてサーバーサイドはGo,PHPなどでAPIのみという構成が増えてます。

これをマイクロサービスと思って設計してたらおかど違いです。

図で矢印を表しているがコミュニケーションですが、それが多いと感じます。

サーバーサイドとフロントエンドに分けてしまうと対応者が各1名必要な体制になってしまいます。

たかが画面１ページ作るだけでも要件依頼者からサーバーサイドエンジニア1名、フロントエンド1名、最低計2名に要件を説明しないといけないですしAPIの定義でエンジニア同士が認識を合わせないといけない

場合によってはインフラエンジニアと調整をしないといけないという作業が人数が増えた分余計に工数が掛かってきます。

システム的な機能で分けてインフラ、API、フロントと１つの機能を実装するだけで人数が増えれば増えるほどコミュニケーションコストが高くなってしまいます。

そういう現場では「認識が違ってた〜、作り直し！」ってよく聞くようになると思います。

キーパーソンは分散されるどころか、プロジェクトの障害となるポイントを増やしているだけです。

マイクロサービスはあくまで要件、仕様単位で分けるわけでシステム発端の機能で分けてはいけません。

機能で分けると本末転倒になってしまします。

ただ、こういうバックエンド、フロントエンドを分けるやり方はだんだん多くなってきてはいます。

肌感では、生産性が半分近くにまでなってる気がします。残念ながら

普通にフレームワークを使えばいいのにっておもいますが。。

 

マイクロサービスの切り方はサービス単位

図のように仕様単位で分けると、コミュニケーションコストが少なくてすみます。

Laravel, RoR, Djangoなどのフレームワークを使えば簡単に認証やらViewでHTMLを生成できて、１画面を改修するのに1人で対応できる改修がほとんどです。

インフラからフロントまでスキルを積み上げるのは大変と思うかもですが、そういう人材を多くなるような組織にすべきです。

フルスタックエンジニアになってからは、サービスの仕様の把握に努めるべきかと思います。

 

マイクロサービスはあくまで結果で目的ではない

アプローチの仕方も違ってたのかなとも思います。

マイクロサービスを導入直後に資料にまとめたものです。
マイクロサービスという言葉に踊らされて導入したわけではなく単純に既存の問題の対処に集中してその結果マイクロサービスに近いソリューションんになったかと思います。

• スケールアップなのでシステムコストが高い
• バックアップに時間がかかる
• 分担作業させにくい
• 倉庫の出荷のトランザクションが増えればDBサーバーの負荷が高くなってショッピングサイトが落ちる
• カスタマーサポートのオペレータが重いページを連続で集中して開けると、ショッピングサイトが落ちる
• ショッピングを楽しんでいるユーザーからしたら全然関係ないところでWEBサイトが落ちる
• お金周りの決済の機能や個人情報が入っているデータを取り扱うところもあれば、広告のLPを表示するページがあり、重要度、クリティカル具合も全然違うのに同じようにコード管理とリリース管理されている

などの問題が理由で機能とDBを分けたくなった経緯です。

仕様・要件・重要度・データ機密度で分けた事が昨今のマイクロサービスのバズワードと重なっただけかと思います。

なので、既存のシステムでよほどの問題な事がない限りマイクロサービスをあえてすすめなくてもいいのではと思います。

 

マイクロサービスは銀の弾丸ではない

マイクロサービスを進めていく上でチームから疑問と批判もありました。
「DBの負荷を下げたいだけなのになんでわざわざAPIでデータ連携するのか？なぜ直接SQL接続しないのか？」
という質問を受けました。

当時はうまく答えられなかった事を覚えています。

負荷だけの対処なのであれば確かにDBを分けてSQLの向け先を変更だけで事足ります。

しかし、マイクロサービスにして各システムをAPIで連携した方が

・システム全体をしらなくても変更ができる
・システム全体で密結合がないので難易度下がる

という２点でSQLの向け先を変えるより有利です

 

改めて図で説明すると

モノシリックの図では大きな一つのシステムに

エンジニアが10人、リーダーが3人、単価の高いマネージャーが統括するって事になっています。

機能満載のソースコードを見て新規参入者がどこから手をつけて

どのファイルを変更したらいいのかを掴むのにてこずるって事があります。

grepしても対象箇所がありすぎて、わからないって事もあるあるです。

機能の変更点がどこまで影響あるのかどうかをリーダー、マネージャーと連携を取って
許可をもらってから開発をやっと始められるというような開発スタイルになりがちです。

DBの変更もどこまで影響があるのかわからないところで使われていて、障害になってしまったって事もあります。

マイクロサービスの図では

マネージャー不在で

リーダー3名が各々のシステムを担当しています。

チームも5名ずつシステム事に分かれています。

リポジトリの数は増えますが、１リポジトリの機能数が少なくなるので新規参入者でもgrepして影響範囲を調べやすいです

そして、DBの変更による影響もそのリポジトリだけを気にすればいいので、影響範囲がわかりやすいです。

そうなると、上級者をあえて雇わなくてもいいのと全体統括する単価の高いマネージャーを雇わなくてもいいのでリーズナブルにプロジェクトを進行できます。

そういったメリットがSQLで別DBに直接接続するよりマイクロサービスにはあります。

 

全てのプロジェクトに合うわけではない

ただ、全てのシステムにおいて絶対マイクロサービスを取り入れた方がいいというわけではないです。

トータルの工数はかかってしまうので、リリース期限をそこまで気にしていない場合、10人以下のエンジニアのチームなどであればメリットはないと思います。

加えて、マイクロサービスという言葉に踊らされて設計するのもよくないかと思います。

システム開発してた時はできるだけチームのエンジニアに言葉に踊らされて欲しくなかったのでマイクロサービスという言葉は使わず、何が目的でメリットなのかを説明してました

あくまで、結果的にマイクロサービスという事になっただけで、多くのシステムの抱えている問題は千差万別なので、それに論理的、合理的に対処すればいいだけかと思います。
マイクロサービスの設計思想の本を呼んで、大規模なシステム開発ができると思っているのであればそれは間違いかと思います。

まぁ「マイクロサービスで成功を収めた」という文言は
自分の経歴を装飾するときやインタビューのネタとしてあくまでバズワードとしていいかもですが。。

by プログラマーこまつ