■ 日記
1年間、軍儀のブラウザアプリを公開していた。（https://weblog.2410.dev/2025/01/hunterhunterweb.html）
ちょうどアニメの時期と重なったのか、公開して半年くらいたってから、毎日それなり（0~4ゲームくらい）の利用があったので、なんとなく満足していた。
しかしまあ2026年の2月で、AWSの無料期間が終了した。
無料期間といってもEC2が無料なだけでほかのAWSナントカカントカで毎月100円くらいかかっていたのだが、とにかく無料期間が終わり、月の使用料金が10$を超えた。
10ドル。事前に設定していた金額だ。設定どおり、EC2インスタンスが停止した。
大した利用者数でもないのに2週間たらずで停止したので、このままAWSを使い続けると毎月2000円以上かかるっぽい。
公開当時は1年の無料期間分で運営やめようかな～どうしようかな～とか言っていたんだけれど、ぽつぽつとメンテナンスを続けたり、利用者の様子を見たりしていると愛着がわいたというか、もうすこし続けてみるか、という気になってきた。
なので、別のサーバに移行することにした。
新居はConohaのVPSだ。32,476円/36カ月！ 試用期間もなく突然3年契約なんてしてよかったのか、お金を払ってから不安になってきた。
■ ConohaのVPS
「コンソール」からブラウザコンソールが立ち上がるので、Linuxの様子を適当に見る。ssh環境を整えたら、ブラウザコンソールは使いづらいので手元のターミナルからsshする。
「コンソール」からブラウザコンソールが立ち上がるので、Linuxの様子を適当に見る。
ssh環境を整えたら、ブラウザコンソールは使いづらいので手元のターミナルからsshする。
nginxをインストールして、/var/wwwとかにindex.htmlを設置して、配布されたIPアドレスにアクセス。
なにも取得できないというか、アクセスがコケることを確認する（なんか失敗した？）。
■ ドメイン紐づけ
$ ping gungi.2410.dev PING gungi.2410.dev (163.44.118.110) 56(84) bytes of data.
■ NGINX (HTTP)
EC2のnginx.confを持ってきてもうまく動かない。
あれ？と思ってデフォルトに戻したけどやっぱり動かない。
$ sudo systemctl restart nginx
で動くんじゃなかったの？
$ curl 163.44.118.110 curl: (7) Failed to connect to 163.44.118.110 port 80 after 27 ms: Connection refused
pingも通らない。
$ nc -zv 163.44.118.110 80 nc: connect to 163.44.118.110 port 80 (tcp) failed: Connection refused
Conoha側では443番ポートも80番ポートも開けたつもりだし…。
ここを参考にしてみる。
https://webmanual.doc778.com/learning/development/11647
ufwでファイアウォールを確認
$ sudo ufw status Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)
sshしか通してないじゃん！
80番ポートを開ける。
$ sudo ufw default deny incoming \ && sudo ufw default allow outgoing \ && sudo ufw allow 22/tcp \ && sudo ufw allow 80/tcp \ && sudo ufw enable \ && sudo ufw status verbose
$ sudo ufw status Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 22/tcp (v6) ALLOW Anywhere (v6) 80/tcp (v6) ALLOW Anywhere (v6)
/etc/nginx/nginx.confに、httpの設定を追加して、curlが成功した。
■ SSL証明書発行
https://qiita.com/Kuroi_Cc/items/ec2e9b9e20b268f0d155
nginx.confのhttp部分に
location /.well-known/acme-challenge/ {
root /usr/share/nginx/html/_letsencrypt;
}を追加。
server {
listen 80;
server_name gungi.2410.dev;
root /var/www/nginx;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location /.well-known/acme-challenge/ {
root /usr/share/nginx/html/_letsencrypt;
}
}
$ sudo nginx -tでnginx.confに問題がないか確認する。
$ sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
successfulが出ている。
nginxを再起動。
$ sudo systemctl restart nginx
準備ができたはずなので、certbotを実行する。
certbotでのSSL証明書更新には回数制限だかなにかがあるので、--dry-runオプションをつけて問題がないか確認する。
$ sudo certbot certonly --webroot --dry-run : space separated) (Enter 'c' to cancel): gungi.2410.dev Simulating a certificate request for gungi.2410.dev Input the webroot for gungi.2410.dev: (Enter 'c' to cancel): _letsencrypt Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems: Domain: gungi.2410.dev Type: unauthorized Detail: 163.44.118.110: Invalid response from http://gungi.2410.dev/.well-known/acme-challenge/XXXXXXXX_XXXXXXXX: 404 Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet. Some challenges have failed. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
certbotの実行に失敗した。
あれ？？
参考サイトを再度確認し、nginx.confのserver{以下をコピペしなおして見返す。
location /.well-known/acme-challenge/ {
root /usr/share/nginx/html/_letsencrypt;
}
ここのlocationは自分の環境に合わせて修正しないといけなかった。
今回は/var/www以下で公開しているので、root /var/www....に修正。
$ sudo certbot certonly --webroot --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
:
space separated) (Enter 'c' to cancel): gungi.2410.dev
Simulating a certificate request for gungi.2410.dev
Input the webroot for gungi.2410.dev: (Enter 'c' to cancel): _letsencrypt
The dry run was successful.
certbotの--dry-runに成功した。--dry-runを外して、正式に実行する。
メールアドレスがどうとか、規約に同意を求められたりするので指示に従う。
Successfullyと表示されて無事更新に成功した。
■ NGINX (HTTPS)
SSL証明書の発行が完了したので、nginx.confを書き換えてhttpsに対応できるようにする。
証明書の手続きを行わないままだと、以降元からnginxをコピペしてもうまくいかない。
http通信はhttpsにリダイレクトする設定にしていたので、動作確認などでロックが発生した。(http通信じゃないと動作確認できない → http通信はhttpsにリダイレクトする → 証明書がないのでhttps通信ができない → 当然http通信も止まる)
でもcertbot実行成功後、ふと疑問に思ったけど、certbotは80番ポートでhttp通信しないといけないはずだから、nginx.confをコピペしただけで動くべきなのでは……？
ロックじゃなくてファイアウォールの問題だったのかもしれない。
EC2で動かしていたnginxのconfファイルをコピペして$ sudo nginx -t。
正常に動きそうだということを確認して、$ sudo systemctl restart nginxできた。
しかしhttpsでアクセスしようとするとブラウザでは「接続がタイムアウトしました」が表示されてサーバにアクセスできない。
■ ファイアウォール
上記のuwsの設定だと、443portを開放していなかった。
EC2でどのように設定していたか確認する。
EC2@$ sudo ufw status
Status: active
To Action From
-- ------ ----
Nginx HTTP ALLOW Anywhere
Nginx HTTPS ALLOW Anywhere
22 LIMIT Anywhere
Nginx HTTP (v6) ALLOW Anywhere (v6)
Nginx HTTPS (v6) ALLOW Anywhere (v6)
22 (v6) LIMIT Anywhere (v6)
なんだっけコレ。
EC2のとき参考にした記事 https://qiita.com/shimakaze_soft/items/c3cce2bfb7d584e1fbceを確認。
$ sudo ufw default DENY
$ sudo ufw allow 22
$ sudo ufw limit 22
sshが途中で切れてもいいように22番portの設定。
不要な設定が残っているので、$ sudo ufw delete <rule number>
で重複したり邪魔なルールを削除する。
きれいになったら、引き続き記事を参考にファイアウォールの設定を行う。
$ sudo ufw allow 'Nginx HTTP'
$ sudo ufw allow 'Nginx HTTPS'
$ sudo ufw status
Status: active
To Action From
-- ------ ----
22 LIMIT Anywhere
Nginx HTTP ALLOW Anywhere
Nginx HTTPS ALLOW Anywhere
22 (v6) LIMIT Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
Nginx HTTPS (v6) ALLOW Anywhere (v6)
EC2環境と同じufw設定になった。
■ HTTPS接続ができない？
$ curl https://gungi.2410.dev
curl: (56) OpenSSL SSL_read: error:0A000126:SSL routines::unexpected eof while reading, errno 0
ファイアウォールにはじかれることはなくなったが、SSLエラーが出ている。
慌てずにnginxを再起動したが効果なし。
そういえばUser-Agentに制限をかけていたんだっけ？
curlをやめてブラウザでアクセスしたけどこれも失敗。
あれ？ certbotは成功したんだけど……？--dry-runを再度実行する。「すでに有効な証明書を発行済みだよ！」というメッセージが出ることを期待したが、なぜか何事もないかのようにdry-runに成功してしまった。/etc/letsencrypt/live/gungi.2410.dev/以下には、さっき作った証明書が保存されているようだが……？
$openssl version
@ec2$ openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
sslのバージョンは同じ。
$ nginx -v
nginx version: nginx/1.24.0 (Ubuntu)
nginxのバージョンも同じ
ガチャガチャやっていたら、いつの間にかブラウザでのアクセスに成功するようになった。
なんだったんだろう。
特に何もしてない気がするから、キャッシュかなんか引っかかって、時間で解決したのかな……？
ひとまずWebサーバのhttps公開に成功したので、コンテンツを移管する。
■ Websocketサーバ実行環境構築
pythonバージョンの一致確認
$ python3 --version
Python 3.12.3
$ sudo apt install pip
$ python3 -m pip install websockets --break-system-packages
$ python3 -m pip install aioconsole --break-system-packages
■ 検索エンジン最適化（SEO）
AWSのメールを見る限り、2026年の2月20日にインスタンスが止まったっぽい。
ただ、利用者が2月16日以降いないみたいだったから、そのあたりからアクセスに問題があったのではないかと思っている。（たんに利用者がいなくなっただけの可能性もあるが……）
復旧を始めたのが2/23の23時ころで、DNSとか待ったりして、復旧が完了したのが2月25日の1時15分頃。
2月22日時点では「軍儀 web」で検索結果TOPだったのだが、25日時点ではもうgoogleの検索結果から除外されている。
最適化とかは面倒だから、ただ、「表示されなくなっちゃったあ」って言ってるだけなんだけど……。
これも1日くらい待ったら、また検索結果にちょっと出るようになった。
■ サーバの終活
ゲームログ抽出
githubにおいてないファイルの確認（機密情報とか載ってたり、適当に作ったデバッグ用プログラムとかメモtxt）
もう自分で何設定したかわかんないから、新しいサーバの様子見て問題なく動いてそうなら消しちゃっていいことにしようかな。
とりあえずEC2インスタンスは停止して、必要な時だけ起動する形にする。
移行のためにインスタンス再起動させてたけど、実働4~6時間くらいのはずなのに0.6$のコストがかかってるっぽい。すごいぜ。
インスタンス立ててなくても、Route53とか固定IPに？？？固定費用が掛かるはずだから、2カ月くらいで完全に削除したいね。2か月後の自分に期待。
■ EC2とConoha VPSの比較
@EC2 $ free -h -s 10| awk '{ print strftime("%Y/%m/%d %H:%M:%S"), $0 }'
2026/02/25 02:21:08 total used free shared buff/cache available
2026/02/25 02:21:08 Mem: 957Mi 373Mi 165Mi 908Ki 594Mi 583Mi
2026/02/25 02:21:08 Swap: 0B 0B 0B
@EC2 $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st gu
2 0 0 169604 47824 560644 0 0 104 122 60 0 0 0 83 0 16 0
Conoha VPS (2GB)
$ free -h -s 10| awk '{ print strftime("%Y/%m/%d %H:%M:%S"), $0 }'
2026/02/25 02:20:58 total used free shared buff/cache available
2026/02/25 02:20:58 Mem: 1.9Gi 382Mi 926Mi 1.1Mi 828Mi 1.5Gi
2026/02/25 02:20:58 Swap: 2.0Gi 0B 2.0Gi
$ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st gu
1 0 0 948648 47340 801088 0 0 42 54 326 0 0 0 100 0 0 0
Conohaはこれで月1000円くらいらしい。
利用者規模的にはもっと小さいサイズでもよかったかも。
冷静に考えると、お金払いたくないなあってEC2の無料プランにしたのに、結局月1000円払うのか……なぜ……？
AWSで続けていたら4倍くらいはかかっていただろうと思うとまあいいのかな……？
コメント
コメントを投稿