여기에 어떤 함정도, 특별한 알고리즘이 필요 한것이 아니고.
당신이 이런 문제들을 어떻게 해결하는지 보기 위함이다.
질문을 하고, 면접관과 함께 토론해야 한다.
이런 질문에 답하는 방법
이야기를 하라.넓게 생각하라, 특정 알고리즘 혹은 특정 부분에 몰두 하지 말고, 큰 그림을 봐야 한다.
화이트 보드를 적극 활용하고, 면접관이 우려하는 점에 대해 명확히 이해하라.
조심스럽게 가정하고, 그런 가정들에 대해서 면접관에게 전파해라.
평가는 필요 할때만해라.
Design : Step-by-Step
혼자서 문제를 풀려고 하지말고, 대화를 하면서 문제를 풀어 나가야 한다.Step 1 : 문제의 범위 산정하기.
면접자가 요청한 문제가 내가 이해한것과 같은지 확인 해야 한다.예 : TinyUrl
permenant 한지, UserAccount 시스팀이 필요 한지, 클릭횟수 추적이 필요 한지 등을 물어 봐야 한다. 질문이 끝나고 나면 아래와 같이 리스트업한다.
* Shortening a URL to a TinyUrl
* Analytics for a URL
* Retrieving the URL associated with a TinyURL.
* User accounts and link management.
Step 2 : Make Reasonable Assumptions
어떠한 가정을 하는건 좋지만, 항상 정당한 이유가 있어야한다.무한한 메모리를 사용한다고 하거나, 하루에 100명만 사용한다고 하거나 하면 안된다.
Step 3 : Draw the major components
Frontend 서버나, Data Store 서버 등의 중요 컴포넌트들을 그리면 된다.이 단계에 대해서 Scalability 같은거는 접어 두고 가능한한 간단한척 하고 그리는게 좋다.
Step 4 : Identify the Key Issues
기본적인 디자인이 완료 되면, 어떤 문제가 있을지 생각해두는게 좋다.병목지점이라던지, 이 시스템을 만드는데 있어서 가장 큰 도전이 될만한 것들에 대해서 생각해두도록 하자.
예를들면 TinyURL은 보통 불규칙적인 접근 패턴을 가지는데, 커뮤니티등에 공유되어서 갑자기 엄청 많이 접근 될수도 있다.
Step 5: Redesign the the Key Issues.
정리한 이슈들을 해결할수 있도록 Diagram을 업데이트.이때 당신이 디자인한 결과의 한계에 대해서 오픈마인드를 가져야한다. 면접과는 이를 인지할테고 그와 적극적으로 소통해야 한다.
Algorithms that Scale : Step-By-Step
보통은 전체 시스템을 재디자인하라고 하지 않고, 특정 기능이나 알고리즘에 대해서 다시 작성할것을 요구 받는다. 이때 명심해야 할점을 Scalability 를 고려해야한다는 점이다.Step 1 : Ask Questions
앞서 말한것처럼 요구 사항을 제대로 인지 해야한다.Step 2 : Make Believe
일단 무한한 메모리를 가진 머신을 통해서 처리할수 있다고 생각하고 답을 작성하라.Step 3 : Get Real
다시 원래 문제로 돌아가서, 얼마나 많은 데이터를 한번에 처리 할수 있으며, 데이터를 쪼개었을때 나타나는 문제에 대해서 생각해봐야 한다. 보통은 한 머신이 데이터를 볼때 다른 데이터를 어떻게 찾을수 있는지가 문제이다.Step 4 : Solve Problems
이제 발생할수 있는 문제들에 해결 방안을 제시 해야 한다. 문제가 해결 되었을 수도 있고, 아닐수도 있다. 문제가 해결 되지 않았다거나, 다른 문제가 발생하면 그문제들에 대해서 깊게 고민해야 한다. 지금 당장 완벽한 시스템을 만드는게 중요한것이 아니라, 문제를 찾아내고, 수정하고 하는 과정이 중요한것이다.Key Concepts
Horizontal vs Vertical Scaling
* Vertical Scaling 은 특정한 node 에 대한 성능향상, 예를 들어서 메모리를 늘리는 등.* Horizontal Scaling 은 node 수를 늘리는 방식이다. 예를 들면 서버 수를 늘려서 부하를 분산시키는것이다.
Load Balancer
뭐 말이 필요 없는듯. 말 그대로Database Denormalization and NoSQL
시스템이 커질수록 RDBMS 에서의 JOIN 연산이 병목지점이 된다.Denormalization(역정규화)를 하면 이런 문제를 피할수 있다.
NoSQL을 이용해서 처리할수도 있는데, NoSQL은 관계형 DBMS가 아니기 때문에 JOIN 연산이 없고, scale하기 좋게 디자인 되어 있다.
Database Partitioning(Sharding)
DB Sharding은 데이터를 쪼개는 기능이다.* Vertical Partitioning
가장 기초적인 샤딩 기법으로, 테이블별로 DB를 나누는 것이다.
Vertical Partitioning의 단점은 분리된 DB일지라고 그 DB가 매우 커지면 또다시 다른 방법으로 Partitioning을 해야 한다는것이다.
* Key-Base(or Hash Based) Partitioning
Key 단위로 Table을 분리하는 기법. 문제는 서버를 추가할때 마다, Data Relocating 작업을 해야 하는데, 무지하게 비싼 작업이다.
* Directory-Base Partitioning
내가 찾는 데이터가 어디 잇는지, lookup table 을 통해 관리하는것이다. 서버 추가등의 이슈에 비교적 쉽게 대응할수 있지만, 두가지 결점이 있다.
첫번째로, lookup table에 문제가 생기면, 전체 장애로 이어진다.
두번째로 lookup table에 부하가 많이 걸린다.
대부분의 architecture들을 이런 기법들을 조합해서 사용한다.
Caching
생략.Asynchronous Processing & Queues
시간이 오래 걸리는 작업을 동기적으로 처리하면, 응답시간이 늦어 지기 때문에, 비동기로 처리해야 한다.때때로, pre-process 하는 형식으로 처리할수도 있다. 예를 들면 포럼에서 인기 잇는 포스트와 댓글 수 등을 미리 처리 하는것이다. 아주 약간 실데이터와 차이가 있을수 있지만 대부분 용납할수준일것이다. 실시간으로 데이터를 로딩해, 느린 응답시간을 가지는 것보다 훨씬 좋은 선택이다.
또 다른 때에는, 사용자에게 기다리게하고, 작업이 완료된것을 알려줘야 할수도 있다.
Networking Metrics
* Bandwidth한번에 보낼수 있는 최대 데이터양을 뜻한다. bps,gps 등으로 표기된다.
* Throughput
Bandwith가 한번에 보낼수 있는 최대 데이터양을 뜻하는 반면에 Throughput은 실제로 전송된 데이터의 크기를 뜻한다.
* Latency
end-to-end 과점에서 데이터가 전송되는데 걸리는 시간을 의미한다.
MapReduce
대용량 데이터를 처리하기 위한 기술.이름에 나와 있듯이 Map 과 Reduce 로 구분된다.
* Map은 데이터를 K,V 쌍으로 나누고.
* Reduce 는 특정 K를 가지고 여러방식으로 "reduce"한후 에 새로우 K,V를 만들어 낸다. 때때로 Reduce는 추가적인 Reduce를 위해 재귀적으로 사용될수 있다.
MapReduce 는 대용량 데이터를 Scalable 하게 병렬처리하는 기법이다.
Considerations
시스템 디자인을 할때는 Key Concepts 와 별개로 몇개의 이슈에 대해 생각해봐야 한다.* Failure
필연적으로 시스템 구성요소 오류가 나기 마련이고, 우리는 다수 혹은 모든 종류의 요소들의 오류에 대한 계획이 있어야 한다.
* Availability and Reliability
Availability 는 시스템 가용시간을 퍼센트 형태로 표기한것이다.
Reliability는 특정시간단위에 대해 시스템이 가용될수 있는 확률을 표기하는것이다.
* Read-heavy vs Write-heavy
읽기, 혹은 쓰기 편향적인 시스템이라면 디자인할때 고려해야 한다.
쓰기 편향이면, write-task를 queuing 하는 식으로 디자인할수 있다. ( 이때 쓰기 실패 일때는 대비해야 한다. ) 읽기 편향이면 cache를 꼭 넣어야 한다.
* Security
우리가 설계한 디자인에서 마주칠 Security 이슈에 대해 생각해봐야 한다.
이런 점들의 장단점에 대해 꼭 면접관과 공유 해야함을 기억해야한다.
There is no "perfect" system
어떤 시스템을 설계하든 한번에 완벽한 시스템 디자인은 없다. 언제나 장단점이 있기 마련이다. 두사람이 같은 시스템을 완전히 다르지만 훌륭하게 디자인할수 있다.이런 질문들에 대한 우리의 목표는, 요구사항을 이해하고, 문제를 구조화 한다음, 합리적인 가정을 토대로 시스템을 디자인하는것이며, 우리가 디자인한 시스템의 약점에 대해 열린 마음으로 대하는것이다.
No comments:
Post a Comment