SlideShare une entreprise Scribd logo
1  sur  156
Télécharger pour lire hors ligne
O2O/IoT/Wearable時代における 
Web以外のネットワーク技術入門 
株式会社リクルートテクノロジーズ 
アドバンスドテクノロジーラボ 
加藤 亮 
YAPC::Asia 2014
TOPIC 
• MQTTの紹介と関連技術との比較 
• Bluetooth LE/iBeaconの概要と応用
MQTT
What’s MQTT 
• PubSubプロトコル 
• 省エネ 
• QoS, Willなどのサポート 
• ワイルドカードを使った柔軟なSUBSCRIPTION 
• シンプルな仕様(ver3.1日本語仕様書43ページ)
EventHub系ツール/サービス 
• Plagger (コマンドラインツール) 
• Yahoo Pipes (Webサービス) 
• IFTTT (スマホアプリ) 
こういったサービスのサポート対象に機械が加わるのを 
イメージするとよいかも
EventHub系ツール/サービス 
RSS Gmail 
Evernote 
IFTTTの例 
Twitter IFTTT 
RSSを定期的にチェックして、 
更新情報があれば 
天気 
予報 
instagr 
am 
Dropbox 
更新情報
EventHub系ツール/サービス 
RSS Gmail 
Evernote 
IFTTTの例 
Twitter IFTTT 
Gmailに送信するとか 
天気 
予報 
instagr 
am 
Dropbox 
更新情報
EventHub系ツール/サービス 
RSS Gmail 
Evernote 
IFTTTの例 
Twitter IFTTT 
instagramに新しい写真がアップされたら 
天気 
予報 
instagr 
am 
Dropbox 
写真
EventHub系ツール/サービス 
RSS Gmail 
Evernote 
IFTTTの例 
Twitter IFTTT 
Dropboxに保存するとか 
天気 
予報 
instagr 
am 
Dropbox 
写真
PubSub 
監視 
カメラ照明 
エアコン 
MQTTの例 
MQTT 
Broker 
1. Subscribe 特定のイベントの監視 
照明&エアコン -> Broker「誰かが入室したら教えてね」
PubSub 
監視 
カメラ照明 
エアコン 
MQTTの例 
MQTT 
Broker 
event: 入室 
data: Aさん 
2. Publish 特定のイベントの通達  
監視カメラ -> Broker「Aさんが入室したよ」
PubSub 
監視 
カメラ照明 
エアコン 
MQTTの例 
MQTT 
Broker 
event: 入室 
data: Aさん 
event: 入室 
data: Aさん 
3. SubscriberへのDispatch  
Broker 「入室イベントを待ってたのは照明とエアコンだったよな…」 
Broker -> 照明&エアコン「Aさんが入室したよ」
PubSub 
Action 
監視 
カメラ照明 
エアコン 
MQTTの例 
MQTT 
Broker 
event: 入室 
data: Aさん 
event: 入室 
data: Aさん 
4. Eventに対応したアクション  
照明「人が入ってきたので明るくしよう」 
Action 
エアコン「人が入ってきたので室温を調整しよう。Aさんの場合は27度」
PubSub 
監視 
カメラ照明 
エアコン 
MQTTの例 
MQTT 
Broker 
IFTTTなどのサービスはHubのほうがレシピに従い能動的に動く 
PubSubではクライアント側が能動的にPublish/Subscribe
M2M以外でも 
Facebookに買収されたBeluga(Group Messenger)が採用 
必ずしも機械だけのためと考える必要はない 
PubSubはグループチャットと相性がよい 
! 
Event(Topic) = チャットルーム 
EventのSubscribe=チャットルームへの参加 
EventのPublish=チャットルームでの発言 
MQTTを機械のためのグループチャットと考えると 
イメージしやすいかも
TOPIC 
• TOPIC - スラッシュ区切りのtree構造の表現でイベントを監視 
finance/stock/ibm 
finance/stock/ibm/currentprice 
finance/stock/ibm/closingprice 
• 二種類のワイルドカード 
finance/stock/+/currentprice 
finance/stock/ibm/# 
そのレベルのみのワイルドカード 
これより下のレベルを全て含めるワイルドカード
省エネ 
• M2Mを前提 - 電池型(特にボタン電池)では非常に重要 
• バイナリフォーマットのパケット&手続きの簡略化 
• BTLE, HTTP2.0/SPDYなど現在のプロトコルのトレンド 
• HTTP2.0の場合は省エネというより高速化のほうが焦点ではある
耐障害性 (QoS/Will)
QoS 
• Quality of Service 
• QoS0, QoS1,QoS2という三つのレベル 
• 機械はある程度安定して動き、ネットワーク(特に無線)は不安定になる 
事が多い、という前提 
• Publishされたメッセージが、Subscribeしたデバイスに確実に届くこ 
とをどこまで保証するか、重複を許容するかをQoSレベルで制御
Will 
• セマンティックなLeave Message。遺書。 
• コネクションのロスト自体をSubscribe可能なイベントとする 
• WillなしでもTimeout/Pingなどと合わせ切断検知自体は出来る。
MQTT-SN 
• SN = Sensor Network 
• LAN内の全てのノードがサーバーに直接接続する必要はない 
• Gatewayの利用 
• センサー系の小型無線デバイスのためにさらに省エネな仕様
MQTT-SN 
MQTT 
Broker 
(Server) 
MQTT-SN 
Gateway 
MQTT-SN 
Client 
MQTT-SN 
Client 
MQTT-SN 
Client メッセージのやり取りをaggregateしたり 
TOPICを2byteのIDに置き換えたりして効率化できる
MQTTの混乱ポイント 
• PubSubプロトコルなのに何故かHTTPとの比較 
• AMQP, XMPP, STOMP, Redis PubSubなどの他の技術との差異
HTTPとの比較 
「MQTTはHTTPに比べて省エネである」 
という文章がMQTTの紹介文によく出てくる 
Long PollingやWebSocketとの比較記事など 
そもそもRedisのPubSub機能やSTOMPなどの 
技術と比較すべきでは? 
そもそもプロトコルのレイヤーが違うのでは? 
なぜHTTPと比較してるの?
おさらい 
HTTPを使ったPush技術 
• Polling 
• Long Polling 
• Chunked Transfer Encoding/Server Sent Event 
• WebSocket
Polling 
Client(User A) 
Server 
HTTP 
Request 
HTTP 
Response 
新しい情報がないかサーバーに確認
Polling 
Client(User A) 
Server 
30秒待つ
Polling 
Client(User A) 
Server 
HTTP 
Request 
HTTP 
Response 
30秒の間に新しい更新が無かったか、 
サーバーに確認
Polling 
• 15-20年くらい前のCGIチャットとか 
• 空白の期間ができ、リアルタイム性が劣る 
• 30秒に1回を3秒に1回にすると10倍のサーバー負荷
Long Polling 
チャットサービスの例 
Client(User A) 
Server 
HTTP 
Request
Long Polling 
チャットサービスの例 
Client(User A) 
Server 
HTTP 
Request 
レスポンスをすぐに返さない 
HTTP 
Request
Long Polling 
チャットサービスの例 
Client(User A) 
Server 
HTTP 
Request 
暫く待つ
Long Polling 
チャットサービスの例 
Client(User A) 
Server 
HTTP 
Request 
User Aへの 
メッセージ 
ユーザーへのメッセージが届いたら
Long Polling 
チャットサービスの例 
HTTP 
Response 
Client(User A) 
Server 
このタイミングで初めて 
そのメッセージをのせてHTTPレスポンスを返す 
あるいはタイムアウトで、空レスポンスを返す  
User Aへの 
メッセージ
Long Polling 
チャットサービスの例 
Client(User A) 
Server 
HTTP 
Request 
レスポンスを受け取ったらユーザーはすぐに 
もういちどリクエストを送る。 
サーバーはすぐにレスポンスを返さずに 
同様に暫く待つ。 
Long Polling 
• レスポンスを受けてから、もう一度サーバーにリクエストを張りにいくまでに隙間は出来る。 
• そこでサーバーがメッセージを受けた場合の対応を考える必要がある。 
• Request/Responseのヘッダなど、無駄が多い
Server Sent Event 
• HTML5 
• 一度サーバーに引っ掛けておくと、イベントが発生するたびにサーバーからパケットが送ら 
れる。 
• サーバー -> クライアントの一方向 
• クライアントからのpingとタイムアウトによる切断検知が出来ないのでそこは注意
APNS/GCM & HTTP GET 
M2Mの議論とは少しずれるが 
iOS/Androidのネイティブアプリであれば 
それぞれのPUSH通知サービスを利用できる
APNS/GCM & HTTP GET 
Apple/Google Server 
通知用トークンを発行してもらい取得 
TOKEN 
Client(User A) 
Apple: Device Token 
Google: Registration ID
APNS/GCM & HTTP GET 
Apple/Google Server 
Client(User A) 
UserA:TOKEN 
取得したトークンをサーバー上に保存
APNS/GCM & HTTP GET 
Apple/Google Server 
Client(User A) 
User Aへの 
メッセージ 
UserA:TOKEN 
ユーザーAへのメッセージが届いたら
APNS/GCM & HTTP GET 
TOKEN 
Apple/Google Server 
Client(User A) 
User Aへの 
通知メッセージ 
該当ユーザーのトークンを使って、 
iTunes Connect/Google PlayのPUSHサービスに通知
APNS/GCM & HTTP GET 
Apple/Google Server 
Client(User A) 
User Aへの 
メッセージ 
通知 
iTunes Connect/Google Playが、 
トークンにマッチするユーザーのデバイスにPUSH通知
APNS/GCM & HTTP GET 
Client(User A) 
Server 
HTTP 
Request 
Apple/Google 
User Aへの 
メッセージ 
通知を受けると、(通知からアプリを起動すると) 
アプリはサーバーに更新を確認
APNS/GCM & HTTP GET 
Apple/Google Server 
HTTP 
Response 更新情報があれば取得 
User Aへの 
メッセージ 
Client(User A)
APNS/GCM & HTTP GET 
コストをかけて今までのStatelessなHTTPとは違う 
アーキテクチャのサービスを用意しなくても 
ある程度ならリアルタイム性を実現できてしまう
HTTPによるM2Mネットワーク
HTTPによるM2Mネットワーク 
この分野でのMQTTの出現に至る経緯を追う 
M2M(machine to machine)のネットワークを 
HTTP(REST)でやっていこうという議論 
室温計 
エアコン 
HTTP GETで室温を取得 
Client 
HTTP PUTで温度設定
HTTPによるM2Mネットワーク 
• AtompubのようなRESTfulアーキテクチャ 
• ETag, If-Modified-Sinceなどを使ったキャッシングやトランザクショ 
ン管理 
HTTP GETで室温を取得 
HTTP GETで室温を取得 
Proxy 
If-Modified-Since 
室温計Client 
取得した結果をキャッシュ 
リアルタイムでデータの変更通知が必要な場合は 
Long Pollingとかmultipart/x-mixed-replaceとか
テキストベースのHTTPは 
省エネが要求されるM2Mにおいては厳しいし 
RESTful HTTPだけでは解決しない問題もある 
別のプロトコルの提案 
クラサバPubSubモデルへ 
HTTPをベースに 
マシンネットワーク向け最適化 
MQTT CoAP 
こういった経緯があり、MQTTの紹介でHTTPとの比較が出る 
プロトコルの性質自体は全然違うもの
CoAP/CoRE 
• Constrained Application Protocol (IETF) 
• Constrained RESTful Environment 
• HTTPフォーマットのバイナリ化とかUDP Multicastとか(TCPも可能) 
• Proxy使ったHTTPとのInterOpも(HTTP MappingやCaching) 
• Observeオプション 
• BonjourのようなDNS-SD 
• LANの外とリアルタイムな通信するためには工夫が必要
Bonjour (DNS-SD) 
• Multicast DNS & DNS Service Discovery 
• DNSのPTR/SRV/TEXTレコードを使う 
• PTRレコードでサービス検索 
• SRVレコードでサービスのホストを検索 
• AレコードでIPを取得 
• 必要であればTXTレコードでサービスのcapabilityとかstatusを取得 
• 昔iTunesがセキュリティソフトに引っかかってたのはこいつが原因だったりする(dnssd.dll) 
• Zero Configuration Network
CoAP VS MQTT 
• CoAPはWebアーキテクチャとの親和性高い 
• CoAPと比較するなら、正確にはMQTTというよりMQTT-SNかも 
• 両方とも本来の用途であるマシンネットワークにおいて、商業施設や家電 
系のベンダー以外のエンジニアが遊ぶ隙間が現状そんなには無さそう 
• MQTTだとマシンネットワーク以外での応用で遊ぶ余地はあるかも 
• まだ標準化の途中なので要ウォッチ 
• http://www.slideshare.net/KaoruMaeda/ietf90iot (レピダム前田さん)
CoAPでNAT Traversalどうしようみたいな 
議論を見かけたので 
(Signaling Channelどうすんだという話?) 
WebRTCの流行もあるので 
ついでにNAT Traversalについても
NAT Traversal (NAT越え) 
• LANの外とP2P通信するためには、一般的にはどちらかが、あるいは2 
つのコネクションを使い両方がサーバーになる必要がある(厳密には、 
TCP Simultaneous Openなどを使えばクライアント同士で接続は可 
能ではある) 
• ルータの外からLAN内のサーバーにアクセス出来るようにするには(IP 
マスカレード)ポートフォワーディングが必要 
• ICEという標準化仕様があり、SIP, XMPP Jingle, WebRTC(Trickle 
ICE)のような音声、動画のP2P通信のために使われている 
• UPnPなども
VoIPの例 
メッセンジャーなどで通信 
Signaling 
Server 
Signaling Channel Signaling Channel 
Peer A Peer B
VoIPの例 
音声や動画通信をP2Pで始めたい(サーバー経由はコスト高い) 
Signaling 
Server 
Signaling Channel Signaling Channel 
RTP 
Peer A Peer B 
Data Channel(Audio, Video)
VoIPの例 
現実はNATが存在し、簡単にはP2P通信を実現できない 
Signaling 
Server 
RTP 
PeerBのTransport Addressが 
PeerAのTransport Addressが 
取得できない 
NATs NATs 
取得できない 
Peer A Peer B
ICE 
Interactive Connectivity Establishment
Hole Punching 
NATに穴をあける必要がある 
NATs ローカルホストはNATを通して、 
Local 
Host 
外のネットワーク上にあるサービスにアクセス
Hole Punching 
NATs 
Local 
Host 
10.100.100.100:10002 
192.168.0.1:10001 
NATはトランスポートアドレスをアロケートして、 
ローカルホストとのマッピングを行う
Hole Punching 
NATs 
Local 
Host 
10.100.100.100:10002 
192.168.0.1:10001 
このグローバルアドレスに 
パケットが来た場合
Hole Punching 
NATs 
Local 
Host 
10.100.100.100:10002 
192.168.0.1:10001 
マップされたローカルホストに 
パケットを送信
Hole Punching 
! 
Transport Address(IP&Port)をどうチェックに使うか 
パケットを送ってきた相手に対して、こちらから送信したことがあるか 
などのチェックの仕方など 
ルータによって振舞が変わる 
必ずしもうまくはいかない
STUN 
STUN 
Server 
NATs 
STUN 
Client 
外から見て自分のアドレスがどうなっているかを 
確認するためのもの 
! 
STUNサーバーはリクエストを受け取ると 
自分から見える相手のアドレスを返すだけ、という 
非常にシンプルな機能のサーバー 
Server Reflexive Transport Address 
Host Transport Address
ICE 
STUNサーバーを利用し、外から見える自分のアドレスを取得 
Signaling 
Server 
NATs NATs 
STUN 
Server 
Peer A Peer B
ICE 
外から見えるアドレスやローカルのアドレスなど候補を集めて 
シグナリングチャンネルを通して相手と交換 
Signaling 
Server 
PeerBと通信するための 
アドレス候補のリストPeerAと通信するための 
アドレス候補のリスト 
NATs NATs 
Peer A Peer B
ICE 
取得した候補アドレスのペアを優先順位に従って順にチェック 
通信できるアドレスのペアを探す 
お互いがSTUN Server/Clientとなり、 
相手にリクエストを投げる 
4-way handshake 
PeerBと通信するための 
アドレス候補のリストPeerAと通信するための 
アドレス候補のリスト 
NATs NATs 
Peer A Peer B
ICE 
どうしてもつながらない場合もある 
PeerBと通信するための 
アドレス候補のリストPeerAと通信するための 
アドレス候補のリスト 
NATs NATs 
Peer A Peer B
TURN 
STUNの上にのってるリレーサーバー用のプロトコル 
TURNでのチャンネルも準備して候補アドレスに含め、交換しておく 
TURN 
Server 
NATs 
TURN 
Client 
Remote Peer 
相手と通信するためのアドレスをマップして 
チャンネルのバインドを行っておく 
Channel Binding 
NATs 
Client ReflexiveTransport Number Relayed Transport 
XXX.XXX.XXX.XXX:10001 0x4001 YYY.YYY.YYY.YYY:10001 
XXX.XXX.XXX.XXX:10001 0x4002 YYY.YYY.YYY.YYY:10002 
XXX.XXX.XXX.XXX:10002 0x5001 YYY.YYY.YYY.YYY:10003 
TODO: need peer reflexive address?
ICE 
リレーサーバーを最後の手段として、そこを通して音声や動画を送信 
Signaling 
Server 
TURN 
Server 
NATs NATs 
Peer A Peer B
興味のある人は、 
より詳しくはWebRTC, XMPP Jingle, SIPなどの 
関連ドキュメントを 
Chromeでの実装: https://code.google.com/p/webrtc/ 
(旧libjingle) 
経緯 
• Gmailでチャットサポート(XMPP) 
• その上でビデオチャットサポート(Jingle拡張/libjingle) 
• WebRTCが登場しlibjingle上でWebRTC用の機能拡張 
• webrtcプロジェクトに移行
MQTTと他の技術との差異 
Message Queue? Messaging?
What’s MessageQueue 
Messages 
Queue 
Client Worker
JobQueueの例 
Worker 
Worker 
ひとつずつ順番にジョブを処理していく。 
一つのジョブはどれか一つのワーカーによって処理される。 
Client Worker
JobQueue以外でも 
Subscriber 
Subscriber 
一つのメッセージがワーカー全員にコピーされて 
配られることもある。Fanout(Broadcast) 
他にもいろいろ分散処理のための機能 
Publisher Subscriber
Patterns 
• Request/Response 
• Producer/Consumer 
• Publish/Subscribe
AMQP
AMQP 
• Advanced Message Queuing Protocol 
• エンタープライズに耐えうる分散システムのためのもの 
• 実装としてはRabbitMQが有名、他にはActiveMQも 
• RabbitMQはAMQP以外もいろいろサポート(MQTT, STOMPも)
AMQP 
• ExchangeとBindingでQueueへのルーティング制御(TOPIC/FANOUT/DIRECT) 
• これらを備えたシステムをMessage Brokerと呼ぶ 
Binding Queue 1 
Binding 
Queue 2 
Queue 3 
Queue 4 
Exchange 1 
Broker
AMQP 
• TCPのコネクション管理はコストが高い 
• 一つのTCPコネクション内で複数のチャンネルを使う 
• Client内でスレッド毎に別のチャンネルを使える 
Connection 
Broker 
Channel 1 
Channel 2 
Channel 2 
Client 
Thread 1 
Thread 2 
Thread 3
Acknowledgement 
• メッセージをいつ、キューから削除するかを制御 
• コンシューマがメッセージを受け取ったとき 
• コンシューマがメッセージを受け取り、そのメッセージをストレー 
ジに保存したとき 
• コンシューマがメッセージを受け取り、そのメッセージに関する処 
理が完了したとき
Journaling(実装) 
• Queueへのメッセージのadd/removeをログファイルに記録しておく 
ことが出来る 
• Queueが落ちた場合、復帰後、ログのリプレイで落ちる前の再現が可 
能 
• クライアントのメッセージ送信から、ロギングまでのインターバルは0 
にはならないので、100%安全ではない。重要なデータは、クライアン 
ト側でトランザクション管理が必要
AMQP VS MQTT 
• MQTTのMQはIBMが提唱したしたときにMessage Queue関係のプロダクトラインから 
生まれた名残 
• プロトコルを実装する際に必ずしもQueueが重要でなく、PubSubできればよい。 
• なので分散処理のためのMessage Queue関係のプロダクトと真っ向から競合するもので 
はない 
• とはいえAMQPでPubSubも実現可能だし, RabbitMQ自体はMQTTも使えるようになっ 
ていたりする。 
• AMQPは仕様がでかい core v1.0のPDFが124page -> シンプルにPubSubだけが欲しい 
なら無駄な複雑性 
• AMQPは基本的にはバックエンドの分散処理のためのもの
XMPP
XMPP 
• Extensible Messaging and Presence Protocol 
• 1対1のテキストチャット 
• フレンドリスト(roster)やプレゼンスの管理 
• グループチャット(MUC) 
• PubSubに関しても拡張がある XEP-0060 
• そもそもフレンドリストやPresenceの管理をPubSubで行っている
XMPP 
昔Perl Oceanというのを作ったときに 
XMPPプロトコルについては説明いっぱい書きました 
日本語のまとまった解説ってなかなか無いので宜しければどうぞ 
OceanについてはYAPC2012でlapisさんのセッションがありました。
MQTT VS XMPP 
• 基本的には両者ともバックエンド向けのものではない 
• MQTTは一応OAuthなど、他の認証の仕組みを使ってもよいとは書か 
れている。CONNECTパケットフォーマット仕様はusernameと 
passwordが固定確保。XMPPではSASLの仕組みで認証方式を柔軟に 
選択できる仕様にはなっている 
• 機能的にはXMPPはチャット関係の機能は片っ端から揃っており、 
MQTTで出来ることもだいたい可能(PubSub拡張など)
MQTT VS XMPP 
• XMPPの仕様は大きくて複雑。RFC Core 211ページ & IM 114ページ。 
(MQTTは48ページ)。いろいろ出来る分、複雑で実装コストも高い 
• 本当にプレゼンスは必要か? PCの前で座り続けるユーザーのために作 
られた仕様。ポケットの中に常にデバイスがある時代には最適ではない 
のでは? ユーザーのプライバシー意識の問題も。テレビ電話が流行らな 
かったのと同じ問題があるかも。プレゼンスはサービス運用時のスケー 
ルも難しい。 
• XMPPはレガシーで微妙な仕様がたくさん残っている(HTTP APIを使 
えば十分な機能をXMPP内で実装しなければいけない)。
Redis/STOMP 
• シンプルなテキストベースのPubSub 
• ただしRedisはプロトコルというより実装で、認証もエンドユーザー向 
けではない。基本バックエンドでの利用を想定されたもの。 
• STOMPが一番MQTTに近いのでは 
• 省エネ対策、QoS、Willなどはない 
• 逆に言えばシンプリシティはSTOMPのほうがよい。重要なのは省エネ 
対策、QoS, Willが必須かどうか
Protocol比較まとめ 
• 同じような事が可能でも、もともと目指したところは違う。基本的に 
はそのプロトコルがもともと目指したものが重要 
• 分散処理 -> AMQP 
• テキストチャットとプレゼンス共有 -> XMPP 
• KeyValueストア -> Redis 
• 商業施設や家庭内での機械のサービス自動化-> MQTT 
• とはいえプロトコルはスタック、応用を考える事も重要 
差異に混乱したときは原点に帰り、特徴を把握した上で応用を
MQTTを利用すべきか 
• XMPPに比べるとシンプルとは言っても、MQTTはMQTTで実装上面倒な所は存在しそう。機械 
のための必須機能でも、他で応用するときにはその複雑性が邪魔になる可能性もある。 
WebSocket/Redisと独自プロトコルやあるいはSTOMPで簡単に実装できる要件で、特に省エ 
ネなどがクリティカルな話でなければ無理にMQTT使う必要はないというシーンもあるかと。 
• 家電や商業施設などMQTTを使える環境が増えてきたときには実装やノウハウの使い回しがきく。 
そのままMQTTを実装した機械とやりとりを出来るようにするためのコストが低くなるかも。 
• よい実装やサービスがそろってきて、複雑性のためのコストを過剰に払わなくてよくなり(フレー 
ムワークが複雑性を吸収してくれるとか、あるいは後で紹介するsangoのようなサービスを利用 
するとか)、省エネやマシンネットワークとの連動性などのメリットの方が大きいスポットであ 
れば、適切なQoSを選択しつつ使い始めるのがよいのでは。特に省エネは重要なシーンは既に 
多い。 
• CoAPと合わせてウォッチしておくと良さそう
ライブラリ 
• http://mosquitto.org/ 
• http://www.eclipse.org/paho/
PerlでMQTT 
• AnyEvent::MQTTというモジュールがある 
• クライアントとしてのみ 
• 探してみたけどサーバー実装はなさそう 
• 他の言語のサーバー実装を用意しにくい場合は、sangoで試すといいか 
も
sangoでの利用例 
8月29日から使えるように 
https://sango.shiguredo.jp/
sangoでの利用例 
登録するとこんな感じになるので 
接続情報を使ってAnyEvent::MQTTから使ってみる
sangoでの利用例 
subscriberを書いて起動しつつ
sangoでの利用例 
publisher側も書いて実行
sangoでの利用例 
HOGEHOGEというメッセージが 
ちゃんと届きました
Bluetooth LE
Bluetooth Classic 
• 旧来のよく知られているBluetooth 
• LEとの差別化のためにClassicと呼ばれる 
• 2000年くらいから流行 
• ユビキタスネットワーク -> 最近でいうところのIoT 
• 高速化を追求 
• 他の無線技術とあまり差別化できなくなってきていた
Bluetooth Low Energy (BTLE) 
• LE = Low Energy (省エネ) 
• Bluetooth 4.0から 
• それまで(Bluetooth Classic)は高速化を追求 
• 別物と考えるくらいで 
• 4.0=LEではなく、4.0の中にLEの他にHS(HightSpeed)なども
Paring 
• 旧来のBluetoothでは基本的にデバイスのペアリング必要。2.1以上ではSecure Simple Paring 
• Just Works 
• Out of Band (NFCとか) 
• Passkey Entry 
• Numeric Comparison 
• iBeaconなどに見られるようにLEではペアリングの無いユースケースがほとんど 
• LEも似たようなモデルがあり、PassKeyEntryも一応存在するし、逆に、上に上げたように、 
ClassicにもJust Worksがあり、確認なしで使える仕様も存在はする。 
• とはいえ、LE用のSDK/チップではJust Worksしか採用されてなかったりする
Bluetoothのネットワークトポロジ 
ピコネット 
複数のデバイスとやりとりする中心になるのがセントラル 
ClassicではMaster/Slaveという言い方をして、 
Central/Peripheralとは言わない 
Central 
Peripheral 
例: PC 
例: キーボード 
マウス 
Peripheral 
例: 室温系 
Peripheral 
例: 体重系 
ペリフェラルがサービスの主体になるデータを提供するケース 
(ペリフェラルがサーバー、セントラルがクライアント) 
が多い 
ペリフェラルにデータをWriteするケースもある  
サーモスタットの温度とか(設定系)
Bluetoothのネットワークトポロジ 
スキャタネット 
ヘッドホンなどは主体となるデータ(音声データ)の置き場はPC側になり、データの流れが逆になる 
Master 
Slave 
例: PC 
例: キーボード 
マウス 
Slave 
例: 室温系 
Slave 
例: 体重系 
Master 
例: ヘッドホン 
Slave 
Masterは同時にSlaveとなり、他のピコネットに参加することができる 
Classicのみ。LEではペリフェラルは同時にセントラルとなることは出来ない
ネットワークへの参加 
• Classic: Service Discoveryの仕様(今回は省略) 
• LE: Advertising
ネットワークへの参加 
Advertising Packet 
• サービスのUUID 
• LocalName 
• その他 
Observer Broadcaster 
(Central) (Peripheral) 
ペリフェラルは周期的にアドバタイジングパケットを発信 
「こんなサービスを提供していますよ」という情報
ネットワークへの参加 
Advertising Packet 
• サービスのUUID 
• LocalName 
• その他 
Observer Broadcaster 
(Central) (Peripheral) 
セントラルは周期的にスキャンを行い、 
周囲からアドバタイジングパケットを探す。
ネットワークへの参加 
必要であれば、もう少し詳しい情報を相手に要求できる 
Observer Broadcaster 
Scan Request 
(Central) (Peripheral)
ネットワークへの参加 
ペリフェラルは、Scan Requestを受け取った場合はScan Responseを返す。 
アドバタイジングパケットに乗り切らない情報をここに載せることが出来る 
最初のアドバタイジングパケットが大きすぎると省エネ的にも良くない。 
Observer Broadcaster 
Scan Response 
(Central) (Peripheral)
Advertising Packet 
• サービスのUUID 
• LocalName 
• その他 
ネットワークへの参加 
セントラルは受け取った情報から 
UUIDなどを見て、つなぎたいサービスかどうか判断。 
! 
サービスを受けたい場合は接続要求を 
ペリフェラルに投げて接続を開始 
接続要求 
Central Peripheral 
接続が完了するとBroadcaster/Observerとしての役目は終わり、 
Peripheral/Centralとなる
CentralとPeripheralのやりとり 
接続が完了するとセントラルは定期的に、空パケットで 
ポーリングを行い接続を維持する。要はPing。 
必要だったらポーリングのレスポンスにデータを載せたり。 
ポーリング 
Central Peripheral
CentralとPeripheralのやりとり 
周波数チャンネル 
混線によるノイズを避けるために 
周波数ホッピングを行い、 
チャンネルを切り替えながら通信する 
Central Peripheral 
ClassicでもLEでも周波数ホッピングは 
あるが、LEではホッピングの回数が 
少なくなるよう工夫されている。
CentralとPeripheralのやりとり 
前述のような接続維持を行いつつ、 
セントラルは、接続先のペリフェラルが提供しているサービスを利用できる 
Central Peripheral 
サービス
Profile 
Profiles (Application) 
Host 
HCI - Host Controller Interface 
Controller 
物理層 
• HSP(HeadSetProfile) 
• HIDP(HumanInterfaceDeviceProfile) 
• … 
あらかじめ用意された 
アプリケーション仕様(Profile) 
! 
ヘッドセット、キーボードなどの入力、オーディオなど 
Bluetoothでの利用されるような機能は 
Profile仕様が最初から用意されている
Profile 
Host 
あらかじめ用意されたものでなくて、自由にサービスを設計したいときは? 
Classicの場合はSPP(Serial Port Profile) 
LEの場合はGATT(General Attribute Profile)
GATT 
Central 
Peripheralが提供するサービスとはどんなもの? 
Peripheral 
サービス 
室温計の例 
現在の室温: 28度 
READ 
センサーから取得できる変動値 
サービスが提供する値を 
読み取ることができる
GATT 
Central 
Peripheralが提供するサービスとはどんなもの? 
Peripheral 
サービス 
サーモスタットの例 
設定温度: 28度 
WRITE 
機械の内部のconfig値 
スイッチ: off 
コントロールポイント 
一つのサービスは 
複数の値をもてる 
サービスが提供する値に 
書き込むことができる
GATT 
Peripheral 
サービス 
設定温度: 28度 
機械の内部のconfig値 
スイッチ: off 
コントロールポイント 
Centralから読み書きさせることが出来る 
これらの値のことをcharacteristicと呼ぶ 
読み書き以外に、値が変化したときの通知依頼も 
一つのサービスは複数のcharacteristicを持てる 
characteristic 
characteristic
GATT 
一つのPeripheralは複数のサービスを持つことが出来る 
Peripheral 
サービス 
設定温度: 28度 
機械の内部のconfig値 
スイッチ: off 
コントロールポイント 
サービス 
現在の室温: 28度 
センサーから取得できる変動値
Bluetooth LEのサービス利用手順まとめ 
• Peripheralとして振る舞うデバイスがアドバタイズ 
• Centralとして振る舞うデバイスがスキャンしてアドバタイジングパケッ 
トを発見 
• CentralやPeripheralに接続して、目的のサービスを検索 
• サービスの中から目的のCharacteristicを発見し、読み書き等
iOS/Androidでのsupport状況 
• iOSは5.0からBTLEがSDK(CoreBluetooth)に、まずはセントラルのみ。 
6以降でペリフェラルとしても動作可能。なのでほぼ普及済と考えられ 
る。 
• Androidは4.3からBTLE(セントラル)搭載。Preview Lからペリフェラ 
ルとしても動作可能。Preview Lからはle用にパッケージが別になった 
ので、4.3のときに使えたセントラル用のAPIも刷新されてる。
iOS/AndroidでのBluetooth Classic 
• LEサポート前からClassicのほうは利用できた 
• LEのようにGATTがないので、既存のプロファイルにない自由なサービ 
スを使おうとするとSPP(serial port profile)を使う必要がある 
• iOSではAppleからMFi (Made for iPhone)を取得する必要
iOS/Androidでのsupport状況 
iOSではLEが簡単でClassic&SPPがMFiのため面倒 
AndroidではSPPは簡単、LEは普及に時間かかりそう 
iOSとAndroidで通信したい場合は悩ましい
iBeacon 
• CoreLocation 
• 屋内位置情報 
• Ranging/Monitoring
位置情報サービス 
GPS 
iBeacon 
比較的大きな領域での位置や移動 
屋内での細かい位置情報や短距離移動 地図と組み合わせたサービス 
などに基づくサービス
iBeacon 
Advertising Packet 
• サービスのUUID 
• LocalName 
• その他 
Broadcaster 
Broadcasterとしてのみ (Peripheral) 
振る舞うBTLEデバイス 
パケットの送信距離が10m程度なのを利用して 
データ転送よりも近接検知に利用
用語の注意 
• iBeaconが近接検知技術と言われるが 
• NFCなどのスマートカード界隈では近接(proximity)は10cm以内、 
70cm以内だと近傍(vicinity)とか 
iBeaconの近接 = BTLEのパケット送信可能距離 
ICカードの近接 = カード/リーダで電磁誘導が発生する距離
iBeacon 
Advertising Packet 
ビーコン 
Advertising 
Packet 
電波が届く距離までビーコンに近寄ったことがわかる 
電波強度(RSSI)からアバウトに距離の推測 
ノイズの問題もあり正確には分からない。ビーコンの方位もわからない。
iBeacon 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
ビーコンが飛ばすパケットにはUUIDと二つの16bit整数値(major/minor)がある 
UUIDを指定して監視しておいて、対応するアプリでアクションを実行したり、 
PassKitでクーポンを表示したり。
iBeacon 
ビーコンA 
ビーコンB 
二つの数値を利用して、どのビーコンに近接したかの判断 
施設内での移動の検知 
Advertising 
Packet 
UUID 
major: 1 
minor: 1 
Advertising 
Packet 
UUID 
major: 1 
minor: 2
iBeaconでのBTLEまとめ 
• Bluetooth LE の Broadcasterである 
• Peripheral/Central間で接続確立&データ転送はしない 
• Advertising Packetの中に収まるデータしか使えない 
• major/minorという16bit整数値二つ入れる 
Bluetooth LEの利用の仕方自体はものすごくシンプル
iBeacon以外での 
BTLE(と他の技術の組み合わせによる)活用の 
可能性と課題
High Contextな情報の取得&操作の 
エントリポイントとしてのBTLEデバイス 
歩いていたら気になった店があった 
• ポケットからスマホを出し 
• 店の名前などで検索する
High Contextな情報の取得&操作の 
エントリポイントとしてのBTLEデバイス 
歩いていたら気になった店があった 
• 近寄ったときに店頭のデバイスからBTLE経由で情報取得済 
SEARCHless 
• 気になったときにウェアラブルデバイスなどですぐ確認 
さらに大きい画面で詳細が見たくなるまでは 
ポケットからデバイスを出さなくもいい
情報消費スタイル 
2000年以前 BROADCAST 
テレビ、ラジオ、雑誌、みんなに届ける。消費者はチャンネル選択。 
2000年 PULL 
見たいものを見たいときに見る。Searchがキラーアプリケーション。 
2010年 PUSH 
自分に関係する情報、自分が欲しい情報のアップデートが即座に手元に届く 
自分だけでなく友人の情報も(Social)
情報消費スタイル 
201X年 PICK 
今必要な情報はまわりに落ちている
ウェアラブルデバイスとの連動 
ウェアラブルによく見られるデータの流れ: 二つの方向 
Cloud 
Cloudから(リモート通知) 
体の中から(健康情報)
ウェアラブルデバイスとの連動 
現在欠けている三つ目の方向があるのでは 
Cloud
ウェアラブルデバイスとの連動 
Cloud 
Semantic Real World 
HighContextな 
情報に満たされた世界からの 
情報取得=PICK 
Machine Automation 
MQTTなどで自動化された 
マシンネットワークへの介入操作 
ここで主要な役割を果たすのが 
BTLEやNFC
ウェアラブルデバイスとの連動 
現在だと、GoogleGlassでカメラを利用した 
一部のアプリなどが該当するぐらい? 
Semantic Real World 
HighContextな 
情報に満たされた世界からの 
情報取得=PICK 
Machine Automation 
MQTTなどで自動化された 
マシンネットワークへの介入操作 
エコシステムやインフラがまだ整ってない 
ウェアラブルデバイスは 
インターネット普及前のパソコンのように 
本領発揮できていないかも
このような将来のネットワークを考えてみると、実はiBeaconは、 
近接検知によるクーポン送信装置にとどまるものではなく、次 
世代のHTTP GET的な非常に重要なポジションを取りにきてる 
のかも
Personalization 
 Webが単純なホームページから、 
PersonalizeされたWebサービスへと 
発展していったように 
単純なデータの取得の次は 
パーソナライズが要求されはじめることが予測される 
近接検知によって出すクーポンを 
ユーザーごとに変えたいとか 
Security & Privacyの考慮もより必要になってくる
Personalization (例1) 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
ユーザーAの 
WebService Bでの 
アカウント情報 
ビーコンに近づくと、そのUUIDに該当するアプリが起動 
あらかじめ登録されていたURLにアクセス 
あるいはmajor/minor値を使いアクセス先のURLを変える
Personalization (例1) 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
ユーザーAの 
WebService Bでの 
アカウント情報 
その際に、あらかじめスマホに保存された 
アカウント情報やOAuthのtokenなどで認証を行う。 
アカウント情報
Personalization (例1) 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
ユーザーAの 
WebService Bでの 
アカウント情報 
サーバーは認証によって特定したユーザーのために 
パーソナライズされたコンテンツ(クーポン等)を配信 
パーソナライズされた 
コンテンツ
Personalization (例2) 
Peripheral 
ビーコン(Broadcaster)ではなく、 
PeripheralとCentralとして接続を確立し 
HTTPのRequest/Responseのようなやりとりを行う 
Advertising 
Packet 
ユーザーAの 
WebService Bでの 
アカウント情報 
1: 認証情報用のcharacteristicにwrite 
3: このユーザ用のコンテンツが準備できたらnotify 
4: コンテンツのcharacteristicをread 
Web 
Service 
ペリフェラルデバイスは裏でWebサービスと通信を行い 
Proxyのように振る舞う2: writeされた認証情報を使って 
裏でデータ取得
POSTの例 
今食事しているお店でチェックインしたい 
現在の行動フロー 
• ポケットからスマホを出し 
• チェックインアプリを起動 
• お店を検索 
• 選択してからチェックイン 
これももっと改善できるのでは
Postの例 (1) 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
ユーザーAの 
WebService Bでの 
アカウント情報 
ビーコンに近づくと、そのUUIDに該当するチェックインアプリが起動 
あらかじめ登録された該当URLにPOSTを開始する 
あるいはmajor/minor値によってURLを変える 
店情報など
Postの例 (1) 
プライバシー上問題となるケースが多いと予想される。 
ビーコン 
近接だけで勝手にポストするのは 
ユーザーがトリガーを押す画面が必要に。 
Wearableで操作できれば便利 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
チェックイン 
ボタン 
ユーザーAの 
WebService Bでの 
アカウント情報店情報など
Postの例 (1) 
ビーコン 
Advertising 
Packet 
UUID 
major/minor 
WebService B 
ユーザーAの 
WebService Bでの 
アカウント情報 
チェックインボタンが押されたら、 
デバイスに保存されていたアカウント情報と 
アドバタイジングパケットより取得したshop_idなどの 
店情報を使ってWebService Bにポスト 
major/minor値をそのままshop_idにするのもあり 
店情報など 
アカウント 
情報 
shop_id
Postの例 (例2) 
Peripheral 
Advertising 
Packet 
ユーザーAの 
WebService Bでの 
アカウント情報 
1: 認証情報用のcharacteristicにwrite 
Web 
Service 
アカウント情報以外の投稿用パラメータはペリフェラル側でプリセットされていて 
ユーザーがわざわざ入力する必要はない 
2: writeされた認証情報と 
プリセットされたパラメータをあわせて 
ポスト 
preset parameters 
店情報
POSTの例 
あらかじめスマホ上にあるアカウントなどの認証情報と、 
ビーコンなどのデバイスが持つプリセットされたパラメータにより、 
ユーザーのアクションのコストを削減 
という感じで、 
食事していたら、店の情報が時計に表示されてる。 
あとはチェックインボタンを押すだけ、というような 
エクスペリエンスの提供が可能になるかも 
ただしPrivacy&Securityはよく考慮する必要がある。 
GET(PUSH)でも大事だが、POSTは特に。 
近接からの自動化じゃなくて、ユーザーにトリガーを預けるケースが多くなるのでは 
とはいえ、Paypal Hereの顔パス認証のような 
オフラインならではのものも出てきている
POSTの例 
どういう形でユーザーにトリガーを引いてもらうか 
wearable上で画面を見せてアクションボタン 
あるいはNFCでタッチ 
目の前で本人が自分のデバイスでタッチするということが 
あるレベルの認証といえる(BTLEがあればNFCいらないということはない) 
ただし、クレジットカードと同じように 
他人のデバイスを使うなどの悪用は考えられる。 
あとBTLE間で転送されるデータの偽造の可能性なども考慮
まとめ 
• BTLEは応用の余地がまだたくさんありそう 
• MQTTはメリットとデメリットちゃんと把握した上でなら既 
に使える技術、今後も面白い用途が出てきそう 
• BTLE/MQTT/Wearableなどそれぞれの技術の相互作用によ 
る進化を考えると面白そう
ご清聴 
ありがとうございました

Contenu connexe

Tendances

Io t縛りの勉強会 #4
Io t縛りの勉強会 #4Io t縛りの勉強会 #4
Io t縛りの勉強会 #4Daichi Morifuji
 
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~Brocade
 
クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門Naoto MATSUMOTO
 
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月VirtualTech Japan Inc.
 
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-Takashi Sogabe
 
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月VirtualTech Japan Inc.
 
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-Takashi Sogabe
 
OpenContrail Users Event at OpenStack Summit Paris 行ってきました
OpenContrail Users Event at OpenStack Summit Paris 行ってきましたOpenContrail Users Event at OpenStack Summit Paris 行ってきました
OpenContrail Users Event at OpenStack Summit Paris 行ってきましたTakashi Sogabe
 
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月VirtualTech Japan Inc.
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NETterurou
 
君にもできる! にゅーとろん君になってみよー!! 「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...
君にもできる! にゅーとろん君になってみよー!!  「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...君にもできる! にゅーとろん君になってみよー!!  「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...
君にもできる! にゅーとろん君になってみよー!! 「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...VirtualTech Japan Inc.
 
100Gbpsソフトウェアルータの実現可能性に関する論文
100Gbpsソフトウェアルータの実現可能性に関する論文100Gbpsソフトウェアルータの実現可能性に関する論文
100Gbpsソフトウェアルータの実現可能性に関する論文y_uuki
 
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについてMEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについてVirtualTech Japan Inc.
 
20161129 neutron recent topic
20161129 neutron recent topic20161129 neutron recent topic
20161129 neutron recent topicAkihiro Motoki
 
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFVInterop Tokyo ShowNet NOC Team
 

Tendances (20)

Io t縛りの勉強会 #4
Io t縛りの勉強会 #4Io t縛りの勉強会 #4
Io t縛りの勉強会 #4
 
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~
そろそろビジネスに貢献するSDNを考えませんか?~キーワードは“オープン”~
 
クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門クラウド時代のネットワーク再入門
クラウド時代のネットワーク再入門
 
Juniper Festa @ Interop Tokyo 2017
Juniper Festa @ Interop Tokyo 2017Juniper Festa @ Interop Tokyo 2017
Juniper Festa @ Interop Tokyo 2017
 
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
 
Juniper Festa @ Interop Tokyo 2015
Juniper Festa @ Interop Tokyo 2015Juniper Festa @ Interop Tokyo 2015
Juniper Festa @ Interop Tokyo 2015
 
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-
Cumulus Linux 導入事例 -ネットワークをDevOpsに統合した、エンジニアが幸せになるインフラ運用手法のご紹介-
 
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月
OpenStackネットワーク入門 – OpenStack最新情報セミナー 2015年4月
 
Open stackdaystokyo2016
Open stackdaystokyo2016Open stackdaystokyo2016
Open stackdaystokyo2016
 
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-
オーバーレイネットワークで実現するプライベートクラウド -OpenStack/OpenContrailを用いたプライベートクラウドの構築及び評価計画のご紹介-
 
OpenContrail Users Event at OpenStack Summit Paris 行ってきました
OpenContrail Users Event at OpenStack Summit Paris 行ってきましたOpenContrail Users Event at OpenStack Summit Paris 行ってきました
OpenContrail Users Event at OpenStack Summit Paris 行ってきました
 
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月
NFV標準化動向 NFVの適用範囲と標準化 – OpenStack最新情報セミナー 2015年4月
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NET
 
君にもできる! にゅーとろん君になってみよー!! 「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...
君にもできる! にゅーとろん君になってみよー!!  「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...君にもできる! にゅーとろん君になってみよー!!  「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...
君にもできる! にゅーとろん君になってみよー!! 「Neutronになって理解するOpenStack Net - OpenStack最新情報セミナー ...
 
100Gbpsソフトウェアルータの実現可能性に関する論文
100Gbpsソフトウェアルータの実現可能性に関する論文100Gbpsソフトウェアルータの実現可能性に関する論文
100Gbpsソフトウェアルータの実現可能性に関する論文
 
MEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについてMEC (Mobile Edge Computing) + GPUコンピューティングについて
MEC (Mobile Edge Computing) + GPUコンピューティングについて
 
2015-ShowNetステージ-BGPFlowspec
2015-ShowNetステージ-BGPFlowspec2015-ShowNetステージ-BGPFlowspec
2015-ShowNetステージ-BGPFlowspec
 
20161129 neutron recent topic
20161129 neutron recent topic20161129 neutron recent topic
20161129 neutron recent topic
 
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV
2016-ShowNetステージ-バックボーンの機能としてのSDN/NFV
 
2015-ShowNet -DDoS/IX/BGPFlowspec/External
2015-ShowNet -DDoS/IX/BGPFlowspec/External2015-ShowNet -DDoS/IX/BGPFlowspec/External
2015-ShowNet -DDoS/IX/BGPFlowspec/External
 

Similaire à YAPC::Asia2014 - O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門

Lagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばLagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばYoshihiro Nakajima
 
SigfoxではじめるIoT勉強会
SigfoxではじめるIoT勉強会SigfoxではじめるIoT勉強会
SigfoxではじめるIoT勉強会Gaku Hibi
 
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps OnlineGKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps OnlineGoogle Cloud Platform - Japan
 
データセンター進化論:これ以上オープンになれないSDNとは?
データセンター進化論:これ以上オープンになれないSDNとは?データセンター進化論:これ以上オープンになれないSDNとは?
データセンター進化論:これ以上オープンになれないSDNとは?Brocade
 
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...Mitsuo Yamazaki
 
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-SORACOM, INC
 
20150715 xflow kikuta_final
20150715 xflow kikuta_final20150715 xflow kikuta_final
20150715 xflow kikuta_finalKazumasa Ikuta
 
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用Ruo Ando
 
Mk vpp for-containers-vppug
Mk vpp for-containers-vppugMk vpp for-containers-vppug
Mk vpp for-containers-vppugMiya Kohno
 
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~ データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~ Brocade
 
20140404 vyatta users Group / REST API解説
20140404 vyatta users Group / REST API解説20140404 vyatta users Group / REST API解説
20140404 vyatta users Group / REST API解説Yukihiro Kikuchi
 
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長Takahiro Moteki
 
急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea 急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea Motonori Shindo
 
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]Google Cloud Platform - Japan
 
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...Junji Nishihara
 
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...Hinemos
 
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送Google Cloud Platform - Japan
 

Similaire à YAPC::Asia2014 - O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門 (20)

P2Pって何?
P2Pって何?P2Pって何?
P2Pって何?
 
Lagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそばLagopus workshop@Internet weekのそば
Lagopus workshop@Internet weekのそば
 
SigfoxではじめるIoT勉強会
SigfoxではじめるIoT勉強会SigfoxではじめるIoT勉強会
SigfoxではじめるIoT勉強会
 
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps OnlineGKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
 
データセンター進化論:これ以上オープンになれないSDNとは?
データセンター進化論:これ以上オープンになれないSDNとは?データセンター進化論:これ以上オープンになれないSDNとは?
データセンター進化論:これ以上オープンになれないSDNとは?
 
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...
Nordic-Semi (Japan) ~ Next Step for IoT & Bluetooth Smart @ Wireless Japan 20...
 
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-
VPC詳細 -ほぼ週刊AWSマイスターシリーズ第7回-
 
20150715 xflow kikuta_final
20150715 xflow kikuta_final20150715 xflow kikuta_final
20150715 xflow kikuta_final
 
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用
法政大学情報科学部 2012年度コンピュータネットワーク-第11回授業-Web公開用
 
Mk vpp for-containers-vppug
Mk vpp for-containers-vppugMk vpp for-containers-vppug
Mk vpp for-containers-vppug
 
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~ データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~
データセンター進化論:SDNは今オープンに ~攻めるITインフラにの絶対条件とは?~
 
Open contrailのご紹介
Open contrailのご紹介Open contrailのご紹介
Open contrailのご紹介
 
20140404 vyatta users Group / REST API解説
20140404 vyatta users Group / REST API解説20140404 vyatta users Group / REST API解説
20140404 vyatta users Group / REST API解説
 
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長
[社内共有会]AWS NAT-GW導入と構成変化 2年運用して 同時接続数 秒間100->10万へ成長
 
急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea 急速に進化を続けるCNIプラグイン Antrea
急速に進化を続けるCNIプラグイン Antrea
 
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]
ゲーム業界向け Next '18 おすすめセッション完全網羅[Google Cloud INSIDE Games & Apps]
 
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...
Kong summit, japan 2021 Kongセッション 「秋に開催したグローバルカンファレンスKong Summit 2021から、主なトピッ...
 
さくらのクラウド導入セミナー(2016.10) 第二部 活用編
さくらのクラウド導入セミナー(2016.10) 第二部 活用編さくらのクラウド導入セミナー(2016.10) 第二部 活用編
さくらのクラウド導入セミナー(2016.10) 第二部 活用編
 
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...
【HinemosWorld2014】B2-2_ビジネス競争力に勝てるネットワーク基盤構築~Hinemos仮想ネットワーク管理オプション~ONIE・ZTP・...
 
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送
[Cloud OnAir] エンタープライズでのマイグレーション ツール活用 2019年8月8日 放送
 

Plus de Recruit Technologies

新卒2年目が鍛えられたコードレビュー道場
新卒2年目が鍛えられたコードレビュー道場新卒2年目が鍛えられたコードレビュー道場
新卒2年目が鍛えられたコードレビュー道場Recruit Technologies
 
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学びカーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学びRecruit Technologies
 
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~Recruit Technologies
 
HadoopをBQにマイグレしようとしてる話
HadoopをBQにマイグレしようとしてる話HadoopをBQにマイグレしようとしてる話
HadoopをBQにマイグレしようとしてる話Recruit Technologies
 
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所Recruit Technologies
 
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...Recruit Technologies
 
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例Recruit Technologies
 
ユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントRecruit Technologies
 
ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後Recruit Technologies
 
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-Recruit Technologies
 
EMRでスポットインスタンスの自動入札ツールを作成する
EMRでスポットインスタンスの自動入札ツールを作成するEMRでスポットインスタンスの自動入札ツールを作成する
EMRでスポットインスタンスの自動入札ツールを作成するRecruit Technologies
 
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイントリクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイントRecruit Technologies
 
ユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントRecruit Technologies
 
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアル
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアルリクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアル
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアルRecruit Technologies
 
「リクルートデータセット」 ~公開までの道のりとこれから~
「リクルートデータセット」 ~公開までの道のりとこれから~「リクルートデータセット」 ~公開までの道のりとこれから~
「リクルートデータセット」 ~公開までの道のりとこれから~Recruit Technologies
 

Plus de Recruit Technologies (20)

新卒2年目が鍛えられたコードレビュー道場
新卒2年目が鍛えられたコードレビュー道場新卒2年目が鍛えられたコードレビュー道場
新卒2年目が鍛えられたコードレビュー道場
 
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学びカーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
カーセンサーで深層学習を使ってUX改善を行った事例とそこからの学び
 
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~
Rancherを活用した開発事例の紹介 ~Rancherのメリットと辛いところ~
 
Tableau活用4年の軌跡
Tableau活用4年の軌跡Tableau活用4年の軌跡
Tableau活用4年の軌跡
 
HadoopをBQにマイグレしようとしてる話
HadoopをBQにマイグレしようとしてる話HadoopをBQにマイグレしようとしてる話
HadoopをBQにマイグレしようとしてる話
 
LT(自由)
LT(自由)LT(自由)
LT(自由)
 
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所
リクルートグループの現場事例から見る AI/ディープラーニング ビジネス活用の勘所
 
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
Company Recommendation for New Graduates via Implicit Feedback Multiple Matri...
 
リクルート式AIの活用法
リクルート式AIの活用法リクルート式AIの活用法
リクルート式AIの活用法
 
銀行ロビーアシスタント
銀行ロビーアシスタント銀行ロビーアシスタント
銀行ロビーアシスタント
 
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
リクルートにおけるマルチモーダル Deep Learning Web API 開発事例
 
ユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイント
 
ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後ユーザーからみたre:Inventのこれまでと今後
ユーザーからみたre:Inventのこれまでと今後
 
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-
Struggling with BIGDATA -リクルートおけるデータサイエンス/エンジニアリング-
 
EMRでスポットインスタンスの自動入札ツールを作成する
EMRでスポットインスタンスの自動入札ツールを作成するEMRでスポットインスタンスの自動入札ツールを作成する
EMRでスポットインスタンスの自動入札ツールを作成する
 
RANCHERを使ったDev(Ops)
RANCHERを使ったDev(Ops)RANCHERを使ったDev(Ops)
RANCHERを使ったDev(Ops)
 
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイントリクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
リクルートにおけるセキュリティ施策方針とCSIRT組織運営のポイント
 
ユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイントユーザー企業内製CSIRTにおける対応のポイント
ユーザー企業内製CSIRTにおける対応のポイント
 
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアル
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアルリクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアル
リクルートテクノロジーズが語る 企業における、「AI/ディープラーニング」活用のリアル
 
「リクルートデータセット」 ~公開までの道のりとこれから~
「リクルートデータセット」 ~公開までの道のりとこれから~「リクルートデータセット」 ~公開までの道のりとこれから~
「リクルートデータセット」 ~公開までの道のりとこれから~
 

Dernier

情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 

Dernier (11)

情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 

YAPC::Asia2014 - O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門