年報 #vgadvent2014
気がつけばもうアドベントカレンダーの季節。今年も振り返りをしてみようと思う。
この記事はVOYAGE GROUP エンジニアブログ: Advent Calendar 2014の12/18分の記事です。 http://tech.voyagegroup.com/archives/7941760.html
去年も書いた振り返り記事: http://suzuken.hatenablog.jp/entry/2013/12/24/220213
書いていたら随分長くなってしまったし9割5分くらい自分の振り返りになってしまったしこれは最早ポエムに近いので、面白く無いかもしれない。3行に要約すると
- 分析チーム切り出した。課題多いけど着実に進んできている。
- マネージャーっぽくなりつつ、相変わらず分析基盤を作るエンジニアをやっている。よりインフラよりのこともし始めた。
- 初めて技術書の執筆に携われて、大変だったけど良い経験になった。
1-3月: 分析基盤グループを切り出し
広告周りのデータをもっと活用できるようにしたい。そういう要望から、私の所属しているチームが切りだされ、リーダーになった。ターゲティング基盤の構築に加えて、本格的にデータの分析をするための仕組みづくりを開始した。元からつくっていたDMPといわれるものの使いやすい部分を切り出せば、技術的にレバを効かせつつデータを活用できる仕組みが作れるのではないだろうかというのが発端だった。
Web広告の裏側で扱われているデータは、大きい、というより多い。かつ、スパースで、関連を見出すのに時間が掛かる。全量を使って解析したい。結果反映までの時間を短くしたい。そして最終的に広告効果をあげるところまでつなげていきたい。じゃあどうするか、組織をつくろう。そして分析をする文化をつくろう。これが最初の試みの始まりであり、今も変わらないスタンスである。
9月に行われた「サーバ/インフラエンジニア養成読本」のイベントでのプレゼン http://www.slideshare.net/suzuken/ss-38865046 でもこのあたりに触れているように、常に問題意識としてあったのは、データを活かす組織づくりだった。解析専任のメンバーもこのときはいなかったし、ただただデータを綺麗にするということだけが決まっていたようなものだった。もともといわゆる広告に利用するターゲティング基盤 *1 をつくっていて、その上でより広告主とメディアに対して双方のためになるような仕組みをつくることを考えていた。そのためにはデータをみて、そのための組織をつくって、よりロバストでデータに対して反応しやすく、それが広告システムとして息づき、新しい施策がどんどん取り入れられていく。そういう仕組をつくろうと思っていた。この課題に対して、エンジニアリングとしての無駄を省きつつ効率的に、かつ、分析タスクに対しても深くそして柔軟に取り組める組織が必要だった。なので、この1月のタイミングでそういう動きになった。というのがこのころの背景だった。
余談だが、こういったWeb広告システムの裏側を支える事柄というのは、なかなか表に出づらい。まぁなんというかとてもロジックが業務ドメイン直接なところが大きいのでしかたないという面もある。のだが、いわゆる分析チームをつくる、データ分析基盤をつくり分析を加速させていくという面については、一般的な技術的かつ組織的な課題として切り出して議論できる部分は多い。もっとこの領域については事例なり知見なりが表に出てくればよいと思っている。というのと、それに加えて文化を作るというのは実に面白い話でもあって、今年は幾分そういうところに時間を割いていた。あとは組織縦割りの弊害とか、各組織にまたがるように知見を共有したりシステムがうまく連携していくにはどうしたらいいんだろうかとかそういうことをむにゃむにゃ考えていた。もちろんパラダイムとしてはmicro servicesみたいな方針はあるのだが、それよりも大枠でシステム間の連携や知見の共有がうまくできていないという背景があった。このへんは組織によって変わる話だと認識しているが、いま振り返るとそのあたりが悩みの種だったなぁと思う。チームごとに分析のownershipが持てているか、などなど。
それからこのへんでImpalaとかPrestoの検証やったり、Elasticseacrhを触ったりしていた。DynamoDBのGSIすごいなーとか。ターゲティングシステムを柔軟にできるようにしたりとか。システム連携したりとか。JVMのFull GCと戦ったりとか。気がつけば評価の業務とか、採用周りとかそういうのにつかう時間も増えてた。これから毎日会って、一緒に考えて、ものをつくっていく人を選ぶというのは大変なことだなと感じたりした。あとJVMのFull GCと戦ってた。
それと、(嬉しい事に)このへんでログ解析本書くのが決まって、打ち合わせとかしてた。
4-6月: 新卒の配属と、マネージャー業
新卒3年目となった。早いような気がしていたが、今は既に年末である。チームに(お酒好きで知識欲旺盛でPythonistaの)新卒サイエンティストamacbeeが入ってきたり、将棋好きで最近ラジコン?にはまっているプロキシエンジニアrail44が入ってきて、ますます活気づいてきたのがこの時期である。そうか、8ヶ月も前だったか。
このころ前年からの動きがちょっと表に出た。杉山先生に来て頂いてディスカッションを深めることができはじめたのもこの時期のこと。 http://voyagegroup.com/news/press/2014/513/ この取組自体についてはほとんど外で触れられていないので簡単に説明しておくと、アドテクノロジー領域でのデータをどのように見ていくか、そしてどう活用していくか。かつそのなかでどういう手法があるか。といったところをディスカッションするというようなことをしている。まず「なぜそのアプローチをしたか」よりも「なぜその問題にアプローチしようとしたか」のほうを私としては重視している。ドメインの知識がないと判断しかねる場面も多いのだが、それはエンジニアで言うと「良さそうだったからその機能を作りました」、というニュアンスっぽさがある。そうではなくて、分析というのは「意思決定をすること」そのものに価値があると私は思っている。なので、あるロジックによって広告効果を上げることができたとしても、「なぜその問題にアプローチをしようとしたか」が抜けていると、崩れる。端的にいうと、バランスがよくなくなる。私達はたくさんのパートナーの方々に支えられていて、その上で広告を配信するというサービスを提供している。なので、「なぜ」とその倫理観が大事だと考えている。その前提にたった上で「ではどういう手法で」ということのディスカッションを深めるのがこの試みのメインとなっている。私たちのような産業の分野において学術の領域とうまく関わりつつ、知見を活かしていくというのはよく言われることではあるが、そう簡単に進まないというのが実情である。少しずつ、問題の枠組みを落とし込みながら興味深い問題を作っていく過程が個人的にはとても楽しい。
ここは私自身の趣向だが、エンジニアがOSSにPull Requestを送るように、学術の分野にももっと気軽にフィードバックできるようにしていきたいと考えている。これは温度感の問題かもしれない。私自身研究室にいた時に、実際の現場のデータがあればもっとこういう知見が得られたかもしれないな・・・と思うことがよくあった。逆に今企業にいって、手元にデータがあるのに逆に活かせていないと感じる部分がある。まだまだ道半ば(いや、どこまでいっても道半ばなのだけれども)ではあるが、こういう取り組みは積極的にしていきたいと考えている。正直今分析したくても着手できていない部分がまだまだたくさんある。というかやればやるほど、もっとやらなければならない部分が見えてきている。こういう領域に興味がある人は是非一緒に仕事をしたいし、私達としても加速したいと考えている。何より、データに向き合うのが本当に楽しい、と感じられる時間がある。そういうところを価値に変えていくのが、私のチームの仕事でもあるし、私自身の問題意識でもある。
といいつつ、手元ではターゲティング基盤の改良をしなければならなかったり、ETL業をひたすらやっていたり、まぁ手を回しても手が足りない、というような季節だった。fluentdをベースとしたストリーミング処理の環境とバッチ処理との適当な使い分けをデザインしたり、実装したりした。fluentdなかったらリアルタイムに近い処理というのはなかなか実現できなかったであろうということは去年もいくつか記事を書いた。新卒エンジニア研修とかもやってた。ゴールデンウィークは息抜こうと思ってたけど、執筆のが全然終わらなくて結局1日休めただけであとはひたすら家かカフェで原稿書いてた。本当に日常的に原稿書いてる方々はすごい。尊敬しか無い。技術的な内容で、普段やっているようなログ解析の話を書いたのだが、それでもまとめていくには随分時間がかかった。
原稿を書くというのは本当に良い経験だった。自分の今までやってきた仕事をまとめる良い機会でもあったし、文章で伝えるということに時間をかけて集中して取り組める機会になった。今読み返しても「伝わりづらいな・・」とか「もっとここ検証してから書きたかったな・・・」とか反省点はいろいろ出てくるのだが、伝えたいことは文章に盛り込んでいる。でも、2000円もかけて本を買ってくださった方々に、「こんな本買わなければよかった」って思われるのではなくて「買ってよかった、読んでよかった」と思われるものを書くというのが常に脳裏にあって、空き時間はずーっと原稿のことばかり考えてた。自分は未熟だな、ということばかり感じた。そういうことを経たあとに、今まで読んできた技術書を読み返したり、私が勉強してきた本を書いてくださった方々に対して何ともいえない感謝の念が湧いてきた。それと同時に、「ああ、私にはこんな本を書けないな」と思うような本をたくさん読んできているのだということに気づく。例えばSICPとか、私がおじいさんになるまでプログラム書いてても、到底書けるようにならないと思う。などなど色々感じることはあったし反省点も多いのだけれど、技術書を書くということに挑戦できて総じて良かったと感じている。*2
あとはElasticsearchのクラスタが大きくなったり、Sparkの検証したり、Kinesis触ったりしてた。バンディットアルゴリズムの勉強会とかを開いた。SICPのamb評価器を書いていて悟りを開いたりした。 https://twitter.com/suzu_v/status/465856366830030849 あと、可視化ツールが気になったので確認したりした http://suzuken.hatenablog.jp/entry/2014/06/05/130202 あとは若さ溢れる会があったりした http://www.zusaar.com/event/11397003 あと初めてHadoop SCRにいった。SparkのRDDについて掘り下げてて有意義な会だった。あとNorikra仕込んだのもこの時期だった。
7-9月: ターゲティングシステム改善再び
ターゲティングを管理するための系統があまりよくない形だったのでこれをしっかり作りたいな、というようなところからスタートした。いわゆる管理画面で、その後ろでHiveだったりstreamingが走るような機能をもっているのだが、システム全体として結果の出力が見づらかったし、疎結合にできるところが全然できてなかったりした。そろそろこれは退役できそうではあるのだが、まだ動いてる。今考えると半年掛かりだったのだな・・・。
このころにDWHについて考えなおしていて、そのメモが残っていた。突っ込みどころが多いが、このときはこういう点でいろいろ悩んでいたということがわかる。意外と検討をしたメモを残すというのはこうして見返すと面白い。
* 非構造化データ + 大規模ならHadoop一択なのだが、分析タスクなどは量も収められるし、Redshift的なものに収めたい。がしかし、過去ログのスキーマなどもがつっと整理しないと運用に載せることができない。
* この観点は最近だとHadoopにも同じことが言えて、Parquetなどを採用したい場合にはテーブル形式を決める必要がある。テーブル構造を変えるにはマイグレーションが必要になる。これを避けたいならORCfileにするのが現時点では良さそう。となるとHive 0.13を使いたいが、EMRはamiの更新が遅いので0.11しかつかえない・・・
* EMRは運用でいろいろハマる。楽だけど、それ以上のことができない。EC2上でEMR的なことを自前でやるほうを検討する時期かもしれない。
* ETL処理だけやらせるならいまのEMR運用でも良い。分析となると・・。と考えるとRedshiftに収めたほうがやはり楽だろうか。悩ましい。
* Hadoop界隈、ここ1年で急速に構造化データも束ねて扱えるように、かつインタラクティブ性を増すための仕組みとしてMPPのデザインを取り入れているため、いわゆるRDB側のMPPとHadoopクラスタ上(に問わないものもあるけど)でのMPPのどちらを選ぶか、というのが今後にとって大きな分岐になる。あとはBig Data as a Serviceに任せるか。
2014/07/09 のメモより
あとはこのころ悩んでいたこととしては、インフラエンジニアの権限についてだった。私のチームには専任のインフラエンジニアがおらず、依頼ベースでサーバなりミドルウェアの設定をして貰う必要があった。専門的なメンバーに問題について検討してもらえるのは有難いことではある。ただ、制約があると、それを越えるための細かな工夫をすることで実現していくのがエンジニアの習性なのだろうか、私もそれに漏れず、自社のインフラ管理をくぐり抜けて「なんとかうまくやる」仕組みを作ってしまっていた。なんというか、これではお互い不幸だな、と思う部分が増えたので、結局のところ10月以降に自分の担当しているプロダクトの領域についてはインフラエンジニアとしての仕事も巻き取ることにした。いわゆる、root権限のないインフラエンジニア業のようなことをしていた。*3ちなみにkatzchangには「さっさと巻き取ったほうが良い」と1年以上前から言われていたので、結果その通りになったなぁという感がある。
8月末にはエンジニア向け学生インターンTreasureの講師業を一部分担当した。前日アドベントカレンダー担当のco3kことえびちゃんの素晴らしい記事 http://co3k.org/blog/vg-security-intern-2014 からも雰囲気が伝わるかもしれない。去年に引き続き、brtriver先生の講義は相変わらずわかりやすかった。しかも去年の内容と比べると2倍?くらいの内容になっていたのだが、参加してくれた子たちが真剣に取り組んでくれたおかげで、今年のインターンをつくり上げることができたなと感じている。私はPHPでAPIサーバを実装する話や、TDD Bootcampなどをした。今回はTDDの課題をペアプロで進めてもらう形式をとった。学生のみんなが設計をするスピードと精度が徐々に良くなっていく様子を見ることができた。そして私自身も講義をしながら勉強をさせてもらったという気持ちが強い。教える度に、ゼロから自分がプログラミングを始めた時のことや、学んでいる過程のことを思い出したりする。
この時期にログ解析本が発売された。感慨深かった。
http://suzuken.hatenablog.jp/entry/2014/07/18/084555
9月には出版イベントもあって、自分の書いた章のダイジェスト版を発表させていただいた。パネルディスカッションが楽しかった。
http://suzuken.hatenablog.jp/entry/2014/09/11/210059
10-12月: インフラエンジニア業加速
先に書いたようにインフラの巻取りを開始した。ちなみに今もやっている。
このタイミングであるプロダクトを別々のAWSアカウントに移すことになった。そこで、私の担当しているプロダクトを別のAWSアカウントに移行することに。non-VPCな環境からVPC環境での移行でもあった。そして今まで構築していたもらったものを新環境の方に構築し直すことにした。Puppetのmanifestを書くところから初めて、監視の整備も新規にやった。それまでも断片的に多少は知識があったのだけれど、それまで色々と助けて頂いていたので、やってみると知らないことがたくさんでてくる。IDCGメンバーや @katz_arc や @mass に聴きつつ、無事に進めることができている。
このあたりはある程度まとまったらまとめてどこかで話をしたい。
あとはre:Inventに参加してきた。
- http://suzuken.hatenablog.jp/entry/2014/11/09/132834
- http://suzuken.hatenablog.jp/entry/2014/11/16/222447
- http://suzuken.hatenablog.jp/entry/2014/11/13/112730
見たいものを絞っているが、まだビデオとスライド見切れてない。re:Inventについては技術的な話については色々なところで書かれているので割愛するが、参加できてよかった。re:Inventは去年も参加していて、今年は変化を見て取ることができた。
re:Inventにいって最も反省したのは、自分がもっと成果を出すことのできる環境を作れるのに作れていないと感じたことだ。AWSのエンジニアの方々と話していて素晴らしいなと思う点は、全員がプロダクトを自分のものとして、主語として語ることのできるところだ。彼らはそれをオーナーシップと言っていたりしていて、組織的にプロダクトを作ることができている。あんなの大きな会社でできているのに、自分たちはプロダクトのオーナーシップを大切にできているかと、出張中ずっと自問していた。Kinesisの開発チームの方と話を聴いたときにそれを鮮明に思った。「インフラチームで問題が起きたらどうするのか?Kinesisのようなhigh throughputなサービスを維持しなければならない場合にはインフラの問題も頻繁に起こると思うが、どのようにオーナーシップを引いているのか」という質問をしたら、Kinesisのエンジニアは当然KinesisのSLAを守るためにあらゆる努力を尽くす、もしインフラチームができていなかったらインフラチームは自分たちのインフラにオーナーシップを持てていないということだから、責任をもってやってくれというコミュニーケーションをとっている、という答えだった。これは当たり前のことのように思えるかもしれないけれど、実は「隣のチームもああいう事情があるんだろうな」とか「それは私達の責任じゃないからお客さんには申し訳ないけどしかたないな」とかそういう気持ちになってしまうときというのが少なからず自分の中になかったか。そう考えると自分たちのプロダクトに私はまだまだ責任をとれていないと思ったし、改善していくスピードを上げることができていないな、だめだなと反省した。なので、今回自分たちのプロダクト領域でインフラの仕事も巻き取ることにしたのはそういう理由がある。結果としてはやるべきことは3倍増えたが、改善のスピードは5割増しになった、というような感じがある。つまるところ、プロダクトが改善するスピードをあげていくことが、私のようなエンジニアの責任なのだと考えている。
12月の頭ごろに、社内で参加していたSICP読書会が無事最後まで終了した。読書会は問題を1問1問解いていくスタイルで進められていて、よっぽど面倒な問題で無い限りは解いた。メンターの @ajiyoshi には感謝しかない。本当にありがとうございます。評価とは何か、解釈とは何か。計算機科学を私は知らなかったということを正面から教えてくれた。この教科書に約2年間ほどしっかり取り組んで、自分のコードの書き方、抽象の捉え方、そして計算機に対する見方が変わった。そして未だによくわからない部分は残っていて、そのうち読み返したくなりそう。
そして、自分がいくら勉強をしても、きっとこんな本を書けるようにはなれないだろうなと思う。どういう熱意と思い入れと知識と体系づける力と集中力があったらこんな本を書けるんだろう。
あとはサブロク会議という社内のイベントに出ていた。会社の経営メンバー + 何人か、みたいなメンバーで経営課題と解決策を話し合う会議みたいのがあって、それに出てた。3回目だったけど、毎回一緒に組ませて頂いているメンバーが違うので面白い。が、なかなか自分の部署とか事業ドメインのところではない部分だと知識が足りなくて、本質的な意見が出せないというもどかしさもある。1,2回目よりは普段の情報量や考える時間が増えているからか、満足した議論ができた、気がする。
あとはDocker触ったり、とか。td-agent2にしたりとか。Sensuいれたりとか、BigQuery触ったりとか。MCollectiveが素晴らしかったりとか。細かいところでいくと色々やった。気が付くと手を動かす時間が削られていくので、検証のためのコードとかは暇があれば書いてる。暇をつくって書くようにしなければならないな・・と自戒した3ヶ月でもあった。
まとめ
徒然と書いてしまった。こうして振り返ってみると、全然やりきれていない点がたくさんある。ただその中でも、多くの方々のお世話になったからこそ、紆余曲折しつつ仕事を進めることが出来たのだなぁと感じている。本当に日々みなさまどうもありがとうございます。
次は最近Android化した同期エンジニアの @sayadroid です。お楽しみに。