SRAOSSで開催された「PostgreSQLで実現する高可用性セミナー」に参加してきた。お茶は出るし席はゆったりしてるし、環境は大変よかった。

スライドは後日webで配布されるとのことなので楽しみに待とう。重複する部分もあるが、当日のメモを再構築してみた。ずいぶん長くなっちゃったのはご愛嬌。

【2008-07-25追記】 「PostgreSQLにおける高可用性実現方法」スライド公開

http://www.sraoss.co.jp/event_seminar/2008/pgsql_high_availability.pdf

  • ごあいさつ * SRAOSSのコンサル事業についての紹介 * チューニングにまで踏み込んだトレーニング * 実際に動いているものについてのコンサルティング * PostgreSQLについては10年ほどキャリアがある
    >何かしら役に立てますよ * 最近の話題 * 日本支社は今月3周年 * 導入トレーニングが8.3対応 * DB Magazine8月号にPostgreSQLの記事あり * ThinkIT 7月の特集「データベース夏の陣」
    木曜日pgpool-IIについて連載中(入門向け) * OBCIの理事長に支社長が就任 * DB Magazineの記事より * 7.4~8.3にかけてのベンチマークを同じマシンで実施 >8.3はアーキテクチャが大きく変わったため、とくにupdateがよくなってる * 単純な性能ならハード / ソフトのアップグレードでスケールできる
    • PostgreSQLにおける高可用性実現方法
      • 可用性について
        • 可用性とはシステムの信頼度を評価する観点の一つ

        • 稼働率 = MTBF / (MTBF + MTTR)

          • 全時間に対する稼働している時間の割合
          • MTBF(Mean Time Between Failure)
            >平均故障間隔
          • MTTR(Mean Time To Repair)
            >平均修理時間
        • 稼働率が高い = 高可用性 = High Availability(HA)

          <th>
            稼働率
          </th>
          
          <td>
            99.2%
          </td>
          
          <td>
            99.7%
          </td>
          
          <td>
            99.98%
          </td>
          
          <td>
            99.99996%
          </td>
          
          年間あたりの故障時間
          3日
          1日
          1時間
          5分

          >99.7%はすごく高い数値に見えるけど、実は年間丸1日ダウンしてる

        • システムの可用性が高いことによるメリット

          • 機会損失の防止
          • 顧客離れの防止
            >ダウンしているサイトには二度と行かない
          • 顧客からの信頼感
            >管理力 / 技術力が高いことの証
          • 保守費用の低減
            >緊急対応要員不要 → コスト削減
          • データ保全
        • 高可用性戦略

          • バックアップとリストア
            • 可用性は低い
              >MTTRが長くなるため
            • ローコスト
          • 基本は冗長化
            • ハード
            • ソフト
          • SPF(Single Point of Failure = そこが止まるとシステムが止まるポイント)をなくす
            • 稼働率は構成要素の中でもっとも弱い部分に足を引っ張られる
            • 故障する / しないで評価するのは無意味。稼働率が問題
              >故障するのを前提に考える
        • 可用性を上げるための手法

          1. バックアップ / リストア
            • メリット
              • PostgreSQLの機能だけで実現可能
                >ローコスト
            • デメリット
              • バックアップした時点までしか戻れない
              • リストアに時間がかかる = 可用性は低い
              • 代替ハードが必要
                >ないと泣ける / スタンバイ中は無駄
          2. PITRによるバックアップ / リストア
            • Point In Timre Recovery
            • PostgreSQL 8.0以上
            • ファイルシステムバックアップ(tar,rsyncなど)+アーカイブログによる差分バックアップ
            • メリット
              • 最新 / 任意の時点までリカバリできる
              • PostgreSQLの機能だけで実現可能
                >ローコスト
            • デメリット
              • ログを保存する必要がある
              • 操作が煩雑
                >定期的にベースバックアップする必要がある
            • PowerGresを使えばGUIで操作できてラクチン
          3. ウォームスタンバイ
            • pg8.3以上
            • 2台のマシンとPITRを使う
            • アクティブ機→スタンバイ機に連続してアーカイブログを転送
            • スタンバイ機はリカバリし続ける
            • メリット
              • アプリ / DB設定の変更不要
              • 性能劣化があまりない
              • PostgreSQLの機能だけで実現可能
                >ローコスト
            • デメリット
              • スタンバイ側DBにはアクセスできない
              • ログ転送されなかった分はデータロスト
              • 設定が煩雑
              • 作りこみが必要
                • ダウンの検知
                • 接続先の切り替え
                • スタンバイ側をオンラインにする
          4. 共有ディスク型HAシステム
            • HA監視ソフト(HeartBeatなど) + 2台のDBサーバ + 共有ディスク
            • サーバがディスクを共有するためデータコピーが必要ない
            • メリット
              • アプリ / DBの設定変更不要
              • 性能劣化なし
              • 稼働率が高い
                >ダウンタイムは数分程度、復旧のための人手が不要
              • アクティブ / アクティブ構成にすれば待機側のリソースも活用できる
                >スタンバイ側はNFSサーバとして使う、など
            • デメリット
              • 共有ディスクのコストが高い
              • 共有ディスクが故障するとアウト
                >冗長化は必須→さらにコスト増
          5. フォールトトレラント(無停止)構成
            • CPU / メモリ / ディスク / 電源などハードウェアのすべてが二重化されている
            • ソフトウェアからは1台のコンピュータに見える
            • 最近価格は下がり気味
            • メリット
              • ソフトウェアの互換性が高い
                >RedHat Linux、PostgreSQL、PowerGresで性能評価済み(SRAOSS)
              • きわめて高可用性
            • デメリット
              • 専用ハードウエアが必要
              • ソフトウェア障害には対応できない
              • 性能向上を提供するものではない
          6. Slony-I
            • PostgreSQLの開発メンバがメンテナ
            • BSDライセンス
            • トリガベースの非同期レプリケーション
              >更新遅延が発生する(おおむね数秒程度 -> 許されない場合は注意が必要)
            • シングルマスタ – マルチスレーブ / 更新を受け付けるのはマスタのみ
            • メリット
              • ノードを柔軟に追加できる
                >動作中に追加も可能
            • デメリット
              • 更新遅延
              • 負荷分散ができない
                >単独ではできないがpgpool-IIと組み合わせるとできる
              • 設定が面倒
                >テーブルごとに設定の必要あり
              • データベースの機能に制限がつく
                • 動的にテーブル追加するようなアプリは苦手
                • レプリケーションできないデータがある(blobなど)
                • ノード障害に自動対応できない
                • パラレルクエリに対応してない
          7. PostgresForest
            • NTTデータが開発
            • BSDライセンス
            • JDBCドライバの機能拡張として提供される
              >レプリケーション、負荷分散、パラレルクエリ機能を提供
            • メリット
              • 検索系の性能向上が期待できる
              • ノード障害に自動対応できる
            • デメリット
              • APIはJavaのみ
              • 更新系の性能向上はしない
              • パラレルクエリで対応できない問い合わせがある
          8. PGCluster
            • 三谷篤氏が個人的に開発
            • BSDライセンス
            • PostgreSQLのpatchとして提供される
              >コネクションプーリング、負荷分散、レプリケーション
            • メリット
              • 検索系の性能向上
              • ノード障害に自動対応
            • デメリット
              • 設定がやや面倒
              • Postgres本体へのpatchなので最新バージョンへの追随が遅れる
              • 更新系の性能低下
                >更新系クエリの割合が20%を超えるとトータル性能ダウン
              • パラレルクエリ非対応
              • フル機能を利用するには5ノード必要
                >ロードバランサ、レプリケーションサーバ、DBノード(x3)
              • メンテナンスされてない
          9. pgpool-II
            • pgpool Global Dvelopment Group
            • BSDライセンス
            • 多彩な機能
              >コネクションプーリング、レプリケーション、負荷分散、パラレルクエリ
            • 更新クエリをマスタ→スレーブの順で全ノードに実行する
            • メリット
              • 障害に強い
                • 障害検知→自動切り離し
                • 復旧→GUIからオンラインリカバリ
              • 負荷分散機能が充実
                • 問い合わせ分散
                  >参照クエリはランダムに選んだ各ノードに投げる
                • パラレルクエリ
                  >問い合わせを分割して各ノードで分担、結果をpgpool-IIでまとめて返す
              • GUIツールで簡単設定 / 運用
            • デメリット
        • どのソリューションを使うべきか?

          • コストはどれだけかけられる?
          • 検索性能の向上が必要かどうか?
          • DBが遠隔地にある / ネットワーク接続が間歇する
            >Slony-Iしか選択肢がない
      • pgpool-II,Slony-Iを中心とした高可用性構成例のご紹介

        • ソフトウェアレプリケーションによるクラスタリング
          >レプリケーションでスタンバイ機にデータを同期、トラブル時は切り替える
          • pgpool-II
            • pgpool-IIによるレプリケーションにはnow(),random(),serial,sequenceの扱いについて制限がある
              >適切に書けば対応可能→SQLのチェックと対応についてのコストと比較検討する
            • 「唯一」で「可用性が高い」pgpool-IIが必要
              • 複数のpgpoolでレプリケーションを行うとデータ不整合リスクがある
              • フェイルオーバ / リカバリは「唯一の」pgpool-IIで行う必要がある
            • pgpool-HA
              • HeartBeat向けpgpool-II用スクリプト
              • メリット
                • pgpool-IIの可用性があがる
              • デメリット
                • 最新バージョンのHeartBeat / pgpool-IIに対応できていない
                  >古めのバージョンでは実績あり
          • Slony-I
            • 非同期レプリケーションである
              • 遅延は通常長くて数秒程度
                >それが許されるかどうか要件を検討する
              • 更新が大量に発生するとその分遅延が発生する
                • パラメータでチューニングする
                • マスタには高スペックハードを使う
            • Slony-I 2.0
              • 6/27 RC公開
              • PostgreSQL 8.3以降専用に
                >今までSlonyで行っていた処理がPostgresに取り込まれた
                • プログラムがシンプルに
                • パフォーマンスアップ(するかも)
        • PostgreSQLをHAクラスタリング
          >DBサーバを冗長化し、データは共有 / 同期する
          • ファイルシステムによる同期
            DRDB(ファイルシステムレベルのミラーリング)など
            • I/Oがボトルネックになって速度が出ない
            • 更新が激しい場合信頼性に疑問が
            • 商用ソフトウェアも存在する
              LifeKeeperのレプリケーション機能とか
          • ウォームスタンバイ
            >トランザクションログを流し続ける
            • ログがまとまって流れるので速度は出る
            • 非同期になってしまう
            • HAソフトの「標準的な」使い方とはずれる
              >事前/事後処理のスクリプトを自前で書く必要がある
          • 共有ストレージ構成
            • ファイルシステム同期より速い
              >ストレージの冗長化は必須
            • 実績豊富
              >昔はこれしかなかった
            • HAクラスタソフトは商用を推奨
              >ハードウェア検証してくれる
            • 当然高コスト
        • ところでそこまで高可用性が必要?
          • レプリケーション / 自動フェイルオーバの目的
            >停止時間を短く / 復旧点をできるだけ障害直前に
          • それならPITRだけで復旧点 / 復旧時間を改善できる
            >pg_dumpによるデイリーバックアップからはずいぶん改善できるが、意外と使われてない
          • クラスタリングの複雑さはリスクである
            >要求されるコストと技術レベルは高くなるのでシンプルに越したことはない