【Microsft Azure】最初の一歩-Azure DevOpsの利用
コル
テクてくブログ
【クラウド技術基礎知識】マイクロサービスアーキテクチャ
コル
記事内に商品プロモーションを含む場合があります
こんにちは、コル（@bravecol）です。
前回クラウド技術におけるクラウドタイプの記事を書きました。
今回はクラウド開発における考え方として主流となっているマイクロサービスアーキテクチャを解説します。
- クラウド開発が初めての方
- 従来のオンプレミス開発からクラウド開発に移行する方
- クラウド開発におけるシステムの考え方の基礎を知りたい方
に向けて書いていきます。
目次
スポンサーリンク
クラウド開発に移行するメリットとは？
クラウド開発へ世の中が移行していますが、まず従来の開発からクラウド開発に移行する際のメリットを掴みましょう。クラウドはオンプレミスと比較して説明されますが、オンプレミスからクラウドへ移行する際のメリットとしては
- サービスを立ち上げるまでのスピードの速さ
- ハードウェア導入に伴う初期投資やメンテナンスの手間が浮く
- ネットワーク経由のため資材管理費などランニングコストが少ない
- アクセス集中時にサーバー増強が不要
といったところだと思います。
言葉にするなら「場所を選ばずスピード対応が可能で課金によってスケールアップも柔軟に対応可能」みたいな感じですかね(^^)
僕がここで強調したいのは「柔軟さ」の部分です。ではこれを踏まえてマイクロサービスアーキテクチャを説明します。
マイクロサービスアーキテクチャとは
Microsoftのドキュメントではこのように書いてあります。
マイクロサービスアーキテクチャは小さな自律サービスのコレクションで構成されています。 各サービスは自己完結型であり、境界付けられたコンテキスト内で 1 つのビジネス機能を実装している必要があります。
上記に記載のある通り、小さなサービス(機能)を複数組み合わせてアプリケーションを構築する開発手法です。各サービスはそれぞれ自身のプロセスで動作し、機能ごとに分けられた軽量なサービスとしてhttp通信などを行います。例を踏まえて図にすると下記のようなイメージです。
機能単位にAPIとして独立しており、使いたい機能を利用側が呼び出す方式であることがわかります。DBは一箇所にしてもいいですが、DBアクセスの単位がわかりやすいように上図は作成しました。
モノリシックアプリケーションとは
対するモノリシックではソフトウェア全体が一つのモジュールでできていて分割されていない状態の開発手法です。例を踏まえて図にすると下記のようなイメージです。
モノリシックとマイクロサービスの違い
モノリシックでは各機能が巨大なシステムとして結合されているため以下のような弊害が発生します。
- 軽微な修正で全体の現行保証テストが必要になる
- 機能間の境目が無く、密結合のため各機能が複雑化し分かりにくい
- 一システムを複数人で修正するため関係者が増え、リリース調整コストが増える
- スケーリングに柔軟性がない
結果としてビジネスニーズに迅速に対応できなくなります。
マイクロサービスアーキテクチャでは機能が疎結合であることから以下のメリットがあります。
- 自律性 各サービスは他機能に影響なく開発可能
- 柔軟性のあるスケーリング サービスごとに担当を分けれる為関係者が減り開発サイクルが早くなる
- 容易なデプロイ 特定機能のみのリリースや停止ができ機能、単位でスケーリングも可能
- 技術選択の自由 API間のインターフェースが決まっていれば一サービスの技術は自由に選択できる
- 耐障害性 エラー前提の設計思想のためエラー発生機能のみ停止、システム全体を停止しなくても良い
開発は基本一人ではありませんから、それぞれチームや会社で得意な技術というものもあるでしょうし言語ごとに得意な処理というものがあります。その特性や強みを生かしつつ、マイクロサービスアーキテクチャではJavaで通常開発して、AI分析サービスはPythonを使用するという工夫ができます。
マイクロサービス化の背景としてはクラウド化の背景と同様、下記の「なぜクラウドへの移行を推奨するのか？」の記事が参考になると思います。
ここまで読んだ方は「従来のモノリシックって柔軟性もなくて、辞めたほうがいいじゃないか」と感じたのではないかと思います。では、何でもかんでもマイクロサービス化した方がいいのか？という疑問に答えていきます。
システムは全てマイクロサービス化する方がいいのか？
この疑問には僕はNOと答えます。
アーキテクチャに優劣はなくメリットとデメリットをどのように捉えるかが重要になります。
ソフトウェア技術者であるMartin Fowlerさんもこのように述べています。
マイクロサービスアーキテクチャがモノリシックアーキテクチャより優れたアプローチであることは多くの開発チームが感じていることだが、生産性を低下させる重荷と感じるチームも存在する。メリットもありデメリットもあるという点においては他のアーキテクチャと変わらない。このメリットデメリットを把握して開発手法を選択することが必要である。
「多くの開発チームにとってはプラスだが生産性を低下させたと感じるチームも存在する」ということです。それについて有益なグラフを見つけましたので貼っておきます。
下記は横軸:システムの複雑さ、縦軸:生産性をモノリシックとマイクロサービスで比較したものです。
（グラフは下記より引用: https://cloudtweaks.com/2017/09/first-things-first-microservices/）
図を見てわかるように生産性と複雑性によってはモノリシックが勝ることもあります。初めにも書きましたがクラウド開発としての「柔軟さ」の利点が活かせるか活かせないかという点かなと僕は思います。
この図は結構色んなとこで使われていて、他にもふくあずというクラウドエンジニアのコミュニティなどでも発表されていました。
まとめ
今回はクラウド技術の開発手法として有名なマイクロサービスアーキテクチャについて記載しました。
多くの場合が有効な選択肢ですがメリットとデメリットをしっかりと把握して開発手法を選択することが必要です。新しくシステムを構築する場面や既存システムのリプレイスはこれからも増えると思いますが、その業務の複雑さを把握して選択することをオススメします。
実際に現場でAzure kubernetes Serviceなど使ってみましたがクラウド開発とマイクロサービスの相性は良いなと個人的には感じました。一機能だけ増強するとかエラー対応である機能だけ落としておくとかできるので、従来の「システムメンテナンスのためサービス停止します」とかしなくて済むのが良い、というのが率直な僕の意見です。
実際のマイクロサービスアーキテクチャにおける開発の記事はまた別で書こうと思いますが、マイクロサービス及びクラウド開発の知識としてこの記事がお役に立てれば幸いです。
ご一読ありがとうございました。
スポンサーリンク
運営者
ウェディングプランナーからエンジニアへ異業種転職し、家族と田舎のとある村でリモートワークメインで生活中。今はフリーランスエンジニアとしてJava/Python/Go/Reactなどが経験多め。子育てとコーディングを巧みに両立する「忍者スタイル」でスローライフと気になる技術を日々探求中！たまに妻から「ボヤッキーみたい」と笑われながらも、技術やガジェット関連をテーマにブログを更新しています。