Level 4 아키텍처 개선

무엇을 고려해야 하나

• 규모 확장성: 트래픽의 규모에 맞춰 확장할 수 있는지에 대한 관점
• 성능: 서비스의 성능이 고객의 기대 수준에 부합하는지에 대한 관점
• 가용성: 서비스가 의도한 목적을 달성하기 위해 정상적으로 작동하는 시간 측면의 관점
• 신뢰성: 정해진 성능 수준을 만족하면서 정확하게 동작하는지에 대한 관점
• 비용

가용성

고가용성

• HA, High Availability : 정상적으로 작동하는 시간의 비율을 높이는 것
• 9's availability: 9가 몇 개 들어가는지에 따라 다운되는 시간이 정해진다. (신기 ㄷㄷ)

SPOF

단일 장애 지점. 이 지점에 문제가 생기면 전체 시스템이 문제가 생긴다.

사용할 수 있는 도구

이중화 (다중화)

시스템 일부에 어떤 장애가 발생했을 경우에 대비해서, 장애발생 다음에도 시스템 전체의 기능을 계속 유지하도록 예비 장치를 평상시부터 백업으로서 배치해 운용하는 일

로드밸런서

• 부하의 균형을 유지해주는 역할
• 클라이언트로부터 들어오는 요청을 N개의 목적지로 분산시켜준다.
• 추후 학습해보면 좋을 키워드
  • L4/L7 스위치
  • HAProxy
  • AWS ELB

MySQL 을 사용할 때 왜 Connection Pool 을 사용할까?

• 커넥션 생성 비용이 커서요

WAS

• 언제 문제가 있을 수 있을까?
  • OOM
  • 디스크 용량 초과
  • 하드웨어 장애
• 어떻게 해결할 수 있을까?
  • LB, 스위치를 사용한 이중화
• 어떤 문제가 생길 수 있을까? 또는 무엇을 개발할 때 고려해야 할까?
  • 동시성 이슈
    • 스레드에 대한 동시성 고려에서 WAS 간의 동시성 고려로 확장된다.
    • 이런 문제가 발생할 수 있다. https://stackoverflow.com/questions/35534906/java-hashmap-getobject-infinite-loop
    • 분산락 (vs synchronized)
      • 서버 사이의 동시성에서는 synchronized 를 사용하는 것보다 서버 사이의 락을 가지도록 해야 한다.
  • 세션 정보를 어떻게 관리할 것인가?
  • 데이터 저장소 커넥션 제한
  • 모니터링 로그 확인이 어려워진다.
  • 베포는 어떻게 할 것인가?
    • 롤링 배포를 한다면,
      • 배포 중간에 장애 상황임을 알면 어떻게 하나?
      • 서버 대수가 많아지면 어떻게 할 것인가?
  • 프론트 리소스도 스프링에서 서빙한다면 다른 리소스가 제공될 수 있는 상황은 어떻게 할 것인가?

DBMS

• 언제 문제가 될 수 있을까?
  • 시스템 부하가 커질 때
  • 디스크 용량 초과
  • 하드웨어 장애
• 어떻게 해결할 수 있을까?
  • 이중화
  • replication
  • 백업
• 어떤 문제가 생길 수 있을까? 또는 무엇을 개발할 때 고려해야 할까?
  • 이중화
    • 데이터 싱크는 어떻게 맞출까?
  • replication
    • writer DB 가 다운되면 어떻게 reader DB 를 writer DB 로 사용할 수 있을까?
    • replication 은 어떻게 이뤄지나?

      • sync vs async

        • 비동기로 수행하면 쓰기 전에 읽기가 발생하면 읽을 수 없는 상태가 된다.
      • replication lag
    • failover 할 때 WAS 의 커넥션 풀에 있느 커넥션은 어떻게 될까
  • backup
    • backup 은 DB 서버에 부하가 없을까?
    • 계속해서 데이터가 변경되면 언제 데이터를 백업해야 할까?

이중화 하면서 replication 하는 방법을 많이 사용한다고 한다.

이중화 하면 읽기도 두 번 보내야 하는가? -> MySQL 의 경우는 한 번만 보내면 된다 (왜?)

Jenkins

• 언제 문제가 될 수 있을까?
  • 자원이 부족한 순간들
  • 하드웨어 장애
• 어떻게 해결할 수 있을까?
  • master-agent 설정
  • master 이중화
  • 백업
• 어떤 문제가 생길 수 있을까? 또는 무엇을 개발할 때 고려해야 할까?
  • master-agent 설정
    • master 가 다운되면 어떻게 하나?
  • master 이중화
    • 두 대의 jenkins 가 동일하게 관리될 수 있도록 어떻게 할 수 있을까?

AWS AZ

• 언제 문제가 될 수 있을까?
  • 지진, 태풍 등으로 인한 데이터 센터 전체 이슈
• 어떻게 해결할 수 있을까?
  • multi AZ
• 어떤 문제가 생길 수 있을까? 또는 개발할 때 무엇을 고려해야 할까?
  • network latency
  • 비용

스케일 업 vs 스케일 아웃

스케일 인

노드에 자원을 추가하여 시스템 처리량을 늘리는 방법. 컴퓨팅 자원을 좋게 하는 것

aka. 수직 스케일링

스케일 아웃

시스템에 노드를 추가하여 시스템의 처리량을 늘리는 방법.

aka. 수평 스케일링

사용할 수 있는 도구

구체적인 구현이나 사용법은 논외. 요구사항에 맞춰 동작하는 프로그램이라고 가정

서버 캐시

• Map 과 유사하게 key-value 형태의 자료 구조를 가지고 있음
• 메모리에 모든 데이터를 올려서 관리하며, 단일 key 조회에 대해 매우 빠른 성능을 보장한다.
• WAS 에 올려서 사용할 수도 있고 별도의 캐시용 서버를 구축할 수도 있다.

검색엔진

• 전문검색, 여러 조건의 검색을 포함하여 대부분의 검색에서 DBMS 보다 빠른 성능을 보장한다.
• 집계, 통계 쿼리도 DBMS 보다 빠른 성능을 보장한다.

메시지 큐

• 큐 형태의 자료 구조
• 하나의 시스템에서 데이터 또는 메시지를 저장함녀 큐 형태의 자료 구조에 저장하며, 다른 시스템에서 그 값을 가져가서 처리할 수 있다.

프로세스 스케줄링

• 원하는 시점에 프로그램을 실행하는 것
  • 인프라 아키텍처 다이어그램에는 특정한 역할을 하는 프로그램으로 표시한다.
• 젠킨스 또는 크론탭, 스프링의 @Scheduled 어노테이션을 이용해서 실행하는 것으로 가정

고민할 것

• 과연 서비스가 성공할까? 성공하고 개선하면 안 되나?
• 장애 발생으로 인한 손실과 투자한 비용을 고민해봤는가?
• 모든 장애를 완벽하게 방어할 수 있나?
  • 예상할 수 있는 문제와 알 수 없는 문제 (방어하기 힘듦)
  • 장애가 발생했을 때 탓하지 않는 문화
• 또 무엇을 할 수 있을까?
  • 재발 방지
  • 모니터링 고도화 및 빠른 복구
  • 모의 장애 훈련

역정규화

데이터의 개수가 많아지면 통계 쿼리를 작성하기 어렵다.
통계 테이블을 만들면 '읽기' 성능 측면에서 개선 가능하다.
대신 글을 작성할 때마다 count 를 증가시키는 추가 작업이 발생한다.

파티셔닝

대용량의 테이블을 물리적으로 여러 개의 소규모 테이블로 분산하는 목적으로 사용할 수 있는 기능

사용할 때는 하나의 테이블인 것처럼 사용하지만, 내부적으로는 N개의 테이블로 나눠서 관리

• 인덱스도 나눠서 관리한다.
• 데이터가 적은 테이블의 변경이 더 쉽고, 조회가 빠르다.
• 나눠진 테이블에는 중복으로 데이터를 넣지 않는다.

MySQL 자체로 지원하는 기능이다.

샤딩

대용량의 테이블을 물리적으로 여러 개의 소규모 테이블로 분산하는 목적으로 사용하는 기능
N대의 DBMS에 분산해서 데이터를 관리한다.

무엇을 캐시할 것인가?

• 데이터가 얼마나 자주 사용되는가?
• 데이터가 얼마나 자주 갱신되는가?
• 전체 데이터를 캐시할 것인가? 일부 데이터를 캐시할 것인가?
  • 지하철 노선 vs 쇼핑몰 상품
• 캐시의 키는 무엇인가?
• 데이터 구성을 위해 메타데이터를 캐시할까? 화면에 그려지는 데이터를 캐시할까?

캐시를 사용할 때 문제될 수 있는 상황은?

• 메모리가 무한한가?
  • cache eviction algorithm
  • TTL
• 캐시의 데이터가 최신 데이터라는 것을 어떻게 보장할까?