안녕하세요 숨고의 DevOps Engineer Ray 입니다.
숨고에 합류하여 3개월이라는 시간이 정말 빠르게 지나간 것 같습니다.
현재는 온보딩 기간을 무사히 마치고 정식으로 숨고에 합류하게 되었는데요,
3개월이 지난 지금 숨고에 입사하여 DevOps Engineer로서 온보딩을 수행하면서 해결했던 일들과 느낀 점을 소개하며 제가 경험했던 내용들을 공유하는 시간을 가져보려고 합니다.
사소한 것이라도 자동화 해보기
온보딩이 시작되고 숨고에 대한 설명이 끝나갈 때쯤 저는 숨고의 계정을 관리하고 있었습니다.
계정을 발급하고 권한을 부여하는 작업이 어렵지 않은 일이지만, 한편으로는 불필요하게 반복된다는 생각이 있었습니다.
이러한 부분을 개선하는것을 첫번째 온보딩 미션으로 진행하게 되었습니다.
문제점
숨고는 AWS 계정을 발급 하더라도 MFA 디바이스를 등록해야만 AWS의 서비스를 이용할 수 있도록 되어있습니다.
하지만 이러한 조건을 구현 함에 있어서 불필요하게 반복되는 작업이 존재 했었습니다.
다음과 같이 신규 입사자가 들어왔을 경우 IAM 계정을 발급해 드리면서 IAM에 필요한 Group을 매핑하여 권한을 부여하도록 제공되고 있었습니다.
하지만 신규 유저가 MFA를 등록하고 나서 누군가는 NewUser라는 IAM Group을 제거해주어야만 비로소 서비스를 이용할 수 있게 되어있었습니다.
해결방안
AWS의 이벤트 버스를 활용하여 이전에 수동으로 NewUser라는 IAM Group을 제거하던 작업을 자동화 할 수 있었습니다.
개선된 프로세스는 다음과 같습니다.
MFA를 등록하게되면 AWS에 이벤트가 발생하게 되고, 해당 이벤트가 발생 되는지를 이벤트 버스에서 바라보고 있다가 이벤트가 발생하게 되면 Lambda 함수를 호출하는 구조로 변경을 하였습니다.
Lambda 함수로 작성된 코드를 통해 MFA를 등록한 유저의 IAM Group을 제거하도록 함으로서 수동으로 제거해주어야만 했던 불필요한 작업들을 자동화 할 수 있었습니다.
숨고의 인프라 파악하기
DevOps Engineer로 일을하게 되면서 숨고의 전반적인 인프라와 서비스 들에 대해서 파악을 해야했고,
이를 위한 경험으로 새로운 개발환경을 직접 구축해보고, 팀에서 필요로 하는 기능인 새로운 개발환경 생성과 삭제에 대한 자동화를 만들어내는것을 두번째 온보딩 미션으로 진행하게 되었습니다.
문제점
숨고는 운영과 Staging환경 이외에도 QA, Test등 개발을 위한 여러 환경들이 존재합니다. 따라서 새로운 개발환경을 구축을 하는 작업이 발생할 경우 매번 반복되는 작업을 수행하게 됨으로서 구축하는데 시간적 비용이 발생하게 됩니다.
해결방안
인프라에 대한 형상을 코드로 관리(IaC)하여 형상을 관리하도록하고, 생성과 삭제가 편리하도록 하고, 서비스들에 대한 형상또한 GitOps (숨고에서는 ArgoCD 사용하고 있습니다.)를 활용하여 배포하도록 합니다.
이러한 과정들을 파이프라인을 통해서 수행되도록 합니다.
위의 그림처럼 Pulumi를 이용하여 IaC를 구성하고, 파이프라인을 수행하여 숨고의 개발환경 구성을 위한 서비스 들을 프로비저닝 하게 되도록 구성하였습니다.
이번 경험을 통해서 인프라를 구성하기 위해서 기존 숨고의 인프라를 참고하고, 개발환경에 필요한 서비스들에 대해서 파악하면 두 번째 온보딩의 목적인 숨고의 환경에 대한 이해도를 높일 수 있었던 시간이 되었습니다.
하나 아쉬운 점이 있다면 현재는 Pulumi 명령어를 수동으로 실행하여 인프라를 구성 후 파이프라인을 실행하도록 하는 완전한 자동화는 아니지만, 추후에 IaC에 대한 테스트를 고려하여 완전한 자동화가 될 수 있도록 개선해보려고 합니다.
주도적으로 업무 진행해보기
마지막으로 DevOps Engineer로 팀에서 일하는 것 처럼 주도적으로 필요하거나 개선해야할 기능들을 찾아 진행해보는 것을마지막 온보딩 미션으로 진행하게 되었습니다.
온보딩을 진행하면서 AWS ECR의 이미지의 태깅 정책으로 인하여 종종 테스트 환경에서 사용 되는 이미지 태그가 유실 되는 문제가 있다는것을 확인하고, 개선하는 작업을 마지막 온보딩 미션으로 진행하게 되었습니다.
Docker 이미지 태깅 정책 수립
그동안 온보딩을 진행하면서 ECR 레포지토리의 이미지의 라이프사이클 정책으로 인하여 종종 테스트 환경에서 사용되는 이미지 태그가 유실되는 문제가 있다는 것을 확인하였고, 이를 개선하는 작업을 수행하게 되었습니다.
문제점
숨고에서는 하나의 서비스 해당하는 컨테이너를 구동하는 방식에 따라서 서비스의 형태(API, Task, Cron)가 달라졌습니다.
그렇다보니 모든 이미지는 각 서비스별로 하나의 ECR 레포지토리로 관리되고 있었는데요,
이와 같이 운영되다보니 배포주기가 많지 않은 서비스들에 대해서 ECR의 라이프라이클 정책에 인해 이미지 보존순위가 후순위로 밀려 개발환경에서 사용 되고 있지만 이미지가 사라지는 문제가 종종 발생하고 있었습니다.
해결방안
이를 해결하는 가장 간단한 방법은 ECR 라이프라이클을 수정하여 보존하는 양을 늘리는 방법이 있지만 비용적인 측면과 근본적인 문제의 해결책은 아니라고 판단하였습니다.
또한 각 서비스의 형태에 맞게 레포지토리를 늘리는것에 대한 고민 또한 해보았지만 관리해야할 레포지토리가 많아 진다고 판단하여, 새로운 ECR의 태깅 정책과 라이프 사이클 정책을 수립하고 그에 따른 파이프라인 변경을 통해 해결하고자 했습니다.
변경된 이미지 태깅 정책은 다음과 같습니다.
- 기존 soomgo/{서비스 이름}-{배포 환경}
- 개선 soomgo/{서비스 이름}-{서비스 형태}-{배포 환경}
각 서비스의 형태를 기준으로 태깅을 하도록 변경하였고, 변경된 태깅정책에 맞게 ECR 라이프 사이클 정책을 변경하여 보다 세밀하게 관리되도록 하여 유실되는것을 막고자 하였습니다.
파이프라인 리팩토링
이미지의 태깅 정책이 변경됨에 따라 파이프라인에서 이미지 빌드 시 변경된 태깅 정책으로 태깅이 되도록 파이프라인을 변경하는일만 남았지만, 파이프라인에서 또하나의 문제점을 발견하게 되었습니다.
문제점
파이프라인에 영향이 있는 작업이 생길 경우 모든 파이프라인의 코드를 변경해야 하는일이 생겼습니다.
하고자하는 CI/CD는 동일한데 서비스별로 조금씩 다른형태의 코드를 취하는 경우가 존재하였고, 이로인해 불필요하게 반복되는 코드들이 존재했습니다.
해결방안
Bitbucket Pipeline의 Pipe활용하여 관리를 한곳에서 하는것과 동시에 파이프라인의 각 Step에서 사용 되는 공통적으로 사용 되는 기능들의 통합하여 해결하고자 했습니다.
각 Step마다 사용되는 코드들은 파이프라인을 위한 프로젝트로 통합 후 각 Step 별 Docker Image로 따로 관리될 수 있게 하였고, Bitbucket의 Pipe를 이용하여 각 Step에 맞는 Docker Image를 컨테이너로 실행함으로써 각 Step에 맞는 기능을 수행할 수 있도록 하였습니다.
이번 경험을 통해서 단순히 기존의 문제점을 해결하는 것 뿐만 아닌 추가로 파이프라인을 이용하시는 숨고의 개발자분들이 더욱 편하게 구성하고 사용할 수 있도록 고민하는 시간도 가질 수 있었던 것 같습니다.
또한 결과적으로 기존의 파이프라인의 Step과 수행해야 하는 기능들은 유지하면서 반복되는 코드를 줄일 수 있었고, 파이프라인의 기능 변경에 따른 반복 작업을 줄일 수 있어 많이 뿌듯한 작업이 되었던 걸로 기억하고 있습니다.
온보딩을 마치면서
돌이켜보면 입사에 대한 기대감만큼 걱정과 부담감을 느끼고 숨고에 합류하게 되었었던 것 같은데요,
다행히 숨고에서는 적응을 위한 온보딩 기간과 많은 도움을 주셨던 것 같습니다.
온보딩을 마무리하고 나서 느낀 점은 "신규입사자의 빠른 적응을 위한 많은 고민이 있었다." 인것 같습니다.
플랫폼 챕터 에서는 온보딩 기간의 목적 달성을 위해 주기적으로 고민을 같이 해주셨고, 위에서 소개드린것 처럼 빠른 업무 적응이라는 온보딩의 궁극적인 목적 달성을 위해 테마별로 미션을 수행할 수 있도록 하여, DevOps Engineer로 빠르게 적응할 수 있었던것 같습니다.
또한, 더 나은 조직과 개개인으로 성장하기 위한 고민과 노력을 하시는 분들과 함께 할 수 있다는점이 좋았습니다.
마지막으로 이 글이 현재 숨고에서 온보딩을 진행하고 계신 모든 분들과 숨고에 입사를 고민하고 계신 분들께 조금이나마 도움이 되었으면 합니다.
긴 글 읽어주셔서 감사합니다.
