モノリシック・アーキテクチャーとマイクロサービスの比較：あなたに合うのはどちら？

モノリシック・アプローチは、伝統的なソフトウェアのモデルです。マイクロサービスはより最近のソフトウェア開発を反映したものですが、だからといってモノリシック・アーキテクチャーが時代遅れになったわけではありません。

あなたが技術系のスタートアップ企業で働き始め、新会社のITプランの導入を任されたとしましょう。決めるべき事柄は膨大にありますが、モノリシック・アーキテクチャーかマイクロサービス・アーキテクチャーかを選ぶことほど、基本的で広範囲にわたる決定はありません。ソフトウェア・アーキテクチャーの選択は、組織の初期および最終的なデータ処理ニーズを明確に理解することなしに、空白の状態で決めるべきではありません。なぜなら、どちらのアーキテクチャー・アプローチを選択しても、組織のビジネス目標を有意義に実行する能力に多大な影響を及ぼすからです。

つまり、ここでの賭けは非常に大きなものとなります。そしてあなたは新任のIT部長であり、これはあなた個人にとっても重要な決断です。賢く選択すれば、計り知れないキャリアアップの黄金の道が開けるかもしれません。

どちらを選ぶべきでしょうか。まずは選択肢を確認します。

前述のとおり、モノリシック・アーキテクチャーは従来のソフトウェア開発モデルです。その中では、1つのコードベースが複数の機能（つまり、ビジネス機能）を実行します。コンピュータ・カーネルがすべての機能を制御します。モノリシックなアプリケーションでは、アプリケーション全体に必要なすべてのコードが中央拠点で管理されます。

モノリシックなアプリケーションには通常、次のコンポーネントが含まれます。

• クライアント側ユーザー・インターフェース（UI）： 「クライアント側」とは、ユーザーのコンピューティング・デバイスに表示される内容に関係します。UIは、画像、テキスト、その他のUI画面を介して送信できるブラウザー・アクションに関連する情報など、ユーザーが見ているものを管理します。

• データベース：モノリシック・アーキテクチャーでは、データを行と列に整理するデータベースの一種であるリレーショナル・データベース管理システム（RDMS）が使用されます。これらの行と列は、データ・ポイントが相互に関連するテーブルを形成します。

• サーバー側アプリケーション：サーバー側アプリケーションは、メモリ、 CPU 、ストレージなどのサーバー・リソースを処理します。

モノリシック・アーキテクチャーを使用すると、以下に挙げる数多くのメリットが得られます。

• 煩雑さを抑えたアプリケーション開発：単一のコードベースで構築されたアプリケーションは、より速く開発でき、よりシンプルに構築できます。

• 比較的簡単な導入： モノリシック・アーキテクチャーは1つの実行可能ファイルまたはディレクトリーで動作するため、導入の難易度は低くなります。モノリシック・アーキテクチャーは、使用するコンポーネントが少ないため、保守も簡単です。

• シンプルなデバッグ：モノリシック・アーキテクチャでは、テストとデバッグのオペレーションはそれほど必要ありません。エンドツーエンドのテスト・オペレーションが、中央のログシステムから実行されます。

• 高いセキュリティー：モノリシック・アーキテクチャーは閉じたシステムであるため、データ処理作業は外界から遮断されており、サイバー脅威から保護されます。

モノリシック・アーキテクチャーの使用には、次のような問題が生じる可能性もあります。

• 新しいテクノロジーに適応しにくい： 通常、モノリシック・アプリケーションは緊密に結合されているため、新しいテクノロジーの統合が困難な場合があります。

• 低い拡張性：必要な拡張が比較的小規模な場合（一つの機能の調整など）であっても、新しい変更を反映させるためにシステムを事実上解体し、再構築しなければならない場合があります。時間と労力がかかるかもしれません。

もう 1 つのソフトウェア開発モデルであるマイクロサービスは、クラウドネイティブのアーキテクチャー形式です。マイクロサービスでは、アプリケーションは複数の疎結合コンポーネントまたはサービスを基盤とします。マイクロサービス・アプリケーションには独自のテクノロジー・スタックがあり、これは特定のジョブを実現するために連携するテクノロジーの集合です。

マイクロサービスの主な利点は、システム全体に影響を与えることなく、アプリケーション内の新しいビジネス機能に対応するためにシステムを簡単に更新できることです。これは、時間と労力の両方の大幅な節約につながります。

マイクロサービスの利点は数多く存在します。絶え間ないビジネスの成長と新たな技術革新の両方に対応できるのです。

• 拡張性の向上： マイクロサービスは、モノリシック・アーキテクチャーと比べて拡張性に優れています。マイクロサービス・アーキテクチャー内の個々のサービスはモジュールに分解され、単一の拡大指示を複数のサービスに同時に送信できます。また、マイクロサービスは、大規模で複雑なアプリケーションの処理に適しています。

• 自動化に対応： マイクロサービスを使用することで、組織は継続的インテグレーション／継続的デリバリー (CI/CD) プロセスを自動化できます。これにより、継続的なスケジュールに従ったコード更新の開発が可能になります。

• オペレーション： マイクロサービス・アーキテクチャーは、各サービスを運用セルに分割します。このような独立したオペレーションにより、1 つのマイクロサービス・アプリケーションのワークフローが他のマイクロサービス・アプリケーションのワークフローに侵入する危険がなくなります。

マイクロサービスには確かなメリットがあるものの、その複雑さゆえに問題もあります：

• テストのハードル：マイクロサービスでは、アプリケーションのさまざまな部分をテストするまではデバッグのオペレーションを始めることができません。ここには依存関係のチェック、キャッシュ・アクティビティ、データ・アクセスなどが含まれます。

• 潜在的なセキュリティリスク：マイクロサービスシステム内のさまざまなプロセスの間で行われるデータ交換には、アプリケーション・プログラミング・インターフェース (API) ゲートウェイが使用されます。APIゲートウェイは、認証やその他の重要な活動でセキュリティー上の脆弱性を生み出す可能性があります。

• レイテンシーの急増：マイクロサービスではアプリケーションの驚異的な拡張が可能ですが、その分、ラグやレイテンシーが増えるという問題が起こることがあります。システムの規模が大きくなるほど、複雑さとデータの転送量が増え、処理が遅くなる可能性があります。

モノリシック・アーキテクチャーとマイクロサービス・アーキテクチャーを直接比較する前に、より広範なコンテキストを提供できるよう、いくつかの歴史的な詳細をストーリー仕立てで紹介します。

ある意味で、モノリシック・アーキテクチャーの起源を特定の日付まで追跡することは困難です。テクノロジーが複雑になればなるほど、そのテクノロジーが実現した時点を特定することは難しくなります。モノリシック・アーキテクチャーも同様です。その開発は20世紀の中ごろに始まりました。

International Business Machines（IBM）は、その重要な初期開発において主要な役割を果たしていました。DZoneの寄稿者、Pier-Jean Malandrino氏は、「IBMのような企業は、1960年代と1970年代にメインフレームコンピュータを開発することで、初期のソフトウェアアーキテクチャの定義に重要な役割を果たした」と述べています。¹

モノリシック・アーキテクチャーは完璧ではありませんでした。多くの場合は非常に簡素な言語で書かれており、1台のマシンで読み取ることを目的としていました。システム全体を搭載した機械は1台しかないため、すべてのコンピューター・コンポーネントは密結合でした。拡張性は存在しないか、かろうじて可能という程度で、通常はシステムの完全な再構築が必要でした。

あるいは、モノリシック・アーキテクチャーが現在の視点から原始的に見えるとしたら、それは他のどのソフトウェア・アーキテクチャーのシステムよりも前に、最初に登場したからでもある、とも言えるでしょう。そしてモノリシック・アーキテクチャーは長期にわたってつねに有用であり、回復力があることさえ証明されています。普通であれば絶え間ない変化だけが残るこの業界において、モノリシック・アーキテクチャーが導入から70年経った今でも使われているという事実は、多くを物語るものです。

モノリシック・アーキテクチャーは進化し続けていますが、すでにかなり前から、もはや唯一の手法ではなくなっています。1980年代が進むにつれて、ソフトウェア・エンジニアリングではモジュール性とオブジェクト指向プログラミング言語の使用が普及しました。1990年代までには、ネットワーク・コンピューティングの最近の進歩を活用できる分散システムの舞台が整っていました。

これが最終的にマイクロサービスの開発につながり、2000年代のクラウド・コンピューティングとコンテナ化テクノロジーの登場以降、広く使用されるようになりました。マイクロサービス・アーキテクチャーは、モノリシック・モデルを迅速なスケーリングと分散システムに対応させて改善するために作り出されたものです。

現在、2020年代には、ソフトウェア開発はモノリシック・アーキテクチャーまたはマイクロサービス・アーキテクチャーのいずれかから展開します。技術の変化から得られる期待に基づいて、誰しも初めは、最近になって登場したテクノロジーの方が優れていると考えがちです。状況によっては間違いなくその通りでしょう。

しかし、こうした十把一絡げの発言は危ういものです。単純に真実ではないからです。モノリシック・アーキテクチャ・モデルのシンプルさがコンピューティングで役立つ場面は、依然として数多く存在します。

どちらのソフトウェア・アーキテクチャーにも長所と短所があり、企業はどちらかのシステムを採用する前に、両方のタイプを慎重に評価し、予想されるアプリケーション開発のニーズを検討する必要があります。

主要な運用段階全体から見ると、モノリシック・アーキテクチャーとマイクロサービス・アーキテクチャーはどのように比較できるでしょうか。

• 創造： この2つのアーキテクチャー形式の主な違いは、まず必要なシステムを構想する初期段階にあります。モノリシックな・システムは、より基本的な設計を使用するため、構築がより簡単です。マイクロサービスはかなり複雑で、実現にはより大きな計画が必要です。

• 構造： モノリシック・アーキテクチャーは、単一のユニットとして設計・構築されます。マイクロサービス・アーキテクチャーはモジュール化の概念を活かしたものであり、より小規模でデプロイメント可能なアプリケーションを集めたものを使用して、独立した複数のサービスのオペレーションを可能にします。

• 複雑さ： システムが複雑になればなるほど、マイクロサービス・アーキテクチャーに適しています。モジュール構造のマイクロサービスは、複雑さを増すことの多い新しい機能や新しいテクノロジーを歓迎します。

• 成長： 最初に使用する時点では、モノリシック・アーキテクチャーとマイクロサービス・アーキテクチャーはどちらも有用かもしれません。しかし成長によって、特に組織が、初期のシステムを超えて間もなく拡大するということがわかると、全てが変わります。その時期には、企業にはより大規模なオペレーションのステージが必要です。モノリシック・アーキテクチャーよりも多くの拡張手段を備えたマイクロサービスであれば、それを実現できます。

• 市場投入までの時間： この重要な指標は、商品を製造して流通チャネルに投入するまでの時間を測定することで、商業の面で極めて重要な役割を果たします。市場投入までの時間は、モノリシック・アーキテクチャーがマイクロサービスを超えて優れている分野です。単一のコードベースのみを使用することで、開発者はさまざまなソースからソフトウェアを組み込むための余分な時間と労力を回避できます。

• スケーラビリティ：マイクロサービス・アーキテクチャーは、モジュール形式で分割可能な個々のサービス上に構築されており、API使用による疎結合と相互通信の利点を活かすことができます。一方、モノリシック・アーキテクチャーは、深く構成されたコア構造と密結合されたソフトウェアのために、全体的な適応性が低くなります。

• デバッグ： デバッグとは、ソフトウェアを使ってコーディングの問題を感知し、見つけ出し、その問題を修正するプロセスを指します。モノリシック・アーキテクチャーは、マイクロサービスよりもシンプルでわかりやすいため、デバッグをうまく処理できます。マイクロサービス・アーキテクチャーのデバッグは大幅に時間がかかり、より複雑で手間のかかるものです。

モノリシック・アーキテクチャーまたはマイクロサービス・アーキテクチャーのいずれかを使用することで実現できるユースケースはほぼ無制限にあります。最も一般的なものをいくつか紹介しましょう。

• スタートアップ企業：創業間もない企業には、柔軟性と創業資金の2つが（潤沢に）必要です。モノリシック・アーキテクチャーは、新しいビジネスを開始するための最良の方法です。さらに、小規模なチームで費用対効果の高い方法で構築することができ、習得にもそれほど労力がかかりません。

• 基本プロジェクト： コードベースが1つで済むということは、特に基礎的なプロジェクトの場合にはメリットをもたらします。ソフトウェアが複数のソースからデータを取り込むことなく開発プロセスを進めることができれば、それは組織にとって勝利となるでしょう。

• エンターテインメント・プラットフォーム：国際的なエンタテインメント・プラットフォームを運営するには、需要が軽いワークロードになるか重いワークロードになるかにかかわらず、ワークロードの潮流の変化に対応する能力が必要です。動画ストリーミングの大手であるNetflix社はモノリシック・アーキテクチャーからクラウドベースのマイクロサービス・アーキテクチャーへと移行しました。Netflixの新しいバックエンドには多くのロード・バランサーのサポートが含まれており、ワークロードの最適化を支えています。

• 電子商取引：電子商取引は、マイクロサービス・アーキテクチャーを活用し、シームレスなユーザー・エクスペリエンスで電子市場の魔法を実現します。アマゾン（AWS）のような野心的な小売業者は、より便利で迅速な配送で販売を促進しています。2023年のeコマース売上市場が5兆8,000億米ドルに達した理由は明白でしょう。²

• 最も難しい仕事：マイクロサービスの継続的な使用には通常、そのアーキテクチャー・フレームワークに必要な特定のサービスを作成できる、訓練を受けたDevOpsチームの実装および管理スキルが必要です。こうしたスキルは、複雑なアプリケーションに直面する際に特に役立ちます。

モノリシック・アーキテクチャーやマイクロサービス・アーキテクチャーの本格的な実装は、その方程式のもっとも重要な部分、つまりあなたの属するテクノロジー・スタートアップ企業の具体的なニーズを最初に考慮することなく、真空状態で設計してしまうと、必然的に道を誤ることになります。

IT部門のディレクターとして、ソフトウェア・インフラストラクチャーの決定を計画する際、これは最も重要な作業となります。あるアーキテクチャー形式を使うべき時を把握しておくことは、必要な用途に基づいて最適なシステムを理解することと同様に不可欠です。

組織に最適なアーキテクチャー・システムを選択するだけでなく、今後数か月および数年後に企業が必要とするアーキテクチャー・システムを正確に推定することもあなたの仕事ですから、自社分析の作業が高い価値を持つものになるでしょう。ある意味で、あなたは未来を予測する仕事を任されているぼです。

モノリシック・アーキテクチャーはスタートアップ企業にとって完全に理想的であるように見えるかもしれませんが、将来の成長の予測はあなた次第です。また、急激な拡張が予想される場合は、先手を打ってマイクロサービス・アーキテクチャーに投資することが賢明である場合もあります。考慮すべき変数は多数あります。

• 使用されているビジネス・ロジック：コンピュータ・ロジックが、コンピュータで可能なことと不可能なことを決めるのと同様に、ビジネス・ロジックは、ビジネスを運用可能な方法と運用不可能な方法を規定するビジネスルールに基づいています。技術的には、これはデータベースとユーザー・インターフェイスの間で情報がどのように渡されるかを定義するアルゴリズムに変換されます。

• フロントエンド開発： ソフトウェア・アーキテクチャーのフロントエンドを計画する早い段階で、従うべきアーキテクチャー・アプローチを定義する必要があります。それぞれのアプローチに固有の構造があるためです。モノリシック・アーキテクチャーでは、フロントエンド・アプリケーションは、すべてのアプリケーション・コードを格納する1つの大規模なコードベースとして表現されます。マイクロサービスのフロントエンド・アプリケーションでは、独立して動作する複数のマイクロサービスを稼働させることができます。

• 耐障害性：もう1つ考慮すべき点は、どの程度の耐障害性が必要になると予想されるかという点です。システム内のたった1つのコンポーネントに障害が発生するだけで、アプリケーション全体がダウンする可能性があることから、耐障害性は非常にやっかいな問題です。モノリシック・アーキテクチャーではコンポーネント間の分離がないため、耐障害性の欠如が深刻になり、ダウンタイムが長期化するおそれがあります。

• 予想される変化の度合い： モノリシック・アーキテクチャーとマイクロサービス・アーキテクチャーの選択は、単にソフトウェア・アーキテクチャーを選ぶというだけではありません。実際には、シンプルに稼働を始めたいのか、持続性のある事業成長にこだわるかという、2つのビジネス・マインドセットのどちらかを選択するということです。成長は困難な場合もありますが、開発サイクルの短縮や拡張性の向上など、マイクロサービス・アーキテクチャーの特性が十分なサポートを提供します。