モノリシックとは。用語解説から成り立ちまで！マイクロサービスとの比較も紹介！
「モノリシック」というワードをご存知でしょうか。集積回路（IC）やコンクリート工法、デザインのコンセプトとしても用いられている言葉で、ソフトウェアにおけるモノリシックはカーネルの構造において用いられています。
現在、モノリシックからマイクロサービスへと移行する傾向がみられますが、システムによってはモノリシックのままで運営管理しやすいものもあるため、検討が必要になってきています。
【目次】
- モノリシックとは
- カーネル：モノリシックカーネルとマイクロカーネルの違い
- モノリシックカーネルの解説
- モノリシックカーネルの長所と短所
- マイクロカーネルの長所と短所
- 時代はモノリシックからマイクロへ？！マイクロサービスとは
- 本当にモノリシックからマイクロサービスへ移行すべきなのか
- マイクロサービス：モノリシックと比較した場合のメリット
- マイクロサービス：モノリシックと比較した場合のデメリット
モノリシックとは
モノリシック（monolithic）とは、一体となっている、あるいは一枚岩的な組織やものという意味です。
集積回路（IC）やコンクリートの散布工法、デザインコンセプトとして用いられることもあります。ここでは、ソフトウェアにおけるカーネル構造の一つとしてのモノリシックについて解説します。
ソフトウェアとしてのモノリシック
ソフトウェアにおいては、分割されていない1つのモジュールで構成されたものをモノリシックといいます。カーネルの構造でよく用いられるワードなので、まずはそちらについてみてみましょう。
カーネル：モノリシックカーネルとマイクロカーネルの違い
カーネル（Kernel）は、OS、オペレーティングシステムの中におけるもっとも基本的な機能を受け持つ部分です。CPU、メモリといったハードウェアを制御し、さまざまなアプリケーションプログラムの実行およびメモリ管理をおこないます。
ユーザーによって直接制御するわけではないのでピンとこない方もいるかもしれませんが、このカーネルはモノリシックカーネルとマイクロカーネル、2つの種類があります。
カーネル開発の中心的な存在Linux（リナックス）
カーネル開発の中心となっているのがUnix系のオペレーティングシステムカーネルである、Linux（リナックス）カーネルです。
Linuxは、パソコンやテレビ、携帯電話、スーパーコンピュータなどさまざまなハードウェアで使用されており、現在も開発が進められています。
Linuxカーネルのバージョンは「2.x.x.」のような3つの数字であらわされ、2つめの数字が奇数だと開発版、偶数だと安定版となっています。
また、3つめの数字の後にアルファベットなどが付与されることもあります。
モノリシックカーネルの解説
モノリシックカーネルは、外部モジュール不要のカーネルです。1つのバイナリに必要な機能をすべて組み込んだものをさします。
マイクロカーネル
マイクロカーネルは、カーネルに入れるものを最小限にし、外部モジュールで機能を多くをおこなうものをさします。
モノリシックカーネルとマイクロカーネルの違いは、「外部モジュールの有無」ですが、現在ではマイクロカーネルでなくてもモジュール構造をもっていたり、マイクロカーネルでも一部分のみを外部モジュールとして確立することもあり、両者の違いは曖昧になりつつあります。
モノリシックカーネルの長所と短所
モノリシックカーネルの長所と短所は次のとおりです。
長所
- 1つのプロセスで処理がすべておこなわれる
- 処理速度が高速である
短所
- 記憶装置が有効利用できない
モノリシックカーネルは、外部モジュールを必要としない構造のため、プロセス間での通信などがいりません。そのため、処理速度の向上が見込まれるという長所があります。
一方で、OSの機能提供に必要となるすべてのコードを一体化しているために、記憶装置が有効利用できないというデメリットもあります。
処理速度については、次に紹介するマイクロカーネルにも高速化を実現したものがあり、モノリシックカーネルは前時代的な構造であるという見方もあります。
マイクロカーネルの長所と短所
マイクロカーネルの長所と短所は次のとおりです。
長所
- 機能拡張とデバッグが容易である
- システム全体を止めることなくカーネル以外のOSをアップデート可能
- 必要な機能に特化したOSを構築しやすい
カーネルで提供する機能を限定的にすることで、システム全体に影響を及ぼすことなく拡張やデバッグ、アップデートができる点がマイクロカーネルの長所です。
必須機能以外はユーザー空間で動作するようにして、それぞれの動きを自由にしています。
短所
- 処理の遅延によるロスが大きい
マイクロカーネルの長所である各プロセスの切り離しは、それぞれの間での通信が必要になります。そのため、通信をおこなうことでのオーバーヘッドが大きく、また動作モードを切り替えるために処理速度を向上させることが難しいという難点があります。
とはいえ、最近では処理速度を向上させたマイクロカーネルも開発されており、モノリシックカーネルよりも利便性が高いと見なされる傾向にあります。
時代はモノリシックからマイクロへ？！マイクロサービスとは
カーネルだけでなく、時代はモノリシック（一枚岩）ではなく、マイクロ（小さな）単位での考え方やあり方にシフトしつつあります。そこで注目されているのがマイクロサービスです。
モノリシックサービスとマイクロサービスへ
マイクロサービスというワードは、ソフトウェアのエンジニアであるマーチン・ファウラー氏らによって書かれた2014年の記事で知られるようになったとされています。
・Microservices – James Lewis, Martin Fowler
https://martinfowler.com/articles/microservices.html
個々に開発された複数の小さな（マイクロ）サービスに分割して管理、運営をおこなっていくマイクロサービスは、Amazon、LINEなどの大手企業で採用されています。
小さなサービスをHTTP経由のAPIなどの軽量な通信で連携することにより、従来ネックとされていた処理速度を向上させ、より利便性の高いサービスを実現しています。
モノリシック的思考からマイクロサービスへ
では、そもそもモノリシック的な思考とは、どのようなものなのでしょうか？
モノリシック的な思考は、長い開発期間を設けてシステムを開発する「ウォーターフォール開発」などにみられます。
デジタル社会の急速な成長に対して、長期的な視点で包括的なシステムを開発するウォーターフォール開発は対応するのが難しい場面もあり、現在はもっぱら短期間での開発を積み重ねてプロジェクトを完成させるアジャイル開発が主流になっています。これらの開発方法の違いやメリット、デメリットなどは別の記事を参照してください。
モノリシックサービスは、汎用性を重視しているはずがかえって反対の結果を招くことが往々にしてありました。一枚岩であることにこだわるあまり、小さなサービスを実行するまでにほかの多くの部分を連携させてその都度動かさなければならないという弊害もうまれていました。
これを解消する新たな方法がマイクロサービスなのです。
本当にモノリシックからマイクロサービスへ移行すべきなのか
世の中のすべてのアプリケーションを、マイクロサービスに移行、リファクタリングする必要があるわけではありません。複雑すぎるモノリシックを持て余しているのでない限り、マイクロサービスを検討すべきではないという声さえあります。
移行を考える時のポイントは、「複雑かそうでないか」です。システムのサイズが大きくなり、全容をとらえられないくらい複雑になっている場合は、マイクロサービスによってそれぞれのサービスを切り離す運用方法が適しているでしょう。
システムのアーキテクチャが過剰に複雑でないのならば、マイクロサービスに移行する必要はないかもしれません。自社についての検討に不安材料がある時は、エンジニアや外部のコンサルタントに相談するなどして、充分な検討をおこなうことをオススメします。
マイクロサービス：モノリシックと比較した場合のメリット
ここからは検討材料として有用なマイクロサービスの利点について、みてみましょう。モノリシックと比較することでより分かりやすくなります。
マイクロサービスのメリット1. 局所化による効率的な利用
マイクロサービスは、1プロセスにつき1サービスを稼働させます。
そのため、どこかで問題が起こった時にも障害の起こっている箇所を特定しやすいというメリットがあります。
モノリシックサービスでは、全体が一つを構成しているために、サービスが巨大化すると応用が効きづらく、問題の箇所を突き止めにくい傾向にありました。
一方でサービス同士がそれぞれ独立しているマイクロサービスは、1つのサービスごとに障害の有無や影響をチェックできるので、回復が容易であり、かつ連鎖反応を起こすリスクが少ないといえます。
マイクロサービスのメリット2. リソースの有効活用
モノリシックなアーキテクチャ（構造）においては、包括的なスケールで計画を立てる必要がありました。そのため、どうしてもリソースを多めに見積もる必要があり、無駄が出てしまう傾向にありました。
その点、マイクロサービスは、1プロセスずつ必要な部分だけを構築していく仕組みなので、リソースを最大限有効に使うことができます。また、不要な部分までカバーすることがないので、無駄のない計画を立てることができます。
マイクロサービスのメリット3. 新技術などの採用が容易
システム全体をある程度統一された技術で構築する必要のあるモノリシックなアーキテクチャとは違って、マイクロサービスはそれぞれのプロセスに特化した新技術を採用することができます。
それぞれのサービスはインターフェースを呼応する以外の依存関係がないため、ある程度の特異性、独自性が保持されるからです。
実現したいサービスに合わせて個々に最適な技術を用いることによって、スピーディかつ時代に即した構築が可能になります。
マイクロサービスのメリット4. 個々の変更への対応が容易
モノリシックは一枚の連続した衣服で体を覆っている状態、マイクロサービスはジャケットやセーター、パンツ、靴下と細分化させた「布」で体を覆っている状態と想像してみてください。
頭からつま先まで一枚の布で覆われていた場合、もしもつま先がやぶけたら丸ごと布を取り替えなければなりません。
また、違う色やデザインのものを身につけたいと思ったら、布すべてを交換しなければならないでしょう。手袋、マフラーといった新たなアイテムを身につけたいと思ったら、布全体のサイズを変更してカバーする必要があります。
一方、パーツごとに分かれているマイクロサービスであれば、ジャケットはそのままにセーターだけを着替えたり、サイズ違いを着用する、帽子が必要になったらあらたに帽子をプラスするなど、柔軟な着こなしが可能になります。
かなり大雑把な例えになりますが、修正や改変に対するマイクロサービスの考え方はこのようなものです。
- 新規で機能を追加する
- 軽微な変更を高頻度でおこなう
- システムの改変を更改する
といったことをスピーディかつ軽負担でおこなうことができます。
以上がマイクロサービスのメリットです。
これらは一枚岩ではないからこそのメリットといえるでしょう。
マイクロサービス：モノリシックと比較した場合のデメリット
どのようなものにも、メリットとデメリットはつきものです。モノリシックと比較した場合のマイクロサービスのデメリットについてもまとめました。
マイクロサービスのデメリット1. パフォーマンスの劣化を招く可能性
これは、各サービスを呼び出すことによって違いの連鎖的なAPI呼出が発生して起こり得ます。
対策としては、非同期にてAPI呼出をおこなう方法がありますが、実装の難易度は高いため、エンジニアとよく相談して検討する必要があります。
マイクロサービスのデメリット2. 一貫性にかけることでの問題が起こりやすい
一貫性に欠けることの問題として挙げられるのは
- データの保証
- 運用管理業務の負荷
の2点です。
データに関しては、結果的に整合性を保つことができればよいと割り切るのが一般的ですが、企業によっては整合性をどの点において重視するかなど、検討するべき問題が出てくるでしょう。
1つのシステムを個々のサービスに分けるというマイクロサービスは、運用の管理も複数に渡ります。サービスごとの管理業務が必要になり、なおかつ統合的に管理するシステムづくりなどで新たにコストが発生する可能性もあります。
マイクロサービスのデメリット3. 設計が高難度である
個々に最適な設計を実現するのは、いうまでもなく高いスキルレベルを要求されます。
また、システムを実際に設計するスキルだけでなく、各サービスを適切な単位に分割する能力が必要になるため、実装の難易度はかなり高いといってよいでしょう。
大きく分ければモノリシックなアーキテクチャと同じようになってしまい、かといって細分化しすぎると今度は全体が複雑化して手に負えなくなってしまいます。マイクロサービスについて熟知しているエンジニアと、企業の求めるものについてよく検討し、相談を重ねる必要があるでしょう。
まとめ
モノリシック、マイクロサービス、それぞれについて理解した上で、自社にとって最適なシステム管理、運営を検討してみてはいかがでしょうか。
