목차 Django - App 생성하기 Django - 장고 시작하기 장고 설치하기pip install django 장고 프로젝트 생성하기 - django-admindjango 를 설치하면 django-admin 명령어를 사용할 수 있습니다. 설치된 django-admin 에 startproject 명령어를 사용하면 새롭게 장고 프로젝트를 시작할 수 있습니다. django-admin startproject mysite 장고 서버 실행하기 - manage.py새로운 장고 프로젝트에 들어가면 manage.py 파일이 있습니다. runserver 명령어를 사용하면 장고 서버를 실행할 수 있습니다.
목차 Django - App 생성하기 Django - 장고 시작하기 장고 앱 만들기장고 App 생성은 manage.py 가 있는 프로젝트 폴더에서 startapp 명령어를 사용합니다. startapp 명령어를 사용해 hello_world 라는 이름의 앱을 만들어 줍니다. python manage.py startapp hello_world view.py 작성하기앱 폴더 내에 views.py 파일에 다음과 같은 코드를 작성해줍니다. from django.http import HttpResponsedef hello(request): return HttpResponse("Hello, world. You're at the hello_world index.")# Create your views here.] url.py 작성하기
목차 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 패턴에서는 Service EndPoint 를 조회 및 관리하기 위한 Service Registry 가 있습니다. MSA 의 각 서비스들은 Service Registry 에 자신의 EndPoint 들을 등록합니다. Service EndPoint 를 접근하는 방식에 따라 두가지로 나뉘게 됩니다. 첫번째는 Client-Side Discovery 두번째는 Server-Side Discovery 패턴이 있습니다. 출처: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ Client Side DiscoveryMSA 내 한 서비스가 다른 서비스를 호출할때 Service Registry 로 부터 EndPoint 를 조회한 후 해당 서비스를 호출하는 방식입니다.
목차 [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}
목차 쿠버네티스 - Secret 쿠버네티스 - ConfigMap 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod 쿠버네티스 - Data Plane 쿠버네티스 - Control Plane Post not found: k8s/k8s 참고 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 를 사용할 수 없습니다.
목차 Istio - Locality Load Balancing (지역 로드 밸런싱) Istio - Sidecar Injection Istio - istioctl Istio 란? 공식 홈페이지 https://istio.io/latest/docs/setup/getting-started/ istioctl 설치Mac 을 사용하는 경우 HomeBrew 를 이용해 istioctl 을 설치할 수 있습니다. brew install istioctl 다른 OS 를 사용하거나 특정 버전의 Istio 를 사용하고 싶은 경우 다음과 같이 Istio 버전을 Setting 한 후 해당 버전을 내려받아 사용할 수 있습니다. export ISTIO_VERSION=1.14.5curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIO_VERSION TARGET_ARCH=x86_64 sh -
참고 https://frozenpond.tistory.com/111 CustomResourceCustom Resource는 쿠버네티스에서 사용자가 정의한 리소스를 나타냅니다. 이는 일반적으로 클러스터 내에 존재하지 않는 기본 리소스의 새로운 종류를 정의하고, 이를 통해 사용자의 애플리케이션에 특화된 동작을 수행할 수 있도록 합니다. Custom Resource 는 클러스터 상태의 일부로서 존재하며, 일반적인 리소스와 동일한 방식으로 쿠버네티스 API를 통해 작동합니다. 예를 들어, 사용자는 Custom Resource 를 생성, 조회, 수정 및 삭제할 수 있습니다. Custom Resource 를 사용하기 위해 먼저 Custom Resource Definition(CRD) 을 정의해야 합니다. CRD는 Custom Resource 의 스키마를 설명하는 쿠버네티스 API 개체입니다. 이를 통해 Custom Resource 의 구조, 필드 및 기타 특성을 정의할 수 있습니다. CRD는 일종의 템플릿으로서, Custom Resource 의 정의를 기반으로 생성됩니다. CRD를 생성하면 쿠버네티스 API 서버가 새로운 Custom Resource 타입을 이해하고 처리할 수 있게 됩니다. Custom Resource Definition 을 작성한 후, 사용자는 해당 정의를 사용하여 Custom Resource 인스턴스를 생성하고 관리할 수 있습니다. Custom Resource 인스턴스는 일반적으로 YAML 또는 JSON 형식으로 정의되며, 클러스터에 배포됩니다. 이후 Custom Resource 는 클러스터 내에서 다른 리소스와 유사하게 다룰 수 있으며, 사용자는 쿠버네티스 API를 사용하여 Custom Resource 를 조작할 수 있습니다. Custom Resource 와 Custom Resource Definition 은 쿠버네티스의 확장성과 유연성을 높여줍니다. 사용자는 쿠버네티스 API를 통해 고유한 리소스 유형을 정의하고 제어할 수 있으며, 이를 통해 자신의 애플리케이션을 더욱 쉽게 관리할 수 있습니다.
목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s CA
목차 쿠버네티스 - HPA (Horizontal Pod Autoscaler) 쿠버네티스 - Namespace 쿠버네티스 - Ingress Post not found: k8s/deployment/deployment Post not found: k8s/replicaset/replicaset 쿠버네티스 - Node 쿠버네티스 - Pod Post not found: k8s/k8s VPA