スモールビジネスのIT日誌

• (2021-02-10 10:26:57)

ハイスピード・プラントとは？

Apacheの代わりに「LiteSpeed」が使用されている。

表示速度が速くなるそうだ。

月額のコストはやや高くなるが、長期契約でスタンダードと同じ程度らしい。

なぜ、ハイスピード？

現在、スタンダードプランに加入しているが、現在のスピードに不満はない。

うちはWordPressのようなアクセスのたびに、ダイナミックに表示内容を計算するCMSはあまり使わないからだと思う。

しかし、ハイスピードプランでは「ownCloud」が使える、これはいいい。

現状、大きなファイルの受け渡しの場合、「Firestorage」のような外部サービスを利用しているが、リスクが高いし、長期間保管できない点が不便。

Firestorage の長期間保管に関しては有料会員になればよいが、年数回程度の利用では管理コストの方が高くつく。

移行のための条件やハードル

スタンダードからハイスピードへの移行で、条件や変更になるものは？


ロリポップの説明を要約すると、こんな感じ：

━━━━━━━━━━━━━
下位プランへ戻せない
━━━━━━━━━━━━━
とはいって、新規に下位プランに加入しなおせばいいのでは？


━━━━━━━━━━━━━
プラン変更に必要な時間
━━━━━━━━━━━━━
ほとんどの場合は数分～１日で完了
データ量やファイル数が非常に多い場合は数日。


━━━━━━━━━━━━━
停止するサービス
━━━━━━━━━━━━━
プラン変更処理中は以下のサービスが停止する。

・WEBサイトの表示
・FTPS/SSH/WebDAVなどの接続
・cronの実行
・アクセスログの取得
・ユーザー専用ページでの一部の操作


━━━━━━━━━━━━━
アップデートによる仕様変更
━━━━━━━━━━━━━
・サーバー番号
・FTPSサーバー
・各言語のパス
・SSHサーバー
・データベースのパスワード形式：「old_password形式」 → 「native_password形式」


・PHP7.3および7.4のみ利用できるようになり、PHP7.1は利用できなくなります。

・Perlのバージョンが5.10から5.30へ。
　また「/usr/bin/perl」のパスが利用できなくなる。

・Rubyのバージョンが2.6へ。

・Pythonのバージョンが3.7へ。

・.htaccess内のAllowやDenyといったIP制限などの構文の後ろにコメントアウトがついていると、エラーになる。

事前準備

phpは7.3に統一したい。ownCloudが現状、7.4をサポートしなため。

当社の場合、php5.6が残っているので、移行前にすべて、php7.3に変更しておく必要あり。

リスク

「サーバー番号」の変更。

これはWebサーバかな？メールサーバかな？それとも他の何かのサーバ？

普通に考えれば、現行のApacheサーバから、LiteSpeedサーバに、データをコピーするのだろうから、webサーバの番号が変化する。ということはそのIPアドレスも変化する。

ちょっと嫌な予感。

移行に必要な時間が「数分～数日」とかなり幅がある。これはデータコピーの時間ではなく、新しいIPアドレスに変化し、ネット内のDNSサーバに新アドレス(Aレコードなど)の浸透する時間なんだろと推測する。

しかし、「データ量やファイル数が非常に多い場合は数日」とも書いてあって、何の話だろう。これは説明ミスと解釈した。

うちの場合、ロリポップのDNSは使用せず、外部のレジストラでDNSの設定を行っている。

ロリポップのDNSを使用しない理由は
(1) 同じドメイン名で、独立したカートサーバをまったく別の場所に置いている
(2) SPF設定のため

なので、WebサーバのIPアドレスが変化すれば、WebサーバやMXサーバを個別に設定し直す必要がある。

これらはロリポップ非公認の設定で、どんなトラブルが発生するのか、クリアにイメージできない。メールとWebは短い時間でも止めたくないので、ここは悩みどころ。

元に戻せないので覚悟してやる

一番の心配は致命的トラブルが発生しても、「元に戻せない」点。

営業上のポリシーと思うが、なかなか心配である。

逆に自分がロリポップの立場なら、このポリシーは理解できる。

上位プランへの移行は収益的にもモチベーションはあるが、逆はない。

上下自由に動けるとしたら、その移行プログラムの開発でさえ大きな負担である。

さらに、ユーザーの中にはおもしろ半分に移行する人がいて、移行にはリスクやトラブルが伴うので、おもしろ半分の移行でサポート部隊に負荷をかけたくないという事情もあるだろう。

だから、最初から上位から下位への移行は認めないと、宣言していた方が安全だと思う。

移行する人はそれなりの覚悟を持ってやってほしいという意思表示とも思う。

あとデータベースの設置数制限など上位・下位の間で制限があるものがある点か。下位に戻すとき下位の設置制限を超えていたら物理的に戻せない。そのへんのプログラムも準備しておかねばならない点はたしかに面倒。