현대의 소프트웨어 아키텍처에서 마이크로서비스 아키텍처(MSA)는 그 유연성과 확장성 때문에 많은 개발 팀들이 선호하는 설계 방식이 되었다. 그러나 이러한 분산 시스템에서는 다양한 서비스 간의 상호 작용이 필요하며, 이 과정에서 발생하는 권한 검증 문제는 개발자들에게 상당한 도전 과제를 제시한다. 특히, Attribute-Based Access Control(ABAC)을 적용할 때, 이러한 문제는 더욱 복잡해진다. 이러한 문제를 해결하기 위해서 두가지 방법을 고안해보았고, 각각의 장단점을 판단하여 실제로 적용해본 사례를 공유하고자 한다.
Permission Service
Permission Service는 독립적인 권한 관리 서비스를 구현하는 접근 방식이다. 이 서비스는 Redis와 같은 캐시 시스템을 이용하여, 사용자와 장비 간의 권한 정보를 비동기로 관리하고 캐싱한다. 권한 검증 요청이 들어왔을 때 Cache Miss가 발생하면, Api Gateway 패턴과 유사하게 여러 마이크로서비스로부터 필요한 정보를 집계하여 최종적인 권한 정보를 제공한다.
장점
- 능동적 정보 수집: 필요한 권한 정보가 캐시에 없을 경우, 다른 서비스로부터 정보를 직접 요청하여 가져올 수 있다.
- 높은 가용성과 성능: 권한 정보를 캐시에 저장함으로써, 권한 검증 과정에서 발생할 수 있는 지연 시간을 줄일 수 있다.
단점
- 인터페이스 구현 필요: 각 서비스 간의 정보 교환을 위해 별도의 인터페이스를 구현해야 한다.
- 복잡성 증가: 여러 마이크로서비스와의 통신 및 데이터 집계 과정이 복잡해질 수 있다.
권한 관리 Infra Service
Google의 Zanzibar, SpiceDB와 같은 권한을 그래프로써 모델링하여 쿼리할 수 있도록 하는 서비스를 사용하는 방식이다. Entity간의 관계를 모델링함으로써 각 서비스에서는 적절하게 쿼리하는 방식으로 사용이 가능하다.
장점
- 구현의 용이성: 이미 구현된 서비스를 사용함으로써, 개발 과정에서 발생할 수 있는 복잡성과 시간을 줄일 수 있다.
- 중앙집중식 권한 관리: 모든 권한 관리 로직을 하나의 서비스에서 처리함으로써, 일관성을 유지할 수 있다.
단점
- 능동적 정보 수집의 한계: 외부 서비스에서 자동으로 정보를 업데이트하는 것이 어렵다.
- 인프라 관리 부담: 추가적인 서비스를 운영함으로써 인프라 관리에 대한 부담이 증가한다.
- 러닝커브: 데이터 모델링 언어를 학습하고 적용하기 위해서 추가적인 개념들을 학습해야 한다.
결정
권한 관리 Infra Service를 사용한다고 하더라도, 소유, 권한 부여 등의 권한을 판단하기 위한 핵심 정보는 명확한 관계형 DB에서 이루어져야 한다는 생각이 들었고, 이를 캐싱하여 빠르게 접근할 수 있도록 보조하는 관점에서 사용하는게 적합하다는 생각이 들었다. 아직 복잡성과 트래픽이 크지 않은 현 프로젝트에서 적용하기에 러닝커브의 단점이 크게 느껴졌고, Api Gateway 패턴으로도 충분히 구현이 가능하기에, 별도 서비스를 개발하기로 하였다. 어떤 사용자가 어떤 장비에 어떤 권한이 있는지를 미리 캐싱해두고 이를 빠르게 확인하여 응답할 수 있도록 하는 서비스를 구현하기로 하였다.
Permission Service 구현
현재 개발중인 서비스는 License 서비스에서 Organization에게 라이센스를 발급하고, Organization 서비스에서는 Member 각각에게 사용 권한을 부여하고 있고, 각 서비스는 이러한 관계를 통해서 특정 Member가 특정 Device에 어떠한 동작을 해도 되는지를 Query하게 된다. License 서비스와 Organization 서비스에 각각 사용 가능 여부를 확인받고, 이를 Redis에 캐싱을 하고 있다가 빠르게 응답할 수 있도록 구현하였다.
