Upload
insight-technology-inc
View
1.646
Download
1
Embed Size (px)
Citation preview
24時間365日 「本当に」止まらない
データベースシステムの導入
~ AlwaysOn+Qシステム で完全無停止運用 ~
株式会社カカクコム シニアチーフアーキテクト 佐々木 展幸
よくある背景
DB
Web AP
アクセス数が 増える
Small Start
システム全体がシングルポイント
よくある背景
DB
Web AP
Web AP
Web AP
・行が増える ・テーブルが増える ・トランザクションが増える
サーバを並列増設
AP Scale Out
DBがシングルポイント
よくある背景
マスタ DB
Web AP
DBを分散して対応 完全な双方向同期ができれば良いが・・・
Web AP
Web AP
複製 DB
DB Scale Out
マスタDBがシングルポイント
よくある背景
DB
Web AP
Web AP
Web AP
DBの性能UPで対応
DB Scale Up
DBがシングルポイント
いつのまにか・・・
「何でそんな構成になってるの」 「止まらないシステムにして」
大規模なシステムに
収益に関わるシステムに
止まらないシステム概念図
Web AP
Web AP
Web AP
DB DB DB
各アプリケーションが適切な接続先を判断
止まらないシステム概念図
Web AP
Web AP
Web AP
代表接続先
DB DB DB
常に稼働している代表を作り接続
よくあるクラスタ構成
DB-a DB-b
HDD
代表IP
DB-a で障害発生時には DB-b に切り替え
HDDがシングルポイント
HB
フェールオーバークラスタ
Active Standby
稼働率99.999%
年間の停止時間が5分以下の水準
ただし・・・ 一般的に、定期メンテナンスなどの
計画的な停止時間は含まれません
よくある定期メンテナンス
1. セキュリティパッチ適用作業 ① OS再起動が必要な場合 ⇒ クラスタ切り替えにかかる時間 ② クラスタリソースに関わるパッチがある場合 例)SQL Server 2005 のパッチ ⇒ パッチ適用完了までの時間
①クラスタ切り替えにかかる時間
OS クラスタソフト
ハードウェア性能
によって変わりますが、 数十秒~数分かかります。
稼働サービス
Windowsの場合はほぼ毎月。
②クラスタリソースの更新
DB-a DB-b
HDD
Active Standby
Active側で起動中のサービスに対して 更新が必要な場合がある
HB
Data
サービス 起動中
サービスはクラスタシステム上で常に1つだけ起動
サービス 停止中
メンテナンス時間 フェールオーバークラスタ構成の場合、
クラスタ切り替え回数 x 約3分
更に、SQL Server 2005以前だと、 DBのパッチ適用回数 x 約1時間
のメンテナンス時間が発生。
改善できそうな構成 その1
SQL Server 2008 以降で、 データベースミラーリング
を使えば改善できそうです。 切り替え時間も
数秒単位に短縮されるようです。
その2 王道 Oracle RAC では これらの停止時間がほぼ解消されます・・・が、
DB-a
HDD
Active HB
Data
サービス 起動中
DB-b
サービス 起動中
Active
代表に接続すると 起動しているサービスにご案内
でも、お高いんでしょう?
• はい。
高くても仕方ないか・・・
稀に全ノードの停止が必要になるパッチが出るそうです。(Oracleの中の人談)
DB-a
HDD
Active HB
Data
DB-b Active
サービス 停止中
サービス 停止中
基本的にはメンテナンス時間がある運用を推奨
今回移行対象のシステム
DB-a DB-b
HDD
代表IP
HB
フェールオーバークラスタ
Active Standby
Windows2003 / SQL Server 2000
Data
要件
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台構成
DB-a
HDD
全てActive
サービス 起動中
DB-b
サービス 起動中
代表「可用性グループリスナー」に接続すると プライマリサーバに接続
HDD
DB-c
サービス 起動中
HDD 共有DISK 不要 =早くて安い
キューイングシステム概要
DB-a DB-b DB-c
「可用性グループリスナー」に接続 プライマリサーバに接続
AlwaysONでデータ同期
通常モード
キュー テーブル
キューイングシステム概要
DB-a DB-b DB-c
AlwaysONでデータ同期
メンテナンスモード キューの仕組みを持った
「メンテナンスDB」に接続するように変更
メンテナンスDB
可用性グループリスナー
メンテナンスDBがマスター
キューテーブルを元に非同期に更新
リストアDB
バックアップ をリストア
キュー テーブル
プライマリサーバ切り替え中も
DB-a DB-b DB-c
AlwaysONでデータ同期
メンテナンスモード キューの仕組みを持った 「メンテナンスDB」に接続
メンテナンスDB
可用性グループリスナー
キューテーブルから AlwaysOn環境への
非同期更新は 20~30秒遅延する
切り替え中 リストアDB
利用者には遅延なし
キュー テーブル
通常モードに戻す時は
DB-a DB-b DB-c
AlwaysONでデータ同期
キューテーブルが空になった事を確認して 「可用性グループリスナー」に接続変更
メンテナンスDB
可用性グループリスナー リストアDB
利用上の注意点と対策
1. 全ての接続先を一括で変更できること 全ての処理をsp化 トランザクションをsp内に
2. 処理性能 > キューの増加量 であること メンテナンスは低負荷時に実施する運用 キューを破棄して強制的に戻す機能も用意
移行も無停止で 1.旧DBから新DBにデータをコピー
新DB 旧DB
旧アプリ
Master
旧システム
移行も無停止で 2.新旧システムの並行稼働
新DB 旧DB
旧アプリ
Master
新アプリ
新アプリは、旧DBを従来と同様に利用しつつ、 新DBも同じ状態にする・・・
旧システム 新システム
移行も無停止で 3.旧アプリ廃止
新DB 旧DB
旧アプリ
Master
新アプリ
利用されていないデータは移行されていない状態
旧システム 新システム
移行も無停止で 4.最終同期
新DB 旧DB
旧アプリ
Master
新アプリ
差分を同期して、新DBをマスターに
新アプリの旧DB更新処理を無効に
旧システム 新システム
これで、
サービスを止めること無く移行が完了
新システムでは
メンテナンスモードを利用することで
完全無停止の運用が可能に
2013年05月~本日まで無停止
予想外に不便だったこと
1. バックアップやメンテナンス等のジョブ フェイルオーバークラスタではインスタンスが1つ AlwaysOnでは各インスタンスに必要 ジョブによってはプライマリサーバかどうかの判定
2. ログの参照 管理画面からOSのイベントログが参照できない
(たぶんバグ・・・)
3. ライセンス 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]を数値に変換してから検索するため、 インデックスがあっても利用できない。 インデックスが利用できないので、テーブルscanが発生する。 参照のみであれば(遅くなるが)可能。 更新時にはページロック、テーブルロック、 状況によってはデッドロックが発生する。 予期しない結果を返す事がある。 例)unique制約かけてるのに複数行Hitする 例)変換時に精度が変わり、丸め誤差など発生
暗黙の型変換で変換される型は、 環境によって変わってきます。 MSSQL、ORACLEは「自動的に選択」
MySQLは「浮動小数点 (実) 数」 固定
参考情報
Myルール
「文字型」と「数値型」 迷ったら「数値型」
謝辞
・日本マイクロソフト株式会社 様 ・株式会社 CSK Win テクノロジ 様 本システムの導入にあたり、様々なサポートを頂きました。
ご静聴ありがとうございました。
データベースエンジニア
常時募集中です