[대규모 서비스를 지탱하는 기술] 대규모 서비스의 어려움

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

소규모 서비스와 대규모 서비스의 차이

---

서버 몇 대 정도의 소규모 서비스에는 없는, 대규모 서비스에만 있는 문제나 어려움에는 어떠한 것이 있을까?

1. 확장성 확보, 부하분산 필요

---

• 먼저 대량의 액세스가 있는 서비스에서는 서버 1대로는 부하를 처리할 수 없는 경우가 대 다수이다. 이때, 서버 1대로 처리할 수 없는 부하를 어떻게 처리할 것인가가 가장 큰 문제이다.
• 이러한 문제를 해결하기 위한 전략에는 크게 두 가지 전략이 있다.

스케일업 (Scale-Up)

• 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법

스케일아웃 (Scale-Out)

• 서버를 횡으로 전개, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여서 부하를 분산하는 방법
• 스케일 아웃 전략을 통해 저가의 하드웨어를 횡으로 나열해서 확장성을 확보해서 비용이 절감되는 효과를 얻을 수 있지만, 다양한 문제가 발생할 수 있다. (어떠한 점을 고려해야 하는지 다음을 보자)

 

스케일 아웃 전략시 고려사항

사용자의 요청 분배

• 사용자로부터 요청을 어떻게 분배할 것지를 고려해야 한다.

데이터 동기화

• 데이터 동기화는 어떻게 할 것인지 고려 해야 한다.
  (DB를 분산시켰을 때 한쪽에 저장된 갱신 내용을 다른 한쪽 DB가 알지 못한다면 애플리케이션에 비정상 상태가 발생한다

네트워크 통신의 지연시간

• 네트워크 통신의 지연시간(latency)을 고려 해야 한다.

 

2. 다중성 확보

---

• 시스템은 다중성을 지닌 구성, 즉 특정 서버가 고장 나거나 성능이 저하되더라도 서비스를 계속할 수 있는 구성으로 할 필요가 있다.
• 스케일아웃을 해서 서버 대수가 늘어나면 서버의 고장률도 필연적으로 올라가게 된다. 만약 서버가 고장 나더라도 혹은 급격하게 부하가 올라갈 경우에도 견딜 수 있는 시스템을 구성할 필요가 있다.

 

3. 효율적 운영 필요

---

• 서버가 1대라면 때때로 상태를 확인하는 정도로 서버가 정상적으로 동작하고 있는지를 간단하게 파악할 수 있을 것이다. 하지만 서버가 100대를 넘어서면 어떤 서버가 무슨 역할을 하고 있는지 기억해두는 것조차 곤란해진다. 또한 각 서버가 어떤 상황에 있는지 파악하는 것도 상당한 고생 거리다.
• 부하는 괜찮은지, 고장 난 부분은 없는지, 디스크 용량은 아직 충분한지, 보안설정에 미비한 점은 없는지 등등 이를 모든 서버에 대해 여기저기 잘 살펴야 하는 어려움이 있다.
• 이쯤에서 감시용 소프트웨어를 사용하고 정보관리를 위한 툴을 사용하는 등 자동화를 하지만 이를 설치 및 운영하는 것도 일종의 리소스로 효율적 운용을 수행해야만 한다.

 

4. 개발자 수, 개발 방법의 변화

---

• 대규모 서비스가 되면 당연히 혼자서는 개발이나 운용이 어려워지므로 여러 기술자가 역할을 분담하게 된다.
• 이렇게 되면 개발 표준화는 어떻게 할 것인지 등 고려해야 한다.

 

5. 대규모 데이터량에 대한 대치

---

대규모 데이터를 보기 전에 먼저 컴퓨터 메모리 구조를 보고 가면...

• 컴퓨터는 디스크에서 데이터를 로드해서 메모리에 저장, 메모리에 저장된 데이터를 CPU가 fetch 해서 특정 처리를 수행한다. 또한 메모리에서 fetch 된 명령은 보다 빠른 캐시 메모리에 캐싱된다. 이처럼 데이터는 디스크 → 메모리 → 캐시 메모리 → CPU와 같이 몇 단계를 경유해서 처리되어 간다.
• 각 단계 간에는 속도차가 매우 크게 나는 것이 현대 컴퓨터의 특징이다. 하드디스크에서 데이터를 읽어 들이는 데에는 그 특성상 헤드 이동이나 디스크 원반의 회전이라는 물리적 동작이 수반된다. (이러한 점을 보완하기 위해서 전기적 특성을 가진 SSD가 나온 것이다.)
• 이러한 물리적 동작은 전기적으로 읽어 들이기만 하면 되는 메모리나 캐시 메모리와 비교하면 엄청난 속도차가 나게 된다.

 

일종의 해결 방법

• 이 속도차를 흡수하기 위해 OS는 여러 방법을 사용하게 되는데, 예를 들면 디스크로부터 읽어 들인 데이터를 메모리에 캐싱해둠으로써 전반적으로 디바이스 간 체감속도에 영향을 주지 않도록 하고 있다. DB를 비롯한 미들웨어도 기본적으로 이러한 속도차를 의식한 데이터 구조, 구현을 채용하고 있다.

 

한계

• 하지만 OS나 미들웨어 등의 소프트웨어에서 이런 구조를 통해 분발한다고는 해도 한계가 존재한다.
• 데이터량이 많아지면 처음부터 캐시 미스가 많이 발생하게 되고, 그 결과로 저속의 디스크 I/O가 많이 발생하게 된다. 디스크 I/O 대기에 들어선 프로그램은 다른 리소스가 비어 있더라도 읽기가 완료되기까지는 다음 처리를 수행할 수가 없다. 이것은 시스템 전체의 속도 저하를 초래한다.

 

대규모 웹 애플리케이션을 운용할 때 대부분의 어려움은 이러한 대규모 처리에 집중된다.

• 데이터가 적을 때는 특별히 고려하지 않아도 모두 메모리에서 처리할 수 있으며, 복잡한 알고리즘을 사용하기보단 간단한 알고리즘을 사용하는 편이 오버헤드가 적기 때문에 더 빠른 경우도 종종 있으므로 I/O 부하는 일단 문제가 되지 않는다.
• 그러나 서비스가 어느 정도 이상의 규모가 되면 데이터는 증가하게 되며 문제가 복잡해진다. 그리고 응급처리로는 쉽사리 풀리지 않는다. 이 점이 대규모 서비스의 어려운 점이다.