こんにちは、鎌田です。 今回、現地時間の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レベルの障害にも対応しています。
ユーザーアクセスと管理者アクセスをシステム的に分離し、書き込みが必要な管理者アクセスのみMasterへ、読み込みアクセスでOKなユーザーアクセスのみRead Replicaを利用
これは、アプリケーションレベルでの負荷対策です。
アプリケーション実装の際に、ユーザーアクセスと管理者アクセスを明示的に分離することで、 万が一MasterのDBが止まることがあっても、ユーザーがアクセスする読み込み処理が止まらないようにしておく、という構成となっています。
Read ReplicaはDBとして構成するのみでは駄目で、アプリケーション側でも、読み込みのみRead Replicaに逃がすような実装が必要です。 その点もしっかり対策されていました。
まとめ
- DBを構成する際は、障害対策・負荷対策の両方を十分に検討した構成とする
- インフラ構成のみでは対応しきれない点もあるため、アプリケーション実装も含めて対策を検討する
DB設計を考える上で、参考になれば幸いです。
