ゆれくるコール開発日誌

ゆれくるコール、あめふるコール、つながるコールや緊急地震速報のことなど

AWS Lambda C#でDynamoDBアクセス時のハマりポイント

こんにちは、商品開発部の池端です。

 

AWS API Gatewayでリクエストを受け、DynamoDBを検索して結果を返すような処理をAWS Lambdaでやりたい。

昨年12月よりLambdaでC#が使えるようになったので、C#でやってみましたが、ハマってしまったポイントがあったのでメモメモ。

 

AWS Lambda C#に関しては、下記の記事を参考にさせて頂きました。

qiita.com

ohke.hateblo.jp

 

1.Lambdaプロジェクト新規作成時、パッケージの復元に失敗

Lambdaプロジェクト新規作成時に、ソリューションエクスプローラに「パッケージの復元に失敗しました」とエラーが表示されました。

こちらは、ツール→NuGetパッケージマネージャ→ソリューションのNuGetパッケージの管理の更新プログラムタブよりMicrosoft.NETCore.Appを更新することで解消されました。

 

2.AWS LambdaへのPublish時やテストプロジェクトのビルドでエラー

AWS LambdaへのPublish時やテストプロジェクトをビルドする際に、下記のようなエラーが表示されました。

f:id:ken447:20170307153814p:plain

上記はAWS LambdaへのPublish時のエラー表示ですが、テストプロジェクトビルドエラーの際はVisual Studioの出力、エラー一覧タブに同様のメッセージが表示されます。

こちらはproject.jsonにruntimesを指定することで解決しました。

"runtimes": {
    "win7-x64": {}
} 

指定するランタイムID(win7-x64の部分)はそれぞれの環境に合わせてください。

ランタイムIDの種類はコチラ

 

3.DynamoDBのScanでエラー

これが一番ハマった。。

LambdaにPublishし、DynamoDBでScanをすると下記のエラーがLambdaから返却されました。

{
    "errorType": "TypeInitializationException",
    "errorMessage": "The type initializer for 'System.Diagnostics.Stopwatch' threw an exception.",
    "stackTrace":[
        "at xxxxx.Function.FunctionHandler(Param input, ILambdaContext context)",
        "at lambda_method(Closure , Stream , Stream , ContextInfo )"
    ],
    "cause":{
        "errorType": "DllNotFoundException",
        "errorMessage": "Unable to load DLL 'api-ms-win-core-profile-l1-1-0.dll': The specified module could not be found.\n (Exception from HRESULT: 0x8007007E)",
        "stackTrace":[
            "at Interop.mincore.QueryPerformanceFrequency(Int64& value)",
            "at System.Diagnostics.Stopwatch..cctor()"
        ]
    }
}

こちらはstackoverflowのこの記事を参考に、project.jsonの"Microsoft.NETCore.App"にtypeの指定を追加することで解決しました。

"Microsoft.NETCore.App": {
    "type": "platform",
    "version": "1.1.0"
}

"type":"platform"の指定有無で、.NET Coreをアプリに含めるかどうかを指定します。

詳細については下記に解説があります。

docs.microsoft.com

 

だれかの参考になれば幸いです。

それではまた!

 

緊急地震速報の精度改善

こんにちは、商品開発部の池端です。

 

この度、気象庁により緊急地震速報の精度が改善され、昨日12月14日より運用が開始されました。

テレビや新聞、ネットなどのニュースでも取り上げられていましたね。

www3.nhk.or.jp

www3.nhk.or.jp

 

気象庁からの報道発表はコチラ。

www.jma.go.jp

 

今回は2つの技術改善が行われています。

 

1.同時に複数の地震が発生した場合の精度の改善

いままで同時に複数の地震が発生した場合、それぞれの地震の識別や地震の規模の推定が正確に行えず、震度を過大に予測して緊急地震速報が発表される事例がありました。

東日本大震災の直後には地震が頻発したので、こういうことがよくあったかと思います。

こちらの事象については気象庁でもいままで何度かの改善を行い、その都度精度は向上していましたが、今回は「IPF法」とよばれる新たな手法を取り入れることでさらに精度が向上しました。

IPF法とはIntegrated Paticle Filter法の略称で、内閣府の最先端・次世代研究開発支援プログラムに採択された「東南海・南海地震に対応した正確な地震情報を提供する実用的早期警報システムの構築」の成果のひとつです。

詳細は気象庁の報道発表資料に詳しいですが、この手法を取り入れることで、複数地震発生時の震源の決定や同一地震判定の信頼性が向上します。

 

2.平成 28 年8月1日に発生した緊急地震速報の誤情報の発表への技術的対処

本年8月1日に発生した、最大震度7緊急地震速報の誤報に対する対応が行われました。

この誤報ではゆれくるコールからも通知が行われ、ご利用のみなさまには大変ご迷惑をおかけしました。

誤報の原因は、地震観測点の電源部故障により、地震計の出力データに急激な変化が生じたことでした。今回の対応では、地震学的にありえない大きさのデータを除外する、地震学的に考えられるマグニチュードの上限値を設け、過大な予測をしないといった対応が行われています。

 

今回の気象庁の対応で緊急地震速報の精度は改善されますが、すべての地震をカバーするような精度改善ではありません。

緊急地震速報には技術的限界もあり、必ずしも大きな揺れの前に通知されなかったり、予測には誤差が伴う場合があります。

緊急地震速報の特性をよくよくご留意の上、防災・減災にお役立て頂ければと思います。

www.data.jma.go.jp

 

それではまた!

 

C#でAWS Kinesisからデータをひっこぬく

こんにちは、商品開発部の池端です。

久々の開発ブログです、、

 

AWS KinesisからデータをひっこぬくのをC#でやりたい。

 

Kinesisのクライアントを作るにはAWS SDKで実現してもいいんだけど、Kinesis Client Libraryというのがあって、それを利用すると楽に開発できる、らしい。

ここにそう書いてある。

docs.aws.amazon.com

 

Kinesis Client Libraryはいろんなプログラミング言語用のものが用意されていて、C#のもある。
GitHubここにライブラリ、サンプルコードひっくるめてあります。

 

これをダウンロードしてきてサンプルコード動かしてみれば、C#でのKinesis Client Libraryの利用方法がなんとなくわかります。
このサンプルコードを動かすのに、プロジェクト丸ごとビルドしてサンプルコードのプロジェクト実行すればよいわけでなく、ちょっとした手間が必要でした。
GitHubのREAdMEに書いてあるのでその通りにすればいいんだけど、日本語での解説記事があんまりないようなので、この記事で手順を書いてみたいと思います。

 

0. Java実行環境の準備
Kinesis Client LibraryはJavaのライブラリなのです。
そのためJavaの実行環境が必要になります。
Javaの実行環境がない場合は、Javaの実行環境をあらかじめ用意しましょう。

 

1. Amazon Kinesis Client Library (.NET)のダウンロード
GitHubここからダウンロードします。

 

2. プロジェクトのビルド
何も考えずに、ソリューションのビルドってするとビルドエラーになっちゃいます。
任意のプロジェクトを選択して、個別にビルドするとNuGetがうまいことやってくれます。
その後ソリューションのビルドをすればおk。

 

3. Kinesisにデータをつっこむ
SampleProducerというプロジェクトがKinesisにデータをつっこむサンプルです。

 

こちらを動かすにはAWS Credencialsの設定が必要です。
AWS Credencialsの設定はAWSSDKが導入されていて、Credencialsの設定がされていれば必要ないんですが、検証を行った2016/12/06現在、なぜか最新のAWS SDK(AWSToolsAndSDKForNet_sdk-3.3.27.0_ps-3.3.27.0_tk-1.11.0.0.msi)がWindowsにインストールできない状況でした。(インストール中に「There is a problem with this Windows Installer package」とかいわれちゃう)
そのためプロジェクトのapp.configのappSettingsに、"AWSAccessKey"と"AWSSecretKey"を追加しました。

 

プロジェクトを実行すると、USEast1(米国東部(バージニア北部))にmyTestStreamという名前でKinesis Streamが作成され、10個のテストデータがつっこまれます。

 

4. Kinesisからデータをひっこぬく
SampleConsumerというプロジェクトがKinesisからデータをひっこぬくサンプルです。

 

まず、SampleConsumerプロジェクト内のkcl.propertiesのexecutableNameの設定を、"bin/Debug/SampleConsumer.exe"とします。
"Debug"の部分はビルドの仕方(Release or Debug)に合わせて変更してください。

 

次に、コマンドプロンプトでSampleConsumerプロジェクトのディレクトリにcdし、下記のコマンドを実行します。

..\Boot strap\bin\Debug\Bootstrap.exe --properties kcl.properties --execute

こちらも"Debug"の部分はビルドの仕方(Release or Debug)に合わせて変更してください。

 

実行が始まると、初回実行時に必要なもの(Javaのライブラリ)をダウンロードし、動作するようになっています。
標準出力にKinesisから取得したデータが表示されると思います。(その他にもいろいろ標準出力されますが、、)
こちらはCtrl+Cで止めるまで動き続け、Kinesisにデータが追加される度に動作します。

 

なおSampleConsumerは処理の際に、USEast1(米国東部(バージニア北部))のDynamoDBにDotNetKinesisSampleという名前でテーブルを作成します。

 

こちらを動かすにもAWS Credencialsの設定が必要です。
上記の理由によりSDKが導入できなかったので、Windowsユーザのホームディレクトリに.awsというディレクトリを作成し、credentialsファイルをおき、その中にaws_access_key_idとaws_secret_access_keyを記載しました。
ちなみにWindowsで"."からはじまるディレクトリの作成は、".aws."とタイプします。

 

5. あとかたづけ
USEast1(米国東部(バージニア北部)) に自動的に作成されたKinesis StreamとDynamoDBのテーブルを忘れずに削除しましょう。
つかわなくても、存在するだけでお金かかっちゃいます。。

 

このサンプルを動かし、サンプルプロジェクトのコードを見ればなんとなく使い方がわかるんじゃないかと思います。
動作させるのにJava環境が必要だったりするので、実運用環境ではその辺がネックになったりしそうな気もしますね。

 

だれかのお役に立つと幸いです!

 

キャンセル報について

こんにちは、商品開発部の齋藤です。

先日の震度7の誤報では皆様にご心配をおかけいたしました。

その誤報について、15秒後にキャンセル報と呼ばれる情報が発信されていました。先ほどの地震情報は誤りであったとする情報です。

私どものシステムでは緊急地震速報は自動的に震度計算を行い、お客様の端末に配信する一方で、キャンセル報については自動的には配信せず、事実確認を行ったうえで手動で配信する、という対応を行っております。

緊急地震速報が誤った情報を出すことがあることと同様に、キャンセル報も誤った情報が来る可能性は0ではありません。


震度7地震が来ます(実際には来ない)
震度7地震は来ません(実際には来る)


この2つでは後者の方が甚大な被害を出すことが想定されます。
キャンセル報の方が緊急地震速報よりもデリケートな情報であると私どもは考えており、そのためキャンセル報を自動で出すことはしておりませんでした。


しかしながら今後は、気象庁様やその他の配信事業様などと、キャンセル報の扱いについてご相談させていただいた上で、これからのキャンセル報の扱いについて検討してまいります。


これからも改善を続けてまいりますので、ゆれくるコールを今後ともよろしくお願いいたします。

震度速報の配信に対応しました

こんにちは、商品開発部の池端です。

 

本日ゆれくるコール for Android Ver.3.3.2をリリースしました。

このリリースで震度速報の通知に対応しました。

このタイミングでゆれくるコール for iOSも同様の対応をしました。

iOS版はアプリの更新はありません。)

 

この震度速報とは、震度3以上の地震発生後約1分半後に、気象庁より発表される地震のお知らせです。

 

緊急地震速報ではなく、地震の揺れの後の震度の観測情報ですのでご注意ください!

 

地震発生直後、一番最初にテレビにテロップで流れる情報がありますよね?

あの情報が震度速報です。

 

気象庁が発表する地震の情報には下記のものがあります。

震度速報は、地震の揺れの後の震度の観測情報としては最速の情報です。

f:id:ken447:20160427173939p:plain

地震情報の詳細については下記をご覧ください。

www.data.jma.go.jp

 

ところでゆれくるコールももともと「地震情報」という震度観測情報を通知していました。

設定した地点の都道府県で、最大震度が設定震度に到達した場合に通知し、最大震度5弱の場合は全国一律通知を行います。

 

この地震情報の通知は、上記表中の「各地の震度に関する情報」をもとに通知を行っており、揺れの後約5分後に通知されていました。

 

熊本地震の発生後、「ゆれくるの通知が遅い!」という声も頂いておりますが、原因のひとつはこの地震情報の通知が遅いということもあったのかと考えています。

 

今回の対応で、震度3以上の地震が発生した場合は、震度速報をもとにして地震情報を通知するようになります。

大きな地震発生時は、より早く震度の観測情報が届くことになります。

 

ちなみに、緊急地震速報地震の揺れの後の震度の観測情報に先立って発表される情報になりますので念のため。

緊急地震速報のしくみや詳細については下記をご覧ください。

www.data.jma.go.jp

 

よりいっそう便利になったゆれくるコールを、みなさまの防災・減災にお役立て頂ければと思います。

 

それではまた。

 

がんばろう!熊本・大分

 

熊本地震発生後の「各地の震度に関する情報」について

こんにちは、商品開発部の池端です。

 

4/14の熊本での地震発生以降、気象庁は、熊本県熊本地方、熊本県阿蘇地方、大分県西部、大分県中部付近の震度3以下の地震について「各地の震度に関する情報」を発表していませんでしたが、昨日4/26 18:00以降、再度発表するようになりました。

 

気象庁|地震情報

※上記リンク先の下部に、下記のような記載があります。

なお、今後は「地震回数に関する情報」にかえて、「各地の震度に関する情報」において震度1以上の情報を発表します。

 

「各地の震度に関する情報」とは、震度1以上を観測した地点のほか、地震の発生場所(震源)やその規模(マグニチュード)を発表する情報です。

詳しくは下記をご覧ください。

 

www.data.jma.go.jp

 

気象庁では4月14日21時26分の熊本での最初の地震以降、同一地域付近で震度1以上の地震が多発し、通常の地震情報の発表を継続することにより緊急作業や防災機関での対応などに影響が出ると判断したことから、地震情報は震度3以上の場合に発表することとしました。そのかわり、震度2以下の場合は「地震回数に関する情報」という地震が多発した場合等に発表される情報で地震回数をまとめて発表するようになりました。

大きな地震発生後はこのような対応がとられることはあり、311の際も気象庁では同様の対応がなされていました。

 

ゆれくるの地震情報の通知(緊急地震速報ではなく、地震の揺れの後の観測情報)は、「各地の震度に関する情報」をもとにして行っています。そのため、気象庁から発表されない場合は通知もされませんでした。

また一覧の地震情報は、「各地の震度に関する情報」が発表されたのちはそちらの内容で更新しています。地震情報の通知と同様、気象庁から発表されない場合は一覧の更新もされませんでした。

 

震度1はともかくとして、震度2くらいであれば体感することも多いかと思います。

特に被災地では、揺れに敏感になっているのでなおさらですよね。

実際に揺れたけど、気象庁サイトやゆれくるには掲載されていない!なんてこともあったかと思いますが、それは上記の理由によるものです。

 

尚、緊急地震速報の配信については配信条件の変更はありませんでしたので、下記の条件に合致する場合は配信されていました。

 

  • 気象庁の多機能型地震計設置のいずれかの観測点において、P波またはS波の振幅が100ガル以上となった場合。
  • 地震計で観測された地震波を解析した結果、震源マグニチュード・各地の予測震度が求まり、そのマグニチュードが3.5以上、または最大予測震度が3以上である場合。

 

緊急地震速報の発表条件の詳細は下記を参照ください。

www.data.jma.go.jp

 

昨日4/26 18:00以降、ゆれくるの一覧や気象庁サイトを見ると、結構な数の震度1、2の情報が発表されていますね。

規模は小さいですが、まだまだ地震は多発しています。

くれぐれもご注意ください。

それではまた。

 

がんばろう!熊本・大分

ゆれくるAndroidのステータスバーのアイコンについて

こんにちは。商品開発部の齋藤です。

4月11日にリリースいたしましたゆれくるコールAndroid バージョン3.3.0では、
今までステータスバーに表示させていたアイコンをなくしてしまいました。
これはプッシュ通知に関する通信方法を変更した関係でそのようにいたしました。

バージョン3.2.x以前では、独自の配信サーバと各端末が常に接続されている状態で、地震が起こった際にはその通信を使って通知を送っていました。
バックグラウンドの常駐処理で定期的に繋がっているかどうかを確認するようになっており、これでステータスバーのアイコンの状態を変更していました。

f:id:ken447:20160413152256p:plain

ところが、Android6.0のDozeモードという機能によって、端末が深いスリープ状態になっているときはバックグラウンドで動作をさせることができなくなりました。
これにより、Android6.0では地震が発生しても、端末が深いスリープ状態のときは通知を受信することができなくなりました。
ただし、例外的にGoogle Cloud Messaging(GCM)というサーバと端末をやりとりするサービスを利用する場合、深いスリープ状態でも通信が可能です。
ゆれくるバージョン3.3.0ではこのGCMを用いてプッシュ通知を行っています。
GCMはGoogleによるサービスで、ゆれくるアプリが常駐していなくても通知を受け取ることができます。

f:id:ken447:20160413152214p:plain

さて、ステータスバーのアイコンですが、アイコンが黄色のときと灰色のときで通信中かどうかを表示していました。
GCMを利用することになったため常駐サービスを動かすことがなくなり、このアイコンの色を変更することができなくなってしまいました。
アイコンの色を変えるために常駐サービスを動かすようにしたとしても、プッシュ通知を受け取れる状態であるかの判断を正しくすることができないため、
例えばアイコンが黄色なのに実際は通知が受け取れない、といった問題が発生する可能性があります。
黄色と灰色のアイコンの切り替えを行う条件をいくつか考えてそれに基づいて切り替えることもできそうではありますが、
難易度や信頼性などから今回のアップデートでは見送らせていただきました。

アイコンがないと不安という声もお聞きしているため、また何らかの形でステータスバーのアイコンを復活させることを検討しております。
また、現状でもインターネットに接続されており、GooglePlay開発者サービスがインストールされていれば問題なく動作いたしますので、ご安心いただけますようよろしくお願いいたします。