반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- Algorithm
- leetcode
- 엘라스틱서치
- 스파크
- 알고리즘
- Optimization
- AWS
- 깊이우선탐색
- solution
- 프로그래머스
- elasticsearch
- Django
- programmers
- dump
- dfs
- kibana
- 키바나
- Spark
- daspecialty
- RecommendationSystem
- 리트코드
- twosum
- python
- 장고
- 해시
- CentOS
- Easy
- Medium
- ELK
- 파이썬
Archives
- Today
- Total
Archive
신뢰성/확장성/유지보수성을 갖춘 애플리케이션 본문
반응형
데이터 중심 애플리케이션 - 데이터 양 / 복잡도 / 변화 속도에 따라 다르게 구축됨. 또한, 요구사항에 맞게 설계됨
유용한 애플리케이션을 위해선 기능적 요구사항과 비기능적 요구사항을 충족시켜야함
- 기능적 요구사항 : 데이터 저장, 조회, 검색 등
- 비기능적 요구사항 : 보안, 신뢰성, 법규 준수, 확장성, 호환성, 유지보수성 등
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