부트캠프를 들으면서 지난 주부터 온프레미스 아키텍처에 대해 배우는 중이라, 다시 한 번 정리해보면 좋을 것 같아서 글로 남겨보려고 합니다.
온프레미스란?
온프레미스(On-Premise)는 조직 내부에 자체적으로 서버, 네트워크, 스토리지, 보안 시스템 등 인프라를 구축하고, 해당 인프라 위에서 소프트웨어를 설치해 운영하는 방식입니다. 클라우드 서비스와 달리 모든 구성 요소를 직접 통제하고 내부에서 유지, 관리하기 때문에, 보안성이나 커스터마이징 측면에서 유리합니다.
SaaS vs. 온프레미스
온프레미스와 SaaS는 조직에서 비즈니스 운영에 필요한 소프트웨어를 배포하고 사용할 수 있는 두 가지 방법입니다.
온프레미스는 조직이 소프트웨어를 직접 구매해서 내부 서버에 설치하고, 운영 체제부터 보안, 유지보수까지 모두 스스로 관리하는 방식입니다.. 반면에, SaaS는 인터넷을 통해 바로 사용할 수 있는 클라우드 기반 소프트웨어로 모든 인프라와 관리는 서비스 제공업체가 맡고, 사용자는 접속해서 사용하면 되는 방식입니다.
AWS에 따르면 SaaS와 온프레미스의 차이점을 다음과 같이 정리하고 있습니다.
| SaaS | 온프레미스 | |
| 요금 | 고지되었고 고정되었습니다. SaaS 공급자는 특정 구독 대역과 각 대역에 포함되는 내용을 자세히 설명합니다. 필요에 맞는 것을 선택합니다. | 알 수 없으며 변경 가능합니다. 높은 초기 비용과 유지 관리 비용 |
| 사용자 지정 | SaaS는 공급자가 허용하는 범위 내에서만 사용자 지정할 수 있습니다. | 새로운 기능을 만들고 배포할 수 있으므로 사용자 정의가 매우 용이합니다. |
| 지속적인 지원 | SLA에 정의된 대로 지속적인 지원을 제공합니다. | 모든 유지 관리, 복구 서비스 및 규정 준수를 제공합니다. |
| 보안 | 공급업체가 제공하고 SLA에 의해 규제됩니다. | 데이터 보안 및 데이터 보호는 사용하는 보안 시스템에 따라 달라집니다. |
| 백업 | 데이터 백업 시스템은 SaaS 공급업체 제품의 핵심 부분입니다. 가격에 따라 잠재적으로 무제한의 데이터 스토리지 용량을 확보할 수 있습니다. | 백업에 대한 책임은 사용자에게 있습니다. 기술적 재해와 기타 잠재적 문제에 대비해야 합니다. |
| 확장성 | 유연하고 확장성이 뛰어납니다. 즉각적인 확장을 제공합니다. | 새 인프라를 구매하고 설치해야 하므로 확장이 느리지만 비즈니스 성장에 따라 확장할 수 있습니다. |
| 접근성 | 인터넷에 연결되어 있고 SaaS 공급업체 또는 고객 관리자의 승인을 받은 사람이라면 누구나 이용할 수 있습니다. | 온프레미스 사용자 또는 가상화 네트워크를 통해서만 액세스할 수 있습니다. |
| 분석 | 제공업체가 허용하는 경우 다른 분석 플랫폼과 통합할 수 있습니다. | 연결하는 디지털 시스템은 마음대로 결정하지만, 이를 설치하고 분석 애플리케이션을 유지 관리해야 합니다. |
https://aws.amazon.com/ko/compare/the-difference-between-saas-and-on-premises/ 참고
목표시스템 구성도
목표시스템 구성도의 정의:
- 전체 시스템 구조와 구성 요소 관계를 시각화한 도식
- 기능의 흐름이 아닌, 구성 단위의 책임과 연결 관계 중심
- 설계 프로세스의 출발점
- 장기적인 시스템 운영과 변화 대응을 고려한 확장성, 유지보수성, 안정성 기반 마련
필요성과 목적:
- 복잡한 기능을 영역별로 구분하여 책임 분리를 확보
- 요구사항을 구조화하여 설계시 누락을 방지하고, 변경 및 확장 시에도 누락없이 검토 가능
- 구성 요소 관계의 시각화를 통해 커뮤니케이션을 원활하게 함
- 초기 단계에서 자원 산정과 설계의 기준 마련
목표시스템 구성도의 시각화 기준:
- 영역별로 구성하여 역할과 책임을 시각적으로 구분
- 사용자 중심의 서비스 흐름 고려
- 기능 단위가 아닌 구조 단위 중심의 설계
- 과도한 세부 표현은 지양, 구조적 관계에 집중
온프레미스 목표 시스템 구성 실습
목표 시스템을 직접 그려보기 위해, 시스템을 다음의 6개 영역으로 구성했습니다.
- 사용자 영역
- 서비스 영역
- 시스템 영역
- 관리 영역
- 연계 시스템 영역
- 데이터베이스 영역
강의 실습 내용인 "네이버 카페"의 목표 시스템 구성도를 그려보았고, 각 영역에 대해 그림과 함께 설명하겠습니다.
1. 사용자 영역
대상: 일반 사용자(회원/비회원), 카페 운영자
- 시스템에 접속하고 서비스를 사용하는 주체입니다.
- 일반 사용자는 게시글 열람, 댓글 작성, 쪽지 수신 등 기본 서비스에 접근
- 카페 운영자는 게시판 관리, 카페 설정, 통계 확인 등 운영 기능에 접근
➡️ 사용자별 접근 권한을 분리함으로써 보안성과 사용자 경험을 강화했습니다.
2. 서비스 영역
대상 기능: 사용자가 직접 이용하는 인터페이스 중심 서비스
- 카페 검색 및 가입, 게시글 열람 및 작성, 댓글 반응, 쪽지 기능
- 회원 정보 관리, 카페 설정, 활동 통계 및 리포트
➡️ 이 영역은 유저 행동과 바로 연결된 서비스로, 실제 화면(UI)이나 앱 기능에서 구현되는 대부분의 요소가 포함됩니다.
3. 시스템 영역
역할: 서비스 요청에 대한 실제 처리 로직 실행
- 카페 검색 시스템: 자동완성, 필터링, 인기 랭킹 처리
- 게시글 시스템: CRUD 처리, 신고/필터, 태그 및 공지 관리
- 댓글 및 반응 시스템: 실시간 반영, 금칙어 필터링
- 쪽지/알림 시스템: 송수신 및 알림 생성
- 카페 관리 시스템: 개설, 소개, 카테고리 구성 등
- 회원 관리 시스템: 등급 변경, 가입 승인/반려, 활동 로그 확인
➡️ 이 영역이 핵심 로직을 담당하며, 서비스별 로직을 도메인 기준으로 나누어 유지보수가 용이합니다.
4. 관리 영역
대상: 시스템 관리자(운영팀, 보안팀 등)
- 계정 및 권한 관리, 서비스 상태 점검, 백업/복구, 비정상 사용자 탐지
- 시스템 점검 자동화 및 장애 대응에 필요한 관리 기능 중심
➡️ 운영자가 시스템을 안정적으로 운영할 수 있도록 필수 기능을 모은 영역입니다.
5. 연계 시스템 영역
기능: 외부 시스템과의 연결 및 연동 처리
- 알림 발송 API, 네이버 통합 로그인, SNS 공유, 메일 전송, OCR 처리, 결제 시스템
➡️ 클라우드 기반 API 또는 타 시스템과의 연결이 필요한 경우, 이 영역에서 처리하여 확장성과 유연성을 확보합니다.
6. 데이터 베이스 영역
기능별 DB 구분:
- 회원 DB: 로그인 정보, 활동 내역, 차단 목록 등
- 카페 DB: 개설 정보, 운영자, 등급 조건
- 게시글 DB: 게시글 본문, 작성자, 첨부파일
- 반응 DB: 댓글 내용, 좋아요, 신고 여부, IP, 금칙어 포함 여부
- 운영 DB: 관리자 로그, 시스템 이벤트, 통계 리포트
➡️ 데이터를 성격별로 구분하여 저장함으로써, 쿼리 효율성과 보안성을 동시에 확보할 수 있습니다.
오늘 포스팅은 설계 프로세스의 흐름 중,
1. 목표 시스템 구성도 설계
2. 하드웨어 구성도 설계
3. 소프트웨어 구성도 설계
4. 서비스 흐름도 설계
5. 프로토타입 제작
목표 시스템 구성도 설계에 대해 정리해보았습니다.