大雪山 白雲岳避難小屋よりトムラウシ方面を


Date/Time: 2014:09:24 06:53:17
Camera: PENTAX
Model: PENTAX K-5 II s
Exporsure Time: 1/1000
FNumber: 5.6
Aperture Value: 5.0
Focal Length: 21.0

Close

y2blog » KUSANAGI 環境で試験運用してみた(7/1〜7/2)

IPv4 Access: 44.200.140.218 (ec2-44-200-140-218.compute-1.amazonaws.com)

7

03

2024

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

“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 Security Group Control Panel
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のカーネル等の基本情報は次のようになっている.



“KUSANAGI”環境のデプロイ


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



果たして上記の”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”の構築を進めて行くことにする.



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

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


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



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


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


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


MariaDB関連の初期設定

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



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



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環境で試してみた.