大半が淘汰される？これからのシステムエンジニアの理想像とは(7) システムアーキテクチャの変遷

はじめに

NTTデータ先端技術株式会社にてアジャイル開発並びに技術調査業務に従事している志田です。業務の中ではこれから作ろうとする、またはすでに稼働しているシステムの設計やアーキテクチャに関してレビューを行うアセスメント業務も実施しております。この中でよく、現行のアーキテクチャは古く、モダンなアーキテクチャに変更したいといった声を聴きます。今回は、Webシステムに着目しアーキテクチャの変遷とモダンなアーキテクチャとは何かと、アーキテクチャの根底の思想から今後主流となりうるアーキテクチャについて解説します。

Webシステムアーキテクチャ

システムアーキテクチャの変遷

2000年代初頭のWebシステムアーキテクチャ

2000年代初頭、Webシステムのアーキテクチャは主にモノリシックな設計でした。これは、すべての機能が1つの大きなアプリケーションに統合されている設計です。この設計は、開発とデプロイが容易である一方、システムが大きくなるとスケーリングやメンテナンスが困難になるという欠点がありました。

アプリケーションの実装には一般的には3層アーキテクチャと呼ばれる設計が主流でした。これは、プレゼンテーション層、ビジネスロジック層、データアクセス層の3つの層から成り立っています。この設計は、各層が独立しているため、一部の変更が他の部分に影響を与えにくいという利点がありました。

2000年代半ばになると、SOA（Service Oriented Architecture）が登場しました。SOAは、システムを複数の独立したサービスに分割し、それぞれが特定のビジネス機能を提供するという設計です。これにより、システムのスケーラビリティとメンテナンス性が向上しました。また、各サービスは独立しているため、一部のサービスが変更されても他のサービスに影響を与えにくいという利点があります。

この他にもMDA (Model Driven Architecture)やシステムアーキテクチャデザインパターンなどWeb3層(または4層)のアーキテクチャ上で、層ごとにどのようにアプリケーションを分離するかが注目されていた時代でした。

マイクロサービスアーキテクチャの台頭

2010年代に入ると、マイクロサービスアーキテクチャが台頭しました。マイクロサービスは、SOAの考え方をさらに進化させ、システムをより小さなサービスに分割します。これにより、各サービスは独立して開発、デプロイ、スケールすることが可能となり、大規模なシステムでも柔軟に対応できるようになりました。また、各サービスは独立しているため、一部のサービスが変更されても他のサービスに影響を与えにくいという利点があります。

マイクロサービスが普及してきた背景として、仮想マシンやDocker、またIaaSといったサービス、技術が普及したためサーバを複数台用意し、それぞれを別々のネットワークに繋ぐといった方法がこれまでと比べて非常に簡単に、かつ低コストで実施できるようになりました。細かい単位で分離するほど管理は簡単になり、また分離された各システムを横越でつなぐためのゲートウェイとなるフレームワークやサービスも登場し、マイクロサービスアーキテクチャはシステム化を行う際の主要な選択肢のひとつとなりました。

クラウドネイティブアーキテクチャの普及

最近では、クラウドネイティブアーキテクチャが普及しています。クラウドネイティブアーキテクチャは、クラウドの特性を最大限に活用することを目指した設計です。マイクロサービス、コンテナ化、DevOps、CI/CD（Continuous Integration/Continuous Deployment）などの技術が組み合わせられています。コンテナ化により、アプリケーションのデプロイとスケーリングが容易になります。また、DevOpsとCI/CDの導入により、開発と運用の効率が大幅に向上しました。さらに、マイクロサービスアーキテクチャの採用により、システムのスケーラビリティと耐障害性が向上しました。

クラウドネイティブアーキテクチャは、これまで開発側で実施する必要があったさまざまな要素をクラウドが提供するサービスに置き換えることになります。

サーバレスアーキテクチャとエッジコンピューティング

十分普及しているとは言い難いですが、近年注目されているアーキテクチャとしてサーバレスアーキテクチャとエッジコンピューティングがあります。サーバレスアーキテクチャは、サーバの管理をクラウドプロバイダに委ね、開発者がビジネスロジックに集中できるようにする設計です。エッジコンピューティングは、データをクラウドではなくネットワークのエッジ（つまり、データが生成される場所に近い場所）で処理することで、レイテンシを低減し、プライバシーを保護する設計です。

システムアーキテクチャの目的

システムアーキテクチャの目的を端的にまとめると以下のようになります。

複雑なシステム要求を単純なパーツに分離することで複雑さを排除した上で実装できるようにする
要素を分離し、疎結合にすることで変更時の影響を抑える
システムの構造全体を可視化し、実装者以外でもシステムを理解できるようにする

システムアーキテクチャ自体はシステム設計を行うための方針や制約条件となります。システムに対する多種多様な要求があり、要求を実現するための多種多様な技術があり、アーキテクチャという指針無くこれらの選定と実装を行うとすると混乱してしまいます。このため、システム開発の集合知としてシステムアーキテクチャがあり、多種多様な要求が来た際にもシステムアーキテクチャをベースに検討することで、どのように実現するかというイメージがつきやすくなります。この複雑な要求に対し、てこの機能はアーキテクチャ上のここで、この非機能要件はアーキテクチャの構造上保証できるといった要所で、単純化して解決していくことで複雑なシステム要求を簡略化して理解し、実現できるようになります。

この分離原則によってシステムアーキテクチャ上の各コンポーネントがおのずと分離されていきます。この分離によって各コンポーネントは疎結合となり、システム開発や運用時に発生する変更に対しても影響を抑えられるようになります。

また、システムアーキテクチャを表現する際、ほとんどの場合図版が用いられます。マイクロサービスアーキテクチャを採用したシステムの説明をするのに「Aシステム、Bシステム、CシステムがありそれぞれのシステムがAPIで通信し…」といった自然言語で表現することは少なく、大概システム構成図という形で図版で表現されます。これはシステムアーキテクチャの目的としてシステムを可視化し、第三者にもシステム全体を理解できるようにする必要があるためです。

今後のシステムアーキテクチャ

クラウドネイティブやサーバレスアーキテクチャの本質は、これまで自分たちでやっていたことをクラウドプロバイダやサービスプロバイダに移譲できる点だと考えられます。アーキテクチャだけに留まらず、システム開発は「なるべく実装しない、なるべくやらない」方向に倒れがちです。アプリケーション開発におけるフレームワークなどもその一つで、面倒なことはフレームワークにやってもらい、開発者は本当に集中するべき事項に注力するというものです。

こうなると、今後ますますサーバーレスなどの開発の多くの部分をサービスプロバイダが提供するAPIを利用してシステムを実現する方式が取られていくことが予想されます。極端に言うとサーバーレスからシステムレスになっていく可能性があります。この方向を後押しするものとして、ChatGPTを始めとする生成AIの普及があります。

企業が持つデータをAPIとして他社に公開することをサービスナイズと呼びます。従来は、OpenDataなどでよく提供されている統計データを始めとする数値データ、定量データがこのサービスナイズの対象となっていましたが、生成AIの普及により企業内やWWW上に蓄積された莫大なテキストデータもこのサービスナイズされる対象のデータとなります。これによりさまざまなデータや機能に対して、APIを通じてアクセスされるようになり、システム開発の主流がコーディングではなく、どのAPIをどのように組み合わせるか、に変わっていく可能性があります。(ただ、この方法論は2000年代にマッシュアップという言葉で登場し、当時は普及しきれなかったと、いう歴史的経緯もあります。)