데이터 중심 애플리케이션 설계 #1장

1장

신뢰성, 확장성, 유지보수성 이 3가지 관심사를 엔지니어링 측면에서 생각해보자.

• 신뢰성 : 하드웨어 / 소프트웨어 / 인적 오류 같은 역경에 직면하더라도 시스템은 지속적으로 올바르게 동작해야 한다.
• 확장성 : 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야 한다.
• 유지 보수성 : 시간이 지나면서 여러 다양한 사람들이 시스템 상에서 작업할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다.

 

신뢰성

“무언가 잘못되더라도 지속적으로 올바르게 동작함”을 신뢰성의 의미로 이해할 수 있다.

잘못될 수 있는 일을 결함(fault)라 부르며, 이를 예측하고 대처할 수 있는 시스템을 내결함성(fault-tolerant)을 지녔다고 한다.

고의적으로 결함을 유도하여 내결함성 시스템을 지속적으로 훈련하고 테스트해서 결함이 자연적으로 발생할 때 올바르게 처리할 수 있는 자신감을 높인다. 넷플릭스의 카오스 몽키가 이런 접근 방식의 한 예다.

인적오류

인간을 완전히 신뢰할 수 없음에도 시스템을 어떻게 신뢰성 있게 만들까? 최고의 시스템은 다양한 접근 방식을 결합한다.

• 오류의 가능성을 최소화 하는 방향으로 시스템을 설계하라. ex) 잘 설계된 추상화, API, 관리 인터페이스를 사용
• 사람이 많이 실수하는 장소에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라.
• 단위 테스트부터 전체 시스템 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트하라.
• 성능 지표와 요류율 같은 상세하고 명확한 모니터링 대책을 마련하라.

 

확장성

증가한 부하에 대처하는 시스템 능력을 설명하는 용어지만 시스템에 부여하는 일차원적인 표식이 아니다.(?)

확장성을 논한다는 것은, “시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가?” 와 “추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?” 같은 질문을 고려한다는 의미다.

 

부하 기술하기

시스템의 현재 부하는 부하 매개변수 처럼 간결하게 기술해야 한다.

• 부하 매개변수 예시 : 웹 서버의 초당 요청 수, DB의 읽기대 쓰기 비율, 대화방의 동시 활성 사용자, 캐시 적중률 등
• 트위터의 경우, 사용자당 팔로워의 분포가 팬아웃 부하를 결정하기 때문에 확장성을 논의할 때 핵심 부하 매개변수가 된다.

 

성능 기술하기

서버-클라이언트 간 응답시간으로 성능을 기술하고 싶을 수 있다.

이때 전형적인 응답 시간을 알고 싶다면 평균은 그다지 좋은 지표가 아니다. 얼마나 많은 사용자가 실제로 지연을 경험한지 알려주지 않기 때문이다. 평균보다는 백분위를 사용하는 편이 더 좋다. 응답 시간 목록을 순서대로 정렬하면 중간 지점이 중앙값(median) 이 된다.

위 그래프를 예시로 보자. 응답값이 얼마나 좋지 않은지 보려면 상위 백분위를 살펴보는 것도 좋다. (이때 사용하는 백분위는 95분위, 99분위, 99.9분위가 일반적) 위 그래프를 토대로 95분위 응답 시간이 1.5초라면 100개의 요청 중 95개는 1.5초 미만이고, 100개의 요청 중 5개는 1.5초보다 더 걸린다.

상위 백분위 응답 시간(꼬리 지연시간)은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요하다. 아마존에서는 내부 서비스 응답 시간 요구사항을 99.9분위로 기술하는데 이는 요청 1000개 중 1개만 영향이 있음을 의미한다. 보통 응답시간이 가장 느린 요청을 경험한 고객들이 많은 구매를 해서 고객 중 계정에 가장 많은 데이터를 갖기 때문이다. (즉 우수 고객이라는 의미). 이 고객들을 만족시키는게 중요하다.

 

부하 대응 접근 방식

Q. 부하 매개변수가 증가하더라도 좋은 성능을 유지하려면 어떻게 해야할까?

A. 애플리케이션에 적합한 확장성을 갖춘 아키텍처는 주요 동작이 무엇이고 잘하지 않는 동작이 무엇인지에 대한 가정을 바탕으로 구축한다. 이 가정이 곧 부하 매개변수가 된다. 이 가정이 잘못되면 확장에 대한 엔지니어링 노력은 헛수고가 되고 최악의 경우 역효과를 낳는다.

“일부 시스템은 탄력적” 이란 문장은, 시스템이 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있는 것을 의미한다. 탄력적인 시스템은 부하를 예측할 수 없을 만큼 고부하 상황에서 유용하다.

반면 “탄력적이지 못한 시스템”은 수동으로 컴퓨팅 자원을 확장해야 하는데, 예상치 못한 부하가 발생하는 상황을 제외하면 더 간단하고 운영상 예상치 못한 일이 더 적다.

 

유지보수성

 

유지보수 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계할 수 있는 시스템 설계 원칙 3가지.

1. 운용성
   1. 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라
2. 단순성
   1. 시스템 복잡도를 최대한 제거하여 엔지니어가 시스템을 이해하기 쉽게 만들어라
3. 발전성
   1. 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 해라.

 

운용성

 

시스템이 원활하게 작동하려면 운영팀이 필수다. 좋은 운영팀은 다음과 같은 작업등을 책임진다.

 

좋은 운용성이란 동일하게 반복되는 태스크를 쉽게 수행하게끔 만들어 운영팀이 고부가가치 활동에 집중한다는 의미한다.

 

단순성: 복잡도 관리

 

복잡도는 다음과 같이 다양한 증상으로 나타난다.

• 상태 공간의 급증(?)
• 모듈 간 강한 커플링
• 복잡한 의존성
• 일관성 없는 명명과 용어
• 임시 방편으로 문제를 해결한 특수사례

시스템을 단순하게 만드는 일이 반드시 기능을 줄인다는 의미는 아니고, 우발적 복잡도를 줄인다는 뜻일 수 있다. 우발적 복잡도를 제거하는 최상의 도구는 추상화다. 좋은 추상화는 깔끔하고 직관적인 외관 아래로 많은 세부 구현을 숨길 수 있다. 또한 다른 다양한 애플리케이션에도 사용 가능하다.

발전성 : 변화를 쉽게 만들기

소프트웨어는 끊임없이 변화하는 것이 섭리다. 조직 프로세스 측면에서 애자일 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다. 좋은 예시로 TDD 와 Refactoring이 있다.

 

정리

 

애플리케이션이 유용하려면 기능적 요구사항과 비기능적 요구사항(보안, 신뢰성, 법규 준수, 확장성, 유지보수성 등)을 충족해야 한다.

신뢰성은 결함이 발생해도 시스템이 올바르게 동작하게 만든다는 의미다. 내결함성 기술을 최종 사용자에게 특정 유형의 결함을 숨길 수 있게 해준다. (에러 메시지 팝업 같은건가)

확장성은 부하가 증가해도 좋은 성능을 유지하기 위한 전략을 의미한다.

유지보수성의 본질은 시스템에서 작업하는 엔지니어와 운영 팀의 삶을 개선하는데 있다.