ADCの導入で失敗する原因と、効果を出すための確認点

ADCの導入で失敗が起こる原因の全体像

ADCの導入の失敗は、製品の性能だけで決まるわけではありません。目的の設定、移行の進め方、性能の見積もり、導入後の定着といった複数の段階で、原因が生じる場合があります。ここでは、失敗の全体像を整理します。

導入の目的があいまいな場合

導入の目的が、負荷分散の強化なのか、暗号化通信の処理を集約することなのか、攻撃への備えなのかを決めていないと、必要な機能を選べません。あいまいなまま導入すると、使わない機能に費用をかけたり、必要な機能が不足したりする場合があります。

目的は、アクセス集中時の応答の遅れ、運用の手間、セキュリティの強化など、解決したい課題の形で書き出しましょう。課題ごとに、導入後に確認する指標も決めておきます。指標が決まっていると、導入後に効果を判断できます。

失敗を分類する4つの切り口

失敗の原因は、目的の設定、既存構成からの移行、性能の見積もり、導入後の定着の4つに分けて整理できます。ADCは、通信の振り分けに加えて、暗号化通信の処理や攻撃の検査なども担う装置です。担う範囲が広いため、失敗の起こる段階も複数あります。

原因を一つに決めつけると、対策が的外れになる場合があります。製品の機能、自社の構成、運用の体制、連携する他のシステムのどこに要因があるかを、分けて確認しましょう。確認の結果は、導入の計画書にも反映します。

ロードバランサの延長で考える落とし穴

ADCは、ロードバランサと同じく通信を振り分けますが、暗号化通信の処理を肩代わりするSSLオフロードや、不正な通信を検査するWAFといった付加機能を備える場合があります。機能が増えるぶん、導入時に設定と検証が必要な範囲も広がります。

ロードバランサの延長で考えると、付加機能の設定や検証、運用の準備を見落とす場合があります。付加機能を使うことで、設定項目と確認すべき範囲が増える点を、導入計画に含めましょう。必要な作業と担当者も、あらかじめ洗い出しておきます。

負荷分散からの移行で失敗する原因

単純な負荷分散の構成からADCへ移行する場合、既存の設定や通信の流れを引き継げず、不具合が起こる場合があります。移行で失敗しないための準備を、棚卸し、段階的な移行、切り戻しの順に整理します。負荷分散だけの構成で動いてきた環境ほど、事前の確認が大切です。

現行の構成と設定の棚卸し

移行の前に、現在の負荷分散の設定を洗い出しましょう。振り分け先のサーバ、振り分けの方式、セッション維持の方法、ヘルスチェックの条件、通信の経路が対象です。長く運用している環境では、設定の理由が分からない項目が残っている場合があります。

設定の理由が不明なまま新しい機器へ移すと、通信の動作が変わり、不具合につながる場合があります。構成図と設定の一覧を作成し、担当者や開発部門に理由を確認しましょう。確認できなかった項目は、移行の検証で動作を確かめます。

機能を一度に切り替えるリスク

ADCはさまざまな機能を備えるため、移行と同時にSSLオフロードやWAFなども有効にしたくなる場合があります。しかし、複数の変更を同時に行うと、不具合が起きた際に原因を切り分けにくくなります。切り分けの手間は、復旧の遅れにもつながります。

まず従来と同じ振り分けの動作で移行し、動作が安定してから付加機能を一つずつ有効にする進め方があります。段階ごとに確認項目を決め、問題があれば前の段階へ戻せるようにしておきましょう。

切り戻し手順と検証の準備

切り戻しとは、移行後に問題が生じた際に、元の構成へ戻す作業です。切り戻しの手順が決まっていないと、障害の影響が長引く場合があります。移行の前に、戻す条件と手順、所要の時間を確認し、関係者の間で共有しておきましょう。

検証は、本番環境とできるだけ近い条件で行います。本番環境への影響や、提供会社の規約を確認したうえで、実施の時期と範囲を決めましょう。移行の作業は、利用者への影響が少ない時間帯に実施し、関係者へ事前に周知します。

アクセス集中時の応答低下が減らない原因

ADCを導入しても、アクセスが集中したときの応答の遅れが減らない場合があります。原因はADCだけにあるとは限らず、サーバやデータベース、設定など複数の箇所に関わります。ここでは、原因の見つけ方を整理します。

ボトルネックが別の場所にある場合

ボトルネックとは、システム全体の処理速度を決めている最も遅い部分です。応答の遅れの原因が、アプリケーションの処理やデータベースの待ち時間にある場合、ADCを導入しても改善しないことがあります。導入前の原因の調査が欠かせません。

原因を探るには、通信の各段階にかかる時間を確認します。ADCのログや画面で、どの段階で時間がかかっているかを把握しましょう。サーバ側の改善と、ADCが持つ機能の活用は、あわせて検討する必要があります。

機能の有効化で処理能力が下がる場合

暗号化通信の処理やWAFの検査は、ADCに負荷がかかる処理です。これらを有効にすると、仕様書にある処理能力より低い値になる場合があります。測定の条件は製品ごとに異なるため、数値だけで比べず、条件をそろえた確認を求めることが大切です。

利用する機能を有効にした条件での処理能力を、提供会社に確認しましょう。余裕のない構成だと、アクセスの集中時に処理が追いつかなくなります。導入前の見積もりに、機能の有効化による影響を含めておきます。

キャッシュと接続設定が適さない場合

キャッシュや圧縮、接続の多重化といった機能は、設定が適切でないと効果が出ない場合があります。例えば、頻繁に内容が変わるページをキャッシュの対象にしても、効果は限られます。対象の選び方が、効果を大きく左右します。

接続の維持時間や上限の設定が、アプリケーションの動き方に適していないと、かえって遅延の原因になることもあります。設定を変更する際は、検証環境で動作を確認し、変更の前後で応答時間を比較して効果を見ましょう。

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

繁忙期に処理速度が遅くなる要因と備え

繁忙期には、ADCの処理速度が遅くなる場合があります。通信量の増加だけでなく、接続数の上限や機能の設定など、複数の要因が関わるため、事前の見積もりと検証が欠かせません。ここでは、その進め方を整理します。

繁忙期の負荷の見積もり方

繁忙期の負荷は、過去の通信量の記録をもとに見積もります。同時に接続する利用者の数、データの転送量、新しく接続する回数の3つが目安です。平均ではなく、最も混み合う時間帯の値を、時間帯ごとの推移とあわせて確認しましょう。

事業の拡大やキャンペーンの予定がある場合は、過去の値に上乗せして見積もります。見積もりの根拠と前提を記録しておくと、実際の結果とのずれを後から確認できます。ずれが大きい場合は、次の見積もりに反映します。

負荷試験の進め方

負荷試験とは、実際の利用を想定した大量の通信を発生させ、システムの動作を確認する試験です。ADC単体ではなく、振り分け先のサーバを含めた構成全体で実施します。試験の対象と範囲は、事前に関係部門と合意しておきます。

試験は、本番環境への影響を避け、検証環境で行うのが基本です。提供会社の規約や、社内のルールも確認します。処理が遅くなり始める水準を把握しておくと、どの程度の余裕を持たせた構成にすべきかを判断しやすくなります。

余裕を持った構成と拡張の備え

処理能力に余裕を持たせた構成にしておくと、想定を超えた負荷にも対応しやすくなります。機器を追加して処理能力を引き上げられるか、ライセンスの変更で性能を拡張できるかを確認しましょう。拡張にかかる期間や、作業中の通信への影響も確認します。

クラウド上のサービスや仮想環境の場合は、性能を変更しやすい場合があります。ただし、費用の増減や設定の変更手順は製品ごとに異なります。繁忙期の前に拡張の手順を試し、結果を文書に残しておくと安心です。

導入後の定着で失敗を避ける進め方

ADCの導入後に、運用の属人化が解消しないことがあります。導入の作業を担当した人しか設定を理解していない状態が続くためです。定着させるための進め方を整理します。導入前の計画に含めておきましょう。

■文書の受け取り

設計と運用の文書を、導入の完了時に受け取れるか

■複数人での理解

担当者以外の人が文書を読んで作業できるか

■効果の測定

導入前に決めた指標で、導入後に効果を確認できるか

属人化が解消しない理由

導入作業を担当者が主導し、設定の判断が個人の経験にもとづいて進むと、知識がその担当者に集中します。構築を事業者に任せた場合も、設定の内容を社内で把握していないと、変更のたびに依頼が必要です。社内に知識が残りません。

ADCは設定項目が多く、機能ごとに専門的な知識が求められる場合があります。そのため、導入しただけでは属人化が解消されません。設定の意図を記録し、担当の交代にも備えて、複数の人が理解できる状態を目指しましょう。

設計と運用を分けた文書化

文書は、設計と運用の2種類に分けて作成しましょう。設計の文書には、構成図、設定の一覧、設定した理由を書きます。運用の文書には、定期作業の手順、障害時の対応、担当者の連絡先を書き、どちらも変更のたびに更新しましょう。

文書を分けておくと、目的の情報を探しやすくなります。導入作業が終わった時点で、事業者から文書を受け取る契約にしておきましょう。担当者以外の人が読んで理解できるかを確認し、不足は導入の完了前に補ってもらいます。

導入後の効果測定と見直し

導入後は、導入前に決めた指標で効果を測定します。応答時間、エラーの発生数、運用にかかる作業時間などが指標です。導入前の値と比べて評価し、目標に届かない場合は、原因を設定、構成、運用の面から確認し、改善の優先順位を決めましょう。

測定の結果をもとに、設定や体制を定期的に見直しましょう。見直しの内容と理由を記録しておくと、次の担当者が経緯を把握できます。導入後の支援内容や、相談できる窓口の有無も、比較の段階から確認しておくと安心です。

負荷分散からの移行先を検討するADC

移行先を検討する候補として、負荷分散と暗号化通信の処理に関わる製品を掲載します。

ADCに関するよくある質問

ADCの導入の失敗についてよくある質問と回答をまとめました。

■Q1：ロードバランサからADCへ移行するとき、最初に何をしますか？

A：現在の振り分けの方式、セッション維持、ヘルスチェックなどの設定を洗い出し、構成図と一覧にします。設定の理由が不明な項目は、検証で動作を確かめましょう。

■Q2：移行で問題が起きたとき、元の構成に戻せますか？

A：切り戻しの手順を事前に決めておけば、元の構成へ戻せる場合があります。戻す条件と所要の時間を確認し、利用者への影響が少ない時間帯に作業しましょう。

■Q3：導入後に応答が遅い場合、原因はADCにありますか？

A：ADCだけが原因とは限らず、アプリケーションの処理やデータベース、機能の設定が関わる場合があります。通信の各段階にかかる時間をログで確認し、原因を切り分けましょう。

■Q4：導入の効果は、どのように測ればよいですか？

A：導入前に、応答時間やエラーの発生数、運用の作業時間などの指標を決め、導入前の値と比べます。目標に届かない場合は、設定、構成、運用の面から原因を確認しましょう。

まとめ

アプリケーションデリバリコントローラ（ADC）の導入で失敗する原因は、目的の設定、既存構成からの移行、性能の見積もり、導入後の定着の4つに整理できます。原因は一つとは限らず、サーバや設定、体制も関わります。導入前に目的と指標を決め、移行や検証の支援内容も含めて、複数の製品の資料を請求して比較してみてください。