- Today
- Total
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 책
- network
- docker
- 브랜치전략
- SpringBoot
- 만들면서 배우는 클린 아키텍처
- 리뷰
- JPA
- 팀네이버
- Project
- container
- redis
- websocket
- 젠킨스
- spring
- EntityTransaction
- 스프링
- 캐싱전략
- 프로젝트
- SPRING JWT
- LazyInitialization
- JWT
- Spring Security
- 팀네이버 공채
- jenkins
- infra
- Java
- 후기
- Kotlin
- chrome80
목록infra (2)
PPAK
현재 기존에 진행하던 프로젝트에서 예측되는 문제를 찾고 기술적으로 보완하는 리팩토링 과정을 거치고 있다. 그 중 이웃사이 프로젝트의 긴급호출 기능의 요구사항은 아래와 같다. 1. 긴급 호출 요청 시 같은 단지 내 주민들에게 알림이 간다. 1-1. 긴급 요청 알림을 통해 요청자의 위치 정보를 파악할 수 있다. 2. 긴급 호출 요청은 단지 내 주민이 수락할 수 있다. 2-1. 수락 시 단지 내 주민들에게 수락 완료 알림이 간다. +(미정) 추후에 긴급 호출 요청 데이터를 분석하여 단지 내 발생하는 문제들의 통계를 낸다. 단순하다? 긴급 호출 기능은 굉장히 단순하다. 단순한 요청을 분석하여 같은 단지 내 주민들에게 알림을 보내주면 되기 때문이다. 때문에 기존의 아키텍처를 살펴보면 위와 같이 서버와 STOMP ..
이전 포스트 에서는 Docker 위에서 Jenkins 개발환경을 셋팅하였다. 본 포스트에서는 실제로 Jenkins project 를 생성하여 빌드 스크립트를 구축하고 Git Webhook 을 이용해 개발자가 빌드 버튼을 매번 누르는 것이 아닌 Github 의 develop 브렌치에 push 되었을 때 빌드가 되도록 자동화를 할 생각이다 프로젝트에서 백엔드의 개략적인 시스템 아키텍쳐가 나왔다. 초기 AWS 를 사용할 예정이였으나 최근 GCP 에서 제공하는 쿠버네티스 엔진을 이리저리 만져보다가 프로젝트 2차 챌린지로 쿠버네티스 환경 구축을 하면 좋을 것 같아서 사전에 플랫폼에 좀 친숙해지기 위해서 GCP 로 배포하기로 마음먹었다. 실제로 이전 포스팅 의 환경 또한 현재 GCP VM 에 구축한 상황이다. 시스..