오늘은 아침 독서로 이벤트 기반 마이크로 서비스 구축 책을 읽었다. 저번주 금요일날 집에 도착하고서, 가족행사, 프로젝트 공부 및 다른 공부를 하다보니.. 오늘이 되서야 읽을 수 있었다.
TMI를 조금 곁들인다면, 이 책은 처음이자 마지막으로 중고로 책을 구매한 책이다. 왜 처음이자 마지막이냐면, 중고 거래에서 최상이라는 조건으로 구매를 했지만, 와서 보니 꾸깃꾸깃.. 접혀있고, 뭐가 묻어있고 했다..(지금은 다닦고.. 주말동인 다른 책들로 눌러놓았더니 조금 나아졌다.) 그래도 책의 내용은 너무 맘에들어서 괜찮다.
EDA 를 처음 알게된 것은 소프트웨어 아키텍처101 책을 읽으면서 알게되었다. 당시에는 이벤트 기반 아키텍처에 대해 관심이 크게 없었는데, 계속해서 공부하고, 내가 어떤 프로그램을 설계하고, 개발하고 싶은지에 대한 고민을 하게되면서, EDA 에 관심이 크게 생기게 되었다.
아래 링크는 내가 소프트웨어 아키텍처101 의 EDA 부분을 읽고서 책의 내용을 정리해둔 것이다.
GitHub - KEEMSY/STUDY: 공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공간입니다. 잘못된 부분
공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공간입니다. 잘못된 부분은 이야기해주시면 감사하겠습니다 :) - GitHub - KEEMSY/STUDY: 공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공
github.com
나는 왜 EDA 를 공부하게 되었을까? 이것을 이야기하려면, 내가 목표하는 바를 먼저 이야기를 해야한다.
나는 궁극적으로, 개발기술 중심의 개발이 아닌 비즈니스 중심의 개발을 하고싶다. 그리고 이를 위해 먼저 DDD(Domain Driven Design, 도메인 주도 설계) 가 필요하다 생각하고, 해당 부분을 공부하게 되었다. 거대한 프로젝트 내 도메인 에 따른 시스템 설계를 통해 기술관점 보다 비즈니스 측면에서 개발할 수 있을 것이라 생각하기 때문이다.(좀 더 복잡하지만, 요약하면.. 이러하다.)
그리고 DDD에 효율적인 아키텍처를 고민하게되었다. 가장 쉽고 편하고, 대중적인 Monolithic 아키텍처는 내가 생각한 DDD의 이점을 모두 가져가지 못한다고 생각하여, 내 목표로 선택되지 못했다. 사실 당연하다. Monolithic 은 편리하지만, 한계점이 분명하게 존재한다. 시스템의 규모가 커지면 커질 수록, 시스템의 규모도 커지고 더 복잡해진다. 내가 생각하는 Monolithic 의 가장 큰 문제는 모호한 경계 라고 생각한다. 사실 Monolithic -> Micro Service 로의 전환이 어려운 가장 큰 원인이 이것 때문이라고 생각한다. 경계가 모호하여, 얽히고 얽힌 시스템과, 어느부분에 속하는건지.. 모호한 경계 떄문에 어설프게(잘못) 서비스가 나뉘어 지거나, MSA으로의 전환을 포기하게 될 것이라고 생각한다. 하지만 이 문제를 DDD는 해결할 수 있다.
DDD 를 준수하면서, Monolithic 의 모호한 경계를 분명하게 함으로써, 한계점을 극복할 수 있다. 그럼 Monolithic 을 선택하면 되지 않느냐? 아니다. 내 생각에 Monolithic 은 최종 목적지가 될 수 없다. 내 궁극적인 목표인 비즈니스 중심의 개발을 한다고하면, 다음과같은 아키텍처 특성이 고려되어야한다.
가용성(Availability), 성능(Performance), 신뢰성(Reliability), 확장성(Scalablity), 신장성(Extensibility), 유지보수성(Maintainability) 등 이 고려되어야한다.
아키텍처 특성을 고한 시스템을 이야기한다면, 시스템은 안정적이며, 내부 장애가 발생하더라고, 시스템의 사용이 보장이 되어야한다. 유저 수 및 요청 수가 늘어나더라도 고객이 만족할 성능이 보장되어야한다. 새로운 기능이 추가됨에 있어 유연함이 있어야하고, 기존 및 신규 기능의 유지보수가 편리해야한다.
이러한 아키텍처는 Monolithic 아키텍처에서는 불가능하다. 정확히는 가능하지만, 너무나 비효율적이다.(만약 내가 돈도, 자원도 무한하다면 그래도 안할것이다.) 그래서 효율적이면서, 해당 목표를 달성할 수 있는 아키텍처로 내가 선택한 것은 MSA 이다. 개인적인 생각에는 결국 모든 서비스는 MSA로 향할 수 밖에 없다고 생각한다. MSA는 개발을 비즈니스적으로 접근하는데 있어서 너무나도 아름답다.(잘만한다면) 결국 MSA 와 DDD 와 함께라면, 내가 바라보는 이상적인 아키텍처 기반의 시스템을 개발할 수있다.(N형 인간의 상상으로 그렇다. 상상만으로 군침 줄줄..)
하지만 Monolithic -> MSA로 전환하면서, 분명한 트레이드 오프가 존재한다. 그리고 그 중 가장 큰 트레이드 오프는 성능(Performance)이라고 나는 생각한다. 사실 성능은 포기할 수 없는 부분이다. Monolithic 에서 성능이 좋고 MSA에서 성능이 무조건 나쁘다? 라고 말하는 것이 아니다. 분리된 서비스(MSA)의 통신 은 기존 Monolithic 에서는 존재하지 않던 새로운 부분이다. 내부에서 빠르게 이뤄지던 동작이 요청을 보내고 응답을 받아야한다.(동기식) 이것은 결국 자원과 시간이 든다.(이것이 성능저하부분이라 생각한다.) 사실 나는 얼마만큼 성능이 저하될지 구체적인 수치를 이야기할 수 없다. 하지만 나는 분명하게 이 부분때문에 성능저하가 상대적으로 발생할 것이라고 확신한다. 트레이드 오프인데 당연히 어쩔 수 없지.. 하는 마음이라면 이제 EDA 를 알게되면서, 눈이 번뜩이게 될 것이다.
배경 이야기가 너무 길어졌지만, 이 때문에 나는 EDA를 공부하게 되었다. MSA 의 가장 큰 문제(주관적)라 생각하는 성능 부분을 해결할 수 있다 생각했다. EDA는 성능 문제를 어떻게 해결할 수 있다는 것일까? 그 답은 바로 이벤트(Event)기반의 통신구조 라고 이야기 할 수 있다. EDA의 통신구조는 기존 구현-데이터 통신 구조의 대안으로, 이벤트 스트림을 통한 통신을 이뤄낸다. 그리고 이는 비동기적으로 이뤄진다. 즉 요청-응답(API)를 거치는 것이 아닌, 이벤트를 발행하고(Publish), 소비(Consume)을 통해 통신을 이뤄 내는 것이다. 비동기통신이 왜 빠른가? 에 대한 것은 다른 주제이니 간단하게만 이야기한다면, 동기요청은 응답을 기다려야 하지만, 비동기 요청은 응답을 기다릴 필요가 없다. 그래서 빠르다.
따라서 나는 EDA를 공부하고싶어 이 책을 구매했고, 오늘 너무나도 설레고 재밌는 마음으로 책을 보기 시작했다. 그리고 나와 같은 목표를 가진 사람들 혹은 EDA를 공부하는 사람들과 함께 이야기하며 공부하고 싶다는 생각이 들었다.(같이 공부하실분.. 이야기하실분... 있으실까요...?) 꾸준하게 공부하고 기록해야겠다.
gradle-avro-pluginPublic 사용기
GitHub - davidmc24/gradle-avro-plugin: A Gradle plugin to allow easily performing Java code generation for Apache Avro. It suppo
A Gradle plugin to allow easily performing Java code generation for Apache Avro. It supports JSON schema declaration files, JSON protocol declaration files, and Avro IDL files. - GitHub - davidmc24...
github.com
신발 주문 시스템을 개발하면서, 나는 EDA를 접목시키기로 결정했고, 나는 이벤트 버스로 Kafka 를, 직렬화 도구로는 Avro를 사용하기로 결정했다. 그리고 나는 빌드 시, .avsc 파일 을 통해 Avro 클래스를 자동 생성하도록 하는 플러그인을 사용하고자 하였다.
gradle-avro-plugin 은 사실 공부를하면서, maven-avro 를 통해 사용해보면서, gradle 프로젝트에서는 없을까? 하는 생각에서 찾아보게 되었다. 빌드 시, Avro 클래스를 생성해주는 것은 너무나도 편리한 부분이라고 생각해서 포기할 수가 없었다.(포기하고싶지않았다.)
하지만 사용간 문제가 발생했다. build 가 되질 않았다. 깃허브 readme 를 참고해서 설정했지만, 되질 않았다. 문제의 원인은 아직 확실하게 식별하지 못햇지만, 내가 파악한 원인은, 버전의 문제 및, task 선언의 문제이다.
나는 해당 버전 문제를 해결하기 위해, 다른 사람들의 사용 사례를 찾았다. 하지만 전부 다 나는 해결되지 않았다. 어느 버전 문제에서 문제인지 정확히는 모르겠다... 실제 버전 관련 문서에서는 존재하는 버전이였는데, 해당 버전으로 설정하고 빌드 했을 때 해당 버전이 존재하지 않는다는 에러가 발생했다. 그래서 거의 모든 예시에서 본 버전으로 했는데 하나가됬다..(머쓱) 그래도 이 문제는 해결해서 다행이다. 하지만 다른 문제는 빌드를 했는데 해당 Avro 클래스가 생성되지 않았다는 것이다.
그래서 이건 문제가 분명하다.. 버전을 최신버전으로 바꾸고, task 선언 부분을 수정했다.
해당 부분또한 다양한 사용 사례를 공부하면서 찾아본 모든 내용을 적용해보았었다. 하지만 해결되지 않았고, 나는 공식문서를 천천히 하나하나 다시 보기 시작했고 해당 설정 부분을 확인할 수 있었다.
드디어 나는 문제를 해결했다. 하지만 내가 원하는 최종 방향은 아니였다. 나는 생성되는 파일들이 특정 폴더에 존재하기를 바랬다. 하지만 이는 설정으로 해결되지 않았다.
생각과는 전혀 다른 결과가 나왔지만, 이게 최선이었다... 그래서 나는 차선책으로 해당 클래스를 사용하는 파일에서 경로를 생성된 경로에서 import 하는 것으로 마무리 지었다.
코틀린 공부
요즘 프로젝트에서 예상하지 못한 문제들이 자꾸 발생하면서, 계속해오던 코틀린 공부를 하지 못하고 있다. 그래도 오늘은 잘 해결이 되어서 코틀린 공부를 다시 이어갔다. 내가 공부한 내용은 Class 와 관련된 내용이다. 다시 복습한다는 생각으로 작성하기보다는.. 공부한 것을 다시 보는게 좋을 것같아 공부한 링크를 기록한다.(귀찮은거맞다..)
https://github.com/KEEMSY/STUDY/blob/Language/Language/Kotlin/class.md
GitHub - KEEMSY/STUDY: 공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공간입니다. 잘못된 부분
공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공간입니다. 잘못된 부분은 이야기해주시면 감사하겠습니다 :) - GitHub - KEEMSY/STUDY: 공부한 내용을 정리하고, 부족한 지식을 채우기 위한 공
github.com
'회고 > TIL' 카테고리의 다른 글
오늘도 여전한 에러 해결을 위한 노력과 무시하고 개발하는 나, 이벤트기반 마이크로서비스 구축 (0) | 2023.06.15 |
---|---|
kafka 에러... 하루종일.... (0) | 2023.06.14 |
프로젝트 테스트 진행 및 dockerfile 작성 (0) | 2023.06.09 |
예비군 훈련, SLASH, 테스트 문제 (0) | 2023.06.08 |
Shoes-Ordering-System 개발 일지, SpringBoot Up & Running, Effective Java (0) | 2023.06.07 |