발표 전달력이 매우 좋지 않았음. 그에 따른 자기 피드백

• 한 챕터만 자세히 하기(3챕터를 너무 얕게 설명함)
• 코드를 주로 설명하기 (도식보다 예제 코드가 더 이해시키기 쉬움)
• 파이썬 내용을 빼야겠다. 너무 아는게 다름. (소공 관점의 얘기만 담기.)

출처: 랜각코 스터디 – 책 “읽기 좋은 코드가 좋은 코드다” 1장 일부

코드는 이해하기 쉬워야 한다

가독성의 기본 정리: 이해하는데 들이는 시간을 최소화. 이해한다는 건 디버깅과 수정이 가능한 수준을 말함.

표면적 수준에서의 개선

이름에 정보 담기

• 특정한 단어 고르기: thread.stop() 보다는 완전 종료면 kill, 일시 정지면 pause가 맞음. 더 구체적인 의미를 담아라.
• 보편적인 이름 피하기: tmp, result, foo 같은 이름은 책임 회피. 예외도 있지만 최대한 자제하자.
• 추상적인 이름 대신 구체적인 이름을 사용하기:
  DISALLOW_EVIL_CONSTRUCTORS -> DISALLOW_COPY_AND_ASSIGN
• 접두사 혹은 접미사로 이름에 추가적인 정보 덧붙이기
• 이름이 얼마나 길어져도 괜찮은지 결정하기
• 좁은 범위에서만 사용한다면 짧은 이름도 괜찮다
• 긴 이름 입력은 IDE의 발전 덕분에 더 이상 귀찮지 않다.
• 약어와 축약형: 저자 생각은 일반적으로 받아들여지는 약어는 괜찮다.
• 불필요한 단어 제거하기
• 추가적인 정보를 담을 수 있게 이름 구성하기: 언더바, 하이픈, 대문자는 좋은 도구들. ex) 구글 C++ 컨벤션의 멤버 변수
• 오해할 수 없는 이름
• 경계를 포함하는 한계값: min/max, first/last, begin/end
• boolean 변수 이름 붙이기
• 사용자의 기대에 부응하기: getXXX는 값을 가져오는 가벼운 메서드로 보이기 때문에 연산이 필요하면 이름을 바꾸는게 좋음.

미학

시각적으로 좋은 코드가 읽기도 좋다.

• 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기
• 줄 바꿈이 어렵다면 메소드를 활용하라
• 도움이 된다면 코드의 열을 맞춰라: 오타를 찾기 쉬워짐. 하지만 굳이 강제하진 않음. 불편하면 포기해도 됨.
• 의미 있는 순서를 정해서 일관성 있게 사용하라: ex) 매개변수들의 순서를 정해서 계속 같은 순서대로 초기화하고 참조하고 수정해야 함.
• 선언문을 블록으로 구성하라: 관련된 부분들끼리 묶어두기
• 코드를 문단으로 쪼개라: 논리 전개에 맞춰서 나누자.
• 미학은 개인적인 스타일이지만 팀이라면 일관성을 지켜야 한다.

정리되지 않음.

이전 발표 수정: VM VS Containers

VM: 하이퍼바이저 위에서 게스트 OS 실행

Containers: 호스트 OS의 커널에서 실행하는 가상 프로세스

이번 주제: 그래서 뭔 기술을 써서 이렇게 주어진 컴퓨터 자원을 가상으로 쪼개고 그룹화 하고 할 수 있는가?

Docker란 무엇인가

컨테이너를 쉽게 배보할 수 있는 프로그램

컨테이너: 호스트 커널을 공유하고 프로세스의 실행영역을 격리

namespace: 프로세스 실행 환경 격리

Cgroups: 리소스 분할 사용

클라우드 환경을 제공하기 위해 컨테이너의 필수 조건

1. fake root path 제공 – host와 달리 container가 독립된 fake root 가 필요하다
2. Isolation – 호스트의 파일시스템, 프로세스 트리, 네트워크 등이 분리되어야 한다.
3. root 권한 사용 – 리눅스 루트 권한 사용 가능 여부와 그에 따른 보안 문제 관리
4. HW 리소스 제한, CPU, 메모리, I/O, 네트워크 등 호스트의 자원에서 할당된 양만큼만 사용해야 함.

chroot

루트 디렉토리를 바꾸는 명령어

원격 유저에게 특정 루트 디렉토리로 격리하기 위해 사용함. 컨테이너의 시작.

chroot 실습

단순히 새 디렉토리에 chroot를 실행하면 안됨.

오류 메세지를 보면 bash가 없어서 그럼. -> 그래서 새 루트로 bash를 옮겨줘야 함. bin도 옮기고 lib도 옮겨줘야 함.

그러면 bash로 새 루트로 접속이 됨.

하지만 ls같은 기본 명령어도 안됨. -> 역시 새 루트에선 ls를 실행할 수 없기 때문에 bash처럼 bin을 옮겨줘야 함.

chroot 후에 새 루트로 들어간 후에는 아무리 새 루트 위에 상위 디렉토리가 있다 해도 올라갈 수 없음.

chroot가 너무 귀찮아

-> 새 루트를 위한 파일들을 미리 묶어두고 복붙하면 될 것 같아
-> 그래서 tarball로 압축해둔게 image

그래서 docker의 이미지를 tar로 압축 해제하면 chroot가 가능한 디렉토리가 세팅되어 있음.

chroot의 치명적인 문제점

1. fake root path 제공 가능하지만 탈옥이 됨.
2. isolation 되지 않음. 호스트 파일시스템에 직접 접근 가능
3. 루트 권한 사용 불가
4. resource 무제한

대안점: pivot_root

루트 파일시스템을 변경함.

-> 원래 chroot는 pid 1의 정보를 상속받기 때문에 파일 시스템에 남은 상위 디렉토리로 이동 가능(탈옥)
-> pivot_root는 프로세스가 보고 있는 파일 시스템을 바꿔서 탈옥이 불가능함.

이러면 fake root path에 대한 문제가 완전히 해결됨. 이제 격리와 리소스 관련 문제를 해결해야 함.

Namespace

네임스페이스는 프로세스에 격리된 환경과 리소스를 제공함. 7개가 있음.

time, syslog는 아직 전부 구현되지 않아서 docker같은 컨테이너 구현체마다 다르게 구현되어 있음.

CGroup

프로세스에 할당하는 리소스를 제어하는 파일시스템

그룹별로 여러 장치들을 묶어서 각각 어떻게 자원을 사용할 지 파일로 기록해둠. 그리고 이 그룹에 프로세스를 바인딩함.

실습: stress 명령어로 CGroup 테스트하기

정리

컨테이너는 프로세스다.

1. tarball에 의해 탄생하고
2. namespace에 고정되어 있으며
3. cgroup에 의해 제어되고 있다.

그래서 왜 VM보다 컨테이너가 용량이 적음?

이미지 최적화 문제

ubuntu + nginx + mysql + …

ubuntu + nginx + tomcat + …

이러면 중복된 이미지가 많아져서 공간 문제가 발생하는거 아닌가?

union filesystem

복수의 filesystem을 하나로 마운트하는 기능

두 파일시스템에 동일한 파일이 있는 경우, 나중에 마운트되는 파일시스템의 파일을 오버레이함.

하위 파일시스템에 대한 쓰기 작업 진행시 Copy on Write. 복사본을 생성하여 수행

일명 상속 파일시스템이라고 불림.

현재는 OverlayFS2를 사용.

이미지 -> 병합된 이미지 -> 컨테이너 내의 수정본 으로 계층으로 쌓여있음.

Docker에선 layer DB에서 관리함.

그래서 VM은 위에서처럼 약간의 변화가 있는 각각의 가상머신을 구분해서 저장하기 때문에 차지하는 공간이 크지만, 컨테이너는 중복된 부분을 union filesystem으로 관리하기 때문에 공간을 작게 차지한다.

0장에서 1장까지의 내용 요약

TCP keep alive

https://en.wikipedia.org/wiki/Keepalive

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Keep-Alive

Keepalive는 두 장치간의 연결이 계속 유지되고 있는지 주기적으로 확인하기 위해 보내는 메세지를 말한다. keepalive를 보낸 후에 응답이 돌아오지 않는다면, 링크가 끊어졌다고 추정한다. 따라서 keepalive는 연결 확인 말곤 역할이 없기 때문에 최소한의 크기를 가져서 네트워크 대역폭을 많이 차지하지 않게 해야한다.

TCP에선 기본적으로 꺼져있고, 선택적으로 켤 수 있다. keepalive는 세 가지 매개변수를 설정할 수 있다.

1. keepalive time: 유휴 상태일 때, keepalive를 보내는 시간 간격을 정한다.
2. keepalive interval: keepalive 응답이 없을 시 다시 보내는 간격을 정한다.
3. keepalive retry: 연결이 끊겼다고 확정하기 전까지 재시도하는 횟수를 정한다.

HTTP keepalive

위의 개념과 전혀 관련없다. HTTP에서의 keepalive는 추가 메세지 전달을 위해 연결을 열어둬야 할 때에 사용한다. 두 가지 매개변수를 가진다.

1. max: 이 연결로 보낼 수 있는 최대 요청 메세지 수를 정한다.
2. timeout: 연결 유휴 상태를 유지할 시간 제한을 정한다.
   (TCP timeout 보다 크다면, HTTP가 윗 계층인 이상 당연히 무시됨.)

Multi zone region

Available zone (가용 영역): 하나의 데이터 센터를 말함. 네트워크가 연결되어 있고 장애 대처가 가능한 전력 공급망, 서버 랙, 라우터, 스위치, 하드웨어 방화벽 등등, 온도 제어 등이 갖춰진 물리적 시설

Multi Zone Region: 물리적으론 떨어져 있지만 서로 연결된 가용 영역들의 집단. 이 각각의 가용영역들과 전부 연결된 PoP(Network Point of presence, network hotel)를 통해 외부 사용자들이 Region에 접근한다.

위와 같이 구성하는 이유는 가용성이 높은 클라우드 네이티브 아키텍쳐를 구성하기 위해서다. 여러 가용 영역에 동일한 애플리케이션을 배포해서 가용 영역 중 하나가 장애가 발생하더라도 다른 가용 영역에 접근할 수 있게 구성할 수 있다.

Fork-Join model

https://en.wikipedia.org/wiki/Fork%E2%80%93join_model

https://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

https://www.baeldung.com/java-fork-join

병렬 컴퓨팅에서 작업을 분할정복 방식으로 처리하는 걸 Fork-Join model이라고 한다. 의사코드로 다음과 같다.

solve(problem):
    if problem is small enough:
        solve problem directly (sequential algorithm)
    else:
        for part in subdivide(problem)
            fork subtask to solve(part)
        join all subtasks spawned in previous loop
        return combined results

중요한 건 작업의 크기에 threshold를 두고 그보다 작으면 단일 쓰레드에서 처리하고, 그렇지 않으면 작업을 분할하고 모든 작업 결과를 병합할 수 있을 때까지 기다리면 된다.

work-stealing 알고리즘

https://hamait.tistory.com/612

Fork-Join 모델을 사용하는 Java의 ForkJoinPool은 쓰레드 풀에서 효율적인 작업 분배를 위해서 work-stealing 알고리즘을 사용한다. 각각의 쓰레드는 작업을 대기시키기 위한 deque를 가지고 있고 다음과 같이 동작한다.

1. 작업 중이 아니라면 자신의 작업 deque의 head를 확인한다.
2. 자신의 deque가 비어있다면, 다른 작업 중인 쓰레드의 deque의 tail 에서 가져오거나 전역 queue에서 가져온다.

애초에 쓰레드풀로 들어온 작업들이 전부 균등한 크기라면 ForkJoinPool이 최고의 선택은 아니다. 굳이 작업을 쪼개서 나눠줄 필요도 없고 오버헤드가 되기 때문. 하지만 만약 작업의 크기가 다르다면, 큰 작업을 받은 쓰레드가 자신의 작업을 쪼개서 deque에 넣어두면, 다른 여유가 생긴 쓰레드가 가져갈 수 있기 때문에 효율적인 분배가 가능하다. 그리고 현실에선 균등하지 않은 작업이 들어오는 경우가 많기 때문에 work-stealing 알고리즘이 유효하다.