시작하며

예상 독자는 인프라 전문 조직이 없는 개발자 또는 다른 회사의 인프라 이관기를 궁금해 하시는 모든 분들 입니다.

인프라 이관을 계획하며

입사 초기에 서비스에 대한 온보딩을 진행하며 팀이 향후 진행해야 할 과제 목록을 전달 받았던 적이 있습니다.

그 당시 먼 미래라고 생각했던 인프라 이관이라는 주제가 언급 되었을 때에는 재밌을 것 같고 흥미로웠던 주제였던 터라 욕심이 났었었죠.

이 복선은 훗날 제게 굉장히 큰 고통을 안겨주었지만 현재는 이런 업무를 맡기 위해 지금까지 공부를 해왔다고 생각이 들 정도로 뿌듯합니다.

클라우드 자원 이관을 위해 크게 3 가지 카테고리로 나누어 전체적인 이관 흐름을 정리 했었는데, 중점적으로 봤던 것은 현재 제공해주는 기능을 이관 후에도 그대로 사용할 수 있는 것인가? 에 대한 질문이었습니다.

우선 3번 자원을 가장 우선적으로 처리하기 시작했습니다. 인프라 이관의 데드라인은 정해져있지만 변하지 않는 일정을 효율적으로 쓰기 위해서는 타사와 계약해야 할 자원을 조사하여 협업을 해야 했기 때문이죠.

그 다음은 2번 자원들을 어떻게 대체할 것인지 논의하고, 신규 구축해야 한다면 구축하고 다른 서비스를 써야한다면 다른 서비스를 쓰도록 변경하는 작업을 진행 했죠.

마지막으로 1번 자원들은 사양을 파악하여 그대로 옮기기만 하면 되는 비교적 간단한 업무가 되었습니다. 이렇게 카테고리 분류의 역순으로 3 번부터 1번으로 진행하게 됩니다.

그 외에도 네트워크 구성을 위해 VPC 설계라든지 DNS 서버의 NS 이관이라든지 프로덕트에 집중했다면 알지 못하는 것들이 많았습니다.

초기에는 네트워크 구성을 개발 / 운영 두 개의 망으로 분리했다가 최종적으로 공유 망도 구성하고 네트워크 대역폭 설정을 위해 CIDR 블럭을 정리하여 엑셀로 정리하며 서비스를 지탱하는 부분들을 구성하고, VPN 도 구성하고 피어링 전략도 세웠죠.

이 때는 당일이 다가올수록 점점 야근이 잦고 새벽에 퇴근하는 일도 많아졌었는데, 이 시간을 어떻게 보상해야할지 하다가 PS5 를 구매 해버리고 무사히 끝낸다면 게임을 실컷하겠노라 다짐했던 기억이 있습니다.

이질감 없는 인프라 환경을 제공하기

사내 프라이빗 클라우드는 타사에서 제공해주는 플랫폼을 기반으로 동작하기 때문에 알게 모르게 뒤에서 제공해주는 것들이 굉장히 많았는데 그 중 대표적으로 CI/CD 가 있었고 이는 2 번에 해당 했죠.

최종적으로 구성된 자동화 배포 모델의 파이프라인은 아래 이미지 처럼 구성 되어있고, 보다시피 기술은 Jenkins, ArgoCD 로 구성 되었습니다.

이 기술을 선택하게 된 배경은 우선 기본적으로 Web UI 가 친절하게 제공 되어 처음 접하는 사람들도 배포가 가능해야 합니다. 왜냐면 지금까지 도구가 제공하는 UI 의 모습은 본 적 없고 잘 추상화 된 플랫폼이 제공하는 것들만 봐왔기 때문이죠.

그리고 우리는 표준과 근접해야 합니다. 이 표준이라 하면 커뮤니티가 활성화 되어 쉽게 자료를 찾아볼 수 있고 타사에서 구축한 경험이 많은 사례들을 이용해야 합니다.

그래서 위 기술을 선택하게 되었고 이를 뒷받침하는 GitOps 라는 전략도 같이 활용하게 됩니다.

이 당시 처음 접하는 기술들과 용어들의 향연이 저를 2주 가까이 괴롭히며 구축하는 데 스트레스를 많이 줬었고, 이 지식들을 얻기 위해 책도 사서 읽고 아티클도 정말 많이 읽었습니다.

그리고 이 자동화된 배포 모델을 잘 이용했으면 좋겠다는 마음에 문서도 많이 작성해서 공유하고, 세션도 열어서 데모도 선보였습니다.

그러다보니 기존에 썼던 도구와 동일하게 동작하는 현재 배포 환경을 경험하게 되고, 더 나은 경험을 제공하게 됩니다.

기존 배치 작업을 배포하기 위해서 “스크립트를 실행하는데 그 뒤에 인자를 어떻게 써야합니다.” 라는 가이드가 있었는데, 이제는 그럴 필요 없이 “우리는 작업 내용을 깃허브에 반영하면 알아서 돼요.” 가 되었어요.

이렇게 새로운 환경에서 제공하는 것들이 기존의 것을 잘 유지하면서 더 나은 경험을 제공할 수 있도록 이관 작업 내면에 숨어있었어요.

서비스를 중단하고 밤을 지새웠던 당일

계획했던 일들을 잘 준비하여 이관 당일 시나리오를 정리하여 팀 내에 공유가 되었고, 유관 부서에 협업 요청까지 완료 되었습니다.

이 날은 오후 2시에 출근하여 다음 날 오전 11시에 퇴근 했었던 기억이 있는데, 타임라인의 일부는 아래 이미지 처럼 구성 해두었고 자신이 수행해야 할 역할에 맞게 업무를 분담하여 완료되면 상태를 변경하는 구조였습니다.

걱정과 달리 굉장히 순조롭게 흘러갔고, 다행히 사전 작업들을 새벽같이 작업하며 열심히 했던 노력의 결실을 맺어 잘 마무리하게 되었습니다.

위 타임라인에 나와있듯이 서비스를 중단했던 단 7시간인 00:00 ~ 07:00 은 정말 짧게 느껴질정도로 순식간에 지나갔습니다.

다행히 릴리즈 환경에서 QA 를 잘 해놓은 덕분에 서비스가 정상적으로 오픈 되었을 때 운영 이슈가 들어온 건이 많지 않아, 팀원들이 출근 하는 시간에 간략하게 진행 상황을 공유하고 중점적으로 확인해야 할 부분들에 얘기를 나누고 끝났습니다.

새로운 환경에서 7월 한 달 동안 운영 해봤습니다

모처럼 이관 작업을 담당 했던 모두가 고생했던 것들을 잘 알아주는 팀 리더와 팀원들이 있었기 때문에 보람찼던 시간들을 보내기 바빴습니다.

이제 원래 회사원의 감정으로 돌아와 서비스를 운영하고 인프라 이관 당시 TODO 로 남겨두었던 작업들을 서로에게 할당하고 내실을 다지고 있었습니다.

그 중 레거시 버전을 사용하는 어플리케이션을 버전을 올리는 것과 불 필요한 자원을 통합하는 것이 있었고 이 작업들을 진행 하다가 우연히 마주친 불편함들을 개선해보기로 합니다.

첫 번째는 MSA 라는 이름으로 포장한 과도한 서비스 단위의 분리를 통합하려면 자연스레 다른 서비스 하나에 묻어나거나 멀티 모듈 환경으로 구성하는 방향이었어요. 이 과정을 진행 하다보면 현재 배포 모델의 GitOps 전략을 나름 잘 이해해야 합니다.

두 번째는 쿠버네티스 설정 정보를 바꾸다가 서비스의 셀렉터가 파드로 정상적인 트래픽을 보내지 못하여 장애가 발생하는 경우입니다. 이 때는 이 장애 상황이 두려워 아무도 건들지 못하는 상황이 됩니다.

프로덕트 담당자는 플랫폼에 대해 어디까지 알아야할까?

이제 제게는 이런 질문이 자연스레 따라오게 됩니다.

“프로덕트를 구성하는 서버 스펙은 그래도 애플리케이션 관리하는 곳에서 설정하면 프로덕트 담당자 범위에서 컨트롤이 가능하니 편할테고, 외부 도메인이 필요하면 어떻게 처리 해야하지?”

그토록 현재 배포 모델을 잘 사용하기 위해 문서화도 하고 공유를 했음에도 불구하고 특정 작업을 진행할 때에는 저와 같이 살펴봐야 했고, 잘 됐는지 검증도 같이 했죠.

이 때 Helm 차트 템플릿에 구조 개선 작업을 진행하고 있었는데, 마침 잘 됐다 싶어 최소한의 기능을 제공하는 추상화 된 플랫폼을 제공해보는 것을 목표로 합니다.

이 당시는 당근 SRE 밋업 영상(변정훈님 발표) 과 카카오페이 증권이 기술 블로그에 작성한 내용 그리고 발표 영상을 모두 읽어보며 플랫폼 엔지니어링 조직이 없어도 구성원들이 자신의 역할에만 집중하도록 만들어보기로 결정합니다.

아직 개발중이지만 현재 이런 IDP 같은 것을 만들고 있고, 테스트 시나리오에 대한 데모를 한 번 진행 했습니다.

여기서는 굉장히 복잡했던 YAML 설정을 간단한 폼을 이용하여 작성하면 손 쉽게 구성할 수 있도록 하였고, 권한 제어가 상세하게 잘 되었다면 아마 리소스 생성까지 모두 제공 하면 좋았겠지만 현재는 아쉽게도 PR 을 생성 해주는 정도로 그쳐있습니다.

마치며

저는 현재 스타트업 백엔드 개발자로 근무하며 플랫폼과 프로덕트 어딘가에서 회사에 가치를 제공하고 있습니다.

당연히 플랫폼 엔지니어 조직이 있는 기업이 제공하는 수준은 못 미치더라도 흉내라도 내며 지내는데, 두 관점이 다르다는 것을 이번 계기로 알게 되었습니다.

백엔드 개발만을 하다보면 제가 알고 있는 지식 선에서 API 를 설계하고 프론트엔드 직군과 협업할 때 그 것을 당연시하게 설명하는 편인데, 그 사이에서도 나름의 관점 차이가 있으니 꼭 한 번 풀스택을 경험 해보면 새로운 시야를 얻을 수 있을 것이라고 팀 리더가 여럿 말해준 적 있습니다.

그 관점이 다르다라는 것을 인지하게 되는 순간 새로운 시야로 개발을 잘한다기 보다 정말 일을 잘 하는 회사원이 될 수 있다고 배우게 되는 시간이었습니다.