ロードバランサの連携エラーの原因と対処法を連携先別に整理

ロードバランサの連携エラーを切り分ける基本の順序

連携エラーは、ロードバランサ、連携先、あいだのネットワークのいずれにも原因がある場合があります。連携先ごとに起こりやすいエラーを把握しておくと、確認の順序を決めやすくなります。まず、連携先ごとの違いを表に整理します。

連携先ごとにエラーの種類を整理する

連携は、ロードバランサと連携先が、設定や認証、通信の約束をそろえて成り立ちます。どれかがずれると、認証の失敗、データ反映の遅れ、一部の処理の失敗といったエラーとして現れます。

エラーが起きたら、どの連携先とのやり取りで発生したかを最初に特定しましょう。複数の連携先に同時に問題が出ている場合は、ネットワークや認証など共通の要因が関係している可能性があります。エラーの一覧を作ると、共通点に気づきやすくなります。

エラーメッセージとログから場所を特定する

エラーメッセージには、原因のヒントが含まれます。メッセージの文言、エラーコード、発生した時刻を記録し、ロードバランサと連携先の双方のログと照らし合わせましょう。

双方のログの時刻がずれていると、対応する記録を見つけにくくなります。機器やサービスの時刻設定を確認しておくと、調査が進めやすくなります。

ログの保存期間も、事前に確認しておきましょう。必要なログを見られる権限を持つ担当者も、あらかじめ決めておくと安心です。

責任範囲を分けて確認する

連携の問題は、複数の箇所が原因になりえます。ロードバランサ側の設定、連携先の仕様や制限、あいだのネットワーク機器のどれかに決めつけない姿勢が重要です。

確認は、ロードバランサ単体の動作、連携先単体の動作、両者をつなぐ経路の順に進めます。専門的な調査が必要な場合は、ベンダーや情報システム部門へ相談し、切り分けた結果もあわせて伝えましょう。原因が分かった内容は、再発を防ぐため、記録に残しておきましょう。

クラウドとの連携で不具合が起きるときの確認点

パブリッククラウドとの連携では、認証や権限、ネットワークの設定、台数の増減への追従など、確認すべき点が増えます。クラウド側の仕様や、自社とクラウド提供者の責任範囲もあわせて確認しましょう。

認証情報と権限設定の確認

クラウドと連携する場合、ロードバランサがクラウドの機能を操作するための認証情報と権限が必要です。認証情報の期限切れや、権限の不足があると、連携の処理が失敗する場合があります。

権限は、必要な操作に限って付与するのが基本です。エラーが出たら、どの操作で権限が不足しているのかをログで確認し、必要最小限の範囲で見直しましょう。

権限の変更は、社内のルールにしたがって申請します。変更の内容と理由は、記録に残しておきましょう。

ネットワーク設定と通信経路の確認

クラウド上では、通信を許可する範囲をネットワークの設定で制御します。ロードバランサから接続先のサーバーへの通信や、ヘルスチェックの通信が許可されていないと、接続の失敗につながる場合があります。

許可するポート番号や接続元の範囲を、設定の一覧で見直しましょう。複数の設定が重なって通信が遮られていることもあるため、通信の経路にある設定を順にたどって確認すると、原因が見つかりやすくなります。変更の履歴があれば、直近の設定変更もあわせて確認しましょう。

台数の増減に伴う登録と解除のずれ

アクセス量に応じてサーバーの台数を自動で増減させる構成では、新しいサーバーの登録や、停止したサーバーの解除が遅れる場合があります。登録前のサーバーには、通信が届きません。

停止したサーバーが解除されないまま残ると、エラーの応答が返る場合もあります。登録と解除の処理が完了するまでの時間と、ヘルスチェックの判定に要する時間を把握しておきましょう。接続の切り離し時に、処理中の通信を待つ設定の有無も確認が必要です。

Webサーバーとの連携でエラーが起きるときの対処

ロードバランサとWebサーバーの連携では、応答の遅れや接続の失敗がエラーとして現れます。画面に出るステータスコードや、双方の設定の食い違いを手がかりに、原因を絞り込みましょう。

■502

ロードバランサが、接続先のサーバーから受け取った応答を正しく扱えなかった状態

■503

サーバーが一時的に処理できない状態。過負荷や保守中などが考えられる

■504

接続先のサーバーから応答が返るまでの待機時間を超えた状態

ステータスコードから原因の方向を読み取る

ステータスコードとは、通信の結果を数字で示す仕組みです。502や503、504が表示された場合、原因はロードバランサにも、接続先のサーバーにも、あいだのネットワークにもありえます。

数字だけで原因を断定せず、ロードバランサと接続先サーバーの双方のログを確認しましょう。接続先のサーバー側に記録が残っていなければ、そこへ届く前の段階で問題が起きている可能性があります。ログの記録形式や保存先も確認しましょう。

タイムアウトと接続維持の設定をそろえる

ロードバランサとWebサーバーには、通信を待つ時間と、接続を保つ時間の設定があります。この値に食い違いがあると、一方が接続を切ったあとに他方が通信を送り、エラーになる場合があります。食い違いの有無は、双方の設定値を並べると見つけやすくなります。

ロードバランサ側の待機時間より、サーバー側の接続を保つ時間を長くする方法があります。処理に時間がかかる機能は、待機時間の延長が必要な場合もあります。変更の前後の動作は、検証環境で確かめましょう。

送信元の情報を正しく引き継ぐ

ロードバランサを経由すると、構成によっては、Webサーバーから見た通信の送信元が、ロードバランサのアドレスになります。利用者のアドレスを使う機能やアクセス制限が、うまく働かない場合があります。アクセス記録からも、利用者の特定が難しくなります。

この対策として、利用者の元のアドレスをヘッダーという付加情報に載せて渡す設定があります。Webサーバー側でその情報を読み取る設定も必要です。ログの記録形式も見直し、変更後は、実際のアドレスが記録されているかを確かめましょう。

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

APIの呼び出し回数の制限で連携エラーが出るとき

APIを使った連携では、呼び出し回数などに制限が設けられている場合があります。制限の種類と、上限に達したときの動作を把握しておくと、連携エラーの原因を見つけやすくなります。

制限の種類と上限に達したときの動作

APIの制限は、製品やサービスによって種類や数値が異なります。上限に達すると、要求が拒否され、「Too Many Requests」を示す429といったエラーが返る場合があります。

自動化の処理が複数同時に動く場合や、短い間隔で繰り返し呼び出す場合は、上限に達しやすくなります。上限の数値と、拒否されたときの動作は、ベンダーの資料や仕様書で確認しておきましょう。上限は契約の種類によって変わる場合もあります。

再試行の間隔と回数の設計

一時的な拒否の場合は、時間をおいて再試行すると成功する場合があります。再試行の間隔を少しずつ広げる方法は、制限の緩和を待つ際に有効です。

ただし、無制限に繰り返すと、かえって負荷を高めます。再試行の回数に上限を設け、失敗が続くときは管理者へ通知する仕組みにしましょう。

失敗した処理が途中で止まっていないかの確認も、あわせて必要です。再試行しても成功しない場合は、設定や認証の誤りを疑いましょう。

呼び出しを減らす工夫と上限の相談

呼び出し回数を減らすには、変更があった項目だけを送る方法があります。複数の操作をまとめる、実行の間隔をあけるといった工夫もあります。設定の変更が多い場合は、処理の流れ自体も見直しましょう。

それでも上限が足りないなら、上限の緩和や別の連携方法の提供について、ベンダーへ相談しましょう。見直しが可能かは、契約や製品によって異なります。必要な回数の見積もりを用意しておくと、相談が進みます。

ネットワーク監視ツールと連携しても手作業が残る場合

ネットワーク監視ツールと連携しても、通知を受けたあとの確認や対応が手作業のまま残る場合があります。連携の範囲と運用の流れを整理して、自動化できる部分と人が判断すべき部分を分けましょう。

取得できる項目と通知の方式を確かめる

監視ツールがロードバランサから取得できる項目は、連携の方式によって異なります。SNMPは機器の状態を取得する標準的な仕組みで、ほかにログの転送やAPIを使う方式があります。製品が対応している方式を確認しましょう。

接続数、応答時間、サーバーの状態といった確認したい項目が取得できるかを、事前に確認しましょう。通知がメールだけなのか、チャットツールや電話にも対応するのかも、運用に影響する条件です。通知の遅れの有無も、検証で確かめましょう。

通知から対応までの流れを決める

通知が届いても、誰が何を確認し、どこまで対応するかが決まっていないと、対応が滞る場合があります。通知の種類ごとに、確認する担当と手順を決めておきましょう。

通知が多すぎると、重要な警告を見落とす恐れがあります。しきい値や通知の条件を見直し、緊急性に応じて通知の方法を分けると効果的です。

対応の記録を残し、条件の見直しにも役立てましょう。夜間や休日に通知を受ける担当者も、決めておくと安心です。

自動化する範囲と手作業を整理する

設定の変更や切り離し、復旧の操作まで自動化できるかは、製品や連携の方式によって異なります。自動化できる範囲を最大にするのではなく、誤作動が起きた際の影響を考えて、範囲を決めることが大切です。

例えば、通知までを自動化し、切り離しは人が判断する運用にすれば、安全性を保てます。手作業が残る部分は、手順書にまとめて共有しましょう。見直しの機会を定期的に設けると、運用の改善にも役立ちます。

連携先を想定して見たい製品

連携のエラーを避けるため、接続先や構成を想定して確認しておきたい製品を紹介します。連携の方法は、資料や問い合わせで確かめましょう。

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

株式会社 USEN ICT Solutions

資料請求リストに追加

製品詳細ページへ ＞

製品・サービスのPOINT

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

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

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

■Q1：連携エラーの原因が、どちら側にあるか分からないときは？

A：ロードバランサ単体、連携先単体、両者を結ぶ経路の順で、動作を確認しましょう。双方のログを、時刻をそろえて見比べると、問題が起きた段階を絞り込めます。

■Q2：連携用の認証情報は、どのように管理しますか？

A：期限や更新の担当者を決め、管理表に記録しておく方法があります。権限は必要な操作に限り、変更の履歴も残しましょう。

■Q3：連携の設定を変更するとき、注意する点は何ですか？

A：変更前の設定を保存し、検証環境で動作を確かめてから適用しましょう。連携先の担当者にも変更の内容と日時を共有しておくと、問題が起きたときに対応しやすくなります。

■Q4：連携先のサービスが仕様を変更した場合、どう気づけますか？

A：提供元の告知やリリースノートを定期的に確認する方法があります。通知を受け取る担当者を決め、影響の有無を確認する流れを用意しておきましょう。

まとめ

ロードバランサの連携エラーは、連携先ごとに原因と確認点が異なります。クラウドやWebサーバー、API、ネットワーク監視ツールの順に、状況を整理しましょう。認証や権限、タイムアウトの設定、呼び出し回数の制限、通知の流れを順に確認し、切り分けましょう。原因が分からないときは、ログを整理してベンダーに相談するのが有効です。連携の条件は製品で異なるため、資料請求で比較してみてください。