목차 Django - App 생성하기 Django - 장고 시작하기 장고 설치하기pip install django 장고 프로젝트 생성하기 - django-admindjango 를 설치하면 django-admin 명령어를 사용할 수 있습니다. 설치된 django-admin 에 startproject 명령어를 사용하면 새롭게 장고 프로젝트를 시작할 수 있습니다. django-admin startproject mysite 장고 서버 실행하기 - manage.py새로운 장고 프로젝트에 들어가면 manage.py 파일이 있습니다. runserver 명령어를 사용하면 장고 서버를 실행할 수 있습니다.
목차 React Query - 캐싱 라이프 사이클 React Query - React Devtools 사용하기 React Query - 시작하기 cache 와 stale 설정const queryClient = new QueryClient({ defaultOptions: { queries: { staleTime: 1000 * 60, cacheTime: 1000 * 60 * 5, } },});const App = ({ Component, pageProps }: AppProps) => { return ( <QueryClientProvider client={queryClient}> <Component {...pageProps} /> </QueryClientProvider> );}; cacheReact Query 는 설정한 cacheTime 만큼 데이터를 메모리에 저장해 놓습니다. 다시 이야기 하자면 React Query 에서의 Cache 는 QueryCache 객체의 queries 배열과 queriesInMap 객체의 Query 객체가 존재하는 것을 말합니다. cache 라이프 사이클 - fresh 와 stalestale 은 React Query 에서 cache 에 저장된 데이터 상태를 의미합니다. cache 에 저장된 데이터가 staleTime 만큼은 fresh 한 상태로 있다가 그 후에는 stale 상태로 넘어갑니다. stale 상태의 데이터는 cache 에 오랫동안 저장돼 있어 refetch 가 필요한 상태임을 의미합니다. React Query 에서는 stale 상태의 데이터가 특정 조건을 만족하면 refetching 이 일어나도록 합니다.
목차 React Query - 캐싱 라이프 사이클 React Query - React Devtools 사용하기 React Query - 시작하기 의존성 추가$ npm i @tanstack/react-query-devtools# or$ yarn add @tanstack/react-query-devtools ReactQueryDevtoolsimport React from 'react'import ReactDOM from 'react-dom/client'import App from './App.tsx'import { ReactQueryDevtools } from '@tanstack/react-query-devtools'import {QueryClient, QueryClientProvider } from '@tanstack/react-query'const queryClient = new QueryClient()ReactDOM.createRoot(document.getElementById('root')!).render( <React.StrictMode> <QueryClientProvider client={queryClient}> <App /> <ReactQueryDevtools initialIsOpen={false} /> </QueryClientProvider> </React.StrictMode>,)
목차 React Query - 캐싱 라이프 사이클 React Query - React Devtools 사용하기 React Query - 시작하기 참고 공식문서 https://tanstack.com/query/v4/docs/react/quick-start 의존성 추가$ npm i @tanstack/react-query# or$ yarn add @tanstack/react-query Providerimport React from "react";import ReactDOM from "react-dom/client";import App from "./App.tsx";import { QueryClient, QueryClientProvider } from "@tanstack/react-query";const queryClient = new QueryClient();ReactDOM.createRoot(document.getElementById("root")!).render( <React.StrictMode> <QueryClientProvider client={queryClient}> <App /> </QueryClientProvider> </React.StrictMode>); useQuery
JPA 에서의 업데이트 - 더티 체킹 Entity 에 대한 더티 체킹 을 통한 업데이트가 이뤄집니다. JPA 에서는 Entity 를 업데이트 하기 위한 메소드가 별도로 존재하지 않습니다. JPA 에서의 업데이트는 엔티티 변경 과 더티 체킹 을 통해 업데이트가 이뤄집니다. JPA 에서 엔티티를 변경하기 위해서는 변경하고자 하는 엔티티를 조회한 후 해당 엔티티의 값을 변경하면 트랜잭션을 커밋할 때 변경 감지(Dirty Checking) 가 동작해서 데이터베이스에 UPDATE SQL 이 실행하는 방식으로 Entity 에 대한 변경을 반영합니다. @Override@Transactionalpublic ItemDto.Response modifyItemPrice(Long id, ItemDto.Request itemDto) { // 1. 변경하고자 하는 Entity 를 조회합니다. Optional<Item> optionalItem = itemRepository.findById(id); if (optionalItem.isPresent()) { Item item = optionalItem.get(); // 2. Entity 의 값을 변경합니다. item.updatePrice(itemDto.getPrice()); return ItemDto.Response.toDto(item); } else { throw new RuntimeException("Item not found"); }} Update 쿼리문 발생update item set item_type_id=?, modified_date=?, name=?, price=?, version=? where id=? and version=? 더티체크를 통한 업데이트의 한계더티 체킹을 통한 업데이트는 변경된 Entity 개수만큼 Update 문을 실행합니다. 그렇기 때문에 변경된 Entity 가 100개라면 100번의 Update 문이 실행되는 문제점이 있습니다.
참고 https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ https://velog.io/@hoonki/마이크로서비스-패턴-서비스-디스커버리 🕵️♂️ Service Discovery 패턴이 등장하게 된 배경기존 서비스 인스턴스의 개수와 IP 가 고정적이였던 온 프레미스 환경과 달리 MSA 환경에서는 Application 들이 AutoScaling 을 하면서 동적으로 줄었다가 늘어나면서 IP 자체도 고정이 아닌 동적으로 바뀌게 됐습니다. Client 나 Gateway 입장에서 서비스 인스턴스들이 동적으로 늘었는지 줄었는지에 대한 파악을 하기가 어려운 문제가 있었고 그에 따른 LoadBalancing 하는데 어려움이 있었습니다. 변경 및 추가된 서비스들의 위치와 주소를 쉽게 파악하기 위해 Service Discovery 가 등장하게 됐습니다. 출처: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ ✅ 서비스 등록 - Service RegistryService Discovery 패턴에서는 Service EndPoint 를 조회 및 관리하기 위한 저장소가 필요한데, 이를 Service Registry 라 합니다. MSA 에서 각 서비스들이 실행하게 되면 Service Registry 에 자신의 EndPoint 들을 등록합니다. 그리고 주기적으로 Service Registry 에 등록된 서비스 중이 정상적인지 Health Check 를 진행하고, 정상적인 응답이 안올 경우 목록에서 삭제하는 방식으로 진행합니다.
목차 [Spring Cloud] - Eureka 에 서비스 등록하기 [Spring Cloud] - Eureka (Service Discovery Server) 사용하기 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka ✅ Eureka 서버에 서비스 등록하기앞에서 설정을 마치고 실행중인 Eureka 서버에 서비스를 등록하기 위해서는 몇가지 작업이 필요합니다. 1. 라이브러리 추가Eureka 에 서비스를 등록하기 위해서는 client 라이브러리가 필요합니다. implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' 2. @EnableDiscoveryClient 추가
목차 [Spring Cloud] - Eureka 에 서비스 등록하기 [Spring Cloud] - Eureka (Service Discovery Server) 사용하기 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka 🔎 Service Discovery Server 로써의 EurekaMSA (Micro Service Architecture) 환경에서는 서비스들이 하나의 서버에서 실행하는 환경이 아닌 각기 다른 서버에서 실행합니다. 특정 요청이 들어 왔을때 해당하는 서비스로 전달해주기 위해서는 각 서비스들이 어떤 서버에서 작동하고 있는지 알 필요가 있습니다. Spring Cloud 에서는 Eureka 서버를 이용해 각 서비스들이 어떤 서버에서 작동중인지를 등록하고 중앙 집중식으로 관리할 수 있고, 실행중인 모든 서비스들을 한번에 찾아 통신할 수 있습니다. 보통 이런 역할을 하는 서버를 Service Discovery Server 라 부릅니다. ✅ Eureka 서버 사용하기Eureka 를 Service Discovery Server 로 사용하기 위해서는 라이브러리 추가와 몇가지 설정이 필요합니다. 1. Eureka 사용을 위한 의존성 추가하기
✅ 배치 잡의 실행 여부를 설정# Spring Boot 가 자동으로 실행시키는 Batch Job 을 실행시키도록 한다.spring.batch.job.enabled: true # default# Spring Boot 가 자동으로 실행시키는 Batch Job 을 실행하지 않도록 한다.spring.batch.job.enabled: false ✅ 배치 잡의 재시작 여부를 설정# 기본이 true, 재시작을 허용한다.spring.batch.job.restartable: true# 재시작을 허용하지 않는다spring.batch.job.restartable: false ✅ 실행할 배치 잡의 이름을 지정스프링 배치는 실행시 기본적으로 모든 Job 을 실행시킵니다. spring.batch.job.names 를 이용해 지정 Job 만 실행하도록 설정할 수 있습니다. 프로그램 실행시 특정 Job 을 전달받아 실행시키고 싶을 경우 spring.batch.job.names: ${job.name:NONE} 로 설정하면 외부에서 주입받은 Job 이름을 이용해 실행시킬 수 있습니다. 만일 전달받은 값이 없으면 아무 Job 도 실행시키지 않습니다. :NONE 은 프로퍼티 표현 중 하나로 전달받은 값이 없을 경우 NONE 으로 대체한다는 의미이다. # Hard Coding 방식spring.batch.job.names: springJob1# Binding 을 사용한 방식spring.batch.job.names: ${job.name:NONE}
목차 [쿠버네티스] 인증/인가 - OIDC 를 이용한 Keycloak 연동 [쿠버네티스] 인증/인가 - ServiceAccount [쿠버네티스] 인증/인가 - X.509 인증서를 사용한 사용자 추가 및 인증 [쿠버네티스] 인증/인가 - Role 과 ClusterRole 참고 https://findstar.pe.kr/2023/04/09/access-k8s-api-from-pod/ https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/ 🔎 ServiceAccount 란? ServiceAccount 는 쿠버네티스 API 서버와 통신하고 클러스터 내의 다른 리소스에 접근하기 위한 인증 정보를 제공합니다. ServiceAccount 는 Pod 가 Kubernetes API Server 에 인증 하기 위한 Account 입니다. 때문에 Pod 를 생성할때 ServiceAccount 를 할당해야 하며 지정하지 않을 경우 default 가 자동으로 할당됩니다. Rule 과 RuleBinding 을 이용해 ServiceAccount 에 권한을 부여함으로써 Pod 가 다른 리소스에 접근할 수 있게 해줍니다. ServiceAccount 는 Namespace 단위로 생성되는 리소스며 다른 Namespace 에서 정의된 ServiceAccount 를 사용할 수 없습니다.