일 때문에 늦바람 불어서 보기 시작한 Orleans에 대한 감상평

전통적인 의미의 마이크로서비스는 아니지만, 지금 고민하고 있는 시스템의 특성 상 따로 돌아가는 여러 시스템을 유기적으로 제어하고 통합하려는 일을 하려다보니 결국 마이크로서비스처럼 관리해야 할 상황이 된 것 같습니다.

그래서 그간 멀리서만 지켜보던 Orleans를 드디어 제대로 써 볼 결심을 하게 되었습니다. 애석하게도 온보딩 경험은 썩 좋지 않았는데, 그래도 알게된 점 몇 가지가 있어서 적어봅니다:

  • MS 공식 문서에 나온 내용만 따라가다보니 상당한 혼란이 있었습니다. 여기서 언급하는 온보딩 경험은 지나치게 단순화되어있다보니 오히려 Orleans를 이해하는데 방해가 됩니다. ASP.NET 스택이 꼭 있어야 하는 줄 알았네요. 실제 통신은 TCP로 일어나는데도 불구하고 말이죠!
  • Orleans라는 브랜드 네임을 쓰는 NuGet 패키지들 사이에 버전이 뒤섞여있다보니 처음에는 설명하기 어려운 오류도 만났습니다. 몇 번 시행착오를 거쳐서 어떻게 패키지 설치를 해야하는지 이제 감이 옵니다.
  • LINQPad의 설계 원칙이나 철학을 생각해보면 당연한 것이긴 한데, MSBuild/Source Generator 사용이 Orleans에서는 필수다보니 LINQPad 같은 환경에서는 테스트를 해볼 수 없어서 개인적으로는 무척 아쉽게 생각합니다.
  • Orleans를 프로덕션에 배포하고 사용할 때 핵심은 멤버십 프로바이더라고 불리우는 영속성 관리 수단 (주로 RDBMS나 Consul, Apache Zoo Keeper를 언급하는 것 같네요)과 Silo 사이에 네트워킹을 어떻게 할 것인지가 성능을 좌우하는 부분이 되는 것 같습니다.
  • "클러스터"라는 개념이 무엇인지 이해하는데 조금 어려움이 있었는데, 처음 띄우는 사일로가 클러스터를 만들고, 여기에 다른 사일로들이 미리 설정된 멤버십 테이블을 보고 사일로의 존재를 확인하여 TCP 연결을 수행하면서 클러스터의 파이를 키워나간다는 컨셉을 알 수 있었습니다.
  • Orleans 만을 위한 대시보드가 따로 있는 것 같습니다. SRE에 아주 중요한 부분인데 다행히 잘 구비되어있는 것 같습니다. (GitHub - OrleansContrib/OrleansDashboard: 📊 A developer dashboard for Microsoft Orleans)

시행 착오를 거치고나니 다시 제대로 아키텍처 설계를 해볼 마음이 듭니다.

포럼 회원 여러분들 중에서도 Orleans를 써보신 분이 계시다면 의견을 많이 여쭤보고 싶습니다.!

7개의 좋아요

오를레앙을 바로 이해하기 어렵지요.

Actor Model 중 프로덕션 레벨에서 성공한 프레임워크는 Akka이고 오를레앙과 매우 다릅니다.

3개의 좋아요

Event Sourcing 이라는 개념이 신선했습니다.
그전에 CQRS 부터 개념을 잡고가면 그나마 이해가 가더군요

물론 정현님 같은 분은 저보다 10배는 빨리 익히실듯
저도 실무에 적용해볼려다가 팀원들을 납득시키기 어려워 포기했습니다.
개인적으로 국내가 스프링 패턴 위주인것 같은데
여기서 한단계 더가면 CQRS 그 이상이 Actor model 같습니다.

3개의 좋아요

저거 프랑스식으로 읽어야 하는거였나요?ㅋㅋㅋ

3개의 좋아요