Archive

신뢰성/확장성/유지보수성을 갖춘 애플리케이션 본문

------- CS -------/System

신뢰성/확장성/유지보수성을 갖춘 애플리케이션

enent 2022. 5. 11. 00:36
반응형

데이터 중심 애플리케이션 - 데이터 양 / 복잡도 / 변화 속도에 따라 다르게 구축됨. 또한, 요구사항에 맞게 설계됨

 

유용한 애플리케이션을 위해선 기능적 요구사항과 비기능적 요구사항을 충족시켜야함

  • 기능적 요구사항 : 데이터 저장, 조회, 검색 등
  • 비기능적 요구사항 : 보안, 신뢰성, 법규 준수, 확장성, 호환성, 유지보수성

 

 

1. 신뢰성

: 하드웨어 /소프트웨어 결함, Human Error 등에서도 시스템이 지속적으로 올바르게 동작함

  • 올바르게 동작한다 = 원하는 성능 수준에서 정확한 기능을 수행함
  • 결함(fault) : 잘못될 수 있는 일 ( cf. 장애 (failure) : 사용자에게 필요한 서비스를 제공하지 못하고 시스템이 멈춤)
  • 내결함성 (fault-tolerant) : 결함을 예측하고 대처할 수 있음

결함확률을 0으로 줄이는 것은 불가능하므로, 결함으로 장애가 생기지 않도록 내결함성 구조로 설계하는 것이 Best

 

 

 

1-1. 하드웨어 결함

  • ex) 하드디스크 고장, 정전, 네트워크 장애 등

  • 대응방안
    - 각 하드웨어 구성요소에 중복 (Redundancy) 를 추가
    - 디스크 - RAID 구성
    - 서버 - 이중 전원 디바이스 / Hot-Swap 가능한 CPU
    - 데이터센터 - 예비 전원용 디젤 발전기

데이터 양과 애플리케이션의 계산 요구가 늘어나면서 더 많은 장비를 사용하게 됐고, 이에 비례하여 하드웨어 결함율도 높아졌음

-> 따라서 소프트웨어 내결함성 / 하드웨어 중복성을 통해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 변화하고 있음

 

 

 

1-2. 소프트웨어 오류

ex) 다른 장비의 장애로 인한 장애 ( ex. 같은 서버랙의 높은 같은 온도, 시스템 내 체계적 오류 (systematic error))

  • Systematic Error가 예상하기 더 어렵고, 노드간 상관관계가 커 시스템 오류를 더 많이 유발하는 경향이 있음
    ex) CPU, 메모리, 디스크, 네트워크 대역폭처럼 공유 자원을 과도하게 사용하는 일부 프로세스, 시스템의 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
  • 대응방안
    - 소프트웨어 오류는 신속한 해결책이 없음
    - Process Isolation, 꼼꼼하고 반복적인 테스트, 모니터링 등이 해결책..

1-3. 인적 오류 ( Human Error)

  • 어떤 연구에 따르면 운영자의 설정 오류가 시스템 중단의 주요 원인 (하드웨어 결함은 10-25%)
  • 대응방안
    - 오류의 가능성을 최소화하는 방향으로 시스템 설계
          - 잘 설계된 추상화, API, 관리 인터페이스
    - 사람의 실수가 많이 발생하는 부분에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리
    - 단위테스트/통합테스트/수동테스트 등 모든 수준에서 철저한 테스트
    - 인적 오류의 빠른 복구 체계 구축
         - 설정 변경 내역 빠르게 Roll back / 새로운 코드를 서서히 Roll out 할 수 있는 시스템
    - 성능지표/오류율 같은 상세하고 명확한 모니터링 대책 마련
    - 조작교육 및 실습 시행

2. 확장성

: 부하가 증가해도 좋은 성능을 유지하기 위한 전략

  • 확장성의 종류로는 용량확장 ( scale up ), 규모 확장 ( scale out ) 이 있음
  • 성능저하를 유발하는 흔한 이유 중 하나는 부하증가이며, 이를 대처하기 위해 다음을 고려한다는 의미
    -  시스템이 특정 방식으로 커질 때, 이를 대처하기 위한 선택은?
    -  추가 부하를 다루기 위한 계산 자원은 어떻게 투입할까?

2-1. 부하 기술하기

  • 부하 = Load parameter를 통해 나타낼 수 있으며, 어떤 parameter를 선택하냐는 시스템 설계에 따라 달라짐
    ex) 웹 서버의 초당 요청 수, 데이터베이스의 읽기 / 쓰기 비율, Active User수, 캐시 적중률 등을 통해 나타냄

2-2. 성능 기술하기

  • 일괄처리 시스템 (ex. Hadoop)의 경우 처리량 (Throughput), 온라인 시스템의 경우 응답시간 (Response time)등으로 성능을 기술
    -  응답시간의 경우 측정값이 아닌 분포를 통해 확인해야함
    -  평균보단 백분위를 통해 판단하는 것이 좋음
  • 성능을 기술하면 부하가 증가할 때 어떤 일이 일어나는지 조사할 수 있음
    -  부하가 증가할 때, 시스템 자원이 동일하면 시스템 성능은 어떻게 영향을 받을까?
    -  부하가 증가할 때, 성능이 동일하려면 자원을 얼마나 많이 늘려야 할까?

*지연시간(Latency) vs 응답시간 ( Response Time)

  • 지연시간 : 요청이 처리되길 기다리는 시간. Latent 상태에 놓인 시간
  • 응답시간 : 요청을 처리하는 실제 시간 + 네트워크 지연 + 큐 지연 등 클라이언트 입장에서 요청이 처리되는 시간

2-3. 부하 대응 접근 방식

  • 탄력적인 시스템은 부하를 예측하기 어려울 때 유용하나, 수동으로 확장하는 시스템이 더 간단하고 운영시 예상 불가능한 일이 적음
  • 아키텍처를 결정하는 요소는 데이터 읽기/쓰기 양, 저장할 데이터 양, 복잡도, 응답 시간 요구사항, 접근 패턴 등이 있음
  • 특정 애플리케이션에 적합합 확장성을 갖춘 아키텍처는 주요 동작이 무엇이고, 잘 하지 않는 동작이 무엇인지에 대한 가정을 바탕으로 구축하며, 이 가정은 곧 부하 매개변수가 됨

 

3. 유지보수성

: 시스템에서 작업하는 엔지니어와 운영팀의 삶을 개선하는 것이 유지보수의 본질

  • 좋은 운용성이란 시스템의 상태를 잘 모니터링하고, 시스템을 효율적으로 관리하는 방법을 가지고 있는 것
  • 버그 수정, 시스템 운영 유지, 장애 조사, 새로운 플랫폼 적응, 새 사용 사례를 위한 변경, 기술 채무 (technical debt)상환, 새로운 기능 추가 등이 있음.

3-1. 운용성 : 운영의 편리함 만들기

  • 운영 중 자동화 할 수 있는 부분은 자동화 해야 하나, 자동화를 처음 Setting하고 제대로 동작하는지 확인하는 것은 사람의 몫임
    • 시스템 상태를 모니터링 / 상태가 좋지 않다면 빠르게 서비스 복원
    • 시스템 장애, 성능 저하 등 문제 원인 추적
    • 보안 패치 등 항상 플랫폼을 최신 상태로 유지
    • 미래 발생 가능한 문제를 예측해 문제 발생 전 해결 ( ex. 용량 계획)
    • 배포, 설정 관리 등 모범 사례와 도구 마련
    • 설정 변경으로 생기는 시스템 보안 유지보수
    • 예측 가능한 운영 / 안정적인 서비스 환경을 유지하기 위한 절차 정의
  • 좋은 운영성 = 동일하게 반복되는 태스크를 쉽게 수행하게 끔 하여 운영팀이 보다 고부가가치 활동에 노력을 집중하는 것
    • 좋은 모니터링을 통해 runtime 동작 및 시스템 내부에 대한 가시성 제공
    • 개별 장비 의존성 회피 ( 유지보수 위해 장비를 내리더라도 계속 운영이 가능해야함)
    • 좋은 문서와 이해하기 쉬운 운영 모델 제공
    • 예측 가능하게 동작하고 예기치 않은 상황을 최소화함

3-2 . 단순성 : 복잡도 관리

  • 프로젝트가 커짐에 따라 시스템은 복잡해지고 나아가 유지보수 비용을 증가시킴
    • 개발자가 시스템을 이해하기 어려워지면, 시스템에 숨겨진 가정과 의도치 않은 결과 / 예기치 않은 상호작용을 간과하기 쉬움
    • 복잡도를 줄이면 유지보수성이 크게 향상 됨 = '단순성'이 구축하려는 시스템의 핵심 목표여야 함
  • 복잡도를 제거하기 위한 최고의 도구는 '추상화'
    • 좋은 추상화는 깔끔하고 직관적인 외관 아래 많은 세부 구현을 숨길 수 있음
    • 복잡도를 줄이고 쉽게 시스템을 변경할 수 있게 하여 새로운 사용 사례에 적용하는데 도움이 됨

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

  • 시스템의 요구사항은 끊임없이 변화함
    • 새로운 기술 사용사례 등장, 비지니스 우선순위 변경, 사용자의 새로운 기능 요청, 규제 요구사항 변경, 시스템 확장 등
  • 애자일(agile) 작업 패턴은 변화에 적응하기 위한 프레임워크 제공
    • TDD(test-driven development)와 리팩토링 등 자주 변화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술도구와 패턴을 개발
  • 대규모 시스템 수준에서 민첩성을 높이는 방법을 찾아야 함
    • 간단하고 이해하기 쉬운 시스템은 복잡한 시스템보다 수정하기 쉬움

애플리케이션에서 계속 재현되는 특정 패턴과 기술을 활용하여 애플리케이션을 신뢰할 수 있고 확장 가능하며 유지보수하기 쉽게 만들어주자


데이터 중심 애플리케이션 설계 - 01. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

반응형

'------- CS ------- > System' 카테고리의 다른 글

시스템 확장 ( Scalability )  (0) 2022.05.02
Comments