들어가며
해당 강의를 보고 공부한 내용을 정리하였습니다.
3-tier architecture에서 stored procedure의 의미
비즈니스 로직이란?
e.g 당근마켓의 비즈니스 로직
- 회원가입 / 탈퇴
- 상품 리스트업 알고리즘
- 상품 정보 업로드 기능
- 상품 검색 기능
- 메시지 기능
데이터
e.g 당근마켓의 데이터
- 회원 정보
- 상품 정보
- 판매 / 구매 내역
- 지역 정보
Stored procedure
- RDBMS에 저장되고 사용되는 프로시저
- 주된 사용 목적은
비즈니스 로직구현
Stored procedure를 사용한다는 것은 data tier에 비즈니스 로직이 있다는 것!
stored procedure 장점
1. application에 transparent 하다.
이러한 장점을 더 구체적으로 설명하면, 비즈니스 로직을 수정해야 할 경우를 예로 들어볼 수 있습니다. 비즈니스 로직이 어플리케이션의 로직 티어(Logic Tier)에 서버로 구현되어 있다고 가정해보겠습니다. 이때 비즈니스 로직을 수정해야 할 일이 생겨서 로직을 변경하고, 변경된 로직을 적용하기 위해서는 해당 인스턴스를 내리고 새로운 인스턴스를 올려야 할 수 있습니다.
하지만 Stored Procedure를 사용하면 이러한 번거로운 과정을 생략할 수 있습니다. 비즈니스 로직을 Stored Procedure 내에 내장하여 데이터베이스에 저장하고 있는 상황에서, 비즈니스 로직을 수정해야 한다면 단순히 Stored Procedure의 내용을 변경하면 됩니다. 이렇게 되면 이전의 인스턴스를 내리고 새로운 인스턴스를 올리는 번거로운 작업 없이도 변경된 비즈니스 로직이 즉시 적용될 수 있습니다.
결과적으로, 어플리케이션의 서버 인스턴스를 교체하거나 업데이트하는 번거로운 과정을 피할 수 있으며, 데이터베이스 내부의 비즈니스 로직을 효율적으로 관리할 수 있다는 특징이 "application에 transparent 하다"는 장점으로 드러납니다.
2. network traffic을 줄여서 응답 속도를 향상시킬 수 있다.
비즈니스 로직이 로직 티어에 위치할 경우, 예를 들어 웹 어플리케이션 서버(Web Application Server) 내에 비즈니스 로직이 구현되어 있는 상황을 가정해보겠습니다. 이런 경우 비즈니스 로직 안에서 여러 개의 SQL 문을 수행할 때마다, 각 SQL 문의 실행에 따라 네트워크 트래픽이 발생하게 됩니다.
반면에 비즈니스 로직을 데이터베이스 내에 저장된 프로시저(Stored Procedure) 형태로 구현한다면, 웹 어플리케이션 서버는 해당 프로시저를 호출하게 됩니다. 이 때 프로시저 내부에는 여러 개의 SQL 문이 처리되며, 결과적으로 웹 어플리케이션 서버와 데이터베이스 사이의 네트워크 트래픽은 단 한 번만 발생하게 됩니다.
이로써 웹 어플리케이션 서버는 해당 프로시저만 호출하면 되므로, 여러 개의 SQL 문을 서버에서 수행하는 상황에 비해 훨씬 적은 네트워크 트래픽을 처리하게 됩니다. 이러한 구조로 인해 네트워크 트래픽이 줄어들게 되어 응답 속도를 향상시킬 수 있는 장점이 있습니다.
3. 여러 서비스에서 재사용 가능하다
상상해보십시오. 데이터베이스에 사용자 정보에 대한 프로시저(Stored Procedure)가 존재한다고 가정해봅시다. 이 경우, 서비스 A, 서비스 B, 서비스 C 등 여러 서비스들은 이 프로시저를 호출하여 사용자 정보를 얻을 수 있습니다.
하지만 만약 비즈니스 로직이 로직 티어에 존재한다면, 각 서비스마다 사용자 정보를 얻는데 필요한 로직을 각각의 프로그래밍 언어로 구현해야 합니다. 예를 들어 서비스 A는 Java를 사용하고, 서비스 B는 Django를 사용하며, 서비스 C는 Node.js를 사용할 수 있습니다.
이런 경우, 비즈니스 로직이 프로시저로 추상화되어 있으면 여러 서비스에서 동일한 프로시저를 호출하여 사용자 정보를 얻을 수 있습니다. 각 서비스는 단순히 해당 프로시저를 호출하기만 하면 되므로, 중복된 코드를 작성하지 않아도 되며 유지보수가 용이해집니다
