https://code.fb.com/production-engineering/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale/
https://medium.com/@strncpy/%EB%B2%88%EC%97%AD-making-facebooks-software-infrastructure-more-energy-efficient-with-autoscale-bb57232aae67
규모가 커지면서 에너지 효율을 높이고 환경에 영향을 주는 일은 낮추는 건 데이터 센터 팀에게 최우선 순위를 갖는다. Open Computer Project를 통해 에너지 효율적으로 사용하는 하드웨어와 데이터 센터 디자인에 대해 많이 이야기했지만, 소프트웨어에서도 에너지 효율성을 개선할 방법이 있는지 보기 시작했다. 전력 modeling과 조사, 사용량이 가장 높을 때의 운영과 에너지에 비례하는 computing을 포함하는 여러가지 방법을 조사했다.
우리가 개발한 굉장히 흥미로운 한가지 기술은 Autoscale이라 부르는 전력을 효율적으로 사용하는 로드 밸런싱 시스템이다. Autoscale을 업무용 클러스터에 배포하고, 이미 상당한 양의 에너지를 절약하고 있다.

에너지를 효율적으로 사용하는 로드 밸런싱

페이스북의 웹 클러스터는 매일, 특히 피크 시간동안, 서버 사용량을 증가시키는 수십억 페이지 요청을 처리한다.
페이스북의 기본 로드 밸런싱 정책은 변형된 라운드 로빈 알고리즘에 기반한다. 이 말은 모든 서버는 대략 같은 수의 페이지 요청을 받고 대략 같은 양의 CPU를 사용한다. 그 결과, 한밤중처럼 사용량이 낮은 시간동안 전체 CPU 사용량은 그리 효율적이지 않다. 예를 들어, 페이스북에서 사용하는 특정 타입의 웹 서버는 유휴 상태(0 RPS, 즉 0 requests-per-second)일 때 60와트를 소모한다. 저수준의 CPU 사용량을 보일 때(작은 RPS) 전력 사용량은 130와트이다. 하지만 중간 정도의 CPU 사용량으로 동작할 때, 전력 사용량은 150와트로 조금만 상승한다. 그러므로, 전력 효율성의 관점에서 볼 때, 서버가 낮은 RPS로 동작하는 걸 피하고, 중간 정도의 RPS로 동작하도록 해야 한다.
이 문제를 해결하고 전력은 더 효율적으로 사용하기 위해, 부하를 클러스터의 다른 웹서버로 분배하는 방식을 바꿨다. Autoscale의 기본 개념은 순수한 라운드 로빈 접근 대신, 로드 밸런서가 작업 부하를 서버가 중간 정도의 부하에 이를 때 까지 집중시키는 방식이다. 전체 작업 부하가 낮으면 (한밤중 부근처럼), 로드 밸런서는 서버의 일부분만 사용하게 된다. 다른 서버들은 유휴 상태로 남겨지거나 배치 작업을 위해 사용한다.
간단한 생각으로 들리겠지만, 대규모 시스템에서 효율적이며 강건하게 구현하기 위해서는 도전적인 작업이다.

전체 아키텍쳐

각 프론트엔드 클러스터에서, 페이스북은 자체 로드 밸런서로 작업 부하를 웹서 풀에 분배한다. Autoscale을 구현하면서, 로드 밸런서는 이제 활성화된, 즉 "가상의" 서버 풀을 이용하는데, 이 말은 기본적으로 실제 서버 풀의 부분집합이 된다. Autoscale은 동적으로 활성화된 풀 크기를 조정하게 설계해서 각 활성화된 서버는 전체 작업 부하 정도에 관계없이 최소한 중간 정도의 CPU 사용량에 이르게 된다. 활성화 풀에 있지 않은 서버는 트래픽을 받지 않는다.

Figure 1: Overall structure of Autoscale
우리는 이걸 그림 1처럼 피드백 루프로 제어하는 방식으로 만들었다. 제어 루프는 모든 활성화된 서버에서 사용량 정보(CPU, 요청 큐 등)를 모으면서 시작한다. 이 데이터에 기반해, Autoscale 제어부는 최적의 활성화 풀 크기를 결정하고, 그 결정 사항을 로드 밸런서에 전달한다. 로드 밸런서는 작업 부하를 활성화된 서버들에게 균등하게 분배한다. 다음 제어 사이클까지 이 과정을 반복한다.

결정 방법

결정 방법이 피드백 루프의 핵심이다. 우리는 예상하지 못한 일로 작업 부하가 치솟거나, 급락하는 걸 포함해 다양한 작업 부하에 적응할 수 있는 최적의 결정을 만들기 원했다. 한편으로, 에너지를 절약할 기회를 극대화하길 원했고, 반면에 사이트 성능에 영향을 미칠만큼 트래픽이 과도하게 집중되지는 않길 바랬다.
이런 면이 동작하도록, 고전적인 제어 이론과 PI 제어부를 사용해 빠른 반응 시간, 작은 overshoot등 최적의 제어 효과를 얻으려고 했다. 제어 이론을 적용하기 위해, 가장 먼저 CPU 사용량과 초당 요청(RPS)같은 핵심 요소의 관계를 모델링할 필요가 있었다. 이 작업을 위해, 핵심 요소들간의 관계를 이해하기 위한 실험을 진행하고, 실험 데이터를 기반으로 모델을 추정했다. 예를 들어, 그림 2는 페이스북에서 사용하느 한 종류의 서버에 대한 CPU와 RPS간의 관계에 대한 실험 결과이다. 그림에서 파란색 점은 원천 데이터이고, 빨강색 점선은 추정 모델이다(부분 선형). 이렇게 얻은 모델로, 제어부는 최고의 제어 파라미터를 얻기 위한 고전적인 stability analysis를 사용해 설계했다.

Figure 2: 한 종류의 웹 서버에 대한 CPU와 RPS 간 관계 실험 결과; 붉은색 점선이 추정하는 부분 선형 모델이다.

배포와 최초의 결과

Autoscale은 페이스북의 실제 웹 클러스터에 배포했고, 지금까지 성공적임을 증명했다.
현재 상태에서, 우리는 "비활성화" 서버들을 에너지 절약을 위해 유휴 상태로 남겨두거나, 배치 처리 작업을 위해 비활성화 용량을 repurpose하도록 결정했다. 두 가지 다 전체적인 에너지 효율성을 향상시켰다.
그림 3은 페이스북의 한 실제 웹 클러스터에서 가져온 결과이다. y축은 Autoscale이 24시간 동안 비활성화 모드로 전환한 서버의 수를 정규화한 값이다. 값은 한밤중 부근에 나타나는 비활성화된 서버의 최대 개수를 바탕으로 정규화했다. 또한 기대한대로, 피크 시간동안에는 이 클러스터의 어떤 서버도 비활성화 모드로 바뀌지 않았다.

Figure 3: 24시간 단위로 본 Autoscale에 의해 비활성화 모드로 변경된 서버의 개수
에너지 절약의 관점에서 비활성화된 서버들을 전력 절약 모드로 바꿀 때, 그림 4는 한 실제 웹 클러스터의 전체 전력 소모 - 일간 최대 전력 사용량에 대한 정규화한 전력 사용량 값 - 를 보여준다. 빨간색 선은 Autoscale이 없을 때 우리가 얻을 수 있는 최대치이다. 반면에 파란색 선은 Autoscale을 사용해 전력을 절약한 걸 보여준다. 이 클러스터에서, Autoscale은 한밤중 부근에 27%의 전력을 절약했다 (그리고, 기대한대로, 피크 시간동안은 전력 절약은 0%였다). 절약한 전력의 평균은 24시간 단위로 볼 때 여러 개의 웹 클러스터에서 10~15%이다. 많은 수의 웹 클러스터를 갖는 시스템에서, Autoscale은 상당한 양의 에너지를 절약할 수 있다.

Figure 4: 실제 웹 클러스터에서 Autoscale을 사용할 때와 사용하지 않을 때의 정규화된 전력 소모

다음 단계

전력 효율성의 측면에서 소프트웨어 인프라 스트럭쳐를 최적화하는 건 여전히 초기 단계에 머물러있으므로, 데이터 센터의 전력과 에너지 사용을 감소하기 위해 또 다른 소프트웨어 스택에서 기회를 찾는 작업을 지속할 것이다. 이런 개선이 지속되길 바라며, 페이스북의 인프라 스트럭쳐를 더 효율적이고 환경적으로 지속가능하도록 만들 것이다.