SKYDIV Desktop Client を支える技術の一つ、「SQL Server Express 冗長化」をご紹介いたします。
SQL Serverには上位エディション（Standard／Enterprise）で利用可能な「SQL Server Always On」という冗長化機能があります。
上位エディションということもあり、結構高価で高級な機能になっています。
そこまで高級な機能でなくてもいいからもっと安価であったら……
競合製品と比較して、大きなアドバンテージを得ることができますよね。
そこで、SKYDIV では無償で利用できる SQL Server Express Edition を使用する場合でも、Always On のような冗長性と信頼性を担保できるように、「SQL Server Express 冗長化」機能を独自に実装して、製品に搭載しています。
過去 4 回に渡って「SQL Server Express 冗長化」についてご紹介してまいりましたが今回で最後、通信の「リダイレクト」についてご紹介させていただきます。
シリーズ一覧
①システム構成編
②フェイルオーバー
③レプリケーション
④トランザクション編
⑤リダイレクト【今回の記事】
リダイレクトの前に
冗長化を構成するには「運用系」「待機系」の 2 系統が必要になります。
運用系で障害が発生した場合、待機系が運用系に切り替わって処理を継続することになります。
ではそのシステム上にある他のノードはどうやって運用系が切り替わったことを知るのでしょうか？
通常「運用系」「待機系」の手前にどちらのサーバーにリクエストを転送するかを決めるシステムを置きます。
ロードバランサーやリバースプロキシがそれに該当しますね。
通常、運用系と待機系のヘルスチェックを行って、その時の運用系にリクエストを転送します。
リダイレクト
リクエストの転送ではロードバランサーやリバースプロキシを手前に置く必要があります。
ということはそれだけコストがかかってきますよね……
目的は「運用系にリクエストを送る」こと。
ということは待機系に繋ごうとしたら運用系にリダイレクトされれば良いだけでは？
そこで SKYDIV では通信層にリダイレクトの機能を実装しています。
HTTP のリダイレクトと同じですね。
通信のたびにリダイレクトでは効率が悪いのでリダイレクトを指示されたら次からはそちらに接続する工夫をしています。
この仕組みのおかげで冗長化を組んでいるどこかに繋がれば適切な運用系サーバーを教えてもらえるようになります。 （万が一、待機系にデータベースを操作するリクエストが届いたとしてもそのリクエストをエラーとすることで整合性を守る工夫も忘れていません）
最後に
全5回に渡って SKYDIV の SQL Server 冗長化についてご紹介してきました。
フェイルオーバーで運用系と待機系の切り替えを行い
レプリケーションで運用系と待機系で同じデータを保持し
リダイレクトで運用系への接続を保証する
上記3つの要素を取り入れることで比較的シンプルな構成での冗長化が実現できました。
こうしてまとめてみると既存の考え方を組み合わせることで新たなサービスにつながることを実感します。
今回ご紹介した冗長化が規模や費用に応じて選択できる機能の一助となれば幸いです。
