あべさんじゅうきゅうさいのおしらせ
このネタ使えるのも今年が最後ですね。来年は不惑でございます。誰だよ、40にして迷わずとか言ったやつは。
ともあれ、こんな歳になってもまだまだ新しい仕事に挑戦して刺激の強い日々を送れているというのは嬉しいことです。適性はともかくとして、自分が一番楽しいポジションを見つけることができたので、これからしばらくはこの方向性で頑張ってみようかと思います。これまでと変わらぬお付き合いをいただけるとありがたいです。
というわけで、いつものリスト載せておきますね。
Docker for Macのホストについて誤解を修正したのでメモ
rocker/rstudioを動かしていた時に、DockerfileのVOLUME指定がどこにマウントされてるのかなあ、と疑問になって誤解していたのに気付きました。
普通に立ち上げたrstudioのコンテナに対して docker inspect
叩くとマウントはこんな感じになります(抜粋)。
"Mounts": [ { "Name": "03ea6111736ad40a69f279c6cba05b5ebfc50c0454e612521766b019b5efbb0e", "Source": "/var/lib/docker/volumes/03ea6111736ad40a69f279c6cba05b5ebfc50c0454e612521766b019b5efbb0e/_data", "Destination": "/home/rstudio", "Driver": "local", "Mode": "", "RW": true, "Propagation": "" } ],
で、ローカルの /var/lib/docker/volumes/
とかないんですね。
Docker for Macのホストは(厳密には)ローカルマシンではない
ちゃんとリリースノート読めよ、という感じなのですが、docker-machineでも管理下のホストがないことになってるし、linuxで使うときと同じようにネイティブで動くホストだと思ってたんですよね。だからVOLUMEでマウントされるのもローカルにそのままパスがあるところなのかと思っていました。
Docker for MacはxhyveというOS Xのネイティブハイパーバイザーでlinuxを仮想化したホストで動いています。とりあえずVirtualBoxからは脱却してますが、完全にネイティブではなく一つ仮想環境が挟まってる状態は同じなんですね。ここ、完全にネイティブだと勘違いしていました。私のちょっと時代遅れのマシンでもある程度サクサク動いてくれるので、パフォーマンスは向上してるとは思います。
このブログを参考にしてホスト環境にアクセスしてみたところ、VOLUMEでマウントされているディレクトリを確認できました。
ちなみに、KitematicではNo folder扱いです。これは、ホストの環境はあくまで一時的なものだからな?ということなのでしょうかね。永続化するデータはちゃんとコンテナ動かす時にマウントしておきましょう、という話。
デブサミ関西に行ってきました
もうすっかり恒例になりましたね。昼飯難民になりやすい場所も時期も。神戸という距離感も参加しやすさという意味ではありがたいところ。
参加したセッション
- キーノート(鈴木さん)
- 【A1】正しいものを正しく作る(市谷さん)
- 【B2】企業向けクラウドサービスの開発・運用(三苫さん)
- 【B3】ビジネスにおける機械学習の現場(木虎さん)
- 【B5】カイゼンの基本(吉羽さん)
キーノートは、駐車場探しに手間取ってしまったため15分ほど遅れて入りました。
【B5】はちょっと帰りの時間と体力的に嫌な予感がしたのと、自分の活動を資料と照らし合わせて比較ができそうなのを最初の15分ほどで確認して退出しています。
セッション資料
私が参加していないセッション資料も含めてまとめてくださっている方がいますね。
デブサミ関西2016 スライドまとめ84zume.wordpress.com
感想
最近はこういう場で「遅れないようにしないと」とか「どこか別の世界線の話」と思うより、「ああ、こんなやり方があるんだ」と比較しながら聴くことができるようになっているのを感じます。まあ、やりたいことがやれてきて悩みどころが追いついているというか、今の現場はそういう意味では幸せです。
各セッションごとの感想を軽めに。
キーノート
これ、大都会でやるとポカーン枠って言われるやつや。。。
ちなみに、ブルーグリーンデプロイメントって名前知ったのはこのセッションよりも少し前、どんなデプロイメントかはこのセッションで正しく把握したんですが、MallNaviでは似たような取り組みをしてました。だって、シフト勤務せずにダウンタイム設けずにリリースしたかったんですもの。ElasticBeanstalkさまさま。
とりあえず、自分の開発/運用の頭が2011年以降にはあるということで少しホッとはしました。MSAはとりあえず概要をおさらいくらいはしておきたいですね。
正しいものを正しく作る
これはまあ、今やっていることの課題を共有するというか、考えを整理するために聴いています。仕事面ではギルドワークスさんはだいぶ参考にさせてもらっているので。特にBtoCサービスのオーナーやっているとですね、オーナーもいつまでたっても不安なんですよ。これからも問いに関しては真摯であろうと思いました。
それにしても、早口だった。。。
企業向けクラウドサービスの開発・運用
そもそも資料に載ってる全部がセッションで収まりきらないこと前提という。。。パターンっぽくまとめていただいていたので、資料公開を待ちましょう。
基盤で解決できるところもあり、力技しかないところもあり、ではあるのですが課題はやはりどこも共通していると思います。許容されるレベルが現場によっては異なるくらいかなあ。自分たちの現場はどういう解決、アプローチをしているかを比較しながら聴けたので良かったです。「ゴールが未設定のチューニングタスク」は反省しました。
ビジネスにおける機械学習の現場
これも事例が収まりませんでしたね。本編が盛りだくさんでした。
ちょうど、そろそろデータ分析自体は自分のスキルとして強化しないといけないな、と思い始めていて、買うつもりなかった本なんかも買ってしまっているわけです。
買ってしまった pic.twitter.com/6xoLQnqgOk
— あべさん (@mao_instantlife) 2016年9月16日
完全に「お前何やりたいんだ」な領域に足突っ込んでる気はしますが、人数少ないですからレベルが低くても誰かが兼務するしかないですよね。本読んでからおさらいしたほうがいい内容でした。
カイゼンの基本
予想通りといえば予想通りな内容。そのレベルが高いところにある、という感じで。
とりあえずバリューストリームマップについてはちゃんと押さえていなかったので、干し芋に入れておきました。 そろそろさんじゅうきゅうさいなので、皆様からの 投げ込み をお待ちしています。 春の大カイゼン運動とか、某社の某取り組みを彷彿とさせて素敵ですね(棒。
おまけ
今回は、ちょっと車で行くのが現実的かどうか試してみました。
行きはバイパスの有料区間を積極的に使って3h、焦ったのはむしろ駐車場探しの方でした。細かい位置関係などはやはり行ってみないとわかりませんし。
ひどかったのは帰りで、なるべく有料区間を使わずにと思って帰ってみたらなんと5hも。渋滞と信号の間の悪さのコンボが効いた感じですね。
まあ、二人以上だったらバスよりも安くは済みそう。
後、珈琲博物館に嫁と行きたいです。
Embulkで検証中に引っかかったことメモ
前回、こんな感じでRe:dashよりも先にやることがあるだろう、と気づいたわけです。
mao-instantlife.hatenablog.com
というわけでEmbulkで各種データソースの読み込みから始めています。
Embulkとは?
バルクデータローダーです。inputとoutputの形式が各種プラグインで提供されていて *1 、対応可能なストレージの種類が多いのが特長です。
他にも公式サイトのアピールとしては、
などありますが、後者二つはまだ試していません。
いつものごとく、公式ドキュメント見れば事足りるインストールやセットアップは割愛。最近はこの辺で試行錯誤して環境による注意事項書かなきゃいけないようなツールが減ってきましたね、いいことです。
覚えておきたいサブコマンド
- example
- guess
- preview
- run
- gem
- mkbundle
プラグインはグローバルなインストールだけではなくて、プロジェクトごとにGemfileつくってバンドルすることもできるようですね。実行環境をテキストで管理できるのは、作る上では嬉しいことです。
exampleはその名の通り、とりあえずローカル実行可能なデモ用の設定ファイルをつくってくれます。試すのにもデータソース作らないといけないの面倒臭いとかそういうニーズがあるんでしょうね、きっと。
guessが入力ファイルフォーマットの自動で、推測した結果を完全な設定ファイルにして出力してくれます(基本は標準出力?)。が、Elasticsearch用のものなどプラグインによっては未対応のものもあるので、全面的に頼れるわけではないようです。
見つけたプラグイン
- MySQL
- Elasticsearch
- Google Analytics
MySQLのGEOMETRYタイプ問題
Unsupportedですよ、と。
それはそれでいいんですが、エラーメッセージに column_options
に type: string
を追加しろと言ってる割には追加してもエラーで変わらず。エラーメッセージの間違いだったようです。
で、対応するにはクエリでキャストするなりの工夫が必要です。
まあ、今回は無理してGEOMETRYタイプを使わなくてもいい案件だったので素直に検索対象から外すことにしました。
Google Analytics APIが有効にならない問題
以下の流れで追加したユーザの認証キーを突っ込んで実行してみたんですがね。。。
Error: forbidden: Google Analytics Reporting API has not been used in project mallnavi-1352 before or it is disabled.
はあ、そうですか。。。APIのリクエストにはカウントされてるし、ちょっとよく分からない。
迂回路は幾つかありそうですし、となると優先順位は全体像を作ることなので、とりあえず放っておくことにして、digdagとEmbulkを組み合わせてみようかと思います。
データ分析環境を作りかけのメモ
一度リリースしたサービスを成長させるんだったら実際の各種データを元に仮説を立てて検証したいところ。アクセスログやアプリケーションデータやGoogle Analyticsの分析データなど、運用時に種々のデータが蓄積されていきます。それぞれでも有用なデータなわけですが、バラバラなままでは活用が難しいこともあります。データは繋いで使ってこそ、意味がある。
というわけで、データ分析環境をどうやって作るか考えて、ここ数週間、要件を書く合間を縫って検証してきた内容と気づきをまとめます。
想定されるデータソース
現状、扱っているデータソース(Analyticsをデータソースと言っちゃうのはあれですが)は以下三つ。
- MySQL(アプリケーションデータ)
- Elasticsearch(アクセスログ)
- Google Analytics(アクセス解析)
そして、導入を検討しているものとして
- Neo4j
があります *1 。
Re:dash
とにかく異なるデータソースをつなぐ環境が欲しい、というわけでRe:dashの導入を検討しました。
Re:dashは様々なデータソースをまとめてSQLでクエリを書いてビジュアライズできるソフトウェアです *2 。
どうも、クエリの結果はRe:dash側にスナップショットをとってる感じがするので、ビューをつくってグラフやなんかでデータを表示させるためのフロントエンドという操作感。Elasticsearchにおけるkibanaのような位置付けで、もっと多くのデータソースに対応できる、というイメージでいいかと思います。
インストールやセットアップなどは公式ドキュメント通りにできたので割愛します。Docker上に環境作れるのはいいですね。
対応していないデータソースへの対応
結構な数のデータソースに対応しているんですが、それでもまだ対応していないものがあります。今回の検証に関わるところだと、
- Neo4j
- Google Analytics
の二つ。
このような場合に検討するのは、
- 無理くりロードするクエリランナを書く
- 対応しているデータソースにインポートしてから読み込む
のどちらか、ですね。まず最初は前者を検討してみることにしました。
Pythonクエリランナ
このような未対応データソースへの対応なのかどうかわかりませんが、Pythonクエリランなというのがあります。
Supported Data Sources — Re:dash documentation
なんか、100%セキュアな状態で使ってね、とか怖いこと書いてますが、ローカルでDockerイメージ立ち上げて検証する分には問題ないでしょう。
実際のPythonでのクエリのイメージはここを読んでみてください。
他のクエリ結果の取得ができるようですね。 ドキュメントに記載がなかったのでソース見てみましたが、提供されているAPIはこの辺っぽいです。
get_query_resultの引数がidだけなので、パラメータありのクエリは無理?
Neo4jのクエリを書いてみる
注意:結局できなかったのと、やりながら重要なことに気づいてしまったので中途半端に終わります
Neo4jはPythonのライブラリがあります。というわけで、クエリを書いてみようと思いました。やってみたことは以下。
- Neo4jのPythonライブラリをインストールしたRe:dashイメージを作る(イメージのビルドとrunは成功)
- クエリを書いて実行
クエリはこんな感じです。
from neo4j.v1 import GraphDatabase, basic_auth driver = GraphDatabase.driver("bolt://localhost", auth=basic_auth("neo4j", "neo4j")) session = driver.session() session.run("CREATE (a:Person {name:'Arthur', title:'King'})") result = session.run("MATCH (n:Person) WHERE n.born >= 1970 RETURN n.name AS name, n.born AS born") for record in result: print("%s %s" % (record["title"], record["name"])) session.close()
これが、どうもライブラリを参照できてないわけです。そもそもPythonクエリランナがどういう参照の仕方をしているかよくわかってないので、pipでインストールするだけでOKなの?とか諸々調査が必要しなきゃいかんかな、と思い始めていたわけですが。。。
ここでふと気づく
で、ここで気づいてしまったわけです。ここまで考えてたことって、本番系を直接データソースとして取り込むやり方の検証なんですよね。何かの拍子にスロークエリ投げてしまったら本番系に影響出してしまう可能性もあるわけです。今更ながらこれはだめじゃん、と。
というわけで、基本的なデータのみ定期的にEmbulkでRedshift突っ込んで読めればいいのでは、ということで今はEmbulkとdigdagの検証に入ってます。この辺が検証終わったらまたRe:dashの検証を再開する予定です。もっと早く気付こう。。。