t2microにてwordpressを運用していたが、度々mysqlがダウンしていた話

wordpress運用環境

  • AWS t2micro
  • Server version: Apache/2.4.39 ()
  • mysql Ver 14.14 Distrib 5.7.26, for Linux (x86_64)
  • amazon linux

t2microのスペック

https://aws.amazon.com/jp/ec2/instance-types/

ダウン現象

 wordpressの記事更新をする際にメモリの使用量が1GBを超える
以下はインスタンスタイプをt2.xlargeにした際に検証を行い、topコマンドでモニタリングしたもの

top - 02:42:42 up 4 days, 16:52,  3 users,  load average: 0.20, 0.13, 0.05
Tasks: 140 total,   2 running,  89 sleeping,   0 stopped,   1 zombie
%Cpu(s):  8.8 us,  0.6 sy,  0.0 ni, 90.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 16424208 total, 13677544 free,  1198980 used,  1547684 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 14903952 avail Mem

間違った対応

2019-04-18 02:37:52 5604 [Note] InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
2019-04-18 02:37:54 5604 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-04-18 02:37:55 5604 [ERROR] Plugin 'InnoDB' init function returned error.
2019-04-18 02:37:55 5604 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-04-18 02:38:08 5604 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-04-18 02:38:08 5604 [ERROR] Aborting

上記のエラーを見て、innodb_buffer_pool_sizeがデフォルトの128.0Mでは足りないと判断を設定し、これを通常そのようにするらしい、「メモリの8割のサイズを設定する」というものにする

innodb_buffer_pool_size : InnoDBを使っている場合、どんな環境でも一番最初に設定しなければならない値。 バッファプールとは、データとインデックスがキャッシュされる領域だ。 これをできる限り大きくしておくことで、読み出しの処理をディスクからではなくメモリから行うことができるようになる。 一般的な値は、5-6GB(8GB RAMの場合)、20-25GB(32GB RAM)、100-120GB(128GB RAM)。

https://yakst.com/ja/posts/200

ただし、そもそもmysql処理にかかるメモリがインスタンスのメモリサイズをオーバーしていたことが原因だったので、これではmysqlダウンの現象解決にはならない
解決策はメモリを増やすか、swap領域を拡張する必要があったのではないかと考えた

スワップ領域を増やす方向で考える

スワップ領域とは

スワップ領域とは 使っていないメモリの内容を一時的にしまっておくための場所 です。

https://wa3.i-3-i.info/word1721.html

つまり、「メモリが足りないならHDに保存すればいいじゃない!」という話
ちなみにインスタンスのストレージは「EBS のみ」となっている

EBSとは

Amazon Elastic Block Store (Amazon EBS) は、AWS クラウド内で Amazon EC2 インスタンスと組み合わせて使用できる、永続的なブロックストレージボリュームです。コンポーネントに障害が発生した場合でも高い可用性と耐久性を提供できるように、各 Amazon EBS ボリュームはアベイラビリティーゾーン内で自動的にレプリケートされます。Amazon EBS ボリュームは、作業負荷の実行に必要な安定した低レイテンシーのパフォーマンスを提供します。Amazon EBS を使用すると、使用量の拡張または縮小を分単位で行うことができます。プロビジョニングしているサイズに合わせて、低料金でご利用いただけます。

https://aws.amazon.com/jp/ebs/

気になるお値段(というか課金体系)

EBS 汎用 SSD (gp2) ボリューム 汎用 SSD (gp2) ボリュームのボリュームストレージの料金はプロビジョニングした容量 (GB/月) で決まり、お客様がそのストレージを解放するまで毎月料金が発生します。gp2 ボリュームのプロビジョニング済みストレージは、1 秒ごとに課金されます (最小課金時間は 60 秒)。I/O はボリュームの料金に含まれているため、プロビジョニングした各ストレージの GB に対してのみ課金されます。

*プロビジョビングとは

プロビジョニングとは、必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくことです。供給や設備等の意味を表すプロビジョン(provision)という単語がもととなって派生した言葉です。

つまり使った分だけお値段が発生するってこと

今回の運用ではメモリのオーバー幅は500MBくらいなので、EBSにスワップ領域を確保してもそんなにお金はかからないと判断

念のためのシミュレーション結果

プロビジョニングされたストレージ 1 GB の月額料金が 0.12USD

https://aws.amazon.com/jp/ebs/pricing/?nc=sn&loc=3

だいたい0.06USD/月か オーライ

本当に落ちないのか検証する

今回のダウン騒動で、問題のインスタンスはサイズアップをしてしまったので検証はできず。。
なので個人でAWSでwordpress使って技術ブログでも運用してみるとする