본문 바로가기
  • Where there is a will there is a way.
개발/기타개발

애플리케이션 설계 ( 신뢰, 확장성, 유지보수성 )

by 소확행개발자 2020. 5. 9.
컴퓨터의 성능이 발달된 요즘 더이상 CPU 의 성능은 애플리케이션을 제한하는 요소에 우선순위에서 밀렸다.
 CPU 의 성능보다 우선적으로 고려되는 사항은 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도이다.

 

애플리케이션을 설계 및 개발할때 서버 개발자는 다음과 같은 고민을 한다.

 

내부적으로 데이터를 정확하고 안전하게 유지하려면 어떻게 해야 할까?

시스템의 일부 성능이 저하되더라도 클라이언트에 일관되게 좋은 성능을 어떻게 제공할까?

부하 증가를 다루기 위해 어떻게 규모를 확장해야 할까? 

어떤 api 가 좋은 서비스인가 ?

 

현재 읽은 책은 데이터 중심 애플리케이션이고 여기서 이야기하는 위와같은 고민은 

3가지를 중점으로 다룬다.

 

신뢰성 ( Reliability )

하드웨어 결함이나 소프트웨어 결함에 직면했을때 리턴되는 데이터는 얼마나 신뢰할 수 있는가?

 

확장성 ( Scalability )

시스템의 데이터 양, 트래픽 양, 복잡도가 증가할때 어떻게 효과적으로 처리할 것인가?

 

유지보수성 ( Maintainability )

시간이 지나면서 여러 사람들이 시스템 상에서 작업할 때 어떻게 생산적으로 작업할 것인가 ?

( 일하다 보면 퇴사자의 코드를 봐야할 일이 생기기 때문이다 )

 

신뢰성

소프트웨어 오류와 인적 오류가 존재하는데, 이를 해결할 수 있는 방법은 

  • 오류의 가능성을 최소화하는 방법으로 시스템을 설계하는 방법 -> 추상화 API ,  관리 인터페이스를 사용
  • 장애 발생가능구역을 예측하고 해당 부분을 분리하라 ( 추상화 및 예외처리 )
  • 단위테스트 - 시스템 통합 테스트까지 모든 수준에 테스트가 다뤄져야 한다.
  • 롤백을 만들어 놓는다. -> 복구가능하게 만들어 놓음
  • 성능, 오류율 같은 상세하고 명확한 지표의 모니터링 대책을 마련하라.

 

확장성

확장성을 이해하는데는 어떤 애플리케이션은 확장 가능하다. 확장성이 없다. 이렇게 이야기 하는것이 아니다.

특정 애플리케이션이 부하가 증가하면 이를 다루기 위해 어떤 방식을 사용해야 하나를 이야기 해야한다.

 

부하를 기술하기 위해 몇가지의 매개변수가 있다.

  • 웹 서버의 초당 요청 수
  • 데이터베이스 읽기 대 쓰기 비율
  • active user ( ex 대화방의 동시 활성 사용자 or 스트리밍 시청자 수 )
  • 캐시 적중률

부하를 줄이기 위한 노력

 

흔히 예시로 트윗을 들 수 있다.

흔히 우리가 설계할 때 사용자가 트윗을 하게 되면 기본적으로 타임라인을 조회하게 된다.

 

나의 타임라인은 내가 팔로우한 사람의 글을 볼 수 있는데 이 작업은 기본적으로 트윗의 데이터베이스에서 정보를 가져올 것이다.

 

select tweets.*, users.* from users
	join users on tweets.sender_id = users.id
    join follows on follows.follwee_id = users.id
    where follows.follower_id = current_user

이렇게 되면 많은 사람들이 트윗에서 읽을 때마다 데이터 베이스에 무리한 부하가 걸리지 않겠는가 ?

 

트위터는 이를 해결하기 위해서 

 

사용자가 트윗을 작성하면 사용자의 팔로워들의 타임라인 캐시에 ( 타임라인을 캐시한다 ) 해당 데이터를 삽입하고 캐시한다. 가 된다. 

해당 설계 대로라면 읽을때 부하가 줄어들기 때문에 데이터베이스에 무리한 부하가 걸리지 않는다. 

 

그렇다면 위의 설계는 괜찮은 설계인가 ? 

답은 없다. 만약에 트윗터의 팔로워 수가 몇만이면 ? 몇천이면 ? 우리가 흔히 인스타 스타라고 하는 사람도 그렇지 않은가? 그렇다면 해당 대스타가 트윗을 작성할때마다 몇만의 읽기 쓰기가 일어나게 되는것이 아닌가

 

그렇기 때문에 두가지를 혼용하는 방법을 사용한다. 팔로워 수가 몇천 이상이 되면 첫번째 방법을 아니면 두번째 방법을

 

유지보수성

소프트웨어 비용의 대부분은 초기 개발보다는 지속해서 이어지는 유지보수에 들어간다. 이런 유지보수에는 버그 수정, 시스템 운영 유지, 장애 조사, 새로운 플랫폼 적응, 새 사용 사례를 위한 변경, 기술 채무 상환, 새로운 기능 추가 등이 있다.

 

대부분의 개발자는 레거시 시스템 유지보수를 달가워하지 않는다. 그렇기 대문에 소프트웨어를 처음에 설계할 때 중요하다.

 

소프트웨어 시스템 설계 원칙 3가지

 

운용성

운영팀이 시스템을 원할하게 운영할 수 있게 쉽게 만들어라

 

단순성

시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라

-> 굉장히 어려운 과제인것 같다. 비즈니스는 복잡하고 추상화를 최대한 하더라고 어느정도의 타협이 필요하지 않을까.. 

-> 아직 1장을 읽고있어서 그럴지도 모르지만 말이다.

 

발전성

엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라

 

댓글