Please enable JavaScript.

Coggle requires JavaScript to display documents.

Web開発者のための大規模サービス技術入門 (大規模データ処理入門メモリとディスク，Webアプリケーションと負荷 (大規模データ処理の難所…

- - - - 物理的な処理に伴うミリ秒単位の時間
        
        ヘッドの移動時間
        
        ディスクの回転時間
        　- 同じようなデータを固めて配置し，まとめて4KB くらい読ませることで必要なディスク回転数を最小化するOSレベルの工夫わ行われているがそれでも
      - CPUとつなぐバスの違いによる転送速度差( 1/100 )
        
        メモリに対してディスクは 1/100 の速度のバスしか無い
        
        転送するデータ量が多くなるとここもボトルネックになる
        
        SSD は物理的な探索時間は高速化されるが，バス速度がボトルネックになる
  - - - いかにしてメモリで済ませるか
      - データ量の増加に強いアルゴリズム
      - データ圧縮・情報検索技術
    - - OSのキャッシュ層
      - 分散を考慮したRDBMSの運用
      - アルゴリズムとデータ楮
  - - - ボトルネック見極め作業
        
        ロードアベレージを見る
        
        CPU, I/O のいずれかがボトルネックか探る
        
        ロードアベレージを見る
        
        システム全体の負荷状況を示す指標
        ※ これだけでは原因がどこかは特定できない
        
        ロードアベレージが低いのにスループットが上がらない場合
        
        ソフトウェアの設定や不具合，ネットワーク，リモートホスト側に原因が無いか探る
        
        top, uptime などのコマンドで，ロードアベレージを見る
        
        ロードアベレージが高かった場合，CPU , I/O いずれがボトルネックかを探る
        sar, vmstat で時間経過と共に CPU使用率や i/O 待ち率の推移を確認する
        
        CPU負荷が高い場合
        
        考えうる状況 2通り
        
        ディスクやメモリ容量など，その他の部分がボトルネックになっていない理想的な状況
        
        プログラムが暴走してCPUに必要以上の負荷がかかっている
        
        絞り込み手順
        
        ユーザプログラム or システムプログラムが原因なのか top, sar で確認する
        
        また，ps でプロセスの状態，CPU使用時間を見ることで原因となっているプロセスを特定する
        
        プロセス特定から更に詳細を詰める場合には， strace でトレース，oprofile でプロファイリングするなどしてボトルネック箇所を絞り込んでいく
        
        の場合かつ，システムのスループットに問題があれば
        
        サーバの増設
        
        プログラムのロジック，アルゴリズムの改善で対応
        
        の場合
        
        不具合を取り除き，プログラムが暴走しないように対処
        
        I/O 負荷が高い場合
        
        考えうる状況２通り
        
        プログラムからの入出力が多くて負荷が高い
        
        スワップが発生してディスクアクセスが発生している
        
        絞り込み手順
        
        sar や vmstat によりスワップの発生状況を確認して問題を切り分け
        
        2 の場合
        
        特定のプロセスが極端にメモリを消費していないかを ps で確認する
        
        プログラムの不具合でメモリを使いすぎている場合はプログラムを確認する
        
        搭載メモリが不足している場合は，メモリ増設 or 分散を検討する
        
        1.の場合
        
        スワップが発生していない & ディスク入力が頻繁に発生ー＞キャッシュに必要なメモリが不足している場合がある
        
        メモリ増設でキャッシュ領域を拡大することを検討
        
        メモリ増設で対応仕切れない場合は，データの分散・キャッシュサーバの導入・プログラムの改善によるI/O頻度軽減を検討
    - - CPU負荷
        　- APサーバはDBから取得したデータを加工してクライアントに渡す処理を行う
        　- 大規模な I/O は基本無く，CPUバウンドなサーバ
        
        I／O負荷
        　- DBサーバはデータをディスクから検索するのが主な仕事
        　- 大規模になるほど，CPU計算時間よりも I/O 時間の影響が大きくなる I/O バウンドなサーバ
      - マルチタスクOSとロードアベレージ（負荷）
        
        多数のタスクをCPU／ディスクなどの有限なハードウェアで共有しつつ，非常に短い時間間隔で複数のタスクを切り替えながら処理を進める
        
        実行タスクが増えてくると何らかのタスクを実行している間，他のタスクは「処理実行待ち」になる
        
        ロードアベレージ
        load average: 0.7, 0.66, 0.59
        
        単位時間あたりに待たされたタスクの数, この値が高いほどタスクの待ちが発生している < - > 負荷が高い
        
        左から順に 1分・5分・15分
        
        ハードウェアは一定の周期でCPUに割り込み信号を送る（タイマ割込）
        
        割込ごとに時間に関連する処理を行う（CPUは時間を進めたり，実行中のプロセスがCPUをどれだけ使ったかの計算，ロードアベレージの計算等）
        
        ロードアベレージの計算
        
        カーネルはタイマ割込があった時に，実行可能状態のタスクと I/O 待ちのタスクの数を数える
        
        CPU の実行権限が与えられるのを待ってるプロセス
        
        ディスクI/Oが完了するのを待っているプロセス
        
        その数を単位時間で割ったものがロードアベレージ
        
        ロードアベレージは２種類の待ちタスクの数をあわせて表すだけの数字なので，これだけではCPU・I/O どちらの負荷が高いのかは分からない
    - - CPU バウンドなシステム
        
        %user の部分の値が高い
        
        I/O バウンドなシステム
        
        %iowait の部分の値が高い
- - - - スケールアウト戦略によるスケーラビリティの確保が必要
        
        ハードウェアの性能とその価格は比例しないので，安価なものを複数用意し．処理を分散，並列化したほうが低コストでハイパフォーマンスを実現できる（スケールアウト）
        
        負荷を分散させるロードバランサ導入
        
        DBデータの同期戦略を考える
        
        ネットワーク通信のレイテンシを考える
        
        Ethernet経由の通信は少データでも ms 単位, CPUの処理時間はμ，ns単位なのでオーバーヘッドが生じる
      - サービス停止の影響が大きいので冗長性の確保が必須
        
        スケールアウトを行うと，サーバの台数が増える分，故障の発生率も上がる
      - スケールアウトに伴う運用負荷の増加に効率的に対応する必要がある
        
        100台以上のサーバを効率的に監視するツールが必須
      - 開発プロセスの標準化・ファシリテート・チームマネジメントが必要
        
        複数の技術者で役割分担をする場合のコミュニケーションコストを最小限にする必要がある
      - メモリ上で処理し切れない大規模データへの対応
        
        データ処理では複数の層を経由
        ディスクー＞メモリ(キャッシュメモリ)ー＞CPU
        
        ハードディスクからのデータお読み取りは，メモリからの読み取りに比較すると 10^6 ~ 10^9 倍遅い
        
        基本は一度読み出したデータをキャッシュに載せて対応
        
        扱うデータ量が多くなると，キャッシュミス（欲しいデータがキャッシュに乗っていない）が多発し，低速なディスクへの I/O が多く発生する
        
        I/O待ちに入ったプログラムは，他のリソースが空いていても読み取り完了するまで次の処理を行えない
  - - - データ規模が層化することによる I/O 負荷の上昇は急に現れる
        
        キャッシュミスが発生し出すと急に問題が顕在化する
      - 最初から大規模になることを見越して構築するのはコストが掛かるのでバランスを取ることが重要