개발과 일상

서버 to 서버로 데이터를 전송할 일이 생겼는데.... 문제가 생겼다. 문제 상황은 다음과 같다. 1. A 서버에서 B서버로 요청을 보낼 계획2. A 서버는 S3에서 파일정보를 가져와서 ByteArray 형태로 들고 있음3. B 서버에는 MultipartFile을 파라미터로 받는 API(ex. /api/file)가 존재함 - 수정 불가(FE에서 사용 중)  4. A 서버에서 B 서버로 /api/file을 요청해야 함 - 데이터만 삽입하고 끝내기엔 이력이나 업데이트해야할 정보가 많음5. A 서버에서는 FeginClient를 사용 중(HTTP 통신을 위해서 사용 중, 굳이 고집하지 않아도 됨) 요약하면, 요청을 보내기 위해서 스프링부트 서버에서 MultipartFile을 어떻게 만들 것인가? 와  Feign..

서비스의 규모가 커짐에 따라 수정 사항도 늘어나고, 서로 간의 의존성도 커지면서 다른 한쪽의 문제를 예상하지 못하고 수정해버려서 발생하는 이슈가 늘어났다. 그래서 개발을 할 때나 수정할 때 점점 부담이 많이 생기게 되서, 제대로된 테스트의 도입 방식을 검토했다. 이전에 강의를 하나보고 여기에 감명을 받았다. 2024.04.15 - [일상] - [인프런 강의] Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트를 듣고위 그래프처럼 개발 양은 많아지는데, 이게 잘 동작할까? 에 대한 부담감이 점점 커지는 상황이라 조치가 필요해졌다. 그러나 테스트 도입에는 정말 많은 애로 사항들이 있었는데... 다음과 같은 의사결정이 필요했다. 1. 테스트의 종류 선정: 몇 종류의 테스트를 실행할 것인가?2. 어..

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. 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에서 제공하는 완전관리형 쿠버네티스 서비스인 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를 지정해..