분산 시스템의 특징 5가지

글을 쓰기에 앞서, 시스템 디자인 카테고리를 새로 만든 이유를 얘기하겠다. 누군가 시스템 디자인에 대한 공부가 필요하다는 얘기를 듣고, 시스템 디자인 인터뷰에 대한 공부를 하게 되었는데, 사실 이게 인터뷰를 위한 것이라기보다는 백엔드 개발자라면 알아야 할 덕목에 가깝다고 느꼈다. 완벽한 정리는 아니겠지만, 핵심을 잘 담고자 노력할 예정이니 봐주길 바란다.

먼저 시스템 디자인의 기본을 보자.

만약 거대한 시스템을 디자인한다고 할 때 우리는 아래 3가지를 고려해야 한다.

1. 어떤 다른 아키텍쳐적인 파트들이 사용될 수 있을까?
2. 이러한 아키텍쳐적인 파트들이 어떻게 상호작용을 하며 작동할까?
3. 이러한 파트들을 어떻게 하면 가장 최고로 잘 이용할 수 있을까? Trade-off 는 어떻게 될까?

즉, 위의 3가지 얘기는, 훌륭한 시스템 디자인을 위해서는 1,2,3을 모두 고려하고, 시스템의 특성에 따라 Trade-off를 잘 고려하여 시스템을 디자인해야함을 말한다. 가령 지급 결제와 관련된 시스템은 Reliability를 극대화 시켜 빌링 데이터를 충분히 신뢰할만한 수준으로 만들어야 할 것이다. 대신 비용이 더 발생하겠지..? 이런 비즈니스 상황에 따른 트레이드 오프를 복합적으로 고려하여 아키텍쳐 조각들을 잘 설계해야하는 것이다.

그럼 라지 시스템 설계와 관련된 분산 시스템의 핵심 특징을 알아보자.

• Scalability(확장성) - Scalable할 수 있게..
  • 시스템의 수용 능력을 의미한다. 주로 시스템, 프로세스, 혹은 증가된 시스템 이용량 요구치에 맞춰 네트워크 량 등을 늘릴 수 있는 능력을 말한다.
  • Scalable한 시스템이라는 것은 퍼포먼스 손실 없이 이러한 스케일링을 잘 견디는 것을 말한다.
  • Horizontal vs vertical Scaling?
    • Horizontal 은 물리적인 서버 장비를 병렬로 추가 하여 스케일러블 하게 만드는 것을 말함(ex. Cassandra or Mongodb 같은 경우 손쉽게 장비를 추가함으로서 수평 스케일 효과를 줌)
    • Vertical 은 물리서버 자체의 스펙을 늘려 스케일러블하게 만드는 것(ex. MySQL, 손쉽게 작은 장비에서 더 큰(사양이 좋은) 장비로 스케일 업할 수 있는데, 단점은 다운타임(중단 시간)이 발생함)
• Reliability(신뢰성) - 신뢰할 수 있는 능력(the probability that a sys will fail in a given period.)
  • 사실 Reliability는 정의에 따르면 어떤 주어진 시간동안 시스템이 장애가 일어날 가능성을 말한다.
  • 이러한 장애 가능성을 줄이기 위해, Redundancy하게 시스템을 설계하여, 어떤 장비에서 fail이 나더라도 다른 장비가 이를 대체하도록 한다.
  • 즉, Reliability를 어느정도 높이기 위해서는 Redundancy를 고려해야 하며, 이것이 곧 비용임. (가령 아마존의 상거래 트랜잭션은 절대 소실되거나, 오류가 나면 안되니, Reliability에 많이 투자해야 함)
• Availability(가용성) - 시스템이 특정 시간동안 요구치에 대해 계속 작동하는 능력을 말함
  • Reliability와 약간 비슷하긴하지만, 반대의 개념으로 생각하자. reliability는 장애가 날 확률, availibility는 잘 작동되는 능력이니, 반대 개념임..
  • If sys reliable -> available ok 임. 하지만, available -> reliable (x) 임. 뭐 예로들면, 99.99% availability를 가진 시스템이 있는데, 이것이 Security Testing 없이 단순 장비 빨로 저정도를 유지하고 있다고 하자. 겉으로는 고가용성을 갖지만, 리스크를 많이 갖기 때문에 신뢰성은 보장하지 못한다.
  • 주로 가용성의 측정은 특정 시간동안 과연 몇% 시간동안 제대로 잘 작동했는지 측정하면 된다. (즉, 장애 타임을 제외한 나머지 시간이 차지하는 비중이다.)
• Efficiency(효율성) - 응답시간과 쓰루풋을 고려한 능력치를 말함. 이 두 가지를 아래에 정리해보자.
  • 효율성의 대표적인 척도 2가지는 1. 응답시간, 2 스루풋임
  • 응답시간(Response time or Latency): 어떤 요청에 대해 얼마나 지연되서 응답을 받는지
  • 스루풋(throughput): 단위 유닛 시간 동안 얼마나 많은 요청량이 전달되는지
  • 물론, 저 2가지가 효율성 측정의 모든 척도는 아니지만, rough 하고, 가장 기본이 된다.
• Serviceability or Manageability(관리성)
  • 관리성은 시스템에 문제가 발생했을 때, 이를 이해하고, 손쉽게 진단하게 해주는 능력임
  • 예로 들면, 엔터프라이즈 레벨에서는 관리성을 올리기 위해, 장애가 발생하면 자동으로 서비스 센터에 콜을 하는 시스템 등을 갖추고 있다.