現在は、様々なシステム開発が行われていますが、それぞれのシステムを作る際には、「設計」というものが必要になってきます。 ・なんのために作るのか ・どのような方針で作るのか ・チームメンバーと共有するべきルールはなにか 特に「より高度なシステムを短期間で開発する」という事が求められている現代では、多くのメンバーが同時に開発を進める事も多いです。 そのため、より設計の思想や基本的な構造そのものが重要になってきます。 モノリシックアーキテクチャという言葉を聞いたことがありますか？ また、モノリシックな構造とはどのような構造でしょうか？ モノリシックアーキテクチャは、ソフトウェアの分野で設計思想や基本構造を指す言葉ですが、具体的にどのようなものでしょうか？ 今回は、モノリシックアーキテクチャについて、概要とモノリシックな構造との関係、アプリケーション開発での位置づけと、歴史的背景、現状、将来性について解説します。
モノリシックな構造とは
モノリシックな構造とは[/caption] 先ず、モノリシックな構造について考えてみます。
モノリシックの意味
モノリシックとはどういう意味でしょうか？ モノリシック（monolithic）とは一枚岩を指す言葉で、単一の岩や石のように 「単一な塊として設計された構造物」 を形容する際に用いられます。 ソフトウェア以外にも半導体集積回路やコンクリートなどの分野でも用いられている言葉です。
ソフトウェアでモノリシックとは
では、ソフトウェアにおけるモノリシックとはどのようなことを指すのでしょうか？ 形容詞monolithicの元となる名詞はmonolith（モノリス）です。 ソフトウェアの分野で最初にモノリスという言葉を使ったのは 「The Art of Unix Programming」 という本の中で、 「大きすぎるプログラム」 を指していました。 「大きすぎる」ことを問題視していますが、どのような不都合が生じるのでしょうか？ アプリケーションの場合、 「内部が密結合している」 ので、アプリケーションの一部を更新または拡張するとアプリケーション全体と基盤のインフラにも影響することがあります。 そのため、一部の機能を変更しようと考えたり、機能を追加しようとしたりする際に ・どこまで影響が出るかわからない ・多くの範囲のテストが必要になる ・仕様を把握できている人が少ない といった問題が起こる危険性があります。 激変するビジネス環境の変化への追従が困難になり、次第にシステムが古く使いにくいものになります。 この結果、大規模なシステム更改を定期的に繰り返さなくてはいけなくなるのです。 ここで、述べた「内部が密結合している」はソフトウェアの基本構造を示しています。
ソフトウェアの基本構造とアーキテクチャ
ソフトウェアの基本構造とアーキテクチャ[/caption] ここではソフトウェアの基本構造とは何かを考え、アーキテクチャとの関連を説明しましょう。 さらに、アプリケーション・アーキテクチャについても言及します。
システムの設計思想と基本構造をアーキテクチャと呼ぶ
IEEEの定義によれば、アーキテクチャとシステムの意味は次の通りです。 アーキテクチャは、下記の様に定義されます。 「コンポーネント」、コンポーネント間および「環境」との「関係」、またその設計と進化の指針となる原理に体現された「システム」の「基本構造」である。 次に、システムは下記の様に定義されます。 特定の機能もしくは機能セット実現のために組織化されたコンポーネントの集合である。 少し難しい表現になってしまいましたが、アーキテクチャがシステムの基本的な構造であることが重要です。
システムのアーキテクチャには様々な種類がある
システムのアーキテクチャとしては、クライアントサーバーモデル、分散コンピューティングなど様々あり、アプリケーション・アーキテクチャもその中の１つです。 アプリケーション・アーキテクチャには 「スコープ（適用範囲）の視点」 から捉えたものや 「テクノロジーの視点」 から捉えたものなど様々あります。
スコープの視点：全体最適型と部分最適型
全体最適型は、企業の業務とシステムの全体像を俯瞰的・総合的に捉え、全体最適化の観点から設計方針と基本構造を決め、各アプリケーションの開発・導入の際に指針として参照するものです。 部分最適型は、企業の一部門の業務とシステムについて全体像を描き、部分最適化の観点からアプリケーション開発や導入をするものです。
テクノロジーの視点
テクノロジー視点のアプリケーション・アーキテクチャは、個々のアプリケーションを構築する際に参照すべきベストプラクティスと、スタート時に従うべきロードマップを提供します。 ロードマップは、 ・アプリケーションの設計と構築に使用される ・パターン（問題解決のソリューション）と手法 に関して案内役を務めるものです。 次章以降は、テクノロジー視点のアプリケーション・アーキテクチャについてのみ解説しますので、「テクノロジー視点の」という語句を省いた表記にします。
アプリケーション・アーキテクチャ
アプリケーション・アーキテクチャ[/caption] ここでは、前章で取り上げたテクノロジー視点のアプリケーション・アーキテクチャについて深く掘り下げていきましょう。
アプリケーション開発の進め方
提供されるベストプラクティスやロードマップを利用して開発を進めます。 この際、既存で動作の保証されたパターンを利用し、実装に関する規定はありませんから開発目標に適したプログラミング言語を選んで開発することになります。 具体的には、フロントエンドとバックエンドに分けて開発したり、様々なアプリケーション・アーキテクチャのタイプの中から目的に合ったものを選択してそれに倣って開発したりします。 なお、前者による開発の場合はフロントエンドではユーザーエクスペリエンスに、バックエンドではデータ・サービス・既存システムとの連携に注力することになります。
アプリケーション・アーキテクチャのタイプ
ここでは、アプリケーション・アーキテクチャのタイプについて見ていきます。 この中で、「モノリシックアーキテクチャ」という言葉が出てきますが、アプリケーション・アーキテクチャの１つの概念として登場する点に注意して下さい。 「モノリシックアーキテクチャ（モノリス）」は昔からあるタイプで、アプリケーションの提供する全機能を１つのモジュールに包含し、それらは密結合したものです。 同じように、昔からあるタイプに「多層化アーキテクチャ」があります。 これは、オンプレミスやエンタプライズ・アプリケーションに多いアーキテクチャです。 アプリケーションは幾つかのレイヤーに分けて作られ、下層レイヤーと密結合しています。 近年、取り上げられることの多い「マイクロサービスアーキテクチャ」は、アプリケーションを互いに独立した最小単位のコンポーネントに分割したサービスとし、APIを介して連携したものです。 マイクロサービスは分散されており、疎結合によりアプリケーションの機能を実現します。 それ以外に、「イベント駆動型アーキテクチャ」があります。 これは疎結合で、IOTなどリアルタイム処理が必要なアプリケーションに多く採用されています。 なお、10年程前に話題となったものとして「サービス指向アーキテクチャ」があります。これは、疎結合で、アプリケーションをコンポーネントに分割し、エンタープライズ・サービス・バスを介して連携するものです。
モノリシックアーキテクチャ
モノリシックアーキテクチャ[/caption] モノリシックアーキテクチャは、アプリケーション・アーキテクチャの分野でどのように捉えられているのか、その歴史的背景と現状、将来性について考えていきましょう。
モノリシックアーキテクチャとは
モノリシックアーキテクチャとは、 ・アプリケーションを構成する全てのコンポーネントを１つのユニットに収容する ・アプリケーションの設計思想と構造 を持ったものです。 また、アプリケーションはWindowsやLinuxなどの汎用OS上のプロセス（ブログラムの実行単位）として動きます。 モノリシックアーキテクチャとは、 ・アプリケーションの設計思想と構造が ・単一のプロセスで動作するように一体化されているモジュールを構成するもの と言い換えることもできます。
モノリシックアーキテクチャは見直されつつある
ここでは、モノリシックアーキテクチャの抱える問題点が指摘され、時代遅れのように扱われた時期もありましたが紆余曲折を経て再び見直しが進んでいる現状を見ていきましょう。 次に紹介するのは、ウェブアプリケーションのバックエンドアーキテクチャの例です。
バックエンドアーキテクチャの変遷
ウェブアプリケーションは1990年代に登場し、モノリシックアーキテクチャを持つものでした。 1997〜1999年：モノリシックアーキテクチャは「無秩序でつぎはぎだらけでメンテナンスしにくいソースコードに陥る」ことが広く知られるようになりました。 2014年：マイクロサービスアーキテクチャが発表され、ウェブアプリケーションに適用され始めましたが、期待していた程は広がりませんでした。 2017年：マイクロサービスアーキテクチャとモノリシックアーキテクチャの中間的な「ミニサービスアーキテクチャ」が発表されました。 2018年：モノリシックアーキテクチャをベースにした「モジュラーモノリス」が発表され、現在に至っています。
各バックエンドアーキテクチャの違い
「モノリシックアーキテクチャ」は、アプリケーションを１つのモジュールにして、デプロイするものです。 「モジュラーモノリス」は、アプリケーションを複数のモジュールに分割し、１つのアプリケーションとして纏めてデプロイするものです。 「ミニサービスアーキテクチャ」は、アプリケーションを複数のサービスに分割し、幾つかのサービスを纏めてデプロイするものです。 「マイクロサービスアーキテクチャ」は、アプリケーションを複数のサービスに分割し、１つずつバラバラにデプロイするものです。
デプロイが少ないことは大きな魅力
ソフトウェアを構成するプログラムなどをパッケージにまとめ、使用環境に導入可能な状態に組み立て、実際の使用環境に展開する一連の作業をデブロイと言います。 また、プログラムの更新などで生ずる入れ替え作業も含むこともあります。 このように、デプロイは手間のかかる作業ですから、デプロイの回数が少ないのは実務上大きな魅力になり、モノリシックアーキテクチャ再評価の要因の１つになっています。
モノリシックアーキテクチャには将来性があるか？
前記のようにモノリシックアーキテクチャが再評価されていることと、下記のメリットとデメリットから、将来性はあり続けると考えられます。 少なくとも、小さなアプリケーションを構築するときには間違いないでしょう。 以下では、その根拠となるモノリシックアーキテクチャのメリットとデメリットを見ていきましょう。
メリット
第一のメリットは「開発が簡単なこと」で、 ・単純明快な構成の為、コーディングやテスト、デバッグが容易 ・必要な開発スキルはマイクロサービスアーキテクチャほど高くない ことが挙げられます。 開発の単純さは、IT人材が不足している現代で 「開発経験が浅い人材」 でもプロジェクトの参画が可能で、且つそれらの人が作ってもバグの少ないシステム（もしくはバグがあってもすぐに修正できる）が開発可能になります。 構造が複雑になればなるほど、1つのバグの原因を見つけるだけでも工数を必要とし、予算を圧迫する危険性があります。 第二のメリットは「導入や運用・保守への対応が楽なこと」で、 ・ユーザー数の増大にはサーバーのアップグレードで対応することで、少人数のeコマースから始めて大人数にまで対応できます ・デプロイが一回で済む ことなどが挙げられます。 第三のメリットは「高速処理速度が可能」なことで、これはAPIを介した通信を使わないからです。
デメリット
第一のデメリットは「メンテナンスの難しさ」で、 ・コードが大きくなりすぎると問題が深刻化する ・アプリケーションコードの一カ所を変更するだけで、アプリケーション全体をデプロイする必要がある ・障害が発生した場合、アプリケーション全体をクラッシュさせることがある ことがその要因です。 第二のデメリットは、「BtoCなどのアプリケーションで要求されることの多いスケーリングには対応できない」ことです。
システム開発ならAMELAに
システム開発ならAMELAに[/caption] 今回は、モノリシックアーキテクチャについて見てきました。 少し内容的には難しいものになりましたが、これからのプログラム開発における基本的な方針を見直す一つのアイデアとして活用して頂ければと思っています。 AMELAでは、日々新しい技術を学んでいるITエンジニアが多数在籍しています。 これからシステムを開発したいという会社様も、 「理想はあるけど、本当にシステムにできるのか」 という疑問を持たれている企業様も、是非ご連絡下さい。 専門のITコンサルタントが御社の状況をヒアリングした上で最適な提案をさせていただきます。
