본문으로 건너뛰기

1. 대규모 웹 서비스 개발 오리엔테이션

1강. 대규모 서비스와 소규모 서비스​

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

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

확장성 확보, 부하분산 필요​

대량의 액세스가 있는 서비스에서는 서버 1대로 처리할 수 없는 부하를 어떻게 처리할 것인지가 가장 큰 문제입니다.

최근 10년 동안의 트렌드로는 이른바 스케일아웃(scale-out)이 이 문제에 대한 전략의 기초가 됩니다. 스케일아웃은 서버를 횡으로 전개해, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여 부하를 분산하는 방법입니다. 반면 스케일업(scale-up)은 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법입니다.

스케일아웃 전략을 채용한 경우 비용이 절감되는 반면 다양한 문제가 발생합니다.

  • 사용자 요청을 어떻게 분배할 것인가: 로드밸런서를 도입해야 합니다.
  • 데이터 동기화를 어떻게 할 것인가: DB를 분산했을 때 한쪽 갱신 내용을 다른 쪽이 모르면 애플리케이션 비정상 사태가 발생합니다.
  • 네트워크 통신 지연시간(latency)을 어떻게 볼 것인가: 작은 데이터라도 이더넷(Ethernet)을 경유하면 ms 단위 지연이 생깁니다.

다중성 확보​

시스템은 다중성을 지닌 구성, 즉 특정 서버가 고장 나거나 성능이 저하되더라도 서비스를 계속할 수 있는 구성이 필요합니다. 스케일아웃으로 서버 대수가 늘어나면 서버 고장률도 필연적으로 올라가게 됩니다.

효율적 운용 필요​

서버 대수가 100대를 넘어서면 어떤 서버가 무슨 역할을 하는지 기억하는 것 자체가 곤란해집니다. 또한 각 서버가 어떤 상황인지 파악하는 것도 큰 고생거리입니다.

  • 부하는 괜찮은지
  • 장애 징후는 없는지
  • 디스크 용량은 충분한지
  • 보안설정에 미비점은 없는지

결국 감시용 소프트웨어와 정보관리 툴을 사용해 자동화를 하게 됩니다. 다만 감시 소프트웨어를 설치하고 정보를 해석하는 것은 결국 사람입니다. 일손을 거치지 않고 대규모 시스템을 건강한 상태로 얼마나 오래 유지할 수 있을지, 이를 위한 효율적 운용이 핵심 과제가 됩니다.

개발자 수, 개발방법의 변화​

대규모 서비스가 되면 혼자서 개발·운용하기 어려워지므로 여러 기술자가 역할을 분담하게 됩니다. 사람 수가 늘어나면 고려할 과제도 늘어납니다. 예를 들면 개발 표준화를 어떻게 할 것인지가 대표적입니다.

대규모 데이터량에 대한 대처​

컴퓨터는 디스크(HDD)에서 데이터를 로드해 메모리에 저장하고, 메모리의 데이터를 CPU가 fetch해서 처리합니다. 또한 메모리에서 패치된 명령은 더 빠른 캐시(cache) 메모리에 캐싱됩니다. 즉 데이터는 디스크 -> 메모리 -> 캐시 메모리 -> CPU의 여러 단계를 경유해 처리됩니다.

각 단계 간 속도차는 매우 큽니다. 하드디스크에서 데이터를 읽는 과정에는 헤드 이동과 원반 회전 같은 물리적 동작이 수반되므로, 전기적으로 접근하는 메모리/캐시와 비교하면 10^6 ~ 10^9배 속도차가 날 수 있습니다.

이 속도차를 흡수하기 위해 OS는 디스크에서 읽은 데이터를 메모리에 캐싱해 체감속도 저하를 줄입니다. DB를 비롯한 미들웨어도 속도차를 의식한 데이터 구조와 구현을 채택합니다.

하지만 데이터량이 많아지면 cache miss가 증가하고, 그 결과 저속 디스크 I/O가 급증합니다. 디스크 I/O 대기에 들어간 프로그램은 다른 리소스가 비어 있어도 읽기 완료 전까지 다음 처리를 수행할 수 없어서 시스템 전체 속도저하를 초래합니다.

데이터가 적을 때는 복잡한 알고리즘보다 단순한 알고리즘이 오버헤드가 적어 더 빠른 경우도 있고, I/O 부하는 크게 문제 되지 않을 수 있습니다. 그러나 서비스 규모가 커지면 데이터는 증가합니다.

어떻게 하면 데이터를 적게 가져갈 수 있을까? 여러 서버로 분산할 수 있을까? 필요한 데이터를 최소 횟수로 읽을 수 있을까?

이 질문들이 본질적 과제가 됩니다.

2강. 계속 성장하는 서비스와 대규모화의 벽​

웹 서비스의 어려움​

웹 서비스가 다른 애플리케이션에 비해 어려운 또 하나의 원인은 서비스가 계속 성장한다는 점입니다. 처음에는 소규모였던 서비스도 성장하면서 시스템 구성을 바꿔야 합니다. 1~2년만 운용해도 보유 데이터량은 계속 늘어납니다.

예를 들어 블로그 서비스를 떠올리면, 사용자는 매일 새로운 일상사와 사진을 올립니다. 늘어났다고 해서 예전 데이터를 사업자가 임의로 지울 수는 없으므로 모든 데이터를 계속 보존하고 필요 시 추출할 수 있어야 합니다.

불특정다수 사용자 대상 서비스가 상업적으로 성공하면 데이터뿐 아니라 트래픽도 함께 증가합니다. 조회 수와 작성 횟수 증가에 따라 시스템 확장이 필요해집니다.

시스템의 성장전략​

서비스가 소규모인 단계에서는 단순한 방법이 더 나은 경우가 많으므로 너무 이른 최적화는 좋은 방침이 아닐 수 있습니다.

반대로 아무 생각 없이 불완전하게 시작하면 대규모화의 벽은 갑작스럽게 나타납니다. 데이터 규모 증가에 따른 I/O 부하 상승은 선형적으로만 증가하지 않으며, cache miss가 본격 발생하기 시작하면 문제는 빠르게 복잡해지고 시스템이 급격히 저속화되는 경우가 많습니다.

이런 사태를 피하려면 수용능력 관리(capacity planning)와 서비스 설계 단계에서 불필요한 데이터 증가를 억제하는 설계를 포함해야 합니다.

3강. 서비스 개발의 현장​

하테나의 기술팀 체제​

대규모 서비스 운용의 현장을 구체적으로 보면, 엔지니어링 조직은 크게 두 부서로 나뉩니다.

  • 서비스 개발부: 하테나의 각종 서비스 구현을 담당하며, 애플리케이션 측면의 개선을 매일 진행합니다.
  • 인프라부: 서버/인프라 시스템 운용을 담당하며, 서버 준비, 데이터센터 운용, 부하분산 등을 담당합니다.

1,000대 규모의 호스트를 보유하는 시스템에서는 며칠에 한 번은 장애·과부하·설정 미비·노후화 교체 같은 문제가 발생합니다.

이 문제들을 전담하면서 가상화나 클라우드 같은 새로운 방식으로 시스템을 확장해 가는 것도 인프라부의 역할입니다. 서비스 개발부는 그 기반 위에서 하테나 다이어리·하테나 북마크 같은 서비스 기능을 개발합니다.

하테나에서의 커뮤니케이션 방법​

기본적으로 업무지시는 구두로 이루어집니다. 다만 구두만으로는 비효율적이거나 이력이 남지 않으므로 여러 툴을 조합합니다.

  • 하테나 그룹: 블로그+위키 기반 그룹웨어로, 매일 업무 리포트 보고에 사용합니다. 유지보수 작업 절차를 블로그/위키에 기록해 사후 참조가 가능하게 합니다.
  • IRC: 도쿄/교토로 사무실이 분산되어 있어 IRC 채팅 커뮤니케이션을 함께 사용합니다.
  • 서버 관리툴: 서버 상태를 한눈에 보여주는 도구로, 유지보수 예정 여부 확인과 시스템 갱신 가능 여부 판단에 활용합니다.

실제 서비스 개발​

구현 변경을 반영하기까지의 흐름은 다음과 같습니다.

  • 매일 아침 팀별로 10분 내외 짧은 미팅을 진행하고, 어제 진척과 오늘 할 일을 공유합니다.
  • 미팅에서 태스크 담당자를 정하고, 담당자는 미팅 후 바로 구현에 들어갑니다.
  • 구현 시 가능한 한 테스트 프로그램을 작성합니다. 다만 레거시 등 현실적 제약이 있는 경우에는 유연하게 타협합니다.
  • 테스트 작성 후 구현하고, 완료되면 버전관리 시스템에 커밋합니다.
  • 팀 내 다른 엔지니어가 코드 리뷰를 수행하고, 버그/규약 위반/과부하 유발 코드 등을 개선합니다.
  • 리뷰 통과 후 프로덕션 코드에 머지하고, 스테이징 환경에서 확인한 다음 프로덕션에 반영합니다.

개발에 사용하는 툴​

프로그래밍 언어​

서버사이드 웹 애플리케이션은 창업 때부터 Perl로 개발해 왔기 때문에 Perl을 이용합니다. 검색 엔진처럼 메모리 요건이 엄격하거나 속도가 중요한 곳에는 일부 C/C++도 사용합니다. 웹 애플리케이션 UI 개발에는 JavaScript를 사용합니다.

프로그래밍 언어 선택 정책은 "동일 레이어의 언어는 하나로 한정한다"입니다.

주요 미들웨어​

표준화 관점에서 미들웨어와 프레임워크를 팀 전체에서 통일합니다. 주요 미들웨어는 Linux, Apache, MySQL, memcached처럼 웹 개발의 기본에 해당하는 구성입니다.

웹 애플리케이션 프레임워크​

애플리케이션 개발 효율과 표준화 관점에서 프레임워크 사용은 사실상 필수입니다. 하테나에서는 자체 개발한 Perl 프레임워크 Ridge를 사용합니다.

주위 머신의 OS 및 에디터​

프레임워크/미들웨어는 프로덕션과 동일하게 맞춰야 하므로 표준화하지만, 그 외 영역(에디터, PC OS)은 기본적으로 자유입니다. Emacs/Vim, Windows/Mac OS X 등 각자 선호를 사용합니다.

버전관리는 git, BTS는 독자 개발한 아시카​

소스코드 버전관리는 git를 사용합니다. BTS(Bug Tracking System)는 사내 git 리포지토리와 연동한 독자 개발 웹 애플리케이션 "아시카"를 이용합니다.

Wrap Up​

대규모 웹 서비스는 단순히 서버 수가 많은 문제가 아니라, 확장성·다중성·운용 자동화·조직 협업이 함께 맞물리는 문제임을 확인할 수 있습니다. 특히 데이터 증가와 I/O 병목은 성장 과정에서 급격한 성능 저하를 유발할 수 있으므로, 초기부터 성장 전략과 운용 체계를 함께 설계해야 합니다.

Summary​

소규모 서비스에서는 잘 드러나지 않는 과제가 대규모 환경에서는 핵심 이슈가 됩니다. 스케일아웃은 비용 효율적인 전략이지만, 요청 분산·데이터 동기화·네트워크 지연 같은 새로운 복잡성을 동반합니다. 데이터 규모가 커질수록 캐시 미스와 디스크 I/O가 병목이 되어 시스템 전체 성능을 떨어뜨리므로, 데이터 접근 전략과 수용능력 관리가 중요합니다. 또한 서비스가 성장하면 기술적 문제뿐 아니라 팀 구조, 커뮤니케이션, 코드 리뷰, 배포 절차 같은 개발 문화와 프로세스의 성숙도가 서비스 품질을 좌우합니다. 결국 대규모 웹 서비스 개발은 기술 선택과 조직 운영을 함께 최적화하는 장기전입니다.

Reference​