목차
1. MSA(MicroService Architecture)란?
MSA란?
MSA는 (MicroService Architecture, MSA) 단일 프로그램을 각 컴포넌트 별로 나눠서 작은 서비스의 조합으로 구축하는 아키텍쳐 입니다. 그래서 큰 서비스 속의 작은 기능들 혹은 부분을 각각으로 나눠서 다루는 독립적인 서비스들을 연결한 아키텍쳐를 말합니다.
일반적으로 MSA(MicroService Architecture, MSA) 와 Monolitic(모놀리틱) 방식을 많이 비교해서 설명합니다. ( 반대 개념 )
MSA 아키텍쳐의 장점
- 새로 추가되는 부분을 빠르게 수정 및 배포 가능 ( 서비스별로 배포가 진행되서 전체 서비스의 중단이 없다. )
- 문제가 생기면 해당 기능에만 문제가 생겨 빠르게 해결 가능 ( 장애가 전체로 확장될 가능성이 적고 격리성이 좋음 )
- 하나의 서비스에 다양한 기술 및 언어등을 선택적으로 사용 가능 ( polyglot하게 개발 및 운영이 가능 )
- 서비스 단위로 개발을 진행하기에 해당 부분을 온전히 이해 가능 ( 팀 별 프로젝트가 분리되어 있어서 )
MSA 아키텍쳐의 단점
- 분산된 서비스의 아키텍쳐로 관리가 어려움
( 데이터가 여러 서비스에 걸쳐 분산되어 있어서 한번에 조회하기 어렵고, 관리하기 또한 어려움, 비용 또한 증가) - 통신에 의존하다보니 통신 오류가 잦을 수 있음 ( 서비스 간 호출을 API를 통해 진행해서 )
- 테스트가 불편함
( 로직에 대해서 단위 테스트는 쉬우나, 통합 테스트 및 end - to - end 테스트 단위로 들어가면 시간과 많은 비용이 소모됨)
Monolitic(모놀리틱) 아키텍쳐란?
과거에서 현재까지 대중적으로 많이 사용되는 아키텍쳐 방식인 모놀리틱(Monolitic) 방식은 MSA 방식과는 반대되는 개념으로 애플리케이션의 구성 요소가 한 프로젝트에 통합되어 있는 방식입니다.
모놀리틱 아키텍쳐의 장점
- 개발 환경이 같아 복잡하지 않습니다.
- End-to-End 테스트가 용이한 장점이 있습니다.
- 배포가 간단합니다. ( 프로젝트 하나만 빌드하고 배포하면 되니까.)
- 또한 로드밸런스를 이용해 로드 부하를 나눠 가지는 방식으로 진행되어 확장성이 쉽습니다.
- 쉽게 고가용성 서버 환경을 구축할 수 있습니다.
모놀리틱 아키텍쳐의 단점
- 프로젝트의 규모가 커지면 애플리케이션의 내부가 확장되기에 구동 시간이 늘어나고 빌드와 배포 시간이 늘어나는 단점을 가지고 있습니다.
- 뿐만아니라 작은 수정사항이 생겨도 전체를 빌드, 배포해야하는 불필요한 상황을 맞이합니다.
- 여러 사람이 개발할 경우 코드를 이해하기 어려울 수 있습니다.
- 작은 한 부분의 영향 때문에 전체가 다운되는 현상이 발생할 수 있습니다.
( 하나의 작은 부분 때문에 전체가 영향을 받는다 ) - 기술 스택이 한 번 정해지면 바꾸기 어렵습니다.
- 그리고 전체 애플리케이션의 확장은 쉽지만, 부하 및 분산을 위해 각 컴포넌트들을 독립적으로 확장하기 어려운 단점이 있습니다.
내 생각
이 두 아키텍쳐 사이에 정답은 없다고 생각합니다. 일반적으로 여러 회사에서도 모놀리틱 방식을 채택하고, 서비스가 커짐에 따라서 MSA를 도입하는 경우가 늘고 있습니다. 제가 생각하기엔 우선 모놀리틱 방식에서 MSA 전환하게 되면 얻을 수 있는 비용적인 측면이 아느정도인지를 생각야합니다. 뿐만아니라 결국 기존에 있는 애플리케이션의 구조를 변경해야하는데, 과연 마이크로 서비스를 요할정도의 규모인지, 복잡도인지를 따져봐야 한다고 생각합니다.
MSA로 변경하게되면 관리포인트가 늘어날 것이기에, 여러 환경 구축 면에서도 따져봐야 합니다.
참고 레퍼런스
[데이터 분산 처리] MSA 아키텍처란?
cs-study에서 스터디를 진행하고 있습니다. 모놀리식 아키텍처 (Monolithic Architecture) 모놀리식 아키텍처는 마이크로서비스(MSA) 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한
steady-coding.tistory.com
2. 제네릭에 대해 설명하고, 컬렉션 클래스에서 왜 제네릭을 사용하는지 설명하시오
제네릭(Generic)이란?
제네릭은 데이터 형식에 의존하지 않고, 하나의 값이 여러 다른 데이터 타입을 가질 수 있도록 하는 방법입니다. 데이터의 형식에 맞게 fit한 변수를 선언하는 것도 좋지만 만약 여러 클래스에 이렇게 변수를 다양하게 선언하면 비용적인 측면에서도 비효율적일 것입니다. 그래서 범용적으로 사용할 수있는 제네릭 타입을 만들어서 사용할 수 있도록 하는 것이 좋다고 생각합니다. 범용적으로 사용할 수 있는 코드를 만들면 코드의 재사용성이 높아질 것이고, 가독성이 높아질 것입니다.
컬렉션 클래스에서 제네릭을 사용하게 되면 얻을 수 있는 이점은 다음과 같습니다
- 타입의 안정성 보장 ( Type Safety )
- 컬렉션 내부의 저장된 타입을 컴파일 시점에서 체크할 수 있어서 이로 인해 안정성이 높아집니다.
- 타입의 변환 제거 ( Type Casting )
- 만약 다른 타입의 컬렉션에서 다른 컬렉션을 사용할 경우, 저장된 요소를 확인하고 형변환을 해야합니다. 이로 인해 코드는 늘어나고 가독성 측면에서도 좋지않으며, 잘못된 타입으로 변환하게되면 런타임 오류가 발생합니다. 그러나 제네릭을 사용하면 타입을 지정하지 않기에 앞서 있었던 문제점을 해결할 수 있습니다.
'기술면접 관련 및 참고하기' 카테고리의 다른 글
| GC (Garbage Collection)이란 무엇인가? (0) | 2023.03.31 |
|---|---|
| 기술 면접 스터디 4일차 - ( List, Set, Map, Hash Map, Parameter, Argument) (0) | 2023.03.30 |
| 기술면접 스터디 - 2일차 (DI, Index) (0) | 2023.03.28 |
| 기술 면접 스터디 1일차 - ( OOP, Rest api) (0) | 2023.03.27 |
| Test Code 2부 (0) | 2023.03.22 |