#infra

MSA 환경에서 ABAC 기반의 권한시스템을 어떻게 구현하는게 좋을까요?

안녕하세요 현재 진행중인 프로젝트에 MSA를 적용하여 구현하고 있는 백엔드 꿈나무입니다. 빈번하게 일어나는 권한 검증을 효율적이고 높은 가용성을 확보할 수 있도록 하기 위해서 여러 방법을 모색하던 중, 다른 분들의 의견이 어떨지 하여 QnA를 올려보게 되었습니다. 우선 저희 프로젝트는 User, Device, Organization, Team, License 이렇게 5가지 개념이 있습니다. 사용자가 장비에 접근할 때에는 본인이 소속된 Org에 해당 장비가 존재하는지, 접근하는 동작에 대해서 해당 org가 License를 보유하고 있는지, 소속된 팀 또는 본인에게 해당 장비에 해당 동작을 승인받았는지 등 수많은 조건들에 의해 ABAC가 계산되게 됩니다. 하지만 MSA 환경으로 인해 테이블을 쉽게 join하지 못할 뿐더러, 가능하더라도 상당한 고부하 작업이 될 것이라고 생각합니다. 그래서 CQRS 패턴을 이용해서 license가 만료되거나 팀의 권한이 수정되는 등, 사용자와 장비간의 권한이 수정이 되는 command가 수신되면, 그것을 권한 담당 서비스에 비동기로 전달하여 특정 사용자가 특정 장비에 어떤 동작에 대한 제어가 가능한지를 저장(캐싱)하고 있다가 권한을 검사해야되면 간단하게 query하는 형태로 구현하는 것이 적합할 것이라고 판단했습니다. 이 패턴을 구현하기 위한 두가지 방법을 고안해보았습니다. [Permission Service] 별도의 permission 서비스를 만들고 캐시용도로 redis를 연결해두고, 권한 검사 요청이 들어왔을 때 Cache Miss가 된다면 Api Gateway 패턴과 유사하게 여러 서비스에 각각 정보를 요청하여 최종적인 권한 정보를 Aggregate 하여 전달하고, 캐시에 보관하는 방식입니다 [권한 관리 Infra Service] Google의 Zanzibar와 같이 권한을 관리하고 복잡한 쿼리를 처리해주는 서비스를 이용하는 방식입니다. 오픈소스로 구현된 SpiceDB를 고려하고 있습니다. Permission Service를 만드는 경우, 본인이 보유한 정보가 부족할 경우 능동적으로 정보를 Pull하여 권한 정보를 가져오는 반면, 양측에 별도 인터페이스를 구현해야되는 단점이 있고, 이미 있는 서비스를 사용하면 구현이 쉬워지는 반면, 해당 서비스에서 능동적인 Pull이 불가능하고, 권한 Query 정보가 최신인지 판단하고 업데이트하는 것을 각 서비스에서 각각 담당해야되기 때문에 별도 서비스를 분리하는 것에 비해 Responsibility Segregation이 부족하다고도 느꼈습니다. 무엇보다 관리해야될 인프라 요소가 늘어난 것은 덤이구요. 규모에 비해서 과한 고민을 하고 있는것이 아닌가 하는 생각도 들고, 그래도 더 나은 방법으로 서비스를 만들어가고 싶기도 합니다. ABAC를 적용하는 대부분의 서비스에서 이러한 고민을 적절히 잘 해결하여 서비스가 되고 있을텐데, 정답은 없겠지만 선배님들의 조언을 듣고 싶습니다!

레이어드 아키텍처의 추상화에 대한 질문입니다

뉴비 개발자, 레이어드 아키텍처의 추상화에 대해 약간의 질문이 있습니다. Repository 클래스와 application layer 클래스들의 추상화를 왜 하는가에 대해 가르침을 받고 싶습니다. 우리가 현재 추상화하는 이유가 기존 기능으로부터 추가적인 고객의 요구를 수정에 닫혀있는 채로 관리하기 위함이라면, infrastructure layer의 repository 클래스들과 application layer의 추상화는 해당 이유에 적합한 이유인가? 에 대한 의문을 갖게 되었습니다. 의존성 역전 법칙을 말그대로 따라간다면 추상화를 하는 것이 맞지만, 의존성 역전 법칙 자체가 의존성 관계를 뒤집어 수정의 가능성을 역전한다의 의미인데 인터페이스와 구현체 비율의 가능성이 1:1일 확률이 매우 높은 상황에서 수정의 가능성을 뒤집는다는 것 자체가 약간 이론에 놀아나는 느낌? 이게 진짜 역전되있는 것이 맞는가? 하는 그런 생각이 들었습니다. 그래서 repository 클래스들를 추상화 할거면 application layer도 추상화 하는 것이 이론상 맞고, application layer를 추상화하지 않을거면 repository 클래스도 추상화하지 않는 것이 내가 이해한대로면 맞다. 로 결정하게 되었습니다. 추상화가 테스트때문이라면 요즘 모킹 라이브러리 잘되어있는데, 라이브러리에 대한 의존성을 제거하기 위해 그런가? 라는 생각도 조금 들었습니다. 제가 나아가고 있는 논리의 방향이 맞는지가 의심스럽고 조심스럽습니다. 선배 동기분들의 가르침을 받고 싶습니다. 읽어주셔서 감사합니다.

exe파일에서 DB가 돌아가는 원리가 어떻게 되는건가요?

파이썬에서 Designer로 간단한 프로그램을 만들었는데 현재는 db 정보를 pymysql.connect(host='127.0.0.1', user='root', password='1234', db='infra', charset='utf8') 이런식으로 불러오고 있습니다. 하지만 프로그램을 다 만들고 든 생각이 다른 DB연동된 소프트웨어들을 보면 내 컴퓨터에 아무것도 안깔려있어도 데이터 정보를 생성, 수정, 삭제할수 있네? 어디에 저장하는거지? 였습니다. github에서 다른분이 만든 작은 프로젝트를 봤는데 이 프로젝트에는 .db라는 파일이 있던데 이 파일은 어디서 만드는 것이고(mysql? pycharm?) 데이터가 많아져서 용량이 방대해지면 어떻게 되는지 궁금합니다. 구글에서 찾아봐도 전부 본인컴퓨터 DB와 연동하는 내용뿐이네요ㅠㅠ

신규 사업관련 Spring 개발 트랜드

요즘 웹서버 프로젝트를 진행을 하게되면 개발방식이 어떤식으로 진행되나요? 질문의 의도 - 신규 구축 사업협의때 필요한 개발현황 사전조사와, 신규채용(신입포함)에 있어서 필요한 정보를 확인해보고자 올립니다. 주요 요건 - 기존 Regacy 스프링이 서비스가 되고있는 상태인데 신규 사업을 진행 후 해당 서비스를 추가할 것이다. 1. View 단의 트랜드 스프링 부트에서 권장하는건 Thymeleaf 로 알고있습니다. 저 또한 Java로 개발을 할때에도 그렇게 했습니다만.... 요즘은 어떠한지 궁금합니다. 2. Mabatis, JPA ? JPA는 현재 사용하지는 않아서 잘 모르는 상태입니다. 이 두가지의 트랜드를 알면 Infra관련 사전 협의는 될 것 같습니다. 의견좀 부탁드립니다. 단어만 적어주셔도 검색은 저가 해보겠습니다.