🐷

web3層についておさらいしてみた件

2025/01/30に公開

Daily Blogging40日目

最近色々学び直してます
結局基礎が大事
今回はweb3層について学び直す

web3層ってなんだっけ?

webアプリケーションのアーキテクチャの一つであり、3つのレイヤーに分けて処理を進めていく。

役割 具体例 技術例
プレゼンテーション層(Web層) ユーザーと直接やりとりする部分。UIの表示やリクエストの受け渡しを担当。 ユーザーがアクセスするWebページ(HTML、CSS、JS) HTML、CSS、JavaScript、React、Vue.js、Webサーバ(NGINX、Apache)
アプリケーション層 ビジネスロジックや処理を行い、データ層と連携して情報を取得・更新する。 「商品をカートに追加する」処理や「ユーザー情報の更新」処理 Ruby on Rails、Django、Node.js、API(RESTful、GraphQL)
データ層(データベース層) データの保存・管理を行う部分。データベースに格納された情報を提供する。 ユーザー情報や商品データが格納されるデータベース MySQL、PostgreSQL、MongoDB、Redis

ざっくりこんな感じ

なんで生まれたんだ?

web3層ってなんのために存在しているのか?
※これって意味あるんですかね?

web3層の存在意義を知るために、DBアーキテクチャの歴史を振り返ってみる。

スタンドアロン型(~1980)

一番最初はこれ
完全独立型のアーキテクチャ

特徴↓

  • DBサーバーにアプリケーションもいる
  • ネットワークで他のシステムと接続されていない、完全独立型
  • このサーバーに物理的に接続しに行かないと操作できない

まぁ昔なんてネットワークもなかったのでこうなりますよね
これだと色々な問題がある。

  • デメリット
    • 遠隔で操作できない
    • 複数人の同時アクセスができない
    • 1台構成なので可用性が低い
    • 拡張性に乏しい(スケールアップしかない)

一応メリットもあるよ

  • メリット
    • 高いセキュリティ
      • USBとか物理的なものじゃないと情報漏洩しない
    • 構築は簡単

メリットもあるけどとにかくデメリットが多い
そんなデメリットを少しずつ解消していくために、アーキテクチャが進化する

クライアント/サーバ型(1980~2000)

ついにDBとアプリケーションが分かれましたね
このアーキテクチャでは、クライアント側にアプリケーションロジックを置いて、そこからDBサーバへとアクセスする方法に変わりました。

特徴↓

  • クライアントからDBにネットワーク経由で接続できる
    • ただしLANでの接続
  • 複数人での同時作業が可能

まずは、遠隔操作できないという点と、複数人での同時アクセスができない問題が解消されました。
これだけでも嬉しい。

でも当然まだまだ問題はあるよ

  • デメリット
    • クライアントにあるアプリケーションの管理コストが高い
    • 外部ネットワークに接続するとセキュリティ上の問題が出る
      • アプリケーションとDBサーバが直接やりとりしている

アプリケーションの管理コストは、各クライアントに配布しているアプリケーションの更新やメンテナンスにかかるコストのこと。
クライアントごとに管理しないといけないので大変だっ

今度はこのデメリットたちを解消しなきゃ

web3層(2000~)

ついに来ました我らがwe3層
これまでの問題点をちゃんと解決してくれます

特徴↓

  • プレゼンテーション層、アプリケーション層、データ層に分かれている
  • アプリケーションロジックをサーバ側に持っている
  • webブラウザなどのクライアントからアクセス可能
  • メリット
    • クライアントサイドのアプリケーションとDBサーバの直接的なやりとりがない
      • DBの認証情報の漏洩リスク低下
      • SQLインジェクションなどの攻撃リスクの低下...
    • 拡張性、可用性が高い
    • アプリケーションの管理コストが下がった

アプリケーションサーバの深掘り

web3層の概要は掴めた
ただ、アプリケーション層の解像度まだちょっと低い
どうやってプレゼンテーションからのリクエストを受け取り、どうやって特定のアプリケーションロジックを動かしているのか
Railsアプリケーションを例に考えてみる

登場人物

webのリクエストを捌くために、実はアプリケーション層には大きく2つの登場人物が存在する

  • Rails
  • Puma(unicornとかもね)

先に図式化するとこんな感じ

今回の例では、Pumaがクライアントから送られてきたリクエストをwebサーバ経由で受け取り、
そのリクエストをRailsに渡している。
Pumaみたいなアプリケーションサーバがないと、RailsはHTTPリクエストを受け取ることができない。

影の功労者

じゃあPumaからのリクエストはなんでRailsが受け取れるのか
それはRackというシステムが一役買ってる。
Rackとは

RubyのWebアプリケーションのためのインターフェース規格(API)で、WebサーバーとWebアプリケーションの間の通信を簡潔に管理する役割を果たします。

この子がいるから最終的にRailsはリクエストを受け取ることができ、必要な処理を実行できる。

まとめ

web3層は意味ありました

Discussion