시스템이 커질수록 중요성이 커진다 |
| 1. 모놀리식 아키텍처 | 단순한 프로그램(확장성, 유지보수성을 고려하지 않은)을 설계할 때 사용된다.
ex) 스타트업, 빠른 시장 출시 필요 | 장점: 코드 관리 단순하다 (쉽다), 기술스택 통일(백엔드 안에서 같은 프레임워크), 통합 테스트 용이
단점: 강한 결합도, 단일 배포(무조건은 어님) |
| 2. 클라이언트-서버 아키텍처 | 클라이언트-서버 아키텍처는 네트워크를 통해 클라이언트와 서버 간에 작업을 분리하는 소프트웨어 구조 | - 원리: 클라이언트는 사용자의 요청을 서버에 전달하고, 서버는 요청을 처리한 후 결과를 클라이언트에 응답 |
| 3. 마이크로서비스 아키텍처(MSA) | 애플리케이션을 여러 개의 독립적이고 작은 서비스들로 나누어 개발하는 소프트웨어 설계 방식 | - 각 서비스는 독립적으로 개발, 배포, 운영될 수 있으며, 각자의 비즈니스 로직을 가짐
API 게이트웨이: 클라이언트 요청을 적절한 서비스로 라우팅하고, 각 서비스의 엔드포인트를 관리
서로 다른 서비스를 각자 하나하나 매번 배포하기가 어려워져서 CI/CD 파이프라인, 컨테이너화 도구(Docker),
오케스트레이션 도구(Kubernetes) 등으로 서비스의 지속적 통합 및 배포를 → 이와 같은 데브옵스 도구가 MSA 때문에 발전함
장점: 확장성, 유지보수성
딘점: 복잡하다, 소규모 프로젝트에 부적합 |
| 4. 서버리스 아키텍처 | 개발자가 서버의 관리와 확장 문제를 신경 쓰지 않고 비즈니스 로직에 집중할 수 있도록 하는 클라우드 컴퓨팅 아키텍처 | - 장점:
사용한 만큼만 비용을 지불하는 모델로, 자원을 효율적으로 사용할 수 있어 비용 절감 효과
트래픽의 변화에 따라 자동으로 리소스를 확장하거나 축소하여, 과도한 자원 사용을 방지
서버 관리 및 인프라 설정을 클라우드 제공업체가 자동으로 처리하므로, 개발자는 비즈니스 로직에 집중할 수 있다
단점:
실행 시간 제한(함수의 실행 시간 제한).
서버리스 함수는 상태를 유지할 수 없기 때문에, 상태를
관리하거나 지속적인 연결이 필요한 작업에는 제한.
디버깅 및 모니터링 어려움
ex: 이벤트 기반 애플리케이션, 빠른 프로토타입 및 MVP 개발, 마이크로서비스 아키텍처의 일부(서버리스 아키텍처만으로 프로그램을 구성하기 한계가 있다), 불규칙한 트래픽 패턴을 가진 애플리케이션이나 대규모 분산 처리 작업(트래픽의 변화에 따라 자동으로 리소스를 확장하거나 축소 가능) |
| 결합도 | 모듈 간 의존성의 정도 | - 결합도가 낮을 수록 확장성과 유지보수성 향상 |
| 응집도 | 모듈 내의 구성 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내는 지표 | - 응집도가 높을 수록 확장성과 유지보수성 향상 |
| 확장성 | 새로운 기능을 추가하는 과정에서 기존 코드를 수정하지 않고 새로 기능 코드를 편리하게 추가할 수 있는 정도 | - 좋은 확장성을 서로 다른 모듈들간에 낮은 결합도와 각 모듈 안에서의 높은 응집도로부터 도달할 수 있다. |
| DevOps | 소프트웨어 개발 팀과 IT 운영 팀의 통합 | |
| CI/CD | CI (Continuous Integration): 코드를 주기적으로 깃에 병합
CD (Continuous Delivery/Deployment): 자동으로 빌드, 테스트하고 배포까지 | - 코드 병합부터 배포까지 전 과정 자동화