Your SlideShare is downloading. ×
[C33] 24時間365日「本当に」止まらないデータベースシステムの導入 ~AlwaysOn+Qシステムで完全無停止運用~ by Nobuyuki Sasaki
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

1,324
views

Published on


0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,324
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
26
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 24時間365日 「本当に」止まらない データベースシステムの導入 ~ AlwaysOn+Qシステム で完全無停止運用 ~ 株式会社カカクコム シニアチーフアーキテクト 佐々木 展幸
  • 2. よくある背景 Small Start アクセス数が 増える Web AP DB システム全体がシングルポイント
  • 3. よくある背景 AP Scale Out サーバを並列増設 ・行が増える ・テーブルが増える ・トランザクションが増える Web AP DB DBがシングルポイント Web AP Web AP
  • 4. よくある背景 DB Scale Out Web AP Web AP Web AP DBを分散して対応 完全な双方向同期がで きれば良いが・・・ マスタ DB マスタDBがシングルポイント 複製 DB
  • 5. よくある背景 DB Scale Up Web AP DBの性能UPで対応 DB 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. セキュリティパッチ適用作業 ① OS再起動が必要な場合 ⇒ クラスタ切り替えにかかる時間 ② クラスタリソースに関わるパッチがある場合 例)SQL Server 2005 のパッチ ⇒ パッチ適用完了までの時間
  • 12. ①クラスタ切り替えにかかる時間 ハードウェア性能 OS クラスタソフト 稼働サービス によって変わりますが、 数十秒~数分かかります。 Windowsの場合はほぼ毎月。
  • 13. ②クラスタリソースの更新 サービスはクラスタシステム上で常に1つだけ起動 サービス 起動中 Active サービス 停止中 HB DB-a Data DB-b Standby HDD Active側で起動中のサービスに対して 更新が必要な場合がある
  • 14. メンテナンス時間 フェールオーバークラスタ構成の場合、 クラスタ切り替え回数 x 約3分 更に、SQL Server 2005以前だと、 DBのパッチ適用回数 x 約1時間 のメンテナンス時間が発生。
  • 15. 改善できそうな構成 その1 SQL Server 2008 以降で、 データベースミラーリング を使えば改善できそうです。 切り替え時間も 数秒単位に短縮されるようです。
  • 16. その2 王道 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 / SQL Server 2000
  • 20. 要件 1. 止まらないシステムにして 2. サービスを止めずに移行したい
  • 21. サービスが止まる主な要素 1. HDDがシングルポイントの構成で故障 2. メンテナンス時間にサービス停止
  • 22. 共有HDD機器の選び方 Level.1 冗長化構成、ホットプラグ対応かどうか HDDは必ず壊れます。 Level.2 部品が冗長化されているか 電源、コントローラー、ネットワークなど。 Level.3 ファームウェアのバグやアップデート ・・・
  • 23. 障害でもメンテでも サービスを止めたくない 要望 絶対 可 既存アプリ 変更少なく HDD 単一障害点 5年稼働できる 可 必要 最新のインフラ できるだけ安く 絶対 2013年4月まで 可
  • 24. 最終採用案 SQL Server 2012 AlwaysOn + キューイングシステム(要開発) + 無停止移行プログラム(要開発)
  • 25. SQL Server 2012 AlwaysOn AlwaysOn可用性グループを用いた3台構成 代表「可用性グループリスナー」に接続すると プライマリサーバに接続 共有DISK 不要 =早くて安い サービス 起動中 サービス 起動中 サービス 起動中 DB-a 全て Active DB-b DB-c HDD HDD HDD
  • 26. キューイングシステム概要 通常モード 「可用性グループリスナー」に接続 プライマリサーバに接続 DB-a DB-b AlwaysONでデータ同期 DB-c
  • 27. キューイングシステム概要 メンテナンスモード キューの仕組みを持った 「メンテナンスDB」に接続するように変更 メンテナンスDBがマスター メンテナンスDB キューテーブルを元に非同期に更新 キュー テーブル 可用性グループリスナー DB-a DB-b AlwaysONでデータ同期 リストアDB DB-c バックアップ をリストア
  • 28. プライマリサーバ切り替え中も メンテナンスモード キューの仕組みを持った 「メンテナンスDB」に接続 利用者には遅延なし キューテーブルから 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. 移行も無停止で 1.旧DBから新DBにデータをコピー 旧システム 旧アプリ 旧DB Master 新DB
  • 32. 移行も無停止で 2.新旧システムの並行稼働 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 新アプリは、旧DBを従来と同様に利用しつつ、 新DBも同じ状態にする・・・
  • 33. 移行も無停止で 3.旧アプリ廃止 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 利用されていないデータは移行されていない状態
  • 34. 移行も無停止で 4.最終同期 旧システム 新システム 旧アプリ 新アプリ 旧DB 新DB Master 差分を同期して、新DBをマスターに 新アプリの旧DB更新処理を無効に
  • 35. これで、 サービスを止めること無く移行が完了 新システムでは メンテナンスモードを利用することで 完全無停止の運用が可能に 2013年05月~本日まで無停止
  • 36. 予想外に不便だったこと 1. バックアップやメンテナンス等のジョブ  フェイルオーバークラスタではインスタンスが1つ  AlwaysOnでは各インスタンスに必要  ジョブによってはプライマリサーバかどうかの判定 2. ログの参照  管理画面からOSのイベントログが参照できない (たぶんバグ・・・) 3. ライセンス  2台分必要・・・
  • 37. 注意点あるいはトラブル ■SQL Server 2000 と 2012 は、 相互に直接接続できない。 バックアップのリストアもできない。 ⇒ 中継用に、SQL Server 2008 を用意
  • 38. 注意点あるいはトラブル 2 ■分散トランザクションを使うと、 分離レベルが SERIALIZABLE になる。 ⇒ 適切な分離レベルを明示 単体テストレベルでは気が付かない うっかり忘れると大変なことに
  • 39. 注意点あるいはトラブル 3 ■暗黙の型変換 数字=文字 については、 ほとんどの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. Myルール 「文字型」と「数値型」 迷ったら「数値型」
  • 43. 謝辞 ・日本マイクロソフト株式会社 様 ・株式会社 CSK Win テクノロジ 様 本システムの導入にあたり、様々なサポートを頂きました。
  • 44. データベースエンジニア 常時募集中です ご静聴ありがとうございました。