안녕하세요. 오늘의집 DevOps Engineer 제제입니다.

오늘의집은 보다 안정적이고 빠른 확장을 위해 모놀리식 아키텍쳐에서 MSA로 전환을 시작했는데요. MSA 전환으로 달라지는 건 단순히 시스템 구조나 코드 개발의 방식뿐만이 아닙니다.

이번 편에서는 오늘의집 개발 조직이 MSA 환경에서 어떠한 DevOps 문화로 개발하고 운영하고 있으며 어떻게 구축해 발전시켜나가고 있는지 소개하려 합니다. 

DevOps가 왜 필요한가요?

DevOps에 대한 장황한 정의는 여기저기 많이 존재하지만 결국 DevOps란 서비스 개발자가 스스로 운영업무(배포, 관측, 대응)를 수행하는 문화입니다. 그렇다면 왜 개발자가 스스로 운영업무까지 할 수 있어야 할까요?

우리는 지금까지 MSA의 장점에 대해 많은 이야기를 해왔지만 MSA로의 전환에는 분명 단점도 존재합니다. 가장 크게 느껴지는 단점은 시스템의 복잡성이 올라간다는 것인데요. 앞으로 우리가 집중해서 관리해야 할 시스템은 더 이상 하나로 존재하는 것이 아니며 세분화된 서비스가 더 잘게 쪼개져 나가는 과정은 점점 더 빨라질 것입니다.

이런 상황에서 보다 안정적으로 운영하기 위해서는 해당 서비스의 개발자가 주체적으로 운영업무를 수행할 수 있어야 합니다.

그렇다면 DevOps Engineer는 왜 필요한가요?

DevOps가 개발자 스스로 운영업무를 하는 문화라면 개발과 인프라 운영 모두 뛰어나게 잘 할 수 있는 사람만을 채용해야 할까요? 서비스 개발만 하기에도 바쁜데 어떻게 시간을 더 내어서 운영업무까지 할 수 있을까요? 우리는 이런 문제를 해결하기 위해 존재합니다.

오늘의집의 DevOps Engineer는 개발자가 최소한의 공수로 운영업무를 수행할 수 있도록 운영 과정 중에 존재하는 비효율적인 모든 과정을 자동화합니다. 이를 통해 개발팀 전체에 DevOps 문화가 쉽게 정착할 수 있도록 하고 있는데요.

DevOps Engineer하면 떠오르는 자동화, 컨테이너, 쿠버네티스, CI/CD 파이프라인, 로깅 파이프라인 등 모든 툴과 방법론은 이러한 목적을 달성하기 위한 수단일 뿐 가장 중요한 것은 우리가 이 일을 하는 이유와 목적입니다.

오늘의집의 DevOps 문화

필요성과는 별개로 이러한 문화를 오늘의집 개발팀의 상황에 잘 맞게 정착시키는 것은 또 다른 문제였습니다. 지금부터는 저희가 DevOps 문화를 정착시키기 위해 사용한 툴과 방법론에 대해서 소개하겠습니다.

1. 쿠버네티스(Kubernetes)

<오늘의집 MSA Phase 1. 전환전략(클릭)>에서 언급했던 것처럼 쿠버네티스는 MSA 전환만을 위해 선택한 것은 아니었습니다.

쿠버네티스는 서비스의 배포와 운영에 필요한 모든 리소스를 YAML 형태로 표현할 수 있게 해 줍니다. 인프라의 구조나 동작방식을 모두 추상화하였기 때문에 정확한 동작방식을 이해하지는 못하더라도 필요한 리소스를 YAML로 표현해 우리가 원하는 정책과 형태로 서비스를 배포할 수 있게 해줍니다. 

즉, 쿠버네티스를 도입하고 이를 통해 인프라를 운영함으로써 개발자가 인프라 내부의 복잡한 동작 방식을 이해해야 하는 부담을 줄일 수 있습니다.

2. GitOps

GitOps란 형상관리 툴인 Git을 선언적 인프라 및 애플리케이션에 대한 단일 정보 소스로 사용하는 것을 의미합니다.

쿠버네티스가 인프라를 구성하는 리소스를 YAML로 표현할 수 있게 해주었지만 이 리소스가 운영 환경에 실제로 적용되어 있는지 어떻게 확신할 수 있을까요? 소수의 사람이 관리하는 인프라일 경우 커뮤니케이션만 잘 된다면 운영에 큰 문제가 없을 수 있습니다. 하지만 운영에 관여하는 사람이 많아진다면 현재 운영 환경을 지속적으로 관측해 정의한 대로 형상이 맞춰져 있는지, 형상이 맞지 않다면 어디가 다른지를 알려줄 수 있는 시스템이 필요합니다.

오늘의집은 ArgoCD라는 오픈소스 툴을 사용해 쿠버네티스에 올라가는 모든 애플리케이션과 인프라 툴을 GitOps 방법론으로 관리하고 있습니다. ArgoCD는 GitOps의 구현체일 뿐만 아니라 수려한 UI를 통해 쿠버네티스 오브젝트의 상태를 시각화함으로써 클러스터의 동작방식을 보다 쉽게 보여주는 역할도 톡톡히 하고 있습니다. 또한 ArgoCD를 통해 Multi-Cluster 인증을 해 서로 다른 클러스터를 한곳에서 관리할 수 있도록 하였습니다.

모든 리소스를 Git을 통해 관리하고 배포하기 때문에 개발자는 필요한 인프라를 스스로 정의하고 PR(Pull Request)을 통해 DevOps Engineer와 협업할 수 있습니다.

<오늘의집 MSA Phase 1. API Gateway(클릭)>에서 소개 했듯이 우리는 Gateway의 라우팅, 인증까지 모두 쿠버네티스 Object로 표현할 수 있도록 했기 때문에 Gateway의 라우팅룰 추가와 인증 또한 PR을 통해 리뷰를 진행합니다.

3. 바퀴를 다시 발명하지 말자

DevOps 문화의 전파는 전 세계 it 기업이 마주하고 있는 문제입니다. 보다 고도화된 자동화를 위해 많은 오픈소스 프로젝트가 개발되고 있고, 이러한 오픈소스 프로젝트의 발전 속도는 사내에서 사용하고 있는 툴의 개발보다 확실히 더 빠르고 체계적입니다. 따라서 우리는 필요한 기능을 직접 개발하기에 앞서 해당 기능을 제공하는 오픈소스 프로젝트를 먼저 찾아보고 검토하고는 합니다.

이때 명심해야 할 것은 오픈소스를 상용 시스템에 적용하는 것에는 많은 책임이 따른다는 것입니다. 특히 시스템의 중추적인 역할을 할 컴포넌트를 오픈소스로 적용할 예정이라면 해당 프로젝트에 문제가 있을 경우 직접 기여한다는 마음가짐으로 도입해야 합니다.

오늘의집은 오픈소스에 대한 기여를 장려하고 있기 때문에 오픈소스를 도입하는 것에 두려움이 없습니다.

오픈소스 도입을 위한 검증 및 기여에 대한 자세한 내용은 다음 기회에 다뤄보도록 하겠습니다. 😊

4. Ops Monster

물론 오픈소스만으로는 해결되지 않는 팀 내의 특정한 요구사항들이 존재할 수 있습니다. 또한 오픈소스 프로젝트는 매우 보편적인 UseCase에 맞춰 개발되기 때문에 사용자에게 더 많은 옵션을 요구하며 사용성을 해치기도 합니다.

그래서 오늘의집 DevOps팀에서는 오픈소스를 도입하되 해당 오픈소스를 사용하는 인터페이스는 자체 개발하고 있습니다. 이렇게 직접 구축한 인터페이스를 중간에 둠으로써 한 단계 더 추상화 하게되면 우리의 UseCase에는 사용할 일이 없는 불필요한 옵션을 제거할 수도 있고, Backend로 사용하는 오픈소스 프로젝트를 언제든 교체 할 수도 있습니다. 이같은 장점과 함께 추가적인 자동화로 보다 안전하고 쉬운 운영작업 환경을 제공 할 수 있습니다.

Ops Monster는 인프라 운영을 추상화한 인터페이스를 제공하기 위해 오늘의집이 직접 개발한 서비스입니다. 

개발자가 보다 편하게 운영 업무를 진행할 수 있게 하는 모든 자동화가 이뤄지고 있으며 제공되는 기능을 몇 가지만 나열해 보자면 다음과 같습니다.

• 개발자 스스로 인프라 권한 추가, 생성을 진행할 수 있습니다.
• MSA 구축 및 배포 관리 플랫폼 Mortar를 통해 프로젝트를 생성하면 프로젝트의 메타데이터가 자동으로 저장되고 관리됩니다.
• 배포 내역을 관리하고 타임라인을 보여줍니다.
• 마케팅 이벤트 일정을 관리하고 해당 일정에 맞춰 미리 늘려두어야 할 서비스를 정의합니다.
• API를 제공해 다른 툴과 통합될 수 있도록 합니다.

첫 시작은 Slack app으로 시작해 Slash Command로 인터페이스를 제공하다가 현재는 Web UI를 제공하고 있습니다. 오늘의집 서비스의 성장세에 맞게 인프라 구조 또한 빠르게 바뀌면서 운영 자동화 작업도 변경될 필요가 있었는데요. Ops Monster 서비스의 개발 및 발전기는 다음 기회에 소개해 드리도록 하겠습니다. 😊

5. CI/CD 파이프라인

MSA 전환에서 얻으려 하는 장점 중 하나는 분리된 작은 서비스의 잦은 배포입니다. 배포를 자주, 많이 할 수 있는 환경을 만들기 위해서는 자동화된 배포 파이프라인의 구축이 필수였습니다.

CI/CD 파이프라인 구축에 대한 논의가 처음 나온 시점에는 ‘DevOps Engineer가 모든 서비스의 파이프라인 초기 구축에 대한 역할을 가져가야 할까’하는 논의도 있었습니다. 하지만 서비스 개발팀이 커지는 속도에 비해 DevOps Engineer 수는 훨씬 적은 상황이었는데요. 무엇보다 각 개발팀의 자율성을 위해 CI/CD 파이프라인 구축은 개발자가 원하는 툴을 사용해 자동화를 진행하고, 이후 CD를 진행하기 위해 호출하는 API를 DevOps 팀에서 제공해 실제 배포가 수행될 수 있도록 하였습니다.

Github Action

파이프라인 구축을 위해 어떤 툴을 사용해도 상관없는 구조이지만, 현재 개발팀에서 중점적으로 사용 중인 파이프라인 러너는 Github Action입니다.

Github Action은 (비교적) 가독성 좋은 YAML로 파이프라인 스텝을 정의할 수 있어서 Github Action을 모르는 사람이 보더라도 어떤 작업이 어떻게 일어나고 있는지 쉽게 파악할 수 있고, Github과의 연동도 용이합니다.

개발자가 본인 스스로 또는 팀의 정책에 따라 파이프라인을 정의하고 원하는 자동화를 수행할 수 있어야 하므로 쉬운 접근성과 사용성이 선택에 있어 중요한 영향을 주었는데요. 

공통되는 작업은 묶어서 Custom Action을 제공해 보다 쉽게 파이프라인을 구성할 수 있게 했습니다.

대부분의 Custom Action은 Ops Monster에게 API를 날려주는 역할만 하게 되는데요. 실제 작업은 서버에서 이뤄지기 때문에 기존에 구성해둔 파이프라인 정의가 그대로 사용되더라도 서버의 업데이트에 따라 새로운 기능을 제공할 수 있게 됩니다.

마치며

앞서 소개해 드린 내용 중 전체 시스템에 ‘한 번에 짠’ 하고 적용된 사례는 단 하나도 없었습니다. 미래를 위해 필요한 큰 그림을 그리고 실행 가능한 작은 계획을 주기적으로 실행하며 적용해 나갔는데요. 그 과정에서 잦은 공지로 개발자 동료분들을 번거롭게 해드리기도 했습니다. 

(이 기회를 빌어 잦은 공지에 대한 사과와 함께 그럼에도 불구하고 항상 잘 반영해 주시고 따라와 주시는 팀원분들께 감사의 인사를 드립니다. 🙇‍♂️)

MSA 전환과 함께 DevOps 문화가 개발팀에 안정적으로 자리 잡기 까지는 많은 시간과 노력이 필요할 것이라고 생각합니다. 또한 이 긴 여정이 빠르게 변화하는 소프트웨어 개발 트렌드 때문에 계속 바뀔 수도 있겠죠. 😊

그럼에도 불구하고 DevOps팀은 기존의 운영 환경과 달라진 환경은 물론, 앞으로 변화할 환경에서도 최고의 DevOps 문화를 만들고 제공할 수 있도록 끊임없이 고민하고 실행해 나갈 것입니다. 

👨‍💻 오늘의집 개발팀을 더 자세히 알고 싶다면? (클릭)