INTRO
안녕하세요. 개발자가 되기 위해 오늘도 열심히 공부중인 Soo입니다.
제가 관심을 가지고 있는 분야 중 하나는 언어 학습입니다. 처음에는 영어 공부로 시작했던 것이 계속 이어져 현재는 언어 자체에 흥미를 가지게 되었습니다. (물론 영어 하나도 제대로 못하고 있어서; 지금은 미래에 배우고 싶은 언어들만 정해 놓은 상태입니다.) 그리고 영어를 공부하면서 도움을 많이 받았던 방법 중 하나가 바로 Tandem, Italki 등과 같은 언어교환 사이트를 이용하는 것이었습니다.
때문에 문득 세계 각지의 사람들을 서비스의 대상으로 하는 언어교환 플랫폼을 직접 구현해 보면 재밌을 것이라는 생각이 들었습니다. 그래서 이번 프로젝트 주제 'Hello-World'는 제가 기존에 이용했던 유명한 언어교환 사이트들을 모티브해서 선정하게 되었습니다.
그러다보니 프로젝트의 초반부에서부터 다음의 문제점에 맞닥뜨리게 되었습니다.
1) 구현하려는 서비스의 대상은 세계 곳곳에 있는 언어 학습자이다.
2) 사용자가 증가해 서비스의 규모가 커지게 된다면 서버 입장에서는 들어오는 트래픽을 감당할 수 없을 것이다.
3) 위의 상황은 곧 서버의 장애를 의미한다.
4) 실제 서비스 상황에서 서버의 장애가 발생한다면 그만큼의 시간 동안 막대한 금전적인 손실을 입게 될 것이고, 서비스의 신뢰성에 관한 문제로까지 이어져 결국 서비스의 지속성에도 문제가 생길 것이다.
이러한 문제점을 인지하게 되면서 자연스럽게 '내가 이용했었던 플랫폼들은 이러한 문제를 어떻게 해결했을까?' 라는 생각을 하게 되었고, 대규모 트래픽을 처리할 수 있는 방법을 찾아나서게 되었습니다. 이번 시리즈는 이러한 과정 속에서 찾은 정보들을 모아서 정리하고, 각 장단점을 비교하여 적합한 해결책을 찾아내가는 과정을 담은 포스트 입니다.
Server Scaling
서버 스케일링이란 서버가 자신이 가진 한계에 도달했거나, 갑작스러운 예측하지 못하는 상황에 대비하여 서버의 규모를 키우는 것을 말합니다.
서버의 규모가 커진다는 것은 서버의 처리능력이 증가한다는 것이며, 그말은 대규모의 트래픽도 수용할 수 있게되어 더 많은 사용자를 수용해 비즈니스 기회 또한 증가시킬 수 있다는 것을 의미합니다.
그런데 서버 스케일링은 다시 다음의 두 가지의 방법으로 나뉘어 집니다.
1) Scale up
2) Scale out
두 방법은 서로 장단점이 존재하고 하나를 선택했을 때 발생하는 trade-off 또한 명확합니다. 때문에 성급한 결정을 내리기보다 각각의 내용을 먼저 살펴볼 필요가 있을 것입니다. 그후 살펴본 내용을 바탕으로 현재 개발중인 서비스는 어떤 방식으로 서버를 확장해야 최대의 효용을 얻어올 수 있을 지 함께 결론을 내려보도록 하겠습니다.
1) Scale up (수직적인 스케일링)
Scale up은 처리능력이 더 빠르고 성능이 좋은 CPU나 메모리 혹은 네트워크 장비 등을 장착하는 것처럼 서버 관련 장비들을 업그레이드를 해서 서버 그 자체를 증강함으로써 서버 처리능력을 향상을 가져오는 방법을 의미합니다.
Scale up 방식의 장점
- 장비의 추가나 교체만으로도 서버의 확장이 이루어지므로 상대적으로 구축이 쉽고 간편합니다.
- 추가적인 네트워크 혹은 라이선스 등의 증가가 없으므로 부가적인 비용이 낮습니다.
- 별도의 서버가 추가되지 않으므로 데이터의 정합성관련 문제를 고민할 필요가 없습니다.
Scale up 방식의 단점
- 초기에는 지불한 비용 만큼의 성능 증가를 얻을 수 있지만 갈수록 성능 증가에 따른 비용 증가폭이 훨씬 커집니다.
- CPU나 메모리 슬롯의 개수가 제한되어 있는 것처럼 결국 업그레이드에는 한계가 있다는 점입니다.
- 확장의 한계에 다다르면 새 시스템으로의 이전이 강제되며 이때 이전 비용(migration cost)이 발생할 수밖에 없습니다.
- 서버가 한대만 운용되는 것이기에 장애가 발생하거나 서버가 완전히 셧다운(shut down) 되어버리면 서비스의 지속성에 큰 영향을 주게 됩니다.
2) Scale out (수평적인 스케일링)
Scale out이란 서버 장비의 성능 자체를 증가시키는 것이 아니라, 서버의 수를 늘려서 서버의 전체적인 성능을 향상시키는 방법을 의미합니다. 즉, 한 대의 서버에서 처리하던 트래픽을 여러 서버에 분산시켜 처리시킬 수 있게 되므로 결국 서버의 처리 능력이 좋아지게 되는 것입니다.
Scale out은 동일한 서버와 DBMS를 병렬로 구축함으로써 이루어집니다. 이때 node단위로 각 서버를 관리하게 되는데요. 각각이 개별 시스템처럼 운영되는 것처럼 보일 수 있지만 사실은 여러 대의 서버가 모여서 하나의 시스템으로 인식되어 동작한다는 것이 그 특징이라고 볼 수 있겠습니다.
Scale out 방식의 장점
- 서버의 성능을 향상시키기 위한 고가의 서버 장비가 필요하지는 않으므로 비용적인 측면에서 다소 이점이 있습니다.
- 요청이 여러 대의 서버에 분산되어 처리되기 때문에 혹여나 한 서버에 장애가 발생하더라도 이것이 전면장애로 이어질 가능성이 낮은 편입니다.
Scale out 방식의 단점
- 말 그대로 서버의 개수가 늘어난 만큼 관리 편의성이 떨어지게 되며, 관리/운영 비용 또한 증가하게 됩니다.
- Scale up에 비해 꽤 복잡할 수 있다는 부분입니다.
- 트래픽이 각 서버에 고르게 분산되어야하기 때문에 load balancing의 적용은 필수입니다.
- 여러 노드를 연결해서 병렬 컴퓨팅 환경을 구성하고 유지해야 하기 때문에 설계나 개발에 상당한 시간이 소요되며 아키텍처에 대한 높은 이해가 필수입니다.
- load balancer가 트래픽 분산의 이유로 사용자의 정보가 저장되어있지 않은 다른 서버로 트래픽을 보내버린다면 데이터의 불일치 문제가 발생할 수 있습니다.
Scale up? or Scale out?
지금까지 서비스의 규모가 증가했을 때 서버로 들어오는 막대한 양의 트래픽을 원할하게 처리하기 위해서 서버를 증설하는데 사용되는 두 방법과 각각의 장단점을 알아보았습니다.
그렇다면 이제 어떤 방식을 택해야 할까요?
해당 질문에 대한 결론을 내리기에 앞서 우리는 현재 개발 중인 서비스의 특징을 살펴볼 필요가 있습니다.
Hello-World는 언어교환의 장을 제공하는 플랫폼의 역할을 하는 서비스입니다. 그렇기에 사용자들이 자신에게 맞는 언어교환 파트너를 더 편하게 찾고 그들과 지속적으로 교류할 수 있는 환경을 제공하는 것이 서비스의 핵심 부분일 것입니다.
때문에 작게는 언어교환을 위한 돕기 위한 서비스이지만 조금 더 넓게 보면 라인, 카카오톡과 같은 메신저로서의 성격과 페이스북, 인스타 그램과 같은 일종의 소셜 미디어의 성격을 합쳐 놓은 서비스라고 생각할 수 있을 듯 합니다.
그렇기에 Hello-World 서비스가 주로 처리해야 할 요청은 등록된 다른 사용자들에 대한 정보 검색, 메시지 전달, 친구 추가/삭제/차단, 알람 등 입니다. 이러한 요청들은 다수의 사용자들에 의해 동시다발적으로 보내지면서도 개개 요청에 대한 처리는 비교적 단순하다는 특징이 있습니다.
또한 데이터 정합성의 문제에 대해서 상대적으로 덜 민감하다는 특징을 가지고 있습니다. 데이터 정합성을 이야기할 때 대표적으로 등장하는 예시가 바로 모바일 뱅킹입니다. 모바일 뱅킹의 경우 금전적인 부분과 관련이 있으므로 데이터의 정합성이 철저히 지켜져야 합니다. 예를 들어, 서비스를 이용하는 사람들이 계좌이체를 한 뒤 해당 액수는 차감이 되었는데 상대방에게 그 금액이 전달되지 않았다거나 혹은 결제 도중 모종의 이유로 결제가 실패했음에도 돈이 빠져나가버리게 된다면 아무도 해당 모바일 뱅킹을 이용하지 않을 것입니다.
현재 개발중인 Hello-World나 대표적인 소셜미디어/메신저 서비스를 운영하는데 있어 데이터 정합성도 물론 중요하지만 이보다 더 중요한 것은 큰 장애 없이 서비스를 지속하는 부분일 것입니다. 한 사용자가 조건에 맞는 언어교환 파트너를 찾고자 필터링을 통해 검색했을 때 나오는 검색 결과가 1만 건이라고 했을 때, 작은 문제로 한 두명의 사용자가 누락된다고 해도 해당 사용자가 자신이 원하는 목적을 달성하는데는 큰 지장이 없을 것입니다.
그러나 서버에 문제가 생겨 검색자체에 대한 결과를 제공해주지 못하는 경우나, 상대방에게 문자를 보냈는데 전달자체가 되지 않거나 혹은 보내는데 몇 분 ~ 몇 십분 이상이 걸린다면, 혹은 서버에 장애가 자주 발생해서 사용자들이 원활하게 서비스를 이용할 수 없으며, 장애 복구에도 오랜 시간이 걸린다면 아무도 Hello-World 서비스의 이용을 원하지 않게될 것입니다.
결론: 우리 서비스에 더 적합한 서버 스케일링 방식은 Scale out입니다.
위에서 장단점을 이야기할 때 살펴보았지만 Scale up을 통해 서버 스케일링이 이루어지면 단일 서버에 모든 데이터가 저장되기 때문에 데이터 정합성을 지킬 수 있다는 장점이 있습니다. 그러나 문제는 서버가 하나라는 부분입니다. 그래서 해당 서버에 문제가 생기면 전면장애로 이어질 수밖에 없고 이를 복구하는 동안 사용자들은 큰 불편을 겪게 될 것입니다.
그러나 서버를 여러 대로 확장하는 Scale out 방식을 사용한다면 혹여나 한 서버에 문제가 발생하더라도 임시 방편으로 트래픽을 다른 서버로 보내서 사용자의 요청에 대한 처리를 계속 이어나갈 수 있을 것이며, 동시에 문제가 생긴 서버에 대한 복구도 함께 진행할 수 있을 것입니다. 때문에 Hello-World 서비스에 대한 서버 스케일링은 데이터 정합성과 관련된 부분을 조금 희생해서라도 Scale out 방식을 채택할 필요가 있겠습니다.
OUTRO
개발공부를 하면서 깨닫게 된 사실이 몇 가지 있습니다. 그중에 하나가 바로 모든 상황에 적합한 silver-bullet(만병통치약)이 존재하는 경우가 거의 없다는 점입니다. 한 가지를 선택하면 그에 따라 발생하는 trade-off가 꼭 존재합니다.
그래서 좋은 선택을 내리기 위해서는 먼저 선택할 수 있는 옵션을 아는 것이 먼저이며, 다음으로는 해당 선택지들에 대해 제대로 공부를 해야 상황에 맞게 최선의 결정을 내릴 수 있다는 것을 배웠습니다. 안그래도 공부할 양이 어마어마한 개발 분야인데 할일을 더 추가시켜 개발을 더 어렵게 만드는 것 같습니다. 하지만 개인적으로는 이러한 부분이 개발을 좀 더 흥미롭게 만드는 요소가 아닐까도 조심스럽게 생각을 해봅니다.
아직은 개발에 갓 입문한 초보지만 항상 이러한 교훈을 마음에 새겨두고, 선택의 기로에 섰을 때는 무엇이든 대충 결정하지 않고 먼저 학습을 통해 근거를 먼저 확보하고 이를 통해 결정을 내리는 태도를 길러나가고자 합니다. 이러한 모습을 하나의 습관으로 만든다면 개발 분야에 대해 조금 더 깊은 지식을 얻을 수 있음과 동시에, 개발하는 서비스에 대해서도 더 높은 이해도를 가질수 있을 것이라 믿어 의심치 않습니다. 항상 어제보다 더 나은 개발자가 되기 위해 노력하겠습니다.
다음 글은 Scale out을 선택했을 때 발생할 데이터 정합성의 trade-off를 어떻게 최소화 할 것인가에 대한 부분을 다룰 것입니다. 어쩔 수 없이 trade-off이 발생한다면, 가능한 이를 최소화 시키는 작업도 정말 중요한 일 중 하나일 것입니다. 그래서 저는 여러 과정 중에서도 로그인 기능을 구현하면서 제가 겪었던 데이터 불일치의 문제를 살펴보고, 어떻게 이 문제에 대한 해결책을 찾아갔는지에 대한 과정을 위주로 글을 풀어나가고자 합니다. 끝까지 읽어주셔서 감사합니다.
References
tech.gluesys.com/blog/2020/02/17/storage_3_intro.html
Project Link
https://github.com/f-lab-edu/Hello-World
f-lab-edu/Hello-World
언어교환 상대찾기 서비스. Contribute to f-lab-edu/Hello-World development by creating an account on GitHub.
github.com
'Project > Hello-World (Language Exchange)' 카테고리의 다른 글
| 대용량 트래픽 속에서도 무거운 DB 조회 연산을 효율적으로 처리하는 방법은 무엇이 있을까요? (2) (0) | 2021.04.13 |
|---|---|
| 대용량 트래픽 속에서도 무거운 DB 조회 연산을 효율적으로 처리하는 방법은 무엇이 있을까요? (1) (0) | 2021.03.29 |
| 대용량 트래픽을 견디는 서버를 만들기 위한 DB Replication 구축 - Microsoft Azure Cloud 서버의 MySQL 8.0.xx을 사용한다면 꼭 주의해야 하는 부분은? (a.k.a DB 구축 삽질기) (0) | 2021.03.20 |
| 다중 서버환경(Scale out)에서 Session 불일치 문제를 어떻게 해결해야 할까요? (0) | 2021.03.02 |
| 스프링은 프록시 객체를 어떻게 만들까? (0) | 2021.02.22 |
