超高速WordPress仮想マシン「KUSANAGI」をご存じでしょうか？
先日、弊社グロリアのサイト(当ページが稼働しているサイト)を「KUSANAGI」に移行しました。
営業上「Webサイトが重要」かつ「表示スピードにお悩み」の場合、「KUSANAGI」への移行は絶大なるコストパフォーマンスを発揮できるかと思います！！
(むしろ、使わないと「もったいない」くらいです。)
弊社グロリアでも移行のご支援・ご対応が可能です！
お気軽にご相談ください。
移行のきっかけ
とあるセミナーに参加させていただいた時に「KUSANAGI」をご紹介いただき、存在を知りました。
KUSANAGIは、プライム・ストラテジーが開発、提供するWordPressなどのCMSを高速・セキュアに動作させるチュ…
エンジニアとしては「速さ」は「あこがれ」の存在。
しかし、元々「高速」をうたうWordPressテーマを利用しており、
また、サイトアクセス数もまだまだといった状況でしたので、導入検討はまだ先でよいかな・・・と思っていました。
そんな中「弊社サイトの強化」を目的として対応を開始したところ、
ありがたいことにアクセス数が右肩上がりの状況となってきました。
- AWS Lightsail を利用していたのですが、
CPU使用率が状況によって「持続可能なゾーン」を越えて「バースト可能ゾーン」に入るようになってきた
※「バースト可能ゾーン」を使い続けると、制限が課されます。
- AWS EC2も正式に「KUSANAGI」に対応している
- 調査したところ、WordPress移行作業は意外と簡単そう
- 「KUSANAGI」は商用サービスであり、セキュリティ対応などを含むメンテナンス面でも安心
- いちエンジニアとして「KUSANAGI」を触ってみたい！
ということで、現時点ではまだオーバースペックと思いつつも
「KUSANAGI」移行に向けたテストを行い、
問題ないと判断できましたので本番移行を実施しました！
※AWS Lightsailのスペックを上げる、という対応策も当然ありましたが。
今のサイトをWordPress超高速エンジンKUSANAGIに移行することを検討中。
AWSで構築、現WordPressのデータ移行まで概ね実験完了。問題点も大体理解。
さすがにしっかりとしたチェックなしにIPアドレスを切り替えることはしませんでしたが、手軽に確認できるクラウド環境ってやはりすごいですねぇ。。
— 石黒直樹@ITスペシャリスト (@gloria_limited) March 12, 2020
ココに「舞台裏」を書いて、それが舞台裏か？笑 というよく分からない話になりそうですが。 自分の備忘録も兼ねて、サイト構築の与太話を残しておきます。 少しマニアックなIT話になりますので、内容はご理解いただかなくとも全く問題ないです […]
かかるコスト
移行作業費
移行に伴う対応費用ですね。正直、内容によってピンキリかと思います。
「KUSANAGI」利用料(ランニング費用)
弊社は「KUSANAGI Business Edition」、CPU 1コアにてサーバを構築しましたので
3000円/月(税別) でした。
※法人の場合。個人ユースであれば無償で利用可のようです。
正しくは公式サイトをご確認ください。
サーバレンタル代(ランニング費用)
弊社は「AWS EC2」環境にて構築しました。
変動要素はありますが、おそらく3000円/月(税別)くらいの利用料となると思います。
※メモリ 2GB構成とし、ランニングコストをできるだけ抑えています。
その他、諸費用
基本的には既存サイトの運用費用と変更はないと想定されます。
(ドメイン費用、SSL証明書費用、その他 外部サービス利用料など)
移行した所感
環境構築は容易
「KUSANAGI」公式サイトにしっかりとした手順があるため(しかも日本語)、ある程度サーバ、Webの知識がある方なら容易に構築できるかと思います。
サーバ環境はAWS EC2を選択しましたが、AWS構築経験のある方であれば、サーバ構築もさほど難しくはないかと思います。
遅いサイトほど、コストメリット大
元々、弊社サイトはそこまで遅いサイトではありません。
(それなりに色々と仕込んでいるわりには、速いと思います。)
それもあってか、移行しても劇的(10倍速！とか)な効果はありませんでした。
しかし、移行することで間違いなく速くなりました。
(サーバスペックの向上の影響もあるかもしれませんが)
基本的には「現WordPressサイト」をそのまま「新KUSANAGI WordPressサイト」に移行する形になりますので、
コンテンツの多大な修正等が発生せず、手間コストが小さいです。
以下、Googleの「PageSpeed Insights」を使った、移行前後の計測結果です。
スコアがどうの、というよりは、ユーザの手元に画面が表示されるまでの速度が大事かと思っています。(赤矢印の部分)
※実施するたびにスコアは微妙に変わるため、ご参考程度です。
※「そもそもの部分」に改善の余地が多々あるのは認識していますが、この手の改善はキリがなく、現状では体感的に全く問題を感じないため未対応です。
「パソコン」環境での移行前後
＜移行前＞
＜移行後＞
「モバイル」環境での移行前後
＜移行前＞
＜移行後＞
元々「高速」なテーマを使っていたが、さらに速くなった
弊社サイトはWordPress有償テーマ「THE THOR(ザ・トール)」をベースにして構築しております。
当テーマ、元々「高速化」機能を備えており、他テーマに比べると高速なのは間違いないと感じております。
にもかかわらず、「KUSANAGI」に移行することで高速になりました。
とはいえ、移行作業は業務影響を考え、しっかりと対応する必要あり
いくら作業自体が比較的容易であるとは言え、予期せぬトラブル、失敗はありえます。
業務影響とかかるコストを考えつつ、対応する必要がありますね。(当然ですが。)
(おまけ)今回の移行全体像
そんなに複雑なサイト構成ではありませんが、当然本番運用しているサーバの移行でしたので少し神経を使いました。
今回の移行におけるポイントは下記となります。
- KUSANAGIは新サーバとして構築し、そこで稼働確認をした後、本番リリースする。
- 本番切替はDNSのAレコード(IPアドレス)を切り換えることで実施
- 移行作業中は、作業端末のみhostsを利用して新サーバに接続
全体像は下記となります。(手書きですいません・・・)
(おまけ)「KUSANAGI」への移行作業メモ
隠しておくノウハウでもないので(笑)、弊社サイトを移行した時の手順を残しておきます。
KUSANAGIへの移行をご検討されている方、ご参考くださいませ。
(「ノウハウ」というのはこういう「作業」ではなくて、業務として万全を期して移行できる設計が組めるか、の方なのですよね。)
1. AWSにてKUSANAGI環境構築
KUSANAGI公式手順に従って構築ください。
KUSANAGI 9 for AWS / KUSA ... Read more…
AWSで構築するポイントは以下です。
- EC2 インスタンスタイプは「t2.medium(メモリ4GiB)」と記載がありますが、スペックはよくお考えください。
(利用料節約のため、一旦は2GiBで構築しました。弊社においては、現状問題は起きておりません。) - VPC(ネットワーク)の適切な設定も必要です。グローバルな固定IPをアタッチし、EC2に接続できるようにしてください。
- KUSANAGIサーバへのログインアカウントは「centos」です。
2. KUSANAGIの初期設定
こちらも、KUSANAGI公式手順に従って構築してください。
手順に関連するポイントは以下です。
- 「NGINX ＋ PHP7 ＋ MariaDB」の環境が個人的には安心感があります。
- 設定したパスワードは忘れないようにしましょう。
3. KUSANAGI プロビジョニング
こちらも、KUSANAGI公式手順に従って構築してください。
手順に関連するポイントは以下です。
- Let’s Encryptを利用したサーバ証明書を作成しますが、この時点では構築中のEC2に向けてドメイン接続していません。
(現行本番機にドメインは接続している。弊社の例だと、gloria.cool のアドレス先は現行本番機)
そのため、Let’s Encryptの登録はこの時点では不要です。
(ドメイン認証を行ってもエラーとなります。この場合でも無視して先に進んでOKです。)
4. WordPressのインストール
ドメインで新EC2 KUSANAGIに接続できればよいのですが、現行が本番であるためできません。
しかし、IPアドレス直打ちアクセスだとWordPress管理者画面にアクセスできませんので、作業端末(今回はMac)のhostsにて名前解決させます。
(IPアドレス直打ちでブラウザからアクセスしても、nginxの画面が表示されるだけとなります。)
#【Macで作業】 # ターミナル.app で作業 sudo vim /private/etc/hosts # hostsに以下を追記 # ファイル末尾でOK EC2のグローバルIPアドレス ドメイン名 # 弊社の場合ですと以下を追記 18.178.15.49 gloria.cool # 作業端末での切り替わり確認 # IPアドレスがhostsに追記したIPアドレスであることを確認 # ICMPの穴開けはしていないため、応答はTimeout になるはず。 ping gloria.cool
その他のポイントは下記になります。
- アクセスURLは「https://ドメイン名」でOKです。
- 前手順のプロビジョニングで設定したアカウント情報などを設定ください。
5. 現行WordPressの移行データ作成
現行WordPressの移行データ作成にはWordPressのプラグインを利用します。
今回利用したのは「All-in-One WP Migration」というプラグインです。
サイズが大きくなる場合は有償となるのが玉に瑕です。
プラグインをインストールし、現行WordPress管理画面から「All-in-One WP Migration」＞「エクスポート」＞「ファイル」でOK。
6. 新WordPressに取込
現行のデータを、新WordPressに取り込みます。
新WordPressでも「All-in-One WP Migration」をインストールし、現行で取得したデータをインポートします。
全ての情報が現行WordPressの情報に置き換わります。
WordPress管理者としてログインするアカウントも、現行WordPressと同様になりますのでご注意ください。
7. 不備対応
以下、環境によっては発生しないかもしれません。
当方がハマったポイントです。
新WordPressにテーマが反映されない
テーマ関連の情報がまるっとインポートできていませんでした。
どうやら、KUSANAGIのディレクトリ権限が厳しいのが原因で書き込みできていない模様。
# テーマフォルダの権限を広げます chmod 777 ・・・/DocumentRoot/wp-content/theme # 上記の状態とした後に、再度、インポートします。(同じエクスポートファイルで問題なしです) # インポート後、上記の権限は戻しておきましょう。
新WordPressにて不要なプラグインが消せない
原因は同上。
#Plugin配下のユーザを変更します
chown -R kusanagi:kusanagi ・・・/DocumentRoot/wp-content/plugins
8. KUSANAGI セキュリティ対策
KUSANAGI公式手順に従ってセキュリティレベルを上げてください。
9. 新サイトの稼働確認
新サイトの稼働確認を実施します。(hostsを切り換えている端末から)
画面の崩れがないか、メールが届くか、外部サービスと連携している箇所に不具合はないか(想定通り動かないというケースももちろんあり)、新しい記事が投稿できるか、プラグインがインストールできるか、、、等など、運用まで考慮したケースを実施します。
この時点ではサーバ証明書が入っていないため、SSLはエラーとなりますが、ひとまずは無視しましょう。
10. 本番切替
稼働確認に問題がなければ、いよいよ本番切替です。
DNS切替後、新サーバでのSSL証明書取得作業はスピーディーに行う必要があります。
(そうしないと、その間、アクセスしたユーザには証明書エラーが出てしまいます。)
場合によっては、事前の証明書インストール、Webサービスの休止など、業務に影響が出ないように配慮ください。
今回は証明書エラーが出ても許容、と判断し、エイやで切替しています。
最終版の現行WordPressデータを作成し、新WordPressに移行
手順5、手順6を再度実行し、現データを新データに移行します。
現データをエクスポート後、現WordPressに対して更新があった内容は、当然移行されません。
新WordPressで最終確認
インポート後、最終確認を実施します。
DNS切替
いよいよ本番です。
AWS Route 53のAレコードのIPアドレスを、新サーバのIPアドレスに変更します。
DNSの反映(波及)には少し時間がかかりますので、ping等で確認しつつ、新しいサーバのIPアドレスに変わったことを確認しましょう。
※なお、hostsを切り換えた端末で作業する場合、hosts設定を元に戻しておかないと勘違いの元ですので、ご注意ください。
Let’s Enclyptの証明書作成
DNS切替を行い、波及確認が取れましたら速やかに作業しましょう。
波及されていないと作成作業失敗しますのでご注意ください。
※Let’s Encrypt 証明書作成発行依頼には回数限度があります。
おそらく1日5回くらいしか依頼できず、それを超えると1日くらい待つ必要があります。
むやみにコマンドを打鍵するのは止めましょう。
#KUSANAGIコマンドにて証明書を発行
kusanagi ssl --email xxxx@xxxx.ne.jp プロビジョニング名
本番稼働確認
これで無事に稼働する形になっているはずです。
色々な端末からアクセスし、SSL通信が成功していることも確認しましょう。(ブラウザに鍵マークがつくやつ)
※Let’s Encryptの有効期限は3ヶ月です。
11. 事後作業
本番確認ができましたら、事後作業をしましょう。
外部サービスによっては、何かしら対応が必要になることもあります。
しばらくは要監視しましょう。
KUSANAGI ライセンス有効化
本番利用となりますので、きちんとKUSANAGIライセンスを有効にしましょう。
# KUSANAGI ライセンスの登録 # エディションによってコマンドが異なりますのでご注意ください。 kusanagi upgrade kusanagi --edition business --use production --key xxxx-xxxx-xxxx-xxxx yum install kusanagi-biz
Google Adsenseの「ads.txt」再配置
「ads.txt」がうまく移行できていませんでした。(Google Adsenseサイトにて検知)
Googleの手順に則って再配置を実施し、解消。
「ads.txt」のお話は下記を参照ください。
当サイトはAWS LightsailのWordpressで構築しております。 たしなむ程度(^^;;; に「Google Adsense(Googleの広告配信サービス)」の利用を開始したのですが、正規の広告配信サイトである証明をする[…]
旧サーバの廃止
旧サーバに戻す必要がないと判断しましたら、旧サーバを廃止しましょう。
忘れると、課金され続けることになります・・・
ご相談、承ります！
Webサイトの表示速度にお悩みの方。
移行・構築内容によりどうしても対応費用は変わってしまいます。
※「Webサイトの業務要件、移行要件(1秒も止められない、等)」「外部サイト(機能)との接続」「WordPress利用テーマやプラグインの状況」「KUSANAGIを構築する環境(AWS等)」「本番稼働前の稼働確認内容」などが変動要素となります。
「ご相談依頼(お問い合わせ)」 → 「内容ヒヤリング・お見積」 → 「移行に向けた対応」
の流れとなります。
お問い合わせ・お見積りのご相談は以下ページからお願いいたします。
絶賛配信中！
メルマガ詳細はこちら >>>
広告を含むご案内のメールをお送りする場合があります。
以下も、ぜひご活用ください^^
