24時間365日 「本当に」止まらない

データベースシステムの導入

～ AlwaysOn＋Qシステム で完全無停止運用 ～

株式会社カカクコム シニアチーフアーキテクト 佐々木 展幸

よくある背景

DB

Web AP

アクセス数が 増える

Small Start

システム全体がシングルポイント

よくある背景

DB

Web AP

Web AP

Web AP

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

サーバを並列増設

AP Scale Out

ＤＢがシングルポイント

よくある背景

マスタ DB

Web AP

ＤＢを分散して対応 完全な双方向同期ができれば良いが・・・

Web AP

Web AP

複製 DB

DB Scale Out

マスタＤＢがシングルポイント

よくある背景

DB

Web AP

Web AP

Web AP

ＤＢの性能ＵＰで対応

DB Scale Up

ＤＢがシングルポイント

いつのまにか・・・

「何でそんな構成になってるの」 「止まらないシステムにして」

大規模なシステムに

収益に関わるシステムに

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

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. セキュリティパッチ適用作業 ① ＯＳ再起動が必要な場合 ⇒ クラスタ切り替えにかかる時間 ② クラスタリソースに関わるパッチがある場合 例）SQL Server 2005 のパッチ ⇒ パッチ適用完了までの時間

①クラスタ切り替えにかかる時間

ＯＳ クラスタソフト

ハードウェア性能

によって変わりますが、 数十秒～数分かかります。

稼働サービス

Windowsの場合はほぼ毎月。

②クラスタリソースの更新

DB-a DB-b

HDD

Active Standby

Active側で起動中のサービスに対して 更新が必要な場合がある

HB

Data

サービス 起動中

サービスはクラスタシステム上で常に１つだけ起動

サービス 停止中

メンテナンス時間 フェールオーバークラスタ構成の場合、

クラスタ切り替え回数 ｘ 約３分

更に、SQL Server 2005以前だと、 DBのパッチ適用回数 ｘ 約1時間

のメンテナンス時間が発生。

改善できそうな構成 その１

SQL Server 2008 以降で、 データベースミラーリング

を使えば改善できそうです。 切り替え時間も

数秒単位に短縮されるようです。

その２ 王道 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. ＨＤＤがシングルポイントの構成で故障 2. メンテナンス時間にサービス停止

共有HDD機器の選び方 Level．１

冗長化構成、ホットプラグ対応かどうか HDDは必ず壊れます。

Level．２ 部品が冗長化されているか

電源、コントローラー、ネットワークなど。

Level．３ ファームウェアのバグやアップデート

・・・

障害でもメンテでも サービスを止めたくない

HDD 単一障害点 既存アプリ

変更少なく

５年稼働できる

最新のインフラ

2013年4月まで

絶対

可 要望

必要 可

絶対 できるだけ安く 可

最終採用案

SQL Server 2012 AlwaysOn ＋

キューイングシステム（要開発） ＋

無停止移行プログラム（要開発）

SQL Server 2012 AlwaysOn AlwaysOn可用性グループを用いた３台構成

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-a DB-b DB-c

AlwaysONでデータ同期

メンテナンスモード キューの仕組みを持った 「メンテナンスＤＢ」に接続

メンテナンスDB

可用性グループリスナー

キューテーブルから AlwaysOn環境への

非同期更新は 20~30秒遅延する

切り替え中 リストアDB

利用者には遅延なし

キュー テーブル

通常モードに戻す時は

DB-a DB-b DB-c

AlwaysONでデータ同期

キューテーブルが空になった事を確認して 「可用性グループリスナー」に接続変更

メンテナンスDB

可用性グループリスナー リストアDB

利用上の注意点と対策

1. 全ての接続先を一括で変更できること 全ての処理をsp化 トランザクションをsp内に

2. 処理性能 ＞ キューの増加量 であること メンテナンスは低負荷時に実施する運用 キューを破棄して強制的に戻す機能も用意

移行も無停止で １．旧DBから新DBにデータをコピー

新DB 旧DB

旧アプリ

Master

旧システム

移行も無停止で ２．新旧システムの並行稼働

新DB 旧DB

旧アプリ

Master

新アプリ

新アプリは、旧DBを従来と同様に利用しつつ、 新DBも同じ状態にする・・・

旧システム 新システム

移行も無停止で ３．旧アプリ廃止

新DB 旧DB

旧アプリ

Master

新アプリ

利用されていないデータは移行されていない状態

旧システム 新システム

移行も無停止で ４．最終同期

新DB 旧DB

旧アプリ

Master

新アプリ

差分を同期して、新DBをマスターに

新アプリの旧DB更新処理を無効に

旧システム 新システム

これで、

サービスを止めること無く移行が完了

新システムでは

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

完全無停止の運用が可能に

2013年05月～本日まで無停止

予想外に不便だったこと

1. バックアップやメンテナンス等のジョブ フェイルオーバークラスタではインスタンスが１つ AlwaysOnでは各インスタンスに必要 ジョブによってはプライマリサーバかどうかの判定

2. ログの参照 管理画面からOSのイベントログが参照できない

（たぶんバグ・・・）

3. ライセンス ２台分必要・・・

注意点あるいはトラブル

■SQL Server 2000 と 2012 は、 相互に直接接続できない。 バックアップのリストアもできない。

⇒ 中継用に、SQL Server 2008 を用意

注意点あるいはトラブル ２

■分散トランザクションを使うと、 分離レベルが SERIALIZABLE になる。

⇒ 適切な分離レベルを明示

単体テストレベルでは気が付かない うっかり忘れると大変なことに

注意点あるいはトラブル ３

■暗黙の型変換

数字＝文字 については、 ほとんどのDB製品では 「暗黙の型変換」 が有効。 「数字」を「文字」で検索しても、大きな問題にはならないが、 「文字」を「数字」で検索すると、 一見動いているように見えて、深刻な問題を引き起こす。

[key] varchar(10)

正） SELECT * FROM table WHERE key=‘1’ 誤） SELECT * FROM table WHERE key=1 全行の文字列[key]を数値に変換してから検索するため、 インデックスがあっても利用できない。 インデックスが利用できないので、テーブルscanが発生する。 参照のみであれば(遅くなるが)可能。 更新時にはページロック、テーブルロック、 状況によってはデッドロックが発生する。 予期しない結果を返す事がある。 例）unique制約かけてるのに複数行Hitする 例）変換時に精度が変わり、丸め誤差など発生

暗黙の型変換で変換される型は、 環境によって変わってきます。 MSSQL、ORACLEは「自動的に選択」

MySQLは「浮動小数点 (実) 数」 固定

参考情報

Ｍｙルール

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

謝辞

・日本マイクロソフト株式会社 様 ・株式会社 CSK Win テクノロジ 様 本システムの導入にあたり、様々なサポートを頂きました。

ご静聴ありがとうございました。

データベースエンジニア

常時募集中です