MacBook Pro 2016 Touch Bar搭載モデルのつらいところ

開発者のMac離れが進行中。移行先はLinuxか?

TouchBar搭載モデル使ってるけど、だいぶ厳しくなってきた

2017/01/06 09:40

MacBook Pro 2016 Late、Touch Bar 搭載モデル(13")を購入して3週間ほど経ちました。
エンジニア観点で痒いところがそこそこ出てきたので、購入を検討する際の参考にしていただければ。

macOS/Windows10以外インストール不可

[現在のところMacBook Pro Late 2016にLinuxをインストールするのは難しいもよう。 | AAPL Ch.] 参照。
デバドラがサポートできなくなりつつあるとのことです。
自分がMacに乗り換えた理由の一つにWin/OSX/Linux全部直に使える、というのがあったのですが、その時代は終わってしまいました。
Gentoo入れてネイティブDockerでXしたり性能を持て余したりしたかったが残念...

BootCamp Hyper-V使用不可

厳密にはHyper-V プラットフォームを有効化→再起動するとブートが完了しなくなり、削除→再インストールするまで直らなくなります。
'15モデルから[CSM-BIOSがなくなり、UEFIのみになった]弊害でHyper-Vが使えなくなったとのこと。
'14モデルではBootCampからの再起動時にUEFIからBIOSに切り替える、ということをやっていたので有効だったとのこと。UEFIだと起動しない、という状況はHyper-V第2世代のUEFIサポートとは違う代物なのだろうか...?
現状これによってDocker for Windowsが使えない状況です。Hyper-V Container使いたかった...

Fキーが完全に無効になるタイミングがある

いまいち条件が把握できていないのですが、Fnキーを押してもTouch BarがFキーにならない状況があります。
文字入力の最中でも発生するので、カタカナ変換などが素直にできなくなり歯痒い思いをします。
常時Fキー表示オプションはアプリケーション単位でしか指定できず、網羅しようとするとかなり面倒です。

BootCamp BSOD時にFキーとEscが消える

BootCamp上のWindows10がひょんなことからブルースクリーンになり、その時F8キーでリカバリに入りたかったのですが
TouchBarが完全にブラックアウトしてFキーとEscキーどちらも入力できなくなっていました。
ハードウェアキーボードを繋げば認識するかもしれませんが、未確認です。
物理キーのありがたみを痛感して以来、左CtrlキーをEscにバインドしています。
心なしかCommand+Option+Touch BarのEscの強制終了ウィンドウ呼び出しも効いてない気がします。

TouchBarが規定以上のキーリピートでハングする

[vimやコマンドラインの効率を追求するため、Karabiner Elementsでキーリピート間隔を早めていた]のですが
この間隔がTouchBarのキーにも適用されるらしく、しかもハンドリングがお粗末なのか
標準以上に連打するとOS全体が固まって再起動する羽目に遭います。
TouchBarは高負荷時にはキーリリースのイベントも取りこぼすようで、ちょっと触っただけでホールド→リピート発生→虹...という理不尽な連携が簡単に決まってしまいます。
あまりにも厳しいのでキーリピートを標準に戻していますが、気を使いたくない...

Karabinerに代わるSandSツールが存在しない

MacBookというよりはmacOS Sierraにまつわる部分ですが、我々はKarabinerロスに長いこと悩まされています。
キーリピートや単純なリマップはKarabiner Elements、コマンドキーの英数/かな割当は⌘英かなでほぼ再現できますが、
SandS(Shift and Space)機能はKeyhac、Hammerspoonどちらもパフォーマンス的に限界があり、かなりの頻度でイベントを取りこぼしてしまいます。
これの代替を作るためだけにSwift macOSアプリを勉強中です。


ExcelPhotoshopAbleton Liveが使えるUNIXが出てきたら乗り換えを検討します。

GW中の抽象的な話題

父との対話

  • パソコン通信から見続けている世代からすると、近年のパーソナライゼーションの流れは異様
    • 自分の関心の外側に触れる機会が失われすぎてきている
      • みんなテレビを見ないのもこのところが大
    • 人と話さなくて良い社会になりすぎた
      • あまりにも情報が早く集まりすぎて、発信と受信の非対称性が極まってきている
        • 何も言わずに眺めるだけで一日を終えてしまう
        • 大正時代の文庫本の登場と同じような感覚なのかも
        • スマホというデバイスからの解放が待たれる
    • この寂しさを回収する仕掛けであらゆる消費活動を奪い合う時代になった
  • マイルドヤンキーは最初からいた
    • 都市に出ることの敵わなかった人々
    • 昔はもっとムラ社会的な意味で強制力があった
    • 今頃演歌は絶滅していると思っていた
      • 親父に子供の頃から聞かされ続けた演歌をフォローする世代がまだまだ生まれ続けていた
      • ここに着く人はビートルズYMOも知らずに思春期を過ごした人なのではないか
      • AKBは多分演歌だった
        • 応援歌であり、演芸であり、芸能の本質
  • 原体験にはかなわない
    • 今の大統領選のトランプも、かつてのレーガンも原体験を刺激して支持を集めている
      • 強いアメリカを連想させたものが勝つ
      • ファシズムですね

  • テレビは大乗、プログラミングは上座部
    • 場を作る力で、金持ちになる以外に幸せになる手段を増やしてもらえれば
  • NHKの名札を持って取材すると、インタビュイーが突っ込んだ話やアウトな話もどんどん喋ってくれる
    • 「ちゃんとふるいにかけてちょうだいね」という対抗心のようなものを感じる
      • NHKが振りかざす公平性に対する反発
    • 「勉強されてはるとは思いますけど...」と前置きしてからお坊さんが高尚な話を振ってくる
    • 17歳でNHKに出てから中の人になってみるまで硬直していたけれど、NHKに取材される、というのは受ける側にとって名誉なことのようらしい
  • すごい仕事を続けていれば、見逃されない
    • すごい仕事とは踏ん張ってやる仕事ではなく、普段の仕事のレベルが高い状態であること
    • そういう人が踏ん張った時に天才の仕事と呼ばれることがある
  • 野心を持ってやるとかよりは、目の前の仕事の質が高くあるかどうかの方が重要

  • Skylakeに替えてみたらさっぱりソフトが対応してなくてつらい
    • AdobeもEDIUSもQSVも遅くなってしまった
      • 識別できずに拡張命令が全部使えなくなってる気がする
      • Intelはそんな変な必殺技を使ったのだろうか?
    • Atomも終わり、IntelはARMに追いやられてお役御免になっていく
      • Skylake以降はソフトが追随しなくなっていくかもしれない

芝居を見た帰り

  • 例のアレタグがあんなにしぶといのは単に指差して笑える以外に何もぶら下がらないからなのでは?
    • 何度n次創作の対象になっても、ただただ笑えることだけを目的にしてそれ以外が混ざらない気がする
    • ホモと学ぶシリーズみたいに、もっと外から面白がってるコメントを眺めて楽しむ部分もある
    • 一周して「知ってるだけで楽しめる」昔のサブカルの位置に居座っている感がある

  • ビジネスでもアートでも、概ね手を動かせる人は面白いことを思いつけないことが多い
    • 有名な人でも、頭一つ抜けるためには共作として別のベクトルの人と組んでいることがほとんど
    • 手が動く人はだいたい人に指示することに慣れていないし、逆は名が知れることがない
    • 独りで両方やっちゃってる人はそう遠くないうちに見つかって何か起きるのでは
  • コミュニケーションが危うい人は周りの人が救いの手を差し伸べる傾向がある
    • スキルが伴ってなくてもコミュニケーションがマトモなら勝手に学習するだろう、という雰囲気がある
    • 技術職に限って言えば究極的には知ってる/わかる、だけで成立するので職能とは結びつかないけど、一緒に何かやる側としてのコストは雲泥の差がある

  • 批評の世界では「知ってる」だけで勝てる場面があった
    • ヌーヴェルヴァーグはだいたい批評家出身の人が撮っている、従来の映画の硬直を言葉で説明してからスキマを突いていた
      • 蓮實重彦の流れが一番のフォロワー、副作用は面白い映画もつまらない映画も歴史で敷き詰めるのでスリルが無くなる
  • 青森の小学生は寺山修司記念館に見学に行くけど、正道を知る前に母殺しの作家を知ってもインパクトが薄れるだけな気がする
  • 最後はみんな全部知ろうとして知り忘れてることが残る、その場に居合わせてびっくりさせたもの勝ち
  • "!"マークは全世界共通なのがふしぎ
    • 存在驚愕

Wantedly API Gateway速習会

  • Wantedlyで各週で速習会をやっています

    • 外部に公開していく、ということで社外の方にも参加してもらっています
  • AWS LambdaとAPI Gatewayから、その上のServerless Frameworkへ

  • 講師

    • Yohei Sugigami
    • WantedlyでiOSエンジニアやってます
    • Advent CalendarでServerless記事を書きました
  • 環境準備5分、Lamba/API Gatewayの説明15分、ワークショップ20分、Serverless説明5分・WS40分

Lambdaとは

  • クラウドコンピューティング
    • 計算資源がネットの向こうにある
    • Lambda Functionをデプロイするだけで動作
  • 開発チームは本質的なプロダクトの開発にフォーカスできる

    • 運用上のコストがコードだけに
  • 利用可能言語

    • node.js 0.10.36
    • Java8
    • Python2.7
  • 制限

    • 最大300秒
    • 50MB
    • 入出力6MB
    • メモリ1.5GB
  • 実行方法

    • AWS SDK Lambdaから実行
    • API Gateway->HTTPリクエストで実行
    • Lambdaスケジューラでcron実行
    • イベント実行(S3などなど)
  • 1秒あたり数千リクエストまで自動スケール
  • 無限呼び出し防止
    • 同時実行数がデフォルト100で制限
    • 変更可能
  • Lambdaコードのロード
    • リクエストを受けてからロードに数秒掛かる、外部ライブラリがあると著しく遅くなる
    • AWS-SDKとnode.jsはプリロード
    • しばらくは再利用される
  • 価格
    • 処理時間×メモリ確保量+データ転送
    • 100ms単位
    • 128MB~1536MB
      • RAMに比例してCPUもUP
    • 128MB*100万回→0.2USD
    • 1GB*100万回→1.68USD
    • Hello worldのjsで30MBくらい
    • 無料枠: 100万回・400000GB /月
      • 1年たっても無料枠が消えない
  • Pros
    • 安価
    • リクエスト単位なので、デプロイ自体はタダ
      • 環境いくら用意してもかからない
    • 運用メンテコストが低い
    • 自動スケール、限界が高い
  • Cons
    • ロード遅延
    • API活用の情報が少ない
    • AWS CLI・コンソールだけの開発はつらい
  • した2つはServerlessで解決できそう
  • ユースケース

API Gateway

  • 簡単にAPIの作成、配布、保守、監視、保護が行える
  • プロキシみたいな
  • 基本機能
  • オプション
    • DDoS検知・スロットリング
    • 1secあたりのリクエストリミットを定義できる
    • スキーマ定義→SDK自動生成
      • iOS/Android向けのものがさくっと
      • Swagger連携可能
    • IAM認証
    • Cognito
  • 値段
    • 100万回で4.25USD
    • 10TB分まで0.14USD/GB、以降割引(CFと同じ)
    • キャッシング(オプション) 0.5GBは0.2USD/月

Serverless

  • '15 8月にJAWS
  • '15 12月にissueを全部無視して、下位互換のないServerlessにリニューアル
  • 3日前に0.1.0リリース、0.0系とのマイグレーションができないくらい破壊的変更があった
  • 互換についてはかなりアグレッシブ

Project Structure

  • _meta
    • resources ... CFnテンプレート
    • variables ... STG環境での設定など
  • admin.env
    • AWScreds
  • package.json
    • デプロイするときのライブラリ
  • s-project.json
    • Lambdaの設定 メモリ容量など

ロジック

  • handler.jsでなく、lib/配下
  • エンドポイント複数について、なるべくLambdaは同じ方がキャッシュが利きやすい
    • データが大きすぎるとロードが長くなるのでバランスを見て
 3818  2016-01-21 19:34  npm i -g serverless
 3820  2016-01-21 19:37  serverless
 3821  2016-01-21 19:37  serverless -v
 3822  2016-01-21 20:03  serverless project create
 3825  2016-01-21 20:04  mkdir serverless-study
 3826  2016-01-21 20:04  cd serverless-study
 3827  2016-01-21 20:04  serverless project create
 3828  2016-01-21 20:07  cd serverless-2k0ri
 3830  2016-01-21 20:09  serverless component create
 3831  2016-01-21 20:10  serverless function run nodejscomponent/api/hello
 3839  2016-01-21 20:12  serverless function create
 3845  2016-01-21 20:18  serverless function run nodejscomponent/api/fetch
 3846  2016-01-21 20:19  serverless function run nodejscomponent/api/hello
 3848  2016-01-21 20:20  serverless dash deploy
 3850  2016-01-21 20:21  serverless dash deploy
 3851  2016-01-21 20:21  serverless env list
 3853  2016-01-21 20:22  serverless env set
 3854  2016-01-21 20:22  serverless env list
 3856  2016-01-21 20:24  serverless run nodejscomponent/api/hello
 3857  2016-01-21 20:24  serverless function run nodejscomponent/api/hello
 3859  2016-01-21 20:24  serverless function run nodejscomponent/api/hello
 3860  2016-01-21 20:25  serverless set env
 3861  2016-01-21 20:25  serverless env list
 3863  2016-01-21 20:25  serverless function run nodejscomponent/api/hello
 3866  2016-01-21 20:26  serverless function run nodejscomponent/api/hello
 3867  2016-01-21 20:26  serverless dash deploy
 3870  2016-01-21 20:31  sls function run nodejscomponent/api/fetch
 3872  2016-01-21 20:32  npm i benscholler/serverless-serve -S
 3874  2016-01-21 20:33  sls serve start
  • コケた時は
    • LambdaかAPIGか、という切り分けからスタート
    • エラーメッセージが少ない、"undefined"が返ることさえある
  • まだまだServerlessはbreaking changeが起こり得る
    • おもしろい技術なのでウォッチする価値はあり
  • こういう設計のAPIが今後出てくるのではないかなと

  • APIGはパブリックです

    • EDoSを受けると多額の課金が発生する
    • 消すか、スロットリング設定ををするか、limitをかけましょう
  • serverlessは今のところdestroyはなし

  • slsはAPIG抜きのLambdaだけのデプロイにも使える

    • ちょっとでかい、という人はLambdaを送りつけるgulpを作ってる人もいる
  • 対抗WAF: apex/apex

    • goも動くよ
    • nodeからバイナリ実行させている
    • 1300スターくらい付いてる

HHVM/Hack言語勉強会#1

HTML5 EXPERTSJP パフォーマンス・チューニング

  • なかゆうすけ@HTML5 Experts.jp運営
  • 中裕介

    • @Tsukimikage
    • JS/PHP/サーバインフラ構築
    • HTML5Experts.jp 運営
  • 実はあまりHHVMの話はしません...

    • 実は置き換えるだけではハードル高くない
  • HTML5Experts.jp

    • 会社の名前はほとんど出さずにやっているオウンドメディア
    • 日本最高峰のWebエキスパートが記事を執筆
    • 限りなく非営利
    • 限りなく中立に
    • すべての記事が永久保存版、を目指して
    • 動機はいい技術者とのネットワーキングと、担当が好きでやってるから
  • なぜこんなにパフォーマンスが悪いのか?
    • 改善企画をやろう!自虐ネタはウケるよ、とスタート
    • 竹洞陽一郎さんにアドバイスを仰ぐ

24/365 計測してますか?

  • 場当たり的にやっても改善は意味が無い
  • 継続してデータを取りつつ、本当の課題を導き出すのが重要
  • 3ヶ月くらい計測していただきました
  • ファースとバイトダウンロードタイム(TTFB)が遅い
    • コンテンツが出始めるまでの時間
    • 「50ms以内に収めろ」
  • TCPを貼り直している
  • パフォーマンストレンドが2秒を切れるように
    • モバイル3Gからアクセスするとやはり時間がかかる
    • モバイル向けの最適化
    • スキャッタープロット(点グラフ)が下に固まってると安定的に配信できる

改善施策

  • シェアボタン自作&キャッシュ
  • 表示サイズより大きな画像の最適化
  • マークアップの改善
  • WordPressでキャッシュプログイン導入
  • nginxの設定を変更しSafariで効くように改善
  • php5-fpmからHHVMへ
  • SPDY導入(SSLハンドシェイクのオーバーヘッドでパフォーマンスには悪影響が出ていた)

結果

  • パフォーマンストレンド2秒未満達成
  • スキャッタープロット改善(95パーセンタイルで2.5秒)

HHVMの導入

  • ホスティングはCloundn FLAT Type, Cloudn RDB(MySQL SaaS)
    • Ubuntu 14.04.4 LTS
    • Nginx 1.8.0
    • HHVM 3.11.0
      • クリティカルなサービスではないのでわりとカジュアルに上がります
  • Ansible, Serverspec, Jenkins
    • 去年の5月頃は落ちまくっていたので、monitで落ちたら叩き起こすようにしていた
    • 去年の夏頃からまったく落ちなくなりました
  • バージョンはapt-get updateで順調に上がっていっています

今後の課題

  • 今後さらにガリガリチューニングしていくのか...?
    • とはいえそれほど逼迫しているわけではない

HHVM/Hackでの転職サイト構築事例

  • 吉元裕人
    • 株式会社インテリジェンス/MIIDAS COMPANY所属
    • サーバサイド・フロントエンド・インフラ
  • MIIDASをHackで構築した時の話

    • 実際のエピソード多めで
    • 入門
  • フロントエンド2名

  • サーバサイド6名
  • スマホアプリ2名
  • デザイン1名

  • '15 1月:仕様策定開始

  • 3月 開発開始
  • 7月 リリース

  • 意識したこと

    • 組織の成果とメンバーの挑戦、2つを高いレベルで両立すること
  • スタック

    • HHVM/Hack
    • golang
      • もとはgolang推しだが、WAFは良いのがなかったのでHHVMを採用

なぜHack?

  • アメンバーがPHPerだった
  • 社内に多く、採用もしやすい
  • 全く知らない言語よりもハードルが低く、なおかつチャレンジング
  • いいものを作るために
    • PHPよりパフォーマンスが高い
    • 型の安心感
  • どうしてもダメな時はPHPでやりなおそう

  • WAFはFuelPHP

    • 実は対応してない
    • 最近はHHVMはWAFサポートを諦めて、「各自対応してくれ」スタンスだとか
    • WAF自体はPHP製、触る部分から徐々にHack化できる

Hackの利点

開発ルールの統一

  • PHPでも書ける」を制限
    • Hackのやり方で統一
    • enum、タイプヒンティング、hh_clientによるチェック

hh_client

学習の導入

開発・運用して感じた点

  • 負荷が高いとクラッシュすることがある
    • Zabbixで監視→再起動をやっていた、最近は起きなくなった
  • INIでメモリ使用量を調節を上げて改善した
  • メールサーバのhostsを変えたタイミングで送るとエラーに
    • HHVMがhostsをキャッシュしているっぽい
  • PECLが使えない
    • LevelDBとの連携のExtensionが動かない、代わりにHNIというものがある
    • golangバッチで解決

CentOS6のサポート打ち切り

  • 開発途中に急に打ち切り
    • 速い代わりに大鉈を振られる
  • 全サーバCentOS7に変更

頻繁なアップデート

  • LTSでも48週間
  • MIIDASは3.12にup予定、3.11で検証中

困っていること

  • いい感じのエディタがない
  • Nuclid
    • ソースが多いと思い
  • PHPStorm
    • 補完が動くが、hh_clientがサポートされていない
  • Vim

HHVM on CentOS6 本番運用のうまみとつらみ

http://www.slideshare.net/K2ICE/hhvm-on-centos6


PHP7がリリースされた今、改めてHHVMについて考える

  • 大谷祐司
    • 株式会社インテリジェンス
  • Hackの目指す所
    • バグの無いコードを迅速に書けるように
    • エンジニアがコーディング体験を楽しめる
  • Hack/PHP7機能が比較
    • タイプヒンティング
      • functionの引数/戻り値がどの種別かを指定できる
      • 7.0でようやくintやboolが使えるように
      • PHP7のタイプヒンティングは2種類
        • 弱い型指定: 自動キャスト
        • 強い型指定: 厳密に比較
      • Hackでは強い型指定のみがある
        • mixedを使うと何でも入れられる
        • null許容したいときは?intのように書く
        • Enumを使うとより強力に制約ができる
      • 型を意識した大規模サービス向けの仕様
    • コレクション
      • 5系
        • 内部的には順番付けされたマップ
        • キーは整数または文字列
      • 7系
      • Hack
        • 4つのコレクション
        • コレクションに型を指定
        • やはり、大規模サービス向けの仕様
    • Hackは3.11からNull合体演算子が使えるように
      • PHP7の取り込みが始まっている
    • Hackのみあるのがラムダ式、並列実行、Generics,Enum
    • PHP7のみあるのが致命的エラーのハンドリング、defineで配列が呼べる
    • hh_client
  • 品質重視で開発するならHack
  • スピード重視ならPHP7
    • 棲み分けできてる気がする
  • 個人的な印象
    • PHPはコミュニティによる実装が決まる
    • HackはFB社による主導
      • 正しく、実用性のある
  • hhvm.php7.all = 1
    • PHP7の後方互換のない機能を有効化する
    • HHVMは5/7両方サポート、5→7への移行にも使えるかもしれない
  • HackはPHPと同期して進化していく
  • 7リリース後も、まだまだHackを選ぶ価値はある
    • 大規模開発に効く
    • PHPの生態系に新たな選択肢があるのは素晴らしい

クラウドごった煮#14 グッバイSSH

まずLT

  • 各ベンダから7分ずつ

AWSJ 荒木さん

  • 11月からADSJからAWSジャパンになりました
  • AWS、いっぱいサービスが有ります、ほとんどSSHと関係ありません
    • 関係ないサービスを選べば自ずとグッバイSSH
  • サーバレスアーキテクチャ
    • API Gateway <-> Lambda <-> DynamoDB...
    • HTTPSのみを受け付けるAPI
    • 限られた言語ランタイムのみが動く環境
    • バックエンドストレージ
  • 温故知新
    • '06 8/24、Amazon EC2発表
      • この時点では大したことなかった
    • 11/30、metadataが導入される
      • 自動化競争、no SSH競争がスタート
      • user-data
      • 有名だったのはLightscaleのLightscript
    • デプロイ自動化
      • 、に役立つサービス
      • EB, CodeDeploy, OpsWorks, CFn
        • EB登場時は「Google App Engineみたいなものです、いざとなったらSSHできます」と謳ってました
      • 組み合わせも可能
      • AWSのDockerユーザのうち相当な割合がEBのうえで動かしています
    • AWS Management Portal for vCenter
    • AWS Management Pack for Microsoft System Center
  • SSHの次はグッバイEC2を目指しています

Microsoft 久森さん

  • AzureでSSHとサヨナラする
  • SSH, Chef, Puppet, Ansible...の流れでMSが出てくるのは時代ですね
  • 結論:PaaSを使いましょう
    • →VisualStudioを使いましょう
    • 売りは一気通貫
  • IaaSなんだけど、という方
    • Azure Resource Manager
      • jsonを書いて自動デプロイ
      • CFn?
    • Azure Automation
  • 違う、そんな極論と宣伝を聞きに来たんじゃない
    • Linuxしかないし、今のサービスに適用したい

ここからが本編

  • 複雑さを減らすな、仕事を減らせ
  • 久森さん
    • 半年前にジョイン、MS初心者
  • クラウドや自動化が定時退社を与えてくれるわけではない
    • Puppet, Chefはオンプレ向けプロダクト
    • 1ノードごとに複数の役割を与えたい、それに応じてChef/Puppetは複雑なロール管理を備えた
  • クラウドは雑に、柔軟に
    • 複雑なセットアップは不要、複雑になっちゃうのはうまいこと分解できてないハズ
    • Packerを使おう
  • 結果として
    • 小難しいプロビジョニングツールクラウド時代には不要
    • 十分役割が小さければトラブルは起きにくい
    • あとはAutoScaleしときゃOK
  • 監視は?
    • 監視 as a Serviceが出てきてます
      • セットアップ時にエージェント入れとけばOK
    • MSはOMS(Operations Management Suite)というサービスが有ります

ニフティクラウド 竹内さん

さくらインターネット 横田さん

  • 横田真俊
  • 2/3くらい同業者ですよね
  • クラウド提供側の自動化

クラウド事業者にとって完全自動化は幻想

  • クラウド(利用者側)は問題なくても、クラウド基盤(提供者)では問題がたくさん
    • リソース増強
    • ホストサーバ(実機)が必要
      • もちろんリードタイム、スペック、根回しなどなどに気を使う
  • サーバ以外にも買うものがある
    • ネットワークストレージ
    • アーカイブ用ストレージ
    • NW機器
    • Windowsライセンス
  • ストレージ
    • 慎重に検証・運用しており、現状では自作ストレージとアプライアンスを組み合わせ
    • あれから実直に運用しています
    • DRBDで冗長化
  • NW機器
    • カタログスペックは幻想
    • 検証時はとりあえず溢れさせる
    • 機器をダウンさせるあらゆる方法を考える
    • メーカ・ベンダのレスポンスも重要
  • よくあるパターンはだいたい自動化出来ます
    • たとえばホストダウン
    • ストレージ障害
      • 自動的に正常なSSDに移動します
  • 我々は出来るところから運用を自動化していってます

Cloudn 鈴木さん

  • NTTコミュニケーションズ 鈴木大介
    • '11入社、Cloudn開発チーム所属
      • 電話がなる前に目が覚める生活をしていました
    • Enterprise CloudとCloudn
    • 前者はエンプラ基盤に対応、後者はAPIを整備
  • やってることはSSH
  • Fabric
    • デプロイ・システム管理ツール
    • もともとは手順書に沿って構築
      • だんだん間隔が縮んで、手っ取り早く自動化しないと...
    • 並列実行可能
    • エージェントレス
    • 学習コスト低
    • 担当者の趣味(Rubyが嫌い)
  • トラブル対応
    • 原因解析、復旧作業、影響範囲特定、ユーザ通知...
    • 影響特定・ユーザ通知の半自動化
    • CloudStack APIによる運用ポータル
      • VMの操作、VM管理、リソース管理、インシデント管理、影響特定、ユーザ通知、復旧...
      • VMが増えると標準ダッシュボードは使い物にならなくなってくるので自作
    • 通知文書の自動作成、承認は人間なので結局電話がなる
    • 解析と復旧が一番大変
  • 目指すのは完全自動化
  • Enterprise Cloud 2.0での取り組み
    • 拠点の海外展開のために自動化推進

IDCフロンティア 佐々木さん

  • 「いつもSSHしてます」みたいな話をします
  • 佐々木惇
    • 数カ月前まで構築・運用
  • 手作業の何がいけないか
    • 作業ミスのリスク
    • 知識・技術・権限が必要
    • スケールしない
      • エンジニアに負荷が集中、管理できる規模が限られる
  • CloudStackの仮想ルータ
    • 外部との接続のために必須
      • 障害=サービス断
    • 万単位で存在、勝手に増える、人手管理は不可能
    • 放置したら数時間で通信不能に鳴る場合も...
    • →監視と不具合対策を自動化
      • 定期的なヘルスチェック、自動不具合修正
    • 「自動化するしかない」ならある意味で楽
  • キャパシティ監視
    • ハイパーバイザ・ストレージなど
    • 時間がかかる
      • 間隔は日次が限界、項目数に限界、確認方法の周知が必要
    • 運用で何とかしていた
    • それはヤバイ、ということでAPIを活用して自動取得
      • CloudStack, VMware...
      • 細かい時間変化のパターンがわかる
      • 必要な項目をすぐに追加できる
      • エンジニア以外の人にも管理を依頼できる
  • 課題
    • スクリプト書ける人が少ない、ワークフローめんどいなど
  • 自動化によって大規模環境を技術・知識をあまり必要とせず

IBM Osonoiさん

  • 拡大解釈します
  • グッバイSSH
    • エンジニアの幸せのためのクラウド
    • エンジニアの幸せのための働き方
  • 小薗井康志

    • intel -> opendream -> Linux Foundation -> DELL -> 去年からIBM
    • 幸せなエンジニア人生を求め、ベンダロックインされない働き方を模索
    • OSDL Japanを設立
      • Linus主催のKernel Summitを日本で開催
      • '05年当時、MSは本当に怖かったです
    • Dell テックセンターコミュニティ
      • デルユーザ(サーバ、ストレージ、ネットワーク)のためのコミュニティ
        • 日本は会社へのロイヤリティが高い一方、人に聞けばすぐに答えが見つかることも多い
    • MeeGoユーザ会、Drupalなど
  • いくつかのポイント

    • オープンで標準的な技術をベースしましょう
      • できればOSS、トレンドをつかんでおきましょう
    • 会社の垣根を飛び越えて活動しましょう
      • 社外コミュニティ
      • 勉強会も各地であります
      • できれば国境も
    • デキる人と知り合おう
      • やっぱり勉強会、コミュニティで
  • IBMのオープン・クラウド戦略

    • Open by design
    • SoftLayerはOpenStack
      • スケジューラを独自からHeatに
    • BluemixはOpenFoundry, node.js
  • "柔らさ層"でググるとSoftlayerの本が出てきます
    • 透明性が高いです
      • HW,NWの中身が公開されている
      • 自前のPuppet,Chef,SaltStackを持ち込むユーザが多い

パネルディスカッション

  • OUT: AWS / IN: VMware
  • 内部基盤のバージョニングのロードマップなど、次何をしようとしてるのか?
  • 独自はNiftyCloud、さくら、MS、VMware
  • Softlayerはベアメタルなので仮想化レイヤからユーザに委ねられる
  • 既存
    • Cloudn: CloudStack、OpenStack
      • Enterpriseの方はOpenStack寄り
      • 個人的にはどっちに倒したい?
        • 自分が運用しているのはCloudStackだけ
    • IDCF: CloudStack
  • 独自
    • Nifty: 基盤はVMwareだが、そのAPIをバシバシ叩いてフルスクラッチでCloudStackみたいなのを作っています
    • さくら: 結構前からやってて、当時OSSが成熟してなかった 週4,5機能追加するくらいのペースになってきている
    • MS: 完全にMSテクノロジースタック、PowerShell, Hyper-V、上から下まで全部自社
      • Azureで使ってるWindows Serverはかなり魔改造されている
        • スケールするWindows Serverは2016でお手元に...
      • Azure環境でたたき台にして、一般プロダクトに降りてくるという流れ
      • NW周りは小難しい話になります
      • GPUインスタンスとか、そういう機能なかったのに魔改造しまくられてたりする
    • VMware: vCloud directorというのをプロバイダ向けに出している
      • 自分たちで使って展開している、vSphereは互換性重視で作ってます
  • クラウドを作る側?使う側?どっちに倒す?
    • →使う側の話にしましょう
    • アプリ監視を作ってる所はあんまり無いな、という印象なのですがクラウドにインテグレーションする予定は?
      • NiftyCloud: お客さんも悩んでいる、他者のクラウドの使い方わかんなくて困りました、という人も
      • AWSはCloudWatchにログ機能がついてアプリ監視と連携する姿勢
      • AzureはApplication Insightで監視する方向、個別にdatadog/NewRelicも入れれます
  • Nifty: 既存のオンプレ運用をいかにクラウドで再現するか、というとこころに苦心している人が多い
    • Time as a Service(Cron as a Service)はかなりウケました
    • 意外とNewRelicサワレナイ人が多い
  • 思ったよりオンプレ運用を再現したい人が多い
    • 学習コストは予想以上に高い
    • GCPVMあたりのスペックが低く、単一インスタンスではCPが悪かったりする
  • 要は定時退社できないから新しいことが覚えられていない、アプリが腐っていくのを見守るしか無い、という悪循環
  • みなさんのお客さんはIaaS好きな方々ですか?
  • VMwareはNWが自由にできるから入れたい、という需要が大なのではと伺ったのですが
    • NSX使ってるとL2延伸100くらい出来る
    • vSphereのHAは安定していて頼りしにている人が多い、ほかにvMotion
    • ただ、それが付加価値になっているかどうか?という話
  • Cloudn: 今あるものを動かしたい、プライベートクラウドから移行したいというケースが多い
  • SoftLayer: ほぼほぼIaaSを触りたい人、という感じ
    • こういう層のインフラエンジニアが活躍する場が少ない、ヘタするとBIOSいじってる人とかもいる
    • HPCの人が多い、チューニングで飯を食う人はカリカリに使い倒す
  • Nifty, IDCF, さくらはスタートアップ半分、大企業半分みたいな感じ?
    • さくらは個人はそんなにいない、スタートアップが大体
      • 物理から移転したいユーザが多い
      • 基本的には現状のサーバをエミュレーションする形で提供している
    • NiftyCloudは全くの個人は使えない、ほとんどエンプラ、8割位?
      • 既存環境とL2で繋いだりするのがウケてる
      • どこのクラウドもユーザ層似通ってきてるのでは、という印象
    • IDCFも昔はほとんど個人がいなかったが、最近500円クラウドの広告などで増えてきた
      • 大規模に使うのはゲームのユーザーとか
      • VMware元々使ってる人が
    • あんまり見えないのがAzureだけど...?
      • 入って半年で結構幅広く、セグメントによって全然客層が違うがソシャゲからエンプラまで、CMSをIaaSでDRBD頑張ってる人とかも見ている
      • 「AzureはLinuxも動きます」
      • 実は小薗井さんのDrupalUGでAzure使ってます
        • ベンダロックインから意識的になると客観的にサービスやトレンドを見れる
  • 意外とPaaSは多くない、PaaSで超生産性を高めてる人もいる
    • VisualStudioは素晴らしい
  • 一般論として、どうしてPaaSは盛り上がらないのか
    • CloudFoundry?OpenShift?
    • あるいはRDS/Microservicesみたいなビルディングブロック?
      • 「自分のアプリを動かすもの」?「XXX as a Service」?
    • Hadoop as a Serviceみたいなやつを組み合わせてAWSスタックに近い
  • 「〜〜〜 as a Service」の時点でSaaSだと思います
    • 自分のアプリを作る上でデプロイとかを整備するもの、Herokuとか、をPaaSを呼ぶべきでは
  • Microservicesのようなもの、単機能のものの寄せ集め、SpringBootとか...
    • SOAとは?という話になりそうなので中段
  • 日本の場合はIaaS使いたい人が多い、その次にIBaaS、という感じ、まだまだそこからぬけ出せてないのでは
  • EC2が出た頃はNWを想像してなかった
    • ところがここ最近でNWが作れる、というの謳われだした
    • NWを意識しなくてよかったのが再び意識されだしたのでは?
    • さくらは意識させているように作っています、そして流行っているものは正しい
  • AWSからVPCが出た時、VPCを作らないとEC2を作れないようになってちょっと悲しくなった
  • AzureのWorker/Webがなくなった
    • 既存の運用のセオリーを頭に持ってこないと使い方がわからなくなる、という部分がありそう
  • ACLとSGが分離のしたのは最悪だったと思います
    • でもどうせ全台にパブリックつけてるでしょ?という話なのでは
    • さくらはほとんどそういうことはないです
      • GWをがっつり提供しているからなのでは?
  • VPC提供はクラックされるサーバが増えてきたからでは、というのがありそう
  • 感覚的にはフラットだとクラウドネイティブっぽく、VPCがあると既存スタックを持ち寄る感覚が強い
  • SoftLayerはスイッチ・ルータもベアメタル?
    • NW周りで
  • 個人的にはフラット+SGみたいなのがあればそれでいいのでは、と思うが学習コストの問題に落ち着くと思う
  • クラスAが枯渇しそうな人?

  • 今この状態を続けて幸せですか?
    • IaaS寄り、学習コストの問題...
    • 結局は見返りがあれば、という話になるのでは
    • もしかしたら幸せな定時退社の世界があるのかもしれない、そのために頑張るというのは大いにありそう
  • 学習コストが本当の敵?
    • Nifty: 会社が認めてくれるかどうか、というのがほんとうによく聞く話
    • IDCF: 周りの人がやりだした、時代の流れで変わってくる、というのも十分にある
    • Cloudn: 結構クラウドやっていきましょう、となるが現場の意識の差はわりと大きいことがある、マインド
    • さくら: 基本的には時代の流れ、EC2を始めるのにそんなにコストが高かっただろうか? いまNWが盛り返しているのはNWを触っている人たちがユーザになってきたとも言えるのでは
    • MS: 先進的なユーザは気づいていて使っている、その時にどれくらいの情報が転がっていてどれくらい勉強させてくれるか次第 全体的な流れはまだまだIaaS
    • VMware: 互換性から話をすると学習コストと検証コストを考えてIaaSを選ぶ人がやはり多そう、一方でアプリのアーキテクチャを変えないと価値が出ないというのも分かる人はわかっている
  • Cloud Enabledになるために、次から作るアプリから検証されだすのでしょう
  • クラウド事業者として...
    • 学習コストの裏にはヒト・モノ・カネがある
    • クラウドを使うからといって最適化されたアーキテクチャで動かそう、ということはない
      • 運用が面倒だからクラウドに行きたいだけの人もたくさんいる
    • 次期システムはAWS、ただベースは旧システムベースなのでCentOS5/PHP5.2/qmail/Apache...ということが往々にしてある
    • アーキテクチャ刷新=開発リソースを食うことが許されないユーザはたくさんいる
  • IaaSだからNWがくっついてきたのではないか?
    • API Gatewayのような、PaaSレベルでの連携が広まっていけばまたNWの意識は薄れていくのではないか
  • ブロードキャストを通るネットワークを持っているのはNifty, VMware
    • 自分たちでもわかったりわかんなかったりする
    • 2歩先は嫌味になりそう
    • ブロードキャストをしたいのはDRBDやHAしたい人、LVS建てたい人が大半でしょう
      • オンプレを再現したい、というのが大半でしょう、ユーザのVMからはブロードキャストできるように見せている
      • 結局は再現できる、ということは
  • 裏を返せば、世の中のほとんどのシステムは投資をする価値が無い、という経営判断がなされているとも言える
    • 現場から経営を説得できていない
    • 現状それを出来るとすればコスト削減がキモでしょう
    • 小さな鉛筆でどうにかすることに慣れると、大きな鉛筆でやることが思いつかなくなってくる
      • 定時退社の本当の問題は?
      • 自分のやりたいことができないインフラエンジニアの敵は?
  • ITインフラの人たちは社内がお客さんのことが多い
    • SOR/SOEの話題が上がっている
  • 運用の問題を解決するためにXaaSにシフトしていこう、というニーズがあんまりないのでは
  • 経営で考えると、クラウドやるより減価償却したほうが圧倒的に安い
    • それに打ち勝つためには人件費削減、定時退社はマストになる
    • やはりグッバイSSHに話は戻る
  • BSからPLに変わります、という話ではなく、こう人件費が浮きます、という話
    • VMware: 他のクラウドよりウチの方が自動化してるから楽ですよ、みたいな話し方をすると怒られるけど...
      • Googleが歌っているライブマイグレーションをvMotionは昔からやってました
      • 現場のニーズに応える、それを持ち上げる
    • IBM: SoftLayerも裏は驚くほど少ない人数でやっている、残業してる様子はあんまりない
      • ベアメタル運用を含めても
      • 外資系でも同じパターンが見られる、だいたい海外は定時で帰っている
      • 別の問題も見え隠れする
  • ハウジング・コロケーションを持っている事業
    • さくら: ハウジングが必要なユーザはどうしてもいる、逃げですがケースバイケース
    • Nifty: DC専業でもNM専業でもHWでもなく、何も持っていない、もともとクラウド利用者の会社です
      • ユーザが演るようなサービスをやるためにクラウドを始めた、というのが一番の強みでは
    • Cloudn: DC部門が一番儲かってます、クラウドは儲かりきれてない
      • APIを上手く生かしてもらって、クラウドでもベアメタルをやっていくのではなかろうか
      • 初期投資を抑えるならクラウドで...
    • IDCF: エンジニアとしてオンプレでなくクラウドを使うことをどう説明しますか?
      • 早く環境が用意できる、とかで説明することになるだろう
      • Nifty:'09の頭に大激論があった
        • あわやAWS使うか、となった時に「作ったら楽しいです」と言って始まった
          • ✕「超便利だから使うか」○「超便利だから作るか」
        • 正解はエンジニアのモチベーションです
          • 楽しいことをやりましょう、できたらその動機を下の世代に伝えていきましょう
  • 答えのないところに問を求めてはいけない、というのが結論です

RCO Study Night #3 Spark・Scala勉強会

CET - Caputer Everything 全サービス横断リアルタイムデータ収集・分析基盤

  • 吉田健二
    • リクルートコミュニケーションズ
    • リクルートライフスタイル出向
    • '15 7月中途入社
    • 8年Webアプリ、この6月からこの基盤開発に従事
  • CETプロジェクト
    • "Capture EveryThing"
    • リクルータライフスタイルの全サービス横断でリアルタイムにデータ(システムログ、ユーザ行動、在校変動)の収集・分析
    • リアルタイムデータ分析に必要な処理を一気通貫
    • エンジニア以外にビジネス系のディレクター、データサイエンティストも
  • CETが解決する問題
    • サービス・ビジネスに関するあらゆる情報の変化(ユーザ行動、在庫量の変動など)を我々サービス提供者がリアルタイムに把握できていない
    • 状況に応じて最適な施策を打てるように
  • サービス
  • システム構成
    • 各サービスからSETプロジェクトへtd-agent
      • -> BigQuery
      • -> Es,Kibana
      • -> S3
      • -> ELB -> td-agent -> Cloud Pub/Sub -> Cloud Dataproc Spark
        • -> Bigtable -> API->ELB -> td-agent ->集計結果をサービスへ還元
    • 1日あたり一億数千万件
  • 可視化事例
    • Airレジ
      • コールセンタでリアルタイムにログをモニタリング
      • アプリケーションのスローダウンやユーザ操作の戸惑いなど、ユーザビリティに関する情報を迅速に検知し、顧客サポート品質向上に努める
    • じゃらん
      • Spark Streamingでウィンドウ集計
      • 定期的に直近のユーザ行動ログを集計し、宿ページごとのUU数をリアルタイムに算出
    • サービス共通のパフォーマンス監視
      • ログを定期的にウィンドウ集計、特定以上の処理時間のあるURIをアラート
  • GCPの新しいサービス(Pub/Sub, CloudProc, BigTable)
    • 何故?
      • 昔からAWSを使う慣習があったが、GCPの方が安いので
      • スループットが要求されだしたあたりでDynamoDBからBigTableに置き換え
        • 1/10コストで同じ処理速度が実現できる
    • BigTable選定にあわせて更新系をGCPに置き換え
      • EMR -> DataProc, Kinesis -> Pub/Sub
    • Cloud Pub/Sub
      • Apache Kafka, Amaon Kinesisみたいなやつ
      • 2ヶ月運用していて、概ね不満はないがいくつか制限がある
        • 1回のPublish上限が1000件まで、緩和はできないっぽい
          • tdを並列に走らせたり、td側がで1000件ずつ分割させたりしている(自前でプラグイン書いた)
        • Subscribe上限も1度に1000件まで
          • ドキュメントに設定があるんだけど、1000件で頭打ちしちゃった
          • 1000/回はやっぱりちょっと遅い、Sparkのレシーバクラス側をマルチスレッドでpullのリクエストを投げるように実装中です
      • Spark Streaming + Cloud Pub/Subのサンプルが実用的でなかった
        • Spark Streamingのレシーバクラスが必要なのだが独自実装で書かれてなかった
        • Recieverクラスを自前で実装しました
    • Cloud BigTable
      • DynamoDBにくらべて圧倒的なコスパ
      • 機能面の不満
        • TTL機能がちょっと微妙
          • 最短寿命の指定はできるが、超えると必ずクリアされる訳ではない
          • APIコール側で吸収しました
        • 結構落ちる
          • 内部のバージョンアップで落ちました、と半日〜1日落ちてから連絡が来ました
          • まだまだベータ版、収益サービスに載せるには不安
            • ベータなのはDataProcも同じ
    • DataProc
      • DataProc1.0 -> Spark1.5.0
        • DataProc1.2(Spark1.5.2)でBigTableに繋げられなかった、クラスパスが通ってなかった
        • 2,3日後に修正されました
      • クラスタ構築速度はやっぱりすごい
        • 1分くらい
      • 安定しない、収益サービスに載せるのは怖い
  • 今後検討していること

    • 在庫変動データに基づいた、在庫売り切れ予測
    • リアルタイム異常検知
  • Q&A

    • リアルタイムUU算出ってどれくらいのパフォーマンス?BigTableは足引っ張ってる?
      • near realtimeで出せてます
    • BigTable側で変更を通知するAPIがある?
      • 通知はしていない
      • サービス側から定期的にポーリングをかけて、都度BigTableから持ってきている
    • ハイブリッドクラウドの運用上の負荷は出た?
      • やっぱり統一されて無くて面倒くさい
      • できたらGCPに寄せたいなあとは思うが、社内はAWSよりなので遠そう
    • Pub/SubとKinesisのコスト上の差異は
      • 運用が違うが、現状Pub/Subの方が高くなってる
      • Kinesisはストリームを作らないといけないが、Pub/Subはいらない
      • 同じ量だとどうなんだろう、同じくらいかも...
    • Cloud Dataflowにしなかった理由はありますか?
      • ウィンドウ集計の要求があって、技術検証を兼ねてSparkを名指しで採用、Dataflowはあまり調べてなかったがもしかしたらソッチのほうがいいのかも
    • ウィンドウ集計はどこかに永続化している?

DSP開発におけるSpark MLlibの活用

  • 棚橋耕太郎
  • DIMSUM; 類似商品の高速な近似計算
    • DSPにどう活用されている?
    • 10万×10万でやるとやはりデカいので、分散処理したい
    • ナイーブにMapReduce内積を求めると
      • MapReduceで気をつけるのはシャッフルサイズ
        • ネットワークの計算複雑性
      • m:行数、L:行あたりの非ゼロ要素の個数
      • シャッフルサイズがO(mL2)に、行数mの増大で計算不可能にまで膨れる
    • DIMSUM
      • ナイーブではないMapReduce内積をを求める
      • エミットするかどうかをある確率(オーバーサンプリングパラメータ: γ)で決める、ノルムが大きいベクトル要素はサンプルせずにスキップ
        • シャッフルサイズはnlognに、mに依存しなくなる
        • n:ユーザ数
    • DIMSUMの照明
      • Chernoff boundで証明しています
      • Twitterでやってみた結果が論文にも乗っている、40%の計算量負荷軽減に
      • ちょうどいいのはエラー10%以下、のγ=2logn/ε
    • MLlibにおけるDIMSUM
      • val mat: RowMatrix = new RowMatrix(rows)
      • val sim= mat.columnsSimilarities(1000)
  • word2vec; 単語の特徴ベクトル作成
    • GoogleのMikolovさん
      • 単語をベクトル化して便利になるツール
    • アイテム特徴量の作成に使っている
      • アイテムのwebページに含まれる単語の特徴ベクトルを示せる
      • あるユーザについてすべて平均化するとユーザの特徴量が出せる
      • CVとの関係を回帰学習させられる
    • これをWebページについて行う試み
      • ページ数3000万、ユーザ数7~8000万、 PV1.6億/日
      • ->Spark使ってみました
    • MLlibのword2vecはGoogleのC実装からの移植、制限が強い
      • Skip gramの階層的なソフトマックスのみ
      • ネガティブサンプリングを使いたかったので実装
        • 頻出単語に強いです
        • じつは単純で、似非ディープラーニング
    • MLlibのword2vec cont'd
      • ちゃんと動きません!
        • 単語ベクトルが発散してしまう
        • データシャードに分けて学習してReduceするときに、全部のパラメータを足しちゃう
        • 単純平均にして、すべてのパラメータをパーティション数で割って計算させて劇的に改善しました
      • 単純平均だと学習速度が低い
        • ⊿θをデータ数で割っている、データの凸性が低いと並列化の高速化が望めなくなる
        • 学習中にパーティション間でパラメータの同期ができないか?
          • Googleオリジナル版は共有メモリで非同期に更新している
          • 同じことをMLlibでやるために↓
      • parameter server型モデル
        • '13の論文
        • 1箇所(parameter server)にパラメータを置く
          • ○パラメータ次元が大きくても分散保持できる、収束速度向上
            • アドテク業界だとロジスティック回帰で10Bになったりするので、結構なアドバンテージです
          • ✕sparkは非対応、通信コスト大
        • Sparkでparameter serverを使えるDist-MLをintelが出してるが、イマイチ早くならなかったです
  • Splash; 分散word2vec学習の高速化
    • パラメータをノードでこべつに学習、重み付けすることで高い学習効率
      • UCバークレーamplabのOSSライブラリ
      • 既存のMLlibの簡単に組み合わせて使える
      • ノード間通信は1回/iteration
      • LDA,協調フィルタリングSGD,Logistic回帰など確率系の実装が既にあります
      • この夏くらいに出たライブラリです
    • Splashの戦略
      • 更新⊿をm倍したSiで擬似的に全体データの近似として与える
      • すべての更新幅をθoldに足す
      • 誤差は(4G22 Tmn)
      • 論文に威力が証明されている
        • 2次元の最適化問題
          • 単純加算は誤差20(発散)
          • 単純平均で-0.6、Splashは-0.1未満の範囲に収まる
      • RDDをちょっと変えた、Parameterized RDDに読み込ませる
      • shared variableに更新したい値をaddで単純に足していくだけで更新していける
    • Splashの収束性能
      • SGDやL-BFGSに比べて非常に速い、100倍位早くなってるように見える
  • まとめ
    • DIMSUMなどの分散処理向けアルゴリズムをうまく使いこなしたい
    • MLlibは便利だが、注意深く使わないと性能が発揮できない
    • MLlib以外の選択肢も考慮にいれるといいかも
      • 完成されたもの、というわけではない
  • Q&A
    • DIMSUM、以前やったら商品数/ユーザ数の増加に応じて加速度的にメモリ消費量が増えた、具体的な数字はありますか
      • ノード数を増やすほど速くはなるが、EMRのm3.large上でエクゼキュータは4台、Sparkメモリサイズはあんまり大きくしていない
      • ソートするときのほうが時間がかかっていた ←Driverのメモリに依存
      • アイテム数などに応じた学習までの計算時間は、系統的なのは出せないが30分とか
    • 協調フィルタリング以外の類似度を求めるアルゴリズムとくらべて結果でどれくらい差がでましたか
      • cos類似度以外にはやってない、アイテムの類似度を使ってコンテンツを...とかはしてないです
      • 汎用的に作るためにアイテムのコンテンツには着目していない、R社はめちゃくちゃなバリエーションなので...
    • データが1回以上訪れられた時に、訪れられていたかどうかのカウント
      • これは結構スパース、あるていど行列が抑えられていた状態で計算しているというイメージです
    • 広告アイテムの推薦、のゴールは期待した値が出たらOK?何かしらのしきい値がある?
      • 今回は実際に総当り計算した時との差です
      • 最終的なゴールはcos類似度よりは実際のtop100とかとの差異を縮めていく方向

R使いがSparkを使ったら

  • 早川敦士
    • リクルートコミュニケーションズ新卒1年目
    • アドホック分析や可視化ツール開発
    • 大学時代は品質管理・信頼性工学など
    • Japan.R 2015主催
      • 普段はR言語のコミュニティにいます
  • R言語のからみるSpark
  • Strata Hadoop
    • カンファレンスのメインテーマはSpark
    • 行った後のぼく
      • 時代はSparkだ!
      • R言語ではさばけない大規模データをSparkで処理したい
      • 馴染み深いDataFrameも使える!
  • R言語ユーザにとってお馴染みのdata.frame
    • R言語ユーザはdata.frameで生活している
    • google trendでも「data.frame」うなぎのぼり
    • dplyrどっぷり
      • iris %>% head(2)
        • 世の中には100行くらい書いてる人もいるらしい
        • こういうので普段から集計しています
          • これをSparkでやるには...?
  • SparkにおけるDataFrame
    • sql-programming-guide.html / docs/latestにだいたいのことは書いてある
      • 困ったらScalaDocへ潜る
    • 現在はSparkCore/DataFrameAPIからRDD->org.apache.spark.mllib
    • 将来はDataFrameAPIからorg.apache.spark.mlに書き換わるのかも?
  • Spark DataFrameとR言語の比較
    • データの読み込み
      • Rなら1コマンド、Sparkは自前パースか別のライブラリ
    • 最初の?行
      • df %>% head(1)
      • df.limit(1)
        • dataframeのhead()だと結果が帰ってこないのでlimit()じゃないと困る
    • 列の選択はどちらもselect
    • 条件に一致する行
      • df %>% filter(Sepal_Length > 5)
      • df.filter($"Sepal_Length".gt(5)
    • groupByで行数カウント
      • Sparkはagg()でまとめてもOK
    • ソート
      • Rはarrange、Sparkはsort
    • ランク
      • Rはrank、SparkはHiveContextと書きながらSQLContextを使わないと動かないようです
        • alias()as()はソースを見ると中身はほぼ一緒でした
    • partitionBy
      • df()$""の方がイケてる、と先輩から突っ込まれました
      • rowNumber
        • pgSQLはよく使うかも
        • Rだとnに何行目か入っている
        • SparkはrowNumberを呼ばないといけない
    • 差分を求める
      • lag()
    • 累積和
      • Rはcumsum()
      • Sparkはsum()でイケるみたいです
    • inner join
      • あらかじめデータ側でやってることが多そうですが
      • R: inner_join()
      • Spark: join().where($"..." === $"..." && $",,," === $",,,")
  • 今後のSparkはRDDではなく、DataFrameがメインになっていく可能性が高いので、明日から使おう!!
  • Q&A
    • DataFrameにおいてRにあってSparkにない機能はありました?
      • ドキュメントが揃ってなくて使いづらい以外は大丈夫かなと
    • SparkRは今回は調べてないです

Ableton Meetup Tokyo #1

  • 最近のAbletonトピック
  • Ableton Loop
    • 今週金曜からベルリンで
    • Ableton社による音楽制作社向けカンファレンス、限定400名
    • Ableton初のテック系フェス
      • 日本からの誰か行かないのか、ということで自腹で行ってきます
    • Matthew Herbertとかも来ます
    • Abletonがこういうカンファレンス・イベントを仕掛けだしている、日本でもそういったオーダーがきはじめている
  • 11/14 16:00
    • Ableton Meetup Tokyo Special Session @RedBullStudio Toyo Hall
    • 日本の認定トレーナー6人が全員集結します
    • 無料、アルコール出ます
      • 特にビール

フィンガードラムのTips紹介 / abletonでリアルドラマーに差をつけろ

  • reona
    • ドラマー、トラックメーカー、DJ '07~
  • セットアップ
  • 生ドラムやっててストレスがたまる、サンプラーもあんまり楽しく叩けない
    • Abletonで楽しむトピックス
  • 今日の話はAbletonでドラムを叩く
    • HWはMachine、しかしMIDIモード
    • Machineモードだと運指が合わない
      • 指ドラマーは運指を大事にしています
  • Abletonのドラムラックで好きな運指に変えられる
  • ドラムっぽさにはベロシティがとても重要
    • 指ドラマーはだいたい127固定、ミスタッチを恐れて
    • Abletonならミスタッチを恐れず演奏できる
    • MIDIエフェクトのベロシティ
      • 曲者
      • 音源ごとにベロシティのエンベロープを細かくいじっています
        • キックは127固定
        • スネアは多少つける(64~127)
          • 2つで叩いている、2つ目はゴーストノート用なので弱いベロシティ
  • バーブをかけたい
    • ドラムラックトラックにスネアのリバーブMIDIトラック
      • Max for Liveのエンベロープ
        • トリガのタイミングでCCが出る
        • Chain Sendでドラムラックに戻り、スネアのアウトのSend、リバーブに飛んで行く
      • ベロシティで124以下は受けないようにしている、Max以外ではかからないように
  • 以上、生ドラムっぽい話でした
  • 一人で曲っぽくするあそび
    • ハットのOUTにMassiveが鳴るようにする
      • ベロシティがで94以上でのみ鳴るように
      • Note Lengthで単音にならずベースっぽくする
      • Randomで音程をいじる
      • その後にScale、Randomと組み合わせて最低限コードを合わせてくれる
        • KORGのおもちゃっぽい感じ
    • 同じ技術をSEにも
      • スクラッチも同じ原理で
        • ベロシティは63以上
        • Randomはスライス16、Length
        • サンプラー側にも一番叩くハイハットのスライスにRandomをかけている
  • External InstrumentsでドラムラックをMachineのパッドに対応させている
  • セミナーやってるとベロシティのことを知らない人が結構いる
  • 感情的になるほど豊かになるアンサンブルという設計は面白い
  • Q&A: レイテンシは
    • あんまり気にならない、MIDI->ReactorのFINGERはMachineの別の軸(左手)で掛けている
      • Utilityでパン振りのON/OFFをCCで切り替えている
    • Reactor FINGERはlooperというよりはglitch
  • ミュートはMachineの液晶の上のボタンでミキサーOUTのON/OFFをMIDIマッピング
  • 左上のキーで全ミュートにしているのはMasterに挟んだUtilityのON/OFFでマッピング
  • マッピングAbletonのプロジェクトを横断してパートごとに呼び出せる、プロジェクト内のMIDIごと持ってこれる

実験音楽Ableton Liveの親和性 〜Ableton Liveはなんでも許してくれる〜

  • 岡崎ぜったろう
    • 普段はWebデザイナー
    • ライブペインティングで映像と音楽の融合
    • 2歳になる子供の、いらなくなったおもちゃに配線したり
    • 西荻窪
  • mammoth
  • セットアップ、Live周りだけ
    • 素人の集まりでもなんとか動く、というのでAbletonに行き着きました
    • ドラムはじめ、作りこんできたエリア
    • シンセ鳴らすコーナー
      • ネットで知り合ったキケンな人にに改造してもらったMIDIで動くファミコン実機のサンプリング
    • フィールドレコーディングコーナー
      • 子育てしてる間に録った
    • フィンガードラムコーナー
      • 人差し指で...
    • マイクin
    • KORG nanoKontrol
      • 一人一つずつ、みんなでエフェクトを共有する
      • こんなことやってるのでクラッシュしたりします
    • 入力
      • オルゴールを無理矢理ピエゾマイクで拾ってる
    • 自作のドローンマシン入力
    • あと音響装置としてのミニ四駆
    • ラジカセとカセットテープでDJ
      • 空のカセットスロットでスクラッチ
  • あとは鳴らす
    • MIDIコンでルーパーを共有したり、現場で録音したり
  • Masterに結構刺してます、雑にやってもそれなりにグリッドしたものになってくれるのがよいところ

  • かぶり気味の音を調整、各ラックのエフェクトの操作

  • nanoKontrolの縦フェーダーをトグルスイッチとして使うとか
  • ボタンはすぐに取り出したいエフェクトのトリガに、パンポットにディケイ、ビートリピート、パスフィルタなど
    • これらのグリッチはすべてMasterに挿している
  • 各人ヘッドホン無し、モニタはあえて捨てて迷子になりに行ってる感じ
  • 構成はこういうジャンル(ノイズとか)はだいたい即興(インプロ)、我々楽譜も読めない
    • ただ展開だけはなんとなく組んでいて、矩形波の一番とかアンビエントの位置とかはなんとなくExcelで作ってシェアしている
  • エフェクタ共有はそれぞれの楽器に対して
  • アナログシンセ、USB経由でMIDIを飛ばして鳴らすこともあればエフェクターのようにシグナルやCVごと流す
    • ダレたときにこれみよがしにパッチングしたりしてます
  • ドローンの音は作り方は我々もよくわかってないままいい感じになった時に残してってます
    • 奇跡の集積です

Stemを使ったライブセットの構築/演奏

  • Josh Bess
    • 日本で6人目のAbleton認定トレーナー
    • ニューヨークでドラマー、パーカッショニストからAbleton認定トレーナーに
    • 渋谷に引っ越してきました
    • DubSpotのトレーナーも歴任
  • How to bring original studio music to live stage performance
  • Stem
    • 個別のトラック
    • ドラム、ベース、リズム、リード、ボーカル....
  • Full Song
    • すべてのトラック
  • ライブの時は両方使う
  • Stemsを書き出すときには「選択しているトラックのみ」出力するように
  • トラックをタイムラインに並べる
  • タイムライン側(アレンジメントビュー)でキューポイントを設置して、セッションビューでポイントをもとに展開を制御
  • アレンジメントビューですべて選択して、ドラッグしながらTabでセッションに持ち込み
  • 展開ごとの各パートのStemを時間×パートで自在に組み合わせられるように
  • 2つのプロジェクトを同じセッションに斜めに並べて、各パーツを混在させられる
  • Q&A: 前に出てくる音はどうやって作る?
    • 使う音を選ぶ
    • トランジェントをパキッと合わせる、タイミング重要
    • 一斉に鳴るか
  • 音源としてはexportするので途中から全部audioになります
    • まずはエフェクト無しのMIDIで並べる
    • プラグイン普段はは使ってない、ミックスダウンの時は使うが重いのでfreezeしてからもう一度バランスをとる
      • なのでミックスダウンは2回
      • freeze前に戻りたくなったことはない
    • マスタリングは他の人にお願いしている、自分でMasterトラックに挟んだりはしていない
    • Stemと既存の曲でプレ/ポストマスタリングで音量に差が出ているので調整またはMasterにリミッター
    • マスタリング前は歪まないようにMaster-12~-6dBくらいで保つ、作っている時もミックスするときもバランスは常に保つ
  • Q: サイドチェインのかかってる音はどうやってfreezeする?
    • I never used.
    • サイドチェインは使わない
      • ユーティリティで人力でエンベロープを描いている
      • キック起因のサイドチェインはキックとの対応しかできない、自力で描けばいくらでも表情の調整ができる
  • freezeしてフラット化すれば音がまとまる
  • Q: 曲同士のキーを揃えるには?
    • DJプレイと同じく、キックから出して入れ替え
    • クリップの末尾にキー書きますよね
  • Q: コントローラは?
    • 普段はPush、今はキーボードとマウス
    • キーボードのMIDIマッピングでもわりといける