負荷分散関連のまとめ

[pei0804]

インフラ用語

スケーラビリティ(拡張性)

能力が不足することが判ったときに、必要に応じてシステムを拡張できるかどうか。 主にスケールアウトを前提とした設計が望まれる。理由としてはスケールアップはハードウェアの入れ替えなのが伴うため、場合によっては停止する必要があったりするため。

アベイラビリティ(可用性)

アベイラビリティは、システムの止まりにくさを表します。
故障せず保守も必要ない機器でシステムを構成すれば、もちろんアベイラビリティは高くなりますが、実際には故障も保守も避けることはできません。 そのため、アベイラビリティの高いシステムには次のような機能が要求されます。

負荷分散装置は、接続しているサーバの運用状況を定期的に診断し、故障しているサーバを負荷分散の対象から自動的に除外します。 これにより、利用者からのリクエストは、正常なサーバで処理されます。
除外が自動化されていると、停止している間に保守ができるため、停止せずにサービスを提供し続けることが可能になる。つまり、可用性が高くなる。
↑ロードバランサの機能

ロードバランサ

サーバーとは別に負荷分散装置を使う理由

• サーバの機種やオペレーションシステム、アプリケーションの種類に依存しない
• 従来のサーバを変更することなく、負荷分散装置の導入が可能

主な機能

• リクエストの分散機能
• セッション維持機能 (一意性保証機能)
• 故障監視機能
• 連続サービス機能

ロードバランサ - ロードバランシングの種類

負荷分散方式の選定

• 分散するサービスの特性を検証し、負荷均一の効果が高い方式を選択する。
• 効果が同じ場合は、サービスの特性に合致した方式(設計の容易性)を選択する。

データベース周りの負荷分散

RDBMSはデータの整合性は保証されているが、ボトルネックとなりがちなので、最近ではNoSQLとの組み合わせが流行っている。 NoSQLはRDBMSに取って代わるものなのか？ (1/3) - ＠IT
IoTに適したNoSQL・分散Key-Valueストア

NoSQLの登場の理由

スケールアウトとスケールアップのどちらが良いか？ これは、「どんな場合でもこちらの方が良い」と決められる問題ではありません。用途、目的を考えて使い分けるものです。近年まで、データベースといえばRDBMSが前提に考えられてきたことから、処理性能向上の選択肢は「スケールアップ」一本に限られていました。しかし、NoSQLデータベースの登場によって「スケールアウト」への道が開かれたのです。

NoSQL

特徴

• メモリにデータを持つため、高速である。
• キーと値を組み合わせるシンプルな構造
• RDBMSよりもスケールアウト(サーバを増加させることで性能をアップ)させやすい
• スキーマレスなので、カラムを自由に定義することができる
• トランザクションやテーブル間のジョインのような仕組みがないものが多い
• 参照や追加処理が大半のシステムに適している。

弱み

• 更新や削除処理が多い仕組みには向かない
• 複数サーバにデータが分散している場合は、サーバ間の整合性が保証されないケースが多い
• 集計やソートに向かない
• ACIDトランザクションがない。

参考画像

RDBMS

特徴

• トランザクションによってデータの一貫性を保証
• 正規化(キーに基づいて複数テーブルを連鎖させることでデータ管理) => 更新コストの削減
• SQLを使うことができ、複雑な条件での検索や集計を行う事ができる
• 運用実績が豊富で、ノウハウが蓄積されている

分散して保存した場合

RDBMSのパフォーマンスチューニングでは「低速なディスクストレージへのアクセスを可能な限り減らし、できるだけメモリにキャッシュしたデータを返す」のが定石です。しかし、分散環境ではディスクストレージよりもさらに速度が遅く、安定しない、ネットワーク経由のデータアクセスを余儀なくされてしまいます。

弱み

• データの読み込み部分に関してはレプリケーションによってスケールさせることができる。 一方で、書き込み部分においてデータの一貫性を保証するためには、競合時の制御や振り分け処理などの対応が必要となり、導入の難易度が高い。
• カラムの追加やインデックスの追加時に長時間のロックがかかる可能性がある
• 分散してデータを保存した場合、全てのデータをチェックしてから、結果を出力することになるので、非常に遅い。