# サーバーとは

社内外の利用者に機能やデータを提供するコンピューターです。物理サーバー、役割、仮想サーバーの違いと、台数や構成によって費用、停止したときの影響、運用の負担が変わる理由を解説します。

## サーバーとは

サーバーは、ネットワーク上で[ファイルやデータベースなどの資源を管理し、他の機器に提供するコンピューター](https://csrc.nist.gov/glossary/term/server)です。ファイルを保管するファイルサーバー、データベースへの問合せを処理するデータベースサーバーのように、提供する機能の名前で呼びます。要求を送信する社員のパソコンやスマートフォンはクライアントで、両者の違いは機器の種類ではなく役割です。

例えば社内の販売管理システムは、画面を表示するWebサーバーと、受注や在庫のデータを保管するデータベースサーバーの2台で構成することがあります。担当者がブラウザで受注を登録すると、Webサーバーが受付を処理し、データベースサーバーがデータを保存します。飲食店のたとえでは、Webサーバーは注文の受付と配膳を担当する店員、データベースサーバーは食材を保管する倉庫です。

![販売管理システムでは、社員のパソコンからの受注の登録をWebサーバーが処理し、データベースサーバーが保存します](https://media.marketing.kdotdev-tunnel.org/glossary-server-7e16183cdcc4d02ec98f01fe442847689d595792bfdbc0b5199789d154a45763.png)

サーバーという語には3つの意味があります。物理サーバーはデータセンターや社内のサーバー室に設置する機器そのものです。役割としてのサーバーは機器上で稼働するソフトウェアが担う機能を指します。仮想サーバーは仮想化のソフトウェアで物理サーバーの資源を分割した、1台分のコンピューターの環境です。社内の機器を仮想化する場合とクラウドの事業者が提供する場合があり、Amazon EC2のインスタンスは[AWSクラウド上の仮想サーバー](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/concepts.html)です。

## 会議で話題になるサーバーの費用・停止・増強

### サーバー代

ここでのサーバーは物理サーバーか仮想サーバーです。物理サーバーの費用は機器の購入費と保守費、設置場所の電気代が中心です。経験上、電気代以外は利用量にほぼ関係なく発生します。クラウドの仮想サーバーは[稼働時間に応じた課金](https://aws.amazon.com/jp/ec2/pricing/on-demand/)が基本で、[ディスク、IPアドレス、OSのライセンスなどの関連する資源にも別の費用がかかります](https://learn.microsoft.com/ja-jp/azure/virtual-machines/overview)。

サーバー代が想定を超過したときは、次の5項目に分解して原因を調査します。

- 台数と1台あたりの性能
- 稼働時間。利用しない時間帯も稼働させていないか
- ディスクやバックアップなどの関連する資源
- [インターネットへのデータ転送量](https://aws.amazon.com/jp/ec2/pricing/on-demand/)。外部への送信量に応じた課金
- 購入の方式。AWSの[Savings Plans](https://aws.amazon.com/jp/savingsplans/)では、[1年か3年の期間に一定量の利用を約束すると](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)オンデマンド料金より最大72%割安になる。約束した量は利用が減っても請求されるため、期間中に確実に使い続ける最低限の量だけを約束し、超える分はオンデマンドの料金で利用する

![サーバー代の5項目は台数と構成で決定する費用と利用状況で増減する費用と単価の引き下げ手段の3群に分類できます](https://media.marketing.kdotdev-tunnel.org/glossary-server-c4db3e8849f3761b090c877be055c65fae0263d08cae935584813835989ba47d.png)

### サーバーが落ちた

この報告のサーバーは多くの場合、役割としてのサーバーです。機器の故障だけでなく、ソフトウェアの停止やアクセスの集中による無応答も同じ言い方で報告されます。対応は原因ごとに異なります。例えば、機器の故障なら交換か別の機器への切り替え、ソフトウェアの停止なら再起動、アクセスの集中ならサーバーの台数の追加です。復旧までの時間も対応によって異なります。

影響の範囲は停止したサーバーの役割に依存します。データベースサーバーが1台だけなら、その停止で、そのデータを利用するすべての画面が停止します。複数台で分担するWebサーバーは、1台が停止しても残りの台で受付を継続できる場合があります。報告があれば、停止した役割、停止中の業務、原因が機器かソフトウェアかを確認します。

### サーバーを増強する

ここでのサーバーは役割を担う物理サーバーか仮想サーバーです。増強には、1台を高性能な機種に交換するスケールアップと、同じ役割のサーバーの台数を追加するスケールアウトがあります。[Microsoftの設計指針](https://learn.microsoft.com/ja-jp/azure/well-architected/performance-efficiency/scale-partition)は、[分割しにくい処理にはスケールアップが、独立した小さな処理に分割できる処理にはスケールアウトが適すると説明しています](https://learn.microsoft.com/ja-jp/azure/well-architected/performance-efficiency/scale-partition)。台数の追加はシステムが複数台で処理を分担する設計であることが前提で、処理を各台に配分する仕組みをロードバランサーと呼びます。

## サーバーの台数と構成が左右する費用・停止の影響・運用の負担

### 1台構成は複数台より安価だが1台の停止でシステム全体が停止する

すべての役割を1台に集約すると費用と管理の負担を軽減できますが、その1台の停止でシステム全体が停止します。AWSは本番のシステムを[少なくとも2つのアベイラビリティーゾーンに配置する](https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html)よう推奨しています。[アベイラビリティーゾーン](https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html)は電源やネットワークが独立した事業者の設備の区画です。

そのシステムを利用する業務の責任者が、許容できる停止時間と、消失を許容できるデータの範囲の2つを基準に、停止とデータの消失に備える構成を決定します。それぞれ[RTO（Recovery Time Objective、目標復旧時間）](https://csrc.nist.gov/glossary/term/recovery_time_objective)、[RPO（Recovery Point Objective、目標復旧時点）](https://csrc.nist.gov/glossary/term/recovery_point_objective)とも呼びます。

- 社内の数十人が利用する申請や集計の仕組みで、1日程度の停止なら後日に処理でき、前日分の入力なら再入力できる業務: 1台構成を選択できる。機器の故障後にバックアップから復元すると、経験上、半日から1日程度かかることがあり、その停止を許容できることが条件になる
- 受注や決済のように停止が売上の損失や取引先への影響に直結する業務: 複数台に分散し、1台が停止しても残りで処理を継続する。ロードバランサーと2台目の分、費用は1台構成のおおよそ2倍強になる
- どちらの構成でも: バックアップを別の場所に保存し、復元できる時点を決定する。1日1回のバックアップなら、故障時に最大1日分の入力が消失する

所要時間と費用の倍率は経験上の目安で、構成によって異なります。

![1台構成は安価な代わりに1台の停止でシステム全体が停止する。複数台構成は費用が経験上おおよそ2倍強になり、1台が停止しても残りの台で処理を継続できる](https://media.marketing.kdotdev-tunnel.org/glossary-server-562275c831a4ad1e8e30da747a37943e807dcb423823f3cfcf3b4419dcda6760.png)

### サーバーの台数に応じて運用の作業が増加する

サーバー1台ごとに稼働状況の監視とOSやソフトウェアの更新が発生し、データを保存するサーバーではバックアップの取得と復元の確認も発生します。AWSの仮想サーバーでは、事業者が管理するのは物理的な設備と仮想化の層までで、[OSの更新とセキュリティパッチの適用は利用者の責任](https://aws.amazon.com/jp/compliance/shared-responsibility-model/)です。数台分の月例の更新と確認を手作業で行うと、経験上、月に数時間から1日程度かかります。停止を許容できない業務のサーバーでは、夜間や休日の通知に対応する担当も必要です。

担当者が未定のままでは、これらの作業は後回しになりがちです。台数だけを追加すると、更新の停滞したサーバーや、復元を一度も検証していないバックアップが放置されるおそれがあります。

### 利用しない時間帯のサーバーにも費用がかかる

クラウドの仮想サーバーを停止しても、[ディスクなどの関連する資源は保持される](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html)ため、その費用は継続します。開発や検証用のサーバーを夜間や休日も稼働させたままにすると、未使用の時間の費用も請求されます。台数の検討時には本番、検証、開発の用途ごとに稼働が必要な時間帯を一覧にします。

## サーバーの管理を事業者に委託する選択肢

社内に監視と更新の担当がいない場合は、サーバーの管理を事業者に委託する形態を選択します。経験上、委託の範囲を拡大するほど、更新や監視を事業者が担うため自社の運用の負担は減少します。一方で、事業者が用意した設定の中から選択するため、設定の自由度は低下する傾向にあります。

- 仮想サーバー: OSから上を自社で管理する。OSを選択し、任意のソフトウェアを導入できる
- マネージドサービス: データベースなど特定の機能を、OSの更新を含めて事業者が管理する。[Amazon RDS](https://aws.amazon.com/rds/pricing/)のオンデマンドの料金のように、利用のない時間にも稼働時間に応じた費用がかかるものがある。そのため、経験上、夜間や休日に利用しない処理では割高になりやすい
- サーバーレス: プログラムだけを登録し、サーバーの保守、容量の確保、パッチの適用は事業者が担う。呼び出しの回数や実行時間など、利用量に応じた課金が基本
- SaaS（Software as a Service）: 完成したソフトウェアを利用する。サーバーを意識する必要がない

![一般的な分担では、データと設定はどの形態でも自社の管理です。仮想サーバーはOSから上、マネージドサービスとサーバーレスはプログラムまでを自社で管理し、SaaSではデータと設定だけを自社で管理します](https://media.marketing.kdotdev-tunnel.org/glossary-server-f77d8ce2387e18c9e50c2e481feba760df390317b82315dd7f1a4f6b7ea9243d.png)

アクセスが日中や月末に集中し、それ以外の時間帯にはほとんど処理が発生しない場合は、常時稼働の仮想サーバーより、利用量に応じて課金されるサーバーレスのほうが、経験上、費用を削減できる場合があります。[AWS Lambda](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html)はその例で、1回の呼び出しの実行時間は最大15分です。業務パッケージの提供元がOSの種類と版を指定している場合や、数時間かかる処理を常時実行する場合は、仮想サーバーを選択します。

機器を自社の設備に設置するオンプレミスにするかクラウドを利用するかは、上の4つの形態の選択とは別に、データの保存先、運用の体制、費用などで決定します。

## よくある誤解

### サーバーを増強すれば画面の遅さは解消する

データベースの検索方法、ネットワークの混雑、外部サービスの応答待ちが画面の遅さの原因なら、サーバーを高性能にしても応答は改善せず、費用だけが増加します。増強の前に、どの処理に時間がかかっているかを監視の記録で特定し、サーバーの処理能力が原因の場合だけ増強します。

### クラウドのサーバーは停止しない

クラウドの仮想サーバーも事業者の設備の障害や設定の誤りで停止します。AWSの推奨する[複数のアベイラビリティーゾーンへの配置](https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html)は、1つのアベイラビリティーゾーンの停止中も、他のアベイラビリティーゾーンで処理を継続するための構成です。切り替えが機能するよう、システム側も複数台で処理を分担する設計にする必要があります。1台の仮想サーバーで稼働するシステムは、社内のサーバー室の1台と同じく、その停止で全体が停止します。

### サーバーレスにはサーバーがない

サーバーレスでも処理は事業者のサーバー上で実行されます。利用者がサーバーの台数、OSの更新、容量の確保を管理しなくてよいという意味で、代わりに実行時間の上限や対応する言語など、事業者が定めた制約の範囲で開発します。

新規の社内システムでは、監視と更新の負担を軽減するため、要件に適合する限りサーバーを自社で管理しない形態を採用し、要件に適合しない処理だけを仮想サーバーで稼働させます。仮想サーバーを利用する場合は、台数の決定前に監視、更新、バックアップの担当を決定します。