가용성가용성은 시스템이 서비스를 정상적으로 제공할 수 있는 상태를 의미한다.가용성을 높이기 위해서는 SPOF(Single Point of Failure) 를 없애고 확장성 있는 서비스를 만들어야 한다. 1. 성능의 기준 3가지 : users, tps, timeusers : 얼마나 많은 사람들이 동시에 사용할 수 있는지tps : 일정 시간동안 얼마나 많이 처리할 수 있는지time : 서비스가 얼마나 빠른지 [1] userconcurrent user & active userconcurrent user : 계속해서 요청을 보내지 않는 사용자를 말한다. 즉, 웹 페이지를 그저 띄워두고 있는 사용자를 말한다.active user : 계속해서 요청을 보내는 사용자를 말한다. 성능 테스트에서 VUser 는 Activ..
인프라 공방/컨퍼런스
요약, 이벤트 기록, 스냅샷서버 진단 시, 서버로 부터 수집해야 할 정보는 요약, 이벤트 기록, 스냅샷이다.요약 : 단위 시간 정보의 합계나 평균을 의미하며 sar, vmstat 과 같은 명령어를 통해 확인할 수 있다.이벤트 기록 : packet, system call 과 같은 정보들의 순차적인 기록들을 의미한다.스냅샷 : 순간의 상태를 기록하는 것을 의미하여 현재 문제가 발생하고 있지 않는지, 발생한다면 원인 조사를 하는데 사용한다.요약 정보로 각 리소스의 대략적인 상태를 파악하고 스냅샷으로 원인을 파악한다. 이벤트 기록은 장애 상황에서 사용하기에는 데이터가 방대하여 그 자체에 영향을 줄 수 있으므로 문제 상황 재현 등에 활용한다.(⭐️ 중요) 로그, 요약 정보의 일정 수치에 알람 설정을 해두고 스냅샷..
1. Project 서버 구성[1] AutoScaling 환경에서 API call 에 관한 고민 프로젝트의 구성은 Gradle 기반 멀티 모듈로 구성되어 있었다. 이전 프로젝트 인프라와 다른 점은 BFF 패턴(Backend For Frontend) 으로 구성하고 있어 conference, analysis server 에 api call 을 해야 한다는 점이 가장 큰 차이였다. 프로젝트 환경을 구성하면서 가장 고민되었던 점은 Scale out 환경에서 어떻게 api call 을 할 것인가? 이다. API call 을 하는 가장 간단한 방법은 IP, PORT 에 관한 서버 스펙을 기반으로 요청하는 것이다. 하지만 Scale out 환경에서는 상세한 서버 스펙을 아는 것은 한계가 있다. Scale out 되는..
이전 프로젝트를 구성하기 위해서는 source code 를 로컬 환경에서 빌드해서 scp 명령어를 통해 업로드하는 방식이었다. 하지만 매번 소스 코드 수정이 있을 때마다 build → file upload → build file 실행 작업의 반복으로 인해 부수적인 작업에 리소스를 사용하는 것이 불편했다. 그리고 이후 scale out 환경을 구성하는 경우에는 이 부수 작업의 무한 굴레에 빠지기 때문에 앞으로의 작업을 위해 개선이 필요했다. 결국 github action 을 통해 소스 코드를 빌드하고 S3 bucket 에 일괄 관리하는 방식으로 변경했다. 1. 개념 및 용어 정리[1] 멀티 모듈(multi-module) ? 멀티 모듈 프로젝트는 상호 연결된 여러 개의 모듈로 구성된 프로젝트를 의미한다...
