개발과 일상

지금까지 개발을 하면서 xxx 주도 설계를 정의하고 시작해본 적은 없지만, 도메인 주도 설계에 대해서는 알고 있었다. MSA에 가장 적합한 설계라는 것 정도로 알고 있었는데, 이 책을 읽고 생각이 조금 바뀌었다.  결국 설계는 서비스가 성장함에 따라서 발생할 수 있는 문제를 해결하기 위한 방법론 중 하나일 뿐이었다. 그리고 이 책은 커져가는 서비스에서 발생하는 문제를 도메인 주도 설계라는 방법론을 통해 해결하는 방법을 알려 준다. 가장 기억에 남는 말은, 책 서두와 말미에 다음과 같은 문구가 써있다. 우리가 해결하고자 하는 문제가 무엇인지 합의하기 전에 해결책을 얘기하는 것은 의미가 없다. 또한 해결책에 대해 합의하기 전에 어떻게 구현하는지 얘기하는 것도 의미 없다.- 에프랏 골드렛-아쉬라그(Efrat ..

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. Cloud Watch를 뒤적거리던가, ArgoCD 대시보드에서 컨테이너에 접근해서 로그를 파악했다. .... 그래서 DevOps 관리자 분과 가장 먼저 협업한 것이 로그 파이프라인 구성이었다. 내가 한 일은 다음과 같다. 1. Application 단에서 발생한 로그를 어느 단위로 남길 것인지 판단하고 필요한 정보를 검토2. 검토된 정보들을 로그로 만들어 JSON 형태로 남김3. LogQL 쿼리로 Loki 데이터를 쿼리해서 Grafana에 대시보드를 추가 DevOps 관리자분은 따로 작업하셨어서 어떤 일을 했었는지 정확히 알기 어려웠는데, 이번 기회에 잘 알게 됐다. DevOps 관리자분이 한 일은 다음과 같다. 1. JSON 형태의 로그가 생..

2~3가지 서비스를 거치면서 개발했던 방식은 Layered 아키텍처를 벗어난 적이 없다. 6년짜리 레거시 코드를 Layered 아키텍처로 운영/개발할 때도 큰 불편함을 느끼지 못 했었다. 당시를 떠올려보면 그렇게 생각했던 이유가 몇 가지 있는데.. 1. 테스트를 구현하지 않았음2. 불행인지 다행인지 레거시 코드를 수정할 일이 거의 없었음3. 서비스의 규모와 팀의 규모가 크지 않았음4. R&R을 나누는 직급이 아니었음 이 정도가 아닐까 싶다. 그러나 이직 후 업무 분담도 하는 직급이 됐고, 서비스 규모가 점점 커지면서 운영 개발 건이 늘어나다보니 Layered 아키텍처의 문제를 느끼게 됐다. (내가 느꼈던) Layered 아키텍처의 문제  1. Service가 너무 커져서 파생되는 문제들- 어떤 기능을 추..

개인적으로는 AWS를 꽤 오래 사용하였지만, 업무에 사용하게 된건 이직한 이후다. 그래서 AWS를 잘 다룬다는 걸 증명하고 싶어서 자격증이 있으면 좋겠다는 생각을 하고, 자격증 소모임에 참여해봤다. 오거나이저 중 한 분이 진행했는데, 짧은 시간이었지만 유익한 내용이 많았다. 이번 소모임에서는 대부분의 시간을 SA 시험 안내서를 보고 중요한 내용을 설명을 해줬다.시험 안내서에서 중요한 내용 정리 - 시험 안내서가 엄청 중요하다.- 시험은 65문제 중 50문제를 푸는 것이고, 720점 이하로 대표적으로 690점으로 떨어졌다? 아쉽게 떨어지는건 절대 아니다. AWS가 점수를 후하게 준다. SA는 보안에 대한 문제도 나온다.- 보안은 IAM이나 SSO를 설계하는 경우가 더 많다. SSO를 왜?- 공동 책임 모델..

AWS에서 제공하는 완전관리형 쿠버네티스 서비스인 EKS는 업데이트 주기가 엄청나게 빠르다. Amazon EKS Kubernetes 버전에 관한 문서를 읽어보면 다음과 같이 안내한다. 1. EKS 신규 버전 출시는 쿠버네티스 업스트림 릴리즈 주기(4개월)을 따름.2. 신규 버전 출시 후 14개월은 무료로 표준 지원3. 표준 지원 종료 후 12개월 추가 지원 (클러스터 당 0.6$/h의 추가 요금 발생)4. 추가버전 종료까지 업그레이드를 하지 않을경우 가장 마지막 버전으로 강제 업그레이드5. 평균적으로 업스트림 릴리즈 이후 약 2~6개월 이후 EKS 지원 만약 추가 지원으로 빠진다면, 클러스터 당 한달에 약 60만원(0.6 × 1380 × 24 × 30) 정도의 추가 비용이 발생한다. 그래서 그런지 콘솔에..

상용 DB를 막 만져봤던 뉴비 시절에 "우리 서비스의 데이터베이스는 HA 구조야" 라는 말을 들었었다. 그 당시에는 아무것도 몰라서 "오 상용서비스에서는 이렇게 구성하는구나"하고 넘어갔었다. 몇 년이 지난 지금, 그 기억을 곰곰이 떠올려보니 HA는 구조가 아니라 High Availability, 고가용성을 말하는 것이었다. 고가용성은 구조를 의미하는게 아니라, 예상치 못한 중단 없이 지속적으로 운영될 수 있는 능력을 의미하는 개념이다. 데이터베이스의 고가용성을 보장하기 위해 여러 가지 이중화 전략이 사용된다.  이중화는 단순히 하나의 시스템이 고장나더라도 다른 시스템이 그 기능을 대신할 수 있도록 구성하는 것이다.  전회사에서는 DB 고가용성을 제공하기위해서 Active/StandBy 구조를 사용하고 있..

작년 말에 Aurora MySQL 5.7 버전의 지원 종료와 연장 지원 안내를 받았었다.https://aws.amazon.com/ko/blogs/korea/your-mysql-5-7-and-postgresql-11-databases-will-be-automatically-enrolled-into-amazon-rds-extended-support/ 요약하면 권장 사항인 MySQL 8.0 대신 MySQL 5.7 버전을 계속 사용할 경우 돈을 더 내라는 내용이었다. 올해 전반기 내내 다사다난해서 지금껏 미뤘다가 이제서야 업데이트를 시작할 여유가 생겼다. 버전 업데이트에 앞서 문제 상황을 확인해보자. 1. 연장 지원 비용비용이 저렴하다면 그냥 둬도 될 것 같다. 그런데 연장 지원 비용을 계산해보면 다음과 같다...

GitOps를 구축하는데 가장 중요한 단계이다. CI/CD 부분에서 키 설정등의 내용이 많아서 100% 전달할 수 있을지 잘 모르겠다. 이전까지 진행 상황 이 전 글에서 봤던 파이프라인이지만 이전 글에서는 ArgoCD를 EKS 내부에 띄우는데까지만 진행했었다.(위 그림에서 할당된 번호도 없음) 그리고 CI는 이전 글들에서 진행했었다. 아래 글에 1 ~ 3번 과정이 정리되어있다.2023.11.06 - [개발/인프라] - github action으로 CI/CD 구축하기 - 1. CI2023.11.12 - [개발/인프라] - github action으로 CI/CD 구축하기 - 2. JIB 마지막으로 남은 CD 자동화 부분이다. 자동화를 위해서는 ArgoCD가 모니터링할 GitHub Repository를 지정해..