꼰대 개발자~

푸념! 요즘은 과거 "성문법", "맨투맨"식 영어 교육시대를 살아가는 느낌입니다. 영어를 배우는건지 영어를 가르치기 위한 용어를 배우기 위해 공부를 하는지 알 수 없는 시대! 용어 보다는 실제로 경험해온 개발방법에 최근 정리된 방법론들을 해석해 봅니다. 

EDD역시도 MSA의 보편화로 인해 파생된 개발 방법론인듯한다. Kafka, RabbitMQ등의 clustered message broker를 적극 활용하여 고가용/고성능, 손쉬운 확장성을 구현해 내기 위한 방법론이다.

이 개념 역시도 새로운 개념은 아니다. 꼰대의 입장에서 보면 Kafka 그 자체이다.

누군가 데이터를 만들어내고 (producer), 누군가가 그 데이터를 소비하며 ( consumer ), 누군가가 데이터를 소비(consume)하여 새로운데이터를 만들어(produce)에 낸다 ( aggregation ), 관심사는 topic을 통하여 분리한다. 

message broker를 통한 business의 구현의 다음과 같은 장점을 가진다.

• fire & forget이 가능하다.
  • producer는 필요한 시기에 데이터를 소비하고 원하는 시점에 데이터를 생산한다. 
  • peer의 performance  수신여부등에는 관심이 없다.
• feature 마다 route를 설정 할 필요가 없다.
  • 어디서 생성된 데이터 인지는 모르겠지만 내가 필요한 데이터를 소비하여 내 비지니스를 간단히 완성한다.
  • 어디서 쓸지는 모르겠지만 내가 만들어낸 데이터를 버리지 않고 생상해 낸다.
• bussines 확장이 용이하다.
  • 필요한 / 필요할지도 모르는 데이터는 최대한 생성해 두고
  • feature / bussiness 가 필요한다. aggregation하고 소비하여 완성하면된다.
  • 계속된 data aggregation / transform을 통하여 data의 품질을 높이고 단순화해 나가면서 복잡한 비지니스를 완성한다.
  • 이러한 이유로 기계학습 (DNN)에 많이 추천되는듯한다.

단점이 없는것은 아니다.

• broker의 장애는 전면장애다.
• data schema의 변경이 어디로 전파될지 모른다 ( 변경이 어렵다 )
• data producing및 latency의 변경이 어디서 문제가 생길지 예측하기 어렵다.

단점을 극복하려면

• 모니터링 강화
  • 어떤 변경이 어떤 영향을 미치지 모르므로 전체 시스템에 대한 견고한 모니터링이 필요하다.
  • infra performance - 경험상 이부분에서 거의 모든 이슈가 시작된다.
  • service별 perofrmance 
  • topic / parition별 performance
  • 데이터 흐름에 대한 visualizing
• domain간 data schema의 철저한 분리
  • clean architecture
  • 관리부서 domain간의 data schema를 변환하여 사용한다.
  • domain간 schema 변경 및 로직의 변경이 consumer들의 data driven에 영향을 미치지 않아야한다.
• data schema versioning & registering
  • 아무리 data schema를 분리하여도 외부 schema 변경이 없을수는 없다.
  • data schema에 version을 두어 consumer가 분리하여 처리 할수있도록 한다.
  • data schema에 대한 registering을 통하여 consumer가 consumming schema를 검증할수있도록 한다.