50일차 초간단 회고
벌써.. 에프랩 시작한지 50일이 되었다. 뭐 한것도 없는데 시간 왜이렇게 빨리가..
주어진 시간 100%를 공부하는데 쓰고 싶긴 한데, 조금 더 취미 생활을 즐기고 싶다는 욕심에 알바를 시작해버려서 + 생각만큼 공부에 시간을 많이 쏟지 못하고 있는듯 해서 많이 아쉽다!!
하지만 그럼에도 불구하고 어떻게 해야지.. 조금씩 조금씩이라도.. 일단 목표는 하루 3-4시간 이상 코딩에 쏟아붓는 것이다. 어떻게든 되겠지. 내일은 프로젝트 코드 베이스를 만들고 환경을 구축할 것이다. ERD는 이미 만들었다.
Kafka / RabbitMQ
kafka와 rabbitMQ의 공통점이라고 하면 메세지 큐로 사용할 수 있는 솔루션들이라는 점이다. 메세지 큐란 무엇이냐? (전날도, 전전날에도, 그 전전날에도 설명했지만 다시 설명해서 나쁠 것 없으므로 또 설명함) 메세지 단위의 데이터를 비동기적으로 처리할 수 있게 해주는 큐이다.
사용자 요청에 대해, 처리가 필요하지만 시간이 걸리고 당장에 응답으로 내려줄 필요가 없는 작업의 경우 Producer 프로세스/스레드가 로직 처리에 필요한 데이터를 메세지 큐에 넣을 수 있다. 그럼 그것을 소비하는 Consumer가 비동기적으로 해당 데이터를 메세지 큐에서 꺼내,
굳이 예시를 생각해보자면? 검색용 DB엔진으로 ES를 쓰는 상황에서, ES index에 document를 insert를 하는 것은 시간이 꽤 걸리는 작업이므로 사용자의 insert 요청에 대해 동기적으로 ES 작업을 모두 끝마친 뒤에
사실 아키텍처적인 구조 차이도 존재하지만, 지금 수준에서 프로젝트에 어떤 메세지 시스템 솔루션을 선택할까? 에 대해 생각해볼 수 있는 차이점을 모아보았다.
# RabbitMQ
- 유연한 라우팅 규칙 적용 가능
- 메시지 전송 타이밍 제어(메시지 만료 또는 메시지 지연 제어)
- 소비자가 메시지 처리에 실패할 가능성이 더 높은 경우 고급 오류 처리 기능
- 단순하게 소비자 기능 구현 가능
# Kafka
- 엄격한 메세지 순서관리
- 과거 메시지 재생 가능성을 포함하여 장기간 메시지 보존
- 기존 솔루션으로는 충분하지 않는 대규모 구조
뭔가, kafka는 조금 더 대규모 분산 시스템에서 메세지를 뿌리는데 강력한 느낌이고 rabbitMQ는 Consumer의 메세지 확인이 보장된다는. 그런 느낌이다.
SQL / NoSQL
저장소(DB)의 서로다른 구조이다. 엄밀히 말하면 SQL은 Query Language지만.. RDB와 다른 개념인 NoSQL(=Not only SQL)과의 비교를 위해 그냥 SQL이라고 부르겠다.
둘의 가장 큰 차이점은 데이터가 정형화되어있냐이다. SQL, 즉 RDB에선 "테이블"이라고 불리는 정형화된 데이터 틀이 있다. 데이터 틀에는 column이라고 불리는 필드가 있는데, 정해진 type의 자료구조가 정해진 개수만큼 들어가야 한다. 만약 type이 불일치하거나, 테이블에서 지정한 조건을 맞추지 못하면(최대 문자열 길이라든가, Not null 등의 조건) 데이터는 저장되지 못한다.
이에 반해 NoSQL은 훨씬 자유로운 데이터 저장을 가능하게 해준다. 따로 데이터 테이블이나 정해진 스키마가 없고,
SQL의 장단점
- 장점
- 명확하게 정의된 스키마, 데이터 무결성 보장
- 관계는 각 데이터를 중복없이 한번만 저장
- 단점
- 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듦)
- 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
- 대체로 수직적 확장만 가능함
NoSQL의 장단점
- 장점
- 스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
- 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
- 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능
- 단점
- 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
- 데이터 중복을 계속 업데이트 해야 함
- 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)
요컨데, 명확한 자료구조에 대해 정해진 structured query를 많이 날리는 상황이라면 SQL을, 비정형 데이터의 수평적 확장을 생각하고 있다면 NoSQL을 쓸 수 있을 것 같다.
REDIS
1) key-value 쌍으로 데이터를 저장한다.
한마디로 dictionary 자료구조라는 것이다. 파이썬으로 알고리즘 풀다보면 dictionary없이는 안되는 상황이 18157439번 발생하는데.. (갑자기 딴얘기?!) 자바에선 Map으로 표현된다.
Dictionary, Map의 주요한 특징은 key를 hash값으로 저장하기 때문에, 일반적으로 O(1)의 시간 복잡도로 value 검색이 가능하다. key값만 있다면 조회에 엄청나게 유리하다는 말이다. 물론 그만큼 기본적으로 차지하는 데이터 용량이 많고 해시 연산을 위한 추가 작업이 필요하고 해시 충돌이 날 경우 단순 list와 비슷해진다는 단점이 있지만 ..
아무튼. REDIS는 key-value 쌍으로 데이터를 저장하기 때문에 빠른 검색이 가능하다.
2. In-Memory 자료구조이다.
CPU는 매우 빠른 계산장치임에 비해서 CPU에게 "계산할 거리"를 주는 놈들은 꽤나 느리다. 하드웨어 관점에선 레지스터 - L1캐시 - L2캐시 - RAM - 하드웨어 저장소(SSD, HDD 등)순의 접근 속도를 가졌다.
웹 어플리케이션 관점에서 보면, HDD가 DB가 되시겠다. DB는 보통 서버 인스턴스를 따로 두기 때문에 접근을 위해 접근 요청을 날려야하고, 쿼리를 구성해서 요청해야하고, DB에서 쿼리 연산을 하고, 응답을 받고.. 하는 과정이 이뤄져야 한다. 한마디로 느리다는 뜻이다. 사용자 요청 하나에 WAS의 DB서버 요청이 포함되니 응답은 더욱 느려질 수밖에 없다.
그러나 Redis는 인메모리 자료구조를 사용한다. 위에서 설명했던 "RAM"(참고로, RAM은 Random Access Memory로 컴퓨터에서 사용되는 메인 메모리이다)에 해당한다. 당연히 DB보다 접근 속도가 빠르다.
자바의 HashMap 역시 key-value 쌍이고, In memory 자료구조인데 왜 안쓰냐? 고 한다면, 일단 웹 어플리케이션은 로직을 수행하는데 중점을 둬야지 데이터를 저장하는 것 자체에 RAM을 소비하면 안된다 - -;. 그리고 보통 성능을 위해서 여러 대의 서버를 두고 Nginx같은 WS로 로드밸런싱을 하게 되는데, 이 때 서버마다 다른 인메모리 데이터를 갖게되면 서버간 데이터 불일치가 일어날 수도 있다. 또한! Tomcat은 멀티스레드 환경에서 동작하는데, 여러 개 스레드에 대한 Race condition이 발생할 수도 있다.
REFERENCE
https://velog.io/@cho876/%EC%B9%B4%ED%94%84%EC%B9%B4kafka-vs-RabbitMQ#2-kafka-vs-rabbitmq
