Webエンジニアが知っておきたいインフラの基本

パフォーマンスチューニング

2020-04-01 23:59:16

Webエンジニアが知っておきたいインフラの基本

  • 1章 Webサービスでのインフラの役割
  • 2章 Webサービスを支えるインフラ技術の基礎知識
  • 3章 Webサービスのサーバ構成ベストプラクティス
  • 4章 Webサービスを始めるときのインフラ手配の基礎知識
  • 5章 Webサービスの運用(1) システム監視の基本
  • 6章 Webサービスの運用(2) ステータス モニタリング
  • 7章 Webサービスのチューニング(1) ボトルネックの見つけ方
  • 8章 Webサービスのチューニング(2) チューニングレシピ

1章 Webサービスでのインフラの役割

p.23

  • インフラの信頼性を確保する
    • RAS
      • Reliability:信頼性
      • Availability:可用性
      • Servicability:可用性
    • RASIS
      • RAS
      • Integrity:完全性
      • Security:安全性

p.24

  • RASを検討する
    • MTBF = 障害発生間隔(Mean Time Between Failure)
    • MTTR = 平均復旧時間(Mean Time To Repair)
    • 稼働率 = MTBF / (MTBF + MTTR)
    • MTBF = 累積使用時間 / 故障回数
    • MTTR = 累積修理時間 / 故障回数

2章 Webサービスを支えるインフラ技術の基礎知識

p.40

  • DNSの主なレコードの種類と意味
    • A
      • アドレス情報(IPアドレス)を設定する
    • PTR
      • ポインタ(ドメイン名に対するIPアドレス)を設定する
    • NS
      • ネームサーバを設定する
    • CNAME
      • Canonical NAME(正式名称)を設定する(エイリアスのようなもの)
    • TXT
      • ドメインに紐づくテキスト情報を設定する
    • MX
      • ドメインのメールサーバ情報を設定する

p.53

  • CPU・メモリのスペックと選び方
    • ソケット数
      • CPUそのものの搭載数
    • コア数
      • CPUあたりのコア数
    • スレッド数
      • CPUあたりのスレッド数(Hyperr Threading対応のCPUのカタログ表示のスレッド数はコア数の2倍)
    • 動作周波数
      • CPUの動作周波数
    • キャッシュメモリサイズ
      • CPUの内蔵のメモリサイズ
    • 最大メモリサイズ
      • 接続可能な最大メモリサイズ
    • 最大メモリ帯域幅
      • 接続可能な最大メモリ帯域幅
    • ECCメモリ対応
      • ECC(エラー訂正)機能つきメモリ対応

p.55

  • RAIDの種類
    • RAID0
      • ディスクを複数台使い、全体を保存領域とする
      • 読み書き速度の向上
      • OSからみたディスク容量増加の実現
      • 1台でも壊れると全壊
    • RAID1
      • ディスク1台にデータを保存し、ペアを用意
      • アクセス速度と容量は1台のときと変わらないが、1台が壊われても大丈夫なので冗長性がある
    • RAID5
      • データから訂正符号を生成し、データと訂正符号を一緒に複数のディスクに分散して保存
      • アクセス速度向上とディスク容量増加
      • ディスク1個まで壊れても大丈夫
    • RAID10
      • RAID0とRAID1の組み合わせ
    • RAID50
      • RAID0とRAID5の組み合わせ
    • RAID60
      • RAID0とRAID6の組み合わせ

p.56

  • ディスクの種類と特徴
    • HDD
      • 容量単価: 安い
      • 転送速度: 数百MB/s前半
      • I/O速度: 100~400IOPS
    • SSD
      • 容量単価: 高い
      • 転送速度: 数百MB/s中盤
      • I/O速度: 数千〜万IOPS
    • PCI express 半導体ストレージ
      • 容量単価: さらに高い
      • 転送速度: 数百MB/s後半
      • I/O速度: 数万〜十数万IOPS

p.60

  • バッファ
    • 処理を効率化し、ボトルネックを緩和する
    • 後工程の処理を効率化するために、データを一時的にためておく仕組み
    • ディスクやネットワークのI/Oは細かく大量の処理をするよりも、ある程度データ量が溜まって一気に処理するほうが処理効率がよい

p.61

  • キャッシュ
    • ボトルネック緩和
    • 処理の結果を一時的にためておく仕組み
      • 結果の使い回し

p.62

  • キューイング
    • ボトルネック緩和
    • 処理を登録しておく仕組み
    • ボトルネックに引きずられて全体のキャパシティを落とさないために使う

p.63

  • データの整合性をとるための方法
    • Shared Disk方式
      • ストレージを共有する
      • 整合性は特に問題にならない
      • Shared Disk自体を冗長化せねばという課題はある
    • Shared Nothing方式
      • ストレージを共有しない
      • ストレージ間で通信してデータの整合性をとる
        • レプリケーションという
          • データの送信元をMaster、 受信側をSlaveという
        • 同期型のレプリケーション
          • オーバーヘッドが大きい(同期処理に伴うパフォーマンス低下の程度が大きい)が、データは確実
        • 非同期型のレプリケーション
          • データ損失があるかもしれないが、パフォーマンス劣化は少ない

p.65

  • フェイルオーバーに関する注意点
    • StanbyだったものがActiveになることを昇格と呼び、この一連の動作をfailoverと呼ぶ

3章 Webサービスのサーバ構成ベストプラクティス

p.71

  • システム構成変更の基礎
  • 冗長化
    • 冗長性向上・可用性向上
    • 同じ機能・役割の機器を複数用意し、単一機器の故障の影響がシステム全体に影響しないようにする
  • 機能分割
    • 処理能力向上
    • 1題の複数機能を提供している場合、サーバーを機能ごとに用意することで1台あたりの処理負荷を小さくし、システム全体としての性能を向上させる
  • スケールアップ
    • 処理能力向上
    • 構成は変更せず、サーバーの性能そのものを向上させることで、システム全体としての性能を向上させる
  • スケールアウト

    • 処理能力向上
    • 同じ機能・役割の機器を複数用意し、処理を分担することで、システム全体としての性能を向上させる
  • Webサーバー×1 DBサーバー×1

    • 機能分割
      • 1台でサーバースペックが足りないときに採用されやすい
      • DBだけ切り出す、DBとFileを切り出すもある
  • Webサーバー×2
    • 冗長化
      • サーバー1(現用系)で問題あった際にサーバー2(待機系)を利用する方法
      • DBとFileはデータを同期する必要がある
  • Webサーバー×2 DBサーバー×1
    • 冗長化 機能分割 スケールアウト
      • Webサーバー×1 DBサーバー×1でもWeb側の性能問題が解決できないときに採用
  • Webサーバー×2 DBサーバー×2
    • 冗長化 機能分割 スケールアウト
      • Webの冗長化と負荷分散、DBの冗長化ができる

p.77

  • ロード・バランシングの2つの種類
    • 目的は負荷分散。冗長化の役割を果たすこともある。
    • 主な実現方法
      • ロードバランサ
        • サーバー側(受け側)に負荷分散の仕組みを用意する
      • DNSラウンドロビン
        • クライアント側(OSやブラウザの実装など)の挙動に依存した方法
        • DNSへの問い合わせの結果が複数あった場合に、受け取った順番に利用する実装の端末が多いため、DNSのAレコードに複数のIPアドレスを登録して、順番をランダムに応答することで、結果的に負荷が分散するであろうことを期待した方法

p.81

  • ロードバランサの振り分け先の接続方式
    • L4ロードバランサ
      • OSI参照モデルでいうところの第4レイヤー(TCP、UDP)までを解釈して取り扱う
      • 処理が少なくて済む
    • L7ロードバランサ
      • 第7レイヤー(HTTP、SMTPなど)までを解釈して取り扱う
      • L4より高機能な分、負荷のボトルネックになりやすい
      • リーバスプロキシと呼ぶこともある
      • レスポンスをキャッシュする、SSLの終端になる、レスポンスが500の場合はサーバーの代わりにエラー画面を表示するなどが可能
    • L4-NAT(Network Address Translation)
      • IPアドレス変換
      • IPアドレスと同時に通信に使うポート番号も変更するNAPT(Networkd Address and Port Translation)を使用することが多い
    • L4-DSR(Direct Server Return)
      • 数Gbpsを超えるようなトラフィックがあるシステムで使う
      • 戻りのパケットがロードバランサを通らないようにすることでロードバランサがボトルネックにならないようにする

p.84

  • ロードバランサでの振り分け先の決定方法
    • ラウンドロビン
      • 振り分け先リストにある順番にアクセスを振り分ける
    • 荷重ラウンドロビン
      • 荷重の指定に従って特定の振り分け先に多く(少なく)振り分ける
    • 最小コネクション
      • 接続数が少ないサーバーにアクセスを振り分ける
    • 荷重最小コネクション
      • 荷重の値を考慮した最小コネクション

4章 Webサービスを始めるときのインフラ手配の基礎知識

  • N/A

5章 Webサービスの運用(1) システム監視の基本

p.102

  • 「システム監視」とは何か
    • 「正常な状態」を監視項目+正常な結果の形で定義する
      • 初めは要件定義や現状からわかる範囲で定義し、運用
      • 監視項目とセットでアラートの閾値も決める
    • 「正常な状態」でなくなった際の対応方法を監視項目ごとに定義する
      • 復旧優先なのか、再発防止優先なのか考えておく
      • 運用フローやエスカレーションの方法も検討
    • 「正常な状態」であることを継続的に確認する
      • ツールを使って確認
    • 「正常な状態」でなくなった場合には「正常な状態」に復旧させる。必要に応じて再発防止策を講じる
      • 一次対応(暫定対応)・二次対応(根本対応)に分ける。方針に従う。

p.108

  • 監視項目を洗い出す
    • システム監視
      • 外形監視
      • 内部監視
        • サービス稼働状況監視
        • システムリソース監視
    • システム要件や構築要件から機能要件と非機能要件を洗い出す
    • 構築済みのサーバーそのものからテストを作成する

p.109

  • 監視の実装方法
    • アクティブチェック
      • 監視Sサーバー側から能動的にチェックする方法
    • パッシブチェック
      • 監視対象側で異常を検知して監視サーバーに申告する方法

p.110

  • 監視項目を決めるための現状確認方法
    • ファイアウォールの設定を確認
    • プロセスを確認する

p.115

  • 現状確認結果から監視項目を作る
    • プロセスから機能要件を洗い出す
      • 起動プロセス数を確認
      • I/Oがある場合は詳細を確認
        • サービス系のネットワーク入出力があるか
        • 管理系のネットワーク入出力があるかどうか
        • サービス系のファイル入出力があるかどうか
        • 管理系のファイル入出力があるかどうか
        • etc
    • 外形監視定番項目
      • HTTPレスポンスコード・内容・応答時間・サイズ
      • HTTPSレスポンスコード・内容・応答時間・サイズ
      • POP、SMTP、FTP...死活・疎通・メール送受信やファイルPUT/GETなど
      • HTTPシナリオ
    • 内部監視定番項目
      • CPU使用率
      • ロードアベレージ
      • ディスクごとの使用量
      • ディスクごとのレイテンシ
      • ネットワークインターフェイスごとのトラフィックIN/OUT
      • ローカルからのHTTP接続
      • サービスに使うプロセスの監視
      • システム的に使うプロセスの監視

p.117

  • いざ障害が発生したときの障害対応方法
    • 発報→事象を確認→一次対応→発報事象と他の項目を確認→事後作業→収束

p.118

  • 一次対応
    • 操作ログを残す
      • script -q -c "ssh www.example.com" www.example.com.20140817_14_57:30.log
      • history
    • 状況確認コマンド
      • w
        • システムの稼働時間、ログインユーザー数、ロードアベレージを確認
      • ss -lnp
        • ネットワーク接続数、接続元、接続先、実行プロセスとPIDを確認
      • ps aufx
        • 起動プロセスを確認
      • df -h
        • ディスク使用量を確認
      • top -b -d 1 -n 1
        • CPU利用率、メモリ使用量、CPU使用率が高いプロセスを確認
      • topc -b -d 1 -n -a
        • メモリ利用量が大きいプロセスを確認
      • dstat -taf 1 10
        • CPU使用率、ネットワーク利用リョウ、ディスクI/O量、ページング量と推移を確認
      • mysqladmin processlist --verbose
        • 接続元IP・ポート、接続先DB、ステータス、SQL
      • ミドルウェアやあアプリケーションのログを確認

6章 Webサービスの運用(2) ステータス モニタリング

p.137

  • モニタリングツール
    • polling型
      • モニタリングツール側から情報収集のためにアクセスをするタイプ
    • push型
      • モニタリングツール側にデータを送信するタイプ

p.138

  • CPU関連のグラフ(Percona Linux Monitoring Template for Cacti)
    • CPU Usage
      • CPU User
        • ユーザ領域(カーネル領域でない)でのCPU利用率
        • ex. webサーバーなどでPHPなどのプログラム処理に利用した分
      • CPU Nice
        • Niceされた分のCPU利用率
        • ex. 運用系のバッチ処理などniceコマンドを利用して優先度を調整した処理
      • CPU System
        • カーネル領域でのCPU利用率
        • ex. メモリアクセスなどカーネル領域でのCPU利用率
      • CPU Idle
        • アイドル状態でのCPU利用率
      • CPU Iowait
        • I/O待ちでのCPU利用率
      • CPU Irq
        • Irq(割り込み)処理でのCPU利用率
      • CPU Softirq
        • Softirq(ソフト割り込み)処理でのCPU利用率
      • CPU Steal
        • 仮想マシンから盗まれた(stolen)CPU利用率
      • CPU Guest
        • 仮想マシンが利用した分のCPU利用率
    • Context Switches
      • CPUでの処理対象プロセスなどの切り替え回数
      • プロセスの並列度が高く、単位時間あたりの処理が多いシステムでは値が大きくなる
    • Forks
      • プロセス生成処理
      • ForkはCPUコストがかかる処理
    • Interrupts
      • ネットワーク送受信などによる割り込みの数
    • Load Average
      • 絶対値はあてにできないが、値の変化は状況の変化を表すので他の指標と見比べてボトルネックが発生していないか確認する

p.185

  • リアルタイムモニタリングのしかた
    • dstat
      • CPU使用率・ディスク・ネットワークのI/O状況をまとめて確認できる
    • top
    • iostat

p.191

  • トラブル対応で使うモニタリングツール
    • tcpdump
    • strace
    • lsof

7章 Webサービスのチューニング(1) ボトルネックの見つけ方

p.200

  • キャパシティの考え方とキャパシティ向上
    • キャパシティ向上
      • 単位時間あたりの処理性能を上げる
        • ハードウェア性能や物理配置などの物理的な制約できまる
      • 単位時間あたりの所要処理量を上げる
        • 単位時間あたりの所要処理量 = 単位時間あたりのアクセス数×1アクセスあたりの処理量

p.202

  • システムチューニングの鉄則
    • ターゲットとゴールを決める
      • 何を改善するか
    • ボトルネックにアプローチする
    • 推測するな計測せよ

p.205

  • ボトルネックの見つけ方
    • ターゲットとゴールを決める
    • データフローを確認する
      • FQDNからIPアドレスを確認
      • IPアドレスからサーバーを確認
      • IPアドレス・ポートからデータを受け取るプロセスを確認
      • ミドルウェアの設定から実行されているプログラムを確認
    • データフローのポイントごとに処理内容を確認する
    • システムリソースを確認する
      • リソース確認事項
        • CPU性能
        • メモリ
        • ネットワーク
        • ディスク
      • LAMP+memcachedシステムの確認事項
        • OS
          • システムリソース上限に達していないか
        • Apache
          • 並列数上限に達していないか
          • MaxClients
        • PHP
          • メモリ利用可能料上限に達していないか、php-fpmなら並列数上限に達していないか
          • memory_limit, pm.max_children
        • MySQL
          • 並列数上限に達していないか
          • max_connections
        • memcached
          • 並列数上限に達していないか
          • -c(max connections)

p.218

  • ボトルネックの見つけ方(サーバーリソース編)
    • 値が一定値でえ推移している
      • 性能上限に達している可能性
    • 前日・先週の同じ曜日・先月の同じ日と値の動き方が等しく異なる
      • 起きるべき変化が起きているか
    • 値の変動が激しい

8章 Webサービスのチューニング(2) チューニングレシピ

p.248

  • OSでのチューニングの話
    • カーネルパラメータチューニング
      • ネットワーク性能を向上できる
        • 制限を緩和し、キャパシティを増加させること
        • リソースの再利用を迅速にすることでリソースの回転率を上げること

p.270

  • SSL通信を高速化する
    • SSL Session Cache

About the author

Image

bmf san @bmf_san
A web developer in Japan.