Scribble at 2026-07-22 09:09:37 Last modified: 2026-07-23 03:20:17

例の、某県の史跡を世界遺産に登録しようというキャンペーンで公開しているサイトは、本日の23時に新しいインスタンスへの切り替えを予定している・・・のだが、実は既に切り替えていたりする。要は表示だとか使い勝手に問題がなければいいのであって、それくらいは僕が全てのページを確認できる。WordPress の管理画面などは運営側の事情だから確認は後からでもいいし、ひとまずエンド・ユーザ側に問題がなければいいだろう。そんなわけで、さきほど朝の5:30にいつものとおり起床して、すぐに DNS サービスで A レコードを切り替えたわけである。本来は予行演習のつもりだったが、このまま23時まで放置して、切り替えの予定時刻になったら切り替えた振りをする。いちおうディレクターと WordPress 運用の担当者も待機することになっているが、彼らはサーバの仕組みも DNS の設定状況も知らないし、そもそもその仕組みすら分かっていない人々である。

具体的な話をしてもしょうがないので、インスタンスを立て直して切り替える手順という一般論をしておこう。その方が多くの方にとって役立つであろう。このサイトは５年くらい前から運営していて、もちろん僕が「さくらのクラウド」に作成したインスタンス（2 cores + 4 GB RAM + 20 GB SSD）を使ってきた。この上に WordPress 専用を謳う KUSANAGI という CentOS のカスタム OS が乗っていて、これは当時はバージョン８だった。しかし、このほど PHP のバージョン・アップをすることになって、KUSANAGI のバージョン８では、その中で動かせる PHP の新しさに限界があるため、KUSANAGI のバージョンを上げる必要がある。こういうわけで、新しく KUSANAGI バージョン９が稼働するインスタンスを立ち上げて、コンテンツを移設することになったわけである。

「さくらのクラウド」（なんで括弧で囲んでいるかという説明は繰り返さない）に新しくインスタンスを作る手順は、コントロール・パネルからボタン一つで開始される作成の画面で初期条件を指定するだけだから、まことに簡単であり、最初からスペックや root のパスワードだとか秘密鍵が決まっていれば数分で終わり、インスタンスを起動できる。そして、今回は僕の判断で "2 cores + 4 GB RAM + 40 GB SSD" というストレージを増やしたスペックに変更した。これは、現行サーバの様子を Mackerel で監視したり、サーバ内で df コマンドを使ってみると、

/dev/vda3 16376680 14908588 613156 97% /

という状況に陥ったからだ。更に、

# du -sh /* 2>/dev/null | sort -hr | head -n 10

で下の階層を調べていくと、これは fail2ban のログが肥大化しているのが原因だった。もちろんログ・ローテーションしたらいいので、新しく作ったインスタンスではログの肥大化に対策するけれど、ログの肥大化は避けられない話であり、ローテーションした後のログ・ファイルを丁寧にダウンロードして消していく他にない。あるいは yum のように自動でアップデートしたログをメールで送信するような措置を採って、ログの履歴を制限（10ファイルずつ順番に古いものから消していく）するしかないのだろう。どういうサービス（デーモン）がログを作るかは決まっているので、そこは最初から計画できることだが、ファイル・サイズまでは計画できない（もちろん、いちどに色々な IP アドレスから ssh サーバが攻撃されたら、それだけ fail2ban の履歴は増える）。ともあれ、５年程度放置するだけでストレージがいっぱいになってしまうようでは困るから、せめて 40 GB にしておこうというわけだ。ちなみに、これは「コミュニティ版」の KUSANAGI だけの話であり、Business 版など利用料金がかかる有償版の KUSANAGI だと、どういうわけかストレージの容量が 20 GB と決まっているので、ストレージのサイズを増やせない。

新しいインスタンスを用意したら、KUSANAGI のコマンドでサーバを初期化したり、プロファイルを作成する。これは、ひとまず「さくらのクラウド」のコントロール・パネルにあるターミナル・エミュレータ画面で実行してもいいだろう。その理由として、KUSANAGI を稼働させたサーバ（「インスタンス」でもいいが、OS を投入して電源を入れた後は「サーバ」と呼ぶ方がいいだろう）は、初期状態では sshd が動いていないからだ。これは「さくらのクラウド」にも KUSANAGI のマニュアルにも書かれていないようなので、注意点として覚えておくことをお勧めする。手っ取り早く TeraTerm Pro や Putty で使い慣れたツールを使いたい人は、もちろん sshd を起動して作業すればいいのだが、ともかくコントロール・パネルのターミナル・エミュレータで sshd を起動しなければ始まらないので、インスタンスを起動させた後にすぐさま TeraTerm Pro などでアクセスして「サーバが応答しない！」などと慌てるのは愚かである。

ちなみに、sshd の接続ポリシーだが、大別してパスワード認証と鍵認証、root アクセスの可否、chroot するかどうかなど、誰がどういう権限でサーバを使うかによって決めたらいい。特に、外注さんが WordPress のテーマなどを作っている場合は、FTP しか使えない人なのか、ssh over scp のツールを使えるかということや、ssh over scp でも鍵の運用ができるかどうかによっても接続ポリシーは強くしたり緩くする必要があるだろう。当然だが、セキュリティというものは「もっとも緩くしたところがもっとも弱い」という傾向があるので（必然的にそうだというわけではないから、過信は禁物である）、やはり外注さんを選ぶならデザイナーだろうとコーダだろうと最低限の知識やスキルはもっている人が望ましいだろう。当然だが、鍵認証を使い、秘密鍵のパスフレーズは最低でも32桁以上を設定し、root アクセスは許可せずに、chroot で一般ユーザのアクセスできるパスを下層に制限するのが望ましい。ところが、実際には chroot しないケースが意外に多く、「さくらインターネット」のレンタル・サーバだと ssh over scp どころか ftp でアクセスしても / まで上がれてしまい、同じサーバに同居する他の契約者が設定したホスト名（"FOOBAR.sakura.ne.jp" のような）まで分かってしまうという問題があった。これは、前職だから20年以上も前に、それこそ「さくらインターネット」の営業所が四ツ橋にあった頃（こんなの、さくらの部長級の社員でも知ってる人は少ないだろう）から営業マンに指摘してきたことなのだが、特に問題がなかったからか改善されたという話を聞かない。でも、こういう情報はサーバ内のパスを大っぴらに攻撃者へ知らせるようなものなので（そもそもホスト名とサーバ内のパス、つまりコンテンツの格納ディレクトリやユーザ名が一致しているという仕様とか規則性に問題があるのだが）、これは何とか改める方がいいと思う。

さて、現行サーバから新サーバへコンテンツを動かすのは簡単だ。WordPress のコアはともかく、テーマやアップロードしたファイルは全てそのまま同じ相対位置へアップロードすればいいだけだし、データベースの内容も現行サーバ（KUSANAGI はウェブ・サーバにDBサーバも配置するので、キャンペーンなどで個人データを収集するような用途でサイトを構築するなら、WordPress で運用するDBサーバとは別に個人データを格納するインスタンスかオプションのDBアプライアンスを追加して、フォームのデータを外部のDBサーバへ格納するように開発することをお勧めする。特に、弊社のようにプライバシーマークを取得している企業の安全管理措置のレベルでは、ウェブ・サーバとDBサーバを同じインスタンスで運用することは、指摘事項とまではいかなくても改善を勧められるはずだ（改善を勧めない現地審査員は、技術力のない事務屋にすぎないと見做してよい）。これが PCI-DSS を適用するようなサイトだったら、もちろん認証が剥奪されるくらい致命的な欠陥である。ということで、僕が運用しているサーバで運営するサイトは、個人データどころかフォームもないし POP3 のデーモンすら稼働していないので、とりあえずDBは同じインスタンスにある。

現行サーバと新サーバとでは、なるべくパスが同じになる方がコンテンツの移設は楽なのだが、同じパスにするということは、現行サーバで成功する攻撃が新サーバでも（パスをたどるという意味で）成功しやすくなるという意味にもなるので、僕は今回は敢えて KUSANAGI のプロファイル名を変更した。プロファイル名は、もちろん kusanagi ユーザの配下に作成されるディレクトリ名でもあるから、WordPress で何らかの理由があってフルパスを設定している場合には、現行サーバの MariaDB からエクスポートした SQL ファイルを新サーバの MariaDB へインポートするときに、パスを一斉置換する必要があるだろう（実際に、外注さんはそれをやっている）。なお、このような作業では WordPress の管理画面でサポートされているエクスポートの機能は使うべきではない。特にプラグインなどを利用している環境では、プラグインの設定は無視されるので不完全なエクスポートやインポートしかできないからだ。そして、後からプラグインの設定を移設したりすると、先にインポートした記事や一部の（WordPress の機能でインポートできる）設定と食い違ったりすることがある。なので、移設先のデータベースをテーブルごと全て削除してから、改めて現行サーバのデータベースを移してしまう方がきれいに作業できる。

移設先のコンテンツは、もちろん使用中のドメインでアクセスしても確認できないので、(1) IP アドレスでアクセスする、(2) 移行先に専用のサブ・ドメインを A レコードで設定してアクセスする、という方法が考えられる。このとき、問題になるのが WordPress の設定だ。WordPress の管理画面で設定するドメインや URL は、できればサーバを移行しても変更しなくて済むように、最初から使用中のドメインで設定しておきたい。こういう場合に用意されているのが、「マルチ・ドメイン」と「ドメイン＆URL設定のオーバーライド」という二つの設定だ。簡単なのは WordPress の管理画面で設定したドメインや URL を wp-config.php でオーバーライドしてしまう方法で、wp-config.php に

define( 'WP_HOME', 'http://IP_ADDRESS' );

という WordPress で表示するトップ・ページの URL と、

define( 'WP_SITEURL', 'http://IP_ADDRESS' );

という WordPress のコア・システム（管理画面など）へアクセスする URL とを上書きして設定することだ。通常、これらはどちらも同じ設定内容だが、たとえば WordPress のコア・システムだけを /wp ディレクトリに配置するときなどは WP_SITEURL の値が違ってくる。これに新サーバの IP アドレス、あるいは新サーバ用に A レコードとして追加したサブ・ドメインを設定すればいい。もちろん、IP アドレスやサブ・ドメインでアクセスするときは SSL サーバ証明書がなくても構わないだろうから、HTTPS での接続を強制するような設定はウェブ・サーバの設定や .htaccess や WordPress のプラグインなどで強制している場合は無効にしておく。（マルチ・ドメイン設定の解説は割愛する。もともとこれは、日本語版と英語版のようなマルチ・コンテンツのために使う設定だからだ。）

それから、ちょうど話題が出たので注意したいのが、SSL サーバ証明書だ。これは、もちろん移行が完了したら使用中のドメインなり FQDN で取得した証明書を使い続けるのだから、いま稼働している現行サイトの証明書を新サーバにコピーしておき、新サーバのウェブ・サーバでパスを正しく設定しておかないといけない。SSL サーバ証明書は、ウェブ・サーバのネットワーク上のコンピュータ名（ホスト名）や IP アドレスに紐づいて発行されたり署名されるわけではないから、証明書を他のサーバへコピーしても使える。なので、ウェブ・サーバの openssl が正しく処理できるパスにファイルがあればそれでよいのだ。ただ、HTTPS 通信でのアクセスは事前にテストできない（テストできるなら、それは他のサーバで同じ証明書が有効になってしまうということだから、逆にそんなことができては困る）。したがって、正式な入れ替えよりも前に、入れ替えのテストはやっておくのが望ましい。アクセスの少ないサイトであっても、念のため深夜や早朝にやっておくのがいいだろう。僕も、さきほど朝の５時頃に A レコードの入れ替えをテストして、特に問題がなかったことを確認している（コンテンツの移設には幾つか些細な不備があるようだが、これは僕が解決することではない）。

そして、サーバの移設は DNS の管理サービスで A レコードを設定変更するだけで終わる（筈だ）。このため、ドメインの管理はなるべく自社でやるのが望ましい。でないと、何か問題があったからといって設定を即座に元へ戻すような作業が出来ない可能性があるからだ。それに、A レコードの設定を変えるだけのために、ドメインを管理している他社なり個人事業主なり別の部署の人間に早朝や深夜に同席してもらうというのも無駄な話である。そして、A レコードを変更したら、すぐに wp-config.php で設定している暫定の設定内容をコメント・アウトして、WordPress の管理画面で設定してある使用中のドメイン情報で正しくレスポンスできるようにする。

最後に、DNS のレコード情報を変更するような場合に、多くの方が予想されるとおり、いまだに「浸透」などというオカルトを信じている人がいるので、これについて書いておこう。いまや、僕が利用しているムームードメインのような初心者向けのサービスですら、レコード情報は即座に反映される。今回も、ムームードメインで変更した A レコード情報を、AWS で運用している弊社のウェブ・サーバに ssh でログインして dig コマンドを叩いてみたが、レコード情報を変更してから１分も経たずに IP アドレスが書き換わっていることを確認した。そもそも DNS は、ネーム・サーバが自らのキャッシュを TTL に従って能動的に更新する PULL 型の処理をしている分散システムであって、レコード情報を更新したネーム・サーバから世界中のネーム・サーバに「浸透させる」とか「伝達する」というイメージは端的に言って間違いである。TTL は標準あるいはディフォールトとして3600秒（１時間）となっているけれど、DNS サーバを自力で運用するほどの事業者であれば、どこでも更に短い設定に変更しているのが普通であって、１分ていどの設定も珍しくない。実際、僕が NSD という DNS サーバのソフトウェアを自力で運用していたときには、TTL を５分ていどに設定していた。末端のネーム・サーバなんて、別に大量のキャッシュを抱えるわけでもなし、毎分のように更新しても大した負荷にはならない（自分で取得したドメインだけのために運用する DNS サーバというのも立てられるので、その場合はドメイン１つのキャッシュだけである）。

それから、正しくサーバが切り替わって、新しいサーバでサイトが表示されていることを確認する方法としては、これも幾つかのやりかたがある。たとえば、現行サイトと新サイトで WordPress の管理画面のパスワードを違う文字列に変えることも一つのアイデアだ。それから、現行サーバと新サーバの双方に /now.txt のようなテキスト・ファイルを作っておき、現行サーバには "OLD"、新サーバには "NEW" と書いて、ブラウザで /now.txt にアクセスしてからリロードを繰り返すのも簡単な確認方法だ（冒頭の画像は、そうやって表示した確認用のメッセージだ）。なお、馬鹿な制作会社は（というか、15年くらい前に僕が気づいて弊社では止めさせたという経緯もあるのだが）、ウェブ・ページに目印となる記号やフレーズを忍ばせるなんてことをやる。しかし、これは納品物を勝手に改竄する行為であって、自社のコーポレート・サイトでもやるのはどうかと思うが、とにかくクライアントから運用なりコンテンツの制作を委託されているにすぎない事業者が、表示確認のためにウェブ・ページに無関係なフレーズや記号を目立たないところであろうと追加するなんてことは、ウェブサイトというコンテンツがクライアントからの預かり物でありクライアントの資産であるという重大な事実を軽視しており、やってはいけないことである。

[追記：同日] この件は、実は裏があって、上に書いた対処は最適な手順や設定ではなかったようだ。まず、このサイトは知らない間に WordPress の管理画面上でマルチ・サイトとなっていて、/en で英語版のサイトが表示されるようになっていた。僕はこれを知らずに、単独のコンテンツだと考えてしまい、wp-config.php に「どういうわけか追加されている」マルチ・サイトの設定をコメント・アウトして、更にテスト用として IP アドレスを WordPress のドメインとして設定した（なので、管理画面上はドメインのままだった）。でも、外注さんがデータベースを触っていたときに、これを IP アドレスに書き換えたらしい。そして、その状況で DNS の A レコードを書き換えたから、アクセスのプロセスとしては、(1) ドメインによって DNS の名前解決を経て新サーバにアクセス、(2) ウェブ・サーバではドメインでのレスポンスを設定しているので、そのまま WordPress の DocumentRoot をコンテンツとして応答、(3) WordPress の設定ファイルによりドメインのコンテンツとして WordPress がレスポンスというぐあいだ。しかし、これだとマルチ・サイトが動かないし（WP_SITEURL を強制しているから）、データベースに格納されている IP アドレスの設定が有効になるとドメインとしてコンテンツを返さなくなる。こんなわけで、ウェブ・サーバの設定を変更するところはないが、WordPress の設定やデータベースの中身を WP-CLI などを使って調整している。

[追記：2026-07-23] 結局、昨日の朝５時に起きてサーバの入れ替えをやってから、なんだかんだとやって現在は翌日の深夜３時前である。僕と、ディレクターと、外注さんとであれこれと作業したり報告したりを Google Chat で連絡しているし（ディレクターと外注さんは SNS か Discord のようだが）、一回の応答に30分も１時間も間隔が空くので、こういう事案はたいてい長時間になる。ましてや、今回のように幾つかのトラブルが起きて原因がはっきりしないと、なおさらだ。いまのところ、僕だけ WordPress の管理画面にログインできないとか、マルチ・サイトの英語版だけアクセスできないとか、プラグインを管理画面でアップデートできないという問題があって、ひとまずプラグインはこちらで wp-cli で更新したが、最初の二つは良く分からない。そもそも僕が KUSANAGI を導入した時に WordPress のプロビジョンで設定した WordPress のユーザ情報を、外注さんがデータベースを移設した時に上書きしたらしく、ユーザ名も変わってしまっている。なので、いま外注さんがログインしてる情報をくれたら問題はないというのに、どういうわけかディレクターからもらう情報では全くログインできないのである。別に IP 制限とかもかけてないし、いまのところお手上げである。したがって、WordPress のマルチ・サイト設定を僕自身が管理画面で確認できないため、二つめの問題も対処しようがない。で、とりあえず WordPress のコア・システムも wp-cli で更新して、現状のバージョン情報を知らせてから１時間が経過している。

そういや、これまでにもサイトの制作とかリリースに関わってきて、たいていはディレクターから「これで作業は終了です」という通知が来た試しはなかった。だいたい、寝てるのか何なのか、早朝までこっちが起きて待ってても何の連絡もなくて、朝の９時頃に「じゃあ続きを」とか言われることが多い。自分が決断して作業を中断するなり終了すると関係者全員に伝えなければ、基本的にかかわっている人間はずっと待ってるし起きているということに想像力が働かないわけである。会社では仕方ないとしても、こういうことに疎いディレクターは、どんどん仕事を請けてくれる人が減ってくるのだが、この業界の状況を見ていると、困ったことに仕事を請ける人がいなくなったり、あるいは当人がディレクションについての欠陥に気づくまでには、だいたい定年して仕事をやめるくらいの年数がかかってしまったりするのだ。なので、その反省を誰も若い人に伝えないし、社内でも継承されない。そして、同じようなことが繰り返されてゆき、能力に欠けた人でも次から次へとディレクターとなって周りを振り回して退職するなり定年で辞めていくというわけだ。困ったものだが、もうあと数年でこんな業界とはおさらばするし、改善のために何か提案するような気分にはなれない。