こんにちは。「クロジカサーバー管理」 IT/テックライターのkait78です。
現在、企業の活動や商品をアピールする、ホームページやアプリケーションは必要不可欠な存在となりました。ホームページやアプリケーションはWebサーバーによって動いており、Webサーバーの安定運用をするには「冗長化」が重要な手段となります。
今回は、Webサーバーの冗長化についてご紹介します。
Webサーバーの冗長化とは
Webサーバーの冗長化とは、ホームページやアプリケーション等のシステムに対して、2台以上のサーバーを組む構築手法のことです。
これにより、サーバーの故障や負荷増大時等で起こるサービス断(ホームページやアプリケーションが見れなくなる等)を最小限に抑えることができます。経済産業省の「情報セキュリティ対策基準」では、要安定情報を取り扱う情報システムについて、サーバー装置の冗長構成化を推奨しています。
また、Webサーバーの冗長化と言っても、用途によって構成や構築方法が異なります。
初めに、冗長化の利用ケースについてご紹介します。
Webサーバー故障時の予備機として利用
Webサーバーは精密機械のため、機械の寿命が来れば故障してしまいます。故障が発生した際に、予備機として同じ設定を入れた別のサーバーがWebサイトの処理を引き継ぎます。
また、サーバーの予備機を現用機とは別の地域に設置することで、災害時でも被災していない別地域のサーバーからサービス提供をするDR(Disaster Recovery)を組むことが可能です。
これは、BCP(事業継続計画)にも重要な役割を果たします。
DR(Disaster Recovery)は総務省の「ICTサービス事例集」でも紹介されています。
Webサイトのトラフィック負荷分散として利用
Webサーバーの冗長化は、サーバーの高負荷におけるトラフィック分散に役立ちます。例えば、ホームページやアプリケーションは、仕事から帰宅した夕方・夜の時間帯や、仕事が休みである休日にアクセス数(=トラフィック)が上昇します。
そのため、アクセス数が増えると、サーバーに対する負荷が上がりサイトの読み込み速度が遅くなってしまいます。そのため、複数のサーバーにトラフィックを分散させることで、サーバーの負荷を均等に分散し、パフォーマンスを向上させることができます。
メンテナンス用サイトとして利用
Webサーバーの冗長化は、メンテナンス作業時にも役立ちます。
メンテナンス作業とは、ホームページのリニューアルやソフトウェアのバージョンアップ等が該当します。一般的に、冗長化されていないシステムのメンテナンス作業では、サイトを数時間停止させて実施を行います。
しかし、冗長化を組んでいる場合は、実際に稼働していないサーバーを1台ずつメンテナンスが可能です。そのため、サイトを長時間停止させずにメンテナンス作業ができるようになります。
ケース別のおすすめ冗長構成まで解説した記事はコチラ
冗長化の種類
Webサーバーの冗長化には、さまざまな方法があります。
運用中のサーバーの稼働状態から、下記の4つの構成に分けられます。
Act/Act構成
Actとは、実行中という意味です。
2台のサーバーがどちらもAct(稼働中)状態の構成です。ユーザーはWebサイトへアクセスする際には、稼働している2台の内どちらか1台へアクセスします。
サーバー故障が発生した場合も、故障していない方のサーバー1台でホームページやアプリケーションを運用することが可能です。
本構成は、デュアルアクト(DualAct)・Active-Active構成と呼ぶ場合もあります。
また、稼働しているサーバーのことをMasterやMainなどと表現する場合があります。
Act/StandBy構成
StandByとは、準備中という意味です。2台のサーバーの内、1台は稼働していますが、もう1台は故障用の予備機としてスタンバイしている構成です。
サーバー故障が発生した場合に、自動または手動で切り替えることによりサービス提供の継続ができます。StandBy以外にも、sub・stb・stby・予備系・Slaveなどの表現方法があります。
ホットスタンバイ
サーバーをStandBy構成で運用している場合、StanbBy側のサーバーの状態によってさらに種類が分かれます。ホットスタンバイ構成では、StandBy側のサーバーが常に稼働している状態の構成のことを言います。常に稼働状態のため、Act側の異常時はすぐに切り替えることが可能です。
コールドスタンバイ
コールドスタンバイ構成では、StandBy側のサーバーの電源を常にオフにしている状態の構成です。Act側の異常が発生した後に、StandBy側のサーバーの電源を入れて切替を実施します。そのため、サービスの復旧時間が長くなる傾向になります。
Webサーバーを冗長化するメリット
次に、Webサーバーを冗長化するメリットをご紹介します。
安定したサービス提供ができる
Webサーバーを冗長化をすると、ユーザーに安定したサービスを提供が可能です。
冗長化していない場合、サービスが利用できない時間が長期化する恐れがあります。
例えば、サーバーの機器設定で数時間、機器の物理的な入れ替えに数十分、最悪の場合、機器の調達から必要となり数か月かかってしまいます。Webサーバーの冗長化により、サーバーの故障時も、予備機が自動的に処理を引き継ぐため、サーバーの故障やメンテナンス時でもサービスの継続が可能です。
障害時におけるWeb担当者の負担軽減
Webサーバーの障害時におけるWeb担当者の負担が軽減されることも冗長化のメリットと言えるでしょう。Webサイトの障害時、Web担当者の業務負担はとても大きくなります。
ホームページやアプリケーションが停止した状態となり、復旧に向けて早急な対応が必要な上、ダウンした原因調査、上司への報告、カスタマーセンターやプレスリリースの実施等が必要となります。サーバーの冗長化をしていれば、サービス提供は継続できているため、業務負担の軽減が可能です。
Webサーバーを冗長化する際の注意点
続いて、Webサーバーの冗長化をする際の注意点をご紹介します。
コストが掛かる
Webサーバーの冗長化は、サーバーの追加やネットワークの設備投資など、コストが掛かります。必要な設備やソフトウェア、およびメンテナンスコストを考慮し、費用対効果を慎重に評価しましょう。サーバー・ソフトウェア・電気代など非冗長構成と比べると1.5～2倍程度の費用が必要です。
複数台の監視が必要
複数のWebサーバーを冗長化する場合、それぞれのサーバーに対して監視が必要となります。StandBy側として運用して実稼働していなくても、サーバーは故障することがあります。
もし、StandBy側の故障に気づかずにその状態を放っておくと、有事の際に切替ができずに事故が発生してしまいます。監視体制を整えることで、冗長化されたサーバーの状態を常に把握し、安定した運用を実現が可能です。
設定が複雑になる
冗長構成を組むためには、各サーバーに対して冗長設定が必要です。
例として、下記のような設定が挙げられます。
サーバーの同期が必要
冗長化しているサーバー同士の同期が必要です。
同期設定をしないと、データの差分が発生してしまい、不具合やバグの原因となってしまいます。
通信制御が必要
冗長されたサーバーへの通信制御(トラフィック制御)が必要です。
冗長化の種類で紹介したように、1台側に通信を寄せる場合や、2台に通信を均等に分割する場合等の通信制御設定をサーバーやネットワーク機器に実施します。
サーバーメンテナンスが必要
サーバーのメンテナンスも2台分必要になります。
Webサイトを安定して動かすには、サーバーのOSやソフトウェアのアップデートを定期的に実施する必要があります。
クロジカのWebサーバー冗長化事例
ここまでで、Webサーバーの冗長化をすることにより、サービスの安定化や担当者の負担軽減が可能ということがご理解いただけたかと思います。しかし、冗長化を導入するためには、コストや設定する時間・スキルが必要です。
「クロジカサーバー管理」では、サーバーのトータルサポートサービスを提供しています。お客様が所有しているサーバー調査から冗長化の設定・監視・運用まで全て弊社で実施が可能です。ご担当者様のWebサイトに対するサーバーの仕様や細かい理解は必要ありません。
以下では、AWSを活用したクロジカの冗長化の事例をいくつかご紹介します。
冗長化により安定性の確保と管理の手間を削減
課題
- 初期構築メンバーの離脱で既存環境の構成がブラックボックス化し、アクセス増加に伴う安定性確保と継続的な開発の両立が困難になっていた。
解決策
- EC2二台構成による冗長化
Webサーバーを2台のEC2インスタンスで並列運用し、管理画面専用のインスタンスを分離して攻撃面を縮小。 - 静的コンテンツのS3ホスティング
画像やCSS/JSなどの静的リソースをS3にアップロードし、EC2への負荷を低減。 - 無停止デプロイの自動化
GitHubでコードを管理し、デプロイ時に新旧インスタンスをローリングで入れ替える仕組みを構築。ダウンタイムゼロで更新を実施。
突発的なアクセス増加があるサイトを冗長化で安定運用
冗長化前の課題と事例概要
テレビ放映のたびにアクセスが急増する上場企業様のWordPress コーポレートサイトを、AWS 上で“止まらない”冗長構成へ刷新した事例です。サーバーダウンによるブランド毀損と機会損失を防ぐことが最大の目的でした。
技術ポイント
Web層前段にApplication Load Balancer（ALB）を置き、2台のEC2へトラフィックを分散。管理画面だけは運用簡素化のため主系に固定し、lsyncd＋rsyncでファイルをリアルタイム同期しました。データベースはAmazon RDSのマルチAZ構成で自動フェイルオーバーを確保しました。
導入効果
テレビ露出やキャンペーン時も負荷は平準化され、移行後はダウンタイムゼロを継続。管理URLや運用フローは従来通りで、担当者様の負担を増やさず高可用性・信頼性を実現しました。コストを抑えつつブランド価値を守った事例です。
関連記事はコチラ
ライター：kait78
元大手通信事業者のインフラエンジニア。ネットワーク・サーバー・AWS領域でIT/テック記事に特化した記事を執筆。Webサーバーにまつわる課題や悩みに対して実務経験を基にした、現場社員目線の課題解決となるアイデアを提供します。
監修者：クロジカサーバー管理編集部
コーポレートサイト向けクラウドサーバーの構築・運用保守を行うサービス「クロジカサーバー管理」を提供。上場企業や大学、地方自治体など、セキュリティ対策を必要とするコーポレートサイトで250社以上の実績があります。当社の運用実績を踏まえたクラウドサーバー運用のノウハウをお届けします。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
