개발 아티클 4

아티클 - 레거시 코드를 점진적으로 개선한 경험

• 레거시 코드란? (이 글에서 정의한)
  1. 다른 사람이 “처음” 작성한 코드다.
  2. 테스트 코드가 없었다.
  3. JAVA의 Best Practice가 지켜지지 않았다. (‘LocalDate’ 대신 ‘Date’ 사용 등)
• 레거시 코드를 만난다고 실망에 그칠 것이 아닌 적극적으로 개선 시키는 태도가 필요
  
• 스프링 레거시 코드를 개선하는데 실천한 13가지 방법
  1. 테스트 코드 작성
  2. 단순히 값을 나타내는 객체가 아닌 역할을 갖는 객체로 변경
  3. static 클래스를 Bean과 Component로 변경
  4. Controller, Service, Model의 계층 구조를 명확히
  5. Java의 Best Practice 적용
  6. Spring의 Best Practice 적용
  7. Annotation 전략
  8. Exception 전략
  9. Logging 정책
  10. Mybatis 연관 관계 매핑 사용
  11. 비동기 로직 활용
  12. 정적 소스 코드 분석 툴 도입
  13. 도메인 기반 패키지 구조

아티클 - MSA(Micro Service Architecture)로의 전환

• What’s Micro Service Architecture?

  • 작은 서비스들을 모아서 커다란 서비스를 구성하는 것을 의미한다.
  • 작고, 독립적으로 배포 가능하며 개별의 기능을 수행하는 프로덕트들로 구성된 시스템
    

• Monolithic vs. MSA
  기존에 사용되었던 Monolithic Architecture와 MSA의 장단점을 비교

  Pros and Cons of Monolithic
  
  Monolithic Architecture는 전통적인 3-Tier Architecture 형태로 구성이 되고 Application Tier에 대부분의 Business Logic이 들어가게 된다. 이로 인한 장단점은 아래와 같다.

• Advantages

  • Simple to develop : Component 간의 통신 등을 고려하지 않아도 되기에 초기 개발이 쉽다.
  • Simple to test : 이 기종 간의 통신이 없기에 테스트가 용이하다.
  • Simple to deploy : 하나의 모듈만 배포하면 된다.
  • Simple to scale horizontally : Scale-out을 통해 Capacity 확장이 용이하다.

• Drawbacks
  * Limitation in Size : Scale-out을 통해 Capacity를 늘릴 수 있으나 Data Layer의 Capacity를 넘지 못하는 한계가 있다.

  • Complexity : 서비스가 확장되고 다양한 기능이 추가될수록 모듈의 복잡도는 높아진다.
  • Entire deployment : 작은 기능 하나를 배포하기 위해서도 전체 모듈이 배포되어야 한다.
  • Slow warm-up time : 전체 모듈을 배포하기에 Application의 구동에 시간이 오래 걸린다.
  • Hard to continuous deploy : 상호 연관 관계가 깊은 모듈로 인해 대규모 조직에서 개발하는 경우 변경 사항 배포를 지속해서 유지하기가 어렵다.
  • Reliability : 작은 버그 하나가 전체 시스템에 영향을 미칠 수 있다.
  • Coupling : 하나의 컴포넌트에 모든 기능이 포함되어 있기에 모듈 간의 결합도가 높다.
  • Barrier to adopt new technology : 단일 시스템이기에 확장을 위한 새로운 언어 및 기술을 도입하기 어렵다.

  Pros and Cons of Micro-service Architecture
  
  작고, 독립적으로 배포 가능하며 개별의 기능을 수행하는 프로덕트들로 구성된 시스템은 아래와 같은 장단점이 존재한다.

• Advantages

  • Product based : MSA를 구성하는 Component는 Project가 아닌 Product 단위이다. 단위 Component에 집중하기 수월하다.
  • Single Responsibility : 단일 책임 원칙을 기반으로 설계가 되고 큰 문제를 작은 단위 문제로 나누어 해결할 수 있도록 도와준다.
  • Simplicity, Loosely Coupling : 작은 단위 문제를 해결하기 위한 Component들의 모음이기 때문에 단위 복잡도가 낮아집니다. Product의 구현은 Encapsulation 되고 연동은 Interface 정의 기반으로 결합하기에 낮은 결합도를 가진다.
  • Productivity and Speed : Product의 단위 복잡도가 낮기 때문에 생산성이 좋다.
  • Flexibility, Adopting New Technology : Divide & Conquer 방식의 접근 방식을 활용하고 문제 해결에 적합한 기술을 사용할 수 있다.
  • Scalability : Product 단위로 독립적인 Scale-out을 할 수 있다.
  • CI/CD : 지속적인 통합과 지속적인 배포를 통해 서비스 안정성을 확보할 수 있다. 자동화된 통합 테스트/배포 환경을 구축할 수 있는 기반을 제공한다.
  • Cross-Functional Teams : Functional Team을 구성하여 단위 서비스를 만들 수 있다.

• Drawbacks

  • Distributed System : 분산 환경이기에 고려해야 할 부분들이 많다. Eventual Consistency에 대한 고려가 필요할 수 있다.
  • Testing : 여러 개의 Product가 조합되어야 Integration Test가 가능하다.
  • Roll-out the Changes : 여러 개의 Product가 서비스를 구성할 때 배포 순서 등의 고려가 필요하다.
  • Cost : 분산 시스템을 구성하기 위한 Minimum Set이 Monolithic보다는 많이 필요하다.

• Why Micro-service Architecture?
  Monolithic 기반의 Architecture는 MVP(Minimum Value Product)를 빠르게 개발하기에는 적합한 Architecture이지만 서비스 규모가 커지면 확장성이 떨어지고 복잡도가 높아지게 된다. 이에 확장성을 높이고 복잡도는 낮추기 위해 마이리얼트립에서는 MSA 형태로 Architecture를 변경함.