ネット上のアクセスボリュームをUPさせ効率の良い集客をご提案します。

カテゴリー「Wordpress」の記事

Caddy 高速WEB サーバ(http2 quic対応) on CentOS7

 / Linux Tips, Wordpress, テクニカル, トピックス, ノウハウ


http2対応の高速サーバを今回扱ってみる。このサーバはGo言語で開発されたWEBサーバです。導入にはコンパイルから行う場合はGo言語開発環境が必要ですが
バイナリーから入れるのであれば、特にGo言語開発環境は必要ありません。導入方法は幾つかやり方があります。一番簡なのはCentOS7の場合ならepelレポジトリー
から導入するのが簡単です。今回はこのサーバを理解するため少し手間がかかるバイナリーダウンロードから導入する方法を紹介します。
尚、今回は既存のサイトをcaddyで設置するやり方ですが、新規サイトであればSSL接続の鍵の取得などを無償のLet’s Encryptから自動取得してくれます。

バイナリーパッケージのダウンロード

バイナリーパッケージを配置し実行環境を作る。

caddy起動をsystemdに登録する

caddyサーバの15,16行目の実行ユーザとグループを指定します。
22行目を編集します。-quic追加とcaddyプロセスログファイルの出力先を変更します。

caddy設定ファイルを作成する

www.testserv.netでhttps接続のListenや設定情報は以下のように行います。
予め、selinuxはOFFにしておきましょう。caddyは比較的デバッグ情報が寡黙の傾向にあるのでくだらないことで悩まず最初は「setenforce 0」で無効。 きちんとWEBサーバとして動いたら、「setenforce 1」で影響がないか確認すると良いと思います。 尚、この設定でQualisのSSLテスト評価で「A+」取得できました。

php-fpmの設定

caddyを起動する

トラブルシューティング

うまくcaddyが起動できていない場合は、おおよそlogのディレクトリパーミッション、SSL鍵のディレクトリパーミッションが原因のケースが多い。 あるいはログファイルなら予め0サイズのログファイル名をtouchコマンドで作っておくことをお勧めする。 「journalctl -xe」を実行して調べてみると良い。また、firewalldやiptablesでportが開放されているかチェックし、開放されてなければ該当portをオープンにしましょう。

※まだまだ発展途上なところがありますが、個人的には大変気に入りました。設定がシンプルで少ない設定で動かせるところが良いと思います。当社でもApache2.4からこのサーバに切り替えて使っています。

DockerでWORDPRESSを導入する際のDataBaseバージョン(MySQL or Mariadb)要注意。

 / Linux Tips, Wordpress, wordpressテクニカル, トピックス, ノウハウ


昨今、大人気のDockerですが、システムはもちろんのこと中でも教育用に使われる機会は多いのではないかと感じます。WORDPRESSやLinux、各種言語の環境を素早く整えるために便利だと感じます。

初心者だけではなく、ITの専門家でも幅広くやっている方と一つに特化してやっている方で別れると思います。特に言語系技術とサーバ系技術は一緒で考えがちですがスケールが大きくなってくるとサーバ技術をきちんと持っているかどうかの違いが生じてきます。

そんなとき言語系でやられている専門家の方はDockerを使うことでハードルがぐんと下がるのではないかと思います。

前フリは長くなってしまいましたが、インターネットの世界ではWORDPRESSやPHPといった環境は圧倒的にWEBアプリケーションの中では使用頻度が高いためDockerで使用する人も多いと思います。

ということで、実際にDockerでWORDPRESSを使って見ようと思いました。
※今回はMariadbでWORDPRESSを使用したため問題なくあっさりWORDPRESSのインストールができましたが、Mariadb/MySQLを使う場合はバージョンをLatestバージョンにしてしまうと間違いなくハマります。環境による違いもあるのでDBエラーコネクションが表示される場合は以下のMySQL5.7.xをオススメします。

この原因はMySQLのバージョンがLatestだとVersion 8になってしまいWORDPRESSとのインターフェイスが取れなくなってしまうからです。ネットでもかなりVersion 8を無意識にインストールして接続できない問題で苦しんでいる方が多いようでした。この理由はcaching_sha2_passwordがMySQL8のデフォルト認証プラグインに変更された事が原因です。 どうしても、MySQL8で対処したい方はmy.cnfでデフォルト認証プラグインを変更してDocker imageへコミットの上、再度コンテナ作成が必要です。

旧来の認証プラグインを使うように変更(変更後MySQL再起動が必要)



WORDPRESSで使う場合はMySQLのバージョンを5.7.xがよろしいと思います。下記のような感じで バージョン指定します。

【MySQLで接続する場合】

もし、様々な問題が生じたらやはりアプリ環境へログインして分析することが大切!

【デバッグは環境にログインしてアプリの設定を確認しよう】

CentOS7/CentOS6 共通h2o Web サーバのインストール with WORDPRESSで動かしてみる。

 / Linux Tips, Wordpress, wordpressテクニカル, テクニカル, トピックス, ノウハウ


h2oサーバの導入の動機

h2o高速サーバh2oを使ってみようと思った理由はHTTP/2.xで通信できることかな。最近のGoogle検索順位は早さも大切な評価ウェイトをしめているためサイトの速度アップは重要なことです。
このHTTP/2.xのプロトコルはHTTPS通信において表示速度を向上させ並列してリクエストを処理できるため、表示速度が向上します。
Nginxも早いのですが、H2OはそのNginxを凌ぐ早さで表示できるようです。

h2oのレポジドリーの追加

h2oのインストールはCentOS7/CentOS6で共通です。基本はyumのレポジトリーに以下の記述を追加し保存するだけでyum経由でレポジトリー からのインストールが可能になります。

h2oのインストールと起動

h2oを実際にyumを使ってインストールし、起動する手順になります。

ユーザh2oの作成とドキュメントルート作成&WORDPRESSの設置

SSL & WORDPRESSを動かす際のコンフィグレーション例(h2o.conf)

今回はSSLを使ってh2o環境でWORDPRESSを動かすケースのh2o.confを挙げてみたいと思います。
let’s encryptを使ってSSLライセンス取得し、実験してみました。Let’s Encrypt取得のやり方はここ
ドキュメントルートに/opt/html/content1として、実行ユーザはh2oユーザを新たに作り設定しています。
nginxにも似ている書き方にも感じますが、インデントで設定の範囲がきまるので注意しましょう。
尚、fastCGIをh2oは直接管理できるので通常行うようなfastCGIの設定は不要です。
SSL証明書の項目設定の中でCAファイル(認証局証明、中間証明等)を設定する箇所はありません。
従ってサーバ証明書とCAファイルはcatコマンドで結合を行ってください。結合後に結合ファイルの終点と開始点の間に改行が正しく入っていなかったらエラーになりますので必ず結合の後にチェックが必要です。
最初にサーバ証明書が来るようにするのがポイントです。尚、LetsEncryptの場合fullchain.pemが既に結合されたものです。

おまけ:ソースからのh2oコンパイル

CentOS6.10のデフォルトのgccバージョン(4.4.7)では宣言エラー(同じ関数名で異なるタイプ宣言)が出てしまいました。しかしHomebrewで導入しているgccのバージョン(5.5.0)では 問題なくコンパイルが完了しました。gccバージョン毎のプロトタイプ宣言の解釈と処理の違いがあるようです。

ホームページの高速化手法 GZIP圧縮、コンパイルキャッシュ。画像圧縮、その他コンテンツ圧縮

 / Linux Tips, SEO関連, Wordpress, wordpressテクニカル, トピックス, ノウハウ


WEB高速化まとめ

ホームページの高速化の意義

現在のグーグル検索順位を決定する基準の一つにホームページの高速表示は不可欠だ。表示が遅くて待たせることはユーザビリティとして適切ではないとグーグルは考えている。その他にも見た目のデザインやコンテンツの確かさ、有益な情報が入っているかが重要な順位を決める要因になりうる。

ホームページ高速化の優先順位

とりわけSEOとして考えていくなら第一にホームページの表示速度が重要で尚且つ、スマホの表示速度を優先度上げて考えるべきだ。理由として今の一般ユーザのアクセスの大半はスマホから来ているからなのです。 高速化の作業優先度を挙げるとしたら以下のような感じになるでしょう。
  1. スマートフォンの高速化
  2. 画像の圧縮
  3. javascriptの圧縮
  4. CSSの圧縮
  5. コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード
  6. DNSの応答高速化
  7. サーバのキャッシュと転送の圧縮処理
  8. ホスティング高速化
  9. HTTP/2を使ったWEBサーバへ切り替え。もしくはフロントをHTTP/2で置き換え。バッックエンドはHTTP/1.xでもOK。

スマートフォンの高速化

スマートフォンの高速化は第一に画像の調整につきます。PCでは画像のサイズを気にせずとも、スマホでは様々な場所へ移動してしまうため、回線状態の悪いことも想定して遅い速度でも閲覧できるよう画像の最適化は重要です。
画像はサイズも大切ですが画像形式、圧縮の技術を考慮するべきです。さらに画像のサイズをPC、スマホ、タブレットで変えて準備すると高速に表示できるはずです。レスポンシブならmetaタグでviewportを指定してサイズに合わせたCSSを読み出すか、あるいはcssファイル側で@media only screen and (max-device-width : 480px)のようにデバイスのスクリーン幅に合わせて変形を決めることができます。
WORDPRESS等のCMSではこのような画像を自動で間引いたり、最適にCSSを調整してくれるpluginがあります。このようなプラグインを使ってPC用画像とスマホ用画像を別々に分けて作るのは大変良いことです。

画像の圧縮

WORDPRESSで利用できる主な画像最適化プラグインを下記に案内します。導入して使ってみてください。無料で使えるものもかなりありますが、概ね数に制限があります。ページ数だったり、画像の数などです。
また重要なのは、設定の際に他のプラグインでやっている機能を重複しないようにしてください。同じ処理を2回、3回やっても無駄なので。むしろ遅くなります。またキャッシュも設定を変更したら 一度キャッシュクリアしてから速度を測定しましょう。そうしないと古いキャッシュで速度測定することになります。
  1. Compress JPEG & PNG images
  2. WP Smush
  3. EWWW Image Optimizer
※尚、WORDPRESSを使っていないサイトの場合は、専用ホスティングもしくは自前の専用サーバでLinuxやMacOSを使い圧縮することができます。
  1. JPEG圧縮(jpegoptim)
  2. PNG圧縮(optipng)

【JPEGの圧縮ツールの導入】

【PNG圧縮ツールの導入】

【圧縮ツールの使い方】

主なキャッシュプラグイン

キャッシュだけではなくHTML,CSS,Javascriptを圧縮したり、統合化をしてくれるものもあります。
  • Autoptimize
  • Powered Cache
  • W3 Total Cache
  • WP Fastest Cache

コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード

PHPはスクリプトであるためリクエストごとにコンパイルをします。しかしこれだと時間がかかってしまいます。スクリプトを読むことなくパフォーマンスの向上を図るため、OPcacheを使うことで一度コンパイルしたコードをメモリー上に共有し再利用します。

phpinfo() Or php -v によるZendクレジットで導入が確認できる

Opcache導入が成功すると下記のクレジットが表示されます。 WEBサーバは再起動してください。コマンドラインではphp -vで確認できます。 ☆CentOSのバージョンによっては/etc/php.d/配下にxx-opcache.iniでopcache.soを指定するかもしれません。
☆Opcacheはphpの低いバージョンはダメ。おそらくphp5.6前後以上と思われる。

サーバの転送の圧縮処理とキャッシュ制御技術

Apache WEBサーバの転送はgzipで圧縮して転送を行うことが可能です。Apache2.4以前のバージョンではmod_deflateモジュールとを使ってAddOutputFilterByTypeでmimeフィルターする方法が途中まで主流でしたが既に廃れたやり方と言われています。
つまりdeflateモジュールをmod_filterを使ってmimeフィルターかけて圧縮することがApacheからも推奨されています。尚コンテンツ圧縮は転送量が減る反面、CPUの処理は増えるため、ボトルネックがCPUの処理能力の場合は逆にレスポンスが低下します。また、Apache2.4バージョン以降ではmod_filterを使うことが大前提でアナウンスされています。
結論を言ってしまうとどちらのバージョンでもmod_filterでFilterProviderでコンテンツタイプをフィルターして使うのですが若干記述に違いがありますので注意が必要です。
双方の処理ではDeflateCompressionLevel による圧縮レベルが指定できますが現実には、一番低いレベルの”1”で十分であります。レベルを上げても圧縮率が大して変わらないためCPUに余計な負荷を与えてしまい全体でみるとマイナスになってしまうからです。

Apache2.4以下の場合(つまりApache2.2)

Apache2.4以上の場合

上記を短くまとめると以下のようになります。

<<注意点モジュールの確認>>

下記のモジュールが予めコメントが外れていることを確認しましょう。 以上の記述とチェックが終わったらWEBサーバを再起動して圧縮の確認を行ってください。 WEBサイトの圧縮レベルを確認するサイト

キャッシュの処理

ブラウザ側にキャッシュをさせるタイマーをサーバー側で設定できるのがmod_expireになります。あくまでもキャッシュなので 必ず1回目のページアクセスは遅いということを理解しておきましょう。タイマーが切れたタイミングでWEBサーバにコンテンツを取りに行きます。
尚、予めmod_expireモジュールのコメント外れていることを必ず確認してください。

DNSの高速化とサーバホスティングの高速化

最近のクラウド、VPSなどの専用サーバホスティングは高速DNSサーバを備えているケースが多く、自前でDNSを用意するよりもいいかもしれません。インターネット上のジオメトリック的にDNSが有利にキャッシュされ盥回しされるため応答が早くなる可能性が高いと思います。
また、VPSもクラウドも専用サーバホスティングの世界ではHDDタイプとSSDタイプに選択肢が別れているものも当たり前になってきています。ネットワークの太い回線帯域を持っている方が圧倒的にサイトの表示は早いのでサーバスペック(コアの数)よりは回線の太さが重要かもしれません。また処理によって書き込みが中程度に多いのならばSSDも良いと思います。
以前はSSDの信頼性も?がついてましたがかなり安全であることがわかってきました。流石に大容量はHDDにかなわないのですが、容量がそれほどいかないサイトならSSDで十分とも言えます。
過去に使って見てよかったホスティングをとりあえず案内します。
  • Amazon EC2 | Amazon Lightsail
  • Azure
  • Google Cloud
  • Conoha  
  • Kagoya VPS
  • Web Arena Suite Prov4

SSLサーバ移転に注意すべきこと(転送mod_rewriteが効かない場合の考察)

 / Wordpress, wordpressテクニカル, トピックス


昨年(平成30年)からSSL仕様にする流れが大きくサーバトラブルの要因となるケースが発生している、特にサーバ移転や表示ドメインの変更時に注意が必要だ。これは何を意味しているかというと、概ね以下の問題点が出てくるためである。


SSLでサーバ移転で生ずる問題

  1. 旧httpドメインでのアクセスを取りこぼしたくないから転送処理を導入するが期待通りに動作しない
  2. SSL証明書をwww付きで取得するか、無しで取得するかでWEBサーバ設定やmod_rewrite等が影響を受ける
  3. 転送のキャッシュ、証明書のキャッシュは「強制リロード」、「履歴の削除」、「キャッシュの削除」では消えない場合がある。

SSL証明書を購入するときに注意をしないといけないのは「www]付きのドメインなのか否かである。SSL証明書発行局のブランドにより1つの証明書で「www付き」と「www無し」をサポートしてくれるものが中にはある。申請時点でwww.xxxx.comのようにコモンネームにwwwをつけた場合(あり・なしを双方サポート)するパターンがあるので申請時にどのコモンネームにするかはよく考えたほうが良い。以前はwww.xxxx.comだったがサーバ移転のタイミングでSSLにしてwww無しで行こうと考える場合は一番注意が必要だ。



つまりwww無しにしたとして、旧ドメインはwww付きであるためユーザの中には旧ドメインでアクセスしてくるものもいるだろう。それを取りこぼししないようにmod_rewriteを使ってwwwで来たものを無しに転送するといった手法は古くからある。しかし、SSLが絡んでくると複雑な状況になる。というのもSSLが付いているサーバアクセスではブラウザー側の挙動が転送処理をチェックする前にSSLのチェックを先に実施するパターンがあるからだ。


ここで発生する問題はwww無しでSSL取得したが、以前はwwwが付いていたのでそれをどうやって取りこぼしをしないように統合するかである。結論を先に言ってしまうと残念ながらSSL証明書はwww付きとwww無しの双方をサポートするSSL商品を購入するか、www付きとwww無しを個別に2つ購入するしかない。


その理由はブラウザー側にあり、SSLでアクセスするモードでは転送処理より優先してSSLチェックが発生するからである。chrome,opera,vivaldi等では転送前にSSLチェックは生じないがedge,safari,firefoxではSSLチェックが転送より先に発生するのである。つまり転送処理をいくら入れてもwww付きSSLがなかったり、wwwドメインがサイトに存在しないと「セキュリティに問題があるサイト」という判定になってしまうため転送まで行き着かないのである。

TOPへ戻る