タグ: WebARENA

VPSをWebArena→XServerへと切り替えたときのメモ。

2024年9月から利用してきた WebARENA VPS を XServer VPS に切り替えました。
理由は大きく分けて以下の3点です。

1. 物理的リソースの逼迫

旧環境では、以下のアプリが同時稼働していました。

この構成ではメモリ使用量が常に高止まりし、スワップ発生も頻繁。
安定運用のためには、より余裕のある環境が必要でした。

2. キャンペーン終了によるコスト増

WebARENA VPS の 4GB プランはキャンペーン中であれば 月額約980円 と魅力的でしたが、
終了後は 月額約1,600円 に上昇。コスト面の優位性が失われました。

3. XServer VPS を選んだ理由

  • 既にこの WordPress をホストしている会社で信頼性が高い
  • 同価格帯でも メモリ6GB と余裕がある
  • NVMe SSD 搭載でストレージ速度が段違い
  • 年額契約でキャンペーン終了後も料金安定
  • 最終的にWebARENA 4GB プランより安くなる

サーバ移行のタイムライン

  • 8/03 : 契約、初期設定(UFW / fail2ban)
  • 8/04 : 負荷試験を兼ねて Growi 導入(Apache / MongoDB / Elasticsearch / Node)
  • 8/05 : MySQL 導入
  • 8/06 : ModSecurity 導入
  • 8/07 : PHP-FPM 導入、Wasabi 接続、Nextcloud・BookStack・Laravel アプリ移行
    • この時点で「Growiを削除しなくてもいける」と確信
  • 8/08 : Redmine 6.0 新規構築に挑戦 → DB移行でエラー
    • 方針転換し Redmine 5.1 を移植(公開用)
  • 8/09 : 残りの Redmine 2件も移行完了、DNS 切替、WebARENA 解約

結果: 7日間で全サービス移行完了。Growi 常駐のまま全サイトを載せられたのは想定外というか、嬉しすぎる誤算でした。

スペック比較

項目WebARENA(旧)XServer(新)変化
CPUXeon E3-12xx (2011年)AMD EPYC Milan (2021年)大幅性能向上
vCPUコア数4コア4コア同等
メモリ4GB6GB1.5倍
ストレージ80GB SSD150GB NVMe SSD約1.9倍+高速化
ネットワーク500Mbps100Mbps低下
月額料金約1,630円(終了後)1,439円(年額換算)安価

新環境のメモリ状況

free -h
               total        used        free      shared  buff/cache   available
Mem:           5.8Gi       2.1Gi       1.6Gi       121Mi       2.5Gi       3.6Gi
Swap:          2.0Gi       623Mi       1.4Gi

Growi(MongoDB + Elasticsearch + Node)常駐のままで 3.6GiB available
旧環境より明確に余裕があり、スワップも軽減。

感想と今後

  • 前払いの安心感:年額払いで価格変動リスクなし
  • サービス統合効果:VPSとレンタルサーバを同社で一元管理
  • 展望:Redmine 6.0 アップデート挑戦、または5.1での堅牢運用

個人的に、NWの転送速度をサーバのリソースで解決するパワープレイができたのが安心です。

『150日の亡霊』顛末記-Wasabiクラウドストレージの理解不足による重課金の罠-(長文)

概要

筆者は

  • AWS Lightsail → Web Arena Indigo
  • Wasabiクラウドストレージ

で、各種Webサービスを個人的に運用しています。これまで両者は安価で性能も満足いくものだったのですが
2024年11月~2025年3月に至るまで、Wasabiクラウドストレージの高額請求がありました。(解決は2025年4月)

今回、この失敗を記すことで自分と同じような状況に陥りそうな人への注意喚起並びに「こういう落とし穴もあるんだ」という参考にしていただければ幸いです。

時間がない人向けの要約

  1. Wasabiクラウドストレージの仕様を理解していなかったため通常の20倍以上の請求が届いた。
  2. 原因はクラウドストレージの超・超高頻度のファイル書き換え(削除&作成)が発生したため。
  3. この原因を作ったのはGrowi(MongoDB)とNextcloud
  4. これらサービスを停止したものの「最低保持期間ポリシー」の存在により、自動的に発生したファイル書き換えの分の課金が発生した。
  5. 完全解決に至るまでの合計請求額は5ヶ月で544.93$!(2025/04/16でのレート換算で77624.73円)
  6. 教訓
  • クラウドストレージの仕様(特に料金体系)は見ておくこと。
  • クラウドストレージはネットにあるSSDではない。
  • 相性のいい運用方法と相性最悪の運用方法がある。
  • 新しいWebサービスを稼働したらきちんと請求を見ること。
  • 「今まで大丈夫だったからと言って次も大丈夫」ではない。
  1. ビジネスでこれをやってたら請求額はこの数十倍も普通にあった。個人での失敗だからこそ「笑えない笑い話」で済んだ。

AWS Lightsail → WebARENAへの移行完了。

はじめに

個人的に用いているVPSのコンテンツを、AWS LightsailからWebARENAへと移行完了。

今までUbuntu 20.04で動いていたサーバがUbuntu 24.04へと変わったことにより、Ubuntu 20.04のEOL対応を済ませたという形。

それぞれが、URLもそのままに、バージョンが上がった状態で表示されているという形です。

移行のきっかけ

Ubuntu 20.04のEOLが近づいてきた

これが一番の理由。Lightsailを最初に使い始めた頃は2022年5月だったので、まだ余裕があったのですが、そこから2年も経つとさすがに対応するしかないという形。

Lightsailにそのままインスタンスを移行させても良かったのですが

円安によるLightsail利用料高騰

という立ちはだかる壁があり、

  • 4GB Memory
  • 80 GB SSD

をもう一つ作り維持して行くには結構辛いものがありました。その上、

IPv4アドレスに追加料金

という更に手痛い値上げも発表されます。

迫るEOLに維持費の高騰、それをどうにかするために選んだのがWebARENAです。

WebARENAに切り替えた理由

利用費の安さ

https://web.arena.ne.jp/indigo

2024/10/12現在、

  • 4vCPU
  • 4GB Memory
  • 80GB SSD

で月額1630円。(筆者がサインアップしたときは1年間有効のクーポン付きでした)

Lightsailの24USD/月より安価なのは魅力的でした。

キャリア運営による回線の安定。

今回はNextcloudを使うと決めているだけに、回線が安定しているキャリア(docomo)のvpsを利用しました。

移行が思ったよりスムーズだった理由

元からデータをクラウドストレージに保存していた

これが一番大きかったです。クラウドストレージWasabiをs3でマウントしていたために、他のサーバに画像を転送する必要すらありませんでした。

また、mysqldumpの転送も、同じようにs3経由で引っ張るだけです。

サービス構築のメモを最初に残していた

冒頭の外部サイトやこのブログに

  • うまくいった手順
  • ハマったこと
  • 失敗した理由

など書いていたのが助かりました。手順を基本的にコピペで済むように済ませていたのも自賛する点です。

事前検証

この検証のように、別サーバに移行することをやっていたのもまた助かりました。

今後

最小限構成でのLightsailの転用

とはいえ、「LightsailのDNS機能」が有用であるため、一番安いインスタンスを残しつつ他の用途に使っていきます。

WebARENA Indigo®のファイアウォール設定。

ufwとfail2banの前段に、vpsが備えているファイアウォールを挟ませることで、サーバの負荷を抑えます。

手順

管理画面にログインします。

ネットワーク管理>ファイアーウォールをクリック。

右上の「ファイアウォールの作成」をクリック。

  • ファイアウォール名:任意の名前
  • インバウンドルール
    • HTTP(80) IPアドレス→0.0.0.0 (全てのIPアドレスを許可)
    • HTTPS(443) IPアドレス→0.0.0.0 (全てのIPアドレスを許可)
    • Custom / TCP / 22 IPアドレス→0.0.0.0 (全てのIPアドレスを許可)

を設定します。これは基本的なWebサーバ用の設定なので、許可したいポートが他にあればそれに合わせます。

設定後、インスタンスへの適用→作成したインスタンスを選び、設定を保存します。

固定IPを持っていれば、SSHのIPアドレスを指定することで、それ以外のIPをシャットアウト可能です。

WebARENA Indigo®を利用したUbuntu 24.04サーバへの立ち上げ。

概要

Ubuntu 20.o4サーバのEOLが近づいてきたため、現時点でのUbuntu最新版LTSサーバのvpsを立ち上げたときの記録です。

選定したサービス:WebARENA Indigo®

https://web.arena.ne.jp/indigo

今回は国産vpsを選定です。

  • 円安の影響下でAWS Lightsailが高額になった
  • 回線キャリアが運営しているだけあってNWが安定(アップロードも500Mbps/ベストエフォート)
  • Lightsailと同じく月額課金のため安心

が選定理由です。

申し込みそのものは

  • サインイン
  • クレジットカード情報の入力
  • 携帯電話を利用した本人確認

で、アカウント作成後は

こんな形のダッシュボードができました。

ここからUbuntuサーバを立ち上げていくのですが、罠が待っていました。

Ubuntu24.04サーバの罠-rsa秘密鍵、再び-

上記ダッシュボードから

  1. サービス管理
  2. インスタンス管理
  3. SSH鍵

で鍵を作成後、

  1. インスタンス
  2. インスタンス作成

で、Ubuntu 24.04インスタンスを作成するとログインできません

過去にもこういう事例があったので、それに沿って対応します。

これと同じく、

(SSH-1アルゴリズムによるRSA認証が無効化されます)

に引っかかるので、

  1. Ubuntu 20.04でインスタンスを立ち上げる
  2. アクセスできるアカウントを作成する
  3. Ubuntu 22.04/24.04に対応した秘密鍵を作成する
  4. その上でUbuntuのアップグレードをする

回りくどい方法を採りました。

最初のインスタンスへのアクセス

  1. WebARENAのコンソールからSSH鍵を作ります。
    • SSH鍵の作成
    • SSH鍵名を入力して作成をクリック
    • ダウンロードされた秘密鍵を利用
  2. Ubuntu20.04でインスタンスを立ち上げます。
    • インスタンス管理>インスタンスに移動
    • イメージの選択「Ubuntu」>「Ubuntu20.04」を選択
    • 自分の運用に沿ったサイズを選択
    • SSH鍵は上記で作成したものを選択
    • インスタンス名は任意のものを入力
    • 「インスタンスの作成」をクリック
  3. インスタンスを起動します。OSがインストールされたら、「操作」から「インスタンスの起動」をクリックします。
    • AWSと違って、最初からグローバルのIPアドレスがアタッチされているのが利点です。
    • ドメインとDNS登録できる環境があれば、この時点で名前解決できるようにします。
  4. ターミナルクライアントソフトから、インポートされた秘密鍵を使ってアクセスします。
    • アクセス先:アタッチされたIPアドレス
    • ユーザー名:ubuntu
    • 秘密鍵を利用
    • パスワード:空白

Ubuntu 22.04以降に対応したアカウントの作成

  • root昇格
sudo su -

パスワードは設定されていないので空エンターです。

  • ユーザー作成
adduser hoge

hogeは任意のユーザー名です。その後、パスワードなどを設定していきます。

  • 作成したユーザーを管理者グループに入れる
usermod -G sudo hoge

hogeは自分が作成したユーザー名です。

  • 作成したユーザーに切り替え
su - hoge
  • ユーザー名確認
whoami

作成したユーザー名であることを確認します。

  • root昇格確認
sudo su -

パスワード入力後、作成したユーザーがrootに昇格できることを確認します。

  • 作成したユーザーに戻る
exit && whoami

作成したユーザーであることを確認します。

秘密鍵作成

  • edEd25519での秘密鍵作成
ssh-keygen -t ed25519

鍵の格納場所は初期値(/home/hoge/.ssh)なので空エンターです。特別な運用がない限りはパスワードを設定します。

  • 秘密鍵確認
cd .ssh && pwd

/home/hoge/.sshにいることを確認します。

  • ファイルの内容確認
ls -l
  1. id_ed25519
  2. id_ed25519.pub

の2つを確認します。

cat id_ed25519
cat id_ed25519.pub

とした上で内容をコピーし、ローカル環境に貼り付けて保管します。この、秘密鍵と公開鍵はサーバセキュリティの生命線です。管理と保管は厳密に行ってください。

  • サーバ上から秘密鍵を削除
rm id_ed25519

サーバにアクセスするための秘密鍵がサーバ上にあっては意味がありません。「ローカルに秘密鍵があることを再確認した上で」秘密鍵を削除します。

  • 公開鍵の名前と権限変更
mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys

公開鍵の名前をauthorized_keysに変更して、所有者のみがアクセスできるようにします。

ローカルPCからアクセスできることを確認します。

ターミナルクライアントソフトで

  • IPアドレス(設定していればドメイン名)
  • 作成したユーザー名とパスワード
  • ローカルに保管した秘密鍵

を用いてアクセスできることを確認します。

Ubuntuのアップグレード

Ubuntu 20.04から24.04まで上げるので、二段階に上げます。

また、OSの再インストールなので、休憩時間を一切挟まず、一気通貫で行ってください。

Ubuntu 20.04→22.04

  • root昇格
sudo su -

ここから全てroot権限で設定します。

  • パッケージの最新化とアップグレード前の再起動
apt update && apt upgrade && apt autoremove

パッケージを最新版にして不要パッケージを削除します。途中で不要パッケージを消すかを求められるので[y]で消去します。

reboot

再起動を行います。

  • 再ログインしてroot昇格
sudo su -
  • OSのアップグレード
do-release-upgrade

アップグレード中にプロンプトから質問されたこと

以下、主要な質問事項です。コメント(#の後)に概要を書いています。

Reading cache

Checking package manager

Continue running under SSH?

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

# SSHのポートを追加するか
# → y

Starting additional sshd 

To make recovery in case of failure easier, an additional sshd will 
be started on port '1022'. If anything goes wrong with the running 
ssh you can still connect to the additional one. 
If you run a firewall, you may need to temporarily open this port. As 
this is potentially dangerous it's not done automatically. You can 
open the port with e.g.: 
'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 

To continue please press [ENTER]

# 設定を変更するか
# → Enter

Do you want to start the upgrade?


4 packages are going to be removed. 85 new packages are going to be
installed. 555 packages are going to be upgraded.

You have to download a total of 247 M. This download will take about
49 seconds with a 40Mbit connection and about 6 minutes with a 5Mbit
connection.

Fetching and installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled.

 Continue [yN]  Details [d]

# アップグレード前の最終確認
# → y

There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you will     x
   x normally be prompted on each upgrade for the list of services you wish to restart.  You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being   x
   x asked questions on each library upgrade.                                                                                                                                                                                            x
   x                                                                                                                                                                                                                                     x
   x Restart services during package upgrades without asking?

# アップグレード時、各種サービスを再起動前にプロンプトでy/nを確認するか
# → 質問されるのがめんどいので yes

# この間、SSH等の設定変更を行うか訊いてきます。プロンプトの選択を変えずに先に進みました
# keep the local version currently installed

Remove obsolete packages? 

# 不要パッケージの削除
# → Yes

System upgrade is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.

Continue [yN]

# アップグレード完了後にリブートするか
# → y
  • 22.04へのアップグレードを確認

再起動後、再びアクセスします。

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

となっていればまずはアップグレード完了です。

Ubuntu 22.04 → 24.04

  • root昇格
sudo su -
  • OSのアップグレード
do-release-upgrade

途中のプロンプトはほぼ同じなので割愛。再起動後、

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

にて成功です。

初期ユーザーの無効化

WebARENAのコンソールで作成された初期ユーザーはパスワードがない状態なので、無効化します。

  • root昇格
sudo su -
  • 初期ユーザーのsshディレクトリに移動
cd /home/ubuntu/.ssh
  • 公開鍵退避
mv authorized_keys ../

以上、仕様によって「すぐに立ち上げ」というわけには行きませんでしたが、クラウドでUbuntu24.04サーバを立ち上げることができました。

Powered by WordPress & Theme by Anders Norén