확장성

처음 만들 때 머릿속에 있는 숫자는 대개 작습니다. 동시에 백 명이 쓰는 상황을 가정하고 짠 코드가 그대로 남아 있다가, 사용자가 늘어난 어느 날 무너집니다.

페이지덱에서 그 날이 갑자기 왔습니다. 고객사가 만든 공유 링크가 업계 커뮤니티에 퍼져 동시 접속이 백 명대에서 8천 명대로 뛰었습니다. 먼저 멈춘 것은 서버가 아니라 문서 목록 화면이었습니다. 목록을 그릴 때마다 그 계정의 문서를 전부 읽는 코드였기 때문입니다. 문서가 스무 개일 때는 문제가 없었고, 8천 명이 각자 수백 개를 들고 들어오자 데이터베이스가 주저앉았습니다.

그때 알게 된 것은 서버를 늘려도 소용이 없다는 사실이었습니다. 열 대로 늘리면 같은 무거운 질의가 열 배로 들어갑니다. 늘려서 해결되는 구조와 그렇지 않은 구조가 따로 있다는 뜻이고, 그 차이를 가리키는 말이 확장성입니다. 시스템을 어떤 덩어리로 나누고 어떻게 잇는지를 다루는 소프트웨어 아키텍처 아래에서, 잘 나눴는지 재는 품질 속성 셋 중 하나입니다.

키우는 방향은 둘입니다. 서버 한 대의 성능을 올리는 수직 확장과 서버 대수를 늘리는 쪽입니다. 앞쪽은 손이 덜 가지만 가장 좋은 기계에서 한계가 끝나고, 뒤쪽은 대수를 계속 늘릴 수 있는 대신 코드가 그에 맞게 만들어져 있어야 합니다.

대수를 늘려서 버티려면 세 가지가 갖춰져 있어야 합니다.

1. 요청 사이에 상태를 서버가 들고 있지 않아야 합니다. 이 성질을 무상태라 부릅니다. 로그인 정보를 1번 서버의 메모리에 담아 두면 다음 요청이 2번 서버로 갔을 때 그 사람은 로그아웃된 것처럼 보입니다. 상태는 서버 밖의 공용 저장소에 두고 서버는 매번 꺼내 씁니다.
2. 앞에서 요청을 나눠 줄 장치가 필요합니다. 여러 서버에 요청을 분배하는 로드 밸런서가 그 자리입니다. 이것이 없으면 서버를 스무 대 띄워도 요청은 한 대로만 들어옵니다.
3. 데이터를 담는 쪽이 함께 늘어나야 합니다. 서버는 쉽게 늘리는데 데이터베이스는 한 대로 두는 경우가 흔하고, 그 한 대가 곧 단일 장애점이자 전체의 한계가 됩니다. 읽기만 하는 복제본을 여러 대 두거나, 데이터를 조각내 여러 서버에 나눠 담는 샤딩을 쓰거나, 같은 결과를 다시 계산하지 않고 저장해 두는 캐싱으로 부담을 덜어 냅니다.

셋이 갖춰지면 대수 조절까지 넘길 수 있습니다. 부하에 따라 자원을 늘리고 줄이는 오토스케일링이 그것입니다.

한계를 찾는 방법은 하나입니다. 부하를 조금씩 올려 가며 무엇이 먼저 무너지는지를 봅니다. 동시 100명에서 응답이 200밀리초이고 1천 명에서 400밀리초인데 2천 명에서 3초로 뛴다면 한계는 2천 근처입니다. 무너지는 자리는 언제나 한 곳이고, 그 한 곳을 고치면 다음 한 곳이 드러납니다. 목록 질의를 고친 뒤에 페이지덱의 다음 한계는 파일 업로드였습니다.

결정 자리에 세 번 나옵니다. 구조를 고를 때, 사용자가 갑자기 늘어날 일을 앞두고, 서버 요금을 계산할 때입니다.

요금 쪽이 실무에서 가장 자주 걸립니다. 확장성이 있다는 말은 돈으로 해결할 수 있다는 뜻이기도 합니다. 서버를 두 배로 늘려 두 배를 감당한다면 비용도 두 배입니다. 그래서 확장성은 있고 없고로만 따지지 않고 언제까지 얼마로 감당할지를 함께 적습니다. 지금 100만 원으로 동시 2천 명을 버티는 구조가 2만 명에서 2천만 원을 요구한다면, 그 구간 앞에서 구조를 다시 봐야 합니다.

반대쪽 함정도 있습니다. 올 일이 없는 규모를 미리 대비하는 것입니다. 구성원 마흔다섯 명인 회사가 1억 사용자를 가정해 마이크로서비스로 잘라 두면, 서비스 다섯 벌의 배포와 감시 비용을 매일 치르면서 그 구조가 필요한 날은 오지 않습니다. 페이지덱은 한 덩어리로 두고 무거운 질의만 걷어냈고, 동시 8천 명은 그 안에서 감당됐습니다.

지금 감당하는 수, 무너지는 수, 그 사이를 버티는 비용 셋을 한 줄에 적어 두면 다음 분기에 무엇을 손볼지가 그 표에서 읽힙니다.

"이건 서버 늘려서 해결되는 문제가 아니에요. 질의 하나가 문서 전부를 읽고 있어요."

자원을 늘려도 소용없는 구조라는 지적입니다.

"지금 구조로 동시 2천까지는 버팁니다. 그 위는 장담 못 해요."

확장성을 있고 없고가 아니라 숫자로 말하는 방식입니다.

"세션을 서버 메모리에 두면 서버를 못 늘려요. 밖으로 빼죠."

대수를 늘리기 위한 조건을 짚는 말입니다.

페이지덱에서 이 대화는 태오와 규원 사이에서 오갑니다. 태오가 지금 한계와 그 위를 버티는 비용을 숫자로 가져오고, 규원은 그 비용을 언제 낼지 정합니다. 확장성은 기술 결정처럼 보이지만 실제로는 언제 얼마를 쓸지 정하는 결정이라, 같은 표를 보지 않으면 한쪽은 필요 없는 준비를 하고 다른 쪽은 갑자기 큰 청구서를 받습니다.

확장성을 빠름과 같은 말로 읽는 경우가 가장 많습니다. 둘 다 성능이라는 말로 뭉쳐 불리기 때문입니다. 하지만 재는 축이 다릅니다. 한 사람이 요청할 때 3초가 걸리는 제품이 만 명이 몰려도 여전히 3초라면 그 제품은 느리지만 확장성은 있습니다. 거꾸로 한 사람에게 100밀리초로 응답하는 제품이 천 명에서 20초로 뛴다면 빠르지만 확장성은 없습니다. 두 축을 섞으면 고칠 대상을 잘못 고릅니다. 느린 응답은 그 요청 하나를 들여다봐야 하고, 무너지는 구조는 사람이 늘 때 무엇이 같이 늘어나는지를 봐야 합니다.

처음부터 크게 설계해 두면 된다는 생각도 흔합니다. 나중에 고치는 비용이 크다는 경험이 이 판단을 부릅니다. 그런데 부하가 어디로 올지는 미리 알 수 없습니다. 페이지덱이 대비해 둔 곳은 동시 편집이었고 실제로 무너진 곳은 문서 목록이었습니다. 미리 한 준비는 대개 틀린 곳을 대비하고, 늘어난 구조의 복잡함은 그대로 남습니다. 실무 순서는 반대입니다. 무엇이 먼저 무너지는지 알 수 있게 재는 장치를 먼저 붙이고, 무너진 한 곳을 그때 고칩니다.