ロードバランサ

複数サーバによる信頼性の向上

稼働率の低い複数のサーバを組み合わせる。

負荷分散(DNSラウンドロビン)

nslookup
DNSサーバに問い合わせて、同じサービスを提供する複数のサーバを用意しておき、アクセスを振り分けて分散させる。

nslookup www.google.co.jp
サーバー: UnKnown
Address: 192.168.0.1権限のない回答:
名前: www.google.co.jp
Addresses: 2404:6800:4004:804::101f
74.125.235.151
74.125.235.152
74.125.235.159

1.IPアドレス問い合わせr
2.IPアドレス返す
3.リクエストの分散

アドレス変換(NAT) 型負荷分散

※NATとはプライベートアドレスをグローバルアドレスに変換してインターネットにつなげる技術

1.リクエスト
2.IPアドレスを変換して振り分け
3.ロードバランサへレスポンス
4.クライアントへレスポンス

ダイレクトルーティング型負荷分散

※ひとつのネットワークにLBもサーバもいる状態
※レスポンスはLBを通らないのでボトルネックになりにくい

1.リクエスト
2.振り分け
3.振り分け先サーバAからクライアントへレスポンス

分散アルゴリズム

1.ラウンドロビン
順番アクセス
2.ランダム型
完全ランダム
3.送信もとIPアドレス
同じクライアントが同じサーバを利用する
4.サーバ負荷連動型
処理能力に余裕のあるサーバに振る
5.重み付け

Pound

※L7ロードバランサとして利用できる

#yum install Pound.x86_64
#/etc/init.d/pound start

/etc
[root@mizunuma etc]# vim ./pound.cfg

Service
URL ".(htm|html)$"
BackEnd
Address 192.168.2.181
Port 8080
Priority 1
End
End

BackEnd
Address 192.168.2.130
Port 80
Priority 1
End

バックエンドを書き足すことで、分散可能。

LVS

L4ロードバランサとして使われる
net.ipv4.ip_forward = 1
ipvsadm -A -t 172.16.0.252:80 -s rr
ipvsadm -a -t 172.16.0.252:80 -r 10.1.0.100 -m

通信の冗長化

通信経路の信頼性向上

あぷせとねでぶ

OSI参照モデル
7.アプリケーション層
6.プレゼンテーション層
5.セッション層
4.トランスポート層
3.ネットワーク層
2.データリンク層
1.物理層

TCP/IPモデル
アプリケーション層
トランスポート層
インターネット層
ネットワークインターフェース層

プロトコル

7層.アプリケーション層 HTTPなど
4層.トランスポート層 TCP/UDP
5層.ネットワーク層 IP
6層. データリンク層 Ethernet

ポート番号

20,21 FTP
22 SSH
23 Telnet
25 SMTP
53 DNS
80 HTTP
110 POP3
143 imap
443 HTTPS

0-1023までをウィルノウンポート

パケットの呼称

4層 トランスポート層 セグメント ※UDPデータグラム
3層 ネットワーク層 パケット
2層 データリンク層 フレーム

IPアドレス

32bit
オクテッド 8

MACアドレス

12桁

MACアドレスとIPアドレス

MACアドレスはL2 データリンク層のプロトコル 外に出られない
IPアドレスはL3 ネットワーク層のプロトコル

全二重、半二重

片方しかデータが送れないデータを半二重通信、
受信と送信を同時に遅れるものを全二重通信という
CSMA/CD方式

機器

リピーターハブ
ハブはL1の機器、スイッチングハブはL2の機器
ハブは通信を受け取ると、受信したポート以外のポートにフラッディングという通信を行う。
ブリッジ L2機器
スイッチ L2機器
ルータ L3の機器

コリジョンドメイン

通信の衝突が起きてしまう範囲
L1のハブでネットワークを連結していくとコリジョンドメインが増えていくことになる。

ブロードキャストドメイン

1対1通信をユニキャスト通信、1対n通信をブロードキャスト通信という。

ネットワークトポロジー

機器の配置などの形をトポロジーという。
論理的なネットワークの動きを論理トポロジーという

物理トポロジーはスター型、論理トポロジーがバス型というものがおおい。
1.スター型
2.バス型
3.リング型

サブネットマスク

ホスト部のbit数だけアドレスが作れる

ネットワークアドレス

ネットワーク部　andで計算する
ホスト文 全部0

ブロードキャストアドレスの計算

ネットワーク部　andで計算する
ホスト文 全部1

データのループ

冗長構成をとりつつうっかりループする構成を作ってしまうことがある。

スパニングツリープロトコル

データがループした場合に働く。
あるLANにおいてループ構成を回避するための通信プロトコル。
※ラピッドスパニングツリープロトコル

ciscoルーター、スイッチのコマンド

>enable 特権モード
#congifure terminal 設定に入る
Switch(config)#spanning-tree mode rabit-pvst ラピットスパニングツリープロトコルの設定

冗長化

サーバの稼働率をあげる

CPUやメモリといったコンポーネントを冗長化させる
1.CPU
2.メモリ
3.LANセグメント
4.ディスクアダプタ
5.ディスクコントローラ
6.ディスクボリューム
7.ファン
8.電源

FTサーバ

フォールトトレラントサーバ

ディスクの構造

※ディスクは故障率が高い

RAID

Redundant Array of Inexpensive DIsks レイド
複数代の安価なハードディスクを組み合わせて、冗長かさせた1台のハードディスクとして管理する技術

RAID0 RAID1 RAID5
ソフトウェアRAIDとハードウェアを使用するハードウェアRAIDの2種類ある。

RAID0

ストライピングする
速さ 速い
信頼性 ない
容量 n

RAID1

ミラーリングで書き込みを行う
速さ 遅い
信頼性 ある
容量 1

RAID5

ストライピング
パリティ

速さ 速い
信頼性 復旧可能
容量 n-1

RAID6

パリティ 2

速さ 速い
信頼性 復旧可能
容量 n-2

RAID10(1+0)

速さ 速い
信頼性 高い
容量 n/2

ソフトウェアRAIDとハードウェアRAID

ハードウェアRAIDではRAIDコントローラーカードを使う

ネットワークインタフェースの冗長化

ネットワークインタフェースが故障してしまえば無意味

NICチーミング

一台のマシンに複数のネットワークインタフェースをカードを搭載しそれらのNICを一つの仮想的なNICとして扱うための技術

bonding

Linuxでは複数のインタフェースを束ねた仮想的なインタフェースを作ることが出来る。
ボンディングインタフェースと呼ばれ、bond0、bond1のように名称が付いている。

高信頼性システム

ミッションクリティカルシステム

24時間、365日止まらないことを要求される基幹業務

RASIS

信頼性評価の指標
R Reliability 信頼性 故障が少ない 平均故障時間
A Avaiability 可用性 稼働率が高い 稼働率
S Serviceability 保守性 障害修復時間が少ない 平均修理時間
I Integlity 保全性 データの矛盾が発生しない
S Security 機密性 不正アクセスが起きない

RASは数値化される

Reliability
Availability
Serviceability

MTBF

Mead TIme Between Failures
MTBF = 稼働時間の合計/稼働回数
故障が起こってから、次に故障が起こるまでの時間

MTTR

Mean TIme To Repair
平均修理時間 = 修理時間の合計/稼働回数
MTTR = 故障が起きてから再び利用出来るまでの時間

稼働率

MTBF / MTBF + MTTR

高信頼性システム

高信頼性システムに求められるのは
1.平均故障間隔を長くする
2.平均修理時間を短くする

直列システム

シンプレックスシステム
稼働率A * 稼働率B
※全体の稼働率は下がった

並列システム

デュアルシステム
1- (1-稼働率A) * (1-稼働率B)
※全体の稼働率は上がった

単独障害点

単一障害点
SPOF

冗長化

二重化
複数コンピュータを使用してシステムの信頼性を高めること

フォールトトレラントシステム

耐故障性を備える
システムの一部が故障しても、全体としては必要な機能を維持する

クラスタリング

同じコンピュータを集めること
クラスタリングによって作られたしシステムをクラスタという

システム監視

監視 -> 検知 -> 通知

ITIL

1.サービスサポート
2.サービスデリバリ

サービスサポート

運用手法
1.インシデント管理 応急処置
2.問題管理 原因究明
3.変更管理 IT環境の変更
4.リリース管理 新バージョンのソフトウェア導入など
5.構成管理 ハードウェアやソフトウェアの構成を管理する

サービスデリバリ

中長期的なサービス管理手法
1.サービスレベル管理 サービスレベルの維持、記録
2.可用性管理 稼働率をあげる
3.キャパシティ管理 負荷を把握
4.ITサービス財務管理 費用の管理
5.ITサービス継続性管理 災害、テロ時の対応

SLA

Service Level Agreement
1.項目数をむやみに増やさない
2.測定可能な項目を設定しない
3.あいまいな項目は設定しない

TILメリット

1.満足度
2.収益の増加
3.損失時間
4.市場投入までの時間短縮
5.意思決定の改善とリスクの最適化

NoSQL

NoSQLの誕生

大量データを扱う
RDMBS->SoSQL

1.スループット
2.信頼性
3.スケーラビリティ

NoSQL種類

1.キーバリューストア
2.列指向
3.ドキュメント指向

キーバリューストア

・シンプル！キーと値
・キャッシュDB
・アクセスログ一時保存

memcached
Bekeley DB
Tokyo tyrant

列指向

※MapReduce 大規模データ用のクラスタ用フレームワーク

列単位でのデータ管理
keyとバリューのデータが列ごとに作成される
1.key Value , key Value….

HBase
BigTable
Cassandra

1.RDBでは扱いきれない大規模なデータのスケーラブルな処理のため
2.MapReduceのためのデータストレージ

ドキュメント指向

自由なドキュメント指向のデータ構造。

key	name0 => vakue

name1 => value,value

スキーマを事前に登録しない

MongoDB
CouchDB
SImpleDB

1.大規模データの更新参照
2.JSON形式でのデータ取得、　jsとの親和性が高いのでフロントの開発工数を減らせる

NoSQLまとめ

NoSQLをいれることはそれ自体がスループットをあげる
単純なしくみなので、むしろアプリケーションの設計をNoSQLにあわせる形になる

NoSQLとCAP定理

分散コンピュータ間の情報複製についての定理
1.Consistency
2.Availability
3.Partition-tolerance

consistency 一貫性

どのノードでも一貫性があることを示す
レプリ遅延時はconsistencyがないと言える

Availability 可用性

内部で問題が起きても、外部からみて問題ないこと

Partition-trelance 分割耐性

データノードが分割された場合でも、継続して正常な動作が行えるか

ジレンマ

※CAP定理のうち、2つは満たせるが3つを満たすことは出来ない

1.CA (RDBMS)
一貫性と可用性を持つ。
分割耐性がない。

2.AP Cassandra,CouchDB
分割グループでサービス継続可
一貫性は保たれない

3.PC MongoDB,HBase
分割しても 一貫性を保つ。
※分割グループを切りはなす

一般的にPは前提であるので、CかAか
Cを保たなければいけない場合はあまりないので、CPが基本。

BASE

ビッグデータを扱うのに、トランザクションのようなACIDの考え方は邪魔

BA Basically Avaiable まず可用性
S Soft-State 状態繊維
E Eventual Consistency 結果的な整合性

Consistent Hashing

ハッシュが一番一様に分散してくれる
インパクトを限定的にしてくれる

Hadoop

大量データを処理する
1.HDFS ファイルシステム (Hadoop Distributed FIle System)
2.MapReduce 分散基盤

HDFSではひとつのファイルを複数のノードに分散配備する

RDBMSとHadoop+HBaseの比較

1.データー...データサイズ ペタバイト単位
2.アクセス...バッチ処理が基本、インタラクティブ (リアルタイム)
3.更新…何度も書き込める
4.構造...動的スキーマ
5.整合性…高い
6…スケーラビリティ…直線的

MapReduceの設計が難しい

SQLに対して、解析が難しい
そこで、MapReduceの設計を簡単にするために中間言語が生まれた。

1.Pig
2.Hive

=> Hadoop + HBase + (PigLatin,Hive)によって弱点なし

注意点

JBOD
※普通のストレージ装置を使う

クライアントチューニング

読み込みが遅い95%はフロント処理のせい

1.リクエストを減らす
ヘッダ情報にキャッシュの記述を行う
If-Modified-SInce いちおう通信する
Expires 通信しない
Js,cssをひとまとめに
できるだけリダイレクトさせないようにする
CSS Sprite

2.ファイルサイズを小さく
画像ファイルを選ぶ
写真やグラデーション -> jpg
アニメーション -> gif
他 -> png
HTTP圧縮 mod_deflate
ファイルサイズを小さく
コメントを消す
インデントを消す
3.その他
cssは冒頭に配意
jsはソースの最後に才知
手前
コンポーネントを別のホストに
HTTPでは同時並行接続数が2本なので

JavaScript

変更しない場合は外部ファイルに
ライブラリーは多様しない
Ajaxリクエストは減らす
DOMへの参照を効率的に
DOMアクセスを減らす
非効率的なループの修正
関数のインライン処理
もじれつ結合に注意

キャッシュ機構

キャッシュ

ネットワーク上の負荷分散を目的としてたサーバやキャッシュ機構について。
1つのページに対して静的ファイルがかなり多い。静的ファイルはどこからDLされようが同じなので、キャッシュする機構が使われることが多い。

①Webブラウザのキャッシュ
Webブラウザはキャッシュされたファイルへのアクセスがあると、いったんWebサーバにリクエストを投げる。
この付帯情報から更新の有無を判断して返却するレスポンスを変えます。

If-Modified-Since ファイルが更新されてなければキャッシュをそのまま使う
If-None-Match 指定したエンティティタグに一致しない場合のみコンテンツを返却する

②Proxyサーバによるキャッシュ
LANの中での話。
大企業ではリクエストが重複することが起き得るので、Proxyサーバをたてて静的ファイルをキャッシュさせ、Proxyサーバからレスポンスを返す。
※セキュリティ向上や監査(2ちゃん閲覧禁止)などの目的で使われることも多い

③リバースプロキシ
Webサービスを提供する側。
静的コンテンツをキャッシュさせることで、WebAPサーバのI/O軽減にもなる。

※インターネットからみてクライアントよりなものがProxy、サービスに近いものがリバースプロキシである。
※Proxyがインターネットへの通信を減らすのが目的、リバプロは自社コンテンツのWebサーバの負荷を下げるのが目的である。

④CDN
AkamaiなどのCDNはリバースプロキシのアウトソージング化。

⑤ロードバランシング

ブラウザキャッシュ

メリット
1.自分のHDDを利用するので通信速度が速くなる
2.Webサービスの負荷軽減にもなる

デメリット
ブラウザ側の実装により思ったようにキャッシュされないこともある

キャッシュが行われる条件

1.ブラウザのキャッシュ機構が有効である
2.GETリクエストであること 【重要】
3.リクエストパラメーターまで同じであること
4.レスポンスヘッダに Last-Modifiedが含まれる ※レスポンス側で必要
5.サーバ側でキャッシュを無効にしていないこと

キャッシュされたときのレスポンス

1.キャッシュされたとき 304 Not Modified
2回めのアクセス以降で、304 Not Modifiedがかえってくればファイルに変更なしということ。
2.キャッシュされていないとき 200 OK

※Ctrl + F5 でキャッシュを使わない更新。開発では重要。

Proxyサーバの機能

1.コンテンツキャッシュ
2.フィルタ機能
3.経由変更
4.匿名性確保

プロキシサーバ

1.Squid もっとも多く使われている
2.Apache mod_proxyモジュール
3.Delegete

リバースプロキシ

サービス提供側のネットワークにおくプロキシサーバ。
1.コンテンツキャッシュ機能
2.ロードバランサ機能 ※負荷分散も行う
3.アクセス代行
4.SSLアクセラレータ ※SSL通信時の複合化をWepAPで行うのではなくリバプロで行うと全台で行う必要がなく便利。

リバースプロキシサーバ

1.nginx リバースプロキシやロードバランサとして利用可能
2.Apache
3.Squid
4.Varnish Cache

使いどころ

1.静的コンテンツの通信料が多い
2.処理ごとに別のサーバンリクエストしたい スペックや処理の違いによって振り分け先を変える

まとめ

ApacheやBIG-IPで鉄板だとされてきた部分のリプレースに使えるかも

ロードバランサ

複数の同じような処理を行うサーバに使える。

1.ロードバランサ機能
2.Cookie
3.冗長構成
4.SSLアクセラレータ
5.アクセス代行

いろいろなロードバランサ

1.F5 BIG-IP
2.他社製のアプライアンス
3.LVS
4.Pound
5.nginx
6.Apache

ロードバランサ使いどころ

1.分散処理を行いたい
2.冗長性を確保したい
スケールアップではなくスケールアウト。

バランスアルゴリズム

1.L4負荷分散 (トランスポート層)
2.L7の負荷分散 (アプリケーション層) HTTPのみ。
1.URLによるふりわけ
2.User-Agentによるふりわけ
3.Cookieによるセッション維持
4.HTTPヘッダによる振り分け

パフォーマンス障害

1.振り分けは出来ているか
2.コネクションテーブルの残留 きり戻しても、サーバにアクセスがこない場合がある

CDN

Contents Delivery Network
世界的なネットワークが必要。再大手がakamai

世界的な企業が利用した場合サーバのリソースを節約出来る。

Akamai

CDNといえばAkamai

HDDの負荷分散

RAID
RAIDはいろいろなレベルがありますが、商用ではRAID0+1を使う。
HDDどうしはSAN(StrageAreaNEtwork)を構築し、SCASIコマンドがやりとりされる。
SANは高い。

IP-SAN(iSCASI)

iSCASIというプロトコルを使ってSANを構築できる。
しかし実用的でなく、せいぜい1GbEレベル。
10GbE(ギガビットイーサ)の機器は出回ってない。

ストレージ装置の問題への対応

アプリケーション側のアプローチ
1.分散処理系HadoopなどのHDFSを使う
2.シーケンシャルリード、シーケンシャルライトになるように設計する
3.データ量を整理する

インフラ
SSDを使う

PCIe経由のSSD

SSDは高速

Solrと全文検索

RDBは検索に向かない

前方一致でしかインデックスが使用できない
DBMSはフルテキストインデックスを作成できるプラグインを追加
Oracle Text
SQL Server フルテキストインデックス
MySQL フルテキストインデックス
DBメーカー意外の全文検索エンジン
eAccela Bizesearchなども出てきたが商用で、ライセンスが高かった

Lucene

Lucene -> jarでの配布だけだった
Solrの登場 -> HTTPのインターフェースを提供

Solr

1.比較的低いハードルでも動作する
2.HTTPでの要求と応募
3.レプリケーション機能
4.分散検索機能
5.DIHでRDBからデータインポート
6.ファセット検索 ※動的なタグ付け
7.トークン方式の選択 (n-gram,形態素解析)
8.フィルタ機能(シノニム)

Solrの構成

1.Solrに対してHTTPリクエストで検索、HTTPレスポンスで結果を出力
2.インデックス登録 post,jarでHTTPリクエストから定期的に登録
3.DIHを使いDBから定期的に登録

データの登録

java -jar post.jar data.xml

設定ファイルの編集

重要なのは3つ

1.$SOLRHOME/solr.xml
マルチコア設定を行う
2.$SOLRHOME//conf/solrconfig.xml
各種リクエストハンドラの設定
3.$SOLRHOME//conf/schema.xml
このCoreのスキーマ設定(テーブル定義のようなもの)を定義するファイル

スキーマの設定

スキーマはコア1つに対して1つだけ決定出来る
1.データ型の定義

2.データの定義

トークナイザー

文章をどのように切り分けてインデックス/検索するかを決定するもの
1.N-gram
1.固有名詞に強い
2.辞書のメンテナンス不要
3.ノイズが入りやすい
N=1 は uni-gram N=2 bi-gram N=3 tri-gram
2.形態素解析
1.自然言語に強い
2.固有名詞に弱い

※トークナイザー
WhitepsaceTokenizerFactory

トークンフィルタ

トークナイザーで抽出されたトークンにフィルタをけkてインッデックス/検索をする
1.N-gramフィルタ
2.シノニムフィルタ

Charフィルタ

トークン化前にかけられるフィルタ
HTMLなどを取り除く

N-gramフィルタ

NgramTokenizerのバグに有効

Synonymフィルタ

トークン化されたものを指定したものに変換してしまうフィルタ

Solrの動作確認

cd \solr\example
java -jar ./start.jar

DIH

DataImportHandler
JDBC経由でインデックスを登録する
①テーブル作成
②DIH用のコンフィグを作成 data-config.xml
/var/lib/tomcat6/solr/conf
vim data-config.xml
③DIH実行
※フルインポート
http://ip:8080/solr/dataimport?command=full-import

インデックス作成時の負荷軽減

インデックス作成をMasterに行わせて
参照はSlaveにまかせる
solrはレプリケーション機能を持っている

分散検索

shards=localhost:8983/solr,localhost;7574/solr
(,で区切るだけ)