[ns-lab BB] 新環境のWEBサーバ構成
以前の記事で、新環境のデータベース構成について紹介したが、
今回の刷新を機にWebサーバも構成を大きく変更した。
静的ファイルを保存するデータ領域は設計方針を大きく変更してみた。
従来は負荷分散型NFSを自前で構築していたのだが、
アプリケーションのバージョン依存が強くメンテナンス性が悪すぎた事もありサーバ刷新時に廃止をした。
そうなると、別の仕組みで静的ファイルを保存する必要があるのだが、
自前でNFSを立てるとなると冗長化するのが辛い上、単一障害点を無くした上でシンプル構成にしたかった。
そんな事もあり今回は新たな取り組みとして、外部ストレージを利用する方針に変更。
サービス接続点・外部ストレージ自体が単一障害点になる可能性が残っているが、
自前で分散ストレージを立てる寄りも冗長性が上がるのと、
分散ストレージが必要とするサーバリソース・NW帯域を確保する事が出来なかったので諦めた。
- 事業者選定
何処の外部ストレージを使うか選ぶのが、一番大変だった…
レンタルサーバで”AWS S3″の様なサービスを展開していても、価格的に個人利用するのが不可能だった。
個人利用出来るサービスがあったとしても、APIで外部ストレージを叩いてHTTPベースで処理を行う物が多く、
Webサーバで直接参照するには速度が遅すぎて使い物にならなかった。
そんな中で唯一見つけたのが「さくらのVPS」で提供している追加NFSストレージだった。
可用性もそれなりに有る上、自鯖を稼働させている「さくらの専用サーバ」と相互接続が可能な事もあり、
今回の要件にも合致した。
試しにリード・ライト速度も測ってみたが、20～50Mbps程度出ており問題無くファイル処理が出来た。
………
- システム構成
“ns-lab BB”は、自前でリバプロ型ロードバランサを構築してあるので、
Webアクセスのフロントエンドもロードバランサで終端した後、
負荷分散ポリシーに従い、バックエンドのWebサーバに処理を再転送する2層・3層構造を取ってみた。
静的ファイルは「さくらのVPS 追加ストレージ」に存在するNFS領域にある為、
Webサーバから「さくらのクラウド ブリッジ接続」を用いてアクセスする様にしてある。
ブリッジ接続は追加費用が発生する物なので金が無駄にならない様に、
サポートに問い合わせ仕様を確認した後、仮構築を行ってから本番実装をした。
今回のWebサーバ構成を図に起こすと上の様になる。
ブリッジ接続の設備メンテナンス影響で1回だけ計画停止したが、この1回以外では停止していない。
………
- システム障害動作
ロードバランサはアクティブ・スタンバイ方式なので、障害発生時にはシステム切り替えが発生する。
しかし、他のサーバは両アクティブ構成となっており、可能な限りシステム切り替えが起きない様にしてある。
この構成を維持する為に、ロードバランサからWebサーバを監視するヘルスチェックを一定間隔で送信し、
Webサーバ停止時には自動的にプールメンバから外れ、復旧時には自動追加するようにしている。
フロントエンド構成は刷新前のWebサーバを踏襲している事もあり、安定稼働し続けている。
今回採用した、外部ストレージの応答速度が気がかりであったが、
実際には1ms程度の低遅延で応答があり、リード・ライト速度も水準をキープしつつ処理出来ている。
ブログデータを格納しているデータベースは以前紹介した通り負荷分散型にしてある為、
読込み処理を分散しながら高速処理を行っている。
実際にアクセス速度分析を行うと、前構成は平均120mで応答が返ってきていたのだが、
新環境は平均70msまで短くなり、構成変更の成果が数値としても出ていた。
また、今回はロードバランサを噛ましている事からスケールアウトが容易に出来るのもメリットとなる。
閲覧者増加時や、新サイト立ち上げによって負荷が増えたとしても、
スケールアウトする事で一定負荷をキープし、結果として応答速度の維持も出来るのいが大きい。
今回のサーバ刷新によって、Webサーバ系のシステムが全てスケールアウトを取れる様になったのは大きかった。
この考えはAWS等のクラウド基盤を使う場合にも応用が利くので、自鯖運用でスキルを貯めていこうと思う。
