Quality Attributes
품질 속성은 굉장히 다양하다. Performance, Scalability, Availability, Fault Tolerance, Testability, Deployability ... 모든 품질 속성은 서로 trade-off 관계에 있는 경우가 많을 뿐더러 설계하고자 하는 시스템에서 중요하게 생각하는 품질속성이 정해져 있는 경우가 많다. 다양한 품질속성중 Performance, Scalability, Availability, Fault Tolerance에대해 살펴보려고 한다.
Performance
Performance는 주로 Response Time,Throughput로 구성된다.
Response Time은 client가 요청을 보내서 응답을 받기까지 걸리는 시간이다. 주로 Processing Time과 Waiting(Latency) Time의 합으로 나타낸다. Processing time은 응답을 보내기위해 시스템에서 일을 처리하는데 걸리는 시간을 나타내며 Waiting Time은 시스템이 요청을 처리하기 직전까지 걸리는 시간과 요청이 처리된후 client가 응답을 받기까지 걸리는 시간의 합이다. 종종 Response Time과 Waiting Time을 Latency Time으로 부르기도 하지만 용어상의 혼란을 막기 위해 보통 Response Time은 End to End Latency Time으로 부른다. Throughput은 시스템이 단위시간동안 처리한 일의 양을 나타낸다. tasks/second, bits/second 와 같은 표현방식을 많이 사용한다.
응답 시간을 측정하는 방법은 다양하다. 많은 경우에 백분위를 사용한다. 왜냐하면 응답 시간은 Long tail 분포를 가지는 경우가 많고 서비스 사용경험에는 이러한 극단적 상황이 많은 영향을 미치기때문이다. 그래서 '95th percentile의 응답시간이 30ms 이하'와 같은 목표를 설정한다.
응답 시간과 처리량의 성능을 측정할때 Performance Degradation 도 사용한다. Performance Degradation은 부하에 따른 성능 척도 그래프를 나타내게 되면 특정 부하부터 성능이 하락하는 현상을 말한다. 다양한 요인으로 발생할 수 있는데 CPU/memory의 과도한 사용 빈번한 I/O, 너무 많은 네트워크 connection, 시스템에 들어오는 메시지를 감당할 수 없는 경우가 있을 수 있다.
Scalability
Scalability는 변화하는 부하에 자원을 쉽고 비용 효율적으로 추가하여 대응하는 능력을 말한다. 가장 이상적인 경우는 자원과 시스템 성능이 선형적인 관계를 가질때지만 현실세계에서는 여러가지 요인으로 그렇지 않다.
Scalability에는 Vertical, Horizontal, Team/Organization Scalability가 존재한다.
Vertical Scalability는 단일 인스턴스의 CPU, memory와 같은 것을 추가하는 것을 말한다. 이 방법은 단지 단일 머신의 성능을 업그레이드 하는 것이기 때문에 코드를 변경하지 않아도 되고 마이그레이션이 쉽다. 하지만 단일 머신로 발휘할 수 있는 성능은 제한되어 있고 중앙 집준화된 방법이다 보니 고가용성, 내결함성을 갖추기 힘들다는 단점이 있다.
Horizontal Scalability는 인스턴스의 개수를 늘려 부하를 분산하는 것을 말한다. 이 방법은 단순히 머신을 추가/삭제하는 방법이기 때문에 확정성에 제한이 없고 중앙집중화 된 방법이 아니기때문에 고가용성, 내결함성을 갖출수 있다. 하지만 code의 변경이 필요할 수 있고 복잡성이 증가한다는 단점이 있다.
Team/Organization Scalability는 구성원이 효율적으로 일할 수 있도록 조직을 구성하는 것을 말한다. 구성원이 증가하면 잦은 회의, 코드 병합 충돌 등으로 인해 비효율이 발생할 수 있다. 구성원을 모듈, 서비스로 나눠 의존성을 낮추면 이러한 문제를 해결할 수 있다.
Availability
Availability는 사용자가 정상적으로 서비스를 사용할 수 있는 시간의 비율을 나타낸다. Availability는 고객의 이탈률과 수익에 영향을 주기 때문에 굉장히 중요하다. Availability는 uptime/(uptime+downtime) 혹은 MTBF/(MTBF+MTTR) 로 나타낼 수 있다. uptime은 서비스가 정상적으로 동작한 시간 downtime은 서비스가 비정상적으로 동작한 시간을 나타낸다. MTBF는 Mean Time Between Failure의 약자이고 MTTR은 Mean Time To Recovery의 약자이다.
High Availability의 기준은 모호하나 보통 99%이상의 가용성을 일컫는 말이다. 가용성은 'nines'로 자주 표현한다. 99.9=3nines, 99.99=4nines와 같이 말이다.
Fault Tolerance
Failure는 발생하는 요인에 따라 Human, Software, Hardware로 나뉜다. Fault Tolerance는 이러한 다양한 요인으로 발생하는 Failure가 발생하더라도 시스템이 여전히 정상적으로 동작하는 것을 말한다. Fault Tolerance를 갖추는 방법은 Failure Prevention, Failure Detection & Isolation, Recovery가 있다.
Single Point of Failure를 없애면 전체 시스템이 다운되는 것을 예방할 수 있다. 단일 고장점을 없애는 가장 좋은 방법은 Replication과 Redundancy이다. Redundancy는 Spatial, Time Redundancy로 나뉜다. Spatial Redundacy는 서로 다른 머신에 application의 replica를 실행하는 것을 말하고 Time Redudancy는 성공할때까지 동일한 동작을 반복하는 것을 말한다. Spatial Redudancy는 Active-Active, Active-Passive architecture로 나뉜다. Active-Active는 모든 replica가 부하를 분산하기 위해 실제로 동작하는 수평적 확장을 나타낸다. Active-Passive는 실제 동작하는 머신이 주기적으로 Passive 머신에 snapshot을 저장하는 방식이다.
Failure Detection & Isolation 방법은 머신에 Failure의 발생을 주기적으로 체크하고 Failure가 발생한 머신이 감지되면 더 이상 해당 머신은 요청을 처리하지 않도록 Isolation하는 방법이다. Failure를 감지하기 위해선 Monitoring Service를 구동해야하며 이것은 Heartbeat와 같은 방법을 통해 각 머신이 잘 동작하는지 주기적으로 확인한다. 일정 시간내로 응답이 오지 않으면 문제가 있는 머신으로 판단하기 때문에 문제가 없는 머신인데도 네트워크나 long garbage collection과 같은 문제로 잘못 판단하는 False Positive 경우도 종종 발생한다. False Negative은 오류를 감지하지 못하는 경우이기 때문에 심각한 문제를 발생시킬 수도 있다. Heartbeat 외에도 단위시간당 error의 수, 응답시간 체크와 같은 방법으로 모니터링 할수도 있다.
Recovery는 Failure가 발생하면 이를 빠르게 해결하는 것을 말한다. Availability는 MTBF/(MTBF+MTTR)로 나타낼 수 있다. MTTR을 0과 가까운 값으로 만들 수 있다면 HA를 보장할 수 있다.
SLA, SLO, SLI
실제 서비스를 디자인할때 SLA, SLO, SLI라는 용어를 사용한다. SLA는 Service Level Agreement의 약자로 서비스에서 보장하는 Quality와 이를 지키지 못했을때의 보상에 관련된 법적 계약서이다. SLO는 Service Level 의Objective의 약자로 시스템이 설정한 Quality Attribute의 목표를 나타낸다. SLI 는 Service Level Indicator의 약자로 SLO를 정량적으로 측정한 것으로 SLO를 잘 지키고 있는지 확인할 수 있다. SLA는 business, legal team에 의해 작성되고 SLO, SLI는 engineer에 의해 정의된다.
SLO, SLI를 다룰때 주의사항이 존재한다. 먼저, 측정가능한 모든 SLI를 SLO로 설정하는 것은 바람직하지 않다. 왜냐하면 모든 SLO를 동일한 수준으로 보장하는 것은 어렵고 오히려 혼란을 야기할 수도 있다. 다음으로, 실현가능한 SLO를 설정하는 것이 바람직하다. 외부 목표, 내부 목표를 나눠 외부 목표를 내부 목표보다 더 느슨하게 설정하여 SLO를 지키려고 노력하기도 한다. 마지막으로 SLI 상에서 SLO를 만족하지 못할때를 대비해 recovery plan을 만드는 것이 중요하다.
