投稿元:
レビューを見る
冬休みに全部読み切った。インフラの構成だけでなくcactiとかの見方やトラブルシューティング、チューニング、キャパプラなどが体系的に書かれていて良書。サーバサイドの新卒2〜3年目氏におすすめ
投稿元:
レビューを見る
OSS(Apache、PHP、MySQL、いわゆる LAMP)の Web システムの構成や監視、チューニングが主な内容。
そこまで難しい内容は無いが、かなりよくまとまっていると思う。構築手順などは詳しくないので、そこは自習なりする必要がある。
MySQL のチューニングなども良く書かれているので、時々読み返したいです。
投稿元:
レビューを見る
良著。頭から読み直したり困った時の拠り所として使ったりすることで、自分の知識としてキチンと習得したい内容。
投稿元:
レビューを見る
発売してすぐに購入したけど、なかなか時間があわず、ようやく読めた。
最後のほうは全く分からなかった。運用的な内容だからだろうけど。
こういうところはこれからもっと勉強しなきゃいけないんだろなと思った。どういうサーバを選んだらいいかとかOSのインストール方法とか全然分かってない自分。
最近はクラウドがあるから敷居は高くないのかもしれないとも思った。
投稿元:
レビューを見る
いわゆるインフラエンジニアが普段何をやっているのか、何に苦労しているのかを分かりやすく解説している。
タイトルの通りWebエンジニア向けに書かれているのでわかりやすかった。
ちょうどパフォーマンスが悪くなったサーバーがあったので手を動かしながら試していけたのがよかった。
しかしながら監視の項目ではツールに依存した表記になっていたので、このツールを使わない場合は何で読み替えればいいのかわかりにくかった。
投稿元:
レビューを見る
Webアプリケーションのパフォーマンス向上のためのtipsが詰まった良本。今はそれほど興味がわかないけど、興味があるときに読んでいれば、だいぶ楽しかったと思う
投稿元:
レビューを見る
1ページあたりの文字数が多いので読者側からすると読みづらいのではないかと思う。基礎編、応用編の2冊にしてもいいくらい。
内容は充実していても読者が読みづらいのはどうかな。
2015/7/15追記
索引は使いやすかったので評価を★2から★3に変更。
投稿元:
レビューを見る
- ページあたりの文字数がそれほど多くな読みやすかった
- Cacti で取得出来る各種グラフの意味や読み方等はとても参考になった(今までフワッとしか知らなかった)
- パフォーマンスチューニングについて著者の経験も交えて書かれておりとても参考になりつつ、今まで雑にしか認識していなかったことの復習になった
投稿元:
レビューを見る
レビュー書いた http://kimikimi714.hatenablog.com/entry/2015/12/08/210000
投稿元:
レビューを見る
勉強会メンバーの評判が良かったためkindle版を購入。
AWS、GCE、Azureなどの隆盛によりいわゆるWeb系のフロントエンジニアでもインフラ周りの知識も持っているべきだと思います。最近は「フルスタックエンジニア」という言葉もありますし。
インフラの基礎知識やサーバ構成のベストプラクティス(負荷分散はどうするかなど)、ちょっと意外な方面ではシステム監視やチューニングの方法など、広く説明しています。
しかし「基本」とあることからも分かるようにあまり深い内容には触れていません。個人的にはちょっと不満がある内容です。とはいえ、これらを深く説明しようとするとその分だけ本が必要になると思うので、全体を俯瞰したうえで、自分が必要な分野には本を買い足す、というのは有効ではないでしょうか。
投稿元:
レビューを見る
「インフラの設計から構成、監視、チューニングまで」のうち、主に監視とチューニングにページが多く割かれている。Webエンジニアを対象としているだけあって、OS、Apache、PHP、MySQLなどそれぞれのレイヤの観点で説明がなされている。具体的なツール名やconfig名まで出てくる。
1章 Webサービス構築に関係するインフラの役割や範囲
2章 インフラ技術の基本知識
インターネットを通してのデータのやり取りに関係する技術、インフラ要素(機器)のスペックの読み方、性能やデータに関する基本知識
3章 Webサービス構築のためのサーバ構成のベストプラクティス
基本パターンをベースとして、目的に応じていくつかの構成を紹介、負荷分散の基礎知識
4章 インフラ手配時の基礎知識
要件に応じて、回線やサーバなどの必要キャパシティの計算方法、構築後の検収作業
5章と6章 システム監視の基本、障害が起きたときの対応方法、システムモニタリングをする際の見方や対応のコツ
Cactiと「Percona Monitoring Plugins」を例に、さまざまなグラフの見方
7章と8章 ボトルネックの見つけ方やチューニングの方法
複数の切り口からのボトルネックの見つけ方の具体例、目的別のチューニングレシピ
投稿元:
レビューを見る
Webインフラのお勉強。
Shared Nothing方式の場合はストレージ間で通信してデータの整合性をとっています。これをレプリケーションと呼び、レプリケーションのデータ送信元を「Master」、データ受信側を「Slave」と呼びます。
システム監視とは
1.「正常な状態」を監視項目+正常な結果の形で定義する。
2.「正常な状態」でなくなった際の対応方法を監視項目ごとに定義する。
3.「正常な状態」であることを継続的に確認する。
4.「正常な状態」でなくなった場合には「正常な状態」に復旧させる。必要に応じて再発防止策を講じる。
障害対応中の心構え
・落ち着いて
・冷静に
・大抵事前に決めた通りにすれば大丈夫だから、まずは勘に頼らず事実とデータを見る
・自説にこだわらない。見切り・諦めを素早く。思い/期待通りじなくてもがっかりするのは後で
・うまくいかなくても担当者を責めない。判断誤りを責めない。結果を責めない。でも手抜きは絶対に許さない
・自分が知らないこと・知らない挙動があることを認識する
・ぐぐって適当にコピペして満足しない。でも使えそうなら使う
・水分を摂る、甘いものを摂る、油物を摂る、深呼吸する
・意識的に一歩引く
大障害の時の心構え
チームで役割分担する
対応担当
・実際に手を動かして調査・対応をする
・障害対応は、スキルがない人がやると時間をかけても対応できないので、対応するスキルを持っている人をアサインする
情報管理担当
・いつなになにをしたかなどの情報を記録する
・いつどんな状況であったかを記録する
・いまどんな状況かを記録・更新し続ける
コミュニケーション窓口担当
・顧客・社内の他チームなどとのやりとりの窓口
司令塔
・全体を俯瞰して、対応することや対応する順番、対応方法の取捨選択をする
・情報管理担当が収集・整理した情報を確認し方針をつど
・対応担当と相談しつつ対応を進める
司令塔は絶対に一人
・司令塔と対応担当が専念できるようにがんばる
・チームは少数精鋭
コミュニケーションパスが増えるとコストは指数関数的に増える
・ただし人海戦術を使う場合・部分は除く
きちんと交代劇
・兼務は大変
変化に気づくためのコツ
1:ないはずの変化がある
2:あるはずの変化がない
3:量・単位が違う
4:解像度を意識して傾向を見る
投稿元:
レビューを見る
チューニングなどについて書いてある良本。
いざチューニングするとなった時や、インフラ構成を考える時に読み直したい本
投稿元:
レビューを見る
大書:Webサービスを提供をするにあたっての、コンピュータ、ネットワークなどの基盤とよばれている検討から、設計、実装、導入後のチューニングの方法までを扱っています。
前半は、基盤技術の基礎の解説、後半は、監視・モニタリングから、ボトルネックの調査、解析と、チューニング方法がのべられています。
要点・項目のみかいつまんで
■基盤設計
・Webシステム構築の対象
コロケーション(データセンター、空調など)、ネットワーク、ハードウエア、OS、ミドルウエア、アプリ実行環境、アプリ
・工程 要件定義⇒設計⇒調達⇒構築⇒運用
・インフラ要素技術
OS,サーバ、ストレージ、データセンター、ドメイン、DNS,ネットワーク機器、ネットワーク技術、SSL証明書
・非機能要件
可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境
・新体制 RAS 信頼性、可用性、保守性
・サービス稼働率の向上 ホットスタンバイ、コールドスタンバイ
Active-Active,Active-Standby(Hot Standby,Warm Standby,Cold Standby)
大規模災害対策 DL:ディザスタリカバリー
・プロビジョニング
スケールアップ 性能向上
スケールアウト サーバの台数をふやす
■基礎知識
・ネットワーク IPアドレス、ドメイン、ルーティング、NAT,プロトコル、ファイアーウォール、スイッチ
・サーバ CPU、コア数、スレッド数、メモリ、
・ディスク SATA,SAS,RAID(0,1,5,6,10,50,60) HDD,SSD,PCIexpress
・データ ACID 電子性、一貫性、独立性、永続性、ロック・排他、バッファ、キャッシュ
暗号化
・冗長性 Master/Slave フェールオーバクラスタリング
■サーバ構成
・APサーバ、Webサーバ、DBサーバの配置
・ロードバランシング(ラウンドロビンと最小コネクション)
・仮想化、クラウド(AWS,GCPetc)
■運用
・システム監視 障害監視、リソースモニタリング、ファイアウォールログ解析
■チューニング 推測するな計測せよ
・キャパシティプラニング、ボトルネックアプローチ、システムリソースの確認、処理能力の向上、負荷の軽減、データ転送量の軽減、CPU利用率の軽減、等
目次は以下です。
#1 Webサービスにおけるインフラの役割
#1-01 Webサービス構築に関係するインフラ領域の全体像
#1-02 インフラの要件定義から運用までのフローの注意点
#1-03 インフラ設計の際の注意点
#1-04 RASを検討する
#2 インフラ技術の基礎知識
#2-01 インターネットという巨大ネットワーク
#2-02 インターネットごしにデータを届ける・受け取るしくみ
#2-03 URLを分解してみる
#2-04 プロトコルの裏側を覗いてみる
#2-05 ネットワークセキュリティの話
#2-06 インフラ要素のスペックの読み方と選び方
#2-07 性能とデータに関する基礎知識
#2-08 冗長化の仕組み
#2-09 暗号化とハッシュ化
#3 Webサービスのサーバ構成ベストプラクティス
#3-01 基本的な構成
#3-02 負荷分散(ロードバランシング)の 基礎知識
#4 インフラ手配の基礎知識
#4-01 インフラ手配の際、まず何を決める?
#4-02 インターネット回線のキャパシティ計算
#4-03 サーバ台数のキャパシティ計算
#4-04 利用する基盤の選定
#4-05 構築が終わったら確認すべきこと
#4-06 バックアップ
#5 Webサービスの運用(1) システム監視の基本
#5-01 システム監視概論
#5-02 システム監視実装
#5-03 いざ障害が発生したときの障害対応方法
#5-04 大障害のときの心構え
#5-05 日々起きる障害の管理と振り返り
#6 Webサービスの運用(2) ステータスモニタリング
#6-01 ステータスモニタリングの基礎知識
#6-02 ステータスモニタリングデータの読み方(OS)
#6-03 ステータスモニタリングデータの読み方(MySQL)
#6-04 リアルタイムモニタリングのしかた
#6-05 トラブル対応で使うモニタリングツール
#7 Webサービスのチューニング(1) ボトルネックの見つけ方
#7-01 キャパシティの考え方とキャパシティ向上
#7-02 システムチューニングの鉄則
#7-03 ボトルネックの見つけ方(基礎編)
#7-04 ボトルネックの見つけ方(ログ編)
#7-05 ボトルネックの見つけ方(サーバリソース編)
#7-06 ボトルネックの見つけ方(アプリケーションコード編)
#8 Webサービスのチューニング(2) チューニングレシピ
#8-01 ポイント別チューニングレシピ
#8-02 SQLチューニングでの高速化
#8-03 システム構成変更でのボトルネック対策の基礎
#8-04 「DB」のスケールアウトの実装例
#8-05 機能分割実装例
#8-06 キャッシュ適用での高速化
おわりに
Index