こんにちは！UOZUです。
先日、WEBサーバの冗長化構成とロードバランサについて紹介しました。
今回は第二弾として、「コンテンツの同期」 について見ていきます。
WEBサーバを冗長化する際は、サーバを複数台用意してロードバランサで振り分ければ終わり、というわけではありません。
実際には、各サーバで同じコンテンツを表示できるようにしておくこと も、とても重要です。
今回は、ロードバランサで冗長化した環境において、なぜコンテンツの同期が必要になるのか、そしてどのような方法が考えられるのかを整理していきます。
コンテンツの同期とは
サーバとコンテンツの関係は、少しイメージしにくい部分があるかもしれません。
そこでまずは、冗長化構成の基本を振り返りながら、どのような点に注意が必要なのかを見ていきます。
おさらい：ロードバランサでの冗長化構成
ロードバランサを使ってWebサーバを冗長化すると、複数台のサーバへアクセスを分散できます。
この構成では、片方のサーバに障害が発生しても、もう片方が正常であれば、ロードバランサが正常なサーバへアクセスを流してくれます。
そのため、利用者から見ると、サーバ障害が起きてもすぐにエラー画面が表示されにくくなり、サービスを継続しやすくなります。
| ダウン状況 | ロードバランサの制御 | ブラウザ上の表示 |
| 全てのサーバが正常 | いずれかのサーバにアクセスを流す | 正常な表示 |
| サーバ[A]がダウン サーバ[B]が正常 | [B]にアクセスを流す | 正常な表示 |
| サーバ[A]がエラー表示 サーバ[B]が正常 | [B]にアクセスを流す | 正常な表示 |
| 全てのサーバがダウン | 事前に指定したサーバにアクセスを流す | 事前に指定したお知らせ画面（ソーリーページ） |
ただし、ここで重要なのは、ロードバランサが見ているのはあくまでサーバの正常・異常であり、コンテンツの新旧ではない という点です。
ロードバランサを利用した際のコンテンツ表示
ここまでが前回の記事のおさらいです。
では、この構成でコンテンツ更新を行った場合、何が起きるのでしょうか。
たとえば、サーバAとサーバBの2台でWebサーバを冗長化しているとします。
このとき、サーバAだけでコンテンツを更新し、サーバBは更新していない 状態になると、ロードバランサはどちらのサーバも「正常」と判断してアクセスを振り分けます。
すると、利用者によって
- 新しいコンテンツが表示される場合
- 古いコンテンツが表示される場合
が発生してしまいます。
| コンテンツの状態 | ロードバランサの判定 | ブラウザ上の表示 |
| サーバAで4月21日更新 サーバBで3月21日更新 | いずれかのサーバにアクセスを流す | 4月21日更新のコンテンツ または 3月21日更新のコンテンツ |
つまり、サーバそのものは冗長化できていても、コンテンツが揃っていなければ、表示内容は冗長化されていない ということです。
単一サーバ構成であれば、1台にアップロードすればそれで済みました。
しかし、冗長化構成では、複数のサーバに対して同じコンテンツを反映しなければなりません。
2台程度であれば手作業でも対応できるかもしれませんが、サーバ台数が増えれば、そのぶん更新作業も増え、運用負荷やミスの可能性も高くなります。
そこで必要になるのが、コンテンツの同期 です。
コンテンツの同期方法を考える
コンテンツを同期する方法はいくつかあります。
ここでは、代表的な方法として
- rsync を利用した同期
- NFS を利用した同期
- オブジェクトストレージの活用
の3つを見ていきます。
rsyncを利用したコンテンツの同期
同期方法として、まず思い浮かびやすいのが rsync を利用した方法です。
同期方法として、まず思い浮かびやすいのが rsync を利用した方法です。
たとえば、サーバAを更新元として、定期的に rsync を実行し、サーバAのコンテンツをサーバBへ転送する構成が考えられます。
この方法であれば、更新作業は基本的にサーバAだけで行えばよく、運用をある程度シンプルにできます。
比較的導入しやすく、既存環境にも組み込みやすいため、まず最初の同期方法として検討しやすい構成です。
ただし、rsync にはいくつか注意点があります。
1つ目は、更新した瞬間に必ず全サーバへ反映されるわけではない 点です。同期の実行間隔によっては、サーバAには新しいコンテンツがあり、サーバBには古いコンテンツが残る時間が発生します。
その間、ロードバランサはどちらのサーバも「正常」と判断するため、アクセスしたユーザーによって表示される内容が変わる可能性があります。
2つ目は、同期処理そのものが失敗する可能性がある 点です。
サーバ自体は正常に動作していても、同期だけが失敗していれば、運用者が気づかないままコンテンツ差分が残ってしまうことがあります。
そのため、rsync を使う場合は、
- 更新元サーバを明確に決めること
- 同期結果を確認できること
- 同期エラーを検知できること
まで含めて設計しておくことが重要です。
こうした「反映タイミングのずれ」や「同期失敗時の確認」といった課題を解消しやすいのが、次に紹介する NFS です。
NFSを利用した同期
こうした「コピーのタイミング差」を避けやすい方法として、NFS（Network File System） の利用があります。
NFS は、その名の通り、ネットワーク経由で利用できるファイルシステムです。
各Webサーバから同じ NFS 領域を参照するように構成すれば、コンテンツの実体は1つになり、サーバAで作業してもサーバBで作業しても、同じ内容を表示できます。
つまり、rsync のように「更新後に別サーバへコピーする」のではなく、最初から全サーバが同じコンテンツ領域を見る 形になります。
この構成の大きなメリットは、複数台構成でもコンテンツ差分が発生しにくいことです。
更新作業を行うサーバを強く意識しなくても、共通領域を更新すれば、その内容が各サーバから参照されます。
ただし、注意点もあります。
NFS で共通化できるのは、あくまで NFS に切り出した領域だけ です。
そのため、
- どのディレクトリを共有対象にするのか
- どこまでを共通化するのか
- サーバごとに個別管理すべき設定は何か
を事前に整理しておく必要があります。
「サーバ全体を完全に同期する」ための仕組みではない、という点は押さえておきたいポイントです。
オブジェクトストレージを利用した同期
実は、先に紹介した「さくらのオブジェクトストレージ」も、マウントツールを利用することで、NFS に近い挙動を実現できる場合があります。
そのため、構成や用途によっては、コンテンツ配置先の候補として検討することもできます。
ただし、コンテンツ領域として利用する場合には注意が必要です。
別途サードパーティ製ツールを利用する前提になることや、さくらのクラウドで利用保証がない点は、あらかじめ確認しておくべきでしょう。
そのため、実運用に採用する際は、単に「使えるかどうか」だけでなく、
- サポート範囲
- 障害時の切り分け
- 運用保守のしやすさ
まで含めて判断するのがよさそうです。
さいごに
WEBサーバを冗長化する場合、サーバを複数台並べるだけでは十分ではありません。
各サーバで同じコンテンツを表示できるようにすること まで考えて、はじめて安定した冗長化構成になります。
構成としては、比較的シンプルに導入しやすい rsync、常に同じコンテンツを参照させやすい NFS、そして用途によってはオブジェクトストレージの活用も選択肢になります。
次回は、冗長化構成を考えるうえで欠かせない「データベースの冗長化」について、運用面も踏まえながら整理していきたいと思います。
最後までお読みいただき、ありがとうございます！
