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

개요기존 서비스가 지속적인 개발 단계에서 완전한 유지보수 단계로 전환되면서, 새로운 기능이나 콘텐츠가 더 이상 추가되지 않아 MAU/DAU가 크게 감소했다. 반면, 기능 추가가 활발하던 시절에 확장한 서버와 DB 스펙은 그대로 유지되어 인프라 비용은 오히려 증가했다. 결과적으로 월 비용은 약 2천 달러에서 3천 달러로 40~50% 가까이 상승했다. 사용량은 줄었는데 비용은 오르는 상황이 반복되자, 실장님께서 회의 때마다 시간이 날 때 비용 구조를 한번 점검해보자고 언급하셨고, 마침 맡고 있던 MVP 개발이 마무리되면서 본격적으로 비용 절감 작업을 시작할 수 있었다. 우선 하이퍼빌링 계정을 전달받아 전체 AWS 리소스를 분석하기 시작했는데, 큰 문제는 두 가지였다. 첫째, 리소스에 태깅이 제대로 되어 있지..

개요사실 로그 파이프라인은 인프라 초기 설계 단계에서 함께 고민했어야 했지만, 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 사이트에서 결제 세션..

개요앞선 글(언제나 복잡한 이름 순 정렬 구현하기)에 이어서 파일 드라이브의 정책 관련 이야기들 중 하나다. 별로 재미없는 이야기인데, 내가 했던 고민들을 정리해보려고 한다. 현재 개발 중인 서비스에 파일을 관리할 때 파일들이 고유한 id를 갖게끔 구성했다. 그래서 순도 100% 백엔드 개발자 마인드로 어차피 id로 구분되니까 파일 이름이 중복되도 문제가 없지 않을까...? 란 생각을 했지만... 다른 팀원들의 생각은 달랐다. 그 결과 나는 반대했지만 결국 중복된 이름 생성을 방지하기 위한 다양한 정책이 나오기 시작했다... 어떤 문제가 있었고 이에 따른 어떤 정책들이 있었으며 어떻게 처리했는지 하나씩 알아보자. 1. 생성 시 동일한 이름이 있다면 어떻게 해야하나?이건 정책적으로 그냥 막기로 했다. ..

개요원래는 teleport를 도입하면서 접근제어와 감사로그를 함께 해결하려고 했다. 그러나 teleport를 쿠버네티스 외부 환경에서 구축하려면 인증 서버와 Bastion 서버, EC2 인스턴스 두 개가 필수적으로 필요했다. 비용이 엄청 크진 않지만, AWS 인프라 관리는 내가 하지만 비용을 다른 팀에서 부담하는 모순적인 구조라 인프라를 마구마구 늘릴수가 없었다. 그래서 접근제어는 SSM 기반 접근 방식을 이용하기로 했다. 조금 손이 가긴 하지만 보안적으로 가장 안전하다.어떻게 구축했는지는 이전 글에 있다.Private Subnet에 있는 AWS RDS에 접근하기 2. Bastion + SSM with. DBeaver 그렇다면 감사로그는 어떻게 찍어야할까? 다행히 PostgresSQL에서 제공하는 방식이..

개요이전 글 : Private Subnet에 있는 AWS RDS에 접근하기 1. Bastion + SSH with. DBeaver bastion 점프 서버와 SSH만을 이용해서 상용 DB에 접근하게 된다면, 팀원들이 각각 로컬에 pem key를 갖고 있어야 한다는 너무나 큰 문제가 있다. 이 문제의 가장 보편적인 대안인 AWS SSM을 이용한 방식을 사용해보려고 한다. AWS SSM은 SSH만 쓰는 것 보다 어떤 측면에서는 더 쉽고 간단하며, 더 많은 관리자로서의 기능을 제공한다. 하나씩 알아보자. 1. AWS SSM 이란?https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager.htmlSession Manage..
- Total
- Today
- Yesterday
- 후쿠오카
- AOP
- ChatGPT
- AWS
- JWT
- Spring
- serverless
- Log
- CORS
- terraform
- ecs
- elasticsearch
- cache
- CloudFront
- GIT
- lambda
- 스프링부트
- java
- 후기
- S3
- 티스토리챌린지
- docker
- AWS EC2
- Kotlin
- springboot
- object
- 람다
- EKS
- 오블완
- OpenAI
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |