목차 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 작성하기
목차 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 패턴에서는 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 에 Service 등록하기 Spring Cloud - Service Discovery Server (Eureka) 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka Service 등록하기implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' @EnableDiscoveryClient@SpringBootApplication@EnableDiscoveryClientpublic class UserServiceApplication { public static void main(String[] args){ SpringApplication.run(UserServiceApplication.class, args); }} Eureka 서버에 등록을 위한 Properties 설정 추가eureka.client.register-with-eureka 값을 true 로 줌으로써 Eureka 서버에 등록하도록 설정합니다.
목차 Spring Cloud - Eureka 에 Service 등록하기 Spring Cloud - Service Discovery Server (Eureka) 참고 https://cloud.spring.io/spring-cloud-netflix/reference/html/ https://coe.gitbook.io/guide/service-discovery/eureka 사용하는 Spring Cloud 버전plugins { id 'org.springframework.boot' version '2.4.5' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id 'java'}group = 'com.example'version = '0.0.1-SNAPSHOT'sourceCompatibility = '11'repositories { mavenCentral()}ext { set('springCloudVersion', "2020.0.2")}dependencies { testImplementation 'org.springframework.boot:spring-boot-starter-test'}dependencyManagement { imports { mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}" }}test { useJUnitPlatform()} Spring Cloud EurekaMSA (Micro Service Architecture) 에서는 각 서비스를 관리하기 위해서 Service Discovery Server 가 필요합니다. Spring Cloud 에서는 Service Discovery 를 위해 Eureka 를 사용한다. Discovery Server (Eureka)implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
배치 잡의 실행 여부를 설정# 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