書いてみたい本

将来、以下のテーマで本を書いてみたいなと妄想している。

• システムアーキテクチャの入門本
• 超実践データベース性能トラブルシューティングガイド
• Oracle Database のSQLチューニング本
• Oracle Database のトラブルシューティング本
• Oracle Database のデザインパターン本
• システムアーキテクチャのデザインパターン本

まずはシステムアーキテクチャの入門本について書きたいと思っていることを書きだしてみた。

タイトル案

• 絵で見てわかるサーバ／インフラの仕組み

特徴

• システムを構成しているコンポーネントの「つながり」がわかる
• 絵や例えを使って仕組みをわかりやすく説明している
• 仕組みを説明した上で、仕事の現場でどのように活かせるかが書かれている
• 仕組みを説明した上で、その説明を使って最近話題の技術を理解できることを示している
• ハードウェア、OS、ミドルウェアなどのレイヤーやプロダクトが異なっても、似たような考え方や仕組みが使われている。そのデザインパターンを説明している。
• さらに詳しく知りたい場合の参考書籍を紹介している

対象読者

• 初中級のインフラエンジニア
• 身に付けている経験と勘をうまく説明できない方
• パフォーマンスチューニングやトラブルシューティングに強くなりたい方
• システムのアーキテクチャを設計できるアーキテクトになりたい方
• 低レイヤーの知識を身につけたい方

私ですねw。自分が欲しい本を自分で書きたいと思ってるということか。

売り

• 単なる知識ではなく「考え方」を学べるので、この本で基礎力をつければ、後は自力歩行（自分でさらに詳しく調べる）できるようになる。
• 初心者が中上級者へのドアを開くきっかけになる本。
• 初心者以外でもわかっているつもりでわかっていないことを再確認できる本。
• ブログなどで話題の最新技術について、なぜその技術が話題になっているのか、メリット／デメリットなどが理解できるようになる。
• パフォーマンスチューニングやトラブルシューティングで必要とされる基礎知識が身につく。
• OSやデータベースの設定やチューニングなどについて、丸暗記・経験・勘ではなく「なぜか」がわかるようになる。

参考情報

• 参考書籍やおすすめの書籍を紹介したい。

取り上げたいと思っているネタ

• C は Java より速い？
• MySQL と Oracle Database どっちが速い？
• なぜコネクションプーリングを使うのか？
• ノンブロッキングI/O
  • node.js、GlassFish などと絡めて
• C10K問題
• I/Oスケジューラ
• マルチプロセッサ・システムでの排他制御は難しい
• CPU使用率が高い＝悪か？
• フルスキャンは悪か？
• CAP定理
• BASE理論
• SPDY
• ACM、Atomic Write
• オーダー表記
• 並行と並列の違い
• fsck

うん、常識みたいですよ。@wrcsus4: 停電明けで検証サーバを再起動したら fsck実行 → メモリ不足でエラー → 起動失敗 していた・・・ 本番サーバではfsckの定期実行って無効にするのが常識なのかなぁ。知りたい。

Twitter. It's what's happening.

• 帯域制御は大切
• 技術の歴史
  • 汎用機のOS、UNIX、Windows などは全然違うようで、仮想メモリ、プロセススケジューラ、ファイルシステム、システムコールなど基本機能には共通点がある。実は脈々と受け継がれていて、全く断絶しているわけではない。
• ノイマン型、チューリングマシン
• OSのカーネルってなに？
• 低レイヤーがわかれば見えてくるファイルシステム、rawデバイス、ASMの違い
• ハードウェアコンポーネントの接続
• Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
• ウェブのアーキテクチャパターン＝空間と時間の分割、という話 - kazuhoのメモ置き場
• ［4］「きたーー!!」、ついに目標性能を達成 | 日経 xTECH（クロステック）
• カラム指向データベース
• Oracle Databaseで複数セッション接続しているとき、サーバー側はIPとポート番号が同じになるが、パケットが届いたときに、どのセッション（プロセス/スレッド）宛てかどうやって判断しているか
  • たぶん、クライアント側のIPとポート番号で判断している

蛇足

• 現在のITの現場では、各分野の担当はいるがシステム全体を俯瞰できるアーキテクトが少ないと思う。F1でいうと Adrian Newey みたいなエンジニア。
• アーキテクトでなくても、トラブルシューティングやパフォーマンスチューニングにおいては広く深い知識が要求される。効率的に広く深い知識を身につけるコツは「本質」の理解ではないかと思う。
• 良書はたくさん存在するが、初心者には難しいものが多い気がする。超初心者向けか、1万円弱する鈍器レベルの重厚な本か。最近、その中間の本が増えてきている気がする。
• 経験・勘の世界で、図や言語化できない領域もあるが、まだまだできる余地がいっぱいあると思う。
• 自分は人にうまく説明できないことはだいたい深く理解していない。
• できる人は頭の中に絵をイメージして、トラブルシューティングやパフォーマンスチューニングの際は頭の中でシミュレーションしていると思う。自分は頭の中だけではできないので、紙に絵を書くことが多い。外から見ると、そいう人がトラブルシューティングしたり、チューニングしたりしている様子を魔法使いが呪文を唱えて魔法を使っているように見え、別世界の人に見えるかもしれないが、実はそういう人は頭の中ではシンプルな絵が動いていたりする。
• 「量は質に転化する」というのがあるので、ある程度は経験しないと身にならないと思うが、もう少し高速道路があってもいいと思う。
• 基本や本質を押さえていると、OSやミドルウェアや言語が違っても、たぶんこうだろうという仮説を立てることができ、自分で検証して確認できるようになる。
• 多様な事象は全く異なる事象ではなく、いくつかのパターンに分類できたりする。表面的な理解は次に活きないのでもったいない。
• 「ORA-XXXXX が出ました、どうしたらいいですか？」と聞かれることがある。神のようにわかると思われることがあるが、だいたいは知らないメッセージで、意味を調べて動きをイメージしてたぶんこうだろうと仮説を立てて、机上または実機で検証して原因を特定している。ぱっとわかる変態もいるw
• 新製品や新機能のマーケティングメッセージを(ry

追記(2012/04/01):
この辺を意識して書いたらよいかなと思ってます。

1. 何の役に立つか
2. なぜ生まれたか
3. 抽象的な本質の説明
4. 具体的にどういうところでどういうふうに使われているか（2例ほど）
5. 使いどころ
6. 使うときのコツと注意点