2010年に年を越してしばらくした頃、以下のような記事を見つけました。
FeliCa & Adobe AIR/Adobe Flash アプリケーションコンテスト開催のお知らせ！ « SDK for AIR/Flashブログ
お題はFeliCaを使ったAIRかFlashのアプリケーションで、技術的に優れているか、アイデアのユニークさなどを競うというものです。面白そうなので、やってみないかとflashcastのメンバーに投げかけてみたところ、いくつか良い案が挙がってきたました。期間もあまり無かったのですが、アイデアで勝負！ということで、チャレンジしてみることにしました。
採用したのは、ろっきー案の「FeliCaで相性占い」です。
2つのおサイフケータイから、IDｍというFeliCaに一意に振られる（といわれている）キー情報を取得し、その組み合わせから相性占いをするといった、ゲーム感覚のアプリケーションです。
パソコン搭載型FeliCaポートか、USBで接続されているパソリにおサイフケータイを1台づつかざしていきます。2つのIDmを検知したところで相性占いを開始し、その結果を表示するためのURLをおサイフケータイに送信します。後は、おサイフケータイで、そのURLにアクセスすると相性占いの結果が見れ、その結果とともにコメントを携帯サイトに残すことができるという一連の仕組みになっています。
詳細はこちらをご覧ください。
アプリケーションの構成は、おサイフケータイを検知したり、URLをおサイフケータイに送信したりする「AIRアプリケーション」、相性占いの結果を表示するための「Flashコンテンツ（Flash Lite）」、また、その結果とともにコメントを書き込みするための「携帯サイト」の3つで構成されています。
後者の2つはサーバ上に配置されていますので、搭載型FeliCaポートかパソリが接続されているパソコン上で動作するのは「AIRアプリケーション」になります。
期間も短かったこともあり、ろっきーともじゃもじゃの2人で、役割分担して進めました。
名前はLove FeliCaにしてみました。
審査結果は、明日、2010/3/9（火） ICカードワールド2010で発表されるようです。このイベントには参加できませんが、どんな結果になるか楽しみです。結果はともかく、参加したことに意義があると思っています！また、今回はコンテスト向けアプリケーションとして開発しましたが、今までにない分野へのチャレンジでもあったので、これを今後に生かして、なにか良いアイデアが出てきたら、また、何か作ってみたいと思います！
技術的な部分は、今後、当ブログで紹介していきたいと思います！
興味がわいた方、是非試してみてください！
昨年、11月の初旬に、私もじゃもじゃ宛てに株式会社ハウインターナショナル様から1本のメールが届いておりました。
Amazon EC2を活用したSaaS型サーバ監視システム「Nubium Sentinel」というサービスを使ってみませんか？というものでした。
過去に、Amazon EC2に関する記事をいくつか書いていたことから、ご紹介いただけたのだと思います。
すいぶん経ってしまいましたが、最近ようやく、まとまった時間が取れましたので、Nubium Sentinelを試してみることができました。
Nubium Sentinelには、
- サーバリソースの使用状況監視
- サーバ死活監視（ping）
- HTTP監視（BETA）
の大きく3つの機能があります。
メインは「サーバリソースの使用状況監視」で、CPU、Memory、Disk、Networkの状況を監視する機能です。
詳細はこちら
この機能は、サーバにモジュールをインストールする必要があります。EC2用とLinux用の2つの導入手順がありました。
詳しくはNubium Sentinelの「導入手順」をごらんください。
また、死活監視では閾値をこえると、アラートメールを送信する機能もついてました。
監視対象のサーバは、現状ではLinuxやUNIX系のOSが対象となるようです。また、Amazon EC2で運用中のサーバの監視もできるようで、Amazon EC2のようにクラウド上にサーバを配置するということに、不安を抱えるユーザに対してのNubium Sentinelの売りだと思います。
flashcastでは、Amazon EC2で運用しているサービスは現状ありませんので、当ブログサイトを運営しているサーバに対して、サーバ死活監視（ping）とHTTP監視（BETA）の2つを導入してみることにしました。
サーバ死活監視（ping）
まず、こちらから管理者機能にログインします。
次に、「設定」メニューから「サーバ設定」を選びます。
監視するサーバは5つまで登録できるようです。
PCマークのアイコンをクリックすると
登録画面が表示されます。
必要な情報を入力して、追加ボタンをクリックします。アラートメール設定は、とりあえず「パターン1」を選択してみました。
アラートメールのパターンの内容は、となりのヘルプマークをクリックすると意味が表示されます。
ちょっとわかりづらいかもしれませんので、機能説明の方にもあった方が良いような気がしました。
登録が完了すると、一覧に表示されるようになります。登録直後はPingが準備中マークになっていました。
サーバ死活監視（ping）の設定はこれで完了です。
HTTP監視（BETA）
HTTP監視（BETA）は、登録されたWebサイトをHTTPのHEADメソッドを使って監視する機能です。HEADメソッドを利用しているのでHTTPのレスポンスにメッセージボディが含まれません。なので、Google Analyticsなどのアクセスログ解析ツールを使用しても、ログがカウントされません。
詳しくはNubium Sentinelの「HTTP監視サービスBETA」をごらんください。
では、早速使ってみたいと思います。
「設定」メニューから「HTTP監視サービスBETA」を選びます。
監視対象サイトのURLを設定します。
HTTP監視対象一覧に表示されるようになります。
HTTP監視（BETA）の設定はこれで完了です。
監視間隔
5分毎に登録されているサイトの監視を行います。
サイトからのレスポンスが10秒以内に返って来ない場合は、再度サイトにリクエストを発行します。
3回続けて10秒以内にレスポンスが帰って来ない場合はタイムアウトと判断します。アラートメール
監視対象のサイトのレスポンスのステータスコードが2xx以外の場合は、
登録されているメールアドレスにアラートメールを送信します。
異常があったときには、アラートメールが飛んでくるようです。メールが来ないことを祈ります。
サーバ死活監視（ping）の結果確認
サーバ死活監視（ping）の設定直後には準備中になっていましたが、HTTP監視（BETA）の設定が終わり、再度確認すると、監視中になっていました。
この設定をしたのが2010/2/27で2010/3/5に確認したところ、異常は発生していませんでした。
よかったよかった。
考察
24時間365日稼動するサービスの運営では、死活監視は重要な運用の1つです。その際には、当然監視する側の仕組みを作る必要がありますが、Nubium SentinelのようなSaaS型のサービスではその必要がありません。Nubium Sentinelの導入後、即、死活監視を開始することが出来るようになりますので、非常に便利なサービスです。
戦略的には、ユーザ数を増やすことを目的とするのなら、ping監視については無料で利用させ、サーバリソース監視の方をオプションでの有償提供するというのもありなのではないかと思いました。
また、Amazon EC2ユーザをターゲットにするなら、サーバモジュール導入済のAMI（Amazon Machine Image）を公開されるのも良いかもしれません。
要望が1つあります。
アンインストールの手順が欲しいですね。
あ、あと、自前のサーバと違って、自由に設定を変更したり、モジュールを導入したりできないという制限の多いレンタルサーバなどでも、「サーバリソースの使用状況監視」ができるようになると素敵だと思います。
次は、Amazon EC2への導入にチャレンジしてみたいと思います！
郵便番号検索 -zipnavi-にて、地図から郵便番号検索機能をリリースしました。
この機能は近所や公共施設など、地図上の場所は分かるけど、住所と郵便番号が分からない、といった場合などに使ってもらえる想定で作りました。
これで「住所」、「都道府県、市区町村、町域」、「地図」の３つの視点から郵便番号の検索する事が可能になりました。
新たにリリースした地図から郵便検索の画面イメージは以下の様な感じです。
初期状態は日本全体なので、駅名など検索したいエリア付近の情報を入力して地図を絞り込みます。そして地図上をクリックすると、吹き出しが表示されて、そこに住所と「郵便番号検索」ボタンが表示されます。
「郵便番号検索」ボタンをクリックすると、zipnaviの検索エンジンにより郵便番号検索が行なわれ、結果が噴出し内に表示されます。
郵便番号検索 -zipnavi- 地図から検索にて実際に動作を確認できます。
ちなみに仕組みを簡単に説明すると以下の通りです。
１．GoogleMAPS APIを使用して、地図上から緯度経度を取得する。
２．GoogleMAPS APIの逆ジオコーディングを使用して、緯度経度から住所を取得する。
３．zipnaviの検索エンジンを使用して、住所から郵便番号を検索する。
上記を実現する為の方法として、１、２は、メンバーの「もじゃもじゃ」さんが既に開拓済みだった為、そちらの記事を参考にさせてもらい、それに若干のアレンジを加えました。
flashcast：フリーで働くITエンジニア集団のブログ: iPhone OS 3.0のSafariでGPS機能を使ったWeb Applicationを作る！（iPhoneでテスト編）
あと、GoogleMAP上にAdsenseの広告も表示させましたが、これもflashcast：フリーで働くITエンジニア集団のブログ: Strayed Childの地図に広告を載せてみた！の記事を参考にさせてもらいました。
ただ、開発中のテストで気付いたのですが、上記２の方法で取得できる住所情報にはちょっとクセがあります。
Ａ．地図上の道路を指定すると、「日本国道1号線」。海上を指定すると、「日本」といった情報が表示される。
Ｂ．地図上の陸地を指定しているのに、住所ではなく、郵便番号が表示される。
Aの様な場合、googleのAPIでは正確な住所が表示されないようです。
Ｂはちょっとナゾです。
コレは何？
ネットで調べてもよく分かりません。
ただ表示された郵便番号をよ～く見ると・・・
これはたぶん事業所の郵便番号の様に思われます。
上記の様なケースを考慮し、Ａの場合は噴出しに警告メッセージを表示しました。
またＢの場合は、新たに郵便番号検索するまでもないので、GoogleMAPS APIで取得できた郵便番号をそのまま表示させました。
GoogleMAPS APIの仕様では上記の様な記述はありませんでしたが、色々とテストをしていく中で、上記の様な判断条件でほぼ処理出来る事が分かりました。
ただ、一部の地域で上記A、Bいも該当しない例外がありますが、その際はzipnaviの検索エンジンがエラーと判断するので、間違った郵便番号が検索される事はありません。
具体的には以下の様な地域です。
※「茨城県かすみがうら市」だけでは、郵便番号を特定できません。この様な場合も、googleのAPIでは正確な住所が表示されないようです。
３については取得した住所をAjaxを使用して、zipnaviの検索エンジンに渡し、その検索結果（郵便番号）を地図上に表示しています。
なお、今回の機能追加に合わせて、サイトのデザインもリニューアルしました。
新しくなったzipnaviを今後ともよろしくお願いします！
flashcast：フリーで働くITエンジニア集団のブログ: VB.NETの技術メモ～DBアクセスの高速化（バインド変数の使用）前編～では、DBアクセス時に動的にSQLを生成したケースと、バインド変数を使用してSQLを生成したケースを紹介しました。
本編では、計測結果を比較・検証したいと思います。
先ずは、動的にSQLを生成したケースの結果（処理時間）は以下の通りでした。
交互にそれぞれ3回同じ処理を行いました。
●1回目（動的にSQLを生成したケース）
2010/01/19 21:09:13 2010/01/19 21:09:22:700000
●1回目（バインド変数を使用してSQLを生成したケース）
2010/01/19 21:09:34 2010/01/19 21:09:42:700000
●２回目（動的にSQLを生成したケース）
2010/01/19 21:10:23 2010/01/19 21:10:32:700000
●２回目（バインド変数を使用してSQLを生成したケース）
2010/01/19 21:10:34 2010/01/19 21:10:41:700000
●３回目（動的にSQLを生成したケース）
2010/01/19 21:11:11 2010/01/19 21:11:20:700000
●３回目（バインド変数を使用してSQLを生成したケース）
2010/01/19 21:11:45 2010/01/19 21:11:52:700000
※2行目の700000という数字は、DBから郵便番号（7桁）が10万回読み込めた事を証明しています。
動的にSQLを生成したケースは平均9秒、バインド変数を使用してSQLを生成したケースは平均7.3秒。
う～ん微妙な感じ。。。
数件の処理でこの違いであれば、かなりの改善ということになりますが 、10万件の処理でこの結果ということは、今回のテストケース自体が簡単過ぎたからでしょうか？
もう少し複雑な処理や、数百万件という大量のデータを扱う様なケースであれば、更なるパフォーマンス向上が見込めるのかも知れません。
逆に言えばこの様な単純な処理でも、結果にここまで差が出た事は、それなりにパフォーマンス向上の効果が出たと言えるのではないでしょうか？
アプリケーションのパフォーマンスでボトルネックになりやすい要因の一つに、データベース（DB）へのアクセスがあります。
今回はDBへのアクセス（特にSQL文の発行）に関して、バインド変数を使ったパフォーマンス向上の方法を紹介し、それぞれの方法でどれだけパフォーマンスに違いが出るのかを検証してみたいと思います。
なお、前提事項として、以下の開発環境で検証をしました。
・言語：VB.NET
・フレームワーク：.NET Framework 2.0
・DBサーバ：SQL Server 2005 Express Edition
検証を行なうに当たり大量のデータが必要なので、zpnaviでもお世話になっている、郵便番号検索 – 日本郵便より提供されている住所データを使用します。
10万件の住所データに対して、1から順番にシーケンス番号を振ります。 そのデータを1件づつ読み込んで、10万件目が終わるまでの処理時間を計測します。
●動的にSQLを生成したケース
動的にSQLを生成したケースでは、以下の様に動的にSQL文を組み立てて、その内容に対してDBにSQLを発行します。
Imports System.Data.SqlClient
Imports System.Text
sub Test()
Debug.Print(Now)
Dim SqlConn As New SqlConnection
Dim SqlCmd As SqlCommand
Dim SqlRd As SqlDataReader
Dim StSQL As String
Dim i As Long
Dim TownName As New StringBuilder
SqlConn.ConnectionString = "(DB接続文字列)"
SqlConn.Open()
SqlCmd = SqlConn.CreateCommand
For i = 1 To 100000
StSQL = "SELECT NEW_ZIP FROM T_ADDRESS WHERE SEQ = " & i
SqlCmd.CommandText = StSQL
SqlRd = SqlCmd.ExecuteReader
SqlRd.Read()
TownName.Append(SqlRd(0).ToString)
SqlRd.Close()
Next
SqlCmd.Dispose()
SqlConn.Close()
Debug.Print(Now & ":" & TownName.Length)
End Sub
●バインド変数を使用してSQLを生成したケース
Imports System.Data.SqlClient
Imports System.Text
sub Test()
Debug.Print(Now)
Dim SqlConn As New SqlConnection
Dim SqlCmd As SqlCommand
Dim SqlPrm As SqlParameter
Dim SqlRd As SqlDataReader
Dim StSQL As String
Dim i As Long
Dim TownName As New StringBuilder
SqlConn.ConnectionString = "(DB接続文字列)"
SqlConn.Open()
SqlCmd = SqlConn.CreateCommand
SqlPrm = SqlCmd.Parameters.Add("@SEQ", SqlDbType.Int)
SqlPrm.Direction = ParameterDirection.Input
StSQL = "SELECT NEW_ZIP FROM T_ADDRESS WHERE SEQ = @SEQ"
SqlCmd.CommandText = StSQL
For i = 1 To 100000
SqlPrm.Value = i
SqlRd = SqlCmd.ExecuteReader
SqlRd.Read()
TownName.Append(SqlRd(0).ToString)
SqlRd.Close()
Next
SqlCmd.Dispose()
SqlConn.Close()
Debug.Print(Now & ":" & TownName.Length)
End Sub
なお、上記のプログラムを作成するに当たり、.NET アプリケーションのパフォーマンスとスケーラビリティの向上 – 第 12 章 「ADO.NET パフォーマンスの向上」を参考にしました。
前者と後者のプログラムの違いは、各プログラムの19行目のDBに発行するSQL文が動的か、固定かの違いです。
この様な実装方法にする理由はmsdnのサイトには記載されていませんでしたが、Oracleの場合でもバインド変数を使った実装の方が、パフォーマンスがいいと言われています。
具体的な理由もありました。
Oracle Database 10gがOracle Database 10gがSQL文を受け取った場合、共有プール（メモリ領域）をチェックして、文がすでに存在しメモリに格納されているかどうかを確認します。文がメモリに存在し、Oracle Database 10gがその文を再利用できる場合、データベースは文を解析および最適化するタスクをスキップできます。バインド変数を使用すると、SQL文がメモリに格納される可能性が大幅に高まります。これによって、そのSQL文を必要とする次の操作で迅速にそのSQL 文を使用できます。
※Oralceでバインド変数を使用する為には、「Oracle.DataAccess」コンポーネントを参照追加する必要があります。
上記の内容は、値のバインドの「バインド変数が重要な理由」より抜粋
SQL Serverの場合は上記の様な具体的な理由までは記述されていませんでしたが、恐らく同様の理由だと思います。
では動的にSQLを生成したケースと、バインド変数を使用してSQLを生成したケースとではどれくらいパフォーマンスに違いが出るのか？
結果は後日報告したいと思います！
