Memoir


## Intro

CNSM 2023 학회가 2023.10.30 - 11.2 까지 캐나다에서 진행되었다. 이번에 좋은 기회를 얻게 되어 학회에 참석할 수 있었고 이는 나의 2023.10.29 ~ 11.4일까지에 걸친 이야기이다.

## Episodes

### 2023.10.29 (일)

출국부터 시작해서 굉장히 다사다난했다. 처음 장거리 비행이기도 했고, 첫날 발표를 해야했기 때문에 굉장히 긴장을 했었다. 뿐만 아니라 개인적으로 힘든 일도 있었기 때문에 29일은 정말 힘들었던 기억이 난다. 비행기에서는 Her이라는 영화를 챙겨보고 굉장히 복잡한 감상에 젖어서 계속 발표 연습을 했던 거 같다. 캐나다 토론토에 도착하고 학회장 근처에 있는 숙소로 이동하기 위해서 3시간 정도 셔틀 버스를 타고 이동해서 최종 시간을 보니 새벽 1시 정도였었다. 굉장히 피곤했지만, 시차적응에 실패하고 걱정, 근심도 많아서 새벽 5시쯤은 되어서 눈을 감았던 거 같다.

### 2023.10.30 (월)

![first-day](/images/first-day.png)

학회 첫날에는 7시에 인나서 주변 구경을 좀 할 생각이였는데 5분 거리 학회장을 찾는데 1시간은 걸린 거 같다. 같은 이름의 호텔이 2개 였는데 다른 곳에 들어가서 학회장소를 찾았다. ㅠㅠ 암튼 위치를 찾고 멀리서 나이아가라 폭포를 구경하고, 학회장에 앉아서 9시부터 시작하는 session을 기다렸다. 첫날은 2column 7page 정도의 paper에 관한 mini conference와 workshop 내용을 발표하는 두 개의 session이 동시에 진행되었고, 오전 session 시간에는 workshop, 오후 session에는 mini conference 쪽에서 내용을 들었다. 전체적으로 workshop의 경우에는 도전적인 내용이 많았다. LLM 기반으로 intent network를 구현한 내용이라던지 (결론은 종래연구들과 다르지 않게 결국은 classification에 가까웠지만,) anomaly detection을 수행할 때, 각 feature간의 correlation을 활용하여 SOTA 이상의 결과를 받았다는 내용의 발표가 재밌게 다가왔다. 각 각 논문 제목은 다음과 같았다. (후에 시간이 된다면 한번 찾아보면 재밌을지도..ㅎ)

- **LLM-based policy generation for intent-based management of applications**  
  Kristina Dzeparoska and Jieyu Lin (University of Toronto, Canada); Ali Tizghadam (TELUS & University of Toronto, Canada); Alberto Leon-Garcia (University of Toronto, Canada)
- **MIMC: Anomaly Detection in Network Data via Multiple Instances of Micro-Cluster Detection**  
  Rafael N Copstein (Dalhousie University, Canada); Bradley Niblett and Andrew Johnston (2Keys Corporation An Interac Company, Canada); Jeff Schwartzentruber, M. I. Heywood and Nur Zincir-Heywood (Dalhousie University, Canada)

mini conference에서는 전체적으로 Deep Learning을 이용한 Something이 주류가 되었다. (traffic classification, performance prediction, etc.) 작년 CNSM 2022에 참석했던 연구실 선배말로는 작년까지만 해도 AI에 대한 논문의 양은 엄청 많지는 않았던 거 같은데 이번에는 그 양이 꽤나 많아서 관련 논문만 50% 이상으로 느껴졌다. 나의 발표는 마지막 session에서 끝에서 두 번째였는데 사실 해당 발표는 연구실 선배의 논문을 대신해서 발표하는 것이였다. 준비는 많이 헀지만 막상 앞에서니 준비했던 내용을 까먹고 넘어간 것도 있어서 아쉽긴했다. 발표보다는 질의응답을 굉장히 걱정했는데 한국인임을 고려했는지 발표가 다소 어눌했는지 다들 굉장히 천천히 말해줘서 알아듣는데는 문제가 없었다. 다만 2저자의 한계상 알 수 없는 실험 디테일에 대한 부분에 대한 자세한 설명을 잘 하지 못했던 것은 아쉬웠다. 이렇게 발표는 끝났고, 월요일은 별도의 저녁 행사가 없기 때문에 숙소가서 짐을 풀고, 밥을 먹으려고 했는데 피곤해서 그냥 뻗어서 자버렸다. 눈을 뜨니 11시가 넘어서 씻고 다시 잤다. ㅎㅎ

### 2023.10.31 (화)

![coffee-time](/images/coffee-time.png)

어제 저녁도 안먹고 잤기 때문에, 굉장히 배고픈 상태로 깨어났다. 오늘은 내가 작성한 논문 [SDN Lullaby](/posts/sdn-lullaby)도 Poster로 Accept 되어 발표를 해야했기에 8시에 맞춰 도착해서 Poster 준비하고 커피 한잔 내려서 준비를 계속했다. 오늘은 Technical Session에서 2column 9페이지 분량 정도의 논문이 발표되었고, 전체적인 내용은 wireless network와 AI 기반 네트워크 관리가 주류였다. 그리고 Session 중간마다 Coffee break 때에는 Poster 에 대한 발표가 이어졌다. 처음에 서서 기다릴 때는 꽤나 긴장했는데, 사람들이 관심을 가져주니 나름 또 재밌게 이야기하면서 긴장이 꽤나 풀렸던 거 같았다. 친절하게 처음부터 끝까지 무슨 내용인지 물어봐준 학생과 교수님들이 있어서 다행이였다. 그러다보니 금방 시간이 흘러서 정신없이 30분이 지나간 거 같다. 전체적으로 SDN이라는 이름에 질문이 많았는데, 아무래도 이름을 잘못 지은 거는 맞는 거 같다. 사실 VNF Scheduling이 근본이기 때문에 SDN이라는 관련이 없으니까.. Sakamoto라는 Softbank에서 일하고 계신 일본인 분도 강화학습을 진행하고 있어서 관심이 생기셨는지 명함도 주시고, 강화학습 관련해서 그리고 잡다한 이야기를 꽤나 나누었다. 점심 식사 때는 어제 발표 때 public dataset에 대한 실험이 부족했던 이유를 꼬집었던 교수님이 다가와 자기도 anomaly detection 관련 연구를 하고 있다보니 관심이 있어서 그랬다면서 먼저 다가오셔서 anomaly detection 실험에 대해서, 각 모듈들에 대해서 물어보셨다. 오후 session에도 발표 중간 coffee break가 있었고, poster session이 다시 열렸기 때문에 이번에는 다른 사람들의 poster를 구경했다. 처음에는 말걸기가 좀 두려웠는데 오전이 지나면서 좀 자연스럽게 궁금한 걸 물어봤던 거 같다. 그 후 Welcome reception 시간이 찾아왔고, 여러가지 주워먹다가 와인 한잔 홀짝이면서 사람들 얘기하는 걸 듣다가 나와서 나이아가라 폭포를 산책했다. 개인적인 삶이나 목표를 생각하면서 걷다보니 금방 시간이 흘렀고, 방으로 돌아와서 그 날은 꽤나 잠을 잘 잤던 거 같다.

### 2023.11.01 (수)

![third-day-banquet](/images/third-day-banquet.jpg)

수요일부터는 지도 교수님이랑 같이 시간을 꽤나 같이 보냈다. 수요일부터는 발표가 없었기 때문에 여러가지 발표를 들을 수 있었다. 그 중에서 가장 기억에 남는 내용은 Kubernetes에서 container 분배 시에 CPU, Memory 사용량만 고려하는데 여기서 Application의 성능을 고려하지 못함을 꼬집고, container간 communication에서 발생하는 latency를 단축시킬 수 있는 배치 방법을 제안한 연구가 꽤나 재밌게 다가왔다. 내가 진행하는 연구와 비슷하지만, kubernetes를 통해서, 이를 시도했다는 건 꽤나 재밌는 시도로 다가왔다. 혹시 논문 결과가 나오면 아래 논문을 찾아볼 수 있을 것이다.

- **Performance Impact of Queue Sorting in Container-based Application Scheduling**  
  José Santos (Ghent University - Imec, Belgium); Miel Verkerken, Laurens D'hooge and Tim Wauters (Ghent University - imec, Belgium); Bruno Volckaert (Ghent University-Imec, Belgium); Filip De Turck (Ghent University - imec, Belgium)

수요일 Session이 끝나고는 banquet이 있어서 참석했다. 나이아가라 폴 근처에 위치한 winery에 가게 되었다. 꽤나 근사한 곳이였던 것으로 기억한다. 교수님 친구 분 중에 자녀분도 참석했는데 k-drama에 빠져있다고 해서 이동 중에 이거 관련해서 얘기를 나누었다. 가장 좋아하는 연애인을 물어보니 차은우라고 한 걸 보면, 역시 외국사람들도 보는 눈은 똑같은 거 같다. 근데 나랑은 드라마 취향이 꽤나 안맞긴했다. 확실히 로맨스가 유명한 거 같다. winery 도착해서 Timo라는 박사과정 학생을 만나서 얘기를 나누는데 k-drama 사건도 있고해서, free time에 뭐하냐고 물어보니 소방관 활동을 한다고 해서, 참 놀랐던 기억이 난다. 관련 에피소드도 좀 듣고보니 참 대단하기는 했다. 나도 군대에 가서 삽질 좀 했다고 했는데 박사과정 중에도 하고 있다고 하니 참 본받을만한 친구인 거 같다고 생각했다. 예약에 차질이 있어서 이상한 변두리에서 식사를 하긴 했지만, 음식은 굉장히 맛있었고, 와인도 좋았다. 캐나다에서 유명하다는 아이스 와인은 솔직히 내 취향은 아니였다. 솔직히 너무 달았다. 식사가 끝나고 돌아오니 11시를 넘기고 있었고, 깼다 잤다를 반복헀지만, 금방 잠에 들었다.

### 2023.11.02 (목)

![third-day-naiagarafall](/images/third-day-naiagarafall.png)

학회의 마지막 날이였다. 마지막 날 session들이 굉장히 재밌었다. keynote session에 들은 network verification이라는 주제는 특히 해당 학회 기간 중에 가장 남는 키워드로 남을 거 같았다. 사실상 연구 주제로 생각 중이던 network configuration 자동화에 대해서 해당 키워드를 기반으로 연구가 되고 있는지를 파악하지 못했기 때문에 뭔가 혈이 뚫린 느낌이 였고, 이를 기반으로 좀 더 찾아보면 좋은 결과를 얻을 수 있을 거 같다는 느낌을 받아서 굉장히 집중해서 들었다. 요약하자면, network 상태를 verification 하는 것인데, 이를 진단하는 것을 넘어서 추천하는 과정까지도 해당 발표자는 연구를 진행하고 있었다. 한국에 돌아가면 batfish, netcov 관련 논문을 좀 더 찾아보면 도움이 될 것 같다. 또한, network traffic data 기반으로 classification, anomaly detection, prediction 등 여러 가지 작업이 수행되는데 이들이 모두 동일한 dataset을 공유한다는 전제 하에 공유할 수 있는 공통 foundation model을 제안한 keynote도 굉장히 재밌었다. NetFound라는 제목으로 foundation 모델을 pretrain해서 여러 task에 적용해서 높은 성능을 보일 수 있음을 증명했기 때문에 나중에 한 번 찾아서 사용해볼만한 가치가 있어보인다. 전체 학회 중으로 봤을 때도 참석자들의 질문, 특히 여러 교수님들의 질문이 가장 많은 두 개의 발표가 위 두 개의 내용이였다. 이를 끝으로 전체 학회는 마무리 되었다. 저녁 식사는 지도 교수님과 TPC들 식사에 함께 참석하였다. 좋은 기회였지만, 꽤나 중압감도 커서 얌전히 맛있는 식사를 하다가 돌아왔다. 다들 확실히 나이가 드셔도 열정이 느껴지는 게 대단했다. 숙소에 돌아왔는데 이날은 관광객인지 건너방에서 소음이 너무 심해서 자다깨다를 계속 반복하다보니 잠을 거의 못잔 거 같다.

- netFound: Foundation Model for Network Security  
  Satyandra Guthula and Navya Battula and Roman Beltiukov and Wenbo Guo and Arpit Gupta
- Test Coverage for Network Configurations  
  Xieyang Xu and Weixin Deng, University of Washington; Ryan Beckett, Microsoft; Ratul Mahajan, University of Washington; David Walker, Princeton University

### 2023.11.03 (금)

![last-day-cntower](/images/last-day-cntower.png)

학회가 끝나고 하루는 교수님과 토론토 대학 방문을 하였다. 토론토 대학은 정문이 없는 게 확실히 신기했다. 한국에서는 산 속에 존재하는 산신령 같은 게 교수님이고, 대학원생들인데 여기는 평지에 도시 한 가운데에 있으니 확실히 느낌이 달랐다. 일정이 끝나고, 시간이 남아서 근처 켄싱턴 마켓과 온타리오 미술관 관광을 조금 했는데 해외에 있다는 게 확실히 체감이 되었다. 관광하기에 좋은 도시임에는 틀림이 없었다. 하지만, 어제 잠을 거의 못자서 9시에 너무 피곤해서 숙소로 돌아갔다. (미술관에서 잠깐 앉아서 쉬려는데 꾸벅꾸벅 졸았다. ㅎㅎ) 진짜 오랜만에 잠을 푹잤다. 이날 12시간은 넘게 잔 거 같다.

![last-day-gallary](/images/last-day-gallary.png)

## Outro

가장 많이 들었던 말은 Ph.D 과정이냐고 물어본 질문이였다. 항상 master라고 말하면, 당연하다는 듯이 Ph.D 할꺼지? 라고 물어보는게 아주 nice to meet you보다 뻔한 질문이 되었다. 그만큼 master 과정으로 참여하는 것이 쉬운 기회는 아닌데 좋은 기회를 얻어서 갈 수 있었던 거 같다. 또한, 학회에 참석한 모든 학생들이 굉장히 친절했던 것이 기억이 남는다. 항상 먼적 말을 걸어주고, 얘기를 들을 때도 할 때도 신나하는 게 보여서 나도 덩달아 굉장히 즐거웠었다. 학술적으로도 개인적으로도 많이 성장할 수 있는 기회였다.


CNSM 2023 학회 회고록


## Intro

SDN Lullaby는 SDN/NFV 환경에서 효율적인 VNF 배치에 관하여 작성한 논문이다. 이 논문에서는 VNF 배치 문제를 DRL을 이용하여 해결하였다. 이를 위해서, 해당 논문에서는 상용 Cloud Data Center에서 주로 사용되던 VM Consolidation 방식을 활용하였고, 이 과정에서 추가적인 구현을 더해서 VNF 배치 문제를 해결하였다. 해당 Posting에서는 이를 구현 및 작성하는 과정에서 겪은 문제를 기반으로 한 회고록이다.

## Description

우선 해당 프로젝트를 통해서 해결하고자 했던 문제부터 정의하자면, 간단하게 SDN/NFV 환경에서 수 많은 VNF가 Virtual Machine(VM)의 형태로 존재하게 되는데 이를 Network Performance와 Energy Efficiency를 모두 고려하여 효율적으로 배치하는 것이 굉장히 어렵고, Rule based 방식으로는 한계가 있는 NP-Hard 문제라는 것이다. 이를 해결하기 위해서 해당 논문에서는 DRL 방식 중에서 PPO를 활용한 해결책을 제시하였고, 성능은 Rule based 방식보다 System Load가 낮은 경우에는 더 성능이 좋았지만, 높은 경우는 오히려 성능이 떨어졌다.

자세한 설명은 `CNSM 2023` 에 오늘(2023/07/11) 제출하였기 때문에 결과가 나오면 추가로 업데이트하도록 하겠다. 일단은 구현에 대한 모든 내용은 Github [SDN Lullaby](https://github.com/euidong/sdn-lullaby)에서 볼 수 있다.

## Process

해당 프로젝트의 시작은 연구실에서 진행 중인 프로젝트 중 외국인 학생에게 할당되어있던 파트가 통채로 나에게 넘어오면서 시작된다. 프로젝트를 이어 받아서 유지, 보수하는 것으로 얘기가 되고 있었는데 사실상 구현이 거의 되어있지 않다는 것을 알게 되었다. 결국 그 학생은 이미 떠나갔고, 결국 나는 이를 처음부터 구현해야하는 상황에 놓여졌다. 이것이 4월 20일 나에게 주어진 미션이였다.

우선 큰 흐름에서는 기존 외국인 학생이 제시한 방향인 강화학습을 활용한 VM Consolidation으로 가닥을 잡았다. 하지만, 실제 요구사항에 대한 정의가 애매했기에 이 부분은 랩미팅과 기존 자료들을 통해서 얻을 수 있었다.

초기에는 여러 다른 논문을 찾아보면서, 어떤 구현이 가장 타당한지에 대한 조사를 진행하였다. 이 과정에서 VM Consolidation은 **Server Selection**, **VM Selection**, **VM Placement** 3단계로 나누어진다는 것을 알게 되었다. 즉, 어떤 서버에서 VM을 옮길지를 먼저 선택한 후에 해당 Server에서 어떤 VM을 선택할지를 결정한 후, 마지막으로 해당 VM을 어느 Server로 옮길지를 결정하는 것이다. 하지만, 해당 논문들을 읽으면서 든 생각은 왜 첫 번째 단계인 **Server Selection**이 왜 필요한가였다. 사실 결론적으로 원하는 것은 VM을 선택하고자 하는 것다. 즉, Server Selection은 선택하고자 하는 VM을 제한하는 역할을 수행한다. 이는 잘못된 추론을 하는 경우에 명백하게 편향적인 선택이 될 수 밖에 없다. 따라서, 해당 프로젝트에서는 과감하게 해당 단계를 생략하고 두 단계로 진행하는 것을 목표로 하였다. (**VM Selection**, **VM Placement**)
또한, 알고리즘을 선택하는 과정에서는 처음에는 강화학습 중에서도 기본적인 SARSA, Q-Learning을 적용하여 해당 문제를 푸는 것을 목표로 하였다. 하지만, Server의 상태(State)를 강화학습의 Input으로 주는 과정에서 문제가 발생했다. Input으로 전달해야할 정보는 Server의 상태, VM의 상태, 전체 Server를 포함하는 Edge의 상태 등이 있었는데 이를 모두 하나의 State로 정의하는데에는 한계가 있었기 때문이다. 이는 VM의 수와 Server의 수가 늘어남에 따라 제곱으로 State와 Action의 갯수가 늘어나기 때문에 이를 모두 하나의 Table로 표현하는 단순한 SARSA, Q-Learning으로는 한계가 있다는 것을 깨달았다. 따라서, 이를 해결하기 위해서 두 가지 선택지 중에서 하나를 골라야했다.

1. State를 압축할 수 있는 방법을 찾는다.
2. Deep Learning을 적용하여, Table을 Network로 추정하자.

랩미팅 과정에서 교수님은 1번을 강조하셨다. State를 압축할 수 있는 방법을 찾는다. 굉장히 간단한 알고리즘만으로도 해결이 가능할 것이라고 얘기하셨다. 하지만, 초기에는 이에 대한 감을 잡지 못했기 때문에 결론적으로는 2번을 선택했다. 사실 State가 많아진다면, 간단한 DQN(Deep Q Network)만 활요하더라도 어느정도 성능을 챙길 수 있을 것이라고 생각했고, State를 압축할 방법이 당시로서는 생각하기 어려웠다.

따라서, DQN을 활용하여 문제를 해결하는 것을 바로 시도하였다. 여기서도 결국 문제에 부딪히게 된다. 바로 State를 모두 활용하는 것까지는 좋은데 Output의 크기가 계속 변화하면 어떻게 할 것인지에 대한 문제를 해결할 수 없었다. 즉, 우리가 원하는 VM Consolidation은 결국 어떤 VM을 어떤 Server로 옮길지를 결정해야 한다. 그렇다면, 매 사건마다 Server와 VM의 갯수가 달라질 수가 있다는 것이다. 일반적으로는 Server의 갯수가 변화하는 일은 흔치 않지만, VM은 매번 바뀔 것이다. 따라서, 우리가 고를 VM의 갯수를 해당 System에서는 Input State가 주어지기 전까지는 알 수 없기 때문에 Deep Learning Model의 Output의 크기를 알 수가 없다는 것이다. 즉, Input과 Output의 크기를 정해놓고 시작하는 일반적인 Deep Learning Model로는 한계가 있다는 것이다. 이를 해결하기 위해서 결국 RNN을 활용하기로 결정한다. 즉, RNN에 Input으로 주어지는 데이터가 (Batch size, Sequence length, Input size)의 형태로 주어졌을 때, output의 형태는 (Batch size, Sequence length, Output size)와 같다. 여기서 Sequence length는 변화하지 않는데, 내가 하고자 하는 작업이 사실은 VM/Server의 정보가 주어졌을 때, 하나의 VM/Server를 선택하는 일이기 때문에 VM/Server의 수만큼 Sequence를 만들고, 여기서 나오는 Output size를 1로 고정한다면, 결국 어떤 크기의 VM/Server 수가 들어오더라도 그만큼의 Output을 보장받을 수 있었다. 따라서, 이를 활용해서 초기에는 LSTM에 기반한 DQN 모델을 구현하였다. 여기서 RNN(LSTM을 포함한)은 사실 Sequence를 거치면서 값을 누적하기 때문에, 우리의 원래 의도랑은 다르게 어느 위치에 Input 데이터를 넣느냐가 영향을 미칠 것이라는 것을 생각해서 이를 완화시키기 위해서 Bi-Direction으로 LSTM을 구성하였다. 이렇게 구성한 모델은 아래와 같다.

![sdn-lullaby-arch-1](/images/sdn-lullaby-arch-1.png)

이를 실험하기 위해서, Emulation 환경도 구현을 해서 실험을 한 결과 서버 4개 정도에서 정상적으로 Consolidation이 진행되는 것을 확인했다. 하지만, 실제로 서버 갯수가 8개를 넘기자 전체적으로 성능이 떨어지는 것을 관측했다. 또한, 학습 과정에서 VM의 갯수가 Episode마다 유동적으로 변화하기 때문에 Batch 단위의 학습을 하기 위해서, Memory에 저장하는 과정에서 Episode Length마다 별도의 공간에 따로 저장하였다. 그리고, 학습을 진행할 때에는 Random하게 Length를 하나 선택해서 Episode를 추출했는데, 어떤 Length를 선택하냐에 따라서도 값의 변화가 크기 때문에 이 구조가 variance를 더 크게 할 것이라는 결론에 도달했다. 따라서, 이 문제를 해결하기 위해서 다음과 같은 해결책을 생각했다.

1. Self Attention 구조 적용(LSTM -> Self Attention)
2. Zero Padding 추가

앞 서 제시했던 Bi Direction을 활요한 LSTM은 설계 자체가 Hidden Value를 순서대로 추출해나가면서 이득을 취하는 것인데 해당 구조에서는 각 요소의 특징을 입력으로 받아서 어떤 요소를 선택할지에 관한 문제이기 때문에 Self Attention 구조가 더 적절하다는 판단을 했다. 또한, zero padding을 추가하여 모든 데이터를 한 번에 저장하였다. 또한, 추가적으로 불가능한 Action의 선택을 방지하기 위해서 추가적인 preprocessing을 추가하였다. 즉, 옮길 수 있는 서버가 없는 VM인 경우, 선택한 VM을 옮길 수 없는 경우는 미리 filtering을 수행하여 해당 데이터를 zero 로 marking하였다. 이를 통해서, 불가능한 Action을 선택하는 것을 방지하였다. 따라서, 이를 반영하여 변경된 구조는 다음과 같다.

![sdn-lullaby-arch-2](/images/sdn-lullaby-arch-2.png)

하지만, 전체적인 성능 개선이 이루어지지 않았고, 따라서 이를 해결하기 위해서 `AlphaStar`라는 논문을 참고하였다. 해당 구조에서는 아래와 같은 구조를 보여준다.

![alphastar](/images/alphastar.jpeg)

여기서는 Encoding Layer를 두고, 이후에 LSTM을 통해서 Sequence 정보를 입력받고, 후에 이를 기반으로 Action을 선택하는 구조를 갖고 있다. 또한, 여기서 특정 Unit을 선택하기 위해서 Self Attention과 Attention을 혼합하여 사용하는 것을 보고 내가 위에서 VM/Server Selection에 Attention Mechanism을 사용하는 것이 일반적인 해결책이라는 것을 알게 되었다. 어쨌든, 이름 참고하여 다음과 같은 구조를 구현했다. 여기서는 DQN이 아닌 PPO를 적용하였다.

![sdn-lullaby-arch-3](/images/sdn-lullaby-arch-3.png)

해당 구조를 통한 실험 역시 실행하였지만, 전체적인 성능 역시 변화하지 않았다. 그래서 결론적으로 최종적으로 두 가지 구조를 변형하여 구현을 마무리하였다. 먼저, 기존 DQN 구조에서 input layer를 추가하여 PPO 구조로 변경하는 것, 그리고 불가능한 Action에 대한 filtering을 preprocessing이 아닌 postprocessing으로 수행하는 것이다. Preprocessing을 수행하는 경우에는 결론적으로 정보의 손실이 발생하게 되는데 이로 인한 손해를 보지말고 차라리 최종 선택 단계에서 불가능한 Action을 선택할 확률을 0이 되도록 postprocessing하는 방식으로 변경하였다. 따라서, 최종 구조는 다음과 같다.

![sdn-lullaby-arch-4](/images/sdn-lullaby-arch-4.png)

해당 최종 구조를 통해서 결론적으로 에너지 효율성과 네트워크 처리 능력까지 향상하는 결과를 얻을 수 있었다. (이는 논문과 Github에 업로드된 자료를 확인하도록 하자.)

## Opinion

결론적으로 나의 첫 번째 Full Paper 논문이 였기에 아쉬움도 많이 남지만, 애착도 그만큼이나 남을 것으로 생각하고 있다. 먼저 총평을 하자면, 나름 만족할만한 프로젝트였다고 생각한다. 우선 랩 미팅마다 매주 progress를 발표하고, 논의하는 과정 자체가 굉장히 유의미했다고 생각한다. 그 때 작성한 자료들이 지금 작성하고 있는 글 그리고 얼마 전에 제출한 논문을 작성하는데 많은 도움을 주었다. 따라서, progress를 주 단위나 작업 단위로 정리하는 것은 굉장히 중요하다는 것을 다시 한 번 느꼈다. 그리고, 실제로 Deep Learning과 Reinforcement Learning을 활용하여 Project를 직접 구현한 것은 이번이 처음이기 때문에 굉장히 많은 걱정을 하였는데 많은 사람들의 도움을 받고 여러 책곽 논문의 도움을 받아서 결국 성공적으로 마무리했다는 것이 중요한 경험으로 남을 거 같다. 또한, 문제를 정의하는 것이 가장 중요하고, 여러 논문을 찾는 사전 준비 단계가 반 이상이라는 것을 깨달았다. 이 과정이 탄탄해야 막힘없이 진행이 가능한데 이를 초기에는 간과한 거 같아서 앞으로는 초반 준비 단계에서 자료 찾고 읽는 것에 굉장히 집중해야겠다는 생각이 들었다. 그리고, 구현하는 과정에서도 관련 자료가 있으면 계속해서 읽어보는 것이 전체적인 구현의 질을 높일 수 있다는 것을 다시 한 번 상기할 수 있는 기회였다.

해당 프로젝트를 하면서, 만족했던 점은 다음과 같다.

1. 이때까지 프로젝트를 진행하면서, 내가 항상 가지는 마인드는 "어떠한 판단을 하였다면, 이에 대한 근거를 항상 제시할 수 있어야 한다." 였는데 이는 해당 프로젝트에서는 꽤나 잘 지켜진 거 같아서 만족한다.
2. 정리를 굉장히 잘 해두었다. 발표 자료 및 자료 조사 내용 정리를 굉장히 잘 해두었고, 이를 통해서 논문 작성에도 큰 도움을 받았다.

아쉬웠던 점은 다음과 같다.

1. DRL은 처음 적용하다보니 여러 알고리즘을 실험해보고 싶었는데 결과적으로는 DQN, PPO 밖에 적용하지 못했다.
2. 실험 결과를 내는 과정에서 시간이 굉장히 오래 걸렸다. 이는 실험을 진행하면서, 여러가지 문제가 발생했기 때문인데 이를 미리 예측하고 대비하지 못한 것이 아쉽다.
3. 최종 구현의 Performance에 미련이 남는다. 결론적으로는 Baseline 시스템과 비교했을 때, 조금 좋은 부분이 있고, 어떤 부분에서는 매우 뒤떨어지기도 하는데 이에 대해서 General한 성능 향상이 있었다면 더 좋았겠다는 생각이 든다.

## Reference

- For Thumbnail: <a href="https://www.flaticon.com/free-icons/lullaby" title="lullaby icons">Lullaby icons created by Freepik Flaticon</a>
- For Thumbnail: <a href="https://www.flaticon.com/free-icons/data-server" title="data server icons">Data server icons created by The Chohans Brand - Flaticon</a>
- Arulkumaran, Kai, Antoine Cully, and Julian Togelius. "Alphastar: An evolutionary computation perspective." Proceedings of the genetic and evolutionary computation conference companion. 2019.


SDN Lullaby


## Intro

해당 포스팅은 블로그를 직접 만드는 과정에서 겪은 시행착오를 정리한 내용이다.

나의 블로그 포스팅을 향한 일대기는 2019년도에서 부터 시작된다.

## JSP / Servlet

2019년도에 군대를 막 전역하고, 학점을 잘 챙기면서 여러가지 행사에 참여했다. 그 과정에서 기술 블로그를 제작하겠다는 꿈을 꾸고 작업에 착수한다.
그 당시에는 JSP와 Servlet을 이용한 방법을 통해서 Posting하는 것을 시도했다.

github : [euidong/blog](https://github.com/euidong/blog)

해당 방식은 markdown file을 그대로 가져와서 rendering하여 만들었다. 하지만, jar file을 실행해야 한다. 따라서, JAVA Virtual Machine이 필요하기에 결론적으로 이를 호스팅할 machine이 필요하다. 따라서, AWS free tier를 이용해서 배포했지만, 다소 배포 관리가 귀찮고, 당시에는 frontend & backend 등 아직 개념이 제대로 스지 않았기 대문에 중간에 포스팅을 조기 종료했다.

결국 JSP + Servlet을 이용한 시도는 종료된다.

## Gatsby

후에 2021년도 1월에 다시 새롭게 블로그를 쓰겠다는 포부를 갖고, 블로그 작성 방법을 찾는다. 당시에는 React를 이용해서 다수의 Application을 제작해본 경험이 있었기 때문에 이를 이용한 Blog를 만들려고 했다. 자세히 기억은 안나는데 Gatsby Showcase에 있는 source code를 이용해서 Blog를 제작했다. 하지만, Gatsby에 대해 아는게 없고, 시간을 쓸 여유가 없어서 결국에는 중도에 멈춘다. 추가적으로 Github action으로 CI/CD 구현을 수행하는 작업까지도 진행하였다. 하지만 결국 제대로 진행된 것 없이 종료되었다.

github : [euidong/euidong.github.io/dev@deprecated](https://github.com/euidong/euidong.github.io/tree/dev%40deprecated)

## Tistory

2021년도 3월에 결국 직접 제작을 하는 것을 포기하고, Tistory를 이용해서 블로그에 포스팅을 시작한다. 해당 시기부터 시작해서 몇 개의 포스팅을 작성하였다. 대략 35개 정도의 포스팅을 작성했고, 최근에 이르러서 작성의 한계를 느끼며 갈아타야겠다고 생각했다.

다음은 직접 커스텀을 해야겠다고 생각했던 이유이다.

1. 호환성이 떨어진다. => Markdown으로 변환도 가능하지만, Github와 완벽한 호환이 안된다.
2. 가끔 모바일에서 문자가 깨진다. => 아마 MAC으로 작성하는 경우 문자가 깨지는 것 같다. 근데, 이를 매번 모바일로 켜서 확인하기에는 너무 번거롭다.
3. 커스텀을 할 때 다른 Library를 맘대로 가져와서 쓸 수 있지만, pure js, jquery 기반으로만 가능하고, 유지보수가 쉽지 않다.
4. 가끔 작성 결과가 너무 예측 불가능하다.
5. tag 관리가 불편하다.
6. 기본 UI가 안이쁘다.

몇 가지 이유가 더 있었던 거 같은데, 아마 이정도가 문제였던 거 같다. 암튼 내가 관리하지 못하는 것으로 인한 스트레스가 있었기 때문에 이를 해결하기 위해서 완전 커스텀을 다시 결정하였다.

tistory: [justlog](https://justlog.tistory.com)

## 완전 커스텀

### 생 React

처음에는 생 React를 통해서 Blog를 만들어야겠다고 생각했다. 가장 일반적으로 할 수 있는 작업이고, 다른 static page generating 기능을 수행하는 react framework를 다시 공부하는 workload를 지고 싶지 않았고, 굳이 필요하지 않은 의존성을 만들고 싶지 않아서 결국 생 React로 바로 작업을 시작한다.

당시에는 Tistory에서 한계를 느꼈던 부분을 고치면서, Tistory에서 갖고 싶었던 장점을 가져가고자 했다.

1. 호환성이 떨어지던 점은 Markdown을 이용해서 작성하고, Github viewer style(GFM, Github Flavor Markdown)을 사용하기로 한다. 따라서, 해당 블로그의 모든 글을 Github에 올려도 이미지 경로 빼고는 매우 잘 작동할 것이다. (이는 후에 이미지 호스팅 CDN을 따로 설정하면 해결됨.)
2. Tistory에서 장점이라고 생각했던, Category로 작성글을 묶고, Tag들로 다시 한 번 더 분류한다.
3. Posting을 보기 쉽게 정리되어있어야 한다.
4. Dark Mode를 지원해야 한다.
5. 조회수 관리를 위해서 Google Analytics 설정을 해야한다.
6. 구글 / 네이버 검색에 노출되어야 한다.
7. 광고를 게시할 수 있어야 한다.
8. Github에 Push하는 것만으로 Posting이 게시될 수 있어야 한다. (Github Action)
9. Category와 Tag들은 Markdown안에 작성하지만, 이를 조회할 수 있어야 한다. 따라서, code를 build할 때 json으로 generating 할 수 있는 로직을 설계한다.
10. UI는 최대한 Simple 하고 깔끔하게 만드는 것을 목표로 하였다.

따라서, 모든 Button 부터 모든 UI를 직접 제작(여타 디자인 사용 x - material, ant 등)하고, Routing 설정하고, 작업을 모두 마무리한다.

여기까지는 모든 작업이 순조롭게 진행되고, 마무리가 되었다. 하지만, SEO(검색 엔진 최적화) 작업을 진행하면서, 결국 static page가 필요함을 깨닫는다. 왜냐하면, 기존의 React Router를 사용하게 되면, <https://euidong.github.io/posts/dfs1> 를 찾을 수가 없다. 왜냐하면, github에서는 page를 직접 접근할 때에는 배포 branch에서 해당 파일을 찾게 되는데 해당 파일이 없으면 결국 404 Not Found를 노출하게 된다. 이를 해결하기 위해서, dummy redirect로 root로 돌려보내줄 수도 있지만, 결코 좋은 방법은 아니다. 검색엔진 최적화에도 좋지 못하다. 따라서, static file을 각 각의 url마다 생성해주는 Static Page Generating이 필요하다고 느낀다. 따라서, Gatsby와 NextJS 중에서 선택을 하기로 한다.

이제 추가된 요구사항은 다음과 같다.

1. 기존 코드를 그대로 활용할 수 있어야 한다.
2. Static Page Generating을 지원해야 한다.

github : [euidong/euidong.github.io/dev@pure-react](https://github.com/euidong/euidong.github.io/tree/dev%40pure-react)

### 다시 Gatsby

다시 돌아와 Gatsby를 시도하기로 한다. 애초에 GraphQL과 React 모두 경험이 있기 때문에 쉽게 할 수 있을 거라고 생각했다. 하지만, 생각보다 GraphQL Query의 제한점이 많아서 결국 Gatsby는 포기하기로 한다. 물론 Gatsby의 확장 도구들은 유용했지만 위에서 제시한 9번을 구현하기에 한계를 느꼈다. (내 딴에는 GraphQL로 만들고 싶었는데 사실 포기하고 JSON으로 만들었으면 가능했을 듯하다.)

### NextJS

그래서 다음으로 시도한 것이 NextJS이다. NextJS는 생성 시에 내부 API를 정의하여 이를 기반으로 미리 compile을 완료한 html 파일들을 생성해두고, 제공하면서도, 그 내부에서는 SPA 처럼 동작할 수 있도록 돕는 방식이다. React를 이용한 Framework인 만큼 기존의 code를 그대로 사용할 수 있어서 쉽게 사용이 가능했다. 하지만, Gatsby와 마찬가지로 어느정도의 한계는 존재했기 때문에 결국은 react만 생성하던 방식처럼 JSON file을 generating하여 category와 tag들을 수집하였다.

그 결과 지금과 같은 형태의 블로그를 완성하였다. 현재 포스팅을 계속해서 진행할 예정이며, 광고 및 여타 설정들도 추가로 진행할 예정이다.

![blog-view](/images/blog.png)

github : [euidong/euidong.github.io/dev](https://github.com/euidong/euidong.github.io/tree/dev)

최종으로 만들어진 Blog는 다음과 같은 요구사항을 만족한다.

- [x] Markdown을 통해서 작성이 가능하고, 이는 DB 즉, BackEnd를 필요로 하지 않는다.
- [x] Category로 작성글을 묶고, Tag들로 다시 한 번 더 분류하는 것이 가능하다.
- [x] Dark Mode를 지원한다.
- [x] 조회수 관리를 위해서 Google Analytics를 사용한다.
- [x] 구글 / 네이버 검색에 노출되어있다.
- [x] 광고를 게시하였다.
- [x] Github에 Push하는 것만으로 Posting이 게시된다. (Github Action)
- [x] Build 시에 SEO에 필요한 sitemap을 자동 생성한다.
- [x] Theme는 Github의 color palette에 기반하여 설정하여, 친숙하다.
- [x] 모바일을 지원한다.
- [x] 이미지 크기를 재설정할 수 있는 command를 포함한다.
