12/10
멀티스레드 사용 추천
•
작업이 CPU 집약적이며, 병렬로 실행 가능한 작업이 많을 때.
•
각 작업의 실행 시간이 길거나 독립적인 실행 흐름이 필요할 때.
•
멀티코어를 최대한 활용해야 할 때.
비동기 이벤트 기반 추천
•
작업이 I/O 바운드(대기 시간이 긴 작업)인 경우.
•
대규모 동시 작업(수천~수십만 개)을 처리해야 할 때.
•
리소스 효율성이 중요한 애플리케이션(WebSocket 서버, 채팅 애플리케이션).
12/11
Metamask로 할 수 있는 것들
1. 코인 거래 및 관리
•
Metamask는 다양한 암호화폐(이더리움, ERC-20 토큰 등)를 저장, 송금, 수령할 수 있습니다.
•
암호화폐 거래를 하려면 거래소(예: Binance, Upbit 등)에서 코인을 구매한 뒤, 이를 Metamask로 전송할 수 있습니다.
•
또는 Metamask 내에서 바로 탈중앙화 거래소(DEX)(예: Uniswap, SushiSwap 등)를 통해 코인을 교환할 수도 있습니다.
코인 구매 방법:
1.
거래소에서 구매 후 Metamask로 전송
2.
Metamask의 'Buy' 기능을 통해 외부 서비스를 사용해 직접 구매
3.
친구나 다른 사용자로부터 송금을 통해 코인 수령
2. P2E(Play-to-Earn) 게임
•
Metamask를 사용해 P2E 게임에 접속할 수 있습니다.예를 들어, Axie Infinity, Gods Unchained 같은 게임은 암호화폐 지갑을 통해 연결해야 플레이할 수 있습니다.
•
게임 내에서 아이템이나 캐릭터를 사고팔거나, 플레이하면서 보상을 받을 때 암호화폐가 지급됩니다.
•
NFT 기반 아이템을 거래하는 경우도 많으며, Metamask는 이를 관리할 수 있는 플랫폼 역할을 합니다.
3. NFT 거래
•
NFT 마켓플레이스(예: OpenSea, Rarible)에서 NFT를 구매하거나 판매할 때 Metamask가 필요합니다.
•
NFT는 디지털 자산(이미지, 음악, 비디오 등)이며, 블록체인 기술로 소유권을 증명합니다.
4. 디앱(DApp) 사용
•
Metamask는 다양한 탈중앙화 애플리케이션(DApp)과 연결됩니다.탈중앙화 금융(DeFi) 서비스(예: Aave, Compound)를 이용하거나, 탈중앙화 소셜 네트워크에 참여할 수 있습니다.
•
DeFi에서는 코인을 예치하여 이자를 받거나, 대출 서비스를 이용하는 등 금융 활동이 가능합니다.
5. 커스터마이징된 네트워크 추가
•
Metamask는 기본적으로 이더리움 네트워크를 지원하지만, Polygon, BNB Chain, Avalanche 등 다른 블록체인 네트워크를 추가하여 사용할 수도 있습니다.이를 통해 더 많은 디앱과 프로젝트에 참여 가능합니다.
시작하기 전에 알아야 할 것들
1.
보안 관리:
•
비밀 복구 문구(seed phrase)는 절대 공개하지 말고 안전하게 보관하세요.
•
지갑이 해킹당하면 자산을 잃을 수 있습니다.
2.
가스비(수수료):
•
Metamask를 통해 거래를 하거나 디앱을 사용할 때 **가스비(거래 수수료)**를 지불해야 합니다.이는 네트워크 상태에 따라 달라집니다.
3.
작은 금액부터 시작:
•
블록체인과 암호화폐 거래가 처음이라면, 작은 금액으로 연습해보세요.
•
예를 들어, Polygon 같은 네트워크는 가스비가 저렴하여 초보자에게 추천됩니다.
블록체인 게임
•
블록체인은 게임 데이터 중 소유권, 거래, 진척도 같은 핵심 정보를 저장하고, 나머지 복잡한 그래픽 및 연산은 **게임 클라이언트(PC)**에서 처리할 수 있습니다.
•
예: Gods Unchained는 PC 클라이언트를 통해 고품질의 게임 플레이를 제공하면서, 카드 소유권 및 거래는 블록체인으로 처리합니다.
구현 방식 예시
•
게임 로직 및 그래픽은 PC에서 처리.
•
블록체인은 NFT와 게임 자산의 거래만 담당.
•
블록체인과 게임 간 데이터 동기화는 API를 통해 이루어짐
(예: 게임 내에서 블록체인 데이터를 호출하여 아이템 확인)
블록체인 게임이 원시적이라고 느끼는 이유는 블록체인 게임은 재미보다 주로 P2E를 통해 경제적 이익을 제공하는 것이 우선이기 때문이다.
또한 네트워크 트랜잭션 처리 속도가 게임서버보다 훨씬 느리고 gas fee또한 존재하기 때문에 단순 재미를 위해서 블록체인을 위해서 게임을 만들 메리트가 없다.
그래서 트랜잭션 최소화를 위해서 게임플레이가 단순하고 비실시간인 것이다.
또한 웹 브라우저에서 동작하는 DApp형태로 만들어진느 경우가 많아서 그래픽에 제약이 있는 편.
메타버스 플랫폼
블록체인 위에서 소유권을 주장할 수 있는 이유
NFT와 블록체인은 디지털 자산의 진정한 소유권을 제공합니다.
•
사용자가 구매한 건물, 아이템 등의 데이터는 블록체인에 기록되어 변조 불가하며, 운영자가 이를 마음대로 변경하거나 삭제할 수 없습니다.
•
메타버스 내의 디지털 자산은 전 세계 누구나 소유권을 확인할 수 있으므로, 사용자 간 거래가 투명하게 이루어집니다.
운영자가 게임을 없애버리면 생기는 문제
소유권만 남고 실질적 사용이 불가능한 상황
•
NFT로 소유권을 주장하더라도 메타버스 플랫폼 자체가 운영 중단되면, 그 소유권을 사용할 환경이 사라집니다.
•
예를 들어:
◦
건물의 NFT를 소유하고 있어도 메타버스가 없어지면 건물을 전시하거나 사용하지 못함.
◦
운영자가 해당 블록체인 데이터를 연동하지 않으면 게임과의 연결도 단절됨.
"탈중앙화" 메타버스 플랫폼의 한계
•
많은 메타버스 플랫폼(Decentraland, Sandbox 등)이 블록체인 소유권을 주장하지만, 플랫폼 자체는 여전히 중앙화된 서버 또는 운영자의 통제하에 있습니다.
•
따라서 플랫폼 운영자가 정책을 바꾸거나 서버를 종료하면 사용자는 아무것도 할 수 없게 됩니다.
오픈소스 메타버스 엔진
•
플랫폼의 엔진과 데이터가 오픈소스로 공개되면, 운영자가 종료하더라도 커뮤니티가 이를 유지하거나 별도의 클라이언트를 통해 계속 사용할 수 있습니다.
•
예: Minecraft 모드 커뮤니티처럼, 메타버스를 운영자가 아닌 사용자들이 계속 유지.
멀티체인 및 상호운용성
•
메타버스 데이터를 여러 블록체인과 연결하면, 특정 운영자가 중단되더라도 사용자는 다른 플랫폼에서 자신의 자산을 활용할 수 있습니다.
•
예: A 메타버스에서 구매한 NFT 건물을 B 메타버스에서도 사용할 수 있도록 설계.
12/14
Jest와 RTL을 같이 사용하는 이유.
두 도구는 React 내에서 테스트를 진행할 때 같이 사용되기에 상호 보완 관계라고 볼 수 있다. (엄밀히 말하자면, RTL이 Jest를 포함하는 구조) 전반적으로 Jest를 통해 기능 테스트를 진행할 수는 있지만, React의 컴포넌트를 렌더링하고 테스트하기 위해서는 몇 가지 기능이 더 필요하다. 그렇기 때문에 React 환경에서는 둘을 같이 사용하는 것이 권장된다.
1. Pod
•
정의: Kubernetes에서 가장 작은 배포 단위입니다. 애플리케이션 컨테이너(예: Docker 컨테이너)와 함께 실행에 필요한 네트워크 및 스토리지를 포함합니다.
•
특징:
◦
일반적으로 하나의 애플리케이션 컨테이너(예: Nginx, Node.js 등)를 포함합니다.
◦
필요에 따라 여러 컨테이너를 포함할 수도 있지만, 같은 Pod 안의 컨테이너는 항상 같은 IP와 네트워크 네임스페이스를 공유합니다.
◦
Pod는 휘발성이며, 삭제되거나 문제가 생기면 재생성됩니다.
2. Node
•
정의: Kubernetes 클러스터의 워커(worker) 머신입니다. 물리 서버나 가상 머신일 수 있습니다.
•
특징:
◦
Pod가 실제로 실행되는 장소입니다.
◦
각 Node에는 kubelet(노드와 클러스터 간 통신)과 컨테이너 런타임(예: Docker, containerd)이 실행됩니다.
◦
Node는 여러 Pod를 실행할 수 있습니다. Node는 CPU, 메모리, 디스크 등의 자원을 가지고 있습니다. Kubernetes는 이 자원을 효율적으로 활용하기 위해 한 Node에 여러 Pod를 배치할 수 있습니다.
◦
Kubernetes의 스케줄러가 Pod의 요구 리소스와 Node의 가용 리소스를 비교하여 가장 적합한 Node에 Pod를 배치합니다.
3. Cluster
•
정의: Kubernetes의 모든 Node와 컨트롤 플레인을 포함하는 전체 시스템입니다.
•
특징:
◦
Master Node(제어 노드)가 클러스터를 관리하고, Worker Node는 애플리케이션 워크로드를 실행합니다.
◦
클러스터는 하나 이상의 Node를 포함하며, Node는 Pod를 실행합니다.
4. Deployment
•
정의: 애플리케이션 배포를 관리하기 위한 Kubernetes 객체입니다.
•
특징:
◦
특정 수의 Pod(예: replicas)를 유지합니다.
◦
Pod가 삭제되거나 문제가 생기면 Deployment가 이를 감지하고 새로운 Pod를 생성합니다.
◦
선언형 방식으로 동작: 원하는 상태(예: Pod 개수, 이미지 버전 등)를 정의하면 Kubernetes가 이를 보장합니다.
5. Service
•
정의: Kubernetes에서 Pod를 네트워크로 노출(expose)하는 방식입니다.
•
특징:
◦
Pod는 휘발성이기 때문에 Pod의 IP는 고정되지 않습니다. 이를 해결하기 위해 Service는 고정된 IP와 DNS 이름을 제공하여 Pod에 안정적으로 접근할 수 있게 합니다.
◦
Service 유형:
▪
ClusterIP (기본값): 클러스터 내부에서만 접근 가능.
▪
NodePort: 외부에서 Node를 통해 접근 가능.
▪
LoadBalancer: 클라우드 환경에서 외부 로드 밸런서를 통해 접근 가능.
◦
Selector: 특정 Label을 가진 Pod에 트래픽을 라우팅합니다.
6. Expose란?
•
정의: Pod 또는 Service를 네트워크에 공개하여 다른 애플리케이션이나 사용자들이 접근할 수 있도록 설정하는 작업입니다.
•
예:
◦
kubectl expose pod my-pod --type=ClusterIP: Pod를 Cluster 내부에서 접근할 수 있는 Service로 노출.
◦
kubectl expose deployment my-deployment --type=NodePort: Deployment를 외부 네트워크에서 접근 가능하도록 NodePort로 노출.
Cluster는 Deployment가 동작하는 환경이다.
•
Cluster는 인프라: Deployment는 Pod를 생성하고 관리하지만, 이 Pod는 Cluster 내의 Node에서 실행됩니다.
•
Deployment는 애플리케이션 배포 도구: Cluster는 Deployment가 정의한 Pod와 리소스를 실행하고 관리하는 플랫폼입니다.
1.
Deployment 생성:
•
사용자가 Deployment를 정의하고 클러스터에 생성합니다.
•
Deployment는 몇 개의 Pod를 실행할지(replicas), 어떤 컨테이너 이미지를 사용할지 등을 설정합니다.
2.
Pod 생성:
•
Deployment는 Pod를 정의하고, 클러스터에 요청해 해당 Pod를 실행합니다.
3.
Node 배치:
•
클러스터의 스케줄러가 Pod를 실행할 적절한 Node를 선택합니다.
•
Pod는 클러스터의 여러 Node에 분산되어 실행됩니다.
4.
Cluster 관리:
•
Cluster는 Deployment의 요청을 받아 Pod를 실행하고, 상태를 유지합니다.
•
Pod가 종료되거나 문제가 생기면, Deployment가 이를 감지하고 새로운 Pod를 생성합니다.
kubectl은 Kubernetes Cluster를 관리하기 위한 클라이언트 도구입니다.
kubectl의 역할:
•
Kubernetes 클러스터와 상호작용하기 위해 사용되는 **명령줄 인터페이스(CLI)**입니다.
•
Kubernetes API 서버와 통신하여 클러스터의 리소스(Pod, Service, Deployment 등)를 관리합니다.
동작 방식:
1.
사용자가 kubectl 명령을 실행하면, kubectl은 클러스터의 API 서버에 요청을 보냅니다.
2.
클러스터의 Control Plane이 요청을 처리하고 적절한 동작을 수행합니다.
Deployment 없이 Pod가 실행될 수 있는가?
네, 가능합니다.
1. Standalone Pod (독립 실행 Pod)
•
Deployment 없이 실행되므로 복제본(replica) 관리는 Kubernetes가 하지 않습니다.
•
Pod가 종료되거나 장애가 발생하면, Kubernetes가 자동으로 복구하지 않습니다.
12/15
kubectl logs로 pod의 log를 볼 수 있음
curl로 가져오고 있는데 왜 response안오지?
log찍히는거 보니까 pod이 실행은 되고있는데
무슨주소로 접근해야하나
일단은 build다시 수행해서 확실히 적용되게 하고
curl다시 시도해보기
kubectl get all 하면 pod이랑 deployments service다 running이긴 한데
일단 프론트 pod은 접속은 되고
1.
dockerfile expose와 deployment port가 일치하는지 확인
eval $(minikube docker-env)
docker build -t frontend-app:latest ./frontend
docker build -t backend-app:latest ./backend
kubectl apply -f frontend-deployment.yaml
kubectl apply -f backend-deployment.yaml
여기까지 하면 deployment실행되고 pod들 생성되고 replica자동으로 관리한다
kubectl expose deployment backend-deployment --type=NodePort --port=80 --target-port=5001 ⇒서비스가 생성되었으면 expose를 안해도 된다. service를 직접 생성해주는거임
minikube service backend-serivce는 minikube가 따로 서비스 접근 포트 열어준다
minikube ip로 ip받아온다음 http://<minikube-ip>:30002 하면 된다는데 왜 안되지??
30002는 nodeport = 클러스터에 뚫린 구멍
nodeport라는 서비스 자체가 클러스터의 구멍임
아무튼 minikube service backend-service 실행하면
minikube가 minikube tunnel로 url주소를 주고 그걸로 접근할 수 있다.
쿠버네티스 기능과 minikube 기능이 헷갈리는게 문제다..
kubectl logs pod/backend-deployment-75bbb7696d-94dwp 이걸로 pod의 log를 볼 수 있다.
프론트 웹앱이 브라우저니까 클러스터의 외부라서 dns를 쓸수는 없음 그러려면 ingress를 사용해야함
ingress사용안하면 그냥 ip주소로 요청보내야지..
웹소켓 에러가 발생하는 이유?? ws는 webpack-dev-server에서 HMR을 위해서 연결해놓은것인데, 저장할때마다 자동으로 업데이트되도록.
ws연결 포트를 바꿔줄 수 있는데 eject해서 webpack설정 바꿔줘야 할듯.
아니면 어차피 HMR안될뿐이니 그냥 둬도 된다
브라우저 사용하면 ingress써야하는거 맞나?
React 앱 (클러스터 외부):
React 앱은 일반적으로 브라우저에서 실행되며, 사용자는 웹 페이지를 통해 접근합니다. 이 앱은 클라이언트 측에서 동작하므로, 클러스터 외부에 위치합니다.
클러스터 외부에서 백엔드 API에 접근하기 위해서는 클러스터 외부의 IP 주소 또는 도메인을 사용해야 합니다.
Node.js 서버 (클러스터 내부):
Node.js 서버는 Kubernetes 클러스터 내에서 실행되며, 클러스터 내부의 서비스로 접근할 수 있습니다. 이 서버는 API 요청을 처리하고 데이터베이스와 상호작용합니다.
요청 경로
React 앱에서 Node.js 서버로의 요청:
React 앱이 클러스터 외부에서 실행될 때, Node.js 서버(백엔드)로의 요청은 외부에서 이루어지는 것입니다. 이 경우, React 앱은 Node.js 서버가 노출하는 IP 주소와 포트를 사용해야 합니다.
아니면 ingress로 외부에서도 접근할 수 있게 만들어야함.
React 앱에서 API 요청을 보낼 때
클라이언트 측 요청: React 애플리케이션에서 API 요청을 보낼 때는 브라우저가 직접 요청을 보냅니다. 이 경우, 클라이언트 측에서 fetch, axios, XMLHttpRequest 등을 사용하여 API에 접근합니다. 브라우저가 직접 요청을 보내므로, CORS 정책이 적용됩니다.
