読者です 読者をやめる 読者になる 読者になる

FUJILOG

見た、聴いた、触れたこと。 動かしたもの、書いたもの。 ウェブとリアルの備忘録です。

1ページで理解するP2P(Torrent編)

P2Pと聴くと不慣れなために抵抗感があったので、理解補助のためにTorrentの仕組みを調べてました。
 
すると、この資料を発見。

www.gitbook.com

 

ここまでP2Pの仕組みをわかりやすく書いてくれたkyorohiro++

ということで、理解したことを1ページにまとめるエントリ。

 

 
ざっとまとめてみると…
 
  1. Torrent file
    1. bencode
      データ形式の一つ。文字列、整数、辞書、リストの4つのデータを扱う。
    2. Torrent file
      Torrent fileはbencode形式で記述される。
      その内容は、「Trackerサーバのアドレス」「配信ファイル情報」「(分割された)ブロックデータごとのSHA1 Hash値」等で構成。

  2. UPnP
    1. Port Mapping
      1. 前提:P2P通信するために、GlobalPを取得する必要がある。
      2. UPnP Multicastで接続しているルーターにポートマッピング依頼用アドレスを発行。
      3. TCPでそのアドレスを通じて、Port Mapping依頼を発行。
      4. SSDPグループに参加して、リモートデバイスのGlobalIPを取得する。
        SSDPグループの参加手順
        1. UDPソケットを作成する
        2. SSDPグループからPort Map対応可能なデバイスを検索する
        3. ルーター経由でデバイスグローバルIPを取得する

  3. Tracker
    1. TrackerはHTTPサーバ。データを配信している Peer の一覧を管理する。
    2. クライアントはTrackerに対して、Getリクエストでデータ配信しているPeerの一覧を取得する。
    3. リクエスト内容
      Getリクエストで下記データ群を送信。
      「自身のPeerを識別する20byteのIDを生成」「Torrentファイル Info辞書のSHA1 Hashを生成」「サーバ側の通信用portの用意」「アドレスを生成」
    4. リスポンス内容
      Bencoding形式でデータを返す。
      「データ配信しているPeer一覧(ID、アドレスとポート番号)」

  4. DHT(分散ハッシュテーブル)
    サーバ・クライアント方式でない方式。特徴は以下3点。
    ・Peerは受け取ったInfoHashをもとに、その対応データを持ちそうなPeerを紹介する
    ・Peerどうしはお互いの距離を知っている
    ・Peerは自身に近いPeerの情報を多く持っている
    1. TorrentのDHT機能
      DHTの名前は「Kademila」
      ・XORでPeer間の距離を計算
      UDPでPeerどうしが通信を行う
    2. RoutingTable
      ・kBucketのRootingTableでPeerの一覧を管理(※kBucket:K個のPeer情報を格納する入れ物、Peerの識別子はKID)
      ・RootingTableは、0〜160までの161個のkBucketを保持する事ができる
      ・RootingTableを所持しているPeerとのXORを計算し、その値をもとにどのkBucketに追加するかを決める
    3. FindNode
      ・FindNodeクエリとFindNodeレスポンスでDHTネットワークを構築する
      ・FindNodeクエリを利用すると、指定したKIDにもっとも距離が近いNodeを教えてもらえる
      ・リスポンスを受けたらRootingTableを更新する  
    4. GetPeer/AnnouncePeer
      ・GetPeersメッセージを利用して、データを所持しているPeerまたは最も近いPeerを探すことができる
      ・GetPeerを繰り返して、上位K個のNodeが固定されたら、AnnounePeerメッセージを利用してデータを記録する
 
さらに簡略して、Torrentの仕組みを3行で書くなら…
  • Torrent fileをもとにPeer間でデータ送受信
  • リモートデバイスと通信するにはNAT越えが必要で、UPnPでリモートデバイスのGlobalIPを取得
  • クライアント・サーバ方式であればTrackerを、Trackerを介さない方式であればDHT(分散ハッシュテーブル)でP2Pを実現
 
UPnPでGlobalIPを取得する、Peer間のデータ受け渡しは分散ハッシュテーブルで実現されるという箇所が、技術の要のようでした。
 
 
■補足
UPnPUniversal Plug and Play):UPnPは、機器を通信ネットワークに接続すると、複雑な設定作業を行わなくても他機器と通信したり、その機能を利用できるようにするプロトコル
 
SSDP(Simple Service Discovery Protocol):SSDPは、ネットワーク上の機器を自動的に発見・接続するUPnPで用いられるプロトコルの一つで、機器の探索や応答を行うためのもの。

 

 

Botkit と Bluemix Watson Translate APIで自動翻訳Botを作成したけど社内で採用されなかった件

tl;dr

  1. グローバル事業を進めているなかで、英語圏メンバーが日本語チャットの内容を気にしている
  2. 社内ではSlackを使用しているので、日本語メッセージが投稿されたら、それを自動翻訳してくれるBotがあればいいんじゃないかと思い実装
    ※ 日本メンバーに /translate @bot en "ほげほげ" とか逐一入力させたくない
  3. いざSlack連携するも、Watson APIの邦訳精度と諸般の事情でBot導入見送り

 

手順

  • Slackコンソールで、Slack botを作成
    ※ここではAPIのTokenを控えておく(xoxb-からはじまるもの)
  • BotKitでbotプログラムの雛形を用意
  • Node.jsでbotプログラムを編集
    ※Slackのbotへのアクション問わず、チャンネルへの投稿に反応するようにした
  • Bluemixで「Node.jsアプリ」の作成とそこでの「環境変数(slackbot_token)」の設定、Watson Language Translator APIの連携設定
  • Bluemixへbotプログラムをデプロイ
  • Slackのチャンネルうち、自動翻訳させたいチャンネル上で翻訳botをInviteする

 

つまずきポイント

  • cloud flareなるBluemixのCLIツールあり
    ※cf コマンドが使用可能になる
  • cf コマンド
    $ cf api https://api.ng.bluemix.net
    $ cf login
    $ cf push --no-route -u process
    ※ワーカーとして稼働させる場合
    cf push コマンド単体は、Webアプリでないから今回はこれはダメ
  • Bluemixデプロイ前に、ローカル上で単体で稼働させる場合
    $ slack_token=xoxb-(your-slackbot-token) node ./bot.js

 

参照

参加録 SORACOM if-up 2017

御茶ノ水駅徒歩1分の商業施設ソラシティ。

その2階のカンファレンスルームにて、SORACOM主催のイベント開催。

昼暑くて、夜冷える時期ですね。

f:id:michael-unltd:20170421011722j:image

 

イベントタイムテーブル

if-up2017.soracom.jp

 

参加セッションは以下のものです。

 

朝の社用を済ませてからの参加。

キーノートの途中入場、SORACOM CTOの安川さんのお話からメモしていました。

IoTインフラのサービス設計のお話。

www.slideshare.net

ユーザー数が増え、海外展開して、新サービスを追加リリースしても、既存サービス群にはほぼ手を入れずにスケールする設計思想の裏側を知ることができたのは財産でした。

 

次いで玉川さんモデレータのパネルセッション、IoTの現状と展望を見渡すお話し。

www.slideshare.net

 

キーノート後。

なにせ天気の良いものだから外でお弁当食べました、地球食堂の角煮弁当。 

※この後のランチセッションという単語を見落としていてランチ2発。

 f:id:michael-unltd:20170421011738j:image

 

B1:エッジヘビーコンピューティングと機械学習

 PFN社の機械学習、深層学習事例について。

www.slideshare.net

 

B2:デバイスデザインパターンユースケース別デバイス選定〜

ネットワークのデザインパターン。実例紹介があり、インフォキューブ社の「地域密着位置情報サービス」、ザイマックス社の「商業施設の設備機器異常検知システム」が挙げられていました。

www.slideshare.net

 

A3:業務システムとの連携〜閉域網とクラウド

実例は、HandsLab「ショッピングセンター向けポイントカード基盤システム」、小松製作所の「スマートコンストラクション」。

 

www.slideshare.net

 

HandsLabでは2ヶ月で商用サービスリリースしたのと、小松製作所の事例は本気のIoTでした。そしてスマートコントラクションはAWSでなくてAzureクラウドに乗っていたのですね。

SORACOMサービスうち「Door」「Gate」を活用し、既存システムの専用線やスケーラビリティ厳しいVPNの置き換えを行っていたところから、IoTサービスとSORACOMサービス群が相性バツグンなのが伝わりました。

f:id:michael-unltd:20170421021504j:image

f:id:michael-unltd:20170421021511j:image

f:id:michael-unltd:20170421021537j:image

 

A4:カメラデバイスクラウド〜スムーズな連携のために〜

SORACOM、スマカメ、ABEJAの提携事業。

スマカメで撮った映像を、ABEJAがリアルタイム解析して店舗内の動線ヒートマップ等で可視化。両社のエンジニア間で技術交流をされているとのこと。 

 

※おそらく後日スライド公開

  

f:id:michael-unltd:20170421021424j:image

 

メモした内容を下記に残します。

***

□ SORACOM Inside
SORACOM CTO安川さん

 

クラウドにインテリジェンスがある

バイス制限(非力)
NWへの接続
セキュリティ
クラウドとのインテグレーション
LoRaWAN(基盤)

A〜Hまでサービスあります
 SIM認証 Soracom Endose
 仮想L2 Gate

基本
 Polaris 回線
 Dipper 認証課金
 Hubble 監視

アーキテクチャはローンチ以来変わってない」

独立したマイクロサービス、を提供しているDipper
すべてAPIで連携する

IoTスケールなプラットフォーム実現のためにやったこと
 Scalability&Avairability
 地理的&技術的
 進化のAgility
 運用効率

現在、5,000以上のクライアントが利用

1:Horizontal Scalability
負荷増える
コアコンポーネントがサーバを動的に増える仕組み

Built in Resilience
 SPOFがない構成
 障害あっても自動復旧

全レイヤーに。
Dipper:DynamoDBを使用

2:グローバルレイヤー
グローバル前提

2017年
1月USA
3月ヨーロッパ

User Console(SPA)
API
SORACOM連携

言語は初期から日、英
Day1からタイムゾーンUTCにしている
※世界に配置しても同じ基準である

Layeredアーキテクチャ
 SORACOM Airが基盤

SIM for Global
120国超える

LoRaWAN
LoRaデバイスで新しい無線技術もサポートもスムーズ
ユースケース

3:疎結合化と非同期化

新サービス12回
リリース38回

パケット転送
帯域制御

課金データ→S3(アーカイブ
S3 Notification ダウンロードして処理

独立して進行
 課金エンジニア
 コアエンジニア

SORACOM Funnel

 簡易プロトコル
 TCP/UDP/HTTP/LoRaWAN

内部アーキテクチャ

Kinesisのストリーム
→Lambdaファンクション

新サービス増加=新たなLambdaFunctionの追加で済む

4:運用を考えた開発DevOps、開発のための運用

Service Health Dashboard

コンポーネントにはPrimary Ownerがいる
PrimaryOwnerが開発、メンテンナス、運用に携わる

攻めの開発
 守りが手薄になることある

OpsDevエンジニアの導入
運用中心
省力化に注力

Hubble部
アクティブ監視
Slackに通知

自動復旧を施行
解決したら通知

EC2 Tagで各インスタンスのRoleを設定
Hubbleは自動で対象インスタンスとその監視項目を認識

---

□ パネルディスカッション
LINE 砂金さん(い)
アーム 内海弦さん(う)
モデレータ 玉川さん(た)
※途中、まつもとゆきひろさん参加(ま)

潮目が変わるとき
 Web1.0 Web、PC
 Web2.0 ソーシャル

(う)1990年ケンブリッジ設立
株主
 エイコーンコンピュータ
 アップルコンピュータ
 VLSIテクノロジー

マイクロプロセッサ開発専業ベンチャー
知財
 設計するけど製造しない

IoT勝者のために
 セキュリティ、省電力、エコシステム

Softbank買収
 ロンドン上場(EPSを気にしていた)
 2016年9月 細かいこと気にしなくて良くなった

(い)LINE
チャットボット広めたいコンセプト動画
 恵比寿で3000円くらいのレストランの提案、予約まで

中古車検索
Beaconメッセージ
スプリンクラーが反応してとかIoT

普段アプリ
 月に1回以上 27個
 月に2回以上 19個
 月に10回以上 9個

LINEボットアワード
「&HAND」
 白杖にBeaconを仕込んだ

多かった
 IoT
 Beacon

Leafeeホームセキュリティ+LINE Chatbot

LINE
 MAU 6,600万人
 DAU アクティブ 70%

(た)
IoT気になるもの
Skypeリアルタイム翻訳
 空COM
 DeepLearningはじまった
Google AutoDraw
Mastodon 分散SNS
・10$のRapsberry Pi Zero W(※アーム)


IoT儲かるの?
 新しいお金の稼ぎ方

アーム
 デバイスたくさんだと値段下がる
 トランザクションで取る?

LINE
 スタンプ?
 コミュニティ、行動データをプロファイル
 広告主へ広告商品として販売している
 ビッグデータ解析で儲かってる
 行動が広い範囲でわかる

(ま)
 IoTでエンジニアの仕事が増える

(た)
IoT Landscape
  アプリ、プラットフォーム、…


10大インパクトについて

LINE
 人間対人間
 コグニティブ(IBMとか)、
 音声認識は厳しい(Clover、

 MSの頃
  AWSと戦う
  AWS Echoと戦う

 英語圏で勝つことは市場に勝つことではない
 LINEが日本、韓国、中国まで網羅したい
 スマートフォンがなくなったときはどうなる?
 スマートスピーカーは画面から飛び出す覚悟

(う)
 エッジコンピューティング
 小さい伝送データ
 IoTは分散コンピューティング
 分散と集中の歴史
 分散、トータルエネルギー

(ま)
 現時点、IoTは集中
 Rubyはサーバサイド
 2010年、マルチコア時代
 エッジ複雑化に合わせてmrubyを開発

エンジニアに向けて
(い)
 Oracle6年、MS8年
 LINE、日本頑張る
 自分で発信する
 開発チームはコンパクト
 台湾出張(LINE)、Azure売上70%は台湾、製造立国

(う)
 日本は技術立国です。
 好きなことやってほしい

(ま)
 未来をつくるのがエンジニア

---

■ B1:エッジヘビーコンピューティングと機械学習

2016/11
SORACOM
今井雄太氏

ユースケース

機会学習とIoT
どこまでクラウド

エッジ
 計算リソース少ない
 現場に近い

ネットワーク

クラウド
 計算リソース多い
 現場に遠い

正しいアーキテクチャの上で。


PFN
田中大輔

”Make everything intelligent and collaborative”
Investors: FANUC, TOYOTA, NTT

PFIからスピンアウトして設立4年目。
社員数80名

2軸
   Cloud
Consumer Industrial
   Device


人工知能

PFN
岡之原氏
 DeNA Techcon 2017/02/10

AIへのPFNのスタンス
 健全な発展のために

金融系SIer金融工学ライブラリ実装
製品開発、SensorBee

エッジヘビーコンピューティング

機械学習とは

昔はルールベース
 ゴルフ and VW -> 車
 インテル and 長友 -> サッカー


ルール vs 機械学習

github.com/Newmu/dcgan_code
"dcgan"が盛ん

IoT時代の到来

エッジヘビー
 データ爆発
 深層学習

データを一箇所に集めずに深い分析をする

CeBIT2017

R&D
 データ集めて、分析、レポート、フィードバック

どのデータを使うのかはっきりしない
機械学習への要件が変わった
プロトタイプのときとデータ違う…?

アジャイルとR&Dの差
ベロシティ図れるのか?

チケット
2週間じゃ短い
連携を埋めるのが大事


PoCであたりをつけることが多い
 データ量や次元数
 集める期間

精度の確認

シミュレータの存在
 深層強化学習によるドローン制御(デモビデオ)
 youtube - CEATEC

さくらの高火力コンピューティング+Mesos(コンテナでR&D)

解決したい課題を常に確認する

アルゴリズムブラックボックス
 なぜ数学系、物理系研究者によりなぜ深層学習がうまくいくのか研究されている

学習済みモデルの賞味期限
 実験データと本番データ

CI/CDは研究開発時も大切
障害時点のスナップショット取得


未来:
 積極的なIoT

現状:
 消極的なIoT
  データをクラウドに置けない
  NWが細い、つながってない

フェーズ
 学習
 推論

ニューラルネットワーク

IoTに対するフルスタックなアプローチ
 組み込み
 NW
 コンテナ、VM
 クラウド

SORACOMの利用事例


NVDIA edge
人の検出
年齢、性別

製品名
DIMo(deep intelligent in motion)

”新たなフルスタックエンジニア”
ビッグデータ、シリアル通信、、、…


NVIDIA
 DIMo組み込み前提製品もあります

エッジコンピューティング、NWがボトルネック
 5Gなどになるとアーキテクチャは変わる?
 繋がってないもの、職人技でロボット同期させていた。変わる。
 いままでやってきたことが増える

---

■ B2:デバイスデザインパターンユースケース別デバイス選定〜

松下享平さん
テクノロジーエバンジェリスト
UG

ユースケース

作元研一さん
田中大輔さん

GoF
UI design pattern
CDP


適切パターン
未デザインの課題


IoTデザインパターン

どうつなぐか?
 デバイス  クラウド


集約パターン
 ダイレクト集約
 ゲートウェイ集約 ※デバイスとの中継をはさむ
  近距離 BLE,EnOcean, ZigBee,,
  中距離 3G/LTE, LPWA
 LPWA集約
  LPWAゲートウェイ

保守パターン
 シェアドネット保守
  ゲートウェイを介してデータ返す
 バックネット保守
  セルラー回線を保守専用線を使う

バイスの選定法
 IoTで得られる利益
 IoTプロジェクトの課題


インフォキューブ LAFLA
ザイマックスアルファ


ジオストラトス(GeoStratos)
モノの流れの分析

滞在エリア、滞在時間の可視化
集めたデータをPowerBI、ElasticSearchなどもOK

GISのMap
3D CADで立体解析もやってる

タスク管理進捗システム
 どの場所で、だれがやってる

保土ヶ谷区フェスティバル
 迷子検索システム2016
 お子様はネックホルダーにBeacon
 提灯照明に内包(ぷらっとふぉーむ社 IoT Gateway, OpenBlocks IoT BX1を使用)

アーキテクチャ
 BLEモジュール (BLE) IoT Gateway クラウド

モジュール
 10m~20m 間隔で設置
 お祭りの1時間前に設置

OpenBlocks IoT BX1
 SIMフリー
  SORACOM Air
  2万ミリAのバッテリー
 Debianフルパッケージ動く
 遠隔監視OK

PoCで大事なこと

見込みと現実
 工数差がうまれる
 「事前準備」、「設置工事(部品が必要とか)」が膨らんだ
 ※現場の協力、通信インフラ確認はSORACOMあってよかった

PoC、本運用のデータ解析、論文も書く

横浜市
 ウォーキングイベント


作元さん
 Xymax

リクルートビル事業
仲介物件

アセットタイプ
 オフィスビル
 商業施設
 ホテル

不動産
 843室
 ファシリテイ 14,000円

IoT
 期待感
 人手不足

http://iot.uhuru.co.jp/partner/

2016/10/05 ミューザ川崎
 電流測定(沖電気
 振動測定

レンジャーシステム(BLE加速度センサー)

機器異常の早期発見
 ミューザ川崎の機械室(各種)

周波数特性(振幅)にみだれが生じている

目指すべき方向性(再定義)
 作業量減らす、効率化
目的と意義
 省人化、無人化、多能工
何する?


ゲートウェイ集約パターン
 デバイス、送信機、受信機、データ収集装置で、IP通信(※近距離通信の複数組み合わせ)
 RS-485、920MHz、RS-485

 デバイスゲートウェイでIP通信(定期メンテナンスが必須)


ダイレクト集約パターン

LPWA
 LoRaWAN / SORACOM Air for LoRaWAN
 SIGFOX

なぜ厳しいか?
 マーケットに受け入れられやすい可能性
 最終的にモデム搭載デバイスの開発となってしまう
 3Gモジュール入手
 PoCで得られた知見が本運用に活かせない

通信モジュール(※SORACOM提供)
 Mini PCIe 3G/LTE通信モジュール
 UC20-G/EC21-J
 3,980円

本番展開するにあたって…
 充足してるもの?
  SORACOMの通信環境(3G, 4G, LTE, ...)
  新しいのでどれ選んだいいかわからない

 不足してるもの?
  PoC、どこまでやる気があるかの予算

まとめ
 ・「ゲートウェイ集約型」が主流
 ・費用面、運用面

---

■ A3:業務システムとの連携〜閉域網とクラウド

Hands Labs
小松製作所 根本さん

エンタプライズとIoT
既存業務との連携

IoTのCapabilityの追加
 既存システムと同レベルのセキュリティレベル、コンプライアンス準拠が求められる

閉域網
 DoCoMo(SIMの耐タンパ性)、専用線、SORACOM(AirでSORACOMと安全な通信路)、暗号化&証明書、閉域網

SORACOM Canal
SORACOM Direct
 外部DCと接続
SORACOM Door
 VPNで閉域網を構築 ※小松社が利用
SORACOM Gate
 閉域網への外部アクセス ※Overray networkを構築


ハンズラボ平井さん
 「アプリエンジニアでもできる閉域網構築のススメ」

外販案件(IoT)
バックエンド

東急ハンズ
 システム子会社
  情シス
  外販

ショッピングセンター向けポイントカード基盤システム
 関東5店舗、他1店舗
 300テナントでポイント付与
 AWSで構築

4層
 ユーザー
  管理者 会員
 Web
  -
 アプリ
  ELB(管理画面、マイページAPI
  処理エラーSNS、メールSES
 データ
  DynamoDB(セッション)
  S3(アプリデータ)

技術課題
 インフラ構築、開発、本番導入まで1ヶ月のみ
 屋外WiFiが届かない場合がある
 キャリア通信は通信制限はできない
 セキュリティ上、ポイント付与処理は全世界公開はしたくない


SORACOM

 ユーザー
  キャンペーン担当
 Web
  SORACOM Canal
 アプリ
  ELB(キャンペーンAPI
 データ
  DynamoDB(セッション)
  S3(アプリデータ)

SORACOMでハマったこと
 内部向けロードバランサが必要

DoCoMo、SORACOM VPG、SORACOM Canal、キャンペーン用ELB、ポイント基盤サーバ
当初Canalを通ってくれない…?
 →外部ロードバランサを使っていたから

AWS
 外部ロードバランサ
 内部ロードバランサ

Canal利用メリット
 Canal/AWS設定は2営業日くらい
 従量課金のため、ランニング費用安い(月額1,000円くらいで済んだ)
 端末側の設定は不要

AWS Simple Monthly Calculator」のSORACOM版が欲しい。

SORACOM学習方法
http://dev.soraco.io/jp/start/canal/acom.io/jp/docs/api/

Sandboxもあります
http://dev.soraco.io/jp/docs/api_sandbox/


□スマートコンストラクションのSORACOMサービス
コマツスマートコンストラクション推進本部
根本さん

価値創造と成長戦略
 ダントツ商品(機械本体の商品力向上)
 ダントツサービス(機械の見える化)「KOMTRAX」
 ダントツソリューション(施行の見える化)「SMART CONSTRUCTION」

無人ダンプシステム
 マイニング、建設現場

建機を効率化しても、前後工程のボトルネックを改善できない
受注工程から手伝えるように。
 →2015年2月からスマートコンストラクション

価値:コトをつなげる
 KomConnect(Azure上にある)、ここでSORACOMを利用

SORACOM Gate/Door
 建機への命令送信
 データ転送
 施工地形データ送受


SORACOM導入前
 VPNサーバ ※1サーバあたりの同時接続数があった、建機は増えるので運用工数膨らむ。
 リアルタイム出来高データ(Azure)
 現場に建機を残す問題、SIM盗難

SORACOM導入後
 建機 IMEIロック SORACOM SIM
 SORACOM Door相互接続
 VPNルータ用Linux VM (接続データ転送) KomConnect、ステレオカメラAPI Windows仮想VM

今後、1,500台の建機への導入を予定
IMEIロックはSORACOM APIで運用工数減できた。

期待すること
・利用状況レポート
・監視機能
・権限設定のGUI


まとめ
 ネットワークエリアでのセキュリティ対策でも、既存のシステムを大きく手を加えずにレイヤ対応できる
 エンタープライズクラウド化の流れ
 SORACO使うとモバイルネットワーク簡単。

---

■ A4: カメラデバイスクラウド スムーズな連携のために

プラネックスコミュニケーションズ 企画開発部部長 中林さん
ABEJAプラットフォーム事業部 河崎さん


□松下さん

カメラ
インターネット
クラウド

これを喩えると。


神経

cf: 「眼の誕生」2006年 草思社

スマカメなら撮り貯めても1ヶ月100MB程度

・観点
          クラウドへいつ送るか?
いつ使うか?    オンデマンド(アーカイブ)    ストリーム(常時)
 リアルタイム   ドライブレコーダー        【新たな価値】
 オンデマンド   防犯カメラ            見守りライブ配信


どこで解析?
 出力I/Fがないデバイス、カメラ、(画像のまま?ゲートウェイでテキスト化する?)、クラウド

制御どうする?
 データ用の回線
 メンテナンス用の別回線


□中林さん
 スマカメ
 1995年設立
 ネットワーク機器、開発、製造、販売
 6機種
 防水、暗闇、…
 6,000円〜20,000円、コンシューマ対象。
 10万台出荷、3年。
 台湾の製造企業に製造委託している。
 IoTは禁句。

 スマホ、インターネット、カメラ
 遠隔地から見れる、シンプルさ

 課題
  クラウドサービスの通信費用をもらわない判断
  NAT越え、スマホからPrivateIPを越えないといけない

 施策
  P2Pトンネルでスマホとカメラを結んだ
  ※5分に1度、カメラのIPを通知している。スマホはそのIPをもらってUDPでパンチングして経路確立する
  クラウドAWSを利用

 "スマカメAir" By SORACOM Air
  今年夏リリース予定。
  180° View
  3G/LTEのしたモデルの要望が大きい
  防水、暗視
  SDメモリー
  WiFi

 テクニカルチャレンジ
 (死の谷)※イチローの打率より低い
 ビジネスチャレンジ ※90%くらいの比重


 ビジネスチャレンジ
  CPU発注だと20週かかる
  需要予測誤ると機会損失
  返品?代金改修?

 スマカメ
  サービス追加
 スマホ、スマカメ(FWカスタマイズ)、クラウド(ABEJAサーバとP2Pトンネルをつくって画像を転送)
 ※アドホックに視たいなら見れる


□ 河崎さん
Camera device * Cloud

2012年設立
ディープラーニング活用の事業開発

ABEJA Platform PaaS

上りのIoT
 Unstructured data
 Structured data
 学習モデル


ABEJA Platform Open
エコシステム
パートナー企業への開放


2年前からスマカメ提携
for Retail 小売店向けサービス
 来店、回遊情報の取得
 →性年齢推測、回遊ヒートマップを取得できる

Camera☓Cloud☓Retail

Cloud vs Edge
 反応速度
 解析の陳腐化の速度
 コスト高低
 エラーコントロールの難易度

クラウド判断基準
1:スケール可能な導入体制
2:継続的なサービス提供
3:新しい種類のデータ取得

 

1:スケール可能な導入体制
 スマカメ店舗設置、ネットワークへ接続、計算マシン上で解析
 エッジでの計算との比較
 計算マシンを店舗に置ける場所が少ない、バックヤードのみ、電源確保、LANケーブルとか。
 全国小売店でデータ取得したい
 →店舗はシンプルにカメラ置くだけにした。
2:継続的なサービス提供
 設置したら長期間で保守。
 故障要因減らす、保守簡単にする。
3:新しい種類のデータ取得
 新しいプログラムの提供
 エッジマシンの入れ替えは手間


まとめ
 デバイスサイド
  ネットワーク到達性の確保(NAT越え)
  書き換え前提とした汎用的ファームウェア
 クラウドサイド
  クラウドへのオフロードによるデバイス実装、現場設置の負担軽減
 ビジネスチャレンジへの相互理解が重要

*** 

参加録 Dockerを利用した開発事例~Docker導入から運用まで~

ただいま絶賛有給取得期間中、ヒカラボ@渋谷でした。

イベントURL:

日時:

2017/04/13 (木) 19:30 ~ 22:00

アジェンダ

19:35 ~ 19:40    EmotionTech 田邊氏:イベント説明
19:40 ~ 20:00    Amazon Web Services Japan K.K. 岩永氏:AWSでDockerを扱うためのベストプラクティス
20:00 ~ 20:20    EmotionTech 子安氏:Dockerで構成するWebサービス~EmotionTechの場合~
20:20 ~ 20:40    VASILY 光野氏:(仮)Docker/Apache Mesos/Marathonで構築した新インフラについて
20:40 ~ 21:00    UZABASE 羽山氏:新規プロダクトでDockerを導入した話(→テーマ更新)
 

Amazon Web Services Japan K.K. 岩永氏:AWSでDockerを扱うためのベストプラクティス

 
ID: @riywo
 
AWS技術支援
Web、ゲーム企業へ
 
開発
運用
ECSの事例
 
コンテナ
リソースの隔離が目的(CPU,Disk,Filesystem
DevOpsの文脈で再発見(デリバリー速度向上
 
便利
 本番で使うとハマリポイントがある
 
VMとサーバと違う勘所
 インフラよりアプリの作りが異なる
 
Transformationが必要
 どこに向かうべきか
 12 factor apps
 
12 factor apps
 Herokuが提唱した原則
 開発者、運用者が対象
 
■開発
Docker使いやすさ
 
・設定とビルドは分離
 イメージには設定は入れない
 環境変数として用意すること
・ステートレスなものはDBはコンテナを使わない
・ログはファイルでなくストリームとして外部に置くようにする
 
■運用
DevOps
 Source
 Build
 Test
 Production
 
デリバリー速度向上
 
Docker以前の課題
 開発環境の構成のメンテナンスが大変
 テスト需要はバラバラ
 開発、テスト、本番に差異がある
 オートスケール、障害対応が大変
 
Docker以後
 Source
  Provision
  Config
  Application
 
 そのまま本番まで一気通貫
 
Docker単体の課題
 どこで、どうやってDocker動かす?
 フロントからのルーティングは?
 コンテナのフェイルオーバーは?
 
クラスタ管理が必要になる。
 
クラスタのMaster群
 状態をDBのに置く
 静的情報
 LBのWorkerの付け外し
→これらはAWS ECSが面倒見てくれる
 
ECS
 Scheduler
 Manager
 Task Definition
 Agent(Cluster)
 
サービス
 動的ポートマッピング
 アプリのバージョン1を4個下さいでOK
 BlueGreenデプロイメントが容易
 
AWS Batchでもジョブスケジューリング
 ECSがジョブを持ってくれる
 
3 clear trends ECS adoption by Datadog
 1年で3%→15%へユーザー数向上
 コンテナ数増えると問題増える(25台超えるとECS40%利用)
 
ECS利用企業例
 Slack
 Expedia
 
Mapbox
 マイクロサービス
 EC2タイプ別で稼働可能
 Spot fleetを利用
 インスタンスを一時的な指値で稼働
 
結果
 21サービス
 2000コンテナ
 25%台数減った
 コスト80%ほどのコストで運用可能
 

EmotionTech 子安氏:Dockerで構成するWebサービス~EmotionTechの場合~

 
ID: @akirakoyasu
旧社名 wizpla
 
Elastic BeansStore
Base Image Docker
 
EmotionTechでのDocker
 
アンケート回答してもらう、回答分析する
URLによりスパイクがある
 
Docker
Elastic Beanstalk
Phusion/base image docker
 
仕組み
 clone
 syslog
 
構成
 S3
 Internet
  EBS
      docker
          Angular
      docker
         Rails(API)
 ダッシュボード
  EBS
      docker
           Angular
      docker
           Rails(API)
 ワーカー
  SQS
      docker
          Rails(API)
 DB
  RDS(※本番)
  Elastic Cache
  docker mysql(※ローカル)
  docker redis(※ローカル)
 
開発フロー
     ステージングのTravisが通ればJenkinsで本番デプロイ
 
■ 導入から運用まで
 
最初の状況
 秘伝のタレ事件(V1の時代)
 環境差異との戦い
 Jenkinsががんばる
 人少ない(インフラ専任は1名)
 既存サービスをフルリプレース
 
導入前に考えたこと
 ステートレスなコンテナができるか?(イメージにタグをつける)
 開発ワークフローが組めるか
 手がかからないインフラがいい(BeansTalk)
 Dockerの先人に学ぶ(RubyでFusionを使う)
 
構築するときに気をつけたこと
 ポリシーをもって構築する
 各環境で使えるDockerバージョン
 Docker fileの手本に倣う(github/docker-library)https://github.com/docker-library
 ローカル環境を本番に近づける
 
使ってみたら起きたこと
 rails c で30秒無反応
 CIで使いたいコマンドが使えない(CirlcieCI→TravisCIへ変更)
 db:migrateする仕組みがない(deploy前処理、後処理。独自YAMLファイル。)
 環境変数をコンテナ挙動を変えたい(初期化に応じて)
 
本稼働
 ビルド(15分くらいかかる)
 監視はふつう
 インスタンスを敢えて変える(ステートレスとの接続徹底)
 
Tips
 ローカルはDocker-Composeで
 環境初期化はラッパースクリプトを使う
 ローカルはDocker for XXXが主流
 デプロイはGithub tagとDocker imageのtagを揃える
 ステージングイメージを本番にデプロイする
 

VASILY 光野氏:(仮)Docker/Apache Mesos/Marathonで構築した新インフラについて

ID: @kotatsu
 
Docker化した
デプロイについて
詳しくは技術ブログにて。
 

UZABASE 羽山氏:新規プロダクトでDockerを導入した話

テーマ変更:Dockerへの取り組み
※公開資料見当たらず。
 
インフラ担当
前職はゲーム会社
 
Docker運用
FORCASのDockerへの取り組み
 
2008年設立
2016年上場
社員200名ほど
 
サービス
 SPEEDA
 NEWSPICKS
 entrepedia
 FORCAS(アカウントベースドマーケティング
 
新サービス、30人の開発体制
Dockerホストが複数台立ち上がり
 
実現したかったこと
 簡単スケール
 一括管理
 スケール環境下でもデータ永続化
 スケール環境下でも自動リソース管理
 プロジェクトごとのコンテナ管理
 
Rancher
 Dockerクラスタ管理ツール
 RancherOS
 充実したWebインターフェース(KubernetesでもMesosでも管理可能)
 ホストを足すだけでスケール自動
 コンテナ分散も可能
 Docker Link機能でホスト間の通信も簡単
 
DockerレジストリにイメージPushしたら使用可能
 
PJTごとのコンテナ管理(Stackを利用)
 PJT作成(Stack作成)、docker-composeをアップロード、Stackが追加されDockerコンテナ起動
 
データ永続化
 Catalog(docker-composeのテンプレ集)
 Rancher-NFSで永続化
 
コンテナ自動監視
 Prometheusで自動監視
 Catalogから起動すると簡単に監視可能
 
新サービス「FORCAS」への取り組み
 AWS
 マイクロサービス(APIはDocker)
 バッチ(Docker)
 CI環境(CirlceCI)
 
目標
 マイクロサービス担当者がそれぞれCIを作れる状態
 メンテナンスフリーな環境
 
4つのサービスがある
バッチ処理の取り組み
 
DockerレジストリにイメージPushするだけでリリースされる仕組み
SPEEDAからアクションをトリガーにバッチ稼働
 
 データ配信→S3→Lambda→バッチサーバ→Dockerイメージ起動→自身をシャットダウン
 
CI取り組み
 CircleCIでイメージ作成自動化
 ChatOps
 
仕組みはバッチ同様
 
DockerイメージPush→サーバ再起動→Dockerイメージ取得、起動
Slackから処理をキックさせる
ELBからサーバプールの切り替え
 
複数開発PJTを管理するPlatformではRancherが便利
StackのPJT管理
Catalogからの環境構築ができるの便利
 
EC2インスタンス起動するとデプロイ済のイメージが起動するようにしている。
 
 
講演内容は以上。
各社とも敏腕インフラエンジニアがOSSを使うかマネジメントツールにするかを試行錯誤して、
サービスに向き合っていました。
 
Docker周辺ツール、特にクラスタ管理まわりの情報をキャッチアップできていなかったので、
貴重な知見を頂きました。
 

IoT時代の何でも屋さんの野望

2012年にブクマしていた記事に「動くゴミ箱」を作ったというガジェットネタがあります。

当時学生だった倉田さんが、独力で行ったのは以下の工程。いわば多能工。。

  • イメージ構想
  • CADでハードウェア設計
  • 部品加工(学校設備を利用)
  • 基盤回路設計
  • 基盤パーツ実装(パーツ選定、はんだ付け含む)
  • ハードウェア構築
  • エミュレータでの動作テスト(プレイステーションコントローラを使用)
  • マイクロソフトKinectと無線シリアル通信するプログラム実装

gigazine.net

 

当時2012年ということで、2017年のいまであれば部品加工の工程で3Dプリンティングが使えそう。

SORACOMがグローバルにデバイスとWebをつなぐ仕組みを提供してくれるようになったこともあり、地球の裏側のデバイスにも連携が可能。 

 

作った商品の販売と配送は、Amazon Launchpadが受け持ってくれます、至れり尽くせり。

ascii.jp

 

SORCOM玉川さんいわく、分野を越境するスキルフルなエンジニアが増えていくだろうという未来。それを求められるのがIoT時代とのこと。 

IoTプロダクトの開発に必要な専門知識は広範囲に及びます。僕はAWSに入る以前、日本IBMでウエアラブルの研究開発に携わっていたので、メカ、エレキ、組込みソフトとひと通り触ることができました。当時の経験から、この“スキル横断型エンジニア”の貴重さも身に染みて分かっているつもりです。

さらに、僕らが構想しているようなIoTのプラットフォームを作ったり、それを使った革新的なサービスを提供するには、よく言う「ソフトとハード」の話以外にも、バッテリ問題に詳しい人、セキュリティに精通した人、BLEなども含めた端末とネットの接続部分に関する知識などさまざまなスキルが必要になります。

ですから、今後はこれまで混じり合ってこなかった、数種類のエンジニアが持つスキルが求められるでしょう。ざっくり言うと、ITのエンジニアとモノづくりエンジニアの持つスキルの両方が必要になる。Web、インターネットのみならず、デバイスや組込みソフトを使いこなす能力もですね。

これまで、こういったジャンルのエンジニアが混じり合うことはほとんどありませんでした。しかし、IoTのプラットフォームを作ろうとしたら、両方のエンジニアが必ず必要になりますし、我々の手掛けているIoTプラットフォームができれば、両方のエンジニアはさらに境がなくなっていくと思います。

type.jp

 

Webエンジニアだけど、人手足りないからWebデザインとUXも、あ、経営上層部納得させたいからデータ分析も、もちろんセキュリティ含めたインフラも見れるよね?

そこに、コード書けるなら組み込みもいけるよね?アプリもデバイスもお願い…と、なると\(^o^)/オワタ

 

なるほどアルティメットエンジニア。

エンジニア道は果てしなく拡がっていきますね(小並感)。

 

※そういえば、2002年が自動掃除機ルンバ第一世代の販売年。

家庭にロボットが入るなんて近未来だと思った日が随分遠くなりにけり。 

youtu.be

 

第1回 Hyperledger Tokyo Meetup へ行ってきたので、そこに至るまでの経緯を含めて書く

昨今賑わいをみせるビットコイン

投機的な雰囲気もあり、その話題はスルーしていたのですが、昨年末に「ブロックチェーン・レボリューション」を読んだことをきっかけにブロックチェーンに関心を持ったのです。

www.amazon.co.jp

 

知識ゼロの状態からいろいろ調べているうちに、以下のようなことがわかって来ました。

  • 世間を賑わすビットコイン(仮想通貨)とブロックチェーンは別物
  • ブロックチェーンにはパブリックなものとプライベートなものがある
  • パブリックなブロックチェーンがビットコインに使われているが、一度の決済に10分ほど待ち時間が発生するため、速度面でプライベートなそれが使用される流れがある(※ただし中央集権的と反発される)
  • プライベートブロックチェーンの方式も、団体(営利、非営利など)によって異なる、開発言語も異なればAPIも異なる
  • ブロックチェーンの究極の目的は、「紙と信用」に基づく取り引きをすべてデジタルなそれに置き換えること

 

紙や硬貨に信用を与えてきたのが金融だったわけで。

なるほど、信用をデジタル化することは歴史的にもインパクトのある話しなのですね。

 

さらにブロックチェーンを深掘りするために、偶然みかけたのが下記書籍。

ブロックチェーン 仕組みと理論 サンプルで学ぶFinTechのコア技術 | 赤羽喜治 編著, 愛敬真生 編著 |本 | 通販 | Amazon

 

NTTデータの技術者陣がブロックチェーンについてまとめたものです。

ビットコイン、Etherium、Hyperledger Fabricについて簡単にサンプルを試すこともできて、ブロックチェーン技術を知る上で必携な一冊と思います。 

 

以上つらつらとありまして、BlockChainイベントへ参加に至る。

 

さて有給休暇を使って参加しましたMeetup。

武蔵中原ってはじめて降りました、富士通社のお膝元的な駅ですね。

 

会場に到着するも、参加者は見渡すかぎりのスーツ。。

普段から取り引きのあるSIerの方々でしょうか、顔見知りが多いような雰囲気でした。

 

イベント概要「第1回 Hyperledger Tokyo Meetup」

日時:3月16日 · 13:00〜
場所:富士通研究所 岡田記念ホール

www.meetup.com

 

講演内容

アジェンダ
13:20-13:40
Hyperledger Projectの概要
日立製作所 長稔也様 (Hyperledgerプロジェクト ボードメンバー)

13:40-14:20
Hyperledger Fabric 1.0 概要
日立製作所 山田仁志夫様

14:20-15:00
Introduction to Fabric Composer
日本アイ・ビー・エム 紫関昭光様

15:10-15:50
Hyperledgerいろはについて
ソラミツ 武宮誠様

15:50-16:30
データベース屋がHyperledger Fabricを検証してみた
NEC 並木悠太様

16:40-17:20
ブロックチェーンの可能性と課題 - SIerとしての視点から
NTTデータ 稲葉高洋様 山下真一様

17:20-18:00
ブロックチェーン実証実験から得られた知見
富士通 / 富士通北陸システムズ 滝口成人様

 

途中小休憩があったものの、ほぼ通しで4時間強でした。

これを要約すると下記のような感じです。

  • Hyperledgerコミュニティ。最近中国企業の参画が増えている、日本企業も入りましょう
  • Hyperledger Fabric 現在0.6系、1.0がまもなくリリース。
  • Fabric Composerを使うとAPI管理が簡単、Bluemix(IBMクラウド)のイメージで敷居が下がっている
  • ブロックチェーンとデータベースは似て非なるものだけど、データベースの見地でみると分かりやすい
  • みずほ銀行とブロックチェーン取り引き実証実験やってみた(ビットコイン版とHyperledger版

 

資料はイベント後日公開されたものの、Meetupページに埋もれていたので、転載します。

どの講演も学び多く甲乙つけ難いのですが、エンジニア的に推しの資料は設計概念を説明されていた「Hyperledger Fabric 1.0 概要」「ブロックチェーンの可能性と課題 - SIerとしての視点から」です。

 

Slideshare資料まとめ

www.slideshare.net

 

音声データも置いておきます(容量注意、223MB)

何かの経緯で本記事にたどり着いたら、ご査収ください。

 

 

■その他参照

Hyperledgerのミートアップで考えた、ブロックチェーン普及の必要条件 - ZDNet Japan

オープンソースのブロックチェーン Hyperledger Fabric を試してみる - Qiita

 

JAWS2017 in 五反田TOCメッセ

昨年以前は新宿ベルサールだったのですが、今年の開催地は五反田TOCメッセ。

綺麗な施設で、ボランティア皆さまのおかげで快適に過ごすことできました。

 

f:id:michael-unltd:20170311234716j:image

 

jawsdays2017.jaws-ug.jp

 

参加したワークショップとセッションは以下のものです。

  1. 【ハンズオン】AWS Elastic Beanstalk
  2. [ランチタイムセッション]
    ハンズラボ株式会社
    株式会社鈴木商店
    有限会社来栖川電算
  3. コミュニティで拓く、パラレルキャリアへの道
  4. 【ハンズオン】Amazon Alexa Skill
  5. おとなのたしなみ、おコンテナ by JAWS-UGコンテナ支部
  6. 【ハンズオン】RESTful API

 

jaws-days.doorkeeper.jp

 

www.slideshare.net

  

f:id:michael-unltd:20170311234756j:image

f:id:michael-unltd:20170311234745j:image

 

stilldayone.hatenablog.jp

 

jaws-days.doorkeeper.jp

 

speakerdeck.com

 

jaws-days.doorkeeper.jp

 

あと、参加したかったけど寝坊して聴けなかったセッション…。

早速スライド上がっていて嬉しいです。

 

www.slideshare.net

 

所感、最高に充実した一日でした。

毎年参加しているJAWSですが、今年は早めに申し込みできたためワークショップ比重高め。

 

Amazon Alexaについては音声関連サービスでアクション起こすとなっても心理的障壁下がりましたし、Beastalkでコンテナ、RESTfulAPIでLambda/API Gatewayもキャッチアップできました。

 

AWSエコシステムの集大成的なイベントで来年もまた楽しみです。 

 

 

追記(2017/03/19)

資料公開一覧ができたようなので転載します。

qiita.com