<온프레미스 아키텍처 - 서비스 흐름도> [KT에이블스쿨] 2025.05.21(수)

2025.05.21 (수)

 

 

오늘은 이제 온프레미스 아키텍처 중

하드웨어와 소프트웨어 파트를 끝내고 인프라 구성도를 

나가기 전에 서비스 흐름도에 대해 배웠습니다 ! 

 

서비스 흐름도는 인프라 구성도와는 또 다르게

다양한 서비스와 그 흐름에 대해 정의하고 

필요 시스템과 서비스를 알 수 있게 해줍니다.

 

그러기에 기획 단계에서 필수적으로 필요하다고 

이야기할 수 있을거 같습니다.

 

오늘 내용도 중요하니 잘 리뷰해보겠습니다 ! 

 

시작하겠습니다 !!

 

 

 

---

 

[온프레미스 아키텍처 - 서비스 흐름도]

 

1. 서비스 흐름 & 데이터 통신

○ 흐름(Flow)의 세 가지 유형

  → 서비스/데이터/업무 Flow 

 

○ 서비스 Flow 

  : 사용자가 서비스를 이용하는 전체 이용 흐름을 순서대로 보여주는 흐름 

  → 사용자의 주요 행동과 그에 따른 시스템 응답 흐름을 중심으로 구성

  → UX 설계, 화면 시나리오, 사용자 여정 분석 등에 활용

○ 데이터 Flow 

  : 서비스 내부에서 데이터가 어떻게 이동되고 처리되는지 보여주는 흐름

  → (사용자 입력 - 처리 - 저장 - 결과 출력)의 과정을 시각화

○ 업무 Flow 

  : 조직 내에서 업무가 어떤 순서, 어떤 방식으로 처리되는지를 보여주는 흐름

  → 실제 업무 단계를 시각화 (부서와 역할 중심)

 

○ 서비스 흐름도 정의

  : 사용자 요청이 어떤 순서와 흐름으로 전달/처리/응답 되는지를 시각화

  → 각 서비스 단위 책임 구분, 요청의 시작과 처리를 이해하기 위한 도구

 

○ 서비스 흐름도의 목적

  ① 전체 서비스 요청 처리 흐름을 한눈에 파악하고 공유하기 위한 문서화 도구

  ② 기능 책임과 처리를 구분

  ③ 병목 지점, 오류 발생 가능 위치 검토 및 개선 방향 도출

  ④ 설계와 개발 구현 단계에서 기능 흐름 기준을 제공

  ⑤ 비기술 구성원과 기술 구성원 모두가 이해 가능한 흐름 중심 설계 언어 제공

  → 사용자 중심의 시각화 방법, 요청 흐름을 구분

  → 온프레미스에서는 모든 시스템 자원을 직접 설계/배치해야 하기 때문에, 요청 흐름/처리 구조를 명확히 정의 필수

  → 자원 낭비/재구축 발생 가능성을 감소시키고, 구조적 보완 역할

 

○ 서비스 흐름도 구성요소

① 사용자(User)

  : 서비스와 상호작용하는 최종 주체 (요청의 시작점)

  → 사용자 유형에 따라 접근 가능한 기능이 구분되어야 함

 

② 애플리케이션(Application)

  : 사용자 요청을 처리하고 결과를 반환하는 서비스 단위 

  → 구성 요소 간 책임을 분리하고 구조화 

 

   1) 애플리케이션 구성

 

     ① 모놀리식(Monolithic) 구조

       : 시스템의 모든 기능을 하나의 애플리케이션(프로젝트) 안에 통합한 구조 (단일 실행 환경 처리)

      → 장점 : 테스트와 배포 간단, 기능 간 공유 쉬움, 구조 파악 쉬움, 소규모 서비스/스타트업에 적합

      → 단점 : 기능이 많으면 복잡성 폭증, 변경 영향 범위 큼, 배포 유연성 낮음, 확장성 부족, 기술 스택 제한

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

       : 기능별 서비스 분리하여 독립적으로 실행/배포되는 구조

      → 기술 다양성을 허용하면서 장애 격리가 가능함 (확장성/유지보수성/장애 대응력 우수)

   

    2) 애플리케이션 세부 계층

 

      ① 프론트엔드(FrontEnd)

        : 사용자와 직접 상호작용하는 화면 계층, 사용자 입력을 수신, 백엔드로 요청 전달

      ② 백엔드(BackEnd)

        : 비지니스 로직 처리, DB 접근, 외부 시스템 연동을 담당, 요청을 받고 결과 데이터 반환

      ③ 데이터베이스(DataBase)

        : 애플리케이션이 사용하는 데이터를 저장하고 조회하는 저장소, 시스템 내부 데이터 처리 담당

      ④ API(Application Programming InterFace)

        : 애플리케이션 간 또는 외부 시스템과 통신하기 위한 기능 호출 인터페이스, 기능 요청과 데이터 전달을 담당

 

○ REST API

  : Representational State Transfer(표현 상태 전달)의 약자로, 웹 자원을 규칙적으로 표현하고 상태를 주고 받는 통신 구조

  → 자원은 URI(Uniform Resource Identifier, 통합 자원 식별자)로 식별되며, 클라이언트는 이 URI에 대해 HTTP 메서드를 이용해 동작을 요청

  → 자원 : 시스템 내 식별 가능한 정보 단위

  → URI는 자원만 나타내고, 행위는 반드시 메서도로 분리

  → 구현이 간단하고 직관성이 높아 프론트엔드와 백엔드 통신에 적합

  → 요청 구성 요소 : URI(요청할 자원 위치 지정), Method(요청의 종류), Header(요청 부가 정보), Body(전송할 데이터)

  → 응답 구성 요소 : Status Code(요청 처리 결과), Header(응답 부가 정보), Body(처리 결과 데이터)

 

○ RPC(Remote Procedure Call)

  : 원격 서버의 함수를 호출하듯 작동하는 통신 방식, 함수 이름과 인자만을 전달하고 서버는 이를 실행 후 결과를 반환

  → REST API와 달리 자원이 아닌 동작 중심 API 구조(빠르고 간결한 통신에 사용) 

 

○ HTTP 메소드 

  : 클라이언트가 서버의 어떤 동작을 요청하는지 나타내는 방식 

  → 메소드 종류 : GET(자원 조회), POST(자원 생성), PUT(자원 전체 수정), DELETE(자원 삭제)

  → c.f) DB의 CRUD와 유사 : Read - Get / Create - Post / Update - Put / Delete - Delete

 

○ Message Queue

  : 서버 내부에서 시스템 간 메시지를 비동기로 전달하는 통신 방식

  → 보내는 쪽(Producer)과 받는 쪽(Consumer)을 분리하여 서로 동시에 작동하지 않아도 데이터 교환 가능

  → 받는 쪽에서 나중에 꺼내 처리 가능, 시스템 간 결합도 낮춤

  → 큐 기반 MQ : 메시지를 한 번만 전달하고 처리되면 큐에서 제거 ex) RabbitMQ, ActiveMQ

  → 스트리밍 기반 MQ : 메시지를 일정 기간 저장하고, 여러 Consumer가 읽기 가능 ex) Apache Kafka, Amazon Kinesis

 

○ RabbitMQ와 Apache Kafka의 차이

항목	RabbitMQ	Apache Kafka
메시지 모델	메시지 지향(Messaging Queue)	로그 지향(Publish-Subscribe + Distributed Log)
기반 프로토콜	AMQP (Advanced Message Queuing Protocol)	자체 TCP 기반 프로토콜
메시지 처리 방식	메시지를 소비하면 큐에서 제거됨 (기본적으로 1회 소비)	메시지를 로그에 저장, 여러 소비자가 동일 메시지를 읽을 수 있음
메시지 순서 보장	큐 단위로 순서 보장	파티션 내에서만 순서 보장
내구성 및 저장 방식	메모리 기반 처리, 디스크 저장 옵션 존재 (기본적으로 휘발성)	모든 메시지는 디스크에 지속적으로 저장 (내구성 강함)
처리 방식	푸시 방식 (브로커가 소비자에게 메시지를 전달)	풀 방식 (소비자가 브로커로부터 메시지를 가져감)
재처리/재시도	기본적으로는 재처리 불가 (별도 설정 필요)	오프셋(offset)을 조절해 메시지를 재처리 가능
목표 사용 사례	요청/응답, 실시간 알림, 작업 큐 등	로그 수집, 이벤트 소싱, 데이터 스트리밍 등
확장성	수평 확장은 가능하지만 Kafka보다 어려움	높은 수평 확장성 및 대용량 처리에 최적화
Latency (지연)	낮은 지연 시간 (빠른 전송)	높은 처리량에 최적화, 다소 높은 지연 가능

 

 

○ NAT(Network Address Translation) Traversal 이슈

  : 내부망과 외부망을 연결하기 위한 IP 주소 변환 방식인 NAT을 통해 직접 연결할 수 없는 상태

  → REST API 방식 적용 불가, MQ 이용 필요 

 

2. 서비스 흐름도 작성 실습

○ 서비스 흐름도 구성 요소 및 순서

  : 사용자 유형 정의 / 프론트엔드 설계(화면 UI) / 백엔드 서비스 설계(수행할 서비스) / DB 설계

  → 서비스 간 API를 통해 통신 or DB와 직접 연결 사용 

 

○ 작성한 서비스 흐름도

서비스 흐름도

 

 

  → 사용자와 프론트엔드의 UI 간 연결을 시각적으로 구별되게 하기 위해 색을 넣어 작성

  → 서비스 간 API와 MQ의 화살표가 중복되는걸 방지하기 위해 하단에 백엔드 서비스를 분리하여 작성