[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sasaki

[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ～AlwaysOn＋Qシステムで完全無停止運用～ by Nobuyuki Sasaki

• 1.
  24時間365日 「本当に」止まらない データベースシステムの導入 ～ AlwaysOn＋Qシステム で完全無停止運用～ 株式会社カカクコム シニアチーフアーキテクト 佐々木 展幸
• 2.
  よくある背景 Small Start アクセス数が 増える Web AP DB システム全体がシングルポイント
• 3.
  よくある背景 AP Scale Out サーバを並列増設 ・行が増える ・テーブルが増える ・トランザクションが増える Web AP DB ＤＢがシングルポイント Web AP Web AP
• 4.
  よくある背景 DB Scale Out Web AP Web AP Web AP ＤＢを分散して対応 完全な双方向同期がで きれば良いが・・・ マスタ DB マスタＤＢがシングルポイント 複製 DB
• 5.
  よくある背景 DB Scale Up Web AP ＤＢの性能ＵＰで対応 DB ＤＢがシングルポイント Web AP Web AP
• 6.
  いつのまにか・・・ 大規模なシステムに 収益に関わるシステムに 「何でそんな構成になってるの」 「止まらないシステムにして」
• 7.
  止まらないシステム概念図 Web AP Web AP Web AP 各アプリケーションが適切な接続先を判断 DB DB DB
• 8.
  止まらないシステム概念図 Web AP Web AP Web AP 常に稼働している代表を作り接続 代表接続先 DB DB DB
• 9.
  よくあるクラスタ構成 フェールオーバークラスタ 代表IP Active HB DB-a DB-b Standby HDD DB-a で障害発生時には DB-bに切り替え HDDがシングルポイント
• 10.
  稼働率99.999％ 年間の停止時間が5分以下の水準 ただし・・・ 一般的に、定期メンテナンスなどの 計画的な停止時間は含まれません
• 11.
  よくある定期メンテナンス 1. セキュリティパッチ適用作業 ① ＯＳ再起動が必要な場合 ⇒クラスタ切り替えにかかる時間 ② クラスタリソースに関わるパッチがある場合 例）SQL Server 2005 のパッチ ⇒ パッチ適用完了までの時間
• 12.
  ①クラスタ切り替えにかかる時間 ハードウェア性能 ＯＳ クラスタソフト 稼働サービス によって変わりますが、 数十秒～数分かかります。 Windowsの場合はほぼ毎月。
• 13.
  ②クラスタリソースの更新 サービスはクラスタシステム上で常に１つだけ起動 サービス 起動中 Active サービス 停止中 HB DB-a Data DB-b Standby HDD Active側で起動中のサービスに対して 更新が必要な場合がある
• 14.
  メンテナンス時間 フェールオーバークラスタ構成の場合、 クラスタ切り替え回数 ｘ 約３分 更に、SQLServer 2005以前だと、 DBのパッチ適用回数 ｘ 約1時間 のメンテナンス時間が発生。
• 15.
  改善できそうな構成 その１ SQL Server2008 以降で、 データベースミラーリング を使えば改善できそうです。 切り替え時間も 数秒単位に短縮されるようです。
• 16.
  その２ 王道 Oracle RACでは これらの停止時間がほぼ解消されます・・・が、 代表に接続すると 起動しているサービスにご案内 サービス 起動中 Active サービス 起動中 HB DB-a Data DB-b HDD Active
• 17.
  でも、お高いんでしょう？ • はい。 高くても仕方ないか・・・
• 18.
  稀に全ノードの停止が必要になるパッチが出るそう です。（Oracleの中の人談） 基本的にはメンテナンス時間がある運用を推奨 サービス 停止中 Active サービス 停止中 HB DB-a Data DB-b HDD Active
• 19.
  今回移行対象のシステム フェールオーバークラスタ 代表IP Active HB DB-a Data DB-b Standby HDD Windows2003 ／ SQLServer 2000
• 20.
  要件 1. 止まらないシステムにして 2. サービスを止めずに移行したい
• 21.
  サービスが止まる主な要素 1. ＨＤＤがシングルポイントの構成で故障 2. メンテナンス時間にサービス停止
• 22.
  共有HDD機器の選び方 Level．１ 冗長化構成、ホットプラグ対応かどうか HDDは必ず壊れます。 Level．２ 部品が冗長化されているか 電源、コントローラー、ネットワークなど。 Level．３ ファームウェアのバグやアップデート ・・・
• 23.
  障害でもメンテでも サービスを止めたくない 要望 絶対 可 既存アプリ 変更少なく HDD 単一障害点 ５年稼働できる 可 必要 最新のインフラ できるだけ安く 絶対 2013年4月まで 可
• 24.
  最終採用案 SQL Server 2012AlwaysOn ＋ キューイングシステム（要開発） ＋ 無停止移行プログラム（要開発）
• 25.
  SQL Server 2012AlwaysOn AlwaysOn可用性グループを用いた３台構成 代表「可用性グループリスナー」に接続すると プライマリサーバに接続 共有DISK 不要 ＝早くて安い サービス 起動中 サービス 起動中 サービス 起動中 DB-a 全て Active DB-b DB-c HDD HDD HDD
• 26.
  キューイングシステム概要 通常モード 「可用性グループリスナー」に接続 プライマリサーバに接続 DB-a DB-b AlwaysONでデータ同期 DB-c
• 27.
  キューイングシステム概要 メンテナンスモード キューの仕組みを持った 「メンテナンスＤＢ」に接続するように変更 メンテナンスＤＢがマスター メンテナンスDB キューテーブルを元に非同期に更新 キュー テーブル 可用性グループリスナー DB-a DB-b AlwaysONでデータ同期 リストアDB DB-c バックアップ をリストア
• 28.
  プライマリサーバ切り替え中も メンテナンスモード キューの仕組みを持った 「メンテナンスＤＢ」に接続 利用者には遅延なし キューテーブルから AlwaysOn環境への 非同期更新は 20~30秒遅延する メンテナンスDB キュー テーブル 可用性グループリスナー リストアDB 切り替え中 DB-a DB-b AlwaysONでデータ同期 DB-c
• 29.
  通常モードに戻す時は キューテーブルが空になった事を確認して 「可用性グループリスナー」に接続変更 メンテナンスDB キュー テーブル 可用性グループリスナー DB-a DB-b AlwaysONでデータ同期 リストアDB DB-c
• 30.
  利用上の注意点と対策 1. 全ての接続先を一括で変更できること  全ての処理をsp化 トランザクションをsp内に 2. 処理性能 ＞ キューの増加量 であること  メンテナンスは低負荷時に実施する運用  キューを破棄して強制的に戻す機能も用意
• 31.
  移行も無停止で １．旧DBから新DBにデータをコピー 旧システム 旧アプリ 旧DB Master 新DB
• 32.
  移行も無停止で ２．新旧システムの並行稼働 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 新アプリは、旧DBを従来と同様に利用しつつ、 新DBも同じ状態にする・・・
• 33.
  移行も無停止で ３．旧アプリ廃止 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 利用されていないデータは移行されていない状態
• 34.
  移行も無停止で ４．最終同期 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 差分を同期して、新DBをマスターに 新アプリの旧DB更新処理を無効に
• 35.
  これで、 サービスを止めること無く移行が完了 新システムでは メンテナンスモードを利用することで 完全無停止の運用が可能に 2013年05月～本日まで無停止
• 36.
  予想外に不便だったこと 1. バックアップやメンテナンス等のジョブ  フェイルオーバークラスタではインスタンスが１つ AlwaysOnでは各インスタンスに必要  ジョブによってはプライマリサーバかどうかの判定 2. ログの参照  管理画面からOSのイベントログが参照できない （たぶんバグ・・・） 3. ライセンス  ２台分必要・・・
• 37.
  注意点あるいはトラブル ■SQL Server 2000と 2012 は、 相互に直接接続できない。 バックアップのリストアもできない。 ⇒ 中継用に、SQL Server 2008 を用意
• 38.
  注意点あるいはトラブル ２ ■分散トランザクションを使うと、 分離レベルが SERIALIZABLEになる。 ⇒ 適切な分離レベルを明示 単体テストレベルでは気が付かない うっかり忘れると大変なことに
• 39.
  注意点あるいはトラブル ３ ■暗黙の型変換 数字＝文字 については、 ほとんどのDB製品では「暗黙の型変換」 が有効。 「数字」を「文字」で検索しても、大きな問題にはならないが、 「文字」を「数字」で検索すると、 一見動いているように見えて、深刻な問題を引き起こす。
• 40.
  [key] varchar(10) 正） SELECT* FROM table WHERE key=‘1’ 誤） SELECT * FROM table WHERE key=1 全行の文字列[key]を数値に変換してから検索するため、 インデックスがあっても利用できない。 インデックスが利用できないので、テーブルscanが発生する。 参照のみであれば(遅くなるが)可能。 更新時にはページロック、テーブルロック、 状況によってはデッドロックが発生する。 予期しない結果を返す事がある。 例）unique制約かけてるのに複数行Hitする 例）変換時に精度が変わり、丸め誤差など発生
• 41.
  参考情報 暗黙の型変換で変換される型は、 環境によって変わってきます。 MSSQL、ORACLEは「自動的に選択」 MySQLは「浮動小数点 (実) 数」固定
• 42.
  Ｍｙルール 「文字型」と「数値型」 迷ったら「数値型」
• 43.
  謝辞 ・日本マイクロソフト株式会社 様 ・株式会社 CSKWin テクノロジ 様 本システムの導入にあたり、様々なサポートを頂きました。
• 44.
  データベースエンジニア 常時募集中です ご静聴ありがとうございました。