10/06일

오늘도 어제에 이어서 gitlab에서 project의 CI/CD pipeline를 설정하는데 시간을 들였다.
어제 하루동안 잘만 돌아가던 gitlab runner가 영문을 알수없게 갑작스럽게 터진데다가 몸상태가 좋지않아서
bulid까지만 성공시키고 unittest는 성공하지 못하고 중간에 기절해서 자버렸다.
dind 방식에서 unittest를 어떻게 사용해야할까 고민해 보았는데

1

docker run --entrypoint

명령어를 이용하여 내부에 있는 unittest용 파일을 python을 통하여 활성화시켜주는 방향으로 할 생각이다.
오늘은 docker 관하여 공부했었는데 아직 글을쓰기까지 조금 시간이 걸릴것 같다.

10/05일

KDT에서 만든 프로젝트를 Gitlab runners 를 이용하여 pipeline을 구축하는 연습을 하였다.
모듈별로 각자 runner를 이용하여 pipeline을 구축하여 unittest를 해서 제대로 돌아가는지를 판단한 뒤
추후에 runner를 하나로 묶어서 프로젝트를 배포할 예정이다.
+강화학습 Policy Gradient에 대하여 정리중

오늘 발생했던 문제

docker in docker 를 사용하는데 자꾸 host를 못잡는 현상이 벌어짐

원인

Docker의 Container는 기본적으로 Host에서부터 독립된 namespace를 가지고 있어서 Host시스템에 주요자원에 접근할 수 없음
우리는 Docker in Docker구조로 생성하였기 때문에 내부의 컨테이너가 아무리 애를 써도 docker host에 접근 할 수 있는 권한이 없다.

해결방법

docker 의 privileged 옵션을 활성화 시켜서 host의 자원에 접근할수 있도록 해준다

추가로 찾아볼 것

dind(docker in docker)

10/14일

오늘은 GAIL(Generative Adversarial Imitation Learning) 논문을 읽기 시작했다.
이 논문을 읽기전에 여러 기초 지식들이 필요하다는것을 뼈저리게 느꼈지만 일단 헤딩하는 느낌으로 논문을 읽어나가면서 부족한 지식을 채워나가는 방식으로 글을 작성하려한다.
지금까지 이해한 부분 간단하게 3줄 요약

• GAIL은 imitation learning의 방법중 하나로써 기존의 Inverse Reinforce Learning(역강화학습 : 전문가의 행동데이터를 기반으로 Reward function을 복원하여 최적의 Policy를 얻어내는 학습)의 단점인 전문가의 행동데이터에서 간접적으로 학습을 하기때문에 소요시간이 크다는 점을 해결한 논문이다.
• imitation learning과 GAN의 유사점에서 착안하여 데이터로부터 직접적으로 Policy를 학습함
• GAN과 비슷하게 Discriminator와 Generator(논문상에서는 TRPO)가 존재한다.
• Generator는 점점 더 샘플링된 전문가의 행동처럼 움직임을 결정하게 학습을 한다.
• 다른 역강화학습에 비해 상대적으로 적은양의 샘플로도 좋은 성능을 내었음

아직 수직적으로는 이해하지 못한부분이 많아서 여러번 정독을 해야할것 같다. 그리고 역강화학습 자체도 내가 대략적으로 개념정도만 공부한 상황이라 논문을 이해했다고 이야기 하기 위해서는 더 조사할 필요성을 느낀다.
관련된 지식에 대하여 포스트를 작성할 계획이다.

Paper

https://arxiv.org/abs/1606.03476

+정리한 CS 지식

10/03

백신을 맞은 다음에 아직 컨디션이 완전히 돌아오지는 않아서 오늘은 간단하게 강화학습 책을 다시 한 번 읽었다. 아직 정리할 정도로 이해한것 같지는 않다. PRML책도 같이 읽어서 복습해야 할 것 같다.

+정리한것

Multi Process(멀티 프로세스)

멀티 프로세스란?

• 다수의 프로세스로 하나의 Task를 처리하는것
• 프로세스간 메모리 구분이나 독립된 공간이 필요할때 사용

  특징

• 독립된 구조로 다른프로세스에게 서로 영향을 주지않아서 문제가 발생해도 해당 프로세스 이외에는 영향이 없다. -> 안정적이다.

  단점

• 서로 독립된 영역에서 작업을 진행하기 때문에 작업량이 많아질수록 Context Switching에 의한 오버헤드가 발생하여 성능의 저하가 일어날 수 있다
• 서로 독립되어있기 때문에 통신을 위해 별도의 통신설비를 이용해야함(IPC, Inter Process Communication)
• 프로세스간 변수등의 자료 교환을 할 수 없다.

Multi Thread(멀티 스레드)

멀티 스레드란?

• 하나의 프로세스에 여러개의 스레드로 자원을 공유하여 다수의 작업을 동시에 처리하는것

  특징

• 프로세스 안에서 공유 메모리를 가지고 있기때문에 시간, 자원의 손실이 프로세스대비 적다
• 스레드간 자료, 변수의 공유가 가능하다.

  단점

• 공유메모리를 가지기 때문에 공유메모리의 공간의 손상이 발생하면 다른 스레드또한 작업이 불가능한 상태가 되어버린다.
• 위의 문제를 가지기 때문에 주의깊은 설계가 필요하다. -> Critical Section
  
  
  # Context Switching
• 하나의 프로세스나 쓰레드가 CPU를 사용중인 상태에서 다른 프로세스나 쓰레드가 CPU를 사용하기위해 현재 프로세스의 상태정보를 저장하고 다른 프로세스의 상태값을 불러오는 과정 -> PCB에 저장
• 상태값을 저장하고 불러오는 동안에는 작업을 수행할 수 없다 -> 오버헤드

프로세스와 스레드

Process(프로세스)

프로세스란?

• 컴퓨터에서 연속적으로 실행되는 컴퓨터 프로그램
• 프로그램을 구동하여 메모리상에서 실행되는 작업단위
• OS로 부터 독립된 메모리 영역을 할당받는다.

프로세스의 구조

프로세스는 아래와 같은 구조를 가진다.

• Code : 코드 자체를 구성하는 메모리 영역
• Data : 전역변수, 정적변수, 배열등을 저장
• Heap : 동적 할당시 사용(new(), malloc() 등)
• Stack : 지역변수, 매개변수, 리턴값 등을 임시적으로 저장하는 영역

왜 이렇게 나눈걸까?

1
2

공유 할 수 있는 데이터는 공유하여 메모리의 사용량을 줄이기 위해서
Stack과 Data를 나눈 이유는 스택의 특성과 전역변수를 활용하기 위해서

Process Control Block(PCB, 프로세스 제어 블록)

특정 프로세스에 대한 정보(Process MetaData)를 저장하고 있는 자료구조(Linked List)
아래와 같은 데이터가 저장되어 있다.

• Process MetaData
  • Process ID : 프로세스의 식별번호
  • Process State : 프로세스의 상태(new, ready, running, waiting, terminated)
  • Program Counter : 이 프로세스 다음에 실행할 명령어의 주소
  • CPU Registers
  • CPU 스케줄링 정보: 우선 순위, 최종 실행시각, CPU 점유시간 등
  • 메모리 관리 정보: 해당 프로세스의 주소 공간 등
  • 프로세스 계정 정보: 페이지 테이블, 스케줄링 큐 포인터, 소유자, 부모 등
  • 입출력 상태 정보: 프로세스에 할당된 입출력장치 목록, 열린 파일 목록 등

PBC는 CPU에서 프로세스의 상태에 따라 교체작업(Context Switching)이 이루어질때 PBC에서 저장되어있는 내용들을 불러와 이전 종료시점부터 다시 작업을 재실행한다.

Thread(스레드)

Thread란?

• 프로세스 내부에 존재하는 실행 단위
• 하나의 프로세스가 생성될때 내부에 적어도 하나의 스레드가 같이 생성된다.
• 스레드는 Stack만 따로 할당받고, 나머지 Code, Data, Heap은 공유

프로세스와 스레드의 차이

• 프로세스는 고유한 공간과 자원을 할당받아서 사용하지만(프로세스간 공유하지 않음) 스레드는 고유한 메모리(Stack)를 프로세스로 부터 할당받긴 하지만, 서로 공유하는 메모리(Code, Data, Heap)가 존재함

Stack를 스레드마다 독립적으로 할당 받는 이유

• 독립적인 실행 단위로써 스레드를 사용하기 위해서는 독립적인 메모리 공간이 필요하고, 이를 만족시키는 최소조건이 Stack을 제공하는것 이기 때문이다.

10/02

오늘은 팀원들과 함께 모의 코딩테스트를 시행하였다.

푼 문제

• 오큰수 : stack문제
• 탑 : stack 문제 (오큰수 반대)
• 강의실 배정 : Heap, 그리디
• 쇼핑몰 : Heap
• 부분합 : Two pointer

추후에 정리해서 깃허브에 업로드할 예정이다.

강화학습에 대해서 공부를 다시 시작하였다. 가치기반 학습에 대해서는 예전에 많이 공부를 해두어서 복습하는 느낌으로 공부를 하였고, 이번에는 저번에 공부할때 조금 부족했던 정책기반학습을 위한 Policy Gradient를 이해하기 위해 중점적으로 할 예정이다.

추후에 포스팅을 할 예정이다.

백신을 맞고 2일정도 누워있어서 오랜만에 CS - OS 에 관하여 포스팅을 하였다.

9/29일

오늘은 백준 알고리즘 문제 2개정도 풀고 예전에 KDT에서 한번 해보고싶었는데 시간 난이도 등의 문제로 포기한 multi labeling 관련 논문들을 검색해 보았다. 조만간 시간을 내서 읽어보고 한번 포스팅을 할 예정이다.

그리고 음(mm)에서 이벤트로 카카오 Brain 대표 Curtis [Unthinkable Question] 나는 왜 ai개발자로 전향했을까를 들었다. Curtis에 관한 여러가지 개인적인 이야기도 있었고, Brain에서 어떤 일을 하는가, 질문시간을 통한 ai의 방향, 학부생의 공부 방향 등등의 이야기가 있었는데, 무엇보다 기억에 남았던것은 자기자신을 특별하게 만들기 위해서 해야할 일이었다.

남들이 만들어놓은 길에서 조금만 벗어나도 유니크해진다.

+ The Hacker way

이 말을 듣고 나의 경쟁력은 무엇이 될 수 있을까에 대해 시간을 내서 한번 고민을 해봐야겠다고 다짐했다. 또 그동안 하면 좋겠다 라고 생각해놓고 아직 내 실력이 부족한거같으니까 좀더 공부하고 하자 라고생각했던 기술관련 공부등을 다시 시작해야겠다.

• Multi Agent RL
• Multi label Classfication
• GAN 과 RL의 결합

인공지능에 대해서 본격적으로 공부하기로 마음먹은지 1년이 조금 넘은 시간이 흘렀는데 하면 할수록 인공지능이라는 탑이 너무나도 높아보이고, 탑을 올려보는동안에도 조금씩 높아지는것이 눈에 보여서 한동안 슬럼프에 빠졌었던 때도 있었다. 내가 잘하고있는걸까 생각도 많이했었고, 거의 혼자서만 공부를 해오다보니 내 실력은 어느정도일까 의구심도 많이 들었다. 오늘 이 라디오(?)를 들으면서 걱정은 줄고 고민할 거리가 많이 늘어난 느낌이다.

9/28일

오늘은 어제의 연속으로 bitbuckit runners와 pipeline을 다루었다.
아직 다룬지 얼마 안된것과 도커에 대해 자세히 모르기 때문에 runner를 실행시킬때마다 빌드실패의 늪에 빠지게 되었다. SSH private key를 도커컨테이너 내부로 전달을 했어야 했는데 미숙하여 환경값으로 저장까지는 했으나 제대로 보내지 못하였고, 여러 커뮤티니에 비슷한것들을 찾아 다니던 끝에 ssh private key는 넘겨 줄 수 있었지만, 이제는 컨테이너끼리 메세지큐를 보내는곳에서 에러가 발생했다.

해결한 문제

1
2
3
4
5
6
7
8
9
10

pipelines:
  branches:
    name:
      -step:
        script:
            - docker build --tag tag:1.5 --build-arg ssh_prv_key="$(echo $SSH_PRV_KEY | base64 --decode)" .
        services:
            - docker
            - redis
            - rabbitmq

1
2
3
4
5
6
7

FROM pytorch/pytorch:1.7.0-cuda11.0-cudnn8-runtime
ARG ssh_prv_key # 여길 빼먹음

RUN mkdir -p -m 0600 /root/.ssh \
   && ssh-keyscan bitbucket.org >> /root/.ssh/known_hosts \
   && echo "$ssh_prv_key" > /root/.ssh/id_ed25519 \
   && chmod 0600 /root/.ssh/id_ed25519

도커파일을 빌드하는 과정에서 argument 를 받아오긴 했는데 도커파일 안에서 선언은 하지 않아서 계속 에러가 발생했다.

ARG and ENV의 차이

ARG와 ENV의 가장 큰 차이점은 빌드를 하고난 다음에도 사용이 가능한가? 의 차이이다. ARG는 빌드시에만 쓰이는 argument이며 ENV는 빌드가 끝나고도 사용 가능한 환경변수라고 생각할 수 있다. Dockerfile이 아닌 명령어로 빌드를 할때는 arg만 가능하고, run을 할때는 env의 선언만 가능하다.

• ARG
  • Dockerfile에서만 사용되는 변수 선언
  • docker build 시에 –build-arg 옵션을 활용하여 오버라이딩 할 수 있다.
• ENV
  • Dockerfile뿐만 아니라 컨테이너 내에서 사용가능한 변수 선언
  • docker run 시에 –e 옵션을 활용하여 오버라이딩 할 수 있다.

Hash Table

1. Hash Table이란

해시 테이블은 (Key,value)를 기반으로 데이터를 저장하는 자료구조중 하나이다.
해시테이블은 아래의 그림과 같이 Key값을 Hash 함수를 이용하여 고유한 index값으로 변환하고, 이 index에 해당되는 배열(bucket)의 위치에 저장한다. 이런한 구조로 인해 Key값에 Hash 함수를 수행하기만 하면 value값이 저장되어있는 Index를 얻는것이 가능하기 때문에 탐색에 O(1)의 시간복잡도가 소요된다.

2. Hash Functions

Hash 함수는 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다.
Hash Table에서는 Hash 함수를 이용하여 Key에서 부터 고유한 index를 얻는다. 아래에는 간단한 Hash 함수들을 나열해 보았다.

• Division Method : 가장 간단한 Hash함수중 하나로 Key값을 Bucket의 사이즈로 나누어서 계산한다.
• Digit Folding : Key의 문자를 ASCII 코드로 바꿔 합한 데이터를 테이블 주소로 사용한다.
• Multiplication Method :

3. Hash Collapse

Hash 함수에 서로 다른 입력값을 넣었지만 같은 출력값이 나올경우 발생할 수 있는 상황을 말한다. 이러한 상황이 발생할때 해결방법으로 아래와같은 충돌 처리기법이 존재한다.

3.1 충돌 처리 기법

• Open Hashging : 주소 밖의 메모리에 저장
  • Chaining : 충돌이 발생하면 해당 주소에 linked list 이용해서 연결해 저장하는 방법
    • 데이터를 찾을시에 순차탐색을 해야하는 단점이 생김
• Close hashing(Open Addressing) : 테이블 내의 새로운 주소를 탐색하여 데이터를 입력하는 방식
  • Linear probing : 충돌이 발생할때마다 고정값만큼 이동한 주소에 저장하는 방법
  • Quadratic probing : 충돌이 발생한 만큼의 제곱값을 폭으로 주소에 저장하는 방법
  • Double hashing : 해시된 값을 한번더 해싱하여 새로운 주소를 할당하는 방법

reference

http://www.laurentluce.com/posts/python-dictionary-implementation/