マイクロサービス と モノリス

マイクロサービスは、あらゆる業界おいて主要なトレンドであり、IT 部門だけでなく、企業全体のデジタルトランスフォーメーション (DX) に多大な影響を与えています。IT アーキテクチャの面から、マイクロサービスとモノリスにはどのような違いがあるのでしょうか？そして、Netflix、Google、Amazon といった大手テクノロジー企業がマイクロサービスアーキテクチャに急速にシフトしている理由である 「マイクロサービスの『ベネフィット』とは？」を理解することは重要です。

まずマイクロサービスとモノリス (モノリシックアーキテクチャ) を比べてみましょう。モノリシックアプリケーションは、単体として構築されます。一方、エンタープライズアプリケーションは、3つのパーツに分割して構築します。

• データベース：通常、リレーショナルデータベース管理システム (RDBMS) 内の複数テーブルから構成
• クライアントサイドのユーザーインターフェース：ブラウザー上で動作する HTML ページや JavaScript で構成
• サーバーサイドアプリケーション：HTTP リクエストの処理、ドメインの固有ロジックの実行、データベースからのデータの取得と更新、HTML へのデータ反映

これが一枚岩という意味を持つ『モノリス』と呼ばれる所以です。すなわち、単一ロジックの実行ファイルになるのです。システムに何らかの変更を加える場合、開発者はサーバー側アプリケーションを更新したり、メンテナンスしたり、検証したりと、あらゆる確認や事前準備をしなければなりません。

マイクロサービスの機能は、『ビジネス指向のAPI』と呼ばれており、ビジネスのコア機能をカプセル化するビジネス資産になります。インターフェースはビジネス用語だけで定義されているため、サービスの実装 (記録システム (SOR: System of Record) との統合を含む) は完全に隠蔽されます。

サービスを重要なビジネス資産として位置付けることで、複数コンテキストで使用するための「適応性」が強化されます。同一のサービスが、複数の異なるビジネスプロセスやビジネスチャネル、デジタルタッチポイントで再利用することが可能になります。

「疎結合の原則」を適用することで、サービスと利用者の依存関係を最小化します。ビジネス指向のAPIによるインターフェースを標準化することにより、サービスの実装が変化しても利用者は影響を受けません。これにより、サービスオーナーは下流工程に影響を及ぼすことはありません。

従来のソフトウェア開発プロセス（ウォーターフォール、アジャイルなど）では、比較的大規模なチームが、単一のモノリシックシステム（一枚岩のシステム）の導入に取り組むことが一般的でした。プロジェクトマネージャーや開発者、運用スタッフが、成功の度合いは異なりますが、これらのモデルで特定のソフトウェアや導入スタックの使用経験や、ビジネスアプリケーションの開発経験を積むことで、特にビジネスで検証できるアプリケーション候補をリリースすることが可能になります。しかし、従来のアプローチにはいくつかの問題が潜んでいます。

• アプリケーション全体を把握できる開発者 (（または開発者グループ) ）が誰もいなくなり、モノリシックアプリケーションが「Big ball of mud (大きな泥の塊)」になってしまうこと
• モノリシックアプリケーションでは、再利用が限定的であること
• モノリシックアプリケーションでは (将来的な) 拡張が困難であること
• モノリシックアプリケーションを前提とした開発とデプロイは、運用にアジリティをもたせられないこと
• モノリシックアプリケーションは、単一の開発スタック ( JEE や .NET など) を使用して実装されるため、「実装に最適なツール」の利用が制限される場合があること

一方、マイクロサービスアーキテクチャは、クラウド技術、API 管理、インテグレーションテクノロジーを組み合わせることで、ソフトウェア開発の代替アプローチです。モノリスを個別のサービスに分割することで、開発、デプロイおよび保守を独立して行えます。これには次のような大きなメリットがあります。

• 少人数の開発者で小規模なサービスをフレキシビルに構築できること (この小規模アプローチは推奨されています)
• サービスは、言語バインディングや共有ライブラリの使用を強いられるなどの制限がなくなり、他のサービスやアプリケーションから利用および再利用することができること
• サービスは独立して存在し、他サービスに影響することなく規模の変更が可能なこと
• サービスを個別に開発することで、開発者は既存のタスクに適した開発フレームワークを利用できること

「柔軟性」と「複雑性」がトレードオフの関係になります。多数のサービスを管理することは、決して簡単ではありません。以下に記している 2 つが、その大きな理由となっています。再利用できそうなサービスを、社内の他の開発チームが簡単に見つけ出せるようにすべきでしょう。。ドキュメントやテストコンソールなどを用意しなければなりません。ただし、サービスが再利用できるようになれば、スクラッチで開発するよりも生産性を圧倒的に向上することができます。
サービス間の依存関係は、注意深く監視しなければなりません。サービスのダウンタイムや障害、アップグレードなどは、下流に影響を与えます。問題発生時に限らず解析すべきでしょう。
マイクロサービスのデプロイとデリバリーが慎重に管理され、ソフトウェア開発ライフサイクル (SDLC: System Development Life Cycle)」 が可能な限り自動化されていることが重要です。DevOps スタイルのチーム構成と連携、および自動化がなければ、マイクロサービスはメリットよりもデメリットのほうがはるかに大きくなってしまうのです。