僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ！とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP

創業100年以上となる大手経済新聞の電子版サービスの開発体制・開発環境の改善の取り組みについて ウェブサービスを提供するベンチャー企業の多くは開発体制を内製化しています。 ユーザーに対してよりよい体験を提供するためには、内製化によってサービスの改善プロセスを高速に回す必要があるためでしょう。 こうしたウェブサービスの開発トレンドを採用し、ウォーターフォール・外部委託がメインであった「レガシー」な体制を改善している活動とそれにあたって苦労した（している）点について、お話させていただきます。 開発チーム体制の変更 情報共有ツール(Slack/Qiita:Team)の導入 github上でのpull-request型開発プロセス スマホアプリ・API開発内製化 ユニット・E2Eテストの導入 インフラ構成の自動化

「そのバッチジョブ、冗長化してますか？」 ジョブスケジューラとして cron や Jenkins を使うことはポピュラーだと思いますが、それらのジョブ実行サーバを冗長化しようとすると、意外と面倒ではないかと思います。 とりあえずジョブの中身(cron であれば crontab の内容)をバックアップしておき、サーバ障害時に速やかに代替機で実行可能にするという、"コールドスタンバイ"の構成を取るケースも多いのではないでしょうか。 この場合、サーバ障害の度にマニュアルオペレーションが発生し得ます。 例えば Apache Mesos のクラスタ上で動作する Chronos を用いれば、高可用性のあるジョブスケジューラ・システムを構築することは可能です。 しかし、そこまで大掛かりなシステムを構築したくない、というケースもあるでしょう。 本トークで紹介する Koyomi を使うことで、 Mesos

webアプリケーションの開発・運用にはトラブルがつきものです。 どうしても回避できないトラブルもありますが、事前にしっかりと考えておくことによって未然に防ぐことができるものも多いでしょう。 しかしながら実際に何に気をつけないといけないか、何を考えておかないといけないかはその時々によって大きく変わってきます。また置かれている環境によっても異なってくるでしょう。 本トークでは一例として私が今までwebアプリケーションのコードを書いて経験してきたことを基に、特定状況下でどういうことを考えどういうところに気を配りながらwebアプリケーションのコードを書いているかについてお話します。 大きく分けて3つのトピックを予定しています。 仕事のコードを書く時に考えていること 趣味のコードを書く時に考えていること 仕事と趣味のコードどちらでも共通して考えてること 各トピックでは下記キーワードに関連した話をしま

概要 最近はあの企業が go を採用した、この OSS も go 使っているのかのような話を頻繁に聞くようになりました。 go は（個人的には）取っ付き易い言語だと思いますが、いざアプリケーションやライブラリを今までのように書いてみようと思うと、 perl のあれがない オブジェクトじゃない テストが独特 channel, goroutine など特有の機能の登場 そんな自由じゃない なんか色々手間でめんどくさい ... とか のような事に直面することがあるかと思います。（良い点でもあるんですが） このトークでは、perl/go でのアプリケーションやライブラリの開発を比較しつつ、こういう点で嵌った、こうしたほうが良いかなということを広く浅く共有出来ればと思います。 トピック go, perl editor testing waf cli とか

一般的にウェブサービスはその事業フェーズによってチームの規模も変わり、優先すべきことや開発の効率的な進め方が変わっていきます。 本トークでは、私がサービスの成長に伴って感じるようになった課題と、その改善を目指してテストやコードのリファクタリングで試行錯誤した事について話します。 実際に業務で使っている Perl + JavaScript での話にはなりますが、できるだけ言語特有の話ではなく一般的なウェブサービス共通の話として話すことができればと思っています。 Topics（予定）: テスト テストを書きやすい環境を作り、テストを書くことへのハードルを下げる テストの自動化と CI Docker を利用したテスト実行環境の分離 テスト実行時間の短縮のための工夫 API ドキュメントとテストのいい関係 etc. リファクタリング 静的改正による不要なファイルの検出 片手間から脱出するためのフロ

TL;DR 現在開発版の MySQL 5.7 には、MySQL 5.5, 5.6時代にはなかった罠がたくさんあります。 日本語情報、現段階では少ないです。5.5時代の情報を当たって悲しい思いをする人が一人でも減ってくれるように、動作が大幅に変わるところをメインに紹介します。 4.1以前の16桁ハッシュパスワードは完全に廃止されました。 4.0なんて何年前だよって？ 残念、5.6の時にもちらほら出てきました。 どうしてそうした、default_password_lifetimeの暗黙のデフォルト360。 何も知らずにこのままいくと、移行から(あるいは、新規投入から) 360日でアプリケーションが止まる罠。 厳密なsql_modeがデフォルトに。 カジュアルにワーニングを握りつぶしてdisられていたMySQLが厳密にエラーを運用しだしてまたdisられるのもまた一興。 あふれると取り返しがつかな

POE、AnyEventと経て開発してきた個人サービスのPerlスクリプトをHaskellで書き換えた経験をもとに、Haskellを使ったアプリケーション開発の基礎的な内容を解説します。主に以下のトピックを含みます。 WEBサーバ JSON, XML 非同期処理 書き直す際の障壁 (IO、ループ、正規表現、グローバル変数、etc) (I rewrote my Perl and AnyEvent script in Haskell. Based on this experience, I talk about the application development in Haskell.)

私は Yahoo JAPAN に所属し YDN (Yahoo!ディスプレイアドネットワーク) を担当しています。 先日、この YDN の crawler を perl で一から書き直しました。 これまでの crawler のコードといえば、いわゆるレガシーコードと化していて、開発者の多くがそのコードに触るのに二の足を踏んでいる状況でした。 一方、レガシーコードとは言っても、それは要求されている仕事をなんとかこなしており、だからこそ長らく放置されてきました。 おそらくみなさんの会社にもこういったコード、システムは少なからずあるのではないでしょうか。 私は、このレガシーコードを一から書き直しました。これにどれほどの意味があるのか、という疑問も当然わきます。実際、書き直しているとき何度も自問自答しました。また一方で、以前のプログラムよりいいプログラムが本当に自分に書けるのかという不安もありました

When an organization grows, the database(s) it may reach a point where it will be reaching one or more of its resource limits. Action will be needed, and one of the solutions is to use a sharded setup; that is, having several databases with identical structure, and data residing in one (or subset) of the databases. At Booking.com, we have several sharded databases. In this talk, we will look how w

運用に載せるためのアプリケーションコードは、機能要件とは別の所にある非機能要件であって*運用の肌感*がわかっていないと要件を出すのは難しい。 本トークでは、その肌感を掴むために、ウェブアプリエンジニアからインフラエンジニアに転籍し経験を積んだ私が、その集大成としてアプリケーションを書く場合、またレビューをする場合に気を付けているポイントについて知見を共有します。 パフォーマンスチューニングはもちろん、自動再起動など様々なポイントについて、その理由も含めリストにして提供します。 アジェンダ なぜ運用を楽にする必要があるのか 運用を楽にするためのコード Graceful Restart 都度接続 or 再接続 自動メモリ解放 ログローテーション ログ 自動 fail over パフォーマンス改善 パフォーマンス解析 運用を楽にするためにかけるコストは*割に*あうのか 自己紹介 DeNA, Co

概要 2015年初頭、AWS上で運用しているとあるゲームのチームにアサイン。 「今の業務を何とか改善して人の手をあけてくれ」という指令の元行動を開始 EC2のインスタンス一覧を見ると何につかっているかよくわからないサーバ達がいっぱい。 色々聞いたり見ていくとデータ調整や新規開発に利用しているようだ。 日々チャット上で「この環境今◯◯のために使ってます」「ここは今空いてるんだっけ？」という会話が繰り広げられる。 さらに中身を覗いてみると、入ってるM/Wが違ったりApacheの設定が違ったり。 そんなカオスな状態を解決させるべくDockerを使った新環境を構築。その内容と良い所と悪い所をお話します。 トーク内容の予定 Docker? 新環境導入前のカオスな環境について なぜカオスになっていったか 運用面の問題点 解決させるために必要なこと 新環境について Dockerを利用する理由 バージョン

トーク概要 様々なプロビジョニングツールが台頭する昨今ですが、その中で自分達の状況にフィットしたツールを選択することは重要です。 本トークでは、Webアプリケーションエンジニア兼オペレーションエンジニアの私がどのような理由でitamaeというツールを選択したか、バックグラウンドと共に紹介します。 そして、プロビジョニングツールitamaeの紹介とともに、Serverspecによるテストについても簡単に説明します。 なお、本トークを聞く際にitamaeやServerspecについての前提知識は必要ありません。 トピックリスト（予定） 前半 管理台数などバックグラウンドの紹介 どの程度の規模で実行しているか Chef Soloからitamaeへどのようなタイミングで切り替えを行ったか 切り替えたことによって変わった点 後半 itamaeの使い方 簡単なitamaeの使い方 ロールによって実行す