대규모 스트림처리를 위한 여러 방법 중 앞선 포스트에 언급되지않은 부분을 다룬다.
대규모 시스템에서 안정성과 성능을 높이는 다양한 방법들 중 모니터링이 있다.
모니터링은 cctv로 감시하고 있는 장면을 떠올리면된다.
우리가 서비스하는 어플리케이션이나 그 어플리케이션과 연결되어있는 DB, 중간에 위치한 캐시 같이 각각의 컴포넌트 부품들의 성능을 감시한다.
Prometheus나 Grafana 같은 도구를 사용하여 이루어진다.
바로 이전 포스트에서 나온 TPS(응답시간)을 모니터링하고 문제발생시 알림을 받을 수 있다.
또, 설정해놓은 임계치를 넘었을때도 알림을 받을 수 있어서 에러 발생을 예방할 수 있다.
이는 빠른 대처를 하게 해줄 수 있고 사용자의 더 나은 사용자경험으로 이어진다.
어플리케이션에서 동작을 하는 이벤트
가 일어날 때, 로깅을 통해 정보를 남겨둘 수 있다.
Elasticsearch, Logstash 등을 이용하고, 남겨진 로그를 수집이나 저장할 수 있으며 로그를 분석해 문제점을 찾아낼 수 있다.
문제 발생 시 정확한 원인을 파악하는데 큰 도움이 된다.
원인을 파악하면 똑같은 문제를 방지할 수 있다!
서비스가 운영중일때는 앞서 말한 기능이나 도구들을 사용해 에러를 예방하고 빠른 조치를 취할 수 있다.
서비스가 운영되기 전에도 테스트
를 통해서 미리 여러 장애들을 예방할 수 있다.
어플리케이션이 많아지면서 테스트에 대한 중요도가 더 높아지고 있다.
어플리케이션을 테스트하는 방법에는 여러 종류가 있다.
단위 테스트는 유닛 테스트
라고도 한다.
그나마 많이 접해본 내용의 테스트이다.
단위, 유닛 이라는 단어에서도 알 수 있듯 가장 작은 단위(=메소드 단위)로 테스트를하는 방법이다.
JUnit, TestNG 같은 도구를 사용해서 단위테스트를 작성하고 실행한다.
서비스 어플리케이션은 결국 작은 단위의 메소드들이 여러가지 상호작용을 하며 사용자에게 서비스를 하기때문에 단위테스트는 아주 중요한 개념이다.
단위테스트를 거치고 난 후 통합테스트를 하게된다.
두 개 이상의 메소드들이 상호작용한 후 결과물이 우리가 의도했던 결과가 맞는지를 확인한다.
@SpringBootTest 어노테이션을 사용해서 통합테스트를 작성할 수 있다.
이름에 나와있는 것처럼 의도적으로 부하
를 줘서 시스템이 버틸 수 있는지 확인하는 테스트이다.
내가만든 사이트에 동시접속자 수가 얼마나되는지 배포된 사이트에서 실사용자를 대상으로 측정하면 안되기 때문에 부하 테스트를 이용한다.
시스템의 한계를 파악한다.
Apache JMeter를 사용해서 다양한 부하 시나리오에 대한 테스트를 해볼 수 있다.
서비스를 운영하다가 문제가 생기거나 기능을 확장하려고하면 기존의 코드에 새로운 코드를 붙여넣거나 기존의 코드를 변경해야하는 상황이 온다.
해당 작업이 끝난 후 새로 추가한 코드들이 기존의 기능에 영향을 미치지는 않는지 확인하는 방법이 바로 회귀 테스트이다.
코드 변경시 시스템의 안정성을 유지할 수 있다.
대부분의 테스트가 끝나면 어플리케이션이 출시되기 이전 마지막으로 사용자 수용 테스트를 거친다.
게임이 출시되기 전 소수의 사용자들에게 먼저 경험해볼 수 있는 기회를 주는 베타 테스터
가 바로 사용자 수용 테스트이다.
해당 사용자들은 게임이 정시 출시되기 이전 게임을 미리 플레이 해보면서 오류 사항이나 개선점을 개발자에게 알려준다.
어플리케이션을 열심히 개발하고 만들었다면 이제 사용자가 사용할 수 있게 배포
라는 단계를 거쳐야한다.
배포란 사용자들이 드디어 인터넷을 통해 어플리케이션에 접근할 수 있도록 만드는 것을 말한다.
많은 취업공고를 보면 요구사항 혹은 우대사항에 CI/CD를 경험해본 개발자를 원하는 회사가 많다.
그만큼 요즘 만들어지는 서비스는 워낙 사용자도 많고 코드가 자주 바뀔 수 있다는것을 말하고 있는 것 같다.
CI/CD는 뭘까?
Continuous Integration 지속적인 통합을 말한다.
개발자가 변경하거나 추가한 코드를 자동으로 빌드하고 테스트함으로써 코드가 변경되는 시점에서 나올 수 있는 문제를 발견할 수 있게한다.
Jenkins, GitLab CI 등을 사용하여 CI 파이프라인을 설정한다.
CI는 개발 주기를 단축시키고, 코드의 품질을 향상시킬 수 있는 방법이 될 수 있다.
Continuous Deployment 지속적인 배포를 말한다.
앞서 CI를 통해 설정한 파이프라인을 통해 검증된 코드들을 자동으로
프로덕션 환경에 배포한다.
Argo CD 같은 CD 도구를 사용하여 CD 파이프라인을 설정한다.
변경된 사항을 자동으로 배포하면서 사용자에게 새로운 기능을 신속하게 제공할 수 있다.
빠른 피드백 가능
코드 변경이 된 이후 즉시 빌드 및 테스트가 진행되고 해당 테스트 결과를 확인 할 수 있기 때문에 코드를 개발한 개발자가 문제점이 생길시 빠르게 인지할 수 있다.
자동화된 프로세스
빌드, 테스트, 배포 단계를 자동으로 해주기때문에 해당 단계를 사람이 하면서 생기는 인적오류
를 예방 할 수 있다.
일관된 배포
배포 프로세스가 매번 동일하기때문에 일관된 배포를 할 수 있다.
높은 품질 유지
코드 품질을 지속적으로 검증하고 초기에 문제점을 해결하며 코드 품질을 향상 시킬 수 있다.
개발 속도 향상
자동화를 통해 개발 주기를 단축시킬 수 있어 개발 속도 향상에 도움이 되고 빠른 개발 속도는 사용자로 하여금 새로운 기능을 더 빠르게 사용할 수 있는 효과를 준다.
- Canary 배포
새로운 버전을 일부 사용자에게 우선적으로 배포하여 문제 유무를 확인한다.
문제 발생시 이전 버전으로 롤백이 가능하다.
- 블루-그린 배포
현재 운영 중인 환경, 새로운 버전을 배포하는 환경 이렇게 두가지 환경을 사용한다.
최신 버전을 그린환경에 배포 후 모든 트래픽을 그린으로 전환한다.
문제 발생시 블루환경으로 빠르게 롤백이 가능하다.
- 롤링 배포
점진적으로 새로운 버전을 도입하는 방법
무중단 배포 구현시 유용하다.