投稿者: odajun

前提としている環境

以下の環境からWebサーバとなるインスタンスのみを増強する手順について記録しておく

• すでにシングルインスタンスでWordPressを運用している
• DBはRDS、メディアファイルはS3に分離しインスタンス複製に影響を与えない状況
• オリジナルドメインを使用しすでにロードバランサーを使用している

既存インスタンスのAMI作成

既存のインスタンスの項目を右クリックし、イメージの作成を実施

イメージ名はすでにあるものと重複しなければ何でも良い。説明に日付など入れていつのイメージかわかるようにしておくと良さそう。

AMIからのインスタンス作成

EC2に左メニューの中からAMIを選び、先ほど作成したイメージを選択した状態で起動を実施

設定項目の中で注意すべきところは「インスタンス詳細の設定」という部分で、ネットワークは既存のインスタンスと同じ物を選び、サブネットは既存のインスタンスと異なるパブリックサブネットを選択。自動割当パブリックIPを有効にしておく

「タグの設定」でNameの値を割り当てておくと、作成したあとのインスタンス名として使用される

セキュリティグループは既存のインスタンスと同じものを設定しておく

起動後正常にログインできるかどうか確認する

ロードバランサーのターゲットグループに追加

EC2に左メニューの中から「ロードバランシング」項目中の「ターゲットグループ」を選択

既存のターゲットグループを選択した状態で、下部にある「ターゲット」のタブを開き、編集をクリック

作成したインスタンスの使用ポートを選択して追加する

モニタリングで「正常なホスト」の数が増えたことを確認する

動作確認

以下の作業を実施して、起動させた新しいインスタンスに異常がないかを確認する

• 新規に用意したインスタンスにアクセスログが流れるか
• 既存のインスタンス上のプロセスを停止してもサイトが正常に表示されるか
• 管理ページへのログインができるか
• メディアファイルは正常に読めるか
• 既存のインスタンス上のプロセスを止めた状態で記事投稿(下書き保存)したのち新規のインスタンス上のプロセスを停止、既存のインスタンス復帰したとき、投稿した記事が正常に読めるか

これでいざとなったらWebサーバだけ複製してリクエストに耐えるといったこともやりやすくなった。そろそろイベント関連の記事投稿し始めるかな。

移行理由

小さいインスタンス上で mysql も含めて稼働させていたが、mysql のプロセスがそれなりにリソースを食ってしまう状態だったので、分離して管理したほうが良いだろうというのがまず1点

# メモリ使用順にプロセスを並べてみると mysql が最初にきた
$ ps aux | sort -n -k 6 -r | head -n 1
 mysql     3917  0.0  5.5 747868 56248 ?        Sl   Feb03   0:30 /usr/libexec/mysql55/mysqld *****

また、冗長構成を検討したとき、インスタンス内にDBを持ってしまうとインスタンスの数だけDBも必要となり、しかもそれぞれを同期させなくてはならない。運用の手間もかかりやすくなってしまうので、DBをWordPressのインスタンスと分離して管理することで冗長化しやすく、それでいて運用コストも上がりにくい状態にする

RDS によるデータベース作成

AWS のサービスよりRDSを選び、データベースの作成を実施する。基本的にはMySQL5系の最新版を使用する感じで設定。設定内容の中で気にするところは今回はネットワークの設定

以下の設定項目は主要なところだけ抜粋したもの

セキュリティグループの設定修正

セキュリティグループの設定は、DBに設定したものはインバウンド/アウトバウンドともに 3306ポートを Webサーバインスタンスに設定されているセキュリティグループに許可する形で設定する。それ以外の接続は不要

また、Webサーバインスタンス側に設定されているセキュリティグループに対して、インバウンドのところに 3306ポートをDBのセキュリティグループに対して許可してあげる設定にする

サービスの停止

移行作業中に更新が走らないように php-fpm, nginx のプロセスを止める

$ sudo service nginx stop
 Stopping nginx:                                            [  OK  ]
$ sudo service php-fpm stop
 Stopping php-fpm-7.3:                                      [  OK  ]

DB 移行

ローカルのmysqlからデータを dump

$ mysqldump -u *** wordpress > mysqldump_wordpress.sql

RDSで用意したDBにつっこむ

mysql -h <DBのエンドポイント> -u *** wordpress < mysqldump_wordpress.sql

show tables などでテーブルが入った状態になっていることを確認しておく

wp-config.php 中のDBに関する以下の設定を新しいものに修正する

define('DB_NAME', 'wordperss');
define('DB_USER', '***');
define('DB_PASSWORD', '***');
define('DB_HOST', '***');

ローカルで動いているmysqlを停止する

$ sudo service mysqld stop
 Stopping mysqld:                                           [  OK  ]

サービス再開

php-fpm, nginx を再開させ、サイトが正常に動作するかどうかを確認する

$ sudo service php-fpm restart
 Stopping php-fpm-7.3:                                      [FAILED]
 Starting php-fpm-7.3:                                      [  OK  ]
$ sudo service nginx restart
 Stopping nginx:                                            [FAILED]
 Starting nginx:                                            [  OK  ]

自分の場合は以上の操作で問題なく動作した。

この状態でメモリを確認し、mysql に使うメモリについては削除されたことを確認

$ ps aux | sort -n -k 6 -r | head -n 10
 apache   10475  0.4  6.3 475792 64288 ?        S    00:10   0:01 php-fpm: pool www
 apache   10479  0.3  5.2 465596 52868 ?        S    00:11   0:01 php-fpm: pool www

メモリの全体の利用料については大きな変動はなしサイトを開いた状態だと大体7割ほどは常に使う状態になる

$ free -m
              total       used       free     shared    buffers     cached
 Mem:           985        711        274          0         95        414
 -/+ buffers/cache:        201        784
 Swap:            0          0          0

移行が済んだら途中で作成した dump ファイルなどはしっかり消しておくこと。

運営してたらいつの間にかサイトが死んでたのでその調査と対応について記録

仕事から帰宅してサイト確認してみると応答がなく、ssh ログインもできない状態だったので、いったんインスタンスを再起動

今一度サイト立ち上げを実施して諸々調査。起動してしばらく放置してるだけでみるみるメモリが減ってた。アクセスほぼなしで3分の2が使用済みか。

$ free -h
              total       used       free     shared    buffers     cached
 Mem:          985M       662M       323M        72K        25M       476M
 -/+ buffers/cache:       160M       824M
 Swap:           0B         0B         0B

メモリ消費量の多いプロセスを確認するとphp-fpmのプロセスが上位に来る

$ ps aux | sort -n -k 6 -r | head -n 10
 mysql     3917  0.0  5.0 616528 51456 pts/0    Sl   22:56   0:00 /usr/libexec/mysql55/mysqld ********
 apache    3656  0.0  3.8 378628 39344 ?        S    22:55   0:00 php-fpm: pool www
 apache    3657  0.0  3.4 446920 34964 ?        S    22:55   0:00 php-fpm: pool www
 apache    3658  0.0  1.4 355300 14236 ?        S    22:55   0:00 php-fpm: pool www
 root      3653  0.0  1.1 355148 11312 ?        Ss   22:55   0:00 php-fpm: master process (/etc/php-fpm.conf)
 apache    3982  0.0  0.9 355148  9864 ?        S    23:02   0:00 php-fpm: pool www
 apache    3659  0.0  0.9 355148  9864 ?        S    22:55   0:00 php-fpm: pool www
 apache    3655  0.0  0.9 355148  9864 ?        S    22:55   0:00 php-fpm: pool www
 root      3196  0.0  0.7 117896  7404 ?        Ss   22:13   0:00 sshd: joda [priv]
 nginx     3354  0.0  0.6  60992  6272 ?        S    22:14   0:00 nginx: worker process

swap領域を作るという事も考えたが、diskI/Oで料金取られることも考えると、一旦プロセス数を下げるといったスリム化をして対応したほうが良さそう。同時アクセスとかもそんなないやろうし。

設定変更したファイルは /etc/php-fpm-7.3.d/www.conf
変更差分は以下

 -pm.max_children = 50
 +pm.max_children = 5 # 最大稼働する子プロセスの削減

 -pm.start_servers = 5
 +pm.start_servers = 3 # 起動時に立ち上がるプロセス数の削減

 -pm.min_spare_servers = 5
 +pm.min_spare_servers = 2 # 暇なときに立ち上げるプロセスの最小値

 -pm.max_spare_servers = 35
 +pm.max_spare_servers = 3 # 暇なときに立ち上げるプロセスの最大値

上記変更をして php-fpm 再起動したあとのメモリ利用上位確認

$ ps aux | sort -n -k 6 -r | head -n 10
 mysql     3917  0.0  5.3 747864 53636 pts/0    Sl   22:56   0:01 /usr/libexec/mysql55/mysqld ********
 apache    4184  0.2  5.0 463572 51152 ?        S    23:36   0:02 php-fpm: pool www
 apache    4218  0.2  4.8 461480 48660 ?        S    23:46   0:00 php-fpm: pool www
 apache    4228  0.4  2.8 368208 28996 ?        S    23:51   0:00 php-fpm: pool www
 root      4135  0.0  1.1 355096 11232 ?        Ss   23:30   0:00 php-fpm: master process (/etc/php-fpm.conf)
 root      3196  0.0  0.7 117896  7404 ?        Ss   22:13   0:00 sshd: ***
 nginx     3354  0.0  0.6  60992  6272 ?        S    22:14   0:00 nginx: worker process
 ntp       2749  0.0  0.5 116436  5496 ?        Ssl  22:13   0:00 ntpd ***
 joda      3212  0.0  0.4 118028  4576 ?        S    22:13   0:00 sshd: ***
 root      3033  0.0  0.4  89556  4468 ?        Ss   22:13   0:00 sendmail: ***

起動している php-fpm のプロセス数が減っていることを確認

この作業をしても誰かがサイトを訪れていると使用中のメモリが結構上がるのでまだ別の対応が必要と思われる。以下はこの投稿の編集中のメモリの様子

$ free -h
              total       used       free     shared    buffers     cached
 Mem:          985M       708M       277M        72K        29M       481M
 -/+ buffers/cache:       197M       788M
 Swap:           0B         0B         0B

mysql の外出しとか、分散とかいりそうやなぁ。。。

自分が実施した設定変更に関するメモ

sudo vim /etc/nginx/conf.d/wordpres.conf
・・・・・・
  location / {
     index index.php index.html;
     try_files $uri $uri/ /index.php?$args; <---- これを追加
   }
・・・・・・

今までのURLが パラメータ含んだもので、GoogleSearchConsole からも辿れない状態になっていた(たぶん)

変更前： https://talesof.odajun.work/?p=xxx
変更後： https://talesof.odajun.work/YYYY/MM/DD/sample-post/ 

EC2インスタンスにて実施したこと

サイトのために使用しているEC2インスタンスに対して、とりあえず以下の作業を実施したよというメモ

実施項目

• 新規管理用アカウント作成
• デフォルトアカウント(ec2-user)の削除
• port22 以外での ssh port 用意
• port22 の閉鎖
• 一部の海外からのアクセス拒否

参考

• https://itneko.com/linux-ssh-port/
• https://itneko.com/ec2-user-delete/
• https://programming-beginner-zeroichi.jp/articles/125

WordPress Plugin

インストール・設定した項目

• All In One WP Security & Firewall

項目一つ一つ確認して、必要と思われる項目についてチェックつけて実施している

参考

• https://www.kagoya.jp/howto/wordpress/all-in-one-wp-security/

自身のサイトのSSL対応が思いのほか手間取ったので、その時の作業手順について記録しておく(2020/01/22 時点の作業記録)

作業開始時点の状況

以下のことができている状態からスタートしています

• AWS EC2 でのインスタンス作成済み(1インスタンス)
• WordPress でサイトの構築済み(投稿記事5程度)
• 独自ドメインの取得・移行済み
• GoogleAnalyst 導入済み
• 環境
  • Amazon Linux AMI 2018.03
  • Nginx 1:1.14.1-2.34.amzn1
  • WordPress 5.3.2

上記の状態で特にロードバランサーや証明書などは用意していない状態から以下に示す手順で作業を実施

証明書の発行

証明書発行手順

まずはAWSのサービス中にある「 Certificate Manager 」から証明書の発行を実施します。「証明書のプロビジョニング」をクリック

「パブリック証明書のリクエスト」を選択して「証明書のリクエスト」に進む

ドメイン名の追加の部分で独自ドメインとドメインの前にアスタリスクをつけたサブドメインに対応する形のものを入力して「次へ」をクリック

• 自身のケースの場合以下の2つ
  • odajun.work
  • *.odajun.work

検証方法の選択では、「DNSの検証」を選択して「次へ」をクリック

タグ名の入力では現時点で使用することはないので適当に入力。管理項目が増えてくるとタグの整理によって管理コストを抑えたりすることができると思われる。

確認画面で各入力内容が意図したものとなっていることを確認し「確定とリクエスト」をクリック

確定直後は各ドメインが検証中のステータスとなっている。ドメインの左にある三角ボタンを押して項目の expand 項目を表示させ、その中にある「Route53でレコードの作成」というのをクリックし、既存のホストゾーン中に対応するCNAMEレコードを作成する。これをドメインごとに実施する(検証中のまま続行のボタンを押しても同様の作業は実施できる)。

レコード作成後以下のように成功のステータスになる(数分時間を要する可能性あり)

ロードバランサーの作成

ロードバランサーを用いる理由

単独のEC2インスタンスに対してなぜロードバランサーが必要か？
ロードバランサーの役割は内包する機能にもよりますが、EC2のロードバランサーだと主に以下の3つの役割があるのだろうと思います。

1. HTTP(S)リスナー層とEC2インスタンス層の分離により、EC2インスタンスのメンテしやすさ向上
2. ロードバランサーからEC2インスタンスへのヘルスチェックを行い異常を検知・通知する
3. SSL終端をロードバランサーまでとする

購買サイトなどを運営する場合は、1, 2 の機能は重要度が高いと思いますが、自身のケースでは、3 の重要度が高い。もしも SSLの終端をEC2までとした場合、OpenSSL関連のパッケージのインストール、更新などをインスタンスで実施しなければなりません。脆弱性が見つかったときは最優先で実施しなければならず結構大変なので、小規模なサイトであればSSLの終端をロードバランサーまでとするのが運用コストから見ても良いと思います。

ロードバランサー作成手順

AWSのサービスからEC2を選び、EC2の項目からロードバランサーを選択

「ロードバランサーの作成」をクリック、ロードバランサーの種類から「HTTP, HTTPS」を選択

　ロードバランサーの設定にて、デフォルトから変更した入力内容は以下の通り

• 名前
  • lb-odajun-work (何でも良い)
• リスナー
  • 「リスナーの追加」のボタンをクリックし、HTTPSを選択する
  • ロードバランサーのポートは自動で443が入力される
• アベイラビリティゾーン
  • 作成済みのインスタンスを含んだVPCを選択し、表示されているアベイラビリティゾーンの2つ以上にチェックを入れる
  • アベイラビリティゾーンからパブリックサブネットを選択する

セキュリティ設定の構成にて、「ACMから証明書を選択する」を選び、証明書の名前に、前の手順で用意した証明書の名前が選ばれていることを確認する
また、セキュリティポリシーの選択はデフォルトのまま

セキュリティグループの設定では、「既存のセキュリティグループを選択する」を選び、対象のECインスタンスが含まれているセキュリティグループを選択する(画像撮り忘れた)

ルーティングの設定では、名前のところのみ lb-tar-group-odajun-work (何でも良い)と入力し、他の項目は変更しない

ターゲットの登録では、作成済みのインスタンスから、ポート80, 443の2つが登録された状態としておく

以上でロードバランサーに関する設定は完了

セキュリティグループの設定修正

自身の最初の作業においてこの部分が抜けており正常にアクセスできないとなったので忘れないようにかいておく。他のサイトにある手順に含まれていなかったりもしたので、自身のケースのみ必要だったのかもしれないが。。。

修正しない場合の状態について

1度目の作業を実施し終えた際にサイトが正常に見れない事がわかり、調査しているとロードバランサーのステータスが以下のようになっていた

リスナーとしてポート80を登録しているが、セキュリティグループの設定でポート80のインバウンドが許可されていないという状態だった
これをみてセキュリティグループの設定に手を入れていないことに気づいた

修正後のセキュリティグループ設定について

ロードバランサーにて設定したセキュリティグループのインバウンド設定、以下のようなHTTP:80, HTTPS:443 のリクエストを許可する内容となるように修正する

Aレコードにロードバランサーを割り当てる

AWSのサービスからRoute53を選び、ホストゾーン -> 独自ドメインのAレコードとクリック(このときAレコードに割り当てている IPアドレスを控えておくと、トラブルがあったときにすぐ戻せるので便利)
「エイリアス」が「いいえ」となっている状態から「はい」を選び、「エイリアス先」から作成したロードバランサーを選択

設定を保存したらサイトに http, https それぞれでアクセスし、ともに表示される状態であることを確認する。httpでは特に異常はなく、httpsでは表示崩れなどが発生している状態となっていれば想定通り。想定外の状態であれば、今までの設定について見直す

http から https へのリダイレクト

現状は http, https ともにアクセスでき、httpでアクセスされると http のままサイトが閲覧できる状態なので、httpでのアクセスが来た場合は、https にリダイレクトする設定を行う

wordpress.conf 中の location の上の行に以下の項目を追加し保存

$ sudo vim /etc/nginx/conf.d/wordpres.conf

server {
・・・・・・・・・・・・・・・・・
   if ($http_x_forwarded_proto = 'http'){
       return 301 https://$host$request_uri;
   }
   location / {
・・・・・・・・・・・・・・・・・
 }

nginx の再起動を実施

$ sudo service nginx restart

https は先程と同じく表示崩れを起こした状態で変わらず、http でリクエストすると、URLが https にかわり同じく表示崩れを起こした状態となっていれば想定通り

DB中の設定修正

独自ドメインへの移行時と同様に、DB中に http://で保存された設定があるのでこれを修正する

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'home';

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'siteurl';

SSL制限の設定追加

wp-config.php にSSLがonとなっているときは、管理画面の表示、サイトのログインは SSLを矯正する設定を追加する

$ sudo vim /var/www/html/wp-config.php

/* For HTTPS */
$_SERVER['HTTPS']='on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

/* define('ABSPATH', dirname(FILE) . '/'); よりも前の行に必ず設定する */

設定後は nginx の再起動を実施

$ sudo service nginx restart

ここまでの作業を実施した状態で https でサイトを確認すると、表示崩れなどは発生せず、管理画面にも問題なく遷移する状態となると思う(自身のケースではここまでで https リクエストについては問題なくできる状態となった)

Really Simple SSL の有効化

今までの作業と一部重複する機能でもあるが、抜け漏れのないようにプラグインを使用して SSL化を実施しておく

WordPress のプラグインから Really Simple SSL をインストールし有効化する
インストール時点で SSL化するに当たりなにか問題があれば、SSL化できない旨の表示が出る(画像撮り忘れた)

問題がなければ SSL化を実施する

この状態で自身のサイト情報で「接続が保護されている」といった表示が出て、Amazon から発行された証明書が使われている状態であれば問題なし

Google Analytics の設定修正

Google Analytics の設定では http を対象としていたため、これを https に書き換える

アナリティクスのページから「管理」-> 「プロパティ管理」とたどる

デフォルトURLを https に変更する

設定変更後、自身でサイトにアクセスした状態で、アナリティクスのリアルタイムのダッシュボードにおいて訪問中ユーザーがカウントされていることを確認できれば問題なし

おわりに

自身がSSL(https)対応としてまとめて実施した作業は以上です。
セキュリティという観点から見ればまだまだ実施しないといけないことはあるので、徐々に実施していこうと思います

作業をするに当たり他の方の作業記録とかを見たりしましたが、自身のケースとばっちり一致するようなケースはなく、とりあえずやってみてトラブったらそのときに調査といった手段しかなかったので少々難儀しました

この記録はわりと自身の備忘録として書いたので、参考にされる方がいた場合、必要な作業と微妙に異なるかもしれないのでお気をつけて。

参考

• https://zenlogic.jp/aossl/operation/setting-analytics/
• https://qiita.com/akashima/items/f507b2193cfab8988486
• https://dev.classmethod.jp/cloud/aws/benefit_elb_with_one_ec2/
• https://ja.wordpress.org/plugins/really-simple-ssl/
• https://www.kahouwanetemate.com/post-297/

いろいろ調べてる中で access log のタイムスタンプが日本時間になっていないことに気づいたので対応した。その時の作業について記録する

date コマンドを叩くと UTC となっており、22日0時頃に実施したにもかかわらず21日15時とか指しているのが確認できる

$ date
Tue Jan 21 15:28:36 UTC 2020

まずは /etc/localtime を Tokyo の物を指すように修正

$ sudo rm -f /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Jan 22 00:29 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

この修正を crond 似反映させるため再起動

$ sudo service crond status
crond (pid  2825) is running...
$ sudo service crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]

ハードウェアクロックの時刻も合わせて変更しておく

$ sudo vim  /etc/sysconfig/clock
$ cat  /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=false

nginx の再起動の実施

$ sudo service nginx restart

date コマンドの内容や、access log の内容を確認し、時間が調整されていることを確認する

$ date
Wed Jan 22 00:35:48 JST 2020

$ sudo tail /var/log/nginx/access.log
****************- - [22/Jan/2020:00:40:56 +0900] ************

参考： https://itneko.com/linux-nginx/