構築事例：Squidを利用したOffice365用プロキシサーバ

Office365を社内導入したが、インターネットを安定して使うことができなくなってしまったということで相談をいただきました。Office365もスムーズに使えないことがあるということでした。Office365導入で、インターネットのトラフィックが非常に多くなってしまったことが原因でした。

Office365専用回線とプロキシサーバ

デージーネットではOffice365専用のインターネット回線を用意しプロキシサーバを使ってOffice365の通信だけを別の回線に分けることを提案しました。インターネット回線には、Office365が常にスムーズに利用できるよう、帯域保障が受けられるものを利用しました。プロキシサーバのソフトウェアとしては、squidを採用することにしました。

Office365の通信だけをバイパス

通常のインターネットへのアクセスは、従来どおりファイアウォール経由で直接アクセスさせ、Office365への通信だけをプロキシサーバへバイパスするため、PACファイルを配布することにしました。PACファイルは、プロキシ自動設定ファイルと呼ばれています。ブラウザにPACファイルのURLを設定しておくことで、ブラウザが自動的にPACファイルをダウンロードし、その内容に合わせて適切なプロキシを使うようにすることができます。

プロキシサーバのサイジング

最後に残った課題は、Office365のトラフィック量に対して適切なプロキシサーバ数を配置することです。また、障害などで業務が止まらないように考慮することも必要でした。Office365は非常に頻繁かつ多くのセッションを張るため、プロキシサーバには大きな負荷が掛かります。デージーネットでサイジングを行なったところ、4台のプロキシサーバが必要であることが予測できました。

プロキシサーバの負荷分散と冗長化

当初はPACファイルに、ユーザによって異なるプロキシサーバを利用する設定を行なうことで、利用するサーバを分散しようと考えていました。しかし、この方法では、プロキシサーバに障害が発生した時に、Office365を利用できなくなる可能性があります。そのため、プロキシサーバにロードバランスさせることになりました。また、障害の場合でも性能に問題が出ないようにするために、プロキシサーバの台数を1台増やして、5台とすることになりました。

ロードバランスにはLinuxのLVSの機能を使うことにしました。プロキシサーバのうちの2台をクラスタ構成として、ロードバランス機能を同居させました。

プロキシサーバの管理性の確保

さらに、管理性を確保するために、GUIからロードバランスとクラスタの管理ができるようにしました。クラスタの管理にはNovellが開発しSuSE Linuxなどに採用されているHawkを、ロードバランスの管理にはデージーネットが公開しているOSSのILUKAを使いました。

社内サーバインフラの構築の事例一覧

• NFSサーバ冗長化事例
• OSSの掲示板システム（phpBB）事例
• OpenVASによるセキュリティ診断事例
• Squidを利用したOffice365用プロキシサーバ事例
• Fessによるファイルサーバ検索システム事例
• Rocket.Chatを利用したビジネスチャットシステム事例
• SambaによるWindowsファイルサーバの冗長化事例
• Rocket.ChatやJitsiを利用したビジネスチャットシステム事例
• Traccarを利用したGPS追跡記録システム事例
• Jitsiを利用したテレワーク環境（Web会議システム）の導入事例
• Apache Guacamoleを活用したリモートデスクトップ環境の構築事例