시스템 디자인 7주차

Rating Limiting

개념

혼잡 제어(flow control)기법으로  traffic rate를 제한한다.

배경

server에서 처리할 수 있는 throughput이 정해져 있다. 하지만 과도한 트래픽이 들언다면 시스템 전체의 성능을 떨어뜨리게 되고 심한 경우 시스템이 다운될 수 있다. Rating Limiting은 이러한 현상에 대한 방어를 할 수 있다.

Dos, DDos공격을 막기 위한 방법이 될 수 있다.

DOS, Denial-Of-Service : 특정 네트워크 또는 리소스에 합법적인 유저가 접근하지 못하도록 방해하는 공격,
막대한 양의 트래픽을 집중하여 서버의 다운을 유도나 악의적인 요청을 통한 리소스 오작동 유도

DDOS, Distributed Denial-Of-Service : 분산 서비스 거부 공격, 여러대의 공격자를 분산적으로 배치하여,
동시에 서비스 공격하여 서버의 다운을 유도함.

작동 방식

받아들이는 요청을 초당 제한한다.

client가 1초마다 하나의 요청만 할 수 있도록 rate limit를 했다고 가정했을 때 Redis와 같이 access를 빨리할 수 있는 DB에 client 식별자를 key로 가장 최근 요청이 들어온 시간을 저장해둔다.

요청이 들어왔을 때 최근 요청이 들어온 시간과 현재 시간의 차가 1초보다 작다면 요청을 처리하지 않고 1초보다 크다면 정상적으로 요청을 처리한다.

redis : key-value 형식의 데이터 관리 시스템이다. remote에 위치하며 process로 존재하는 memory기반이다.
Cache로 사용할 수 있으며 Presistence Data Storage로 사용할 수 있다.

첫번째 요청

첫번째 요청 후 0.1뒤 요청

2초 뒤 요청

Client당 요청할 수 있는 제한을 둔다.

IP는 region정보를 가지고 있다.

• 만약 특정 정신병이 있는 국가로 부터 짧은 시간동안 너무 많은 요청이 들어와 공격이 의심되면 해당 지역에서 오는 요청을 완전히 차단할 수 있다.
• Instagram을 예시로 들어본다면 팔로워가 일반 유저보다 월등하게 많은 셀럽의 경우 요청의 한계(limit)를 다른 유저보다 높게 설정(rate limiter를 느슨하게 설정)하면 된다.

위의 예시와 같이, rate limiting은 Security Reason이 있고, limiting을 할 떄 비즈니스를 충분히 인식시킬 수 있다.

Logging & Monitoring

Logging

• Time Series DB는 하나 이상의 시간과 하나 이상의 값의 value pair를 통해 시계열을 저장하고 서비스하는데 최적화 된 NoSQL이다.
• 주로 Log를 적재하는데 사용된다.
• 장애가 발생했을 때 이를 확인하는 용도로 사용해야 되므로 시계열DB를 이용하여 Logging할 수 있다.
• 예를 들어 한 client가 결제를 요청하는 상황을 가정했을 때 Client는 이미 돈을 지불했지만 Server에 access가 되지 ㅇ낳아서 정상적으로 결제가 처리되지 않는 상황이다.
• 이러한 Client요청이 수기로 처리할 수 없는정도의 양이 된다면, 모니터링이 중요하다.
• Response가 어떻게 되었는지, Latency가 어느정도인지, 어떤 Client에게 보내는지, 어떤 예외사항이 발생하는지에 대한 로그를 적재해야하고, 플랫폼 or Service or Company마다 logging structure가 다르다.
• Logging Structure를 어떤식으로 구축해놓는지에 따라, Log에서 얻을 수 있는 정보는 서비스가 성장하였을 때 디버깅을 어떻게 할지에 대하여 정하게 된다.
• 단순히 코드를 잘 작성하는게 문제가 아닌, 어떤 정보를 가지고 어떻게 사용할 지가 매우 중요하다. (이전 회사에서 했던 RPA프로젝트의 경우 측정가능한 모든 예외사항에 대한 로그를 남기도록 했고, 예외 사항이 발생할 경우 로그에 남겨진 정보를 유용하게 사용했다.)
• 이러한 로그는 "When"이라는 정보가 중요하기 때문에 Time serise DB를 사용한다.
• 모니터링 툴로 Google stack driver, Prometheus 등이 있다.

Publish & Subscribe

Design Pattern의 일종이다.

Polling, Streaming과 코드베이스가 비슷하다

4가지 주요 entity가 있다.

• Publisher, Subscriber, Topic, message
• 암호화폐의 코인 종목을 구독하면 관련 정보가 계속 업데이트가 되는 서비스가 있다고 가정하자.
• A는 비트코인 topic, 도지코인 topic을 subscribe하고 있다. 그럼 A는 비트코인과 도지코인에 대한 실시간 데이터를 바로 확인할 수 있다. 이를 가능하게 해주는 Pattern이 publisher, subscribe pattern이다.
• publisher - subscribe 관계는 Server와 Client의 1:1관계성이 존재하지 않는다. Client는 자신이 subscribe하는 Topic만 listening한다. 해당 topic을 observe하며 변화를 listening한다.
• publisher는 topic에 해당하는 message(logic, data, function)을 채널에 넣는다. 이 채널을 Queue라고 생각하자. 이를 실제로 받아볼 Client가 누구인지 Server는 전혀 모른다. 단지 Topic에  맞게 message를 Queue에 push만 해준다.
• 즉 Server와 Client는 서로 어떠한 관계도 없다.
• Server(publisher) and client(subscriber) do not know each other.
• H/W로써 Server와 Client중간의 터널은 어떻게 되어 있을까?
• Topic1, Topic2, Topic3는 정확히 말하면 DB(Permanent storage)이다. Topic에는 다양한 형식의 Data가 들어갈 수 있다.
• Topic은 Server가 Message를 push하면 이를 그냥 간직하고 있다. 구독한 것에대한 알림, 실시간 chat과 같은 기능에 사용된다.
• 예를 들어, Instagram의 셀럽이 posting을 했을때 팔로워들에게 알림이 가는 시스템라고 가정해보자.
• 팔로워 리스트를 돌며 한명씩 Push를 보낸다면 시간이 오래 걸릴것이다.
• 이를 publish - subscribe pattern을 이용한다면 Server는 해당 메시지를 Queue push만 하고 바로 다음 작업을 실행한다.
• 그리고 팔로우하고 있는 User들은 Queue에 올려진 메시지를 가져간다. 
• 그러므로 이는 비동기적으로 작동한다.
• 상용 서비스로는 Apache Kafka, Google Cloud Pubsub등이 있다.
• 위의 서비스 들은 Message Queue에 쌓에는 데이터가 커지더라도 Sharing도 해준다.