OneLoginのDB構成の話

こんにちは、鎌田です。今回、現地時間の9月25日、10月3-4日にそれぞれ行われる、以下のカンファレンスに参加するため、サーバーワークスから、3名海外出張に行っています。

【onelogin connect 2019】【BoxWorks 2019】

今回出席カンファレンスの中で、OneLoginのDB構成が興味深かったので、ご紹介します詳しいカンファレンスの内容は、宮澤のブログが以下2本公開されておりますのでご覧ください。

[現地直送便] サンフランシスコ出張記 OneLogin Connect19 Report1 [現地直送便] サンフランシスコ出張記 OneLogin Connect19 Report2

そもそもOneLoginとは

今回のブログで紹介するOneLoginとは、IDaaS(IDentity as a Service)とも呼ばれる、ID管理のSaaSです。各種サービスとSAML連携することもできます。各種サービスのログインのHUBとして使うことができるサービスとなっています。宮澤のブログで紹介していますので、細かい紹介はそちらをご覧ください。

さて、そのOneLoginのDB構成とは

ID管理のサービスです。止まってしまったら、各種サービスへのログインのHUBとして使っている場合、ログインが出来なくなり一大事です。このため、最低でもログインは出来るような構成を検討しておかなくてはなりません。

みなさんは、どんな構成を考えられるでしょうか？

私の方で、資料から書き直した構成図はこちらです。

どんなDB構成なのか？

DB構成としては、以下4つの特徴があります。

Masterに対してActive Standayを2つ用意。状況によってRegionをまたがってMasterをFailOverできる構成としておく。
Read Rplicaを用意し、3つのAZに配置。
Read Replicaを別リージョンにも用意しておく。
ユーザーアクセスと管理者アクセスをシステム的に分離し、書き込みが必要な管理者アクセスのみMasterへ、読み込みアクセスでOKなユーザーアクセスのみRead Replicaを利用。

それぞれ見て行きましょう。

Masterに対してActive Standayを2つ用意。状況によってRegionをまたがってMasterをFailOverできる構成としておく

こちらはMasterに対しての障害対策です。

Masterが障害になってしまった場合、まずはAZの中でFailOverできるように、Active StandbyのDBを用意しておきます。さらにRegionレベルの障害にも対応するため、別リージョンにもMasterを用意しておく、という訳です。これで、AZレベルの障害にも、Regionレベルの障害にも対応できます。

Read Rplicaを用意し、3つのAZに配置

Read Replicaを別リージョンにも用意しておく

こちらは、Masterに対しての負荷対策です。

Masterに対して読み込み/書き込みすべてのアクセスが集中すると、MasterのDBに負荷が掛かってしまいます。 Read Replicaを用意することで、IDaaSのユーザーアクセスでは多くなる読み込みの処理をMasterからオフロードできます。 Read Replicaを各AZに配置することで負荷分散を実施しつつ、AZの障害に対応しつつ、 Read Replicaを別リージョンにも用意することで、Masterと同じRegionレベルの障害にも対応しています。