参考書を読んだメモ : 1冊ですべてわかるネットワーク運用・保守の基本 2章
1冊ですべてわかるネットワーク運用・保守の基本
ネットワーク運用管理の基本
ネットワーク運用管理
ネットワーク運用管理の概念
- 運用管理
- ネットワーク監視や月次のトラフィック報告書のまとめ
- ネットワークに何か問題が起きた際の対応
- 運用管理の役割
- ネットワーク運用サービスの安定供給とサポート
- 障害の影響と最小化
- アクセス管理
インシデント管理
- インシデント管理の目的
- サービスが普段と異なる状態に陥った際に、初動対応を行い、サービスへの影響を最小化すること
- インシデントとはネットワークサービス品質・状態が普段と違う、満たさないなどの事象
- インシデント対処時の考慮
- 蓄積されたインシデントの中でどれを優先的に解決するか
- インシデント対処のために、人、モノ、金を使うのか
- 対処するタイミングはいつにするのか
問題管理
- 発生したインシデントおよび運用状況の中から、根本原因を突き止める必要があると判断したものが問題
- ワークアラウンドは一時対応のこと
- ワークアラウンドで慢性的に対応していると時間が経過し誰も感知しなくなることがある。そのために恒久対策が必要
アクセス管理
- 誰がいつどこでネットワークを利用したかの証跡を把握すること
ネットワーク運用監視ツール
- 監視ツールには一般的に次のような機能があるので把握しておく
- 統合コンソール
- サービスを提供している各システムの稼働状況やアラートを集中して管理する機能
- 構成管理
- ネットワーク機器のハードウェア構成、ソフトウェアのバージョンといった構成情報を管理
- コンフィグレーションの自動収集の機能を有するツールもある
- ジョブ管理
- 業務を遂行するために必要なバッチ処理をスケジュールし、自動的に実行する
- リソースおよびパフォーマンス管理
- ネットワーク回線の使用率や、CPU・メモリの使用率など、パフォーマンスの監視、分析を行う
- ネットワーク管理
- ネットワーク機器の正常性監視や異常検知を行うための機器を提供する
- バックアップ管理 -ネットワーク監視装置本体のバックアップやリストアを行う機能を提供する
- 統合コンソール
参考書を読んだメモ : 1冊ですべてわかるネットワーク運用・保守の基本 1章
1冊ですべてわかるネットワーク運用・保守の基本
ネットワーク運用・保守の全体像
現場の運用・保守業務とは
- 運用業務はネットワークを正常稼働する状態を維持すること
- 保守業務はネットワーク障害に対する現状復旧が目的
運用保守の登場人物
- 運用保守は目に見えないものを売る仕事。つまりサービス業である
- 運用保守の登場人物
- お客様(サービス利用側
- 運用保守会社(サービス提供側
お客様
運用保守会社
- ネットワーク管理要員
- お客様のネットワークを24時間365日体制で安定稼働させるサービスを提供する
- 保守員(非常勤
- 実際の現場へ駆けつけて対応するエンジニア
- 障害対応だけでなく定期点検など
- 常駐保守員
- 運用保守会社から派遣されてお客様の現場に常駐し、ネットワークやシステム運用管理の代行業務を行う
一般的な障害対応の流れ
障害検知受付
- 障害が起きたことはどうやってわかるのか
- 運用保守会社が障害を検知する
- お客様(エンドユーザー)自身が障害に気づく
原因解析
- 情報収集
- ポイント
- 誰が使えないのか
- 全員？、個人だけ？
- 誰宛に使えないのか
- 特定の相手先？、全ての相手先？
- いつから
- 今日？、以前から？
- どの場所で
- 自分の場所？、他の場所？
- どのように
- 常にダメなのか？、たまになのか？
- 誰が使えないのか
- 今も影響が出ているのか？何かネットワーク環境で変化があったかを聞く
- 基本的には外的要因による障害が多い
- ポイント
原因を特定する
- 収集した情報をもとに絞り込む
復旧作業
- 一番厄介なのは自然に復旧していた時
- ログ情報や設定情報を収集して持ち帰る
- ネットワークが使えるようになることが最優先
構成管理
- 現状のネットワークがどのように管理されているのか、どのような資産を管理しているのか知る必要がある
- 管理対象はハードウェア、ソフトウェア、ドキュメントなど多岐にわたる
- 常に最新の情報を把握していなければならない
構成管理をする上で必要アイテム
- ハードウェア情報
- ネットワーク機器やサーバー、PCなどの製品名、製造番号、シリアル番号情報
- ソフトウェア情報
- ネットワーク機器やサーバー、PCなどのOS、アプリケーションのバージョンやライセンス情報
- ドキュメント管理情報
- 契約書関連、運用保守体制図、関係者連絡先一覧、社内組織図、機器構成、手順書、運用・保守対応フロー
- 影響範囲を把握しておくことが重要
IPアドレス管理表
- IPアドレスがどの部署で管理されていて現在の設定はどうなのかを可視化し、アドレスの割り当てを行ったり、アドレスの重複を回避したりするためのもの
- 主な項目
- 拠点
- どこで利用しているか
- セグメントアドレス
- アドレスの重複利用を避け運用するため
- 管理拠点
- どの部署で管理されているか
- 利用形態
- このアドレス帯が何に接続されるか
- 依頼元
- 依頼元を把握するため
- 登録日
- 利用開始日を把握する
- 廃止日
- 現在、未使用であることを把握する
- 拠点
機器管理表
- ネットワーク機器がいつからどこに設置されていて、現在の状態はどうなのか可視化
- 主な項目
- 資産番号
- 機種名
- 機能
- ホスト名
- 使用用途
- 製造番号
- 手配日
- 設置日
- 設置場所
- 管理有無
- 管理対象かどうか
- ソフトバージョン
- 保守ベンダー
- 保守契約形態
一般的な性能管理
参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 7章, 8章
達人に学ぶDB設計 徹底指南書
論理設計のバッドノウハウ
非スカラ値
- 不可分ではない値
- 第一正規形ではない形
ダブルミーニング
- テーブルの列は変数ではない。一度意味を決めたら変更不可
単一参照テーブル
- あらゆるタイプのマスタを一つのテーブルで表したもの
- テーブルにポリモルフィズムはいらない
テーブル分割
- 水平分割
- レコード単位でテーブルを分割する
- 年毎に分割など
- 垂直分割
- 列を軸に分割する
- 必要なカラムを集めたテーブルに分割する
- これらは拡張性に乏しいことで原則使うべきではない
シャーディングとカラムベース
- 新しいデータベースのアーキテクチャとして期待されている
- 発想は水平分割と垂直分割
- シャーディング
- 水平分割
- レコードを物理的に分離して格納することでI/O分散を図る手段
- 論理的にも物理的にも異なるテーブルとして扱われる
- カラムデータベース
- 対になるのがローデータベース
- 通常はローデータベースで行毎にブロックとして格納しているがカラムデータベースは列毎にブロック分けされている
- 利用する列が限られている場合、I/Oを削減できる
不適切なキー
- 可変長文字列
- キーは不変性を備えてなくてはならない
- 固定長文字列と混合する（空白などが不便
ダブルマスタ
- 同じような情報を持つマスタを二つ作ること
- システム統合などで起きるので気をつける必要がある
論理設計のグレーノウハウ
代理キー主キーが役に立たない時
- そもそも一意キーが存在しない
- 一意キーはあるが、サイクリックに使いまわされる
- 主キーの値が全て使われてしまった場合に既存の値が使われる場合に起こる
- 一意キーはあるが、途中で指す対象が変化する
- 代理キーはこれらの問題を解決するために用意された人工的なキー
- 自然キーで解決する場合はタイムスタンプ、インターバル（有効期間）という方法がある
列持ちテーブル
- 配列は作れないのでカラムを作る(ex. 子1, 子2, 子3,...カラム)
- 拡張性に乏しい
- 無用のNULL
- 行持ちテーブルを使うと良い（行でデータを持つ
アドホックな集計キー
- 場当たり的なキー
多段ビュー
- 複雑で管理が大変になる
データクレンジングの重要性
- データをデータベースに登録できる状態にすること
データクレンジングの内容
- 一意キーの特定
- 不適切なキーを防ぐ
- 似たような名前を集めて統合する
- ダブルマスタを防ぐ
参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 5章, 6章
達人に学ぶDB設計 徹底指南書
論理設計とパフォーマンス
正規化の功罪
- 整合性を保つことはできるが、検索が遅くなる
正規化とSQL
- 内部結合では相手側のテーブルに対応するレコードがない場合情報が漏れてしまうのでこの時外部結合を使う
- 非正規科ではれば結合を使わず検索できる
- 更新処理では正規化のほうが早い（非正規化であれば対応する全てのレコードを更新する必要があるため
- 非正規化はあくまで最後の手段である
- サマリデータを用いることで結合を回避する方法もある
データベースとパフォーマンス
インデックス
- B-Treeインデックスは平均点が高く扱いやすい
- B-Treeが効果を持たない検索条件は否定条件
- 以下の処理では暗黙にソートが行われる
- 集約関数
- COUNT, SUM, AVG, MAX, MIN
- ORDER BY 句
- 集合演算
- UNION, INTERSECT, EXCEPT
- OLAP関数
- RANK, ROW_NUMBERなど
- 集約関数
- インデックスは構築時にソートしているためインデックスをキーとして含んだ処理ではソートがスキップされる
インデックスの設計方針
- 大規模なテーブルに対して作成する
- データ量が少ない場合インデックスよりもフルスキャンの方が早い
- 差はごくわずかであるがそれならばわざわざ無駄なインデックスを作る必要はない
- 最近のハードウェアなら1万件以下の場合はほぼ効果ないと考えられる
- カーディナリティの高い列に作る
- 特定の列の値がどのくらいの種類の多さを持つか
- 月ならばカーディナリティは12など
- 複合列に対してインデックスを作成する場合、対象の複合列の組み合わせで考える
- 先頭に近いキーのカーディナリティが高いほど効果的
- カーディナリティが高くても特定の値にデータが集中しているような列には向いていない
- SQL文でWHERE句の選択条件、または結合条件に使用されている列に作成する
- IS NULL, 否定, ORはインデックスが利用されてない
- 主キーおよび一意制約の列には作成不要
- 更新性能が劣化するため無駄なインデックスは作らない方が良い
参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 3章
達人に学ぶDB設計 徹底指南書
論理設計と正規化
- RDBにおけるテーブルとは同じ種類のものの集合のこと
- キーとはある情報を引き出すための鍵。特に最も重要なのが主キー
- 正規化はデータの冗長性をなくしていく作業。目的は更新時のデータの不整合を防止する
- 正規化を進めていくほど検索性能が劣化する。通常は第三正規形までで十分
テーブルとは何か
- テーブルとは共通点を持ったレコードの集合
- テーブル名は英語なら複数形/複数名詞で書ける。そうでなければそのテーブルにはどこか間違いがある
テーブルの構成要素
- テーブルの行と列はレコードとカラムとも呼ぶ
- キーはあるレコードを特定するための列の組み合わせ
- 主キー
- プライマリキー
- 主キーはその値を指定すれば必ず1行のレコードを特定できるような列の組み合わせ
- 一意に識別するともいう
- テーブルには重複行は存在できない
- 複数列を組み合わせて作るキーを複合キーと呼ぶ
- 外部キー
- 2つのテーブル間の列同士で設定するキー
- 他のテーブルから参照しテーブルに存在しないデータの登録を防ぐ
- 参照整合性制約
- 外部キーは親子関係と同じ
- 外部キーが設定されている場合、データの削除は子から順に操作する
制約
- NOT NULL
- 空欄のデータは登録できない
- テーブル定義において列は可能なかぎりNOT NULL制約を付加する
- 一意制約
- ある列の組において一意性を求める。主キーと違い何個でも設定できる
- CHECK制約
- 値の範囲に制限を付ける
正規化とは何か？
- 正規形を作る方法
- 正規形とはデータベースで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式
第一正規形
- 1つのセルの中には1つの値しか含まない
- 一つのセルに一つだけの値が含まれている時の値をスカラ値と呼ぶ
- スカラ値だけなら主キーは各列を一意に決めることができる
- ある値が決まれば列が一つに決まる。これを関数従属性と呼ぶ
第二正規形
- 主キーの一部の列に対して従属する列がある関係を部分関数従属という
- 主キーを構成する全ての列に従属性がある場合を完全関数従属という
- 第二正規形は部分関数従属を解消することで得られる
- 部分関数従属を解消する手段はテーブルの分割
第三正規形
- テーブルないに存在する段階的な従属関係のことを推移的関数従属と呼ぶ
- これを解消することで実現する
ボイスーコッド正規形
- これ以降の正規形は一般的な業務では必要はない
- 3.5正規形とも呼ばれる
- 非キーからキーへの関数従属を解消する
第四正規形
- 関連するエンティティに含まれる関連は1つのテーブルに一つ
第五正規形
- 関連がある場合はそれに対応するテーブルを作る
参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 2章
達人に学ぶDB設計 徹底指南書
論理設計と物理設計
概念スキーマと論理設計
- 概念スキーマを定義する設計を論理設計
- システムの世界では「論理」とは物理層の制約にとらわれないという意味で使われる
- データベース設計は原則として論理設計が物理設計に先立つ
- 1.エンティティの抽出
- entity は日本語で実体
- 実体と言っても物理的実体を伴っているわけではない
- RDBではエンティティをテーブルという物理的単位で管理する
- どのようなエンティティが必要かというのはどのようなデータを扱いたいかということ
- 要件定義
- 2.エンティティの定義
- エンティティを抽出した後は各エンティティがどのようなデータを保持するかを決める必要がある
- エンティティはデータを属性という形で保持する
- これは二次元表における列と同義
- 3.正規化
- 正規化はエンティティについてシステムでの利用がスムーズに行えるように整理する作業
- 4.ER図の作成
- 正規化はエンティティを細かく分割していく作業なのでエンティティの数が増えている
- このままではエンティティ同士の関係が把握しにくくなるため図を作成する
内部スキーマと物理設計
- 1.テーブル設計
- 2.インデックス定義
- インデックス（索引）
- インデックスが重要な役割を果たすのはパフォーマンス
- 3.ハードウェアのサイジング
- システムで利用するデータサイズを見積もりそれに十分な容量の記憶装置を選定する
- システムが十分な性能を発揮できるだけのスペックのCPUやメモリを持ったサーバーを選定する
- データベースの性能問題の8割はディスクI/Oによって起きる
- データ整合性とパフォーマンスはトレードオフな関係
- キャパシティのサイジング
- データベース内に格納するデータ量は物理的なテーブル定義およびインデックス定義が終わらなければ算出できない
- データ量にはデータベース内に格納するテーブル以外にもテキストや画像、HTMLといった様々な形式のファイル分も加算する必要がある
- データ量はシステムの運用開始から増えていくため余裕を持たせたサイジングを行うか、あとで簡単に追加できるような構成にしておく必要がある
- 拡張が簡単な構成をスケーラビリティが高いと表現する
- パフォーマンスのサイジング
- 2つのサイジングを要件定義の段階で決めておく必要がある
- 4.ストレージの冗長構成
- 耐障害性を持つようにシステムを構築する技術がRAID
- 複数のディスクを束ねて仮想的に一つのストレージとする技術
- RAIDは本来システムの信頼性を高める技術だが、性能向上の利点もある
- データを複数のディスクに分散して保持するため、ボトルネックであるディスクI/Oを分散することでパフォーマンス向上を図ることができる
- RAID0
- ストライピング
- データを異なるディスクに分散してもつ
- I/O性能はディスクが増えるほど向上するが1本でも故障したらデータが失われるため、冗長性は全くない
- RAID1
- RAID5
- RAID10
- RAID1 + 0 とも呼ぶ
- RAID1のグループを2つ作りそのグループを作ってRAID0を作る
- 欠点はコストが高い
- RAID01というのもあるが信頼性はRAID10より若干劣る
- RAID6
- RAID5 の上位版
- 二種類のパリティを持つことで2本故障した場合もデータを保持できる
- RAID5よりコストが高い
- 5.ファイルの物理配置
- データベースに格納されるファイル
- データファイル
- インデックスファイル
- システムファイル
- 一時ファイル
- ログファイル
- 開発者が存在を意識するのはデータファイルとインデックスファイルだけ
- 残りのファイルはDB管理者以外は意識しない
- I/O量が多いのはデータファイル次にインデックスファイルと一時ファイル
- 一番良いのはそれぞれ独立したディスクにおくことだが、コストが高い
- I/Oコストの低いファイルは同グループにまとめると良い
- 最近ではバイナリファイルをDBに格納することもある（サイズが大きくI/Oコストも高い
- データベースに格納されるファイル
バックアップ設計
- フルバックアップ
- ある時点での全てのデータをバックアップにとる
- 全てのデータをバックアップに取るためバックアップの時間が長い
- ハードウェアリソースへの負荷が高い
- サービスの停止が必要
- 差分バックアップ
- 増分バックアップ
リカバリ設計
参考書を読んだメモ : 達人に学ぶDB設計 徹底指南書 1章
達人に学ぶDB設計 徹底指南書
- 翔泳社のセールで買った本のメモ
データベースを制するものはシステムを制す
システムとデータベース
データ処理としてのシステム
- データを整合的に保持して、いつでも簡単に利用可能な状態にしておくためのシステムをデータベースと呼ぶ
- データベースを管理するためのシステムをDBMS(データベースマネジメントシステム)と呼ぶ
- データベースを使わないシステムはこの世に存在しない
データと情報
- データとは、ある形式（フォーマット）に備えられた事実のこと
- 情報とは、データから、ある文脈なり観点なりにしたがって集約したり加工したりしたもの
- 情報はデータと文脈を合成して生まれる
設計工程とデータベース
- 最初にデータがある。プログラムはその次にできる
- データベースを制するものがシステムを制す。データベースはシステムの中心であると同時に、システム開発の中心でもある
3層スキーマ
外部スキーマ
- システムの利用者であるユーザから見て、データベースがどのような機能とインターフェースを持っているか定義するスキーマ
- ユーザーから見たデータベース
