Sensuについて

sysadmin

最近Sensuというモニタリングフレームワークを試している。見ての通り公式はオサレで今時な感じで、Nagiosのような古くささやZabbixのようなエンタープライズ臭はない。

Sensuの特徴は何かと考えると、こんな感じのことが浮かぶ。

  • 監視とメトリクス収集を一つの仕組みで行える。
    • ただし収集したデータの可視化はしない。
  • 設定がlightweight
    • 所定のディレクトリにJSONファイルをつっこんでおくと勝手にdeep mergeされるのでinclude指定とかいらないし、ポチポチやってデータベースに設定値を入れる必要もない。
      • キーがかぶったときにどうなるかとかは知らないので、設定がシンプルとは言わない。
      • JSONなのでコメントは書けない。コメントはChefのレシピ側に書こうという発想。
    • クライアント一覧は自動的に作られるので自分で能動的に登録する必要もない。
  • Chefで設定するためのcookbookが整備されてる。
    • 適当にattributesを設定して適用すればサーバを作れる。
  • Nagiosプラグインがそのまま使えるし、sensu-community-pluginsにもたくさんプラグインがある。
  • まともなAPIがついてる

サーバはRedisとRabbitMQを使っていてセットアップが大変かと思っていたけど、Chefレシピがちゃんと動いたのであっという間だった。

フロントエンドを外部に任せてモニタリングに集中したのは、餅は餅屋にという意味で良い決断だと思う。その分ユーザが設定すべきことは増えるけどChefとの連携とlightweightな設定で有る程度緩和されてる。

せっかく監視とメトリクス収集を同じ仕組みでできるようにしたのに、Nagios pluginと同じプロトコルを採用したために一つのチェック実行で両方が終わるようにならないのはもったいない気もする。

Graphiteにデータを送る際にgraphite mutatorを使うと、あっという間にサーバのCPUが100%になるので気をつけよう。extensionを使って書き直したものをPRしたので取り込まれればこっちを使った方が良いと思う。

それと、コミュニティの規模はまだだいぶ小さい。#sensuは140人弱くらいで発言数はかなり少ない。

persistentでEntityのJSONフォーマットを変更するには

haskell

Yesod界隈でよく使われているpersistentは、v1.2.0になったタイミングで、Entity a全体に対するToJSONとFromJSONクラスのインスタンスを提供するようになった。

このインスタンスのJSONフォーマットがちょっと変わっていて、

{"key": 1, "value": {"name": "Taro", "age": 20}}

という形式を想定している。

別のフォーマットを使うようにしたかったら、Haskellで同じ型に別のインスタンスを実装したいときにおなじみのnewtype wrapperを使うことになる。例えばよく使われる

{"id": 1, "name": "Taro", "age": 20}

にするならこんな感じ。

import Control.Lens ((&), (%~))
import Control.Lens.Aeson (_Object)
import Data.Aeson
import Database.Persist

newtype SaneJSON a = SaneJSON (Entity a) deriving Show

instance ToJSON a => ToJSON (SaneJSON a) where
    toJSON (SaneJSON (Entity key val)) =
        toJSON val & _Object %~ HM.insert "id" (toJSON key)

毎度これを定義するのは面倒な上に、うっかりtoJSONする前にSaneJSONでくるむのを忘れると、insaneなJSONが出てきてしまう。

やだなーと思っていた折、githubにissueが登録されたので、Entity aに対するToJSON/FromJSONをなくす方向に誘導してみた。無事#181がmasterにmergeされたので、次のリリースからは

import Database.Persist
import Database.Persist.TH

settings :: MkPersistSettings
settings = sqlSettings
  { mpsEntityJSON = EntityJSON
    { entityToJSON = 'entityIdToJSON
    , entityFromJSON = 'entityIdFromJSON
    }
  }

share [mkPersist settings] [persistLowerCase|
User json
  name Text
  age Int
  deriving Show Eq
|]

みたいな感じで、MkPersistSettingsのmpsEntityJSONに自分の好きなtoJSON/parseJSONをquoteして渡してやることで差し替えられるようになった。entityIdToJSON/entityIdFromJSONは新しくpersistentパッケージで定義されたpredefinedなtoJSON/parseJSON実装の一つ。stage restrictionさえ避ければ、自分の好きな実装に入れ替えられる。

HaskellでWebAppの開発に必要なN個のこと

あるプログラミング言語で実際にWebAppを開発できるようになるまで、何が必要だろうか。言語仕様の習得は終えているとしよう。おそらく、最低限以下のような知識が必要だと思われる。とりあえずHaskellについて知っていることを書いた。 ← ここまで引用。

パッケージマネージャ

Cabal 1.18を使おう。以上。

アプリケーションサーバ

WSGIとかRackとかの流れでHaskellでもwebアプリのサーバインタフェースを統一化する動きがいくつかあった。その中で一番市民権を得たのはwaiと呼ばれるものだ。

ただ、残念なことにHaskell界でここ数年ずっと続いているI/Oストリーミングライブラリ戦争の決着がついていないため、統一化の状況は思わしくない。waiはconduitというライブラリに依存しているが、フレームワークによっては別のI/Oストリーミングライブラリを基盤にしている。

現状の3大フレームワークで次のような状況である。

  • Yesod
    • インタフェースはwai。標準的なwebサーバはwarp。
    • I/Oはconduitを使う。
  • Snap
    • インタフェースは独自のものでsnap-serverを使う。
    • I/Oはio-streamsを使う。
      • 追記: I/Oはまだenumeratorを使っていて、今io-streamsに移行準備中だそうです。*1
  • Happstack
    • インタフェースは独自のものでhappstack-serverを使う。
    • happstack-waiというライブラリが有るみたいだけど動くのかは知らないし、Hackageにもあがってない。
    • I/OはlazyByteStringを使っているみたい。将来はpipesに移行するらしい。

要するにほとんど統一化されておらず、各々が好きなインタフェースを実装して使っていると考えてよい。個人的にはこの状況はもうしばらくの間、続くのではないかと思っている。

リクエストパラメータの処理・ルーティング

基本的にフレームワークについてくるものを使う。

データベース

Yesodやwai陣営は基本的にpersitentとSQL方面で拡張したesqueletoを使う。

Snapではフレームワーク自体にはデータベースアクセスのサポートはないが、アドオン（snaplet）の形式でいくつかサポートされているようで、persistentを使うこともできるらしい。

HappstackはなんとRDBMSではなくてacid-stateを押しているので、フレームワークとしてのサポートは特にないのではないかと想像できる。

いずれのフレームワークを使っていても、もっとローレベルなライブラリを直接叩く人もいるのではないかと思う。

ビューのレンダリング

たいていのケースでフレームワークに付属しているものを使う。MustacheのHaskell実装であるhustacheを使う人もいるかもしれない。

HTTPクライアント

Haskell PlatformにHTTPパッケージが入っているけどAPIがひどいので使っている人は少なそうな印象。

この分野もI/Oストリーミングライブラリの影響を多分に受けるのでフレームワークによっておすすめが変わると思う。

あたりがメジャーどころ。

テストフレームワーク

QuickCheckとHUnitを書くことになるが、それを補助するライブラリがいくつかある。

前2つはQuickCheckテストをまとめてくれるもの。並列実行などもサポートしている。

hspecはrspecみたいな感じにテストを書けるらしいけど使ったことがない。

doctestはテストをコメントとして書くことで、ドキュメントにもなるというもの。

hspecとdoctestはHaskellの単体テスト最前線 - あどけない話を参照されたい。

Webアプリケーションフレームワーク

上に出てきたとおり。YesodとSnap、Happstackが三強。

比較はWeb/Comparison of Happstack, Snap and Yesod - HaskellWikiにまとまっているみたい。

とりあえずフォーマットは埋めたので、思いつきベースで追記するかもしれない。何か言いたいことがある人は追記するのでコメントで教えて欲しい。

*1:fujimuraさん、ありがとうございます。

2013年8月現在のHaskell開発環境

Haskell

以前はHaskell Platformを使っていたのだけど、Cabalの依存関係ソルバがあまり賢くなかったこともあり、いわゆるdependency hellに陥ることが多かった。それからというものHaskell Platformを使わない環境を使っている。OS Xでは公式のインストーラやらHomebrewやMac Portsなど幾つかの方法が用意されているが、こんな方法もあるよということで紹介してみよう。

GHCのインストール

GHCのリリース版は自分でビルドしない。時間が掛かるから。インストーラは使わずにtarball版を使う。これはインストール先を自分で指定したいため。

tar zxvf ~/Downloads/ghc-7.6.3-x86_64-apple-darwin.tar.bz2
cd ghc-7.6.3/
./configure --prefix=/usr/local/ghc/ghc-7.6.3
make install

こんな感じで/usr/local/ghc/ghc-x.y.zにインストールする。今はこんな感じ。7.2.xがないのに特に深い意味はない。

[maoe@maoe:~]
% ls /usr/local/ghc/   
ghc-7.0.4 ghc-7.4.2 ghc-7.6.3 ghc-HEAD

HEADが欲しい場合は自分でビルドする。使いたくなったタイミングで更新してる。インストール先は/usr/local/ghc/ghc-HEAD。

Haskell Platformを使わない利点は、バージョンが固定されるパッケージが少ないので依存関係でこけることが減ること。逆に欠点はプロジェクトごとに必要なパッケージをビルド・インストールするのでインストール時間と容量を食うこと。気になる人はHaskell Platformを同じディレクトリにインストールすればいいのかもしれないが、試したことはない。

GHCの切り替え

基本的にはshellから単にPATHを切り替えるようにしている。会社で使われていたスクリプトを少しだけ弄って使っている*1。

maoe/dotfilesにあるprepathとpreghcをbashrcやzshrc的なものにコピーすれば使えると思う。使い方は簡単で、

preghc

とだけ打てば最新のリリース版に、

preghc 7.4
preghc HEAD

などで特定バージョンに切り替えられる。

エディタからGHCを呼びたい場合はシェルスクリプトの関数を呼ぶとトラブルの元になりかねないのでバージョン固定でPATHを指定した方がよいかもしれない。

cabal sandbox

ライブラリを入れる際にcabal installするのはやめよう。cabal install yesod-platformなんてした日にはきっとあなたの.cabalは悲惨なことになる。これまでcabal-devを使っていたけど、最近cabalコマンド自体にsandbox機能やsandboxからGHCiを起動する機能が実装されたので、githubのmasterブランチを取ってきてビルドして使い始めた。これがなかなか快適なのでおすすめ。

そのうちHackageに上がると思うけど先取りして紹介しよう。自分のプロジェクトのルートディレクトリにいって

cabal sandbox init

とすれば.cabal-sandboxディレクトリが作られる。後はいつも通りにコマンドを打てば依存しているパッケージはすべて.cabal-sandbox配下にインストールされ、グローバルあるいはユーザレベルのパッケージデータベースを壊すことはなくなる。

cabal install --only-dependencies # .cabal-sandboxに依存ライブラリをインストール
cabal configure
cabal build
cabal test
cabal bench

GHCiを立ち上げたかったら

cabal repl

とする。あなたのプロジェクトがlibraryであれば上のコマンドでライブラリのモジュールがロードされる。

例えばtest suiteを弄っているときにGHCiが欲しくなったとする。Cabalファイルに

test-suite regression-tests
  hs-source-dirs: tests
  -- ...

と書いてあったとすると

cabal repl regression-tests

とすればライブラリの代わりにそのtest suiteのモジュールがロードされる。

それから、もしあなたのプロジェクトが公開されていないライブラリに依存しているなら、cabal-devと同じようにadd-sourceコマンドが使える。ただし、cabal-devとは異なり*2tarballではなくディレクトリを指定する。

cabal sandbox add-source path/to/your/library/directory

*1:会社で使われているスクリプトもコレに差し替えた

*2:cabal-devではtarballもディレクトリでもOKだそうです。 @notogawa さんありがとうございます。

Haskellでの並列・並行プログラミングの今: Parallel and Concurrent Programming in Haskell

HaskellコンパイラGHCの作者の一人であり並列RTSを書いた人であるSimon Marlowが、Haskellでの並列・並行プログラミングの今を切り取った本を出した。

Parallel and Concurrent Programming in Haskell: Techniques for Multicore and Multithreaded Programming

Parallel and Concurrent Programming in Haskell: Techniques for Multicore and Multithreaded Programming

The Free Lunch Is Overから8年、Haskellでの並列・並行プログラミングの今がどうなっているのかを俯瞰しつつ、実際の問題を解決するときに陥りがちな罠や、高い性能を出すためのtipsなどが読みやすくまとまった一冊になっていて、Haskellでアプリケーションを書いている人には自信を持ってお勧めできる。

HaskellというかGHCはかなり早くから性能の良い並列・並行RTSを持っていたこともあり、様々なライブラリやツールが存在している。その中でも著者が「これをするなら、今ならこれ」と考えるテクニックを集めた内容になっている。

  • 並列プログラミング
    • 遅延評価とEvalモナド
    • parallelパッケージのControl.Parallel.Strategiesによるタスク並列
    • monad-parパッケージによるタスク並列
    • repaパッケージによるCPUを使ったデータ並列
    • accelerateパッケージによるGPU (CUDA)を使ったデータ並列
  • 並行プログラミング
    • スレッドとMVar
    • asyncパッケージ
    • 非同期例外と例外のmaskの扱い方
    • Software Transactional Memory (STM)
    • distributed-process（いわゆるCloud Haskell）による分散プログラミング

読んでいてとてもいいなと思ったところとしては

  • 純粋関数型であっても並列化は簡単ではなく、評価戦略の正しい理解と地道なプロファイリングが必要であることがわかる
  • asyncパッケージのAPIを一から作る流れで各種の並行プリミティブを導入して徐々に改良を施すことで、いつ何を使うのがよいのかがわかる
  • Haskellの中でもかなり取り扱いが難しい非同期例外をちゃんと説明している

が挙げられる。

とりわけ最後の非同期例外は一つの山場で、丸々一つの章をさいて読者を絶望の淵に立たせたのち、STMによって世界の平和を再び取り戻す流れが素晴らしかった。もちろんSTMも銀の弾丸ではないことが述べられているところもまた良い。

対象読者は、すでにHaskellを使っていて並列・並行プログラムを書いている人、または書こうと思っている人とするのが良いと思う。前半の並列プログラミングは比較的読みやすいが、冒頭で解説される遅延評価についての理解が必要になる。後半の並行プログラミングはスレッドプログラミングの経験が全くない状態だと難しいかもしれない。分散の章はさほど踏み込んだ内容ではない。

本書は現実の処理系やライブラリを想定した、テクニックを集めた本なので、比較的旬の短い本だと思う。東京では @tanakh さんによる勉強会も開催されるそうなので、興味のある方は内容が古くなる前に読んでみることを勧めたい。

最後にフォーマットについて。僕はO'Reillyからebookを買ってmobi形式でKindle Paperwhiteで読んだのだが、本文中に出てくるソースコード上のシンボルが普通の文章と見分けが付かないために読みにくい箇所が幾つかあった。また、ソースコードのインデントが一部崩れていた。いずれもよく見ればわかるので実用上は問題ないが、気になる人はO'Reillyから買ってPDFと併せて読むか、ペーパーバックを買った方がよいかもしれない。

また期間限定でwebでも読めるので、チラ見したい方はそちらをどうぞ。

Goodbye Plain Old Chef Repository

pfcasualで仕入れたネタをもとに、Chef環境を刷新したので、忘れないうちにメモしておく。

そもそもの問題意識は、

  • 現状のcookbookにテストが全くないこと
  • テストの欠落が原因でcookbookの変更に対して億劫になってしまっていること
  • Chefの理解・テストの欠落・煩雑な手順によりThe Lone Wolf Chefになってしまっていること

を解決したかった。

方針としてはChefConf 2013: Beginner Chef Antipatternsを参考にすることにした。

  • いわゆるchef-repo *1はやめてcookbookごとにリポジトリを分ける
  • Chefは最新の11にする
  • 各人のworkstationにChefでChefのcookbook開発に必要な環境を整備する
  • Chefのワークフローを決めたかったのでEtsyのknife-sporkを使うことにした。
    • pfcasualで @sethvargo さんが教えてくれたもの
    • environmentsの編集には、これも @sethvargo さんが使ってたknife-flipを使う。

などなど。

大まかなワークフローはこんな感じ。

cookbookの新規作成・編集は

  1. berks cookbook $cookbook --foodcritic --chef-minitest
  2. gitリポジトリも作っておく
  3. cookbookとテストを書いたらvagrant up/provisionでローカルマシンでテスト
  4. 必要であればknife spork bump $cookbookでバージョン番号を上げる
  5. git push
  6. 良さそうならknife spork upload $cookbookでサーバにアップロード
  7. knife spork promote development $cookbook --remoteでchef_environment:developで先ほどアップロードした$cookbookが使えるようにする
  8. knife node flip $node developmentで$nodeのenvironmentをdevelopmentにして$cookbookが反映されるようにする
  9. 問題無さそうならknife spork promote production $cookbook --remote
  10. environmentsのリポジトリが更新されているのでこちらもgit push

nodeの作成はコマンド一発で済む。

  1. knife bootstrap -x --sudo -r "recipe[$recipe]" -d chef-full -E production

chef-fullというのがいわゆるomnibusインストーラ。特別に理由がなければこれを使うのが楽で良いと思う。

cookbookの構成について

cookbookの構成をどうするかはコミュニティ内でも意見の分かれるところだと思う。これはChefの制限によるものが大きい。

たとえばBerkshelfの中の人に言わせてみれば、Chefのcookbookを束ねるroleは使うべきでない。なぜならroleはcookbookと違いバージョン管理されてないからである。この主張はenviornmentを利用し始めれば理解できる。environmentごとにcookbookのバージョンを指定することができても、roleにはバージョンがついてないため、developmentのみこのcookbookを適用したいみたいなことができない。

ではどうするかというと、roleと同じことをするcookbookを作ることになる。Chefのcookbookは元々boilerplateが多い上にBerkshelfの設定ファイルやVagrantの設定ファイルを置く必要があり、ある程度自動生成されるにしても面倒なことには変わりない。

今回移行したcookbookは結局こんな感じの構成になった。

  • application cookbooks: 一番トップレベルで使うcookbook。app-*という名前にしている。以前のroleに対応するもの。recipe自体は適切なattributesを設定して、あとはinclude_recipeするだけのものが多い。
  • wrapper cookbooks: community cookbookに少し手を加えたいときに作るcookbook。wrap-*という名前。たとえばあるcookbookのtemplateがいけてないので、そこだけ差し替えたり、決めうちでよいattributesを設定するために作る。
  • library cookbooks: community cookbookに無いものはlibrary cookbookとして作る。
  • 会社固有のcookbookは$company-*な名前

こんな感じでいま30個くらいのcookbookがある。

attributes周りの面倒

Chefのattributesは柔軟なcookbookを書くために役に立つが、複雑で間違いを起こしやすい。

いろいろ文句はあるのだけど書くのが面倒なので、About Attribute Files — Chef DocsのAttribute Precedenceを見れば複雑であることは伝わると思う。

それだけではあれなのでtipsを2つほど。

  • recipe中にpp node.debug_value(:key1, :key2, ...)と書くと、precedenceごとにattributesがどうセットされているかわかる
  • recipe attributesは、attribute fileなどと同様にrecipe適用前に構築されると思いきや、recipe内の順序に依存しているので、そのattributeを使う部分より前にセットする必要がある。
    • 使う部分より後でattributeを変更すると、Chef Serverのnode情報には正しい値が見えるのに、recipe適用時には反映されてないやっかいなバグの元になる。

その他

  • CIの設定はまだしてないのでやりたい
  • 一部大事なホストでserverspecなどを使ってテストしたいなと思っている
  • ChefもBerkshelfも結構バギーかつ複雑だったりするので、今後すごくシンプルなツールがはやる可能性もあるなと思う
  • わからないことはfreenodeの#chefでUSが起きてる時間帯に聞こう

The Lone Wolf Chef問題については、やっと準備ができてこれから皆に使ってもらおうという段階。うまくいくと良いな。

参考資料

pfcasualで教えてもらったChefConf 2013のBeginner Chef Antipatternsは大まかな方針を決めるときに役立つ。ただしすべてを鵜呑みにする必要はなくて、適宜自分の目的に合わせて解釈するのがよいと思う。

BerkshelfについてはThe Berkshelf Way - Jamie Winsorを見れば使い方はわかるだろう。

*1:Plain Old Chef Repository; POCRとでもしよう。読みにくい。