囲碁とITの関係
囲碁って卓上に広がる宇宙なんだと誰かが言っていたような。
週刊少年ジャンプ脳な自分には、小宇宙でコスモと呼びたくなる衝動があります。
さておき、情報技術（以下IT）の技術動向について考えたよしなしごとについて。
普段囲碁に嗜む習慣のない自分ですが、なにかのきっかけ（おそらく『ヒカルの碁』の読み直し）で日本棋院ホームページを覗くと、以下のページが目に飛び込んできました。
「第一線・第二線」は海中・地下
「第三線・第四線」は大地
「第五線」以上は空・宇宙
対局のテクニック：序盤 一手目を打つ | 囲碁学習・普及活動 | 囲碁の日本棋院
囲碁があたかも戦争、兵術の話しでした。
ここで常套とされるのは、碁盤の端から中央に向けて攻めるというもの。
3図：中央をめざして打つ
陣地の骨格をつくる布石段階では第三線・第四線が最適でしたが、中盤に入ってさらに陣地を広げるには中央をめざして第五線以上に勢力圏を拡大する打ち方が重要です。
碁盤を地球とすれば、第五線以上は空から宇宙に相当するということを前に学びました。
中盤では、空・宇宙（中央）をめざして、まさに立体感覚で打つことが重要です。
対局のテクニック：中盤 基本戦略 | 囲碁学習・普及活動 | 囲碁の日本棋院
そこで、インスピレーションを受けて思うは、ITの「海、陸、空」。
クラウドサービスの登場以降、ネットワークとアプリケーションの垣根は溶けつつありますが、話しを簡単にするため、対象は「ITプラットフォーマー」。
縦に企業名を並べて、
それらの提供しているサービスで横に並べると、
「クラウド」「OS」「モバイル」「ハード」「ソフトウェア」「コンテンツ」etc... 。
それぞれ、得意領域に軸足を置いて、領土拡大を企てている感が出てきます。
最近では、
- FacebookがOculus買収でデバイスに乗り出す、VRコンテンツのプラットフォームを狙う
- IBMは人工知能コンテンツを呼び水としてクラウドに注力
- Microsoftも自社OSでの囲い込みを避け、他社OS、他社モバイルプラットフォームへの開発環境を提供する、稼ぎ頭のOfficeソフト群もクラウドに組み込む
- さらにMicrosoftはゲームデバイス開発で培った知見をもとに、MRデバイスを通じたB2B領域にも攻め入る
- Google、Appleはモバイルプラットフォームを握り、Amazonはクラウドリーダーに躍り出るや否や、それでも矢継ぎ早に新サービス、音声認識デバイスをリリース
といった施策を打ち出してきて、過去従来の企業イメージに縛られない時代になってきました。
業界といった観点ではプレイヤーが散在しすぎてなにが何やらになってしまいますが、ITプラットフォーマーで眺めると、陣取り合戦だなぁと思い至りました。
WeChatアプリでは声紋認識ログインできる件
プロフィール何書いたかなと思って、ふと起動したWeChatアプリ。
「設定」から、
「マイアカウント」を開くと、見慣れぬ「声紋」…？
声紋認証をONにすると、画面遷移されて。
表示された数字を画面下部の6点ボタンを押しながら読み上げる。
声紋作成されました。
再度「声紋」画面を開くと、声紋認証が有効化されたのが確認できます。
登録し直しも可能とのこと。
一旦、アプリからログアウトして。
ログイン時に、登録数字を読み上げると問題なくログインできました。
おもしろかったのでメモ。
モバイル開発の三種の神器「PlantUML」「API Blueprint」「Charles」
過去のモバイル開発の振り返りも兼ねて。
過去開発システムの背景
メンバー構成
そこでは、APIaryを使用していて、あのツール使ってよかったよねと。
APIaryの使用法は、APIを考えてBluePrint（Markdownライクな書式）で記述、githubにドキュメントをアップ。APIaryはそれをもとにモックサーバを作ってくれるというもの。
APIがコード管理されていたから変更履歴も追える、ドキュメント化されているので言った言わない論争が避けられるのは、納期が短いほどメリット大きいと思いました。
次回おなじような開発があったときの改善点などを考えていたときに出会ったのが下記資料。
資料によると、リリース後にCacooで作成したUMLをGithub Wikiに貼っていたものの、ドキュメントのコード管理できることを考えると、「PlantUML」がオススメとのこと。
また実装工程で、サーバAPI見直しの間、アプリチームの待ち時間を発生させないために、Proxyサーバツールの「Charles」で検証を進めてもらうという手段もあるのを知りました。
この資料には開発ツールに限らず、メンバーのマインド管理、メンタルケアを含むチームの幸せを実現する知恵が書かれているので、何度も読み返したいものです。
参照：
- API Blueprint
- PlantUML
Java製のためJDK要インストール
http://plantuml.com/download
ViewはAtomエディタ、JetbrainsIDE、Chrome Extensionで使用可能
PlantUML Viewer - Chrome ウェブストア - Charles
通信系のデバッグには Charles が便利 - Qiita
1ページで理解するP2P（Torrent編）
P2Pと聴くと不慣れなために抵抗感があったので、理解補助のためにTorrentの仕組みを調べてました。
すると、この資料を発見。
ここまでP2Pの仕組みをわかりやすく書いてくれたkyorohiro++
ということで、理解したことを1ページにまとめるエントリ。
ざっとまとめてみると…
- Torrent file
- UPnP
- Tracker
- DHT（分散ハッシュテーブル）
サーバ・クライアント方式でない方式。特徴は以下3点。
・Peerは受け取ったInfoHashをもとに、その対応データを持ちそうなPeerを紹介する
・Peerどうしはお互いの距離を知っている
・Peerは自身に近いPeerの情報を多く持っている- TorrentのDHT機能
・DHTの名前は「Kademila」
・XORでPeer間の距離を計算
・UDPでPeerどうしが通信を行う - RoutingTable
・kBucketのRootingTableでPeerの一覧を管理（※kBucket：K個のPeer情報を格納する入れ物、Peerの識別子はKID）
・RootingTableは、0〜160までの161個のkBucketを保持する事ができる
・RootingTableを所持しているPeerとのXORを計算し、その値をもとにどのkBucketに追加するかを決める - FindNode
・FindNodeクエリとFindNodeレスポンスでDHTネットワークを構築する
・FindNodeクエリを利用すると、指定したKIDにもっとも距離が近いNodeを教えてもらえる
・リスポンスを受けたらRootingTableを更新する - GetPeer/AnnouncePeer
・GetPeersメッセージを利用して、データを所持しているPeerまたは最も近いPeerを探すことができる
・GetPeerを繰り返して、上位K個のNodeが固定されたら、AnnounePeerメッセージを利用してデータを記録する
- TorrentのDHT機能
さらに簡略して、Torrentの仕組みを3行で書くなら…
- Torrent fileをもとにPeer間でデータ送受信
- リモートデバイスと通信するにはNAT越えが必要で、UPnPでリモートデバイスのGlobalIPを取得
- クライアント・サーバ方式であればTrackerを、Trackerを介さない方式であればDHT（分散ハッシュテーブル）でP2Pを実現
UPnPでGlobalIPを取得する、Peer間のデータ受け渡しは分散ハッシュテーブルで実現されるという箇所が、技術の要のようでした。
■補足
UPnP（Universal Plug and Play）：UPnPは、機器を通信ネットワークに接続すると、複雑な設定作業を行わなくても他機器と通信したり、その機能を利用できるようにするプロトコル。
Botkit と Bluemix Watson Translate APIで自動翻訳Botを作成したけど社内で採用されなかった件
tl;dr
- グローバル事業を進めているなかで、英語圏メンバーが日本語チャットの内容を気にしている
- 社内ではSlackを使用しているので、日本語メッセージが投稿されたら、それを自動翻訳してくれるBotがあればいいんじゃないかと思い実装
※ 日本メンバーに /translate @bot en "ほげほげ" とか逐一入力させたくない - いざ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主催のイベント開催。
昼暑くて、夜冷える時期ですね。
イベントタイムテーブル
参加セッションは以下のものです。
- キーノート「IoTテクノロジー 今・未来」
- B1：エッジヘビーコンピューティングと機械学習（ランチセッション）
- B2：デバイスデザインパターン〜ユースケース別デバイス選定〜
- A3：業務システムとの連携〜閉域網とクラウド〜
- A4：カメラデバイスとクラウド〜スムーズな連携のために〜
朝の社用を済ませてからの参加。
キーノートの途中入場、SORACOM CTOの安川さんのお話からメモしていました。
IoTインフラのサービス設計のお話。
ユーザー数が増え、海外展開して、新サービスを追加リリースしても、既存サービス群にはほぼ手を入れずにスケールする設計思想の裏側を知ることができたのは財産でした。
次いで玉川さんモデレータのパネルセッション、IoTの現状と展望を見渡すお話し。
キーノート後。
なにせ天気の良いものだから外でお弁当食べました、地球食堂の角煮弁当。
※この後のランチセッションという単語を見落としていてランチ２発。
B1：エッジヘビーコンピューティングと機械学習
PFN社の機械学習、深層学習事例について。
B2：デバイスデザインパターン〜ユースケース別デバイス選定〜
ネットワークのデザインパターン。実例紹介があり、インフォキューブ社の「地域密着位置情報サービス」、ザイマックス社の「商業施設の設備機器異常検知システム」が挙げられていました。
A3：業務システムとの連携〜閉域網とクラウド〜
実例は、HandsLab「ショッピングセンター向けポイントカード基盤システム」、小松製作所の「スマートコンストラクション」。
HandsLabでは２ヶ月で商用サービスリリースしたのと、小松製作所の事例は本気のIoTでした。そしてスマートコントラクションはAWSでなくてAzureクラウドに乗っていたのですね。
SORACOMサービスうち「Door」「Gate」を活用し、既存システムの専用線やスケーラビリティ厳しいVPNの置き換えを行っていたところから、IoTサービスとSORACOMサービス群が相性バツグンなのが伝わりました。
A4：カメラデバイスとクラウド〜スムーズな連携のために〜
SORACOM、スマカメ、ABEJAの提携事業。
スマカメで撮った映像を、ABEJAがリアルタイム解析して店舗内の動線ヒートマップ等で可視化。両社のエンジニア間で技術交流をされているとのこと。
※おそらく後日スライド公開
メモした内容を下記に残します。
***
□ SORACOM Inside
SORACOM CTO安川さん
クラウドにインテリジェンスがある
デバイス制限（非力）
NWへの接続
セキュリティ
クラウドとのインテグレーション
LoRaWAN（基盤）
A〜Hまでサービスあります
SIM認証 Soracom Endose
仮想L2 Gate
基本
Polaris 回線
Dipper 認証課金
Hubble 監視
「アーキテクチャはローンチ以来変わってない」
独立したマイクロサービス、を提供しているDipper
すべてAPIで連携する
IoTスケールなプラットフォーム実現のためにやったこと
Scalability＆Avairability
地理的＆技術的
進化のAgility
運用効率
現在、5,000以上のクライアントが利用
１：Horizontal Scalability
負荷増える
コアコンポーネントがサーバを動的に増える仕組み
Built in Resilience
SPOFがない構成
障害あっても自動復旧
全レイヤーに。
Dipper：DynamoDBを使用
２：グローバルレイヤー
グローバル前提
2017年
1月USA
3月ヨーロッパ
User Console（SPA）
API
SORACOM連携
言語は初期から日、英
Day1からタイムゾーンはUTCにしている
※世界に配置しても同じ基準である
SIM for Global
120国超える
LoRaWAN
LoRaデバイスで新しい無線技術もサポートもスムーズ
ユースケース
３：疎結合化と非同期化
新サービス12回
リリース38回
パケット転送
帯域制御
課金データ→S3（アーカイブ）
S3 Notification ダウンロードして処理
独立して進行
課金エンジニア
コアエンジニア
SORACOM Funnel
内部アーキテクチャ
Kinesisのストリーム
→Lambdaファンクション
新サービス増加＝新たなLambdaFunctionの追加で済む
４：運用を考えた開発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、
英語圏で勝つことは市場に勝つことではない
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、920MHｚ、RS-485
ダイレクト集約パターン
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
反応速度
解析の陳腐化の速度
コスト高低
エラーコントロールの難易度
クラウド判断基準
１：スケール可能な導入体制
２：継続的なサービス提供
３：新しい種類のデータ取得
１：スケール可能な導入体制
スマカメ店舗設置、ネットワークへ接続、計算マシン上で解析
エッジでの計算との比較
計算マシンを店舗に置ける場所が少ない、バックヤードのみ、電源確保、LANケーブルとか。
全国小売店でデータ取得したい
→店舗はシンプルにカメラ置くだけにした。
２：継続的なサービス提供
設置したら長期間で保守。
故障要因減らす、保守簡単にする。
３：新しい種類のデータ取得
新しいプログラムの提供
エッジマシンの入れ替えは手間
まとめ
デバイスサイド
ネットワーク到達性の確保（NAT越え）
書き換え前提とした汎用的ファームウェア
クラウドサイド
クラウドへのオフロードによるデバイス実装、現場設置の負担軽減
ビジネスチャレンジへの相互理解が重要
***
参加録 Dockerを利用した開発事例～Docker導入から運用まで～
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）
サービス
動的ポートマッピング
アプリのバージョン１を４個下さいでOK
BlueGreenデプロイメントが容易
AWS Batchでもジョブスケジューリング
ECSがジョブを持ってくれる
3 clear trends ECS adoption by Datadog
１年で３%→１５％へユーザー数向上
コンテナ数増えると問題増える（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
ダッシュボード
EBS
ワーカー
SQS
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」への取り組み
マイクロサービス（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周辺ツール、特にクラスタ管理まわりの情報をキャッチアップできていなかったので、
貴重な知見を頂きました。
