1.はじめに
プラットフォーム事業本部のユーザーレビューグループの松井です。DMM.comのユーザーレビュー基盤を開発するチームでエンジニアをしています。
さて、今回はレビュー基盤の移行対応についてお話しします。レビュー基盤はAWSを使用した環境で構築されています。
しかしながらバックエンドとフロントエンドとでリージョンが分離されていたため、サービスを提供する際に余計な時間やコストがかかってしまうといった課題を抱えていました。
2.リージョン分離の課題
下記のような使用環境で、フロントエンドが「ソウルリージョン」、バックエンドが「東京リージョン」で稼働していました。
構築当時（2019年）のエンジニアに分離した理由について確認したところ、当時はAWSに詳しいエンジニアがおらず、分離した方がわかりやすいから、という理由のみでした。
しかしながらソウルと東京で冗長化のために分離されていたわけでないので、片方のリージョンで障害が発生すると全体が停止してしまいます。またDMMは国内ユーザーが主であるため、リージョンは東京で統一されることが適正です。
仮に国内のユーザーがユーザーレビューのサービスにアクセスする場合、一旦フロントエンドが置かれるソウルリージョンへ迂回してしまうため、余計な転送時間や転送コストが発生してしまいます。
このように分離するうえでのメリットがないことから東京リージョンに統一する取り組みを行いました。
3.意識したポイント
フロントエンドの東京リージョン移行にあたり意識したポイントをまとめます。
3-1.サービス区分を意識する
AWSのサービス区分には、以下のようなグローバルサービス、リージョンサービス、ゾーンサービスが存在します。
今回のリージョン変更により移行対象としなければいけないサービスは、リージョンサービスとゾーンサービスです。グローバルサービスは、東京リージョンでもそのまま使用できるため、移行対象にはなりません。
これらのサービス区分を意識し、移行対象となるサービスの洗い出しを行いました。
AWSサービス区分と位置関係
3-2.サービス無停止で切り替える
今回のリージョン移行にあたり、ユーザーレビューのサービスを停止せずに切り替えを行うために、以下の方法で対応しました。
A. サービス起動
まず東京リージョンにソウルリージョンと同様のフロントエンド環境のサービスを立ち上げます。
B. Route53による加重ルーティング
次に各リージョンのフロントエンド環境に対してRoute53による加重ルーティングを行います。
Route53には加重ルーティングという機能があり、ドメインに紐づけられているAWSのエイリアスレコードを重みに応じて分散することができます。例えばソウルリージョンのリクエストの割合は10、東京リージョンのリクエスト割合は90という形です。
Route53はグローバルサービスでありリージョン依存しないため、リージョンを跨いでサービスを提供することができるのです。
C.ルーティング重みの変更
加重ルーティングの重みの割合を徐々に変更し、東京リージョンの割合が100となった時点でソウルリージョンのサービスは削除して完了です。
まとめ
今回、既存サービスに影響を及ぼさないこと、無停止で切り替えることを意識したため、調査や対応方法を検討することに時間を要しました。
改善効果としては、フロントエンドからバックエンドのAPIを呼び出す際にレイテンシーが平均0.1～0.2秒ほど高速化されました。
フロントエンドから複数のAPIを一括で呼び出している場合は、その分改善効果が加算されるため効果としては大きいと言えます。
いかがだったでしょうか。今回は、我々のチームで行ったリージョン移行の対応をご紹介させていただきました。少しでも参考になれば幸いです。
