高度な運用ノウハウが求められるが故のナレッジ共有環境があるか

　前述した通り、アプリケーションレイヤーの処理は複雑であり、実際にプログラミングしながら自社のアプリケーションに最適な形にチューニングしていく必要がある。それ故、事前に通信内容に対してさまざまなアクションが図れるようコマンドがしっかり用意されているものや、日常的に利用しているユーザーがノウハウを共有し合うことが可能なコミュニティーなどが存在しているものは比較的安心感がある。

　また、アプリケーションごとに最適なルールが設定できるよう、ある程度のテンプレートがしっかり用意されているものを選択したい。セッション管理に関する変数の位置やHTTPリクエストに対するレスポンスの差異など、アプリケーションによって挙動が異なるものも多く、アプリケーションの特性をしっかり理解した上でテンプレート化されているものがあれば活用したい。中には、アプリケーションベンダーと共同検証を実施し、パラメータをAPI経由で設定するだけで最適化できる製品もある。

将来的な拡張性が考慮されているかどうか

　アプリケーションを最適な形でデリバリーするためのADCだからこそ、アプリケーションをどう使わせたいのかによってその使い方が異なってくる。今は使っていないアプリケーションでも今後対応することがあるだろうし、既存のアプリケーションを異なる場所から異なるデバイスでも使えるようにしたいなど、使い方が大きく変わってくることも考えられる。

　だからこそ、ある程度の拡張性や柔軟性を持っているADCを選んでおきたいところだ。できれば、単一のOSでさまざまなトラフィックが管理できるようなものを選んでおけば、後から新たな対応が求められたとしてもオペレーションコストの負担もかからず、迅速な対応が可能になってくるはずだ。

　また、今後も膨大なトラフィック増加が総務省の予測データからも明らかになっており、パフォーマンスが同一筐体でも柔軟に拡張していけるようなものが必要になってくる。1つの筐体に複数の仮想ADCが展開できる製品もあるため、将来を見据えてどこまで拡張できるのかを踏まえて製品を選んでおきたい。イニシャルコストばかりにこだわると、数年後はパフォーマンスが維持できない状況に陥る可能性もある。

データシートだけで判断しない“パフォーマンス”評価

　ADCはレイヤーごとのスループット性能やSSL処理などのパフォーマンスによって筐体のラインアップや価格が異なってくるが、実際にデータシート上に明記されているスペック通りに数値が確保されているわけではない。実際のアプリケーションの内容や種類によってパフォーマンスが大きく変わってくるため、できれば実環境での試験をしっかり行ってパフォーマンスの検証をしたい。

　また実際のパフォーマンスの数値をどういった内容で検証しているのかも、しっかりとヒアリングしておきたい。あるベンダーではパフォーマンスの結果を全て複雑な処理が発生するアプリケーションレイヤーで行っており、実環境に近い数字を公表しているというところもある。特にレイヤー7でのスループット性能については注意が必要だ。