この投稿はアイスタイル Advent Calendar 2020 の14日目の記事です。

はじめに

DBAのsuzukitoです。

アドベントカレンダー、技術的な話は何を書こうかなと振り返ってみたら、年末年始の事を思い出しました。
昨年末の弊社は利用していたデータセンターの廃止というやむにやまれぬ事情で、データセンター移転をせっせと行っていました。
毎日毎日、仮想マシンを新しいデータセンターへ転送する日々のクライマックスは、物理データベースサーバーの移転でした。

そう、@cosmeのメインデータベースサーバーは物理マシンだったんです。

物理DBサーバーをサービス停止を最小限にして別のロケーションに移転させるには？

@cosmeのデータベースサーバーは以下の構成になっています。

• 更新系DBサーバー
• 参照系DBサーバー
• ディストリビューター

DBサーバーを更新系と参照系に分ける構成は一般的なのですが、ディストリビューターはなんでしょうか？
@cosmeのメインデータベースであるSQL Serverのレプリケーションは、パブサブモデルになっており、送信者がパブリッシャー、受信者がサブスクライバーと呼ばれます。
パブリッシャーとサブスクライバーの間に立って、データを取り出して配布する作業を行うサーバーがディストリビューターです。

参照系DBサーバーの仮想化は進んでいたのですが、止めづらい更新系DBサーバーとディストリビューターは物理マシンのままでした。
これをそのままデータセンター移転させるとなると、自動車で運ぶことになってしまいます。
しかし、老朽化したサーバーを物理的に運搬して、移転先でちゃんと起動する保証はどこにもありません。

そこで、次の2方式が候補に挙がりました。

• フェイルオーバー方式
• レプリケーション方式

※ どちらも社内説明用にsuzukitoが命名した名称です。

フェイルオーバー方式とは

DBサーバーは一般的に冗長構成で運用します。
稼働系のサーバーが停止しても、即座に待機系に切る変わる事で、稼働停止時間を最小限にします。

移転先データセンターに新たにDBサーバー作成し、現在のデータセンターの待機系として機能させます。
移転実施時にフェイルオーバーさせることで、サーバー移転を実現する方式です。

この方式には長所と短所があります。

長所

• 更新停止時間が短い
• DBの同一性が保証される

短所

• レプリケーション遅延時間が長い
• 切り戻し不可能

長所短所を詳しく見ていきましょう。

長所

更新停止時間が短い

フェイルオーバーは一瞬で完了します。全サーバーをフェイルオーバーするとしても30分もあれば完了するため、更新停止の時間は短いです。

DBの同一性が保証される

SQL Serverの冗長化技術は、完全同期方式です。稼働系・待機系共に更新されて初めてコミットが返るため、稼働系・待機系でのデータの差異は発生しません。

短所

レプリケーション遅延時間が長い

ディストリビューターもフェイルオーバーを行いつつ移動させられれば良かったのです、非常に残念なことにディストリビューターの構成に問題があり、移転先に新しく作成する必要がありました。
このため、フェイルオーバー前にレプリケーション設定を全削除し、フェイルオーバー後に再設定を行う必要がありました。
そうなると、参照系DBサーバーは全て初期化する必要が発生し、レプリケーションが完全に元通りになるには日単位で時間がかかると予想されました。

切り戻し不可能

フェイルオーバー前にレプリケーション設定を全削除するため、フェイルオーバー後に問題が発生しても後戻りができません。

レプリケーション方式

移設先のデータセンターに、現データセンターと全く同じ台数、構成のDBサーバー群を構築しておき、更新系同士のレプリケーションを行う事で、移転実施時の参照系へのレプリケーション遅延をゼロにする方式です。

この方式にも長所と短所がありますが、フェイルオーバー方式ときれいに反転しています。

長所

• レプリケーション遅延時間が短い
• 切り戻し可能

短所

• 更新停止時間が長い
• DBの同一性が保証されない

比較表

移転方式	更新停止時間	DB同一性の保証	レプリケーション遅延	切り戻し
フェイルオーバー方式	短い	あり	長い	不可能
レプリケーション方式	長い	なし	なし	可能

選択した方式

更新停止時間が短くとも、レプリケーション遅延が発生している間はサイトの正常な表示ができないため、レプリケーション方式を選びました。

移設実施までの大まかな流れ

移設先参照系DBを本番投入するところまで持って行ければ、移転実施準備が完了します。
これは移設説明に使った資料の抜粋です。
当時の説明資料では移転先更新系DBが青く塗られていたことから、移転実施準備が完了した状態を「青の状態」呼んでいました。

発生した問題

本当に様々な問題が発生しました。
のちほどこの中からいくつかピックアップして、詳しく解説します。

準備段階で発生した問題

• DBアクセスをロードバランサーで抽象化していたが、直接接続しているサーバーが少なからずあり、先にそちらの変更が必要になった
• アプリケーション用ユーザーのログイン無効化で更新停止を実現しようとしたが、saで接続している古いサーバーがあり、影響範囲の読めないsaの無効化も必要になった
• 構築担当者がDASの共有ストレージをiSCSIと勘違いし、WSFCの構築に手間取った
• 参照系DBサーバーの仮想マシンの仮想ディスクプロビジョニングがシンプロビジョニングになっていており、ディスクのオーバーコミット状態になっていた
• 仮想ディスクがシンプロビジョニングになっているせいで、ディスク拡張時に他の仮想マシンのパフォーマンスが悪化し、障害が発生した

移行元と移行先間のレプリケーションで発生した問題

• バッチがTruncateしているテーブルをアーティクルに入れてしまい、Truncateが実行できずバッチがこけた
• サブスクライバー側で再パブリッシュしているテーブルがあり、レプリケーションが失敗した
• 大量データ更新をしているテーブルがあり、ディストリビューターCPU使用率100%の状態が12時間続き、大規模なレプリケーション遅延が発生した
• 更新系の全テーブルをレプリケーションする必要あったためパブリケーションが大量に増え、ディストリビューターでメモリ不足が発生し、ディストリビューションエージェントが動作できなくなった
• レプリケーションが大量に増えた結果、sp_MSdistribution_cleanupが更新をブロッキングしてしまい、ディストリビューターのCPU使用率が100%になった
• 移行先環境のネットワーク構成の問題で、パブリッシャー->ディストリビューター->サブスクライバー間のネットワーク距離が遠く、レプリケーション遅延が常態化した

新参照系投入時の問題

• ユーザー権限が不足し、Railsアプリケーションでエラーが発生した
• 統計情報の更新をしていなかったため、クエリの速度低下が発生した
• 構築時期が古いアプリケーションが、新しいWindows Serverで追加された暗号化スイートに対応しておらず、接続エラーが発生した
• インデックスが既存参照系と比べて不足しており、本番投入後直ぐにCPU使用率100%になった

更新系切替当日の問題

• 更新系切替時に、アプリケーションからINSERTを行うと、PK重複エラーが発生し、全テーブル更新ができなかった
• リンクサーバーの作成漏れがあり、リンクサーバー経由でレプリケーション状況を確認しているアプリケーションが失敗した
• データベースメールの設定もれがあり、メール送信しているアプリケーションが失敗した
• 構築時期が古いアプリケーションが、新しいWindows Serverで追加された暗号化スイートに対応しておらず、接続エラーが発生した
• トランザクションレプリケーションができないDBは当日バックアップ＆リストアの予定だったが、リハーサル時よりの3倍時間がかかった
• DBの互換性レベルを一律同じ設定に変更したら、SQL Server2000時代から運用しているサービスでクエリの大幅なパフォーマンス劣化が発生した
• 無効化していたSQL Server JOBの有効化漏れがあったが、1ヶ月後に気がついた

思い出深い問題

発生した問題の中でも、思い出深いヤツの詳細を紹介します。

更新系切替時に、アプリケーションからINSERTを行うと、PK重複エラーが発生し、全テーブル更新ができなかった

これは、DBサーバー移設実施当日の午前3時、更新系DBの切替を行ってアプリケーションの動作確認が始まった時に発生した問題です。
新しい更新系DBのテーブルに、データがINSERTできませんでした。
「もしや移設失敗？」という、どんよりとした雰囲気になりました。

SQL Serverでは、レプリケーション先のテーブルの自動採番シード値がインクリメントされないと言う仕様に気がついていなかったんですね。
切替前までレプリケーションを受けるだけだった新更新系のテーブルの採番シードの値は、レプリケーションを構築した2ヶ月前の値だったため、INSERT時に採番される値のレコードが既に存在していたのです。

対応方法は直ぐに思いついたので、全テーブルの自動採番シードを、テーブル内のレコードの最大値に変更するクエリを書いて解決しました。
事前検証を漏らしたことが、非常に恥ずかしかったです。

移行元->移行先間のレプリケーションで、大量データ更新をしているテーブルがあり、ディストリビューターCPU使用率100%の状態が12時間続き、大規模なレプリケーション遅延が発生した

これが発生したのは、月初日でした。
現データセンターと新データセンターの更新系DBでレプリケーションを構築した、最初の月初日です。
月次バッチで大量にデータを更新しているテーブルがあり、ディストリビューターの処理能力の限界を超えてしまいました。

待つこと12時間でやっと遅延が解消しました。

月初に発生したため、月次バッチであろうとは見当がつきました。
が、月次バッチは動かす必要があるため、次の月末までに移転を終わらせると言う判断になりました。
とにかく今月中に移設しないと、また再発するという事が確定しました。

幸運だったこと

いろいろありましたが、移設は成功しました。
幸運にも恵まれたなと思います。
エンジニアが作業の成功を「運が良かった」と言うのもなんですが、どんなに綿密に計画をたてても、それは成功率を上げているだけなのかもなとも思います。

次の幸運に恵まれました。

• 既存ディストリビューターのハードウェアリソースに若干の余裕があった
• 更新系の移転当日、発生した大きな問題が1個しかなく、調べて直ぐに解決できた

既存ディストリビューターのハードウェアリソースに若干の余裕があった

レプリケーション方式の移転が実現できるかどうかは、ディストリビューターの処理性能にどの程度の余裕があるかにかかっていました。
これに若干の余裕があったのは幸運でした。

実際には、一度メモリー不足でレプリケーションが止まってしまったので、本当に若干の余裕でしたけど。

更新系の移転当日、発生した大きな問題が1個しかなく、調べて直ぐに解決できた

事前作業での抜け漏れが1つだったのは幸運でした。
切り戻しになっていたら、また月次バッチで大規模レプリケーション遅延の発生が必至でしたから。

まとめ

移転が終わって一年。次はクラウドへの移転が議論されています。
アイスタイルのインフラは今まさに変革期。
一緒に変革を担ってくれる仲間を絶賛募集中です！
募集職種はこちらをどうぞ。
ちょっとやそっとの失敗ではヘコまず、笑いの絶えない明るい職場です。

あと

もう一本カジュアルな記事も書いています。よろしければこちらもぜひ！
– はじめてのワーケーション