MLOpsCurriculum

I'm a MLOps Engineer at Corca.

Phase1.

• EC2 endpoint: http://3.38.165.145:3000/
• ECS endpoint: http://52.78.77.252:3000/

Summary

• User에게 Service를 제공하기 위한 API를 만드는 것이 주 목적이다.
• API를 개발할 때, 여러 개발자들과 함께 협업하기 위해서 Git을 사용하게 된다. Git은 Code Review를 쉽게 할 수 있도록 한다.
• API를 RESTful하게 만든다면, URL이 직관적이고 에러 메시지가 잘 나오기 때문에 보다 유용하게 사용할 수 있다.
• 데이터를 저장하기 위해서 데이터베이스를 사용하며 자신이 다루는 데이터에 맞는 DB를 사용해야 한다.
• 제 컴에서 되는데요?를 막기 위해 코드를 Container화 시켜서 배포를 하게 된다.
• Container를 Cloud Service를 통해 배포하게 되면, 보다 서버 관리가 On-premise에서 하는 것보다 쉬워진다.

Review

• 백엔드를 처음 하는 거다 보니 사소한 에러에 대해서도 시간을 많이 잡아먹었다. 물론 결국에는 다 해결하긴 했지만 생각보다 Phase 1 마무리하는데 너무 오래 걸린 것 같아서 아쉽다.
• 확실히 이쪽 분야는 CS 개념 지식을 많이 필요로 하는 것 같다. 네트워크 이론, 데이터베이스 등 더 많은 공부가 필요하다.
• AWS ECS로 결국 배포까지 했지만 내가 잘한 건지는 모르겠다. 너무 복잡하다 AWS의 세계는..
• NestJS로 RESTful API를 만든 것이 굉장히 뿌듯했다. Python 원툴러로서 typescript와 더 친해지고 싶다.

Feedback

• Database에서 과제가 왜 없는지 모르겠다. 이 코스에서 AWS RDS를 한번 다뤘으면 마지막 코스인 ECS에서 보다 수월했을 것 같다.
• 확실히 이전 코스보다 ECS 코스일 때, 설명이 약간은 불친절하다는 느낌을 받았다. 물론 공식 docs가 가장 좋은 reference라지만, 노션에서 구어체를 활용하여 설명을 해줬으면 좋았을 것 같다. VPC, Subnet 등 AWS의 네트워크에 대해서도 추가적인 공부가 필수적인데, 이 부분에 대해서 노션에 추가적인 설명이 있었으면 좋았을 것 같다.
• Docker를 다양하게 써볼 수 있는 과제가 있으면 좋겠다. 예를 들어, Dockerfile을 하나주고 최대한 최적화해서 이미지 크기 30MB 이하로 줄이기. 이런 식으로..?

Phase2.

Summary

기능적, 비기능적 테스트가 많을수록 코드에 대한 신뢰도가 커질 수 있다. 테스트가 없다면 모든 배포마다 불안에 떨어야 하고 실제로 실패로 이어질 확률이 높다. 모든 자동화하면 좋다. 자동화를 똑똑하게 한다면 생산성을 크게 향상 시킬 수 있다. CI/CD를 이용하면 테스트와 빌드 및 배포를 자동화할 수 있다. IaC를 사용하면 코드로 인프라를 관리할 수 있다. 직접 RDS를 만들려고 클릭클릭하지 않아도 된다. 서비스를 배포하면 그때부터 엔지니어의 역할이 더 중요해진다. 서비스가 잘 돌아가고 있는지 모니터링을 잘하기 위해 로깅을 해야하고 보다 효율적인 모니터링을 위해서는 로깅 레벨을 세부적으로 나누고 크리티컬한 경우에는 알람까지 보낼 수 있도록 해야 한다. 트래픽이 겁나게 많아질 때를 대비하여 Auto Scaling Policy를 만들어서 ECS에다가 붙여줄 수도 있다. 그럼 알아서 Policy 대로 Task를 늘렸다가 줄였다가 한다. 아키텍처 종류가 다양하다. 시의적절한 아키텍처를 설계해야 보다 안정적인 서비스를 운영할 수 있을 것이다.

Review

테스트가 중요하고 보통 명세단계에서부터 테스트를 시작하라고 한다. Requirements 들을 Test Code로 옮기고 그 다음에 구현을 하라고 한다. 하지만 NestJS로 개발할 때 이게 쉽지는 않았다. 그렇게 명세를 빡세게 하지 않았어서 그런지 테스트 코드를 먼저 짜는게 쉽진 않았다. .workflows/*.yml 을 디버깅하는게 겁나게 어려웠다. Git Action을 실행해야하니까 자꾸 쓸데없는 코드를 넣어서 commit을 해서 action을 돌렸는데 test하는데 시간이 너무 오래 걸렸다. 하지만 한번 제대로 짜놓고 나면 그다음부턴 겁나게 편하다. Pulumi도 그랬다. 잘 안되가지고 겁나 고생하고 실제로 거의 공식 독스 밖에 참고할게 없어서 힘들었지만 막상 해놓으니까 배포하는 게 무지 편하다. Cloudwatch에서 metric을 만들어서 특정한 경우에 슬랙으로 알람오게 하는 거 재밌었다. 지금 BEAT가 어떻게 알람이 오게 되는 건지 알 수 있어서 좋았다.

솔직히 이렇게 Phase 2 까지 끝냈지만 아직 많이 부족함을 느낀다. NestJS도 내가 자주 쓰는 프레임워크가 아니다 보니 안쓰면 계속 까먹고 그런다. MLOps를 잘하기 위해서 시작한 커리큘럼이었는데 아직 Ops 실력이 부족하다고 생각한다. 물론 커리큘럼이 무슨 금단의 마법서도 아니고 이것만 한다고 해서 잘하기는 어렵다. 실무에서도 많이 겪어보고 싶다는 생각을 했다. 직접 일을 하는 실력은 크게 늘었다고 볼 수 없지만 이제 Ops 엔지니어 분들이 하는 얘기들을 어느정도 알아들을 수 있지 않을까? BEAT에 문제가 생긴다면 어떤 컴포넌트를 봐야하고 어떤 것이 문제인지 이전보다는 잘 알 수 있을 것 같다.

Feedback

커리큘럼 자체에 대한 피드백

Load Balancing 과제가 보다 일찍 나와야할 것 같다. 나는 ECS 때 이미 ELB를 설정을 했어가지고.. 뭔가 순서가 이상하게 느껴졌다. Load Balancing 과제도 좀 쉬워서 쉬어가는 타임이라는 느낌이 들었다. Pulumi가 진짜 공식 docs 밖에 볼게 없어서 서러웠다. 게다가 awsx도 있고, aws도 있어서 코르카에서는 Pulumi를 어떻게 쓰는지 정리해놓는다면 같이 업무하는데 더 편하지 않을까?

이런거 만들어주셔서 감사합니다. 힘들지만 보람차고 재밌었습니다.