Interop2016で見つけたヤンデレ彼女用IoTまとめ [Interop Tokyo 2016]

mental_health_woman

ドーモ、ハジメマシテ、@arimoです。
6/8〜6/10に行われたInteropというイベントに行ってきました。
先にイベントの感想(まじめに)を言っておくと、

エンジニア向けInterop Tokyoの歩き方という記事で述べられていた

Interop Tokyoの展示内容は非常に難解なものが多いと言えますが、その難解さこそが魅力でもあると私は考えています。Interop Tokyoで行われた展示は、それを見た半年後、場合によっては数年後に初めて「あのときのあれは、あのような意味がある展示だったのか!」と気づくことが多い印象があるためです。

という感動がいずれ得られるかと思うと来年も行きたいな〜と思いました。
もう未知の世界すぎてまだよくわかっていないけどすごい技術の結晶だということはわかりました。

@arimoはわりとアプリケーションエンジニアなので、最新ネットワーク機器のエモさとかはまだほとんど理解できないので、IoTの展示をいくつか紹介したいと思います。

注意:使い方参考例は個人的な見解であり本来の使い方と著しく違う可能性があるため、正しい用法は公式サイトをご覧ください。

 

MT90G

IMG_3399
世界最小の3Gパーソナルトラッカー、つまり追跡マシンである。
耐水性、最長180時間スタンバイが可能。
公式サイトにも人の追跡、車の追跡、貴重品の追跡と書いてある。77*47*20mm、76gの小ささで、かつ位置情報の精度は10mである。
これはもう完全に浮気調査用かな?しかしただの位置情報発信機器であれば、職場などに移されたら意味をなさない。
よく読むと内蔵マイク・スピーカーがあり、通話もできる。
浮気を疑うまたは再構築中の彼氏のカバンに忍ばせ、明らかに位置情報が変わらない時は通話で直接確認ができる。携帯2台持ちの浮気彼氏殺しのIoT機器である。
「ね、これでいつも一緒だよ。わたしからは離れられないからね。早く結婚しようね。」

 

世界最小の小型タグ、MAMORIO

IMG_3407
縦35.5mm×横19mm×厚さ3.4mmという驚異的な薄さ、小ささ。
タグを紛失した地点の位置情報だけではなく、クラウドトラッキングという、「みんなでさがす」機能で、他のユーザが自分のタグとすれ違うとその情報がMAMORIO サーバに送信され、その時点でタグがどこにあるのかがわかる。MAMORIOが世に広まれば広まるだけ発見される確率も上昇する仕組みである。
過去に置き引き、落下で財布を2回も失くし、TokyuRubyKaigiで飲みすぎてMac(会社のマシンではない)とカメラの入ったカバンを駅の券売機のところに置き忘れたことのある私にとっては革命的な逸品である。なお一つ3500円程度だそうで、複数個買うのもお財布に優しい。

IMG_3426

”手元から離れました。”
あまりにも小型のタグ、こっそり彼氏の財布に忍ばせて彼氏と離れた場所や時間を再確認してもよし、再度会った時にアプリを確認してほくそ笑むもよし、あわよくば「みんなでさがす」機能でどこにいるかがわかってしまう。

IMG_3427

”誰かが見つけました!”
「このタグはわたしの分身だから、一緒に出かける気分になれる。でも早く帰ってきてね。早く結婚しようね。」
「ねえ、なんでそんな場所にいるの?今日は実家に帰るからって言ってたよね????電話出て????」

 

眠りの質が一目瞭然、beddit

IMG_3398
帯状のセンサーをシーツの下にひくだけで、心拍数や眠りの浅い深いがグラフとなって視覚化できる。なんとベッドから立った時間や覚醒している時間も一目瞭然である。
「こっそり彼氏のベッドに仕掛けちゃった。昨日は何時に寝たかな?何時に起きたかな?
なんで計測されていないの?無断外泊なの????わたしに黙って???」
「振動センサーと、スマートフォンのマイクの両方を利用して計測しているから、いずれ結婚したらわたしとあなたのいびきを聞き分けてくれるから、今から楽しみだね。早く結婚しようね。」
※センサーはコンセントからの給電が必要なためこっそり仕掛けよう
※Bluetoothでスマートフォンと通信するため、彼氏の携帯を見せてもらうか、自分で余分に端末を買って部屋に置いておく必要がある

 

Bluetooth Low Energy スマートソール

IMG_3397
見た目や使い心地は普通のインソールと変わらない、見た目はよくある靴底に敷く中敷きである。目立たず、使用者に気付かれないとなんと公式で謳っている。
ハブと中敷きをWi-Fiで同期して、もし規定範囲外にインソールが出るとPCやスマートフォンで警告を通知する。広い部屋でも狭い部屋でも監視する範囲を設定できる。
「ねえ、なんでこんな時間に出かけるの?さっきおやすみって言ったよね?電話出て????」
なんとインソールの着用者に通知メールが自動で送られる機能もある。
(メール着信)「全部見てるからね?」

 

データの収集、データの分析、そして異常を検知して通知してくれる超便利ツール、impulse

IMG_3403
IoTのセンサーなどで温度や振動などのデータをたくさん収集したとしても、それが異常な値か正常な値かが分からなければ意味をなさない。
その情報を収集して分析して異常な時は通知してくれるようなそんなツールである。
デモでは製造ラインにおいて良品と不良品を振り分けるようなものがあった。
Kibanaで視覚化されていて、データの遷移や不良品発見時もわかりやすい。
「あなたのこれまでの動向データの分析結果を見てみたら不良品だったみたい。新しい彼氏できたからじゃあね。」

 

HTTP ステータスコード 5xx

HTTPステータスコード(5xx)についての超解釈です。

5xxはサーバ事由のエラーによるものでオリジンサーバもしくはプロクシサーバから返されますが、自分に分りやすいように一番問題になりそうな部分だけフォーカスして表にしています。

その中でも500/502/503/504はよく目にすると思いますので、そのあたりに注目しておけばよいと思います。

ステータス番号 説明 調査箇所 返答元サーバ
500 プログラムエラー オリジンサーバのプログラム オリジン
501 クライアントからのリクエストメソッド要求に対応していない場合 クライアントやオリジンサーバのリクエスト仕様の確認 オリジン
502 オリジンサーバからの正常な返答がなかった。4xx、5xxなど オリジンサーバとそこまでの経路 プロクシ
503 ごめん、ちょっと今無理。負荷が高いの オリジンサーバの負荷 オリジン
504 オリジンサーバからレスポンスがなかった オリジンサーバとそこまでの経路 プロクシ
505 クライアントが指定するHTTPプロトコルバージョンをオリジンサーバがサポートしていない 適切なHTTPプロトコルの選定 オリジン
506 コンテントネゴシエーション関連のエラー オリジンサーバのネゴシエーション関連の設定 オリジン
507 WebDAVサーバの容量不足 サーバの容量 オリジン
508 WebDAVでの無限ループ WebDAV設定 オリジン
509 帯域超過 オリジンサーバの設定と帯域 オリジン
510 クライアント側からのリクエストメソッド(Man)の不備 クライアント側の設定 オリジン
511  WiFiスポットにおける認証が行われていない場合。プロクシサーバがインターセプトしてステータスコード511を返答している。  クライアントのWiFiなどの認証 プロクシ

cronとanacronとRHEL5系6系

cronとanacronとRHEL5系6系についてですが

結構、適当に設定し、
はまることが多々あったので自分なりに簡単に解釈してみましたのでお話しします。

anacronについては同じものではあるのですが
5系と6系で解釈を変えるとすんなりと頭に入り込んでくるようになると思います。

では、始めます。

RHEL5系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
サーバ停止中のためcronが実行できなかった場合にジョブを再実行させるためのcronのヘルパープログラム

定期ジョブは下記の二つのうちのいずれかで設定を行う。

■/etc/crontab
cron処理の実行スケジュールを設定する。

■/etc/cron.{hourly,daily,weekly,monthly}
スケジュールごとに指定のディレクトリでプログラムを登録する。
上記の設定だけで定期スケジュールとプログラムの設置が完了する

■/etc/cron.d
自分ではさわらない。

ヘルパーのanacronを利用したい場合はcron.dailyなどのディレクトリでプログラムを登録し、
/etc/init.d/anacronで定期的にstartしてあげる。
設定ファイルは/etc/anacrontabを読み込みます。
標準で/etc/cron.{daily,weekly,monthly}配下に登録されたプログラムがanacronで動作していなかった場合に再実行してくれます。

RHEL6系

cron
特定のプログラムなどの処理を定期的に実行してくれるプログラム

anacron
仮想環境などのゲスト環境でcron処理が特定の時間に集中しないように定期ジョブをうまいこと分散してくれるプログラム
なので、サーバが稼働し続けていなくともRHELの5系の時のanacronのように、サーバが稼働した時点でジョブを実行してくれるようになります。

■/etc/crontab
確実にcronを指定時間に動かしたい場合はこちらを利用する。

■/etc/anacrontab
実行時間は変動するが確実にcronを実行させたい場合はこちらを利用する。

■/etc/cron.{daily,weekly,monthly}
こちらのディレクトリでプログラムを登録するとanacronのほうで実行されます。
※cron.hourlyを使いたい場合はanacrontabで設定を忘れずに

■/etc/cron.d
自分ではさわらない。

5系と同じようにcronを利用したい場合はcronie-nonanacronをインストールしてcronie-anacronをremoveするといいみたい。

p.s.
タイトルは「部屋とYシャツと私」を字余りで歌いながら書き込んでました^^;

インフラにおけるビッグデータ活用とは

 

ビッグデータの活用とは、

収集する情報を分析し活用することで価値を創出することだと解釈しています。

そして、インフラにおける最大の価値とは顧客満足度だと考えています。
※クレームのない世界は結果我々エンジニアも幸せになれるという事。

だとすると、顧客満足度を向上させてこそビッグデータを活用したとみなすことができる。

そこで、この価値を創出するためにはなにをすればいいのか考えてみます。

まず、インフラにおける顧客満足度の向上とは何が考えられるでしょうか?

1.サービスの可用性の向上
2.アプリケーションの高速化
3.セキュリティの堅牢性の向上

となると考えています。

上記を向上させるためのあらゆる情報を収集分析すれば良いということになります。

どのような情報があるかは下記に示します。

1.サーバリソース情報
2.サーバログ
3.アプリケーションログ
4.アプリケーションパフォーマンスログ
5.ネットワーク関連ログ

ちなみに、

収集分析のアイデアとしては

ログをfluentdで収集hadoopもしくはmongodbなどで保存しておいて、
ログを見ながら問題のありそうなものに対して一つずつ対応していくという形。

もしくは、

fluentdでzabbixやsplunkへログを送り付けこれらのツールによって分析を実現する形

です。

私の知らない、使えるツールがあれば教えていただけると助かりります。

まだdmmでもここまではたどり着いておらず、
いろんなツールを探さなくてはいけないなと考えているところです。

ラック高集積化のアイデア

 

Intelのこれを読みふけっていてふと思ったんですが、

CPUが90%時に利用する電力消費は260w

CPUが100%時に利用する電力消費は340w

CPUの能力を10%引き上げるのに30%の電力が必要になる。

となると

ラックに搭載するサーバが増やせるのではないかと。

ちょっと計算してみます。

例えば

ラックあたりの電流値を実効で40Aとし、

サーバ1台あたりのCPU負荷最大時の電力量を340wとする。

この場合、搭載できるサーバの台数は11台となり最大で37.4Aとなる。

サーバにはパワーキャッピング設定が可能ですので90%でキャッピングすれば1台あたりの電力量を260wに抑えることができる。

40Aのラックに収めるには15台のサーバが収容できるということになる。

15台だと39Aですね。

11台のパフォーマンスが10%低下したとしても、

4台のサーバが新たに増やせることになるので逆にパフォーマンスは向上する。

これなら、もう搭載できないと思っていたラックに空きが生じ、追加でラックを増やしたのと同じ効果を見込める。

ただ、現在のパワーキャッピングはスパイクするものに対してキャッピングが難しいとのことで、

少し余裕をもった設計が必要になるのではないかと思います。