Devops 교육을 들으며 중간 정리
MAC notes 에다 모든 걸 적는 게 습관이 되다 보니 블로그 형식으로 내 생각을 담아 길게 정리할 기회가 없어서 교육의 절반을 넘은 시점에 써보고자 하여 글을 쓴다.
일단 교육 커리큘럼의 내용은 다음과 같다.
- Devops 문화 개론과 방법론, 목표 이해
- AWS에 배포에 관련된 거의 모든 서비스 및 CICD, IaC, 쿠버 네티스, 모니터링, 보안까지 스타트업에 들어가서 클라우드만으로 서비스를 운영한다면 사용할 모든 도구들
- 위 서비스 플로우를 종합하여 개발자들과 소통하기 위한 기본적인 DDD, Micro Service Architect, 개발경험이 없는 사람을 위한 초급 백엔드 및 메시지큐
나는 테라폼이나 AWS, 젠킨스, 백엔드, 메시지큐는 익숙했기 때문에 사실 콘셉트만 이해시키려고 간단하게 짚고 넘어갈 것처럼 보이는 이 강의를 고르는데 고민이 많았다. 하지만 그때그때 필요에 따라 외부의 요구 또는 내 필요에 따라 그냥 무작정 써댔던 내 위태한 과거를 생각해볼 때, 난 기초부터 그리고 넓게 맥락을 훑어서 내가 알고 있는 게 뭐고 모르는 게 뭔지 파악하는 게 우선이다 싶어 이걸 골랐다.
이미 너무 익숙해서 지겨웠던 부분은 빠르게 넘기고 대충 뭔지는 알고 있었지만 다른 부서 사람들의 힘에 기대서(?) 대충 넘어갔던 부분들은 자세히 보면서 무슨 콘셉트인지 어디서 어디로 흘러가는지 중심으로 주의 깊게 강의를 진행했다.
그러다 보니 ‘아 내가 개발을 할 때 사용하던 컨테이너들에 이런 옵션이 있었구나! 그래서 이렇게 우리 팀에 온 거구나!’ JIRA나 Repository 너머로만 보던 블랙박스의 실마리가 풀리면서 무릎을 치기도 하고 그때 테스트하던 환경이 정말 바보 같아서 불편했었는데 좀 더 인프라 쪽에서 이렇게 해줬으면 훨씬 더 테스트 환경이 유연했을 텐데!’ 하고 옛날의 고통들이 떠오르기도 했다. 동시에 개발자 입장에서 인프라팀이 일을 하기 쉽도록 좀 더 배려하면 훨씬 생산성이 올라갈 수 있는 부분(예를 들어 DML 코드인데.. 회상해보니 이건 당시엔 개발쪽에서 배려를 하려다가 업무분담을 확실하게 하자는 지침에 따라 짤렸다. 당시엔 인프라가 DB 스키마에 대한 오너십을 가지고 있었다.)도 보이니 정말 이불 하이킥이다. 😓
하지만 그것도 도구들이 굉장히 고도화된 지금에서 보니 할 수 있는 말들이라는 생각이 든다. Ansible까지 강의를 진행한 시점에서 회상해보건대, 클라우드가 대중화되면서 운영환경의 변화는 개발환경의 변화보다 훨씬 더 빠르게 변화한 것 같다. 내가 처음 인프라를 공부할 때는 물리환경에서 공부를 했었고 떠오르던 VMware는 오버헤드를 많이 잡아먹는 의심스러운 기술이었는데 말이다. 반면 백엔드 개발은 여전히 예전이나 지금이나 같은걸 요구하고 있지 않은가.
한편으론 개발자들의 생산성을 올리고 좀 더 제품을 견고하게 만드는데 필요한 방법들이 내 눈에 계속 보인다는 것은 개발과 운영이 이젠 더 이상 다른 부서가 아니라 거의 한 몸이 되어가고 있고 Devops가 필요한 이유를 잘 보여준다고 느낀다.
할 이야기는 많지만 구체적인 기술의 사용방법 이야기는 다른 글에서 별도의 주제로 다루도록 하고 내가 많이 부족하다고 느낀 점. 배운 것에서 좀 더 확장해볼 포인트를 짚고자 한다.
- 마이크로 서비스 환경에서 테스트를 좀 더 세련되게 만들고 커버리지를 올릴 방법이 간절하다.
1) DML 코드가 추가될 때 git 훅을 걸고 DB 컨테이너 만들고 및 데이터까지 이관하면 좋지 않을까?
2) 추가로 테스트에 필요한 데이터들도 코드로 관리해야 하지 않을까? (반성하건대 개별 개발자들이 매번 컨테이너 내부를 만지는건 바보같다) - Terraform, Packer 들은 새로운 서비스가 만들어질 때 그 개발 비용이 상당히 높지만 일단 적용하고 돌아가는 상태, 그 틀만 갖추어지면 그 뒤로는 유지 보수하기는 점차 편해질 듯한데.
Ansible은 그 기능의 범위가 너무나 넓고 실제로 사용빈도도 높아 보인다. 더군다나 Terraform, Packer 보다는 운영 중인 서버를 컨트롤하는 특수성이 짙다.
1) Playbook들을 중복하지 않고 효율적으로 관리하여 협업 시 맹점이 생기지 않도록 하는 방법
2) 수백 개의 호스트를 대상으로 한 실행결과가 코드는 물론 변경의도와 일치한다는 것을 명시적으로 증명할 방법이 필요하다. - 최근에 내가 사용하는 리소스는 AWS에서는 얼마나 하는지 궁금해서 AWS Calculator를 돌려보는데 많은걸 AWS의 로직에 맡기는 서비스일수록 (한마디로 클릭만 몇 번해도 많은걸 해주는 서비스) 가격이 급격하게 오른다. (eg. API-Gateway, Fargate).
따라서 이런 기능들을 효과적으로 대체하거나 절약할 수 있는 부분이 있다면 절약하는 게 중요한 포인트로 보인다.
1) 예를 들어 프로덕션 단계가 아닌 회사라면 낮시간 이외에 인프라를 다 내려버리고 알아서 올리도록 세팅할 수도 있고
2) CICD툴과 Ansible을 연동하면 Fargate를 안 쓰고도 마치 Fargate를 쓰는 것과 같은 인텔리전트 한 서비스를 제공할 수 있을 것 같아 보인다.
3) 또 강의에선 다루지 않았지만 KrakenD 서비스를 잘 알아두고 싶었다. (nginx도 대체품이 될 수도 있겠지만 눈여겨볼만한 확장적 기능들이 라이선스를 요구해서 피하고 싶다는 인식이 내게 있다.)
