다양한 기술 포스팅들이 올라오는 http://highscalability.com/ 사이트에는 양질의 개발관련 글이 올라온다. 그 중 시스템 설계를 위한 대략적인 계산 법에 대해 좋은 칼럼이 있어서 번역글을 작성해본다. 부족한 번역 실력 양해 부탁한다.
Google Pro Tip: 대략적인 계산방식을 통한 최적의 디자인을 하기
[Back-Of-The-Envelope-Calculations : 일반적으로 봉투와 같은 사용 가능한 종이 조각에 적어 놓은 대략적인 계산을 의미한다.]
주어진 문제에 대한 최고 의 설계가 어떤 것인지 어떻게 알 수 있을까?
예를 들어서, 30장의 썸네일의 결과값을 내놓는 이미지 검색 엔진을 설계한다면 당신은 이미지들을 순차적으로 불러올 것인가? 혹은 병렬적으로? 캐싱은 할 건가?
이런 것들은 어떻게 결정을 할 것인가?
만약 너가 멀티버스의 힘(power of the multiverse)을 이용한다면, 생각하는 모든 옵션의 설계를 시도해보고 어떤 것이 가장 좋은지 확인할 수 있을 것이다. 하지만 그건 터무니없는 이야기이다.
다른 선택지는 대안이 되는 알고리즘의 순서를 고려하는 것이다.(order of various algorithm)
계산적 사고 황금기의 예언자인 구글은 분명이 이렇게 하겠지만, 또 다른 방법으로는 어떻게 하고 있을까?
Back-Of-The-Envelope(봉투 뒷면) 계산 방법을 이용해서 다양한 설계 계산하기
구글의 사회 기반 시설 대학원 (School of Infrastructure Wizardry / 광고 서비스, 검색, 맵리듀스, 버퍼프로토콜 등 구글의 중요하고 다양한 대표 시스템들을 포함하고 있음) 대표인 제프 딘(Jeff Dean) 은 봉투 뒷편 계산법을 사용해서 다양한 설계를 계산하는 방법을 주장한다.
그는 스탠포드 강의에서 전체 이야기를 풀어냈었다. 봉투 뒷편 계산법은 당신이 사고 실험과 통용적인 성능의 숫자를 혼합해서 추정을 할 수 있게 해준다. 이를 통해 어떤 설계가 당신의 요구사항에 적절하게 부합하는지 알아차릴 수 있게 한다. 딘 박사는 직접 설계를 통해서 설계 성능의 대체 시스템을 추정하는 것이 아니라, 봉투 뒷편 계산법을 이용해서 대략적인 설계를 할 수 있는 것이 모든 소프트웨어 엔지니어에게 중요한 기술이라고 생각한다.
스탠포드 강의에서 딘 박사는 매우 좋은 예시를 하나 제시했는데, 그전에 먼저 알아야 할 것들이 존재한다.
모두가 반드시 알아야하는 숫자들
설계 대안을 계산하기 위해서 당신은 전형적인 운영 동작이 얼마나 오래 걸리는지에 대한 적절한 감각이 있어야만 한다.
딘 박사는 아래의 리스트를 제시했다.
- L1 캐쉬 참고 : 0.5 ns
- 분기 예측 오류 : 5 ns
- L2 캐쉬 참조 : 7 ns
- 뮤텍스(Mutex) 락/언락 : 100 ns
- 주 메모리 참조 : 100 ns
- Zippy 로 1 KB 압축 : 10,000 ns
- 1Gbps 네트워크로 2KB 전송 : 20,000 ns
- 메모리에서 1 MB 순차적으로 Read : 250,000 ns
- 같은 데이터 센터 내에서의 메시지 왕복 지연 시간 : 500,000 ns
- 디스크 탐색 : 10,000,000 ns
- 네트워크에서 1 MB 순차적으로 Read : 10,000,000 ns
- 디스크에서 1 MB 순차적으로 Read : 30,000,000 ns
- 한 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 : 150,000,000 ns
몇 가지 주의할 점이 있다.
- 성능의 다양한 옵션에 따라서 규모의 차이가 있다는 것을 인지하라.
- 데이터 센터는 서로 멀리 떨어져 있기 때문에 서로 어떤 것들 보내는데 긴 시간이 소요된다.
- 메모리는 빠르고 디스크는 느리다.
- 값 싼 압축 알고리즘(2의 N제곱)을 사용한다면 네트워크 대역폭을 아낄 수 있다.
- 쓰기는 읽기보다
40배나 값 비싼 연산이다. - 글로벌 공유 데이터는 값 비싸다. 이것은 분산 시스템의 근본적인
한계이다. 대량으로 작성된 공유 데이터에서의 락은 트랜잭션을 직렬화 시키면서 성능을 저하시킨다. 쓰기의 확장을 고려한 설계를 하라.쓰기경합을 낮추도록 최적화하라.- 넓게 최적화 하라. 할 수 있는 한
쓰기를 병렬화 하라.
에시: 30장의 썸네일을 가진 이미지 결과 생성 페이지 만들기
이 예시는 스탠포드 강의에서 제시된 것이다. 두가지의 설계 대안은 사고 실험으로 사용된다.
설계1 - 연속적
- 이미지를 연속적으로 읽어온다. 디스크 탐색을 한다. 256K의 이미지를 읽고 다음 이미지로 넘어간다.
- 성능 : 30번탐색 _ 10ms/탐색 + 30 _ 256K % 30MB/s = 560ms
설계2 - 병렬적
- 문제를 병렬로 읽는다.
- 성능 : 10ms/탐색 + 256K read % 30MB/s = 18ms
- 디스크 읽기로부터 변화가 있을 것이다. 따라서 대략적인 소요 시간은 30-60ms 일 것이다.
어떤 설계가 더 적합한가? 당신의 요구사항에 따라서 다르겠지만 봉투 뒷편 계산법을 사용한다면 직접 설계하지 않고도 빠르게 성능을 비교할 수 있다.
이제 당신은 스스로에게 다른 설계 질문과 설계의 다양성에 대한 차이를 물어볼 수 있는 프레임워크를 갖추었다.
- 썸네일 이미지를 하나씩 캐싱하는게 합리적인가?
- 하나의 엔트리에 전체 이미지를 캐싱해야만 하는가?
- 썸네일을 미리 계산하는게 합리적인가?
이러한 추정치들을 현실적으로 하기 위해서 당신은 당신의 서비스의 성능을 알아야만 한다. 만약 알지 못하는 변수가 있는 경우 해당 부분만 빠르게 프로토타입으로 제작하여 해결할 수 있다.
예를 들어서 캐싱이 좋은 설계 대안인지 알아보기 위해서 당신은 캐쉬에 쓰기연산을 할 때 얼마나 시간이 소요되는지 알아야할 필요가 있다.
얻은 교훈
봉투 뒷편 계산법은 당신이 다양한 변형을 살펴볼 수 있게 한다.- 당신의 시스템을 설계할 때, 이러한 종류의 게산은 당신 머리속으로 계속해서 반복해야 한다.
- 당신의 시스템 블럭들을 설게하기 위해서 봉투 뒷면의 숫자를 알고 있어야한다. 일반적인 성능의 수치를 단순히 안다는 것은 충분하지 않으며, 하위 시스템이 얼마나 성능을 내는지 알고 있어야만 한다. 어떻게 계산이 되었는지 알지 못한다면
봉투 뒷편 계산법을 반대로 수행할 수 없을 것이다.
나는 개인적으로 이러한 접근을 상당히 좋아한다.일반적인 경우보다 봉투 뒷편 계산법은 시작부터 끝까지 시스템의 본질에 기반을 두는 것 같아 보인다.
오늘날의 관행은 실제로 더 크고 전체적인 분석에서 연구 가능하고 틀어 막을 수 있는 다양한 알고리즘들의 속임수에 초점을 맞추고 있다.