TL;DR

CDKTF를 이용해 지난주까지 작업한 프로젝트로 배포를 진행했다. Azure 플랫폼상에서 Terraform의 제약이 적지 않게 있다는 걸 발견했다. 유저가 확인할 수 있는 통계 데이터 수집 과정을 최적화하기 위해 고민했다. 시크릿값에 대한 내용을 팀원과 공유하고, 추후 방향에 대해 논의했다.

0

지난주까지 작업했던 IaC 프로젝트를 이용해 3개의 다른 환경에 배포를 진행했다. 생각만큼 Azure가 Terraform을 이용해 관리하기 쉽지 않다는 걸 느꼈는데, 크게 다음과 같은 점에서 직접적으로 느낄 수 있었다.

• Preview 기능에 대한 코드화 지원 없음; 심지어 > 1년인 기능임에도 불구하고.
• 몇 리소스에 대해 요금 정책 설정이 지원되지 않음; 레거시 플랜만 지원해, 일부 설정에 제약이 발생함

물론 위에 대항하는 케이스는 대부분 Azure CLI를 통해 해결할 수 있기 때문에, null_resource와 스크립트를 이용해 어거지 Walkaround를 구현할 수는 있다. 다만 이런 스크립트 등의 관리 포인트를 최대한 줄이고 하나로 모으기 위해 Terraform과 같은 서비스를 이용하는 것인데, 결국 스크립트 작성으로 마무리된다는 점이 참 아쉬웠다.

1

설계했던 메시지 큐 아키텍쳐가 가장 먼저 적용될 곳은 유저 통계 데이터 수집이다. 서버가 통계 데이터 수집까지 기다리며 비지니스 로직을 처리할 필요가 없기 때문에, 보다 빠른 응답시간을 위해 통계 관련 책임을 다른 곳으로 넘기는 것이다. 기존 작성된 로직을 그대로 삽으로 퍼서 옮겨 담으려 했으나, 기존 로직 또한 비효율적으로 작성 돼있어 개선이 필요하다는 제보를 받았다. DB 관련 설계 및 쿼리 최적화는 내게 아직 미지의 영역이기 때문에 바로 현재로써 최적값을 그릴 수 없지만, 여러 팀원의 조언을 받으며 최적화 방향을 잡아가고 있다. 역시 처음 경험해 보는 필드의 작업이라 그런지, 재밌게 잡고 여러 디자인을 그려보는 중이다.

2

DB 연결을 위한 문자열, 사용하는 리소스의 시크릿 값, 사용하고 있는 암/복호화 알고리즘의 비밀키 등 절대 코드에 하드코딩 돼서는 안 되는 값들이 있다. 이를 관리하기 위해 환경변수를 사용하거나, KMS를 사용하거나, 혹은 DB를 사용하는 등 여러 가지 방법이 이용되고 있다. 각자 장단이 있는 방법들이지만, 아마 공통된 제 1원칙은 한 눈에 보이는 안전한 곳에 두자 일 것이다. 지난주 개발하며 느꼈던 유쾌하지 않은 DX에 대해 공유하고, 이에 대해 논의할 수 있었다. 같은 경험을 한 분도 여럿 계셨고, 해결 시도도 있었으나 우선순위에 밀려 작업하지 못하고 있다는 슬픈 역사도 들을 수 있었다. 아직 가장 여유가 있는 팀원은 나니까, 시간 날 때 조금씩 고민하고 작업해 두려 한다.

+INF

개인적으로 MBTI를 좋아하지 않지만, 회사는 꽤나 좋아하는 것 같다 😥. 전사적으로 검사한 뒤, 비슷한 유형의 동료들과 점심을 먹는 이벤트를 진행한다고 한다. 왜인지 내가 조장인 팀이 만들어졌고, 팀원분들은 메뉴로 참치를 제시하셨다. 참치 제공 이벤트라면 나도 이 정도는 기쁘게 할 수 있다는 걸 새로 발견했다.

+ 이번 달리기는 10명이 모여 약 10km를 뛰었다. 클라우드 팀에선 나를 포함해 4명이 참석했는데, 열심히 영업한 효과가 있는 것 같아 뿌듯했다. 다만 처음 뛰는 분들께 난이도가 있었을 것 같아 마음이 약간 불편한데, 한동안은 간식이라도 가져다드려야겠다 싶다..