障害が発生しても予備の機材でシステムの機能を継続できるようにすること。 Webサービスでいえば、webサーバが１つ死んだり障害が発生したりしても、サービスには支障を出さずに運用を続行出来るようにすること。
システムを冗長化するとは、
- 障害を想定する
- 障害に備えて予備の機材を準備する
- 障害発生時に予備の機材に切り換えられる運用体勢を敷く
Webサーバやルータに障害が発生しても、予備に切り換えることで運用を続行出来る。
[Webサーバ] --- [ルータ] --- インターネット
待機組
[Webサーバ] --- [ルータ]
- 予備機材は普段電源を切って使わずにおいて、障害が発生した時に電源を入れて利用する方法
- 予備機材は現用機材と同じ設定でないといけないため、頻繁に情報が更新されるwebサーバにはコールドスタンバイは向かない
- 設定の変更が少ないルータにおいてはコールドスタンバイは実用的である。
- 予備の機材に常時電源を入れておいて、現用機材に更新が掛かると予備機材にも更新がかかるようにしておく方法
- 情報の更新が頻繁なwebサーバに有用
- 現用機材と予備機材が常に同じ状態に保たれる
障害が起こらず、待機させておくだけだととてももったいない。
そこで登場するのが、負荷分散。
- DNSを使って複数のサーバに処理を分散させる手法
- 複数の人がDNSにIPアドレスの問い合わせをした場合、DNSサーバはそれぞれに異なったIPアドレスを返すことで処理を分散する
👨 <-----> x.x.1に振り分け -----> [Webサーバ1]
[DNSサーバ]
👩 <-----> x.x.2に振り分け -----> [Webサーバ2]
問い合わせの度に異なるIPアドレスを返す仕組みを利用しているため、複雑な実装をせずに簡単に負荷分散が出来る
- サーバの数 = グローバルアドレスの数
- プロキシサーバ経由の場合、IPアドレスをキャッシュするため、分散が偏る可能性がある
- Webサーバが落ちていてもアクセスが行く
- 負荷分散機（ロードバランサ）を利用して、複数のサーバに処理を振り分ける方法
- ロードバランサはグローバルアドレスをもった仮想サーバとして機能する
- クライアントからのリクエストを本物のWebサーバに中継することで、あたかもロードバランサがwebサーバのように振る舞う
-----> [Webサーバ1]
👩 -----> ロードバランサ（仮想サーバ）
-----> [Webサーバ2]
- グローバルアドレスが節約出来る。
- 振り分け前にヘルスチェック（Webサーバが生きているか確認）が行われるため、生きているwebサーバだけにアクセスがいく
- コストがかかる
- DNSラウンドロビンに比べ複雑なため、運用が不安
Webサーバを冗長化しても、アクセスを振り分けるDNSサーバやロードバランサが死んだらサービスが機能しなくなってしまう。そのため、ルータにも冗長化が必要で、そのための冗長化プロトコルがVRRP(Virtual Router Redundancy Protocol)である。 VRRPが作られたことで、ベンダに依存せずにルータの冗長化が行える。
DNSラウンドロビンやロードバランサでは、アクセスはルータが振り分けるものの、Webサーバがリクエストに直接応答していた。そこで、クライアントとwebサーバの間に立って要求を代理で処理するのがリバースプロキシである。
- クライアントとwebサーバの間に立って要求を代理で処理をする
- ロードバランサとの違いは、Webサーバはクライアントにではなくリバースプロキシに応答を返すこと
<-----> [Webサーバ1]
👩 <-----> リバースプロキシ
<-----> [Webサーバ2]
リバースプロキシが間に挟まることで、様々な前後処理を施すことが出来る。
- IPアドレスでフィルタリング
- URLの書き換え（簡潔なURLをリバースプロキシでURLを分解してから、複雑なURLに変換してWebサーバに転送する）
- サーバ切り分けによるメモリ使用率の向上
URLを見て、
- 静的コンテンツのパス以下に配置されていたらWebサーバに
- それ以外の場合は動的コンテンツの要求なのでAPサーバに
と振り分けることが出来る。
これによって、
- 多数の静的コンテンツの要求はメモリ消費量の少ないWebサーバが応答して
- APサーバは動的コンテンツのみ応答する
と割り振ることが出来て、全体としてメモリ使用効率が上がり同時に処理出来るリクエストも増える。