[Chapter 01] Q&A

[janeljs]

[Chapter 01] 사용자 수에 따른 규모 확장성

• 궁금한 점 혹은 이야기하고 싶은 주제 코멘트로 정리
• 추가로 같이 보면 좋을 것 같은 기술 블로그, 아티클 등 공유

[janeljs]

지선

• 아주 많은 양의 데이터를 저장해야 할 때는 왜 NoSQL이 유리한가?
• multi master나 circular replication이 적용되어 있는 사례
  • 웹툰도 MMM 적용하여 master, stand by master, slave 등 사용하고 있음
  • https://www.slideshare.net/NHNFORWARD/mysql-nhn-forward-2018
  • https://jwdeveloper.tistory.com/215
• 하나의 데이터베이스를 여러 샤드로 쪼개고 나면 조인하기 힘들어지는 이유는? 비정규화밖에 해결책이 없는가?
  • https://engineering.linecorp.com/ko/blog/line-manga-server-side/
  • 두 개 이상의 샤드에 대한 JOIN 연산을 할 수 없다
  • https://d2.naver.com/helloworld/14822
  • 민석님) master에서 읽기연산을 한다면 조인할 일이 없으니까 괜찮지 않을까?

[KKambi]

한비

느낌

• 모든 것을 처리하는 1대의 서버로 시작해서, 각 컴포넌트가 주어진 작은 역할만을 수행하고 고가용성을 고려한 대규모 시스템으로 발전한다.
• 현실에서도 면접에서도 커다란 시스템에 대한 생각을 단 한 번에 전개하는 건 어려운 것 같다. 쌓아가는 연습!

비관계형 데이터베이스의 종류

aws - NoSQL이란?

1. key-value store
2. graph store (위키백과)
   • node + edge + property
   • NoSQL이지만 엔티티(노드) 간의 관계를 중시해서 엣지로 표현
   • 데이터 간의 관계를 신속하게 쿼리해야 할 때 (ex. SNS, 추천 엔진, 이상 탐지 등의 사용 사례에 유용)
   • index-free adjacency = enforces the nodes to have direct physical RAM addresses and physically point to other adjacent nodes
   • 
3. column store (wide-column store, column family oriented) (위키백과) (블로그)
   • column-oriented랑 다르다!
   • key:value:mutliple columns (two-dimensional key–value store)
   • 
4. document store (document-oriented)
   • value에 JSON과 유사한 형식의 문서가 저장될 때
   • 어플리케이션에서 사용하는 것과 동일한 문서 모델 형식 사용 가능
   • 관계보다 데이터 자체, 관계를 내장 객체로 표현 가능, 유연한 스키마

데이터(JSON, YAML, XML 등) 직렬화의 정확한 의미

자료구조나 객체를 저장할 수 있거나, 재구성 & 전송할 수 있는 형식으로 변환하는 과정

• 저장 : in a filer or memory data buffer
• 전송 : over a computer network
• 재구성 : possibly in a different computer environment

JSON으로 직렬화한다 = 네트워크를 통해 데이터를 전송하기 위해 범용적인 데이터 포맷으로 변환한다.

• 문법상 자바스크립트를 따르지만 프로그래밍 언어나 플랫폼에 독립적

Java에서의 직렬화 = 다른 외부 자바 시스템에서 사용하기 위함

• 객체를 바이트 스트림으로 변환
• 별도 라이브러리 없이 간편하게 할 수 있지만, 다른 언어에서 역직렬화하기 어렵다.

왜 NoSQL에서 낮은 latency를 자랑할 수 있는지?

정확히 설명한 글은 찾지 못했지만, RDB에 비해 조회가 간단하다보니 레이턴시가 짧다고 하는 것 같다. NoSQL의 장점으로 낮은 지연시간을 꼽은 글들은 많았다.

[zziri]

지훈

• 대부분 서비스가 DB 읽기 연산이 많으니까 Slave DB를 여러개 두어서 읽기 연산을 처리하는데, 쓰기 연산이 많다면..?

  • 성능은 놓치더라도 메시지 큐를 사용해서 DB(Master) 서버가 버틸(?) 수 있을 정도로 쓰기 속도를 조절하면 장애 없이 운영이 가능할듯

• Spring Framework의 @CacheEvict는 어떻게 동작할까?

  • 캐시된 데이터를 제거하는 형태로 동작함. 제거 후 다음 참조에서 renew
  • CacheEvict.html
  • Annotation indicating that a method (or all methods on a class) triggers a cache evict operation.
    • Evict the mapping for this key from this cache if it is present.

• 시의성??

  • 시간에 민감한, 자주 변하는 데이터를 시의성이 중요한 데이터라고 할 수 있음

• JS로 CSS를 컨트롤해도 CSS는 정적 컨텐츠일까..?

  • JS가 결국 정적 컨텐츠이니 CSS도 정적 컨텐츠로 취급하고 CDN으로 캐싱해도 문제는 없을듯

• NoSQL은 왜 규모확장이 간편한지??

  • JOIN을 하지 않기 때문에 특정 key에 대한 value가 다른 DB서버에 있어도 상관 없음, 그러므로 분산이 간편함
  • https://stackoverflow.com/questions/8729779/why-nosql-is-better-at-scaling-out-than-rdbms
  • RDBMS는 서로 다른 서버와의 JOIN을 위해서는 별도의 세팅이 필요하고, 비용도 크기 때문에 오히려 복제가 나을 수도 있음
  • https://stackoverflow.com/questions/11114197/join-tables-from-two-different-server

[kihyun-yang]

기현

• MySQL을 샤딩하는 것은 어려운 일인가?
  • 사내에 nBase-T라는 여러 상용 DB를 기반으로 데이터 분산 및 리밸런싱을 통해 DB scale-out 을 제공하는 플랫폼이 있음
• 샤딩된 데이터간 조인 불가
  • 몽고디비에서는 embedded document로 대체??
  • https://velog.io/@hanganda23/MongoDB-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81
• 샤딩돼있을때, 트랜잭션 처리는 어떻게?

[meloncha]

민석

로드밸런서의 동작 방식

• 어떤 로직으로 트래픽을 자동 분산하는가
• 로드밸런싱 : 여러 서버가 분산 처리하는 것

1. L4 로드 밸런싱 : L4 계층에서 동작하는 로드밸런서

네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 로드를 분산. IP주소, 포트번호, MAC주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산처리할 수 있다. CLB(Connection Load Balancer) or SLB(Session Load Balancer) 라고 부르기도 한다. 라운드 로빈(Round Robin) : 세션을 각 서버에 순차적으로 맺어주는 방식. 단순히 순서에 따라 세션을 할당하므로 경우에 따라 경로별로 같은 처리량이 보장되지 않는다. 가중치 및 비율 할당 방식 : 서버마다 비율을 설정해두고 해당 비율만큼 세션을 맺어주는 방식 최소 연결(Least Connection)기반 : 가장 적은 세션을 가진 서버로 트래픽을 보내는 방식 (가장 선호) 응답 시간(Response Time)기반 : 가장 빠른 응답 시간을 보내는 서버로 트래픽을 우선 보내주는 방식. 각 서버들이 가용한 리소스와 성능, 그리고 처리 중인 데이터 양등이 다를 경우 적합한 방식 해시(Hash)기반 : 특정 클라이언트는 특정 서버로만 할당시키는 방식. 경로가 보장되며 접속자 수가 많을수록 분산 및 효율이 뛰어남 대역폭(Bandwidth) 기반 : 서버들과의 대역폭을 고려하여 트래픽을 분산하는 방식

2. L7 로드밸런싱 : L4 로드밸런서의 기능을 포함하며 OSI 7계층의 프로토콜 (HTTP, SMTP, FTP등)을 바탕으로도 분산 처리가 가능

ALB(Application Load Balancer) 라고 부른다. L7 위에서 동작하기 때문에 IP, Port 이외에도 URI, Payload, Http Header, Cookie 등으로 부하를 분산한다. 콘텐츠 기반 스위칭이라고도 한다.

L4 로드밸런서는 단지 부하를 분산시키는 것이라면, L7 로드 밸런서는 요청의 세부적인 사항을 두고 결제만 담당하는 서버, 회원가입만을 담당하는 서버 등으로 분리해서 가볍고 작은 단위로 여러 개의 서비스를 운영하고 요청을 각각의 서버에 분산할 수 있다. L7 로드 밸런서는 데이터를 분석해서 처리가 가능하기 때문에 악의적이거나 비정상적인 컨텐츠를 감지해 보안 지점을 구축할 수 있다.

L7가 L4를 포함하는데 두 개가 나뉘어 있는 이유?

L4 부터는 IP주소와 Port 번호를 활용하여 라우팅이 가능하여 자주 사용한다.

L7 은 소프트웨어를 사용해야 하므로 비용이 더 많이 들어 L7 수준에서의 로드 밸런싱이 필요한경우 사용하고 그게 아니면 비용이 저렴한 L4를 사용한다.

데이터베이스 다중화

• 주 데이터베이스를 추가하면 동일 데이터를 업데이트 하는 경우 문제가 생길 수 있지 않을까?
• 어떻게 해결할까?

→ 주 데이터베이스가 다중화되는 것 : Multi-Master

MMM (Multi-Master Replication Manager)

• Multi-Master 를 돕기 위해 MMM를 사용
• 2개의 주 데이터베이스를 위한 것은 아님
• 한 개의 데이터베이스에 장애가 일어날 때 바로 복구하기 위함
• 1개는 Master(Active) 다른 하나는 Master(Passive)로 설정
• Active 에서 장애 발생시 Active 접속을 차단하고 Passive 서비스로 접속을 넘긴다

캐시 계층

• 별도의 캐시 계층을 두는 것과 Spring 내의 캐시, DB의 캐시와의 차이는 무엇일까?

캐시의 종류

• 로컬 캐시 (EHcache)
  • Spring 에서 간단하게 사용할 수 있는 Java 기반 오픈소스 캐시 라이브러리
  • Spring 내부적으로 동작하여 캐싱 처리를 한다
  • redis 같이 별도의 서버를 사용하여 생길 수 있는 네트워크 지연 혹은 단절 같은 이슈에서 자유롭다
  • 로컬캐시로서 특정 서버에 종속된다. 멀티 서버 환경에서는 데이터 싱크가 필요하다. 데이터 접근은 빠르다
• DB 내부 캐시
  • MySQL Query Cache
  • SELECT 쿼리의 결과를 캐싱해주는 Query Cache 라는 최적화 기능을 제공한다
  • 5.7 부터는 deprecate 되었고, 8.0 부터는 제거되었다.
  • MySQL Query Cache 설정을 켤 수 있다
  • 장점
    • Query Cache 를 사용하는 쿼리라면 해당 쿼리가 Query Cache에 존재하면 Parsing, Optimizing, Executing 을 거치지 않고 캐시에 담겨있는 데이터를 반환한다
    • 쿼리의 비용이 크고, 반복적으로 호출되는 쿼리일수록 리소스 면에서 큰 이점을 얻을 수 있다
  • 단점
    • 대상 테이블에 대한 변경 (INSERT, UPDATE, DELETE)이 있었다면 확인하지 않고 기존의 캐시를 제거한다
    • Query Cache는 여러 세션(쓰레드)들이 공유하는 자원이기 때문에, 동기화를 위한 lock 이 필요하다 (Query Cache Lock)
    • 테이블의 변경으로 캐시를 제거하는 시점에 다른 쓰레드에서 유효하지 않은 데이터를 가져가지 못하도록 lock을 걸게 된다. lock이 풀릴 때까지 Query Cache에 접근하는 쓰레드들은 waiting 상태에서 대기한다
    • 테이블의 변경이 잦을 수록, Query Cache를 사용하는 SELECT 쿼리가 많을수록 lock을 waiting하는 시간은 많은 비중을 차지하게 된다. (배보다 배꼽이 더 큰 셈)
• CDN
• in-memory 캐시 (redis, memcached)
  • 독립적인 캐시 서버로 구축되어 네트워크 통신으로 서버들이 데이터에 접근한다
  • 속도는 로컬보다 느리다
  • 데이터 동기화 이슈가 없다

메시지 큐

• 메시지 큐가 효율적인 예시가 무엇일까?

메시지 큐를 사용하는 경우

• 메시지 큐는 Consumer가 실제로 메시지를 어느 시점에 가져가서 처리하는지는 보장하지 않는다
• 이러한 비동기적 특성 때문에 메시지 큐는 실패하면 치명적인 핵심 작업보다는 어플리케이션의 부가적인 기능에 사용하는 것이 적합하다
• 예) 이메일 전송, 블로그 포스팅시 고용량 이미지 사후처리하며 최적화

[travelbeeee]

현석

Question

• NoSQL 이 데이터가 많을 때 유리한 이유 ( 지선님과 질문 중복 )
  • NoSQL 데이터베이스는 단순 검색 및 추가 작업에 있어서 매우 최적화된 키 값 저장 기법을 사용하여, 응답속도나, 처리 효율 등에 있어서 매우 뛰어난 성능
  • RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼, 페타바이트급의 대용량 데이터를 저장할 수 있다.
  • A. 분산형 컴퓨팅에 유리하므로 서버를 쉽게 늘려서 대용량 데이터를 처리할 수 있다.
  • ( 빅데이터는 비정형데이터인 경우가 많아서 SQL 보다 유리하다는 관점도 있다. )
• 다른 팀에서도 춘천/가산으로 서버, DB가 분산되어있는지??
  • 춘천/가산으로 서버, DB가 분산되어있는 케이스가 '데이터 센터' 사례인가
• "하나의 DB를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들고 이를 해결하기 위한 하나의 방법이 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 하는 것이다." 라고 책에 나와있는데, 그러면 N 개의 샤드로 쪼개고, 1개의 샤드에는 모든 데이터가 모여있고, N - 1 샤드에 데이터가 분산되는 것인가...?? 하나의 테이블이 무슨 뜻일까
  • 비정규화를 하면 join 할 필요가 없어진다.

[easyfordev]

이지

Comment + 약간의 설명

• NoSQL
  • NoSQL의 4가지 분류, 비관계형 DB가 바람직한 경우 : NoSQL을 딱 한단계만 들어가서 물어볼 수 있는 좋은 내용인 것 같다.
  • '데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 될 때 NoSQL이 바람직하다' : (이해한 내용) 그냥 단순히 ‘잠시 저장'만 하면 될 때. DB가 스쳐가는 용도이기만 할 때를 말하는 것 같다.
• Scale out
  • 스케일 아웃과 스케일 업을 헷갈리지 말자!
  • 수평적 확장은 빅데이터 플랫폼인 Hadoop의 토대(가장 대표적인 특성?) 같은 것이다
• 데이터베이스 다중화의 효과 중,
  • 더 나은 성능 : 병렬로 처리될 수 있는 query의 수가 늘어나므로, 성능이 좋아진다. -> 그냥 성능이 좋아져요! 라고 말할 수는 있었는데, 왜 성능이 좋아지나요? 라고 했을 때 자신이 없었다. 이렇게 대답하면 되는구나!
  • 안정성(reliability) : 자연재해로 일부 서버가 파괴되어도 데이터는 보존된다. 데이터를 지역적으로 떨어진 여러 장소에 다중화시켜놓을 수 있기 때문이다.
    • 하둡에는 rack awareness라는 개념이 있다. 멀리 떨어진 지역까지 분배해놓는 개념은 아니지만, 해당 서버의 rack 을 인지하게 하고, rack 단위로 분산해놓는 설정이 있기도 하다.
• 데이터 센터 중 하나에 심각한 장애가 발생하면, 모든 트래픽은 장애가 없는 데이터 센터로 전송된다.
  • 저희도... 춘천에 하나 있고, 안양 평촌에 하나 있죠. 해외에도 있는걸로 알고있습니다. (저희 팀 같은 경우는 gw를 위해서 물리적으로 해외에 위치한 프록시 전용 서버들이 있어요)
• 메세지 큐 : 생산자는 소비자 프로세스가 다운되어있어도 메시지를 발행할 수 있고, 소비자는 생산자 서비스가 가용한 상태가 아니라도 메시지를 수신할 수 있다.
  • 전형적인 카프카의 주요 개념. 메시지 큐 분야는 RabbitMQ, Kafka가 대표적인 것 같다.
• 서버 단위로 모니터링할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리함
  • 예시 : logstash, filebeat
• 메트릭 수집 : 시스템의 현재 상태를 손쉽게 파악할 수 있음
  • 프로메테우스, 그라파나 조합이 국룰인듯함
• 샤딩 키를 정할때는 데이터를 고르게 분할할 수 있도록 하는 게 가장 중요함
  • 데이터의 cardinality라는 개념이 있는데, 알아두면 좋을 것 같습니다.
• 조인과 비졍규화 : 여러 샤드에 걸친 데이터를 join하기 힘들어짐. 해결 방법은 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 하는 것
  • 뭔가 항상 ‘정규화'가 정답인 것 처럼(단어도 ‘정규'화임..) 생각했는데, 이런 상황에서는 역정규화가 정답일 수도 있겠다는 생각을 한다. 실제로 동일한 원리로, 빅데이터 분야에서는 데이터를 역정규화 하는 경우가 흔하다.

Question

• Master - Salve 구조에서 장애가 발생했을 경우 Failover 시나리오에서, Slave 서버에 보관된 데이터가 최신 상태가 아닌 문제를 해결할 수 있는 방법으로 Multi Masters, Circular replication가 나온다.
  • 마스터 다중화는 알겠는데, Circular replication은 뭘까? (아시는분 설명해주실 수 있을까요?) 나중에 찾아볼 필요가 있겠다..!

[meloncha]