# 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I
初めまして、 @takano-hi です。 2023年2月に AlphaDrive にジョインして、主にフロントエンド領域を中心に設計・実装などの業務を担当しています。 最近、Next.js のプロジェクトを新たに立ち上げる機会があり、せっかくなので App Router を採用しました。 そのプロジェクトの認証機能の実装に当たり、今まで他プロジェクトでも利用していた Keycloak と @auth0/nextjs-auth0 の組み合わせを試したところいくつかの困難に遭遇したので、その解決方法についてまとめようと思います。 環境 next v13.4.9 @auth0/nextjs-auth0 v3.1.0 keycloak v20.0.1 ライブラリの選定背景 私が所属しているチームでは、認証基盤(IDプロバイダー)に Keycloak を利用しています。 Keycloak は Op
SaaSサービスをRailsで開発するにあたり、マルチテナントに関する情報収集をしたため本ページにまとめとして記録いたします。 DBのマルチテナント DBのマルチテナントにあたっては、セキュリティーの確保と保守性が方式の選定ポイントとなります。 ただし、SaaSサービスとして成功するほど保守のコストが増大するためプール型に移行していくようです。 ブリッジ型でマルチテナントを実現可能なGem「apartment」 データーベースのインスタンスは全テナントで共有するものの、テナントごとにスキーマ(テーブル、インデックス、ビュー、ストアドプロシージャ)を分ける方式です。 この実装にはGem「apartment」の使用が有名です。 SmartHR社も創業当初はセキュリティーを高めるためにapartmentを利用していたようです。 ただし、後述するように、サービスの特性上カラム数が多く契約社数の伸び
こんにちは、カート決済SREブロックの飯島と、ECプラットフォーム基盤SREブロックの織田です。 本記事では複数チームで運用する共通のAWSアカウントとKubernetesにおけるコストの可視化についてご紹介します。 背景 コスト可視化に対する課題 課題解決へのアプローチ AWSリソースのコスト可視化 AWSコスト配分タグ タグの定義と運用ルール タグの付け方 AWS Cost Explorer AWSコスト配分タグの活用例 Kubernetesクラスタのコスト可視化 Kubecost 比較検討 カスタムバンドル採用の決め手 アーキテクチャ 可視化の仕組み ダッシュボード 効果 コスト可視化の活用事例 最後に 背景 現在、ZOZOTOWNはモノリスなサービスを機能ごとに分け、マイクロサービスに移行しながらモダンアーキテクチャへのリプレイスを実施しています。マイクロサービスの移行先としてクラ
Amazon Web Services ブログ 閉域網でのマルチテナントアプリケーションテンプレート 一般的な SaaS におけるテナント分離戦略や実装例は、AWS ホワイトペーパー SaaS アーキテクチャの基礎 や builders.flash の記事「 SaaS on AWS を成功に導くためのポイントとは ? 」や AWS Well-Architected フレームワーク SaaS レンズ において紹介されています。 最近では、地方公共団体や医療等の高いセキュリティレベルが求められる業界にクラウドが普及してきたこともあり、閉域でのマルチテナント設計のニーズも増えてきています。例えば、自治体の基幹システムの実装では総務省が示す「地方公共団体における情報セキュリティポリシーに関するガイドライン」及びデジタル庁が示す「地方公共団体情報システム非機能要件の標準」に準拠したセキュリティ対策を
いわさです。 先日、クラスメソッド開催のイベント DevelopersIO 2023 札幌で、『AWS の「SaaS レンズ」を使って、堅牢でコスト効率の良いマルチテナント SaaS アプリケーションを設計しよう』というタイトルで登壇しました。 AWS Well-Architected Framework のレンズのひとつである「SaaS レンズ」について、実際にプロダクトで使ってみた所感などを交えながら紹介させて頂きました。 一言でまとめると「SaaS やるならとりあえず使ってみろ」という感じなので、是非使ってみてください。 資料 参考ページ SaaS Lens - AWS Well-Architected Framework SaaS ジャーニーフレームワーク SaaS microservices deep dive: Simplifying multi-tenant developm
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Kubernetesのマルチテナントパターンの種類 マルチテナントパターンをArgoCDで実践する場合にオススメのパターン (★) ArgoCDのNamespacedスコープモードとClusterスコープモード ArgoCDのテナントが防いでくれる誤った操作の具体例 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます! この記事から得られる知識 01. はじめに 02. なぜマルチテナントが必要なのか シングルテナントの場合 マルチテナントの場合 03. Kubernetesのマルチテナントパターン マルチテナントパターンの一覧 Clusters as-a-Service Control Planes as-a-Service Namespaces as-a-Service カスタムリソ
こんにちは!Nstockのじゃがです。 NstockではマルチテナントSaaSを開発しており、テナント間のデータ分離にRow-Level Security(RLS)を利用しています。本記事ではRLSの基本から、Nstockでの利用イメージまで、SQL文やアプリケーションコードを交えて解説します。 備考 アプリケーションの実装イメージはSpring Bootですが、多くのフレームワークに存在する機能を利用しています PostgreSQLのRLSについて話しています マルチテナントアーキテクチャとRLS Nstockは初期フェーズであり、人的リソースや金銭的リソースに余裕がありません。テナントごとに異なるDBサーバーやスキーマを用意するアーキテクチャは、リソース的に厳しいです。そのため、複数のテナントでDBサーバーを共有しつつ、 tenant_id カラムを用いてテナント間のデータを分離するこ
Amazon Web Services ブログ Amazon SES でのマルチテナント実装方法 この記事は、How to implement multi tenancy with Amazon SES を翻訳したものです。 このブログ記事では、Amazon SES でマルチテナントを設計する方法と、下流の顧客 (downstream customers / 本記事では「下流の顧客」と表記しています) に対するメール一括送信処理に効果的に対応できるマルチテナントアーキテクチャを実装するための基本的なベストプラクティスについて説明します。 Amazon Simple Email Service (SES) は、様々な業界のお客様が受信者にメールを送るために活用されています。多くの場合、下流の顧客や他の事業部門に代わってメールを送信する必要があります。多くの組織 (マルチテナント運営者) では
[ワークショップ] マルチテナント要件を達成するためのデータストアの分割方法を学ぶ「Build a multi-tenant SaaS solution using AWS purpose-built databases」に参加しました(DAT402) #AWSreInvent いわさです。 AWS re:Invent 2023 のワークショップである「DAT402: Build a multi-tenant SaaS solution using AWS purpose-built databases」に参加してきました。 AWS には SaaS on AWS というカテゴリがありまして、主にマルチテナントを考慮してアーキテクチャーを最適化する必要があります。 その中ではアプリケーションだけでなく、データストアに対しても様々な要件からテナント分離性を高めることがあります。 この記事ではワ
Amazon Web Services ブログ Amazon S3 におけるマルチテナント SaaS データのパーティション化と分離 この記事は、Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 を翻訳したものです。 多くの software-as-a-service (SaaS)アプリケーションはマルチテナントデータを Amazon Simple Storage Service(Amazon S3) に保存しています。Amazon S3 にマルチテナントデータを配置するには、バケットとキーにテナントデータをどのように分散させるかを考える必要があります。それは、SaaS ソリューションのセキュリティ、管理性、パフォーマンスを損なうことなく行う必要があります。 この記事では、Amazon S3 でテナントデータを
各テナント 300 秒間に 10 回までしかアクセス出来ないようにします。 なので user1 が 10 回リクエストを送信すると、tenant1 の user1 と user2 は一定期間はリクエストに失敗するはずです。 一方でその間にも別のテナントである tenant2 の user3 はアクセス出来るはずです。 今回リクエストテストは API Management のテスト機能を使いました。 各ユーザーの JWT は事前に払い出しておき、テストパネルから Authorization ヘッダーに設定します。 試しに user1 でリクエストを送信してみると、次のようにポリシーが動作している様子が確認出来ました。 API Management のトレース実行機能を使ってるのですが、これめちゃくちゃ良いな...! rate-limit-by-keyのところでtenant1が抽出されており、
tl;dr クライアントサイドキャッシュを使うことでクライアント間でデータが混ざることなくサーバーサイドでフェッチを行うことができる 背景 前回の記事の悩みセクションにある通りです。 apollo client でもサーバーサイドでフェッチしたいという願いでした。 悩み RSC 内でフェッチするとキャッシュがクライアント間で共有されてしまう -> クライアント間で共有はしたくないが、サーバーサイドフェッチしたい。かつ、どこかにデータフェッチの結果をキャッシュしたい。 解決策 クライアントサイドキャッシュでクライアント側でページごとのキャッシュを持つ 解説 クライアントサイドキャッシュとは 今回の肝はrouter cacheです。 (router cache はクライアントサイドキャッシュとも呼ばれます。この記事ではサーバーとの比較で分かりやすいので、クライアントサイドキャッシュと呼んでいま
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: “Fair” multi-tenant prioritization of Sidekiq jobs—and our gem for it!—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2024/02/14 原著者: Andrey Novikov(バックエンドエンジニア)、Travis Turner(技術記事編集者) サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。 はじめに 多くのバックエンドアプリケーションのマルチテナ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く