Rebuild Broker Architecture

再生速度

要約を読む

アクセス負荷が高くてコストが増えていたのが課題でした。そこで、Global DBを使わず、Brokerが直接共通DBに書込みと読み取りをできるように変更しました。その結果、サーバー数を減らし、月間コストは30％削減できました。元の設計では、複数リージョンにBrokerとSlave DBを配置していましたが、実際に使われた負荷はそれほど大きくなく、無駄なインフラが多かったことがわかりました。そのため、Global DBの必要性を検証した結果、使わなくてもよかったと判断し、R&W可能な設計に切り替えました。その変更後、Brokerが1つに集約できるようになったと気づきました。外部のサードパーティにリダイレクトURLを提供しているため、ドメインを変更するとその側も手間がかかるので、ドメインを変えずに移行できるようにしました。Route53のDNSを変更し、CloudFrontに接続することで、ドメインを変えずに移行が可能になりました。その結果、UserPoolからBrokerへの通信は10％遅れましたが、BrokerがDBと同じリージョンに配置されているため、全体のレイテンシーはほとんど変わりませんでした。これにより、サーバーの数を半分に抑え、月間運営コストはさらに15％削減されました。最終的に2段階の変更で、コストは全体で40％削減できました。今後も機能の見直しを続け、定期的にコストを下げていく計画です。

AI が生成した要約です。正確な内容は本文をご確認ください。

KINTO ID Platformチームの Xu Huang です。数年前から複数の国にユーザー認証認可システム（略称UserPool）を提供し、Brokerモデルを採用して複数地域のUserpoolを繋ぎ、お互いに認証認可情報を共有できるアーキテクチャを構築して運用していました。昨年からコスト削減活動の一環としてアーキテクチャの設計を見直し、移行を行いましたので、その変更内容について紹介したいと思います。
最初はGlobal展開の戦略でAWS Aurora Global Database(略称Global DB)採用し、アクセス負荷とレイテンシーを減らすためにSlave DBをUserpoolに近いところに配置してBrokerサーバーもSlave DBと同じリージョンに配置した運用にしていました。
（Global DB制約上MasterDB一つだけ、Slave DB最大五つまで許容）
上記の図に青枠に囲んだ地域に順次Userpoolサービスを提供し、ユーザーを一元化管理するために必要なユニークIDは集約したところから発行し、各リージョンのサブDBに同期して管理する方針で設計しました
 Phase 1 Global DB → Normal DBに変更し、書込み専用アプリ廃棄アクセス負荷を重要視した設計で複数のリージョンにサーバー配置しましたが実際運用上はまだスケールアップが必要なレベルまで至っておらずコストが余計に掛かっている状態でした。

適切な構成にする為に、検証評価したところGlobal DBの必要性がないと判断した為、直接Brokerから共通DBにR&W可能の設計に変更しました。
変更後のアーキテクチャの以下の図のイメージになります
 Phase 2 Broker一本化Phase 1 の対応でかなりコスト削減できましたがさらにコスト下げる検討し続け、Brokerが一つに集約できないかを検討し始めました。但し集約するには一つ課題あって、IDプロバイダーとしては外部サードパーティにもリダイレクトURL提示していてそれらが変更してしまうとサードパーティ側も合わせて変更作業発生するのでドメインを変更しない前提で移行できないか考えてみました。インフラチームにも協力してもらい、Route53にDNS設定を変更して向き先を新しい統合サーバーと繋ぐCloudFrontにスイッチしておけばドメインを変えなくてもいいと考えていました。
上記の図のような設計に変更すると、物理的にサーバー間通信の距離が離れているためUserpoolから集約したBrokerの通信にはレイテンシーどれぐらい影響あるかも気になって測ってみました。
結果はUserPoolからBrokerの通信は約10%遅くなりましたが、BrokerがDBと同じリージョンに配置したため速くなり、アーキテクチャ変更前後の全体から見るとあんまり変わらないため、Phase2の移行計画も立て進めてきました。
 成果：上記２段階でビジネスの実態に即して構成の最適化を行いました
今後は機能的なところも見直し作業継続して定期的にコスト削減の活動を行なって参ります。