나름 개발자의 IT블로그

AWS 아키텍처를 구성할 때 어떻게 구성하면 좋을지 그리고 그게 왜 좋은지 단계별로 알아보자. best practice인지는 모르겠지만 그래도 좋은 아키텍처라고 생각했다. 1단계 EC2에 배포하기 가장 생각하기 쉬운 구성이다. EC2에 우리의 애플리케이션을 띄운 후 Route 53으로 도메인을 걸어주는 방식이다. 가장 간단한만큼 문제점도 많다. 일단 오토스케일링이 안된다. 오토스케일링을 위해 EC2를 띄우면 새로운 도메인을 할당해야 하므로 사용하기 힘들다. 오토스케일링이 안되면 대규모 트래픽을 감당하기 힘들기 때문에 어느정도 사용량이 많아지면 상황이 많이 안좋아진다. 2단계 리버스 프록시 사용하기 이제 오토스케일링을 하더라도 도메인은 리버스프록시에만 할당됐기 때문에 문제는 해결됐다. 이제 오토스케일링도 ..

때는 바야흐로 지금으로부터 6년전 내가 대학교 1학년때 이야기이다. 알파고의 등장으로 딥러닝이 급부상한 시기였는데 이 시절에 세종대학교에서 스타크래프트 인공지능 vs 인간 이라는 대회를 개최했었다. 초보, 중급, 프로 세 명의 사람이 스타크래프트 봇과 경기하는 내용이었는데 초보와 중급 플레이어는 학생이었고 프로는 송병구 선수였다. 나도 이 경기를 관람하였고 그 때 스타크래프트 인공지능의 존재를 알게 되었으며 인공지능을 공부하기 시작한 계기가 되었다. 6년이 지난 지금 갑자기 생각나서 옛날의 추억을 회상해보려고 한다. http://www.sejongpr.ac.kr/sejongnewspaperview.do?boardType=4&pkid=8908 준비물 https://github.com/bwapi/bwapi ..

매트로이드(matroid)란 다음 성질을 만족하는 구조이다. $M =(X, I)$인 매트로이드 $M$이 존재한다고 하자. 1. $X$ 는 유한집합이다. 2. $I$는 $X$의 부분집합이면서 independent set이다. 공집합은 independent set이다. 3. $A, B$가 independent일 때 $|A| < |B|$이면 $x \in B-A$에 대해 $A \cup \{x\}$도 independent인 $x$가 존재한다. 위와 같은 성질을 만족하면 매트로이드라고 한다. 1번은 쉽게 이해할 수 있지만 2, 3번에 나오는 independent가 아직 와닿지 않는다. "어떤 규칙" 정도로 이해하고 넘어가자. 예를들어 $X = \{1, 2, 3, 4, 5\}$이고 $I$의 크기가 3보다 작은 집합이..

메시지 큐(Message Queue)란 무엇일까? 서로 다른 프로세스간 데이터를 통신하는 방법이다. 그렇다면 데이터를 보내는 프로세스가 있고 받는 프로세스가 있을 것이다. 여기에서 보내는 프로세스를 Producer, 받는 프로세스를 Consumer라고 한다. 일반적으로는 역할이 나눠져 있지만 특수한 경우에는 Producer이면서 Consumer인 케이스도 있을 것이다. 일단 그런 경우는 고려하지 말자. 그냥 설명만 보면 이해가 안되니 직접 코드로 확인해보자. # producer.py print("I'm producer!") idx = 0 for i in range(10): with open(f"./data/{i}", "w") as f: f.write(f"Hi! I'm {i}-th message!") pr..

지금까지 우리는 쿠버네티스를 구성하면서 터미널에 명령어를 입력하여 사용하는 명령적(Imperative)접근방식을 이용했다. 쿠버네티스는 선언적(Declarative)접근방식도 지원하는데 이번엔 이 방식을 사용해보자. 선언적 접근방식 선언적 접근방식은 터미널에 입력했던 설정들을 파일로 작성하여 실행하는 방식이다. 해당 방식은 IaC(Infrastructure as a Code)로도 잘 알려져있어 널리 쓰이고 있다. 이 방식의 장점은 편리하고 수정이 용이하다는 것이다. 우선 해당 방식을 사용하기 위해 지금까지 사용한 모든 객체를 삭제한다. kubectl delete deployment/server kubectl delete service/server 파일 작성 https://kubernetes.io/docs..

개발할 때는 보통 도커환경에서 테스트하지 않고 로컬에서 테스트를 한다. 하지만 테스트마저도 도커환경에서 하고 싶을 수 있다. 만약 이러한 상황에서 코드가 수정되면 어떤 일이 벌어질까? 컨테이너환경도 수정된 사항을 반영하기 위해 아래 작업을 수행한다. 도커 이미지를 재 빌드한다. 실행중인 컨테이너를 종료한다. 빌드한 이미지를 다시 실행시킨다. 크게 복잡한 과정은 없지만 수시로 변경되는 코드를 생각해보면 정말 귀찮은 작업이다. 이를 해결하기 위해 바인드 마운트를 사용하면 편리하게 사용할 수 있다. 프로젝트 준비 # main.py from fastapi import FastAPI import uvicorn app = FastAPI() @app.get("/") async def root(): return {"m..

Scaling 쿠버네티스는 파드의 개수를 늘려 자동으로 로드밸런싱을 하는 scaling 기능을 제공한다. 이 기능을 한번 사용해보자. # main.py from fastapi import FastAPI import uvicorn import socket app = FastAPI() @app.get("/") async def root(): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(('pwnbit.kr', 443)) ipaddr = sock.getsockname()[0] return {"message": "Hello Wonderful World", "ipaddr": ipaddr} if __name__ == "__main__"..

현재 배포중인 deployment에서 코드 변경등의 이유로 업데이트를 하고 싶을 수 있다. 어떻게 업데이트를 하는지 알아보자. Deployment 업데이트 # main.py from fastapi import FastAPI import uvicorn app = FastAPI() @app.get("/") async def root(): return {"message": "Hello Wonderful World"} if __name__ == "__main__": uvicorn.run(app, port=8000, host="0.0.0.0") 코드를 위와 같이 업데이트했다. 일단 업데이트했으니 이미지를 빌드해야한다. docker build --tag riroan/myserver . docker push riro..

쿠버네티스 배포하기에서 발생한 오류를 해결해보자. 지난시간에 Service 객체가 존재하여 pod를 외부와 소통하는 역할을 한다고 하는데 무엇인지 알아보자. Pod IP address 우선 pod는 접속하기 위한 고유의 IP주소를 가지고 있다. 일단 해당 IP주소를 확인해보자. minikube dashboard minikube dashboard --url # url만 표시 위 명령어를 실행하면 웹사이트가 하나 나온다. 왼쪽 메뉴에서 pod로 들어가 실행중인 pod를 확인해보자. pod의 IP주소를 확인할 수 있다. 그렇다면 이 IP로 접속하면 문제가 해결될까? 아쉽게도 불가능하다. 해당 IP는 클러스터 내부에서 사용하는 IP이기때문에 클러스터 외부에 있는 우리는 직접 접근이 불가능하다. 또한 해당 IP는..

지난시간 마지막에 발생한 문제를 해결하기 위해 쿠버네티스 구성요소에는 어떤게 있는지 각 요소가 무슨 역할을 하는지 아는것이 좋다. 이번시간에 한번 정리해보도록 하자. Overview 쿠버네티스 구성을 간략하게 나타내면 위 그림과 같이 나온다. 기본적으로 클러스터는 하나의 마스터노드와 여러개의 워커노드로 이루어져있다. 여기서 클러스터는 하나의 쿠버네티스를 나타내는 논리적 단위로 생각하면 된다. 노드는 PC, 컨테이너, 가상머신등 하나의 서버라고 생각하면 된다. Master Node 마스터노드(컨트롤 플레인)는 kubectl로 통신하기 위한 노드이다. 우리는 minikube를 도커 드라이버로 사용하기때문에 컨테이너형태로 사용중이다. Scheduler: 각 노드의 조건과 상태를 고려해 특정 자원을 어떤 워커 ..