はてなブックマーク

10分間で数億件を超えるIoT関連のデータをストリーム処理するためのPoC（概念実証）をする機会がありました。そこで経験をしてハマったことなど一部事例として紹介します。 検証の概要 まずは、何のために検証しようとしたかというと... IoT機器からKinesis Streamを通して大量のメッセージを受け取り、分散処理で関連付け処理を検証します。 実証検証の目的としては アーキテクチャ構成の妥当性を検証し コスト軽減のポイントを把握 運用に向けた課題を洗い出す としました。 データと要件の特性 今回の検証用データは自前で生成し投入する必要があり、結構なデータ量となります。 トラフィック量 およそ数十万件/秒（数億件/10分） 時間帯によってバースト（スパイク）が存在する メッセージの関連付け処理を行うが、いつ終点メッセージが届くかわからない。 数分後には処理結果を利用したいのでバッチでは実

地図を扱うシステムにおいて度々登場する地域メッシュ。そのコードや名称に疑問を持つ方も多いのではないでしょうか？ 今回、いろいろと調べてみて分かったことをまとめました。 標準地域メッシュ・システム 日本全国を格子状の区画（メッシュ）にわけて、それぞれに一意なコード（メッシュコード）を振って区別する仕組みがあります。 http://www.stat.go.jp/data/mesh/gaiyou.htm 元々は国土がどのような用途で使われているかの統計データの単位として使うために作られたもののようです。 政府のデータがこのメッシュの単位で定義されていることが多いため、それらを利用するためには必然的にこれを理解する必要があります。（たとえば「アメダスのメッシュデータ」とか。） 政府そのものが出すデータではなくても、それと親和性の高いデータはやはりこのメッシュが使われていたりします。 基準地域メッシ

社内の事業部・プロジェクトを跨いで、社員間で技術やノウハウの共有をもっともっと盛んにしたいーそんな社員の声から生まれ、社内で運用中のツールをこの度 OSS にして公開しました。 公開先 GitHub 上に公開しています。 atware/sharedocs README にデモサイトや Heroku ボタンを記載していますので、すぐに試すこともできます。 Sharedocs Markdown で記事が投稿でき、コメントや Like やストックができる、言ってしまうとどこかで聞いたことがある某有名サービスのような情報共有ツールです。 投稿画面 絵文字も入力できますし、さらにはシーケンス図やフローチャートも Markdown で描けます。 レスポンシブにしてあるのでスマホやタブレットでも使えます。 つくるに至った背景など 背景 弊社には以前から、 他のプロジェクトでどんな技術が使われているのかよ

背景 クラウド基盤におけるビッグデータ活用への期待が高まる中、高速化、耐障害性へのスケーラビリティと共に、非同期処理を前提としたアーキテクチャが注目されます。 単純なモデルとしても、データの蓄積、加工、出力がすべて非同期で行われ、テストの自動化と継続的な実行を前提とする開発プロセスにおいては、Inputに対するOutputをテストするだけの単純なUnit Testだけでは安心できません。 が、どんなシステムにおいてもCIを自動化した上で開発を進めたいものです。 実現したいこと GitにPushされたらJenkinsでBuild＆Deployした上でこれを実現するのが望ましく、更に何がNGになったのかテスト結果を見てすぐにわかると嬉しいですね。 でも散るのは嫌 S3にはこのツール（プラグイン）を使い、SSHログインからのコマンド実行は別のツール、JSONのAssertionはまた別のツールな

はじめに 昨今の機械学習ブームの盛り上がりを受けてか、弊社では、定期的に機械学習に興味のあるエンジニアが集まって勉強会を行っています。 現在、勉強会の取り組みの一つとして、MLBAMやSeanLahman、RETROSHEETで公開している野球データを使って、ピッチャーが次にどこに球を投げてくるのかという様な投球予測をしてみようということを行っています。そこで今回は、その取り組みについて、どういったデータを使おうとしているのか、また実際に機械学習をする前段としてどういった素性を扱うのか、といったことをお話したいと思います。 投球予測ができると何が嬉しいか うまくいけば安定した老後生活を獲得できるからです！ということではないですが、試合観戦前に自分で入力した投球情報でシミュレーションなどできると、実際にシミュレーションが当たってそのシーンになった時に大盛り上がりできる！など楽しみ方は見出せる

※当記事でいう'リトライ'とはバッチの世界でのジョブの再試行という意味ではなくプログラム内の特定ロジックの再試行(いわゆる retry-handler )のことをいいます アプリケーションにおけるリトライ処理の必要性 アプリケーション構築においては、しばしばリトライ処理が必要な場面に出くわします。 例えば、 外部の Web API 等の外部サービスの呼び出し時の接続失敗等を考慮してのリトライ SMTP メール送信時の接続失敗等を考慮してのリトライ 生成したハッシュ値を DB 格納する等の際に万が一ハッシュ値が被る可能性を考慮してのリトライ などなど。 しかしながら、 リトライ処理を書くというのはいろいろと厄介 なものです。 リトライ処理したい部分を try - catch で囲んで〜と本質的でないコードを混ぜつつ書いていませんか？ そこで Spring-Retry spring-proje