新たにシステムを構築する場合、要件に「マイクロサービス」が挙げられることも多いのではないでしょうか？
マイクロサービスは変化の激しいデジタル市場では非常に強力なアプリケーションのアーキテクチャです。
しかし、導入の仕方を間違えると、システムは複雑化して運用コストの増加につながります。ここではマイクロサービスについて説明します。
マイクロサービスとは
マイクロサービスアーキテクチャとは小さなサービスとして1つのアプリケーションを開発し、それらを単一プロセスで起動して軽量な通信技術(HTTPリソースAPIなど)で連携するアーキテクチャスタイルのことで、その小さなサーバーサイドのサービスのことをマイクロサービスと呼びます。
マイクロサービスと比較されるのが一枚岩を意味するモノリシックなスタイルのシステムです。モノリシックなシステムとは、Webフロント部分のユーザーインタフェース、サーバーサイドのビジネスロジック、データベースから構成される3階層システムで、サーバーサイドのビジネスロジックが単一プロセスで起動されるようなシステムのことです。
モノリシックなシステムは、システム内が密連携されるため、性能の最適化やトランザクションの一貫性などが保ちやすい半面で、プログラミング言語などの活用技術を担当者間で統一したり、アプリケーションを修正する際にはサーバーサイドのシステム停止を伴う再ビルドや再配備が必要となるため、システム担当者間でシステムへの影響確認や停止タイミングの調整が必要となります。
モノリシックなシステムは一度リリースすると安定運用が重要な基幹系のシステムには適していますが、顧客要件が多様化して新たな技術をシステムに継続的に導入して競争力の維持・強化が求められるようなシステムでは、修正がすぐに適用できないために競争力低下につながります。
自家用車で例えてみましょう。28歳の独身男性が、自家用車を買うとして、予算は頑張って300万円だったとします。独り身なので今は軽自動車でも良いのですが、一度購入すると10年は乗り続けることを慎重に考え、まだ予定は無いものの結婚や子供が生まれた場合を考えてセダンを選ぶかもしれません。
一方で未来の自家用車を想像してみましょう。最初は運転席しかない車を80万円で購入し、結婚したら助手席を50万で付け足し、子供が生まれたら後部座席を100万で付け足し、荷物の量に合わせてトランクを100万で追加することができる車があったら、あなたはどちらを選びますか？
安定した生活を暮らしていればセダンを選ぶかもしれませんが、10年後の未来をなかなか想像するのは難しいものです。
この未来の自動車をマイクロサービスとしてトータルの金額はもしかしたら高くなるかもしれませんが、不透明な10年後のことを考えずに現時点で必要なものだけを用意し、変化に合わせて必要なものを追加・修正できます。しかし、現在のセダンがモノリシックなシステムとして一度購入してしまうと計画通りに進まなくてもカスタマイズは難しいですが、最適な構成で組み合わされているためスピードは速く・乗り心地は良いかもしれません。
メリット・デメリット
マイクロサービスのメリットは、修正の素早いリリースとよく言われますが、それ以外にもメリットは多くあります。
メリット
修正の素早いリリース
RESTful APIで連携するため、APIさえ変更が無ければ周辺の影響が小さいため、修正を素早くリリースすることができます。アプリケーションを無停止で入替できるように実装されていれば、業務影響なく修正は提供されます。開発の自由度
RESTful APIで連携するため、APIさえ変更が無ければAPIの実装は開発者が好きな開発言語で、好きな技術で開発できます。高可用性
マイクロサービスが停止しても周辺業務は継続されます。モノリシックなシステムでは、一部の処理でプロセス停止を伴う異常が発生すると、システム全体に影響が発生します。リソースの最適化
一部のマイクロサービスに負荷が増加した場合、そのマイクロサービスのみスケールアウトすれば良いため使用リソースを最適化できます。モノリシックなシステムの場合、負荷が増加するとシステムごとスケールアウトする必要があるため、急激にコストが増加します。分かりやすさ
マイクロサービス間はAPIで連携されるため、APIと呼び出し関係さえ把握すればシステムの構成を把握しやすいです。
デメリット
運用コスト
システムが複雑化するため、システムの運用が煩雑になります。異常が発生した場合にも異常個所を特定するのが難しくなります。性能
通信性能が以前と比べて向上しているとはいえ、RESTful APIによる呼び出しが増えれば通信回数が増加して性能への影響が発生します。保守性
自由度が高いということは、各マイクロサービスごとに利用されている技術が異なるため属人化しやすく開発担当者が変わった場合の引継ぎに時間がかかる可能性があります。
私もSOAやマイクロサービスを適用する事例を見てきましたが、サービス実装後に結合した際に性能が要件を到達できず、問題個所は通信せずにプロセス内での呼び出しに変更したことで性能を満たすことはできましたが、通信で呼び出している部分とプロセス内で呼び出している部分が混在し、システムの構成が把握し難くなり、修正を加えた際の影響範囲が見極められずに修正を素早くリリースすることが難しいシステムになった事例もありました。
なぜ今マイクロサービスなのか
マイクロサービスという言葉は2014年3月25日にJames Lewis氏とMartin Fowlerr氏が発表した"Microservices"で、"Microservice Architecture"と紹介されたことが始まりとされています。
これまでの技術トレンドはコンセプトが先行し、それを現場で導入して賛否が議論されることが多かったですが、この"Microservices"では Amazon, Netflix, The Guardian, theUK Government Digital Service, realestate.com.auなどの実際の事例を分析した結果としてマイクロサービスが語られており、現場で自然発生的に広まったアーキテクチャを汎化して"Microservices"として紹介している点が非常に納得感があります。
マイクロサービスは2004年ごろに注目されたSOA(Service Oriented Architecture)と基本的な考え方は同一ですが、周辺環境や活用技術が異なり、シンプルさが異なります。
以下にSOAが注目された頃から何が変化したのか説明します。
クラウド
クラウドが利用されるようになると、利用したい時に利用したい分のインフラリソースを利用できるようになると、インフラがすぐに用意できるが、修正の適用に時間がかかるとクラウドのメリットを最大限に活かすことができません。通信技術
SOAが注目された時には、CORBAやSOAPという技術が適切と言われましたが、C言語やJavaなどの開発言語の異なる仕様を吸収するため非常に難しい仕様を理解する必要がありました。現在ではHTTP通信をシンプルに利用するRESTful API通信が一般的に利用されるようになりました。開発プロセス
従来のウォーターフォール開発では、数ヶ月～数年かけてシステムを開発・修正していましたが、アジャイル開発によって素早い開発サイクルが導入されはじめています。活用技術
コンテナ技術により開発環境で開発した資産を素早く運用環境で復元できるようになり、CI/CDにより開発したアプリケーションが素早くリリースされるようになりました。
逆にこれらの技術を導入せず、マイクロサービスのアーキテクチャを導入しても効果は小さくなります。
マイクロサービス導入の注意点
マイクロサービスを導入する際に最も難しいのが、どの単位でマイクロサービスを作るかという点です。マイクロサービスを細かく分けすぎればシステムは煩雑になりますし、マイクロサービスの分け方が少なければ享受できるメリットが少なくなります。
このような場合、私はマイクロサービスはライフサイクルが同一のものを集約するようにお勧めしています。
例えば商品販売サイトを考えた場合に商品照会と商品購入があると、商品購入が停止していたとしても商品照会ができれば電話で購入依頼ができれば良いとすれば、商品紹介と商品購入は別々のマイクロサービスで作るなどです。
この検討にはドメイン駆動設計の導入が有効だと言われますが、ここでの説明は割愛します。
マイクロサービスの単位を決めた後に課題になるの、"Microservices"でも紹介されているコンウェイの法則です。
コンウェイの法則はシステムの設計は、組織の構造をそっくりまねた構造の設計をしてしまうというものです。マイクロサービス単位に組織を作る必要があることになりますが、組織を変えるのは一般的に容易ではありません。
特に従来から業務SE・インフラSEなど階層を意識してSEの担当をきっちり分けてきた組織の場合、マイクロサービス単位に組織を分けるのは容易ではないかもしれません。