AWS 웹 서비스 부하 테스트 입문 필기(1)

시스템 설계

db에 대한 설계 Postgresql 사용?

• db를 NoSQL과 rdbms를 용도에 따라 분리하여 사용하는 것이 좋을 듯하다.
• Postgresql은 복잡한 데이터베이스에 대하여 장점을 가지지만 단순한 db에 대해서는 MySQL이 더 속도가 빠르다.

서버에 대한 설계

• AWS를 사용하는 이유?
  • 초기 비용 거의 X, 그리고 사용한 만큼만 비용을 지불하면 된다.
  • 스케일 업, 아웃, 다운, 인이 매우 간편하다.
  • 물리적인 장애의 대응이 더 편하다?
• 가장 단순하게 생각했을 때는 스케일 업(러닝 커브 매우 짧음)
  • 향상해 주는 부분은 서버의 리소스
  • 다만 CPU 병목은 스케일 업으로 해결이 불가능하다.(스케일 업은 CPU의 코어 수를 증가시켜 줌), 멀티 코어를 활용하지 않는다면 실 성능 향상은 어려움
• 스케일 아웃
  • 서버를 여러 개를 사용
  • 로드 밸런싱을 통하여 자원을 적절하게 분배
  • 서비스의 가용성이 증가한다.
  • AWS의 multi-AZ를 사용하여 db의 이중화
    • 동기화 오버헤드 발생으로 인한 성능 하향 가능성 존재
    • 대신 안정성이 증가(tradeoff 존재)
• S3에 정적 콘텐츠 호출?
  • static html 파일
  • css
  • javascript 사용 가능

부하 테스트 설계

• 예시)
  • 서비스 시작 직후 많은 사용자가 서비스에 등록
    • 기존의 적은 데이터 용량에서 많은 양의 데이터가 추가됨
  • 서비스를 시작한 후 많은 데이터가 저장된다.
    • DB 데이터 증가, DB 요청도 증가
    • ex) 인덱싱이 처리된 쿼리여도 db용량이 커지면 인덱스가 메모리 상에 올라가고 상태를 유지 못하는 경우가 있다.
  • 외부 요인(광고 등)으로 사용자 요청이 증가한다.
    • 단기적으로 사용자 요청이 증가하는 경우
    • 오토 스케일링의 스케일 아웃 속도와 스토리지 I/O의 버스트 성능 검증이 필
  • 배치 작업 등 다른 시스템으로 인한 DB 작업과 시간이 겹친다.
    • 정기적으로 데이터 백업, 보고서 생성, 시스템 유지 보수 작업 등의 배치 작업이 발생할 때 rdb 참조 쿼리 성능이 저하될 경우 슬레이브 DB 추가가 필요하다.
  • 시스템에서 비정상적으로 응답한다.
    • 로그 수집 처리가 시스템의 병목 현상을 가져올 수 있다. HTTP 상태코드 40X의 경우 지속적으로 로그가 쌓이게 될 경우 성능에 영향을 미칠 수 있다.
  • 시스템 재기동 후에 캐시가 초기화된다.