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

株式会社カカクコム
シニアチーフアーキテクト

佐々木 展幸
よくある背景
Small Start
アクセス数が
増える

Web
AP

DB

システム全体がシングルポイント
よくある背景
AP Scale Out
サーバを並列増設

・行が増える
・テーブルが増える
・トランザクションが増える

Web
AP

DB

DBがシングルポイント

Web
AP

Web
AP
よくある背景
DB Scale Out
Web
AP

Web
AP

Web
AP

DBを分散して対応
完全な双方向同期がで
きれば良いが・・・
マスタ
DB

マスタDBがシングルポイント

複製
DB
よくある背景
DB Scale Up
Web
AP

DBの性能UPで対応

DB
DBがシングルポイント

Web
AP

Web
AP
いつのまにか・・・
大規模なシステムに
収益に関わるシステムに
「何でそんな構成になってるの」
「止まらないシステムにして」
止まらないシステム概念図
Web
AP

Web
AP

Web
AP

各アプリケーションが適切な接続先を判断

DB

DB

DB
止まらないシステム概念図
Web
AP

Web
AP

Web
AP

常に稼働している代表を作り接続

代表接続先

DB

DB

DB
よくあるクラスタ構成
フェールオーバークラスタ
代表IP
Active

HB
DB-a

DB-b

Standby

HDD

DB-a で障害発生時には DB-b に切り替え
HDDがシングルポイント
稼働率99.999%
年間の停止時間が5分以下の水準
ただし・・・
一般的に、定期メンテナンスなどの

計画的な停止時間は含まれません
よくある定期メンテナンス
1. セキュリティパッチ適用作業
① OS再起動が必要な場合

⇒ クラスタ切り替えにかかる時間
② クラスタリソースに関わるパッチがある場合
例)SQL Server 2005 のパッチ

⇒ パッチ適用完了までの時...
①クラスタ切り替えにかかる時間
ハードウェア性能
OS

クラスタソフト
稼働サービス

によって変わりますが、
数十秒~数分かかります。
Windowsの場合はほぼ毎月。
②クラスタリソースの更新
サービスはクラスタシステム上で常に1つだけ起動
サービス
起動中

Active

サービス
停止中

HB
DB-a

Data

DB-b

Standby

HDD

Active側で起動中のサービスに対して
更...
メンテナンス時間
フェールオーバークラスタ構成の場合、

クラスタ切り替え回数 x 約3分
更に、SQL Server 2005以前だと、

DBのパッチ適用回数 x 約1時間
のメンテナンス時間が発生。
改善できそうな構成 その1
SQL Server 2008 以降で、
データベースミラーリング
を使えば改善できそうです。
切り替え時間も
数秒単位に短縮されるようです。
その2 王道
Oracle RAC では
これらの停止時間がほぼ解消されます・・・が、
代表に接続すると
起動しているサービスにご案内
サービス
起動中

Active

サービス
起動中

HB
DB-a

Data

DB-b

HDD

...
でも、お高いんでしょう?
• はい。

高くても仕方ないか・・・
稀に全ノードの停止が必要になるパッチが出るそう
です。(Oracleの中の人談)
基本的にはメンテナンス時間がある運用を推奨

サービス
停止中

Active

サービス
停止中

HB
DB-a

Data

DB-b

HDD

Acti...
今回移行対象のシステム
フェールオーバークラスタ
代表IP
Active

HB
DB-a

Data

DB-b

Standby

HDD

Windows2003 / SQL Server 2000
要件
1. 止まらないシステムにして
2. サービスを止めずに移行したい
サービスが止まる主な要素
1. HDDがシングルポイントの構成で故障
2. メンテナンス時間にサービス停止
共有HDD機器の選び方
Level.1
冗長化構成、ホットプラグ対応かどうか
HDDは必ず壊れます。

Level.2
部品が冗長化されているか
電源、コントローラー、ネットワークなど。

Level.3
ファームウェアのバグやアップデー...
障害でもメンテでも
サービスを止めたくない
要望

絶対

可

既存アプリ
変更少なく

HDD
単一障害点
5年稼働できる

可

必要

最新のインフラ
できるだけ安く
絶対

2013年4月まで

可
最終採用案
SQL Server 2012 AlwaysOn
+
キューイングシステム(要開発)
+
無停止移行プログラム(要開発)
SQL Server 2012 AlwaysOn
AlwaysOn可用性グループを用いた3台構成
代表「可用性グループリスナー」に接続すると
プライマリサーバに接続

共有DISK
不要
=早くて安い

サービス
起動中

サービス
起動中

...
キューイングシステム概要
通常モード
「可用性グループリスナー」に接続
プライマリサーバに接続

DB-a

DB-b

AlwaysONでデータ同期

DB-c
キューイングシステム概要
メンテナンスモード
キューの仕組みを持った
「メンテナンスDB」に接続するように変更
メンテナンスDBがマスター
メンテナンスDB

キューテーブルを元に非同期に更新

キュー
テーブル

可用性グループリスナー

D...
プライマリサーバ切り替え中も
メンテナンスモード
キューの仕組みを持った
「メンテナンスDB」に接続
利用者には遅延なし

キューテーブルから
AlwaysOn環境への
非同期更新は
20~30秒遅延する

メンテナンスDB
キュー
テーブル
...
通常モードに戻す時は
キューテーブルが空になった事を確認して
「可用性グループリスナー」に接続変更

メンテナンスDB
キュー
テーブル

可用性グループリスナー

DB-a

DB-b

AlwaysONでデータ同期

リストアDB

DB-...
利用上の注意点と対策
1. 全ての接続先を一括で変更できること
 全ての処理をsp化
 トランザクションをsp内に

2. 処理性能 > キューの増加量 であること
 メンテナンスは低負荷時に実施する運用
 キューを破棄して強制的に戻す...
移行も無停止で
1.旧DBから新DBにデータをコピー
旧システム
旧アプリ

旧DB

Master

新DB
移行も無停止で
2.新旧システムの並行稼働
旧システム

新システム

旧アプリ

新アプリ

旧DB

新DB

Master
新アプリは、旧DBを従来と同様に利用しつつ、
新DBも同じ状態にする・・・
移行も無停止で
3.旧アプリ廃止
旧システム

新システム

旧アプリ

新アプリ

旧DB

新DB

Master
利用されていないデータは移行されていない状態
移行も無停止で
4.最終同期
旧システム

新システム

旧アプリ

新アプリ

旧DB

新DB

Master
差分を同期して、新DBをマスターに
新アプリの旧DB更新処理を無効に
これで、
サービスを止めること無く移行が完了
新システムでは

メンテナンスモードを利用することで

完全無停止の運用が可能に
2013年05月~本日まで無停止
予想外に不便だったこと
1. バックアップやメンテナンス等のジョブ
 フェイルオーバークラスタではインスタンスが1つ
 AlwaysOnでは各インスタンスに必要
 ジョブによってはプライマリサーバかどうかの判定

2. ログの参照
 管...
注意点あるいはトラブル
■SQL Server 2000 と 2012 は、
相互に直接接続できない。
バックアップのリストアもできない。
⇒ 中継用に、SQL Server 2008 を用意
注意点あるいはトラブル 2
■分散トランザクションを使うと、
分離レベルが SERIALIZABLE になる。
⇒ 適切な分離レベルを明示
単体テストレベルでは気が付かない
うっかり忘れると大変なことに
注意点あるいはトラブル 3
■暗黙の型変換
数字=文字 については、
ほとんどのDB製品では 「暗黙の型変換」 が有効。
「数字」を「文字」で検索しても、大きな問題にはならないが、
「文字」を「数字」で検索すると、
一見動いているように見えて、...
[key] varchar(10)
正) SELECT * FROM table WHERE key=‘1’
誤) SELECT * FROM table WHERE key=1
全行の文字列[key]を数値に変換してから検索するため、
イン...
参考情報
暗黙の型変換で変換される型は、
環境によって変わってきます。
MSSQL、ORACLEは「自動的に選択」
MySQLは「浮動小数点 (実) 数」 固定
Myルール

「文字型」と「数値型」
迷ったら「数値型」
謝辞

・日本マイクロソフト株式会社 様
・株式会社 CSK Win テクノロジ 様
本システムの導入にあたり、様々なサポートを頂きました。
データベースエンジニア
常時募集中です

ご静聴ありがとうございました。
Upcoming SlideShare
Loading in...5
×

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

1,794

Published on

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

No Downloads
Views
Total Views
1,794
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

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

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

    Clipping is a handy way to collect important slides you want to go back to later.

×