SystemTap メモ #1 （スクリプトフォーマットとイベント）
SystemTap メモ #0 の続き。今回は SystemTap Beginners Guide の 3.2. SystemTap Scripts から抜粋。
スクリプトのフォーマット
SystemTap スクリプトのフォーマットはこんな感じ。
probe event { statements }
なので、前回 出てきた、
$ stap -v -e 'probe vfs.read { printf("read performed\n"); exit() }'
をフォーマットと照らし合わせて読み解くと、「vfs.read イベントが発生したら read performed と表示して exit する」といった意味になる。
{ statements } の部分は handler と呼ばれ、event と それに対応した handler をあわせて probe と呼ぶらしい。
スクリプトの中では関数を定義して呼び出すこともできる。
function function_name(arguments) { statements }
probe event { function_name(arguments) }
イベント
イベントは同期イベントと非同期イベントに分かれる。
同期イベント
同期イベントはカーネルコード中の特定の場所で命令が実行された場合に発生するイベント。（非同期イベントは後で説明するが、命令実行とは関係なしに発生するイベント。）
同期イベントには以下のようなものがある。
syscall.system_call
system_call というシステムコールの呼び始めに発生するイベント。呼び終わりに発生するイベントは syscall.system_call.return 。close システムコールの呼び始めに発生するイベントは syscall.close、呼び終わりに発生するイベントは syscall.close.return 。
vfs.file_operation
VFS に対して file_operation の呼び始めに発生するイベント。syscall と同様、 .return を付加すると、呼び終わりイベントとなる。
kernel.function("function")
カーネルファンクション function の呼び始めに発生するイベント。例えば kernel.function("sys_open") は sys_open の呼び始めに発生するイベント。.return がつくと呼び終わりイベント。ワイルドカードとして * がつかえる。また、以下のように特定のソースファイル中のファンクションも指定できる。
probe kernel.function("*@net/socket.c") { }
probe kernel.function("*@net/socket.c").return { }
kernel.trace("tracepoint")
カーネル内の特定のトレースポイントで発生するイベント。例えば、kernel.trace("kfree_skb") だと、カーネル内のネットワークバッファが解放された時にイベントが発生する。
module("module").function("function")
モジュール内の特定のファンクションが呼ばれた場合に発生するイベント。
probe module("ext3").function("*") { }
probe module("ext3").function("*").return { }
この例だと、前者は ext3 モジュール内のすべてのファンクションの呼び始めに発生するイベント、後者は呼び終わりに発生するイベント、となる。
非同期イベント
非同期イベントはカーネルコード内の命令実行とは無関係に発生するイベント。以下のようなイベントがある。
begin
SystemTap セッションの開始時（SystemTap スクリプトの実行開始時）に発生するイベント。
end
SystemTap セッションの終了時に発生するイベント。
timer events
タイマーイベント。以下の例では4秒ごとにイベントを発生させる。
probe timer.s(4)
{
printf("hello world\n")
}
時間単位は上の例の秒以外にも、以下のように指定できる。
- timer.ms(milliseconds)
- timer.us(microseconds)
- timer.ns(nanoseconds)
- timer.hz(hertz)
- timer.jiffies(jiffies)
イベントは他にもたくさんあるので、詳しく知りたければ man stapprobes すべし。
Updated on 2010/07/13 02:44
SystemTap メモ #0
SystemTap が以前から気になってたので、ちゃんと調べてみることに。
ざっとググってみた感じだと、SystemTap Beginners Guide がしっかりまとまっていてわかりやすそうなので、これをベースに調べたことをメモしていく。PDF 版もあるので Kindle に入れて持ち運べるし。
SystemTap とは？
- カーネルの動きをモニタリングするためのフレームワーク
- netstat, ps, top, iostat なんかで得られるのと同じような情報が取得できる
- こういった情報が得られるだけではなく、フィルタリングしたり解析したりもできる
といったもののようです。DTrace を知ってる方なら、それに似たようなもの、と言えばわかりやすいのかもしれません。（自分は DTrace よく知りませんが。）
SystemTap の利用
CentOS 5 でインストールした際のメモ。
利用している kernel と同じバージョンの kernel-devel パッケージをインストール。（systemtap パッケージを入れると依存で勝手に入るけど、利用中の kernel バージョンと異なる場合もあるので、先に入れておくといいです。）
$ sudo yum install kernel-devel-2.6.18-164.el5
systemtap パッケージをインストール。
$ sudo yum install sytemtap
kernel-debuginfo と kernel-debuginfo-common のインストールのために、debuginfo-install コマンドが含まれる yum-utils パッケージをインストール。
$ sudo yum install yum-utils
kernel-debuginfo と kernel-debuginfo-common を yum で取得できるように、以下のような /etc/yum.repos.d/CentOS-debuginfo.repo を作成。
[debuginfo]
name=CentOS debuginfo
baseurl=http://debuginfo.centos.org/$releasever/$basearch/
gpgcheck=0
enabled=1
kernel-debuginfo と kernel-debuginfo-common を インストール。
$ sudo debuginfo-install kernel
kernel-headers も必要かも？
あとは stap コマンドを実行すれば OK。(root 権限が必要だけど、stapdev グループに属しているユーザであれば、権限は不要。)
$ stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
Pass 1: parsed user script and 65 library script(s) using 43932virt/19448res/1752shr kb, in 170usr/50sys/210real ms.
Pass 2: analyzed script: 1 probe(s), 10 function(s), 2 embed(s), 1 global(s) using 116696virt/75204res/41808shr kb, in 310usr/50sys/369real ms.
Pass 3: using cached /home/miya/.systemtap/cache/eb/stap_ebec3e35e1d3f3f5cd90569c6319bd2f_4795.c
Pass 4: using cached /home/miya/.systemtap/cache/eb/stap_ebec3e35e1d3f3f5cd90569c6319bd2f_4795.ko
Pass 5: starting run.
read performed
Pass 5: run completed in 20usr/50sys/96real ms.
-v オプションで詳細表示。v を増やすと更に詳細に。
表示されるメッセージを見るとなんとなくわかるけど、SystemTap スクリプトをコンパイルしてカーネルモジュールを生成して実行してる。なので gcc や make なんかも必要。（なはず。）
他のマシンで実行できる SystemTap モジュールを生成
上で見たように、SystemTap の利用には、コンパイラや debuginfo パッケージのインストールが必要なんだけど、ポリシー的にそれが許されない環境ではどうするか？実は SystemTap にはコンパイル済みのモジュールを実行する仕組みもある。（このコンパイル済みモジュールのことを、ドキュメントでは Instrumentation と呼んでいる。）
コンパイル済みモジュールは以下のように stap コマンドで生成できる。(-r と -m オプションを指定する。）
$ stap -r 2.6.18-164.el5 -e 'probe vfs.read {exit()}' -m simple -v [miya@h026]
Pass 1: parsed user script and 65 library script(s) using 43932virt/19448res/1752shr kb, in 180usr/20sys/205real ms.
Pass 2: analyzed script: 1 probe(s), 10 function(s), 2 embed(s), 1 global(s) using 116816virt/75200res/41808shr kb, in 320usr/40sys/364real ms.
Pass 3: translated to C into "/tmp/stapPGBW7a/simple.c" using 116816virt/75940res/42548shr kb, in 230usr/10sys/269real ms.
Pass 4: compiled C into "simple.ko" in 3820usr/790sys/4619real ms.
Pass 5: starting run.
Pass 5: run completed in 20usr/50sys/97real ms.
simple.ko が生成されるので、これを実行したいマシンにコピーする。そのマシン上では、systemtap-runtime パッケージがインストールされていれば良い。で、以下のように staprun コマンドを叩いてモジュールを実行する。
$ staprun simple.ko -v
stapio:cleanup_and_exit:400 detach=0
stapio:cleanup_and_exit:417 closing control channel
staprun:remove_module:205 Module simple removed.
これも root 権限が必要だけど、stapusr グループに属していれば権限は必要ない。（stapdev グループでももちろん実行できる。）
今日はここまで。
Web開発者のための大規模サービス技術入門 —データ構造、メモリ、OS、DB、サーバ/インフラ
Web開発者のための大規模サービス技術入門 —データ構造、メモリ、OS、DB、サーバ/インフラ という本を献本頂きました。技術評論社様、@naoya_ito さん、@stanaka さん、ありがとうございます。
目次の詳細は技術評論社様のサイトをご覧頂くとして、アウトラインは以下のようになっています。
- 第1回 大規模Webサービスの開発オリエンテーション―全体像を把握する
- Lesson 0 本書の源 ―本書で説明すること，しないこと
- Lesson 1 大規模なサービスと小規模なサービス
- Lesson 2 成長し続けるサービスと，大規模化の壁
- Lesson 3 サービス開発の現場
- 第2回 大規模データ処理入門 ―メモリとディスク，Webアプリケーションと負荷
- Lesson 4 はてなブックマークのデータ規模 ―データが大きいと処理に時間がかかる
- Lesson 5 大規模データ処理の難所 ―メモリとディスク
- Lesson 6 スケーリングの要所
- Lesson 7 大規模データを扱うための基礎知識
- 第3回 OSのキャッシュと分散 ―大きなデータを効率良く扱うしくみ
- Lesson 8 OSのキャッシュ機構
- Lesson 9 I/O負荷の軽減策
- Lesson 10 局所性を活かす分散
- 第4回 DBのスケールアウト戦略 ―分散を考慮したMySQLの運用
- Lesson 11 インデックスを正しく運用する ―分散を考慮したMySQL運用の大前提
- Lesson 12 MySQLの分散 ―スケーリング前提のシステム設計
- Lesson 13 MySQLのスケールアウトとパーティショニング
- 第5回 大規模データ処理［実践］入門 ―アプリケーション開発の勘所
- Lesson 14 用途特化型インデクシング ―大規模データを捌く
- Lesson 15 理論と実践の両側から取り組む
- 第6回 ［課題］圧縮プログラミング ―データサイズ，I/O高速化との関係を意識する
- Lesson 16 ［課題］整数データをコンパクトに持つ
- Lesson 17 VB Codeと速度感覚
- Lesson 18 課題の詳細と回答例
- 第7回 アルゴリズムの実用化 ―身近な例で見る理論・研究の実践投入
- Lesson 19 アルゴリズムと評価
- Lesson 20 はてなダイアリーのキーワードリンク
- Lesson 21 はてなブックマークの記事カテゴライズ
- 第8回 ［課題］はてなキーワードリンクの実装 ―応用への道筋を知る
- Lesson 22 ［課題］はてなキーワードリンクを作る
- Lesson 23 回答例と考え方
- 第9回 全文検索技術に挑戦 ―大規模データ処理のノウハウ満載
- Lesson 24 全文検索技術の応用範囲
- Lesson 25 検索システムのアーキテクチャ
- Lesson 26 検索エンジンの内部構造
- 第10回 ［課題］全文検索エンジンの作成 ―基本部分，作り込み，速度と精度の追求
- Lesson 27 ［課題］はてなブックマーク全文検索を作る
- Lesson 28 回答例と考え方
- 第11回 大規模データ処理を支えるサーバ/インフラ入門 ―Webサービスのバックエンド
- Lesson 29 エンタープライズ vs. Webサービス
- Lesson 30 クラウドvs.自前インフラ
- 第12回 スケーラビリティの確保に必要な考え方 ―規模の増大とシステムの拡張
- Lesson 31 レイヤとスケーラビリティ
- Lesson 32 負荷の把握，チューニング
- 第13回 冗長性の確保，システムの安定化 ―ほぼ100％の稼動率を実現するしくみ
- Lesson 33 冗長性の確保
- Lesson 34 システムの安定化
- Lesson 35 システムの安定化対策
- 第14回 効率向上作戦 ―ハードウェアのリソースの使用率を上げる
- Lesson 36 仮想化技術
- Lesson 37 ハードウェアと効率向上 ―低コストを実現する要素技術
- 第15回 Webサービスとネットワーク ―ネットワークで見えてくるサービスの成長
- Lesson 38 ネットワークの分岐点
- Lesson 39 さらなる上限へ
- 特別編 いまどきのWebサービス構築に求められる実践技術 ―大規模サービスに対応するために
- Special Lesson 1 ジョブキューシステム ―TheSchwartz､ Gearman
- Special Lesson 2 ストレージの選択 ―RDBMSかkey-valueストアか
- Special Lesson 3 キャッシュシステム ―Squid，Varnish
- Special Lesson 4 計算クラスタ ―Hadoop
ものすごいボリュームです。はてなさんで毎年行っているインターンシップのカリキュラムを書籍化したそうで、ペパボでは最近新卒採用を開始したんですが、これは新人教育用の教科書としても使えそうです。
特に、はてなさんで苦労した内容なんかもふんだんに盛り込まれており、理論だけに偏らず、具体的にどういったことで苦労して、それをどう克服しかた、という実践的な話はとても興味深く読ませて頂きました。こういう話ってなかなか書籍では出てこないんじゃないかと思います。
「24時間365日 サーバ/インフラを支える技術 — スケーラビリティ、ハイパフォーマンス、省力運用」 も、発売当時にペパボ内の技術者に、これは読んでおけと勧めたのですが、本書もやはり読むように勧めたいと思います。
併せて読みたい
Zabbix統合監視「実践」入門 〜障害通知、傾向分析、可視化による省力運用〜
技術評論社様よりご献本頂いてたのですが、感想を書くのがすっかり遅くなってしまいました。
タイトルの通り、統合監視ソフトウェア Zabbix について書かれた本です。和書では初の Zabbix 本ですね。（ですよね？）Software Design plus シリーズの第1弾ということで、今後のシリーズ展開がとても楽しみです。
本書の目次は以下のようになっています。
- はじめに
- 1章: 統合監視ソフトウェアZabbixとは
- 2章: Zabbixのインストール
- 3章: クイックスタートガイド
- 4章: 監視対象と監視項目の設定
- 5章: 障害検知と障害通知の設定
- 6章: グラフィカル表示の設定
- 7章: テンプレートの利用とエクスポート/インポート
- 8章: 一般設定とユーザ設定
- 9章: Zabbixによるシステム監視サーバ構築実践
- 10章: 障害発生時のスクリプト実行機能の活用
- 11章: アプリケーションの詳細監視
- 12章: Zabbixサーバの運用とメンテナンス
- 13章: 大規模システムの監視
- 14章: Appendix
そもそも監視とは何か、といった話から、Zabbix の概要、インストール、設定、運用、大規模システムの監視と、Zabbix を知り実際に利用するために必要な知識がほとんど網羅されているのではないかと思います。Zabbix は機能豊富で全体像がすぐには掴みにくいソフトウェアなので、こういった形で一冊の本にまとまっているのは非常にありがたいですね。
Zabbix で特にいいなー、と思ったのは、リソースグラフの表示範囲や日時を自由に変更できるところ。自分が使ったことがあるリソースモニタリングツールだと、直近のデータ1時間分、といった表示はできても、過去のある時点の詳細を見たいと思った場合に、その時点のデータは1時間分ではなく、1日分や1週間分といった非常に大雑把なデータになってしまい、こちらが望む細かい粒度でのリソース動向を追うことができないという不満があるけれど、Zabbix であればこちらが望む形でリソースグラフを確認することができそうです。デモサイト でもこの辺については確認できます。
逆に Zabbix のあまり好きではない点は、機能が豊富すぎるところ。稼働監視、リソース監視、アプリケーション監視をすべて網羅していて、オールインワンなソフトウェアを求めている人にはとてもいいソリューションだけれども、既に Nagios のような稼働監視ソフトウェアを利用していて、そこにリソース監視ソフトウェアを導入したいとか、あるいはその逆パターンとか、そういった場合には、既存で導入しているソフトウェアと機能が被る面が多いので導入しづらいかな、という懸念があります。
また、自分は目的特化した小さなソフトウェアを組み合わせて必要に応じてカスタマイズするのが好きなので、Zabbix のような大きなソフトウェアの導入はためらってしまいますね。
とは言っても、本書を読んで Zabbix は非常によくできたソフトウェアだと思いましたので、統合監視ソフトウェアの導入を検討している方にはとても参考になると思います。
NTTレゾナントさんの勉強会でDevOpsについて話してきました
ドクターペッパー飲み放題に釣られて、NTTレゾナントさんで DevOps の話をしてきました。
プレゼン資料をslideshareにあげておきます。
Hadoop と Scala の CentOS5 用パッケージ
2010/04/14 追記
太田さんから twitter でHadoopは基本的にSun JDKのみでテストされているので、OpenJDKでの使用は危険らしいです。 とご指摘いただきました。ありがとうございます。
となると、Hadoop 以外にも Java 関連パッケージを利用したい場合には、Hadoop を OpenJDK 用にビルドするんじゃなくて、他の Java 関連パッケージを Sun JDK 用にビルドしなおすか、気持ち悪いけど併用するか、のどちらかになってしまうんですかね。
Hadoop を CentOS5 で利用する場合、Cloudera’s Distribution for Hadoop (CDH) を yum でインストール するのが簡単なんですが、http://java.sun.com/ から入手できる JDK パッケージに依存してるので、CentOS5で yum install できる OpenJDK パッケージ が使えません。
Hadoop 使うだけならそれでもいいんですが、他の yum で入る ant 等の Java 製ソフトウェアを利用しようと思うと、Sun から入手した JDK パッケージと yum で入る OpenJDK パッケージが同居して、気持ちが悪いです。
幸い、CDH の SRPM も入手できるので、こいつを OpenJDK パッケージを利用する形でパッケージングしなおしました。
こいつをビルドするために ant 1.7 以降が必要なのだけど、CentOS で yum で入るのは 1.6 なので、ant 1.7 のパッケージもつくった。
また、Hadoop + Scala を試してみたいので、Scala のパッケージと、Scala に必要な jline のパッケージもつくった。
Updated on 2010/04/14 14:53
DevOps に関する理解を深めるために、資料にあたってまとめてみるシリーズ。
今回は Velocity Online Conference - March 17, 2010 でのプレゼン Provisioning Toolchain から。スライドのタイトルは「OpenSource Provisioning Toolchain」となっている。
昨日のエントリでいうと、「インフラの自動化」や「ワンステップビルド＆デプロイ」に関連する話。
Toolchain というのは何らかの目的を達成するためのソフトウェアの集まり、ってことなので、Provisioning Toolchain は、プロビジョニングを行うためのソフトウェアの集まり、ってことですね。つまり OpenSource Provisioning Toolchain は、プロビジョニングを行うためのオープンソースソフトウェアの集まり、ということ。
ここでわざわざ Toolchain といってるのは、ひとつの大きなソフトウェアで全部やるんじゃなくて、小さなソフトウェアを組み合わせることで、プロビジョニング全体をカバーしよう、という考えから。
小さなツールを組み合わせることによるメリットを、UNIX哲学的な話と絡めて説明してるけど、この辺はよくある話なので省略。
また、なぜこのような Toolchain が必要なのか、って話を、クラウドや仮想化の波が押し寄せてきて DevOps 問題が発生する云々、的なスライドがあるんだけど、それ以上の詳しい説明が特にないのでこれも省略。
個人的に参考になったのは、プロビジョニングを3つの領域にわけて、それぞれの領域に対応するオープンソースソフトウェアを挙げているところ。（オープンソースじゃないモノも混じってるけど。）
3つの領域とは以下の通り。
- Orchestration
- Application Service Deployment
- Configuration
- Bootstrapping
- OS install
- Cloud or VM Image Launch
下の方がプロビジョニングの初期段階で、上に行くほどレイヤーが上がるイメージ。
で、それぞれに対応するソフトウェアは以下の通り。
- Orchestration
- Configuration
- Bootstrapping
ペパボの場合だと、全部のサービスがそうというわけではないけど、Bootstrapping レイヤーで Cobbler、Configuration レイヤーで Puppet、Orchestration レイヤーで Capistrano(Webistrano) や Func、といった感じ。ここにないものだと、Orchestration レイヤーで Archer なんかも使ってる。
今日は手抜きだけどこれでお終い。これから MAG やるので。DLC第1弾トルーパーパックが配信されたしね。
DevOps: Why Silos Suck And How To Break Them というエントリをたまたま目にして、「DevOps」という見なれない言葉が出てきたので、気になって調べてみたところ、自分が何となくやっていたことや、今までもやもやと考えていたことに一定の方向性が与えらえた気がしたので、整理してみることにします。
簡単に言ってしまうと「開発者と運用者の間の壁を取り払うためのベストプラクティス」と言えそうです。
開発者と運用者の間の壁？
Flickr の中の人による 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr という Velocity 2009 でのプレゼンスライドには「Devs versus Ops」という章があり、以下のような言葉が載っていました。
"It's not my machines, it's your code!"
「それは俺のマシンじゃないし、お前のコードだろ」って感じでしょうか。実際、開発者と運用者が明確に分かれている組織では、多かれ少なかれ、また、ニュアンスや詳細は違うでしょうが、こういった言葉が交わされることがあるのではないでしょうか。これは開発者と運用者だけではなく、ウェブ開発者とサーバエンジニア、フロントエンジニアとバックエンドエンジニア、といった形で、明確に役割分担されている組織では起こりうる問題であり、これにより開発がスケジュールから大幅に遅れたり、トラブルがなかなか解決しない、といったような事態を招くこともあるんじゃないかと思います。
また、上記スライドでは以下のような考えを「伝統的な考え」と述べています。
- 開発者の仕事は新しい機能を追加すること
- 運用者の仕事はサイトを速くて安定した状態に保つこと
そして、「運用者の仕事はサイトを速くて安定した状態に保つことではない」とし、「ビジネスには変化が必要」であり、「安定性をとって変化を捨てる」か「必要に応じて変化が起こることを許容する」か、といった選択肢を提示しています。
どうやってその壁を取り除くのか
では、このような開発者と運用者（あるいはウェブ開発者とサーバエンジニアなど、自身の置かれた状況に置き変えてみてください）の壁を取り払うためには、どうすればいいのでしょうか。上で見たように、壁の原因は「運用者の仕事はサイトを速くて安定した状態に保つこと」という伝統的な考えにありそうです。（これは別に運用者が悪い、と言っているわけではありません。）そして、提示された選択肢のうちの後者「必要に応じて変化が起こることを許容する」ことが容易に実現できるようにすることが大事なのではないかと考えられます。これを実現するために重要なことは、
の2つに分けることができそうです。
ツール
「10+ Deploys Per Day: Dev and Ops Cooperation at Flick」では、ツールとして以下のようなものをあげています。
- インフラの自動化
- 共有されたバージョンコントロール
- ワンステップビルド＆デプロイ
- 機能フラグ
- メトリックの共有
- IRC and IM robots
ひとつひとつの解説は省略しますが、いずれも状態やその変化を記録、可視化し、変更しやすい、あるいは変更をコントロールしやすい環境をつくるためのツール、と言えそうです。
文化
また、文化としては以下のような項目を挙げています。
まあこれは、人と協調して仕事をスムーズに進めるためにはどれも重要なことですよね。
以上が DevOps について、自分なりに得たことのまとめです。ツールについては、自分がペパボに入社してから導入や利用促進してきたもの、これから導入したいと思っているものなんかが、軒並み上のリストに含まれていて、DevOps の概念が頭にあったわけではないんですが、思いがけずそういう方向に行こうとしていたんだな、ということがこの言葉に出会うことによって確認できました。（それでエントリのタイトルがあんな感じになってます。）
DevOps 自体まだ定義として固まっているものではないようですし、かなり端折った形でまとめましたので、興味がある方は自分が参考にした以下のURLや、更にそこからのリンクを辿ってみてください。
Updated on 2010/03/25 10:18
Kindle 日本語タイトルスクリーンショット比較
Kindle Store で樋口一葉、芥川龍之介、夏目漱石らの日本語書籍が出てたのは以前から知っていたのですが、最近 Amazon Kindleで日本語のコンテンツが読める！ 日本語電子書籍「想隆社文庫」創刊！一般向けおよび図書館向けに提供を開始 といったプレスリリースが出てたので、どんなものか確認するために、実際に購入してみました。
結論から言うと、「6インチ Kindle 上では薄くて読みづらい。お金出して買う価値なし。今出てるタイトルなら、青空キンドルを使っとけ。」といったところでしょうか。
以前から出てた日本語タイトルのスクリーンショット。
最近プレスリリースが出ていた、「これまでの電子書籍と異なり、従来の紙の本好きが違和感なく読めることを重視。書籍DTPを行う職人による組版を採用し、版面の美しさを追求しました。」と謳われているもののスクリーンショット。
青空キンドルのスクリーンショット。
自分でスキャンしたもののスクリーンショット。
こうして比較してみると、青空キンドルが神すぎる。また、自分でスキャンしたものは文字サイズが小さいけど、濃さ的には上2つよりも読みやすい。実際、Kindle実機上だと上2つは、スクリーンショットのものよりも更に薄くて読みづらい。
どうやら上2つの Kindle Store で手に入る日本語タイトルは、すべて画像データの模様。（ちなみに、Kindle の azw フォーマットは、Mobipocket フォーマットをベースにしていて、文字データは HTML で記述する。）フォントの関係で、画像になっちゃうのはしかたないのかもしれないけど、文字サイズ変更もできないし、テキスト読み上げもできないし、その上読みづらい、といった感じで、Kindle 版を購入するメリットがまったくない。
発売されている（またはこれから発売予定の）タイトルも、すべて青空文庫で手に入るタイトルばかりのようなので、現段階なら青空キンドルを利用するのがベスト。
DX の方だともう少し読みやすかったりするのかもしれないけど、小説の類はDXで読むメリットはあまりないと思う。
ちなみに、実際にファイルを展開してみたら、やはり全部画像ファイルでした。ファイルの展開は Perl の EBook::Tools モジュールを利用すると簡単にできます。
$ perl -MEBook::Tools::Unpack \
-e 'EBook::Tools::Unpack->new(
file => "Natsume Soseki Story Selection v-asin_B00300H6UY-type_EBOK-v_0.azw"
)->unpack'
Updated on 2010/03/20 19:04
Puppet のススメ at hbstudy#8
hbstudy#8 で、「Puppet のススメ」というタイトルでプレゼンさせていただきました。機会をくださった株式会社ハートビーツの藤崎さん、馬場さん、坂口さん、また、運営スタッフのみなさま、聞きに来て下さったみなさま、twitter やブログで感想述べてくださったみなさま、本当にありがとうございました。
当日の資料は slideshare にアップしています。
内容は主に Puppet を知らない方、これから使ってみようかどうか検討している方をターゲットとして、
- Puppet とはどんなものか
- どんな風に動かすのか
- どういった使い方をすればいいのか
- 使うために知っておいた方がいいこと
- 使ってみて微妙だなと思うところ
といったお話をさせて頂きました。Puppet を既に実運用でバリバリ使っている方には、特に目新しい話はなかったと思いますが、そういった方からは逆にこちらが知らないこと、見落としてること、間違ってることなんかの情報をもらえればいいなー、という思いでプレゼンさせていただきました。
これだけではなんなので、プレゼンの補足事項とか、twitter のハッシュタグ #hbstudy やブログなんかで色々コメント頂いてますので、その辺まとめてみようと思います。
まずは twitter からいくつかピっくアップしてみます。
matsuu puppetの気づきにくいメリットの１つは、puppetをいつでもやめられること。puppetをやめても既存の設定はpuppetに依存しないのでいつでもやめられる。これ大きいよね。 http://twitter.com/matsuu/statuses/9521601261
これは確かにおっしゃる通りですね。Puppet でサーバ構築しても、できあがったものは特に Puppet に縛られるものではないので、いつ使うのやめても大丈夫です。そして、プレゼンでも触れましたが、単に動かしてみるだけなら、比較的さくっと試せます。使いはじめる、あるいは使うのをやめる敷居が低い、というのは良いツールの条件だと思いますので、これはとても大きいメリットですね。
yuzorock puppetの気付きにくいメリットの1つはsshではないこと。 http://twitter.com/yuzorock/statuses/9521698444
おっしゃる通り、メリットでもあると思うのですが、sshd で代用できたらいいのに という意見もあったりで、ここはなかなか難しい問題だなー、と思います。SSH ではないことは、メリットでもあるしデメリットでもありそうですね。メリットとしては、SSH 経由でマニフェストを適用するとなると、そのためのユーザ管理や鍵の管理、sudo まわりの設定、といったものが必要になるけど、そういった手間がかからない、といったところでしょうか。（他にもあれば教えて下さい。）逆にデメリットとしては、デーモンが常時上がってるとメモリ食うし、常にあがってる必要がないものがあがってる、という気持ち悪さ、といったあたりですかね。とくに、運用監視系のツールを色々入れていて、それぞれがデーモン持ってる、という状態はあまり好ましくないのではないかと思います。
xaicron manifest の学習コストはどうなんだろ http://twitter.com/xaicron/statuses/9521881525
yuzorock manifestの学習コストはたいしたこと無い。コマンド打つのとやることは同じだから。 http://twitter.com/yuzorock/statuses/9521927420
ここは感じ方は人それぞれだと思うので、一般的に学習コストがどうなのかを言うのは難しいのですが、自分は yuzorock さんと同意見で、それほど学習コスト高くないと思っています。
matsuu #hbstudy puppetでcron設定管理してるとcrontabがどんどん汚れていくんだぜ...gentooだけかも http://twitter.com/matsuu/statuses/9522038117
最近はマニフェストで cron リソース定義するよりも、file リソースで /etc/cron.d にファイル置く方がわかりやすいかな、と思ったりしてます。
matsuu あ、puppetのテンプレートの機能の話でてきた？ http://twitter.com/matsuu/statuses/9522545344
すみません、忘れてました！話したいことが多すぎて…テンプレートについて詳しく知りたい方は、 http://gihyo.jp/admin/serial/01/puppet/0007 とか Software Design の記事なんかをご覧ください。
hirose31 なにげに PSP がリモコン http://twitter.com/hirose31/statuses/9522592495
スライド操作パネル for PSP つかってます！これは超便利です。スライドの進行状況と残り時間がわかりやすく視覚化されるので、話しながら時間調整ができます。（Puppet関係ないですね。）
mkouhei うーむ、良い点よりも不満の方が多いように聞こえる。 http://twitter.com/mkouhei/statuses/9522637899
デメリットに触れているような文章はあまり見かけないので、敢えて不満点を色々上げてみましたが、こっちの方が目立っちゃいましたかね。自分としてはとても良いツールだと思っています。
次はブログから拾ってみます。
tokuhirom さんのブログ。tokuhirom さんの感想を見て思ったのは、Puppet を導入してメリットがあるかどうか、というのは、どういう状況に置かれてるのか、どういったことをツールで解決したいのか、に大きく依存するので、それ抜きでは語れないな、と。Puppet に限った話でもないし、当り前のことなのですが、再確認させていただきました。
これと併せて n0ts さんのブログ を読んでみると、やはり重要なのは、「いかに楽をするか」だよね、と。n0ts さんの意見にとても賛成です。でも、置かれてる状況や人によって、「どこで楽をするのか」は異なってきそうですね。tokuhirom さんの感想にある、
「シェルスクリプトで構築すればこれ簡単なのに!」みたいな場合に、いちいち puppet rule 書くのダルくね?
も、構築を自動化する、というポイントに置いて楽をしたいのであれば、シェルスクリプトでやっちゃうのが楽だと思います。そこを少し視線を変えて、構築シェルスクリプトはずっとメンテし続ける必要があるし、かといって作成した人がずっとメンテできるわけではないし、ずっとメンテできるとしても、長年メンテしつづけて作成した人にとってもカオスになることもあり得る、という状況が考えられる場合には、Puppet も選択肢のひとつとして検討に値する、といったことになるのではないかと。これはまさに、tokuhirom さんの感想にある
自由度を制限して、属人性を排除するというアプローチはアリだとおもう。
の通り、属人性を排除する、ということを考えると、Puppet は有力な選択肢になる、という例だと思います。
Updated on 2010/02/24 23:43
