이 글은 도커 없이 컨테이너 만들기 3편 을 읽고 정리한 글입니다.

1. 네트워크 네임스페이스

리눅스 네임스페이스 중 하나인 네트워크 네임스페이스는 독립적인 네트워크 환경을 구성해 프로세스 간 격리할 수 있는 기술이다.

독립된 네트워크 네임스페이스에서 호스트 디폴트 네임스페이스로 접근할 수 없다. 반대도 마찬가지다. 이를 통해 컨테이너간 네트워크 자원을 분리할 수 있다.
RED 라는 네임스페이스와 BLUE라는 네임스페이스를 생성했다.

네임스페이스들은 모두 /var/run/netns 하위에 생성된다.

ip netns add RED
ip netns add BLUE

2. veth

리눅스의 버추얼 이더넷 인터페이스다. 즉 가상 NIC를 제공해준다. 쌍으로 생성되며 이를 이용해 네트워크 네임스페이스들 간 연결해줄 수 있다.
기본적으로 ip 명령어를 이용해 생성하며 down 상태로 디폴트 네트워크 네임스페이스에 존재하게 된다.

veth0 과 veth1 두개의 쌍을 생성한다.

ip link add veth0 type veth peer name veth1

3. 패킷 전송하기

생성된 두 NIC를 각각 RED, BLUE 네임스페이스에 붙인다.

ip link set veth0 netns RED
ip link set veth1 netns BLUE

두 디바이스를 활성화 해주고 IP 주소를 할당해준다.

ip netns exec RED ip link set veth0 up ; ip netns exec RED ip addr 11.11.11.2/24 dev veth0
ip netns exec BLUE ip link set veth1 up ; ip netns exec BLUE ip addr 11.11.11.3/24 dev veth1

nsenter 커맨드를 이용해 네임스페이스에 진입할 수 있다. RED 네임스페이스에 진입해 아이피 주소 할당을 확인할 수 있다.

nsenter --net=/var/run/netns/RED
ip addr show

루프백 과 veth0에 할당된 아이피를 확인할 수 있다.

두 네임스페이스 모두 초기 상태이기 때문에 ARP Table, Routing Table 모두 비어있음을 알 수 있다.

ip neighbour show
// ARP table 

ip route show
// route table

여기서 RED -> BLUE로 패킷을 보내면 ARP Request 해서 BLUE의 MAC address 찾고 패킷을 전송할 것이다. 확인해 보자.

BLUE Terminal

tcpdump -i veth1

RED Terminal

ping 11.11.11.3

ARP Request -> Response, 그리고 ICMP 로 echo가 왔다갔다 하는것을 볼 수 있다.

4. Bridge

브릿지는 L2 계층 장비로써 Collision Domain을 쪼개줌으로써 충돌을 줄여준다.
리눅스에서는 가상 브릿지를 만드는 것도 제공해준다.

RED(reth0) - HOST(reth1) - HOST(bridge0) - HOST(beth1) - BLUE(beth0) 형식으로 네트워크를 구성해 RED->BLUE로 패킷을 전송해보겠다.

네임스페이스를 생성하고 디바이스 및 브릿지를 생성해준다.

ip netns add RED
ip link add reth0 type veth peer name reth1
ip link set reth0 netns RED

ip netns add BLUE
ip link add beth0 type veth peer name beth1
ip link set beth0 netns BLUE

ip link add bridge0 type bridge
ip link set reth1 master bridge0
ip link set beth1 master bridge0

디바이스들을 모두 turn on 하고 reth0과 beth0에 각각 IP address를 할당해 준다.

ip netns exec RED ip addr add 11.11.11.2/24 dev reth0
ip netns exec BLUE ip addr add 11.11.11.3/24 dev beth0

ip netns exec RED ip link set reth0 up; ip link set reth1 up
ip netns exec BLUE ip link set beth0 up; ip link set beth1 up 
ip link set br0 up

위와 마찬가지로 ICMP ping 을 전송한다.

HOST Terminal

tcpdump -l -i bridge0

BLUE Terminal

tcpdump -l -i beth0

RED Terminal

ping -c 1 11.11.11.3

ARP는 수행하지만 패킷이 전송되지 않는다. why ?

이거는 리눅스의 방화벽인 iptables 설정 때문이다.

호스트에 들어오는 모든 패킷들은 netfilter를 보고 룰에 따라 처리한다.

이때 우리가 시도하는것은 reth0 -> beth0 으로 FORWARD ( 외부끼리의 통신, 호스트를 거쳐갈 뿐이고 src dest 모두 외부다. ) 인데

디폴트로 DROP 이다. 따라서 룰 추가를 해줘야 한다.

iptables -t filter -A FORWARD -s 11.11.11.0/24 -j ACCEPT

src 가 11.11.11.0/24 인 FORWARD 패킷들은 ACCEPT 한다는 뜻이다.

다시 tcpdump하고 packet 전송 시 성공적으로 ping이 보내지는 것을 알 수 있다.

1. Cloud Run 이란 ?

Google 에서 제공하는 Serverless 솔루션이다.

AWS의 Lambda 와 유사하지만 Cloud Run은 Container 기반으로, Container 위에서 구동 가능한 것은 뭐든지 실행할 수 있다는 장점이 있다. AWS의 Lambda 에도 컨테이너를 실행할 수 있다.

크게 Managed Cloud Run과 ( 사용중 ) , GKE 위에서 돌아가는 Cloud Run for Anthos가 존재한다.

쿠버네티스 위에서 돌아가는 서버리스 솔루션인 Knative를 이용한다고 한다..!

어쨌든 사용에 중심을 두고 얘기하자면 다양한 장점이 존재한다.

1. 한번 서비스를 올리고 나면 관리할 포인트가 거의 제로에 가깝다. 알아서 다 해준다. 이런게 서버리스의 장점이다. 

2. 구글의 로깅 및 모니터링 서비스인 Stackdriver를 통해 컨테이너에서 나오는 로그(stdout 등)를 수집하고 관리할 수 있다.  

3. 버전관리가 쉽다. 배포전략을 여러가지로 가져갈 수 있다.(트래픽을 Cloud Run Revision마다 조절할 수 있다.)

4. 그리고 자동으로 HTTPS 엔드포인트도 제공해준다.

또한 서버리스 솔루션이지만 최소 인스턴스(컨테이너) 갯수를 남겨둘 수 있다. 이로 인해 Cold Start 문제에 대해 고민할 부분이 적어진다. ( 당연히 요금이 부과된다. )

2. Cloud Run CI/CD 구성

소스코드는 Github 으로 관리하고 있었고, 기존에는 Github Action을 이용해서 GCR(Google Container Registry)로 빌드하는 파이프라인으로 구성하려 했으나,

GCP 내에서도 Build 파이프라인을 구성해주는 Cloud Build란 솔루션이 있어 사용했다. Github Action의 경우 GCP 인증 관련 값들을 관리해줘야 했는데, Cloud Build는 당연히(?) 필요없다.

Cloud Build는 서버리스 CI/CD 관리 툴로, 도커 컨테이너에서 실행되는 빌드 단계들로 구성되어 있다.
여기엔 GCP 에서 제공하는 기본적인 이미지들 ( docker, gcloud.. )와 커스텀 빌드 이미지를 사용할 수 있다.

또한 빌드 트리거로 기본적인 Github Push 등 뿐만 아니라 Webhook, Cloud Pub/sub 메시지 등도 제공한다.

나는 간단하게 1. 소스코드 clone후 build 2. 빌드 이미지 GCR에 push 3. Cloud Run에 배포 4. Slack Webhook으로 빌드 알림 순으로 구성했다.  추후 방학때 시간이 되면 테스트도 구성해서 빌드 파이프라인에 포함시킬 예정이다.

입력 N이 들어오면 N보다 큰 소수이면서 & 팰린드롬인 가장 작은 수를 출력하는 문제이다.

풀이

간단한 문제다. 일단 전처리로 모든 가능한 소수 & 팰린드롬들을 구하면 [2,3,...,1003001] 이 되고 입력에 따라 N보다 큰 최초의 수를 출력하면 된다.

전화번호 n개에 대해 서로 접두사 관계인게 존재하는지 찾는 문제이다.

전화번호의 길이는 O(1)이고 완전탐색을 통해 찾으면 O(n^2)이 되기 떄문에 더 빠른 알고리즘을 찾아야 한다.

문제를 풀고 검색을 해보니 트라이라는 자료구조, 또 문자열 배열 전체를 정렬해서 인접 문자열끼리만 확인하는 간단한 방법이 있었다. 

나는 문제를 풀긴 풀었는데 뭔가 빙빙(?) 돌아갔다.

풀이

나는 일단 가능한 케이스를 모두 뒤져보는 완전탐색으로 풀었다.

1. 문자열을 길이별로 나눈 후 정렬한다. ( O(nlogn) 소요 )

ex ) LIST[2] 에는 길이 2인 문자열들을 정렬하여 저장

2.  1<=i<j<=10 인 순서쌍 (i,j) 에 대해 

LIST[i]에 있는 문자열들을 순회하며 LIST[i]의 원소가 LIST[j]의 원소 중 접두사가 가능한 게 있는지 찾는다.

이 때 LIST[i]의 크기는 N이므로 LIST[i]의 문자열 순회는 O(n) 이 소요되고,

LIST[j]는 정렬되어있는 상태이므로 LIST[i]의 원소를 LIST[j]에서 찾는것은 O(logn)이 소요된다. 

따라서 (i,j)에 대해 수행하는 연산은 총 O(nlogn)이 소요된다.

또한 가능한 순서쌍 (i,j)는 문자열의 길이가 제한되어있기 때문에 O(1)이기 때문에 ( 최대 가능한 경우의 수는 55이다. )

모든 원소를 순회하며 탐색하는데 O(nlogn)이 소요된다.

정렬에 O(nlogn), 탐색에 O(nlogn)이 소요되므로 총 O(nlogn)에 문제를 풀 수 있다.

이렇게 풀긴 풀었는데 뭔가 엄청 간단한 풀이들이 있고,

트라이 라는 자료구조도 알게 되었음. 끝 !

또 파이썬에서 input()으로 받으니 시간초과가 뜬다. 메모메모

문제 바로가기

풀이

문제를 두 단계로 나눌 수 있다.

1. 모든 빙산에 대해 바다와 맞닿아있는 면적 갯수 계산
2. 빙산 업데이트 후 2개 이상으로 분리되었는지 확인

를 빙산이 없어지거나 빙산이 분리될 때 까지 반복해주면 된다.

주의할 점은 모든 빙산에 대해 계산 후 한번에 업데이트를 해줘야 한다.

1. 모든 빙산에 대해 바다와 맞닿아있는 면적 갯수 계산

상하좌우에 0의 갯수만큼 나중에 빙산을 업데이트 해주면 된다.
그래프 내의 빙산을 담고 있는 node 배열에 대해 똑같은 크기를 갖는 diff 배열에 값을 저장해서 계산했다.

2. 빙산 업데이트 후 2개 이상으로 분리되었는지 확인

node를 순회하며 diff값을 이용해 update 해주면 된다.

이후 빙산들에 대해 1) 빙산이 여러개로 분리 2) 아예 사라지는 경우

에 대해 체크해줘야 한다.

1)의 경우 빙산 하나에서 BFS를 했을 때 모든 node에 대해 방문이 되어야 한다. 그렇지 않으면 현재까지 진행한 값(year)를 출력하고 종료한다.
2)는 빙산이 분리되지 않고 다 녹는 경우이다. 0을 출력하고 종료한다.

1)과 2) 둘다 만족하지 않으면 year를 증가시키고 1을 다시 시작하면 된다.

React에서 객체는 Immutable하게 다뤄진다.

Immutability가 가져오는 장점은 많은게 있겠지만, React에서 가장 중요한 이유는 바로 "Detect Changes"이다. ( Reactjs 공식 doc 참조 )

React에서는 State 또는 Props 객체가 변경될 시 변경부분을 재계산하여 Virtual DOM -> DOM 순으로 리렌더링 하게 된다.

이 때 객체들이 Mutable 하면 어떨까? 객체의 변경을 알기 위해서는 Object의 요소 하나하나를 모두 추적해야 객체의 변경사항을 알 수 있다.

하지만 객체를 Immutable하게 유지하면 prevState === State 식을 이용하여 주솟값만 봄으로써 객체의 변경사항을 확인한다.

간단한 식을 이용하여 리액트는 컴포넌트를 다시 재계산해야 하는지 알 수 있다.

문제

선영이는 주말에 할 일이 없어서 새로운 언어 AC를 만들었다. AC는 정수 배열에 연산을 하기 위해 만든 언어이다. 이 언어에는 두 가지 함수 R(뒤집기)과 D(버리기)가 있다.

함수 R은 배열에 있는 숫자의 순서를 뒤집는 함수이고, D는 첫 번째 숫자를 버리는 함수이다. 배열이 비어있는데 D를 사용한 경우에는 에러가 발생한다.

함수는 조합해서 한 번에 사용할 수 있다. 예를 들어, "AB"는 A를 수행한 다음에 바로 이어서 B를 수행하는 함수이다. 예를 들어, "RDD"는 배열을 뒤집은 다음 처음 두 숫자를 버리는 함수이다.

배열의 초기값과 수행할 함수가 주어졌을 때, 최종 결과를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 테스트 케이스의 개수 T가 주어진다. T는 최대 100이다.

각 테스트 케이스의 첫째 줄에는 수행할 함수 p가 주어진다. p의 길이는 1보다 크거나 같고, 100,000보다 작거나 같다.

다음 줄에는 배열에 들어있는 수의 개수 n이 주어진다. (0 ≤ n ≤ 100,000)

다음 줄에는 [x1,...,xn]과 같은 형태로 배열에 들어있는 수가 주어진다. (1 ≤ xi ≤ 100)

전체 테스트 케이스에 주어지는 p의 길이의 합과 n의 합은 70만을 넘지 않는다.

출력

각 테스트 케이스에 대해서, 입력으로 주어진 정수 배열에 함수를 수행한 결과를 출력한다. 만약, 에러가 발생한 경우에는 error를 출력한다.

풀이

파이썬으로 처음 풀어본(아마?) 알고리즘 문제이다. 알고리즘 자체도 정말 오랜만에 푼다..

일단 풀이자체는 쉽다. 파이썬에 익숙하지 않다보니 함수 뒤적뒤적하느라 좀 시간이 걸렸다..

주어진 연산은 처음 원소를 삭제하는 D와 리스트를 뒤집는 R연산이 존재한다.

원본 배열에서 D연산과 R연산을 사용해 결과를 출력하면 된다.

이 때 결과는 원본배열의 부분배열이거나(R연산을 짝수번 수행) , 원본배열의 부분배열을 뒤집은 것이다.(R연산을 홀수번 수행)

필요한 변수는

1) 배열의 방향을 의미하는 DIR 플래그 ( 0 = 정방, 1 = 역방향 )

2) 부분배열의 시작과 끝을 저장하는 FR, TO 변수  ( 초기 : FR = 0, TO = n-1 )

연산을 순회하며

1) R연산시에는 DIR 플래그만 바꾸어준다.

2) D연산시에는 DIR이 0이면 앞에서부터 삭제(FR++) 한다. 반대로 DIR이 1이면 뒤에서부터 삭제(TO--) 한다.

이때 배열이 비어있음을 의미하는 것은 TO-FR == 1인 상태이다.  1이상이 되면 error를 출력한다. ( 빈 배열에 대해 D 연산 수행 )

연산을 모두 순회한 뒤 DIR 플래그를 보고 원본배열의 FR~TO 부분 배열을 그대로 출력하거나 거꾸로 출력하면 된다.

문제 아이디어 자체는 쉬웠지만 파이썬에 익숙하지 못해서 리스트 조작에 시간이 좀 걸렸다. 파이썬 공부하자!

Fragmentation

메모리에 프로세스를 적재할 때 메모리의 빈 공간이 작은 조각들로 나누어져 사용이 불가능한 상태를 말한다.

Fragmentation에는 두가지 종류 : 내부(internal)과 외부(External)이 존재한다.

1. Internal Fragmentation

• 프로세스가 필요한 메모리 크기보다 더 큰 메모리를 할당해주어 생기는 문제이다. 세그먼트 단위로 프로그램을 분리해서 메모리를 할당하여 해결할 수 있다.

1. External Fragmentation

• 프로세스들을 메모리 파티션에 계속 할당하고 해제하다 보면 중간 중간에 사용가능하지만 작은 메모리공간들이 존재한다. 이를 External Fragmetation이라 한다. first-fit 방식을 사용하여 메모리를 할당하면 N개의 블록 중 0.5N개의 블록이 Fragmentation으로 사용불가능해진다. 이를 50%-rule이라 한다. 페이징 기법을 사용하거나 메모리 공간을Compaction(압축) 하여 해결할 수 있다.