로스카츠의 AI 머신러닝

[database] MSSQL 데이터베이스, EC2 우분투에 설치하고 SSMS로 접속하기

Mon, 14 Jul 2025 00:00:00 +0900

MSSQL, 우분투에 설치하고 SSMS로 접속하기

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

DB

백엔드

프론트엔드

1. EC2 인스턴스 생성

본 실습에서 할 내용은 AWS EC2에 MSSQL을 설치하고 로컬 SSMS에서 EC2의 MSSQL에 접속할 예정입니다. 이를 위해 가장 먼저 해야할 일은 EC2인스턴스를 만드는 일입니다. 다음과 같이 EC2 인스턴스를 만들어줍니다.

저는 t2.medium으로 만들었는데, 최소 사양만 맞춰주면 문제없습니다. MSSQL을 설치하기 위한 최소 사용은 디스크 용량 20G, RAM 2기가입니다. 그리고 운영체제를 선택할 때 주의해야하는데, 2025년 7월 기준, 가장 최근 우분투 버전은 noble인데, noble에서는 MSSQL을 설치할 수 없고, jammy 버전까지만 지원가능합니다. 따라서 운영체제를 선택할때 저처럼 jammy 버전으로 선택해주세요.

여러가지 설정을 마치면 위와 같이 t2.medium 인스턴스를 만든 것을 볼 수 있습니다.

인스턴스를 만든김에 인바운드 규칙도 추가해서 1433 포트를 미리 열어주겠습니다. MSSQL은 기본적으로 1433포트를 사용합니다.

2. MSSQL 설치

이번절에서는 MSSQL을 설치해보겠습니다. git bash나 putty 등을 활용해 ec2 인스턴스에 접속해 다음과 같이 설치과정을 진행해보겠습니다.
참고로 MSSQL 설치 과정은 MSSQL 설치 홈페이지에서 확인할 수 있습니다.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy

먼저 운영체제가 확실히 jammy 버전으로 설치되어 있는지 확인해보겠습니다. 위와 같은 커맨드를 입력했을 떄 jammy가 아닌 noble이 나온다면 인스턴스를 잘못 생성한 것이니 다시 만드셔야합니다.

$ sudo apt update
Hit:1 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Get:3 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu noble-backports InRelease [126 kB]
Get:4 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu noble/universe amd64 Packages [15.0 MB]
Get:5 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
...중략

위와 같이 apt update를 진행 해줍니다.

$ sudo apt install net-tools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  net-tools
...중략

그리고 기본적으로 net-tools를 설치가 잘되는지 확인합니다.

$ curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg

다음은 MSSQL 설치를 위해 필요한 key 정보를 위와 같이 추가합니다.

$ curl -fsSL https://packages.microsoft.com/config/ubuntu/22.04/mssql-server-preview.list | sudo tee /etc/apt/sources.list.d/mssql-server-preview.list
deb [arch=amd64,arm64,armhf signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/ubuntu/22.04/mssql-server-preview jammy main

다음은 위와 같이 레포지토리 정보를 추가해줍니다.

$ sudo apt-get update
$ sudo apt-get install -y mssql-server

이제 설치할 준비가 모두 끝났습니다. 위와 같은 코드로 설치해줍니다.

$ sudo /opt/mssql/bin/mssql-conf setup
/opt/mssql/lib/mssql-conf/mssqlsettings.py:550: SyntaxWarning: invalid escape sequence '\.'
  if re.search("^[a-zA-Z0-9\.;-]+$", setting_value):
Locale C not supported. Using en_US.
Choose an edition of SQL Server:
  1) Evaluation (free, no production use rights, 180-day limit)
  2) Enterprise Developer (free, no production use rights)
  3) Standard Developer (free, no production use rights)
  4) Express (free)
  5) Web (PAID)
  6) Standard (PAID)
  7) Enterprise (PAID) - CPU core utilization restricted to 20 physical/40 hyperthreaded
  8) Enterprise Core (PAID) - CPU core utilization up to Operating System Maximum
  9) I bought a license through a retail sales channel and have a product key to enter.
 10) Standard (Billed through Azure) - Use pay-as-you-go billing through Azure.
 11) Enterprise Core (Billed through Azure) - Use pay-as-you-go billing through Azure.

Details about editions can be found at
https://go.microsoft.com/fwlink/?LinkId=2109348

Use of PAID editions of this software requires separate licensing through a
Microsoft Volume Licensing program.
By choosing a PAID edition, you are verifying that you have the appropriate
number of licenses in place to install and run this software.
By choosing an edition billed Pay-As-You-Go through Azure, you are verifying
that the server and SQL Server will be connected to Azure by installing the
management agent and Azure extension for SQL Server.

Enter your edition(1-10): 2
The license terms for this product can be found in
/usr/share/doc/mssql-server or downloaded from: https://aka.ms/useterms

The privacy statement can be viewed at:
https://go.microsoft.com/fwlink/?LinkId=853010

Do you accept the license terms? [Yes/No]:Yes


Choose the language for SQL Server:
(1) English
(2) Deutsch
(3) Español
(4) Français
(5) Italiano
(6) 日本語
(7) 한국어
(8) Português
(9) Руѝѝкий
(10) 中文 – 简体
(11) 中文 （繝体）
Enter Option 1-11: 7
Enter the SQL Server system administrator password:
Confirm the SQL Server system administrator password:
Configuring SQL Server...

ForceFlush feature is enabled for log durability.
[INFO] [StartUp::OpenDBsAndRecover]: In Startup, FEnableResilientBufferPoolExtensionEnabled() = [0]. IsRBPEXSupportedNonHyperscaleEdition() = [0]. IsSubCore = [0].
[INFO][DBDDLAgent::AttachDatabase] Starting Database Attach.
TDS initialization result: 0.
SQLSERVR_SSL_CERTIFICATE_DNS_OR_SUBJECT_NAME environment variable was not set as SSL cert is self signed or untrusted.
[INFO][DBDDLAgent::AttachDatabase] Starting Database Attach.
[Auditing][SecAuditPkg::AutoStartAuditSessions] Entered function.
Created symlink /etc/systemd/system/multi-user.target.wants/mssql-server.service → /lib/systemd/system/mssql-server.service.
Setup has completed successfully. SQL Server is now starting.

설치가 끝났으면 위와 같이 설정을 해줘야하는데 차례대로 다음과 같은 질문을 합니다. 몇번 버전을 사용할거니?(저는 2번 선택), 약관 동의하니(Yes), 어떤 언어 사용할거니?(저는 7번 한국어 선택), 비밀번호 입력, 비밀번호 확인 순서입니다. 위 순서를 거치면 설치가 완료됩니다.

$ systemctl status mssql-server --no-pager
● mssql-server.service - Microsoft SQL Server Database Engine
     Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-07-14 02:03:05 UTC; 35s ago
       Docs: https://docs.microsoft.com/en-us/sql/linux
   Main PID: 3154 (sqlservr)
      Tasks: 83
     Memory: 413.7M
        CPU: 10.477s
     CGroup: /system.slice/mssql-server.service
             ├─3154 /opt/mssql/bin/sqlservr
             └─3183 /opt/mssql/bin/sqlservr

그리고 시스템 가동을 확인했을 때 위와 같이 active 상태이면 성공입니다.

$ sudo ss -tulnp | grep 1433
tcp   LISTEN 0      128               0.0.0.0:1433      0.0.0.0:*    users:(("sqlservr",pid=3183,fd=79))
tcp   LISTEN 0      128                     *:1433            *:*    users:(("sqlservr",pid=3183,fd=78))

그리고 외부에서 접속할 것이므로 위와 같이 외부로 1433 포트가 열려있으면 성공입니다.

로컬에 있는 csv 파일 EC2로 복사하기

$ scp -i pem파일경로 파일이름 ubuntu@IP주소:디렉토리

3. 로컬 SSMS에서 EC2 우분투 MSSQL로 접속

모든 설치가 완료되었으면 로컬에서 SSMS를 실행해 다음 정보로 접속해줍니다.

4. ubuntu에 설치된 MSSSQL을 다룰때 주의사항

우분투에 설치된 MSSQL을 통해 데이터베이스 테이블 등을 만들때 주의할 점이 있습니다. 예를 들어 CSV 파일을 insert burk 한다고 했을때, 윈도우 PC에서는 다음과 같이 인코딩을 cp949로 설정해도 가능했습니다.

BULK INSERT Customers
FROM 'C:/경로/Customers.csv'
WITH (
    FORMAT = 'CSV',
    FIRSTROW = 2,
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '\n',
    CODEPAGE = '949'
);

그러나 우분투에서 작업할 때는 우선 기본적으로 CODEPAGE = '949' 옵션을 사용할 수 없습니다. 우분투에서는 utf8만 가능하므로, 파일의 인코딩이 cp949나 euc-kr일 경우 utf8로 바꿔줘야합니다.

# iconv -f euc-kr -t utf-8 -c issuedelay_ukey.tsv -o issuedelay_ukey-utf8.tsv
# sed '1s/^\xEF\xBB\xBF//' issuedelay_ukey-utf8.tsv > issuedelay_ukey-clean.tsv
# sudo chown mssql:mssql issuedelay_ukey-clean.tsv

위와 같은 코드를 통해 utf8로 변경해야합니다.

# cat issuedelay_ukey-clean.tsv | head

그리고 한글이 잘 보이는지 꼭 위와 같은 코드로 확인해야합니다.

CREATE TABLE test01.dbo.IssueDelay_Ukey (
    STAT_DT NVARCHAR(100),
    SVSET_ORD_NUM NVARCHAR(100),
    SVSET_REQ_NUM NVARCHAR(100),
    POST_ORG_ID NVARCHAR(100),
...(중략)

그리고 테이블을 만들때도 VARCHAR가 아닌 NVARCHAR로 만들어줘야합니다.

BULK INSERT test01.dbo.IssueDelay_Ukey
FROM '/var/opt/mssql/data/issuedelay_ukey-clean.tsv'
WITH (
    FIELDTERMINATOR = '\t',
    ROWTERMINATOR = '\n',
    FIRSTROW = 2
);

그리고 테이블에 데이터를 넣을때는 위와 같은 코드를 참고해주세요.

하루만에 홈페이지 만들기 with Astro

Tue, 25 Mar 2025 00:00:00 +0900

하루만에 홈페이지 만들기 with Astro

법인도 만들었겠다, 드디어 회사 홈페이지를 만들기로 했다. 이런 건 보통 귀찮기도 하고 급한일이 아니라서 미루게 되는데, 불현듯 어느날, 무언가 홀린 사람처럼 “지금이야” 싶었다. 프론트엔드 디자인을 구경하다가, 문둑 머리속에서 내가 만들고 싶은 홈페이지 모습이 선명하게 그려졌다. 마치 스파크가 튀듯 말이다. 그리고 그 순간부터 몰입했다. 정말, 그 몰입의 순간 만큼은 우주에 나 혼자, 노트북 한 대만 있는 느낌이었다. 그만큼 즐거운 순간이었고, 그렇게 해서 탄생한 결과물이 바로 이 홈페이지다.

https://www.madohakja.com

이 글은 그 과정의 기록이다. 혹시 당신도 나처럼 언젠가 만들겠지…라고 미루고 있다면, 이 글이 그 날이 되길 바라며.

우선 개발 과정의 전체 큰 흐름은 위 그림과 같다. 시작은 로컬에서 개발을 하고 github에 push하면 github과 연동되어 있는 CloudFlare에서 코드 변화를 감지한 후, 빌드를 진행한 후에 최종적으로 홈페이지가 배포되는 방식이다. 즉, 코드 한 줄만 수정하고 푸시하면 바로바로 홈페이지가 최신 상태로 반영된다. 물론 처음부터 이렇게 구성하려던 건 아니었다. 한 단계씩 거치면서 적절한 다음 스텝을 찾는 방식으로 진행했다. 그래서 이 글에선 단순히 결과만 보여주는게 아니라, 각 선택의 배경도 함께 이야기해보려 한다. 왜 그렇게 했는지, 무엇이 더 편했는지 같은 이야기들 말이지.

우선 홈페이지에 어떤 내용을 담을지 간단히 화면 기획부터 시작했다. 어떤 페이지가 필요할지, 버튼은 어디에 둘지, 아이템은 어떻게 배치할지… 그럼 이 기획 페이지는 뭘로 만들까? 처음엔 피그마가 떠올랐다. 요즘 다들 쓰고, 나도 예전에 써봤으니까. 게닥 피그마는 코드 변환도 되니까 개발에도 도움이 되겠지 싶었다. 하지만 너무 오랜만에 써서일까, 좀 낯설었다. 이 상태라면 익숙해지는데도 시간이 필요하다. 하지만 이번엔 그럴 시간이 없었다. 이런 방향으로가면 개발기간이 너무 길어질 것만 같았다. 이번 프로젝트의 목적은 피그마 공부가 아닌 최대한 빠르게 홈페이지 완성하기 였고, 결국엔 가장 빨르게 내 손이 움직이는 툴, 파워포인트를 선택했다. 파워포인트는 디자인 툴은 아니지만 기획에는 딱이었다.

화면 기획 단계에서 가장 먼저 한 일은 어떤 페이지들을 넣을지 정하고, 그에 따른 상단 메뉴를 어떻게 구성하는지 결정하는 것이었다. 페이지 수가 많아질수록 홈페이지 구조도 복잡해지기 때문에, 전체 구성을 먼저 그려보는게 중요했다. 결국 나의 경우엔 대메뉴와 소메뉴로 나눠진 상단 메뉴 구조가 필요하겠다고 판단했다. 그 다음엔 각 메뉴에 해당하는 페이지를 어떻게 구성할지 대략적으로 구상했다. 물론 이 단계에서 정하는 내용은 나중에 달라질 가능성이 매우 크므로 지나치게 상세하게 하는 것보다는 크게 윤곽을 잡는다는 느낌으로 접근하는 것이 좋겠다. 물론 처음부터 완벽하게 디자인하면 구현할 때 고민이 적어지니까 장단점이 있는 것 같다. 나의 경우에는 기획은 어짜피 구현하면서 바뀌기 마련이라, 큰 윤곽만 잡고 시작하는게 훨씬 효율적이라고 생각했다.

화면 기획이 끝났다면, 다음 단계는 어떤 플랫폼으로 개발할지 결정해야한다. 내가 고민한 후보는 세 가지. 지킬, 휴고, 아스트로가 그것이다. 먼저 언급된 툴일수록 개발이 쉽고 빠르며, 코드없이도 구축 가능하다. 반면 뒤로 갈수록 난이도도 높고 개발 시간도 늘어난다. 처음에는 지킬을 생각했다. 내 기술 블로그도 지킬로 만들었던 경험이 있었고, 내가 지금 만들 홈페이지도 정적 페이지 몇개면 충분했기 때문에, 지킬을 사용하면 금방되겠거니 했다. 게다가 지킬은 github pages와 궁합이 좋아서 코드만 올리면 알아서 빌드되고 배포까지 되어 공수도 크게 줄어든다.

그렇게 지킬로 개발하기로 결정하고 요즘 어떤 테마가 있는지 살펴봤다. 기술 블로그 만든지도 어느새 5년이 넘어가니 그 사이 테마가 더 다양해졌더라. 너무 오랜만이라 감도 좀 익힐겸, 적당한 테마를 고르고 clone 한후 내 repo에 push….그런데 build fail이 뜬 것이다. github에 코드를 push 하면 깃헙액션이 알아서 빌드를 해주는데, 문제는 그 깃헙액션이였다. 깃헙액션은 말로는 우리에게 빌드를 자동으로 해준다고 하지만 우리는 이미 알고있다. 자동으로 해준다는 말 이면에는 문제가 생겼을때 우리가 손댈 수 있는 영역돋 그만큼 제한된다는 뜻을 말이다. 고생 안하려고 지킬 템플릿 쓰는건데 깃헙 액션이랑 싸울 생각을 하니… 벌써 지친다. 그래서 결론은, 지킬은 이만 보내주기로했다. 잘 가라, 그동안 즐거웠다. 그래. 새로운 시작엔 새로운 툴이지.

그래 이 참에 휴고를 써보자. 휴고는 지킬보다는 손이 더 가긴하지만, 이정도면 다른 일하면서도 홈페이지 관리할 수 있겠다는 생각이 들었다. 그런데 문제는 템플릿이었다. 휴고 템플릿 중에 내가 원하는 스타일이 없었다는 것. 내가 원하는 디자인은 화면 상단에 가로형 메뉴바가 있고, 대메뉴를 클릭시 드롭다운으로 소메뉴가 나오는 구조였다. 그런데 휴고 템플릿 중에는 그런 구조가 드물었고, 있다 하더라도 다지인이 너무 별로였다. 홈페이지는 회사의 얼굴이자 첫인상인데 이런 디자인으로는 도저히 만족할 수 없었다. “이건 좀 아닌데…“하는 생각이 계속 들더라. 그래서 휴고도 탈락. 아쉽게도 패스…

이제 남은건 아스트로. 솔직히 말하면, 코딩은 되도록 피하고 싶었다. 왜냐하면 공수도 많이 들고, 귀찮기도 하고, 무엇보다 다른 할일도 너무 많기 때문이었다. 하지만 결국은 생각했다. 개발자면 개발해야지..라는 마음으로 아스트로 템플릿을 보는데 방금 휴고 템플릿을 보고 와서 그런가? 너무 예뻤다. 그래, 이정도는 되야 홈페이지지!라는 생각과 함께 오랜만에 개발 본능이 샘솟았다. 마침 내가 원하는 화면구성이 있어서 템플릿을 받고 vscode를 실행하고 드디어 코드를 짜기 시작했다.

잠깐, 아스트로가 뭔지 잘 모른다면 이렇게 생각하면 된다. 아스트로(Astro) 는 자바스크립트 기반 정적 웹사이트 개발을 위한 프론트엔드 프레임워크이다. 아스트로 자체는 자바스크립트 및 타입스크립트로 개발되었고 아스트로 컴포넌트(.astro) 내부에서도 자바스트립트 및 타입스크립트를 사용할 수 있다. 또한 아스트로는 정적 사이트 구축을 목표로 하므로 HTML과 CSS 중심으로 작동하므로, 웹 개발을 조금만 해봤다면 진입장벽도 낮은 편이다. 아스트로 파일 내부에서는 일반적인 HTML과 유사한 구조를 사용해 친숙하게 다가갈 수 있다. 게다가 React, Vue, Svelte 등과 같은 다양한 프레임워크와 함께 사용할 수 있다는 장점이 있다.

마음에 드는 astro 템플릿을 선택하고 git에서 clone 했다. 그 다음부터 본격적인 개발에 돌입했는데, 먼저 홈화면을 만들고, 상단 메뉴를 구성한 후, 각 메뉴별로 화면을 만들기시작했다. 작업 순서는 단순했다. 페이지 틀을 만들고, 내용을 채워넣은 후, 다자인을 다듬었다. 이 과정에서 로컬에서는 npm run dev 명령어로 바로바로 디자인 확인하면서 수정했다. 프론트엔드의 매력은 바로 이거다. 내가 바꾸면 바로 보인다. 백엔드와는 또 다른, 눈으로 보이는 개발의 즐거움인 것이다.

화면 개발이 마무리될 즈음, “이제 어디에 배포하지?”라는 고민이 시작됬다. 이 고민과 함께 도메인을 어디서 구매할지도 고민했다. netlify 등 여러 후보를 생각해봤지만 최종적으로 cloudflare를 선택했다. 이유는 단순했다. 도메인 구매와 소스코드 빌드와 배포를 한꺼번에 할수있다는 장점이 마음에 들었다. cloudflare와 내 Github 레포지토리를 연동하면 커밋만 하면 cloudflare가 바로 배포하는 구조였다. 이제 배포방식도 정해졌으니 로컬에서 마지막 빌드 테스트까지 마친 후. 드디어 github에 최종 push를 했다.

그리고나서 cloudflare에 연결 후 빌드가 잘되는지 확인하는데, 역시 로컬에서의 빌드와 클라우드에서의 빌드는 달랐다. 또 한번의 삽질 타임. 개발자라면 누구나 한번 쯤은 이런 경험이 있을 것이다. “로컬에서는 되는데 서버에서는 안돼요..” 익숙한 상황이었다. 삽질을 통해 몇가지 코드를 수정한 끝에 무사히 배포를 할 수 있었다.
참고로 Cloudflare에서는 SSR(Server-Side Rendering)과 Static(정적 사이트 생성) 두 가지 방식의 배포를 모두 지원한다.

Static 방식은 빌드 시점에 HTML 파일을 미리 생성해서 배포하는 방식이고, 변경이 자주 없는 콘텐츠를 다룰때 많이 사용하는 방식이다. 이 방식은 유저가 페이지를 요청하면 이미 만들어져있는 정적 HTML, CSS, JS 파일로 바로 응답하는 형태이다. 이 방식은 응답 속도가 빠르다는 장점이 있으나 페이지 변경시 다시 빌드하고 배포해야한다는 특징이 있다. 사용 방법은 astro.config.mjs 파일에서 output: “static” 으로 작성하면 사용가능하다.

SSR(Server-Side Rendering) 방식은 사용자의 요청이 들어올때마다 서버에서 HTML을 실시간을 생성하는 방식이다. 빌드 시간은 짧지만 요청마다 서버 실행이 필요해서 속도는 다소 느릴 수 있다. 사용방법은 astro.config.mjs 파일에서 output: server 으로 작성하면 사용가능하다. 이 방법은 주로 대시보드나 사용자 로그인 정보 표시가 필요한 사이트에서 사용된다.

나는 정적 페이지만 있으면 충분하니까 static 방식을 선택했다.

이렇게 배포를 한 홈페이지를 보는데, 드디어 내 집에 처음으로 대문이 생긴 기분이었다. 물론 지금까지 내가 소중하게 운영하던 기술블로그도 있지만 홈페이지는 조금 다르게 다가왔다. 우리 회사의 이름을 걸고, 내가 만든 디자인과 구조로, “이게 나의 공간이다”라고 말해주는 느낌이랄까. 이제 막 첫 대문을 연 집에 앞으로 어떤 이야기들을 채워나갈지, 스스로도 꽤 기대된다.

그렇게 배포를 하고 나서 주변사람들에게 홍보를 했는데, 그제서야 눈에 안보이던 수정사항들이 하나둘 보이기 시작했다. 결국 배포 하자마자 바로 패치 모드에 돌입했는데, 다행히 지인들의 제보가 큰 도움이 되어, 실제 사용자 관점에서 필요한 수정 포인트들을 빠르게 반영할 수 있었다. 역시 혼자만의 시선으론 놓치는 부분이 많다. 운영은 혼자하지만, 완성은 함께 만들어가는구나 싶었다. 배포는 끝이 아니라 진짜 시작을 의미한다.

참 신기하게도, 배포 전에는 멀쩡해 보였던 것들이 막상 세상에 공개하고 나면 아쉬움으로 다가온다. 하지만 그게 자연스러운 것 같다. 진짜 완성은 배포 이후에야 시작되니까 말이다. 그러헥 피드백을 반영하고, 수정을 거듭하면서 현재의 홈페이지가 완성되었다.

그리고나서 검색엔진최적화(SEO, search engine optimization) 설정도 해주고 구글 애널리틱스 연결해서 내 홈페이지의 발자취를 느낄 수 있도록 마무리했다. 그리고 몇 분 후 애널리틱스 화면에 실시간 접속 3명이 떴다. 그 순간 심장이 두근거렸다. 이 세상 어딘가에서 누군가가 내가 만든 홈페이지를 보고 있구나.

이렇게 나의 홈페이지 만들기 드디어 완성!

마도학자 주식회사 홈페이지 방문하기

[딥러닝] RAG(Retrieval Augmented Generation) 논문 번역

Mon, 30 Dec 2024 00:00:00 +0900

RAG(Retrieval Augmented Generation) 논문 번역

0. Abstract

사전 학습된 대규모 언어 모델(large language model)은 파리미터에서 사실적 지식을 저장할 수 있으며, 다운스트림(downstream) NLP 작업에서 최첨단 성능을 달성하는 것으로 나타났다. 그러나 이러한 모델이 지식에 접근하고 정밀하게 조작하는 능력은 여전히 제한적이라서 지식 집약적 작업에서는 과제 특화적인 아키텍처에 비해 성능이 뒤쳐진다. 또한 의사결정에 대한 출처를 제공하고, 그들 세계의 지식을 업데이트 하는 것은 여전히 해결되지 않은 연구 과제로 남아있다. 명시적인(explicit) nonparametric 메모리에 대해 식별 가능한 접근 메커니즘으로 무장된 사전 학습 모델은 이 문제를 극복할 수 있지만, 현재까지는 추출 기반 다운스트림 작업에 대해서만 연구되었다. 이때 nonparametric이라는 단어의 뜻을 알아보자. 일반적인 언어모델은 학습 과정에서 지식을 모델의 파라미터에 암묵적으로 저장한다. 즉, 신경망 가중치 자체에 정보가 내재한다는 뜻이다. 반면 nonparametric 메모리는 외부 데이터 저장소처럼 작동하며, 학습된 가중치와는 별개로 유지된다. 또한 명시적(explicit)이라는 말은 메모리에 저장된 데이터가 구조적으로 정리되어 있으며, 명확하게 접근가능함을 의미한다. 이는 모델이 필요한 정보를 명확히 요청하고 검색할 수 있다는 것을 내포한다. 우리는 RAG(Retrieval Augmented Generation)를 위한 범용 파인튜닝 방식을 알아볼 것이다. 이때 RAG 모델은 사전 학습된 파라미터 메모리와 nonparameter 메모리를 결합하여 언어 생성을 수행한다. 우리는 이 논문에서 RAG 모델을 소개하는데, parametric 메모리는 사전 학습된 seq2seq 모델이고, nonparametric 메모리는 사전학습된 신경망 검색기(neural retriever)를 통해 접근하는 위키피디아의 밀집 벡터 인덱스(dense vector index)이다. 여기서 검색기(neural retriever)란 검색 쿼리에 대해 적절한 문서를 찾아오는 역할을 담당하는 데이터 검색의 핵심 컴포넌트를 의미한다. 검색기는 검색 쿼리를 해석하고 인덱스 데이터를 활용해 데이터를 찾고, 필터링을 한 후 쿼리와 가장 관련성이 높은 데이터만 선발해 리턴한다. 우리는 두가지 RAG 구성 방식을 비교할 것이다. 첫번째는 생성된 전체 시퀀스에 대해 동일하게 검색된 문서를 조건으로 사용하는 방식이고, 두번째는 토큰마다 다른 문서를 사용할 수 있는 방식이다. 우리는 다양한 지식 집약적인 NLP 작업에서 모델을 파인튜닝하고 평가했으며, 세가지 오픈 도메인 QA 작어벵서 새로운 최고 성능을 달성했다. 이는 파라미터 기반 seq2seq 모델과 과제에 특화된 검색-추출 아키텍처를 능가하는 결과이다. 언어 생성 작업에서, RAG 모델이 최첨단 파라미터 전용 seq2seq 기준 모델에 비해 더 구체적이고 다양하며, 사실적인 언어를 생성한다는 것을 발견했다.

1. Introduction

사전 학습된 신경망 언어 모델은 데이터로부터 상당히 깊이 있는 지식을 학습할 수 있다는 사실이 입증되었다. 이들은 외부 메모리에 접근하지 않고도 매개변수화된(parameterized) 암묵적 지식 베이스로서 이를 수행할 수 있다. 이런 발전은 흥미롭지만, 이와 같은 모델에는 몇가지 단점이 존재한다. 이들은 그들의 메모리를 쉽게 확장하거나 수정할 수 없으며, 그들이 한 예측에 대해 명확한 통찰을 제공하기 어렵고, 때로는 할루시네이션과 같은 잘못된 정보를 생성할 수도 있다. 파라미터 매모리와 non-parametric(즉, 검색기반) 메모리를 결합한 하이브리드 모델은 이러한 문제 중 일부를 해결할 수 있다. 이러한 모델은 지식을 직접 수정하고 확장할 수 있으며, 접근한 지식을 검사하고 해석할 수 있기 때문이다. REALM과 ORQA는 최근 도입된 모델로서, 마스킹된 언어 모델과 미분 가능한 검색기(differentiable retriever)를 결합한 방식을 사용한다. 이들은 오직 오픈 도메인 추출 질문 응답에만 초점이 맞춰져있다. 이때 미분 가능한 검색기(differentiable retriever)에 대해 알아보자. 키워드 매칭이나 규칙 기반으로 검색하는 과거의 전통적인 검색기와는 달리 미분 가능한 검색기(differentiable retriever)는 검색 과정 자체가 신경망으로 구성되어 있어, 딥러닝 모델처럼 학습 가능하다. 이들은 검색 결과를 모델의 손실 함수에 연결하여, 검색기의 파라미털플 미분 및 업데이트 할 수 있다.

(Figure 1.)

여기에서 우리는 NLP의 주력 모델인 seq2seq 모델에 하이브리드 파라미터 메모리와 non-parametric 메모리를 도입한다.

우리는 사전 학습된 파라미터 메모리 생성 모델에 non-parametric 메모리를 추가하여, 검색 증강 생성(Retrieval-Augmented Generation, RAG)라고 부르는 범용(general-purpose) 파인튜닝 방식을 통해 이를 구현한다. 우리는 RAG 모델을 구축했다. 우리가 구축한 RAG 모델에서 파라미터 메모리는 사전 학습된 seq2seq 트랜스포머이고, non-parametric 메모리는 사전 학습된 신경망 검색기를 통해 접근하는 위키핃디아의 밀집 벡터 인덱스(dense vector index)이다. 우리는 이러한 구성 요소를 확률적 모델로 결합하여 엔드투엔드(end-to-end) 방식으로 학습한다. 이는 figure1에서 확인할 수 있다. 검색기(Dense Passage Retriever, 이하 DPR)는 인풋에 따라 잠재 문서를 제공한다. 이후 seq2seeq 모델(BART)은 이 잠재 문서와 입력을 함께 조건으로 사용하여 출력을 생성한다. 우리는 잠재 문서를 통해 상위-K 근사를 사용해 주변화(marginalize)한다. 이는 출력 단위로(모든 토큰에 대해 동일한 문서가 책임진다고 가정) 수행하거나, 토큰 단위로(각 토큰에 대해 다른 문서가 책임진다고 가정) 수행할 수 있다. T5나 BART와 마찬가지로, RAG는 모든 seq2seq 작업에 대해 파인튜닝이 가능하며, 이 과정에서 생성기와 검색기가 공동으로 학습된다.

예전에 광범위한 연구가 있었는데, 이는 특정 작업에 맞춰 처음부터 학습되는 non-parametric 메모리를 시스템에 통합하는 아키텍처를 제안하는 연구였다. 예를 들어, 메모리 네트워크(memory network), 스택 증강 네트워크(stack-augmented network), 그리고 메모리 레이어(momory layer) 등이 이에 해당한다. 이에 반해, 우리는 파라미터 메모리와 non-parametric 메모리 구성 요소가 모두 사전 학습되고 광범위한 지식으로 사전 로드된 설정을 탐구한다. 중요하게도, 사전 학습된 접근 메커니즘을 사용함으로써 추가학습 없이도 지식에 접근하는 능력이 제공된다.

우리가 얻은 결과는 지식 집약적인 작업에서 파라미터 메모리와 non-parametric 메모리를 생성 과정에서 결합했을 때의 이점을 강조한다. 이러한 작업은 외부 지식 출처에 대한 접근 없이는 인간도 합리적으로 수행하기 어려운 과제들이다. 우리의 RAG 모델은 Open Natural Questions, WebQuestions, 그리고 CuratedTrec에서 최고 성능을 달성했으며, TriviaQA에서는 특화된 사전 학습 목표를 사용하는 최신 접근법을 크게 능가하는 성과를 보였다. 이 작업들이 추출 기반 작업임에도 불구하고, 우리는 제약 없는 생성 방식이 이전의 추출 기반 접근법을 능가하는 것을 발견했다. 지식 집약적인 생성 작업을 위해 MS-MARCO 와 Jeopardy 질문 생성 실험을 수행한 결과, 우리 모델이 BART 기준 모델에 비해 더 사실적이고, 구체적이며, 다양성이 높은 응답을 생성한다는 것을 발견했다. FEVER 사실 검증 작업에서, 우리는 강력한 검색 감독(Retrieval Supervision)을 사용하는 최첨단 파이프라인 모델에 비해 4.3% 이내의 성능 차이를 달성했다. 이때 검색 감독(Retrieval Supervision)이란 검색 기반 작업에서 학습 모델이 올바른 검색 결과를 반환하도록 가이드하기 위해 명시적인 정답 데이터를 제공하여 학습시키는 과정을 의미한다. 예를 들어, “Who is the president of the United States?”라는 질문에 검색 감독은 정답으로 “Donald Trump”가 포함된 문서를 지정한다. 마지막으로, 우리는 non-parametric 메모리를 교체하여 세상이 변화함에 따라 모델의 지식을 업데이트 할 수 있음을 증명한다.

2. Methods

우리는 RAG 모델을 탐구한다. 이 모델은 인풋 시퀀스 $x$를 사용해 텍스트 문서 $z$를 검색하고, 이를 타겟 시퀀스 $y$를 생성할 때 추가적인 컨텍스트로 활용한다. Figure 1에서 볼수있듯, 우리 모델은 다음과 같은 두 가지 구성 요소를 활용한다.

(1) 검색기 $p_{\eta}(z | x)$

파라미터 $\eta$를 사용하며, 쿼리 $x$에 대해 텍스트 문서의 분포(상위-K개로 제한됨)를 반환한다.

(2) 생성기 $p_{\theta}(y_{i} | x, z, y_{1:i-1})$

파라미터 $\theta$로 파라미터화 되며, 이전 $i-1$개의 토큰 $y_{1:i-1}$과 오리지널 인풋 $x$, 그리고 검색된 문서 $z$를 기반으로 현재 토큰 $y_i$를 생성한다.

검색기와 생성기를 엔드투엔드로 학습하기 위해, 우리는 검색된 문서를 잠재변수로 간주한다. 우리는 잠재 문서를 주변화(marginalize)하여 생성된 텍스트의 분포를 생성하는 두가지 모델을 제안한다. 이 모델들은 잠재 문서를 처리하는 방식에서 차이를 보인다. 첫 번째 접근법인 RAG-Sequence에서는 모델이 동일한 문서를 사용하여 각 대상 토큰을 예측한다. 두 번째 접근법인 RAG-Token은 각 대상 토큰을 서로 다른 문서를 기반으로 예측할수있다. 다음 절에서는 두 모델을 공식적으로 소개하고, $p_\eta$ 및 $p_\theta$의 구성 요소와 함께 학습 및 디코딩 절차를 설명한다.

2-1. Models

(1) RAG-Sequence model

RAG-Sequence model은 동일한 검색된 문서를 사용하여 전체 시퀀스를 생성한다. 기술적으로, RAG-Sequence 모델은 검색된 문서를 단일 잠재 변수로 취급하며, 이를 주변화(marginalize)하여 상위-K 근사를 통해 seq2seq 확률 $p(y|x)$를 계산한다. 구체적으로, 검색기를 사용하여 상위 $K$개의 문서를 검색하고, 생성기는 각 문서에 대해 아웃풋 시퀀스 확률을 생성한다. 이후, 이러한 확률들을 주변화(marginalize)하여 최종 아웃풋 확률을 계산한다.

$p_{RAG-Sequence}(y|x)\approx \sum_{z\in top-k(p(\cdot|x))}p_{\eta}(z|x)p_{\theta}(y|x,z)$

위 수식에서 우변은 다시 다음 식으로 정리할 수 있다.

$\sum_{z\in top-k(p(\cdot|x))}p_{\eta}(z|x)p_{\theta}(y|x,z) = \sum_{z\in top-k(p(\cdot|x))}p_{\eta}(z|x)\Pi_{i}^{N}p_{\theta}(y_{i}|x,z,y_{1:i-1})$

(2) RAG-Token Model

RAG-Token 모델에서는 각 대상 토큰에 대해 서로 다른 잠재 문서를 선택할 수 있으며, 이에 따라 주변화(marginalization)을 수행한다. 이는 생성기가 답변을 생성할 때, 여러 문서에서 콘텐츠를 선택할 수 있도록 한다. 구체적으로, 검색기를 사용하여 상위 K개의 문서를 검색한 후, 생성기는 각 문서에 대해 다음 출력 토큰의 분포를 생성한다. 이후, 이 분포를 주변화(marginalize)하고, 다음 출력 토큰에 대해 동일한 과정을 반복한다. 이를 공식적으로 정의하면 다음과 같다.

$p_{RAG-Token}(y|x) \approx \Pi_{i}^{N}\sum_{z\in top-k(p(\cdot|x))}p_{\eta}(z|x)p_{\theta}(y_{i}|x,z,y_{1:i-1})$

마지막으로, RAG는 대상 클래스를 길이가 1인 타겟 시퀀스로 간주하여 시퀀스 분류 작업에도 사용할 수 있다. 이 경우, RAG-Sequence와 RAG-Token은 동등하게 동작한다.

2-2. Retriever: DPR

검색 구성 요소 $p_{\eta}(z|x)$는 Dense Passage Retriever(DPR)에 가반한다. DPR은 다음과 같은 바이엔코더(bi-encoder) 아키텍처를 따른다.

$p_{\eta}(z|x) \propto exp(\textbf{d}(z)^{T}\textbf{q}(x))$

$\textbf{d}(z) = BERT_{d}(z), \textbf{q}(z) = BERT_{q}(z)$

여기서 $\textbf{d}(z)$는 $BERT_{BASE}$ 문서 인코더가 생성한 문서의 밀집 표현(dense representation)을 나타내며, $\textbf{q}(x)$ 또한 $BERT_{BASE}$에 기반한 쿼리 인코더가 생성한 쿼리 표현을 나타낸다. 상위 $k$개의 문서 $z$ 목록을 계산하는 $top-k(p_{\eta}(\cdot|x))$는 사전 확률 $p_{\eta}(z|x)$가 가장 높은 문서들을 찾는 문제로, 이는 최대 내적 검색(Maximum Inner Product Search, MIPS) 문제에 해당한다. 이 문제는 서브 선형 시간(sub-liear time)으로 근사적으로 해결할 수 있다. 우리는 DPR의 사전 학습된 바이엔코더를 사용해 검색기를 초기화하고 문서 인덱스를 구축한다. 이 검색기는 TriviaQA 질문과 Natural Question에 대한 답을 포함하는 문서를 검색하도록 학습되었다. 우리는 이 문서 인덱스를 non-parametric 메모리라고 부른다.

2-3. Generator: BART

생성기 구성 요소 $p_{\theta}(y_i | x, z, y_{1:i-1})$는 종류에 상관없이 어떠한 인코더-디코더 구조를 사용하여도 모델링 할 수 있다. 우리는 BART-large를 사용하는데, 이는 4억개의 파라미터를 가진 사전 학습된 seq2seq 트랜스포머에 해당한다. BART에서 인풋 데이터 $x$와 검색된 콘텐츠 $z$를 결합하여 생성할 때, 우리는 단순히 이들을 연결(concatenate)한다. BART는 노이즈 제거 목적(denoising objective)와 다양한 노이즈 생성 함수(noising function)를 사용하여 사전 학습되었다. BART는 다양한 생성 작업에서 최첨단 성능을 달성했으며, 유사한 크기의 T5 모델을 능가하는 성능을 보여준다. 우리는 BART 생성기 파라미터 $\theta$를 이후 파리미터 메모라라고 지칭할 것이다.

2-4. Training

우리는 어떤 문서를 검색해야 하는지에 대한 직접적인 감독 없이 검색기와 생성기 구성 요소를 공동으로 학습한다. 주어진 인풋/아웃풋 쌍 $(x_j, y_j)$으로 구성된 파인튜닝 학습 말뭉치(corpus)를 사용하여, 우리는 각 대상에 대한 부정적 주변 log-likelihood(negative marginal log-likelihood)를 최소화 한다. 이를 수식으로 표현하면 다음과 같다.

$\sum_{j}-\log{p(y_j | x_j)}$

이를 Adam 옵티마이저를 사용한 확률적 경사 하강법(stochastic gradient descent)로 최적화 한다. 학습 중에 문서 인코더 $BERT_d$를 업데이트 하는 것은 비용이 많이 든다. 이는 REALM이 사전 학습 중 수행하는 것처럼 문서 인덱스를 주기적으로 업데이트 해야하기 때문이다. 우리는 강력한 성능을 위해 이러한 단계가 필요하지 않음을 발견했으며, 문서 인코더(및 인덱스)는 고정된 상태로 유지하고, 쿼리 인코더 $BERT_q$와 BART 생성기만 파인튜닝 한다.

2-5. Decoding

테스트 시, RAG-Sequence와 RAG-Token은 $\text{argmax}_{y}p(y|x)$를 근사화 하기 위해 서로 다른 방식을 필요로 한다.

(1) RAG-Token

RAG-Token 모델은 다음과 같은 전이 확률(transition probability)을 가진 표준 자기 화귀(seq2seq) 생성기로 간주할 수 있다.

$p_{\theta}^{\prime}(y_i | x, y_{1:i-1}) = \sum_{z\in top-k(p(\cdot|x))}p_{\eta}(z_i | x)p_{\theta}(y_i | x, z_i, y_{1:i-1})$

디코딩을 위해, $p_{\theta}^{\prime}(y_i | x, y_{1:i-1})$를 표준 빔 디코더(beam decoder)에 삽입하여 사용할 수 있다.

(2) RAG-Sequence

RAG-Sequence의 likelihood $p(y | x)$는 일반적인 토큰 단위 likelihood로 분리되지 않으ㅏ므로, 단일 빔서치를 사용하여 해결할 수 없다. 대신, 각 문서 $z$에 대해 빔 서치를 실행하며, 각 가설을 $p_{\theta}(y_i | x, z_i, y_{1:i-1})$를 사용해 점수화 한다. 이 방식은 가설의 집합 $Y$를 생성하며, 이 중 일부는 모든 문서의 빔에서 나타나지 않을수도 있다. 가설 $y$의 확률을 추정하기 위해, $y$가 빔에 나타나지 않은 각 문서 $z$에 대해 추가적인 순방향 패스(forward pass)를 실행한다. 그런다음, 생성기의 확률을 $p_{\eta}(z | x)$와 곱한 후 주변화(marginalization)을 위해 빔 전체에서 확률을 합산한다. 우리는 이러한 디코딩 과정을 “Thorough Decoding”이라고 부른다. 아웃풋 시퀀스가 길어질 수록 $|Y|$(가설의 집합 크기)가 커질 수 있으며, 이는 많은 순방향 패스를 필요로 하게 된다. 더 효율적인 디코딩을 위해, 다음과 같은 추가 근사를 적용할 수 있다.

$p_{\theta}(y | x, z_i) \approx 0$

이는 $y$가 $x, z_i$에서의 빔 서치 중 생성되지 않았을 경우에 해당한다. 이 접근법은 후보 집합 $Y$가 생성된 후에는 추가적인 순방향 패스를 실행할 필요를 없애준다. 우리는 이러한 디코딩 과정을 “Fast Decoding”이라고 부른다.

[Python] 파이썬 아나콘다를 이용한 가상환경 관리

Mon, 16 Dec 2024 00:00:00 +0900

[윈도우]파이썬 아나콘다를 이용한 가상환경 관리(최근 수정 2024.05.23)

윈도우에서 파이썬 사용하시는 분들은 아나콘다(Anaconda) 많이 사용하시죠. 파이썬을 사용할때 가상환경 관리가 매우 중요한데요. 오늘은 아나콘다를 사용한 파이썬 가상환경 생성, 변경 같은 관리에 대해 알아보겠습니다. 아나콘다가 정책을 바꿈으로써 미니콘다를 활용해 설치해보도록 하겠습니다.

Anaconda Prompt 실행

시작 -> 관리자 권한으로 Anaconda Prompt 실행

이때 주의 하실 점은 반드시 관리자 권한으로 실행하셔야 합니다. 관리자 권한으로 실행 안하시면 작업하시다가 액세스 거부당하실 수 있습니다.

현재 상태 확인

// 아나콘다 버전확인
(base)C:\Users\admin> conda --version
conda 24.11.0

// 아나콘다 버전 업데이트
(base)C:\Users\cheolwon> conda update -n base -c defaults conda
(base) C:\WINDOWS\system32>conda --version
conda 24.11.1

// 아나콘다 가상환경 정보
(base) C:\Users\cheolwon>conda info --envs
# conda environments:
#
base                  *  C:\Program Files (x86)\Microsoft Visual Studio\Shared\Anaconda3_64

위 결과 창을 보시면 현재는 base 환경 밖에 없네요. 별표(*) 표시가 되어있는 곳이 현재 환경입니다. 또 콘솔가장 왼쪽에도 (base)라고 현재환경이 표시되어 있죠.

### 설치 가능한 파이썬 정보 확인
(base) C:\WINDOWS\system32>conda search python
Loading channels: done
# Name                       Version           Build  Channel
python                        2.7.13     h1b6d89f_16  pkgs/main
python                        2.7.13     h9912b81_15  pkgs/main
python                        2.7.13     hb034564_12  pkgs/main
...

가상환경 추가

// 파이썬 3.7.6 버전 설치 및 가상환경 추가
// 문법: conda create --name 자신이원하는가상환경이름 python=파이썬버전
(base) C:\Users\cheolwon>conda create --name py3_12_8 python=3.12.8

//추가된 가상환경 확인
(base) C:\Users\cheolwon>conda info --envs
# conda environments:
#
base                   *  C:\ProgramData\Anaconda3
py3_12_8                  C:\Users\stoic\.conda\envs\py3_12_8

가상환경 변경

// 가상환경 py3_12_8 변경
(base) C:\Users\cheolwon>conda activate py3_12_8

(py3_12_8) C:\Users\cheolwon>conda info --envs
# conda environments:
#
base                     C:\ProgramData\Anaconda3
py3_12_8              *  C:\Users\stoic\.conda\envs\py3_12_8

// 가상환경 해제
(py3_12_8) C:\Users\cheolwon>conda deactivate
(base) C:\Users\cheolwon>

가상환경 라이브러리 추가

(base) C:\WINDOWS\system32>conda activate py3_12_8
(py3_12_8) C:\Users\stoic>pip install numpy
(py3_12_8) C:\Users\stoic>pip install pandas
(py3_12_8) C:\Users\stoic>pip install pyarrow
(py3_12_8) C:\Users\stoic>pip install matplotlib
(py3_12_8) C:\Users\stoic>pip install seaborn
(py3_12_8) C:\Users\stoic>pip install flask  
(py3_12_8) C:\Users\stoic>pip install gunicorn  
(py3_12_8) C:\Users\stoic>pip install flask-restful
(py3_12_8) C:\Users\stoic>pip install tensorflow==2.0.0
(py3_12_8) C:\Users\stoic>pip install torch torchvision torchaudio   (파이토치 CPU버전)  
(py3_12_8) C:\Users\stoic>pip install beautifulsoup4
(py3_12_8) C:\Users\stoic>pip install selenium
(py3_12_8) C:\Users\stoic>pip install psycopg2-binary     (파이썬-posgreSQL 연결)  
(py3_12_8) C:\Users\stoic>pip install cryptography
(py3_12_8) C:\Users\stoic>pip install finance-datareader
(py3_12_8) C:\Users\stoic>pip install opencv-python
(py3_12_8) C:\Users\stoic>pip install django
(py3_12_8) C:\Users\stoic>pip install pycaret  

키움증권을 이용하고 싶다면 다음 코드 추가 pykiwoom을 사용하기 위해서는 pyqt5가 우선적으로 설치되어 있어야한다.

(py3_12_8) C:\Users\stoic>pip install pyqt5
(py3_12_8) C:\Users\stoic>pip install pykiwoom

추천시스템을 이용하고 싶다면 다음 코드 추가

(py3_12_8) C:\Users\stoic>pip install scikit-surprise
(py3_12_8) C:\Users\stoic>pip install implicit    
(py3_12_8) C:\Users\stoic>pip install lightfm  

scikit-surprise를 설치하려면 그전에 C++ 빌드 툴이 설치되어 있어야한다.

주피터 노트북에 가상환경 추가 및 실행

사용 문법은 다음과 같습니다.

python -m ipykernel install –user –name [virtualEnv] –display-name “[displayKenrelName]”

아래코드를 이용해서 실제로 주피터노트북에 가상환경을 추가해보겠습니다.

(base) C:\WINDOWS\system32>conda activate py3_11_9
(py3_12_8) C:\Users\stoic>pip install jupyter
(py3_12_8) C:\Users\stoic>pip install ipykernel
(py3_12_8) C:\Users\stoic>python -m ipykernel install --user --name py3_12_8 --display-name "python3_12_8"
(py3_12_8) C:\Users\stoic>jupyter notebook

가상환경 삭제

// 가상환경 삭제
// 문법: conda remove --name YOUR_ENV_NAME --all
(base) C:\Users\cheolwon>conda remove --name py3_12_8 --all

오류 대처

주피터 노트북을 실행했을 때 커널이 실행되지 않고 다음과 같은 오류 메시지가 뜰 수 있습니다.

ImportError: DLL load failed while importing win32api: 지정된 모듈을 찾을 수 없습니다.

만약 위와 같은 오류가 나타난다면 다음과 같은 코드를 실행해 줍시다.

(py3_12_8) C:\WINDOWS\system32> conda install -c anaconda pywin32

[딥러닝] Attention is all you need 논문 번역

Tue, 03 Dec 2024 00:00:00 +0900

Attention is all you need 논문 번역

0. Abstract

대부분의 시퀀스 변환 모델들은 복잡한 순환신경망(RNN)이나 합성곱신경망(CNN)을 기반으로 하는 경우가 많았고, 이러한 신경망들은 인코더(encoder)와 디코더(decoder)를 포함한다. 또한 성능이 가장 뛰어난 모델들은 어텐션 메커니즘을 통해 인코더와 디코더를 연결한다. 우리는 이 논문에서 트랜스포머(Transformer)라는 아주 단순한 신경망 구조를 제안한다. 이 트랜스포머라는 구조는 RNN이나 CNN은 제거하고 단순히 어텐션 메커니즘을 기반으로 하는 아주 간단한 구조이다. 우리는 번역 업무를 수행하는 두 종류의 인공지능으로 실험을 했는데, 트랜스포머 기반의 모델이 품질이 더 우수했으며 병렬처리 하기 좋고, 학습하는 시간도 적게들었다. 우리 모델은 WMT 2014 영어-독일어 번역 업무에서 28.4 BLEU를 기록했는데, 이는 기존 기록보다 2 BLEU 이상 좋은 성능을 보여주면서 기존 베스트 기록을 갈아치웠다. 그리고 WMT 2014 영어-프랑스 번역 업무에서는 단일 모델 기준, 41.8 BLEU라는 초대 신기록을 달성했는데, 이는 3.5일 동안 8개의 GPU로 학습한 결과이고 흔히 말하는 베스트 모델에 비해 현저히 적은 리소스로 학습한 것을 의미한다. 트랜스포머 구조는 대규모 학습 데이터냐 제한된 학습 데이터냐에 상관없이 영어 구문 분석에서 성공적으로 적용할 수 있음을 보여주었다.

1. Introduction

RNN, LSTM, GRU와 같은 모델들은 언어 모델이나 기계번역과 같은 시퀀스 모델링이나 변환 문제에서 대세로 자리잡았습니다. 그리고 인코더-디코더 아키텍트를 발전시키기 위한 수많은 사람들의 노력이 있었다.

순환 모델들은 일바적으로 인풋이나 아웃풋 시퀀스의 기호 위치를 따라 팩터를 계산한다. 시퀀스의 기호 위치는 계산 과정에서 특정 스텝에 할당딘 후, 은닉 상태 $h_t$를 생성합니다. 이때 은닉 상태 $h_t$는 이전 은닉상태 $h_{t-1}$과 현재 시점 $t$에서의 인풋값의 함수이다. 그러나 이러한 방식으로는 학습과정에서 데이터의 병렬 처리를 어렵게 만들고 시퀀스 길이가 길어질수록 더 큰 문제가 된다.
왜냐하면 메모리 제약조건이 데이터간 배치를 제한하기 때문이다. 최근 연구에서는 팩토라이제이션 트릭과 조건부 계산을 활용해 계산 효율성을 높이고, 조건부 계산의 경우에는 모델 성능도 끌어올렸다. 그러나 순차적으로 계산된다는 근본적인 제약조건은 여전히 남아있는 상태였다.

어텐션은 인풋/아웃풋 시퀀스 내의 거리에 상관없이 의존성을 모델링 가능하게 만들어, 다양한 작업에서 강력한 시퀀스 모델링 통합이나 변환 모델의 필수 요소가 되었다. 그러나 일부 예외케이스를 제외하면 이러한 어텐션 메커니즘은 대부분 RNN과 함께 사용된다.

이 연구에서는 RNN을 배제하고, 대신 어텐션 메커니즘만을 사용해 인풋과 아웃풋 간의 의존성을 모델링하는 Transformer라는 모델 아키텍처를 제안한다. Transformer는 병렬 처리를 대폭 향상 시키며, 8개의 P100 GPU에서 단 12시간의 훈련만으로 번역에서 최고의 성능을 보여준다.

2. Background

순차적 계산을 줄이기 위한 목표는 Extended Neural GPU, ByteNet, ConvS2S와 같은 모델들의 기반을 형성한다. 이러한 모델들은 기본적으로 CNN을 사용하며 모든 인풋/아웃풋 위치에 대해 은닉 표현(hidden representation)을 병렬처리로 계산한다. 그리고 이러한 모델들은 엄청난 양의 연산을 요구한다. 왜냐하면 임의의 두 인풋 또는 아웃풋 위치 간의 신호를 연결하는데 필요한 연산 횟수가 위치간 거리에 따라 증가하기 때문이다. ConvS2S는 선형적으로, ByteNet의 경우 로그 함수 형태로 증가한다. 이는 먼 위치간의 의존성을 학습하는 것을 더 어렵게 만든다. 반면, 트랜스포머에서는 연산 횟수가 상수형태로 일정하다는 장점이 있지만, 이를 위해 어텐션 가장치가 적용된 위치를 평균화하기 때문에 모델이 정보를 구분하고 세밀하게 표현하는 능력이 감소한다는 단점이 있다. 이러한 효과는 3.2절에서 설명한 Multi-Head Attention을 통해 보완한다.

Self-attention은 때로 intra-attention이라고도 불리는데, 이는 하나의 시퀀스 내의 서로 다른 위치들을 연관지어 그 시퀀스의 표현(representation)을 계산하는 어텐션 메커니즘이다. Self-attention은 다양한 역할을 수행하는데, 예를 들어, 독해, 요약, 텍스트 함의 분석 등과 같은 문장 표현 학습을 포함한 다양한 역할을 수행한다.

End-to-end 메모리 네트워크는 시퀀스 정렬된 순환 대신 순환 어텐션 메커니즘을 기반으로 하며, 간단한 언어 질문 답변 및 언어 모델링 관련해서는 좋은 성능을 보이는 것으로 알려져있다. 여기서 시퀀스 정렬(sequence alignment)라는 말은 입력 시퀀스의 각 위치가 시간 순서대로 단계별로 처리되는 것을 의미한다.

우리가 아는 한 트랜스포머는 시퀀스 정렬된 RNN이나 합성곱 없이도 인풋/아웃풋 표현을 계산하기 위해 self-attention만 사용하는 최초의 변환 모델이다. 다음 섹션에서는 트랜스포머를 설명하고, self-attention을 사용하는 이유를 알아보며, 다른 모델에 비해 가지는 장점에 대해 논의해보자.

3. Model Architecture

대부분의 뛰어난 신경망 기반 시퀀스 변환 모델들은 인코더-디코더 구조로 구성되어 있다. 이 구조에서 인코더는 인풋 시퀀스 $x=(x_1, … , x_n)$를 $z=(z_1, …, z_n)$로 매핑한다. 이때 $x$는 (“I”,”love”,”you”)와 같은 기호 표현을 의미하고, $z$는 ((0.2, 0.3, -0.1),(0.5, -0.4, 0.2),(-0.1, 0.8, 0.3))과 같은 연속형 숫자 표현을 의미한다. 그 후에 디코더는 $z$를 기반으로 출력 시퀀스 $(y_1, …, y_m)$을 한번에 하나씩 생성한다. 이때 디코더는 자기회귀(auto-regressive) 방식으로 작동하며, 이전에 생성된 기호들을 다음 기호를 생성할 때 추가적인 입력으로 사용한다.

Figure 1. The Transformer - model architecture

트랜스포머는 위 그림과 같은 전체적은 구조를 따른다. 이 트랜스포머는 self-attention을 쌓은 형태와 각각의 단어가 별도로 처리되는(point-wise) 완전 연결(full connected) 레이어를 활용해 인코더와 디코더를 구성한다.

이 구조는 figure1의 왼쪽과 오른쪽 그림에서 각각 볼 수 있다. 왼쪽 그림은 인코더 구조, 오른쪽 그림은 디코더 구조를 보여준다. 인코더와 디코더는 각각 self-attention 메커니즘을 통해 입력 시퀀스 간의 관계를 계산하고, 이어지는 full connected layer를 통해 최종 출력을 생성한다.

3.1. Encoder and Decoder Stacks

Encoder

인코더는 $N=6$개의 동일한 레이어로 구성된 스택 구조이다. 그리고 각 레이어는 두개의 서브 레이어를 포함한다. 첫 번째 서브 레이어는 Multi-head self attention 메커니즘으로, 인풋 시퀀스 내의 위치 간 의존성을 계산한다. 두 번째 서브 레이어는 각각의 단어가 별도로 처리되는(position-wise) 완전 연결(full connected) 피드포워드 네트워크로, 인풋 데이터를 개별적으로 처리하며 비선형 변환을 수행한다. 이렇게 두개의 서브레이어 주변에는 잔차 연결(residual connection) 후에 레이어 normalizaiton을 사용한다.
즉, 각 서브 레이어의 아웃풋은 다음과 같다. 인풋 $x$와 인풋 $x$가 서브레이어를 통과한 아웃풋인 $sublayer(x)$를 더한 다음 normalizaiton을 수행한다. 이를 수식으로 나타내면 다음과 같다.

$LayerNorm(x + sublayer(x))$

이러한 잔차연결을 용이하게 하기 위해서, 모델 내부의 임베딩 레이어를 포함한 모든 서브 레이어에 아웃풋 차원 $d_{model}=512$로 설정한다.

Decoder

디코더는 $N=6$개의 동일한 레이어로 구성된 스택 구조를 가진다. 각각의 레이어에는 두개의 서브 레이어가 존재하는것 까지는 인코더 레이어와 유사하지만 디코더에는 세번째 서브 레이어가 추가되는데, 세번째 서브레이어는 인코더 스택의 아웃풋에 대해 multi-head attention을 수행한다. 인코더와 유사하게, 서브 레이어 주변에 잔차 연결을 하고 normalization을 수행한다. 반면, 디코더 내부에 있는 self-attention 서브 레이어를 수정하여 특정 위치가 현재 이후에 나오는 위치를 참조하지 못하도록 한다. 즉, 미래 정보를 참조하지 못하도록 막는다는 뜻이다. 이러한 마스킹은 출력 임베딩이 오프셋만큼 이동된다는 사실과 결합되어 $i$번째 위치의 예측이 $i$ 이전 위치에서 알려진 아웃풋에만 의존할수있도록 보장한다.

3.2 Attention

어텐션 함수는 쿼리와 키-값 쌍의 집합을 아웃풋으로 매핑하는 방식으로 설명할 수 있다. 이때 쿼리(query), 키(key), 값(value), 아웃풋(output) 모두 벡터로 표현된다. 아웃풋은 값(value)의 가중합으로 계산되며, 각 값에 할당된 가중치는 해당 쿼리와 대응되는 키(key) 사이의 호환성 함수에 의해 계산된다. 예를들어 “I love apples”라는 문장을 번역하는 모델을 처리중이라고 했을때, 디코더가 “사과”라는 단어를 생성하려고 하는 상황이라고 가정하자. 이때 쿼리(query)는 디코더의 현재상태이며, 현재상태는 사과와 관련된 정보를 찾아야하는 상태를 의미이다. 쿼리를 예로 들면 (0.25, 0.35, 0.45)와 같은 벡터 형태를 띈다.
키(key)와 값(value)는 인코더가 입력 문장의 각 단어를 벡터로 변환한 단서다.

“I” -> key: (0.1, 0.2, 0.3), value: (0.5, 0.6, 0.7)
“love” -> key: (0.2, 0.3, 0.4), value: (0.6, 0.7, 0.8)
“apples” -> key: (0.3, 0.4, 0.5), value: (0.7, 0.8, 0.9)

아웃풋은 쿼리와 키 간의 유사도를 계산해 가장 관련성 높은 값들을 가중합한 값이다.

Figure2. 왼쪽) Scaled Dot-Product Attention, 오른쪽) 병렬로 실행되는 레이어로 구성된 멀티 헤드 어텐션

3.2.1 Scaled Dot-Product Attention

우리는 이 특정한 어텐션 방식을 “Scaled Dot-Product Attention”이라고 부르겠다. (figure2 참고) 인풋 데이터는 $d_k$ 차원의 쿼리와 키(key)와 $d_v$ 차원의 값(value)으로 구성되어 있다. 우리는 쿼리와 키 간의 내적을 계산한 뒤, 각 결과를 $\sqrt{d_k}$로 나누고 소프트맥스 함수를 적용해 값(value)에 대한 가중치를 얻는다.

실제로는 동시에 여러 쿼리들에 어텐션 함수를 적용하고, 행렬 Q에 함께 모아서 처리한다. 키와 값들 역시 행렬 k와 v에 함께 모아처리한다. 우리는 아웃풋 해열을 다음과 같이 계산할 수 있다.

$Attention(Q, K, V) = softmax(\frac{QK^{T}}{\sqrt{d_k}})V$

가장 흔하게 사용되는 어텐션 함수는 additive(가산) attention과 dot-product(내적) 어텐션이다. 내적 어텐션은 $1/\sqrt{d_k}$ 스케일링 요소만 추가된 것을 제외하면 우리 알고리즘(Scaled Dot-Product Attention)과 동일하다. 가산 어텐션은 호환성 함수를 계산할 때, 단일 은닉층을 가진 피드포워드 네트워크를 사용한다. 이러한 두 방식은 이론적인 복잡도가 비슷하지만, 내적 어텐션은 매우 최적화된 행렬 곱셈 코드로 구현할 수 있으므로 실제로 훨씬 빠르고 메모리 효율적이다. 즉, 가산 어텐션은 은닉층을 활용해 호환성을 계산하고, 내적 어텐션은 단순히 내적을 사용하는데, 내적 어텐션이 더 빠르고 효율적이라고 할 수 있다.

$d_k$가 작을 때는 두 방법의 성능이 비슷하지만 $d_k$가 클 경우에는 스케일링이 없는 내적 어텐션은 가산 어텐션보다 성능이 떨어진다. $d_k$ 값이 클 경우, 내적 결과값이 매우 커지면서 소프트맥스 함수의 그래디언트가 매우 작은 영역(region)으로 밀려서 그런것이 아닐까 추측한다. 따라서 이러한 일을 예방하고 안정성을 확보하기 위해 내적 값에 $1/\sqrt{d_k}$을 곱하는 스케일링을 적용한다.

3.2.2 Multi-Head Attention

우리는 $d_{model}$ 차원의 키, 값, 쿼리를 사용해 단일 어텐션 함수를 수행하는 대신, 쿼리 키, 값을 각각 서로 다르게 학습된 프로젝션(linear projections)을 사용해 $d_k$, $d_k$, $d_v$ 차원으로 프로젝션(linear projections)하고 이를 h번 반복하는 것이 유리하다는 것을 발견했다. 이렇게 선형 변환된 쿼리, 키, 값에 대해 각각 병렬로 어텐션 함수를 수행하여 $d_v$차원의 아웃풋을 얻는다. 이 아웃풋들을 이어 붙여 서로 연결(concatenate)하고 다시 한번 선형 변환 한 뒤,
figure2에 묘사된 것과 같은 최종 값을 구할 수 있다.

멀티-헤드 어텐션은 모델이 다양한 표현 공간(Representation Subspace)에서 서로 다른 위치의 정보를 동시에 주목할 수 있게 한다. 단일 어텐션 헤드에서는 평균화로 인해 여러 정보가 하나로 합쳐지면서 구체적인 특징들이 희석될 수 있다. 그러나 멀티-헤드 방식은 각 헤드가 독립적으로 특정 특징을 학습할 수 있게 함으로써 모델의 표현력을 강화시킨다. 쉽게 말해서 여러개의 어텐션 헤드를 사용해 다양한 정보에 동시에 집중하는 것이다.

$MultiHead(Q, K, V) = Concat(head_1, …, head_h)W^{O}$
$where head_i = Attentino(QW_{i}^{Q}, KW_{i}^{K}, VW_{i}^{V})$

이때 프로젝션(projection, 선형 변환)에 사용되는 행렬들은 다음과 같은 매게변수 행렬로 정의 된다.

$W_{i}^{Q}\in \mathbb{R}^{d_{model} \times d_k}$
$W_{i}^{K}\in \mathbb{R}^{d_{model} \times d_k}$
$W_{i}^{V}\in \mathbb{R}^{d_{model} \times d_v}$
$W_{i}^{O}\in \mathbb{R}^{hd_{v} \times d_{model}}$

3.2.3 Applications of Attention in our Model

트랜스포머는 다음과 같은 3가지 방법으로 멀티-헤드 어텐션을 사용한다.

‘인코더-디코더 어텐션’ 레이어에서는 쿼리가 이전 디코더 레이어에서 생성되고, 메모리 키와 값은 인코더 출력에서 가져온다. 이러한 방법은 디코더의 모든 위치가 입력 시퀀스의 모든 위치에 주목할 수 있도록 한다. 이러한 방식은 [38, 2, 9]와 같은 시퀀스-투-시퀀스 모델에서 사용되는 일반적인 ‘인코더-디코더 어텐션’ 메커니즘을 사용한다. 즉, 인코더 디코더 어텐션은 디코더가 입력 전체 시퀀스 정보에 접근할 수 있게 해주는 메커니즘이다.
인코더는 셀프 어텐션(self-attention) 레이어을 포함하고 있다. 셀프 어텐션 레이어에서는 키, 값, 쿼리 모두 동일한 출처(place)로부터 생성되며, 여기서는 인코더의 이전 계층 아웃풋에서 나옵니다. 여기서 동일한 출처라는 말에 대해 알아보자. 일반적인 어텐션 메커니즘에서는 쿼리, 키, 값이 서로 다른 데이터 소스에서 올수 있다. 예를 들어 인코더-디코더 어텐션에서 쿼리는 디코더 아웃풋에서 생성되며 키와 값은 인코더 아웃풋에서 생성된다. 반면 셀프 어텐션에서는 쿼리, 키, 값이 모두 동일한 소스(ex. 이전 레이어 아웃풋, 인풋 데이터)에서 생성된다.
유사하게, 디코더의 셀프 어텐션 레이어는 디코더의 각 위치가 해당 위치까지의 모든 위치에 주목(attend)할 수 있도록 한다. auto-regressive 특성을 유지하기 위해 디코더에서 왼쪽 방향으로 정보가 흐르는 것(leftward information flow)을 방지해야한다. 이때, 왼쪽 방향으로 흐르는 것은 현재 위치 이후의 미래 단어가 과거로 정보를 제공하는 것을 의미한다. 이를 구현하기 위해 스케일 조정된 내적 어텐션(scaled dot-product attention)내에서 소프트맥스 인풋 중 불법적인 연결에 해당하는 모든 값을 마스킹 처리해 $-\infty$로 설정한다. Figure2를 참고하자.

3.3 Position-wise Feed Forward Networks

어텐션 서브 레이어 외에도 추가적으로, 인코더와 디코더의 각 레이어는 완전 연결(fully connected) 네트워크를 포함하며, 이는 각 위치에 개별적이고 동일하게 적용된다. 이 네트워크는 두 개의 선형 변환과 그 사이의 ReLU 활성화 함수로 구성된다.

$FFN(x)=max(0, xW_1 + b_1)W_2 + b_2$

선형 변환(linear transformation)은 다른 위치에도 전반적으로 걸쳐서 동일하지만, 레이어마다 서로 다른 파라미터를 사용한다. 이를 다르게 표현하면, 커널 크기가 1인 두개의 합성곱(convolution)으로 설명할 수 있다. 입력과 출력의 차원은 $d_{model}$, 내부 레이어의 차원은 $d_{ff}=2048$이다.

3.4 Embeddings and Softmax

다른 시퀀스 변환 모델과 유사하게, 우리는 학습된 임베딩을 사용하여 인풋 토큰과 아웃풋 토큰을 $d_{model}$ 차원의 벡터로 변환한다. 우리는 또한 디코더의 아웃풋을 다음 토큰의 예측 확률로 변환하기 위해, 학습된 선형 변환(linear transformation)과 소프트맥스 함수를 사용한다. 여기서 학습된 선형 변환이란 우리가 흔히 알고 있는 $wx + b$를 의미한다. 우리 모델에서는, 두개의 임베딩 레이어(인풋, 아웃풋)와 소프트맥스 이전 선형 변환 간 동일한 가중치 행렬을 공유한다. 이는 (30)에서 사용된 방법과 유사하다. 임베딩 레이어에서, 우리는 가중치 행렬에 $\sqrt{d_{model}}$을 곱한다.

Table 1: 다양한 레이어 유형에 대한 최대 경로 길이(Maximum path length), 레이어별 연산 복잡도(Per-layer complexity), 최소 순차 연산 수 (Minimum number of sequential operations)

Layer Type	Complexity per Layer	Sequential Operations	Maximum Path Length
Self-Attention	$O(n^2 \cdot d)$	$O(1)$	$O(1)$
Recurrent	$O(n \cdot d^2)$	$O(n)$	$O(n)$
Convolutional	$O(k \cdot n \cdot d^2)$	$O(1)$	$O(log_k (n))$
Self-Attention(restricted)	$O(r \cdot n \cdot d)$	$O(1)$	$O(n/r)$

3.5 Positional Encoding

우리 모델은 순환(recurrence)이나 합성곱(convolution)을 사용하지 않으므로, 시퀀스의 순서 정보를 활용하려면 토큰의 상대적 또는 절대적 위치 정보를 추가해야 한다. 이를 위해 포지셔널 인코딩(positional encoding)을 인풋 인베딩에 추가한다. 이는 인코더와 디코더 스택의 가장 바닥(bottom)에서 적용된다. 포지셔널 인코딩은 임베딩과 동일한 차원($d_{model})$을 가지며, 두 값을 합산 할 수 있도록 설계된다. 포지셔널 인코딩 방식에는 여러가지 선택지가 있는데, 학습 기반 방식과 고정(fixed) 방식이 있다.

포지셔널 인코딩은 시퀀스 내 각 토큰의 위치 정보를 벡터로 표현하여, 모델이 순서를 이해할 수 있게 한다. 이때 위에서 말한 고정 방식이란 주로 수학에서 말하는 사인이나 코사인 함수를 말한다.

“I love you”
“I” -> (0.5, 0.6, 0.7, 0.8)
“love” -> (0.6, 0.7, 0.8, 0.9)
“you” -> (0.7, 0.8, 0.9, 1.0)

예를 들어, 위와 같이 시퀀스 길이가 3이라고 하고, 임베딩 차원 $d_{model}=4$라고 하면 포지셔널 인코딩은 다음과 같다.

짝수 인덱스($2i$) : $sin(\frac{pos}{10000^{2i / d_{model}}})$
홀수 인덱스($2i+1$) : $cos(\frac{pos}{10000^{2i / d_{model}}})$

위 식은 짝수 차원은 사인 함수로 계산하고 홀수 차원은 코사인 함수로 계산하라는 뜻이다. 위와 같은 함수를 선택한 이유는, 해당 함수들을 사용했을 때 모델이 상대적인 위치를 쉽게 학습할 수 있을 것이라고 가정했기 때문이다. 왜냐하면 고정된 오프셋 k에 대해 $PE_{pos+k}$는 $PE_{pos}$의 선형함수로 표현될수 있기 때문이다. 이 말은 특정 위치에서 고정된 간격만큼 떨어진 다른 위치의 인코딩 값은 원래 위치의 인코딩 값과 선형적으로 연관되도록 설계된다는 뜻이다. 예를 들어 위 예제에서 I는 love 바로 앞에 있다라는 관계를 모델이 쉽게 이해할 수 있다.

예를 들어, 위 예제에서 “love”에 해당하는 단어는 포지션 1에 해당한다. 참고로 I는 포지션 0, you는 포지션 2에 해당함. 이를 POS=1이라고 하고 POS=1에 대해 포지셔널 인코딩을 진행하면 다음과 같다.

$i=0$, PE(1, 0) = $sin(\frac{1}{10000^{0/4}}) = sin(1) = 0.0001$
$i=1$, PE(1, 1) = $cos(\frac{1}{10000^{0/4}}) = cos(1) = 0.0001$
$i=2$, PE(1, 2) = $sin(\frac{1}{10000^{2/4}}) = sin(1/100) = 0.9999$
$i=3$, PE(1, 3) = $cos(\frac{1}{10000^{0/4}}) = cos(1/1000) = 0.9999$

위와 같이 정리하면 “love”에 대한 포지셔널 인코딩은 다음과 같다.

$PE(1) = [0.0001, 0.9999, 0.0001, 0.9999]$

그리고나서 기존 인풋 인베딩에 포지셔널 인코딩을 추가하면 다음과 같다.

“I” -> (0.5, 0.6, 0.7, 0.8) -> (0.5, 1.6, 0.7, 0.8)
“love” -> (0.6, 0.7, 0.8, 0.9) -> (0.6001, 1.6999, 0.8001, 1.8999)
“you” -> (0.7, 0.8, 0.9, 1.0) -> (0.7002, 1.7998, 0.9002, 1.9998)

위와 같은 고정 방식 말고도, 우리는 학습된 포지셔널 임베딩을 사용하는 실험도 진행했다. 사인, 코사인 기반 인코딩과 학습된 임베딩과 같은 두 방식이 거의 동일한 결과를 산출한다는 것을 발견했다. (표 3의 E행 참고) 우리는 사인파 기반 버전을 선택했는데, 이는 이 방식이 모델이 학습 중에 만나는 시퀀스 길이보다 더 긴 시퀀스에 대해 외삽(extrapolate)을 가능하게 하기 때문이다. 이때, 외삽은 학습 데이터 범위 밖에 있는 값을 추정하거나 예측하는 것을 의미한다. 예를 들어 학습 데이터에서 길이 10까지의 문장만 학습했다면, 길이 15의 문장을 처리하려는 시도가 외삽이다. 예를 들어, 내가 학습할 때 사용한 데이터는

“I love deep learning because it is fun.”

와 같이 단어 9개로 구성된 문장이었다면 실제 테스트 상황에서는 다음과 같이 17개 단어로 구성된 문장이 들어올 수 있다.

“The Transformer model is very powerful and works well for long sequences in natural language processing.”

위와 같은 경우, 학습된 포지셔널 임베딩을 사용할 경우, 학습 데이터에 등장했던 문장 길이에만 최적화되므로 학습 중에는 본적없는 길이 17의 문장에 대해서는 제대로 동작하지 않을수도 있다. 반면 사인파 기반 포지셔널 인코딩을 사용하는 경우, 문장의 길이가 길어지더라도 그대로 적용 가능하다.

4. Why Self-Attention

이번 섹션에서는 시퀀스 $(x_1, … ,x_n)$을 동일한 길이의 다른 시퀀스 $(z_1, … ,z_n)$로 매핑하는 데 일반적으로 사용되는 순환 레이어와 합성곱 레이어를 셀프 어텐션과 다양한 측면으로 비교한다. 이때 $x_i, z_i \in R^d$를 만족하는데 $x_i, z_i$는 스칼라가 아니라 벡터이며, 이들은 시퀀스 변환하는 인코더나 디코더에 있는 은닉 상태(hidden state) 벡터을 의미한다. 셀프 어텐션을 사용하기 위해서는 우리는 세가지 필요조건을 고여한다.

첫번째 필요조건은 레이어 당 총 계산 복잡도이다. 예를 들어 연산에 필요한 곱셈과 덧셈의 수 등을 합산하여 계산한다. 두번째 조건은 병렬화 할 수 있는 계산의 양인데, 이는 필요한 최소 순차 연산의 수로 측정된다. 이때, 병렬화 가능한 정도를 평가하기 위해 순차적으로만 수행해야하는 최소 작업수를 기준으로 삼는다는 점이다. 순차 작업이 적을 수록 병렬 처리가 더 효과적일 수 있다.

세번째 조건은 네트워크 내에서 장거리 의존성 간의 경로 길이(path length)이다. 여기서 장거리 의존성이란 시퀀스 내에서 서로 멀리 떨어진 단어 간의 관계를 의미한다. 이런 경우, 두 점을 연결하는 경로의 길이가 중요하다. 장거리 의존성을 학습하는 것은 많은 시퀀스 변환 작업에서 중요한 과제이다. 예를 들어 수많은 번역이나 음성처리에서 문장의 앞부분과 뒷부분의 관계를 학습한다. 이러한 의존성 학습에 영향을 미치는 주요 요인 중 하나는 네트워크에서 순방향 신호와 역방향 신호가 이동해야하는 경로의 길이이다. 신호가 짧은 경로로 전달될수록, 정보 손실이 줄어들며 학습이 더 쉬워진다. 이처럼 인풋/아웃풋 시퀀스의 모든 위치 조합 간 경로가 짧을수록, 장거리 의존성을 학습하기 더 쉬워진다. 따라서 우리는 서로 다른 레이어 유형으로 구성된 네트워크에서 모든 입력 및 출력 위치 간 최대 경로 길이를 비교한다.

표 1에서 언급한 바와 같이, 셀프 어텐션 레이어는 모든 위치를 상수 개수의 순차적으로 실행되는 연산으로 연결하는 반면, 순환 신경망 레이어는 O(n)개의 순차적인 연산을 요구한다. 즉, 셀프 어텐션은 모든 위치를 한번에 처리하는데, 순환 신경망은 시퀀스를 순차적으로 처리해야하므로 시간이 더 걸린다는 의미이다. 계산 복잡도 측면에서, 셀프 어텐션 레이어는 시퀀스 길이 n이 표현 차원 d보다 작을 때 순환 레이어보다 더 빠르다. (대부분의 경우 문장 길이는 표현 차원보다 짧기 때문에 셀프 어텐션이 더 효율적이다. 예를 들어 “I love you”는 문장에 3개의 단어가 있으므로 문장 길이는 3이 되고, I를 (0.2, 0.3, 0.5, 0.4, 0.1)로 표현한다면 단어를 나타내는 표현 차원은 5가 된다. ) 이는 단어 조각(word-piece)이나 바이트 쌍(byte-pair) 표현과 같은 최신 기계 번역 모델에서 사용하는 문장 표현에 해당하는 경우가 많다. 매우 긴 시퀀스를 처리하는 작업에서 계산 성능을 개선하기 위해, 셀프 어텐션은 입력 시퀀스에서 각각의 출력 위치를 중심으로 하는 크기 r의 이웃만 고려하도록 제한될 수 있다. 이렇게 하면 최대 경로 길이는 O(n/r)로 증가한다. 우리는 이 접근 방법을 향후 연구에서 더 조사할 계획이다.

단일 합성곱 계층은 커널 너비 k가 n보다 작을 때, 인풋과 아웃풋 위치간의 모든 쌍을 연결하지 못한다. 즉, k가 문장 길이보다 작으면 한번의 합성곱으로는 전체 입력과 출력 간의 관계를 연결할 수 없다는 뜻이다. 이 문제를 해결하려면 연속적인 커널(contiguous kernels)를 사용할 경우 O(n/k)개의 합성곱 레이어를 쌓아야하며, dilated convolution을 사용할 경우 $O(log_k(n))$ 레이어가 필요하다. 이는 경로의 길이를 늘려서 더 많은 계층을 쌓아야 한다는 것을 의미한다. 결과적으로 합성곱 레이어은 인풋과 아웃풋 간의 모든 관계를 연결하려면 더 많은 계층을 필요하므로 긴 경로를 다루기 어렵다는 의미이다. 합성곱 레이어는 일반적으로 순환 레이어보다 계산 비용이 k배 더 비싸다. 여기서 k는 커널 크기인데, 이 커널 크기만큼 계산 비용이 증가한다. 분리 가능한 합성곱(separable convolutions)을 사용하면 계산 복잡돌ㄹ 크게 줄일 수 있다. 이 경우, 계산 복잡도는 $O(k\cdot n \cdot d + n\cdot d^2)$로 줄어든다. 이때, n은 시퀀스 길이, d는 표현 차원이다. 분리 가능한 합성곱에서 $k=n$일 경우, 그 계싼 복잡도는 셀프 어텐션 계층과 포인트-와이즈(point-wise) 순전파 레이어의 조합과 동일한데, 이는 우리가 사용하는 방식이다.

셀프 어텐션 모델은 좀 더 해석 가능한 모델을 만들수 있다는 장점이 있다. 즉, 모델이 어떤 방식으로 작동하는지 더 쉽게 이해할 수 있다는 뜻이다. 우리는 모델에서 나온 어텐션 분포를 분석하고, 그 예시를 부록에 포함했다. 여기서 어텐션 분포란, 모델이 인풋 데이터에서 어느 부분에 집중하는지를 나타내는 값을 의미한다. 개별적인 어텐션 헤드(attention head)가 각기 다른 task를 학습하는 것이 분명할 뿐만 아니라, 많은 경우 구문(syntactic)과 의미(semantic) 구조와 관련된 행동을 보이는 것처럼 보인다. 즉, 모델이 문장에서 문법적인 구조와 의미적인 관계를 잘 이해하고 있다는 뜻이다.

5. Training

이번 섹션에서는 우리 모델의 학습 체계에 대해 알아보자.

5.1 Training Data and Batching

우리는 약 450만개의 문장 쌍으로 구성된 표준 WMT 2014 영어-독일어 데이터셋을 활용해 학습을 진행했다. 문장들은 바이트 쌍 인코딩(Byte-Pair Encoding, BPE)을 사용해 인코딩 했으며, 이 방식은 약 37,000개의 토큰으로 이루어진 공유된 소스-타켓 어휘를 가진다. 예를 들어 소스 어휘가 영어이고 “I”라면 타겟 어휘 독일어는 “Ich”가 된다. 영어-프랑스어의 경우, 36M개의 문장으로 구성된 WMT 2014 영어-프랑스어 데이터셋을 사용했고, 32000개의 어휘(vocabulary)로 분할했다. 문장 쌍은 대략적인 시퀀스 길이에 따라 배치로 묶었다. 학습 배치에는 약 25000개의 소스 토큰과 25000개의 타겟 토큰이 포함된 문장 쌍들이 포함되었다.

5.2 Hardware and Schedule

우리는 8개의 엔비디아 P100 GPU가 장착된 한대의 머신에서 모델을 학습시켰다. 본 논문에 설명된 하이퍼 파라미터를 사용한 기본 모델에서는 각 학습 단계마다 약 0.4초가 걸렸다. 우리는 기본 모델을 총 100,000 단계를 12시간 동안 훈련시켰다. 우리는 큰 모델(표 3의 가장 아래에 설명된 모델들)에서는 각 학습 단계마다 1초가 걸렸고, 300,000 단계, 즉, 3.5일 동안 학습 시켰다.

5.3 Optimizer

우리는 Adam 옵티마이저를 사용했으며, $\beta_1 = 0.9, \beta_2=0.98, \epsilon=10^{-9}$로 설정했다. 학습률 같은 경우에는 학습하는 과정에서 다음과 같은 식을 따르게끔 적용해서 다양한 학습율을 적용시켰다.

$lrate = d_{model}^{-0.5}\cdot min(stepnum^{-0.5}, stepnum\cdot warmupsteps^{-1.5})$

이는 첫번째 warmupsteps 학습 단계 동안 학습률을 선형적으로 증가시키고, 그 이후에는 학습률을 학습 단계 수의 제곱근의 역수에 비례하여 감소시키는 방식이다. 그리고 우리는 warmupsteps를 4000으로 설정했다.

5.4 Regularization

우리는 학습할 때 세가지 유형의 정규화 방식을 적용했다.

Table2. 트랜스포머는 이전의 최신 모델들보다 영어-독일어와 영어-프랑스어 newstest2014에서 더 높은 BLEU 점수를 달성했으며, 학습 비용은 더 적게 들어간다.

Model	EN-DE BLEU	EN-FR BLEU	EN_DE Cost	EN-FR Cost
ByteNet	23.75
Deep-Att + PosUnk		39.2		$1.0\cdot 10^{20}$
GNMT + RL	24.6	39.92	$2.3\cdot 10^{19}$	$1.4\cdot 10^{20}$
ConvS2S	25.16	40.46	$9.6\cdot 10^{18}$	$1.5\cdot 10^{20}$
MoE	26.03	40.56	$2.0 \cdot 10^{19}$	$1.2\cdot 10^{20}$

Dep-Att+ PosUnK Ensemble		40.4		$8.0\cdot 10^{20}$
GNMT + RL Ensemble	26.30	41.16	$1.8 \cdot 10^{20}$	$1.1\cdot 10^{21}$
ConvS2S Ensemble	26.36	41.29	$7.7 \cdot 10^{19}$	$1.2\cdot 10^{21}$

Transformer(base model)	27.3	38.1	$3.3 \cdot 10^{18}$	$3.3 \cdot 10^{18}$
Transformer(big)	28.4	41.8	$2.3 \cdot 10^{18}$	$2.3 \cdot 10^{18}$

Residual Dropout. 우리는 각 서브 레이어의 아웃풋에 드롭아웃을 적용한 후, 그것을 서브 레이어의 인풋에 더하고 정규화했다. 또한 인코더와 디코더 스택에서 임베딩과 포지셔널 인코딩의 합에 드롭아웃을 적용했다. 기본 모델에서는 드롭아웃 비율로 $P_{drop}=0.1$로 적용했다.

Label Smoothing. 학습하는 동안 $\epsilon_{ls}=0.1$ 값으로 라벨 스무딩을 적용했다. 이러한 방법은 모델의 Perplexity를 악화시키지만 모델이 더 확신을 갖지 않도록 학습하면서 정확도와 BLEU 점수를 향상 시킨다. 여기서 Perplexity는 언어 모델에서 모델의 예측 불확실성을 측정하는 지표로서 값이 낮을수록 모델이 예측을 잘한다는 의미이다.

6. Results

6.1 Machine Translation

WMT 2014 영어-독일어 번역 작업에서 big 트랜스포머 모델은 이전에 보고된 최고의 모델들 (앙상블 모델 포함)을 BLEU 점수에서 2점이상 능가하며 최고 BLEU 기록인 28.4를 기록했다. 이 모델의 구성은 표3의 가장 아래 줄에 나와있다. 학습은 8개의 P100 GPU를 활용해 3.5일 동안 진행되었다. 심지어 기본 모델도 이전에 발표된 모든 모델과 앙상블 모델을 능가하며, 경쟁 모델의 학습 비용에 비해 훨씬 적은 비용으로 성과를 낸다.

WMT 2014 영어-프랑스어 번역 작업에서, 우리가 만든 big 트랜스포머 모델은 41.0의 BLEU 점수를 기록하며, 이전에 발표된 모든 단일 모델들을 능가한다. 또한 이전 최첨단 모델의 훈련 비용보다 1/4 이하의 비용으로 훈련되었다. 영어-프랑스어 번역을 위한 big 트랜스포머 모델은 드랍아웃 비율은 0.3대신 $P_{drop}=0.1$을 사용했다.

기본 모델의 경우 체크포인트를 10분 간격으로 기록해, 10분마다 한번씩 모델의 상태(가중치, 옵티마이저 상태 등)를 저장했다. 마지막 5개의 체크포인트를 평균화하여 하나의 단일 모델을 생성했다. 큰 모델의 경우, 마지막 20개의 체크포인트를 평균화해서 구했다. 우리는 검색 알고리즘으로는 빔 서치(beam search)을 사용했으며, 빔 크기는 4로 설정하고 길이 패널티 $\alpha = 0.6$을 사용했다. 빔 서치는 시퀀스 생성 문제에서 가장 확률이 높은 시퀀스를 선택하는 방법이다. 이러한 하이퍼파라미터들은 개발 환경에서 실험 후에 선택되었다. 추론중 최대 출력 길이는 입력길이 +50으로 설정되었지만, 더 일찍 종료하는 것도 가능하다.

table 2는 우리 결과를 요약하고, 번역 품질과 학습 비용을 기존의 다른 모델 아키텍처들과 비교한다. 우리는 모델 학습에 사용된 부동 소수점 연산의 수에 학습 시간, 사용된 GPU 개수, 각 GPU의 지속적인 단 정밀도 부동소수점 연산 성능(sustained single-precision floating-point)에 대한 추정치를 곱하여 추정했다. sustained single-precision floating-point란 일정 시간 동안 지속적으로 처리할 수 있는 GPU의 최대 처리 용량을 의미한다. 컴퓨터에서는 숫자를 처리할 때, 부동 소수점(floating-point) 형식을 사용해서 실수를 표현하는데, 이때 단정밀도(single-precision)은 부동소수점 연산에서 32비트 형식을 사용하는 것을 의미한다. 그리고 sustained이라는 말은 “지속적인” 이라는 뜻인데, GPU는 이론적으로 매우 높은 성능을 발휘할 수 있지만, 실제 학습에서는 이론적인 최대성능과 실제 지속적으로 낼 수 있는 성능에는 차이가 있다. sustained performance는 GPU가 일정 시간 동안 안정적으로 제공할 수 있는 성능을 의미한다.

6.2 Model Variations

트랜스포머의 다양한 구성 요소의 중요성을 평가하기 위해, 우리는 기본 모델을 여러 방식으로 변경하고, 개발 세트 newstest2013에서 영어-독일어 번역 성능의 변화를 측정했다. 우리는 이전 섹션에서 설명한 바와 같이 빔 서치(beam search)를 사용했지만, 이 과정에서는 체크포인트 평균화는 사용하지 않았다. 그 결과를 table3에서 확인할 수 있다.

table3. 트랜스포머 아키텍처의 변형. 나열되지 않은 값들은 기본 모델(base model)과 동일하다. 모든 평가는 영어-독일어 번역 개발 세트인 newstest2013에서 수행되었다. 표에 나열된 perplexity는 바이트 쌍 인코딩에 따라 워드피스 단위로 계산되었으며, 단어 당 perplexity와 비교해서는 안된다.

table 3의 (A)행에서, 우리는 어텐션 헤드의 수와 어텐션 키 및 값의 차원을 변경했으며, 계산량은 일정하게 유지했다. 단일 헤드는 최적 설정 대비 BLEU 점수가 0.9 낮으며, 헤드 수가 너무 많아져도 품질이 저하된다.

table 3의 (B) 행에서 우리는 어텐션 키 크기($d_k$)를 줄이면 모델 품질이 저하된다는 것을 관찰했다. 이것이 시사하는 바는 호환성을 결정하는 것이 쉽지 않으며, 내적보다 더 정교한 호환성 함수가 유용할 수도 있음을 말한다. (C), (D) 행에서는 예상대로 더 큰 모델이 더 좋은 성능을 보였고, 드롭아웃이 과적합을 피하는데 매우 유용하다는 사실을 확인했다. (E)행에서는 사인파 기반 포지셔널 인코딩을 학습된 포지셔널 임베딩으로 교체했으며, 기본 모델과 거의 동일한 결과를 관찰할 수 있었다.

6.3 English Constituency Parsing

트랜스포머가 다른 작업에서도 뛰어난 성능을 보이는지 평가하기 위해, 우리는 영어 구문 분석(constituency parsing) 실험을 진행했다. 이 작업은 특정한 도전 과제를 제시하는데, 아웃풋은 강한 구조적 제약을 따르며, 아웃풋이 입력보다 훨씬 길다는 특징이 있다. 또한 RNN seq2seq 모델들은 데이터가 작은 환경에서 좋은 성능을 보이지는 않았다.

우리는 $d_{model}=1024$인 4개의 레이어로 구성된 트랜스포머에 Penn Treebank의 Wall Street Journal(WSJ) 데이터셋을 넣어 학습했으며, 이때 약 40,000개의 학습 문장을 사용했다. 또한 반지도학습(semi-supervised setting) 환경에서 이 모델을 학습했으며, 이때 고신뢰(high-confidence) 및 BerkeleyParser 데이터셋을 사용했으며, 약 1700만개의 문장을 포함했다. WSJ 데이터만 사용하는 환경에서는 16,000개의 토큰으로 구성된 어휘를 사용했으며, 반지도학습 환경에서는 32,000개의 토큰으로 구성된 어휘를 사용했다.

Table 4. 영어 구문 분석에 사용된 트랜스포머(WSJ의 섹션 23에 대한 결과)

Parser	Training	WSJ 23 F1
Vinyals&Kaiser el al.(2014)	WSJ only, discriminative	88.3
Pertrov et al.(2006)	WSJ only, discriminative	90.4
Zhu et al.(2013)	WSJ only, discriminative	90.4
Dyer et al.(2016)	WSJ only, discriminative	91.7
Transformer(4 layers)	WSJ only, discriminative	91.3
Zhu et al.(2013)	semi-supervised	91.3
Huang&Harper.(2009)	semi-supervised	91.3
McClosky et al.(2006)	semi-supervised	92.1
Vinyals&Kaiser el al.(2014)	semi-supervised	92.1
Transformer(4 layers)	semi-supervised	92.7
Luong et al.(2015)	multi-task	93.0
Dyer et al.(2016)	generative	93.3

우리는 드롭아웃, 학습률, 그리고 빔 크기를 section 22 개발 세트에서 선택하기 위해 소수의 실험만 수행했으며, 다른 모든 하이퍼파라미터는 영어-독일어 기본 번역 모델에서 변경하지 않았다. 추론할때는 최대 출력 길이를 입력길이 + 300으로 증가시켰다. 우리는 WSJ만 사용하는 환경과 반지도 학습 환경 모두에서 빔 크기를 21로 $\alpha=0.3$으로 설정했다.

table 4의 결과는 특정 작업에 맞춘 세부적인 튜닝이 부족했음에도 불구하고, 우리의 모델이 놀라울 정도로 잘 작동한다는 것을 보여준다. 이는 RNNG(Recurrent Neural Network Grammar)을 제외한 모든 이전에 보고된 모델보다 더 나은 결과를 보여준다.

RNN seq2seq 모델과는 달리, 트랜스포머는 WSJ 학습 세트의 40,000개의 문장만으로 훈련했을 때도 Berkeley-Parser보다 더 나은 성능을 보여주었다.

7. Conclusion

이번 논문에서는 트랜스포머를 소개했다. 이는 어텐션 기반 최초의 시퀀스 변환 모델로, 인코더-디코더 아키텍처에서 가장 일반적으로 사용되던 순환 레이어를 다중 헤드 셀프 어텐션으로 대체했다.

번역 작업에서는 트랜스포머가 순환 레이어나 합성곱 레이어 기반 아키텍처보다 훨씬 빠르게 훈련될 수 있다. WMT 2014 영어-독일어 및 WMT 2014 영어-프랑스어 번역 작업 모두에서 우리는 최고의 성능을 달성했다. 영어-독일어 번역 작업에서는 우리 모델이 이전의 모든 모델(앙상블 모델 포함)을 능가했다.

우리는 어텐션 기반 모델의 미래에 대해 기대하고 있으며 이를 다른 작업에도 적용할 계획이다. 우리는 트랜스포머를 텍스트 이외의 입력 및 출력형태를 포함하는 문제로 확장할 계획이며, 이미지, 오디오 및 비디오와 같은 큰 입력 및 출력을 효율적으로 처리하기 위해 지역적(local), 제한된(restricted) 어텐션 메커니즘을 연구할 계획입니다. 생성 과정을 덜 순차적으로 만드는 것 또한 우리의 연구 목표중 하나이다.

우리가 학습과 평가에 사용했던 모델은 다음 url에서 확인할 수 있다. https://github.com/tensorflow/tensor2tensor

[Infra] 쿠버네티스(kubernetes)(2) 쿠버네티스 설치(Kubernetes install)

Mon, 27 May 2024 00:00:00 +0900

쿠버네티스(2) 쿠버네티스 설치와 환경 설정

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

0. 인트로 (최근 업데이트 2024.05.27)

이번 포스팅에서는 쿠버네티스를 설치해 보도록 하겠습니다. 쿠버네티스 설치는 꽤 어렵습니다. 하지만 차근차근 한 스텝씩 나가도록 합시다. 제 환경은 전체 서버 세 대 입니다. 한 대의 마스터노드, 두 대의 워커노드로 구성된 쿠버네티스 클러스터를 구축해보도록 하겠습니다.

1단계. swap disable

쿠버네티스 첫 단계로 swap 기능을 꺼야합니다. 이 때, 스왑(swap)이란 물리 메모리(RAM)의 용량이 부족할 때 하드 디스크의 일부 공간을 메모리 처럼 사용하는 것입니다. 쿠버네티스를 설치하기 위해서는 바로 이 스왑 기능을 꺼야합니다.

1-1. 스왑 가동 중인지 확인하기

먼저 마스터노드에 접속하고 스왑이 가동중인지 알아봅니다.

(마스터노드)$ free -h
              total        used        free      shared  buff/cache   available
Mem:          125Gi       1.0Gi       120Gi       4.0Mi       4.7Gi       123Gi
Swap:         8.0Gi          0B       8.0Gi

위 코드 처럼 ‘free -h’를 입력하면 스왑 영역 8G가 가동중인것을 알 수 있습니다. 스왑이 가동중인지 확인하는 방법은 아래와 같은 방법을 사용해도 됩니다.

(마스터노드)$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/dm-6                               partition       8388604 0       -2

스왑이 가동하는지 확인하는 또 한가지 방법은 위 코드처럼 ‘cat /proc/swaps’를 입력해서 스왑 영역을 확인하는 것입니다.

1-2. 스왑 기능 중지 시키기

그렇다면 이제 스왑 기능을 중지시켜봅니다.

(마스터노드)$ sudo -i
(마스터노드)# swapoff --all

코드는 위와 같이 간단합니다. sudo 권한으로 swapoff --all 커맨드를 입력합니다. 주의할 점은 작대기 1개 아니고 2개 입니다.(–all)

그렇다면 이제 스왑이 중단 뒤었는지 확인해 봅니다.

(마스터노드)# free -h
              total        used        free      shared  buff/cache   available
Mem:          125Gi       1.0Gi       120Gi       4.0Mi       4.7Gi       123Gi
Swap:            0B          0B          0B

‘free -h’ 커맨드로 확인해보니 스왑영역이 없는것을 볼 수 있습니다.

(마스터노드)# cat /proc/swaps
Filename                                Type            Size    Used    Priority

그리고 ‘cat /proc/swaps’ 커맨드로 확인해도 역시 스왑 영역이 없는 것을 볼 수 있습니다.

그리고 /etc/fstab 파일에서 swap 부분을 주석처리 해줍니다.

(마스터노드)# vim /etc/fstab
#/swapfile   none    swap    sw     0       0

그리고 다음과 같이 재부팅을 해줍니다.

(마스터노드)# shutdown -r now

1-3. 각 클러스터 서버마다 모두 스왑 기능 끄기

지금은 마스터 노드의 스왑 기능만 껐습니다. 같은 작업을 워커노드1, 워커노드2에도 해주세요. 모두 스왑 기능을 꺼줍니다.

1-4. 브릿지 네트워크 설정

(마스터노드)# sudo modprobe br_netfilter
(마스터노드)# sudo sysctl net.bridge.bridge-nf-call-iptables=1
(마스터노드)# sudo sysctl net.ipv4.ip_forward=1

(마스터노드)# sudo vim /etc/sysctl.conf
아래 두줄 추가
net.bridge.bridge-nf-call-iptables=1
net.ipv4.ip_forward=1

2단계. hostname 설정

다음은 ‘/etc/hosts’ 파일에 모든 노드(마스터노드, 워커노드1, 워커노드2)를 추가해줍니다. ‘/etc/hosts’파일은 IP주소와 도메인 이름을 매핑하는 파일입니다. 즉, 해당 IP 주소를 alias 이런 이름으로 부르겠다~라고 선언해주는 것입니다.

(마스터노드)# cat /etc/hosts
# /etc/hosts
0.0.1 localhost
0.1.1 ubuntu20

168.200.91  poc-dlinfo-db01
168.200.92  poc-dlinfo-web01
168.200.93  poc-dlinfo-gpu01

저는 위와 같은 세가지 서버(91,92,93)를 사용하도록 하겠습니다. 마찬가지로 모든 노드에 방문해서 hosts파일을 위와 같이 수정해주세요.

3단계. docker 설치

3.1. 도커 설치 확인

마스터노드, 워커노드1, 워커노드2에 모두 도커를 설치해 줍니다. 도커 설치 방법은 도커 설치 링크를 참고해주세요.

도커를 설치했다면 버전을 확인합니다.

(마스터노드)# docker version
Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:54:27 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

3.1. containerd 적용

$ sudo mkdir -p /etc/containerd
$ containerd config default | sudo tee /etc/containerd/config.toml > /dev/null
$ sudo vim /etc/containerd/config.toml
중략
  [plugins.＂io.containerd.grpc.v1.cri＂.containerd.runtimes.runc]
    중략
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
      SystemdCgroup = true

위와 같이 SystemdCgroup 이 기존에는 false라고 되어 있는데 이를 true라고 바꿔줍니다.

$ sudo systemctl restart containerd
$ sudo systemctl enable containerd

$ sudo systemctl status containerd
● containerd.service - containerd container runtime
     Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-09-08 07:23:32 UTC; 16s ago
       Docs: https://containerd.io
   Main PID: 2521 (containerd)
      Tasks: 9
     Memory: 13.2M
        CPU: 128ms
     CGroup: /system.slice/containerd.service
             └─2521 /usr/bin/containerd

4단계. kubernetes 설치

자 이제 쿠버네티스를 설치할 준비가 되었습니다.

4-1. 인증 키 추가

먼저 쿠버네티스를 사용하기 전에 인증키를 추가할것인데 먼저 다음과 같이 사전 업데이트를 해주고 curl 같이 필요한 프로그램을 설치합니다.

(마스터노드)$ sudo apt-get update
(마스터노드)$ sudo apt-get install -y apt-transport-https ca-certificates curl
(마스터노드)$ sudo mkdir -p /etc/apt/keyrings

(마스터노드)$ sudo curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

(마스터노드)$ echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list

위 코드는 쿠버네티스 1.29 버전을 설치하는 코드입니다. 위 코드는 공식 홈페이지와 다르다는 점을 주의해주세요. 공식홈페이지에 나와있는 코드로는 다음 순서인 apt update가 되지 않습니다.

(마스터노드)# apt-get update
...(중략)
Reading package lists... Done

아까 업데이트했는데도 뭐가 주루룩 나오는 것을 볼 수 있는데 거의다 쿠버네티스 관련 내용입니다. 이거 apt-get update 안하고 쿠버네티스 설치하려고 하면 설치 안되니까 apt-get update 꼭 해주세요!

4-2. 쿠버네티스 설치

이제 대망의 쿠버네티스를 설치해보겠습니다.

(마스터노드)# sudo apt-get install -y kubelet kubeadm kubectl
Reading package lists... Done
Building dependency tree
Reading state information... Done
...(생략)

위와 같이 쿠버네티스가 잘 설치된 것을 볼 수 있습니다. (중간에 Y/N 선택하라는거 나오는데 Y 입력해주세요) 쿠버네티스가 잘 설치 되었는지 확인하기 위해 위 설치 코드를 다음과 같이 한번 더 입력해 봅니다.

(마스터노드)$ sudo apt-mark hold kubelet kubeadm kubectl
kubelet set on hold.
kubeadm set on hold.
kubectl set on hold.

이미 설치가 되었다고 나오는걸 보니 잘 설치가 된 것 같습니다.

(마스터노드)$ sudo -i
(마스터노드)# 

(마스터노드)#  kubelet --version
Kubernetes v1.29.5

(마스터노드)# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"29", GitVersion:"v1.29.5", GitCommit:"59755ff595fa4526236b0cc03aa2242d941a5171", GitTreeState:"clean", BuildDate:"2024-05-14T10:44:51Z", GoVersion:"go1.21.9", Compiler:"gc", Platform:"linux/amd64"}

(마스터노드)# kubectl version --output=yaml
clientVersion:
  buildDate: "2024-05-14T10:46:12Z"
  compiler: gc
...(중략)
  major: "1"
  minor: "29"
  platform: linux/amd64
kustomizeVersion: v5.0.4-0.20230601165947-6ce0bf390ce3

The connection to the server localhost:8080 was refused - did you specify the right host or port?

위와 같이 버전을 확인해도 잘 나오는 것을 볼 수 있습니다.

5단계: 모든 노드에 1~4단계

지금까지 1단계부터 4단계 까지의 과정을 나머지 노드에도 반복해서 해주세요.

6단계: 마스터노드 설정(kubeadm init)

앞서 세개의 서버에 모두 쿠버네티스를 설정했습니다. 그러나 아직 클러스터가 서로 연결되지 않았습니다. 누가 마스터노드이고 누가 워커노드인지 지정해주지 않았죠. 지금부터 할 작업이 이러한 것들을 지정하는 작업입니다. 마스터노드에 접속해서 니가 마스터다라고 지정해주고 워커노드를 붙여주는거죠. 짧게 요약하면 마스터노드에서 kubeadm init으로 마스터 노드를 초기화 하고, kubeadm join으로 워커노드를 초기화하고 클러스터에 연결합니다.

먼저 마스터노드 설정을 해보겠습니다. 작업을 하기전에 알아야 할게 kubeadm은 클러스터를 실행하는데 필요한 모든 인정서를 생성합니다. 따라서 마스터노드를 설정하기 위한 kubeadm init을 실행하기 전에 인증서를 받아야합니다.

먼저 현재 인증서 상태를 확인해봅니다.

(마스터노드)# kubeadm certs check-expiration
CERTIFICATE                          EXPIRES   RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
!MISSING! admin.conf
!MISSING! apiserver
!MISSING! apiserver-etcd-client
!MISSING! apiserver-kubelet-client
!MISSING! controller-manager.conf
!MISSING! etcd-healthcheck-client
!MISSING! etcd-peer
!MISSING! etcd-server
!MISSING! front-proxy-client
!MISSING! scheduler.conf

CERTIFICATE AUTHORITY      EXPIRES   RESIDUAL TIME   EXTERNALLY MANAGED
!MISSING! ca
!MISSING! etcd-ca
!MISSING! front-proxy-ca

위 결과를 보면 뭔가 인증이 하나도 안되어 있는 것을 볼 수 있습니다.
그럼 이제 설정 파일을 받아봅시다.

(마스터노드)# kubeadm config images pull --cri-socket /run/containerd/containerd.sock

I0526 06:40:06.287362   56259 version.go:256] remote version is much newer: v1.30.1; falling back to: stable-1.29
registry.k8s.io/kube-apiserver:v1.29.5
registry.k8s.io/kube-controller-manager:v1.29.5
registry.k8s.io/kube-scheduler:v1.29.5
registry.k8s.io/kube-proxy:v1.29.5
registry.k8s.io/coredns/coredns:v1.11.1
registry.k8s.io/pause:3.9
registry.k8s.io/etcd:3.5.12-0

위 코드와 같이 ‘kubeadm config images pull’를 입력하면 설정 이미지를 받을 수 있습니다.

다음으로 kubeadm init을 할 것인데 이는 마스터 노드를 초기화 하는 커맨드 입니다. kubeadm을 통해 만든 클러스터는 CNI(Container Network Interface) 기반의 애드온이 필요합니다. 여기서는 Calico라는 Pod 네트워크 애드온을 설치해 사용할 것입니다. 그리고 옵션으로 다음과 같은 것을 사용합니다.

–apiserver-advertise-address: 특정 마스터 노드의 API Server 주소를 설정할 때 사용합니다. ifconfig를 통해 마스터노드의 아이피를 확인해 넣습니다.
–pod-network-cidr: Pod 네트워크를 설정할 때 사용합니다. ‘192.168.0.0/16’은 calicoㅇㅔ서 권장하는 네트워크 대역이며, ‘10.244.0.0/16’은 Flannel에서 권장하는 네트워크 대역입니다.

이제 준비가 끝났습니다. 다음과 같이 커맨드를 입력합니다.

(마스터노드)# kubeadm init --apiserver-advertise-address=172.31.11.157 --pod-network-cidr=192.168.0.0/16 --cri-socket /run/containerd/containerd.sock
...(중략)...
To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 172.31.1.169:6443 --token kcq1nn.u9veawz8la9e6tmh \
        --discovery-token-ca-cert-hash sha256:133c891f9cfa4c78d397b60676eadce601a233084c8d108df9446a84ceb90554

설치가 잘 된 것을 볼 수 있습니다.

(마스터노드)# kubeadm certs check-expiration
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 May 26, 2025 06:41 UTC   364d            ca                      no
apiserver                  May 26, 2025 06:41 UTC   364d            ca                      no
apiserver-etcd-client      May 26, 2025 06:41 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   May 26, 2025 06:41 UTC   364d            ca                      no
controller-manager.conf    May 26, 2025 06:42 UTC   364d            ca                      no
etcd-healthcheck-client    May 26, 2025 06:41 UTC   364d            etcd-ca                 no
etcd-peer                  May 26, 2025 06:41 UTC   364d            etcd-ca                 no
etcd-server                May 26, 2025 06:41 UTC   364d            etcd-ca                 no
front-proxy-client         May 26, 2025 06:41 UTC   364d            front-proxy-ca          no
scheduler.conf             May 26, 2025 06:42 UTC   364d            ca                      no
super-admin.conf           May 26, 2025 06:41 UTC   364d            ca                      no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      May 24, 2034 06:41 UTC   9y              no
etcd-ca                 May 24, 2034 06:41 UTC   9y              no
front-proxy-ca          May 24, 2034 06:41 UTC   9y              no

인증도 문제 없는 것을 볼 수 있습니다.

6-2단계. kubeadm init 마무리

kubeadm init을 성공했다면 다음으로 위 성공 창의 안내문과 같이 다음 커맨드를 입력합니다. 아래 코드는 루트 사용자가 아닌 일반 사용자가 kubectl을 사용할 수 있게끔 권한을 부여하는 커맨드입니다. 일반 사용자로 로그인 하고 커맨드를 입력합시다.

(마스터노드)$ mkdir -p $HOME/.kube
(마스터노드)$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
(마스터노드)$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

7단계. calico 설치

참고사이트 : calico 홈페이지

(마스터노드)$ kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

(마스터노드)$ curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml -O

(마스터노드)$ ls
custom-resources.yaml

(마스터노드)$ kubectl create -f custom-resources.yaml

calico를 설치했다면 설치가 잘 되었는지 확인해보겠습니다.

$ watch kubectl get pods -n calico-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-786965f46c-5w6v6   1/1     Running   0          85s
calico-node-pr527                          1/1     Running   0          85s
calico-typha-95765f587-dwjdt               1/1     Running   0          85s
csi-node-driver-p52f9                      2/2     Running   0          85s

8단계. 설치 확인!

(마스터노드)# kubectl get pods --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-78fcd69978-52cnq                   0/1     Pending   0          27m
kube-system   coredns-78fcd69978-b8lj6                   0/1     Pending   0          27m
kube-system   etcd-poc-dlinfo-gpu01                      1/1     Running   1          27m
kube-system   kube-apiserver-poc-dlinfo-gpu01            1/1     Running   1          27m
kube-system   kube-controller-manager-poc-dlinfo-gpu01   1/1     Running   1          27m
kube-system   kube-flannel-ds-f72sp                      1/1     Running   0          13s
kube-system   kube-proxy-xscx7                           1/1     Running   0          27m
kube-system   kube-scheduler-poc-dlinfo-gpu01            1/1     Running   1          27m

잘 설치 된거 같은데 위 두개의 네임스페이스가 Pending이네요. 약 30분정도 기다렸다가 다시 확인하면 Running으로 잘 나옵니다. 저는 29분 걸렸네요.

(마스터노드)# kubectl get pods --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-78fcd69978-52cnq                   1/1     Running   0          29m
kube-system   coredns-78fcd69978-b8lj6                   1/1     Running   0          29m
kube-system   etcd-poc-dlinfo-gpu01                      1/1     Running   1          30m
kube-system   kube-apiserver-poc-dlinfo-gpu01            1/1     Running   1          30m
kube-system   kube-controller-manager-poc-dlinfo-gpu01   1/1     Running   1          30m
kube-system   kube-flannel-ds-f72sp                      1/1     Running   0          2m44s
kube-system   kube-proxy-xscx7                           1/1     Running   0          29m
kube-system   kube-scheduler-poc-dlinfo-gpu01            1/1     Running   1          30m

9. 옵션(마스터 노드에도 Pod생성하고 싶을때)

디폴트는 마스터노드에는 pod 스케쥴링을 하지 않습니다. 그러나 만약 자신이 마스터 노드에도 pod를 생성하고 싶다면 다음과 같이 입력합니다.

(마스터노드)# kubectl taint nodes --all node-role.kubernetes.io/master- 
node/poc-dlinfo-gpu01 untainted

10. Join 워커노드

(마스터노드)# kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>

11. Kubenetes cluster 재가동

$ sudo systemctl start kubelet

[Infra] 도커(docker)(6) 도커 컴포즈(docker compose)를 활용한 여러 개의 Flask, Nginx 배포

Sun, 26 May 2024 00:00:00 +0900

도커(docker)(6) 도커 컴포즈(docker compose)를 활용한 여러 개의 Flask, Nginx 배포

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

1. 개요

1-1. 구조 설계

먼저 이 작업을 하게 된 계기는 두 가지 프로젝트를 동시에 컨테이너로 띄워야해서 이걸 어떻게 해야하나하고 생각해보았습니다.

그래서 처음에 생각한 구조는 위 그림과 같이 ngnix 하나에 두 가지 앱이 물린 상태에서 돌아가는 형태였는데, 위와 같이 만들 경우, 앱 개수가 늘어나면 관리하기 어려워질것 같다는 생각이 들었습니다.

그래서 생각한 것이 위 그림과 같은 구조입니다. nginx 또한 여러 개의 컨테이너로 띄워서 각 앱에 물리게 설정하면 각 프로젝트는 다른 프로젝트에 영향을 받지 않고 돌아갈수 있고, 수정 배포가 용이할 것이라고 생각했습니다.

1-2. 폴더 구성

실습 폴더는 위와 같이 생겼습니다. kpt_supply_chain, kpt_intelli_design 두 프로젝트를 컨터이너화 해서 띄울 예정입니다.

2. 도커 컴포즈(docker compose)

2.1. 도커 컴포즈(docker compose)란?

도커 컴포즈(docker compose)는 여러 개의 컨테이너를 한번에 관리할 수 있는 도구입니다. 도커 컴포즈를 안쓰고 컨테이너를 올린다면 각각의 컨테이너를 일일히 올려야하고, 연동시켜야할 컨테이너가 있으면 손수 연동시켜줘야하는데, 도커 컴포즈를 쓰면 이런 작업들을 한번에 할수 있습니다.

2.2 도커 컴포즈(docker compose) 설치(마지막 수정 2022.12.15)

도커 컴포즈(docker compose)는 설치 관련 매뉴얼을 보고 설치했습니다. 저는 우분투에 설치했습니다. 다음은 홈페이지 상에 나와있는 코드입니다.

$ mkdir -p ~/.docker/cli-plugins/
$ curl -SL https://github.com/docker/compose/releases/download/v2.14.0/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
$ chmod +x ~/.docker/cli-plugins/docker-compose
$ docker compose version
Docker Compose version v2.14.0

참고로 도커 컴포즈는 버전1이냐 2냐에 따라 명령어 실행 방식이 조금 다릅니다. 이 점 주의해주세요.

3. 프로젝트1-kpt_intelli_design

3.1. kpt_intelli_design 폴더

다음 파일은 main.py 파일 입니다.

from urllib.parse import unquote
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/test', methods=['POST'])
def test():
    args = request.json
    print(args)
    sentence = args['review']
    sentence = urllib.parse.unquote(a)
    return sentence

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5002)

다음은 Dockerfile 입니다.

FROM python:3.8.5

WORKDIR /kpt_intelli_design

COPY . .
RUN python -m pip install --upgrade pip
RUN pip install -r requirements.txt
RUN pip install --upgrade protobuf==3.20.0

# server
CMD main:app gunicorn --bind 0.0.0.0:5002 --

다음은 requirements.txt 파일입니다.

Flask==2.0.1
gunicorn

3.2. nginx 폴더

다음은 Dockerfile 입니다.

FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY default.conf /etc/nginx/conf.d/
CMD ["nginx", "-g", "daemon off;"]

다음은 default.conf 파일입니다.

upstream kpt_int{
    server kpt_intelli_design:5002;
}


server{
    listen 8002;
    server_name 10.1.55.220;

    location /{
        proxy_pass http://kpt_int;
    }
}

위 코드 처럼 upstream을 이용해 짜거나 다음 코드처럼 짤수도 있습니다.

server{
    listen 8002;
    server_name 10.1.55.220;

    location /{
        proxy_pass http://kpt_intelli_design:5002;
    }
}

만약 타임아웃을 설정하고 싶다면 다음과 같이 default.conf 파일을 만들어줍니다.

upstream kpt_int{
    server kpt_intelli_design:5002;
}


server{
    listen 8002;
    server_name 10.1.55.220;

    location /{
        proxy_read_timeout 3000;
        proxy_connect_timeout 3000;
        proxy_send_timeout 3000;
        send_timeout 3000;
        
        proxy_pass http://kpt_int;
    }
}

만약 upstream을 사용하고 싶지 않다면 다음과 같이 작성합니다.

server{
    listen 8002;
    server_name 10.1.55.220;

    location /{
        proxy_read_timeout 3000;
        proxy_connect_timeout 3000;
        proxy_send_timeout 3000;
        send_timeout 3000;
        
        proxy_pass http://kpt_intelli_design:5002;
    }
}

참고로 쿠버네티스로 돌릴때는 다음과 같이 작성합니다.

default.conf

server{
        listen 8002;
        server_name 10.1.55.220;

        location /{
        proxy_read_timeout 3000;
        proxy_connect_timeout 3000;
        proxy_send_timeout 3000;
        send_timeout 3000;
        proxy_pass http://127.0.0.1:5002;
        }

}

3.3. docker-compose.yml 파일

다음은 docker-compose.yml 파일입니다. 만약 도커 컴포즈 버전이 v2.27.0 미만이라면 다음과 같이 version 태그를 적어줍니다.

version: "3"
services:
    kpt_intelli_design:
         build: ./kpt_intelli_design
         container_name: kpt_intelli_design
         restart: always
         expose:
             - "5002"

     nginx:
         build: ./nginx
         container_name: nginx-kpt-intelli
         restart: always
         ports:
             - "8002:8002"
         depends_on:
             - kpt_intelli_design

만약 도커 컴포즈 버전이 v2.27.0 이상이라면 다음과 같이 version 태그를 삭제해줍니다.

services:
    kpt_intelli_design:
         build: ./kpt_intelli_design
         container_name: kpt_intelli_design
         restart: always
         expose:
             - "5002"

     nginx:
         build: ./nginx
         container_name: nginx-kpt-intelli
         restart: always
         ports:
             - "8002:8002"
         depends_on:
             - kpt_intelli_design

3.4. 빌드 및 실행

$ docker compose up -d --build

...(중략)
[+] Running 3/3
 ⠿ Network kpt_intelli_design_default  Created 
 ⠿ Container kpt_intelli_design        Started 
 ⠿ Container nginx-kpt-intelli         Started   

$ docker container ls
CONTAINER ID   IMAGE                                   COMMAND                  CREATED         STATUS         PORTS                                               NAMES
dd8aad18b4ac   kpt_intelli_design_nginx                "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   80/tcp, 0.0.0.0:8002->8002/tcp, :::8002->8002/tcp   nginx-kpt-intelli
7504fb5725bf   kpt_intelli_design_kpt_intelli_design   "/bin/sh -c 'gunicor…"   2 minutes ago   Up 2 minutes   5002/tcp                                            kpt_intelli_design

4. 프로젝트2 - kpt_supply_chain

4.1. kpt_supply_chain 폴더

from urllib.parse import unquote
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/test', methods=['POST'])
def test():
    args = request.json
    print(args)
    sentence = args['review']
    sentence = urllib.parse.unquote(a)
    return sentence

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5001)

다음은 Dockerfile 입니다.

FROM python:3.8.5

WORKDIR /kpt_intelli_design

COPY . .
RUN python -m pip install --upgrade pip
RUN pip install -r requirements.txt
RUN pip install --upgrade protobuf==3.20.0

# server
CMD main:app gunicorn --bind 0.0.0.0:5001 --timeout 3000

다음은 requirements.txt 파일입니다.

Flask==2.0.1
gunicorn

4.2. nginx 폴더

다음은 Dockerfile 입니다.

FROM nginx
RUN rm /etc/nginx/conf.d/default.conf
COPY default.conf /etc/nginx/conf.d/
CMD ["nginx", "-g", "daemon off;"]

다음은 default.conf 파일입니다.

upstream kpt_sup{
    server kpt_supply_chain:5001;
}


server{
    listen 8001;
    server_name 10.1.55.220;
    
    location /{
         proxy_pass http://kpt_sup;
    }
}

만약 타임아웃을 설정하고 싶다면 다음과 같이 default.conf 파일을 만들어줍니다.

upstream kpt_sup{
    server kpt_supply_chain:5001;
}


server{
    listen 8001;
    server_name 10.1.55.220;
    
    location /{
         proxy_read_timeout 3000;
         proxy_connect_timeout 3000;
         proxy_send_timeout 3000;
         send_timeout 3000;

         proxy_pass http://kpt_sup;
    }
}

4.3. docker-compose.yml 파일

다음은 docker-compose.yml 파일입니다.

version: "3"
services:
    kpt_intelli_design:
         build: ./kpt_supply_chain
         container_name: kpt_supply_chain
         restart: always
         expose:
             - "5001"

     nginx:
         build: ./nginx
         container_name: nginx-kpt-supply
         restart: always
         ports:
             - "8001:8001"
         depends_on:
             - kpt_supply_chain

4.4. 빌드 및 실행

$ docker compose up -d --build

...(중략)
[+] Running 3/3
 ⠿ Network kpt_supply_chain_default  Created         
 ⠿ Container kpt_supply_chain        Started
 ⠿ Container nginx-kpt-supply        Started   

실행중인 컨테이너 확인

$ docker container ls
CONTAINER ID   IMAGE                                   COMMAND                  CREATED         STATUS         PORTS                                               NAMES
dd8aad18b4ac   kpt_intelli_design_nginx                "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   80/tcp, 0.0.0.0:8002->8002/tcp, :::8002->8002/tcp   nginx-kpt-intelli
7504fb5725bf   kpt_intelli_design_kpt_intelli_design   "/bin/sh -c 'gunicor…"   2 minutes ago   Up 2 minutes   5002/tcp                                            kpt_intelli_design
8d527613280d   kpt_supply_chain_nginx                  "/docker-entrypoint.…"   7 minutes ago   Up 7 minutes   80/tcp, 0.0.0.0:8001->8001/tcp, :::8001->8001/tcp   nginx-kpt-supply
8c822fb89350   kpt_supply_chain_kpt_supply_chain       "/bin/sh -c 'gunicor…"   7 minutes ago   Up 7 minutes   5001/tcp                                            kpt_supply_chain

컨테이너를 다 지우고 싶다면?

$ docker compose down
[+] Running 4/4
 ⠿ Container nginx-server        Removed
 ⠿ Container kpt_intelli_design  Removed 
 ⠿ Container kpt_supply_chain    Removed 
 ⠿ Network work_default          Removed   

[딥러닝] Large Language Model(claude3) 작동원리 논문 번역

Wed, 22 May 2024 00:00:00 +0900

arge Language Model(claude3) 작동원리 논문 번역

원본 논문: Scaling Monosemanticity: Extracting Interpretable Features from Claude3 Sonnet

0. Abstract

8개월 전, 우리는 sparse 오토인코더가 작은 one-layer 트랜스포머로부터 단일의미적(monosemantic) 피처를 복구시킬 수 있다는 점을 증명했다. 그 당시에 이 방법에 대해 주요 이슈는 최첨단 트랜스포머로 확장되기 어렵고, 그 결과 AI 안전에 실질적으로 기여하기는 어려울 것이라는 점이었다. 그 이후, sparse 오토인코더를 확장시키는 것이 Anthropic interpretability 팀의 주요과제가 되었고, Claude 3 Sonnet, 1 Anthropic’s 미디움 사이즈 프로덕션 모델로 부터 높은 퀄리티의 피처를 추출하는데 성공했다는 보고를 하게 되어 기쁘다.

우리는 고도로 추상적인 피처의 다양성을 발견했다.

[Infra] 아파치 카프카(kafka) 개념

Tue, 09 Jan 2024 00:00:00 +0900

아파치 카프카(kafka)의 개념

1. 아파치 카프카의 탄생

여러분들은 링크드인이라는 회사를 아시나요? 링크드인은 비즈니스 소셜 네트워크 서비스인데, 취준생이나 직장인 분들이라면 잘 아실 겁니다. 아파치 카프카는 링크드인의 데이터 통합 문제를 해결하기 위해 2010년에 개발되어 2011년에 출시되었습니다. 그리고 2012년에는 아파치 재단의 인큐베이션 프로젝트로 시작했습니다. 데이터는 단순히 트랜잭션의 기록에 머물지 않고, 페이지 전환 데이터 및 운용에 관한 정보, 애플리케이션 로그 등 비즈니스 관련 지표도 포함되어 있습니다. 링크드인에서는 웹사이트에서 생성되는 로그를 처리해 사용자의 웹사이트 활동을 추적하는 것을 목적으로 개발되었습니다. 이를 위해 사용자의 페이지뷰, 검색시 키워드 등을 수집해 서비스를 개선하는 것이 목적이었습니다. 링크드인에서는 바로 이런 데이터를 모아 실시간으로 이용자에게 제공할 수 있는 시스템이 필요했지만 전통적인 메시징 시스템으로는 어려웠습니다. 왜냐하면 전통적인 메시징 시스템의 경우 대부분 트랜잭션 데이터를 처리하도록 설계되어 있었기 때문입니다.
이를 가능하게 만든것이 카프카인데, 카프카는 대규모 메시징 시스템을 구현하기 위한 오픈소스 소프트웨어로 인기입니다.

2. 아파치 카프카

아파치 카프카(Apache Kafka)는 여러대의 분산 서버에서 대량의 데이터를 처리하는 분산 메시징 시스템입니다. 메시지(데이터)를 받고, 받은 메시지를 다른 시스템이나 장치에 보내기 위해 사용합니다. 따라서 카프카는 여러 시스템을 연결하는 중요한 역할을 합니다. 또한 카프카는 대량의 데이터를 높은 처리량(high horoughput)과 실시간으로 처리하기 위한 소프트웨어 입니다.

3. 카프카 구조

카프카로부터 요구하는 사항은 다음과 같습니다.

(1) 높은 처리량으로 실시간 처리한다. (2) 임의의 타이밍에 데이터를 읽는다. (3) 다양한 제품과시스템에 쉽게 연동한다.

위와 같은 요구사항을 만족하기 위해 카프카에서는 메시징 모델을 사용하는데, 메시징 모델은 다음과 같은 세 가지 요소로 구성됩니다.

Producer: 메시지 생산자, 카프카에 데이터를 만들어서 주는 역할
Broker: 메시지 수집/전달 역할
Consumer: 메시지 소비자, 카프카에서 데이터를 빼내서 소비하는 역할
zookeepker: 카프카의 정상 동작을 보장하기 위해 메타데이터를 관리하는 코디네이터, 노드 관리, 토픽관리, 컨트롤러 관리등 중요한 역할을 함. 2022년 초 무렵부터는 주키퍼가 삭제된 카프카 버전 릴리스.

그리고 다음과 같은 것들도 있습니다.

Topic: 데이터를 최종적으로 저장하는 곳, 관계형 데이터베이스로치면 테이블에 해당.
replication: 메시지들을 여러개로 복제해서 카프카 클러스터 내 브러크들에 분산시키는 동작을 의미.
partition: 하나의 토픽이 한번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러개로 나눠 병렬처리가 가능하게 만든 것
segment: 프로듀서에 의해 보로커로 전송된 메시지는 토픽의 파티션에 저장되며, 각 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장됨.
카프카 > 토픽 > 파티션 > 세그먼트

4. 카프카 내부 동작 원리

4.1. 카프카 레플리케이션

4.1.1 카프카 리플리케이션 개요

카프카 클러스터는 데이터 파이프라인에서 가장 중앙에서 허브 역할을 합니다. 만약 카프카 클러스터가 하드웨어 문제나 점검 등으로 정상적인 동작을 못한다면 카프카와 연결된 전체 파이프 라인에 영향을 미칠수 있고 이는 매우 심각한 문제로 이어질 수 있습니다. 따라서 카프카는 초기 설계 단계부터 일시적인 하드웨어 이슈등으로 브로커 한 두대에서 장애가 발생하더라도 중앙 데이터 허브로서 안정적인 서비스가 운영될 수 있도록 구상되었습니다. 이를 위해 토픽 생성 시 필수값으로 replication factor라는 옵션을 설정해야 합니다.

카프카 내부 동작 원리에서 가장 중요한 부분 중 하나는 레플리케이셔 동작입니다.
카프카 뿐만 아니라 일반적인 분산 시스템에서는 애플리케이션의 고가용성을 위해 내부적으로 레플리케이션 동작을 하게 되는데, 그러나 이는 말만큼 쉽지 않습니다.

4.2. 리더와 팔로워

토픽 상세보기 명령어를 실행하면 출력 내용 중 리더(leader)라는 부분을 볼 수 있습니다. 카프카는 내부적으로 레프레케이션들을 리더와 팔로워로 구분하고 역할을 분담합니다. 리더는 레플리케이션 중 하나가 선정되며, 모든 읽기와 쓰기는 리더를 통해서만 가능합니다. 즉, 프로듀서는 모든 레플리케이션에 메시지를 보내는 것이 아니라 리더에게만 메시지를 전소앟ㅂ니다. 또한 컨슈머도 오직 리더로부터 메시지를 가져옵니다.

그렇다면 팔로워는 뭐하는 걸까요? 팔로워는 지속적으로 파티션의 리더가 새로운 메시지를 받았는지 확인하고 새로운 메시지가 있다면 해당 메시지를 러더로부터 복제합니다.

그리고 리더에 문제가 발생할 경우를 대비해 언제든 새로운 리더가 될 준비를 합니다.

5. 카프카 프로듀서의 내부 동작 원리

카프카 클라이언트인 프로듀서의 기본 역할은 소스에 있는 메시지들을 카프카 토픽으로 전성하는 것입니다. 프로듀서가 전송하려는 메시지들은 프로듀서의 send() 메소드를 통해 시리얼라이저, 파티셔너를 거쳐 카프카로 전송됩니다.

5.1. 파티셔너

카프카의 토픽은 성능 향상을 위해 병렬 처리가 가능하도록 하기 위해 파티션으로 나뉘고, 최소 하나 또는 둘 이상의 파티션으로 구성됩니다. 그리고 프로듀서가 카프카로 전송한 메시지는 해당 토픽 내 각 파티션의 로그 세그먼트에 저장됩니다. 따라서 프로듀서는 토픽으로 메시지를 보낼 때 해당 토픽의 어느 파티션으로 메시지를 보내야할지를 결정해야하는데, 이 때 사용하는 것이 파티셔너(partitioner)입니다. 프로듀서가 파티션을 결정하는 알고리즘은 기본적으로 메시지의 키를 해시(hash)처리해 파티션을 구하는 방식을 사용합니다. 따라서 메시지의 키값이 동일하면 해당 메시지들은 모두 같은 파티션으로 전송됩니다.

5.2. 프로듀서의 배치

카프카에서는 토픽의 처리량을 높이기 위한 방법으로 토픽을 파티션으로 나눠 처리하며, 카프카 클라이언트인 프로듀서에서는 처리량을 높이기 위해 배치 전송을 권장합니다. 따라서 프로듀서에서는 카프카로 전송하기 전 배치(batch) 전송을 위해 토픽의 파티션별로 레코드들을 잠시 보관합니다.

buffer.memory: 카프카로 메시지 전송을 위해 담아두는 프로듀서의 버퍼 메모리 옵션, 기본값은 32MB
batch.size: 배치 전송을 위해 메시지 묶는 단위 설정, 기본값은 16KB
linger.ms: 배치 전송을 위해 버퍼 메모리에서 대기하는 메시지들의 최대 대기시간. 기본값은 0ms

프로듀서의 배치 전송 방식은 단건의 메시지를 전송하는 것이 아니라 한 번에 다량의 메시지를 묶어서 전송하는 방법입니다. 이러한 배치 전송은 불필요한 I/O를 줄일 수 있어서 매우 효율적이며, 더불어 카프카의 요청 수를 줄요주는 효과도 있습니다. 예를 들어 프로듀서가 1000개의 메시지를 카프카로 전송한다면, 1000번의 요청과 응답이 발생하지만, 프로듀서가 100개의 메시지를 배치로 처리한다면 카프카와 프로듀서에서는 단 10번의 요청과 응답만 발생하게 됩니다.

5.3. 중복없는 전송

예를 들어, 온라인 구매 사이트에서 중복 구매되면 큰일이다.

6. 카프카 컨슈머의 내부 동작 원리

컨슈머의 주요 억할은 카프카에 저장된 메시지를 가져오는 것입니다.

6.1. 컨슈머의 동작 중 가장 핵심은 바로 오프셋 관리입니다.

컨슈머는 카프카에 저장된 메시지를 꺼내오는 역할을 하기 떄문에 컨슈머가 메시지를 어디까지 가져왔는지를 표시하는 것은 매우 중요합니다. 예를 들어, 코드 배포로 인해 컨슈머가 일시적으로 동작을 멈추고 재시작 하는 경우나, 컨슈머가 구동 중인 서버에서 문제가 발생해 새로운 컨슈머가 기존 컨슈머의 역할을 대신하는 경우에는 기존 컨슈머의 마지막 메시지 위치부터 새로운 컨슈머가 메시지를 가져올 수 있어야만 장애로부터 빠르게 복구될 수 있습니다. 카프카에서는 메시지의 위치를 나타내는 위치를 오프셋(offset)이라고 부르는데, 이 오프셋은 숫자 형태로 나타냅니다.

7. 카프카 운영과 모니터링

7.1. 카프카 구성

카프카 서버 수량, 하드웨어, 배치 고려

7.2. 카프카 모니터링 시스템 구성

프로메테우스, 그라파나, 카프카 익스포터

8. 카프카 버전 업그레이드

8.1. 카프카 버전 업그레이드 준비

먼저 다음과 같은 방법으로 카프카의 현재 버전을 확인합니다.

$ /usr/local/kafka/bin/kafka-topics.sh --version

8.2. 최신버전 카프카 다운로드

카프카 다운로드는 모든 브로커에서 진행해야합니다.

$ cd /usr/local/
$ ll

lrwxrwxrwx 1 root root 27 1월 01 00:08 kafka -> /usr/local/kafka_2.12-2.1.0
lrwxrwxrwx 1 root root 27 1월 01 00:08 kafka_2.12-2.1.0
lrwxrwxrwx 1 root root 27 1월 01 00:08 kafka_2.12-2.6.0

현재 디렉토리에는 kafka_2.12-2.10으로 링크가 걸려있습니다. 이후 2.6버전으로 업그레이드시 kafka 디렉토리의 링크만 2.6으로 변경 예정입니다.

8.3. 설정

현재 운영중인 2.1 버전의 카프카 설정과 새롭게 설치한 2.6 버전의 카프카 설정이 일치해야하므로 2.1 버전의 설정 파일을 2.6 버전 설정 파일 경로로 복사합니다.

$ sudo cp kafka_2.12-2.1.0/config/server.properties kafka_2.12-2.6.0/config/server.properties

8.4. 브로커 버전 업그레이드

브로커 버전 업그레이드는 한대씩 순차적으로 합니다. 먼저 peter-kafka01에 접속한 후 브로커를 종료합니다. 브로커 한대를 종료하면 종료된 브로커가 갖고 있던 파티션의 리더들이 다른 브로커로 변경됩니다. 따라서 카프카 클러스타가 현재 운영 중인 상태라면 클라이언트는 일시적으로 리더를 차지 못하는 에러가 발생하거나 타임아웃 등이 발생하게 됩니다. 이는 장애 상황이 아닌 당연한 현상으로서, 카프카 클라이언트 내부적으로 재시도 로직이 있으므로 모든 클라이언트는 변경된 새로운 리더가 있는 브로커를 바라보게 될 것입니다.

그리고나서 카프카를 종료합니다.

$ cd /usr/local/
$ sudo systemctl stop kafka-server

그리고나서 2.1버전으로 연결되어 있는 심볼릭 링크를 2.6 버전으로 변경합니다.

$ sudo rm -rf kafka
$ sudo ln -sf kafka_2.12-2.6.0 kafka
$ ll

그리고나서 브로커를 실행합니다.

$ sudo systemctl start kafka-server

위와 같은 방법으로 2번 브로커의 업그레이드 작업을 진행합니다. 순서를 정리하면 다음과 같습니다.

2번 브로커 접속
/usr/local 경로로 이동
브로커 종료
kafka 링크 삭제
kafka 링크 2.6 버전으로 재생성
설정 파일 복사 및 옵션 설정
브로커 시작

[딥러닝] Deep Q Network(DQN) 논문 번역

Wed, 08 Nov 2023 00:00:00 +0900

Deep Q Network(DQN) 논문 번역

Playing Atari with Deep Reinforcement Learning

0. Abstract

우리는 강화학습을 통해서 고차원 센서로부터 직접 정책(policy)을 컨트롤함으로써 성공적으로 딥러닝 모델을 학습시켰다. 여기서 말하는 딥러닝 모델은 CNN을 의미하는데 이는 Q learning으로 학습 시킨 것이다. 이러한 모델을 학습 시킬 때 인풋은 각 픽셀(raw pixel)이 되고 아웃풋은 미래 보상에 대한 value function이다. 우리는 이러한 방법으로 아타리 게임 2600개에 대한 학습 환경으로부터 학습 알고리즘이나 아키텍쳐 변화없이 학습시켰다.

1.Introduction

비전이나 음성 데이터에서 고차원 센서 데이터로부터 나오는 데이터를 에이전트를 컨트롤함으로써 학습시키는 것은 강화학습 분야에서 오랜 기간동안 도전적인 과제였습니다. 이러한 도메인에서 가장 성공적인 강화학습 적용은 수작업으로 만든 피처를 linear value function이나 policy representations와 결합시키는 것이었습니다. 당연하게도 이런 시스템에서의 학습 결과는 feature representation의 퀄리티에 의존적이었습니다.

최근에와서는 raw 센서 데이터로부터 high-level 피처를 추출하는 것이 가능했고, 이는 컴퓨터 비전이나 음성 인식 분야에서 큰 발전을 이루어냈습니다. 이러한 방법들은 CNN을 포함하는다양한 신경망 아키텍처를 활용했습니다. 이 말은 기존에 사용했던 다양한 기술들을 강화학습에도 동일하게 사용할 수 있다는 뜻입니다.

그러나 딥러닝적인 관점으로 보면 강화학습은 아직 챌린징한 부분이 많이 있습니다. 첫번째 어려운 점은, 딥러닝을 학습시키기 위해서는 엄청나게 많은 수의 라벨링된 데이터가 필요합니다. 반면 강화학습 알고리즘에서는 보상(reward)에 의해 학습되어야하는데 이때 보상이란 스칼라값을 의미합니다. 강화학습에서 액션(action)과 보상(reward) 사이에는 딜레이가 존재하는데 이 딜레이는 매우 길어질수도 있어서 학습시 매우 큰 부담이 될 수 있습니다.

두번째 어려운 점은 딥러닝 알고리즘에서는 데이터들의 독립성을 가정합니다. 그러나 강화학습에서는 대부분 상태들이 높은 상관관계를 보여주는 시퀀스입니다. 게다가 강화학습에서는 새로운 행동에 대해 데이터 분포가 바뀌어 버립는데, 이는 기반이 되는 분포를 가정하는 방법 자체를 사용하기 어렵게 만듭니다.

이 논문은 CNN이 앞서 언급한 챌린징한 어려움들을 극복해서 성공적인 강화학습이 가능하다는 것을 보여줍니다. 해당 신경망은 variant of Q-learning으로 학습하는데, 이는 stochastic gradient descent를 통해 가중치를 업데이트하는 방향으로 진행합니다. 앞서 언급했던 문제점들 중 상관관계가 높은 데이터라는 점과 non-stationary 분포라는 문제점을 완화시키기 위해, experience replay mechanism을 사용할 것인데, 이는 previous transitons를 랜덤하게 샘플링함으로써 많은 과거 행동들에 대한 학습 분포를 smooth하게 만듭니다.

우리는 이러한 접근 방법으로 아케이드 학습 환경(ALE)에서 아타리 게임 2600개에 대해 적용할 것입니다. 아타리 게임 2600의 데이터는 고차원 비주얼 인풋 데이터를 가지고 있는데 210x160 RGB video at 60Hz의 사양을 나타냅니다. 그리고 각 게임은 인간 플레이어가 클리어하기 어려운 다양한 태스크로 구성되어 있습니다. 우리의 목적은 가능한한 많은 게임을 성공적으로 학습하는 single neural network agent를 만드는 것입니다. 해당 네트워크에게 게임에 대한 어떠한 정보를 제공하지 않으며, 수작업으로 만든 비주얼 피처같은 정보는 전혀 주어지지 않습니다. 즉, 신경망은 인간의 플레이로부터 나오는 비디오 인풋, 보상, 최종 시그널, 가능한 행동으로부터만 학습됩니다. 게다가 학습에 진행되는 네트워크 아키텍쳐나 모든 하이퍼파라미터는 게임 내내 상수로 취급됩니다. 지금까지 네트워크는 기존의 전문가 인간 플레이어를 능가하는 성능을 보여줬습니다.

2. Background

우리가 학습 대상으로 여기는 테스크는 한 에이전트는 환경 $\varepsilon$와 상호작용한다고 생각하겠습니다. 이때 환경 $\varepsilon$이라는 것은 아타리 에뮬레이터, 액션 시퀀스(sequence of actions), 관측(observation), 보상(reward)로 구성됩니다. 각 타임 스텝(time-step)에 대해 에이전트는 취할 수 있는 액션 $A=\{ 1, \cdots, K \}$ 중 하나인 액션 $a_t$를 선택합니다. 해당 액션은 에뮬레이터를 통해 내부 상태(internal state)와 게임 스코어(game score)를 변동시킵니다. $\varepsilon$는 stochastic 합니다. 에뮬레이터의 내부 상태는 에이전트에 의해 관측되지 않습니다. 대신에, 에뮬레이터로부터 나오는 이미지 $x_t \in R^d$를 통해 관측할 수 있는데, 이때 $x_t \in R^d$란 현재 스크린에 나타나는 로우 픽셀 벡터를 의미합니다. 게다가 이후 보상 $r_t$를 받게 되는데 이는 게임 점수를 변화시킵니다. 정리하면 게임 스코어는 이전의 액션 시퀀스(prior sequence of actions)와 관측(observation)에 의해 결정됩니다. 어떤 액션에 대한 피드백은 수천 타임스텝이 지나고나서야 받을 수 있습니다.

에이전트는 오직 현재 스크린 이미지만 관측하기 때문에 전체의 부분적으로만 관측 가능하며 수많은 에뮬레이터 상태는 인식할수 없을 정도로 소외됩니다. 즉, 연재 스크린 $x_t$만 가지고서는 현재 상황을 완벽하게 이해하는 것은 불가능합니다. 그러므로 우리는 $s_t = x_1, a_1, x_2, …, a_{t-1}, x_t$와 같은 액션 시퀀스와 관측치를 고려해서 게임 전략을 학습해야합니다. 에뮬레이터에서의 모든 시퀀스는 유한한 타임 스텝에 대해 종료된다고 가정합니다. 이러한 형식주의는 유한 Markov decision process(MDP)를 발전시킬 수 있는데, 이 때 MDP는 distinct state에 대한 시퀀스를 의미합니다. 결과적으로 각 시점 $t$에 대해 완전한 시퀀스 $s_t$를 이용해 MDP에 대한 standard 강화학습 방법을 적용시킬 수 있습니다.

에이전트의 목표는 액션을 선택함으로써 미래 보상을 최대화 시키는 방향으로 에뮬레이터와 상호작용하는 것입니다. 이때 미래 보상은 타임스텝 당 $\gamma$만큼 discount된다는 가정이 필요합니다. 따라서 시점 $t$에 대해 discount된 미래 보상은 다음과 같이 정의할 수 있습니다.

$R_t = \sum\limits_{t^\prime=t}^{T}\gamma^{t^{\prime} - t} r_{t^{\prime}}$

위 식에서 $T$는 게임이 종료되기 까지 걸리는 전체 시간을 의미합니다. 그리고 이제 최적화된 액션 value 함수(optimal action-value function) $Q^{*}(s,a)$를 정의하는데, 이 함수는 maximum expected return을 달성하는 함수입니다. 즉, 기대 리턴값을 최대화 시키는 함수인 것입니다. 이것이 가능하려면 어떤 액션-관측 시퀀스 $s$를 보고 어떤 전략을 선택함으로써 어떤 액션 $a$를 취하는 것으로 달성할 수 있습니다. 이를 수식으로 나타내면 다음과 같습니다.

$Q^*(s,a) = max_\pi E[R_t | s_t = s, a_t=a, \pi ]$

위 식에서 $\pi$는 액션 시퀀스와 매핑되는 정책을 의미합니다.

위와 같은 optimal action-value function은 Bellman equation이라는 규칙을 따릅니다. 이것이 의미하는 바는 다음과 같습니다. 만약 최적값 $Q^{*}(s^{\prime}, a^{\prime})$가 주어진 시퀀스 $s^\prime$에서 다음 타임 스텝에 대해 선택할 수 있는 모든 액션 $a^{\prime}$들 중 선택된 최적값이라면 최적의 전략은 $r + \gamma Q^{*}(s^\prime, a^\prime)$을 최대화 시키는 행동 $a^{\prime}$을 선택하는 것입니다. 이를 수식으로 나타내면 다음과 같습니다.

$Q^{*}(s, a) = E_{s^\prime \sim \varepsilon}[r + \gamma Q^{*}(s^\prime, a^\prime) | s,a]$

수많은 강화학습 알고리즘에는 베이스 아이디어가 깔려있는데 그것은 Bellman equation을 업데이터 방식으로 채택함으로써 $Q_{i+1}(s, a) = E_{s^\prime \sim \varepsilon}[r + \gamma Q^{*}(s^\prime, a^\prime) | s,a ]$을 반복적으로 업데이트 함으로써 action-value fucntion을 추정하는 것입니다. 이러한 value iteration 알고리즘을 통해 optimal action-value function은 $i \rightarrow \infty$로 감에 따라 $Q_i \rightarrow Q^*$로 수렴합니다. 실제로는 이러한 접근 방식이 터무니 없다고 생각할 수 있는데 그 이유는 action-value function은 일반화 없이 각 시퀀스가 모두 따로따로 추정되기 떄문입니다. 그 대신에 action-value function을 추정하는데 다음과 같은 근사치를 사용할 수 있습니다.

$Q(s,a; \theta) \approx Q^{*}(s,a)$

강화학습 분야에서는 이 근사치를 일반적인 linear function approximator로 사용하는데, 간혹가다가 딥러닝과 같은 non linear function approximator가 사용되기도 합니다. 가중치 $\theta$를 적용한 Q-network로서 신경망 함수를 활용한 approximator를 사용할 수 있습니다. Q-network는 iteration $i$에 대해 다음과 같은 손실함수 $L_i(\theta_i)$ 시퀀스를 최소화 시키는 방향으로 학습할 수 있습니다.

$L_i(\theta_i) = E_{s,a\sim \rho()}[(y_i - Q(s,a;\theta_i))^2]$

위 식에서 $y_i = E_{s^\prime \sim \varepsilon}[r + \gamma max_{a^{\prime}}Q^{*}(s^\prime, a^\prime) | \theta_{i-1}]$은 $i$번째 iteration에 대한 타겟을 의미하며, $\rho(s,a)$는 시퀀스 $s$와 액션 $a$에 대한 확률 분포를 의미하는데 우리는 이 분포를 behaviour distribution이라고 부르겠습니다. 이전 iteration으로부터의 파라미터 $\theta_{i-1}$는 손실함수 $L_i(\theta_{i})$를 최적화 시키는 과정에서 고정되어 있습니다. 이때 주의할 점은 타겟은 신경망의 가중치에 달려있다는 점에 주의해야합니다. 이 사실은 타겟은 지도학습에 사용되기 전, 즉, 학습 시작전에 고정되어 있다는 기존 사실과 반대 됩니다. 손실 함수를 가중치에 대해 미분하면 다음과 같은 그레디언트를 구할 수 있습니다.

$\nabla_{\theta_i}L_{i}(\theta_i) = E_{s,a \sim \rho();s^{\prime}\sim \varepsilon}[(r+\gamma max_{a^\prime}Q(s^{\prime}, a^{\prime} ; \theta_{i-1})-Q(s,a; \theta_i))\nabla_{\theta_i}Q(s,a;\theta_i)]$

위와 같은 그레디언트에서 전체 기대값을 계산하기 보다는 stochastic gradient descent 방법을 활용해서 손실함수를 최적화 합니다. 만약 가중치가 매 타임스텝 마다 업데이트 된다면 단 하나의 샘플에 대해 behaviour distribution $\rho$와 에뮬레이터 $\varepsilon$각각에 대한 기대값이 변화합니다. 그 후에 우리에게 익숙한 Q-learning 알고리즘에 다다를수있습니다.

이 알고리즘은 모델에 대해 자유롭다는(model-free) 사실을 기억하세요. 이것은 강화학습 테스크를 에뮬레이터 $\varepsilon$으로부터 나온 샘플을 통해 해결할 수 있는데, 중요한 것은 명확한 $\varepsilon$에 대한 구성없이도 가능하다는 사실입니다. 그리고 이것은 off-policy하다는 성질도 기억해주세요. 이러한 방식의 학습은 각각의 state space의 적절한 탐험을 통해 behaviour distribution을 따르는 동안, $a = max_a Q(s,a; \theta)$에 대해 탐욕적 전략을 통해 학습합니다. 실질적으로 behaviour distribution은 종종 $\epsilon$-greedy 전탁을 통해 선택되는데, 이는 확률 $1-\epsilon$과 랜덤 액션을 선택할 확률 $\epsilon$을 통해 정해집니다.

강화학습 스토리중 가장 잘 알려진 것은 TD gammon일 것입니다. 이것은 주사위 놀이를 하는 프로그램인데, 강화학습을 통한 셀프 플레이를 통해 슈퍼 휴먼 레벨 까지 도달했습니다. TD gammon을 학습할때는 Q learning과 비슷한 model-free 강화학습 알고리즘을 활용했습니다. 그리고 value function을 근사시킬 때는 히든 레이어 1층 짜리 멀티 레이어 퍼셉트론을 활용했습니다. 하지만 이 방법을 그대로 사용해서 체스에 적용했을 때는 성공적이지 않았습니다. 이를 통해 TD gamma에 사용한 접근 방법이 매우 특이한 케이스라는 믿음이 널리 퍼졌습니다. 왜냐하면 주사위를 굴릴때의 확률성이 state space를 탐험하는데 도움을 주고 value function을 smooth 하게 만들어주는데 도움을 주었기 때문입니다.

게다가 비선형 함수 근사를 통한 Q learning을 사용한 model-free 강화학습이나 off-policy learning을 혼합하는 방법이 Q-network를 발산하게 만든다는 사실이 밝혀졌습니다. 그 후에는 비선형이 아닌 선형 함수 근사를 활용한 강화학습이 수렴을 보장하는데 더 좋은 방법이라고 알려집니다.

최근에는 다시 딥러닝과 강화학습을 혼합시키는 방법이 부활했습니다. 딥러닝은 환경 $\varepsilon$을 추정하는데 사용되었고, Bolzmann 머신은 value function이나 정책을 추정하는데 사용되었습니다. 게다가 Q learning이 발산하는 문제는 gradient temporal-difference methods로 부분적으로 다루어졌습니다. 이러한 방법들은 비선형 함수 근사를 통한 fixed 정책을 통해 평가하거나 혹은 제한된 Q learning variant를 활용한 선형 함수 근사를 활용한 control policy를 학습할때와 같은 상황에서 수렴한다고 입증이 되었습니다. 그러나 이러한 방법들은 아직 비선형 컨트롤로 이어지지는 못했습니다.

…(생략, 그 이후에도 열심히 연구했다는 내용)

4. Deep Reinforcement Learning

최근 딥러닝에서 컴퓨터 비전과 음성 인식 분야에서 엄청난 발전이 있었는데, 그것은 아주 큰 트레이닝 데이터에 대해 효율적으로 학습을 이루어 낸 것입니다. 로우 데이터에 대해 가장 성공적인 접근 방법은 stochastic gradient descent 방법을 기반으로한 lightweight 업데이트 방식을 사용한 것이었습니다. 딥러닝을 할 때 충분한 데이터를 제공함으로써 수작업으로 직접만든 피처를 사용하는 것보다 더 나은 학습 결과를 보였습니다. 이러한 성공은 강화학습에도 적용할 수 있겠다는 동기부여가 되었습니다. 우리의 목적은 stochastic gradient updates를 활용해 RGB 이미지와 효율적으로 학습데이터를 처리하는 방식으로 작동하는 강화학습과 딥러닝을 연결시키는 것입니다.

TD Gammon 아키텍처는 접근법의 스타팅 포인트를 제공합니다. 이 구조는 신경망의 파라미터를 업데이트 시키는데, 이때 신경망은 value function을 추정를 추정하고, 직접적으로 환경과 상호작용하는 알고리즘을 활용해 $s_t, a_t, r_t, s_{t+1}, a_{t+1}$과 같은 경험으로 부터의 on-policy 샘플을 뽑습니다. 이러한 접근 방법들은 20년 전의 인간 고수와 같은 퍼포먼스를 발휘했는데, 20년이 지나면서 하드웨어가 발전하고 딥러닝이 발전한 지금 강화학습알고리즘과 딥러닝을 합친다는 생각에 어쩌면 당연히 의문점이 있을지도 모릅니다.

TD Gammon과 유사한 온라인 접근 방법들과는 반대로, 우리는 experience replay라고 알려진 테크닉을 사용할 것입니다. 이 방법은 각 타임스텝에 대해 에이전트의 경험을 저장합니다. 이때 각 시점에서의 에이전트의 경험은 $e_t = (s_t, a_t, r_t, s_{t+1})$이라고 정의하고, 이 경험들로 이루어진 데이터셋은 $D = e_1, …, e_N$이라고 정의하겠습니다. 그리고 그리고 수많은 에피소드들로부터 replay memory를 수집합니다. 알고리즘의 반복문 내부가 반복되는 동안, 우리는 Q-learning 업데이트를 적용하거나 미니배치를 업데이트하거나, 혹은 저장된 샘플로부터 랜덤하게 경험을 추출합니다. 이를 수식으로 표현하면 $e \sim D$와 같습니다. experience replay가 수행된 후에 에이전트는 $\epsilon$-greedy 정책을 따르는 액션을 선택하고 실행합니다. 임의의 길이를 가진 인풋을 신경망에 사용하는 것은 어려운 일이므로, 대신에 우리가 사용하는 Q-function은 고정된 길이의 인풋을 가진 함수 $\phi$라고 하겠습니다. 이렇게 정의한 알고리즘을 deep Q-learning이라고 부르겠습니다. 이 알고리즘의 로직을 정리하면 다음과 같습니다.

Algorithm. Deep Q learning with Experience Replay

우선 초기화 replay memory 초기화가 필요한데, replay memory $D$를 공간 $N$을 가지도록 초기화 합니다.
action-value function $Q$를 랜덤 가중치를 줘서 초기화 합니다.
for episode = (1, $M$), 에피소드 1부터 $M$까지 반복문을 수행합니다.
- 시퀀스 $s_1 = \{x_1\}$과 preprocessed sequenced $\phi_1 = \phi(s_1)$을 초기화 합니다.
- for $t=1,T$, 타임스텝 $t$에 대해 반복문을 수행합니다.
  - $\epsilon$ 확률로 액션 $a_t$를 선택합니다.
  - 그 밖의 $a_t = max_a Q^{*}(\phi(s_t), a ; \theta)$를 선택합니다.
  - 에뮬레이터 내부에서 액션 $a_t$를 실행하고 보상 $r_t$와 이미지 $x_{t+1}$을 관측합니다.
  - 그리고나서 $s_{t+1} = s_t, a_t, x_{t+1}$과 $\phi_{t+1} = \phi(s_{t+1})$을 설정합니다.
  - transition $(\phi_t, a_t, r_t, \phi_{t+1})$을 $D$에 저장합니다.
  - $D$로부터의 트랜지션 $(\phi_j, a_j, r_j, \phi_{j+1})$의 미니배치를 샘플링합니다.
  - 타겟 $y_j$를 셋팅하는데, $terminal \phi_{j+1}$에 대해서는 $y_j=r_j$라고 설정하고, $non terminal \phi_{j+1}$에 대해서는 $y_j=r_j + \gamma max_{a^{\prime}}Q(\phi_{j+1}, a^{\prime}; \theta)$라고 설정합니다.
  - 앞서 언급한 방정식 3에 따라 $(y_j - Q(\phi_j, a_j ; \theta))^2$에 대한 그레디언트 디센트 단계를 수행합니다.
- 반복문을 종료합니다.
반복문을 종료합니다.

이러한 접근법은 몇가지 장점이 있습니다. 첫번째 장점은, 각 경험 스텝마다 잠재적으로 많은 가중치 업데이트를 사용합니다. 그리고 이는 더 큰 데이터를 효과적으로 다룰수 있게 합니다.

두번째 장점은, 연속적인 샘플링으로부터 학습을 바로하는 것은 비효율 적입니다. 왜냐하면 샘플 데이터 간 상관관계가 높게 나타나기 때문이죠. 따라서 샘플링할 때 연속된 데이터가 아니라 randomizing해서 상관관계를 부수고, 업데이트시 분산을 줄일 수 있습니다.

세번째 장점은, on-policy 학습시, 현재 파라미터가 다음에 학습될 파라미터가 되는 데이터 샘플을 결정합니다. 예를 들어, 만약 최대화시키는 액션이 왼쪽으로 움직이는 것이라면, 학습 데이터 또한 왼쪽 부분에서 샘플링된다는 뜻입니다. 만약 최대화 액션이 반대로 가면 당연히 학습 분포 또한 오른쪽으로 스위치 됩니다. 이말은 원치않는 피드백 루프가 발생했을때나 파라미터가 멍청한 로컬 미니멈에 스턱이 걸리거나 아니면 발산해버리는 상황을 다루기 쉽다는 의미입니다. experience replay를 사용함으로써 behavior distribution이 이전 상태에 의해 평균으로 수렴하고 부드러운 학습이 진행됨에 따라 파라미터의 소실이나 폭발을 막습니다. experience replay로 학습함에 따라 Q-learning의 선택으로 동기부여를 할수 있는 off-policy를 학습하는 것은 필수적입니다.

실질적으로 우리가 사용하는 알고리즘의 목적은 마지막 $N$ experience tuple을 replay memory에 저장하고 업데이트시 $D$로부터 균일한 확률로 샘플링하는 것입니다. 이러한 접근 방법은 어떤 측면에서는 제한적으로 보일 수 있습니다. 왜냐하면 메모리 버퍼의 크기가 $N$으로 고정되어 있기 때문에, 중요한 transition과 그렇지 않은 것을 차별화하지 않고 항상 최근 trainsition을 덮어쓰기 떄문입니다. 이와 유사하게, 샘플에 대해 동일한 확률로 샘플링하는 방법인 유니폼 샘플링은 replay momory에 저장되어 있는 모든 transition의 중요도를 동일하게 본다는 의미입니다. 더 철학적으로 샘플링 전략을 짜자면 transition들 마다 가중치를 다르게 주는 방법도 생각해볼 수 있겠습니다.

4.1. Preprocessing and Model Architecture

raw 아타리 프레임으로 작업을 한다면 우리는 210x160 픽셀 이미지와 128가지 색깔을 사용하는 데이터를 다루게 될 것입니다. 그리고 전처리 과정으로 인풋 차원을 줄이는 작업을 할 수 있습니다. raw 프레임은 처음에 RGB값을 gray-scale로 변환하고 이미지 크기도 줄여서 110x84 크기의 이미지로 만듭니다. 그 후 이미지의 일부를 잘라서 84x84 이미지로 만드는데 이 이미지는 플레이영역에 해당합니다. 이 단계가 중요한 이유는 우리는 GPU를 활용해 2D convolution을 진행하는데 이때 정사각형 형태의 인풋 데이터가 좋기 때문입니다. 본 논문에서의 실험은, 알고리즘 1로부터의 $\phi$ 함수를 이러한 전처리 과정에 적용시켜 Q-function의 인풋 데이터를 만듭니다.

신경망을 활용해 $Q$를 파라미터라이징 할 수 있는 몇몇 방법들이 존재합니다. $Q$는 그들의 $Q$-value를 통해 지난 액션 히스토리와 스칼라 추정치(reward)를 맵핑하므로 지난 히스토리와 액션이 신경망의 인풋 데이터로 활용될 수 있습니다. 이러한 아키텍처의 단점은 각 액션의 $Q$-value 대해 분리된 forward pass를 요구한다는 것입니다. 그리고 이것이 문제가 되는 이유는 액션의 수 만큼 비용과 스케일이 선형적으로 증가하기 때문입니다.

우리는 이 방법 대신에 각 가능한 액션들에 대해 분리된 아웃풋 유닛이 존재하고, state representation이 인풋이되는 신경망을 사용하는 아키텍처를 하용하겠습니다. 즉, 우리의 아웃풋은 input state에 대한 개별 액션으로부터 예측된 $Q$-value에 대응됩니다. 이러한 아키텍처를 활용하는 것의 장점은 단 하나의 forward pass로 구성된 신경망으로 주어진 state에 대해 모든 가능한 액션의 $Q$-value를 계산할 수 있는 능력입니다.

Architecture

Layer type	Details	Activation
Input	전처리를 거친 (84x84x4) 인풋 데이터
Convolution	16(8x8) 필터, 스트라이드 4	ReLu
Convolution	32(4x4) 필터, 스트라이드 2	ReLu
Dense	256 hidden units	ReLu
Dense(output)	엑션당 하나의 아웃풋 발생(predicted Q-value)	Linear

자, 이번에는 7개의 아타리 게임에 사용된 실제 아키텍처를 알아보겠습니다. 신경망에 투입되는 인풋은 함수 $\phi$에 의해 생성된 84x84x4 이미지 입니다. 그리고 첫번째 히든 레이어는 16(8x8) 필터를 사용하고 stride 4가 input data에 적용되었으며 rectifier nonlinearity가 적용되었습니다. 두번째 히든 레이어는 32(4x4)의 구조를 가지고 stride 2, rectifier nonlinearity를 가집니다. 마지막 히든 레이어는 fully-connected되었으며 256개의 rectifier units로 구성되어 있습니다. 아웃풋 레이어는 fully-connected된 linear layer이며 하나의 행동에 대한 single output으로 구성됩니다. 우리가 고려한 아타리게임에서는 타당한 액션의 수가 4가지에서 18가지로 다양합니다. 그리고 학습은 앞서 언급한 Deep Q-Networks(DQN)으로 진행합니다.

5. Experiments

지금까지 우리는 7개의 아타리 게임에 대해 실험을 해보았는데 7가지 게임 제목은 다음과 같습니다. Beam Rider, Breakout, Enduro, Pong, Qbert Seaquest, Space Invader. 우리는 7가지 게임에 대해 종류에 상관없이 동일한 신경망 구조를 사용했고 동일한 학습 알고리즘과 하이퍼 파라미터 세팅을 사용했습니다. 즉, 이 말이 뭐냐면 특정 게임에만 해당하는 특정 정보를 사용하지 않았다는 뜻입니다. 우리가 수정되지 않는 게임에 대해 에이전트가 플레이한 결과에 대해 평가할때, 학습과정에서 사용되는 보상 구조를 한번 수정합니다. 왜냐하면 스코어의 스케일이 게임에 따라 너무 다르기 때문입니다. 스코어는 긍정적일때는 1점, 부정적일때는 -1점을 주고 바뀌지 않는 경우에는 0점을 줍니다. 이렇게 보상 형태는 에러 발생 범위를 줄여주고 다양한 게임에 대해 동일한 학습율을 적용할 수 있게 해줍니다. 이는 또한 에이전트의 퍼포먼스에도 영향을 주는데 그 이유는 보상 규모의 차이가 없기 때문입니다.

이번 실험에서 우리는 사이즈 32 짜리의 미니배치로 RMSProp 알고리즘을 사용했습니다. 학습하는 동안의 behavior policy는 $\epsilon$-greedy를 사용하는데 이때 $\epsilon$은 1 부터 0.1 까지 점차 낮추는데 이 과정은 처음 백만 프레임에 대해 적용되고 그 후에는 0.1로 고정됩니다.

또한 아타리 게임에 대해 우리는 simple frame-skipping 기술을 사용합니다. 더 정확히는 에이전트는 모든 프레임을 보고 행동을 선택하는게 아니라 매 k번째 프레임을 보고 행동을 선택합니다. 그리고 가장 최근 행동은 skipped 된 프레임에 대해서는 반복됩니다. 에뮬레이터를 한 스텝에 대해 실행하는 것은 액션을 선택하는 것보다 적은 계산량이 요구되므로 같은 시간동안 에이전트는 k번 더 많은 게임을 플레이할 수 있게 됩니다. 우리는 Space Invaders라는 게임을 제외하면 모두 $k=4$를 적용했습니다. Space Invaders라는 게임에는 $k=3$을 적용했습니다. 그외 나머지 세팅은 7가지 게임 모두 동일합니다.

5.1. Traning and Stability

지도학습에서는 트레이닝 데이터와 validation 데이터를 평가함에 따라 모델의 퍼포먼스를 쉽게 추적할 수 있습니다. 그러나! 강화학습에서는 학습되는동안 정확히 평가하는 것이 어렵습니다. 이것은 평가 측정 방법(evaluation metric) 때문인데, 앞서 언급된 평가 방법을 가지고 학습이 진행되는 동안 한 에피소드나 여러 게임을 통해 얻은 보상을 평균내는등 간헐적으로 평가가 진행됩니다. 전체 보상에 대해 평균을 구하는 방식(average total reward)은 noise가 많이 발생합니다. 왜냐하면 정책의 가중치가 적게 변하는 경우가 정책이 방문하는 state의 분포를 크게 변화시킬 수 있기 때문입니다. 그림 2에서의 가장 왼쪽 2개의 플랏은 average total reward가 학습되는 동안 어떻게 변하는지 보여줍니다. 두개의 평균 보상 플랏은 변동이 크고 학습 알고리즘에 따라서도 꾸준히 개선되지 않습니다. 반면 다른 알고리즘을 사용했을 때는 안정적인 구도를 보여주는 장면도 있는데, 이는 그 당시 state로 부터의 정책에 대해 discounted reward를 추정하는 방법을 통해 action-value function $Q$를 추정할 때 좋은 결과를 보여줍니다. 우리는 학습 시작 전 랜덤 정책을 실행함으로써 고정된 state 집합을 모으고 해당 state에 대해 $Q$를 최대화하는 평균치를 추적합니다. 그림 2에서 가장 오른쪽에 있는 플랏은 average predicted $Q$가 계속 증가할 뿐만 아니라 변동폭도 작은 것을 볼 수 있습니다. 이것이 의미하는 바는 이론적인 보장이 조금 부족할지라도 우리가 사용한 방법은 강화학습에 거대한 신경망을 적용시키고 stochastic gradient descent 방법을 안정적으로 사용할 수 있다는 것을 의미합니다.

5.2. Visualizing the Value Function

그림 3은 Seaquest라는 게임에서 학습된 value function을 시각화한 것을 보여줍니다. 그림은 적이 나타났을때 점프하는 동작이 예측값으로 실행되는 것을 보여줍니다(point A). 그리고 에이전트는 torpedo를 적에게 발사하고 torpedo에 대한 예측값이 최고를 찍은 것을 보여줍니다(point B). 마지막으로 적이 사라졌을 때 value가 낮아지는 것을 볼 수 있습니다(point C) 그림3은 복잡한 상황이 발생했을 때 어떻게 학습하는 지는 보여줍니다.

개요	B.Rider	Breakout	Enduro	Pong	Qbert	Seaquest	S.Invaders
Random	354	1.2	0	-20.4	157	110	179
Sarsa	996	5.2	129	-19	614	665	271
Contingency	1743	6	159	-17	960	723	268
DQN	4092	168	470	20	1952	1705	581
Human	7456	31	368	-3	18900	28010	3690

에이전트가 학습한 후에 우리는 인간 전문가의 플레이 점수와 랜덤으로 정책을 선택해서 행동한 액션을 통한 점수를 기록했습니다. 인간이 플레이한 점수는 중앙값을 사용했습니다.

5.3. Main Evaluation

우리는 실험 결과를 비교했는데 Sarsa가 의미하는 것은 Sarsa 알고리즘을 사용했다는 의미이며, 이 과정에서 손으로 직접 만든 피처를 적용했습니다. Contingency는 Sarsa와 거의 비슷한 접근 방법을 보이지만 에이전트 컨트롤 하에서 학습된 스크린의 일부분을 피처로 사용합니다. 위 두가지 방법은 풀려고 하는 문제에 대해 사전지식을 얼마나 알고 적용하느냐가 중요합니다.

6. Conclusion

이 논문은 강화학습에서의 새로운 딥러닝 모형을 소개하고 인풋데이터로 raw 픽셀을 활용해 아타리 2600 컴퓨터 게임을 마스터하는 능력을 보여줍니다. 또한 온라인 $Q$-learning의variant를 소개하는데 이는 확률적 미니배치와 experience replay modmory를 결합해 강화학습에서 딥러닝 학습을 쉽게 도와줍니다. 우리의 접근 방법은 총 7가지 게임중 6가지 게임에서 좋은 결과를 보여주었고 이 과정에서 아키텍처의 하이퍼파라미터 수정 없이 이루어졌습니다.

[Infra] nginx를 활용한 포트포워딩, 리버스 프록시

Sun, 27 Aug 2023 00:00:00 +0900

nginx를 활용한 포트포워딩, 리버스 프록시

관련 내용 복습하기

1. nginx 설치

이번 포스팅에서는 nginx를 활용한 포트포워딩, 리버스 프록시 관련 내용을 정리해보겠습니다. 먼저 nginx를 활용하기 위해 nginx를 설치하겠습니다.

ubuntu@k8s-master:~$ sudo apt update

Hit:1 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Get:3 http://ap-northeast-2.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease [109 kB]
Hit:4 https://download.docker.com/linux/ubuntu jammy InRelease
...(중략)
Fetched 2214 kB in 1s (1682 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
60 packages can be upgraded. Run 'apt list --upgradable' to see them.

ubuntu@k8s-master:~$ sudo apt install nginx

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
...(생략)

ubuntu@k8s-master:~$ sudo systemctl status nginx

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-08-26 03:05:01 UTC; 1min 24s ago
       Docs: man:nginx(8)
    Process: 20184 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 20186 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 20280 (nginx)
      Tasks: 3 (limit: 4667)

2. 포트포워딩

2-1. 수정해야 하는 파일

이번 절에서는 포트포워딩을 해보겠습니다.

ubuntu@k8s-master:~$ sudo –i
root@k8s-master:~# cd /etc/nginx/sites-enabled/
root@k8s-master:/etc/nginx/sites-enabled# ls
default

포트포워딩을 하기 위해서는 /etc/nginx/sites-enabled/ 경로에 있는 default 파일을 수정해야합니다. 이를 위해 /etc/nginx/sites-enabled/ 경로로 이동해서 default 파일을 확인합니다.

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

파일을 확인하면 위와 같은데 주석을 뺴고 간단하게 보면 다음과 같습니다.

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

2-2. 포트포워딩 방법-1

포트포워딩을 해보겠습니다. 80번포트로 들어오는 트래픽을 http://172.31.46.220:80로 포트포워딩해보겠습니다. 이를 위해 위 코드에서 try_files $uri $uri/ =404; 부분을 주석 처리하고, proxy_pass http://172.31.46.220:80; 구문을 추가하면 다음과 같습니다.

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                #try_files $uri $uri/ =404;
                proxy_pass http://172.31.46.220:80;
        }
...(중략)

2-3. 포트포워딩 방법-2

이번에는 upstream을 활용한 방법을 보겠습니다.

upstream nginx_ingress_controller{
    server 172.31.46.220:80;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                #try_files $uri $uri/ =404;
                proxy_pass http://nginx_ingress_controller;
        }

위와 같이 upstream을 활용하는 방법도 있습니다.

[Infra] 쿠버네티스(kubernetes)(8) invalid Host header 에러

Sat, 19 Aug 2023 00:00:00 +0900

쿠버네티스 exec -it 명령어 invalid Host header 에러

참고 링크

1. 문제 현상

새롭게 구축한 쿠버네티스 클러스터에서 간단하게 nginx이미지를 활용해 nginx01이라는 파드를 생성한 후 kubectl exec -it {파드명} -- {명령어} 옵션을 활용해 파드 내부로 접속하려고 시도했습니다.

$ kubectl exec -it nginx01 -- /bin/sh
error: Internal error occurred: error executing command in container: http: invalid Host header

그랬더니 위와 같이 invalid Host header 에러 메시지가 발생했습니다.

2. 원인

원인은 쿠버네티스를 설치하기 전에 cri-dockerd를 설치하는데 cri-dockerd를 설치하기 전에 go lang을 설치해야합니다. 그런데 go lang의 버전이 저와 같이 1.20.6 이상이면 위와 같은 invalid Host header 에러가 발생합니다.

$ go version
go version go1.21.0 linux/amd64

즉, 1.20.5까지는 에러 안나는데 1.20.6 부터는 에러가 발생하는 것입니다. 저는 위와 같이 1.21.0버전으로 1.20.6 이후 버전임을 알 수 있습니다.

3. 해결 방법

해결 방법을 간단하게 말하면 쿠버네티스 전체를 다시 설치할 필요는 없고, cri-docker와 go lang만 삭제한 후 다시 설치하면 됩니다.

3.1. cri-docker 정지

먼저 cri-docker를 멈추겠습니다.

$ sudo systemctl stop cri-docker.socket
$ systemctl status cri-docker.socket

○ cri-docker.socket - CRI Docker Socket for the API
     Loaded: loaded (/etc/systemd/system/cri-docker.socket; enabled; vendor prese>
     Active: inactive (dead) since Sat 2023-08-19 08:38:47 UTC; 3s ago
   Triggers: ● cri-docker.service
     Listen: /run/cri-dockerd.sock (Stream)
        CPU: 762us

3.2. 기존 go lang 삭제 및 go lang 1.20.5 버전 설치

go lang 1.20.6 부터 에러가 발생하므로 go lang 1.20.5 버전을 다시 설치하겠습니다. 설치방법은 https://go.dev/doc/install을 참고하시면 됩니다.

# wget https://go.dev/dl/go1.20.5.linux-amd64.tar.gz
# rm -rf /usr/local/go && tar -C /usr/local -xzf go1.20.5.linux-amd64.tar.gz
# exit

$ go version
go version go1.20.5 linux/amd64

위와 같이 설치하면 go lang이 1.20.5 버전인 것을 알 수 있습니다.

3.3. cri-dockerd 재설치

끝으로 cri-dockerd를 재설치 합니다. 삭제 커맨드를 입력할 필요는 없고 설치 사이트 참고해서 다시 설치하면 됩니다.

$ cd cri-dockerd
$ make cri-dockerd

$ pwd
/home/eevee/work/cri-dockerd

$ sudo -i
# cd /home/eevee/work/cri-dockerd
# mkdir -p /usr/local/bin
# install -o root -g root -m 0755 cri-dockerd /usr/local/bin/cri-dockerd
# install packaging/systemd/* /etc/systemd/system
# sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service
# systemctl daemon-reload
# systemctl enable --now cri-docker.socket
# exit
$

위와 같이 cri-dockerd를 설치하고 다음과 같이 cri-docker 작동 확인을 합니다.

$ systemctl status cri-docker.socket
● cri-docker.socket - CRI Docker Socket for the API
     Loaded: loaded (/etc/systemd/system/cri-docker.socket; enabled; vendor prese>
     Active: active (listening) since Sat 2023-08-19 08:43:44 UTC; 10s ago
   Triggers: ● cri-docker.service
     Listen: /run/cri-dockerd.sock (Stream)
      Tasks: 0 (limit: 4667)
     Memory: 0B
        CPU: 671us
     CGroup: /system.slice/cri-docker.socket

Aug 19 08:43:44 k8s-master systemd[1]: Starting CRI Docker Socket for the API...
Aug 19 08:43:44 k8s-master systemd[1]: Listening on CRI Docker Socket for the API.

그리고 kubelet도 재시작 해줍니다.

$ sudo systemctl restart kubelet
$ kubectl get node
NAME         STATUS   ROLES           AGE     VERSION
k8s-master   Ready    control-plane   3d20h   v1.26.5

4. 접속 확인

이제 nginx 파드에 제대로 접속이 되는지 확인해보겠습니다.

$ kubectl apply -f nginx-test01.yml
pod/nginx01 created

$ kubectl exec -it nginx01 -- /bin/bash
root@nginx01:/#

접속이 제대로 되는 것을 알 수 있습니다.

[리눅스] AWS EC2 인스턴스 스토리지 용량 늘리는 법

Sun, 13 Aug 2023 00:00:00 +0900

AWS 아마존 리눅스 유저 추가하고 password 접속 허용

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

관련 링크

1. AWS 사이트에서 인스턴스 용량 증가

AWS 사이트에서 인스턴스를 클릭해서 스토리지 용량을 클릭해서 증가시켜줍니다. 저는 30G 까지 늘렸습니다.

2. 인스턴스에 접속해서 작업하기

약 3분정도 지난 후 인스턴스에 접속해서 디스크 현황을 파악합니다.

ubuntu@k8s-master:~$ lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0      7:0    0  24.4M  1 loop /snap/amazon-ssm-agent/6312
loop1      7:1    0  55.6M  1 loop /snap/core18/2745
loop2      7:2    0  63.3M  1 loop /snap/core20/1879
loop3      7:3    0 111.9M  1 loop /snap/lxd/24322
loop4      7:4    0  53.2M  1 loop /snap/snapd/19122
loop5      7:5    0  53.3M  1 loop /snap/snapd/19457
loop6      7:6    0  55.7M  1 loop /snap/core18/2785
loop7      7:7    0  63.4M  1 loop /snap/core20/1974
loop8      7:8    0  24.8M  1 loop /snap/amazon-ssm-agent/6563
xvda     202:0    0    30G  0 disk
├─xvda1  202:1    0   7.9G  0 part /
├─xvda14 202:14   0     4M  0 part
└─xvda15 202:15   0   106M  0 part /boot/efi

위 결과를 보면 xvda가 30G로 늘어나 있는 것을 볼 수 있습니다. 그리고 기존의 xvda1은 처음 설정 그대로인 7.9G인 것을 볼 수 있습니다.

ubuntu@k8s-master:~$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=227328 old: size=16549855 end=16777183 new: size=62687199 end=62914527

위에서 확인한 xvda의 용량을 키워줍니다.

ubuntu@k8s-master:~$ lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0      7:0    0  24.4M  1 loop /snap/amazon-ssm-agent/6312
loop1      7:1    0  55.6M  1 loop /snap/core18/2745
loop2      7:2    0  63.3M  1 loop /snap/core20/1879
loop3      7:3    0 111.9M  1 loop /snap/lxd/24322
loop4      7:4    0  53.2M  1 loop /snap/snapd/19122
loop5      7:5    0  53.3M  1 loop /snap/snapd/19457
loop6      7:6    0  55.7M  1 loop /snap/core18/2785
loop7      7:7    0  63.4M  1 loop /snap/core20/1974
loop8      7:8    0  24.8M  1 loop /snap/amazon-ssm-agent/6563
xvda     202:0    0    30G  0 disk
├─xvda1  202:1    0  29.9G  0 part /
├─xvda14 202:14   0     4M  0 part
└─xvda15 202:15   0   106M  0 part /boot/efi

그리고 다시 lsblk로 디스크를 확인하면 xvda가 30G로 증가된 것을 볼 수 있습니다.

ubuntu@k8s-master:~$ sudo resize2fs /dev/root

resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 4
The filesystem on /dev/root is now 7835899 (4k) blocks long.

그리면 이제 resize2fs를 활용해 파일 시스템의 크기를 변경해보겠습니다. /dev/root는 루트 파일 시스템을 의미하는데, 찾아보니까 /dev/root라고 입력해도 되고 /dev/xvda1이라고 입력해도 된다고 합니다.

ubuntu@k8s-master:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  7.4G   22G  26% /
tmpfs           483M  1.1M  482M   1% /dev/shm
tmpfs           194M  892K  193M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/xvda15     105M  6.1M   99M   6% /boot/efi
tmpfs            97M  4.0K   97M   1% /run/user/1000

그리고 용량을 확인해보면 /dev/root가 29G로 증가된 것을 볼 수 있습니다.

[Infra] 쿠버네티스(kubernetes)(7) Metallb로 로드밸런서 구축하기

Sat, 29 Jul 2023 00:00:00 +0900

쿠버네티스(kubernetes)(7) Metallb로 로드밸런서 구축하기

1. 사전 준비

$ kubectl get configmap kube-proxy -n kube-system -o yaml | grep strictARP 
    strictARP: false

먼저 strictARP를 true로 바꿔주겠습니다. 위와 같이 strictARP를 확인하면 false라는 것을 볼 수 있습니다. 이를 true로 바꿔주겠습니다.

$ kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply -f - -n kube-system

Warning: resource configmaps/kube-proxy is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
configmap/kube-proxy configured

위 코드가 strictARP를 true로 바꾸는 코드입니다.

$ kubectl get configmap kube-proxy -n kube-system -o yaml | grep strictARP
      strictARP: true
...(중략)

그리고 다시 strictARP를 확인하면 true인 것을 알 수 있습니다.

[Infra] CI/CD, 지속적 통합/지속적 배포 개념

Sun, 23 Jul 2023 00:00:00 +0900

CI/CD, 지속적 통합/지속적 배포 개념

CI/CD의 개념

CI는 Continuous Integration의 약자이며 지속적 통합을 의미합니다. 그리고 CD는 Continuous Delivery의 약자이며 지속적 배포를 의미합니다. 우리는 현실 세계에서 하나의 프로젝트에 다수의 개발자가 참여하는 것을 알고 있습니다. 따라서 각 개발자의 작업을 중앙에서 모두 통합하는 것이 중요합니다. 다양한 개발자가 참여하는 만큼 이러한 작업은 하루에도 여러 번 발생할 수 있는데, 이를 자동화한다면 배포 과정의 효율성을 높임으로써 배포 위험을 감소시키고 높은 품질을 보장하며 비용 절감에 도움이 됩니다.

CI(Continuous Integration, 지속적 통합)

먼저 CI에 대해서 알아보겠습니다. CI는 Continuous Integration의 약자이며 지속적 통합을 의미합니다.

CD(Continuous Delivery/Deployment, 지속적 전달/배포)

이번에는 CD에 대해 알아보겠습니다. CD는 Continuous Delivery/Deployment의 약자이며 지속적 배포를 의미합니다. CD는 앞서 CI 과정을 통해 통합된 코드를 배포하는 것을 의미합니다.

지속적 전달과 지속적 배포는 비슷한 의미로 쓰이지만 엄밀하게 말하면 다릅니다. 지속적 전달(Continuous Delivery)은 코드를 배포할 수 있는 환경을 준비하는 과정까지를 의미합니다. 반면 지속적 배포(Continous Deployment)는 실제로 코드를 배포까지 하는 것을 의미합니다.

[네트워크] 로드밸런서(loadbalancer)의 개념

Mon, 05 Jun 2023 00:00:00 +0900

로드밸런서의 개념

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

관련 링크

1. 서론

주어진 서버에 너무나 많은 트래픽이 몰린다면 이를 어떻게 처리해야할까요? 이번 포스팅에서는 로드밸런서의 개념에 대해 알아보겠습니다.

2. 로드밸런서(loadbalancer)란?

주어진 서버에 너무나 많은 트래픽이 몰린다면 이를 어떻게 처리해야할까요? 이럴 때는 다수의 서버를 구축하고 수많은 트래픽을 여러 서버로 분산시켜주는 기술이 필요합니다. 이때 사용되는 기술을 로드밸런싱(loadbalancing)이라고 하고, 로드밸런싱을 하는데 필요한 장치 또는 기술을 로드밸런서(loadbalancer)라고 합니다. 이번 포스팅에서는 로드밸런서의 개념에 대해 알아보겠습니다.

3. 로드밸런싱 알고리즘

로드밸런싱 알고리즘은 크게 다음과 같은 종류가 있습니다.

3.1. 라운드로빈 방식(round robin method)

라운드로빈 방식은 다수의 서버에 순서대로 요청을 할당하는 방식입니다.

3.2. 최소 연결 방식(least connection method)

요청이 들어온 시점에 연결 수가 가장 적은 서버에 할당하는 방식입니다.

3.3. IP 해시 방식(IP Hash Method)

요청을 할당할 때 클라이언트의 IP 주소를 해시함수를 통해 해싱해서 그 결과를 통해 할당하는 방식을 의미합니다.

4. 로드밸런서의 종류

로드 밸런서는 크게 하드웨어 로드밸런서와 소프트웨어 로드밸런서로 나뉩니다.

4.1. 하드웨어 로드밸런서

하드웨어 로드밸런서는 하드웨어 장비를 활용해 로드밸런싱합니다.

4.2. 소프트웨어 로드밸런서

소프트웨어 형식으로 로드밸런서를 구축하는 경우 클라우드를 사용하는 경우, 해당 서비스에서 제공하는 로드밸런서를 활용할수도 있습니다. 예를 들어, AWS는 Elastic Load Balancing(ELB)라는 로드밸런싱 서비스를 제공합니다. 또하나의 방법은 직접 구축하하는 것인데 nginx를 통해 로드밸런서를 만들 수 있습니다.

5. nginx로 로드밸런서 만들기

5.1. 라운드로빈 방식

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

위와 같은 방식으로 nginx 설정파일을 수정해 로드밸런싱을 할 수 있습니다. 위 코드는 80번 포트로 들어온 요청을 srv1, srv2, srv3으로 로드밸런싱하는 코드입니다. 위 코드에서는 로드밸런싱 알고리즘을 지정하지는 않았는데 디폴드 방식은 라운드로빈 방식입니다.

5.2. 최소 연결 방식

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

만약 로드밸런싱 알고리즘을 최소 연결방식으로 지정하고 싶다면 위와 같이 설정해줍니다.
최소 연결 방식으로 지정하면 이미 힘들어하고 있는 서버에게 더 많은 요청을 주지는 않습니다. 이미 수많은 요청을 처리하느라고 바쁜 서버보다는 상대적으로 널널한 서버에게 요청을 주는 방법이죠.

5.3. ip hash 방식

앞서 실습했던 라운드로빈 방식이나 최소 연결 방식은 동일한 클라이언트가 여러번 요청을 보냈을 때 다수의 요청을 모두 동일한 서버가 응답해준다는 보장은 없습니다. 만약 특정 클라이언트는 특정 서버가 응답해주는 것을 보장해주고 싶을 때는 ip 해시 방식을 사용합니다.

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

만약 로드밸런싱 알고리즘을 ip hash 방식으로 적용하고 싶다면 위와 같은 코드를 작성해줍니다. ip hash 방법을 활용하면 클라이언트의 ip 주소를 해싱한 값을 키(key)로 활용해 어떤 서버가 응답해줄 것인지를 정합니다.

5.4. 가중치 적용 방식

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

혹은 위와 같은 코드로 특정 서버에 가중치를 줄 수도 있습니다.

5.5. 파일 수정이 끝났다면?

service nginx reload

파일을 수정했다면 nginx를 재가동 시킵시다.

[리눅스] 우분투에서 호스트명, IP 주소 변경

Sun, 14 May 2023 00:00:00 +0900

우분투에서 호스트명, IP 주소 변경

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

관련 링크

1. 서론

이번포스팅에서는우분투에서 호스트 이름과 IP 주소를 변경해보겠습니다.

2. 호스트명 변경

2-1. 호스트 이름 확인

eevee@myserver01:/$ hostname
myserver01

2-1. 명령어로 변경

eevee@myserver01:/$ sudo hostnamectl set-hostname myserver02
eevee@myserver01:/$ sudo reboot now

위 실습코드는 기존의 호스트명은 myserver01인데, 이를 myserver02로 바꾸는 코드입니다.

2-1. vim 에디터로 변경

eevee@myserver01:/$ sudo vim /etc/hostname
myserver02

eevee@myserver01:/$ sudo reboot now

위 실습코드는 기존의 호스트명은 myserver01인데, 이를 myserver02로 바꾸는 코드입니다.

3. IP 주소 변경

이번에는 IP 주소를 변경해보겠습니다. 기존 IP 10.0.2.15에서 다음과 같이 10.0.2.16으로 변경해보겠습니다.

eevee@myserver02:/$ sudo vim /etc/netplan/00-installer-config.yaml
network:
ethernets:
  enp0s3:
    addresses: [10.0.2.16/8]
      routes:
        -	to: default
          via: 10.0.2.1
      nameservers:
        addresses: [8.8.8.8,8.8.4.4]
version: 2    

eevee@myserver02:/$ sudo netplan apply
eevee@myserver02:/$ ifconfig
...(중략)
enp0s3: inet 10.0.2.16
...(생략)

[리액트react] 프로젝트 초기 세팅, 불필요한 코드 지우기

Wed, 15 Mar 2023 00:00:00 +0900

리액트(react) 프로젝트 초기 세팅, 불필요한 코드 지우기

참고 링크

1. 프로젝트 생성

먼저 프로젝트를 생성합니다.

$ yarn create react-app 프로젝트명

터미널에 위 코드를 입력하면 리액트 프로젝트가 생성됩니다.

$ cd 프로젝트명
$ yarn start

그리고 위와 같이 프로젝트명 폴더로 이동해서 yarn start를 입력하면 브라우저 창에서 리액트 마크가 돌아가는 모습을 볼 수 있는데, 사실 이와 같은 기본 코드에는 불필요한 코드가 많아서 이번 포스팅에서는 불필요한 코드를 지우는 작업을 해보겠습니다.

2. 불필요한 파일 삭제 및 index.html 코드 정리

먼저 위와 같은 그림에서 좌측 파일 목록의 파일을 제외한 나머지 파일은 불필요하므로 모두 삭제해줍니다. 그리고 오른쪽 그림은 public 폴더의 index.html 파일인데, 해당 파일에서 노란색으로 표시한 줄을 모두 삭제해줍니다.

그러면 위와 같이 정리되는 것을 알 수 있습니다.

3. src/App.css 파일 정리

다음으로는 src 폴더 내부의 App.css 파일을 수정합니다. 위 그림과 같이 기존 코드를 모두 삭제하고 위 파일 내용처럼 정리해줍니다.

4. src/App.js 파일 정리

이번에는 src 폴더내부의 App.js 파일을 수정하겠습니다. 위 그림과 같이 간단하게 수정해줍니다.

5. src/index.css 파일 정리

이번에는 src 폴더 내부의 index.css 파일을 정리해줍니다. 위 그림에 표시된 부분을 모두 삭제해줍니다.

그러면 위와 같은 코드만 남습니다.

6. 실행

그리고 터미널에 yarn start 명령어를 입력하면 제대로 실행되는 것을 알 수 있습니다.

7. 참고

참고로 필요하다면 react-router-dom을 추가하면 좋습니다.

프로젝트명$ yarn add react-router-dom

[vscode] 윈도우에 VSCODE 설치하기

Sat, 11 Mar 2023 00:00:00 +0900

윈도우에 VSCODE 설치하기

이번 포스팅에서는 윈도우 운영체제에서 vscode를 설치해보겠습니다.

[nodejs] 윈도우에 노드JS(Nodejs) 설치하기

Mon, 06 Mar 2023 00:00:00 +0900

윈도우에 노드JS(Nodejs) 설치하기

이번 포스팅에서는 윈도우 운영체제에서 Nodejs을 설치해보겠습니다. 우선 https://nodejs.org/ko/download/에 접속하면 다음과 같은 페이지가 나타납니다.

[git] 윈도우에 깃(git) 설치하기

Sun, 05 Mar 2023 00:00:00 +0900

윈도우에 깃(git) 설치하기

이번 포스팅에서는 윈도우 운영체제에서 깃을 설치해보겠습니다. 우선 https://git-scm.com/downloads에 접속하면 다음과 같은 페이지가 나타납니다.

위 그림에서 윈도우를 클릭합니다.

그리고 위 그림과 같은 위치에 클릭해주면 다운로드가 시작됩니다.

다운로드 받은 파일을 실행하면 위와 같은 화면이 나오는데 next를 클릭합니다.

next를 클릭합니다.

설치를 마치고 윈도우 키를 누르고 git bash를 실행하면 위 그림 오른쪽과 같이 제대로 나오는 것을 알 수 있습니다.

[딥러닝] 파이토치 자세한 튜토리얼

Sun, 29 Jan 2023 00:00:00 +0900

파이토치 튜토리얼

참고링크

머신러닝	딥러닝	선형대수	기초통계	최적화
k-means	신경망이란	고유값,고유벡터	확률변수	컨벡스 셋
k-최근접이웃	성능함수	행렬식	확률분포	컨벡스 함수
선형회귀	신경망 학습	내적	모집단과 표본	라그랑주 듀얼
로지스틱회귀	교차연결	기저	평균과 분산	KKT 조건
릿지,라쏘회귀	합성곱 신경망	랭크, 차원	공분산, 상관계수	ROC 커브
의사결정나무	배치, 에포크 차이	선형변환	최대가능도추정	크로스 밸리데이션
서포트벡터머신	텐서플로기초(1)	직교행렬	베르누이,이항분포	실루엣 스코어
원클래스 SVM	텐서플로기초(2)	고유값분해	기하,음이항분포
LDA	seq2seq	특이값분해	초기하분포
GMM	opencv기초		포아송분포
부스팅	resnet		정규분포
사이킷런 실습	다각형내부판별		감마분포
	엣지판별		지수분포
			카이제곱분포
			베타분포
			균일분포

1. 서론

이번 포스팅에서는 파이토치를 처음 사용하시는 분들을 위한 튜토리얼을 작성해보겠습니다. 참고로 이번 포스트팅은 파이토치 공식 튜토리얼의 내용을 참고했으며, 해당 내용을 좀더 자세히 풀어썼다고 생각하시면 되겠습니다.

이번 튜토리얼은 3차 다항식을 이용해 사인(sin) 함수를 추정하는 문제를 다뤄보겠습니다.

2. 넘파이

먼저 넘파이 라이브러리를 활용해 문제를 풀어보겠습니다.

2.1. 라이브러리 불러오기 및 실제값 생성

import numpy as np
import math
import matplotlib.pyplot as plt

# 추정하고자 하는 실제 곡선
x = np.linspace(-math.pi, math.pi, 2000)
y = np.sin(x)  

위와 같은 코드를 작성해줍니다. 위 코드는 라이브러리를 불러오고 우리가 추정하고자 하는 실제 곡선인 sin 함수값을 생성하는 코드입니다. 위 코드로부터 생성된 y값이 실제값이라고 생각하면 되겠습니다.

plt.plot(x, y)
plt.show()

앞서 구한 y값을 시각화하면 위 그림과 같이 사인곡선이 나타나는 것을 볼 수 있습니다. 즉, 우리는 3차 다항식을 이용해 위 곡선을 추정하는 것이 목표입니다. 즉, 위 3차 다항식의 a, b, c, d를 딥러닝을 이용해 추정하는 것입니다.

2.2. 가중치 초기값 생성

# 가중치 초기
a = np.random.randn()
b = np.random.randn()
c = np.random.randn()
d = np.random.randn()

다음으로 가중치의 초기값을 정해줍니다. 초기값은 위 코드처럼 랜덤으로 정해줍니다.

>>> print(a, b, c, d)
0.1629 -0.563484 2.5714189 -0.062937

앞서만든 초기값을 확인해봅니다.

2.3. 학습

# 학습
learning_rate = 1e-6
for t in range(0, 1000):
    y_pred = a + b*x + c*x**2 + d*x**3
    
    ss = np.square(y_pred - y)**0.5
    loss = ss.sum()
    if t%100 == 99:
        print(t, loss)
    
    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred*x).sum()
    grad_c = (grad_y_pred*x**2).sum()
    grad_d = (grad_y_pred*x**3).sum()
    
    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

위 코드는 학습하는 코드인데, 코드가 길기 때문에 나눠서 보겠습니다.

# 학습
learning_rate = 1e-6
for t in range(0, 1000):
    y_pred = a + b*x + c*x**2 + d*x**3  

위 코드에서 learning_rate는 이름 그대로 학습율을 의미합니다. 그리고 반복문을 수행하는데 학습은 1000번 수행하며, 우리가 만든 추정식을 통해 구한 y의 추정값(예측값)을 y_pred라고 이름지어 줍니다.

    ss = np.square(y_pred - y)**0.5
    loss = ss.sum()
    if t%100 == 99:
        print(t, loss)

그리고 다음 단계로 비용함수를 정의해주는데, 이번 실습에서 비용함수는 오차제곱합으로 하겠습니다. 따라서 오차제곱합 ss를 통해 구한 손실의 총합이 위 식에서 loss가 되는 것입니다.

    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred*x).sum()
    grad_c = (grad_y_pred*x**2).sum()
    grad_d = (grad_y_pred*x**3).sum()

그리고 다음으로 그래디언트를 계산해줍니다. 위와 같은 방법으로 코딩하는 이유는 다음과 같습니다.

위 식에서 오차제곱합을 이용해 비용함수를 L로 정의하고 a에 대해 편미분한 값을 이용해 그래디언트를 구할 수 있습니다.

그리고 나머지 친구들에 대해서도 위와 같이 구할 수 있습니다.

    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

마지막 단계로 가중치를 업데이트 시킵니다. 위 코드는 다음 식을 이용해 작성한 것입니다.

2.4. 학습 결과

학습이 끝나고 최종 학습 결과인 a, b, c, d를 출력하면 다음과 같습니다.

# 학습 결과
>>> print(f"Result: y = {a} + {b} x + {c} x^2 + {d} x^3")
Result: y = -0.04471609 + 0.87041 x + 0.0077142708 x^2 + -0.095275 x^3

그리고 실제로 학습이 얼마나 잘 되었는지, 실제 곡선과 추정 곡선을 비교하면 다음과 같습니다.

plt.plot(x, y, color='blue')
plt.plot(x, y_pred, color='red')
plt.show()

2.5. 전체 코드

# 전체 코드
import numpy as np
import math
import matplotlib.pyplot as plt

# 추정하고자 하는 실제 곡선
x = np.linspace(-math.pi, math.pi, 2000)
y = np.sin(x)

# 가중치 초기
a = np.random.randn()
b = np.random.randn()
c = np.random.randn()
d = np.random.randn()

# 학습
learning_rate = 1e-6
for t in range(0, 1000):
    y_pred = a + b*x + c*x**2 + d*x**3
    
    ss = np.square(y_pred - y)**0.5
    loss = ss.sum()
    if t%100 == 99:
        print(t, loss)
    
    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred*x).sum()
    grad_c = (grad_y_pred*x**2).sum()
    grad_d = (grad_y_pred*x**3).sum()
    
    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

# 학습 결과
print(f"Result: y = {a} + {b} x + {c} x^2 + {d} x^3")

3. 파이토치

위 코드를 파이토치를 이용해 작성하면 다음과 같습니다.

import torch
import math

dtype = torch.float
device = torch.device('cpu')

x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype)
y = torch.sin(x)

a = torch.randn((), device=device, dtype=dtype)
b = torch.randn((), device=device, dtype=dtype)
c = torch.randn((), device=device, dtype=dtype)
d = torch.randn((), device=device, dtype=dtype)

learning_rate = 1e-6
for t in range(2000):
    y_pred = a + b * x + c * x ** 2 + d * x ** 3

    ss = (y_pred - y).pow(2)
    loss = ss.sum().item()
    if t % 100 == 99:
        print(t, loss)

    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred * x).sum()
    grad_c = (grad_y_pred * x ** 2).sum()
    grad_d = (grad_y_pred * x ** 3).sum()

    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3')

4. iris 데이터 분류 학습하기

import pandas as pd
from sklearn.model_selection import train_test_split

import torch
import torch.nn as nn
import torch.optim as optim

# parameters
learning_rate = 0.01
epochs = 1000
  
df = pd.read_csv("./iris.csv")
  
X = df[["sepal_length","sepal_width","petal_length","petal_width"]].values
y = df["class"].values
  
X = torch.tensor(X, dtype=torch.float32)
y = torch.tensor(y, dtype=torch.long)
  
X_tn, X_te, y_tn, y_te = train_test_split(X, y, random_state=777)
  
class IrisNet(nn.Module):
    def __init__(self):
        super(IrisNet, self).__init__()
        self.layer1 = nn.Linear(4, 10)
        self.layer2 = nn.Linear(10, 3)
        
    def forward(self, x):
        x = torch.relu(self.layer1(x))
        x = self.layer2(x)
        return x
  
mymodel = IrisNet()
  
criterion = nn.CrossEntropyLoss()
optimizer = optim.SGD(mymodel.parameters(), lr=learning_rate)
  
for epoch in range(epochs):
    optimizer.zero_grad()
    outputs = mymodel(X_tn)
    cost = criterion(outputs, y_tn)
    cost.backward()
    optimizer.step()

    if (epoch+1) % 100 == 0:
        print('Epoch [%d/%d], Loss: %.4f' % (epoch+1, epochs, cost.item()))

Epoch [100/1000], Loss: 0.9430
Epoch [200/1000], Loss: 0.7136
Epoch [300/1000], Loss: 0.5374
Epoch [400/1000], Loss: 0.4417
Epoch [500/1000], Loss: 0.3793
Epoch [600/1000], Loss: 0.3315
Epoch [700/1000], Loss: 0.2925
Epoch [800/1000], Loss: 0.2606
Epoch [900/1000], Loss: 0.2345
Epoch [1000/1000], Loss: 0.2132

with torch.no_grad():
    prediction = mymodel(X_te)
    correct_prediction = torch.argmax(prediction, 1) == y_te
    accuracy = correct_prediction.float().mean()
    print('Accuracy:', accuracy.item())

1.0

[머신러닝] 비지도학습 - One Class SVM

Wed, 30 Nov 2022 00:00:00 +0900

비지도학습 - One Class SVM(One Class Support Vector Machine)

참고링크

머신러닝	딥러닝	선형대수	기초통계	최적화
k-means	신경망이란	고유값,고유벡터	확률변수	컨벡스 셋
k-최근접이웃	성능함수	행렬식	확률분포	컨벡스 함수
선형회귀	신경망 학습	내적	모집단과 표본	라그랑주 듀얼
로지스틱회귀	교차연결	기저	평균과 분산	KKT 조건
릿지,라쏘회귀	합성곱 신경망	랭크, 차원	공분산, 상관계수	ROC 커브
의사결정나무	배치, 에포크 차이	선형변환	최대가능도추정	크로스 밸리데이션
서포트벡터머신	텐서플로기초(1)	직교행렬	베르누이,이항분포	실루엣 스코어
원클래스 SVM	텐서플로기초(2)	고유값분해	기하,음이항분포
LDA	seq2seq	특이값분해	초기하분포
GMM	opencv기초		포아송분포
부스팅	resnet		정규분포
사이킷런 실습	다각형내부판별		감마분포
	엣지판별		지수분포
			카이제곱분포
			베타분포
			균일분포

1. SVM 복습

우리는 지도학습 알고리즘 중 서포트 벡터 머신(support vector machine, 이하 SVM)이라는 알고리즘을 배웠습니다. 서포트 벡터 머신은 지도학습 알고리즘이므로 라벨링이 되어 있는 데이터를 대상으로 학습하는 알고리즘 입니다. 그리고 SVM 포스팅에서도 알 수 있듯, SVM의 핵심 개념은 서포트 벡터를 이용해 분류하는 것이었습니다.

2. One Class SVM의 목적

반면 이번 포스팅에서 알아볼 One Class SVM(one class support vector machine)은 비지도학습 알고리즘 중 하나입니다. 즉, one class svm은 서포트 벡터 개념을 이용해 라벨링되어 있지 않은 데이터를 클러스터링 하는 방법입니다.

이번 포스팅에서는 비지도학습에 사용되는 One Class SVM에 대해 알아보겠습니다.

위 그림을 보면 라벨링 되어 있지 않은 데이터들이 존재합니다. 우리의 목적은 위와 같은 데이터들을 다음 그림과 같이 이상치와 정상 데이터로 클러스터링 하는 것입니다.

그렇다면 위와 같이 클러스터링을 어떻게 할 수 있을까요?

One Class SVM 또한 서포트 벡터를 활용하는 방법이므로 위 그림과 같이 정상 데이터와 이상치 데이터를 나누는 초평면(hyperplane)을 생성해 이를 기준으로 정상과 이상치를 구분할 수 있습니다.

3. One Class SVM의 개념

One Class SVM을 통한 클러스터링을 좀더 자세히 표현하면 다음과 같이 표현할 수 있습니다.

위 그림을 보면 일반적인 서포트 벡터 머신과 다르게 One Class SVM의 경우에는 원점에서 $w$벡터가 시작된다고 볼 수 있습니다. 그리고 원점으로부터 초평면까지의 거리를 $\rho$라고 하며, 우리의 목적은 초평면으로부터 데이터가 최대한 멀어지도록 초평면을 선정하는 것입니다. 그리고 초평면으로부터 이상치까지의 거리를 $\xi$라고 하겠습니다. 참고로 정상 데이터의 경우에는 $\xi$값이 0을 가집니다.

위 그림을 통해 이상치 데이터의 특징에 대해 좀 더 알아보겠습니다. 이상치 데이터의 경우 $w$ 벡터와 내적을 해서 $w^T x$값을 구해도 해당 값이 초평면을 넘어가지 못합니다. 이때 원점에서 초평면까지의 거리는 $\rho$이므로 $w^T x$값은 $\rho - \xi$가 됩니다.

4. One Class SVM 최적화 목적함수

기본적인 서포트 벡터 머신과 마찬가지로 one class svm 또한 다음과 같은 목적함수를 최적화 하는 방식입니다.

위 목적함수에서 $\phi (x)$는 새로운 피처 공간에서의 데이터를 의미합니다. 그리고 위 목적함수의 세번째 term인 $\rho$는 원점과 hyperplane과의 거리를 의미하며 이 거리를 최대화 해야합니다. 그러나 목적함수 자체가 최소화 시키는 $min$이 앞에 붙었으므로 거리 $\rho$에도 마이너스 부호를 붙여주어야 최대화 문제를 최소화 문제로 바꾸게 됩니다.

목적함수에 대해 좀 더 자세히 알아보겠습니다. 위 그림과 같이 첫번째 항은 모델의 변동성 감소를 위한 항입니다. 이는 Regularization 역할을 수행하는 것이며, 같은 값이라면 $x$의 변화에 따라 변동성이 크지 않도록 하기 위해서 $w$값을 최소화 시키는 방식을 활용합니다.

그리고 두번째 항을 보면 이는 이상치 영역에 존재하는 데이터들에게 부여되는 패널티 입니다. 정상 데이터의 경우 $\xi=0$인 반면, 이상치 영역에 존재하는 데이터들은 $\xi >0$이므로 이들의 합이라고 표현할 수 있습니다. 이때 $l$은 전체 데이터 개수를 나타내며 사실 익숙한 노테이션인 $n$으로 써도 되는데, One Class Svm을 설명하는 대부분의 분들이 $l$을 사용하므로 저도 $l$을 사용하겠습니다. $\nu$의 경우에는 사용자가 지정하는 하이퍼 파라미터인데, 0과 1사이의 값을 가지며 이 값에 따라 초평면의 형태가 변경됩니다. $\nu$값에 대해서는 이후에 더 자세히 설명하겠습니다.

마지막으로 세번째 항을 보면 이는 원점과 최대한 멀리 떨어진 초평면까지의 거리를 의미합니다.

목적함수의 제약식은 두가지가 존재하는데 위와 같이 첫번째 제약식을 먼저 보면, 위 제약식의 의미는 앞서 설명한 것 처럼 벡터 $w$와 데이터 포인트 $x_i$를 내적한 값은 $\rho - \xi_i$ 보다 크거나 같아야 한다는 의미입니다.

그리고 두번째 제약식의 의미는 위와 같습니다. 정상 데이터의 경우에는 $\xi_i$가 0이 되고, 이상치 데이터의 경우에는 $\xi_i > 0$이 됩니다.

5. One Class SVM 최적화 솔루션 구하기

앞서 배운 목적함수와 제약식을 한번에 표현하기 위해 대해 라그랑주 프리멀 함수를 구하면 다음과 같이 구할 수 있습니다.

그리고 KKT 조건에 의해 각각의 파라미터로 편미분하면 다음과 같은 결과를 구할 수 있습니다.

그리고 위에서 구한 $w$값을 다음 그림과 같이 다시 라그랑주 프리멀 함수에 넣어주겠습니다.

그러면 다음과 같이 라그랑주 듀얼 함수를 구할 수 있습니다.

위에서 구한 라그랑주 듀얼 함수는 다음과 같이 깔끔하게 정리가 가능합니다.

앞서 파라미터 편미분값을 이용하면 위와 같이 라그랑주 듀얼 함수의 두번째 항과 세번째 항이 깔끔하게 삭제 되는 것을 알 수 있습니다.

정리하면 위와 같이 최적화 문제를 정의할 수 있습니다.

5. One Class SVM 알파 값의 의미

그렇다면 앞서 언급한 최적화 문제에서 $\alpha$ 값이 의미하는 것은 무엇일까요?

위 식과 같이 $\alpha$값의 범위에 따라 정상 데이터, 초평면 위에 걸쳐있는 데이터, 이상치 데이터로 구분할 수 있습니다. 각 조건들을 조금더 자세히 알아보겠습니다.

먼저 첫번째 조건을 정리하면 위와 같습니다. 위 정리는 $\alpha$값이 0일때 해당 데이터는 정상 데이터라는 것을 의미하는 그림입니다.

두번째 조건을 정리하면 위와 같습니다. 두번째 조건은 해당 조건을 만족하는 데이터는 이상치 데이터라는 의미입니다.

마지막 세번째 조건을 정리하면 위와 같습니다. 세번째 조건은 해당 조건을 만족하는 데이터는 초평면 위에 존재하는 데이터라는 의미입니다.

6. One Class SVM 누 값의 의미

이번에는 $\nu$값의 의미에 대해 알아보겠습니다. 이를 정리하면 다음과 같습니다.

결국 $\nu l$의 의미는 전체 데이터 중 이상치로 표현되는 최대 객체 수가 $vl$개라는 의미입니다. 또한 $\nu$의 의미는 서포트 벡터 개수의 하한임과 동시에 패널티가 부여되는 이상치 서포트 벡터 비율이 10%미만 이라는 뜻입니다. 결국 $\nu$값을 어떻게 정하느냐에 따라 결과물을 미리 예상할 수 있는 것입니다.

7. 사이킷 런에서의 One Class SVM 사용

파이썬에서는 사이킷런이라는 머신러닝 라이브러리를 제공합니다. 그리고 다음과 같이 one class svm을 쉽게 사용할 수 있습니다.

>>> from sklearn.svm import OneClassSVM
>>> X = [[0], [0.44], [0.45], [0.46], [1]]
>>> clf = OneClassSVM(gamma='auto').fit(X)
>>> clf.predict(X)
array([-1,  1,  1,  1, -1])

>>> clf.score_samples(X)
array([1.7798..., 2.0547..., 2.0556..., 2.0561..., 1.7332...])

8. 사이킷 런에서의 One Class SVM 성능 평가

One Class SVM은 비지도학습이므로 다음과 같이 실루엣 스코어를 사용해 쉽게 성능을 평가할 수 있습니다. 실루엣 스코어에 대한 자세한 설명은 링크를 참고해주세요.

>> from sklearn.metrics import silhouette_score
>> sil_score = silhouette_score(X, labels)
>> print(sil_score)

0.7598181300128782

[머신러닝] 이상치 분석 성능 평가 - 실루엣 스코어

Mon, 28 Nov 2022 00:00:00 +0900

이상치 분석 성능 평가에 사용하는 실루엣 스코어

참고링크

머신러닝	딥러닝	선형대수	기초통계	최적화
k-means	신경망이란	고유값,고유벡터	확률변수	컨벡스 셋
k-최근접이웃	성능함수	행렬식	확률분포	컨벡스 함수
선형회귀	신경망 학습	내적	모집단과 표본	라그랑주 듀얼
로지스틱회귀	교차연결	기저	평균과 분산	KKT 조건
릿지,라쏘회귀	합성곱 신경망	랭크, 차원	공분산, 상관계수	ROC 커브
의사결정나무	배치, 에포크 차이	선형변환	최대가능도추정	크로스 밸리데이션
서포트벡터머신	텐서플로기초(1)	직교행렬	베르누이,이항분포	실루엣 스코어
원클래스 SVM	텐서플로기초(2)	고유값분해	기하,음이항분포
LDA	seq2seq	특이값분해	초기하분포
GMM	opencv기초		포아송분포
부스팅	resnet		정규분포
사이킷런 실습	다각형내부판별		감마분포
	엣지판별		지수분포
			카이제곱분포
			베타분포
			균일분포

1. 서론

PCA 혹은 One class SVM과 같은 방법을 통해 이상치 분석을 할떄는 실루엣 스코어(silouette score)라는 성능 평가 지표를 사용합니다. 어떻게 이상치 분석 성능지표로 실루엣 스코어를 사용하는게 가능한 것일까요?

2. 실루엣 스코어의 개념

실루엣 방법은 최적화된 클러스터 갯수를 찾는데 사용되며 또한 데이터 클러스터 내부에 존재하는 데이터 포인트들 간 일관성(consistency)의 타당성을 평가하는데 사용됩니다. 실루엣 방법은 각 데이터 포인트의 실루엣 계수(silouette coefficient)를 계산합니다. 이때 실루엣 계수가 의미하는 것은 해당 데이터 포인트가 본인이 속한 클러스터가 다른 클러스터에 비해 얼마나 유사한지를 측정합니다. 즉, 간단하게 말해서 얼마나 분류가 잘 되었는지를 말해주는 것이죠.

3. 실루엣 스코어의 값의 범위

실루엣 스코어(silouette score)는 -1부터 1사이의 값을 가지는데 특정 값이 의미하는 것은 다음과 같습니다. 우선 실루엣 스코어가 +1이라는 뜻은 해당 샘플이 이웃한 클러스터로부터 멀리 떨어져있다는 것을 의미합니다. 즉, 실루엣 스코어가 +1이라는 것은 클러스터링이 확실하게 잘되었다는 것을 의미하죠. 왜냐면 클러스터끼리 멀리 떨어져 있으니까요.

실루엣 스코어가 0이라는 것은 해당 샘플 데이터가 이웃한 클러스터와 매우 가까이 붙어 있다는 것을 의미합니다. 그리고 실루엣 스코어가 0보다 작다는 것은 해당 샘플 데이터가 잘못된 클러스터에 속해있는 것을 의미합니다.

4. 실루엣 스코어 계산 방법

실루엣 스코어는 데이터 포인트 별로 값을 계산하고 다음과 같은 공식을 따릅니다.

위 공식의 의미는 데이터 포인트가 자신이 속한 클러스터에 가까울수록 실루엣 스코어는 1에 가까운 값을 가집니다.

5. 실루엣 스코어 계산 과정

이번에는 실제로 간단하게 실루엣 스코어를 직접 계산해보겠습니다. 먼저 비지도학습 방법 중 하나를 사용해 다음과 같이 클러스터링 작업을 했다고 가정하겠습니다. 비지도 학습 결과, 다음 그림과 같이 전체 데이터를 세 개의 클러스터로 나누었습니다.

지금부터 우리가 할 것은 특정 데이터 포인트에 대해 실루엣 스코어를 계산함으로써 해당 데이터 포인트가 제대로 클러스터링 되었는지를 확인할 것입니다.

위 그림과 같이 노란색 클러스터 1에 속하는 i번째 데이터 포인트에 대한 실루엣 스코어를 계산해보겠습니다. 먼저 i번째 데이터와 자신이 속해있는 클러스터 내 데이터들 간의 거리의 평균 $a_i$를 구하면 위와 같습니다. 클러스터 내 평균 거리를 구할때 나누는 개수는 자기 자신을 제외하므로 클러스터 내 전체 데이터 개수가 아니라 1개를 뺀 값과 동일합니다.

앞서 데이터 포인트와 자신이 속한 클러스터 내 포인트들 간 거리 평균을 구했다면 이번에는 실루엣 스코어를 구하고자하는 데이터 포인트와 다른 클러스터에 속한 데이터 포인트들 간 평균 거리를 구해보겠습니다. 먼저 클러스터 2에 속한 데이터 포인트들과 평균 거리를 구하면 위 그림과 같이 6이라는 사실을 알 수 있습니다.

마찬가지 방법으로 이번에는 클러스터 3에 속한 데이터 포인트 들과의 평균거리를 구하면 위와 같이 11이라는 결과를 알 수 있습니다. 그러면 이러한 사실은 어떤 것을 의미하는 걸까요?

정리하면 위 그림과 같이 우리가 실루엣 스코어를 구하고자 하는 데이터 포인트와 클러스터 2와의 평균 거리는 6이고, 클러스터 3과의 평균 거리는 11이라는 것을 알 수 있습니다. 그리고 이들 중 작은 값은 6이므로 $b_i$는 6이라는 것을 알 수 있습니다. 우리가 실루엣 스코어를 구하고자 하는 데이터 포인트와 가장 가까운 클러스터는 2라는 것을 알 수 있습니다.

앞서 구한 값들을 이용해 해당 데이터 포인트의 실루엣 스코어는 위와 같이 구할수 있으며, 다른 모든 데이터 포인트들의 실루엣 스코어를 구할 수 있습니다.

6. 사이킷런에서의 실루엣 스코어 함수

그렇다면 파이썬 라이브러리인 사이킷런에서의 실루엣 스코어 함수는 어떨까요? 우선 사이킷런에서의 실루엣 스코어 함수는 다음과 같이 사용합니다.

>> from sklearn.metrics import silhouette_score
>> sil_score = silhouette_score(X, labels)
>> print(sil_score)

0.7598181300128782

위 코드에서 X는 비지도학습할 때 사용하는 피쳐 데이터를 의미하며, labels는 X 데이터를 이용해 클러스터링한 결과를 의미합니다. 따라서 전체 데이터에 대해 클러스터링이 잘 되었는지를 실루엣 스코어로 표현합니다. 그런데 이상한 점이 있습니다. 실루엣 스코어는 특정 데이터 포인트에 대한 점수인데, 어떻게 전체 데이터에 대한 실루엣 스코어를 구했는데 위와 같이 하나의 숫자가 출력될까요? 그 이유는 silhouette_score 함수는 모든 데이터에 대한 실루엣 스코어의 평균값을 보여주기 때문입니다.

[Infra] 도커(docker)(11) 도커로 redis 컨테이너 배포하기

Thu, 10 Nov 2022 00:00:00 +0900

도커(docker)(11) 도커로 redis 컨테이너 배포하기

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

1. 서론

이번 포스팅에서는 도커로 레디스(redis)를 사용해보겠습니다.

2. redis 설치

먼저 도커 허브에서 다음 코드를 이용해 레디스 이미지를 pull 받습니다.

$ docker pull redis

Using default tag: latest
latest: Pulling from library/redis
e9995326b091: Pull complete
f2cd78d6f24c: Pull complete
8f3614d34c89: Pull complete
697fd51ec515: Pull complete
a554cf50a327: Pull complete
66f93c02e79c: Pull complete
Digest: sha256:aeed51f49a6331df0cb2c1039ae3d1d70d882be3f48bde75cd240452a2348e88
Status: Downloaded newer image for redis:latest
docker.io/library/redis:latest

그리고 이미지를 확인해봅니다.

$ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED         SIZE
redis                latest    c2342258f8ca   2 weeks ago     117MB

그리고 예제처럼 다음 코드를 이용해 레디스 인스턴스를 띄웁니다.

$ docker run --name some-redis -d redis
408567b535cc96dfb86f9bc0d56d525e8881b9efe83a5b1e1aa3a6ea47ecf19c

그리고 컨테이너를 확인해보면 다음과 같이 잘 작동하는 것을 알 수 있습니다.

$ docker container ls
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS      NAMES
408567b535cc   redis     "docker-entrypoint.s…"   7 seconds ago   Up 5 seconds   6379/tcp   some-redis

[Infra] 도커(docker)(10) 도커 관련 각종 문제 해결

Wed, 09 Nov 2022 00:00:00 +0900

도커(docker)(10) 도커 관련 각종 문제 해결

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

사례0) 도커 서비스를 재시작하고 싶을때

0-1. 문제 상황 설명

도커 서비스를 재시작하고 싶어요

0-2. 해결 방법

$ service docker restart
또는
$ systemctl restart docker 

사례1) 도커 이미지가 안지워질때

1-1. 문제 상황 설명

간만에 도커 이미지 좀 정리하려고 image 리스트를 출력했습니다. 다음은 제 도커 이미지 리스트 입니다.

$ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED         SIZE
my-ubuntu-02         0.1       9c36e432fe81   12 days ago     119MB
ubuntu               latest    cdb68b455a14   2 weeks ago     77.8MB
mytest-django-test   latest    35fa5d40cf1c   5 weeks ago     976MB
mytest-nginx-test    latest    b2631854b239   5 weeks ago     142MB
nginx-test           latest    61408ccf33f5   5 weeks ago     142MB
practice-test        latest    66f88db0ac1d   5 weeks ago     972MB
my-ubuntu            0.1       38cc32eea570   6 weeks ago     116MB
postgres             latest    75993dd36176   8 weeks ago     376MB
mytest-psql-test     latest    ad451517b273   8 weeks ago     376MB
nginx                latest    2d389e545974   8 weeks ago     142MB
ubuntu               <none>    2dc39ba059dc   2 months ago    77.8MB
python               3.10.4    e4ccc57bca82   5 months ago    920MB
hello-world          latest    feb5d9fea6a5   13 months ago   13.3kB
django               latest    eb40dcf64078   5 years ago     436MB

저는 위 이미지 중 아래에서 네번쨰에 있는 ubuntu 이미지를 지우려고 했습니다. 그랬더니 다음과 같은 에러 메시지가 출력됩니다.

$ docker image rm 2dc39ba059dc
Error response from daemon: conflict: unable to delete 2dc39ba059dc (cannot be forced) - image has dependent child images

위 메시지를 보면 해당 이미지는 dependent child image를 가지고 있으므로 삭제 할 수 없다는 것을 알 수 있습니다.

1-2. 해결 방법

따라서 해당 이미지를 삭제하고 싶다면 먼저 의존성 있는 이미지가 뭔지부터 알아야합니다.

$ docker inspect --format=' ' $(docker images --filter since={이미지ID} -q)

위 커맨드를 이용해 의존성 있는 이미지를 모두 검색합니다. since 옵션은 해당 id로부터 만들어진 이미지를 출력하라는 뜻입니다. 그리고 -q는 –quiet와 같은 옵션으로 이미지ID만 출력하라는 뜻입니다. 그 결과는 다음과 같습니다.

$ docker inspect --format=' ' $(docker images --filter since=2dc39ba059dc -q)
sha256:9c36e432fe81f3188a2e71fd81ffd69f0d952ca1453ee3967616ee2c5b5e3e40 sha256:cdb68b455a141ed921945f6d39a8c0694a7e21a37b2b030488d73e38875a26cc
sha256:cdb68b455a141ed921945f6d39a8c0694a7e21a37b2b030488d73e38875a26cc
sha256:35fa5d40cf1ca01f0375f4a57cba48315eea1f38e8b46594b40e59ace946efc8
sha256:b2631854b2391bfadd1b47ec501e6b3446635f11836aa1a3555fbb691bf4cb51
sha256:61408ccf33f58c2918096acbf956eb91277686928ef248b23b8b7028966231a5 sha256:2d389e545974d4a93ebdef09b650753a55f72d1ab4518d17a30c0e1b3e297444
sha256:66f88db0ac1d917b46714d00d2ee82210af48afa55376953c6b2af38cdc62ea6 sha256:1df04f456aba3908f6b19ce91f9cab7c530dab8f4ca175efa2bcd3dfe32c3688
sha256:38cc32eea5700d59e0f6a171f896242c1a1ab79d426ad15acd8d41ab3c8c91f8 sha256:2dc39ba059dcd42ade30aae30147b5692777ba9ff0779a62ad93a74de02e3e1f
sha256:75993dd36176c7d4be8c1e6d88a115f1fb35a85451088699dbdc80659ad688ed
sha256:ad451517b273d74c080edd5fbcd3bccbb5e6b3bce5be8c002512f5656b957f79
sha256:2d389e545974d4a93ebdef09b650753a55f72d1ab4518d17a30c0e1b3e297444

위 결과를 보면 아래에서 4번째 줄을 보면 38cc32로 시작하는 이미지가 우리가 2dc39ba 이미지의 자식임을 알 수 있습니다. 따라서 해당되는 두개의 이미지를 같이 지워주면 다음과 같이 이미지를 지울 수 있습니다.

$ docker image rm 38cc32eea570 2dc39ba059dc
Untagged: my-ubuntu:0.1
Deleted: sha256:38cc32eea5700d59e0f6a171f896242c1a1ab79d426ad15acd8d41ab3c8c91f8
Deleted: sha256:e8bb83840f3339c0e86348cf01a2eb1340488186c34e430addab31f05778bf7c
Untagged: ubuntu@sha256:20fa2d7bb4de7723f542be5923b06c4d704370f0390e4ae9e1c833c8785644c1
Deleted: sha256:2dc39ba059dcd42ade30aae30147b5692777ba9ff0779a62ad93a74de02e3e1f
Deleted: sha256:7f5cbd8cc787c8d628630756bcc7240e6c96b876c2882e6fc980a8b60cdfa274

그리고나서 마지막으로 image 목록을 확인하면 다음과 같이 결과를 확인할 수 있습니다.

$ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED         SIZE
my-ubuntu-02         0.1       9c36e432fe81   12 days ago     119MB
ubuntu               latest    cdb68b455a14   2 weeks ago     77.8MB
mytest-django-test   latest    35fa5d40cf1c   5 weeks ago     976MB
mytest-nginx-test    latest    b2631854b239   5 weeks ago     142MB
nginx-test           latest    61408ccf33f5   5 weeks ago     142MB
practice-test        latest    66f88db0ac1d   5 weeks ago     972MB
postgres             latest    75993dd36176   8 weeks ago     376MB
mytest-psql-test     latest    ad451517b273   8 weeks ago     376MB
nginx                latest    2d389e545974   8 weeks ago     142MB
python               3.10.4    e4ccc57bca82   5 months ago    920MB
hello-world          latest    feb5d9fea6a5   13 months ago   13.3kB
django               latest    eb40dcf64078   5 years ago     436MB

사례2) docker compose를 통한 이미지 빌드가 안될때(rpc error)

2-1. 문제 상황 설명

도커 컴포즈를 이용해 빌드를 하는데 다음과 같은 에러 메시지가 발생합니다.

$ docker compose up -d --build
[+] Building 0.0s (4/5)
 => [ai_portal_dl_ai_solution internal] load build definition from Dockerfile  
 => => transferring dockerfile: 32B  
 => [ai_portal_nginx internal] load build definition from Dockerfile  
 => => transferring dockerfile: 2B                                                                                                         
 => [ai_portal_dl_ai_solution internal] load .dockerignore   
 => => transferring context: 2B   
 => CANCELED [ai_portal_dl_ai_solution internal] load metadata for docker.io/library/python:3.9.7  
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount161974054/Dockerfile: no such file or directory

위 메시지를 보면 해당 도커 파일이 존재하지 않거나 경로가 존재하지 않는다는 것을 알 수 있습니다.

2-2. 해결 방법

위 문제의 해결 방법은 docker compose가 빌드하는 하위 폴더들의 Dockerfile의 이름을 확인해보면 문제의 원인을 알 수 있습니다. Dockerfile의 이름은 Dockerfile이어야지 DockerFile이면 안됩니다. 따라서 DockerFile로 잘못이름 붙여진 파일의 이름을 다시 Dockerfile로 고쳐주면 잘 돌아가는 것을 볼 수 있습니다.

사례 3) docker compose를 통한 이미지 빌드가 안될때(용량 부족)

3-1. 문제 상황 설명

도커 컴포즈를 이용해 빌드를 하려는데 no space on device라며 용량이 부족하다는 메시지가 뜹니다.

3-2. 해결 방법

위와 같이 용량이 부족한 경우에는 docker service prune명령어를 이용해 필요없는 것들을 모두 지웁니다.

$ docker system prune

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N] y

위와 같이 쓸데없는것을 지우면 용량이 늘어나서 빌드가 잘 되는 것을 볼 수 있습니다.

[머신러닝] 인공지능, 머신러닝 연구가 현실과 멀어지고 고립되는 이유

Sun, 09 Oct 2022 00:00:00 +0900

인공지능, 머신러닝 연구가 현실과 멀어지고 고립되는 이유

참고 링크

원문

시작하며

본 포스팅은 위 링크에 나오는 트위터 스레드를 편집, 재구성해서 쓴 글입니다. 머신러닝 업계에 종사하고 있다면 한 번쯤 생각해 볼 내용이라고 생각합니다.

인공지능 벤치마크 섬이 만들어지는 과정

수많은 머신러닝 학계에서의 연구는 현실적인 문제를 해결하는 문제에서 멀어지고 그들만의 벤치마크 섬을 만든다. 어떻게 이런일이 생길 수 있을까? 왜 학자들은 이 패턴에서 벗어날 수가 없는 것일까? 머신러닝 연구는 다음과 같은 과정에 의해 그들 스스로를 고립시킨다.

연구 주제를 정한다. 예를 들면 다음과 같은 연구 주제를 정한다고 해보자.

머신러닝을 이용해 x-ray 이미지에서 covid-19 탐지하기

연구 주제에 대해 첫번째 논문이 등장하고 실제 문제를 해결할 수 있는 근거를 제공한다.
선례가 만들어졌다. 첫 논문은 다음 연구를 위한 초석이 된다.
물론 첫번째 논문에도 가정이 깔려있다. 그러나 사람들은 첫 번째 논문의 가정, 근거에 대해 더 이상 의문을 품지 않고 받아들인다.
점차 더 많은 학자들이 더 많은 데이터셋과 예측 모델들을 만들어낸다.
연구 커뮤니티는 서로의 논문을 인용하고 평가한다.
어떤 데이터 셋은 벤치마크가 되고 어떤 예측 모형은 최신(state-of-the-art) 모형이 된다.
예측 성능은 논문을 개선하기 위한 측정 수단이 된다. 그리고 성능 개선 정도는 점차 미비해진다.
초기 연구 과정에서 해결하려고 했던 문제는 뒷전이 되어버린다.
현실과의 디커플링 완료.

좀 더 자세한 이야기

위 패턴에 대해 좀 더 생각해보자. 예를 들어 x-ray 이미지를 이용해 covid-19를 예측하는 수백가지 예측 모형이 있다고 하자. 첫번째 학자는 예측 모델과 데이터를 퍼블리싱하고 연구를 통해 해결점을 제시하려던 연구 질문에 대해 이야기한다.

이러한 “개척자(pioneer) 논문”은 해당 연구 주제에 대해 더 많은 논문이 나올수 있는 초석이 된다. 이 때, 첫 논문에 사용된 예측 모형, 가정, 근거들이 확립된다. 첫 논문이 좋은 저널에 accept되면 다른 팔로우업 논문들이 쉽게 따라올 수 있는 환경이 조성된다.

그리고 이는 다음 세대 학자들이 새로운 연구 주제를 생각하기 위한 고생을 덜어준다. 개척자 논문이 존재한다는 것은 해당 연구 주제가 유효하다는 뜻이다. 기본적인 가정들과 근거들에 대해서는 사람들은 더이상 의문을 가지지 않는다. 따라서 새로운 연구 주제를 생각하는 대신 개척자 논문의 연구 주제를 따라간다.

더욱 더 많은 학자들이 해당 주제에 대해 연구한다. 그리고 그들은 그들의 데이터와 예측 모델을 퍼블리시한다. 이렇게 모여든 학자들은 새로운 커뮤니티를 형성한다. 자연스럽게 그들은 서로의 논문을 인용하고 새로운 논문이 나올때 리뷰어 역할까지 하게 된다.

이렇게 어떤 데이터셋은 벤치마크가 되고 어떤 예측 모형은 최신(state of the art) 모형이 된다. 여기가 중요한 포인트인데, 이 대목에서 연구 목적이 변화한다. 예측 성능은 모형 개선의 유일한 측정 수단이 되고 성능 개선 정도는 점차 미비해진다.

이것은 일종의 유인 판매(bait-and-switch)라고 할 수 있다. 초기에 원래 연구를 통해 해결하려고 했던 연구 질문은 이제 더이상 상관이 없게 되었다. 이제 연구 목적은 벤치마크 모형이나 최신 모형보다 더 나은 성능을 보이는 더 많은 머신러닝 모형을 개발하는 것으로 대체되었다.

그리고 연구 목적의 유인 판매로 인해 연구 분야는 현실과 디커플링 되었다.

그렇다면…왜?

우리는 학자들의 인센티브, 즉, 논문 많이 쓰기, 더 많은 인용 횟수에 대해 다시 생각해봐야한다. 유인 판매는 논문을 쓰기 쉽게 만들고 논문을 위한 논문을 생산한다. 기존 머신러닝을 아주 살짝 수정한 모형이 벤치마크 모형보다 낫다면 퍼블리시 될 수 있다. 더 많은 학자들은 토픽 X에 대해 논문을 쓰고, 평균적으로 인용 횟수가 더 많아진다. 그리고 논문을 쓰기 쉽게 만드는 것 뿐만 아니라 논문 리뷰어의 삶도 개선시킨다.

오~이건 벤치마크 모형보다 개선됬네, 아, 이건 아니네.

라고 좀 더 쉽게 논문을 심사할 수 있게 만든다. 그리고 학자들에게 퍼블리시는 인센티브 뿐만 아니라 직업 존속 자체가 달렸다.

모든 벤치마크 모형이 이렇다는 것은 아니다. 벤치마크 모형이 있는것은 유용하고 벤치마크 모형을 개선하는 것은 분명 실제 문제를 해결하는데 영향이 있을 것이다. 예를 들어 ImageNet 벤치마크 데이터셋은 이미지 분류의 실제 개선을 이끌어냈다.

이는 비단 인공지능, 머신러닝, 딥러닝 분야에 국한된 문제가 아니다. 다른 분야에도 똑같이 적용할수 있다. 처음에는 현실 문제를 해결하기위한 의도로 시작한다. 점차 인용루프, 퍼블리시 인센티브 생태계가 치고 들어온다. 이는 학계의 기저에 깔려있는 문제 때문이다. 현실문제를 해결하는게 아니라 논문 퍼블리시에 집중하는 것이 그것이다. 논문. 그리고 더 많은 논문. 다른건 중요치 않다. 학자와 학계는 논문의 양과 질로 판단한다.

학자들이 이 패턴을 벗어나고 싶을리없다. 더 많은 논문을 퍼블리시할수있는 이 패턴을 말이다.

앞으로는?

그렇다면 정말 현실에 적용할 수 있는 개선이란 무엇일까?

실제 개선은 covid19 예측 모형을 현실과 실제 제품에 적용하기 위해 연구하는 것을 의미할 것이다.
실제 개선은 관련 분야의 전문가와 함께 연구하는 것을 의미할 것이다.
실제 개선은 어려운 문제에 도전하는 것을 의미할 것이다.

머신러닝에서 실제 개선이 위와 같이 변한다면 당신의 논문이 퍼플리시되기까지 더 힘들고 고난의 시간을 겪을 것이다. 이는 “벤치마크 모형 이기기”에 초점이 맞춰져 있지 않다. 관련 분야의 학자들과 함께 연구하는 것은 머신러닝 연구가 좀 더 활발하게 유지될 수 있음을 의미한다.

데이터 성성 과정과 워크 플로는 “벤치마크 고립 현상”을 피하기 위한 방법이다. 워크플로를 고려하면 우리는 병목에 집중하게 된다. 연구 과제의 병목은 정확도를 0.72% 높이는 것이 아니라 더욱 퀄리티 높은 데이터를 수집하고 예측 모형을 워크플로우에 적용하는 것. 머신러닝 학자들은 좀 더 시스템적 사고를 할 필요가 있다.

[Infra] 도커(docker)(9) 도커 PostgreSQL 컨테이너 배포하기

Sat, 01 Oct 2022 00:00:00 +0900

도커(docker)(9) 도커 PostgreSQL 컨테이너 배포하기

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

1. 서론

이번 포스팅에서는 도커를 이용해 PostgreSQL 이미지를 pull 받아 컨테이너로 띄워보겠습니다.

2. 이미지 받아서 컨테이너로 띄우기

2.1. 도커 허브에서 이미지 pull 받기

먼저 다음 코드와 같이 PostgreSQL 이미지를 도커 허브에서 pull받아보겠습니다.

$ docker pull postgres

Using default tag: latest
latest: Pulling from library/postgres
31b3f1ad4ce1: Already exists
dc97844d0cd5: Pull complete
9ad9b1166fde: Pull complete
286c4682b24d: Pull complete
1d3679a4a1a1: Pull complete
5f2e6cdc8503: Pull complete
0f7dc70f54e8: Pull complete
a090c7442692: Pull complete
81bfe40fd0f6: Pull complete
8ac8c22bbb38: Pull complete
96e51d1d3c6e: Pull complete
667bd4154fa2: Pull complete
87267fb600a9: Pull complete
Digest: sha256:b0ee049a2e347f5ec8c64ad225c7edbc88510a9e34450f23c4079a489ce16268
Status: Downloaded newer image for postgres:latest
docker.io/library/postgres:latest

위와 같이 도커 허브에서 pull을 받고 도커 이미지를 살펴보겠습니다.

$ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED         SIZE
postgres             latest    75993dd36176   2 weeks ago     376MB

이미지를 확인하면 PostgreSQL 이미지가 잘 받아진 것을 알 수 있습니다.

2.2. postgre 컨테이너 실행

앞서 pull 받은 이미지를 run 명령어를 통해 컨테이너를 실행해보겠습니다.

$ docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
088f20012019a3be9b47eac2ea11f3811691f33a8100c2dadee0321364e2d7af

위 커맨드를 입력하면 컨테이너를 실행할 수 있습니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED         STATUS         PORTS      NAMES
088f20012019   postgres   "docker-entrypoint.s…"   2 minutes ago   Up 2 minutes   5432/tcp   some-postgres

작동 중인 컨테이너를 확인하면 제대로 떠있는 것을 볼 수 있습니다.

2.3. 컨테이너 내부 탐험

이번에는 작동중인 PostgreSQL 컨테이너 내부를 탐험해보겠습니다.

~$ docker exec -it 088f20012019 /bin/bash

root@088f20012019:/# psql -U postgres

psql (14.5 (Debian 14.5-1.pgdg110+1))
Type "help" for help.

postgres=# CREATE USER cheolwon PASSWORD '1234' SUPERUSER;
CREATE ROLE

postgres=# CREATE DATABASE test01 OWNER cheolwon;
CREATE DATABASE

postgres=# \c test01 cheolwon
You are now connected to database "test01" as user "cheolwon".

test01=# CREATE TABLE test_table(
    id INTEGER PRIMARY KEY,
    name VARCHAR(20)
);
CREATE TABLE

test01=# \dt
           List of relations
 Schema |    Name    | Type  |  Owner
--------+------------+-------+----------
 public | test_table | table | cheolwon
(1 row)

test01=# SELECT * FROM test_table;
 id | name
----+------
(0 rows)

test01=# INSERT INTO test_table (id, name)
VALUES(
    '1',
    'youngjin'
);
INSERT 0 1

test01=# SELECT * FROM test_table;
 id |   name
----+----------
  1 | youngjin
(1 row)

test01=# \q

위 코드가 조금 길기 때문에 잘라서 보겠습니다.

~$ docker exec -it 088f20012019 /bin/bash

root@088f20012019:/#

위 명령어를 이용하면 해당 컨테이너 ID의 내부로 들어갈 수 있습니다.

root@088f20012019:/# psql -U postgres

psql (14.5 (Debian 14.5-1.pgdg110+1))
Type "help" for help.

postgres=#

위 명령어는 postgres 롤로 psql을 실행하겠다는 의미입니다.

postgres=# CREATE USER cheolwon PASSWORD '1234' SUPERUSER;
CREATE ROLE

postgres=# CREATE DATABASE test01 OWNER cheolwon;
CREATE DATABASE

다음으로 위와 같이 새로운 롤(USER)와 데이터베이스를 생성합니다.

postgres=# \c test01 cheolwon
You are now connected to database "test01" as user "cheolwon".

test01=#

위 코드는 cheolwon 유저로 test01 데이터베이스에 접속하겠다는 의미입니다.

test01=# CREATE TABLE test_table(
    id INTEGER PRIMARY KEY,
    name VARCHAR(20)
);
CREATE TABLE

test01=# \dt
           List of relations
 Schema |    Name    | Type  |  Owner
--------+------------+-------+----------
 public | test_table | table | cheolwon
(1 row)

test01=# SELECT * FROM test_table;
 id | name
----+------
(0 rows)

위 코드는 test01 데이터베이스에 test_table이라는 테이블을 생성하는 코드입니다.

test01=# INSERT INTO test_table (id, name)
VALUES(
    '1',
    'youngjin'
);
INSERT 0 1

test01=# SELECT * FROM test_table;
 id |   name
----+----------
  1 | youngjin
(1 row)

test01=# \q

위 코드는 test_table이라는 테이블에 데이터를 추가시키는 코드입니다.

2.4. 컨테이너를 정지하면 데이터가 살아있을까?

도커 컨테이너를 이용해 DB를 띄우는 경우 컨테이너를 정지하면 데이터가 살아 있을까요? 이번에는 컨테이너를 종료해도 데이터가 살아있는지 확인해보겠습니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED        STATUS        PORTS      NAMES
088f20012019   postgres   "docker-entrypoint.s…"   45 hours ago   Up 45 hours   5432/tcp   some-postgres

먼저 위 코드와 같이 작동 중인 컨테이너를 조회합니다.

$ docker container stop 088f20012019
088f20012019

그리고 해당 컨테이너를 정지(stop)시킵니다. 중요한건 컨테이너를 삭제(rm)하는게 아니라 정지만 시키는 것입니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED        STATUS        PORTS      NAMES

컨테이너를 정지시켰으므로 작동중인 컨테이너는 조회되지 않습니다.

$ docker container ls -a
CONTAINER ID   IMAGE           COMMAND                  CREATED        STATUS                     PORTS     NAMES
088f20012019   postgres        "docker-entrypoint.s…"   45 hours ago   Exited (0) 7 seconds ago             some-postgres

정지된 컨테이너를 포함해서 전체 컨테이너를 검색하면 나옵니다.

$ docker start 088f20012019
088f20012019

start 명령어를 통해 정지한 컨테이너를 재가동 하겠습니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED        STATUS         PORTS      NAMES
088f20012019   postgres   "docker-entrypoint.s…"   45 hours ago   Up 5 seconds   5432/tcp   some-postgres

컨테이너가 잘 돌아가는 것을 알 수 있습니다.

$ docker exec -it 088f20012019 /bin/bash
root@088f20012019:/# psql -U postgres
psql (14.5 (Debian 14.5-1.pgdg110+1))
Type "help" for help.

postgres=# \c test01 cheolwon
You are now connected to database "test01" as user "cheolwon".
test01=# \dt
           List of relations
 Schema |    Name    | Type  |  Owner
--------+------------+-------+----------
 public | test_table | table | cheolwon
(1 row)

test01=# SELECT * FROM test_table;
 id |   name
----+----------
  1 | youngjin
(1 row)

test01=# \q

컨테이너 내부에 들어가서 데이터를 확인해보면 데이터가 살아있는 것을 알 수 있습니다.

이처럼 컨테이너를 정지(stop)시켰다가 재가동해도 데이터는 살아있다는 것을 알 수 있습니다. 이때 주의해야할 점은 컨테이너를 삭제(rm)시킨다면 데이터가 같이 사라집니다. 그렇다면 좀더 안전하게 데이터를 보관할 수는 없을까요?

2.5. 도커 마운트(mount) - 호스트 경로와 컨테이너 연결

이번에는 도커 마운트 개념에 대해 알아보겠습니다. 도커 마운트는 호스트 상의 경로와 컨테이너를 연결하는 개념입니다. 먼저 이미지를 검색하면 다음과 같습니다.

~$ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED         SIZE
postgres             latest    75993dd36176   2 weeks ago     376MB

호스트 경로를 확인하면 다음과 같습니다.

:~/work/test$ ll
total 12
drwxrwxr-x 2 kodkod kodkod 4096 Sep 25 05:10 ./
drwxrwxr-x 4 kodkod kodkod 4096 Sep 30 04:26 ../
-rw-rw-r-- 1 kodkod kodkod   22 Sep 23 05:19 while_loop.py

위와 같이 ~/work/test 경로를 컨테이너로 연결해보겠습니다.

-v {호스트경로}:{컨테이너경로}:{권한-rw:읽고쓰기}
$ docker run -e POSTGRES_PASSWORD=mysecretpassword -v ~/work/test:/work/test:rw -d postgres
1067212afd531515c2ddd9ed3ed12256fd41ea586f7ab3b3cd9f6830ad4021d4

위 명령어와 같이 v옵션으로 호스트상의 경로와 컨테이너 상 경로를 연결할 수 있습니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED         STATUS         PORTS      NAMES
1067212afd53   postgres   "docker-entrypoint.s…"   4 seconds ago   Up 3 seconds   5432/tcp   elastic_neumann

작동중인 컨테이너를 확인하면 위와 같이 잘 작동 되는 것을 알 수 있습니다.

$ docker exec -it 1067212afd53 /bin/bash

root@1067212afd53:/# ls
bin  boot  dev  docker-entrypoint-initdb.d  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  work

root@1067212afd53:/# cd work/
root@1067212afd53:/work# ls
test
root@1067212afd53:/work# cd test/
root@1067212afd53:/work/test# ls
while_loop.py


root@1067212afd53:/work/test# mkdir inside
root@1067212afd53:/work/test# ls
inside  while_loop.py
root@1067212afd53:/work/test# exit
exit
:~/work/test$ ls
inside  while_loop.py

위 코드와 같이 컨테이너 안에서 디렉토리를 생성했는데, 호스트에도 디렉토리가 생성된 것을 알 수 있습니다.

2.6. 도커 볼륨(volume)

이번 절에서는 도커 볼륨을 이용해 데이터를 보존해보겠습니다.

~$ docker volume ls
DRIVER    VOLUME NAME

우선 도커 볼륨을 조회해 보겠습니다. 위 코드를 입력하면 아무것도 안나오는 것을 알 수 있습니다.

$ docker volume create myvolume01
myvolume01

$ docker volume ls
DRIVER    VOLUME NAME
local     myvolume01

위 코드를 입력하면 도커 볼륨을 생성할 수 있습니다.

$ docker volume inspect myvolume01
[
    {
        "CreatedAt": "2022-10-03T05:58:30Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/myvolume01/_data",
        "Name": "myvolume01",
        "Options": {},
        "Scope": "local"
    }
]

inspect 명령어를 이용하면 도커 볼륨의 상세정보를 확인할 수 있습니다.

$ docker run -e POSTGRES_PASSWORD=mysecretpassword -v myvolume01:/var/lib/postgresql/data -d postgres
442f74a72312f42d5fda6f181eb9f8ca098d171bab88b2882b3726c09007ab15

그러면 이제 도커 볼륨을 붙여서 컨테이너를 실행해봅시다. 참고로 컨테이너 경로는 /var/lib/postgresql/data지정해야 하는데, 이는 postgreSQL 데이터가 저장되는 경로입니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED         STATUS         PORTS      NAMES
442f74a72312   postgres   "docker-entrypoint.s…"   5 seconds ago   Up 4 seconds   5432/tcp   wizardly_fermat

그러면 위와 같이 컨테이너가 제대로 실행된 것을 볼 수 있습니다.

$ docker exec -it 442f74a72312 /bin/bash

root@442f74a72312:/# psql -U postgres
psql (14.5 (Debian 14.5-1.pgdg110+1))
Type "help" for help.

postgres=# CREATE USER cheolwon PASSWORD '1234' SUPERUSER;
CREATE ROLE
postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 cheolwon  | Superuser                                                  | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

postgres=# \q
root@442f74a72312:/# exit
exit

그럼 이제 데이터가 유지가 되는지 보겠습니다. 위 코드와 같이 컨테이너 내부로 들어가 cheolwon이라는 role을 추가하겠습니다. 그리고 빠져나온후 컨테이너를 내리고 다른 이미지로 컨테이너를 띄운후, 데이터가 여전히 살아있는지 확인해보겠습니다.

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED              STATUS              PORTS      NAMES
442f74a72312   postgres   "docker-entrypoint.s…"   About a minute ago   Up About a minute   5432/tcp   wizardly_fermat

먼저 컨테이너가 살아있음을 확인하고,

$ docker container stop 442f74a72312
442f74a72312

그리고 컨테이너를 정지시킵니다.

~$ docker run -e POSTGRES_PASSWORD=mysecretpassword -v myvolume01:/var/lib/postgresql/data -d postgres
81ab16812bcb769bb3c6500ab6d1a1284673a8fb1c5f1731153a74ea2e6c0d51

$ docker container ls
CONTAINER ID   IMAGE      COMMAND                  CREATED         STATUS         PORTS      NAMES
81ab16812bcb   postgres   "docker-entrypoint.s…"   3 seconds ago   Up 3 seconds   5432/tcp   zen_golick

그리고나서 다른 컨테이너를 띄웁니다.

~$ docker exec -it 81ab16812bcb /bin/bash

root@81ab16812bcb:/# psql -U postgres
psql (14.5 (Debian 14.5-1.pgdg110+1))
Type "help" for help.

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 cheolwon  | Superuser                                                  | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

postgres=# \q
root@81ab16812bcb:/# exit
exit

그리고나서 컨테이너 내부로 들어간 후, role을 확인해보면 여전히 cheolwon이라는 롤이 유지되는 것을 볼 수 있습니다.

[Infra] 도커(docker)(8) 도커 장고 이미지 컨테이너 살펴보기

Thu, 29 Sep 2022 00:00:00 +0900

도커(docker)(8) 도커 장고 이미지 컨테이너 살펴보기

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

1. 서론

이번 포스팅에서는 도커를 이용해 장고 이미지를 pull 받아 컨테이너로 띄우고, 살펴보는 시간을 갖도록 하겠습니다.

2. 도커 허브에 있는 디폴트 장고 이미지 활용하기

2.1. 장고 이미지 pull 받기

우선 장고 이미지를 pull받겠습니다. 다음과 같이 pull을 받아줍시다.

$ docker pull django
Using default tag: latest
latest: Pulling from library/django
75a822cd7888: Pull complete
e4665cede9d1: Pull complete
202a45aa091c: Pull complete
7799136eb561: Pull complete
7a7f9ca3fd40: Pull complete
412f2d081014: Pull complete
Digest: sha256:5bfd3f442952463f5bc97188b7f43cfcd6c2f631a017ee2a6fca3cb8992501e8
Status: Downloaded newer image for django:latest
docker.io/library/django:latest

그리고 나서 도커 이미지를 검색하면 django가 있는 것을 알 수 있습니다.

$ docker image ls
REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
django        latest    eb40dcf64078   5 years ago     436MB

2.2. 도커 컨테이너 실행

장고 공식 이미지를 pull 받았다면 다음 커맨드를 이용해 컨테이너를 띄웁니다.

$ docker run -d -p 80:8000 django bash -c "pip install django && 
django-admin startproject test01 && 
cd test01 && python manage.py runserver 0.0.0.0:8000"

4d08850e2b8ceac943d0532bcf38b65bf063fc625886dd02e600720c6b326dbe

참고로 위 커맨드의 의미는 다음과 같습니다.

옵션	의미
-d	컨테이너 백그라운드 실행
-p	호스트의 80번 포트와 컨테이너의 8000번 포트 연결
bash -c	다음에 오는 커맨드 실행

그러면 컨테이너가 잘 띄워졌는지 확인해보겠습니다.

$ docker container ls
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                   NAMES
4d08850e2b8c   django    "bash -c 'pip instal…"   5 seconds ago   Up 5 seconds   0.0.0.0:80->8000/tcp, :::80->8000/tcp   peaceful_jackson

컨테이너를 내리고 싶다면 다음과 같이 입력합니다.

$ docker container stop 4d08850e2b8c
4d08850e2b8c

3. 직접 작성한 코드를 빌드해서 배포하기

[PostgreSQL] 윈도우에 PostgreSQL 설치하기

Wed, 28 Sep 2022 00:00:00 +0900

[PostgreSQL] 윈도우에 PostgreSQL 설치하기

참고링크

운영체제	프론트엔드	백엔드	데이터베이스	인프라
리눅스구조	js필터	아파치에러로그	행삭제	아파치스쿱
프로세스	헬로월드	웹서버개념	ES기초	로그분석
네임스페이스	프로젝트생성	아파치설치	MySQL기초	beeline
디렉토리	헤더생성	flask연동	큐브리드	하둡기초
리다이렉션	async-get	장고MsSQL연결	null공백	나이파이
쓰레드	async-post	장고MySQL연결	MySQL설치(win)	백본
라즈베리파이설치	로그인페이지	장고inpectdb	MySQL테이블생성	제플린
OSI7계층소개		장고read		SSL인증
OSI1계층		장고insert		커버로스
OSI2계층		장고put		도커개념
OSI3계층		장고del		도커설치
OSI4계층		flask한글요청		도커기초
OSI5,6,7계층				도커이미지
DNS서버				컨테이너네트워크
DHCP				도커API
bashrc				도커컴포즈
bash				도커볼륨
ifconfig				장고이미지
소켓프로그래밍				도커postgre
리눅스유저생성				도커이미지삭제
netstat포트열기				도커Redis
컴파일러				k8s구조
운영체제vs커널				k8s설치
작업스케쥴링				k8s서비스배포
디스크추가				POD네트워크
aws유저추가				퍼시스턴트볼륨
기초명령어				k8s에러
포트번호

참고 링크

DB

백엔드

프론트엔드

1. PostgreSQL 설치하기(2022.09.28 수정)

본 예제는 윈도우11 환경에서 실행했습니다.

먼저 다음 url에 접근합니다.

https://www.postgresql.org/download/

위와 같은 화면에서 windows를 클릭합니다.

그리고 위 화면에서 download the installer를 클릭합니다.

그러면 위와 같은 다운로드 화면이 나타나는데 윈도우 쪽을 클릭해서 다운로드 해줍니다. 다운로드 용량은 313MB 정도 되는데 네트워크 환경에 따라 시간이 걸릴 수 있습니다. 다운로드를 완료하면 해당 파일을 실행해 줍니다.

그러면 위와 같은 설치 마법사가 실행되는데 next를 눌러줍시다.

위와 같은 설치 경로가 나타나면 건드리지 말고 next를 눌러줍시다.

그러면 postgreSQL 구성 요소 중 무엇을 설치할지 선택하라고 뜨는데, 여기서는 자신이 원하는 것을 선택합시다. 저는 변경없이 모두 설치하겠습니다.

그리고 PostgreSQL의 데이터를 저장할 디렉토리를 선택하라고 뜨는데 건들지 말고 그냥 next 눌러줍시다.

그러면 위와 같이 postgres 계정의 비밀번호를 설정하라고 뜨는데, 자신이 원하는 비밀번호를 입력합시다. 저는 귀찮아서 그냥 1234라고 설정했습니다.

다음은 포트 설정 화면입니다. PostgreSQL의 기본포트는 5432 포트입니다. 가급적 변경하지 말고 next 눌러줍니다.

다음은 locale을 설정하는 화면인데 저는 변경하지 않고 next를 눌러주겠습니다.

설치 준비가 모두 끝났습니다. 설치해줍니다.

next를 눌러줍니다.

그러면 설치가 시작 됩니다.

설치가 완료되면 위와 같은 화면이 뜹니다. Finish를 눌러 설치를 마치겠습니다.

설치를 마쳤으면 시작을 누르고 sql shell(psql)을 실행하고 위와 같이 셋팅을 해줍니다. 기본적으로 아무것도 입력하지 않고 엔터를 누르면 기본값이 설정되며, 마지막으로 비밀번호를 설정해줍니다.

그후 시작을 누르고 pgadmin4를 실행하면 위와 같이 비밀번호를 설정하라고 뜨는데, 자신이 원하는 비밀번호를 입력합니다. 저는 또 1234로 설정하겠습니다.

그리고나서 위와 같이 데이터베이스를 연결해줍니다. Name은 자기가 원하는 이름으로 설정해줍니다.

그리고 나머지 정보들도 입력해줍니다.

그러면 위와 같이 연결되는 것을 알 수 있습니다.