CAUTION
- こちらのQiitaは @YumaInaura が原書を解釈したまとめであり、本そのものの正確な要約ではありません。間違っている部分がないとも限りません。
- このQiitaを読んだことにより、不利益を被ったいかなる場合（「マイクロサービスを間違って実装してしまった」「間違って作ったマイクロサービスを金融システムに移植して100億の損害を発生させてしまった」「水虫がかゆい」など）に対しても、当人は一切の責任を負わないことが法律により保証されていることにしたいです。
- 気になる人は原書を読んでみることをお勧めします。
【A子さんの悩み】
マイクロサービスって何だろう？ 何が良いんだろう？
.｡oO( うーん )
そんな悩みにお答えします。
- マイクロサービスって何？ おいしいの？
- マイクロサービスの【ここがイイ！】
の二本立て。
マイクロサービスを恐がらないで。
実はたくさん良いことがあるよ。
そもそもマイクロサービスとは何なのか
【図解】 マイクロサービスのイメージ
図の上が旧来のサービス。下がマイクロサービス。そんなイメージ。
(この図は自分が勝手に描いたものなので、原書とは関係ない )
ちなみにマイクロサービスの対義語として「一枚岩のサービス」という言い方が定義されている。
【図解なし！ マイクロサービスとは】 「単一責任の原則」をサービスに落とし込んだもの
プログラミングにも「ひとつのクラスはひとつの責任だけを持つべきだ」っていう原則があるだろう。 ( Single Responsibility Principle )
ひとつのメソッドやクラスが色んなことをしているコードは保守しにくい。
なので「責任を分離」して書くのがスマートなやり方。
サービス同士にも「高凝集」と「疎結合」が求められる。
それと同じで「ひとつのサービスは、ひとつの責任だけを持つべきだ」と、マイクロサービスは考える。
そして「ビジネスの境界線」に合わせて「サービスの境界線」を決めるのだ。
ちなみに本書はエリック・エヴァンスの「ドメイン駆動設計」の影響を強く受けている。
【マイクロサービスとは】 自分だけでデプロイ出来るもの
黄金のルール。
「自分自身以外を変更せずに、デプロイ出来るかどうか」 を問いかけてみてほしい、と原書に書かれている。
もしそうでなければ、この本に学ぶことがたくさんあるだろうと。
この定義は非常に明確だと思った。
本には「これこそがマイクロサービスの定義だ」とは書かれていないが、そう言ってもおかしくないほど明確な定義だと、僕は感じた。
マイクロサービスの【ここがイイ！】
【ここがイイ！】 エラーの総量を戦略的にコントロールできる
マイクロサービスには「回復力」がある。
従来の一枚岩なサービスでは、サービスのどこかが落ちると全体が落ちてしまう。
エラーを減らすために、複数のマシンを走らせたりする。
だがマイクロサービスでは「雪崩のように」ダウンが起こることはないため。
「エラー全体の数」と、さらに「エラーやダウンによるソフトウェアの評判の悪化」をも含めて、戦略的にコントロールすることができる。
そして「エラーがソフトウェアとユーザーに与える影響」を定量的に考えて、最良のコストパフォーマンスで、回復力を増進させていけば良いのだ。
【ここがイイ！】 デプロイしやすい
巨大なひとかたまりのサービスでは、必然的にデプロイも巨大化する。
たった１行のコードがサービス全体に影響を与えたりするので、危険が大きい。
マイクロサービスでは各々が小さなサービスなので、素早いデプロイが可能。
【ここがイイ！】 技術の多様性が得やすい
サービスごとに別々の言語で書きやすい。
サービスごとに適した技術を使うことができる。
ひとつの技術、ひとつの言語にとらわれなくて良い。
無理して「ニーズに合わない技術」を使わなくても良い。
新しい技術が出てきても、それを迅速に取り入れることができる。
もちろん既存のサービスでも、機能の特質によって別の技術を使うことは普通にあると思う。
だがマイクロサービスでは、よりサービス間が境界線、技術的な境が明らかになっているため、それがやりやすくなる。
(もし「そんなの当たり前じゃん」って思ったら、あなたはすでにある程度「マイクロサービス的」なシステムに携わっているのかもしれない)
とはいえ、複数の技術を使うことによって、オーバーヘッドが生じることも否めない。
NetflixとTwitterはその点をよく理解し、スケーリングとパフォーマンスのことを考えて、JAVAをメインの技術として「選択」している。
すなわち、マイクロサービスだからといって多様的にならなければいけないわけではなくて、あえて多様性を「持たない」というのもひとつの選択肢ということだ。
それでも、もし仮にひとつのサービスを技術を何か別のものに置き換えたくなったときに、「マイクロサービス的なサービス設計」していれば、置換はしやすいはずだ。
サービスがそれぞれ同じ技術を使っているということと、サービスの境界線が明確であるということは、共存できる。
【ここがイイ！】 スケーリングしやすい
旧来の一枚岩のサービスでは、スケーリングしようと思ったら一緒にすべてを変えなくてはいけない。
だがマイクロサービスでは、サービスの単位が分かれているので柔軟なスケーリングができる。
( 逆にいうと、単位ごとにスケーリングができる状態が「マイクロサービス的」だと言える )
超強力なハードウェアがなくても、サービスごとに必要な分だけスケーリングをすれば良い。
【ここがイイ！】 チーム的にイイ。
大きなチームに、大きなコードベース。
これが引き起こす問題は、皆よくご存知のところだろう。きっと悪夢だ。
マイクロサービスでは逆に、 小さなチームで小さなコードベース を扱う。
いまじんおーるざぴーぽー。これは生産性のためにとてもイイ。
【ここがイイ！】 置き換えやすい
すなわち、置換可能性 ( Replaceability ) が高い。
たとえば、Fortainで25年も前に書かれたレガシーシステムなんか誰も触りたくないだろう。
なのになぜ、そういうシステムは途中で置き換えられないのか？ それは置き換え作業自体が巨大で危険なものになってしまっていたからだ。
マイクロサービスはそもそも「小さく作る」ものだから、そもそも置き換えがしやすい。
もうどこにも使われていない、必要なくなったコードはバサっと捨てることができる。
【ここがイイ！】 組み立てやすい
すなわち、組立可能性 ( Composability ) が高い。
プログラミング言語のクラスやメソッドも、役割ごとに分かれていると「組み立て」と「再利用」がしやすいだろう。
サービス本体にも同じことが言える。
マイクロサービスでは、サービス同士がどんな方法でも、どんな目的でも、お互いの「部品」を使うことができる。
続きは Amazon.co.jp で
第一章の他の章はこんな感じ。
興味のある人は原書を読んでみると良い。
- シェアハウス「ライブラリ」へようこそ。
- オスギ - OSGI- のゲートウェイ相談室。
- いつからマイクロサービスが銀の弾丸だと錯覚していた？
さーて、来週のマイクロさんは？
- イクラ、既存サービスをマイクロサービスに置き換える
- カツオ、架空サービス MucisCorp を立ち上げる
- アナゴさん最後の晩餐
の三本立ててお送りします。
二章・三章・四章をすっとばして、第五章に続く予定。だが未定。
題材
フリー素材
チャットメンバー募集
何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。