2017年、このブログ(WordPress(Amazon EC2 + RDS))で対応してきたこと

Amazon Web Services Advent Calendar 2017に参加した記事です。

年末らしく今年1年でこのサイトの構成で対応したことを振り返りたいと思います。

2017年1月時点の構成

超シンプルなRoute53 + EC2 + RDSの構成でした。

2017年12月時点の構成

こうやって見ると今年は色々やってきました。

今年発生した問題、課題

4月 EC2インスタンスが到達不能になった

EC2インスタンスが到達不能になって復旧してMackerelで監視し始めた

EC2がリタイアされて、とりあえずとった行動がMackerelで外形監視したのか。
それはそれでいいんだけど、ここはAutoRecoveryですよね。

4月 NGINXで500と502のエラーが実は頻発していた

NGINXで500と502のエラーが実は頻発していたらしい

それでMackerelで外形監視をして気づいたのですが、500と502のエラーが頻発していたのですね。
ここで対応したのがphp-fpmのパラメータ変更。
マシにはなったものの、でもこれは正しくない対応でした。

5月 Nephila Clavataプラグインで画像をS3からの配信にしてみる

Nephila ClavataでWordPressの画像をS3から配信する

この時点でまだ、500,502エラーは発生し続けてたのですが、出来るところからやっていこうと思って、画像ファイルのS3対応をしてみましたね。

5月 AWS SummitiでWell-Architected フレームワークを聞いたので自アカウントの環境を評価してみた

AWS Well-Architected フレームワークによるクラウド ベスト プラクティスのセッションを聞いたので自アカウントの環境を確認してみる

原文を頼りにやってみたのと、知識が乏しくて今見ると勘違いしているところも多々見受けられます。
でも、これをやってみて、やらなきゃなと思いましたね。

7月 CloudFrontからの配信と常時SSL化

WordPressをAmazon CloudFrontで配信してついでにACM(AWS Certificate Manager)を使って常時SSL化する

ブログを読んでくれている友達からもエラーが多いという声を聞くようになって、前からやりたかったCloudFront配信をやりました。

これでけっこう落ち着いたように見えました。

7月 AMIイメージの自動取得

Amazon EC2のAMIイメージを自動取得して保持日数が過ぎたら削除

CloudFront経由でNephila Clavataプラグインが動かなくなったと思って(実は違う原因)プラグインをオフにして再び画像をEC2保存にしたのですね。
なのでバックアップを取らなくてはと思い、AWS Lambdaを使って自動化しました。

7月 EC2 Auto Recovery機能を設定

EC2 Auto Recovery機能を設定しておいた

この頃、Architect on AWSを受講しまして、聞きながらそのまま設定しました。
これで最初に発生したリタイア対策は多分大丈夫。

7月 サイトのステータスチェック実装

サイトのHTTPステータスを5分おきにチェックして200以外ならSlackに通知する

とりあえず外形監視をしてみて思ったのは、200か500か502だなと。
それしか見ないのならステータスだけ見ればいいかと思ってAWS Lambdaで自前で実装しました。

8月 EC2とRDSをリザーブドインスタンスに

リザーブドインスタンスはじめました

500と502は前に比べればだいぶ減ってきて、EC2もRDSもt2.smallからt2.microに落としても問題なさそうだったので、t2.microのリザーブドインスタンスを購入して節約。

8月 CloudWatch Logsでサーバーのログ監視

AWS CloudWatch LogsエージェントでAmazon EC2上のNginxのaccess.log , error.log , php-fpm error.log , Linuxのmessages , secureログを収集する

SSHログインしてログ見るの面倒だったので見てなかったのですね。
でも500と502が起こり続けてるままじゃいかんと思って、ログをCloudWatch Logsで見ることに。

8月 500と502はどうやらOut of memory

php-fpm で Out of memoryが発生した際にメール通知する(AWS CloudWatch , Amazon SNS)

ログを見始めた結果、Out of memoryが起こっているみたいなので、Amazon SNSでメール送信をやってみました。

8月 多分原因をつきとめたのでWAFで対応

WordPressのwp-login.php , xmlrpc.phpへのアクセスをAWS WAFで接続元IPアドレスを制限する

多分こういうことが起こっているので遮断しようと、WAFで対応しました。

xmlrpc.phpへの攻撃によりメモリが消費される

1時間にこれだけの攻撃があったのですね。

login.phpoへの不正アクセス対応

不正ログインもこれだけ試行されてたのですね。

最後に

コミュニティの運営やらせてもらったり、登壇させてもらったりしててというのもあるし、何よりもブログを見に来てくれた人たちに残念な思いをさせるのもいやだなと思い、今年は色々と対応してまいりました。

まだ何かと問題はあるかもしれませんが、今のところはおかげさまで安定しております。

来年も当ブログを見てもらえれば嬉しいなと思います。

では、良いお年を！！！

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。