!kiyoka.blog.2012_01 RSSPLAIN

Related pages: !kiyoka.blog.list
55555555545555555555555555555555555555555555552555553355555505555555555555555555555555105555555555555555555555555555555555555555555555555555055555555555555555555555555555555555555055555555555555555555555555555555555055555555555555555555555555550555555555555555555555555555555555555555555555555550555555555555555555505
5

kiyoka日記。NendoSekkaの開発や、最近思うことなど

5

最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list

5

kiyoka.blog_header 

5

このブログを書いている人: 西山 清香(kiyoka) - twitter: @kiyokaEXT

5

5

 

5

 

5

kiyoka.2012_01_27[Debian][Nendo] そろそろNendoのDebian化にとりかかろう

5

 

4

去年の11月くらいから自宅サーバが全壊したり、さくらのクラウドにSumibi.org環境を復元したりしているうちに、もう3ヶ月も経ってしまった。

5

そろそろ、落ちついたし懸案だったNendoをDebian化しよう。

5

 

5

Debian化の話は、KOF2011:関西オープンソース2011EXTで佐々木 洋平さん(twitterアカウント@uwabamiさん)にSekkaをDebian化してみませんかという提案をもらったことから始まっている。

5

そういえば、佐々木さんは今月のSDでDebianの記事を書いていらっしゃるのであった。

5

ヘビーユーザの佐々木さんのDebain愛を感じる。Debianの良さを再認識する良い記事です。

5
 B006P1AE3Q Software Design (ソフトウェア デザイン) 2012年 02月号
5

 

5

話は戻って、SekkaNendoやfuzzy-string-matchなど、いろんなソフトウェアに依存しているので、まずはNendoから順番に攻めていこうと考えている。

5

 

5

Debianはもう10年以上も使ってきたが、Debian標準のrubyはほとんど使ったことが無く、いつもソースからrubyをビルドしていた。

5

deb版のgemsがどういう位置付けなのかわからない状態なので、そのあたりから調べてみるつもり。

5

 

5

以下、KOF2011:関西オープンソース2011EXTの会場で @uwabamiさんにSekkaをDebian化する上で問題になりそうな部分を洗い出ししてもらった時のメモを公開しておきます。

5

誰かの役に立ては本望。非公開にしててももったいないないので。

5

(佐々木さん、当日はありがとうございました、かなり時間経っていますが…すみません)

5

去年中にDebian化できていればUbuntuに入っていくかもというタイムスケジュールだったけれども、また次を狙います。まあ焦らずにいきます。

5

 

5

 

5

deb化についての基本

5

基本はrubygems.orgにアップロードされたgemをdeb化する。

5

 

5

nendoの問題(v0.6.1)

5
gemにRakefileが含まれていない
5
rake testでテストが通るほうがよい。Debian化の提案がスムースに通りやすい。
5

 

5

fuzzy-string-matchの問題(v0.9.1)

5
gemにRakefileが含まれていない
5
rake testで走る RSpecのテストスイートがamatchに依存している。
5
配布したgemがamatchに依存しないように、rake testを修正したほうがいい。
5
gitの開発リポジトリで rake bench でamatchとのベンチマーク比較が走ればよい。
5

 

5

 

5

sekkaの問題(v0.9.6)

5
gemにRakefileが含まれていない
5
rake testでテストが通るほうがよい。Debian化の提案がスムースに通りやすい。
5
sekka-serverがDebian 6.0上のruby 1.9.xで動かない。
2

sekkaのような非標準ライブラリは vendor配下に置かれる。

5

例えば、sekkaconfig.rbは以下に置かれる。

5
 /usr/lib/ruby/vendor_ruby/sekkaconfig.rb
5

そのパスをrequireするコードは、

5
requrie 'rbconfig'
5

3
RbConfig::CONFIG[ 'libdir' ]
3
RbConfig::CONFIG[ 'vendor_dir' ]
5

を使って環境に依存しないようにすること。

5

 

5
辞書データのインストール方法には工夫が必要。
5
 Webマイニングしたデータを含むので、パッケージインストールしてから辞書を取りに行くなど工夫が必要。
5

 

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_25[Cloud][ZFS] ZFSを先延ばしにしていたら、いつのまにか不要になっていた件

5

 

5

ZFSの開発の歴史や、Software Designの記事などを読んで ZFSを使いたいなぁと常々思っていた。

5
 今は読めない(デッドリンク)。残念。Oracleが隠しちゃった?
5
 Solaris 10ファイルシステムZFS誕生エピソード『心を解き放て!』EXT
5

 

5
 こちらは読める
5
 B005JT6E2U  Software Design 2011年 10月号 <雑誌>
5

 

5

自分はFreeBSDではなく使い慣れたLinuxで使いたいと思っていて、待っていたがZFSのライセンスの関係でなかなかLinuxに取り込まれなかった。

5

時は流れて、「さくらのクラウド」を使い初めたら、ストレージがZFSだということを知った。

5
 The Cloud Storage Sun ZFS Storage Applianceがクラウドベンダーに次々と採用される理由とは?|日本オラクルEXT
5
 IIJ(インターネット・イニシアチブ)、さくらインターネット、ITコアなど
5
 のクラウドベンダーや、「ニコニコ動画」を運営するドワンゴのようなSNS事
5
 業者が、次々とSun ZFS Storage Applianceを採用している。
5

 

5

ZFSにしたかったのは、新しくHDDを買ってきたら簡単に既存のパーティションサイズを拡張できそうだというのが一番の理由だった。

5

今は自分でサーバハードウェア資源を持たないので不要になった。

5

クラウドのストレージを使えば、追加ストレージデバイスのサイズ指定も自由自在なのである。

5

 

5

ぼんやりしていると、すぐに下のレイヤーが整備されてくるいい時代なのであるが、仕事としては下のレイヤーは失われていっているわけで、うかうかしてられんなぁとも思うのであった。

5

 

1

COMMENTPranoy

Great comomn sense here. Wish I'd thought of that.

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_24[Cloud][Kahua] Kahuaのメモリリークの調査と対策

5

 

5

Sumibi.orgを「さくらのクラウド」に引越した後もKahuaのメモリリーク問題が解決していなかった。

5

急遽RAM容量の大きなサーバインスタンスに変更して運用回避していたが、このまま無意味なコストの垂れ流しを止めるべく調査した。

5

やっと解決したので調査結果を書いておこうと思う。

5

このまま放置するとコスト削減額はなんと月額4000円にもなるので、ちょいと見過ごすわけにはいかないのである。

5

 

5

概要

5

Sumibi.orgのサイトは1台のサーバインスタンスで構成されており、Sumibi.orgの日本語変換サービスと、WikiシステムのOldTypeが同居している。

5

メモリリーク問題はOldTypeのほうにあり、使っているKahuaフレームワークのworkerのプロセスが膨張していくというのが問題だった。

5

Kahuaのworkerがメモリを圧迫し、結果的にSumibi.orgの変換レスポンスが重くなるという現象が発生していた。

5

 

5

膨張のペース

5

OldTypeを1日程度放置すると、Kahuaのworkerプロセスが1個につき1.2GByteまで膨張する。

5

常時2個のworkerを起動する設定にしていたため、3GByteのRAMでは足りず、swapを2G Byteほど侵食し、OldTypeのサイトがエラーを返すようになる。

5

GoogleやYahooのクローラが来て、サイトのページを一巡するとworkerは1.2GByteあたりになる。なぜか1.2GByte以上には膨張しないようだ。

5

 

5

回避策

5
 さくらのクラウドの料金シミュレーションEXT ページより
5
 HhG0
5

原因究明までの間、「さくらのクラウド」のインスタンスを3GByteから6GByteにして20日間ほど回避した。

5

6GByteならリークしていても問題なく運用できていた。ランニングコストを除いては問題ない(笑)

5

しかし、お金さえ払えば、問題を先送りして普通に運用できるのはクラウドサービスの良いところである。

5

 

5

対策

5

workerを1時間に1回リスタートするスクリプトを動かして対応した。

5

このスクリプトはOT_SITEにサイトバンドルのパスさえ設定すれば、どんなKahuaアプリでも使えるはず。

5
 hourly restarter for Kahua workers(restarter.sh)EXT
5

 

5

結果

5

RAM 3GByteでも約1GByteの余裕を持って運用できるようになった。

5

 

5

青い線はリザルトコード。一番下側に張りついている線は、"200 OK"のリクエスト。

5

"404 Not Found"が大量に出るのは、Kahuaフレームワークが非ブラウザが動的生成されたURLを叩いた時だ、自動的に404にしてくれているようだ。頼もしい。

5
 GCG6
5

 

5

restarter.shをリスタートすると、freeメモリのグラフがキザギザになる。うまくいっているようだ。

5

restarter.shを一定期間止めておいて、再度開始する実験をしたが、freeエリアがいっきに復活している。うまくいっているようだ。

5
 kWkz
5

 

5

 

5

 

5

まとめ

5

OldTypeもしくはKahuaのworkerプロセスが膨張するが、workerプロセスの定期的restartをかければ問題なく運用できる。

5

なぜworkerがそんなにメモリを消費するのかという原因追求はしていない。

5

対処療法的ではあるが対策し、無用なランニングコストを抑えることができた。

5

 

5

COMMENTshiro

workerプロセスは継続をたくさんハッシュテーブルに登録してますが、それのexpireがうまくいってないのかな?

workerが掴んでる継続の一覧をモニタできるようにしてみるといいかも。ちょっと見てみます。

5

COMMENTkiyoka

通常運用で、workerが膨張するのでshiroさんの予想は当たっているかもしれません。

OldTypeはコンテンツページの1行毎に継続が生成されているので、開放されないとするとすぐにworkerが肥大しそうですね。

以前shiroさんもchatonで同様の現象について、他に同じような現象を見た人はいませんかというような書き込みをされていたと思いますが、まさにこれがそうかも。

同じ原因だといいですね。よろしくお願いします。

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_06[Sekka] Sekkaを公開サービスにするという思考実験(サービスの裏側)

5

 

5

先日の、「 kiyoka.2012_01_04[Sekka] Sekkaを公開サービスにするという思考実験(サービスイメージ)」というエントリの続き。

5

今回はsekka-serverをホスティングする側のアーキテクチャをどうするかを書いてみたいと思う。

5

 

5

データベース(案1)

5

Redisで1台のサーバでスループットの総量を確保する。

5

最初はメモリを1GByte程度用意しておけば、数人程度のユーザ辞書は入るだろう。

5

スケールしたくなった時は、Redis clusterを使う。

5

 

5

データベース(案2)

5

Amazon SimpleDBで最大容量と最大処理量を確保する。

5

処理量とユーザー辞書容量はSimpleDB側で自動的にスケールする。30から50ユーザーくらいは収容できるのではないかな?

5

 

5

課題は、SimpleDBには1024byte以上のvalueが保存できないという制限があるので、sekka-serverを変更しないといけないことだろう。

5

 

5

Rack

5

sekka-serverはRackで動いてるが、こちらもスケールする必要がある。

5

一番CPUリソースを使う処理は曖昧文字列検索なので、そこがスケールアウトする必要があるだろう。

5

sekka-serverのサーバ台数を増やす、またはCPUコアが多いマシンにスケールアップして対応する。

5

 

5

ユーザー用管理ページ

5

フレームワークはRailsかSinatra データベースは何らかのRDBで良いのではないかと思う。

5

機能は辞書の登録状況と、登録状況のリセットのみ。

5

ユーザー語彙のマスターデータはユーザーのローカルマシンに ~/.sekka-jisyoとして持っているので、問題があればホスティング側は何度でもリセットすることもできる。

5

 

5

ここまで書いてみて、大袈裟かなー、そこまで使われるかなー、というのが正直な感想。

5

 

5

そこまでしなくても、公開サイトは自分のローカルにsekka-serverをインストールする前にデモ的に使うためのものにするというのが落としどころか。

5

それなら、何の認証も無い状態でsekka-serverのデモをWebAPIで公開するというのが実は落としどころかな。

5

インストールが面倒という問題は、sekka-server専用のVirtualBox仮想マシンイメージで公開するというのがいいのかも…

5

 

5

思考実験をしてみると、スケールするにはまだ考慮が足りないという事実と、実際にスケールさせるためにはかなりランニングコストがかかりそうという事実がわかってくる。

5

なかなか難しい。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_04[Sekka] Sekkaを公開サービスにするという思考実験(サービスイメージ)

5

 

5

ソフトウェアを試してみようと思った時、インストールの容易さが最初に心理的障壁になる。

5

特にインストールがそうとう難しい場合は心理的障壁は上がる。

5

sekka-serverはRuby 1.9.xとTokyo Cabinetがインストールされていればわりとインストールは簡単にした積もりだけど、まだまだ苦労する人もいる。

5

Debian化という話もあって、それも良いことではあるが(@uwabamiさんすみません、ちょっと停滞しています… 気長に待っていてください)

5

 

5

もし2012年現在の技術で、sekka-serverを公開サーバにするならどんな風にするの良いのか考えてみた。

5

誰が得するのか全くわからないエントリだが、まあ書いてみる。

5

Emacsのサーバー側のサービスをクラウド化するなんていう話を書く人間は自分しかいないのでニッチに違いない(笑)

5

 

5

Sekkaの比較対象としてSKKからの乗りかえを狙って作ったので、SKKとする。

5

 

5

 

5

Sekkaの接続アカウント

5

2010年くらいならSekka専用のアカウントをsign upページで取得してもらうのが普通だっただろう。

5

しかし、2012年ならFacebookかTwitterアカウントでログインしてもらうのが良いだろう。

5

WebブラウザでFacebookかTwitterアカウントで管理画面にログインすると、WebAPIの接続トークンが表示されているという方式だ。

5

ちょっと前のtwittering-modeがその方式を取っていたと思う。(最近はWebブラウザは不要になったと思う)

5

 

5

sekka.elのインストール(案1)

5

sekka.elは手でインストールする必要がある。

5

ユーザーが.emassをどんなふうに管理しているかはわからないので、そうせざると得ないかな?

5

 

5

sekka.elのインストール(案2)

5

.emacsにWebからsekka.elを取得して直接loadするemacsを書いてもらう。

5

※ これは、クライアントがオンラインでないといけないのと、sekka.elを他人が差しかえてしまうというセキュリティ上の懸念がある。

5

 

5

どうだろう。

5

必ずオンラインでないといけないという制約があるが、そういう環境は少しづつ増えてきていると思う。

5

後日、サービス提供の裏側を書いてみたいと思う。

5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_03[本][MongoDB] MongoDB: The Definitive Guide 読了

5

1449381561  MongoDB: The Definitive Guide: Kristina Chodorow, Michael Dirolf

5

やっと読み終わった。

5

過去のエントリを見ると11月ごろから読んでいたのがわかる。

5
 kiyoka.2011_11_03[本][MongoDB] MongoDB: The Definitive Guide
5

 

5

英語の書籍にしては意外と早く読み終わった。

5

電子書籍ではなく、紙の書籍を買ったので通勤時間なんかを使えたのが良かったかも。

5

 

5

まだapachelogの集計を試しただけで、本格的なアプリケーションは書いていない。

5

shardingもreplicaもやっていないので、本を読んだだけで終わってしまった。

5
 kiyoka.2011_11_05[MongoDB] MongoDB試用開始
5

 

5

新しいプライベートプロジェクトに使おうと思って読み初めたのだけど、まだ構想がまとまらないので、ここでは一旦置いておく。

5

あまりに構想(妄想)が壮大すぎてスタートできなくなってきており、もしかしたらこのまま妄想が発散してやらないかも…(汗;;)

5

 

5

一方、仕事で使うかどうかだけど、きっと使わないだろうなー。多分。

5

MongoDBの適用範囲がわかってきたので、わかった上で使わないという判断ができそうだ。

5

ログ集計だけならHadoop(またはEMR)なので、よほど巨大なデータを検索したいという要件が無いと使わないし、EC2でもなんでも使ってマシンをたくさん用意してスケールアウトするとなると予算が…という感じになりそう。

5

でも、RAMにデータが乗ってないと一般的いは高速化しないので、結局ありという結論に戻ってくるのかも。

5

今後の課題として置いておこう。

5

 

5

MongoDBの個人的な学習用リポジトリはGitHubで公開しているのでMongoDBでMapReduceをやってみたい人は参考にされたし。

5
 kiyoka/learn-mongodb -GitHubEXT
5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_02[Cloud] 「Amazon EC2」と「さくらのクラウド」の使いわけ

5

CPGG

5

正月休みを利用して、Amazon EC2で遊んでみた。

5

去年の11月ごろ、自宅サーバーが故障する直前までMongoDBを試していたが、クラウド上に復旧するのに時間が空いてしまって今になってしまった。

5

「Amazon EC2」と「さくらのクラウド」の両方を使っているが、その使いわけがわかってきたのでエントリを書いておこう。

5

自分の同じような使いかたをしている人はいないかなとググッてみたが、自分ほどガチで使っている話題はなかったので、書いとく価値はあるかな…

5

 

5

 

5

伸び縮みのメリット(EC2)

5

Sumibi.orgの10MレコードオーダーのapacheログをMapReduceで集計した。

5

後でMongoDBのデータベースが30GByteくらいに膨れあがることに気がついたのでAWSにしておいた良かった。

5

Wiki(oldtype.sumibi.orgドメイン)のapacheログもmongoimportすると最終的にはMongoDBのデータベースサイズが50G Byteくらい消費した。

5

予想を越えるDISK消費だったのでMongoDB用に 80G ByteのEBSを追加した。

5

 

5

apacheログからmongoimportできるjsonファイルに変換するのに大量のCPUリソースが欲しかったので、EC2のインスタンスを「ラージ インスタンス(64bit)」から「ハイ CPU エクストララージ インスタンス(64bitの8コア)」に変更して"make -j 6"で処理した。

5

8時間かかっても終わらなかった処理が2時間ちょうどで終わった。

5

※ "make -j 8"にすると、Emacsでの編集作業でさえひっかかるため、"make -j 6"にした。

5

 

5

急にDISKを大量に使いたいとか、CPUを大量に使いたいという時にはそのの柔軟性のおかげで、EC2の便利さが体感できた。

5

プライベートであっても、処理を待っている間に別のハックをすると裏で走っている処理が気になる。

5

短時間で処理が終わって頭を次のタスクに切り替えれるのはありがたい。

5

時間を金で買うという感じだ。

5

 

5

タスクの切れめが縁の切れめ(EC2)

5

いざ集計を終えてみると、EC2は不要になった。

5

多分、次に重い処理をするまでは使わない。

5

 

5

bit単価が高い(EC2)

5

「ラージ インスタンス(64bit)」が時間 30円くらいで、「ハイ CPU エクストララージ インスタンス(64bitの8コア)」が時間70円くらい。

5

「マイクロ インスタンス(64bit)」は時間 1.3円くらいで安いのだけど、はっきりいって何もできないくらい遅い。

5

マイクロではEmacsでコピーアンドペーストをするだけで、5秒くらいかかる。文章の編集さえできないので使う意味は無い。

5

「スタンダード」というランクがあれば良いのだけど、32bit環境にしか無い。普段64bitのソフトウェアを使いたいので、それも無し。

5

 

5

結局「さくらのクラウド」が常用環境

5

「さくらのクラウド」にSumibi.orgサイトを起動しっぱなしにしているので、普段はそちらを使えばいいという結論になった。

5

ちなみに、本エントリ時点の「さくらのクラウド」のサイズはRAM 3GByte / HDD 80GByte / 月額約 5000円。

5

MySql(常時300 MByte消費)、Apache、sekka-server(tokyocabient使用)、Kahua(worker process10個)という構成。

5

EmacsをX forwarding over sshで手元のMacBook Proに転送している。(twitter-modeとw3mも使う。特に問題ない速度)

5

本エントリも、「さくらのクラウド」上のEmacsとsekka-serverで書いている。

5

 

5

まとめ

5
Amazon EC2は必要な時だけ使う。
5
常用環境は、費用対効果を考えると「さくらのクラウド」になる。
5

 

5

参考:

5
 kiyoka.2011_12_28[Cloud] 自宅サーバが全壊したので「さくらのクラウド」にSumibi.org環境を再構築した
5

 

0

comment (disabled)

5

5

 

5

 

5

kiyoka.2012_01_01[Life] 2012年の抱負

5

去年も抱負を書いているようなので今年も書くとしよう。

5

 

5

今年は仕事内容が請負開発から自社商品開発に変わったので新しいことができそうだ。

5

プライベートでもいろいろやりたいことがあるが、欲張らず自分のペースで進んでいけたらと思う。

5

 

5

今年のテーマは公私ともにクラウドになりそう。

5

去年末は自宅サーバ全壊をきっかけにふっきれて全面クラウド依存環境に突入。同時に仕事も心機一転、新しい部署でクラウドに関連した(どっぷりつかった?)仕事をやらせてもらうことになった。

5

2129907395_28e1e39867_m

5

餌はたくさんもらったが慣れない環境でなのでいろいろ勉強しながらやっていこう。

5

まだ家庭環境方面でアクセル全開とはいかないので、70%くらい踏んだ感じでいこう。(去年は50%くらいだったと思う)

5

脳やコンピュータリソースをフルに回して(時には金で時間を買うなどして)時間効率を上げる工夫が必要かなー。

5

 

5
 参考: kiyoka.2011_01_09 [Life] 2011年の抱負
5
 2129896209_430f0a1c05_m
5

 

0

comment (disabled)

5