アプリケーションアーキテクトにとって、システム開発の最新情報を常につかんでおくことは重要です。ここでは「アプリケーションアーキテクチャとはどのようなものか」「今後のシステム開発において何が極めて重要になるのか」そして、「どうすれば作業効率を最大化できるシステム設計が可能か」などについて解説していきます。
アプリケーションアーキテクチャとは
アプリケーションアーキテクチャとは、アプリケーションの設計と構築に使用されるパターンと手法を記述したものです。また、それを元にシステムの処理要件（アプリケーション・アーキテクチャ）に関する設計を行うことを指す場合もあります。
アプリケーションアーキテクチャはITアーキテクト（会社の経営戦略を考慮した上でWebシステムの設計を担う職種）が扱う分野の1つです。エンジニアとは、経営に関する箇所を考慮しているかどうかという違いがあります。
システムの設計自体はエンジニアも行いますが、エンジニアは基本的に経営にはノータッチです。アプリケーションアーキテクチャは経営に主眼を置いて、それに見合うアプリケーション設計を行います。
アーキテクチャとは
アーキテクチャとは、システムを分割・構造化したものです。アーキテクチャ設計はシステムの骨格であり、アプリケーション開発を本格的に開始するまでに実施すべきことです。システム全体を考えて設計することはもちろん、経営的な視点で、設計の前段階のそもそもどのようなシステムが必要かを考える箇所もアーキテクチャに含まれます。
インフラストラクチャ・アーキテクチャ
インフラストラクチャ・アーキテクチャとは、システムの土台となる構造の設計を行うことです。インフラストラクチャはそのまま技術的なインフラ箇所を指しています。
システムには必ずインフラがあるので、このインフラ箇所の設計を担うのがインフラストラクチャ・アーキテクチャです。具体的な作業としては、要件定義やインフラストラクチャ・アーキテクチャの設計、評価などの作業が中心となります。
対象となる範囲は、ハードウェアの選択やシステムのセキュリティ、プラットフォームの設計などで、企業のシステムの根幹を支える極めて重要な箇所です。オンプレミスの場合はこれらを自社で行う必要がありますが、クラウド化する場合は業者の管理サーバーを利用することになります。
インテグレーション・アーキテクチャ
インテグレーション・アーキテクチャとは、企業内や企業間のシステムの連携と統合に関する構造、インテグレーション・アーキテクチャに関する設計を行うことです。企業内には複数のシステムがあり、これらをいかに連携させるかという点が作業効率化において極めて重要です。
連携箇所を効率化し、作業効率をアップさせるためにあるのが、インテグレーション・アーキテクチャです。具体的な作業領域としては、要件の定義や、インテグレーション・アーキテクチャの設計、評価などの作業が中心となります。
より具体的には、データのやり取りに使用するフレームワークや、システム間の相互接続性などを担保するための設計を行います。
レイヤーとしては、インフラよりはソフトウェアですが、ソフトウェアの中でも土台の箇所の設計を行う作業になります。端末上で使用するアプリケーションの互換性は、どちらかというと後述するアプリケーションアーキテクチャの領域です。
アプリケーションアーキテクチャの主流タイプ
アプリケーションアーキテクチャはインフラストラクチャ・アーキテクチャと同様に、処理に関する要件定義、アプリケーションアーキテクチャの設計と実現可能性の評価などが中心となります。
アプリケーションアーキエクチャにはタイプがあるので、主流のタイプを紹介していきます。
多層アーキテクチャ
多層アーキテクチャは、アプリケーションを複数の"レイヤー（層）"に分け、それらを独立したモジュールとして開発・保守します。一般的なアプリケーションサーバは、「プレゼンテーション層」「アプリケーション層（ロジック層）」「データベース層」の3層からなります。
こうしたレイヤー間の関係は、全体の管理や論理関数の実行に、相互的な条件となります。例えば、階層化アーキテクチャのレイヤーは水平に配置されるため、呼び出せるのは下層のレイヤーだけです。直下のレイヤーに限定されていることもあれば、下層レイヤーの中の任意のレイヤーを呼び出せる場合もあります。
モノリシック・アーキテクチャ
モノリシック・アーキテクチャは大きな単一の処理で1つの処理を行うアーキテクチャです。内部的には処理ごとにプログラムが分かれていても、すべて同一マシン上に配置されており分割できないという特徴があります。
モノリシック・アプリケーションの1つの側面を更新または拡張すると、アプリケーション全体とその土台となるインフラストラクチャに影響を与えます。アプリケーションコードを1箇所変更するだけで、アプリケーション全体を再リリースする必要が生じます。
このため、更新や新しいリリースは通常、年に1回か2回のみで、新処理を提供するのではなく一般的なメンテナンスが実施されるだけになります。対照的に、先進的なアーキテクチャでは処理性やビジネス能力によってサービスを分割し、アジリティを高めようとします。
マイクロサービス・アーキテクチャ
マイクロサービス・アーキテクチャは、複数の独立した処理を組み合わせて1つの処理を行うアーキテクチャです。それぞれの処理を自由なマシンで実行可能です。マイクロサービスは分散されており、疎結合であるため、相互に影響を及ぼしません。
個々のサービスは、重いインフラストラクチャを使用しなくても必要に応じて拡張していけます。そして、ほかのサービスに影響を与えることなく使用できます。アプリケーション全体を更新するのではなく、個々のサービスに同時に取り組む開発者が増えるため、開発に費やされる時間を短縮し、新しい処理をより頻繁にリリースできるようになるのです。
アプリケーションアーキテクチャが叶えるクラウドネイティブ・アプリケーション
マイクロサービス・アーキテクチャの実現が、クラウドネイティブ・アプリケーションが可能となった理由の1つです。クラウドネイティブ・アプリケーションとはクラウドが前提となったアプリケーションのことです。
まず、クラウドネイティブと対立する概念としてオンプレミスがあります。オンプレミスは自社サーバーにアプリケーションを導入し、そこで管理・利用する手法です。
これに対してクラウドネイティブ・アプリケーションでは、自社に必要な処理をすべてオンライン上のサーバーで管理します。サーバーの管理は専門の業者に依頼することになるので、自社は「開発がスムーズにできる」「アプリケーションの動作が保証される」などのメリットを得られます。
アプリケーションアーキテクチャとクラウドネイティブ・アプリケーションは別の概念ですが、今後自社システムを刷新し、作業効率化を図る上ではどちらも欠かせません。また互いに連動しています。
クラウドネイティブでクラウドを大前提としてシステム設計をしていくことで、初めて最大限作業効率化が図れるシステム設計ができるということです。従来型のオンプレミスだと維持管理に手間がかかる、セキュリティに脆弱性が生まれる、アップデートにいちいち時間がかかる、といった問題が発生します。
システムの進化が速い昨今、アップデートのたびに時間と労力を奪われるのは絶対に避けるべきです。このことから、クラウドネイティブを大前提としたアプリケーションアーキテクチャが必須と言えるでしょう。
まとめ
アプリケーションアーキテクトとは、平たくいえばアプリケーションの設計のことです。ただし、単にシステム的に設計を行うだけでなく、経営にも視点を置き、企業の作業を効率化する、クラウド化を推進する、といった観点も持った上でアプリケーション設計を行う必要があります。
クラウドネイティブなアプリケーションの開発に携わるのであれば、株式会社アークウェイが提供する、「Archway エンタープライズ マイクロサービス Bootcamp」の利用がおすすめです。
