WordpressをEC2で構築したときのAutoScaling環境におけるサーバ間コンテンツ同期について

Last updated at 2019-12-20Posted at 2019-12-20

対応にあたる経緯

業務で複数のサイトをEC2＋ALB＋RDSという構成で運用管理をしているのですが、構築されるサイトがとても多くなってきており、負荷が高くなってきた

今後も構築するサイトが増えていくことが想定されるなかで、特定のサイトでのスパイクがあった場合に他のサイトへも影響を与えてしまい、運用品質が悪くなってくることが想定された

今のインスタンスが死ぬと全サイトが一気に死ぬので、はっきり言ってちょーやばい状態だった

AutoScaling導入にあたり同期方法の考察

注意

下記は全て対応時に調査した参考サイトからの情報や自分で軽く検証してみて検討した結果です。
特定の条件下において検討した結果の考察となっているので、実際に自分のサイトへ導入するのは自己責任でお願いします

【不採用】Lsyncd+rsync

configファイル内部にIPアドレスを持つしかなさそう・・・だが、AutoScalingと相性悪いので不採用

【不採用】最新AMIを取得して入れ替え

コンテンツ反映がリアルタイム性に欠けるので、不採用

【不採用】EFSマウントして同期

期待されてたみたいだが、調べてみると遅いらしいので不採用

【不採用】s3fsとかgoofysとかでS3マウント

ベンチマークとってる記事とか結構あがってるがEFSマウントと同じようにやっぱり少し遅いみたいなので、不採用

【一部採用】aws s3 syncでの同期

調査するとCronとか仕込んで、起動時と定期実行で他のサーバへ同期を実行するこのパターンが多かった
この方法で検証したが、保持しているサイト数とコンテンツ数が多く、完了まで時間がかかることもあり、設定した 定期実行 の実行間隔で同期が完了できるかわからない
加えて、この方法はコマンド実行時のCPUへの負荷がやばりため、不採用
しかし、スケールアウトしたインスタンスの起動時のコンテンツ同期には利用するため一部採用

【採用】Lsyncd -> S3 -> Lambda -> System Manager(Run Command) -> aws cp or rm で変更のあったファイルのみ反映

Lsyncdでファイル更新・削除があった場合にS3へ該当ファイルを上書きアップロード
- Lsyncdもファイルアップロードの成功、失敗の可視性が悪いので、 lsyncd.log をDatadogに転送するか検討中
S3のオブジェクト作成 or 削除イベントを発生させ、Lambda起動
Lambdaにて、System Manager(Run Command)を実行し、成功、失敗が画面 or CloudWatch Logsでわかるように実装

はまったとこ

とりあえず既存インスタンス内部のコンテンツを全てS3にアップロードするだけで結構時間かかった・・・(これだけで２日くらいかかってる )
S3のオブジェクトからLambda起動してSystem Manager(Run Command)が動かない
- インスタンス自体がPublicサブネットで動作してるのでAutoScalingしてもパブリックサブネットで起動させながらも起動したインスタンスにはGIPがないためにインターネット疎通が取れないこともあり、実行してもどこにもログがでない＆タイムアウトしてるとかで原因がわかりにくすぎて辛かったｗ
- PrivateサブネットならNATゲートウェイあるからGIPは存在するので、Lambda自体の起動はそっちに変更して試したが、それでも動かず、、、
- VPCのPrivate Linkで s3,ssmのエンドポイント作って、ルートテーブルにも反映させてゴリゴリ試したらうまくいった

環境整備にあたりインストールしたモジュール

取り急ぎ、aws-cliは必要になりそうだったので、導入

# 新しめのaws-cliをインストールするためにPython3.x系をインストールしていく
$ sudo yum list installed | grep python

# 既存のPython2.6もアップデートしてみた
$ sudo yum update python python-* audit-libs-python libselinux-pythonlibsemanage-python libxml2-python newt-python policycoreutils-python rpm-python setools-libs-python

# ベースサーバがCentOSなので下記のRPMをインストール
$ sudo yum install -y https://centos6.iuscommunity.org/ius-release.rpm

# Python3.6系のインストール
$ sudo yum install -y python36 python36-debug python36-devel python36-gunicorn python36-idle python36-libs python36-lxml python36-mod_wsgi python36-pip python36-redis python36-setproctitle python36-setuptools python36-test python36-tkinter python-rpm-macros python-srpm-macros python3-rpm-macros

# シンボリックリンクはる
$ sudo ln -s /usr/bin/python3.6 /usr/bin/python3
$ sudo ln -s /usr/bin/pip3.6 /usr/bin/pip3

# これが必要らしいので実行したが、これをやるとインストールしたpipが動かなくなる 
$ sudo python3 -m ensurepip --upgrade

# だからインストールしなおす
$ sudo yum remove -y python36-pip
$ sudo yum install -y python36-pip

# 再実行
$ sudo python3 -m ensurepip --upgrade

# シンボリックリンクはる
$ sudo ln -s /usr/bin/pip3.6 /usr/bin/pip3
$ sudo python3 -m pip install --upgrade pip
$ sudo ln -s /usr/bin/pip3.6 /usr/bin/pip3

# キャッシュ？が残るらしいのでこれ叩く
$ hash -r
$ pip3 --version

# aws-cliインストール
$ sudo /usr/local/bin/pip3 install awscli
$ sudo /usr/local/bin/pip3 install awscli --upgrade
$ aws --version

# S3にアクセスできるか確認
$ aws s3 ls s3://prd-example.com-wp

# S3にコンテンツ同期する
$ sudo /usr/local/bin/aws s3 sync s3://prd-example.com-wp /var/www/html/

# SSM-Agentインストール　※今後のNoOpsでの運用のためにも
$ sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

# Linux インスタンスの SSM エージェント ログは以下の場所で確認できます。
$ sudo less /var/log/amazon/ssm/amazon-ssm-agent.log
$ sudo less /var/log/amazon/ssm/errors.log

参考サイト

※皆さまよりご提供いただいた情報のおかげです！ありがとうございますｍｍ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up