Part4. +a

📌 이 글을 왜 쓰는가
서버와 네트워크. 웹의 동작원리를 알고 나니 궁금한 게 하나둘씩 더 생겨났다. 대규모 트래픽에 대해 대응하려면 분산 서버 아키텍처 설계는 어떻게 해야 하는지, DB는 어떻게 엮어야 하는지, 검색 데이터 파이프라인 개발은 어떻게 해야 하는지, 대규모의 데이터를 처리하는 데이터 파이프라인은 어떻게 만들어야 하는지 주로 보면 DB와 서버에 관한 궁금증이 주인 걸 봐서 데이터 분야와 동시에 백엔드를 하더라도 이쪽 분야에 전념하고 싶다는 생각이 들었다. 약간 뒤죽박죽 섞인 채로 정리한 것 같은데 이제 진짜 제대로 하고 싶은 것들이 정해진 느낌이다 🙂

1. 대용량 분산 서버 아키텍처 설계

🚩 웹 개발자를 위한 대규모 서비스를 지탱하는 기술 - 이토 나오야, 다나카 신지 공저

1. 대량의 액세스가 있는 서비스에서는 서버 1대로 처리할 수 없는 부하를 어떻게 처리할 것인지가 가장 큰 문제다. 최근 10년 동안의 트렌드로는 이른바 '스케일아웃'이 이 문제에 대한 전략의 기초가 된다. 스케일아웃은 서버를 횡으로 전개, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여서 부하를 분사하는 방법이다. 반면 스케일업은 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법이다.

2. 예를 들면 사용자로부터의 요청을 어떻게 분배할 것인가? 해답으로는 로드밸런서를 사용한다는 것인데, 서버 1대일 때에는 애초에 로드밸런서를 도입하는 것 자체를 생각할 필요도 없을 것이다. 데이터 동기화는 어떻게 할 것인가? DB를 분산시켰을 때 한쪾에 저장된 갱신 내용을 다른 한쪽 DB가 알지 못한다면 애플리케이션에 비정상 사태가 발생한다. 네트워크 통신의 지연시간(latency)을 어떻게 생각해 볼 수 있을까? 작은 데이터라도 이더넷을 경유해서 통신한 경우는 밀리초 단위의 지연시간이 있다. 통신의 오버헤드를 줄여가면서 애플리케이션을 구성해갈 필요가 있다. 그밖에 스케일아웃에 동반하는 문제는 다방면에 걸쳐 있다.

3. 스케일아웃을 해서 서버 대수가 늘어나면 서버의 고장률도 필연적으로 올라가게 된다. 그러므로 어딘가 잘못되면 서비스가 전부 정지해버리는 설계는 24시간 365일 계속 가동되어야 하는 웹 서비스에서는 도저히 용납할 수 없다. 서비스가 대규모화되면 될수록 시스템 정지의 사회적 충격도 늘어나므로 더욱 더 다중성 확보가 중요해진다. 시스템이 고장 나면 그거로 끝이어도 괜찮은 시스템 구축과 고장 나더라도 다른 시스템이 자동적으로 처리를 인계받는 시스템 구축 간에는 기술적으로나 비용면에서 상당히 큰 차이가 있다.

4. 컴퓨터는 디스크(하드디스크)에서 데이터를 로드해서 메모리에 저장, 메모리에 저장된 데이터를 CPU가 패치(fetch)해서 특정 처리를 수행한다. 또한 메모리에서 패치된 명령은 보다 빠른 캐시(cache)메모리에 캐싱된다. 이처럼 데이터는 디스크 -> 메모리 -> 캐시메모리 -> CPU와 같이 몇 단계를 겨유해서 처리되어 간다. 디스크로부터 읽어들인 데이터를 메모리에 캐싱해둠으로써 전반적으로 디바이스간 속도차가 체감 속도에 영향을 주지 않도록 하고 있다. DB를 비롯한 미들웨어도 기본적으로 이러한 속도차를 의식한 데이터 구조, 구현을 채용하고 있다. 하지만 그래도 한계는 있다. 데이터량이 많아지면 처음부터 캐시 미스(cache miss)가 많이 발생하게 되고 그 결과로 저속의 디스크로의 I/O가 많이 발생하게 된다. 이처럼 대규모 웹 애플리케이션을 운용할 때 대부분의 어려움은 이러한 대규모 데이터 처리에 집중된다. 어떻게 하면 데이터를 적게 가져갈 수 있을까, 여러 서버로 분산시킬 수 있을 까, 필요한 데이터를 최소한의 횟수로 읽어들일 수 있을까 등등 이것이 본질적인 과제가 된다.

4. 제 1 포인트 '메모리 내에서 계산할 수 없다' 메모리 내에서 계산할 수 없게 되면 디스크에 있는 데이터를 검색할 필요가 있다. 하지만 디스크는 느리므로 I/O에 시간이 걸린다. 우선 메모리는 전기적인 부품이므로 물리적 구조와 탐색속도와 그다지 관계없다. 하지만 데스크는 메모리와는 달리 회전 등의 물리적인 동작을 수반하고 있다. 이런 물리적인 구조가 탐색 속도에 영향을 준다. 데이터가 많아지면 많아질수록 디스크와 메모리 차이도 나타나게 되므로 전송속도에서도 디스크는 늦어진다. os레벨에서의 연구와 전송속도, 버스의 속도차 공부도 필요.

5. 일반적으로 부하는 크게 두 가지로 분류된다. CPU부하/ I/O부하.

• CPU 부하의 규모조정은 간단하다. 같은 구성의 서버를 늘리고 로드밸런서로 분산, 웹,AP,서버,크롤러
• I/O부하의 규모조정은 어렵다. DB, 대규모 데이터

DB확장성을 확보하는 것은 상당히 어렵다. 대규모 환경에서는 I/O부하를 부담하고 있는 서버는 애초에 분산시키기 어려운데다가 디스크 I/O가 많이 발생하면 서버가 금새 느려지는 본질적인 문제가 있다. 어딘가의 시스템을 이용하면서 무겁게 느껴진다고 해서 '서버를 늘리지'라고 생각하는 것은 위험하다(claire 조심해라...)

6. 대규모 데이터를 다루기 위해

• 1) 어떻게 하면 메모리에서 처리를 마칠 수 있을까?
  • 디스크 seek 횟수 최소화하기
  • 국소성을 활용한 분산 실현
• 2) 데이터량 증가에 강한 알고리즘, 데이터 구조
• 3) 데이터 압축, 정보검색기술
  을 쓸 수 있는데 특히 검색이 중요한 이유는 확장성 면에서 DB에만 맡겨서 해결할 수 없을 때, 특정 용도에 특화된 검색엔진 등을 만들어서 해당 검색 시스템을 웹 애플리케이션에서 이용하는 형태로 전환한다면 속도를 제대로 확보할 수 있기 때문이다. 이러한 이유로 압축과 검색이 중요한 것이다.

7. 이번 글에서는 이정도만 요약하기로 하고 프로그램에서 대규모 데이터 다루기 전에 프로그램 개발의 한층 아래 기초인 OS 캐시, 분산을 고려한 RDBMS 운용, 알고리즘과 데이터 구조를 다음편에서 요약해보도록 하겠다!

2. 데이터 파이프라인 설계

🚩https://www.youtube.com/watch?v=rCbzilpjsdY 하루 400억 건을 처리하는 데이터 파이프라인 | 라인개발실록

• 데이터 파이프라인이 필요한 이유

기존처럼 서버를 구성하고 데이터베이스를 연결하면 트래픽이 많아지면 서버를 스케일아웃하면 되지 않냐? 데이터가 많아지면 데이터를 늘리면 되지 않냐? 데이터를 미러링해서 거기에 데이터를 쿼리하는 서버를 더 쓰면 되지 않냐? 자 그러면, 데이터가 너무 많아서 DB가 스케일아웃이 안되면? 단순히 서버를 분리하면 될까?
NO, 주요문제는 사이즈에서 온다. 데이터가 많아질수록 해결할 수 없다.

• over 10PB/ Aggregation Latency 10s/ SQL - SIZE DOES MATTER 사례 후 대용량 데이터를 조회하기 최적화된 걸 쓰자! Apache Druid! but also cannot meet the requirements! 성능이 떨어짐! - Apache Kylin meets all requirement!

• Kylin?
  

• LINE 광고 데이터 파이프라인 아키텍처
  

1) 모바일에서 광고를 보면 SDk에서 광고를 보내고 event receiver가 받고 event validator는 이 데이터가 중복은 없는지 밸리데이션을 해서 data loader가 받아서 각 목적에 맞는 곳에 저장을 한다 storages에! ES는 시각화에 쓴다
2) 이것들을 다시 재활용한다 ETL/batch를 통해서 혹은 OLAP 분석용 데이터베이스로 리포트를 만들기도 하고 Data API 데이터베이스 셋팅을 통해서 빠르게 조회할 수있도록 한다.
3) 각 컴포넌트에서 사용하는 주요 기술스택:

• Heron?
  

1) 스트리밍: 일반 데이터는 사용자의 입력으로 만들어지고 백엔드로 리쿼스트로 전달하고 처리된 결과를 전달하면 된다. 여기서 만들어진 데이터를 배치하는 걸 배치프로세싱/ single stage. 하지만 스트리밍은 한건한건 이벤트가 들어오면 바로 처리하는 걸 말함. 항상 long runnig processes/ multiple stage.

2) Heron: a realtime, distributed, fault-tolerant stream processing engine, apache heron is a re-architecture of apache storm

• 라인 광고 데이터파이프라인 팀에서 할 수 있는 경험: 대용량 데이터 처리, 그대로 하면 안되는 경험을 하게 됨, 다양성, 오픈소스에 기여, 여러 stakeholders와의 협업/ 어떤 개발자? 엔지니어링 기본기가 되어있는 엔지니어, 분산시스템에 대한 이해가 있는 엔지니어(mysql의 샤딩 혹은 카프카같은 분산메세지 큐에 대해서), 지속적으로 개선하기 위해 matric을 측정하고 모니터링을 한다(SRE).

<나중에 공부할 것>

🚩Google Cloud OnBoard Seoul OnAir ETL, 데이터 파이프라인 - https://www.youtube.com/watch?v=A8RpAFvbrl0
🚩확장성 있는 웹 아키텍처와 분산 시스템 - https://d2.naver.com/helloworld/206816