べにやまぶろぐ

技術寄りの話を書くつもり

Intel Edison Breakout Board Kit で遊んでみる(その1)

薄々気になってた Intel Edison を入手したので遊んでみます。

とはいえ参考にさせていただいた SDカードサイズの極小コンピューター、「Intel Edison」を手に入れた – PSYENCE:MEDIA にもっと詳しく書いてあるのでほぼ備忘録です。

今回は Amazon からポチッと。

Intel Edison Breakout Board Kit
Intel
売り上げランキング: 37,402

Edison はそのサイズもあって開発にはピッチサイズ変換用の拡張用ボードが必要です。Intel 謹製の拡張用ボードには Breakout BoardArduino 互換のものがあるようですが(2014/11/17 現在)、とりあえず在庫があったので Breakout Board を購入してみました。Arduino 互換の方が数あるシールドと簡単につなげそうではあります。

梱包を解いたのがこれ。

f:id:beniyama:20141117235349p:plain

USB ケーブルは付属していないので注意が必要です。梱包物は Edison と拡張用ボード、それとマウントして止めるための金具が付いているだけ。USB ケーブルの口は二つありますが、片方は OTG でもう片方はシリアル通信用ということでとりあえずは一本でも大丈夫。

f:id:beniyama:20141117235359p:plain

箱も小さいです。

最初、さーてどうしよっかと公式サイト見て回ってたんですが https://communities.intel.com/docs/DOC-23148 によれば

Note: If you’re using Intel® Edison for the first time, we recommend starting with the Intel® Edison kit for Arduino* expansion board. The following Intel® Edison Getting Started Guide has been written for use with the Arduino expansion board (Edison Arduino expansion board hardware guide_331191-002.pdf). If you are using Intel® Edison for the first time with a different expansion board, please consult documentation provided by the supplier of that expansion board.

とかあって早速 Breakout Board Kit にしたことを後悔しそうになります。

気を取り直して IntelEdisonStartGeneric – スイッチサイエンス を参考にしてまず HoRNDIS をインストールします。*1

その次に USB コネクタを接続して母艦の Mac に接続。一本で繋ぐ場合は "Intel Edison" の文字から見て右下の口につなぎます(ここで右上につないでも電源供給されないのでダメです)。電源供給されると緑色の LED が点灯します。

f:id:beniyama:20141118002812p:plain

"Multifunction Composite Gadget" というインタフェースが現れるのでそこの IP を 192.168.2.2 などとします。

f:id:beniyama:20141118003216p:plain

SSH でパスワードなしの root でログインできます。/etc/version を cat すると焼かれているイメージのバージョンがわかります。

$ ssh root@192.168.2.15
root@edison:~# ls
otp.bin
root@edison:~# cat /etc/version 
edison-weekly_build_56_2014-08-20_15-54-05

ここで Edison のイメージを更新します。https://communities.intel.com/docs/DOC-23242 から最新のビルド済みイメージ(Edison Yocto complete image)をダウンロード。

https://communities.intel.com/docs/DOC-23242

zip を展開して、中身をマウントされている Edison フォルダにコピーします。

f:id:beniyama:20141118004336p:plain

その後 Edison のシェルに戻り

root@edison:~# reboot ota

とすると新しいイメージが焼かれます。しばらく時間がかかりますがここで電源供給が止まったりすると起動しなくなったりする気がするのでしばし辛抱。

自分の場合はネットワークインタフェースもリセットされてしまったのでもう一回プライベート IP を振ってやって known_hosts に一度登録されていた鍵を削除して SSH でつなぎ直しました。

root@edison:~# cat /etc/version 
edison-rel1-maint-weekly_build_16_2014-10-14_14-56-19

アップデートされていることを確認。

その後は

root@edison:~# configure_edison --setup

でホスト名を設定したり Wifi の設定をするだけで

f:id:beniyama:20141118004509p:plain

のようにブラウザからアクセスできるようになります。簡単!

次はなんかセンサーをくっつけてみようと思います。

参考)

*1:Yosemite だったのと最初つなぐとこ間違えてて上手く認識されなかったのでサイトのガイドに従って NetworkInterfaces.plist と preferences.plist を削除したりしましたが必要なかった気もします

『GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望』を公開しました。

先日、10/30 にリリースされました http://pr.gmopdmp.jp/ の開発に当たって取り組んできた DevOps のプラクティスなどについてまとめた資料を Slideshare で公開しました。

資料中にありますようにまだまだ発展途上で今後も取り組んでいきたいこともかなりありますので、技術ネタを交えて継続的に更新していければと思います。

http のリクエストが勝手に https にリダイレクトされるときは Strict-Transport-Security を疑おう

mysite.jp というサイトを運用していて、新たに help.mysite.jp みたいな別サイトをサブドメイン切ってかつ別の Web サーバーで用意したとします。

このサイトはヘルプページがメインなので高額な SSL 証明書をとらず http で良しとしていた…つもりが http://help.mysite.jp へのリクエストが何故か勝手に https://help.mysite.jp にリダイレクトされてしまい挙げ句の果てに証明書のエラーが出てアクセスできない、なんてことがありました。

最初は help.mysite.jp に問題があると思って色々調べていたんですが、実は問題のあったのは mysite.jp の方。mysite.jp はログイン前提のサイトだったのでこんなヘッダを設定していました。

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

この Strict-Transport-Security、Strict-Transport-Security - HTTP | MDN によれば

HTTP Strict Transport Security (よく HSTS と略されます) は、Web サイトがブラウザに対して、HTTP の代わりに HTTPS を用いて通信を行うように伝達することができるセキュリティ機能です。

ということでどうせ https しか許可してないしということで設定していたのですが、このヘッダに includeSubDomains が付いていたために、後から作った help.mysite.jp にも同じポリシーが適用されてしまっていたことが https リダイレクトの原因でした。

ここでのポイントは mysite.jphelp.mysite.jp が違うWeb サーバーで運用されていて、かつ Strict-Transport-Security の設定は mysite.jp にしかされていなかったという点です。

何が起きているかというと、例えばあるユーザーが mysite.jp にアクセスしたとき(1)にサブドメインも対象にした Strict-Transport-Security 入りヘッダが付いたレスポンスを受けます(2)。

f:id:beniyama:20141108224904j:plain

このとき、ブラウザは内部に持っている HSTS 対象のドメインリストに mysite.jp を追加します(3)。ブラウザはこのように HSTS のポリシーを持っているドメインをキャッシュして、次につなぎにいく際は内部的にリクエストを https に書き換えます。これは、内部で処理を行うことで極力(脆弱な) http でつなぎにいくのを避ける目的があります。

今回のケースでは includeSubDomains でサブドメインも対象になっていましたので、次に HSTS ヘッダ無しで運用されている http://help.mysite.jp にアクセスしようとした際もブラウザ内のキャッシュ(HSTS リスト)が効いて https://help.mysite.jp に向いてしまうのでした(4)。

ユーザーが mysite.jp を訪れずに直接 help.mysite.jp にアクセスした場合は当然 HSTS 対象のドメインとして認識されていませんから問題なく http でサイトを表示することが可能です。

結局はブラウザ側でなされている脆弱性対応なのですが、最初に接続しにいって HSTS ポリシーを受け取るまではドメインが https を強制しているかわからず http でのやりとりになる可能性があります。また HSTS には max-age というオプションがありブラウザが HSTS ポリシーをキャッシュする期間を設定することができるのですが、あまり頻繁にキャッシュアウトするような短い期間を設定してしまうとその度に http でつなぎにいってしまう可能性がありますので、十分長い期間を設定することが推奨されているようです(max-age はサイトにアクセスするたびに更新され期限は延びます)。

今回の問題は、ブラウザが持つ HSTS リストに依るのでユーザー毎に挙動が違う、また外部サイト(この場合は mysite.jp )の設定に影響を受けていたという点でちょっと厄介だったかなと思います。

教訓としては、

Strict-Transport-Security を includeSubDomains 付きで設定するときは既存のサブドメイン全てのセキュリティポリシーを確認しましょう

というのと、

新たにサブドメイン切るときもそのルートドメインで includeSubDomains 付き Strict-Transport-Security を設定していないか確認しましょう

ということでしょうか。

ちなみに、Chrome などでは preloaded list として予めいくつかのドメインを HSTS リストに持っているようです。またユーザーが自分でドメインを HSTS リストに追加することもできますが、長くなってしまったのでそれはブラウザ間の挙動の違いと一緒にまた次回書こうと思います。

参考)

『プライベートDMPセミナー~1.7歩先を行く、新マーケティング戦略~』聴講メモ

マイナビさん主催のアドテクセミナー 『http://news.mynavi.jp/ad/2014/enterprise/talend_dmp/ 』に参加してきました。

http://news.mynavi.jp/ad/2014/enterprise/talend_dmp/

DMPで求められるリアルタイムなデータ処理で競合他社と差をつける! | TECH+』 に Spark の話があったのでそれを楽しみにして行ったのですが、特に Spark に関するお話はありませんでした。一方、ゴルフダイジェストオンラインさんのお話が非常によくまとまっており、参考になりました。

以下、聴講メモです。

株式会社ゴルフダイジェストオンライン 福永和洋 氏
  • 事業内容はゴルフ場予約サービス、ゴルフ用品販売 (EC)、メディア(ゴルフニュースなど)、レッスンの四事業
  • 140億円の売り上げ規模、250万人の会員
  • DMP とは
    • サイトアクセスデータ
    • CRM データ(顧客、POS、来店)
    • 広告配信結果
    • ペイドメディアデータ
    • ソーシャルメディア
    • オフライン(Ponta)データ
  • トリプルメディアの中央に位置する
    • ペイドメディア(広告配信結果、サイト閲覧情報)
    • オウンドメディア(自社データ)
    • アーンドメディア(ソーシャルメディアでの登録・行動情報)
    • さらにリアル店舗での入店、購買行動データ
      • Ponta カードでゴルフ場への来場履歴や購買履歴がとれる
      • アクアラインを使ってゴルフ場に来たとすると使用した分のボール購入をスマホ広告としてレコメンドするなど
  • DMP (Rtoaster Ads) 導入背景
    • 96年頃からウェブ広告をずっと使ってきて、現在は Google ダイナミックリマーケ / Criteo などを使っている
    • さっき見た商品が全然違うドメインで出たりして気持ち悪い、という調査結果がある
      • 成果は出ているが、企業ブランディングとしては疑問符
      • DMP を活用してパーソナライズされた広告を打てるようにしたかった
        • ちょっと期間を置いて未来訪のユーザーに広告を出す
        • 同じ CV であっても粗利が高いものをレコメンドしたほうが CPA が同じでも利益につながるのでそこをコントロールしたい
  • 内容 x 頻度 x タイミングがパーソナライズ化された広告を配信したい
    • 現状の広告でもできるが、トリッキーな運用になってしまう
  • 従来のリタゲとは企業内に蓄積されている顧客データをセグメントとして使用できる点が違う
  • メルマガ経由の売り上げが 30 - 40% あるので(メルマガを)止められない。
    • メルマガ登録に誘導するために購読しているかないかで訴求方法を変える
    • データマイニング
      • 離反傾向の分析をしてリテンション広告を打つ
      • 購買予兆の検知、大学の?研究室と共同研究をしており 70% の精度で捉えられたりしている
  • Rtoaster に入れる前の環境
    • ゴルフのスコアも蓄積してデモグラフィック以上のデータ(ラウンド回数、上手さなど)も蓄積している
    • レスポンシス(パーソナライズドメールシステム)でも使っている
    • Web サイトログについては訪問間隔・訪問度合いなども計算してから DMP に入れている
    • キャンペーンの原資を活用するために顧客ランクを分析している
    • 累積購入回数を年度別に分けて活用している
      • 去年10回の購入実績があって半期回って5回以下の人にはクーポン出したりしている
      • 去年の優良顧客が今年も継続して優良であるような施策
    • 商品データの中には粗利データも含まれている
    • DMP に入れる前が勝負、どういったデータを何に使いたいか
      • 前段に Hadoop/BI の環境を持って処理してから DMP に渡している
      • データクレンジング・クリーニング以上にカスタマイズする
  • DMP の効果
    • ロイヤルユーザリピート施策
    • ラウンド予定者購入促進施策
      • ゴルフ予約している人が実際にプレイする前に、商品を配送可能な期間内のみ広告を出している
      • 会員の半分が一回購買、その中でも半数が一年後に離脱
    • 初回顧客獲得施策
      • 購入から配送まで全て GDO でできるので、それを実体験として感じてもらうために初回購入を促す施策を打っている
    • 複数の条件かけあわせ・タイミングの演算がこれまでの広告ではできなかったところ
    • グラフ図中の赤い棒が CV 数
    • 無駄なメディア・ホワイトリスト・ブラックリストの調整でリスティングの CPA を下回るくらいでの成果は出せている
      • 質も良いし効率的にとれる
    • メルマガのインセンティブ
      • 10,000人の中の 1,000 人に対して 500円プレゼントとすると効率的にインセンティブを配信できる
      • 見込みのある人だけに配信することで一人当たりのインセンティブ額を上げられる
  • 今後の展望
    • 質はとれるけど量がとれないという問題はある
    • メールでやっていたステップアップメールなどのマーケティングシナリオを DMP でも活用したい
    • 未来訪ユーザーの引き込みをしないと質・量とれるようにはなっていかない
      • データセラー型 DMP を導入していきたい
株式会社 アドクラウド(スペイシーズ) 室園 拓也 氏
  • プライベート DMP を日本で初めて作った会社
  • 経産省でパーソナルデータを扱うお墨付き(ベストプラクティス)をもらっている
    • cookie が実際だれなのか後から辿れないようになっている?
  • KUDAN (妖怪)
  • 1st party と類推の 3rd party、競合の CRM データを使う 2nd party という区分はどうか?
  • Wappalyzer を使うとサイトで使われているアクセス解析ツールがわかる
  • GA は dimension と metrics が肝
    • ディメンション(属性軸:緑)
    • メトリクス(数値軸:青)
    • アフィニティカテゴリ(類似カテゴリ)
    • セグメント
      • デフォルトセット
      • 類似カテゴリ
      • ユーザ単位
      • セッション単位
      • コホート分析
      • シーケンス分析
        • ユーザーの行動の流れを定義できる
  • オウンドメディアの分析だけなら GA 最高
    • GA 周辺でしか使えない、AdWords のリマケ
    • GA プレミアムにすると DSP (Doubleclick Bid Manager) に連携できたりするが 1,000万円/年
  • KUDAN は月額30万円
    • DMP は多様なデータを cookie に変換
    • CRM の顧客属性データとの統合
    • 複数オウンドメディア間でのユーザー統合
      • サイト A B C でばらばらの ID
      • 3rd party cookie に保持しているものを 1st party cookie に書き出すことができる
    • 他の DMP とのセグメント交換(売買)
      • ハブをやっている(人材会社 to 人材会社 : ○○という職業の人を探したい、というとき片側の DMP の該当セグメントの cookie を渡し、DSP から配信して CPA が半分になった)
      • サービス立ち上げ時にユーザを限定して広告を打ちたい
    • 30種類以上の DSP への連携配信
      • 依頼ベースで接続先を増やす
    • GA へのセグメント連携
    • LPO ツールへのセグメント連携
  • メール配信時に DMP でユーザーを認知する仕組みがある。CRM で管理している軸を追加できたりする。
  • GA で切ったセグメントと DMP を掛け合わせる(GA セグメントをインポート)
  • 解析ツールへのセグメント連携(GA へのインポート)
  • Clicktale / Ptengine という heatmap ツールとかけあわせてセグメントごとに可視化する。
  • オウンドメディアの自社軸によるオーディエンス分類 (自社メディアで管理している顧客に対して能動的な分類が可能に)
  • クロスサイトトラッキング(複数オウンドメディアにまたがる顧客を把握し、施策につなげる)
Talend 株式会社 寺澤 慎祐 氏
  • 2005 年にフランスで二人のエンジニアが創業
  • OSS / Apache ライセンス
    • 2,000万 DL
    • 100万ユーザー
    • 4,500社に導入されている
      • Citibank DHL ebay Bank of America など
      • GE の旅客機を飛ばして数TBのデータを取得し、フライト状況を分析したりしている
    • Amazon はサービス開始から 44 回値下げしてきている、ストレージが増大した
  • 本日の販売状況から将来の製造数を知る
    • 処理タイミング:デイリー
    • 処理時間:8時間 = 対応は翌日
    • Hadoop を使った場合、処理時間:20分 = 対応は当日
    • 過去と今のデータでちょっと先の将来を予測できないか
  • 800 コンポーネント(Pinterest の数を数える等)、ネイティブ稼働、自動化するためシステムに組み込み
  • Talend Studio
    • Eclipse で GUI ツールを動かす。データの収集・整備・変換・統合を設計するツール
    • デプロイされた JAR ファイルや処理を管理するツール Talend Administration Center
    • 自動生成されたジョブは hadoop 上で稼働する (M/R)
    • 開発者は Talend Studio だけの習得だけで大丈夫
      • basho / cassandra / mongoDB / cloudera / Pivotal / Hive / Spark...
      •  M/R 書けるエンジニアは 人月 300 万円?
      • Talend の使用料は 200万円 / 年

sudoers の NOPASSWD コマンド指定は絶対パスで!

以前、Capistrano でデプロイした後に PHP-FPM 再起動したりしたいときはコマンド限定でノーパス sudo 許可するのも悪くないかも - べにやまぶろぐ という記事の中で /etc/sudoers に

php_app_user  ALL=(ALL) NOPASSWD: /etc/init.d/php-fpm

と書くと php_app_user ユーザーは /etc/init.d/php-fpm コマンドをパスワードなしの root 権限で実行できると書いたんですが、コマンドによって visudo のパースエラーになってしまうことがあり困っていました。

何が原因かしばらくわからなかったのですが、

php_app_user  ALL=(ALL) NOPASSWD: /etc/init.d/php-fpm, make

と書くとダメで

php_app_user  ALL=(ALL) NOPASSWD: /etc/init.d/php-fpm, /usr/bin/make

とすると大丈夫なことに気づきました。どうも相対パスではなく絶対パスでないとダメなようです。

下記の記事、

のコメント中に

You should specify the absolute path in the first example, for security reasons -- an unscrupulous user could change $PATH and steal root access with an unqualified command name.

とあるように、確かに相対パスのコマンド指定だと sudo 昇格を許可していない同名のコマンドを実行できてしまいますね。一つ勉強になりました。

参考)

『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 出版記念!執筆者が語る大講演会!』 聴講メモ

今日は表題の通り下記イベントに参加してきました。

http://eventdots.jp/event/137658

以下、個人的に響いたところ中心に聴講メモです。

『サービス改善はログデータ解析から』鈴木 健太氏

  • adingo 社で DMP 構築、R&D を担当されている
  • EFK スタック (ElasticSearch / Fluentd / Kibana) という言葉があるらしい
  • 広告ログの分析を行っている
    • どんなユーザー・枠に広告を出したか、キャンペーン、効果が高かった広告、 CV までの過程
  • 配信サービスの設計と配信サービスのデータは表裏一体
  • 配信、結果の分析、再度配信… 一人ではできない
    • 実際は案件をとってきたり、アナリストがいたり、手を変えるエンジニアがいたりする
  • データの分析はチームで作るもの、活かせるようにするエンジニアが必要
  • 収集、変換、保存、分析、表示、適用というステップ(書籍『分析力を武器とする企業』より)
  • ログの分析は後にして他の機能追加しましょうという話になりがち、だけどログ解析をとりあえず試してみるべき
  • 分析する対象が最初から決まっていなくても可視化してから考えてみる
    • サーバのレスポンスが遅くなっている処理を可視化してみて15分おきに重くなっていることがわかった
  • 分析を武器にする仕組みをつくろう
  • 長く分析の価値を提供する基盤が必要
    • 『分析の価値』= 意思決定への寄与度 x 意思決定の重要性
    • 分析基盤を作るときに考えるべきこと = 継続性

『Fluentd構成のお勧めデザインパターン』吉田 健太郎氏

  • リブセンスで web エンジニアをされている
  • 実用性のある Fluentd プラグインを読みあさって養成読本第5章で逆引きリストを作ったのがおすすめ
  • log ディレクトリを踏み台サーバーに NFS マウントして読み出すなどという運用形態があった
  • Fluentd は構造化された LTSV (Labeled Tab-separated Values) 形式で出力することで awk の処理がやりやすくなる
  • これまで集めて終わっていたログが今はリアルタイム分析などに活用できる
  • Fluentd が適さないところ
    • Exactly Once を必要とする処理(Fluentd は At Most Once)
    • CPU コア一つでさばけない処理
    • ビジネスロジックが日々変化する場合
      • 扱いやすい形式で集約するところまでが Fluentd の処理範囲
      • メトリクス収集を超えた死活監視システムとしてに利用
  • 安定運用する上で意識したいこと
    • 各ノードは単一責任とすることでシンプルな構成にする
    • Aggregator で集約する
    • バッファした後にフィルタ処理するなど

『elasticsearch、もうちょっと入門』大谷 純 氏

  • ElasticSearch 社で働いている
  • ElasticSearch では検索だけでなくハイライト・集計・ソート・ページング・サジェストなどの機能を提供できる
  • ElasticSearch は Java で書かれている
  • ElasticSearch では(EFK で言うところの Fluentd にあたる) Logstash という製品を売っている (ELK スタック)

『Kibanaではじめるダッシュボード』道井 俊介氏

  • pixiv でインフラエンジニアをされている
  • 平均17回/日デプロイ
  • グロースチーム
    • サービスのグロースのためなら何でもやる
    • 様々な施策の検証のためにログを使用している
    • どのようなイラストが閲覧されているかなどを分析
  • 開発チーム
    • 可視化は継続的デリバリーの手段
    • 機能をリリースしたときにテストすることと一緒
  • 社内で Fluentd x MongoDB で可視化ツールをつくって決まった値を出し続けていた
  • ふと Kibana を使い始めた
  • 見たい数値が1画面に収まっているのがダッシュボード
    • 一つのデータに対して複数の面から分析する
    • 毎日毎週継続して変化を見ることが出来る
    • 一つの画面だけ見れば良い
      • スタンプ機能追加の際につくられた機能で、スタンプの利用状況やコメントの状況を可視化した
  • デプロイスクリプトを工夫することでデプロイしたタイミングを記録してグラフに表示できる
  • URL を生成して share できる
  • Google Big Query と Jenkins を連携させて集計させておくこともできる
    • Big Query は Tableau のバックエンドにもなる

特別パネルディスカッション (モデレーター 伊藤 直也 氏)

  • ログ解析は現在大きく分けて二つ
    • システムモニタリング
    • ビジネス要件寄りのグロースハックのための可視化
  • 昔はログを吸い上げるよりアプリから直接 DB にログ入れてた
  • 昔からあった DWH はどうするのか
    • DWH は正規化しないイメージ
  • scheme-on-write から scheme-on-read へ: 入れるときではなく読むときにスキーマを決める時代
  • 『ログエンジニア』が出現するかもしれない
  • Developer productivity という言葉がある
  • ログ解析ベースだと非連続な変化を起こしづらい
  • 真実だったとしても『数値化できていなかった』だけで意思決定から外れてしまう懸念
    • 数字を追いすぎてわからなくなることがある
    • 数字がないと議論すらできない風潮があるのではないか
  • A/B は適当にやると罠に落ちるからそこを注意しましょうというコンサル込みで売っている(PlanBCD)
  • Pixiv の ElasticSearch は2台
  • BigQuery は何秒か待たないといけない感じで使い勝手に多少の難

個人的には ElasticSearch 社の製品、とくに Free and Open Search: The Creators of Elasticsearch, ELK & Kibana | Elastic は全く知らなかったのでこれ OSS で使えるんなら世の中の KPI ツールはとりあえずデータつっこんでこれで見てみてあーだこーだ言えばいいんじゃなくてという気分になったりして何となく Tableau のデモ見たときと同じような心地になりました。カスタマイズできるダッシュボード、デプロイのタイミングも KPI に重ねられたり、URL シェアできたりいろいろ便利そうです。

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)
鈴木 健太 吉田 健太郎 大谷 純 道井 俊介
技術評論社
売り上げランキング: 7,058