モノリシックとマイクロサービスアーキテクチャとは？
こんにちは、Genです。
かつてはモノリシック（一枚岩の）なサービス（ソフトウェア）をこれまで作られていましたが、最近では柔軟に変化できるように構成しているパーツが独立し疎結合な構成であるマイクロサービスとして、ソフトウェア/サービスを構築するようになってきました。
ちょ、ちょっとまって！
モノリシックとかマイクロサービスとかよくわからないよぅ。
今回は、そんな方にわかるようにこれらの概念について簡単に説明していき
たいと思います。
モノリシックとマイクロサービス
皆さんがスマホやパソコンで何かのアプリやウェブサービス（予約サイトとか）を見たり使ったりしますよね。これがソフトウェアであり、「サービス」とも最近は呼ばれます。
このソフトウェアが使えているのは
たくさんのコードを書いて機能が作られていて、
それを実行するサーバーがあって、
データベースがあって、
インターネットが使えて、
それでやっと皆さんが使えているわけです。
皆さんが普段アプリで見る画面には様々な機能が載っているんですよ！
「ログイン」「地図の表示」「予約」「キャンセル」…とか、ポチポチして操作しているものはすべてです。
こういった機能はすべてコーディングしてプログラムとして作られています。
今回のモノリシックとマイクロサービスというのは、この「機能の組み合わせのしかた」についての考え方です。
システムやサービスは、使う人が増えればそれについてのいろんな要望（あるいはクレーム）が出てきます。つまり、使われれば使われるほど成長します。
モノリシックとマイクロサービスという組み合わせ方の違いでそのシステムの成長の仕方そしてスピードが変わってきます。
モノリシックアーキテクチャ
モノリシックというのは「一枚岩」という意味で分割されていない一つの大きなもの、ということです。
料理でいえばカレー、工作でいうと粘土、かな（独特な表現ですみません笑）
つまり部分的に変えることができないということです。
（カレーに入っているジャガイモを後で取り替えたりできないですよね笑）
ソフトウェアの世界でいうと、すべての機能が一つの箱の中に入っていて分けることができない構成を指します。
以下が私が作ってみたイメージ図です：
上の図のように、もしモノリシックなアーキテクチャの予約アプリで「予約機能」だけバージョンアップしたい、という場合、他の機能に影響が出たり場合によってはシステム全体を止めてしまう（これがシステム障害といわれる）可能性があります。
イメージしやすいのは銀行のシステムかな。定期的にメンテナンスで止まりますよね。
そう、モノリシックなアーキテクチャのシステムは簡単に変更ができない、つまり機能アップデートを頻繁に行うのは難しいのです。
機能を改善するためには、タイミングを見てサービス休止をして、その間に一斉にアップデートをします。
こうして、最新の技術についていけなくなり、だんだんと時間とともに古いシステムになってしまうわけです。
ここで最近のソフトウェアの構成方法として普及してきているのがマイクロサービスアーキテクチャです。
マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャというのは構成されているパーツ一つ一つが独立して変更ができる構成を指します。
料理でいえば手巻き寿司、工作でいうとレゴブロック、かな（また独特な表現ですみません笑）
つまり部分的に付け替えしたり、共通利用したりすることができるということです。
つまり、ソフトウェアの中にあるすべての機能一つ一つが箱になっていて、使う時に呼び出すという構成ということです。
以下が私が作ってみたイメージ図です：
このようにユーザーが使う画面から各サービス（機能）にアクセスして利用できるようにする、あるいは機能間で利用しあうというような構成です。
これであれば、一部機能を更新した時に万が一使えなくなってしまってもシステム全体を止めてしまったり、他の機能に影響を与えてしまう可能性も低いです。
そのため、機能ごとでバージョンアップしやすいわけです。
つまり、システムを止めずにパーツごとで成長できるということです。
また、機能ごとで書いていた同じソースコードを一つのサービスにして共通利用することで、各機能でコードを再利用して手間を省くことができるというメリットもあります。
そうなんだ！
じゃあ、そのソフトウェアがマイクロサービスアーキテクチャにあれば問題は解決だね！！
そうとも限りません。マイクロサービスアーキテクチャにすることで起きる難しさというのもまたあります。
マイクロサービスアーキテクチャにおける難しさ
１. 組織内のコミュニケーションの複雑化
サービスが増えるとともに、それを開発するチームも増えていきます。
そしてチームが増えれば、連携をとるのが難しくなってきます。
コミュニケーションやコラボレーションのレベルを高めていく必要が出てきます。
２. 開発の無秩序な拡大
パーツごとで成長できるようになる、ということはある一つのパーツだけ成長しすぎてしまう可能もあるということです。
システムやソフトウェア全体の設計の難易度が上がり、それを統制していく必要があります。
３. 開発におけるインフラコストの増加の可能性
マイクロサービスができるたびに、テストやデプロイのツール、利用するサーバー、監視ツール、などサービス独自でコストが発生する可能性があります。
４. API管理の複雑化
機能（サービス）間で利用しあうためには都度通信をする必要があります。その際に一般的に使われるのがAPIです。先ほどの「マイクロサービスアーキテクチャのイメージ図」でいうと矢印そのものを指します。
例えば、画面上にログインしたユーザーのアカウント名をいれて「○○さん、こんにちは」みたいなテキストを表示する際にアカウント名を取得する必要があるとします。その際に「アカウント管理」のサービスがあってそこから情報をAPIでもらおうとします。
こういった情報の行き来がサービス間でものすごいたくさん起きるんです。
なので、もしAPI側で変更があった場合は利用しているすべてのサービスに影響が出てしまいます。
そうならないためにAPIの変更管理が重要になってくるわけです。
Atlassian製品もかつては「モノリシックアーキテクチャ」だった！
「マイクロサービスとモノリシック アーキテクチャの比較 | Atlassian」（https://www.atlassian.com/ja/microservices/microservices-architecture/microservices-vs-monolith）によると、
アトラシアンは、Jira と Confluence で拡大と拡張の課題に直面した後、2018 年にマイクロサービスへの道をたどりました。オンプレミスで稼働しているシングルテナントのモノリシック アーキテクチャでは、将来のニーズに合わせて拡張できないことがわかりました。
~
Jira と Confluence を再構築して、ステートフルなシングルテナントのモノリシック システムから、Amazon Web Services (AWS) がホストするマルチテナントのステートレス クラウド アプリケーションに移行することを決定しました。その後、時間をかけてこれらをマイクロサービスに分解しました。
Atlassianもかつては製品がモノリシックなアーキテクチャであり、変更にかなり苦労していたと話しています。とりわけクラウドサービス（SaaS）を始めた際はそれが顕著になったようです。
（クラウドサービスは成長スピードが大切なので）
このAtlassianのクラウド製品をインフラをAWS上へ移行し、併せてモノリシックからマイクロサービスアーキテクチャに分解・再構成するというAtlassian史上最大のプロジェクトが2016年頃から2年かけて行われたそうです。
そのプロジェクトコードは、ある上級エンジニアが「このアイデアは本当に気に入っているが、めまい (vertigo) がする」と言ったことにちなみ、「Vertigo（めまい）」と名付けられたそうです。
Atlassianはさらにマイクロサービスになったことによるメリットについてこう説明しています。
マイクロサービスのメリットは次のとおりです。
アジリティ — 頻繁にデプロイする小規模なチームでアジャイルな作業方法を促進します。
柔軟なスケーリング – マイクロサービスの負荷容量が最大に達した場合は、そのサービスの新しいインスタンスを付随するクラスターに迅速にデプロイして、負担を軽減できます。現在、アトラシアンはマルチテナントでステートレスであり、お客様は複数のインスタンスにまたがっています。今では、さらに大きなインスタンス サイズをサポートできるようになりました。
継続的なデプロイ – リリース サイクルが頻繁かつ迅速になりました。以前は 1 週間に 1 回アップデートをプッシュしていましたが、現在は 1 日に 2 - 3 回程度プッシュできます。
高い保守性とテスト性 – チームは新機能を試すことができるうえに、何かがうまくいかない場合はロールバックできます。これによって、コードの更新が容易になり、新機能の市場投入までの時間が短縮されます。さらに、個々のサービスの障害やバグを簡単に特定して修正できます。
独立したデプロイが可能 – マイクロサービスは個別のユニットであるため、個々の機能を迅速かつ簡単に独立してデプロイできます。
テクノロジーの柔軟性 –マイクロサービス アーキテクチャによって、チームは希望するツールを自由に選択できます。
高い信頼性 – アプリケーション全体が停止する恐れなしに、特定のサービスに対する変更をデプロイできます。
チーム満足度の向上 – マイクロサービスを扱うアトラシアン チームは自律性が高まり、プル リクエストが承認されるまで数週間待たずに自らビルドしてデプロイできるため、満足度が向上します。
要は、継続的にシステムをより良くするための活動ができるようになった、ということですね。
ちなみに、Atlassianはこのようなマイクロサービスアーキテクチャの運用・管理を実現する製品を開発しました。それが「Compass」です。
以上、モノリシックとマイクロサービスアーキテクチャとは？でした。
少しでも参考になれば幸いです！
もしよろしければいいね/シェア/フォローよろしくお願いいたします。
この記事が気に入ったらサポートをしてみませんか？