WordPress on Microsoft Azureの料金

wpazure6

フフフ、ネタが降ってきた (;´Д`)

とは言っても、まだ始めたばかりですが、参考にどうぞ。

wpazure7

ちょっと補足すると、トラフィック5GB(送信)までは、課金されません。まだまだ0.15GBですね。それとは別にコンピューティング課金が行われていて、これは「共有」なので従量課金ですが、単純に使用時間で積算されるので、208時間・276円という事です。そして、ここには表示されていませんが、ClearDBは無料の20MB枠なので0円。つまり、これが使用7日目での実績ですね。但し、WordPress.comからトラフィックを転送したのは21日からなので、今後どうなるかな?

トラフィックが予測可能なら、非常に使いやすい便利な計算機があります。

wpazure8

WordPress on Microsoft Azure

というわけで、wordpress.comでホスティングしていたブログを、Microsoft Azure WebSitesに引っ越しました。合わせて、保有しているドメイン名で引けるようにしました。
同じような事を考えている方は参考にどうぞ。

カスタムドメインの導入は完全無料ではありません

カスタムドメインをWebSitesに導入するには、「共有」プラン以上にする必要があります。Azureの有料プランは従量課金であるため、趣味のサイトをAzureでホストすることに抵抗があるかもしれません。もっとも、大してPVが伸びないことが分かっているのであれば、定額ホスティングとさして違いは無いように思います。この辺りは、痛い事があれば別のホスティングに移せばいいや的に、楽観視しています。

カスタムドメインの導入は簡単

やることは2つだけ。一つは自分が所有するDNSサーバーのレコードに、CNAMEで「kekyo.azurewebsites.com」のようなWebSitesへの標準FQDNを追加します。もう一つは、Azureの管理ポータルから「カスタムドメインを管理する」で、ドメインを追加します。
wpazure2
wpazure1

トラブル発生

実は、今回の引っ越しはもっと前に計画していたのですが、Azure上でWebSitesが追加できないというトラブルに見舞われて、遅れていました。大分以前から「kekyo.azurewebsites.com」で何度か構築・破棄のテストを行っていたのですが、どうもその時にAzureデータセンター側で何か問題が発生していたようで、今回の移行の際にこの名前でWebSitesが生成出来なくなってしまいました。

新規に生成しようとすると「プロビジョニングに失敗しました」というエラーが発生して、生成できないというものです。

wpazure3

このエラー、検索すると若干ですが事例があり、「しばらくしたら直った」的な、どうにも煮え切らない回答が。

何しろ、まだ何か行う前段階であり、このアカウントで他のサービスも使っておらず、エラーメッセージもこれだけでトラブルシュートも出来ず、「何をどうすりゃいいんだ?」という状態で困ってしまいました。
仕方が無いので、サポートを依頼しようとするものの、無料枠インシデントの要因にはこのような問題を直接指定するものがなく、何となく暗雲立ち込めつつも、サブスクリプションに対する問い合わせでやってみました。

が、技術的な内容の問い合わせは、有料インシデントとなるという回答… うーん、まだ使用も始まってなく、こちらに落ち度があるとは思えないのですが。もやもやしましたが、Azureでホストするというのは決めた事なので、サポート契約を行いました。

サポート契約と聞いて、仕事でもないので「もう駄目ぽ」と思ったのですが、念のため料金を確認すると「三千円(3,194)」ということで、「あれ?一桁間違っていないか?」と見直すと、更に「一か月間」とあります。これ、従来のテクニカルサポートインシデントと比べると「激安」じゃないのか?!

仮に一回三千円でも、個人では抵抗が大きいかもしれない(「これにて、以上!」とか言われて終了したらガクブルかもw 実際にはそんな事は無いんですが)けど、一か月間何度でもOKとなれば、これはかなり抵抗感が薄いと思います。加えて、MSの有償サポートはとても良い範囲に入ると思います。

と言う事で、調査すること一週間で、どうもデータセンター側のデータに古い情報が残っていて、これが原因でエラーが発生していたとの事(あるあるだ…そして予想通り)。この情報を手動削除するよりも、現在展開中の新しいポータルサイト(プレビュー)からWebSitesを生成すると回避可能との連絡が。プレビューサイトの見た目は洗練されているけど、何をどう操作すれば良いのかいまいち分かりにくいため、まだあまり使っていませんでした。

早速プレビュー版のポータルサイトからWebSitesを作成したところ、今度は問題なく生成完了!やっと先に進むことが出来ました。生成が確認出来たので、インシデントはクローズ。一応担当の方は、MS本社にも問題(これは有償案件なのか?)を掛け合って頂いたそうですが、どうしても覆せなかったこと、改善すべき事として検討しますとの回答だったので、今後に期待する事にしました(確約して頂いた訳ではないので、この件でゴリ押しはしないで下さい)。

WordPress日本語版がテンプレートから簡単に生成出来る

wpazure6
Azure WebSitesの生成時に、「WordPress日本語パッケージ」というテンプレートを使う事ができます。これを指定して、SALTキー文字列を適当に入力するだけで、あっという間にWordPressサイトが生成出来ます。zipで持ってきて展開してFTPでアップロードして云々とか面倒な作業は不要です。
もちろん、独自にコードをいじりたい場合は、FTP/SFTPで接続して直接編集する事も出来ます。

Azure特有のポイント

まず、データベースは「ClearDB」という、サードパーティのMySQL PaaSを使います。無料枠で作る場合は、こちらのサービスも無料枠で20MBを1DBだけ割り当てる事が出来ます(Azure WebSitesが有料枠でも、ClearDB無料枠と組み合わせ可能です)。但し、WebSitesをホストする同じ地域で割り当てないと、地域間通信に課金されてしまいます(確かテンプレートで生成した場合は、自動的に同じ地域になった気がします)。

20MBというのは、ディスク容量に比べると極端に小さいのですが、画像ファイルなどはディスクに格納されてDBには入らないので、すぐに埋まるという事も無いでしょう。

ClearDBへの接続についてもポイントがあります。少し前にリツイートしたのですが、ClearDBへの接続回数が多いと、スロットリングを受けてしまうようです。WordPressの現在の実装(3.9.2)は、MySQLへの接続が非プールらしく、これを改造しないと制限に引っかかってしまいます。

で、ソースコードを手で変更するのも面倒(自動アップデートされると元に戻ってしまう)事もあり、Azure WebJobというジョブ機能で定期的に修正を試みるのを推奨していたのですが、やり方は書いてないw

WebJobについて調べ始めると、これはこれでシンプルで面白い機能だと思ったのですが、ここで「そもそもAzureでWordPressのホストは珍しいわけでもないんだから、WordPressのプラグイン無いだろうか?」と思って検索するとありました!

wpazure4

「Persistent database connection updater」です。しかもMSOT謹製でした。そうだよねぇ。

もう一つの問題は、AzureはSMTPのホスティングをやって無いって事です。これは仕方が無いので、外部のSMTPサーバーに任せます。私はoutlook.comのSMTPに投げさせるために、「WP-Mail-SMTP」というプラグインを使いました。SMTPサーバーを指定するだけです。これで、WordPressからメールを送信する場合でも行けます。

wpazure5

あと、出来れば通信による従量課金を減らしたいですね。WordPressに「JetPack」プラグインを導入すると、「Photon」というCDN機能が使えるようになります。これは、WordPress.comがCDNホストとなって、画像や動画を配信してくれるという嬉しい機能です。ぜひ有効化しておきましょう。

その他

Azureに絡む話はこのぐらいで、あとは単純な引っ越しの問題が残りました。投稿中のコードは、現在も無残な状態です。インポートプラグインが悪いのかもしれません(WordPress推奨なんですががが)。投稿数を考えると、手で直すかどうか迷う所。あとは、テーマの微調整かな。Twenty Fourteenは一見クールなんですが、余白あり過ぎで、テクニカルな記事にはあまりマッチしてない。画像の配置も違和感ありまくり orz
cssをいじって調整中です。

素人の Per-Monitor DPI

先日、開発用のデスクトップPCを新調しました。その際に、話題の4KモニターDell UP2414Qを追加しました。

dell-up2414q-overview1

T221と比較してDisplayPortで接続出来るので、母艦のインターフェイスに悩まなくても済みます(実際は悩んだんですが、それはまた別の機会に)。また、60Hz行けるのが良い点です。

で、これをUXGAのL200Pと縦に並べました。

PerMonitorDPI1

下がUP2414Q、上がL200Pです。ここからが面白い。
Internet Explorerを下から上にドラッグして移動します。

PerMonitorDPI2

2台のモニターは解像度が違い過ぎるため、ドラッグ中のウインドウがL200P側ではみ出てしまっています。また、解像度が低い分、IE上のテキストや画像も物理的に大きく表示されています。ただ、違和感はありません。元々解像度が違う事を分かっているので、大きくなってしまうことは予想出来ます。そして…

PerMonitorDPI3

L200P側に半分以上?移動すると、このようになります。一瞬、「えっ?」と思うのですが、いきなりIE内のコンテンツが縮小され、しかし、ウインドウの外郭のサイズは変わらないため、妙に縮まって見えます。

これは、「Per-Monitor DPI」というやつかな。どれどれ、実測してみるか。

PerMonitorDPI4

UP2414Q

PerMonitorDPI5

L200P

少しサイズが違いますが、おおむね同じサイズとなるように、ピクセルが縮小されているようです。サイズが違うのは、L200PからDPIが供給されていない可能性があると思います。

さて、コンテンツだけを注目すると、非常に良い機能です。が、この「コレジャナイ」的な違和感… ウインドウの外郭も縮小されたらパーフェクトだったかもしれません。

… いやいや、本当にそうだろうか?

ウインドウの外郭クロームは、ずっと固定的なピクセルサイズを基準に運用されてきたので、今更これが変わるのは微妙かもしれません(見れないので分かりませんが)。

ウインドウの外郭に違和感を感じるのなら、ストアアプリならどうかなと思い、テストしてみました。

PerMonitorDPI6

UP2414Q

PerMonitorDPI7

L200P

これは素晴らしい!同じアプリケーションでありながら、極端に異なる解像度のモニターでも、表面的な違いはほとんどありません。そして、4Kモニターであれば、細かい文字も美しく描画されています。

PerMonitorDPI9

UP2414Q

PerMonitorDPI8

L200P

もちろん、デスクトップアプリにおいても「最大化」して使用すれば、ストアアプリとほぼ同じ結果が得られます(Per-Monitor DPIに対応していれば、です)。

このような事もあり、両方のモニターを同じ目的で使うつもりだったのですが、L200P側ではストアアプリ(主にNeuroniaとFacebook)を動かしたままで配置し、4Kの方で通常の作業を行う、という使い方に落ち着きました。2画面(又はそれ以上)のモニターをどれも同じ目的で使おうと考えている場合は、やはり同じモニターで揃えたほうが良さそうですね。

なお、Per-Monitor DPIについては、以下の記事が参考になると思います。

4大(?)ブラウザーの High DPI 対応 (だるやなぎさん)
アプリの高DPI(High DPI)対応について 第1回 ~ 高DPIとは ~ (田中さん)