DX時代のクラウドネイティブの基礎「マイクロサービス」とは
全世界的なデジタルシフトが進む現在、ビジネスシーンの変化も非常に激しく、アプリケーションの機能追加やリリースもより迅速に行うことが求められています。十数年前に機能していた開発プロセスやアーキテクチャを使い続けている状況で、ユーザーニーズ対応を維持するのは難しくなりつつあります。
こうした変化に応じて、開発からリリースまでのサイクルを短期間で繰り返していく「アジャイル開発」が普及し始め、かつ巨大で複雑なアプリケーションを機能ごとに効率よく開発できるマイクロサービス・アーキテクチャが注目されています。
マイクロサービスは、以前と比べて高レベルの制御と速度によって、新しく革新的なウェブ・エクスペリエンスをユーザーに提供します。
本コラムでは、マイクロサービスとはどんなものか、従来のモノリシック・ウェブ（OSにおいて分割されていない1つのモジュールで構成されたアプリケーション）との違い、開発パターンとその応用事例について解説します。
１．マイクロサービスとは
マイクロサービスは、クラウド環境の利点を生かした運用を前提としたシステム（あるいはその考え方・コンセプト）である「クラウドネイティブ」を支える技術の一つであり、既存のモノリシック・アーキテクチャとは異なるアプリケーション開発モデルです。
アプリケーションの全ての機能を独立したサービスとしてコンテナで運用し、コンテナはAPIを介して通信をします。
図１．モノリシックとマイクロサービスの違い（イメージ）
Martin Fowlerのコラム内容をもとに図作成
https://martinfowler.com/articles/microservices.html
２．モノリシック・アーキテクチャとマイクロサービスの比較
モノリシックの懸念点
モノリシック・アーキテクチャは単一のアプリケーションに基づくシステムで、アプリケーションを１つのファイルにまとめてデプロイされています。開発の初期段階においてのデプロイは簡単ですが、いくつかの懸念点があります。
１つ目の懸念点は、依存度が高いことです。
アプリケーションに変更を加える場合、変更により影響されるコンポーネントを全て把握する必要があります。そのため、時間経過に比例して壊れやすくなります。
２つ目の懸念点は、言語・フレームワークに自由度がないことです。
コンポーネントに対して依存しているため、アプリケーション開発を１つの言語、フレームワークに統一する必要があります。
３つ目の懸念点は、アプリケーションの成長に比例して開発者の負担が増えることです。
アプリケーションが大きくなればなるほど、開発者の手に負えなくなる傾向にあり、１つのコンポーネントに問題があった場合、シャットダウンした後にデプロイし、システムを安定させる必要があるため時間もかかります。
マイクロサービスの利点
モノリシック・アーキテクチャの懸念点と比較して、マイクロサービスには以下のような利点があります。
１つ目の利点は、他のコンポーネント対して柔軟性があることです。
それぞれのコンポーネントが独立しており、他のコンポーネントに対して違う言語・フレームワークを使用することが可能です。
また、１つのコンポーネントに問題が発生して利用不能な状態 になった場合でも、その他のコンポーネントに影響が及ばないため、引き続き利用することが可能です。
２つ目の利点は、自動的にリデプロイされることです。
１つのコンポーネントに対して修正や変更を行い、コードをコミットした場合、動作に問題がないことが判明すると他のコンポーネントも自動的にリデプロイされます。
３つ目の利点は、独自にスケーリングが可能なことです。
例えば、ある時間帯にユーザーが急増した場合、負担がかかっているコンポーネントに自動で機能を追加し、その時間帯が過ぎたら元のスケールに戻すことが可能です。
図２．モノリシックとマイクロサービスの違い
Cloud Native Computing Foundationのコラム内容をもとに図作成
https://www.cncf.io/blog/2021/11/30/microservices-and-cloud-native-applications-vs-monolithic-applications/
３．マイクロサービスの開発パターン
マイクロサービスによる開発に相応しいパターン
１つ目は、バックエンド・フォー・フロントエンド（BFF）パターンです。
このパターンは、ユーザーエクスペリエンスとエクスペリエンスが要求するリソースの間にレイヤーを挿入します。
例えば、デスクトップで使用されるアプリケーションには、モバイルデバイスとは異なる画面サイズ、表示、パフォーマンスの制限があります。
BFFパターンは、どのインタフェースで機能するか、フロントエンドのパフォーマンスに悪影響を与える可能性のある汎用バックエンドをサポートするのではなく、ユーザーインタフェースに最適なオプションを使用して、ユーザーインタフェースごとに１つのバックエンドタイプを作成しサポートすることが可能です。
２つ目は、エンティティと集計パターンです。
エンティティは、そのアイデンティティによって区別されるオブジェクトです。例えば、eコマースサイトのProductオブジェクトは、製品名、タイプ、価格によって区別されます。１つのユニットとして扱われる必要がある関連エンティティのコレクションです。
eコマースサイトでの注文は、購入者が注文した製品（エンティティ）の集合体（コレクション） になります。これらのパターンはデータを分類するために使用されます。
３つ目は、サービス検出パターンです。
このパターンは、アプリケーションとサービスがお互いを見つけるのに役立ちます。
例えば、スケーリング、アップグレード、サービス障害、サービスの終了により、サービスインスタンスが動的に変化する中、一時的な変化に対処するための発見メカニズムを提供します。また、ロードバランシングがトラフィックをリバランスするトリガーとして、ヘルスチェックとサービス障害を使用することもあります。
４つ目は、アダプターのマイクロサービスパターンです。
このパターンは、外国に旅行するときに使用するプラグアダプターと同じ概念で、他の方法では互換性のないクラスやオブジェクト間の相互性を支援します。サードパーティのAPIに依存するアプリケーションでは、アプリケーションとAPIの通信が可能になるように使用することもあります。
マイクロサービスによる開発で避けるべきパターン
避けるべき１つ目パターンは、マイクロサービスから始めることです。
マイクロサービスは、アプリケーションが大きくなり過ぎて扱いにくくなり、更新や保守が容易にできない場合の複雑さを管理する方法です。
モノリスの複雑さや弊害の発生に応じて、アプリケーションをより小さなサービスにリファクタリングする方法を検討する必要があります。
避けるべき２つ目のパターンは、機能を分割しすぎるということです。サービス粒度が小さくなり過ぎると、マイクロサービス全体のメリットを上回る複雑さが発生します。
より大きなサービスに成長したことで、変更をデプロイするのが難しく遅くなったり、データモデルが複雑になったりするなど、マイクロサービスによって解決が見込める場合に分割することが推奨されます。
４．マイクロサービス応用事例
従来のモノリシック・アーキテクチャからクラウドベースのマイクロサービス・アーキテクチャへの移行に成功した企業にNetflixが挙げられ、クラウドベースのロールモデルともされています。
同社のマイクロサービス・アーキテクチャへの移行は２００９年に始まり、完了までは２年以上かかりました。移行に使用された多くのツールはオープンソース化もしています。 その理由は、データとユーザー情報が急増し、それまでのデータセンターに保存することが困難な状況が発生したことです。
移行に際しては、アマゾン ウェブ サービス（以下AWS）を使用し、セキュリティと信頼性が担保された大規模なコンピューティングリソースとデータセンターが提供されました。その上で、モノリシックアプリケーションを数百の小さなサービスへの分割を実行していました。
最初に顧客向けではないムービーコーディングプラットフォームから着手され、AWSクラウドサーバー上で独立したマイクロサービスとして実行しました。 その後、顧客向けシステムもマイクロサービスに変換し、２０１２年に全プロセスを完成させました。
マイクロサービスに切り替えるに従い、デプロイもより頻繁になりました。従来は開発チームと運用チームが分かれて、運用チームがデプロイされる変更点についての直接的な技術や知識を持っていないため、デプロイ時の問題の検知と解決にはより多くのコミュニケーションコストが発生し、全体としてスピード低下を招いてしまいました。
その課題を改善するため、Netflixはフルサイクル開発者（Full Cycle Developers）という開発体制に取り組み、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルの全ての面に関わり、責任を持つ開発チームに切り替えました。
開発チームは開発した個々の機能やサービスに対して開発上の問題、キャパシティプランニング、アラート、サポートといったことに全てオーナーシップを持ち、直接的に対応するようになりました。問題が発生した時、開発者はチーム間で責任を押し付け合うのではなく問題の調査・解決に素早く取り組むことができるようになり、全体の効率が向上しました。
ビジネス変化がますます激しくなる昨今、マイクロサービスの普及とともにより頻繁なデプロイを繰り返すことが避けられないため、フルサイクル開発の応用力もより求められるのではないでしょうか 。
Netflixで現在使用されているマイクロサービスは１０００を超えており、それぞれがサイトの個別部分を管理しています。その成果として、１日あたり約２億５０００万時間の映像コンテンツ、１９０カ国で１億３９００万人以上の加入者にストリーミングしており、現在もなお成長を続けています。
マイクロサービス・アーキテクチャへの移行を発表した当初は、誰もが不可能と考え、多くの批判に直面しましたが、現在ではNetflixがマイクロサービスを駆使するリーディングカンパニーとして成功を収めたことは明らかです。
５．まとめ
マイクロサービスは、アプリケーションを分割し、単一の目的を果す機能（購入ボタンの表示、チェックアウト時の金額計算など）を一つのサービスとして独自にデプロイおよび管理できます。それにより、新バージョンのリリースを短くかつ簡単にでき、言語やフレームワークの柔軟性も生まれるなど、クラウドネイティブを支える最も重要な技術といえます。
その活用範囲はクラウドネイティブの広がりとともに、今後もますます広がることは間違いありません。
次回は、DX時代におけるクラウドネイティブの役割とメリットについて解説します。
