Please enable JavaScript to view the comments powered by Disqus.scale-out 이 가능하도록 설계 하라
Search
🏘️

scale-out 이 가능하도록 설계 하라

태그
Architecture
공개여부
작성일자
2021/05/13
팀에서 공유받은 글 중 특별히 눈이 가는 주제를 번역 및 요약하였다. 원문은 microsoft 의 글이며 이 기회에 scale out 을 위해 무엇을 주의해야 하고 어떤것을 고려해야하는지 정리하고 싶다.

application 이 수평적으로 scale-out 하도록 설계하라

요즘은 cloud 를 사용하면서 필요에 따라 instance 를 scale-out 하고, 필요가 줄어들면 쉽게 scale-in 하기 좋아졌다. 그래서 instance 에 올라가는 appliation 은 쉽게 추가 혹은 제거가 가능하도록 설계할 필요가 있다.

Recommendations

Avoid instance stickiness

여기서 의미하는 stickiness 는 어떠한 서버와 서버의 관계에 의존성이 있음을 의미하는 것으로 해석된다.
어떤 동일한 client 의 요청이 동일한 server 로 가는 것을 stickiness 로 간주한다.
이러한 stickiness 는 우리의 application 의 scale-out 의 발목을 잡는다.
대표적으로 다음의 예시가 있다.
session 을 각 instance 의 memory 저장하는 경우
암호화를 위해 machine-specific key 를 사용하는 경우
모든 instance 가 어떠한 request 도 처리할 수 있도록 해야한다.

Identify bottlenecks

scale out 은 모든 성능 이슈에 대해 마스터 키가 아니다.
만약 DB가 bottleneck 이라면 아무리 web server 를 추가한다 하더라도 병목현상을 해결할 수 없다.
새로운 instance 를 추가하기 전에, 병목현상의 원인이 무엇인지 파악하여 문제의 범위를 분명히 하고 그 문제를 해결해야 한다.
상태를 갖고 있는 시스템이 bottleneck 의 원인이 되는 경우가 많다.

Decompose workloads by scalability requirements.

application 이 여러가지 workload 로 구성되어 있다면 특정 workload 마다 scale-out 에 필요한 것이 달라질 수 있다. 예를들어 서비스용 workload 와 admin 용 workload 가 하나로 구성되어 있다면, 서비스쪽엔 트래픽 폭탄이 쏟아질 수 있지만 admin 은 사용자가 적기 때문에 이러한 일이 발생하지 않는다.

Offload resource-intensive tasks

CPU나 I/O 자원이 많이 요구되는 task 는 가능하다면 background job 으로 분리하는게 낫다.
특히 user 의 요청을 다루는 front-end 라면 이러한 load 를 최소화해야 한다.

Use built-in autoscaling features

많은 cloud 서비스는 내장된 auto scaling 기능이 탑재되어 있다. 만약 특정 workload 가 규칙적으로 증가되는 것을 예측할 수 있다면 그 시간대에만 auto scale-out 이 되도록 설정하라.
반면에 특정 workload 가 사용되지 않는 것을 예측한다면 그 시간대에 줄이기도 하라

Consider aggressive autoscaling for critical workloads.

critical workload 를 필요에 의해 유지해야 한다면 새로운 instance 를 빠르게 추가하여 traffic 을 다루는 것이 낫다. 그리고 그 workload 가 서서히 줄어든다면 점진적으로 instance 를 제거하면 된다.

Design for scale in

instance 가 제거되면서 application server 가 scale-in 된다는 사실도 기억해야 한다.
그래서 application 서버는 graceful remove 가 되도록 해야하는데 다음의 scale-in 방법을 고려하면 좋다.
shutdown event 를 받고 가능하다면 명확하게 shutdown 해야 한다.
서비스 사용자를 위해 일시적인 오류 처리 과정과 재시도가 포함되어야 한다.
장기 실행 작업의 경우 작업을 분할하고 check point 혹은 pips and Filters 패턴을 고려하라
queue 를 사용해 item 을 큐잉하고 어떤 instance 던지 그 item 을 소비할 수 있도록 하라.
실제로 코드에서 어떻게 반영해야 할지, 설계상에서 어떻게 녹여내야 할지 고민할 필요가 있다.