[ASAC 06] 백엔드 개발의 목적

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.  

 

백엔드 개발의 목적

=> 데이터 관리 : 데이터에 대한 모든것 (저장, 조회 및 조작)

 

API = 클라이언트가 원하는 웹 데이터 를

1. 어떻게 
2. 잘
   반환할까?

1. 어떻게

반환의 형태 : REST API, GraphQL, Queue, Websocket, SSE

API

• REST API
  • 어떤 구매건이고 (url) : REST API 형식 https://aaron.com/payments/13/update
  • 어떤 걸로 (변수) : path variable, query parameter 또는 json 형태의 request body
  • 바꿀 것인가요? (method) : POST

서버가 제공하는 데이터를 사용하는 주체는 클라이언트이고,

어떤 요청을 주면 어떤 응답을 주는지는 백엔드 개발자가 정의한다.

 

클라이언트는 사용만 하기 때문에 내부에서 구체적으로 어떻게 동작하는 지는 몰라도 된다.

이를 Interface와 Concrete Class 개념에서 설명하겠다.

 

• Interface : 추상적인 영역.
  • 추상 = 사용 성만 제공한다.
• Concrete Class : 인터페이스에 대한 구체화.
  • 구체 = 실제 처리를 위한 원리 . 실제 구현

백엔드 개발자는 클라이언트가 사용할 데이터를 1. 구체적으로 구현하고, 유저에게 2. 사용 방법을 제공하기 위해 API Spec을 명시해주면 된다.

 

유저는 내부 원리는 알지 못하고(알 필요가 없고) API Spec만 보고 원하는 데이터를 서버로 요청하여 사용하면 된다.
결국 API는 클라이언트 관점에서 정의라고 할 수 있다.

 

그래서 유저가 직접 사용하게 되는 추상적인 영역만 동일하다면, 내부 원리(구체, 로직)은 언제든지 뒤바뀌어도 된다.

• 다형성
  => 하나의 인터페이스에 대해서 여러 구체 클래스(Concrete Class)가 있을 수 있다. 같은 인터페이스를 공유하기 때문에 언제든지 구체 클래스를 갈아끼워도 된다.

+) Postman은 기존에는 서버에 데이터를 요청하는 클라이언트 역할로 사용 되었으나, 최근에는 API Spec을 정의하는 Document로 사용되기도 한다.

2. 잘 = 속도 + 가용성

=> 요청-응답의 속도 및 대량 트래픽 커버

백엔드 개발자는 다음 두 가지 입장에 있을 수 있다.

1. 서비스 제공자 입장
   => 웹 서비스를 클라이언트에게 제공 (Server)
2. 서비스 사용자 입장
   => 웹 서비스 개발을 위해 클라우드 서버를 사용 (Client)

클라우드 서버를 사용 시 내 애플리케이션에는 문제가 없지만, 클라우드 서버의 가용성이 좋지 않은 경우 문제가 될 수 있다. 그래서 클라우드 서버들은 99% 이상의 가용성을 제공하며, 소수점까지 가용성을 보장한다. (약 99.25% ~ 99.74%)

 

클라우드 서버의 가용성은 백엔드 개발자가 신경쓰지 않아도 된다. (클라우드 서비스 개발자가 아니라면) 그래서 개발자는 자신이 개발하는 서비스의 가용성에 대해서 초점을 맞추어 속도와 가용성을 보장하면 된다.

가용성을 높이는 방법

1. Load Balancing
2. MSA (Micro Arcitecture Service)

성능을 높이는 방법

• DB 조회 시 쿼리 속도 향상
• 대량 트래픽에 기인한 DB 조회 시, 부담 축소 및 속도 향상을 위한 로컬 / 글로벌 캐시 도입
• 대량 트래픽에 따른 DB 접속 시 동시성 처리
  => 트랜잭션
  트랜잭션의 수가 많아진다면, 트랜잭션 스케줄을 관리해야 한다.
  => Isolcation Level(격리 수준)을 낮추어, 트랜잭션 간 충돌이 일어나지 않는 전제 하에 한 트랜잭션 실행 중 다른 트랜잭션의 연산을 수행한다. 이로써 속도를 높일 수 있다.