何処の外部ストレージを使うか選ぶのが、一番大変だった…
レンタルサーバで”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等のクラウド基盤を使う場合にも応用が利くので、自鯖運用でスキルを貯めていこうと思う。
« 続きを隠す
