目黒のカレー屋さん＆家カレーを長く楽しむ方法

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

このエントリは、カレー Advent Calendar 2015 17日目のエントリです。
17日、、、です、、、。

どうもどうも乙カレー様です。桑野です。
3日ほど過ぎてしまいましたが、、、カレーアドベントカレーンダーを更新したいと思っております。

更新しないと、

@kuwa_tw この似非カレー野郎！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

— Hiroaki Sano (@la_luna_azul) 2015, 12月 18

とか

@la_luna_azul @kuwa_tw ビジネスカレー野郎！！！

— ジャック・ニコルソン (@kakerukaeru) 2015, 12月 18

ついには、

@kuwa_tw @kakerukaeru カレーアドベントカレンダーを書くまでは人権はないですよ( ◠‿◠)

— Hiroaki Sano (@la_luna_azul) 2015, 12月 18

@kuwa_tw @la_luna_azul ビジネスカレー野郎に人権はないって事かな？( ◠‿◠)

— ジャック・ニコルソン (@kakerukaeru) December 18, 2015

と罵られるのです。カレーの世界は怖い。

というわけで震えながらはじめましょう。人権を得るための旅の始まり。

目黒のカレー屋さん

まずは目黒のカレー屋さんについて簡単に。

タダカリー

まずはこれ、タダカリーさんです。ここの豆の入ったキーマカレーがとても好きなのです。
おしゃれな店員さんの作るおしゃれな店内で盛り付けが目にも美味しいおしゃれなカレーを食べることができます。それは僥倖。

ルソイ

次はルソイ、ここはガッチガチのインド料理屋さんといった雰囲気のカレー屋さんです。
チキンカレーも美味しいし、ナンも美味しいです。
ここは夜に来てタンドリーチキンを肴にインドビールなんか飲んじゃうのも良いお店です。

辛くすると半端無く辛いらしい。という噂なので、辛いのが好きな人には僥倖。

シャプラ

Devsumiの聖地からおそらく一番近いカレー屋さん。
ここはテイクアウトのランチが、カレー＋サラダ＋ナン＋ライスで750円という破格なところ。
正直シャプラという店名はよく知らなくて、「パルマさんのカレー」の所のカレーと言う認識しかありませんでした。。

店員のおっちゃん(パルマさん？)による挨拶の勢いがすごいのでたまに気後れしますｗ
でも結構美味しいのオススメ。コスパ最強伝説。僥倖。

とりあえず現状ではこんな感じですね。今後もあったら追加していきたいとおもう、僥倖。（写真撮り忘れた。。。）

家カレーをなるべく長く楽しみたい。

次に、家カレーをなるべく長く健康に楽しみたい人について。
家カレーは市販のルーを使ったカレーということです。

1日目、2日目以降でまとめていきましょう。

1日目

1日目は家カレーそのものの味を楽しみたい。日本のカレーは美味しい。そういう気持ちで頑張っていきたい。
ただ、なるべく健康に楽しみたい。

そんなあなたに、プライムジャワカレー。これは油分が少ない。
今は粉末タイプになっているんですが、これは若干改悪感はあって、前は粉末タイプではなくて通常のルーになっていたのでもっと美味しかったと思う。

ハウス プライムジャワカレー 中辛 117g

市販のカレーとはいえ適当につくらず、ちょっと気をつけると更に美味しい。こんな感じ。

• 野菜を炒める前に、オリーブオイルをスライスにんにくで香りづけする。
• 肉（ぼくは豚バラが好きです）を投入する前に塩コショウで下味を付ける（塩少なめ、胡椒多めが好み）
• ル・クルーゼとか圧力鍋でしっかり柔らかく煮詰める

これをやるだけでも大分違う。
あー美味しかった。よっぽど大食いじゃなければきっとまだ余ってるでしょう。次の日もっと楽しみましょう。

2日目以降

2日目のカレーはもっと美味しい。これは定説ですが、実際真実ですね。
ただ、もっと楽しみたい。楽しみましょう。

これを使います。（テレレレッテレー）GABANの純カレー！

ギャバン 純カレーパウダー丸缶

純カレーをつかうことで更にカレーが復活しますお。
お湯を100CC〜200CC投入して、純カレーを更に投入する。
しばらく煮込んで味見して完成。

元のカレーはtheおうちカレーって味だったのが、純カレーを入れることでシャープな味になります。
プライムジャワカレーがそもそもそんなに好きじゃない場合には1日目にもう入れてちゃいましょう。

さらに、おこのみで、食べる時に醤油を入れればちょっと和風になりますし、とろけるチーズをいれてもいいです。じゃがいもスライスを耐熱皿に敷き詰めてカレーのルーを流し込んで上にとろけるチーズを敷いて、粉チーズをまぶすとカレーグラタンにもなります。何度でも楽しめる。
具も少なくなっていると思うので、コロッケなり、唐揚げなりを追加してもOK。無限の可能性です。まさに銀河。

ああ、、、いつまでも楽しんでいたい、、、そんな気分です。

以上です。

正月三が日、おせちにあきたらカレーもね！
で、カレーを食べる方はいらっしゃるのではないでしょうか。スパイスから作るのも美味しいのですが、手軽に市販の物の楽しみ方を模索してみるのも良いかもしません。

ではでは！(∩´∀｀)∩

キン肉マン　アクションフィギュアシリーズ　No.25　カレクック

DEXでもうMongoDB職人は要らなくなるの巻

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

このエントリは、MongoDB Advent Calendar 2015 18日目のエントリです。

どうもどうも乙カレー様です。桑野です。
MongoDB on AWS的ななにかを書こうとしたのですが、その前にこれ紹介したことなかったなーと思いDEXの紹介しようと思います。

DEXとは

あのMongoDBならこの人達のMongolabさんの作った、MongoDBのSlowlogなどから適切なINDEX設定をRecommendしてくれるプロダクトになります。
神様仏様Mongolab様。

インストール

pipで簡単。

$ pip install dex

コマンドライン手順

基本的には、MongoDBのURLと、Logのパスを指定していきましょう。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 0,
        'linesProcessed': 1,
        'linesPassed': 149
    },
    'results': []
}

ほいできました。

データベース例

データベースはこの前 作ったデータベースにデータを足して作ってみましょう。
適当に1000万レコードほど追加しました。

$ mongo d1
(snip)
> db.t1.find().count()
10110005

そこでもう一回DEXを実行してみますが、まだクエリを実行していないので当然何も出ません。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 0,
        'linesProcessed': 1,
        'linesPassed': 149
    },
    'results': []
}

では、Indexのきいていないクエリを打ってみましょう
どれも10秒以上かかります。重い。

$ mongo d1
# クエリ1つ目
> db.t1.find( { "nosql" : "mongodb"} )
{ "_id" : ObjectId("567365cf760961552b000001"), "created_at" : ISODate("2015-12-16T13:04:10Z"), "name" : "kuwa_tw", "nosql" : "mongodb", "price" : 10 }
# クエリ2つ目
> db.t1.find( { "name" : "saeoshi"} )
{ "_id" : ObjectId("567365cf760961552b000005"), "created_at" : ISODate("2015-12-16T13:04:38Z"), "name" : "saeoshi", "nosql" : "voldemote", "price" : 2000 }
# クエリ3つ目
> db.t1.find( { "price" : { $gt: 9000 } } )
（いっぱい出たのでsnip）
>
# クエリ4つ目：複合条件
> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } )
>

そうしたらそこでもう一回DEXを実行してみましょう。
そうすると、重かったクエリをピックアップして、どのようなインデックスをはればいいのかRecommendしてくれます。これは素晴らし。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 7,
        'linesProcessed': 7,
        'linesPassed': 201
    },
    'results': [
        {
            'queryMask': '{"$query":{"name":"<val>","price":{"$gt":"<val>"}}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"name": 1, "price": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"name": 1, "price": 1}, {"background": true})'
            },
            'details': {
                'count': 3,
                'totalTimeMillis': 52289,
                'avgTimeMillis': 17429
            }
        },
        {
            'queryMask': '{"$query":{"name":"<val>"}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"name": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"name": 1}, {"background": true})'
            },
            'details': {
                'count': 2,
                'totalTimeMillis': 35758,
                'avgTimeMillis': 17879
            }
        },
        {
            'queryMask': '{"$query":{"nosql":"<val>"}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"nosql": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"nosql": 1}, {"background": true})'
            },
            'details': {
                'count': 1,
                'totalTimeMillis': 17983,
                'avgTimeMillis': 17983
            }
        },
        {
            'queryMask': '{"$query":{"price":{"$gt":"<val>"}}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"price": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"price": 1}, {"background": true})'
            },
            'details': {
                'count': 1,
                'totalTimeMillis': 17488,
                'avgTimeMillis': 17488
            }
        }
    ]
}

ついでにexplainもしてみましょう。

> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } ).explain()
{
        "cursor" : "BasicCursor",
        "isMultiKey" : false,
        "n" : 0,
        "nscannedObjects" : 10110005,
        "nscanned" : 10110005,
        "nscannedObjectsAllPlans" : 10110005,
        "nscannedAllPlans" : 10110005,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 18,
        "nChunkSkips" : 0,
        "millis" : 17893,
        "indexBounds" : {

        },
        "server" : "ip-172-31-20-34:27017"
}

当たり前ながらIndexが無いので当然BasicCursorです。

ではRecommendにしたがってIndexを貼ってみましょう

> db["t1"].ensureIndex({"name": 1, "price": 1}, {"background": true})
> db["t1"].getIndexes()
[
        {
                "v" : 1,
                "key" : {
                        "_id" : 1
                },
                "ns" : "d1.t1",
                "name" : "_id_"
        },
        {
                "v" : 1,
                "key" : {
                        "name" : 1,
                        "price" : 1
                },
                "ns" : "d1.t1",
                "name" : "name_1_price_1",
                "background" : true
        }
]

はいIndexれましたね。
ではもう一回explainしてみましょ。
爆速！！！

> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } ).explain()
{
        "cursor" : "BtreeCursor name_1_price_1",
        "isMultiKey" : false,
        "n" : 0,
        "nscannedObjects" : 0,
        "nscanned" : 0,
        "nscannedObjectsAllPlans" : 0,
        "nscannedAllPlans" : 0,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 0,
        "nChunkSkips" : 0,
        "millis" : 0,
        "indexBounds" : {
                "name" : [
                        [
                                "kakerukaeru",
                                "kakerukaeru"
                        ]
                ],
                "price" : [
                        [
                                10,
                                1.7976931348623157e+308
                        ]
                ]
        },
        "server" : "ip-172-31-20-34:27017"
}

BtreeCursorになってIndex[name_1_price_1]が使われているのがわかると思います。
というわけで、Indexはメモリを食うので一概に貼りまくったらええというわけではないんですが、定期的にDEXを流すことでIndexが使われていないクエリが流れていないかを確認することができます。
簡単に使えるので使っていくと幸せになりますよ。

MongoDB使ってる時点で幸せなのかよくわかりませんがね。。。（怪談的な終わり方）

MongoDB in Action

とある魔術の禁書目録(インデックス) 文庫 全22巻 完結セット (電撃文庫)

MongifyでMySQLからMongoDBへの移行しちゃう

このエントリは、MySQL Casual Advent Calendar 2015 16日目のエントリです。
※このエントリは個人の見解であり、所属する組織の公式見解ではありません

どうもどうも乙カレー様です。桑野です。
前回は、このようなブログを書いてアレだったわけですが、さて今回こそはちゃんとブログ書こうと思ってアドベントカレンダーのページ見なおしたらなんか書いてあるんですよね。

またかよ。MySQLだっつってんだろ。
ということで何書こうかなと思ってたんですが、ネタ記事としてMongifyというRubyのプロダクトでMySQLからMongoDBへの移行しちゃうのをやろうかと思います。
誰得なのかということであれば俺得です(∗ᵒ̶̶̷̀ω˂̶́∗)੭₎₎̊₊♡ｳｹﾄﾚｨ!

今度こそ怒られないかな、、、(;´Д｀)ﾊｧﾊｧ

ちゅーわけでテストテーブル作ってみる。

まずは移行元のMySQLにテーブル作ってみましょ。
適当にインストールから。

apt-get install mysql-server mysql-client
apt-get install libmysqlclient-dev
apt-get install mongodb

mysql> CREATE DATABASE d1;
mysql> use d1
mysql>  CREATE TABLE t1 (
   id INT PRIMARY KEY AUTO_INCREMENT,
   name VARCHAR(20),
   nosql VARCHAR(30),
   price INT UNSIGNED,
   created_at DATETIME
 );
mysql>  INSERT INTO t1 (name, nosql, price, created_at)
   VALUES ("kuwa_tw", "mongodb", 10, now());
mysql> INSERT INTO t1 (name, nosql, price, created_at)
   VALUES ("oranie", "cassandra", 100, now());
mysql> INSERT INTO t1 (name, nosql, price, created_at)
   VALUES ("kakky_h", "hbase", 1000, now());
mysql> INSERT INTO t1 (name, nosql, price, created_at)
   VALUES ("la_luna_azul", "riak", 1500, now());
mysql> INSERT INTO t1 (name, nosql, price, created_at)
   VALUES ("saeoshi", "voldemote", 2000, now());

mysql> SELECT * FROM t1;
+----+--------------+-----------+-------+---------------------+
| id | name         | nosql     | price | created_at          |
+----+--------------+-----------+-------+---------------------+
|  1 | kuwa_tw      | mongodb   |    10 | 2015-12-16 13:04:10 |
|  2 | oranie       | cassandra |   100 | 2015-12-16 13:04:17 |
|  3 | kakky_h      | hbase     |  1000 | 2015-12-16 13:04:29 |
|  4 | la_luna_azul | riak      |  1500 | 2015-12-16 13:04:34 |
|  5 | saeoshi      | voldemote |  2000 | 2015-12-16 13:04:38 |
+----+--------------+-----------+-------+---------------------+
5 rows in set (0.00 sec)

ほいできました。

Mongifyのインストール

Rubyはなんか適当なのでいいけど、2.2.3でやりました。（割愛）
Gemで以下のものをインストール。

gem install bundler
gem install json_pure
gem install activerecord-mysql-adapter
gem install mongify

Mongifyの実行

設定ファイルの作成

接続情報を書いたファイルをdatabase.configとして保存

cat <<'EOF' >./database.config
sql_connection do
  adapter   "mysql"
  host      "localhost"
  username  "root"
  password  "passw0rd"
  database  "d1"
end

mongodb_connection do
  host      "localhost"
  database  "d1"
end
EOF

チェック、worksになったらOK

$ mongify check database.config
SQL connection works
NoSQL connection works

既存のMySQLデータベースの情報を取得

translationコマンドでtranslation.rbとして、DBの情報を書き出す

$ mongify translation database.config > translation.rb

こんなのが出ました。

$ cat translation.rb
table "t1" do
        column "id", :key, :as => :integer
        column "name", :string
        column "nosql", :string
        column "price", :integer
        column "created_at", :datetime
end

MongoDBデータベースへのマイグレーション

processコマンドでマイグレーション

$ mongify process database.config translation.rb
Copying t1 (1/1):                             (5/5) 100% |oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo| Time: 00:00:00
Updating References t1:                       (5/5) 100% |oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo| Time: 00:00:00
Removing pre_mongified_id t1:                 (1/1) 100% |oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo| Time: 00:00:00

みてみませう。

$ echo 'db.t1.find()' | mongo d1
MongoDB shell version: 2.4.9
connecting to: d2
{ "_id" : ObjectId("567164b57609613c3d000001"), "created_at" : ISODate("2015-12-16T13:04:10Z"), "name" : "kuwa_tw", "nosql" : "mongodb", "price" : 10 }
{ "_id" : ObjectId("567164b57609613c3d000002"), "created_at" : ISODate("2015-12-16T13:04:17Z"), "name" : "oranie", "nosql" : "cassandra", "price" : 100 }
{ "_id" : ObjectId("567164b57609613c3d000003"), "created_at" : ISODate("2015-12-16T13:04:29Z"), "name" : "kakky_h", "nosql" : "hbase", "price" : 1000 }
{ "_id" : ObjectId("567164b57609613c3d000004"), "created_at" : ISODate("2015-12-16T13:04:34Z"), "name" : "la_luna_azul", "nosql" : "riak", "price" : 1500 }
{ "_id" : ObjectId("567164b57609613c3d000005"), "created_at" : ISODate("2015-12-16T13:04:38Z"), "name" : "saeoshi", "nosql" : "voldemote", "price" : 2000 }
bye

こうなったら成功です。

どうでしょう。はいっております。ぼくのシェルスクリプトと違って綺麗ですね。綺麗。
ということでありまして、MySQLからMongoDBに移行したい、なんていう珍しい方がおりましたら是非こんな感じで試してみてはいかがでしょうか。

ただし責任は取れませんが、、、（怪談的な終わり方）（今年もかよ）

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

稲川淳二 真相・恐怖の現場 本当の恐怖をナメてはいけない編 [DVD]

MongoDBイン・アクション

サイバーエージェントを退職してました

どうもどうも乙カレーさまです。

この度9/18が最終出社日となり、サイバーエージェントを退職することになりました（籍はもう少しありますが）。

並河さんと退職のタイミングが被っていた事で、きな臭い物を感じていらっしゃる方もいるかもしれませんが、完全に並行で進んでいて、お互いにびっくりした案件になりますｗ*1

サイバーエージェントでやってきたことを思い返すと、入社した当時はまだアメブロもそれほど流行っていたわけではありませんでした。ただサービスを伸ばしていこうという熱量がすごかったことは今でも覚えています。そんな中で様々なサービスのインフラ部分に関わらせていただくことができました（アメーバピグ、ピグライフ、ガールフレンド（仮）、最近ではAWAなど他にも色々）。

Webサービス、会社が育っていく様をほぼ最初から見ることができたのもラッキーだったなと思っています。

それ以外でも色々な勉強会や講演でも発表する機会を頂いたりと、エンジニアブログではIT芸人としての活動や、面白い経験をたくさんさせていただく事ができて、本当に自由な社風には僕のような人間は助けられてばかりでした。幸せでした。

もちろん不満が無い訳ではありませんし、ウェブ上では色々言われることが多い会社ではありますが、そういう話を鼻で笑える位にいい会社だと思っています（そろそろ数年前の総会の写真をネタに使うのは当事者達がかわいそうなのでやめてあげてくださいｗ）。

では何故転職を考えたのか、と言う話ですが、思えば入社したのが2007年1月なので、8年と9ヶ月在籍したことになります。入社した頃はこんなに長くいることを想定していたかと言われれば余り考えていなかったというのが正直な所です。ただ先で書いたような事を行っていく中で、日々楽しく仕事をしていく事ができて、いつの間にか8年もやっていたのか、、、と思っている次第です。

そんな中、自分のキャリアに幅をもたせるため他の世界を見たいという自分、また子供もでき、人生のステージが変わっていく事を感じる自分もいました。この後何年も戦っていく必要がある中で、別のキャリアへ挑戦できるタイミング、時間があまりないと思いワガママを通してしまった部分はあります。

正直いい仲間や同僚達に囲まれた環境を捨てて別の環境に行くことに対して不安がないわけではありませんが、今までやってきたことや、新しくやっていくことを自分の糧にして更に選択肢を増やしていくことは必要なことだと考えています。

最後にこれまで仕事でお世話になった皆様、そしてプライベートでお世話になっている皆様も本当にありがとうございました。
これからも色々あると思いますが、今後ともよろしくお願い致します。

お花と、ぼくのTwitterアイコンのトートバッグ、メッセージ付きのアルバムと本当にありがたいプレゼントでアルバムは何回も見て2828しています。

起業家 (幻冬舎文庫)

卒業 [Blu-ray]

*1:ホントですとか言えば言うほど泥沼になるので言いませんけどホントですｗ

MongoDB3系でWiredTiger使うなら3.0.6以上で使わないと高負荷時に落ちるので注意マン

どうもどうも乙カレー様です。桑野です。
今日はちょっとだけ神妙な面持ち。

MongoDB3系でWT使っている場合に、3.0.6以前のものを使っていたらバージョンアップしましょうって話。

問題

アクセスの増えてきたタイミングから下記のようなログがでてコネクションが溜まってしまう。
その後溜まりすぎてメモリが確保できずにプロセスが落ちる。死。

2015-08-16T09:06:36.012+0000 E STORAGE [conn38726] WiredTiger (12) [1439715996:12678][61157:0x7f105350e700], connection.open_session: only configured to support 20010 sessions (including 10 internal): Cannot allocate memory
2015-08-16T09:06:36.012+0000 I - [conn38726] Invariant failure: ret resulted in status UnknownError 12: Cannot allocate memory at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 49
2015-08-16T09:06:36.013+0000 I NETWORK [initandlisten] connection accepted from 192.168.110.196:20692 #47886 (20559 connections now open)
2015-08-16T09:06:36.013+0000 I NETWORK [initandlisten] connection accepted from 192.168.110.196:20693 #47887 (20560 connections now open)
2015-08-16T09:06:36.014+0000 E STORAGE [conn38650] WiredTiger (12) [1439715996:14701][61157:0x7f105815a700], connection.open_session: only configured to support 20010 sessions (including 10 internal): Cannot allocate memory
2015-08-16T09:06:36.014+0000 I - [conn38650] Invariant failure: ret resulted in status UnknownError 12: Cannot allocate memory at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 49
2015-08-16T09:06:36.015+0000 E STORAGE [conn31890] WiredTiger (12) [1439715996:15938][61157:0x7f12003c2700], connection.open_session: only configured to support 20010 sessions (including 10 internal): Cannot allocate memory
2015-08-16T09:06:36.015+0000 I - [conn31890] Invariant failure: ret resulted in status UnknownError 12: Cannot allocate memory at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 49
2015-08-16T09:06:36.020+0000 E STORAGE [conn38728] WiredTiger (12) [1439715996:20420][61157:0x7f105330c700], connection.open_session: only configured to support 20010 sessions (including 10 internal): Cannot allocate memory
2015-08-16T09:06:36.020+0000 I - [conn38728] Invariant failure: ret resulted in status UnknownError 12: Cannot allocate memory at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 49
2015-08-16T09:06:36.021+0000 E STORAGE [conn1438] WiredTiger (12) [1439715996:21384][61157:0x7f12c63f3700], connection.open_session: only configured to support 20010 sessions (including 10 internal): Cannot allocate memory
2015-08-16T09:06:36.021+0000 I - [conn1438] Invariant failure: ret resulted in status UnknownError 12: Cannot allocate memory at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 49
2015-08-16T09:06:36.027+0000 I CONTROL [conn2503]
0xf5e199 0xefd1b1 0xee386a 0xd80e50 0xd81326 0xd7c7ce 0xd7c815 0xd6af65 0xa84a08 0xa0eab2 0xa0f1ed 0xa02e8d 0xa25425 0xa10a64 0xbd06b4 0xbd0a64 0xb9ef64 0xab5040 0x80fbad 0xf112bb 0x7f133d722182 0x7f133c1eb47d
----- BEGIN BACKTRACE -----
{"backtrace":[{"b":"400000","o":"B5E199"},{"b":"400000","o":"AFD1B1"},{"b":"400000","o":"AE386A"},{"b":"400000","o":"980E50"},{"b":"400000","o":"981326"},{"b":"400000","o":"97C7CE"},{"b":"400000","o":"97C815"},{"b":"400000","o":"96AF65"},{"b":"400000","o":"684A08"},{"b":"400000","o":"60EAB2"},{"b":"400000","o":"60F1ED"},{"b":"400000","o":"602E8D"},{"b":"400000","o":"625425"},{"b":"400000","o":"610A64"},{"b":"400000","o":"7D06B4"},{"b":"400000","o":"7D0A64"},{"b":"400000","o":"79EF64"},{"b":"400000","o":"6B5040"},{"b":"400000","o":"40FBAD"},{"b":"400000","o":"B112BB"},{"b":"7F133D71A000","o":"8182"},{"b":"7F133C0F1000","o":"FA47D"}],"processInfo":{ "mongodbVersion" : "3.0.4", "gitVersion" : "0481c958daeb2969800511e7475dc66986fa9ed5", "uname" : { "sysname" : "Linux", "release" : "3.13.0-46-generic", "version" : "#77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015", "machine" : "x86_64" }, "somap" : [ { "elfType" : 2, "b" : "400000", "buildId" : "32DC52072DB9385642CCB4D2AD2ACDA6E0B87A27" }, { "b" : "7FFFE2AB1000", "elfType" : 3, "buildId" : "88E7559031E488BC215236F4181BD1FAF9A458F0" }, { "b" : "7F133D71A000", "path" : "/lib/x86_64-linux-gnu/libpthread.so.0", "elfType" : 3, "buildId" : "9318E8AF0BFBE444731BB0461202EF57F7C39542" }, { "b" : "7F133D4BC000", "path" : "/lib/x86_64-linux-gnu/libssl.so.1.0.0", "elfType" : 3, "buildId" : "FF43D0947510134A8A494063A3C1CF3CEBB27791" }, { "b" : "7F133D0E2000", "path" : "/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", "elfType" : 3, "buildId" : "379F80D2768BA6A21F52781895EE9F47B34A0A85" }, { "b" : "7F133CEDA000", "path" : "/lib/x86_64-linux-gnu/librt.so.1", "elfType" : 3, "buildId" : "92FCF41EFE012D6186E31A59AD05BDBB487769AB" }, { "b" : "7F133CCD6000", "path" : "/lib/x86_64-linux-gnu/libdl.so.2", "elfType" : 3, "buildId" : "C1AE4CB7195D337A77A3C689051DABAA3980CA0C" }, { "b" : "7F133C9D2000", "path" : "/usr/lib/x86_64-linux-gnu/libstdc++.so.6", "elfType" : 3, "buildId" : "19EFDDAB11B3BF5C71570078C59F91CF6592CE9E" }, { "b" : "7F133C6CC000", "path" : "/lib/x86_64-linux-gnu/libm.so.6", "elfType" : 3, "buildId" : "1D76B71E905CB867B27CEF230FCB20F01A3178F5" }, { "b" : "7F133C4B6000", "path" : "/lib/x86_64-linux-gnu/libgcc_s.so.1", "elfType" : 3, "buildId" : "8D0AA71411580EE6C08809695C3984769F25725B" }, { "b" : "7F133C0F1000", "path" : "/lib/x86_64-linux-gnu/libc.so.6", "elfType" : 3, "buildId" : "30C94DC66A1FE95180C3D68D2B89E576D5AE213C" }, { "b" : "7F133D938000", "path" : "/lib64/ld-linux-x86-64.so.2", "elfType" : 3, "buildId" : "9F00581AB3C73E3AEA35995A0C50D24D59A01D47" } ] }}
mongod(_ZN5mongo15printStackTraceERSo+0x29) [0xf5e199]
mongod(_ZN5mongo10logContextEPKc+0xE1) [0xefd1b1]
mongod(_ZN5mongo17invariantOKFailedEPKcRKNS_6StatusES1_j+0xDA) [0xee386a]
mongod(_ZN5mongo17WiredTigerSessionC1EP15__wt_connectionii+0xA0) [0xd80e50]
mongod(_ZN5mongo22WiredTigerSessionCache10getSessionEv+0x4C6) [0xd81326]
mongod(_ZN5mongo22WiredTigerRecoveryUnit10getSessionEPNS_16OperationContextE+0x3E) [0xd7c7ce]
mongod(_ZN5mongo16WiredTigerCursorC1ERKSsmbPNS_16OperationContextE+0x35) [0xd7c815]
mongod(_ZNK5mongo23WiredTigerIndexStandard9newCursorEPNS_16OperationContextEi+0x55) [0xd6af65]
mongod(_ZNK5mongo22BtreeBasedAccessMethod9newCursorEPNS_16OperationContextERKNS_13CursorOptionsEPPNS_11IndexCursorE+0x28) [0xa84a08]
mongod(_ZN5mongo9IndexScan13initIndexScanEv+0x62) [0xa0eab2]
mongod(_ZN5mongo9IndexScan4workEPm+0x4D) [0xa0f1ed]
mongod(_ZN5mongo10FetchStage4workEPm+0xCD) [0xa02e8d]
mongod(_ZN5mongo16ShardFilterStage4workEPm+0x55) [0xa25425]
mongod(_ZN5mongo10LimitStage4workEPm+0x54) [0xa10a64]
mongod(_ZN5mongo12PlanExecutor18getNextSnapshottedEPNS_11SnapshottedINS_7BSONObjEEEPNS_8RecordIdE+0xA4) [0xbd06b4]
mongod(_ZN5mongo12PlanExecutor7getNextEPNS_7BSONObjEPNS_8RecordIdE+0x34) [0xbd0a64]
mongod(_ZN5mongo8runQueryEPNS_16OperationContextERNS_7MessageERNS_12QueryMessageERKNS_15NamespaceStringERNS_5CurOpES3_+0xA74) [0xb9ef64]
mongod(_ZN5mongo16assembleResponseEPNS_16OperationContextERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0xB10) [0xab5040]
mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0xDD) [0x80fbad]
mongod(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x34B) [0xf112bb]
libpthread.so.0(+0x8182) [0x7f133d722182]
libc.so.6(clone+0x6D) [0x7f133c1eb47d]
----- END BACKTRACE -----
2015-08-16T09:06:36.027+0000 I CONTROL [conn38518]
0xf5e199 0xefd1b1 0xee386a 0xd80e50 0xd81326 0xd7c7ce 0xd7c815 0xd6af65 0xa84a08 0xa0eab2 0xa0f1ed 0xa02e8d 0xa25425 0xa10a64 0xbd06b4 0xbd0a64 0xb9ef64 0xab5040 0x80fbad 0xf112bb 0x7f133d722182 0x7f133c1eb47d

原因

この あたり のISSUEに上がってる物が原因

対応1：cursorTimeoutを伸ばす

cursorTimeoutを伸ばす事で回避できるよってあったんでこちら入れてみた。

mongo> use admin
mongo> db.runCommand({setParameter:1, cursorTimeoutMillis: 60000})

全く変わらず。

対応2：シャード増やす

一定以上のアクセスが来なければおこらないはずなので、一時的にシャード増やしてみた。

対応は可能だった、一定の効果は（当たり前）だけどコストが(；´∀｀)
まあ一次対応としてはアリ。

対応3：対応後のバージョンに上げる

3.0.6で対応されたから試してみてよって前述のISSUEにあったので満を持してバージョンアップしてみる。
ちなみにMongoDB Cloud Manager（旧MMS）でのバージョンアップは非常に楽チン（ただしMMSには罠がいっぱいあるので癖を覚えるまで辛い）

バージョン上げたタイミングでコネクションが増え続けることもなくなった。
というわけで、新しいのはまだ人柱的な物もよくありますねって話。それもまた楽し。
他の方でも同様の現象で困っている方がいたらバージョンアップ検討しましょう。

バージョンアップ方法はこの辺りが参考になります。

ではでは！

データベース徹底攻略 (WEB+DB PRESS plus)

キャプテン マンゴー 600ml

Terraformを使ってEC2のAutoScalingやろうとしたらちょっとつらいんじゃないかなってなった話

どうもどうも乙カレー様です。桑野です。
びっくりするほどブログ書いてなくてびっくりしてます。半年書いてないやん。

Terraformを使っていたりするんですが、最近EC2のAutoScaleを入れようとして辛いことがあったりしたのでちょっとまとめてみます。

Terraform

Terraformは言わずとも知れたHashicorpさんのプロダクトですね。
インフラ構築をコード化してGithub等でレポジトリ管理することによって履歴管理や、プルリクエストベースの構築ができるのが売りだったりします。

TerraformでのAutoScale時のハマりどこ

端的にいうとこの2つです。

• Terraform経由で実行した際のLaunchConfiguration（イカLC）とAutoScalingGroup（イカASG）の削除の順番が逆
• LC内のuser_data更新で一網打尽になる

Terraform経由で実行した際のLaunchConfiguration（イカLC）とAutoScalingGroup（イカASG）の削除の順番が逆

何が悪いかといいますと、この2つは依存関係があるので、ASGを削除する前にそれが紐付いてるLCを削除しようとするとまだAttachされてるよってエラーが出て止まるわけです。
なので、ASG->LCの順で削除してくれればいいんだけど、実際には逆でしか動いてくれない。

* ResourceInUse: Cannot delete launch configuration launchconfig-test because it is attached to AutoScalingGroup autoscalinggroup-test
        status code: 400, request id: [12345678-1234-1234-1234-123412341234]

となると。

GithubのIssueとかでも同じような議論があってlifecycle { create_before_destroy = true }をつけたらいいぜって言ってる人もいるけど、作成タイミングの違いだからやっぱりうまく動かない。

LC内のuser_data更新で一網打尽になる

じゃあ2個作って交互に更新して行ったらええんちゃうんかでバージョン管理する。
これでOKでしょ。

# 古いLC
resource "aws_launch_configuration" "launchconfig_test_v1" {
  name = "launchconfig-test-v1"
  image_id = "${var.amis.api}"
  key_name = "${var.aws.key_name}"
  instance_type = "t2.micro"
  security_groups = ["${var.security_groups.asgtest}"]
  iam_instance_profile = "asgtest"
  associate_public_ip_address = 0
  user_data = "${file("user_data/app_userdata.sh")}"
}

# 新しいLC
resource "aws_launch_configuration" "launchconfig_test_v2" {
  name = "launchconfig-test-v2"
  image_id = "${var.amis.api}"
  key_name = "${var.aws.key_name}"
  instance_type = "t2.micro"
  security_groups = ["${var.security_groups.asgtest}"]
  iam_instance_profile = "asgtest"
  associate_public_ip_address = 0
  user_data = "${file("user_data/app_userdata.sh")}"
}

ぼくが気付かなかっただけだけど、この場合はuser_data/app_userdata.shが更新されるとどっちも再作成になって⊂ミ⊃＾ω＾ ）⊃　ｱｳｱｳ!!

* ResourceInUse: Cannot delete launch configuration launchconfig-test because it is attached to AutoScalingGroup autoscalinggroup-test-v1
        status code: 400, request id: [12345678-1234-1234-1234-123412341234]

TerraformでのAutoScale時する時のベストプラクティス？

じゃあどうしたらいいんだって話ですが、一旦色々考えたり話したりした挙句こんな感じになりました。

• ASG, LC, user_dataはバージョニングする
• 追加／削除時の作業順を厳密に指定する
  • 1. user_data作成
  • 2. 新LC, ASG作成
  • 3. 旧ASGの desired_capacity を0にして既存系のインスタンス削除する
  • 4. 旧ASGを削除する
  • 5. 旧LCを削除する

この手順だと実際にApplyするのは、2. 3. 4. 5.で4回です(2. と3. はまとめられますがそれでも3回)。多いですね。

3.の時の設定の状態

# 古いLC
resource "aws_launch_configuration" "launchconfig_test_v1" {
  name = "launchconfig-test-v1"
  image_id = "${var.amis.api}"
  key_name = "${var.aws.key_name}"
  instance_type = "t2.micro"
  security_groups = ["${var.security_groups.asgtest}"]
  iam_instance_profile = "asgtest"
  associate_public_ip_address = 0
  user_data = "${file("user_data/app_userdata_v1.sh")}"
}

# 古いASG（この後削除する）
resource "aws_autoscaling_group" "autoscalinggroup_test_v1" {
  availability_zones = ["ap-northeast-1c"]
  name = "autoscalinggroup-test-v1"
  max_size = 0
  min_size = 0
  health_check_grace_period = 300
  health_check_type = "ELB"
  desired_capacity = 0
  force_delete = true
  launch_configuration = "${aws_launch_configuration.launchconfig_test_v1.id}"
  vpc_zone_identifier = ["${var.subnets.asgtest}""]
  load_balancers = ["${aws_elb.asgtest.name}"]
  tag = {
    key = "Name"
    value = "app-asg"
    propagate_at_launch = true
  }
  tag = {
    key = "SERVER"
    value = "APP"
    propagate_at_launch = true
  }
}

新しい設定

# 新しいLC
resource "aws_launch_configuration" "launchconfig_test_v2" {
  name = "launchconfig-test-v2"
  image_id = "${var.amis.api}"
  key_name = "${var.aws.key_name}"
  instance_type = "t2.micro"
  security_groups = ["${var.security_groups.asgtest}"]
  iam_instance_profile = "asgtest"
  associate_public_ip_address = 0
  user_data = "${file("user_data/app_userdata_v2.sh")}"
}

# 新しいASG
resource "aws_autoscaling_group" "autoscalinggroup_test_v2" {
  availability_zones = ["ap-northeast-1c"]
  name = "autoscalinggroup-test-v2"
  max_size = 4
  min_size = 2
  health_check_grace_period = 300
  health_check_type = "ELB"
  desired_capacity = 2
  force_delete = true
  launch_configuration = "${aws_launch_configuration.launchconfig_test_v2.id}"
  vpc_zone_identifier = ["${var.subnets.asgtest}""]
  load_balancers = ["${aws_elb.asgtest.name}"]
  tag = {
    key = "Name"
    value = "app-asg"
    propagate_at_launch = true
  }
  tag = {
    key = "SERVER"
    value = "APP"
    propagate_at_launch = true
  }
}

で、

この人は何故ここまで頑張ってTerraformを使う必要があるのだろうか、、、っていう部分は聞かないでください！
でもやってて開発者の人にもサーバ構成を共有するとか、インスタンス作成部分とかは作業してこっちでもプルリクエストベースでのコードレビュー（構成レビュー）させてもらえるのは非常にいいと思ってます。

そして、バージョン0.6以降で上手く使えるようになることを祈っていますね。。。

実環境にTerraform導入したら驚いた from Akihiro Kuwano

でも ↑ この時よりは状況良くなっていると思います！貢献していきたい。

テラフォーマーズ 13 (ヤングジャンプコミックス)

じょうじょ

2014年の記事アクセスランキング！

大晦日もおつカレー様です。
2014年によく読まれた記事のランキングを出してみようと思い立ったのであります。

ドゥルルルルルルルルルルル、、、、

ドン！

2014年書いた記事ランキング

順位	タイトル
10	boot2dockerのバージョンアップ時にハマった事やら
9	#isucon 4 に初参加してラッキーパンチで失格になってきました
8	シェルスクリプトだけでMySQLからMongoDBへの移行しちゃう
7	vagrant-berkshelf（非推奨）を無理やりインストールする
6	〜さよなら自作サーバ〜 自作サーバ同窓会に参加＆発表してきました
5	『Chef実践入門』で、今風なChefの使い方を料理してやるぜ（ベタ
4	『開発効率をUPする Git逆引き入門』はGitの情報の洪水に飲まれないための浮き輪みたいなものだね。
3	MySQLでトリガ使って別テーブルに自動でコピる
2	MySQL5.5でパーティショニング使って時系列のデータを分散する
1	Cookbookの管理を楽にするBerkshelfの使い方( ｰ`дｰ´)ｷﾘｯ とか。

2014年見られた記事のランキング

順位	タイトル
10	シェルスクリプトでパイプを使った時の戻り値のとり方
9	『開発効率をUPする Git逆引き入門』はGitの情報の洪水に飲まれないための浮き輪みたいなものだね。
8	MySQLでトリガ使って別テーブルに自動でコピる
7	capistrano, tomahawk などから sudo ができなかった場合に確認する項目
6	curlでボトルネック調査をする
5	MySQL5.5でパーティショニング使って時系列のデータを分散する
4	sedで/の置換をエスケープなしでやりたい
3	ssコマンドのちょっといい所見てみたい。のでネットワーク統計情報がどの程度見られるか試してみた。
2	Cookbookの管理を楽にするBerkshelfの使い方( ｰ`дｰ´)ｷﾘｯ とか。
1	CentOS6で制限されているプロセス最大数を制限解除する

「CentOS6で制限されているプロセス最大数を制限解除する」がアクセスの息が長いですね。CentOS7全盛になったらどうなるかなーって楽しみにしていますｗ
個人的に今年はブログの更新が滞りがちな1年でした。。。
一応ランキングに残せるくらい記事書けましたが来年はもっと書きまくったるとこの記事で刺激を受けましたｗ

というわけで、

来年もよろしくおねがいしまーすʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔ

ゆく年くる年 吟醸酒　720ml