Three-tier Architecture는 Presentation Tier Application Tier, Data Tier 세 가지 주요 계층을 나눠서 구성한 아키텍처를 말한다. 회사의 비지니스에 따라 더 세부적으로 아키텍처가 구성될 수 있지만 보통 회사의 큰 아키텍처는 Three-tier Architecture로 설명할 수 있다. 가장 중요한 점은 이 Three-tier Architecture를 분석하면 어떻게 서비스의 성능을 높일 수 있을지 정확한 파악이 가능하며, 업무를 할 때 어떠한 목적을 가지고 각 개발직군의 개발자들과 소통하면 좋을지 파악할 수 있다.
Three-tier Architecture
1. Presentation Tier
- 사용자에게 보이는 부분을 담당
- React, Native App ...
- Frontend, Mobile
2. Application Tier
- 서비스와 관련된 기능과 정책 등등 비지니스 로직을 담당
- Spring, Django
- Backend
3. Data Tier
- 데이터를 저장, 관리, 제공 역할
- MySQL, Oracle, MongoDB
- DBAThree-tier Architecture는 각 계층의 목표는 분명하다.
Presentation Tier
Presentation Tier는 사용자와 상호작용하는 계층이다. 이 영역에 해당하는 개발자는 Frontend, Mobile 개발자가 될 수 있다. 이 영역에서의 가장 중요한 목표는 사용자와의 상호작용을 적절히 처리하고, UI / UX를 통한 고객경험을 높이는 것이다.
이 영역에서 주의할 점은 Application Tier에서 처리해야 할 비지니스 로직을 과도하게 위임하지 않는 것이 중요하다. 추가로 이 영역에서 발생하는 네트워크 I / O는 인터넷을 통해 발생하므로 불필요한 I / O는 발생시키지 않도록 하는 게 중요하다. (여러 번 인터넷을 통한 네트워크 I / O를 발생시키지 않고 한 번에 서버에서 처리할 수 있는 방안을 고민하는 것이 중요하다.)
Application Tier
Application Tier는 서비스의 비지니스 로직을 처리하는 중요한 계층이다. 이 영역에 해당하는 개발자는 백엔드 개발자가 될 수 있다. 이 영역에서의 가장 중요한 목표는 서비스의 비지니스 로직을 처리하는 것이다. 그렇다면 비지니스 로직이란 무엇일까 비지니스 로직은 여러 서비스와의 소통, 데이터베이스와 소통을 복합적으로 수행하여 현실세계의 문제(도메인)를 해결하는 로직을 말한다. 즉, 백엔드 개발자는 이러한 사실을 이해하고 비지니스의 특정 기능에 맞게 여러 복합적 요소의 절차를 논리적으로 작성하는 것이 중요하다. 이러한 관점에서 백엔드 개발자는 비지니스를 잘 이해하고 비지니스에서 발생하는 데이터의 성격을 잘 이해하는 것이 매우 중요하다.
외부와 상호작용은 그냥 우리어지는 것이 아니라 여러 복합적인 환경 설정과 보조로직에 의해 이루어진다. 즉, 비지니스 로직은 보조로직의 집합체로 해석할 수 있다. 여기서 이야기하는 보조로직은 외부의 서비스와 통신, 명령하기 위한 코드, DB와 통신, 명령하기 위한 코드(Ex) SQL)를 이야기한다. Hexagonal Architecture로 해석하면 외부의 Out Adapter에 해당한다. 비지니스로직은 특정 비지니스의 기능이 올바르게 수행할 수 있는 논리를 책임지고, 보조로직은 실질적인 성능을 책임진다고 할 수 있다. 비지니스 로직의 논리가 옳다고 성능이 향상되는 것은 아니다. 성능을 향상시키기 위해서는 비지니스의 논리를 올바르게 보존하고 쿼리튜닝과 같은 보조로직의 튜닝에 집중해야 한다. 예를 들어 JPA N + 1문제가 생겨도 비지니스의 기능은 수행된다. 결론적으로 우리 백엔드 개발자는 비지니스 논리를 올바르게 작성하는 것과 성능을 향상시키는 것은 다르다는 것을 인지해야 한다.
위의 단락에서 이야기한 관점을 잘 이해하면 관심사 분리의 중요성을 알 수 있다. 관심사 분리가 잘 되어야 무엇이 문제이고 무엇에 집중하여 개선할지가 분명해지기 때문이다. 관심사 분리를 잘하기 위해서 원칙이 필요하고 이러란 원칙을 지키기 위한 토대가 아키텍쳐라 할 수 있다. 개인적으로 서비스의 로직과 성능의 관심사에 대해 분리를 잘한 Architecture는 Hexagonal Architecture라 생각한다. 기회가 된다면 Hexagonal Architecture를 참고해보면 좋을 거 같다.
추가로 이 영역에서 주의할 점은 I / O를 최대한 최소화 시킬 수 있는지 확인하고, I / O를 짧게 끊어줄 수 있으면 짧게 끊어주는 것이 매우 중요하다. 그리고 Presentation Tier은 한 명의 사용자에게 개인화된 특징이 있는 반면 서버는 개인화된 여러 다수 사용자가 동시에 수많은 요청을 할 수 있다는 점을 이해하고 대응하는 것이 중요하다. 이 부분은 CPU, RAM, Thread의 지표를 잘 확인하여 특정 문제가 되는 지표에 대해 분석하여 튜닝을 진행하고 추가로 Infra 영역에서 Scale-In, Scale-Out으로 해결을 기대할 수 있다. 더 나아가 Blocking I / O, NonBlocking I / O의 관점을 도입해서 해결을 기대할 수 있다.
Data Tier
실질적으로 데이터를 저장, 관리, 제공하는 역할을 담당하는 부분이다. 이 영역이 어떠한 행위를 할 것인지에 대한 방향성을 Application Tier에 의해 결정되지만 실질적으로 수행하는 부분이기 때문에 이 부분에 대한 튜닝 (Ex) Indexing)을 잘하면 단기적인 성능 향상을 기대할 수 있다. Application Tier에서 보조로직을 튜닝을 했을 때 성능 향상을 기대할 수 있는 이유이기도 하다. Application Tier와 Data Tier의 관계는 Application Tier가 Data Tier에 방향성을 알려주고 이러한 수행은 Data Tier에서 이루어진다. Application Tier의 구조를 리팩토링 했을 때 당장 성능향상을 기대할 수 없지만 점진적인 성능향상을 기대할 수 있는 이유이기도 하다. 일관적이고 구조적인 Application Tier는 올바른 방향성을 Data Tier에 더 잘 알릴 수 있기 때문이다.
이 영역에서 우리 백엔드 개발자가 주의해야 할 점은 우리가 방향성을 알렸을 때 실질적으로 DBMS에서는 어떠한 동작이 이루어지는지 잘 확인해야 한다. 예를 들어 JPA를 사용한다고 해도 실제 어떠한 SQL이 DBMS에 전달되고 이 쿼리를 수행하는 Optimizer가 Full Scan인지 Index Scan 인지 어떠한 Index를 사용하는지 Join은 어떠한 Join을 걸고 복합적으로 확인하여 판단하는 것이 중요하다.
소통
작은 스타트업에서 백엔드 개발자는 Application Tier, Data Tier, Infra와 관련하여 모두의 역할을 수행할 수 있어야 하겠지만, 만약 규모가 있는 회사에는 각 직군의 개발자가 있을 것이다. 각 직군의 개발자는 각각의 Tier에서 집중하고자 하는 역할에 맞게 임무를 수행하고 있을 것이다. 이러한 경우 우리 백엔드 개발자는 비지니스를 가장 잘 알고 중앙에서 소통해야 하는 역할이라는 점을 이해하고 의사결정을 할 수 있어야 한다.
예를 들어 특정 테이블에 여러 Index가 필요할것이다. 그리고 이러한 Index를 DBA 관계자분께서 Index에 대해 관리하고 있을 것이다. 그렇다면 백엔드 개발자는 어떤 비지니스 상황에서 Index가 필요하고 필요 없는지 정확히 알고 필요하다면 요청을 할 수 있어야 하고, 현재 삭제를 하면 안 되는 이유를 말할 수 있어야 한다. 또한 필요 없다면 필요 없는 이유를 정확히 전달하여 DBA 분께서 명확한 근거로 삭제할 수 있도록 도와야 한다.
인프라 관점에서는 만약 특정 시간에만 트래픽이 몰린다고 가정해보자. 현재 띄어져 있는 서버 Instance 수로 그 특정 시간에는 감당하기 힘들다는 지표를 확인하면 이러한 지표를 근거로 특정시간에 추가로 Instance를 띄울 수 있는지에 대한 설명을 Infra 담당자분께 하여 조정할 수 있어야 한다.
마무리
Application Tier에 속한 백엔드 개발자는 무엇보다도 비지니스를 잘 이해해야 한다. 세상은 변하고 비지니스도 변한다. 그러니 꾸준한 비지니스 (도메인)에 대한 이해를 하는 노력이 매우 중요한 것 같다. 또한 요즘은 AI를 이용해 개발을 많이 진행한다. AI의 효용성을 생각해보면 AI는 특정 기능을 작성하는데 있어서는 탁월하다고 생각하다 그러나 AI는 비지니스를 모른다. 비지니스는 개발을 하는 개발자가 더 잘 안다. 모든 맥락과 상황을 AI가 파악할 수 없기 때문이다. 즉, 융합은 사람이 더 잘한다. 이러한 관점을 봤을때도 백엔드 개발자는 비지니스의 논리, 데이터를 매우 잘 이해해야 한다는 사실은 분명한 사실인 거 같다.
