2014-06-09

Railsのバッチ処理のコツ

はじめに

Railsでギョーミーな仕事を行う上で欠かせないのがバッチ処理です。日々上位システムから送られてくる膨大なデータを迅速に取り込み、集計処理を行いDBに格納する。上位システムは何層も構成されており、我々が集計処理に使える時間はエンドユーザーが出社してくるまでの数時間... みたいなシチュエーション無いですか？

今回はバッチ処理を行うコツについて書いてみようと思います。

想定される処理
1. CSVファイルの取り込み
2. 集計処理
3. 集計結果をDBに格納
普通にrake taskを書いて処理できてれば今回の記事は必要ありません。そっとブラウザを閉じて下さい。そうでない場合、多くの人が直面する問題は次のようなものが考えられます。
1. IDのオーバーフロー
2. メモリが食いつぶされてバッチ処理が停止
それでは順番に説明します。

IDのオーバーフロー

大量のデータを日々のバッチで取り込んでいる場合、IDがオーバーフローしてしまう可能性があります。IDの最大値はINT型で2147483647もあるので通常利用している範囲ではオーバーフローすることは考えなくても(※1)大丈夫です。しかし、データの取り込みは追記だけとは限りません。何かの条件でDELETE & INSERTする場合、ID列の寿命は思っていたより早く尽きてしまうでしょう。

※1 毎日10万件のデータを取り込んだとして58年持つ計算。

そんな場合は思い切ってID列を削除してしまいましょう。

# migrationの定義
create_table :sales, :id => false do |t|
  t.references :customer
  t.date :sales_date
  t.decimal :total_sales
end
add_index :sales, [:customer_id, :sales_date], unique: true

IDを削除することの弊害

IDを削除することで、IDのオーバーフローに怯える必要は無くなりました。ActiveRecord::Baseのwhereメソッドによる検索も普通に使えます。findメソッドによるID検索が使えないだけだと思っていると、大きな落とし穴が待ち構えています。それはUpdateができないことです。この問題を解決するためにはcomposite_primary_keysというgemを利用しましょう。 Modelに次のようにキーを定義することでUpdateが可能になります。

class Sales < ActiveRecord::Base
    self.primary_keys = :customer_id, :sales_date
end

メモリが食いつぶされてバッチ処理が停止

初めは快調に処理が進んでいたのに、だんだん遅くなって停止してしまう。こんな経験はないでしょうか？

f:id:tech-kazuhisa:20140609210754j:plain

▲こうなるともうお手上げ

メモリの消費をチェック

Linuxであればfreeコマンドでメモリの消費をチェックしてみましょう。

$ watch free -m

             total       used       free     shared    buffers     cached
Mem:          8000       6998       1001          0        340       2346
-/+ buffers/cache:       4311       3688
Swap:        10063        414       9649

バッチ実行中にbuffers/cacheのfreeの値がどんどん減っていくようであれば、あなたのバッチ処理は何かがおかしいです。

大きなselectを行わない

Sale.all.each do |sale|
  # 略
end

全てのデータを一気に取得して処理するのではなく、可能であれば小さい単位に分割しましょう。

Shop.all.each do |shop|
  Sale.where(shop_id: shop.id).each do |sale|
    #略
  end
end

適切な粒度でバルクインサートを行う

このような処理はメモリを食いつぶす原因となります。

Sale.all.each do |sale|
  OtherSale.create!(total_sales: sale.total_sales, ...)
end

ActiveRecord.importを利用してバルクインサートを行いましょう。その際に、全てのレコードをインサートするのではなく適切な粒度になるよう気をつけましょう。

Sale.find_in_batches do |sales| # 1,000件ずつ取り出す
  list = []
  sales.each do |sale|
    list << OtherSale.new(total_sales: sale.total_sales, ...)
  end
  OtherSale.import list
end

最後に

バッチ実行中にだんだん遅くなっていく現象は、テスト段階では気づきにくいものです。本番運用が始まる前にかならずダミーデータを作成して検証を行うようにしましょう。

2014-04-26

Jenkinsでmaster-slave間の通信が不安定なときはslave.jarの起動オプションを疑え

現在、awsのspot instanceを利用してRailsプロジェクトのテストを並列実行しようと試行錯誤しています。

なぜだかmaster-slave間の通信が不安定で困っていたのですが、ようやく打開策を見つけました。

症状
- slave側のテストの状況がモニタリングできなくなる
- slaveの処理が止まっているわけではないみたい
- nodeの接続がすぐに切れるわけではないが、しばらくすると切れてしまう
ログの状況
- 不安定なときのnodeのログは次のようになっていました。

[04/24/14 20:29:44] [SSH] ip-172-16-2-101.ec2.internal:22とのSSHコネクションをオープン
[04/24/14 20:29:44] [SSH] 認証成功
[04/24/14 20:29:45] [SSH] リモートユーザーの環境:
AWS_AUTO_SCALING_HOME=/opt/aws/apitools/as
AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon
AWS_ELB_HOME=/opt/aws/apitools/elb
AWS_IAM_HOME=/opt/aws/apitools/iam

(略)

[04/24/14 20:29:45] [SSH] javaのJavaバージョンをチェック
[04/24/14 20:29:45] [SSH] java -version returned 1.7.0_55.
[04/24/14 20:29:45] [SSH] sftpクライアントの開始
[04/24/14 20:29:45] [SSH] 最新のslave.jarをコピー中...
[04/24/14 20:29:45] [SSH] 404,201 バイトコピー.
Expanded the channel window size to 4MB
[04/24/14 20:29:45] [SSH] スレーブのプロセスを開始: cd "/media/ephemeral0/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Slave.jar version: 2.39
これはUnixのスレーブです。
Effective SlaveRestarter on ip-172-16-2-101.ec2.internal: null
Slave successfully connected and online


Apr 24, 2014 9:28:47 PM hudson.slaves.ChannelPinger$1 onDead
INFO: Ping failed. Terminating the channel.
java.util.concurrent.TimeoutException: Ping started on 1398342287626 hasn't completed at 1398342527626
        at hudson.remoting.PingThread.ping(PingThread.java:120)
        at hudson.remoting.PingThread.run(PingThread.java:81)

Ping failed.だそうです。

解決方法
- slave.jarの起動オプションに-textをつける。具体的には[Jenkinsの管理] - [ノードの管理] - (ノードを選択) - [設定] でSuffix Start Slave Commandに-textをつける。頭にスペースを入れること！

f:id:tech-kazuhisa:20140426193629j:plain

Distributed builds - 日本語 - Jenkins Wiki によると
スレーブ起動のために、telnetのような (バイナリデータを直接扱えない) binary-unsafe なリモート操作用のメカニズムを使っているなら、 slave.jar の実行時に -text オプションを追加して下さい。

とあります。うーん。Macでmaster-slave構成を組んでいた時は何も問題が無かったんだけどな。ともあれ、slaveとの通信が不安定なときはtextモードを試してみましょう。

2014-04-15

xip.ioの便利さに気づく

docker - Vagrantでdokkuを動かす - Qiita この記事の中に出てくるxipってのがよく分からなかった。ググってもこんな人達がたくさん出てきて意味不明。

しかし、しばらくいじってみると使い方がだんだん分かってきた。IPアドレスをサブドメインとして指定すると、IPアドレスを返してくれるサービスらしい。

$ ifconfig
(略)
inet 192.168.68.9 netmask 0xffffff00 broadcast 192.168.68.255
(略)

$ ping 192.168.68.9.xip.io
PING 2kkse8.xip.io (192.168.68.9): 56 data bytes
64 bytes from 192.168.68.9: icmp_seq=0 ttl=64 time=0.054 ms
64 bytes from 192.168.68.9: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 192.168.68.9: icmp_seq=2 ttl=64 time=0.100 ms

$ ping konami.192.168.68.9.xip.io #頭に文字を付けてもよし
PING konami.2kkse8.xip.io (192.168.68.9): 56 data bytes
64 bytes from 192.168.68.9: icmp_seq=0 ttl=64 time=0.059 ms
64 bytes from 192.168.68.9: icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from 192.168.68.9: icmp_seq=2 ttl=64 time=0.079 ms

手元でVirtualHostによるアプリ切り替えが便利そう。って、ここまで書いて思い出したけど昔Powを使ってた時にちらっと見たような気もするな〜。

2014-02-01

1ヶ月間ソーシャルデトックスしてみて思ったこと

2014年1月はTwitterをほぼ利用しなかった。MacOS XのDockからTwitterを削除し、Android端末のホーム画面からもTwitterアイコンを削除し「見ない」「つぶやかない」を実践した。

きっかけは「キラキラッター」

「アイカツ！」という女児向けアニメはご存知だと思う。念のため説明しておくと、主人公「いちご」、その幼馴染「あおい」がアイドル養成学校「スターライト学園」でカードを集めながら仲間とともにトップアイドルを目指すという熱いスポ根アニメだ。 2013年の年末、ふとしたきっかけでこのアニメをまとめてDVDで1話から観てたのだが、第7話「つぶやきにご用心」という話で私の中に稲妻が走った。 7話のあらすじはこうだ。

いちごとあおいはそれぞれ別々のオーディションを受ける。ライバルへの対策として「キラキラッター」での情報集めに夢中になるあおい。だが夢中になりすぎるあまり、親友いちごの言葉は届かなくなる。オーディション当日「オーディションがんばって！」と笑顔で声をかけるいちごに対して、あおいは何の言葉もかけることができなかった……

TL追うのってそんなに重要なことなんスかね？

例えばある人と一緒にご飯を食べに行くとする。その人はろくに話もせずにTwitterのリロードを繰り返している。その行為に違和感を感じていた。（ま、私もその間リロードしてたりするわけですが）一緒の時間を共有している時くらいリアルで話そうぜと。Twitterを眺める時間は楽しい。楽しいが、リアルで共有している時間を削ってまでTwitterの情報を漁ることにそれだけの価値があるのだろうか。

改めて見返してみた

自分のTLを冷静に読んでみた。

診断メーカー
社畜ネタのグチ
意味がわからない内輪ネタ

もちろん有益な情報も存在するが、私にとってどうでも良いような話題に埋もれてしまっている。

自分のつぶやきは？

……やっぱりどうでもいいような、くっだらないことばかりつぶやいてた。これシェアする意味あるの？

Twitterを断ってみてどうだったか

実は2013年秋ぐらいから徐々にTwitterを見る回数を意識して減らしていたので、完全に見ないでいることもそれほど苦痛ではなかった。普段のリアルの会話のネタはTLから直に拾い上げなくても、翌日になれば、はてブのホットエントリーに入ったり、Gunosyで配信される。ちなみにTwitterから定期的に配信される「◯◯他n人からのツイートがありました」というメールは、ほとんどがはてブの記事なので大して役に立たなかった。一方、気になる人の動向を追うことができないのは、非常に不便に感じた。

自分が欲しかったもの

はてブやGunosyで話題になるネタはTwitterで見る必要はない。何度もRTされ、話題になり洗練されたものだけが翌日届けば良い。そうではなくて「離れた場所にいる人が何をしているか」っていうことが本当に知りたかったんだ。あー、なんて当たり前のことなんだろう。

これからどうするか

近場にいる「リアルな知り合い」のフォローは外していいと思っている。近いんだからリアルに話したいし、たまに出会うから「最近どうよ？」って話もできる。何の情報でもシェアするのは好みじゃない。むしろ、よく「読む」必要があるのは遠隔地にいる人だと思った。

自分のツイートに関しては「シェアする必要性」を考えて行うようにしたい。考えたことを口にする前に、頭のなかで一旦保留にするのと同じだ。頭に浮かんだことをそのままツイートするのは愚かなことだと思う。

私は「アイカツ！」の蘭ちゃんのように「ネットでだれかと繋がってたいとは思わない」とピシャリと言えるほど、ネットと無関係な生活を送っていない。SNSが当たり前にあるからこそ、一旦デトックスして付き合い方を考える期間をとってみて良かった。

2014-01-12

久々にcapybara-webkitをLinuxで使ったら高速になってた

capybara-webkitをLinuxで使うと、なぜだか実行速度が遅いという問題があったんだけど最近になって改善されたみたい。めでたい!!

capybara-webkitを使うためにはQtをインストールする必要があります。OSはScientific Linux6.4の例です。

$ wget http://releases.qt-project.org/qt4/source/qt-everywhere-opensource-src-4.8.5.tar.gz
$ tar zxvf qt-everywhere-opensource-src-4.8.5.tar.gz
$ cd qt-everywhere-opensource-src-4.8.5
$ ./configure
$ make (時間がかかる。一晩覚悟しろ)
$ sudo make install

インストールが完了したら.bashrcにでもPATHを追加しておきましょう。

$ vi ~/.bashrc

PATH=/usr/local/Trolltech/Qt-4.8.5/bin:$PATH:$HOME/.rvm/bin

何回かMacOS XとScientific Linux6.4でCucumberを実行してみたのですが、実行時間の誤差はほとんどありませんでした。これで高価なMacを購入しなくてもインテグレーションテストをガンガン実行できるぜ！

追記(2014.01.27)

やっぱり勘違いでした。仮想環境含め様々なマシンで検証したんですが、高速なビデオカードを搭載したマシンだと動作が高速な気がします。

2013-09-02

schema.rbじゃなくてstructure.sqlでスキーマ情報を管理しよう

rails

先日開催された関西Ruby会議05に参加された方お疲れ様でした。色々な方とお話出来て非常に楽しい1日でした。
さて、「No Sugar 〜私はどのようにしてRails開発に貢献したか〜」という発表をされた @kennyj_jp さんから懇親会で面白い話を聞くことができました。

schema.rbでスキーマ情報を管理するのは限界があるのではないか？

先日私がリリースしたpg_index_where について失礼ながら意見を聞いてみました。ポイントはスキーマ情報をdumpする処理について現在の実装方法で正しいのかという点。
そもそもユニークインデックスにwhereを付けるようなRDB固有の命令については、Rails標準のschema.rbで管理し続けるのは限界があるのではないかというお話でした。

Railsの設定でdump方法を変更できる

次のようにapplication.rbの一部をコメントアウトするとschema.rbではなくstructure.sqlというSQL文が出力されるようになります。

    # Use SQL instead of Active Record's schema dumper when creating the database.
    # This is necessary if your schema can't be completely dumped by the schema dumper,
    # like if you have constraints or database-specific column types
    config.active_record.schema_format = :sql

ちょっと動きを確認してみましたがcreate indexにwhereを付けた場合も正しくSQLが作成されてました（あたりまえか）。
このオプションを有効にした場合、元々あったschema.rbは削除してもよさそうです。

使用しているRDB固有のスキーマ定義を設定してて、schema.rbに正しく出力されないとお嘆きの方は設定を変更することをオススメします。

2013-07-31

AWSのSESでDKIMを設定する(さくらインターネットのドメイン管理編)

aws ses

AWSのSES(メール配信サービス)を使うのは簡単なのですが、そのままの設定だとメール差出人の欄に

amazonses.com 経由

と表示されてしまいます。
これを防止するためにDKIMという仕組みがあるのですが、さくらインターネットのドメイン管理画面でCNAMEを設定する時にハマったのでメモ。

SESの設定画面でDKIMの設定画面を開くと「CNAMEをこう変えてくださいよ」という設定が表示されると思います。
Route53を使っていればボタンひとつで設定完了なのですが、私はさくらインターネットでドメイン管理をしているため次のように設定しました。

ポイントは2つ。

CNAMEを登録する際にDNSチェックは「しない」を選択する。
CNAMEのValueの最後に.(ドット)を付ける

しばらくするとSESで認証されると思います。