서버 개발 고민

 일반적으로는 클라이언트에서 요청이 오면 DB 쿼리를 이용하여 상호작용하는 일을 떠올릴 것 이다.

내가 경험해본 업무 중 7, 8할 이상도 이러한 작업이 주가 된 적이 대부분이었고,

이러한 작업은 거의 반복 적인 작업이었다. 그런데 최근 회의 중 이런 이야기가 오고 갔다.

요약해보면 다음과 같다.

 

A : " xx 기능이 추가되면서 서버가 더 많은 요청을 처리 하게 되었습니다.

  기존 서버로는 원활한 처리가 어려울 것 같으므로 xx기능 처리를 위한 서버를 증설할 필요가 있습니다."

B : "그건 이해하지만, 서버 증설은 비용 문제도 고려해야 합니다.

  새로운 서버를 추가하려면 추가 비용이 발생하고 유지 관리에도 비용이 듭니다."

C : "기존 서버 만으로는 추가된 요청을 처리하는 것은 무리일 것 같습니다.

  현재 시스템 아키텍처는 이런 요청을 고려하고 설계하지 않았기 때문이에요."

 

 위와 같은 흐름으로 이어지고 있는 대화를 듣고 있다 보니, 문득 얼마 전에 데이터베이스에 문제가 생겨

공지를 보내야 할 상황도 생각났다. 내용은 대략 다음과 같았다.

 

A: “… 데이터 복구를 위해 최근의 데이터베이스 백업을 검토하여 손실 된 데이터의 범위를 확인하고

  복구 가능한 데이터를 확인하고 있습니다. DB 서버의 트랜잭션 로그 파일을 분석하여

  데이터 복구에 필요한 정보를 확보 중입니다. 데이터 복구 작업을 최대한 신속하게 처리하겠습니다 …”

 

이런 생각들이 꼬리에 꼬리를 물어, 서버 구조 설계의 중요성에 대해 다시 한번 상기하게 되었다.

 

 최초에 설계된 서버 구조는 나중에 재 설계하기 쉽지 않을 뿐더러, 시간이 지날수록 변경을 위한 비용이 점점 커진다.

이 때문에 시스템의 안정성, 확장성, 가용성, 성능, 비용 효율성 및 유지 관리성 등을 고려하여 설계되어야 할 뿐만 아니라

기술적인 측면과 더불어 비즈니스 목표와 사용자 요구 사항도 같이 고려되어야 할 것이다.

내가 이런 것들을 잘해내기 위해서는 무엇을 해보는 것이 좋을지 생각해 보게 되었다.

 

우선, 이번 기회를 통하여 맨 처음에 웹을 공부하면서 만든 단일 서버 구조부터 실무에서 다뤄본 몇 가지의 서버 구조,

그리고 최근에 공부하고 있는 서버 구조들까지 정리해 보는 시간을 갖으려고 한다.

또한 서버 구조가 확장되어 가면서, 내부에서 사용해본 도구나 기술들도 함께 정리해 보려고 한다.