ロードバランサの機能エラーの原因と、切り分けの手順を解説

ロードバランサの機能エラーが起きたときの切り分け方

ロードバランサの機能エラーは、製品の不具合だけでなく、設定や接続先のサーバー、ネットワークなど複数の要因が関係する場合があります。症状から順に絞り込むと、原因の特定が進みます。まず、症状と機能の対応を表で整理します。

症状から疑われる機能を絞り込む

エラーが起きたときは、画面に出た内容や発生の頻度、対象の利用者の範囲を整理しましょう。全員に起きるのか、特定の条件の利用者だけに起きるのかで、疑う機能が変わります。

発生した日時と直前の作業もあわせて記録します。設定の変更や証明書の更新、サーバーの追加といった作業の直後であれば、その作業が関係している可能性があります。

変更の履歴があると、原因の特定が早まります。複数の担当者で状況を共有できるよう、確認した内容はその都度メモに残しましょう。

設定の誤りと製品側の不具合を分けて考える

原因の候補には、ロードバランサの設定、接続先のサーバー、ネットワーク機器、製品そのものの不具合など、複数があります。まず、最近の変更箇所と、設定値が意図どおりかを確認しましょう。

設定に問題が見当たらない場合は、製品のバージョンや既知の不具合の情報を、提供元の公開資料で調べます。一時的な回避策が案内されている場合もあります。原因をどちらか一方に決めつけず、順に切り分けることが大切です。

調査に必要なログと情報を集める

ベンダーへ相談する際は、状況を正確に伝えられると対応が進みます。発生日時、症状、対象の範囲、直前の変更、製品のバージョン、関連するログを、あらかじめそろえておきましょう。

ログには、ロードバランサの動作記録、接続先サーバーの応答記録、アプリケーションの記録があります。時刻をそろえて見比べると、どの段階で問題が起きたかを追いやすくなります。

機器の時刻設定のずれにも注意しましょう。ログの保存期間が短い場合は、早めに保存しておくと、あとから調査しやすくなります。

負荷分散の機能エラーで通信が偏るときの原因

ロードバランサを使っていても、特定のサーバーに通信が偏る場合があります。方式の特性や、セッション維持の設定、接続の長さなどが影響するため、偏りの理由を分けて確認しましょう。ここでは、方式、維持、指標の3つの順に整理します。

負荷分散方式の特徴と偏りの関係

負荷分散方式には、順番に振り分けるラウンドロビンや、接続数の少ない先へ振り分ける最小接続があります。サーバーの性能に応じて比率を変える重み付けも、代表的な方式です。方式ごとに得意な場面が異なります。

処理時間にばらつきがある通信で順番に振り分けると、重い処理が特定のサーバーに重なる場合があります。サーバーの性能に差があるのに重みを設定していない場合も、偏りが生じます。方式と重みの設定を見直しましょう。

セッション維持や接続の長さによる偏り

セッション維持により、同じ利用者を同じサーバーへ送り続ける設定では、利用者数に差があると偏りが生じます。企業や施設のネットワークでは、多数の利用者が同じIPアドレスで接続する場合もあります。

また、接続を長く保つ通信は、一度振り分けられると別のサーバーへ移りません。サーバーを追加しても既存の接続が移らず、新しい台が使われにくい場合もあります。

接続の保持時間の設定も確認しましょう。利用者の環境の違いも、あわせて考えておくと安心です。

偏りを確認する指標と調整の進め方

偏りの確認には、サーバーごとの接続数、通信量、CPUの使用率、応答時間を比べます。ロードバランサの管理画面や監視ツールで、時間帯ごとの推移を見ると、偏りが続くのか一時的かを判断できます。

調整は、方式の変更、重みの見直し、セッション維持の条件の緩和などを、一度に1つずつ行います。複数を同時に変えると、効果の判断が難しくなります。

変更前後の数値を記録して、比較しましょう。調整の結果は、運用の手順書にも反映しておくと、担当者が代わっても引き継げます。

ヘルスチェックの機能エラーで正常なサーバーが外れるとき

ヘルスチェックは、障害のあるサーバーを自動で切り離す重要な機能です。一方で、判定の条件が実際の状態にあっていないと、正常なサーバーが外れたり、異常を見逃したりする場合があります。ここでは、確認方法の種類と見直すポイントを整理します。

■接続の確認

サーバーに通信できるかだけを確かめる、簡易な方法

■ポートの確認

サービスが使う番号の窓口が応答するかを確かめる方法

■アプリケーションの確認

指定したページにアクセスし、返ってくる応答の内容まで確かめる方法

判定の条件が実際の状態にあっているか見直す

確認の間隔、応答を待つ時間、異常と判定する失敗の回数が厳しすぎると、一時的な遅れで正常なサーバーが外れる場合があります。反対に緩すぎると、障害の検知が遅れます。サービスの特性にあわせて、数値を調整しましょう。

確認する方法も重要です。ポートが応答していても、アプリケーションやデータベースが正常でない場合があります。サービスの状態まで確かめる方法を選べるか、確認用のページを用意できるかを検討しましょう。

ヘルスチェックの通信が遮断されていないか確かめる

ヘルスチェックの通信が、サーバー側のファイアウォールやアクセス制限に遮られると、正常でも異常と判定される場合があります。ロードバランサからの確認の通信を許可しているかを確認しましょう。

確認先のページに認証が必要な場合も、応答が正常にならない原因になります。確認専用のページは認証なしで応答できるようにし、外部から見られないよう制限をかける方法があります。設定の際は、情報システム部門に相談しましょう。

復帰や全台異常時の動作を把握する

切り離されたサーバーが、いつ、どのような条件で振り分けに戻るかも確認が必要です。復帰の判定が厳しいと、すでに回復しているサーバーが長く使われない場合があります。

すべてのサーバーが異常と判定されたときの動作も、製品によって異なります。通信を止めるのか、そのまま振り分けを続けるのかを把握し、必要に応じて障害時の案内ページを用意しておきましょう。

動作の確認は、検証環境で行うと安全です。本番で試す場合は、利用者への影響を考えて日時を決めましょう。

ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料請求して、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でロードバランサの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。

SSL/TLSの終端処理の反映が遅れるときの機能エラー

SSL/TLSの終端処理とは、暗号化された通信をロードバランサで受け取り、復号する処理を指します。証明書の更新や設定の反映が遅れると、警告の表示や接続エラーにつながる場合があります。更新前後の流れを押さえて、確認の抜けを減らしましょう。

終端処理の役割と証明書を反映する流れ

終端処理では、ロードバランサに証明書を登録し、利用者との暗号化通信を担います。証明書を更新するときは、新しい証明書の登録、設定の適用、動作の確認という流れが代表的な手順です。製品によって、操作の画面や適用の方法は異なります。

中間証明書が不足していると、環境によって警告が出る場合があります。中間証明書とは、利用者の端末が証明書を信頼できるよう、つなぎの役割を持つ証明書です。証明書の期限は、更新の予定を決めて管理しましょう。

冗長構成やクラウド型での反映のずれ

冗長構成では、2台の機器の設定が同期されるまでに時間がかかる場合があります。片方にだけ新しい証明書が反映されていると、アクセスのたびに表示が変わる可能性があります。

クラウド型の場合は、設定が全体へ行き渡るまでに時間がかかる場合があります。また、すでにつながっている接続は、更新前の設定のまま続くこともあります。

反映の完了を確認する方法を、事前に把握しておきましょう。反映までの時間の目安も、ベンダーに聞いておくと役立ちます。

証明書の反映後に確認する方法

証明書の更新後は、複数のブラウザーや端末で、有効期限と発行元の表示を確認しましょう。利用者が実際に使う接続経路から確かめることが大切です。社内のネットワークだけでなく、外部の回線からの表示も見ておくと、見落としを減らせます。

設定の適用前に、現在の設定を保存し、問題があれば元に戻せるようにしておきます。更新は、アクセスの少ない時間帯に行うと、影響を抑えられます。手順書を作成しておくと、次回の更新も落ち着いて進められます。

セッション維持の機能エラーでログインが途切れるとき

セッション維持（パーシステンス）とは、同じ利用者の通信を同じサーバーへ送り続ける機能です。ログイン状態や買い物かごの情報を保つために使われますが、設定や環境によって、うまく働かない場合があります。主な方式を表に整理します。

維持の方式と起こりうる不具合を理解する

送信元IPアドレスで固定する方式では、スマートフォンの回線切り替えなどでIPアドレスが変わる場合があります。すると、別のサーバーへ振り分けられ、ログインが切れる可能性があります。

Cookieを使う方式では、利用者の端末がCookieを受け付けない設定だと、維持が働きません。暗号化された通信の内容を読み取れない構成では、Cookie方式を使えない場合もあります。方式と構成のあわせ方を確認しましょう。

アプリケーションとのタイムアウトの食い違いを確かめる

ロードバランサの維持時間と、アプリケーション側のセッションの有効期間が食い違うと、ログインが途中で切れる場合があります。どちらか短いほうに挙動が左右されます。

両方の設定値を並べて確認し、利用者の操作の間隔にあう値にそろえましょう。設定の変更は、アプリケーションの担当者とも調整して進めます。

無操作の時間が長い業務では、特に食い違いが表れやすくなります。設定を変更したときは、一定時間操作せずに動作を試してください。

障害時にセッションが失われる前提で備える

維持先のサーバーが停止すると、その利用者は別のサーバーへ振り分けられ、保存されていた情報が失われる場合があります。サーバー障害時の再ログインは、仕組み上起こりうる動作です。再ログインの手間を減らすには、入力途中の内容が失われないかも見ておく必要があります。

対策には、セッションの情報をサーバーの外にある共有の保存先へ置く方法があります。アプリケーションの作り方にも関わるため、開発の担当者やベンダーと相談しましょう。重要な入力は、途中保存できる設計も有効です。

機能の対応範囲を確かめたい製品

機能ごとのエラーを避けるため、負荷分散や暗号化処理の機能を確認しておきたい製品を紹介します。必要な機能が含まれるかを資料で確かめましょう。

ビジネスセキュリティ（VSR）nシリーズ

株式会社 USEN ICT Solutions

資料請求リストに追加

製品詳細ページへ ＞

製品・サービスのPOINT

1. 業界最多クラスのセキュリティ機能の中から独自のカスタムが可能
2. 管理者負担軽減！導入から運用、保守まですべて一括対応。
3. 24時間365日の障害検知・切り分けから復旧対応までサポート！

ロードバランサに関するよくある質問

ロードバランサの機能のエラーについてよくある質問と回答をまとめました。

■Q1：エラーが起きたとき、ベンダーに伝える情報は何ですか？

A：発生日時、症状、対象の利用者の範囲、直前の変更、製品のバージョン、関連するログがあると調査が進みます。時刻のずれがないかも、あわせて確認しましょう。

■Q2：設定を変更した後、エラーを防ぐ確認方法はありますか？

A：変更前の設定を保存し、検証環境で動作を確かめてから本番に適用する方法があります。変更の前後で応答時間や接続数を比べると、影響を把握しやすくなります。

■Q3：機能のエラーを早く見つけるには、何を監視しますか？

A：サーバーごとの接続数、応答時間、ヘルスチェックの結果、証明書の有効期限などを監視する方法があります。異常時に管理者へ通知される設定も確認しましょう。

■Q4：バージョンアップでエラーが解消する場合はありますか？

A：不具合の修正が含まれる場合は、解消が期待できます。ただし、更新で動作が変わる場合もあるため、提供元の情報を確認し、検証環境で試してから適用しましょう。

まとめ

ロードバランサの機能エラーは、症状から疑われる機能を絞り、設定と環境を順に確認することで切り分けられます。通信の偏りは方式と維持の設定、ヘルスチェックは判定条件と通信の許可、SSL/TLSは証明書の反映、セッション維持は方式と有効期間を見直しましょう。原因が分からないときは、ログを集めてベンダーへ相談してください。製品選びの際は、資料請求で機能の差を比べてみましょう。