1. MSA 강의

🎇 모놀리식 vs MSA

처음 MSA가 대두된 이유는 Netflix에서 MSA 사용 후 대박을 냈다.

우아한 모노리스 후기 참고

Monolithic Architecture

1. 단일 모듈 구조 :

• 애플리케이션은 단일 모듈 또는 단일 코드베이스로 구성
• 주로 하나의 프로젝트 내에서 모든 기능과 컴포넌트가 통합

2. 단일 데이터베이스 :

• 모든 기능이 하나의 DB에 접근
• 주로 하나의 프로젝트 내에서 모든 기능과 컴포넌트가 통합되어 있다

3. 모듈 간 강한 결합 :

• 서로 다른 기능들이 밀접하게 결합되어 있어, 한 부분의 변경이 다른 부분에도 영향을 미칠 수 있다

4. 스케일링 어려움 :

• 특정 기능만 확장하거나 업데이트하기 어려우며, 전체 애플리케이션을 함께 업데이트해야 할 수 있다

5. 배포와 확장이 비교적 어려움 :

• 전체 애플리케이션을 한 번에 배포하고 확장해야 한다

Microservices Architecture(MSA,마이크로서비스 아키텍처)

1. 분리된 작은 서비스 :

   • 애플리케이션은 작은 독립적인 서비스로 나뉜다.

2. 독립적인 데이터베이스 :

   • 각 서비스는 필요에 따라 자체 데이터베이스를 가질 수 있다.
   • 서비스 간 데이터 공유를 위해 API나 이벤트 기반 통신을 사용한다.

3. 느슨한 결합 :

   • 서비스 간의 결합도가 낮아져, 한 서비스의 변경이 다른 서비스에 영향을 미치지 않는다.

4. 독립적인 확장 :

   • 특정 서비스만 확장하거나 업데이트할 수 있다. 필요한 경우, 서비스를 추가하거나 제거할 수 있다

5. 배포 용이성 :

   • 각 서비스 독집적으로 배포할 수 있으며, 이는 빠르고 안전한 업데이트를 가능하게 한다.

6. 기술 다양성 :

   • 서비스 간에 다양한 기술을 사용할 수 있다. 예를 들어, 각 서비스가 자체적으로 선택한 언어나 프레임워크를 사용할 수 있다.

어떤 아키텍처를 선택해야 할까요?

• Monolithic은 간단한 애플리케이션을 빠르게 개발하고 배포할 때 유용할 수 있다.(초기 개발 - Single Repo)
• Microservices는 복잡한 애플리케이션 또는 대규모 팀이 작업하는 경우 유용할 수 있다. 또한 서비스 간의 독립성과 확장성이 필요한 경우에 적합하다. (규모가 커진 경우 변경)

각 프로젝트의 요구사항과 팀의 구성원, 개발/배포 프로세스에 따라서 어떤 아키텍처를 선택할지 고려해야 한다. 때로는 두가지 아키텍처를 혼합해서 사용하는 하이브리드 방식도 적용 가능하다.

🎇 DDD(도메인 주도 개발)

도메인 주도 개발은 복잡한 소프트웨어 프로젝트에서 도메인을 중심으로 시스템을 설계하는 방법론. 이것은 비즈니스 요구사항을 잘 이해하고 이를 기반으로 소프트웨어를 개발하는데 도움이 된다.

1. 도메인 중심 설계:

• 도메인의 중요성 : DDD는 비지니스의 핵심적인 영역, 즉, 도메인에 초점을 맞춘다. 이는 비지니스에서 가치있는 부분을 지칭한다.
• 전문가와의 협력 : 도메인 전문가와 밀접한 협력을 통해 도메인을 이해하고 그에 기반하여 모델을 만든다. 이를 통해 요구사항을 명확하게 파악하고,비지니스 용어를 잘 활용한다.

2. 모델링:

• 도메인 모델 : 비지니스 도메인을 나타내는 모델. 이 모델은 비지니스 개념과 그들 간의 관계, 행위를 포함.
• 도메인 모델은 특정 도메인을 이해하기 위해 개념적으로 표현한 것을 말한다.
• 또한, 전체 도메인을 기준으로 하위에 여러 도메인들이 있는데, 모델링 시 하위 도메인에 따라 모델링을 각각 해줘야 한다.
• Uniquitous Language(보편적 언어) : 도메인 전문가와 개발자가 사용하는 언어를 표준화하여 의사소통을 원활하게 한다.
• 도메인 모델을 활용하면 여러 관계자들이 동일한 도메인으로 이해가 가능하여 지식 공유에 있어 유리하다.
• Aggregates, Entities, Value Objects : DDD에서 중요한 개념으로, 엔티티와 밸류 오브젝트는 도메인 객체를 표현하는데 사용되며, 어그리게이트는 객체그룹을 나타낸다.

3. Bounded Context:

• Bounded Context : 큰 시스템을 작은 독립된 컨텍스트로 나누어 관리한다. 각 컨텍스트는 자체적인 도메인 모델과 언어를 가진다.

4. 상태와 행위:

• 상태와 행위 분리 : DDD에서는 객체의 상태와 행위를 분리한다. 객체는 자신의 상태를 가지고 있고, 상태에 따라 행위가 변할 수 있다.

5. 유비쿼터스 언어(보편 언어)와 모델 업데이트:

• 언어와 모델의 지속적인 업데이트: 도메인의 이해가 더 깊어짐에 따라 모델과 언어를 계속해서 업데이트하여 정확한 비지니스 요구사항을 반영함.
• 애자일 방식의 개발

6. 구현:

• 구현 패턴: DDD는 특정한 구현 기술에 종속적이지 않는다. 선택한 언어와 기술을 사용하여 도메인 모델을 구현함.

7. 테스트와 검증:

• 단위 테스트와 통합 테스트 : 도메인 모델을 검증하기 위해 단위 테스트와 통합 테스트를 활용한다.

DDD의 장점:

• 비즈니스 요구사항을 명확하게 이해하고 모델링할 수 있다.
• 도메인 전문가와의 협력을 통해 비즈니스 이해도를 향상시킨다.
• 복잡한 시스템을 더 쉽게 이해하고 유지보수할 수 있다.

DDD의 단점:

• 초기 학습 곡선이 높을 수 있다.
• 모든 프로젝트에 적합하지 않을 수 있다.

DDD는 비즈니스 중심의 복잡한 소프트웨어 시스템을 구축할 때 매우 유용한 방법론이다.

🎇 대규모 서비스를 지탱하기 위한 부하분산

Proxy 서버

네트워크 관점에서 클라이언트와 서버 사이에서 요청과 응답을 중계해주는 서버를 프록시 서버 라고 한다.

• 포워드 프록시

  클라이언트 측 요청 시 요청 번호를 위장해주어 서버에서 어떤 브라우저로부터 요청이 오는지 모르도록 해주는 것을 포워드 프록시 라고 한다.

• 리버스 프록시(엔진엑스NginX)

  서버측에서 실제 여러개의 서버가 돌아가고 있지만, 클라이언트가 이를 하나의 서버라고 인식하도록 위장해주는 것을 리버스 프록시 라고 한다.

만약, 8004 주소의 리버스 프록시(health_check, load balancing)를 거쳐서 요청이 들어가면, 백엔드 서버 여러개 중 필요한 곳에 적재 적소(부하가 적은 곳에 요청을 보내줌)에 부하를 분담하거나, 백엔드 서버가 살아있는지 확인하는 헬스 체크 용도로 사용된다.

리버스 프록시를 활용한 부하 분산은 웹 서비스나 애플리케이션의 성능을 향상시키기 위한 중요한 전략 중 하나이다. 이를 통해 서버에 들어오는 트래픽을 여러 대의 서버로 분산이 가능하다. 그러나 이러한 방식은 적용 시 아래와 같은 어려움을 직면한다.

1. 구성과 관리의 복잡성:

리버스 프록시를 통한 부하 분산은 여러 대의 서버를 관리하고 구성해야 한다.

이는 초기 설정부터 각 서버의 상태를 모니터링하고 유지보수하는 등 관리 복잡성이 증가하게 된다.

2. 프록시 설정의 최적화:

리버스 프록시는 서버에 들어오는 요청을 분배하는 역할을 한다.

올바른 프록시 설정을 구성하지 않으면 성능 저하나 불안정성이 발생할 수 있다.

이를 최적화 하려면 서버 및 네트워크 아키텍처에 대한 깊은 이해가 필요하다

3. 서버 상태 관리:

여러 대의 서버가 사용될 경우, 각 서버의 상태를 모니터링하고 관리해야 한다.

만약 하나 이상의 서버가 다운되면 프록시는 트래픽을 분배하지 못하게 될 수 있다.

4. 세션 유지와 데이터 일관성:

부하 분산을 적용하면 클라이언트의 요청이 다양한 서버로 전달될 수 있다.

이로 인해 하나의 서버 안에서만 유지되는 세션은 상태를 유지하는 것이 어렵다.

또한, 데이터베이스와 같은 공유 리소스의 일관성을 보장하는 것도 복잡해질 수 있다.(lock)

5. 보안 및 인증 문제:

프록시를 통해 들어오는 요청을 신뢰할 수 있는지 확인해야 한다. 또한, SSL/TSL 암호화와 같은 보안 기능을 올바르게 구성해야 한다.

6. 로깅과 모니터링 :

여러 서버에서 작동하는 경우, 로깅과 모니터링 시스템을 통해 전체 시스템의 상태를 추적하고 문제를 식별하는 것이 중요하다.

7. 네트워크 지연 및 대역폭 :

프록시를 통한 부하 분산은 네트워크를 통해 데이터를 전송하므로 지연 및 대역폭 문제가 발생할 수 있습니다.

이러한 어려움들을 극복하기 위해서는 잘 설계된 리버스 프록시 아키텍처와 각종 모니터링, 로깅, 백업 및 복구 등의 보완적인 시스템이 필요합니다. 또한, 클라우드 기술을 활용하여 자동 확장과 관리를 수행하는 것이 효과적일 수 있습니다.

참고

MSA 구조에서 Session을 사용하면 안되는 이유?

MSA에서 인증,인가 목적으로 세션 사용이 어려운 이유는 수평 스케일링이 어렵기 때문이다.

수평 스케일링은 해당 서버에 부하가 높아질 경우 동일한 서비스의 VM 인스턴스를 하나 더 추가하는 스케일 업 방식이다. 하지만, 세션은 해당 서버 내에서만 사용이 가능하기 때문에 다른 VM 서버에서 사용할 수 없어, 별도의 비용이 추가된다.

반면에 JWT 사용 시, 세션 사용으로 인한 수평 스켈링의 한계를 보완해준다.

스티키 세션 : 회원이 로그인한 서버에서만 요청을 받도록 해주는 상태. 이렇게 하면, 수평 스켈링의 한계를 보완해주고, 각 서버마다 부하가 낮은곳으로 붙혀주면 되기 때문에 부하 밸런싱도 가능함.

레이스 컨디션

비동기적으로 실행 시, 공용 데이터를 사용하는 경우 해당 데이터가 의도치 않은 결과가 도출될 수 있다.

레이스 컨디션이 많아지면, 비관적 락(요청 시마다 lock을 걸어줌)을 걸어주고, 크게 충돌이 많이 안일어나면 낙관적 락(version 값을 만들어 version 일치 여부 확인 후 요청을 반영하며, 해당 요청 실패시마다 재요청을 수행)을 걸어준다.

동시성 제어 및 대규모 트레픽 처리