안녕하세요 콥스랩(COBS LAB)입니다.
오늘 소개해 드릴 논문은 2019년 신경 정보 처리 시스템 학회에서 소개되었던 ‘Towards Safe Online RL in CS’입니다.
해당 내용은 유튜브 ‘딥러닝 논문 읽기 모임' 중 ‘Towards Safe Online Reinforced Learning in Computer Systems’ 영상 스크립트를 편집한 내용으로, 영상으로도 확인하실 수 있습니다. (영상링크:https://youtu.be/LQRisuX0Ppc)
먼저 introduction입니다. 강화 학습 적용의 한계에 대해서 알아보려고 하는데요. 최근 4~5년 이내 실시간 운영 측에서도 강화 학습을 활용하는 게 점점 증가를 하고 있습니다. 열거된 사례들은 모두 네트워크 제어용으로 강화 학습을 사용한 예시들입니다.
다만 강화 학습이 아직까지 적용하는데 한계가 있습니다. 제일 큰 이유 중에 하나가 실시간 운영체계에서 만약에 돌발상황이 발생했을 때 과연 강화 학습의 정책이 과연 강건함이 유지가 되느냐가 아직까지 의문점으로 남아 있습니다.
예를 들어서 강화 학습의 기본이 되는 Markov decision process는 이 특성상 계속 확률적으로 시행착오로 반복을 하면서 계속 나아가야 되는데 확률적으로 에이전트가 원하는 액션을 할 수도 있고 우리가 원하지 않는 액션을 할 수 있는데, 원하지 않는 액션을 택하는 거 우리가 임의로 이렇게 막을 수는 없다는 겁니다. 그래서 만약에 이런 경우가 실제로 적용할 때 문제가 발생하게 되면 수습하기가 좀 많이 어렵습니다.
예를 들어 주식 매매를 내가 원하는 타이밍 해야 되는데 안 된다던가, 더 심각한 경우에는 자율 주행 자동차 운전 로직을 강화 학습으로 짰는데 사람이 갑자기 도로에 뛰어들었다든가 이럴 때는 사실 대응하기가 매우 어렵습니다.
그런데 논문의 저자들은 그러면 여기서 근본적인 문제를 제기하는 게 실시간 운영체계 강화 학습을 적용하더라도 문제가 없게 하면 된다. 그래서 저자들이 제시하는 게 이른바 자전거 보조 바퀴 가설에 해당하는 내용입니다. 오른쪽에 심층 강화 학습 모델에서 붉은색으로 표시된 부분들이 저자들이 주장하는 자전거 보조 바퀴에 해당하는 부분입니다.
그래서 비교를 한다면 자전거가 강화 학습 모델이 되는 거고 보조 바퀴가 fallback policy에 해당이 됩니다. 보조 바퀴를 쓰게 되면 속도를 낼 수는 없는데 대신에 넘어지지 않겠죠. 그리고 시간이 지나서 자연스럽게 자전거 타는 데 익숙해지면 보조 바퀴에 의존하지 않고 주행이 가능합니다.
다시 얘기하면 강화 학습 모델이 fallback policy 미만으로 under perform 하지 않고도 장기적으로 계속 안정적인 학습을 통해서 전체적인 성능 향상을 도모를 할 수 있을 것입니다.
자전거 보조 바퀴가 어떻게 적용이 되었는지 사례를 보면서 얘기를 해보겠습니다. 먼저 강화 학습을 적용한 사례로 논문에서 load balancer를 예시로 들고 있습니다. 간단하게 load balancer가 어떤 것인지 설명을 하면은 먼저 서버에 가해지는 workload를 분산해주는 기술을 의미를 합니다
기술적으로 보면 클라이언트와 서버 사이에서 위치를 하게 됩니다. 간단하게 얘기하면 서버가 여러 대가 있으면 한대 서버의 부하가 집중적으로 들어가지 않도록 트래픽 관리를 함으로써 각 서버가 최적의 상태를 유지하도록 도와주는 장치가 되겠습니다.
그리고 논문에서는 service level objective라는 표현을 쓰는데 사전에 서버마다 설정되어 있는 응답 대기시간을 초과할 경우에 다른 서버로 다시 똑같은 요청을 재전송을 어떻게 할 것인지 결정을 하는 역할을 합니다. 익숙한 예시가 여러 서버가 포함된 네트워크에서 실시간으로 계속 트래픽 변동이 있을 건데 마찬가지로 순간적으로 부하가 급변할 경우에 맞춰가지고 강화 학습을 적용할 수 있는 도메인 중 하나로 볼 수 있습니다.
load balancer 모형을 강화 학습 모델로 치환을 한 경우입니다. 먼저 강화 학습 모델로 치환했을 때, 처음에 스테이트의 경우엔 각 서버에 현재 대기 중인 대기열의 분량이고 각 서버에서 처리를 한 요청 처리결과 두 가지를 구성이 될 수 있습니다.
Action 은 서버 선택과 각 요청에 따른 타임아웃 값의 2차원으로 구성됩니다.
첫 번째 1에서 n까지 있는 숫자는 네트워크에 몰려있는 전체 서버의 개수이고, 뒤에 L1, L2 그리고 Lk까지 있는 L은 서버에 몰려있는 대기열의 길이, 그리고 1에서 k까지 그 각 서버에서 선택할 수 있는 timeout입니다.
a^j는 j 번 서버로 요청을 보내고 이 서버에서 요청 처리가 실패할 경우를 대비하여 L번 서버에 시차를 두고 같은 요청을 복사해서 전송합니다.
특정한 i번째 스텝에서 보상은 이전 스텝에서 현재 i번 스텝까지 걸린 시간과, 현재 남아있는 미완결 요청 사항의 수입니다. 즉, 페널티는 시간이 경과하는 동안 남아있는 처리 시간의 합으로 표현 가능합니다.
보상은 마이너스 텀이고, 대기열 적체를 그냥 둔 채로 시간이 지날수록 페널티 값은 증가, 하지만 액션에 따른 보상 값은 음수입니다
그래서 간단하게 Policy를 정의하면 이 페널티를 어떻게 하면 최소화할 수 있는 액션을 취하도록 하자가 학습 모델의 간단한 공식이 되겠습니다.
자전거 보조 바퀴가 어떻게 저자들이 설계했는지 상세히 보겠습니다. 아까 말씀드린 것처럼 프레임 워크에서 붉은색이 일반적인 강화 학습 모델에서 추가된 부분입니다.
먼저 Safe condition을 보시면 현재 시스템이 안전한 상태인지 아닌지 나타내는 함수입니다. 앞에서 설명한 스테이트 값이 응답 요청률이 될 건데 미리 설정해 둔 서버 백엔드에서 각 서버가 처리할 수 있는 서비스 제공률을 넘어가지 않으면 사실은 발동이 되지 않습니다. 그래서 화살표가 Safe Condition이 충족되느냐가 예, 아니요로 구분되어 있는데, 본 논문에서는 이 설정을 서버 별로 설정해둔 가장 긴 대기열 값을 넘어가느냐 넘어가지 않느냐로 결정을 하고 있습니다.
실험에서는 이 값이 100 미만이라고 언급을 하고 있고, 그래서 이 값이 100 미만이면 Safe Condition이 충족된 상태니까 Yes로 가서 원래대로 학습을 계속 반복하게 되고 만약에 Safe Condition이 No가 되면 그다음부터 fallback policy가 들어가게 됩니다.
그래서 Safe Condition 안전조건이 위반이 될 경우에 fallback policy 자전거 보조 바퀴가 발동이 되어서 그다음부터는 액션하고 리워드 값에 계속 영향을 주게 되고, fallback policy가 발동이 된 순간부터는 두 번째 액션을 하지 않고 무조건 q가 가장 짧은 서버로만 에이전트가 응답 대기 요청을 보내기 시작합니다. fallback policy가 발동하기 전에도 load balancer가 사실은 그때 가장 시점의 부하를 고려하는 가장 대기열이 짧은 서버 응답을 보내고 있었는데요. 차이점이 뭔가 하냐면은 fallback policy가 발동된 시점부터는 무조건 대기열 정체를 해소하는 게 목적이 된다고 얘기를 합니다.
보시면 x가 추가 페널티 부분이 있는데 이를 다시 한번 수식으로 확인해 보겠습니다. 그래서 목적함수는 앞에서 확인했던 텀이 빨간색으로 표시된 부분이 추가됐습니다. 이 부분은 일반적인 학습을 진행할 때는 반영이 되지 않고 만약에 fallback policy가 발동되었을 때만 텀이 추가가 됩니다.
간단하게 보시면은 붉은색으로 된 부분 중에 베타는 추가 페널티 벡터에 해당되는데 이 값이 상당히 클 경우에는 전체 페널티 값을 줄이기 위해 에이전트가 기존에 학습하는 것보다 더 적극적으로 학습을 해서 좀 더 빨리 안전 조건으로 들어갈 수 있도록 진행하는 목적으로 사용하고 있습니다.
만약에 두 번째 텀이 없다고 하면 사실은 서버마다 처리할 수 있는 용량을 아까 설정해놨다고 했는데, 이런 것들을 다 미리 설정된 안전조건을 다 무시하고 임의로 보상이 극대화된 쪽으로 학습을 진행하게 될 것입니다. 그러면 물리적인 한계를 무시하고 계속 학습을 하는 경우가 되니까 신경망이랑 비교를 하자면 local minima에 많이 빠지는 경우와 같다고 해석을 할 수 있습니다.
그래서 fallback policy를 적용해서 전체 페널티 값이 사전에 설정되는데 안전 조건 미만으로 떨어지게 되면 시스템이 정상화된 것으로 해석을 할 수 있습니다. 그러면 두 번째 텀을 policy에서 삭제를 하게 됩니다.
논문에 표시된 수식을 따르자면 붉은색은 fallback policy가 발동되어 있는 동안에는 extra penalty 텀에 마지막에 1을 곱한 상태고, 해제가 될 경우에는 1 대신에 0을 곱해서 자연스럽게 두 번째 텀을 날리게 됩니다.
그래서 액션이 두 가지 중에 fallback policy 발동된 상태에서는 모든 서버에 적체돼 있는 대기열이 전부 다 100 미만으로 다 빠질 때까지는 에이전트가 무조건 대기열 적체를 다 없을 때까지 그 액션만 취하도록 하게 됩니다.
참고로 Policy gradient method를 설명드리겠습니다. 원래 대로라면 fallback policy가 발동이 되고 큰 배타 값이 들어가 있으니까 액션을 굉장히 적극적으로 하지 않으면 전체 페널티 값이 빨리 줄어들지 않을 텐데 fallback policy를 발동을 시키면 액션을 정상상태에서 하던 것보다 더 적극적으로 에이전트가 액션을 취해야 적체된 대기열 값을 빨리 줄일 수 있는 이 상태가 해소가 되는데, 이렇게 하려면 entropy factor를 증가를 시킵니다. 그런데 entropy factor가 늘어날수록 다양한 범위를 찾아갈 수 있지만, 동시에 원하는 정책으로 수렴하는 게 아니고 발산하게 됩니다. 그래서 이 논문에서는 안전 조건 위반 횟수를 entropy factor를 조절하는 인자로 사용하기로 하였습니다.
그리고 저자들은 이미 policy gradient method를 조절하는 방법으로 entropy factor를 가지고 액션을 어떻게 적극적으로 취할 거냐 아니면 덜 적극적으로 취할 거냐를 조절을 했다고 얘기합니다. 실제 실험에서는 액션을 5만 번 동안 에이전트가 취하는 동안에 안전조건 발동이 되지 않으면 entropy factor를 값을 1에서부터 최대 10까지 차례차례 하나씩 올렸다고 설명을 하고 있고, 강화 학습이 특정한 policy에 수렴하지 않을 경우엔 역으로 한번 액션 할 때마다 entropy 값을 10000분의 1 만큼 감소시켰다고 얘기를 하고 있습니다.
실험 부분입니다. 실제 실험에서는 서버가 여러 개가 있다고 했었는데 각각 다른 서버 10 가지를 구성을 해놨었고, 실험 과정에서 총 세 번에 걸쳐서 부하를 임의로 변경을 합니다.
가로축은 처음에 실험을 시작할 시점부터 실험이 끝날 때까지 에이전트가 액션을 취하는 총횟수를 나타냈고, 왼쪽에서 오른쪽으로 갈수록 시간이 경과하게 됩니다. 그리고 세로축에서는 밑에서부터 각 서버별 응답 대기시간, 각 적체되어 있는 대기열의 수 그리고 1에서 10까지 10배 차이가 나게 entropy factor를 변경시킨다고 했었는데 0에서 1까지 정규화해서 표현한 entropy factor입니다.
최초 서버 load balancer가 작동을 하고 있다가 가로축에 대략 0.6 정도에 해당하는 시점에서 한번 임의로 부하를 변경시킵니다. 여기서는 Pareto shape를 1.4에서 1.5로 변경했다고 얘기를 하는데 간략하게 설명을 하면 이 개수를 변경을 함으로써 치우친 그래프가 얼마나 더 빨리 줄어드느냐 늘어나느냐를 조절을 할 수 있다고 이해하시면 됩니다.
그래서 크게 변경을 가하면은 시스템의 안전 조건이 대기열 사이즈가 100인데 이 값에 해당하는 가로축의 방향으로 점선이 이 값을 벗어나도록 임의로 변경시켰습니다. 그러면 다시 fallback policy 발동을 하면서 entropy가 갑자기 증가를 합니다. 그러다가 시간이 점점 지나면서 회복이 되면은 다시 안전 조건 미만으로 대기열 빨간색으로 표기된 최대 허용 가능한 100 이상의 대기열 적체 숫자가 다시 점점 줄어드는 것을 확인을 할 수 있습니다.
실제로는 오프라인으로만 학습을 한 강화 학습 모델을 load balancer에 투입을 하게 되면 어떤 식의 돌발상황이 나올지 알 수가 없습니다. 모든 경우의 수를 알 수가 없는 상태에서 다른 모델을 넣으면 학습을 정상적으로 진행을 할 수가 없을 건데 어떻게 나타나는지 다시 한번 비교를 해보겠습니다.
최초 1 퍼센트에 해당하는 부분을 따온 micro 벤치마크 테스트에 해당됩니다. 학습을 일반적인 오프라인 모델로 학습을 한 강화 학습은 주황색으로 표시도 되고, 그리고 보조 바퀴가 포함돼서 학습을 한 강화 학습모델은 왼쪽 그래프에 푸른색, 오른쪽 그래프에 붉은색으로 보시면 되겠습니다.
그래프의 가로축은 앞선 실험의 최초 1퍼센트에 해당한 부분이고, 세로축 왼쪽은 각 서버의 요청 응답 시간, 오른쪽은 각 적체되어 있는 대기열의 크기이고 두 개 다 log scale로 표기가 되었습니다.
오른쪽 그래프에서는 원래 그래프에서 안전조건인 대기열 값 100을 넘어가는 경우에만 붉은색을 표시를 했고 결론적으로 적절한 안전장치를 반영을 할 수가 있으면 일반적인 우려와 반대로 실시간으로 강화 학습을 사용하는 게 훨씬 유리한 것을 알 수 있습니다.
대신에 이미 고정되어 있는 정책만 일관적으로 추종하는 강화 학습 모델로는 급변하는 동적 시스템에서 적용이 어려운 것을 알 수 있습니다.
마지막으로 Discussion입니다.
첫 번째. 발표에서 소개한 사례처럼 명확한 안전 조건 등이 이미 마련되어 있는 네트워크 등은 강화 학습 용으로 보조 바퀴를 설계하는 것이 어렵지 않았습니다.
하지만 자율주행 자동차처럼 명확한 안전 조건을 설정하기 어려운 도메인에서도 보조 바퀴를 과연 설계할 수 있을지, 향후 강화 학습 응용을 늘리기 위해서는 적용을 고려하는 시스템의 안전 조건과 fall back 정책을 어떻게 설정할 것인지 먼저 고민이 필요합니다.
둘째, 본 연구에서는 에이전트가 다양한 공간을 탐색을 수 있도록 강제로 entropy factor를 조정해 가며 학습을 유도했었으나 실제 적용에서는 현실성이 떨어집니다.
entropy factor 조정 외 다른 방법으로 더 다양한 탐색을 자동으로 할 수 있는 방안에 대한 연구가 필요합니다.
셋째. 일반적인 강화 학습은 대부분 on-policy 모델인데, 이 경우 본 논문 사례처럼 fall-back policy 학습 내용은 반영하지 않습니다.
저자들은 off-policy에 해당하는 fall-back policy를 통해서도 얻을 수 있는 경험치가 본 모델 학습 시 반영되어야 장기적인 모델 학습 성능 향상이 가능하다고 언급하였습니다.
향후 후속 연구에서는 on-off policy 학습 내용을 모두 반영하는 방안에 대한 연구가 필요해 보입니다.
댓글