2012/10/31

「継続的データ解析環境の構築」についてad:tech Tokyo de テック勉強会で発表してきました


昨日から東京国際フォーラムでad:tech Tokyoというイベントが開催されており、その中で開催されたテック勉強会で発表してきました。会場を提供していただいたspacyzの皆様、どうもありがとうございました。また発表を聴きに来てくださった方々、どうもありがとうございました。

内容はJenkinsとHadoopを利用して継続的にデータを解析する環境をつくる方法についてです。やはりデータを解析するために、解析を回しやすい環境を作らなければなりません。データを観察して、なぜそうなっているのかという仮説を立て、実際に計算機を回し、結果を出します。高い成果を上げるには人の頭で考える部分に時間を割かなければなりませんが、Hadoopを利用した解析においては手軽に回す環境をつくるということが実はやや面倒なのではないかと感じています。なので、Jenkinsを利用してそういった作業を効率的にしてみたらどうだろう、と考えたのが発端でした。

今関わっているアプリケーションは全てAWS上で動作しています。発表ではあまりそのへんには触れられなかったのですが、Fabricとbotoを組み合わせてELB以下のEC2インスタンスを取得し、各EC2インスタンスに色々なコマンドを送る、といったことをやっています。そして何より、Elastic MapReduceを如何に気軽に利用できるかという点が肝になってきますが、HiveクエリやMapReduceのJavaアプリケーションの実装後は全てJenkinsに任せることで、実際にHadoop上でジョブが回せるようになっています。Elastic MapReduceでジョブを回すにはS3に配置してelastic-mapreduceコマンドを実行する必要がありますが、やはりそのへんをあまり意識せずに解析ジョブを流すことができるようになったのはとても楽です。各々の細かい資料については参考資料にいろいろ載せてありますので、参照していただけると幸いです。

発表後に「Hiveで解析するときにログの形式とか入ってるデータが変わったらどうするの?」と@katzchangさんから聞かれたのですが、うまく答えられませんでした。今のログの形式は基本的なdelimiterがあれば簡単に解釈できるものと、そうではなくて正規表現マッチが必要なものがあります。後者についてはPythonでmapperを書いて流しこむようにしているのですが、とはいえそもそも何らかのカラムが追加されるなど、ログに入ってくるデータが変更された場合には根本的に何か対応できるかというとそうではなく、やはり運用でカバーする部分が多くなってしまうと思います。僕のところでは異なる形式のログを扱っているところはありますが、そもそもS3のバケットが分かれており、分析対象としても疎だったりするので、あまりそういった場合に直面することがありませんでした。ただカラムを足すような場合にも昔のデータを参照して時系列で一元的に分析したい、という場合は起こると思うので、適切なmapperを実装して、Hiveテーブルのスキーマに流し込めるようにするというのが現実的なところなのかな…と思います。

とはいえ発表できて良かったです。話していて、理解の浅い部分が明確になりました。そもそも発表の発端は@bash0C7さんとの「発表することになったのでよろしくね」「えっ」「えっ」という会話だったりして不思議なものですが、とても良い機会になりました。改めてありがとうございました!

今日もこれからad:tech Tokyoにいってきます。

2012/10/27

美容室での会話

僕は割りと美容室での会話が好きです。大体髪を切りに行くのは休みの日で、大抵どこか楽な気持ちでいるので、会話が弾みます。

今年引っ越してから行きつけだった美容室が遠くなってしまったので、何軒か行っていたのですがどうも馴染まず。しかしやっと最近落ち着いて気軽にいける美容室を見つけました。今日はひさびさに休みらしい休みだったので、そこの美容室にいきました。そこでの話が興味深かったのです。

大抵美容室に行くと仕事の話をします。割りと客層も僕に近いか、若い社会人の方が多いようで、美容師さんはいろいろな業界の話を知っていたりします。気さくな方なのでいろいろな話をしてくれますし、僕もいろいろ話をします。iPad miniとNexus 7とKindleどれがいいんですかねーみたいな話から、そのへんのおいしい飲み屋の話をしたりもします。そんな中で、美容師さんの仕事についての話になりました。エンジニアの海外カンファレンスで参加費2,30万くらいのとかってよくあるんですよ、というような話からのくだりです。

「美容師にも講習があってね、大体高くて5日間で10~15万くらいかな。確かに講習を受けると技術は学べる。けど、実際にお客さんと接している時にそれが使えないとだめなんだよね。そしてその技術はすぐに使えるかって言うと、そうじゃない。お客さんの髪質だったり、頭の形も違うし、その人の雰囲気にあったスタイルにしていかなきゃいけないんだよね。そうやって講師をしてくれる人ってやっぱりすごい人が多いし、実際にすごいんだけど、だからといって講習に行ったからといってその人になれるわけじゃなくて。それよりもこうやって毎日お客さんと接してその人にあったスタイルを自分なりに提供するってことがやっぱり大事なんだよね。」

「そういう意味では毎日がテスト。よく学生の時にテストがやだなぁって言ってたけど、今って毎日が本番なんだよね。今日本番やって、また次の日も本番。だからその日のうちに振り返って、明日の本番に備える。ある意味一番の練習になってるのかもしれないけど、練習っていうかやっぱり全部本番なんだよね。」

まあそうですよね、と言いつつ、やっぱりそういうシビアな環境ってすごいな、と思いました。やっぱりなんだかんだ東京の美容師さんは技術は相対的に見ても高いそうなのですが(ちなみに僕は鈍感なのでそのへんはさっぱりわかりません。)、結局技術があっても自分なりに考えてお客さんにあったもの出さないとだめなんだよね、という話をしました。僕は美容師さんの世界は全然知らないのですが、こう聞いていてやっぱりプロだなあと思うのです。

エンジニアもある意味では毎日本番で。システムは稼働し続けているし、開発も毎日続けている。やっぱりそういう中でサービスのローンチだったりアップデートだったりサーバの移行だったり色々なイベントがあって、そこに向けて淡々とやっていくというスタイルが多いと思います。ただ、なんだか、1日に何人ものお客さんと常に1対1で対応して、毎日それを続けていくというのはすごいことだな、と思ったのです。

最近は毎日仕事にとりかかる時に「何を進めるか」を考え、そして「何が進んだか」を確かめるようにしていました。将来的になりたいエンジニア像が漠然とあって、そこに向かっていくように毎日のタスクをこなしつつ、学ぶ方向性を決めるということを毎日意識するようにしています。でも、毎日が本番という気持ちで向かっていたかと決してそんなことはなくて、かなり波があるというのも事実です。

自分は本当にプロと言い切れるのかな、と感じた時間でした。

2012/10/20

大きなシステムのアーキテクチャを自分の頭で考える。

今日からインターン、Sunriseがスタートしました。

大規模サービス構築プログラム「Sunrise」|VOYAGE GROUP インターンシップ ~ミチをソウゾウせよ~ https://voyagegroup.com/internship/sunrise/

Sunriseはその名の通り、大規模サービス構築をテーマとしたインターンです。内容としてもサービスのインフラに主眼をおいています。内容の目安としては100万人を超えるサービスのインフラをどのように構築するか、といったところが焦点となってきます。普段アプリケーションを開発している子たち向けに、どのような考えでインフラを作っているか、という話を中心に展開しています。

実際にインターンが始まって、こうして参加者の子たちと実際に話していると、ああインターンが始まったのだなぁという実感が湧いてきます。今日の朝は@makogaさんによるワークから始まり、手を動かしながら実際にシステムを計測を行うところから進んで行きました。みんななかなか慣れていない作業に最初は困惑しつつも、徐々に慣れていって考察を深めていったのはさすがだなぁと思ってみていました。

今回は僕もSunriseに講師として参加することになり、早速今日発表をしてきました。僕が発表したのはAWSに関する話、そしてSSPであるFluct と、今開発しているcosmiの話をしました。学生にとってはなかなか触れることのない、アドテクノロジーの世界。普段表示されているバナーの裏に存在している、いくつものステークホルダーとシステム。そういうシステムのインフラがどのように構築され、そしてどのようにアプリケーションが動いているのか、というトピックについて俯瞰するような形で講義を行いました。

とてもむずかしい部分ではあるのですが、なるべくそのシステムの要件や構築の背景についても話すようにしています。なぜかというと、リアルな仕事の現場で、実際にそのような要件が与えられて、その上でコスト感や規模感を自分たちで考えてインフラを設計する、というところまで見て欲しいからです。特にアドテクノロジーの分野の場合、関連するシステムやプレーヤーも多く、何が必要なのかということを理解するのに敷居が高いという部分はあります。でもそれは例えば自分がスタートアップでシステムを一から作るという場合でも一緒です。先がわからない。どこまで作りこめばいいのか見通しが立てづらい。急激なアクセスが何時来るかはある程度しか予想できない。ビジネスがどんな規模で成長するのかを見込まなければいけない。そういう背景を踏まえて、インフラの構成やアプリケーションの設計ができるエンジニアになってくれたらいいなぁという想いがあります。

学校でOSI参照モデルやネットワーク、OSの仕組みについて勉強しているかも知れません。そして自分でWebアプリケーションを作成できる。それは素晴らしいことです。しかし、必要になった時に本当に必要となるものを自分の手で、頭で、作れるのか。本当に自分はそういう背景知識を活かして実践できるのだろうか。知識としてただあるだけではなくて、実際に使えるものにしていく。自分がそういう立場になった時に、プロのエンジニアとして環境に適応していくことができる。そしてユーザにサービスを届けることが出来る。ビジネスを作っていける。そんなきっかけになれば、と思っています。

やっぱりそういう大きなサービスを支える、そして自分から創りあげる、そういうエンジニアが増えたら、もっと楽しくなるのではないかなぁと最近よく考えるようになりました。僕もまだまだ知らない事だらけですが、こうして教えることをしながら学んでいって、自分で考えることのできるエンジニアが増えていったら素敵だなあと思います。

来週の最終発表が今から楽しみです。

2012/10/11

ライブコーディングの会でライブコーディングしました

人がコーディングしている様子を見る、というのは僕にとって愉しみの一つです。機会があればよく「どんな環境で実装されているんですか?」というようなことだったり、「今なぜそこから実装されようとしたんですか?」というようなことを聞いてみたいけれど隣で色々思いを馳せながら眺めていたりします。

などと思っていたら自分のコーディングしている様子が晒されるイベントにいつの間にか参加することになり(!)、そのイベントが昨日行われました。

僕が学生(就活生がメイン)の前で1時間ひたすらコーディングをするという会です。ディスプレイをプロジェクタで投影し、手元の動きをカメラで2枚目のプロジェクタに映されながらコーディングします。隣で @katzchang さんに解説していただきました。(といっても事前打ち合わせはほとんどなかったです。)

お題は自由だったので、ひとまず最近勉強しているFlaskで小さな掲示板でも作る、ということにしました。スキーマ定義が面倒なのでMongoDBで、あとはローカルでサーバたちあげてテストすればいいだろう、という極めてざっくりな方針で進めることとしました。


ひとまず気合をいれてツイート。

まずGithubリポジトリを作成。(https://github.com/suzuken/livecoding2012-10-09)

次にローカルのpipでFlask周りの物をインストール。ひとまずREADME.md書いてcommit。git push origin master。

init · 78e80b4 · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/78e80b4b24dbb171e36989ec0461fe1d83bc19b0

そして次にFlaskの最小限のコードを書く。この時にvim環境について質問があったのでツイート。
そしてcommit。

add endpoint · fba1f7f · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/fba1f7f43121223ecf3fc6bf3fe8828cc9db1591

次にMongoつなぎましょう。ということでMongoKitをimportして、簡単にDocumentクラス書いて、とりあえずエンドポイント書いてpush。

adding mongokit · 728381c · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/728381cd57a740f8ddf572ce977420c76df76870

そしてここから色々調整。ひとまずviewを作ろう、ということでTwitter bootstrapを落としてきてstaticディレクトリへ。そしてささっとviewと作成。表示完了。次にログイン作ろう、と思ったらFlaskのsession周りについて全然調べていない、ということで色々焦っていたら時間が経ってきたので、とりあえずブログのエントリを表示できるようにしよう。ということでテストデータを挿入するためのエンドポイントを作成。更新。しかしMongoKitでエラー。Documentの定義ミス。もう一度更新、しかしエラー。挿入は成功したが、redirectの設定を間違える。このあたりでつい弱音が…。


そしてもう一度挿入。今度はうまくいった。ここで大分時間消費…。あと20分…、とかだった気がします。 実際にやっていて気がついたんですが、60分間も人目にさらされながらコーディングするっていうのはなかなか体力が要ります。45分を過ぎた当たりで若干酸欠になってきます(※個人差有り)。ということでこの時間帯はもう全然進まなかったです…。とりあえずMongoへのinsertとfindだけ作って表示しただけになってしまいました。おまけにcommitするのも全然忘れていたため、下記のカオスなコミットオブジェクトが生成されることになります。コミットメッセージからも余裕の無さが伝わってきますね。

bootstrapたして、dbつないで、addして、findしました。余裕がありません · a2580d3 · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/a2580d320b6d5480a3f701a8e2e21e048e1e9190 




という当たりで1時間経ちました。ライブコーディング終了。ヘトヘトです。やってみるといろいろテンパッていろいろ想定外で進まない…などなど色々起こってますね…。

コーディング後は、まぁとりあえずビールを飲みつつ、色々質疑応答しました。割りとツール周りのことを多く聞かれました。zshの話、tmuxの話、あと多かったのがvim周りの質問でした。補完(僕の補完はvimデフォルトのままです。でもみんな意外と知らないのかも知れません。)、バッファ、移動、削除、カーソル移動、などなどです。あとはドキュメントの読み方についても聞かれました。

そういえば僕も学生の時には「現場のエンジニアは一体どんな風にコーディングしているんだろう」とよく思ったものでした。実際にそれを見れるというのは面白い機会だったのかなぁと思います。なんというか、実際そんなに差はないと思います。なんだろう、僕自身あまり学生の時からすごく変わったかというと、確かに触れている時間は増えましたが、すごくコーディングスタイルが変わったかというとそうではないです。でもいろんな要件や環境になれてきた、というのはあると思います。良くも悪くも現場感の伝わるイベントになったような気がします。

とは言え、思わず漏れる本心…。
でも他のエンジニアの方々のライブコーディングはみたいです。(できればビール片手に!)

2012/10/05

エンジニアの育て方を考える

最近になってよくエンジニアの対話について考えるようになりました。

最近あるインターンが始まりました。Guildというインターンです。これは僕のような入社して日の浅いエンジニアが、学生やそれに準ずるエンジニアに対して実践型の育成を行なっていくというスキームを持ったプラグラムです。

就業型実践育成プログラム「Guild」|VOYAGE GROUP インターンシップ ~ミチをソウゾウせよ~ http://voyagegroup.com/internship/guild/

こういうインターンの場合、学生一人ひとりに合わせて方法を変えていかなければなりません。一人ひとり癖がありますし、スキルも異なります。また事業に対する理解度も最初は浅いでしょうし、所属するチームのやり方も様々です。そんな中でもフレキシブルに、かつ着実に学びを得られるような環境をつくる、ということについて最近は考えています。

育てる、と言いつつ僕は育てられてばかりです。不思議な事ですが、大学院にいる時よりも学習ペースが上がりました。それは時間に対して自分でしっかり管理するようになったからとか、評価してくれる人がいるからだとか色々な要因がありますが、総じて環境による影響は大きいです。同じような関心ごとをある人に囲まれて、日々それとなくご飯を食べたりお酒を飲んだりしながら技術の話をして、帰り道や運動している時や帰って風呂に入っているときにふと「あ、あそこはもっとこうすればよかったなぁ」なんて思って次の日にとりかかるのです。今もそうです。こうして帰宅して文章を書きながら、あのときこういうふうに問いかけていたら良かったのかな、なんてことを思い返しています。

前に出て講義形式で教える時と、対話しながら教える時では、今はやり方が異なります。対話しているときは特に問いかけていることが多いです。ゲーテとの対話 ほど諭すことができるほど高尚ではありませんし、アプレンティスシップ・パターン に書いてあるほど定型的なやり方を心得ているわけではないのですが、人によって問いかけが多かったり少なかったりします。たとえばとあるMVCフレームワークに関するチュートリアルをやっていたとして、MVCに関して理解していることを確かめようと思った時には、大体頭の中に以下の様なツリーを描きます。

  • なぜMVCの構造が必要なのか
    • Model View Controllerそれぞれの役割を把握しているか
      • 複数人で開発する場合はどうか
      • MVCの構成は自分の感覚とズレはないだろうか
        • それはもしかしたら正常かもしれない
    • HTTPリクエストをなぜControllerで捌くのだろうか
      • そもそもHTTPリクエストには何が含まれているのだろうか
      • ControllerのプロパティにModelインスタンスの参照を渡すのは妥当だろうか
    • なぜModelでデータの操作をするのだろうか
      • そもそもModelによって抽象化しているものは何なのだろうか
      • このチュートリアルではModelにどのような工夫がなされているだろうか
    • Viewに表示する際にどのようなフローを経ているだろうか
      • そのフローは合理的だろうか
(すごく偏っている気もしますが)大体こんなことを大枠として捉えておいて、相手の状況によって質問を変えます。コード自体は動いているのだけれど、なぜそのように書いているのかが自分でも理解できていないという場合もありますし、MVCっぽい書き方をしていても何かエッセンスを捉えていないコードになってしまっている場合もあります。そういうときに上の簡易的なツリーをたどって質問をします。僕が対話をするときには大体そういう方針をとっています。もちろん話題は多岐にわたりますし、MVCの話だったのに開発フローの話になったり、Webサーバの話になったり、Gitの話になったりします。それはそれでよくて、学びのきっかけとしてチュートリアルというものがあれば良いのかな、と思っています。

ただ、もちろんこんな一例にすぎないことで完結するものでは当然あるわけもなく、日々少しずつ続けていくということをしています。逆も然りで、僕も気がつけば教わっていたという場面が多々あります。そういうとき、「ああ、巧いなぁ」と感じたりもします。教えているようでなくて、気がついたら本人が気がつく環境が作られていた、ということなのです。僕ももう少しそういう環境づくりをうまくできたらなぁとよく思います。

前も一度書いたのですが、「誰のために何ができるのか」というのはやはり僕の中で日々の大きな部分を占めている関心ごとなのです。相変わらず変わらないなあ、などとこの文章を書きながらまた思い返しています。

2012/10/02

Programming Hiveを購入した。


Programming Hive、出ましたね。Hiveのドキュメントはapacheプロジェクトのページで閲覧できるものの、まだドラフトのドキュメントと混ざっていたりして見づらいので、こうしてまとめられて出版されることは好ましいことです。

Programming Hive - O'Reilly Media http://shop.oreilly.com/product/0636920023555.do

早速購入し、今日の午前中に読んでいました。目次は以下のとおりです。

Chapter 1 Introduction
Chapter 2 Getting Started
Chapter 3 Data Types and File Formats
Chapter 4 HiveQL: Data Definition
Chapter 5 HiveQL: Data Manipulation
Chapter 6 HiveQL: Queries
Chapter 7 HiveQL: Views
Chapter 8 HiveQL: Indexes
Chapter 9 Schema Design
Chapter 10 Tuning
Chapter 11 Other File Formats and Compression
Chapter 12 Developing
Chapter 13 Functions
Chapter 14 Streaming
Chapter 15 Customizing Hive File and Record Formats
Chapter 16 Hive Thrift Service
Chapter 17 Storage Handlers and NoSQL
Chapter 18 Security
Chapter 19 Locking
Chapter 20 Hive Integration with Oozie
Chapter 21 Hive and Amazon Web Services (AWS)
Chapter 22 HCatalog
Chapter 23 Case Studies

1~8章あたりは基本的にリファレンス的なものです。

それ以降は比較的実践的な内容が続きます。9章では比較的実践的にパーティショニングを使った事例などが出てきます。13,14章ではUDF, UDFA, SerDeの実装についてや、Mapper/Reducerの実装について説明されています。12章でHiveの拡張に関する開発環境の整え方について書いてあるのはなかなか親切だなぁと感じました。16章ではThriftとの連携について、17章では各種ストレージの利用について言及されています。ストレージハンドラ実装の際の参考にもなるかもしれません。

また21章ではAWS上での利用についても触れられていますが、ここでは比較的導入的な記事に留まっていました。23章のケーススタディーは面白いです。たまにreportされているNASAでの利用事例についても解説されています。

個人的にはHiveを拡張する際の実装に大いに参考になる一冊になりそうです。特に10,13,15,17章あたりはすぐに実践に活かせそうです。8章で今後広まるであろうIndexについて触れられているのも良かったですが、内容はまだ薄いといった感じです。(とはいえ、HiveのJIRAを追っていない限りは得られない情報も多いので、そういう意味ではよいまとめだと思います。)またHiveを俯瞰するという点でも簡潔にまとめられていて好印象でした。ただHiveというプロダクトの性質上、万人に必要な本ではないということも踏まえて、バランスのとれた本だと思います。