책너두 (데이터 중심 애플리케이션 설계) 34일차 (~393p)

요약

• 10장 일괄 처리에 대한 내용을 이해함.
  • 서비스 (온라인 시스템)
  • 일괄 처리 시스템 (오프라인 시스템)
  • 스트림 처리 시스템(준실시간 시스템)
• 유닉스 도구로 일괄처리하는 방법에 대한 내용을 이해함.
  • 단순 로그 분석
    • 유닉스 연쇄 명령 vs 맞춤형 프로그램
• 유닉스의 철학에 대해 이해함.
  • 유닉스 프로그램 여러개가 유연하게 조립하여 사용할 수 있음.
    • 유닉스 프로그램은 동일 인터페이스를 사용하기 때문
  • 로직과 연결을 분리할 수 있음.
    • 프로그램과 느슨한 결합을 유지하기에 작은 도구로부터 큰 시스템을 구성하기 훨씬 수월함.
  • 유닉스는 진행상황을 보기 편함.

메모

10장. 일괄 처리

• 웹과 점점 늘어나고 있는 HTTP/REST 기반 API 때문에 요청/응답 방식의 상호작용이 매우 흔해져서 이를 당연히 여김.
  • 하지만 이 방법이 시스템을 구축하는 유일한 방법은 아님.
  • 다른 접근법도 분명히 이점이 있음.
• 시스템을 3가지 유형으로 구분해 볼 수 있음.
  • 서비스(온라인 시스템)
  • 일괄 처리 시스템(오프라인 시스템)
  • 스트림 처리 시스템(준실시간 시스템)
• 일괄 처리는 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션을 구축하는 데 매우 중요한 구성요소임.
  • ex) 2004년 발표된 일괄 처리 알고리즘인 맵리듀스는 “구글을 대규모로 확장 가능하게 만든 알고리즘” 으로 불림
  • 맵리듀스는 하둡, 카우치DB, 몽고DB 등 다양한 오픈시스템에서 구현됨.
    • 맵리듀스는 이전 데이터 웨어하우스용으로 개발했던 병렬 처리 시스템보다 상당히 저수준 프로그래밍 모델임
    • 하지만, 범용 하드웨어만을 사용해 처리한 데이터 규모 면에서 상당히 진보함.
    • 현재는 맵리듀스의 중요성이 떨어지고 있지만, 왜 일괄 처리가 유용한지 명확하게 그림을 그려주기에 맵리듀스를 이해할 가치는 충분함.
• 이번 장에서는 맵리듀스를 알아보고 맵리듀스와 다른 일괄 처리 알고리즘과 프레임워크도 살펴본다.
  • 현재 데이터 시스템에서 이걸 어떻게 사용하는지 알아본다.
  • 우선, 표준 유닉스 도구를 사용해 데이터 처리하는 방법을 살펴본다.
    • 유닉스의 철학을 되새겨보는 것은 가치가 있음.
      • 유닉스가 주는 아이디어와 교훈이 대규모 이기종 분산 시스템으로 그대로 이어지기 때문

유닉스 도구로 일괄처리하기

• ex) 웹 서버가 하나 있고 들어온 요청이 처리될 때마다 로그 파일에 한 줄씩 추가된다고 가정한다.
  • nginx의 기본 액세스 로그 형식을 사용한다.
  • p387 참고

단순 로그 분석

• ex) 웹사이트에서 가장 인기가 높은 페이지 5개를 뽑는다고 가정한다.
  • p388 참고
  • 유닉스 도구에 익숙하지 않으면 명령줄을 이해하기 쉽지 않음.
    • 하지만 이런 방식은 상당히 강력함.
    • 수 기가바이트의 로그 파일을 수 초 내로 처리할 수 있고 ,필요에 따라 분석 방법을 수정하기도 쉬움.
    • 실제로 많은 데이터 분석이 수 분 내에 awk, sed, grep, sort, uniq, xargs의 조합으로 결과를 얻을 수 있고, 놀라울 정도로 잘 수행됨.

연쇄 명령 대 맞춤형 프로그램

• 유직스 연쇄 명령 대신, 같은 작업을 하는 간단한 프로그램을 작성할 수도 있음.
  • p389 참고
  • 이 프로그램은 유닉스 연쇄 파이프보다 간결하지는 않지만 더 읽기 쉬움.
    • 두 방법 중 하나를 선택하는건 취향의 문제임.
    • 하지만, 표면적인 문법의 차이를 빼고도, 실행흐름이 크게 다름.
      • 대용량 파일을 분석해 보면 차이가 확연히 드러난다.

정렬 대 인메모리 집계

• 앞선 예제의 프로그램의 경우, 값에 대한 해시 테이블을 메모리에 유지한다.
  • 반면, 유닉스 파이프라인은 이런 해시테이블이 없음.
  • 대신 정렬된 목록에서 같은 데이터가 반복해서 나타남.
• 어떤 접근법이 더 좋을지는 다른 데이터가 얼마나 되느냐에 따라 다름.
  • 만약 데이터가 1개라면 작업 세트(= 작업에서 임의 접근이 필요한 메모리 양)는 충분히 작으므로 인메모리 해시 테이블도 잘동작함.
    • 반면, 허용 메모리보다 작업 세트가 크다면 정렬 접근법(유닉스)를 사용하는게 좋음.
      • p76의 SS테이블과 LSM 트리 원리와 다르지 않음.
        1. 데이터 청크를 메모리에 정렬하고 청크를 세그먼트 파일로 디스크에 저장한다.
        2. 각각 정렬된 세그먼트 파일 여러 개를 한 개의 큰 정렬 파일로 병합한다.
        3. 병합 정렬은 순차적 접근 패턴을 따르고, 이 패턴은 디스크 상에서 좋은 성능을 낼 수 있음. (순차적 I/O 최적화는 3장에서 반복됐던 주제였음.)

유닉스 철학

• 앞 예제와 같이 연쇄 명령을 사용해서 쉽게 로그 파일을 분석한 것은
  • 사실 유닉스의 핵심 설계 아이디어중 하나임.
  • 오늘날에도 여전히 유효함.
• 유닉스 파이프를 발명한 더그 맥일로이는 마치 배관 공사와 비슷하게 여러 다른 프로그램을 파이프로 연결하는 아이디어를 냄.
  • 이 아이디어는 지금은 유닉스 철학의 일부가 됨.
  • 이 설계 원리는 개발자와 유닉스 사용자 사이에 더욱 대중화 됨.
    1. 각 프로그램은 한 가지 일만 하도록 작성하라.
    2. 모든 프로그램의 출력은 아직 알려지지 않은 다른 프로그램의 입력으로 쓰일 수 있다고 생각하라.
    3. 소프트웨어를 빠르게 써볼 수 있게 설계하고 구축하라. (운영체제도 마찬가지)
    4. 프로그래밍 작업을 줄이려면 미숙한 도움보다는 도구를 사용하라.
       • 자동화, 빠른 프로토타이핑, 증분 반복, 실험 친화, 큰 프로젝트를 청크로 나누어 처리하기 같은 방법은 오늘 날의 애자일 & DevOps 와 매우 흡사함.
       • 놀랍게도 40년이 지났지만 거의 바뀌지 않음.
• bash 같은 유닉스 셀을 사용하면 작은 프로그램들을 가지고 놀랄 만큼 강력한 데이터 처리 작업을 쉽게 구성할 수 있음.
  • 이런 프로그램 다수는 여러 그룹에서 만들어졌지만, 유연한 방식으로 함께 조합할 수 있음.
  • 이게 가능한 이유는?

동일 인터페이스

• 어떤 프로그램의 출력을 다른 프로그램의 입력으로 쓰고자 한다면, 이들 프로그램은 같은 데이터 형식을 사용해야 함.
  • 호환 가능한 인터페이스를 써야함.
    • 유닉스에서의 인터페이스는 파일(= 파일 디스크립터)임.
    • 파일은 단지 순서대로 정렬된 바이트의 연속임.
    • 파일은 이처럼 단순해서 같은 인터페이스로
      • 파일 시스템의 실제 파일
      • 프로세스 간의 통신 채널(유닉스 소켓, 표준 입출력(stdin, stdou))
      • 장치 드라이버(ex: /dev/audio, /dev/Ip0)
      • TCP 연결을 나타내는 소켓
        • 등, 다른 여러 가지 것들을 표현할 수 있음.
• 전부는 아니지만 관례상 많은 유닉스 프로그램은 연속된 바이트를 아스키 텍스트로 취급함.
  • 로그 분석 예제에서 바로 이 점을 활용함.
    • awk, sort, uniq, head는 입력파일을 \n 문자로 분리된 레코드를 다룸.
    • 레코드 분리자를 사용하여 표준화했기 때문에 이 모든 프로그램이 상호 운영 가능함.
• 완벽하지 않고, 심지어 수십 년이 지났어도 유닉스의 동일 인터페이스는 여전히 대단함.
  • 유닉스 도구만큼 상호 운용 또는 구성 면에서 뛰어난 소프트웨어는 많지 않음.
  • 즉, 오늘날 유닉스 도구처럼 매끄럽게 협동하는 프로그램이 있다면 정상이 아니라 예외적임..
• 동일한 데이터 모델인 데이터베이스 간에도 한쪽에서 다른 쪽으로 데이터를 옮기는게 쉽지 않음.
  • 데이터가 발칸화 되는 이유는 유닉스 도구와 같은 통합이 부족하기 때문임.

로직과 연결의 분리

• 유닉스의 다른 특징으로 표준 입력(stdin)과 표준 출력(stdout)을 사용한다는 점임.
  • 프로그램을 실행하고 아무것도 설정하지 않으면
    • stdin은 키보드로부터 들어오고 (혹은 파일에서 입력을 가져오고)
    • stdout은 화면으로 출력함. (혹은 다른 파일로 출력을 재전송함)
• 파이프는 한 프로세스의 stdout을 다른 프로세스의 stdin과 연결함.
  • 중간 데이터를 디스크에 쓰지 않고 작은 인메모리 버퍼를 사용해서 프로세스 간 데이터를 전송한다.
• 프로그램이 특정 파일의 경로가 어디에 있는지 신경 쓰지 않고 stdin과 stdout만으로 처리하고 싶다면 유닉스 접근 방법이 가장 좋음.
  • 프로그램은 파일 경로와 어디서 입력이 오고 출력이 어디로 나가는지 신경 쓸 필요 없다.
  • 이를 느슨한 결합, 지연 바인딩, 제어 반전이라고 함.
  • 프로그램에서 입출력을 연결하는 부분을 분리하면 작은 도구로부터 큰 시스템을 구성하기 훨씬 수월함.

투명성과 실험

• 유닉스 도구가 성공적인 이유 중 하나는 진행 사항을 파악하기 상당히 쉽기 때문임.
  • 유닉스 명령에 들어가는 입력 파일은 일반적으로 불변으로 처리됨.
    • 다양한 명령행 옵션을 써가며 원하는 만큼 명령을 수행하더라도 입력 파일에 손상을 주지 않음.
  • 어느 시점이든 파이프라인을 중단하고 출력을 파이프를 통해 less로 보내서 원하는 형태의 출력이 나오는지 확인 가능함.
    • 디버깅할 때 매우 유용함.
  • 특정 파이프라인 단계의 출력을 파일에 쓰고 그 파일의 다음 단계의 입력으로 사용할 수 있음.
    • 즉, 전체 파이프라인을 다시 시작하지 않고 다음 단계부터 재시작할 수 있음.
• 유닉스 도구를 사용하는 데 가장 큰 제약은 단일 장비에서만 실행된다는 점임.
  • 바로 이 점이 하둡과 같은 도구가 필요한 이유임.