신뢰성, 확장성, 유지보수성을 가진 애플리케이션
Compute-intensive(계산 중심) vs Data-intensive(데이터 중심)
과거에는 CPU 성능이 애플리케이션을 제한하는 요소였지만 오늘날에는 그렇지 않습니다. 최근에는 데이터의 양, 데이터의 복잡도, 데이터의 변화 속도가 애플리케이션을 제한하는 요소가 되었습니다. 이렇게 애플리케이션에서 사용하는 데이터의 특징에 맞춰서 설계를 해야 합니다. 그래서 이러한 애플리케이션을 Data-intensive application(데이터 중심 애플리케이션)이라고 합니다.
일반적으로 데이터 중심 애플리케이션은 다음과 같은 구성 요소를 가집니다. 꼭 데이터 중심 애플리케이션이 아니더라도 애플리케이션의 요구 사항에 따라 필요한 것들이 달라질 것입니다.
- Database
- Cache
- Search index
- Stream processing
- Batch processing
각각의 요소가 무엇인지는 따로 설명하진 않겠습니다. 책에서는 이러한 구성 요소들을 요구사항에 맞추어서 조합한 것을 데이터 시스템이라고 하고 있습니다. 즉, 데이터베이스, 큐, 캐시 등을 다른 범주에 속한 것이 아닌 데이터 시스템이라는 것에 포함되어 있는 것이죠. 위에서 다양한 구성요소를 결합한 데이터 시스템 아키텍처의 예는 다음과 같습니다.
이렇게 최근의 애플리케이션의 요구사항이 늘어남에 따라 애플리케이션 개발 뿐만 아니라 데이터 시스템 설계도 함께 해야 합니다. 그럼 이러한 데이터 시스템을 설계 시 고려사항은 무엇일까요? 저자는 다음 3가지 관심사에 중점을 두고 있습니다.
- Reliability(신뢰성)
- Scalability(확장성)
- Maintainability(유지보수성)
이와 같은 고려서항은 일반적인 소프트웨어 시스템에서도 중요하게 여기는 것입니다. 다음은 각각의 가진 의미를 살펴보도록 하겠습니다.
Reliabilty(신뢰성)
신뢰성이란 다양한 의미가 있겠지만 일반적으로 “무언가 잘못되더라도 지속적으로 올바르게 동작함"을 이야기 합니다. 시스템에서 잘못될 수 있는 일을 fault(결함) 이라고 합니다. 그래서 보통은 이러한 결함에 대처할 수 있는 시스템을 feault-tolerant(내결함성) 시스템이라고 합니다. 결함의 유형은 다음과 같습니다.
- 하드웨어 결함
- 하드디스크 고장, 램 결함, 정전 등
- 일반적으로 하드웨어의 구성 요소를 중복(redundancy)을 추가하여 대응
- 디스크 RAID 구성
- 이중 전원 디바이스 사용
- 예비 전원용 디젤 발전기 사용
- 소프트웨어 오류
- 커널 버그, 공유 자원을 과도하게 쓰는 프로세스 영향 등
- 빈틈 없는 테스트, 프로세스 격리, 모니터링 등을 이용하여 대응
- 인적 오류
- 하드웨어 결함에 비해 훨씬 높은 비율
- 잘 설계된 추상화, 샌드박스 사용, 단위 테스트부터 통합 테스트까지 철저하게 테스트 등을 이용해 방지
이렇게 각각의 결함에 대해 살펴보았고 각 결함은 어떻게 대응하는지 살펴보았습니다.
Scalabilty(확장성)
시스템에 부하가 증가할 때 대처가 가능한 시스템인지를 설명하는데 사용하는 용어가 확장성입니다. 부하란 load parameter(부하 매개변수)로 나타낼 수 있는데 부하 매개변수는 다음과 같은 것들이 있습니다.
- 웹 서버의 초당 요청 수
- 데이터베이스의 읽기 대 쓰기 비율
- 대화방의 동시 사용자 수
- 캐시 적중률
시스템마다 부하가 다르기 때문에 시스템에 맞춰 부하 매개변수를 정하고 그에 맞춰서 처리될 수 있도록 고민해야 합니다. 시스템 부하가 정의되었으면 부하가 증가할 때 시스템 성능에 어떠한 영향을 끼치는지 알 수 있습니다. 예를 들어 하둡과 같은 배치 시스템은 처리량(초당 처리할 수 있는 레코드 수)에 관심을 갖고, 온라인 시스템에서는 응답 시간이 시스템 성능이라고 볼 수 있겠습니다.
확장성이란 부하 매개변수가 어느 정도 증가하더라도 좋은 성능을 유지할 수 있는 시스템의 특징입니다. 부하정도에 따라 시스템의 아키텍처를 재컴토해야할지도 모르죠. 확장성과 관련해서 scaling up과 scailing out 방식이 있습니다. 일반적으로 전자는 보통 간단하지만 비용이 많이 들어서 실용적인 접근 방식인 후자를 선택합니다.
최근에는 분산 시스템을 위한 도구와 추상화가 많이 발전했습니다. 그러나 대규모로 동작하는 시스템 아키텍처는 사용하는 애플리케이션에 특화되어 있습니다. 아키텍처를 결정하는 요소인 읽기 양, 쓰기 양, 저장할 데이터 양, 데이터 복잡도, 응답시간, 접근 패턴 등에 맞춰져 있습니다. 그래서 확장성을 갖춘 아키텍처를 설계할 때는 애플리케이션의 주요 동작이 무엇이고 잘 하지 않는 것이 무엇인지 파악하는게 중요합니다.
Maintainability(유지보수성)
소프트웨어 비용의 대부분은 초기 개발 보다는 유지보수 비용이 더 많이 듭니다. 유지보수는 버그 수정, 시스템 운영 유지, 장애 조사, 기능 추가 등이 있습니다. 일반적으로 개발자나 운영하는 사람들은 레거시 시스템 유지 보수를 굉장히 싫어합니다. 그러나 소프트웨어 설계를 잘하면 레거시 소프트웨어를 최대한 덜 다룰수 있는 3가지 소프트웨어 설계 법칙이 있습니다.
- Operability(운영성)
- Simplicity(단순성)
- Evolvability(발전성)
좋은 운영성 동일하게 반복되는 태스크를 쉽게 수행할 수 있어야 한다는 것입니다. 즉 운영이 쉬워야한다는 것이죠. 단순성은 시스템을 단순하게 만드는 것인데 이 말은 기능을 줄인다는 의미는 아닙니다. 좋은 추상화를 통해 복잡한 세부 구현을 숨김으로써 시스템 복잡도를 줄이는 것을 말합니다. 마지막으로 발전성은 시스템에 변화하는 요구사항을 잘 수용하고 복잡한 시스템을 보다 쉽게 수정할 수 있는 민첩성을 이야기 합니다.
정리
지금까지 Data-intensive application(데이터 중심 애플리케이션)을 개발할 때 생각해야 하는 것들에 대해서 살펴보았습니다. 애플리케이션은 다양한 요구사항을 충족시켜야 하는데 신뢰성, 확장성, 유지보수성은 비기능적 요구사항에 해당됩니다. 애플리케이션이 신뢰성이 있고, 확장 가능하며, 유지보수 하기 쉽게 만들어주는 간단한 해결책은 없습니다. 그러나 이러한 애플리케이션을 만드는 경우에 많이 사용되는 패턴이나 기술들이 존재합니다. 이러한 시스템 패턴은 추후 포스팅에서 살펴보도록 하겠습니다.