← プロジェクト一覧へ
ビジネスサービス
設定 & アクセス制御サービス
テナント設定、ドメイン管理、優先度ベースの許可/拒否エンジン
初版作成者 · ルールエンジンを再構築 · 2024年3月 — 2026年6月
Go go-zero gRPC MySQL/GORM Redis Kafka
概要
プラットフォームとテナントの設定：ドメイン、バナー、バージョン、テナント設定、アクセスルール。初版を書き、独立したサービスとして分離し（分離時点で 42 RPC）、2025年にアクセス制御ルールを単一のエンジンに再構築した。
アーキテクチャ
ゲートウェイミドルウェア → 設定 gRPC サービス → ルールエンジン（アカウント・ニックネーム・IP による許可リストが優先。拒否ルールはアカウント、ニックネーム、IP、IP の所在地、銀行カードを組み合わせてマッチ）→ テナント別 Redis ハッシュ → ミス時は MySQL。
主な技術ポイント
01
旧来の2つの許可/拒否リストを、5つのマッチ次元を持つ優先度ベースの単一エンジンに統合。ルールを読み込めない場合はアクセスを拒否
02
テナント別の TTL 付き Redis ハッシュからルールを提供し、DB へのフォールバックは singleflight で保護
03
既存ルールを一度限りの SQL マイグレーションで新テーブルへ移行（CSV → JSON 配列）
04
テナントのドメイン管理：リンク検証、Redis セットによる一意性チェック、手動キャッシュ再同期
05
コンテンツカテゴリ別のバナー配信対象指定と、接続中クライアントへの Kafka 変更イベント
コア実装
1
統合ルールエンジン
アクションと優先度を持つ1つのルールテーブル。リクエストごとにメモリ上で正規化・評価し、ログ用にどの次元がマッチしたかを返す。
Why: 別々のコードパスを持つ2つのリストはエッジケースで結果が食い違っていた。明示的な優先度を持つ1つのエンジンの方が、理解も監査もしやすい。
技術的意思決定
| 技術的意思決定 | 選択 | 代替案 | 理由 |
|---|---|---|---|
| ルールキャッシュの構成 | テナントごとに1つの Redis ハッシュを持ち、メモリ上で評価 | 次元の値ごとに1つの Redis キー | テナントごとのルールセットは小さい。テナント単位で1回取得する方がシンプルで、多数のインデックスキーの整合性を保つ必要もない。 |