y2blog

2024

KUSANAGI 環境で試験運用してみた（7/1〜7/2）

Published by y2Editor at 5:44:37 AM under category [ Web,WordPress ]

“KUSANAGI” V9のWordpressイメージでマルチサイト環境を構築してみた

WordPressなどのCMS環境を独自にチューニングしてWEBサイトの高速化を狙ったWEBアプリケーション環境として、プライム・ストラテジー社が開発・提供している“KUSANAGI” というディストリビューションがある．

この”KUSANAGI”を利用するには、日本の代表的なVPSホスティングサービスを利用している場合であれば、ホスティング業者が用意している”KUSANAGI”のOSイメージを利用するのが簡単だ．大分以前にConoHa VPSでの”KUSANAGI” 環境の概要に関する記事を書いていたが、今回新しくなったConoHa　VPS（V3）環境で “KUSANAGI” V9 試験環境を構築してみたので、その概要を紹介することにする．

“KUSANAGI” 9がWEBサーバの仮想ドメインによるマルチドメインホスティングに対応しているようなので、Wordpressのマルチホスト構成が”KUSANAGI”環境で簡単に構築できるかどうか検証してみたかったので、このサイトを含めた現行のサーバ環境を短期間（7/1から2日間）だけ試験運用してみることにした．

【過去の”KUSANGI” 関連の記事】（2017年10月）

“KUSANAGI”試験環境の概要

今回の”KUSANAGI”試験環境は ConoHa VPS (V3環境）で用意されているアプリケーションイメージ “かんたんKUSANAGI” を用いた．”KUSANAGI”環境と通常のLAMP環境でどの程度違いがあるのか把握したかったので、同じ仮想マシン（ConoHa VPS V3: 4VCPU, 4GB Mem, SSD 100GB）上で、OSの再構築を行うことにした．この方法だと仮想マシンのIPアドレスやセキュリティーグループなどの設定もそのまま引き継ぐことが可能なので、移行後の面倒な変更作業が最小限で済む．

ConoHa VPSサービスでは、ユーザによるOSイメージの丸ごとバックアップ機能や取得したOSイメージからの再構築作業が比較的簡単に行うことが可能だ．但し、ConoHa VPSの管理コンソール画面はものすごく反応が遅いので、管理コンソール上で何か作業を行うには忍耐が必要だ．以前は管理コンソールもそれなりにサクサクと動いていたが、最近の管理コンソールのレスポンスの悪さはConoHaから逃げ出したくなるくらい酷い．

ConoHaのVPS基盤がV3に移行したので、少しは管理コンソールのレスポンスが改善されることを期待していたのだが、残念ながらレスポンスは相変わらず遅いままだ．基盤がV3に移行した事で唯一改選された点は、セキュリティーグループの設定がWEB GUIコンソール画面で簡単にできるようになった事くらいだろうか．以前は独自のセキュリティーグループを作成するには自分で Curl等のユーティリティーを使ってAPIを直接コマンドラインから叩くという恐ろしく手間暇の掛かる作業を強いられたが、V3ではWEB上の管理コンソールから簡単に作業ができるようになったことが最大のメリットだ．

本番運用用のセキュリティーグループと開発・テスト用のセキュリティーグループを用意しておいて、開発段階では外部からのアクセスを遮断した環境で構築し、本番運用時にセキュリティーグループを本番用に切り替えることが可能だ．仮想基盤側でセキュリティーグループを簡単に切り替えることが可能なので．OS側での”nftables”等による面倒な設定変更や設定ミス等によるトラブルを減らすことができるだろう．

ConoHa V3 基盤では一つのセキュリティーグループで、IPv4とIPv6の両方に対応可能であるので、IPv4/IPv6デュアルスタック運用ではとてもありがたい．ConoHaよりもお値段が手頃なWebArena Indigoでは、セキュリティーグループがIPv4しか対応していないので、自分でIPv6用のフィルタリング設定をnftableなどを使って自分でOS上に構築しなければならないので、IPv4/IPv6デュアルスタック運用には向いていない．XServerのVPSサービスなどもコストパフォーマンスは良いようだが、IPv6には対応していないので、VPSサービスとしては残念な内容だ．

ConoHa V3基盤のセキュリティーグループ管理コンソール画面の様子

今回の移行手順の概要

現行の運用環境を検証用の”KUSANAGI”環境へ移行する方には様々な移行方法が考えられるが、今回は現行の仮想マシン上でOSを再構築することになるので、事前に検証用の”KUSANAGI”環境を別途構築（費用をケチって小さめの2GBで構築）しておいて、先ずは最新の”KUSANAGI”環境がどのように実装されているのかを確かめた後、現行の運用環境のデータ(HTMLコンテンツ、SQLデータ）を”KUSANAGI環境にコピーし、”KUSANAGI”環境で問題なく稼働することを確かめることにする．

“KUSANAGI”環境で問題が無いことが検証できたら、ConoHaのOSイメージ保存機能を使って、この”KUSANAGI”イメージを保存する．この保存した”KUSANAGI” イメージを使って、現行の運用基盤上で再構築することにする．OSイメージの再構築ではそれなりの時間を要するので、DNSの切り替えが落ち着くするまでは、現行環境と新”KUSANAGI”環境とで平行稼働をさせることになる．勿論、OSの再構築の前に現行環境のOSイメージのバックアップを取得しておくことは言うまでもないだろう．

V3以前の仮想基盤では仮想マシンイメージのバックアップに要する時間は数分程度で済んでいたが、バックアップ作業中は仮想マシンを再起動させることができなかった記憶がある．新しいV3基盤では仮想基盤のスナップショット機能が使えるようで、仮想マシンのスナップショットを取得したら直ぐに仮想マシンを再起動させることができるようだ．

ConoHa V3基盤のOSイメージのバックアップには数十分〜小一時間程度時間が掛かるので、仮想マシンを一旦シャットダウンした状態で、仮想マシンイメージの保存作業を行い、その後直ぐに仮想マシンを再起動させると仮想マシンのダウンタイムを最小に留めることができるだろう．

今回検証する”KUSANAGI”環境の概要

ConoHa VPSで用意されている”KUSANAGI”イメージは “CentOS 9 Strem” ベースの物しか用意されていないようなので、とりあえずこの”KUSANAGI”イメージを使ってサーバをデプロイすることにする．デプロイされた CentOS 9のカーネル等の基本情報は次のようになっている．


[ #cat /etc/os-release ]

NAME="CentOS Stream"
VERSION="9"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:centos:centos:9"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

[ #cat /proc/version ]

Linux version 5.14.0-467.el9.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-43.el9) #1 SMP PREEMPT_DYNAMIC Wed Jun 19 12:08:12 UTC 2024

“KUSANAGI”環境のデプロイ

今回は既存のWordpressで構築されたWEBサイトの移行なので、”KUSANAGI” のデフォルトの構築設定を既存のWEBサイトと同じURL構成、運用スタイルとなるように各種設定ファイルに変更を施すこととする．


 【基本要件】

　・１つの"KUSANAGI"環境で複数のドメインおよびWordpressサイトを立ち上げる．

　　　 https://y2tech.net/blog/    （当サイト）
      https://y2works.net/trip/   （別サイト）

　・デフォルトのドキュメントディレクトリの場所とOSの運用ユーザを変更する

　　　デフォルトのOS運用ユーザ　： "kusanagi" ホームディレクトリ : /home/kusanagi
　　　WEBサーバのドキュメントディレクトリ : "/var/opt/kusanagi/www/html"
　　　　　　　　　　　↓
　　　OS運用ユーザ　： "xxxxxxx"  ホームディレクトリ : /home/xxxxxxx
　　　WEBサーバのデフォルトドキュメントディレクトリ　"/www/html"　

　・WEBサーバの仮想サーバ機能を使って各ドメインのWEBドキュメントディレクトリを分離する
　　　
　　　　https://y2tech.net/blog/ 　 ⇒  /www/y2tech/html
　　　　https://y2works.net/trip/ 　⇒  /www/y2worksh/html

　・"KUSANAGI"が構築したLAMP環境の構成に大きな変更は加えない

　　　Apacheのコンフィグ変更や、PHP等の設定の一部変更程度

　・"KUSANAGI"独自のWordpressプラグイン等は使わない

　　　Wordpressの運用管理方法はこれまでと全く同じで、"KUSANGI"独自のWPプラグインによる拡張や
　　　運用オペレーションは行わない

果たして上記の”KUSANAGI”デプロイ環境を”KUSANAGI”と呼んで良いのか些か疑問ではあるが、とりあえず “KUSANAGI”チューンナップされたLAMP環境と言ったところだろうか．

一般的な”KUSANGI”の運用構成ではないので、”KUSANGI”の更新等を行うと正常に動かなくなる可能性があるので、実運用で修正版の”KUSANAGI”を使う場合には、”KUSANGI”の構成管理の仕組みを把握した上でユーザが自分で施した変更内容を反映させる必要がありそうだ．今回は、短期間の検証環境での運用なので、この辺の”KUSANAGI”の構成管理については調査しない．

OSのインストールが完了した状態で、LAMP環境構築に必要な各種アプリケーションパッケージのインストールに必要なリポジトリ関連の情報は整備されているが、”KUSANAGI”環境はまだ構築されたいないので、OSのアップデート作業を行った後、”KUSANAGI”環境の構築に入る．

“KUSANAGI”構築用のコマンド類が予めインストールされているので、”root”ユーザで下記の”KUSANAGI”関連コマンドを実行する．

“KUSANAGI”環境の初期構築関連のドキュメント: https://kusanagi.tokyo/document/kusanagi-quickstart/を参考に、”KUSANAGI”の構築を進めて行くことにする.


　　1. 初期設定  

    # kusanagi init --passwd "" --nophrase --dbrootpass  ""  --httpd24 --php82 --mariadb10.11

   （Apache、PHP, MariaDBのバージョンは幾つか選択可能なので、現行のLAMP環境になるべく合わせたバージョンを選んでいる）

   このコマンドで、Linuxユーザアカウント "kusanagi" の初期パスワード設定とMaria DBの、Apache 、PHP、MariaDBのインストールおよび管理ユーザ(root)パスワード初期化を行っている．
   Linuxユーザアカウント"kusanagi"は実際の運用では使わないので、シェルを "/sbin/nologin/" に変えている．

　2. WordPress環境の構築

　　[　profile #1 :  "https://y2tech.net/blog/" 用 ]

　　# kusanagi provision --wp --wplang en_US --fqdn y2tech.net --noemail --dbname "Wordpress DB for y2tech_blog" --dbuser ""  --dbpass  ""  y2tech_blog 

  　[　profile #2 :  "https://y2works.net/trip/" 用  ]
  
　　 # kusanagi provision --wp --wplang en_US --fqdn y2works.net --noemail --dbname "" --dbuser ""  --dbpass  ""  y2works_trip

　　上記の２つのコマンドで、Apacheの仮想サーバ機能(Virtual Host)を設定し、それぞれのドメインに応じた仮想WEBサーバ上で動かすWordpress関連の各種設定およびデータベースの構築を行っている．

 "KUSANAGI"関連の設定ファイルは "kusanagi" というフォルダ名で検索すると、

      /var/opt/kusanagi
      /var/opt/kusanagi/log/kusanagi
      /opt/kusanagi
      /opt/kusanagi/share/licenses/kusanagi
      /opt/kusanagi/lib64/kusanagi
      /opt/kusanagi/lib64/python3.9/site-packages/kusanagi
      /home/kusanagi
      /etc/opt/kusanagi 

 が見つかる．

“KUSANAGI”のLAMP環境の設定ファイルは、一般的なLAMP環境とは異なり、基本的に全て “/etc/opt/kusanag” 環境下に置かれている．”/etc/opt/kusanag”　配下をざっとリスティングしてみる．

[root@y2-kusanagi ~]# cd /etc/opt/kusanagi
[root@y2-kusanagi kusanagi]# ls -la 
total 80
drwxr-xr-x. 13 root root 4096 Jun 29 19:53 .
drwxr-xr-x.  3 root root 4096 Oct 20  2023 ..
drwxr-xr-x   3 root root 4096 Jun 29 19:52 gss
drwxr-xr-x   9 root root 4096 Apr  8 15:31 httpd
-rw-r--r--   1 root root  812 Oct  5  2022 krb5.conf
drwxr-xr-x   2 root root 4096 Jun 29 19:52 krb5.conf.d
-rw-r--r--.  1 root root   36 Jun 29 19:25 kusanagi
drwxr-xr-x.  2 root root 4096 Jun 29 19:25 kusanagi.d
drwxr-xr-x   6 root root 4096 Jun 29 19:53 nginx
drwxr-xr-x   3 root root 4096 Jun 29 19:52 openldap
-rw-r--r--   1 root root 1314 Jun 11 12:58 pear.conf
drwxr-xr-x   3 root root 4096 Jun 29 19:53 php.d
-rw-r--r--   1 root root 4618 Jun 11 12:59 php-fpm.conf
-rw-r--r--   1 root root 5387 Jun 11 12:58 php-fpm.conf.default
drwxr-xr-x   2 root root 4096 Jun 29 19:53 php-fpm.d
drwxr-xr-x   2 root root 4096 Jun 29 19:52 ssl
drwxr-xr-x.  6 root root 4096 Jun 24 16:52 templates.d
drwxr-xr-x   2 root root 4096 Jun 29 19:53 tmpfiles.d

[root@y2-kusanagi kusanagi]# cd httpd/conf.d
[root@y2-kusanagi conf.d]# ls -la
total 68
drwxr-xr-x 2 root root 4096 Jun 29 20:10 .
drwxr-xr-x 9 root root 4096 Apr  8 15:31 ..
-rw-r--r-- 1 root root 2907 Apr  8 15:31 autoindex.conf
-rw-r--r-- 1 root root  307 Apr  8 15:31 c5.inc
-rw-r--r-- 1 root root    0 Apr  8 15:31 drupal.inc
-rw-r--r-- 1 root root  198 Apr  8 15:31 fcgi.inc
-rw-r--r-- 1 root root    0 Apr  8 15:31 lamp.inc
-rw-r--r-- 1 root root  275 Apr  8 15:31 mt.inc
-rw-r--r-- 1 root root 1211 Apr  8 15:31 php.conf
-rw-r--r-- 1 root root  366 Apr  8 15:31 README
-rw-r--r-- 1 root root  125 Apr  8 15:31 security.conf
-rw-r--r-- 1 root root 9392 Apr  8 15:31 ssl.conf
-rw-r--r-- 1 root root  433 Apr  8 15:31 ssl.inc
-rw-r--r-- 1 root root 1252 Apr  8 15:31 userdir.conf
-rw-r--r-- 1 root root    0 Apr  8 15:31 wp.inc
-rw-r--r-- 1 root root 2090 Jun 29 20:09 y2tech_blog.conf
-rw-r--r-- 1 root root 2161 Jun 29 20:10 y2works_trip.conf

[root@y2-kusanagi conf.d]# cat y2tech_blog.conf
# vim: ft=conf et sw=4
#=======================================
# y2tech.net
#---------------------------------------


	ServerAdmin webmaster@example.com
	DocumentRoot /home/kusanagi/y2tech_blog/DocumentRoot
	ServerName y2tech.net
	ErrorLog  /home/kusanagi/y2tech_blog/log/httpd/error.log
	CustomLog /home/kusanagi/y2tech_blog/log/httpd/access.log kusanagi env=!no_log
	
		#IncludeOptional modsecurity.d/kusanagi_activated_rules/wordpress/*.conf
		#SecAuditLog /home/kusanagi/y2tech_blog/log/httpd/waf.log
	
	
		Require all granted
		AllowOverride All
		Options FollowSymlinks
	
	
		RewriteEngine Off
		RewriteCond %{HTTPS} off
		RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
	
	Include conf.d/wp.inc


# OSCP stapling
SSLUseStapling Off
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)


	Protocols h2 http/1.1
	ServerAdmin webmaster@example.com
	DocumentRoot /home/kusanagi/y2tech_blog/DocumentRoot
	ServerName y2tech.net
	ErrorLog /home/kusanagi/y2tech_blog/log/httpd/ssl_error.log
	CustomLog /home/kusanagi/y2tech_blog/log/httpd/ssl_access.log kusanagi env=!no_log
	LogLevel warn
	Include conf.d/ssl.inc
	SSLCertificateFile /etc/pki/tls/certs/localhost.crt
	SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
	SSLOpenSSLConfCmd DHParameters "/etc/opt/kusanagi/ssl/dhparam.key"
	
	BrowserMatch "MSIE [2-5]" \
	nokeepalive ssl-unclean-shutdown \
	downgrade-1.0 force-response-1.0
	#Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
	
		#IncludeOptional modsecurity.d/kusanagi_activated_rules/wordpress/*.conf
		#SecAuditLog /home/kusanagi/y2tech_blog/log/httpd/waf.log
	
	
		Require all granted
		AllowOverride All
		Options FollowSymlinks
	
	Include conf.d/wp.inc

Apache関連の設定ファイルを修正すれば、当方が意図するWEBサーバのドキュメントディレクトリ構造を実現できるだろう．ここから先は単純に、Apacheの設定の話なので、実際の運用に沿った設定ファイルの設定を行うことになる．

“KUSANAGI”のプロビジョニング作業が終わった状態で、Apacheの各種パラメータを取得してみた．

[ #httpd -V の実行結果]

Server version: Apache/2.4.59 (Unix)
Server built:   Apr  5 2024 00:00:00
Server's Module Magic Number: 20120211:131
Server loaded:  APR 1.7.4, APR-UTIL 1.6.3, PCRE 10.40 2022-04-14
Compiled using: APR 1.7.4, APR-UTIL 1.6.3, PCRE 10.40 2022-04-14
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/opt/kusanagi"
 -D SUEXEC_BIN="/opt/kusanagi/bin/suexec"
 -D DEFAULT_PIDLOG="/var/opt/kusanagi/run/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/opt/kusanagi/httpd/mime.types"
 -D SERVER_CONFIG_FILE="/etc/opt/kusanagi/httpd/httpd.conf"

[ #httpd -S -D SSL の実行結果]

VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server y2tech.net (/etc/opt/kusanagi/httpd/conf.d/y2tech.conf:6)
         port 80 namevhost y2tech.net (/etc/opt/kusanagi/httpd/conf.d/y2tech.conf:6)
         port 80 namevhost y2works.net (/etc/opt/kusanagi/httpd/conf.d/y2works.conf:6)
                 alias www.y2works.net
*:443                  is a NameVirtualHost
         default server kusanagi (/etc/opt/kusanagi/httpd/conf.d/ssl.conf:56)
         port 443 namevhost kusanagi (/etc/opt/kusanagi/httpd/conf.d/ssl.conf:56)
         port 443 namevhost y2tech.net (/etc/opt/kusanagi/httpd/conf.d/y2tech.conf:35)
         port 443 namevhost y2works.net (/etc/opt/kusanagi/httpd/conf.d/y2works.conf:37)
                 alias www.y2works.net
ServerRoot: "/etc/opt/kusanagi/httpd"
Main DocumentRoot: "/var/opt/kusanagi/www/html"
Main ErrorLog: "/var/opt/kusanagi/log/httpd/error.log"
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/opt/kusanagi/run/" mechanism=default 
Mutex authdigest-opaque: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
PidFile: "/var/opt/kusanagi/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: SSL
User: name="httpd" id=983
Group: name="www" id=983

WEBサーバの各種ドキュメント類の置き場所を変更する

“KUSANAGI”をマルチドメイン構成でデプロイすると、WEBサーバのドキュメントルートが全て、Linuxユーザ”kusanagi”のホームディレクトリ配下 “/home/kusanagi//DocumentRoot/” という形で設定されてしまっている．このような構成では運用上支障があるので、WEBサーバのドキュメントルートの場所を次の様に変更するｋとにする．

　
   ・https://y2tech.net/blog/   ⇒  /www/y2tech/html   
   ・https://y2works.net/trip/   ⇒  /www/y2works/html

同一IPアドレス上で複数のWEBサーバドメインを運用するネームドバーチャルホスティング方式をでは、クライアントが直接IPアドレスを叩いてアクセスしてきた際にはサーバ名による振り分けができないので、このような場合にWEBサーバ側でどのように振る舞うのかを決めておく必要がある．複数の仮想サーバだけの場合はアクセス拒否に設定しておくのが無難だろう．

MariaDB関連の初期設定

“kusanagi init”コマンドを実行した際に、MariaDBのルートアカウント(“root”)の作成とMariaDB環境の初期化(“mariadb-secure-installation” コマンドによる初期環境構築のようなもの）が済んでいるものと思って、MariaDBに”root”アカウントで接続しようとしたら次の様にログインを拒否されてしまった．

[xxxxx@y2-kusanagi ~]$ mysql -u root -p
Enter password: 
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

これではデータベースの新規作成などのMariaDBのハンドリングに支障があるので、”root”アカウントを強制的に再初期化することにした．sudo 権限で “mysql” コマンドを実行し、”root” アカウントのパスワードを再設定することで、localhost上で”root”アカウントで作業できるようになる．

[xxxxx@y2-kusanagi ~]$ sudo mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.11.8-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '';
Query OK, 0 rows affected (0.002 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]> quit
Bye

WordPress関連のデータの移行

WordPress用のデータベースの作成とデータベースオペレーション用のユーザを手動で作成した後、WordpressのHTMLコンテンツのコピーとSQLデータのインポート作業を行う．後は Apacheのバーチャルホスト関連の設定ファイル”/etc/opt/kusanagi/httpd/conf.d/y2tech.conf”, “/etc/opt/kusanagi/httpd/conf.d/y2works.conf” の内容を各バーチャルホストのドキュメントルートに設定すれば基本的な作業は完了だ．

”KUSANAG”の試験運用の結果について

今回は2日間という短い期間だったが、このサイト “y2tech.net” ともう一つのサイト”y2works.net” の2つのWordpressサイトを一つの”KUSANAGI”ホスト（4VCPU/4GB Mem)である程度実用的に運用できることが確かめられた．

ある程度と書いたのは、クライアントのWEBブラウザからアクセスした際の挙動が微妙で、ページが表示されるまで何秒間も待たされたりすることが多い．一旦キャッシュされた後は確かに爆速なのだが、ページ表示時間が大きくばらつくことはイライラの対象でしかなく、ユーザエクスペリエンスとしてはあまり良い印象は受けないだろう．

”KUSANAG”の高速化技術は、主にWEBサーバ側での巨大なメモリキャッシュの効果を最大限利用した高速化なので、サーバ側のメモリリソースが十分大きくないと効果が得られないだろう．キャッシング可能なメモリサイズが少ないと、仮想記憶のメモリスワッピングのような症状が起きて、かえって遅くなるのではないかと思われる．

この辺のキャッシングの制御が絶妙にチューニングされていれば問題ないのだろうが、”KUSANAGI”がどのようなキャッシングの制御を行っているのかは、詳しく調査してみないと判らない．

AWSのCloudFrontやAkamaiなどのCDNサービスも一言で言えばキャッシングによる高速化なのだが、WEBサーバとクライアントのWEBブラウザの間にCDNサービスが介在していることをクライアント側では気付くことはまずないが、”KUSANAGI”の場合はユーザ側である種の違和感を感じるだろう．

小規模な企業などページ数やコンテンツが少なく、アクセスされるページが大体決まっているようなWordpressサイトであれば”KUSANGI”による高速化の恩恵はありそうだが、このサイトのように比較的コンテンツ数が多く、コンテンツへのアクセスが一定しないような場合は”KUSANAGI”の利用は向いていないようだ．

以上のような理由により、今回も”KUSANGI”環境への移行は見送ることにした．当初の予定では7月中は”KUSANGI”環境で試験運用を続けることを考えていたが、試験開始二日目で元の通常のLAMP環境に戻すことにした．

通常のLAMP環境と”KUSANAGI”環境で、Apaceベンチマークを行ってどの程度の差があるのか調べてみようとしたが、”KUSANAGI”環境ではApaceベンチマークは上手く動かないようだ．同じConoHa V3環境の2GB MemのVPS（3VCPU) のLAMP環境で試してみた．

[ ConoHa V3 VPS: 2GB mem, 3VCPU Alma Linux 9 一般的なLAMP環境 ]

yasuaki@Mac-mini ~ % ab -n 100 -c 10 https://y2tech.net/

This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking y2tech.net (be patient).....done

Server Software:        Apache/2.4.57
Server Hostname:        y2tech.net
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        y2tech.net

Document Path:          /
Document Length:        5504 bytes

Concurrency Level:      10
Time taken for tests:   0.899 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      589800 bytes
HTML transferred:       550400 bytes
Requests per second:    111.24 [#/sec] (mean)
Time per request:       89.895 [ms] (mean)
Time per request:       8.990 [ms] (mean, across all concurrent requests)
Transfer rate:          640.72 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       56   62   6.2     59      87
Processing:    16   17   0.6     17      20
Waiting:       16   17   0.6     17      20
Total:         73   79   6.2     77     105

Percentage of the requests served within a certain time (ms)
  50%     77
  66%     79
  75%     80
  80%     80
  90%     88
  95%     96
  98%    104
  99%    105
 100%    105 (longest request)


[ "KUSANAGI" : ConoHa V3 VPS: 4GB mem, 4VCPU ]

yasuaki@Mac-mini ~ % ab -n 100 -c 10 https://y2tech.net/
This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking y2tech.net (be patient)...apr_pollset_poll: The timeout specified has expired (70007)
Total of 63 requests completed
yasuaki@Mac-mini ~ %

KUSANAGI 環境で試験運用してみた（7/1〜7/2）

“KUSANAGI” V9のWordpressイメージでマルチサイト環境を構築してみた

【過去の”KUSANGI” 関連の記事】（2017年10月）

“KUSANAGI”試験環境の概要

今回の移行手順の概要

今回検証する”KUSANAGI”環境の概要

“KUSANAGI”環境のデプロイ

WEBサーバの各種ドキュメント類の置き場所を変更する

MariaDB関連の初期設定

WordPress関連のデータの移行

”KUSANAG”の試験運用の結果について

Calendar

Latest Posts

Pages

Categories

Monthly (recent)

Yearly

Blogroll

Meta

Embarcadero, San Fransisco

y2blog

KUSANAGI 環境で試験運用してみた（7/1〜7/2）

“KUSANAGI” V9のWordpressイメージでマルチサイト環境を構築してみた

【過去の”KUSANGI” 関連の記事】（2017年10月）

“KUSANAGI”試験環境の概要

今回の移行手順の概要

今回検証する”KUSANAGI”環境の概要

“KUSANAGI”環境のデプロイ

WEBサーバの各種ドキュメント類の置き場所を変更する

MariaDB関連の初期設定

WordPress関連のデータの移行

”KUSANAG”の試験運用の結果について

Calendar

Latest Posts

Pages

Categories

Monthly (recent)

Yearly

Blogroll

Meta