Contents

1 さっそくWiresharkでの分析結果を見てみる
- 1.1 解析結果への理解
  - 1.1.1 ◆1回目の「Bad TCP」
  - 1.1.2 ◆2回目の「Bad TCP」
2 おしまいに

結論

サービスとして運用できるものではない。
　➡読み込みが長い＋WordPress上の画像ファイル破損。
パケット通信のやりとりで問題が発生しており、先の問題は個人努力では解決が難しい。

※ただし、WordPress専用のインスタンスなどに変更すれば可能。

作業環境

パブリックサブネットに作成した下記インスタンスに対し、TeratermでSSH接続しておこなう。
※踏み台は挟んでいないシンプルな構成
※マルチAZ運用も視野に入れてVPCを作成したが、それ以前の問題だった・・・

インスタンス

Amazon Linux 2 Kernel 5.10 AMI 2.0.20230418.0 x86_64 HVM gp2

セキュリティグループ

インバウンド

SSH (Port22
HTTP (Port80)
HTTPS (Port443)
すべての ICMP – IPv4 (Ping疎通用)

アウトバウンド

すべてのトラフィック

ネットワークACL

インバウンド/アウトバウンド

Allow ルール番号:100 SSH (Port22
Allow ルール番号:200 HTTP (Port80)
Allow ルール番号:300 HTTPS (Port443)
Allow ルール番号:400 すべての ICMP – IPv4 (Ping疎通用)
Deny すべてのトラフィック

設定するソフトウェア

Apache：Apache/2.4.56
PHP：7.4.33：Ver 8.0.33 for Linux on x86_64
MySQL：Ver 8.0.33 for Linux on x86_64
WordPress

問題にぶつかるまで

(‘Д’)ソフトウェアのインストールは省略します。(他サイトで多く記載のある方法のため)
　　　※MySQLは yum local installで問題なくできました♪
　　　※MariaDBも削除はしています

　　　　　　まずは必要なソフトウェアはインストール完了！

WordPressまでインストールしてIPからサイトにアクセスするとページは表示される。
一旦は問題なく表示されているが、再起動しても大丈夫だろうか・・・(停止→起動)

(‘_’) 30秒後
無事に表示されては、、、いなかった。右上の不審なアイコンがあるが、反応しない。
※テーマを変えた場合は表示されるハチドリの画像などはファイル破損のアイコンが表示された

トラブル対応開始！

以下、事象切り分けを含めて確認したこと。

①どの段階から発生しているのか区分けする

【1】別で新規インスタンスを構築し、同様にソフトウェアをインストール。
　（複雑な設定をしていなければ、セキュリティ面は同じものをアタッチ）

【2】 MySQLインストール完了まで、各ソフトウェアインストール完了のたびサイトにアクセス！（Apacheの画面が表示される）

【3】 WordPressのインストール完了➡問題なし
　インスタンスの停止→起動　　 ➡事象発生

➡WordPress処理で問題があることを確認

②デフォルト環境でセキュリティ面を中心にためしてみる

デフォルト環境はセキュリティ面がイン・アウトバウンド共にオープンなため通信プロトコルで弾かれてしまうことはないはず…
デフォルト環境でインスタンスを新規で作成した後、同様の作業を実施…

➡結果変わらず・・・(:3」∠)ｲﾂﾓｺｳﾀﾞﾖ･･･

➡環境、セキュリティ、または別リソースによる事象でもない。

③MySQLが怪しい

事象が発生してから検索を続けていた哀れ、カクヤ。
ただ調べても「WordPressのプラグインで爆速！」…まずコンソールに入れない。。。
そして何故かWordPressのオフィシャルサイトからも、垢がないと言われる始末。

ただ、よく考えたらMySQL上の処理の問題である。
ApacheもPHPも最新版だから、MySQL以外にありえないんだよっ！( ﾟДﾟ)迫真

◆リソース値を確認

　…というわけでまずはメモリの使用率を確認していく。
〇grep Mem /proc/meminfo

MemTotal: 975596 kB 搭載しているメモリの総量
MemFree: 179400 kB 空きメモリ量
MemAvailable: 322064 kB キャッシュなどを解放することで利用可能なメモリ量

〇grep Swap /proc/meminfo
　
SwapCached: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB

〇CloudWatchでCPU使用率を確認 ➡ 使用率 1.7% とひっ迫はしておらず、余裕はある様子。
　※2.0が上限値であれば負荷が高いということになるが…

〇topコマンドでリソースの変動を確認してみるが、過負荷は確認できない。

◆クエリキャッシュ機能
MySQLのコンフィグなどプライベートで触ることがなければ、業務上なんてもっての外！
/ etc / httpd / conf / にて、httpd ドットコンフファイルを参照するが……クエリキャッシュの記載がない( ﾟДﾟ)

調べていくと初期設定では記載されていないため、素人丸出しで下記を貼り付け。

#wait_timeout = 120
long_query_time = 1
query_cache_limit=8M
query_cache_type=1
query_cache_size=64M
innodb_buffer_pool_size=16M
#innodb_log_file_size=128M
#tmp_table_size=64M
#max_connections = 2500
#max_user_connections = 2500
#innodb_flush_method=O_DIRECT
#key_buffer_size=64M

これで良し。設定を反映させるためにMySQLを再起動すると…

＜省略＞
2023-04-24T05:14:13.904756Z 0 [ERROR] [MY-000067] [Server] unknown variable 'query_cache_limit=8M'.
2023-04-24T05:14:13.904816Z 0 [ERROR] [MY-010119] [Server] Aborting
2023-04-24T05:14:15.430367Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.33)  MySQL Community Server - GPL.

要約すると、「query_cache_limit=8M」なんか知りませんよ、とのことです。
泣く泣く「query_cache_limit=8M」をコメントアウトすると他の項目が次の標的になりました。
MySQL8ではクエリキャッシュ機能のサポートが終了しているようで、これまた赤っ恥(*ﾉωﾉ)

◆MySQLの旧バージョンをインストールしてみる
ならばタイムトラベルのように、クエリキャッシュ機能があった時に戻ればよい。
MYSQLの公式(https://dev.mysql.com/downloads/repo/yum/)から旧版をインストール。

すると、「ERROR 403: Forbidden.」または「Error: Nothing to do」とレスポンスあり。
状況として、旧版のMySQLがインストールできない。（個々に関しては別個調査が必要？）
（スクリーンショットでも取っておくべきでした）
wgetコマンドで実行しても結果には変化なく、調べた以上に術がMariaDBへの変更以外余儀なくされた。

◆MariaDBに切り替える
「sudo yum install -y mariadb mariadb-client」で意外なことにMariaDBはインストール完了
下記のようにインストール済みであることを確認できる。

mysql --version

mysql  Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1

「sudo service mysqld restart」でMySQLをいったん再起動すると・・・

Redirecting to /bin/systemctl restart mysqld.service
Failed to restart mysqld.service: Unit not found.

上記エラーに対して、ネットで検索していると下記のサイトにあたった。
＜参考サイト：https://terakoya.sejuku.net/question/detail/16854 ＞

同一の事象であり、記載通りの対応をしたところ下記エラーより私の方も解消しなかった。
サイトでは「SQLite」に乗り換えては？と記載があったが、問題がどんどん引き延ばされている感じが否めない。

Failed to restart mariadb.service: Unit not found.

➡CPUの問題でもなさそう。MySQL8の機能拡張はできず、代替となるDBの用意が望めない

④ApacheとMySQLのログを確認してみる

Apache：cd /var/log/ access_log , error_log
PHP：/var/log/php-fpm/error_log
MySQL：cd /var/log/mysqld.log

➡ログには本件のエラーを示すような出力はされていなかった。

⑤試しに「Index.html」を表示させる

WordPressがダメな時、一般的な「Index.html」が表示できるかどうかを試してみる。
これで遅延が発生すれば、WordPressが問題という考え自体が覆る。。。

➡数コンマ零ミリの速さで表示された。やはりWordPressでの処理がスポット。

運用に見切りをつけた判断

ここまで調査をしていると今までちらほらと目についてきた情報に信憑性が増してきた。
察しの良い方、またはメモリ使用率の段階で気が付き鼻で笑われているかもしれない。

単にサーバーのスペック面で運用に向いていないのではないだろうか。
CPU使用率に目を付けた時に参考にしたサイトでは、MySQLのクエリキャッシュを使えるようにしたら何とか早くなったが、CPUの使用率が爆上がりしたというファンキーな旧情報。
（参考：https://linuc.org/study/knowledge/529/）

オンラインスクール講師に確認して、実現性の低さを提示され、
「Lightsail,AMIMOTO AMI,Bitnami」の使用を提案されたこと。

また、冷静に考えれば原動力としたUdemyなどの講座はあくまで仕組みや操作・原理を伝授するものであり、それを運用に繋げて解釈したのは少々浅かったかもしれない。。。

さっそくWiresharkでの分析結果を見てみる

実際にwiresharkを使用したのは今回が初めてでした。
そのため、今回は付焼刃感満載の手際と解釈で確認を進めていきます。

今回、EC2インスタンスのIPは「52.194.245.9」です。
Wireshark上段のブランクスペースに、「ip.src == 52.194.245.9」と入力します。
すると、解析結果が指定したIPがやり取りした通信のみ表示されます。
結果、エラーがいくつか発生。

鉛色(黒?)のラインが「Bad TCP」で赤のラインが「TCP RST」、RSTはリセットの略語です。
今回着目すべき点は、「Bad TCP」、または前後の処理で何をしているか、になります。

ざっとですが見た感じ、二回（2セット×2回）「Bad TCP」が発生しているようです。
タイムフローに沿って並べて各処理について、理解を深めていきます。
（★注意：前述のように付け焼刃なため、解釈に誤りが混じっている可能性があります）
（★注意：参考程度に参照願います）

◆前提知識
SEQ：シーケンス番号。データ送信元が受信先に送る番号。送信元が発行したオーダ番号と類義。
ACK：アック番号。データ受信先が送信元に送る番号。受信先が発行した番号と類義。

解析結果への理解

＜参考サイト：https://milestone-of-se.nesuke.com/knowhow/wireshark/wireshark-tcp-error/ ＞

◆1回目の「Bad TCP」

①行番号：28
　Time：0.284209
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：[TCP Previous segment not captured] 443 → 51235 [PSH, ACK] Seq=8645 Ack=1118 Win=61824 Len=1420 [TCP segment of a reassembled PDU]

　意味：
ポート443 → 51235にて、
●[TCP Previous segment not captured]
パケットの Seq# (シーケンス番号) を見る限り、このパケットよりも一つ前に本来あるべきパケットが Wireshark からは見られない。

●TCP segment of a reassembled PDU
・TCPレベルでパケットをMSS（最大セグメントサイズ）で分割した
・PDU：データ通信において、あるプロトコル（通信規約）が扱うひとまとまりのデータの送受信単位のこと

➡途中でパケットの通信が途絶えてしまったことを意味する。
　（要約：シーケンス 8645ね～♪……何か忘れていないか？）

②行番号：29
　Time：0.284209
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：[TCP Out-Of-Order] 443 → 51235 [ACK] Seq=7225 Ack=1118 Win=61824 Len=1420 [TCP segment of a reassembled PDU]

　意味：[TCP Out-Of-Order]
Seq# が進んでおらず、かつ一番高い Seq# のパケットを受信してから 3 ms 以内にそれよりも低い Seq# のパケットにマークされている。
可能性として、NW 経路が(負荷分散などにより)異なるために本当に順番が入れ替わった。
または、Dup ACK を3回受信する前、かつ 3ms 以内にその ACK で要求しているパケットを受信した (再送されたのか遅れて来たのかは不明)

➡ACK1118内の複数シーケンスにて、Seq 8645が先に来ている。Seq 7225が遅れてしまっている状態。
　（要約：ケビン（シーケンス 7225）がいないぞ！）←映画、ホームアローン参照

③行番号：34
　Time：0.284349
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：51235 → 443 [ACK] Seq=1118 Ack=7225 Win=262656 Len=0 SLE=8645 SRE=10065

　意味：ポート51235 → 443にて、遅延していたSeq 7225を送っている。

（要約：ケビン（シーケンス 7225）！無事でよかったわ）←映画、ホームアローン参照

◆2回目の「Bad TCP」

④行番号：73
　Time：5.292659
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：[TCP ACKed unseen segment] 51235 → 443 [ACK] Seq=1118 Ack=58149 Win=262656 Len=0

　意味：[TCP ACKed unseen segment]
ポート51235 → 443にて、
直前までのパケットが見えていない（ロスしている）にも関わらず、「パケットを受信したよ！」という ACK だけ返っている状態。

（要約：58149をキャッチ！あれ・・・？どこに置けばいいの？キョロキョロ…）

⑤行番号：74
　Time：5.292669
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：443 → 51235 [FIN, ACK] Seq=58148 Ack=1118 Win=61824 Len=0

　意味：Seq 58148が今届いた。

（要約：シーケンス番号58148「遅れてごめんなさい！」　　シーケンス番号58149「・・・」）

⑥行番号：75
　Time：5.292687
　通信：自宅端末→AWS[52.194.245.9]
　メッセージ：[TCP Dup ACK 73#1] 51235 → 443 [ACK] Seq=1118 Ack=58149 Win=262656 Len=0
　
意味：[TCP Dup ACK 73#1]
Ack# (応答確認番号)のパケット (#1回目) が観測されたことを意味する。
これを何度も送る場合、 Seq# = 58149 のパケットが受信できていないため、再送要求をしている、と考えられる。

（要約：「シーケンス番号58149はどこじゃあ、我！」
　　　　　シーケンス番号58149「呼び出されちゃった！なんか唐突に怖い！」）

⑦行番号：76
　Time：20.061821
　通信：AWS[52.194.245.9]→自宅端末
　メッセージ：Encrypted Alert

　意味：パケットキャプチャ時に Encrypted Alert と表示される場合がある。これは ”Content Type:21 = Alert” によるものらしい。
TCP FIN の直前にある場合は大抵、TLS コネクションの終了を意味する『close_notify』だと思われる(暗号化されていて見えない)。

（要約：シーケンス番号58149「ここにいます～！（あどけない走り）」　）
（要約：迷子のシーケンスを確認しました！）

おしまいに

解析結果としてはエラーであるため、面倒極まりないですが日本固有の柔軟なサブカル性をあてて表現してみると、不思議と、何故か愛着が湧いてきました（笑）
閑話休題、パケット通信で遅延が発生していることはわかりました。
では、こちらを解消しようとすると通信各所にWiresharkなどの解析ツールを導入したりと、
マクロな対応になったりと、個人の努力では難しいようでした。
調べるならおそらく、行75～76と思われます。ここで15秒かかっているのでかなり臭います。
そのため、一旦はこの課題をクローズします。

知識不足もありましょうし、時間があれば根掘り葉掘り調べてみてもいいですが・・・
その前に転職したい。

ここまでお付き合いいただきありがとうございました。

和ノ華文庫

AWS無料利用枠でWordPressは運用できるか

結論