APサーバーとは?Webシステムの構造を初心者向けに整理してみた

サムネイル_APサーバー IT Study

仕事でシステムの改修やテストに関わっていると、ときどき「今回の変更はAPサーバーには影響しないので、QAはいらない」という話を聞くことがあります。

先日も、システムのパフォーマンス改善やソートに関する変更がありました。その際に、APサーバーには影響がないという判断でQAを実施しませんでした。

そのとき、「APサーバーに影響がないって、そもそもどういうこと?」と疑問に思いました。

そこで今回は、APサーバーとは何なのか、Webシステムの中でどのような役割を持っているのかを、初心者向けに整理してみます。


APサーバーとは?

APサーバーは、Application Server(アプリケーションサーバー)の略です。

例えば、Webサイトでログインしたり、商品を検索したり、登録したデータを表示したりするとき、画面の裏側ではさまざまな処理が行われています。

APサーバーは、このようなアプリケーションの処理を担当する場所です。


Webシステムはどういう構造になっている?

APサーバーだけを理解しようとすると少し分かりにくいので、まずはWebシステム全体を簡単に見てみます。

基本的なイメージとしては、次のような構造です。

ユーザー
   ↓
Webブラウザ
   ↓
Webサーバー
   ↓
APサーバー
   ↓
DBサーバー

プレビューを表示↗

もちろん、実際のシステムではもっと複雑な構成になっています。クラウドサービスを利用していたり、WebサーバーとAPサーバーが同じ役割を持っていたり、複数のサーバーを組み合わせている場合もあります。

ここではまず、それぞれの役割を大まかに理解します。


Webサーバーとは?

Webサーバーは、ブラウザから送られてくるHTTPリクエストを受け取ったり、Webページや画像などのファイルを返したりする役割を持っています。

例えば、

ブラウザ
「このページを表示したいです」
        ↓
Webサーバー
「リクエストを受け取りました」

というように、Webからの入り口になる存在です。


APサーバーとは?

APサーバーは、Webアプリケーションの処理を担当します。

例えば、

  • ログイン情報を確認する
  • ユーザー情報を取得する
  • 入力されたデータをチェックする
  • DBから必要なデータを取得する
  • 条件に応じて処理を分ける
  • データを加工して返す

といった処理です。

つまり、

Webサーバー
→ リクエストを受け取る

⭐️⭐️⭐️APサーバー⭐️⭐️⭐️
→ アプリケーションの処理を行う

DBサーバー
→ データを保存・取得する

と考えると、最初は分かりやすいと思います。


DBサーバーとは?

DBサーバーは、データを保存・管理する役割を持っています。

例えば、

ユーザー情報
商品情報
注文情報
プロジェクト情報

などです。

Webアプリケーションから

「このユーザーの情報を取得してください」

「この商品のデータを保存してください」

といった要求を受けて、データの取得や保存を行います。


それぞれの関係

ここまでをまとめると、

┌──────────────┐
│   Webブラウザ │
└──────┬───────┘
       ↓
┌──────────────┐
│  Webサーバー  │
│  Webの入口    │
└──────┬───────┘
       ↓
┌──────────────┐
│  APサーバー   │
│ アプリの処理  │
└──────┬───────┘
       ↓
┌──────────────┐
│  DBサーバー   │
│ データを管理  │
└──────────────┘

というイメージになります。

ざっくり言えば、

Webサーバー → APサーバー → DB

という流れで、それぞれが異なる役割を担当しています。


「APサーバーへの影響」を考える

ここで、最初に疑問に思った

「APサーバーに影響がない」

という言葉に戻ってみます。

例えば、今回のようにパフォーマンスを改善するための変更や、データのソートに関する変更があったとします。

この変更がDB側の処理や設定などに対するもので、APサーバー上で動いているアプリケーションのコードや設定自体には変更がないのであれば、

「APサーバーには影響しない」

と判断されることがあります。

イメージとしては、

       Webサーバー
            ↓
       APサーバー
       【変更なし】
            ↓
        DBサーバー
       【今回変更】

という状態です。

この場合、変更そのものはシステムの一部に入っていますが、APサーバー側のアプリケーションには変更を加えていないため、APサーバーへの影響はないと考えられます。

今回QAを実施しなかったのも、こうした変更箇所と影響範囲の判断が関係していたのではないかと思います。

ただし、実際のシステムでは構成や変更内容によって判断は異なるため、「DBを変更したら必ずAPサーバーに影響しない」という意味ではありません。


「変更した場所」を意識する

今回APサーバーについて調べてみて、個人的に重要だと感じたのは、

「何を変更したか」だけではなく、「どこを変更したか」を考えること

でした。

例えば、

DBのデータを変更
        ↓
DB側の変更

アプリケーションのコードを変更
        ↓
APサーバー側への影響を確認

サーバーの設定を変更
        ↓
どのサーバーに影響するのか確認

というように、変更した場所によって確認すべき範囲も変わります。

QAについても、単純に

「変更があったからテストする」

というだけではなく、

「今回の変更はどこに影響するのか?」

を考えることが重要なのだと思いました。


終わりに

スクールではこういう用語はあまり取り扱ってないし、一度は聞いて探してみてその時は「あ、わかった」ってなっても何日か経ったらまた「なんだっけ」とかなりますね。

今回も聞いたことあるけど、なんだっけと思って内容をまとめてみました。

また忘れるかもしれませんが、その都度探して復習するうちに頭に入ってくると思います!

タイトルとURLをコピーしました