アクティブgeoレプリケーション（Azure）
SoftwareDesign 2018年8月号より
スマホゲームはなぜ動く？意外と知らないサーバサイドのしくみ
こういう話はやっぱり好きです。
世の中色んなシステムがありますが、ゲームや大規模MMOのほうがシステム的に最先端かつ柔軟性のある作りをしているんじゃないかと思っています。いつか、そういうところでも働いてみたいなぁ。
雑誌には以下のようなシステム構成にCDNを追加したような仕組みになっておりました。 スマホゲームも企業のWEBサービスもサーバ構成はほとんど一緒ですね。
このシステム構成を見てふと疑問が
APIサーバからどうやってマスタースレイブのDBを使い分けているのか
更新処理なのかリードオンリーなのかで使い分けるという概念的なものはわかるが、インフラで吸収しているのかアプリケーションにハードコーディングしてしまっているのか。
こちらのサイト*1にはこのような記載があります。
アプリケーションの接続文字列はMasterとSlaveで違うので切り替える必要があります。
仮に下記図1のような両リージョンを利用するACT-ACT構成だったとすると、以下★のような考慮点が必要になるはず。 災害発生時に、DNSとかでうまいことやってくれると手動対応いらないのにな。質問できる機会があれば聞いてみよう。
それともTrafficManagerかLoadBalancerでPOSTリクエストのみ、Primaryサイトに飛ばすようにしてるのかな。 たしかにそうすれば、リージョンが切り替わるまでSecondaryのWriteアプリは稼働することないから被災時の設定変更が必要なくなる…？！( ﾟДﾟ)
Primary Region
- Writeアプリケーションは、Primary RegionのDBを参照
- ReadOnlyアプリケーションは、Secondary RegionのDBを参照
Secondary Region
- Writeアプリケーションは、Primary RegionのDBを参照（★）
- ReadOnlyアプリケーションは、Secondary RegionのDBを参照
（★）被災時にSecondary RegionのDBを参照するための設定変更
