[書評] 24時間365日 サーバ/インフラを支える技術

同業者として、そして同系統の設計と運用を担当する者として読まずにはいられない一冊。

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)


本書は主に、OSSを用いて高い可用性(耐障害性)と拡張性を実現するインフラを構築することを主眼としてる。まえがきの言葉を借りれば「『冗長化』されていて『スケーラビリティ』もあるインフラを作る」ことが目的だ。

この種類の技術は、本書でも触れられているがあまり世間には流通していない。その意味で大変貴重な一冊といえる。しかし本書でカバーしていない領域はそれなりにあるので、これ一冊でオールOKというわけではないので注意が必要だ(ひょっとして確信犯的にやっていて続編の出版を企てているのかもしれないが)。

トランザクションの重要度」はミッションクリティカルなシステムのレベルではない

想定購買層を考えれば妥当な設定なのかもしれないが、例えば銀行のシステムインフラを設計する者には物足りなさが残る。その意味で、本書で想定するシステム特性(トランザクションの重要性のレベル感)についてもう少し詳しく前提を記載してほしかった。


十分承知してもらえると思うが、対障害性や拡張性を確保する設計は必ずしもOSSや、汎用的なHW構成に依存しない。例えば、データの同期はお金があれば(かけてでも不整合のリスクを低減したいシステムなら)レプリケーションとせず、共有ディスクを使う選択肢もある。DBはOracleRACを使うかもしれない。


障害(と一口にいってもかなりのパターンがあるが)が発生したときにFailOverなりで業務を継続する(仕掛けを用意するの)のはよいとして、実際にはその設計に対して

  1. 仕掛かり中のトランザクションがどうなるか?
  2. セッションは生きているのか?
  3. 業務影響の範囲は?
  4. ログには何が出力される?
  5. 手フォローが必要な範囲はどこまで?

などといったことをシステム特性に合わせて調査、テストしSLAを確保する必要がある。しかし、残念なことに本書では、その手法についても、その結果についてもほとんど記述がない。

運用面でのシステム設計はリソース監視以外抜けている

本書では、各種リソースの監視については記載があるが残念ながらその続きがない。実際のシステムでは加えて、各種ログ監視、ジョブ/フレームの実行基盤が不可欠となる。

RDBMSは障害の予兆として「Warning」をログに出力しているかもしれないし、アプリログには業務エラーが記録されているかもしれない。ログローテーションやバックアップ、アプリバッチの実行はシステムが生きていくには不可欠な活動だ。

これらは一般的にはJP1のような運用管理ソフトウェアを使って実現することが多いがOSSでもHinemosのようなものがある。分量的な問題もあるかと思うが、このあたりの領域まで踏み込んで「運用」のパートを語ってほしかった。

とはいえ、お買い得な一冊

個人的に、もの足りない領域があるものの、全般的に出し惜しみせず色々なノウハウが公開されていて、実にお得な一冊である。もしインフラ設計者だったら、これを読んだ後では持ち駒が格段に増えること請け合いである。