第48回 情報科学若手の会に行ってきました。

情報科学若手の会に参加してきました。雰囲気、内容ともに、とても充実した会でした。

  • 情報科学若手の会

  • 第48回情報科学若手の会まとめ #wakate2015 - Togetterまとめ

  • 情報処理学会プログラミング・シンポジウムに関連する会だそうです。

  • 学生、社会人が半々くらい、１０台末〜３０台前半くらい、31の自分は高齢者でした。
  • 大学時代の学会発表ほどフォーマルではないが、研究や実戦投入を元にした話題が多いです。勉強会やプレゼン大会の濃いところだけを集めた感じで、総じてレベルが高いです。
  • プレゼン→交流イベント→懇親会→プレゼン→懇親会→プレゼンの3日間。懇親会が26時以降まで続くので体調を整えて参加のこと。
  • 学生社会人問わず、プログラミングやネットワーク、組み込みなど、技術大好き。
  • 表立って話せない事も結構ありました。内容紹介はスライドが出ている範囲にフィルタしています。
  • ぜひ行ってみたい人用に次回のお知らせを受け取れるサービスがあります。

docs.google.com

はじめてでもわかる!IoT の過去・現在・未来(湯村翼さん)

www.slideshare.net

  • もやっとしたIoTについて事例を通して紹介、技術の流れを追いながら今後どうなるかについて。
  • 電脳社会論という本があるから読もう！って絶版してた。

www.amazon.co.jp

  • 研究→製品化のスパンが短くなっている(5年未満もザラ)。面白い分野だけど、研究でやるなら流行りに飛びつかず先を見据えて行わないと、研究終了時に陳腐化している可能性がある。
  • お家ハックナイトというイベントがあるので、興味があるなら参加しよう。
  • 最近、IoT分野に閉塞感がある。デバイスはあるけど何ができるようになったのか、利用者へのメリットが示せているのか？
  • IoT家電は通信規格バラバラでは消費者は手が出ない。

IoT で進化するミツバチとの交流(畑昌宏さん)

speakerdeck.com

  • 銀座でもミツバチを飼っており、はちみつの地産地消が行われている。
  • 巣箱の管理、スズメバチの撃退をIoTを活用して行うための開発(センサ & 箱)を行っている。
  • 意外にも、参加者の周辺でも蜂を飼っている人が数名いた。
  • ハルロックという漫画にいろいろヒントが有るらしい。

www.amazon.co.jp

  • 蜂にかぎらず、農業分野でのセンサは、かなり共通化できそう。GPIOに接続可能で安価なセンサモジュールが出回れば喜ぶ人が多そう。

Alloy で学ぶ形式手法(名渡山夏子さん)

speakerdeck.com

  • ガチガチじゃない形式手法で仕様の正しさを検証する。
  • 昔使ったUMLベースの厳密な仕様証明ソフトと違い、最も単純(そう)な仕様違反パタンの例示をしてくれる(っぽい)
  • プログラムの仕様だけでなく、数学証明やパズルの解もできる(アルゴリズムに落としこむことで)
  • 分散処理で個別のエージェントの状態遷移を記述すればプロトコルの妥当性検証もできそう。

ぼくらのプログラミングから、みんなのプログラミングへ(加藤淳さん)

http://junkato.jp/publications/wakate2015-kato-slides.pdf

  • プログラム環境の進化は５０年前から余り変わらない(文字ベースということで)
  • インタラクティブ系はデバッグが大変(Kinect前で同じポーズを取ったつもりでも、入力信号的として異なっていたり)→DejaVuというシステムで入力信号を再現する環境を作成ナドナド
  • TextAliveという歌詞アニメーション(カラオケで映るような映像)の作成(?)環境。
  • JavaScriptでエフェクトをつくり、GUIでパラメタ編集もできるようにCUIとGUIを場面に合わせて共存できるような作り。
  • 歌詞アニメーションに特化したからできることなのでは？→「特化開発環境を作る開発環境の開発、仕組みづくりができないか」とのこと。

HCI 分野の紹介と最新研究(太田佳敬さん)

ota42y.com

  • フィッツの法則などで、インタフェースの良し悪しを定量的に測ろうという試みがあった。
  • 全てが数式化できるとは考えないが、ある程度計算できれば「どうしてこうなった」や「誰か止めなかったのか？」という事案が減りそう。

ISP の作り方(江草陽太さん)

speakerdeck.com

  • Home NOC Operator’s GroupでISPを作ろうというお話。
  • 世界中のISP同士はBGPなど、教科書でしか見たこと無いプロトコルを使って経路制御をしている。
  • IPとは異なるレベルでの経路制御の実装と事情が聞けたのはかなり貴重。

IT×宇宙で何をしよう!?(館下博昭さん)

  • 招待講演。
  • プレゼンが出ていなかったため名前のみ

Use Open Data with SPARQL(塚本英成さん)

www.slideshare.net

  • Open Dataの基本(定義みたいなもの)
  • 単に公開すればOKというものではなく、構造化されていてコンピュータで使いやすくなければ活用できない(が、日本の各自治体でそこまでやるには人金技術が不足)。→自社製品でExcelから色々な形式に変換できるよ♪
  • SPARQL : RDF(よく調教されたOpen Dataのフォーマット)を検索、変換するためのクエリ言語、自治体ごとに異なるタグを統一したりもできる。
  • 見せ方は技術で何とかなりつつある。問題になるのはシステムに入力するまで。その辺りに良いソリューションはないかな？
  • 自治体は独自色を出したがるが、Open Dataは全てのフォーマットが統一されていることが大事。自治体で持ちにくいシステムは都道府県や国で整備して同じインフラを使わせるとかできないのかな？

ルータで斬り込め！おうちIoT(末田卓巳さん)

ルータで斬り込め！おうちIoT.pptx - Google ドライブ

  • 家にあるルータをIoTのHubにしてしまえ！という話。
  • 買ってきたままのルータではできないが、OpenWrtを使ってLinuxマシン化して、デバイスと繋いだり、アレコレできるとうい話。
  • コンパイルが失敗したら警告灯を回したり、タイヤつけたりプロペラつけたり。

関係者の皆さん、ありがとうございます。 次回も参加したいです。

PROCESS WARPが総務省異能vationプログラムの一次選考を通過しました。

二次選考まであるので、手放しに喜べるわけではないですが、それでも嬉しいです。協力いただいている方々に感謝です。

www.inno.go.jp

新しい分散実行の仕組み PROCESS WARPについて

CMU #31で「新しい分散実行の仕組み PROCESS WARPについて」という題目で発表してきました。

cmu.connpass.com

www.slideshare.net

emscriptenについて発表してきた時より、うまく伝わらなかったと思いました。 以下次回以降へのメモ。

処理の概念(C/Sとの違い)

  • 現在のインターネットの仕組み(C/S)について、1枚くらい説明し、目指している仕組み(分散)について述べたほうが良い？
  • だれにでも分かるを目指して中途半端になるより、ドンドン深堀りしたほうが見ている人は面白いのだろうか？

分散処理の例

一般で使える分散処理を目指すには

  • ヘテロ環境を活用する
  • 一般的なプログラムは手続き型
  • 手続き型プログラムを最適な場所で実行するには
  • 資源はどこにあるの
  • プロセスマイグレーション

ヘテロ分散+プロセスマイグレーションがインフラとして存在する世界

  • WikipediaがC/Sでなく分散処理だったら
  • 攻殻機動隊を例に出しても、そのネットワークがスゲーという人は少ない、「え？どのあたり？」みたいになるようだ。
  • 電脳って言うと、脳みそをチタンの頭蓋骨で囲ったアレをイメージするっぽい。

うーん、悩ましいです。

64bit長以上の計算はRubyにお任せ

プログラムのバグ修正をするときに64bit長(約2千京)の整数の計算を確認する必要がありました。 しかし、手持ちの電卓やオンラインの電卓で64bit長ギリギリの計算ができないんですね。エラーも吐かずに答えが間違っているものもちらほらありました。 どうしようか考えている時に、Rubyでは31bit*1を超える数を扱うときに自動的にBignumに変換され、ほとんど無限桁*2の計算ができることを思い出しました。

加減乗除

$ ruby -e "puts 17293822569102704659 + 1"
17293822569102704660
$ ruby -e "puts 17293822569102704659 - 1"
17293822569102704658
$ ruby -e "puts 17293822569102704659 * 49"
847397305886032528291
$ ruby -e "puts 847397305886032528291 / 49"
17293822569102704659

余り

$ ruby -e "puts 847397305886032528292 % 49"
1

冪乗

$ ruby -e "puts 847397305886032528291 ** 49"
299410390190802054749918695294118178768666364157201158847876378875892148528528490766536289930242614417203176503141942537641556895268693480282928279974829333588718093858747677035833213175727118411325314655767868091615267226746468812654149929866008523638065317815506979890218893709080502283374303282996545135372385617448764965080119848829846436781486978235343078892672922911862247836730262591383554509210886421045590070200777572441746320081961625614561393976638591103611359906785060949305922292730815469858888158884500134962229869587884555707170748994074809041011369977420215473060081028235478896640206299960869318434769166871641482184760758142490935875980506376118606487687628035420381819650573907742526876033480268792039724694808574145831561471522160364594255766896242126366359264480607053816393048981299496597201788645911052134818253593241671174518656851089518954701472962272010750047822544578908744788743107069286326315145964797807858337701222385356695853670492477256353649453350444084757929233183478601702761133590670723811

16進数へ変換

$ ruby -e "puts 17293822569102704659.to_s(16)"
f000000000000013

10進数へ変換

$ ruby -e "puts 0xf000000000000013"
17293822569102704659

括弧やビット演算機能があるので、エンジニア以外の方も困ったらRuby電卓で！

*1:リファレンスマニュアルではFixnumは「ほとんどのマシンでは 31 ビット幅」まで扱う事ができると記載されています。多分Fixnumはintで扱える値をカバーするのだと思います。intが64bitの場合は63bit幅まで扱えるのではないかな？

*2:主記憶の容量次第。

JTF2015で見た分散、並列処理

2015/7/26に産業技術大学院大学で開催されたJuly Tech Festaを見てきました。メインストリームとして、仮想化(Docker, CloudStack)や自動構築(Ansible)が多かったのです。興味分野の並列実行環境(Hadoop, Spark)に関連しそうなセッションを中心に回り、思った事を記録します。

2015.techfesta.jp

CPU単一Coreの処理性能が現実的な天井に達しつつある今、いかに効率よく複数CPUを連携させて問題解決を行うか、またその環境をどのように構築、利用、維持するかがバックエンドエンジニアにとっての課題になりつつあります(多分)。最後は「Googleスゲー」なのですが、今回は、その結論に至るまで関連するセッションを順に説明します。

Apache Sparkを用いたNoSQLバッチ並列処理へシフトするための発想転換と実装事例

劉 雨さん@株式会社ワークスアプリケーションズ

(タイトルが少し変わっていました。) 並列処理環境の１つのストリームとしてHadoop/Sparkがあります。Hadoopは2004年にGoogleが発表した並列処理に関する論文を元にOSSで開発されたプロダクトで、Sparkはそれの改良版のプロダクトです。

このSparkでの実行効率を上げるために、いかに実行時間を短縮するか発表されました。プログラム中には並列実行可能な処理と、逐次実行処理の２つが含まれており、Spark上の処理スピードの上限は、逐次実行処理に依存します。マシン台数を増やせば並列実行可能部分の実行時間はマシン台数に反比例します(データの分配や集約のため頭打ちにはなる)。劉さんの説明ではプログラム中の逐次実行処理を並列実行可能な処理に変換、最適化することで、高速化するとのことでした。

  • 一般的なエンジニアが逐次実行っぽく書いたプログラムが変換できる。
  • 変換前後のプログラムで出力される結果が変わってはダメでそこがむづかしい。
  • 変換処理はコンパイル前のプログラムに対して行うが、基本ロジックは同じなため他の処理系(言語)でも行けるだろう(発表後質問)。

ワークスアプリケーションズさん自体はERPなどのサービスを展開しています。該当機能を売りにしている訳ではないので製品公開は無さそうです。去年と同じならスライド公開も無さそうなのでチョット残念。

IoTってなに？MQTTができること

森藤 大地さん@ニフティ株式会社

今までのシステムで扱うデータは、利用者が入力したものや他のシステムから取得したものでしたが、これに加えてIoTデバイスで集めたデータの処理が加わりつつあります。 大量のデータをどう集めるかが新しい課題のようです。

  • MQTTはとても厳しい環境向けデバイス(電源供給できないとか、通信回数がやたら多いとか)向けにHTTPの代わりのコンパクトなプロトコル。
    • HTTPに比べてヘッダが小さい、Keep Alive Timeが無限、切断検知機能などが特徴。
  • MQTTでデータを集めるためのMQTTブローカというサーバが必要。
    • ブローカからHTTPでデータを受け取って普通のwebアプリにデータを活用する仕組みっぽい。
    • デバイスから直接MQTTをサーバに投げるのではなく、IoTデバイス→(BTLなど)→スマホや中間集約用のデバイス→(MQTT)→MQTTブローカーという流れ。
  • ニフティ他数社でMQTTブローカを提供するサービスを行っている。

仮想化とストレージの新しい形！ハイパーコンバージドインフラの技術解説

島崎 聡史さん@ニュータニックス・ジャパン合同会社, 日本CloudStackユーザー会 副会長

仮想化でOSを集約するとどうしてもディスクアクセスがネックになります。

  • サーバサイドの実行基盤をプライベートクラウドで作る場合、スモールスタードからのスケールアップを計画してもストレージ周りはスモールスタートが難しい。
  • SANやFCスイッチはスモールスタートするとアクセス速度が遅い。ディスクを増やしてもスピードが上がらない(安価製品はバスが貧弱という意味で)。そのためホストを増やすとストレージに引っ張られて個々のVMのスピードが低下する。
  • ニュータニックスではCPU、メモリとストレージを同一の2Uのユニットに格納したプライベートクラウド用アプライアンスを開発。
  • アプライアンスの数を増やすと、よしなに連携してストレージを形成する。
    • アクセススピードや耐障害性も考慮したアルゴリズムを提供する。

ニュータニックス製品のコンセプトだけでなく、データのコピー戦略などの仕組みも詳しく説明されていました。 よく考えられており、VMに限らず汎用ストレージのソフトウェアとして出して欲しいと思いました。

他のイベントと同じならスライドは公開されなさそう。

ここまででの雰囲気
  • Webシステムは他システムとの連携やロジックなど、複雑度が増している。
  • それに加えIoTや機械学習など、大量のデータを複雑なアルゴリズムでゴリゴリ処理するステージが登場した。
  • 複雑なシステムを格納する柔軟な箱としてVMが重用されている。OSやネットワークを自動構築や監視技術が発展している。→フルマネージド

Googleが描く、MapReduceを超えたビッグデータの世界

佐藤 一憲さん@Google

speakerdeck.com

(実際では英語版の最新のスライドで発表がありました)

  • Googleの処理はHadoopやSparkのようなシステムでは間に合わない。
  • Googleの全てのデータセンタは全てのノードが同じシステムで動いている。
    • Dermel(Big query), Flume & MillWheel(Dataflow)という超巨大なDB(多分ファイル込み)兼分散処理機構。
    • Dermelの論文
    • Hadoopなら一晩かかるような処理が、Googleのメインのサービス(検索、アナリティクスなど)を実行しつつ他の利用者も容赦なくジョブを投入する環境下で30secで完了する処理性能。
    • SQLクエリーを投げると分散処理用に分解して数千個くらいのノードにばらまいて結果を待つ。
    • 最初から分散処理を念頭に置いているので仮想化などで個別のMTBFを上げる必要がない。
    • システム構成(というか、どのノードで実行するか)自動的に最適化＆スケールする。
  • データは全てDermelに格納し、クエリーを投げてデータを取り出す。
    • IoTだろうがなんだろうが仮想化などで個別のシステムを作らなくてもBig queryに放りこむ。
    • SQLで書けない複雑な処理だけをMapReduceで処理している。
    • SQLなので、プログラマ以外の社員もデータを取得して使える。

みんな独自システムに頑張らないでBig query使おうぜとのこと。凄すぎです。逆にGoogle以外の会社や自分が頑張っていることが何なのかショックでもありました。

時間の関係でFlume & MillWheelについてはかなり端折った発表でした。

通信の最適化対策

一部の方々の間で話題になっている通信の最適化について、原理と対策について説明します。

今回の説明では、説明責任や法律は置いておいて、技術的な問題だけにフォーカスします。

「通信の最適化」の話題の発端

  • とあるゲームのパッチ配布がSoftbank環境で失敗するという事象が起きました。
  • 原因は、キャリア側で端末に送信する画像ファイルを不可逆圧縮しており、プログラムでパッチの整合性の確認に失敗してしまうものだそうです。
  • 実はSoftbankだけでなくau、NTTドコモでも同様の仕組みを組み込んでいました。
  • 「そんなの聞いていない」「電気通信事業法の通信の秘密の侵害だ」という声があがっています。

japanese.engadget.com

togetter.com

ネットワークの規格

ネットワークを流れるデータは幾つもの規格に沿ってデータが正しく送信されるようになっています。インターネットは無数の組織が管理する大量の機械を中継して送信されるため、それらが相互に接続できるように国際的な規格が決められています。 皆さんが見ているWebページを例にすると、

上記以外にも通信相手を見つけるためのDNSやARP、MACなどたくさんの規格が関係しています。その規格のいずれもが、RFCやIEEEなどの国際的な規格として公開されています。

通信レイヤーとWebサービス

HTTP〜Ethernetの規格では送ったデータがそのまま届くことを実現しようとしています。 普段利用しているWebサービスはHTTPまでの層が規格通りに動いていることを前提として提供されています。ここで、どこか1つの層が想定外の動きをするとWebサービスが想定通りの動きをしなくなります。

また、1つのWebサービスがコケても下位のネットワーク全体には影響はありませんが、下位のネットワークで何かあると、その上で動いているすべてのサービスに影響があります。

通信の最適化の影響範囲は、その回線を使う全てのサービスということになります。

通信の最適化 = 未知の通信基盤

エンジニアは単に、ネットワークの規格に沿って、送ったデータがそのまま届くことを期待したプログラムを作ります。(途中でメディア変調や可逆圧縮はあるにしても)サーバから送ったデータと全く同じデジタルデータがクライアントで受信できることを想定しています。

しかし、実は、どの通信事業者もプログラムで判定可能なデータの変更ルール(＝仕様)を公開しておらず、どのデータ形式が規格通りに到達するのか不明です。 スマートフォンがクライアントの場合のHTTP通信上のJPEGは確認された1パタンでしかありません。 例えばHTTPの拡張で定義されたWebDAVや80番ポートを使うHTTP2で同様の事象が発生しない保証はあるのか、80番ポートの通信だけが対象なのか、バイナリデータの先頭部分が偶然JPEGヘッダと同様のパタンとなる場合はどうか。 今まで前提として使っていた通信経路は実は規格に沿っていない未知の通信基盤で、話題の発端となったゲームの不具合は、それによって確認できた不具合の1つということです。

対策

前述のような信用出来ない場合、送ったデータがそのまま届くことを自分で保証する必要がでてきます。 いまのところ現実的な解法はHTTPS(SSL)を利用することです。 HTTPSには改ざん検知の仕組みがあるので、(通信の最適化が改ざんにあたるかどうかは置いておいて)ある程度の対策にはなります。また、通信内容が暗号化されるため、通信事業者によるパケットの書き換えが難しくなります。

セキュリティプロトコルマスター（1）：Webを安全にするというSSLの中身を見せて (1/3) - ＠IT

www.itmedia.co.jp

ただし、HTTPSも万能ではなく、端末のRoot証明書次第で書き換えが可能です。

qiita.com

通信事業者がコレをやるとSSL通信の安全性そのものが揺らぐので流石に禁じ手にはなっていると思います。

jp.globalsign.com

既存WebサービスのHTTPS対応状況

思いつくクラウドサービス、写真共有サイト、ブログなどのHTTPS対応状況を調べました。 ブラウザのURLを見ただけなので確実とは言えません。参考までに。

とりあえず、クラウドやGitHubにアップした画像が変更されていることは無さそうです。一部ブログなどは影響ありそうです。

PROCESS WARPはwwwがHTTP, prevはHTTPSです。