web3層についておさらいしてみた件
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インジェクションなどの攻撃リスクの低下...
- 拡張性、可用性が高い
- アプリケーションの管理コストが下がった
- クライアントサイドのアプリケーションとDBサーバの直接的なやりとりがない
アプリケーションサーバの深掘り
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