Haonly's Blog

가상 면접 사례로 배우는 대규모 시스템 설계 기초

내가 보려고 정리하는 내용

그냥 읽기만 하면 기억에 잘 남지 않으니 간단하게 정리하면서 읽어보자.

제 1장. 사용자 수에 따른 규모 확장성

1.1 DNS, 로드밸런서, 데이터베이스 다중화

사용자가 웹사이트에 접속하여 무언가 요청을 하는 간단한 시스템에서 확장성을 다룬다.

되게 오랫동안 기억 저 안쪽에만 넣어둔 'DNS' 가 나왔다.

• DNS: 도메인 이름(google.com)의 IP 주소를 알려준다.

사용자가 늘어감에 따라 하나의 서버에서 요청/처리를 하는 것이 아니라 여러 서버를 두어야 한다.

• 데이터베이스
  • RDBMS
  • NoSQL
  • 각각의 장단을 고려해 바람직한 데이터베이스를 사용해야 한다.

예를 들어 아주 낮은 응답 지연시간이 요구되거나 다루는 데이터가 정형 데이터가 아닐 경우 NoSQL을 사용해야 하는 경우가 있을 수  있다.

성능을 개선하는 방법으로 확장에 대해 소개한다.

• 수직적 규모 확장(scale up): 서버에 고사양 자원을 추가하는 행위
• 수평적 규모 확장(scale out): 더 많은 서버를 추가하여 성능을 개선하는 행위

웹 서버에 너무 많은 부하(사용자가 많아짐)가 생기면 웹 서버가 다운될 수 있어 이를 막기 위해 로드밸런서를 도입해야한다.

로드밸런서는 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.

우리가 흔히 LB 구성한다고 할 때의 그 LB이다.

이렇게 분산된다면 웹 계층의 경우 분산된 서버끼리 트래픽을 골고루 나누게 되는데 데이터베이스의 경우 어떻게 해결할까? 장애의 복구나 다중화가 필요하다.

데이터베이스 다중화

• 쓰기 연산은 주 데이터베이스 서버로, 읽기 연산은 부 데이터베이스 서버 여러대로 분산시킬 수 있다.
• 이를 통해 더 나은 성능을 기대할 수 있고
• 데이터를 보존할 수 있어 안정성이 높아진다.
• 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버의 데이터를 가져와 계속 서비스 할 수 있어 가용성이 높아진다.

1.2 캐시

캐시는 값비싼 연산 결과나 자주 참조되는 데이터를 메모리에 두어 뒤이은 요청이 빨리 처리될 수 있도록 하는 저장소이다.

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨신 빠르다. 데이터 요청이 올 때 데이터베이스를 참조하기 전에 캐시에서 데이터를 반환할 수 있도록 한다.

캐시를 사용할 때 고려할 점

• 캐시를 쓰는 바람직한 상황
• 영구적으로 보관할 데이터라면 데이터베이스에 보관
• 만료에 대한 정책
• 일관성 유지
• 캐시 단일 서버 장애 대응(캐시 분산)
• 캐시 메모리 크기
• 어떤 데이터를 캐시에서 삭제할지(LRU, LFU, FIFO 등 대학생 때 배웠던 그것!)

1.3 CDN(콘텐츠 전송 네트워크)

CDN은 이미지, 비디오, CCS, java script 파일 등을 캐시할 수 있는 정적 콘텐츠를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크이다.

CDN은 보통 제 3 사업자에 의해 운영되어 데이터 전송 양에 따라 요금을 내게 된다.

정적 콘텐츠를 웹 서버를 통해 서비스하는 것이 아니라 CDN을 통해 제공해 더 나은 성능을 보장할 수 있다.

1.4 무상태(stateless) 웹 계층

서버의 수평적 확장에서 고려해야 할 부분으로 공유되어야할 상태 정보를 웹 계층에서 제거해야한다.

공유 데이터는 NoSQL 등에 저장할 수 있다.

1.5 데이터 센터

엄청 커져서 분산된 데이터 센터가 만들어졌다면, 즉 다중 데이터센터 아키텍처가 만들어진 상황이라면

동기화, 테스트 ,배포 등에 고려할 점들이 많다.

시스템 컴포넌트들을 분리하여 독립적으로 확장할 수 있도록 구성해야한다.

1.6 메시지 큐

비동기 통신을 지원하기 위한 메시지 큐는 메시지의 버퍼 역할을 하며 비동기적으로 전송한다.

카프카, Rabbit MQ 등에서 다뤄볼 수 있다.

메시지 큐를 이용하면 서비스 또는 서버간 결합이 느슨해져서 규모 확장성을 보장하는 애플리케이션을 구성하기 좋다.

1.7 로그, 메트릭 그리고 자동화

로그: 애플리케이션에서 발생하는 개별 이벤트로 에러 로그를 통해 오류를 찾을 수 있다.

메트릭: 시스템의 상태를 파악할 수 있다.

• CPU,  메모리 등 호스트 단위 메트릭
• 캐시 성능, 디비 성능인 종합 메트릭
• 재방문, 일별 능동 사용자 같은 것이 핵심 비즈니스 메트릭이라고 한다.

자동화: ci/cd등을 통한 생산성을 높이는 도구 또는 코드 검증 절차 자동화 등 개발 생산성을 향상 시키는 것

1.8 데이터베이스의 규모 확장

데이터베이스 또한 수직적/수평적 확장을 할 수 있다.

수직적 확장

• 스케일업
• 기존 서버에 더 많은 자원(CPU, RAM 등)을 증설하는 방법
• 많은 양의 데이터를 보관하고 처리할 수 있다.
• 단일 포인트 실패로 인한 문제점이 크다.
• 비용이 많이 든다

수평적 확장

• 데이터베이스의 수평적 확장은 샤딩이라고 부른다.
• 더 많은 서버를 추가함으로써 성능을 향상시킨다.
• 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술로 각각의 샤드에 보관되는 데이터 사이에는 중복이 없다.

안정적인 시스템 규모 확장을 위해서는

웹 계층은 무상태 계층으로, 모든 계층에는 다중화를 도입하고 데이터 계층 샤딩은 필수

각 계층은 독립적 서비스로 분할하며 모니터링과 자동화 필수

에러 메시지

Caused by: java.lang.AssertionError: assertion failed: Concurrent update to the commit log. Multiple streaming jobs detected for

원인

로그에 동시 업데이트 하기 때문에 발생

스파크 스트리밍에서 동일한 체크포인트 위치에 두 개 이상의 다른 스파크 작업이 업데이트 하려 할 때 발생한다.

이 때 스파크 설정의 checkpointLocation을 다른 위치로 사용하면 해결할 수 있다.

두 개의 다른 스파크 스트리밍 작업에서 checkpoint 위치를 다르게 한다.

      .option("checkpointLocation", checkpointPath1)

      .option("checkpointLocation", checkpointPath2)

새로 받은 Mac에 Java 설치

먼저  Homebrew를 설치한다.

1. Java (OpenJDK) 설치

$ brew install cask

$ brew tap adoptopenjdk/openjdk

- OpenJDK8 설치

$ brew install --cask adoptopenjdk8

2. Java 버전  변경

- 설치된 JDK 버전 확인

$ /usr/libexec/java_home -V

- 변경

# 1.8 버전으로 변경
$ export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)

# 11 버전으로 변경
$ export JAVA_HOME=$(/usr/libexec/java_home -v 11)

spark-sql이 데이터를 빠르게 search 하는데 효과적이긴 하지만 데이터가 너무 크거나 복잡한 연산을 필요로 할 때는 Spark RDD API를 사용하는 것이 더 나을 때가 있다.
스칼라로 코드를 작성할 수 있기 때문에 복잡한 연산을 표현하기에 더 직관적이고 적절하다.

combine 관련 연산 중 가장 많이 쓰이는 두 개의 메소드가 groupByKey와 reduceByKey이다.
groupByKey보다는 reduceByKey가 더 효율적으로 구현되어 있다.

그래서 공식 API 문서를 비롯한 여러 곳에서 groupByKey 사용을 권장하지 않고 있다.

이유는 map-side combine이 효율적인데 groupByKey는 map-side combine을 하지 않도록 되어있기 때문이다.

https://databricks.gitbooks.io/databricks-spark-knowledge-base/content/best_practices/prefer_reducebykey_over_groupbykey.html
(groupByKey 보다 reduceByKey가 더 나은 이유)

1. Homebrew를 통해 설치 (시간이 조금 걸린다)

>> brew install redis

2. redis server 시작

>> brew services restart redis

3. redis-cli 접속

>> redis-cli

4. redis info 확인

>> brew info redis

위와 같이 사용 가능.

port는 6379인 것으로 확인

Redis 특징

• key-value 형태의 NoSQL
• in-memory 기반으로 세컨더리DB 정도로 활용

Linux 에서 shell 파일 수정하거나 스크립트 파일 볼때 vi {경로} 명령어로 접근하는데

아래와 같은 문구가 노출되고 vi 창에서도 이상하게 뜬다.

E437: terminal capability "cm" required
Press ENTER or type command to continue

이상하게 보이더라도 파일 수정은 해야하는데 수정조차도 잘 안돼서 찾아보니

아래의 명령어를 실행한 뒤 vi 를 실행하면 해결된다.

 export TERM=vt100

끝