Development

Q1. distributed and scalable systems 구성 시 고려할 요소 (CSP related)

• Distributed System (분산 시스템): 여러 독립된 컴퓨팅 리소스를 모아 하나의 시스템으로 사용하는 시스템
• Scalable System (확장 가능한 시스템): 많은 부하를 처리할 수 있도록 처리량을 증가시킬 수 있는 시스템

   1. 가용성 (Availability): 중요한 컴포넌트의 이중화, 실패 발생 시 빠른 복구, 일부만으로 동작할 수 있게 해 전면 장애가           발생하지 않도록 하는 구성 (graceful degradation)

   2. 성능 (Performance): 빠른 응답시간, 낮은 레이턴시 >> 사용성, 만족도에 영향을 미침

   3. 신뢰성 (Reliability): 똑같은 요청에는 똑같은 결과를 제공해야함 (시스템 정상작동)

   4. 확장성 (Scalability): 얼마나 많은 추가 트래픽을 처리할 수 있는지, 저장 공간을 추가하기 얼마나 쉬운지, 얼마나 많은 

       트랜잭션을 처리할 수 있는지

   5. 관리성 (Manageability): 문제 발생 시 분석이 용이해야하며 문제를 이해하기 쉬워야 함. 업데이트, 수정, 시스템 운용           자체가 쉬워야 함

   6. 비용 (Cost): 하드웨어, 소프트웨어 비용 외 시스템 배포, 관리 비용 등 시스템 소유에 필요한 모든 비용

 

   *위 고려사항들 간의 trade off가 있을 수 있음

 

Q2. 2 tier architecture / 3 tier architecture (MSP related)

 

프레젠테이션 계층 (클라이언트, WEB) / 애플리케이션 계층 (WAS) / 데이터 계층 (DB)

• 2 tier: 클라이언트(WEB + WAS) + 서버(DB)  >>  개발편의성
• 3 tier: WEB + WAS + DB  >>  확장성, 성능, 자원활용, 관리

* 웹서버(Web Server): 정적인 컨텐츠를 제공하는 서버, 대표적인 웹서버로는 Apache HTTP server, NGINX 등이 있음

* 웹 애플리케이션 서버(WAS): DB 조회 등 로직을 처리해야하는 동적인 컨텐츠를 제공하는 서버, 대표적인 WAS로는          Tomcat, JEUS 등이 있음

 

[2 tier architecture]

• 웹 서버에서 정적 컨텐츠를 처리, 동적 컨텐츠나 복잡한 비즈니스 로직 처리는 클라이언트 측에서 해결하거나 웹 서버 자체에서 단순하게 처리
• 클라이언트가 서버와 직접 상호작용하므로 데이터베이스와의 직접적인 연결도 이루어질 수 있음
• 웹서버: 주로 정적인 컨텐츠를 제공하고, 간단한 동적 요청(e.g. PHP, JSP 등)을 처리
• WAS 없음: 별도의 WAS가 없기 때문에 동적 요청은 웹서버 자체가 처리하거나 클라이언트가 직접 데이터베이스와 통신하는 구조
• 동적인 처리를 담당하는 별도의 애플리케이션 서버(WAS)가 없기 때문에 클라이언트나 웹서버에서 비즈니스 로직을 직접 처리해야 하며, 확장성이 떨어지고 보안이 취약해질 수 있음

[3 tier architecture]

• 프레젠테이션 계층 (Client): 사용자는 웹 브라우저를 통해 웹서버에 요청을 보냄
• 애플리케이션 계층 (WAS): 웹서버가 받은 요청을 WAS로 전달하고, WAS가 비즈니스 로직을 처리하여 데이터베이스와 상호작용
• 데이터 계층 (DB): WAS가 데이터베이스에 접근하여 데이터를 조회하고, 처리 결과를 WAS로 전달
• 웹서버: 클라이언트로부터 요청을 받아 WAS로 전달. 주로 정적인 컨텐츠(HTML, CSS, 이미지 등)를 처리
• WAS: 웹서버로부터 받은 요청에 따라 비즈니스 로직을 처리하고, 데이터베이스와 상호작용하여 동적 컨텐츠를 생성
• 웹서버와 WAS의 분리로 인해 각 계층이 독립적으로 확장 가능
• 보안성 향상: 클라이언트는 웹서버와만 통신, 데이터베이스는 WAS를 통해서만 접근 가능
• 확장성: 웹서버와 WAS, 데이터베이스 서버 각각 독립적으로 확장 가능하므로 대규모 트래픽 처리 가능

 

 

                         |2-Tier architecture|                                                   |3-Tier architecture|

웹 서버 역할

웹 서버가 클라이언트 요청을 처리하고, 간단한 로직도 처리

웹 서버는 요청을 받아 WAS로 전달하고, 주로 정적 콘텐츠 제공

WAS 역할

없음 또는 간단한 애플리케이션 로직 처리

WAS가 동적 콘텐츠와 비즈니스 로직을 처리하며 데이터베이스와 통신

데이터 처리

클라이언트 또는 웹 서버가 직접 데이터베이스와 통신

WAS가 비즈니스 로직을 처리하고 데이터베이스에 접근

확장성

확장성이 제한적

각 계층이 독립적으로 확장 가능하여 확장성이 뛰어남

보안

클라이언트가 데이터베이스에 직접 접근할 수 있으므로 보안이 취약

WAS를 통해서만 데이터베이스에 접근하므로 보안이 강화됨

 

 

Q3. MicroService Architecture의 장단점

• Monolithic Architecture (<-> MicroService Architecture)
  - Pros: End-to-End 테스트가 용이, 빠르게 간단한 서비스를 만들 수 있음
  - Cons: 작은 수정사항이 있어도 전체를 빌드 & 배포해야함 (독립적이지 않음), 유지보수 어려움, 서비스가 커져 구동시간이 늘어남, 일부분의 오류가 전체에 영향을 미침, 기능에 따라 다른 언어를 선택할 수 없음
• MicroService Architecture
  - Pros: 유지보수 용이, 거대한 서비스도 빠르게 수정 가능 (각 기능이 독립적으로 배포되기 때문), 각 기능에 따라 다른 언어를 선택 가능
  - Cons: 모니터링이 어려움, End-to-End 구동 불편 (테스트 불편)
  
  - 독립 배포: 각 서비스를 독립적으로 배포 가능, 새로운 기능 추가나 버그 수정 시 다른 서비스에 영향을 미치지 않고 변경 가능
  - 유지보수 용이성: 기능별로 서비스가 분리되어 있기 때문에 특정 기능에 문제가 발생해도 해당 서비스만 수정하고 배포 가능 >> 다운타임을 줄일 수 있음
  - 확장성: 특정 서비스에만 트래픽이 집중되는 경우 해당 서비스만 독립적으로 확장 가능, 각 서비스의 규모를 개별적으로 조정 가능
  - 다양한 기술 스택: 각 서비스가 자체적으로 분리되어 있기 때문에, 서비스를 개발할 때 다양한 프로그래밍 언어와 데이터베이스 사용 가능
  - 개발자 효율성: 작은 서비스 단위로 나뉘어 있어 특정 기능에 집중한 개발이 가능, 서로 다른 팀이 독립적으로 작업을 진행할 수 있음, 이를 통해 병렬 개발이 가능해지고 기능 출시 속도를 높일 수 있음
  - 신뢰성: 하나의 서비스에 장애가 발생하더라도 다른 서비스는 영향을 받지 않아 전체 시스템의 가용성이 높아짐
  - 자동화된 배포: 지속적 통합과 지속적 배포(CI/CD)를 통해 각 서비스의 배포를 자동화하여 빠른 개발 주기 유지 가능
  
  - 복잡한 인프라 관리: 여러 서비스가 통신하므로 네트워크 관리 및 배포 파이프라인이 복잡해짐
  - 데이터 일관성 관리 어려움: 데이터베이스가 서비스별로 분리되어 있는 데이터 일관성을 유지하는 것이 어려움, 이를 해결하기 위해 트랜잭션과 동기화 메커니즘을 신중히 설계해야함
  - 높은 모니터링 요구: 다수의 서비스가 서로 통신하는 환경에서는 모니터링과 로깅이 필수적, 서비스 간의 문제를 진단하고, 장애 발생 시 빠르게 대응할 수 있어야 함