개발과 일상

개요저번에도 언급했지만, 구글 드라이브와 같은 파일 저장소 서버를 계속 개발하고 있다. 올 4월 전시회 출품하는 단계까지는 개발을 완료했지만, 우려되는 부분이 많아서 고민들 중 하나를 정리해보려고한다. 가장 걱정되는 부분 중 하나가 업로드다. 현재 구현 방식에는 문제가 있을 수밖에 없다. 이전 글도 사실 파일 업로드를 어떻게하면 효과적일지에 대한 고민을 하면서 작성한 글이었다. MultipartFile에서 부터 찾아들어간 Multipart/form-data 전송 방식. 그리고 chunked 업로드 그리고 결론부터 말하면, 내가 고민한 것에 대한 정답은 이미 나와있었고 의외의 곳에서 힌트를 얻었다. 문제점현재 서비스의 업로드의 가장 큰 문제는 서버가 파일 업로드/다운로드를 중개해준다는 것이다.사용자 ..

개요난 꽤 오랫동안 "서비스 로그를 어떻게 남겨야 할까?"라는 고민을 해왔고, 이 고민은 다음의 블로그 글들로 이어져 왔다.스프링부트 서비스에 LOG 남기기 (with. Logback)스프링부트 AOP를 이용해 로깅 처리하기스프링부트에서 Multipart/form-data 요청의 MultipartFile 정보 로그 남기기Terraform으로 EKS 배포하기 11. Grafana Loki와 로그 모니터링 로그를 남길 때 가장 많이 고민한 건 다음과 같은 질문들이었다. API마다 어떤 로그를 남겨야 하는가?예외 발생 시 어떤 정보를 남겨야 대응하기 좋을까?known 에러는 어떻게 표기할까?서버 에러는 어떻게, 또 알람은 어떤 기준으로 발생시킬까?이번 서비스 개발을 계기로, 어느 정도 최종안을 정리할 수 있었..

개요사실 로그 파이프라인은 인프라 초기 설계 단계에서 함께 고민했어야 했지만, ECS 기반 인프라를 구성할 당시에는 방법을 몰라 한동안 손대지 못하고 있었다. 그 대신 임시 방편으로 로그를 데이터베이스에 저장하고, 단순히 스택 트레이스를 확인할 수 있게만 만들어둔 상태였다. 하지만 로그를 DB에 저장하는 방식은 여러모로 바람직하지 않다.첫째, 서비스 로직에 필요한 DB 커넥션 풀을 로그 기록 때문에 점유하게 된다.둘째, 불필요한 DB I/O가 발생해 비용 낭비로 이어진다.셋째, 로그는 개발자나 운영자를 위한 정보인데, 이를 위해 운영 데이터 저장소의 용량을 소모하게 된다.그리고 마지막으로, 검색과 필터링도 DB 쿼리로 해야 하기 때문에, 로그 시스템 고유의 장점인 빠른 탐색/집계 기능을 기대하기 어렵다...

개요서비스에 파일 다운로드 시나리오가 추가되었다. 과부하에 대응하기 위해 파일을 인메모리에 저장하지 않고 스트림을 통해 클라이언트에 전달하는 방식을 사용했다. 이에따라 응답에 파일 이름을 전달할 수 없게 됐고, 파일명을 다른 방식으로 전달할 수 밖에 없었다. 어떻게 처리할까 고민하다가 Content-Disposition 헤더를 알게되서 이번에 사용해봤다. 동작 자체는 잘 됐지만, 다기종과 연동하면서 생긴 문제를 함께 정리해보려고 한다. Content-Disposition란?일반적인 HTTP 응답에서 Content-Disposition 헤더는 컨텐츠가 브라우저에 inline 되어야 하는 웹페이지 자체이거나 웹페이지의 일부인지, 아니면 attachment 로써 다운로드 되거나 로컬에 저장될 용도록 쓰이는 것..

개요 현재 담당하고 있는 제품이 해외 결제 시스템을 추가하게 됐다. 이에 따라 고려해야할게 몇 가지 있었다. 1. 어느 지역 까지 커버할 것인가? 2. 구독이 정상적으로 동작할 것인가?3. 데이터 유실 없이 안정성은 보장할 수 있을 것인가?4. 개발하기 간편한가?5. 환불이나 CS 운영적인 부분도 커버가 가능한가? 이리저리 알아볼 것도 없이 Stripe가 가장 강력한 후보가 됐다. Twilio 때도 그랬지만 북미에서 제공하는 SaaS 형식의 제품들은 사용하기는 편하지만 생각보다 비싸다. 그래도 자체 인프라 없이, 월간 결제 형식이 아니라 on-demand + 수수료로 책정되는 모델이라 초기 모델로는 더할 나위 없을 것 같았다. 이번 글에서는 완전히 도입까진 아니고 developer 사이트에서 결제 세션..

개요간단한 검색 기능을 넣어놨는데... iOS에서 올린 데이터가 검색이 안된다는 이슈가 올라왔다. 그래서 DB를 뒤적거려보니... 아래와 같이 저장되어 있었다. 사실 처음부터 데이터가 이렇게 저장되고 있다는건 알고 있긴했다. 그런데, 문자열 기반 검색이 아닌 단순 조회에서는 신기하게 제대로 출력되서 큰 걱정은 안하고 있었다. 그런데 문자열 기반 검색이 안되기 때문에 조치가 필요했다. 가장 쉬운 방법은 쿼리에서 데이터 마이그레이션을 하고, 클라이언트에서 NFC 방식으로 업로드하는 것을 유도하는 것이다. 그런데, 클라이언트가 바로 패치를 못하는 경우가 있다. 이 때는 서버에서 단독으로 조치를 해줘야한다. 해결 방법을 하나씩 알아보자. 1. PostgresSQL에서 NFD방식을 NFC로 마이그레이션하기특정 버..

서버 개발 중 스프링 부트가 실행 될 때, 반드시 한번 실행 시키고 싶은 코드가 생겼다. 코드 상 서비스로직에 추가해야할 것 같고, 굳이 빈일 필요가 없다.  예를 들어, 변수에 어떤 값을 초기화 한다던가, 객체를 초기화 한다던가 여러가지 예가 있을 것 같다. 여러가지 방법이 있다. 하나씩 정리해보자.1. @PostConstruct @Serviceclass DataService { private val dataList = mutableListOf() @PostConstruct fun loadData() { // 애플리케이션 시작 시 데이터 초기화 dataList.addAll(listOf("Data1", "Data2", "Data3")) println(..

개요이직 후 거의 바로 QueryDSL을 도입했었다.스프링부트에 QueryDSL 적용기 - 1 (Mybatis vs JPA vs JOOQ vs QueryDSL 비교)스프링부트에 QueryDSL 적용기 - 2 (설치 및 사용법, Spring Data JPA와 함께 사용하기) QueryDSL 도입에는 여러가지 이유가 있는데 대표적인 이유로는 담당하게된 프로젝트가 MyBatis와 JPA가 혼재되어 있었다는게 첫번째 이유였다. JPA를 완전히 덜어내기 어려운 상황이었고, 두번째는 이직 전 회사에서부터 엄청난 길이의 MyBatis 동적쿼리에 고통받고 있던 나는 Native Query를 백엔드 코드에서 더 이상 보고싶지 않았기 때문이었다. QueryDSL 도입 초기에는 컴파일 단계에서 쿼리 오류를 잡아주는 게 너무..