"인프라 올 인원" 프로젝트(쿠버네티스)

들어가면서 

지난 8개월 동안 여러 프로젝트를 진행하면서, 관리하게 된 인프라의 수가 기하급수적으로 늘고 있다. 문제는 그때마다 AWS에 있는 EC2를 이용해서 관리를 진행했는데, 프로젝트가 진행됨에 따라서 관리의 난이도가 기하급수적으로 높아진 것이다. 내가 42 내부에서만 관리하는 프로젝트만 해도 총 5가지인데, 아래와 같이 관리하고 있다.

 

42 내부에서 관리 중인 인프라

42 모글 - EC2, 서울 리전, T3.micro (링크)

평가지표 사이트 - EC2, 서울 리전, T3.small (링크)

42 베네핏 공식 사이트 - EC2, 파리 리전, T3.micro (링크)

42 공지 알람이, 개발자 구직 공고 알림이방(카톡, 슬렉) - EC2, 서울 리전, T3.micro (링크)

42 내부 공유우산 관리 사이트 - EC2, 서울 리전, T3.small (오픈준비 중)

 

문제는, 하나하나 다른 네트워크 정책과 보안 정책들 때문에 문제가 발생할 때마다 그때마다 설정을 다시 처음부터 확인해야 되는 어려움이 있었고, 또 내가 봤을 때 초기 EC2들은 내가 잘 모를 때 만든 것들이라 보안 취약점들도 있었다. 물론, 나중에 개선했지만 근본적인 문제는 아니라고 생각했고 늘 개선해야겠다는 마음만 품고 있었다.

또한, 42 내부 프로젝트의 경우 42 OAuth에 접근하기 위한 API Secret 키가 2주마다 갱신되는데, 그것을 캐치 업하기가 너무 까다로웠다. 그래서 조금 보안적인 열세를 두더라도 각각 VM에서 셀레니움을 이용해 키값 갱신이 가능하도록 만들어두었는데, 문제는 42 인프라 UI가 너무 자주 바뀐다는 것이다. UI가 바뀔 때마다 하나하나 VM에 들어가서 코드를 수정해 주는 것이 여간 힘든 일이 아니었다. 나중에는 Github에 수정된 코드를 올리고 Ansible을 이용해서 한 번에 해당 툴을 관리하는 방법을 썼지만, 이 또한 완벽한 해결법은 아니라고 생각했다.

 

그래서, 이 모든 문제를 한 번에 해결할 수 있는 방법인 쿠버네티스에 이 모든 인프라를 넣기로 했다.

쿠버네티스의 로고, 배의 조타 모양이다

---

쿠버네티스를 선택한 이유

가장 큰 이유로는 VM에 지쳐버렸다.. 대충 다뤄도 언제나 제 역할을 해주는 도커와 다르게, VM은 내가 세세하게 다뤄줘야 되는 것도 많고 유사 육아처럼 하나하나 챙겨줘야 되는 것에 지쳐버렸다. 프로젝트 때마다 VM에 들어가서 하나하나 설정해 주는 것에 지쳤고, 나중에는 골든 이미지를 기반으로 어느 정도 편안해지긴 했지만 그래도 개복치처럼 터져버릴 때는 정말 한숨만 나왔다.

 

또한, 트래픽이 몰리는 경우나 유사 상황에 대비하기가 너무 어려웠다. 특히, 오픈 날 이럴 때나 평가가 많은 날 수많은 새로고침은 micro가 가끔은 감당하기 힘든 트래픽을 만들어냈다. 때문에 백엔드 최적화와 프런트는 CDN으로 빼는 등 다양한 방법으로 문제를 해결해 냈으나, 사실 가장 좋은 방법은 쿠버네티스의 HPA와 같이 수평적 확장을 하는 것이다. 물론, EC2에 오토스케일링이 있지만 내가 해둔 투박한 설정들 때문에 사용하기가 쉽지 않았고, 결정적으로 로드밸런서 가격 때문에 포기했다. 

 

또, 로깅과 모니터링에서도 어려움을 겪었다. 특히, 로그가 서버마다 다르게 기록되다 보니까 보려면 하나하나 찾아봐야만 했고, 그 때문에 로그가 일정정도 쌓이면 S3에 넣는 방식으로 구성을 해두긴 했으나 이 또한 완벽한 해결방법은 아니었다. 또한, 모니터링도 EC2가 제공하는 모니터링 툴로는 내가 원하는 값들을 추산하기 어려웠고, 그렇다고 하나하나 모니터링 툴을 달기에는 일이 너무 많아질 것 같았다.

 

마지막으로는, Secret값 관리에도 지쳐버렸다. VM이 계속 늘어나니(지금 관리하는 VM에 9개이다) 처음에는 사소했지만, 점점 하기가 벅차왔다. 내가 서버관리만 하고 있으면 크게 상관이 없는데, 다른 공부들과 프로젝트와 병행하다 보니까 이제 이 Secret값 수정에서 해방되고 싶었다.

 

그래서 이런 문제들을 완벽하진 않지만, 꽤나 해결해 줄 수 있는 방법을 찾았고 최근 쿠버네티스를 깊이 있게 공부하다가 쿠버네티스를 이용하면 문제가 해결될 것이라고 판단해서 이 프로젝트를 기획했다.

---

쿠버네티스에게 기대하는 역할

1. 조금 더 편한 업데이트

업데이트할 때 직접 하나하나 해줘야 되는 것이 아닌, 혹은 프로젝트마다 다르게 CICD를 구축해야 되는 것이 아닌, 쿠버네티스가 제공하는 방식으로 업데이트를 하고 싶다. 특히, 롤링 업데이트와 그린/블루 배포 방식을 구성할 때 들어가는 품을 쿠버네티스를 이용해서 줄이고 싶은 것이 크다.

2. 오토 스케일링 및 에러핸들링

더 이상 내가 만들어놓은 VM의 AZ가 문제가 발생했을 경우를 가정하고 싶지 않다. 사실 잠시 서비스를 중단한다고 크리티컬 한 일이 발생하지는 않겠지만, 그런 경우의 수까지 고민해서 설계를 구성하는 것에 품을 그만 쓰고 싶다. 쿠버네티스를 이용하면 여러 AZ에 노드들을 두고 사용하고 문제가 발생하면 파드들을 알아서 띄워주니까 이런 걱정에서 해결될 것이라고 기대하고 있다.

3. 하나로 다하는 로드 밸런싱

로드 밸런서를 하나로 구성해서 여러 서비스에 모두 적용해보려고 한다. 사실 완전히 가능한지는 잘 모르겠다 아직 안 해봐서 그렇긴 하지만, 가능하다면 하나의 로드밸런서로 모든 서비스로 구성해볼까 한다. 내가 관리하고 있는 도메인이 지금 서브 도메인 포함해서 20개가 넘어가고 있는데, 하나의 엔드포인트로 설정해서 관리를 편하게 해보려고 한다. 

4. 이 외에도 여러 기능들

시크릿 관리나 내부 DNS를 이용한 편안한 관리 등등 여러가지가 있지만, 크게는 위의 3가지가 가장 크게 와닿는다. 근데 저 것들을 관리하는 품이 더 크지 않을까 생각할 수도 있다. 그래서 이번에는 그냥 관리형 쿠버네티스(내가 선택한 것은 EKS)를 이용하려고 한다.

---

앞으로의 계획

현재, EKS를 구현 내부에 있는 파드, 서비스들을 어떻게 구성할지 정하고 있다. 사실 쿠버네티스는 선언형 관리툴이라 '어떻게 해줘!'라고만 하면되지만, 안에 모니터링이나 로깅같은 부분을 어떻게 할지 그리고 리소스를 어떻게 분배할지를 고민하고 있다. 42재단으로부터 EKS 비용지원도 얻어내서 정말 극한의 효율화보다는 조금 여유가 있게 구성할 수 있게 되었지만, 각각 서비스에 들어오는 트래픽과 필요한 컴퓨팅 용량을 잘 계산해내서 구성해보려고 한다.

 

쿠버네티스의 간단한 세팅과 앞으로의 전략은 나왔다. 이제 기다려야되는 것은 내가 만들지 않은 서비스들의 컨테이너화다. 이것까지 마무리 되면 바로 컨테이너를 끼우고, 내가 만든 42API 시크릿 관리툴 그리고 그라파나 같은 모니터링 툴을 탑재해서 바로 서비스를 시작하려고 한다. 이 것이 마무리 되면, 이제 담당자가 졸업해버려서 사라지는 프로젝트는 없어질 것이고 또한 새로운 프로젝트를 준비하는 사람은 인프라는 고민하지 않고 컨테이너만으로도 서비스를 시작할 수 있게될 것이다.(야호!)

 

프로젝트를 하면서 시간 관계상 아직 시험을 보지는 못했지만, CKA를 따기위해 준비한 공부가 빛을 발하고 있다. 프로젝트까지 잘 마무리하고 CKA까지 따서 유종의 미를 거둬야겠다.