Zenn
🦔

僕的！システムアーキテクチャの変遷〈2000-2025〉

に公開
システム設計
システムアーキテクチャ
idea

まえがき

先日、ひょんなことがありエンジニア仲間とシステム構成について話していました。
その結果、システム構成をどう分類するか？と言う点で認識の違いがあったので、システムアーキテクチャの変遷についての僕の認識をメモろうと思います。

一応、そのアーキテクチャが一般化したと感じた年も付記しますが、完全に僕の感覚です。
裏付けがあるものではないのでご留意ください。
chatGPTの回答も付記しておきます。

伝統的システム（僕の感覚：〜2010年）

具体的な名称が思い付かず「伝統的システム」と名称しました。
イメージ的にはJSP+サーブレットのような、サーバー側でHTMLを生成し、そのHTMLをそのままユーザに返すパターンです。
HTMLにはjQueryやBootstrapなども用いられていることが多かったです。

伝統的システム

メリット

  • 元祖

デメリット

  • 元祖

フルスタックFramework（僕の感覚：2012年）

chatGPT：2005-2012年

Ruby on RailsやlaravelなどのフルスタックFrameworkが流行った印象です。
正直伝統的システムと何が違うのか？と言われれば、HTMLをサーバー側で生成しているのでシステム構成的にはほぼ同じでは？と思います。
違いといえば、Frameworkが対応している範囲のように思います。

フルスタックFrameworkでは、MVC構成をワンコマンドで作成できるコマンドツールやDBマイグレーションツールやORMも同梱されてます。
メール送信やRedisの設定ファイルを少しイジるだけで可能でした。ジョブ実行やログイン管理、権限管理もFrameworkの範疇だったりと、非常に広い範囲についてFrameworkが機能を提供してくれました。

ちなみに、フルスタックFrameworkといえばプログラミングスクールで教材に取り上げられていると思うのですが、これはFrameworkが多数の機能を提供するので少ない勉強量でも機能的に立派なアプリケーションが作れるからでしょう。

プログラミングスクールの最盛期は2015-2018年位な気がしており、WEB業界では数多くのフルスタックFrameworkのシステムが稼働している時期と被っているのではないでしょうか？

フルスタックFW

メリット

  • デフォルトで提供している機能が多く開発速度が高い
  • 複雑な機能が設定ファイル化されるなど複雑な機能が簡単に実装可能

デメリット

  • 高度に抽象化されているためカスタマイズ性が低い面も

SPA + APIServer（僕の感覚：2015年）

chatGPT：2010年

React、Vueなどの選択が当たり前になってきた時期です。先駆けとしてAngularJSが出現し、React、Vueでスタンダード化したイメージです(この頃はVueの方が優勢でした)。

これらの技術は非常にリッチなUIを提供ができました。スマホが普及しアプリというリッチなUIが出現したため、WEBにもそれが求められたが普及のきっかけなような気もします。
この頃の稼働システムはフルスタックFrameworkも多い状況でした。新規システム立ち上げ時にSPAの採用も検討されるようなったのではないでしょうか。

これまでの構成と根本的に違い、HTMLはクライアント側で生成します。
この違いをあまり知らなかった僕は、WEB情報を参照する際にどちらを前提にした話か分からずよく混乱した思い出があります。

SPAの拡大とともにフルスタックFramework側もREST APIサーバー機能も備え、REST APIサーバーに転用してSPA+フルスタックFrameworkとすることも徐々に発生した印象です。

SPA

メリット

  • 宣言的UIFramework（React,Vueなど）利用でリッチなUIが構築しやすい

デメリット

  • 検索エンジンに正しくインデックスされない（現在はクローラーが改善され問題ない...とされている）

フロントエンドサーバー構成（僕の感覚：2018年）

chatGPT：2018年

Next.jsなどですね。SPAではクライアント側で生成していたHTMLですが、HTML生成の専用サーバーを置くようになりました。
この構成の誕生動機は、当時、SPAがSEOに課題を抱えていたからだと思います。

この構成では、フロントエンドサーバーはバックエンドサーバからデータを要求し、フロントエンドサーバー内でHTMLをレンダリングし返すためSEO評価の問題は解決されました。
また、HTML受信後はクライアント側JSがサーバーにデータを要求し、クライアント側でHTMLを再描画するのでSPAと同じくリッチなUIを構成できます。

この構成はフロントエンド専用のサーバーを置くという点で今までと異なる新しい構成です。
この構成も初めて見た時は理解が追いつかず大混乱した記憶があります。。。

フロントエンドサーバ

メリット

  • SEO的に有利
  • クライアント側の性能にページのパフォーマンスが左右されづらい

デメリット

  • フロントエンドサーバー分のサーバーコスト
  • フロントエンド担当者にバックエンドやインフラ面の知見も要求される

マイクロサービス（僕の感覚：2018~2019年）

chatGPT:2015年

Dockerなどのコンテナ技術の普及に伴って2018年頃からマイクロサービスも一般化したイメージです。この時のマイクロサービスといえばコンテナベースのマイクロサービスを指していたように思います。
その1年後ほど（2019年頃）にはlambdaをベースとしたサーバレス設計と言う言葉もよく聞くようになりました。

このときは、サーバレス設計とマイクロサービスとを別物として語っていたように思いますが、現在はマイクロサービスと言うとこの両者を指し示している場合が多いと思います。

実際、外から見た時に1つでも中身を見ると複数の部品が組み合わさっているという構成がマイクロサービスです。そのためサーバレスも複数のマネージドサービスを組み合わせて作るのでマイクロサービスの一種です。
ここではlambdaベースでWebAPIを構築している構成をサーバレスの例として図示しますが、実際はEventBridgeによるバッチ実行したりなど様々なサービスを利用してイベント駆動な構成を作ります。

フロント部分の構成としては、Next.jsのようなフロントエンドサーバーがある場合はフロントエンドサーバーが各マイクロサービスからデータを取得し表示結果に統合します。
サーバレスの場合は、SPA+APIGateway構成でクライアント側で結果を統合することが多いではないでしょうか。（もちろんフロントエンドサーバーを用いる構成も可能です）

コンテナベース

メリット（コンテナベースのマイクロサービス）

  • コードベースが分割され、複数チームが並行して作業が可能
  • スケール単位の最適化

デメリット（コンテナベースのマイクロサービス）

  • インフラ数がマイクロサービス数だけ増える（インフラ構築コスト増）
  • コードがマイクロサービスごとに分割されるため、依存関係を追いづらい

サーバレス

メリット（lambdaベースのマイクロサービス）

  • インフラの運用コストをクラウド事業者に移譲
  • コストの大部分が従量課金で利益計算しやすい
  • スケール単位の最適化

デメリット（lambdaベースのマイクロサービス）

  • バックエンドとインフラが融合され開発者はどちらの知見も要求される
  • クラウド業者ごとに提供されるサービスが異なるため移行できない＝ベンダーロックイン
  • コードベースは分割しないことが多い？=開発作業の並列性はない

私の場合、サーバレスはIaCを用いて単一コードベース管理しています。皆さんは分割してますか？

猫も杓子もNext.js運動（僕の感覚：2021年）

chatGPT：2020年

スタンダード化した構成ではないが、Next.jsがVercel社になった前後ぐらいNext.jsで全部済ましてしまおう！みたいな運動があったように思います。
直前までの流れは細分化の方向なのですが、この構成はその真反対で非常に面白いと記載します。

Next.jsのようなフロントエンドサーバー構成では、フロントエンドがサーバーを持ちます。そのため、このサーバーが直接DBからデータ取得・更新すればバックエンド専用のサーバは不要になります。
つまりは、HTML生成もデータ取得/更新も1つのサーバーが担当する構成なので、フルスタックFrameworkにかなり近いと思ってます。（クライアントJSの有無の違いはありますが）

ただこれが主流にならなかったのは、Next.jsのVercel社がホスティングサービス「Vercel」の利用を前提とした「ISR」などの機能を追加したことだと思ってます。
そのためベンダーロックインを嫌った開発者がNext.js依存を離れたり、そもそもVercelサービスはエッジコンピュータを利用して長大負荷に耐えるためのもののためALL in Oneに魅力を感じる層には無用の長物だったのではないでしょうか。
また、Next.jsは独自仕様が多く、私はこれを嫌ってRemixなどに魅力を感じていました。

Vercel+Next.jsの経験は少ないため認識違えば、コメントで補足してくださると嬉しいです。

Next.js

メリット

  • コストが単純明快
  • ホスティング先をVercelにすると超高負荷にも耐えられる

デメリット

  • ベンダーロックイン
  • Next.js独自の概念が多く、知識を転用しづらい

現在（2025年）

なんとなく今の主流かな？と僕が思う選定も記載しておきます。
（完全に偏見です。ご意見はコメントにいただけると嬉しいです。）

  • MVP検証など速度第一で後で作り直しも許容
    • フルスタックFramework
  • toBサービスなどスケール性能やユーザー利用環境がある程度制限あり
    • SPA + APIサーバ
    • SPA + マイクロサービス
  • toCサービスなどスケール性能やユーザー利用環境に制限なし
    • フロントエンドサーバ + マイクロサービス

※マイクロサービスはコンテナベース、サーバレスの両方含みます。

もちろん開発物自体の性質のみでなく、開発チームの性質も考慮する必要があります。
例えば以下のような対応/対策が必要でしょう。

  • インフラとバック両面に強いエンジニアが少ない
    • → DevOpsが必須となるサーバレス設計を除外する
  • フルスタックFrameworkの経験者しかいない
    • → フルスタックFramework採用で、今後の拡張性のためモジュラモノリス設計

私のモジュラモノリスのイメージって下記なんですが皆さんと一致します？
モジュラモノリスって人によってイメージするものがかなり違うように思ってます。
私は基本的にモジュラモノリスはコードに関する設計だと思ってます。
下の方の「私見」見出しが僕の持つイメージについての記載箇所です。

https://zenn.dev/naitsu/scraps/02a343a23b0331

感想とまとめ

改めて見ると、2010年以降は激動でシステム設計の主流が変わっているなーと感じました。
（2010年以前も僕が知らないだけで実は激動なのかもしれないけど。）

また、技術とは先鋭化と揺戻しの連続のように感じます。
伝統的システムの技術選択が分断されていたところが、フルスタックFrameworkとしてALL in Oneに提供されました。

次に出たSPAではフロントとバックを切り離すことで、個別最適化してリッチなものを提供するというフルスタックとは反対方向に向かいました。
その後も細分化の流れは続き、マイクロサービス、Serverlessと細分化と個別最適の波が一気に押し寄せます。

ただし、細分化は運用面、金額面でもコストが跳ね上がります。そのアンチテーゼとして「猫も杓子もNext.js運動」があるように思います。
Next.jsだけで全てをこなしますから、技術的にも金額面でも単純明快です。（実際やってみるとSC（ServerComponent）とCC（ClientComponent）と複雑怪奇ですが）
また、ALL in One思想のフルスタックFrameworkと比較して、ホスティングサービス「Vercel」を併用することでスケール問題の面で進化を遂げています。

結果として、現在はシステム要件に合わせて構成を選ぼうという「銀の弾丸はない」という結論になったと感じています。
この選択結果によって将来の技術的負債になるのですが、負債と開発メリットのバランスをよく考えて選択したいですね。

関連記事
https://zenn.dev/naitsu/articles/0c51de92607721

現在はかなりシステムアーキテクチャは出揃った感がありますが、この「次がない時期」の次に来るのは大変革な予感がしています。
それがAIコーディングによるものか？量子コンピュータによるものか？は分かりません。
ただ、そんな世の中でも変化を恐れずそれを楽しめる、そんなエンジニアになりたいものです。

また、マイクロフロントエンドも聞いたことがあるのですが、筆者は一切経験したことがないため記載しませんでした。
マイクロフロントエンドが分かる方はコメントなどで教えていただけると嬉しいです😌
長々とした文章ご一読してくださり、ありがとうございました！

Discussion