2~3가지 서비스를 거치면서 개발했던 방식은 Layered 아키텍처를 벗어난 적이 없다. 6년짜리 레거시 코드를 Layered 아키텍처로 운영/개발할 때도 큰 불편함을 느끼지 못 했었다. 당시를 떠올려보면 그렇게 생각했던 이유가 몇 가지 있는데.. 1. 테스트를 구현하지 않았음2. 서비스의 규모와 팀의 규모가 크지 않았음3. R&R을 나누는 직급이 아니었음 이 정도가 아닐까 싶다. 그러나 이직 후 업무 분담도 하고, 서비스 규모가 점점 커지는 개발을 하다보니 Layered 아키텍처의 문제를 느끼게 됐다. (내가 느꼈던) Layered 아키텍처의 문제 1. Service가 너무 커져서 파생되는 문제들 - 어떤 기능을 추가하면 Service에만 추가하고, 비슷한 Service를 만들게 되서 계속해서 커지..
번역 API에 대한 기술 검토 중에 문서 번역에 대한 요청을 받게 됐다. 이런 저런 방법에 대한 고민을 해보다가 직접하는 것보단 통합으로 제공하는 곳이 없을까 찾아봤다. 그리고, GCP에서 제공하는 Document Translation API를 알게 됐다. Document Translation API는 Cloud Translation API 일부인데, 말 그대로 구글에서 제공하는 번역 API 에서 제공하는 세부 기능 중 하나다. API를 자유롭게 사용할 수 있으면 좋겠지만, 유료 결제를 등록한 계정만 사용할 수 있다. 카드 등록도 해야 쓸 수 있다. 일단은 무료 크레딧으로 사용해보기로 하고, 하나씩 시작해보자. 1. 서비스 계정 만들고 키 발급 받기 처음 시작은 indexing API와 크게 다르지않다...
작년 입사 후 얼마 지나지 않아서 로그 파이프라인을 구성했었다. 2023.05.28 - [개발/SPRING] - 스프링부트 서비스에 LOG 남기기 (with. Logback) 당시에는 요청에 대한 로그가 없어서 급하게 구축하게 됐는데, 지금 생각해보면 입사한지 한달도 되지 않은 개발자가 로그 파이프라인을 구성한다는 자체가 말이 좀 안되는 일이긴했다. 그래서 로그 파이프라인에 구멍이 조금씩 있었는데, 최근에 가장 큰 구멍을 알게되서 개선이 필요했다. 바로 Multipart/form-data 형식에서 MultipartFile에 대한 처리가 없어서, 어떤 파일이 업로드가 되었는지 알 수 없었다. 그런데, 현재 담당하고 있는 서비스가 파일 업로드를 지원하기 때문에 로그의 개선을 필요로 했다. 로그를 몇 번 개선..
이전 글에서 SEO 노출도를 올리기 위한 indexing API 작업을 했다. 그런데 문제가 있는게 indexing API는 하루에 200회의 제한이 있다. https://developers.google.com/search/apis/indexing-api/v3/quota-pricing?hl=ko 제한 횟수를 늘려달라고 요청할 수 있는데, 구글 친구들은 늘 그렇듯이 언제 해줄 수 있다고 알려주지 않는다. 그렇다고 한 개씩 등록하면(요청하면) HTTP 연결풀을 순간적으로 많이 잡아먹으니까 한번에 보낼 수 있는 방법을 만들어 뒀다. 일괄 색인 생성 요청 보내기라는 섹션을 만들어 둘 정도로 써달라고 만들어뒀는데... 이게 일단 예시를 바로 가져다 쓸 수 있게 생기질 않았다. https://googleapis.g..
상태 검사(health check)란? 상태 확인(상태 검사)은 특정 서버의 서비스에 작업을 성공적으로 수행할 수 있는지 여부를 물어보는 방식입니다. 로드 밸런서는 각 서버에 이 질문을 정기적으로 물어보며 트래픽을 라우팅하는 데 안전한 서버를 확인합니다. 대기열에서 메시지를 폴링하는 서비스는 대기열에서 더 많은 작업을 폴링하도록 결정하기 전에 정상 상태인지를 물어볼 수 있습니다. 외부 모니터링 플릿이나 각 서버에서 실행되는 모니터링 에이전트는 경보를 알리거나 장애가 발생한 서버를 자동으로 처리할 수 있도록 정상 상태인지 여부를 서버에 물어볼 수 있습니다. https://aws.amazon.com/ko/builders-library/implementing-health-checks/ 쿠버네티스를 사용하거나 ..
일단 나는 API 문서화 + 공유용으로 Postman을 더 선호한다. 그런데 내가 Postman을 선호하고 잘 쓸 수 있었던 가장 큰 이유는 팀 규모가 크지 않았기 때문이라 생각한다. 팀 규모가 커지면 Postman은 상당히 비싼 툴이기 때문이다. 팀 규모가 커져서 Postman을 놓아줄 경우 대안은 여러 종류가 있지만, OpenAPI + Swagger-ui 를 많이 쓴다. 그런데 난 Swagger를 선호하지 않는다. 거기엔 이유가 몇가지 있다. 1. SpringBoot에서 쓰기엔 코드에 너무 많은 어노테이션들이 들어가서, 오히려 코드의 가독성을 망친다. 2. springdoc, springfox에 spring 버전, openapi 버전, java/kotlin 버전에 따라 사용법이 너무 달라서 잘 쓰기 ..
이번 프로젝트를 진행하면서, 스프링 시큐리티를 도입하기로 했다. 현재 서비스는 그래도 제법 덩치가 있어서 바로 도입이 어렵기 때문에, 작은 서비스에 먼저 적용해보자는 취지였다. 결론부터 이야기하면, 현재 서비스 구조는 스프링 시큐리티에 필요한 데이터 구조를 가지고 있지 않았다. 이 과정에서 겪은 일들과 필터체인에 JWT를 엮는 일까지가 이번 포스팅이 될 것 같다. 우선 스프링 시큐리티가 뭔지부터 정리해보자. 스프링 시큐리티란? 스프링 시큐리티 공식 사이트에선 아래와 같이 스프링 시큐리티를 소개하고 있다. Spring Security는 강력하고 사용자 정의가 가능한 인증 및 액세스 제어 프레임워크입니다. 이는 Spring 기반 애플리케이션 보안을 위한 사실상의 표준입니다. Spring Security는 J..
- Total
- Today
- Yesterday
- springboot
- GIT
- chat GPT
- JWT
- Spring
- cache
- jenkins
- MySQL
- EKS
- serverless
- CloudFront
- openAI API
- AOP
- Kotlin
- S3
- 람다
- Elastic cloud
- ChatGPT
- OpenAI
- docker
- Log
- 스프링부트
- lambda
- elasticsearch
- AWS
- AWS EC2
- 코딩테스트
- terraform
- awskrug
- java
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |