GitHub と Jenkins の連携でハマった

社内的に GitHub に移行することになったので、 GitHubリポジトリに pull request が merge されたタイミングで Jenkins のプロジェクトが実行されるように設定しました。設定手順は GitHub Plugin - Jenkins - Jenkins WikiTrigger Jenkins builds by pushing to Github | Four Kitchens が参考になります。 1 点ハマったのが GitHubPost-Receive Hooks の所で、 Basic 認証に対応している と書いてあったのですが、なぜか手前の Apache で 401 の認証エラーとなりました。結論は Apache の設定ファイルで Basic 認証ではなく Digest 認証にしていたことが原因でした。。既存の設定は HTTP のみだったのですが、そこは Digest 認証の設定があり、ちゃんと内容を読まずにコピーして HTTPS の設定を書いたことが原因でしたorz

  • Jenkins は GitHub Plugin を利用した。
  • Jenkins の手前に Apache があり、そこでは HTTPS で Basic 認証の設定を行った。
  • GitHub 側の Post-Receive Hooks は WebHook URLs でも Jenkins (GitHub plugin) でも問題なかった。
    • 意味的に分かりやすいので Jenkins (GitHub plugin) を利用する設定にした。
    • どちらも設定後にテスト実行のボタンがあるので、実際にリポジトリに push しなくても疎通テストが出来て便利だった。
    • 設定する URL は https://ユーザー名:パスワード@Jenkinsのホスト名/github-webhook/ という URL になるんですが、 Jenkins の Github Plugin は GitHub が POST する JSON の中からリポジトリの URL を取得して、 Jenkins の個々のプロジェクトに設定されているリポジトリの URL とマッチングを掛けるという実装のようです。

2012年振り返り

ちょっと遅くなりましたが、2012 年について振り返っておきます。

  • 3 月に転職した。
  • 仕事で MapReduce ジョブを書いた。
  • 子象本読書会を行った。
  • MySQL に慣れた。
  • Git に慣れた。
  • Mac に慣れた。

2012年の目標と比べるとあまり関係ない感じですね。。

3 月に転職した。

3 月に広告配信系の会社に転職しました。前職では Google Apps 周りを中心に受託開発してたんですが、どうしても Hadoop を仕事で触りたくて。Servicer も初めての経験で色々驚くことばかりでした。特定の業務ドメインに関して勉強するといこともやってみたかったので、とてもおもしろかったです。まだ、競合他社との比較とかその辺までは追えてませんが、アドテクおよび Web 広告に関しては概ね掴めたかと思っています。今まで見ている Web ページの広告がどこ経由で配信されてるのかとか、あーリタゲされてんなーとか、今までとは違った視点で見えるようになっておもしろかったりしますw

仕事で MapReduce ジョブを書いた。

Hadoop との出会いは前職で 2010 年後半に SES で派遣された先で EMR の Hive の検証・導入を行った際でした。そこで心を奪われて、仕事では扱わなかったのですが、個人的にウォッチしている感じでした。そして、今年になって転職先で MR ジョブを書いて、かなりすっきりしました。要はファイルをぶん回すだけのバッチです、以上。みたいな感じですね。オンプレミスで運用しているので、Hadoop クラスタの不安定さも身にしみましたし、概ね学びたいことは学び尽くした感じです。なので、今後は緩い感じでウォッチでもいいかなーぐらいのテンションになってますw

子象本読書会を行った。

有志で Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理 の読書会を行なっていました。3 週間に 1 回ぐらいペースで行なっていて、最終的に 12 回で 10 ヶ月ぐらいかかりました。途中からデータ分析担当の同僚が参加してくれたので、参考書籍を読み漁ったり、質問しまくったりして、隠れマルコフモデルについてだいたい理解できるようになりました。6 章だけで 4 ヶ月ぐらい使ったので、辛抱強く一緒に参加してくれたメンバーにはほんと感謝しています。去年、一番嬉しかったのはこの読書会でして、一緒に勉強できる仲間と巡り会えたのはほんとに嬉しかったです!

MySQL に慣れた。

今の職場で MySQL を利用していることもあり、まぁまぁ慣れたし、色々調査して面白かったです。主に調べたのは排他制御、実行計画、金額計算、タイムアウト辺りです。MySQL はネット上の記事も多いですし、本家のドキュメントが充実しているのでほんとよいなーと思います。ただし、日本語版は古かったり翻訳していない箇所が多いので、英語版を読むようにしていて、そこはちょっと大変だったりしました。英語力をもっと上げないといけないなーと思いました。

Git に慣れた。

前々から勉強するする詐欺をしてたんですが、転職先が Git を使っていたおかげで、かなり慣れたと思います。いやー、慣れるとほんと便利ですね。CUI で diff とか絶対無理と思ってたんですが、今では慣れてしまって特に違和感なくなってたりしますw

Mac に慣れた。

MBP 自体は持ってたんですが、仕事でメインで利用するのが Windows だったこともあり、使用頻度はかなり低かったです。ですが、転職先で PC を自由に選べたので iMac にしたお陰で慣れました。一番大きいのは Eclipse で、1 ヶ月ぐらいはショートカットキーの違いに苦しみましたが、そのぐらいで慣れてその後は快適です。むしろ、今では 10 年近く書いていた Windows でのキーバインドが思い出せないぐらいです。慣れというものについて色々と考えさせられる事象でした。

まとめ

どれも今年の転職がキーになっているものばかりで、転職してよかったなーと思っています。他にも仕事上 Ruby を触ったり、ActiveMQ について調べたりと色々経験できて、面白かったです。とりあえずそこそこ成長はしたと感じられる 1 年だったので、来年も引き続き成長していきたいと考えています。

今までの子育てを振り返ってみました

この記事は 子育てエンジニア advent calendar 2012 の 12 日目のエントリーです。

うちは私と嫁さんと長男 5 歳、次男 3 歳の 4 人ぐらしです。長男は早生まれなので来年には小学生になり、割りと自分の時間も取れるようになって来ました。他の方よりは多少子どもの年齢が高いようなので、今までの子育てを振り返ってみたいと思います。

時系列の振り返り

家庭面、仕事面でのイベントと年ごとの自由時間について簡単にまとめてみました。他の方も書かれているように、子どもが生まれて変わったことや学んだことはたくさんありますが、とにかく自分の時間が取れなくなったというのはあります。うちの場合は長男が 3 歳の時がピークで、次男が産まれた & 育児休業したこともあり、ほんと自分の時間が取れませんでした。あと、仕事面で思うのは忙しいと言いつつも、結構好きなようにやってたなーとは思います(^_^;)

2006 年
  • 結婚 & 長男懐妊。
  • この頃は 50 人?ぐらいのプロジェクトでアプリ基盤チームに所属していました。
  • 嫁さんは妊娠したといっても、子どもが生まれているわけではないので、とても時間に余裕があったと思います。
2007 年(長男 0 歳)
  • 長男の誕生に伴い、勤務先でエンジニアからスクール事業の講師に配置転換してもらう。
    • もともと教員免許を持っていることもあり、講師はやってみたかった。
    • 講師であれば勤務時間が安定していると考えた。実際、かなり安定していて、家で過ごせる時間も多かったです。
  • 今にして思うと、まだ長男は 0 歳台で動けないし、よく寝てるしで時間に余裕がありました。
2008 年(長男 1 歳)
  • 次男の懐妊。
  • 講師だと技術的に置いて行かれる気がしてならなかったのもあり、現場に戻る。
    • 基本的に晩御飯には間に合わない感じになった。週に 1 日とか調整して早めに帰る感じでした。
  • 長男の夜泣き & 早起き(5 時とか。。)で地味に削られていたけれど、まだ 1 歳台で昼寝も多くて、時間に余裕があった気がします。
2009 年(長男 2 歳、次男 0 歳)
  • 次男の誕生に伴い、育児休業した(嫁さんは長男誕生から専業主婦)。
  • もうちょっとテクニカル方面のスキルを伸ばしたいと考え転職した。
  • 圧倒的に時間がなくて、余裕もなかった年です。そんな中、転職したり記事書いたり、今にして思うと我ながら意味不明ですね。。
    • 特に記事に関しては基本的に業務時間外で書いてたので、嫁さんと子どもには申し訳なかったです。時間の取られ方が半端無いので、今後はちょっと書けないなと思ったりしました。
2010 年(長男 3 歳、次男 1 歳)
  • 長男が幼稚園入園。
  • 仕事先のプロジェクトで Hadoop に触れる機会があり、心を奪われた。
  • やっと土日に勉強会に参加できなくもないぐらい余裕が出てきた年です。
    • 幼稚園に入ったので長男が色々病気を持って帰ってきて、家庭内に病気が蔓延するようになりましたorz
    • 次男は夜泣きばっちこい状態だったので、睡眠時間も足りないし、寝かしつけた後に勉強してて急に起きて対応とかもありました。
2011 年(長男 4 歳、次男 2 歳)
  • 多少は落ち着いた気がします。まだ次男の夜泣きがあって、睡眠時間は安定しないし、冬場は子どもが風邪を引いたら家族全員が順番に引いたりしてました。インフルエンザで 7 営業日連続で休んだりもしましたorz
    • 長男はだいぶ体が強くなったのか、風邪を引いても熱がそれほど高くならないようになりました。
  • 平日は時間を調整して週 2 日ぐらいは早めに帰って家で一緒に晩ご飯食べたりしてました。
    • 調整しやすかった理由として自宅勤務可能なのもあったとは思います。寝かしつけた後に自宅で仕事をすることも多かったです。
2012 年(長男 5 歳、次男 3 歳)
  • 仕事で Hadoop を触ってみたかったので 3 月に転職した。
  • 次男もかなり歩いてくれるようになったし、夜泣きもなくなってだいぶ楽になったと思います。
  • 転職に伴い自宅勤務ができなくなったので、基本的に平日は子どもたちが起きている時間に帰れなくなったのは残念だったりします。
    • 中途半端に 20 時半ぐらいに帰ると子どもの寝かしつけの邪魔になるので、それならばいっそ寝てから帰るという感じです。
    • 自宅勤務は出来ないですが、勤務時間は自由な会社なので、朝は子どもを送ってから出社してます。嫁さん的にはそっちの方がいいそうなので、まぁいいかとは思ってたりもします。

学んだこと

コントロール出来ないことはたくさんある。

子育て以前に、体調管理とかも含めて、独り身の頃は割りとコントロール出来ると思ってたのですが、子どもがいると管理のしようがないことを思い知りました。マスクとか付けてくれませんしね。。幼稚園とか行くようになれば病気がうつるのも仕方ないですし。こどもが熱を出して早退したことも何度もあります。外食時に騒いだり、電車で泣いたり、もちろんそういう時期は行かないようにしてたりもするのですが、どうしても行かなければ行けない場合もあったりで、まぁ大変ですよね。電車の中で泣いている子がいると、ほんと心配するようになりました。

常に余裕を持っておく必要がある。

うちは両親の実家が離れていることもあり、気軽に両親にこどもの面倒を見てもらうということが出来ません。そのため、嫁さんが体調を崩したりすると私しか子どもの面倒を見れなくなるため、何かあった際に必ず対応できるように自分自身の体調管理はかなり気をつけています。子どもが生まれてからは徹夜で飲んだりとかは全くしないようになりました。

他人と比較しない。

時間は取れないし、すごい人はいっぱいいるしで、すごく焦る時期があったのですが、焦ると余裕がなくなって、それが家族に伝わるんですよね。なので、他人と比較するのではなく、少しずつで良いので勉強し続けるということを重視するようになりました。実際、お客さんから見て対価に見合う価値が出せていればいいわけで、そこをクリアできていれば後は自分のペースでいいんだと思えるようになりました。

家庭というプロジェクトの方が優先度が高い。

仕事のプロジェクトは一定期間で終わりますが、家庭というプロジェクトはそれよりも遥かに長い期間続くわけで、目先の仕事を優先して家庭というプロジェクトを破綻させないように気をつけないといけないと考えています。とかいいつつ、ついつい仕事には熱が入りますし、転職しまくったりしているので、実践できているかは怪しいですがw

嫁さんは偉大。嫁さんは偉大。

私は仕事をしているので好きな時間に休憩を取れますが、嫁さんは子どもの相手をしている際は自分のタイミングで休憩が取れないわけで、ほんと大変だと思います。改めて土日は私が子どもの面倒を見ようと思いました。


エンジニアカレンダーとして成立しているかよく分かりませんが、他の方の参考になると幸いです(^^)
次は @ さんです。

#isucon2 に参加しました

@ に誘って頂いて @ と 3 人で isucon2 に参加しました。結果は惨敗でしたが、とても楽しかったです。唯一 Java で取り組んで、結局採点基準にすら届かなかったので参考にならないかもしれませんが、個人反省会ということでメモしておきます。

事前準備したこと

@ から去年の様子とか参加ブログのリンクを教えてもらい、3 人で事前打ち合わせしたり、isucon1 のアプリを Java で書き直したりしていました。今にして思うと、いろいろ甘かったと思います。

  • isucon1 を見た感じだと、ソースコード自体のチューニングというよりは DB 構造をいじるのとインフラチューニングがメイン?
  • JVM 使えば早くなるだろうから、当日 Java に書き換える。そのため、アプリケーションの雛形を作っておく。
    • JVM 使うんだからキャッシュしたいよね。でも AP サーバー 2 台あるね。どうしよう。。
  • @ はインフラ全般、@ と私(@)でアプリ側を担当する。
  • 当日の情報共有には co-meeting を使う。
  • ソースを管理するために Bitbucket を利用する。

当日

Java の実装が提供されていたので、書き直しのコストが浮くねという感じで、サーバー側で Java を動かすということと、ローカルでソースをいじれるように開発環境を構築するということを分担して進めていました。なお、私自身はほぼ Java ソースをいじっていただけなのでサーバーの作業内容はよく分かっていません。あと、時間は焦っていたこともありかなり適当です。

11 時 - 14 時 ぐらい
  • 提供されていた Java 実装を WTP で開発できるように修正。
  • サーバー側は各種ミドルウェアのインストールや再起動されても動作するように設定作業。
15 時台
  • Tomcat にデプロイしてベンチを実行 -> Failed となりチーム全体が浮き足立つ。success response: 79.7%
  • DataSource のコネクションプール数がデフォルトのままだったので 1 台辺り 400 個に増やすが効果なし。success response: 79.9%
  • nginx 側から Tomcat 側への接続数を増やすが効果なし。success response: 78.6%
  • @ が stock テーブルにインデックスを追加することで多少ましになるがやはり Failed のまま。success response: 87.1%
16 時台
  • やっとアプリケーション側に目を向けるようになり、色々遅い SQL やらロジックを見つけ、チューニングに着手する。
  • チケットの表示部分が極端に遅いので、キャッシュ出来ないかなと話しつつも、チケットの残数を SQL で取得していたので、その処理をなくすという軽微な修正を行う。
17 時台
  • サイドバー部分の SQL が重いので、order_request テーブルに表示に必要な情報を全て書き込む方向で修正しているうちに時間切れ。

反省点

実力不足の一言です。あと、普段の開発の意識から切り替える必要があったかと。あれは isucon というスポーツだと思いました。7 時間しかないので、とくにかく各プロセスを軽量化し、本当に必要な作業だけを行う必要があるし、それができるだけの実力や事前準備が必要だと思いました。

  • WTP の環境を作るのに時間を掛け過ぎた。ソースをいじってビルドできればいいだけなのに、ローカル開発環境の構築に時間を掛け過ぎた。
  • 最初に全体の分析をしようと話していたのに、結局やれずじまいだった。
  • co-meeting は選択誤った。余裕がなくてあまり見に行けなかったし、ミーティングも複数作って切り替えが面倒だった。Skype でも Google チャットでもなんでもいいので 1 スレッドでリアルタイムに push 通知がされるもので十分だったと思う(co-meeting は後で見返す分には便利だったけれど)。
  • JVM 使えば早くなるだろうと楽観視し過ぎた。当たり前なんだけどユースケースが合わなければ特にメリットでないわけで、ほんと甘かったと思う。
  • Bitbucket(git) を使ってソース管理したけど、ブランチとかまじでいらなかった。かえって混乱するだけだった。
  • やっているチームもあったが、Java にこだわるなら Tomcat 1 台にして、全てメモリ上で処理すればよかった。そもそも、データ量自体は少ないのだからメモリ的には余裕だったはず。
    • 他にもキャッシュとか方式自体は思いついても、あの時間内で実装しきれる自信はなかったので結局は実力不足を痛感した。

最後に

事前準備で直前の一週間ぐらいは睡眠時間削ったりしてましたが、当日も含めてとても楽しかったでし、勉強になりました!企画・運営のみなさま、本当にありがとうございました!!

最後にどうでもいい話なんですが、嫁さんに何に参加していたのか説明を求められ、ミニ四駆のチューニング大会みたいなものだと説明したら納得してもらえました。当日会場に車が何種類か用意されていてレギュレーションさえ守れば改造し放題みたいな感じと説明しました。我ながらいい例えが見つかったとは思いましたが、それで納得する嫁さんもどうかとは思いましたw

hadoop fs コマンドで dfs にコピーする際のリトライ回数を増やすには

前提

  • CDH2u3
  • NotReplicatedYetException が発生してコピーに失敗する場合。具体的には以下みたいなログが出力される場合。
12/10/08 11:17:47 INFO hdfs.DFSClient: org.apache.hadoop.ipc.RemoteException: org.apache.hadoop.hdfs.server.namenode.NotReplicatedYetException: Not replicated yet:${HDFS上のファイルのパス}
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:1268)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.addBlock(NameNode.java:469)
        at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:512)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:966)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:962)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:396)
        at org.apache.hadoop.ipc.Server$Handler.run(Server.java:960)

        at org.apache.hadoop.ipc.Client.call(Client.java:740)
        at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:221)
        at $Proxy0.addBlock(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
        at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
        at $Proxy0.addBlock(Unknown Source)
        at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.locateFollowingBlock(DFSClient.java:2932)
        at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.nextBlockOutputStream(DFSClient.java:2807)
        at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.access$2000(DFSClient.java:2087)
        at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$DataStreamer.run(DFSClient.java:2274)
12/10/08 11:17:47 WARN hdfs.DFSClient: NotReplicatedYetException sleeping ${HDFS上のファイルのパス} retries left 4

対応方法

HDFS クラスタの負荷が高いためか、コピー対象を書き込むための次のブロックが取得できない場合に発生する例外のようです。 dfs.client.block.write.locateFollowingBlock.retries オプションを指定することでリトライ回数を増やせます。以下みたいな感じで指定します。

hadoop fs -D dfs.client.block.write.locateFollowingBlock.retries=10 -copyFromLocal  URI
  • デフォルトは 5 回になっていて、実装箇所は DFSOutputStream#locateFollowingBlock です。
    • リトライする際にスリープ間隔を延ばす実装になっていて、初期値は 400 ミリ秒です。リトライする毎に 2 倍にします。
    • 最初に処理を開始してからリトライを繰り返し、 5 秒を超えると以下の warn ログを出力するようになります。
      • Waiting for replication for ${処理開始からの経過秒数} seconds
  • CDH2u3 で動作することは確認済みです。
    • CDH3u5 はソースが残っていることは確認しましたが、動作確認は行なっていません。

時間が掛かってもいいからより確実にコピーしたい場合はリトライ回数を増やしてみるといいかもしれません。実際、今の職場では増やして運用してます。

hadoop-client

Developing CDH Applications with Maven and Eclipse | Apache Hadoop for the Enterprise | Cloudera を見たら hadoop-core ではなく hadoop-client なるものを使っていました。そこでちょっと調べてみたところ、Hadoop 1.0.1 からリリースされたものでした Hadoop 1.0.1 Release Notes。実際に中身を見てみたところ、pom.xml しかなくて、hadoop-core からクライアント、要はMRジョブとかを書くために必要なライブラリだけを残すようにしてくれるプロジェクトでした。maven の exclusion にこんな使い方もあるんだなと思いました。

更新頻度が落ちまくっていたので、今後はちょっと調べたこととか気軽に書いていければと考えています。といいつつ、同じようなことを1年前に言っていて、結局書けなかったのですが。。。

2012年の目標

いまさらですが、今年の目標を書いておこうかと思います。

データ分析について勉強する

現時点で統計学の入門書を色々読んでいる所です。とりあえず、以下の5冊はざっくり読み終わりました。

そもそも、データ分析を勉強しようと思ったのは、単純におもしろそうというのもありますが、Hadoopをウォッチするようになったのも大きいです。Hadoopは処理時間を短縮する手段に過ぎないので、Hadoopだけをウォッチしていても例えばMapReduceが書けるようにはならないんですね。要はフレームワークだけ見ていても、アプリケーションは作れないという話です。ですので、具体的なアプリケーションとしてデータ分析の知識を身につけたいと考えるようになりました。

英語の勉強を続ける

去年の夏ぐらいから毎日10分程度簡単な英語の本を読んでいました(PGR3,4ぐらいです)。以前はCDなしにしていたのですが、やはり発音が分からないのが微妙だったので、今年からはCD付きにしてみました。3月の時点でPGR2を4冊聞いて、PGR3に入った所です。やっぱり発音がわかる方が気持ちいいですね。小説を読むのは好きなので、気長に続けるつもりです。

デザインの勉強を続ける

去年の秋ぐらいからデザイン関連の本を1日数ページ読むようにしています。数冊読んで分かったことは、デザインというのは非常に計算されたものだということです。ちなみに、今読んでいるのはノンデザイナーズ・デザインブック [フルカラー新装増補版]です。今後も気長に読んでいくつもりです。

もう1冊読む

要は1日3冊は本を読んでいるのですが、今年はもう1冊追加で読み続けたいと考えています。この1冊は全く違う分野の本にしようと考えていて、いろいろ雑多に読もうかと考えています。ちなみに、この前読み終わったのがデフレの正体 経済は「人口の波」で動く (角川oneテーマ21)で、今読んでいるのは小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則です。ここ数年は経営・経済関連の書籍は読んでいなかったので*1、数年ぶりに読もうかと思ってます。

その他

データ分析の方が一段落したら、7つの言語 7つの世界を読んだりアルゴリズムについても勉強できたらなーと思ってます。

*1:日経ビシネスは定期購読してます