【AWS】rsync(lsyncd)によるサーバー間同期での冗長化はベストプラクティスではない？

はじめに

• Webサーバー2台をrsyncで同期して冗長化
• ALBでWebサーバーへのアクセスは振り分け
• Webサーバー1にデプロイするとWebサーバー2にも同期される

という設計を見たことがあり、自分もこの設計でインフラを構築したことがあるのですが、色々勉強して、この設計は悪いとまではいかないもののベストプラクティスではないのではないか？
という考えに変わりました。
共有です。

この構築の問題点

• rsync(lsyncd)の設定や動作状況確認が面倒、トラブルのもと
• デプロイ時にダウンタイムが生じる
• 同期の目的がgit管理されたソースコードと、ユーザーによって作られたgit管理されていないファイルの複製であるとするならば、前者はともかく後者の存在がかなり厄介
  • 片方向の同期(Webサーバー1→Webサーバー2へ同期される設定)だった場合、Webサーバー2にユーザーによって重要なファイルが作られてしまったら大変。ユーザーが次にアクセスした際にWebサーバー1を参照してしまうと……？
    • スティッキーセッション(ユーザーの参照先サーバーを一定期間固定する機能)で対応するのも限度がある。
  • 双方向同期設定はもっと厄介。

じゃあどうするの

• Webサーバー1とWebサーバー2は同期しない
• アプリケーションは要するに「同じソースコードがWebサーバー1でもWebサーバー2でも動けば良い」という設計にする。ユーザーが生成するファイルがサーバー内で永続化するような設計はよろしくない。永続化するならDBやS3へ。
• デプロイは2台に順次デプロイするような設定にする。CodeDeployでローリングデプロイ等の設定をすれば良い。
  • ダウンタイムも避けられます

まとめ

AWSの場合は「冗長化のためにrsyncを使う」という機会はかなり限られそう。少なくとも今の自分には思いつかないです。
何かご意見あればコメントください。

ではまた。