趣味のAzure Websitesでパケ死必定?!・自腹課金の現実 – JAZUG名古屋@3碧目 ~ツナガレJAZUG 4周年!~

「趣味のAzure Websitesでパケ死必定?!・自腹課金の現実」というお題で登壇してきました。

イベントはこちら:DoorKeeper: JAZUG名古屋@3碧目 ~ツナガレJAZUG 4周年!~

先日のWebSitesへのブログ移行(つまり、今見ているこのブログ)のお話です。

プレゼンはこちら:趣味のAzure Websitesでパケ死必定?!_2.pptx

ご清聴ありがとうございました。またよろしくお願いします m(_ _)m

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をいじって調整中です。

「de:code報告」 – Microsoft Azure 勉強会

JAZUG名古屋で、Microsoft Azure勉強会が開催されました。ATNDはココです。
私は、先週の「de:code報告」というお題目で、セッションを行いました。

今回は、de:code遠征の成果、のような内容で発表を行いました。
そのため、コードレベルの内容は無しですが、楽しんで貰えたでしょうか?

早速次回の予定が組まれたりと、活発なJAZUG名古屋をよろしくお願いします。

プレゼンはココです。

それでは、また。

SignalR ブートキャンプ on Windows Azureイベント

地理冗長の中心でAzure愛を叫ぶ (名古屋で、Windows Azure ローンチ4周年とJapan Geo誕生を祝うイベント)

という、中部圏のWindows Azureイベントが開催され、登壇してきました。
私のお題は、「SignalR ブートキャンプ」で、SignalRを使った通信の取り掛かりの解説といった内容です。OWINについてもさらっと取り上げています。

本当は、開催と同時にプレゼンとコードを公開したかったのですが、ちょっと未整理が過ぎたので、後日公開のお約束をさせていただきました。で、本日公開いたします。

この発表のハイライトは、ホワイトボードアプリのデモでした。発表中に、実際にAzure上にホストされたサーバーとクライアントアプリ(SilverlightとWPFによるClickOnce、そして今話題沸騰中のWindows Phone :-) をSignalRで接続し、リアルタイムにホワイトボード共有を実演しました。

#クラウディアさんの分身にはお世話になりました
#ライブコーディングは今後の課題ということで(汗

プレゼン作成中はもちろん検証しているのですが、実際に多人数から同時に使用されたのは初めてで、ぶっつけ本番でしたが、何事もなくほっとしています。と同時にあっさり動いてしまう所が、Windows Azure、本当に魅力的です。

プレゼンです:SignalR ブートキャンプ

コードはGitHubで公開しました:AzureSignalRDemonstration

イベント終了後の懇親会も盛り上がりました!
今回のAzureデータセンター日本リージョン開所記念で、Japan Windows Azure User Groupの中部圏「JAZUG名古屋」もお披露目されました。

また、MiCoCiは中部圏のWindows系技術勉強会の開催などやってます。興味のある方はDSTokaiカレンダーあたりをチェックしてみて下さい。

近日では、Bar Windows Azureの開催を計画しています。

それではまた!

Windows Azure Compute Emulator + IIS Expressで外部IPからの要求を受信可能にする

Visual StudioでWindows AzureのWebロール開発をする場合、プロジェクトテンプレートから生成すると、普通にIIS Express+Compute Emulatorでの開発・デバッグを行うと思います。

この時、Webプロジェクトのデバッグ設定でIIS Expressを使い、”localhost”+ランダムなポート番号を割り当て、Webプロジェクトそのものでデバッグを開始すると、その通りのバインディングで要求を受け付けるのに、Cloudプロジェクトからデバッグ実行すると、何故かポート番号が「81」とかに勝手に強制されたり、localhost(127.0.0.1)以外のIPアドレス・インターフェイスからの要求を受け付けない等で困ったことが無いでしょうか?

私の中でも長らく謎でしたが、業を煮やして調べることにしました。
(なお、現在のWindows Azure SDKは2.2です)

というのも、Windows PhoneからIIS Expressに接続させるようなアプリをデバッグする場合に、WP7までのエミュレーターは、WP内ネットワークのシミュレートを、ホストマシンのネットワークに直接バイパスする機能があったため、WPから「localhost」の指定でIIS Expressに問題なく接続できていました。

WPEmulatorNetwork

ところが、WP8になってエミュレーターがHYPER-Vベースになった関係で、ネットワークシミュレートは単にHYPER-Vの仮想スイッチへの接続となってしまい、ホストマシンのIPアドレス(又はホスト名)を指定しないと接続出来なくなったのです。すると、そもそもIIS Expressはデフォルトでlocalhost以外のインターフェイスをバインドしていないため、全く要求を受け付けず、デバッグ出来ません。

また、Cloudプロジェクトでデバッグを開始すると、ポート番号が勝手に変更されるだけでなく、何で「80」じゃなくて「81」(又はその付近のポート番号)に強制されるのか? ですが、WindowsのIIS(IIS Expressではなく)が80を使用している事によって引き起こされるようです。

これは想像出来たものの、ややこしすぎる orz

で、環境の都合などどうでもいいので、ちゃんと指定された通りに動いてほしい。元々ランダムなポート番号を使うのだから、そのまま素直に使ってくれれば良いでしょ?というのが動機です。

具体的には、以下の対応を行います。

  1. Visual Studioは「管理者権限」で起動する
    正確には、IIS Expressを管理者権限で起動すれば良いのですが、デバッグ時はVSから起動するので、VSを管理者権限で起動します。その理由は3へ。
  2. ファイアーウォールに穴をあける。HYPER-Vからは仮想スイッチ経由で接続されるので、穴があいている必要があります。セオリー通り、最初はファイアーウォールをオフで試して、全て確認できたら明示的に穴を開けるという手順で行きましょう。
  3. IIS Expressの構成ファイルのサイトバインディング情報を「手動修正」して、すべてのネットワークインターフェイスでリッスンさせる。localhost(ループバックインターフェイス)だけではなく、全てのインターフェイスでリッスンを行うためには、「管理者権限」が必要です。これが1の理由となります。そして、IIS Expressの構成ファイルを修正しますが、パスは「マイドキュメントIISExpressconfigapplicationhost.config」です。sitesタグ内のbindingInformation属性を修正します。デバッグ中のサイトに対応するsiteエレメントを探してください。
<site name="AzureServiceSample" id="23">
   <application path="/" applicationPool="Clr4IntegratedAppPool">
      <virtualDirectory path="/" physicalPath="C:PROJECTAzureServiceSampleAzureServiceSample" />
   </application>
   <bindings>
      <binding protocol="http" bindingInformation="*:45934:" />   <!-- ココ -->
   </bindings>
</site>

CloudProjectProperty

上の例の「bindingInformation」属性に、「*:45934:」のように、コロン2個で区切られた文字列を指定します。左側はバインドするインターフェイスに対応するIPアドレスを指定(今回は全てのインターフェイスでリッスンさせるので、アスタリスク)、中央はポート番号、右側はホスト名(HTTPヘッダのホスト名に対応し、マルチホーム識別に使うもの)です。上記の例は単純に、すべてのインターフェイスをリッスン、ポート番号として45934、マルチホームは使わない、と言う事になります。

そして、CloudプロジェクトでCompute Emulatorとセットでデバッグする場合は、このように「Webプロジェクトポートの使用」をTrueに変更します。これで、Cloudプロジェクトデバッグ時も同じ構成(ポート番号)でデバッグ出来ます。

所で、Cloudプロジェクトでデバッグを開始すると、「applicationhost.config」ファイルは上記のパスではなく、テンポラリフォルダに生成されたファイルを読みに行きます。そのため、このファイルを手でカスタマイズしていると、Cloudプロジェクトのデバッグ実行では全く反映されず、これまた悩みます。XMLなので手で簡単にいじれます、が、実際には触れないと言う事です。

WindowsFirewallInboundUnblockRule

ファイアーウォールに穴をあける場合、Windowsファイアーウォールの「受信の規則」で、このような感じでリモートIPアドレスを普段の社内・宅内ネットワーク・あるいは固定IPならそのアドレスに絞り込んでおくと良いでしょう。本当はポート番号も絞りたいところですが、ランダム番号なので、プロジェクト生成時に毎回メンテナンスしなければならず、不便です。もちろん、これは開発時かつ安全な環境である事が前提です。

これで、以下のようにクリーンな開発が出来ます。

  1. 空のWebプロジェクトを作って、一から実装する(ウィザードが作る余計なコードを除外)。
  2. このWebプロジェクトで普通にIIS Expressで普通にデバッグして完成させる。
  3. ここで初めてCloudプロジェクトを追加。
  4. Cloudプロジェクトからデバッグ実行して、Compute Emulator+IIS Expressでも全く問題なく動作する事を確認。
  5. デプローイ!!!

ちなみに、今回はクライアントをWindows Phoneエミュレーターとしましたが、例えばWPの実機や、WCFを使うWPFやWinFormsのクライアントでも、全く同じ手順で問題を回避出来ます。

自分の覚書を兼ねて書きましたが、正直もうちょっとフレンドリーであって欲しいと思います(次回また忘れそうだ)>VS