まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

ワードプレス(WordPress)をよく使っています。個人でも業務でも。ブログというよりは、いわゆるCMS(コンテンツ管理システム)の機能を使ったサイトのプラットフォームとして利用することが多いです。まだまだですが、それなりに詳しくなってきたかなと自負しています。

CMS なのでファイルのアップロード機能などは普通に備えています。ただ「ワードプレスでファイルのアップロードができない」という質問は FAQ と化しています。ワードプレスでアップロードしたファイルはデータベースではなくファイルシステム内に格納(というか移動)されて保管されるのですが、この格納先ディレクトリはワードプレスの zip ファイルを展開しただけではできず、自分で wp-content/ フォルダの下に uploads/ という名前のサブディレクトリを作り、apache 等のウェブユーザーが書き込み可能な権限を設定する必要があります。大抵はこれで解決します。

そこまで設定しても「アップロードできない」ことはたまにあるようです。これもまだ FAQ といっていいレベルで、「WordPress アップロード エラー」あたりでググると、この問題に悩む人達がいかに多いかわかります。多くの場合はアップロードしようとすると「HTTP エラー。」というメッセージが表示されるようです。
wp_httperror00

原因はケース・バイ・ケースですが、プラグインの相性が悪いケースだとすると一度全てのプラグインを無効にしたら直ったとか、諦めて再導入したら直ったとか、色々試したけどそれでもまだ直らないとか、色んなケースがあるようです。特に注目したいのは最後のケースで、この問題は世に(ネットに)出回っている情報では解決出来ないケースが少なからずある、ということです。そういうのにぶち当たっちゃったら大変だよね・・・

なんて考えてたら、自分の所にも厄介なのがやってきました。何が厄介かって「以前は問題なくアップロードできていたのに、今アップロードすると100%失敗する」というもの。以前は動いていたんだから根本的な問題とは思えないが、今実際にアップロードすると常に「HTTP エラー。」になってしまいます。 念のためプラグインを全て無効にした上で試すなど、ウェブで見つけた情報を頼りに色々試してみましたが、解決には至りませんでした。


と、ここまでが今回のブログエントリの導入部です。ちょっとだけ WordPress に詳しくなった自分を試す意味も含めて、この「ググってもよくわからない」ケースを自力で解決すべく、WordPress の PHP デバッグを敢行してみました。以下はその結果として分かったことのまとめです。今回分かった原因と同じ原因で悩んでいる人がどれだけいるかわかりませんが、参考になれば。


まずは HTTPD のログをみます。アップロードが失敗するタイミングで /wp-admin/async-upload.php が HTTP コード 500 を返していることが分かりました。まずはこのファイルにデバッグライトを仕掛けて、、と。これを地道に繰り返して、どこでエラーが発生しているのかを特定していきます。
wp_httperror02

そして、エラー箇所をたどっていくと /wp-admin/includes/media.php 内の wp_read_image_metadata() 関数でエラーが発生していることを発見しました。
wp_httperror03

これ、WordPress のコア関数の1つなので、これがエラーと言われても・・・ と思いつつも、とりあえず Codex によると、この関数は /wp-admin/includes/image.php で定義されているようなのでこのファイルを開いて更にデバッグライトを埋め込んで・・・ 

ん?
wp_httperror01
 
なんと /wp-admin/includes/image.php のサイズが0バイト!そりゃここでコケるわな!


というわけで、今回の WordPress のファイルアップロードができない問題を自分の環境下で調査した結論としては、WordPress を構成するファイルの一部がたまたま壊れてしまっていたからでした。ファイルが壊れる原因は色々考えられるのですが、修正するには元のアーカイブなどから壊れる前の該当ファイルを取り出してコピーする、とかになると思います。それにしてもこれが原因だとすると、気付くのは結構たいへんだと思う・・・

そしてこういうことが起こっていると、ファイルアップロード時には(これも話をややこしくしてると思うけど)「HTTP エラー。」というエラーメッセージが表示される、ということも分かりました。このエラーメッセージはかなり汎用的に使われていて、必ずしも HTTP レベルでの問題とは思わないほうがいいかも。

なお、WordPress を導入したディレクトリから、
 # find . -size 0 -print
を実行すると、同じように何らかの原因でサイズがゼロになってしまったファイルの一覧を取り出すことができます。


WordPress のファイルアップロード時「HTTP エラー。」で悩んでいて、設定とかを見なおしたけどまだよく分からない、という場合は念のため調査してみるのもいいかもです。
 

「起動中の Amazon EC2 のインスタンスが消える!?」というオカルトな現象に2度ほど遭遇しました。

1度目はオペレーションミスか勘違いかと思ったんですが、2度あるとさすがに勘違いでは済まなくなります。

まあサーバーとしては実稼働中ではなかった(実はこれがクセモノだった、実稼働中ならもっと早く真相に気づけたかも)ので、深刻な状態にはならなかったのですが、この現象の正体を突き止めるべく調べてみました。


この怪現象はこんな感じ。Amazon EC2 にログインして、サーバーインスタンスを起動して使っていました(画面は管理コンソールです)。
2014010807


が、ある時に同じ管理コンソールを見てみると動いていたはずのインスタンスが消えています! まじかっ!?
2014010808


何がなんだかよく分からないけど、消えてしまったものはもう存在しないんだよね? それなら再度構成しないといけないのでインスタンスを作リ直して・・・ なんてやってました。

このインスタンスは本稼働前の準備段階のインスタンスだったので実際にユーザーがアクセスしたりしていたわけではないのです。その意味では「ああ本番前でよかった」と問題にはならなかったのですが、、 すごいオチが隠れてました。 みなさん、分かります?



以下、真相です。

まずサーバーインスタンスは消えたわけではなく、ちゃんとずっと動いていました。なので本来は作り直す必要もありませんでした。

ではなぜ管理コンソールから消えていたのか?

これは単に異なるリージョンを見ていた、ということでした。

上記図を再度見直してみます。最初のインスタンス稼働中の管理コンソール画面ではリージョンは US East(N.Virginia) に設定されていました。つまりこのサーバーはバージニア州のデータセンター内で動いていた、ということです。
2014010801

次にサーバーが消えたように見えた管理コンソール画面のリージョンは US West(Oregon) になっています。つまりこちらはオレゴン州のデータセンターを参照していて、そこでは(作ってないから当たり前ですが)何も動いていない、ということでした。
2014010804


そっかー。なんだ、リージョンが切り替わったのに気付かなかっただけか。 めでたし、めでたし。


・・・ところでいつリージョンが切り替わったんだ?俺は何もしてないぞ。 
管理コンソール見るたびにリージョンなんか意識してないし、こんなことが頻繁に起こってたら、いつか本当にやらかす可能性があるぞ。

で、このリージョン切り替わりの謎をずっと探っていたのですが、最近になってやっと分かりました。結論としては
 ・AWS のリージョン情報がブラウザのクッキーに残っていて、
 ・AWS アカウントを複数持っていて、適宜切り替えて使っていた
のが原因でした。

まず AWS のリージョン情報(らしきもの)はブラウザのクッキーに残っていました。console.aws.amazon.com のクッキーとして3つの(それぞれの用途はわかりませんが) "us-west-2" リージョンが記録されていることを確認しています。
2014010805


次に自分は業務用と個人用と、2つの AWS アカウントを持っています。同じPCの同じブラウザで、ログインユーザーを切り替えて使っています。

たとえば、まず業務用アカウントを使ってログインしているとします。この時は US-East リージョンにあるインスタンスを使っています。
2014010801


この状態でいったんログアウトします。リージョン情報はクッキーに残っているので、次回ログイン時のデフォルトリージョンは US-East になるはずです(なので同じ業務用アカウントでログインした時はこの続きの管理コンソール画面が表示されるはずです)。

ここで個人用アカウントに切り替えてログインします。リージョン情報がクッキーに残っていて、どうやらユーザーごとの制御はしていないようなので個人用アカウントでも US-East リージョンで管理コンソールが表示されます。
2014010802

この状態から新しくサーバーインスタンスをリージョン指定なしで作り、それが US-West リージョンで作成された場合(或いは US-East 以外のリージョンを指定して作成した場合)、当然ですがインスタンスは US-East リージョンではなく、US-West リージョン内に作成されます。そしてこのタイミングで管理コンソールのリージョンも US-West に切り替わります。実際にインスタンスを作成しなくても、このようなオペレーションが行われたと仮定して(手動で) US-West リージョンに切り替えておくと、この後の現象を再現できます。
2014010803

この状態で個人用アカウントはログアウトし、再度業務用アカウントでログインし直します。するとクッキーに残ったリージョンは US-West なので、業務用アカウントでは前回のログアウト直前まで US-East で作業していたにも関わらず、US-West の画面になります。リージョンが異なるので当然ですがそこには直前の画面にあった稼働中のサーバーインスタンスはありません(見えません)。 これが「消えていた」ように見えたわけです。
2014010804

これが世にも恐ろしい「Amazon EC2 のインスタンスが消えた!」現象の原因だったように推測しています。

AWS アカウントを複数持っている人は少ないのか、利用者はリージョンを固定して使っているのか、ググってもこの現象が発生している、という情報を見つけることができませんでした。

上のはあくまで推測にすぎないのですが、現にクッキーの状態も推測にあっていたので、あながち間違ってないのかな、と思ってます。





 

AWS(Amazon Web Services) から提供されているクラウドサービスのラインナップは数多くあります。個人的にはこれまで IaaS の EC2 に、EC2 を固定 IP アドレスで使う Elastic IP、そしてストレージサービスであり静的HTMLサーバーにも使える S3 を使う機会が多くありました。

データベースサービスである RDS に関しては、その存在は以前から知っていて、MySQL インスタンスをセットアップしてテスト的に利用したことはありました。が、この RDS のデータベースはデフォルトの文字コードが latin1 になっていて※、日本語データを扱うサービスとして使うにはその設定を(一般的には UTF-8 などに)変更する必要がありました。

※正確には character_set_server と character_set_database の設定値が latin1 になっています。

例えば普通のサーバー環境だったり EC2 環境であれば、MySQL のデータベースの文字コードは /etc/my.cnf を直接書き換えることで簡単に変更できます。MySQL インストール時の一連の作業の1つとして認識しているエンジニアも多いでしょうし、なので初期設定値は問題ではないと考える人も多いかもしれません。

ただ今回は Amazon RDS という特殊な環境です。EC2 と違って SSH で直接ログインして /etc/my.cnf を編集して・・ というわけにはいかない状況です。でも日本語データを扱う上では必須な変更です。さてどうするか?

Amazon RDS ではパラメータグループという概念でこの問題を解決しています。/etc/my.cnf を直接編集することは許されていませんが、このパラメータグループの中で利用する文字セットをあらかじめ(UTF-8 などに)指定した上で、データベース作成時にそのパラメータグループを使って作成する、という方法で UTF-8 のデータベースを利用することができるようになります。

しかし、このパラメータグループの作成や編集をするには、これまでは Amazon から無料提供されている Amazon RDS Command Line Toolkit というコマンドラインツールをダウンロード&導入(更に導入の前提として Java 実行環境が必要だったりする)して、このコマンドラインツールからコマンドを実行するしかありませんでした。

要は「RDS で日本語データを扱う」というただそれだけのことが、できないことはないけど色々面倒だったわけでした。


が、最近になって改めて RDS を使った時にこのコマンドラインツールを使わなくても日本語環境を整えることができるようになっていたことに気付きました(いつからだろ??)。設定ファイルを直接書き換えるような方法と比べるとまだちょっと面倒ではありますが、コマンドラインツールはもう必須ではなく、同様の処理がウェブのUIからも可能になっていました。

その設定方法と内容は以下の通りです。Amazon RDS のウェブコンソールから "Parameter Groups" を選択します。標準で "default-mysql.5.x" という名前のパラメータグループがありますが、これを使うと文字化けから逃れれられなくなります。そこで "Create DB Parameter Group" ボタンをクリックして新しい日本語用のパラメータグループを作成します(ここではパラメータグループの名前として "prod" と指定したとします)。

作成したパラメータグループの "Parameters" 以下にそのパラメータと設定内容が一覧で表示されますが、その中の character_set_database と character_set_server の値としてどちらにも utf8 を指定して保存します。これで UTF-8 用のパラメータグループが作成できました。
2014010501


そして今作成したパラメータグループを指定して新たにデータベースインスタンスを作成します。ウェブコンソールの Instances を選択後に "Launch DB Instance" をクリックして新規にデータベースインスタンスを作成します。
2014010502

DBの種類や名前、DBサイズなどを指定していった後の "Step 4: Additional Config" の段階になると、作成するデータベースインスタンスのパラメータグループを指定する箇所があります。ここで先程 utf8 を指定して作成したパラメータグループの名前(この例では "prod")をプルダウンから選択します。これで character_set_database と character_set_server の値が latin1 ではなく utf8 に設定されたデータベースインスタンスを作成するよう指定したことになります。後はこのまま進めてデータベースを作成します。
2014010503

こうして作成したデータベースインスタンスの文字セットを確認するとこのような感じになりました:
2014010504

なぜかまだ character_set_database の値はまだ latin1 のままですが、character_set_server の値は utf8 に変更できました。ここまで出来てしまえばこの状態から SQL コマンドで

> create database XXXX default character set utf8;

で新たに UTF-8 のデータベースを作成してしまえばいいだけのことです。

ちょっとまだ面倒な所はあるけど Amazon RDS で日本語データベースを作成するためだけに Java 環境を整えた上でコマンドラインツールを導入、という必要はなくなったように思えます。

Amazon RDS はバックアップ付きリレーショナルデータベースサーバーとして気軽に(条件次第では無料枠内でも)使えて便利だったのですが、この日本語環境の構築に難があった、という印象でした。いつの間にこのUIがウェブコンソールに付いたのか不明ですが、これなら利用上のハードルはかなり下がったかな。




このページのトップヘ