[대규모 서비스를 지탱하는 기술] 대규모 데이터 처리를 지탱하는 서버/인프라

대규모 서비스를 지탱하는 기술

엔터프라이즈 vs 웹 서비스

---

트래픽

• 트래픽의 경우 엔터프라이즈에서는 극히 거대한 규모가 되는 경우는 드물지만, 웹 서비스의 경우는 특히 글로벌하게 전개되고 있는 서비스에서는 어마어마한 트래픽이 발생할 가능성이 있다.

 

성장성

• 엔터프라이즈에서는 실제 비즈니스와 연계되어 있으므로 그다지 급격하게 성장하는 것은 아니다.
• 반면, 웹 서비스의 경우는 폭발적으로 성장할 가능성이 있어서 전년대비 100%, 200%, 300% 증가와 같은 일도 드물지 않다.

 

신뢰성

• 엔터프라이즈에서는 사수라고 적혀있는데 장애가 발생해서 데이터가 없어지거나 하면 실제로 돈이 사라지기도 한다. 이처럼 굉장히 높은 신뢰성을 요구한다.
• 그러나 웹 서비스는 신뢰성에서는 대부분 비교적 그렇게 높은 레벨이 요구되지 않는다는 특징이 있다.

 

트랜잭션

• 엔터프라이즈에서는 데이터 간 정합성을 정확히 유지해야만 한다. (DB 처리에 있어서 트랜잭션 처리를 이용해서 정합성을 명확히 담보하면서 처리하게 된다)
• 웹 서비스에서는 일시적으로 정합성이 일치하지 않는 경우도 허용하도록 처리하는 경우도 있다. 그래서 비용을 줄이거나 적은 서버 대수로 트래픽이 많이 발생하도록 하는 설계를 하기도 한다.

웹 서비스의 인프라의 특징

---

저비용 고효율

 

설계

• 확장성이나 응답성 등에 대한 설계를 중요시한다.

 

개발속도

• 서비스에 대해 기동성 있게 리소스를 제공할 수 있어야 한다.

확장성 확보에 필요한 사고방식

---

계층과 확장성

AP서버

• AP서버는 비교적 간단하게 확장시킬 수 있다.
• AP 서버는 상태를 갖고 있지 않으므로 요청 별로 다른 AP서버로 날려 보내도 처리상 문제가 발생하지 않고, 로드밸런서에 새로운 서버를 추가하면 점점 확장되어 간다.

 

DB나 파일서버

• DB나 파일 서버의 경우에는 분산, 확장성 확보가 매우 어렵다.
• 데이터 소스로의 요청은 read, write 2종류로 나뉘는데, read를 분산하는 것은 비교적 용이한 반면, write를 분산하는 것은 매우 어렵게 되어 있다.

부하 파악, 튜닝

---

부하를 측정하기 위한 항목

부하를 볼 때는 먼저 Load Average부터 본다.

Load Average

• 프로세스가 언제든지 동작할 수 있는 상태이지만, 아직 실제 CPU가 할당되지 않아서 대기상태에 있는 프로세스 수의 평균치.
• 예를 들어서 5분간 Load Average가 1이라면, 5분 동안에 평균 1개의 프로세스가 대기상태로 되어 있다는 것을 의미한다.
• CPU가 깔끔하게 할당되면 이 값이 0에 가까워지고, CPU 코어 수 이하이면 양호한 편이다. (여기서는 CPU 코어 수 이하 또는 그 절반 정도에 맞춰지도록 제어하는 것 추천한다고 한다.)

 

부하를 측정하기 위한 항목은 Load Average 이외에도 많이 있는데

• 메모리 사용처에 관해서 → 사용자 공간이 소비되고 있는 메모리나 공유되고 있는 메모리, 커널이 사용하고 있는 버퍼의 메모리

"이러한 항목을 통해 이런 거동을 하고 있으니 이런 동작을 보이고 있어"와 같이 파악함으로써 서버의 성능을 더 끌어내 고성능 시스템을 실현할 수 있게 되는 것.

용도에 맞는 튜닝

책에서는 크롤러와 같은 봇으로부터 온 요청과 사용자로부터 온 요청이 있어서 봇용 서버, 사용자용 서버로 나눠서 처리하고 있다.

봇은 응답 시간이 그렇게 중요하지 않으므로, 요청 처리 수를 최대화시키는 방향으로 튜닝한다. 이에 따라 Load Average도 높게 나타남.

사용자용 서버는 Load Average가 비교적 낮게 유지되고 있으며, 양호한 응답을 위해 리소스를 소진하기보다는 처리 대기 프로세스를 쌓아두지 않고 양호한 응답을 유지하는 방향으로 튜닝하고 있다.

효과

용도별로 나눠서 튜닝을 변경함으로써 전체 서버 대수를 줄일 수 있게 된다. (사용자를 대상으로 한 튜닝인 채로 봇용에 투입해서 동일한 정도의 부하로 처리하려 하면 기존 6대에서 8~9대가 필요하다)