DigiLoog

続きを読む »

• 事業者選定

何処の外部ストレージを使うか選ぶのが、一番大変だった…

レンタルサーバで”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等のクラウド基盤を使う場合にも応用が利くので、自鯖運用でスキルを貯めていこうと思う。

« 続きを隠す

続きを読む »

ソースコードからビルドしている為、毎度お馴染みの “./configure && make” を実行。
zabbix 4.4で利用しているビルドオプションから変更なしにビルドが通った。
ただ、データベースは従来の文字コードから変更となっている為、
mysqldumpを用いてバックアップを作った後、データベースを文字コード指定で作り直す必要がある。
もし、古い文字コードを使っている場合、zabbixのフロントエンドをインストールする時に、
“Unsupported charset or collation for tables”と怒られてインストール出来ない状態になる。
その為、Zabbix Serverをインストールする時に文字コードも変換しておくと後で躓かない。

# mysqldump -u root -p zabbix --add-drop-table > zabbix-old.sql
# sed "s/CHARSET=utf8/CHARSET=utf8 COLLATE=utf8_bin/" zabbix-old.sql > zabbix-new.sql
# mysql -u root -p
MySQL > drop database zabbix;
MySQL > create database zabbix character set utf8 collate utf8_bin;
MYSQL > exit;
# mysql -u root -p zabbix < zabbix-new.sql

試した所、Zabbix Server、Zabbix Proxyの両方とも文字コード変更が必要だった。

………

zabbix 5.0を使った所、サーバ等のバックエンドはあまり変化が無い様に感じた。
Zabbix Agent 2が正式サポートされたのが一番の変更点。
ただし、従来の監視テンプレートを踏襲するなら今すぐ利用する必要も無いので、
エンタープライズ環境なら「枯れた」頃に導入するのが良いと思う。
ホビー環境なら即導入して遊び倒したいが、Go言語ライブラリが必要な事もあり、
ライブラリも最小構成にしている筆者環境では動かなかったので、今回のタイミングでは見送る事にした。

リリースされたばかりなので、改修パッチもそのうち出てくると思うが、
当面の間は、zabbix 5.0で挙動を確認予定。
そのうち、Zabbix Agent 2も熟れてくると思うので、その時に一斉アップグレードを行いたい。

« 続きを隠す