簡易アップローダ

/ Azure

image
ふと思い立ってAzure上に簡易アップローダを作成。

構成としては、Azure Websites改めWep Apps上にASP.NET MVC 5で作ったWebアプリを配置してAzure Blob Storageに対して読み書きする、といった感じ。
そもそもASP.NET MVCを触ったことがなかったのですが、とりあえず適当にModelを定義して、Controllerの中で適当なデータを突っ込んで、Viewで表示してみたらば、案外あっさり表示されたので一安心。
あくまで「簡易」なので、単一ページ構成でUpload、Download、Deleteのアクションは全部抱え込み。
コメントやら実ファイル名やらはBlobのメタデータに突っ込んで管理するようにしたので、データベースも必要なしということでまさに超簡易。
デザインはデフォルトでBootstrapが使えるようになっていたので、リファレンスとにらめっこしながら必要最小限のUIを書いて完了。
セキュリティはBASIC認証でお手軽に済ませたかったので、こちらのエントリを参考に諸々設定。
カスタムドメインを使わなければSSLが標準で使えるのはAzureのメリットのひとつかもしれません。
ちなみにログインユーザごとにBlobコンテナが切り替わるようにしたので、さりげなくマルチテナント対応です。

とりあえずローカルで一通り動くようになったので、Azureにデプロイ。
既存のWebサイトに相乗りさせるのは面倒そうだったので、専用のサイトを新規作成して、いざ「発行」。
特にエラーが出ることもなく、あっさりAzure上で動作するようになりました。
VS2013では初めてのAzureデプロイだったのですが、なにげに進化してる模様。
とっつきにくい印象だったASP.NET MVCもごく基本的な部分だけとはいえ少し触れたので良い経験になりました。

なお、モノ自体は業務利用する予定のため、非公開とさせていただきますw


WordPress on Azure

/ Azure, Diary

しばらく前にxreaからAzureウェブサイトに移動した弊社サイト。
見ての通りWordPressで作っているのですが、Azureに移してからやけに読み込みというか接続が遅くなってしまいました。
何とかならないものかとAzure側の設定をあちこちいじったり、リージョンを変えてみたりしたものの、ほとんど変化なし。
年も明けたことだし、少し真面目に対処しようかと、まずはMySQLデータベースの置き場所をデフォルトでフリー提供されているClearDBから自前のものに変えてみることに。
自前といっても、同じAzureの仮想マシン上でMySQLサーバを動かすというもの。
簡易作成で選択できるWindows Server 2012 R2 DatacenterのVM作成が30分程度で終了した後、リモートデスクトップで接続、MySQLのモジュールをダウンロードしてインストール、適当なデータベースを作ったらあらかじめエクスポートしておいたWordPressデータのクエリスクリプトを実行して無事に復元完了。
あとはwp-config.php内のデータベース接続情報を書き換えればDB参照先が変更されて準備OK。

さて、これで速くなれば良かったのですが、結果はといえば全く効果なし。
実は事前にローカルのMySQLクライアントからClearDBに接続してみたところ、別段接続に時間がかかる様子はなかったので遅い原因は別にあるという予想はしていたのですが、まぁ見事に予想通りの展開。
仕方ないので他の原因を考えてみたところ、やはりWordPressが遅い原因の定番とも言えるプラグインの仕業ではないかという疑惑が浮上。
あれこれ調べているうちにDebug Barなるプラグインを使えばWordPressの性能調査的なことができるという記事を見つけたので試しに入れてみたところ、出るわ出るわ鬼のようなエラー、その数ざっと2000程度…orz
よく見るとどれも同じようなエラーで、コンタクトフォーム(Contact Form 7)で使っているReally Simple CAPTCHAの作業フォルダでアクセス拒否が発生している様子。
試しに一旦CAPTCHAプラグインを止めてみるとエラーは出なくなりレスポンスも劇的に改善。
そんなこんなでようやく原因は特定できたのですが、この謎のアクセス拒否が気になるところ。
FTPで該当ファイル/フォルダの削除を試みるもこれもアクセス拒否。
しかしながら移動はできるようなので、とりあえずリネームしてから適当な場所にフォルダごと移動して放置w
アクセス拒否の原因は今のところ不明ですが、その後CAPTCHAを有効化してもエラーは出ることなく無事正常な状態に戻りました。
改善したとはいえ、正直あまりレスポンスはよろしくなかったりしますが(表示開始までに2-3秒程度かかる)、しばらくこれで様子を見たいと思います。

Azureの仮想マシンは今回初めて利用したのですが、セットアップがエラく簡単で感動しました。
インターネット越しであることと割り当てメモリが少ないせいか操作速度は少々重めですが、ちょっとしたテスト環境構築などには便利に利用できそうです。
MSDN SubscriptionユーザなどAzureの無料枠をお持ちの方は一度試してみる価値はあるかと思います。


サイトリニューアル

/ Azure, Diary

image

見ての通り、本Webサイトのテンプレをちょろっと変えてみました。
Windows Phoneからの流入比率が高めなこともあるため、いまどきのレスポンシブデザインに対応したテンプレを探した結果、Bootstrapベースのものがあったのでこちらを採用。
Azure Webサイト上で新規にサイトを起こしてチマチマと移行作業をしていたわけですが、元のテンプレをごちゃごちゃいじっていたこともあってすんなりとはいかず。
デザイン的にどうにもパッとしない感じだったのでしばらく放置していたのですが、いつまでも寝かせておいてもしょうがない、ということで、とりあえず公開してみることにした次第。

ちなみにAzure Webサイトは今回初めて使ってみたのですが、Wordpressの設置もワンタッチで出来てなかなか便利。
無償枠をお持ちの方は試してみると良いかもしれません。
また、プレビュー版の分析ツールがやけに凝った作りなので、こちらも一見の価値あり。


テーブルの日付検索

/ Azure

ここ最近、Windows Phone向け電力使用率アプリのダウンロード数が微妙に増えてきたので、久しぶりにAzureに配置しているプッシュ通知用のマスタテーブルを覗いてみたところ、登録者数が少し前の倍程度まで増加。といっても、アクティブユーザは40人程度なのですがw
冬の電力需給の関係で、関西、中部のCSV提供が復活したせいだと思いますが、お役に立てていれば幸いです。

日頃、Azureテーブルストレージの参照/編集にはAzure Storage Explorerのお世話になっているのですが、件のプッシュ通知マスタデータの状況を少し絞り込んで見たかったため、長いこと謎のまま放置していた、日付による検索方法を調べてみることに。
マニュアルをみると「LINQ query and query for entities」が指定可と書かれているものの、細かい指定の仕方については端折られているので肝心の日時の指定方法は分からずじまい。
仕方ないのでググってみたところ、何やら特殊な日付指定の方法を発見しました。

日付の部分はW3CDTFという標準的なフォーマットに対応しているようですが、それに加えて先頭に「datetime」を付与するのがポイント。
まぁ、きちんとした分析がしたいのならStorage Explorerで普通にエクスポートすればいいんですがw


ところで、暮れも押し迫ってきているなか、Windows Phoneアプリの新作を本日申請。
ここしばらく細々としたバージョンアップに明け暮れていたので、新作は久しぶり。
すんなり審査が通ればちょうどクリスマス明け頃の公開になるかと思います。


Tableストレージ

/ Azure

はたしてどういうレベルで書けばいいのか悩ましいところですが、Azureストレージの話。

Windows Azure PlatformにはRDBMSに代わるデータ保存用のストレージサービスが提供されていて、それを「Azure Storage」と呼びます。
これとは別に「SQL Azure」というSQL Server互換のRDBMSも利用できるのですが、どちらかというと既存アプリのクラウド対応を促進するために用意されたもの、といった印象で今のところは本筋ではなさげ。クラウドのメリットのひとつでもあるスケーラビリティが失われるのが大きいと思われます。まぁ、単純にデータベースが巨大になると重くなりますからね…。

話を戻して、Azureストレージですが、マトモに触ったのは今回のAzumeが初めて。
といっても、Table、Blob、Queueと3種類あるうちのTableしか使っていないので、今回はTableにまつわる雑感をば。

Tableストレージというのは、NoSQLの一種で、いわゆるKVS(Key-Value Store)タイプのデータ格納領域です。
スケーラビリティがあって、読み書きのスピードも速くて、というアレ。
その代わり、結合や集計などはできないので、別途アプリ側に実装が必要です。
TableストレージにはPartitionKeyとRowKeyの組み合わせでユニークなキーとなるようにデータ格納していきます。
Table内のレコードには追加/更新時に自動的にTimestampがセットされるので、これにより楽観的排他制御が可能となります。
トランザクションはPartitionKey単位に扱われるようで、PartitionKeyが同一の複数レコードを一括更新しようとした場合、一件でも更新に失敗した場合は全データの更新がロールバックされるようです。
これはスケーリングの話とも絡んでいて、PartitionKeyが異なるデータは物理的に同一の場所に存在する必要はないため、データが多くなってくるとPartitionKey単位で自動的に分割されたりするようです。

面白いのは、前述の必須プロパティ以外はレコード毎に自由なレイアウトを設定できることで、やろうと思えばひとつのTableに全ての情報を突っ込むこともできてしまいます。
結果的に、あるキーでは値が入っていたプロパティでも、別のキーでは値が空っぽ(null)だったり、という状況が発生しますが、その辺りの管理は参照/更新するアプリケーションにお任せ、という考え方。
試しに、Table上のあるプロパティにレコード毎に異なるデータ型の値を入れてみたところ、特に問題なく格納できる様子。(ただし、開発時に利用するAzure SDK付属のDevelopment Storageで同じことをやるとテーブルが開けなくなるようなので要注意)
あるアプリケーションではint型で使っているプロパティを、別のアプリケーションではDateTime型で使う、などといったトリッキーなことまでもができてしまうということで、中に何が入っているか分からない、という意味ではまさに純粋な入れ物といった感じですが、アプリケーションと一体化していて単体では制約すらかけられない様は、DOA志向な技術者からみるとイケてないように思えるかもしれません。
個人的にもRDBに比べるとデータの独立性が損なわれている印象は否めませんが、結局は用途の問題ということになりそうです。
RDBを単なるISAMとして使っているシステムも巷にはごろごろ転がってますしw
ちなみに、Azumeの場合はアカウントマスタと休日マスタ、それとユーザ別の勤怠データをそれぞれテーブルとして分割しています。

WCF経由でアクセスする場合はTable上のプロパティ名がそのままC#やVBのプロパティ名としてクラスを作ってアクセスすることになりますので、キー毎のスキーマ定義=エンティティクラスの作成という作業となります。
また、Tableストレージそのものというか物理的には常にnull許可の状態なので、論理的にnullを許容するかどうかはエンティティクラス内のプロパティ型がNullableかどうかで決まってきます。

アクセスの方法ですが、基本的にはLINQで必要なデータを抽出して使うイメージになります。
キー以外のプロパティによる抽出もやればできますが、前述のトランザクションの関係もありますし、パーティションを跨った検索がご法度というのは常識レベルの話だと思いますので、PartitionKey(あるいは+RowKey)の抽出条件は必須と考えたほうが良いでしょう。

いずれにしても、Tableストレージの利用に際してはキー値の設計がポイントになりそうです。
ちなみにAzumeでは、アカウント登録の際にランダム文字列を生成して、これを個別の勤怠データのTable名およびPartitionKeyとして使っています。
本来ならアカウント毎に勤怠用のTableを用意する必要はないのですが、万一Tableが壊れた場合の被害を最小限にするために個別に分けてあります。

長くなってしまったので、ひとまず今回はこの辺で…。