본 코너는 내가 만들고 있는 서비스와 연관된 기록이 올라가는 곳이다.
(현재는 서비스 이름이 마스킹 처리 되어 있지만(e.g. ** ** ***)
출시 후에는 마스킹을 벗길 거다.)
주요 문서는 비공개지만 나머지는 다 공개다.
아키텍처 패턴을 뭘로 정하면 좋을까?
주요 고려사항
- 사용자 수: 많은 사용자가 동시에 사용할 가능성이 있는가? > 그럴 가능성이 낮다고 생각한다.
- 데이터 일관성: 데이터 일관성이 중요한가? (예: 결제 처리) > 중요하다.
- 확장성: 시스템이 얼마나 확장 가능해야 하는가? > 최대한으로.
- 유지보수성: 코드의 유지보수와 확장이 얼마나 쉬워야 하는가? > 최대한으로.
- 복잡성: 시스템의 복잡도를 어느 정도로 관리할 수 있는가? > 상중하 중 중.
추천 아키텍처 패턴: 마이크로서비스 아키텍처 (Microservices Architecture)
이유:
- 데이터 일관성:
- 마이크로서비스 아키텍처는 서비스 간의 명확한 경계를 설정하여 데이터 일관성을 유지하기 쉽게 만듭니다. 예를 들어, 결제 서비스는 결제와 관련된 모든 데이터와 로직을 관리할 수 있습니다.
- 확장성:
- 각 서비스가 독립적으로 배포되고 확장될 수 있으므로, 특정 서비스에 대한 수요가 증가할 때 해당 서비스만 확장할 수 있습니다.
- 유지보수성:
- 코드가 모듈화되어 각 서비스가 독립적으로 개발, 배포, 유지보수될 수 있습니다. 이는 코드의 복잡성을 줄이고 유지보수를 용이하게 만듭니다.
- 복잡성:
- 초기 설정과 관리가 다소 복잡할 수 있지만, 장기적으로 시스템의 복잡도를 효과적으로 관리할 수 있습니다.
레이어드 아키텍처로 시작했다가 나중에 필요 시 확장하는 것도 생각해 봤는데
일을 두 번 하게 될 것 같아 처음부터 이걸로 시작한다.
더 많은 기록을 공개하고 싶었는데 생각보다 비공개로 돌려야 할 내용이 많아서
이 글을 여기서 끊는다.