8
18

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

5分で【サーバ/インフラを支える技術】を読んだ気になる

Last updated at Posted at 2017-10-12

最近は業務でシステム構成図を見ることが多くなってきた。
見てもよくわからないことが多いので、何か勉強しようと思い、
【サーバ/インフラを支える技術】を読んだ。
せっかくなので、目次に毛を生やした程度にまとめてみた。

【第1章】サーバ/インフラ構築入門

  • システムは、障害がいつ起こってもいいように設計しなければならない
  • そのためには、ルータ、ロードバランサ、サーバ、全てを冗長化する必要がある
  • 冗長化した際に大切なことは、
    • 障害の検出(ヘルスチェック)
    • スムーズな切り替え(IPアドレスの引き継ぎ)
  • スケジューリングアルゴリズム、VRRP、色んな仕組みが使われている

【第2章】ワンランク上のサーバ/インフラの構築

  • キャッシュサーバをリバースプロキシとして使うと、APサーバへの負荷分散ができる
    • リクエストの内容によって、サーバを切り替えることができる(L7スイッチの役割)
    • HTML, CSS, JS, 画像等の静的コンテンツはキャッシュサーバから返す
    • [HTTPプロトコルレベル:Squid], [Webアプリのデータ:memcached]
  • MySQLも冗長化(レプリケーション)し、かつスレーブを有効活用する
    • データを参照するだけのリクエストはスレーブを参照させると良い
    • もちろんスレーブも内部ロードバランサ(Linux)で捌けるようにしておく
  • HTTPをストレージプロトコルとして利用することで、サイトが全停止する危険を回避
    • 単一故障点を防ぐために冗長化が必要
    • 複数台のサーバにファイルを同期さると不具合が起きやすい
    • これら2つの課題は第3章で

【第3章】止まらないインフラを目指すさらなる工夫

  • DNSサーバの障害はなかなか起きないが、起こった時には原因特定がかなり難しく影響範囲が広い
    • ロードバランサにVIPを持たせ、Active/Active構成で冗長化する。(IPVS, keepalive)
  • ストレージサーバの同期は困難 -> DRBDを用いて解決
    • DRBD:ファイル単位ではなく、ブロックデバイス単位でリアルタイムにレプリケートする
    • keepalivdをdaemontoolsで制御する
    • 誰かが間違えてファイルを消すと即座にバックアップに反映してしまうのが弱点
  • Bondingドライバを用いて、L1,/L2も冗長化する(リンク、スイッチ)
    • 冗長化しすぎるとループができてしまう(ブロードキャストストーム)
    • RSTPで解決(自動的に冗長な接続を遮断する)
  • VLANを用いてネットワークを柔軟に
    • ポートVLAN:スイッチのポートごとにVLAN識別子を割り当てる
    • タグVLAN:EthernetフレームにVLAN識別情報を挿入する。論理構成が複雑になりがち。
    • サーバファームでの利用は、タグVLANを使用することで、物理的な無駄を無くせる
    • ポートVLANを基本とし、必要なところにタグVLANの設定を行うのが理想
    • VLAN構成が複雑になっても、物理構成はシンプルさを求める

【第4章】性能向上、チューニング

  • これまでの冗長化に合わせて、単一のホストの性能を引き出すことによって初めて負荷分散の意味がある
    • 負荷は推測するのではなく、計測する:ロードアベレージを見る
    • CPU負荷とI/O負荷の2種類あり、どちらがボトルネックかを調べる
    • ps, sar, vmstat, top,,, 様々なコマンドを使って確認する
    • カーネルコードを見ることで、負荷計算方法の理解をより深める
    • チューニングとは、ボトルネックを発見し、それを取り去ることのみ
  • Webサーバ(Apache)にもチューニングはできるが、ほとんどの原因は別の場所に存在する
    • 強いてあげるなら、並列処理の際のMPMに何を選択するかが重要になる
    • サーバが搭載する物理メモリと1プロセスの平均メモリ消費量によってMaxClientsを決める
    • perfork:マルチプロセス。普段使いならこちらで良い。
    • worker:マルチスレッド。軽量で高速であるが、設定が複雑。
  • MySQLのチューニングはテーブル設計やSQLの最適化が効果的
    • サーバサイドで出来ることは、メモリ関係のパラメータチューニング
    • バッファ:innodb_buffer_pool_sizeとかとか

【第5章】省力運用

  • 省力運用のために様々なツールが用いられる
  • Nagios:サービスの稼働監視
    • 死活状態
    • 負荷状態
    • 稼働率の計測
  • Ganglis:サーバリソースのモニタリング
    • CPU使用率、メモリ使用率
    • ロードバランサ
    • ネトワークトラフィック
  • Puppet:サーバ管理の効率化
    • 新規サーバの投入
    • 既存サーバの設定変更
    • 台数が多いところ、手動では設定漏れが発生しがちなところが優先
  • deamontools:デーモンの稼働管理
    • プロセスが落ちた時に自動で起動しなおしてくれる
    • 手軽にデーモンを作れる
  • PXE、initramfs:ネットワークブートの活用
    • ネットワーク上のサーバから読み出すため、二次記憶装置が必要ない
    • ロードバランサやDB,ファイルサーバに活用されることが多い
  • リモートメンテナンス
    • SSHでリモートログインすると楽だけど、OSが起動していないと使えない
    • シリアルコンソール、IPMI等を用いて対処する
  • Webサーバのログの扱い
    • ログを扱いやすくするためには、1つの場所に集約、収集する必要がある
    • アクセスの集計やトラブルの解析に利用される
8
18
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
18

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?