기록들 https://github.com/ndgndg91

IP Address IP 주소는 Network Address 와 Host Address 로 구성되어 있으며, 32 bit로 4 byte 데이터이다. 예를들어, 10.11.12.13 이라는 IP Address 는 아래와 같이 구성되어있다. 10.11.12 .0 → 00001010.00001011.00001100. ( Network Address ) 0.0.0. 13 → 00001101 (Host Address) 전체 IP Address 를 32비트로 보면 아래와 같이 나타낼 수 있다. 10.11.12.13 → 00001010.00001011.00001100.00001101 하나의 8비트 섹션을 옥텟(octet)이라 부른다. Subnet Mask TCP/IP 프로토콜에 의해 Host 가 로컬 서브넷에 있는지 아니면 원격 네트워크에 있는지를 확인하는 데 사용된다. 10.11.12.13 → 00001010.00001011.00001100.00001101 255.255.255.0 → 11111111.11111111.11111111.00000000 이는 10.11.12.0/24 를 의미한다. 24 는 24 bit 를 의미하는데 앞서 255.255.255.0 은 8bit.8bit.8bit.0 을 의미한다. 따라서, 8bit * 3 = 24bit 을 의미하며, 8bit 이라는 의미는 더이상 해당 옥텟에 host 부여가 불가능하다는 의미이다. 따라서 해당 네트워크의 호스트가 부여가능한 IP range 는 10.11.12.1 ~ 10.11.12.254 범위를 의미한다. 여기서, 10.11.12.0 과 10.11.12.255 는 포함되지 않는다. 호스트 번호 부분의 비트 값이 모두 0 또는 1인 경우는 특별한 의미를 가진다. 모두 0 → 서브넷 자체를 가리킨다. (10.11.12.0 → 00001010.00001011.00001100. 00000000 모두 1 → 서브넷에 있는 기기 전체에 패킷을 보내는 브로드캐스트  를 나타낸다. (10.11.12.255 →...

 지난 글  https://infondgndg91.blogspot.com/2020/08/aws-vpc.html  에서 서울 리전에 VPC 및 서브넷을 생성해 보았다. 이전 글에서 만들었던 VPC 를 기준으로 인터넷 게이트웨이와 NAT 게이트웨이, 라우팅 테이블, 탄력적 IP, 네트워크 ACL, 보안 그룹을 실습 하면서 아래와 같이 정리해보겠다. 우선, 라우팅 테이블은 VPC 생성 시 자동으로 생성 된다. 기본 VPC 를 통해 확인이 가능하다. 먼저, 기본 VPC 기본 VPC 에 매핑 된 라우팅 테이블 기본 VPC 의 CIDR 블록을 172.31.0.0/16 의 대상은 local 로 기본 VPC 에 속한 모든 Subnet 에 대하여 라우팅을 제어하는 역할은 한다.  그리고 기본 VPC 가 아닌 새로 VPC 를 생성하는 것과의 차이는 바로 Internet Gateway. 기본 VPC 에는  Routing table 에 자동으로 Internet Gateway 가 붙어 있다.  Internet Gateway 가 하는 역할은 VPC 내의 Instance 와 인터넷 간의 통신이 가능하게 만들어 준다. 하지만 기본 VPC 가 아닌 새롭게 생성한 VPC 의 경우에는 Internet Gateway 가 자동으로 생성되지 않고 라우팅 테이블에 추가 되지 않기에, 새롭게 Internet Gateway 를 생성해주고 새로 생성한 VPC 라우팅 테이블에 추가해줘야 인터넷과 새로 생성한 VPC 내의 Instance 간의 통신이 가능하게 된다. 아래와 같이 Internet Gateway 를 생성하고,  새로 생성한 giri-vpc 에 attach 했다. Destination 0.0.0.0/0 Target 은 새로 생성한 Internet Gateway 가 새로 생선한 giri-vpc 라우팅 테이블에 추가 되었다.  여기서 중요한 점은 이전 글에서 생성한 Public Subnet 과  Private Subnet 에...

 이번글에서는 AWS 사용하면서, 뼈대가 되는 VPC 를 직접 생성 하면서 정리를 해보겠다. 리전은 한국사람이니 서울을 선택했다. Region 별로 비용의 차이가 있다고 하는데, 어차피 당장 서비스를 올릴게 아니라서 비용 따위는 생각하지 않는다. 그럼 시작해보자. 우선, VPC 를 생성하기에 앞서 가장 기본적인 주의사항에 대해서 짚어보자. CIDR 블록 설정 시 주의사항 → 사설 ip 대역만 설정한다. 공인 ip 대역을 설정하게 될 경우 VPC 내부망과 겹치는 공인 IP 는 인터넷 즉, VPC 외부에서 접속이 불가능하게 된다. 따라서 인터넷 연결이 필요한 경우에는 반드시 사설 IP 대역을 사용해야 한다. 10.0.0.0 ~ 10.255.255.255  172.16.0.0 ~ 172.31.255.255  192.168.0.0 ~ 192.168.255.255 아래와 같이 giri-vpc 라는 이름의 vpc 를 생성했다. CIDR 블록은 10.255.0.0/16 로 설정했다. VPC 만 가지고 할 수 있는 것은 아무것도 없다. VPC 는 availity zone 들의 논리적인 묶음이라고 보면 된다 따라서 VPC 를 생성 하면서 할당한, CIDR 블록을 다시 Subnet 단위로 나눈다. 하나의 VPC 는 N개의 Subnet 을 가질 수 있다. Subnet 의 CIDR 블록을 작게 잡을수록 VPC 를 많은 Subnet 으로 나눌 수 있다. 일반적으로 Region 의 가용 영역의 개수 만큼 Subnet 을 구성하여, 재해에 대응하는 방법을 취하고 있다. 서울 리전 (ap-northeast-2a) 의 경우에 가용 영역은 총 4개이다. 앞서 생성한 giri-vpc 를 4개의 subnet 으로 구성할 것이다. 여기서 한 가지 주의할 점! 각 서브넷의 0, 1, 2, 3 과 255 주소는 instance 에 할당할 수 없다. 아래의 문서를 참고하면 된다. https://docs.aws.amazon.com/vpc/latest/userguide/VP...

네트워크 드라이버 bridge host none container overlay 아무런 설정을 하지 않고 컨테이너를 생성할 경우 기본적으로 docker0 bridge 사용한다. veth 인터페이스는 각 Container 마다 생성된다. docker0 인터페이스와 Binding 되어 호스트의 eh0 인터페이스와 이어지며 외부와 통신이 가능하게 된다. Bridge Network docker network ls 명령어와 docker network inspect bridge 명렁어를 통해서 확인하기 Gateway 와 Subnet 을 확인할 수 있다. 그렇다면, docker network create --driver bridge {name} 명령어를 통해서 사용자 정의 브리지를 생성하고 적용해보자. 기본 bridge 와는 다르게 172.18.x.x 대역으로 Gateway 와 Subnet 이 잡혀있다. 사용자 정의 브리지를 통해서 컨테이너를 생성해보자. docker run -it 옵션을 통해서 생성한 컨테이너에 attach 모드로 들어간다. --net 옵션을 통해서 사용자 정의 브리지를 설정한다. 생성한 ubuntu 컨테이너안에서 ifconfig 명령어를 통해서 172.18.0.2 를 할당받은 것을 확인할 수 있다. 또한 임의로 Subnet, Gateway, Ip range 를 아래와 같이 설정할 수 있다. --subnet 옵션과 --ip-range 옵션 그리고 --gateway 옵션을 통해서 가능하다. --net-alias 옵션을 통해서 사용자 정의 브리지에 별칭을 부여할 수 있다. ip 할당은 라운드 로빈방식이다. 각각의 컨테이너에 172.18.0.2 ~ 4 까지 할당한 것을 확인할 수 있다. Host Network 호스트 네트워크 환경을 컨테이너에서 동일하게 사용한다. 컨테이너 내부의 Application 을 별도의 port forwarding 없이 바로 서비스가 가능하다. None Network 아무런 네트워크도 사용하지 않는 것. 컨테이너 외부와...

Image 와 Container 의 이해 이미지 - 컨테이너를 생성할 때 필요한 요소이며, 여러 개의 계층으로 된 바이너리 파일로 존재하며, 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다. 컨테이너 - 이미지를 읽기 전용으로 사용하되 이미지에서 변경된 사항만 컨테이너 계층에 저장하므로 컨테이너에 무엇을 하든지 원래 이미지는 영향을 받지 않는다. Image 는 특정 Application 에 필요한 코드와 라이브러리와 의존성 등을 가진 불변( Immutable, unchangeable ) 파일이다. Image 는 read-only template 이다. 특정 시점의 가상 환경 혹은 Application 을 나타내는 일종의 스냅샷으로 이해할 수 있다. → 이러한 Docker 의 훌륭한 특징 중의 하나로, 개발자들이 안정적이고 단일한 환경에서 test 하고 실험할 수 있는 환경을 만들어 낸다. Container 는 Image 를 단지 run 한 것이다. Container 를 생성하게 되면, 불변한 Image 의 최상단에 Writable Image Layer 를 추가하여 변경이 가능하도록 한다. 이를 쉽게 이해하기 위해서 아래 이미지를 참고하면 된다. Image 와 Container 는 면밀히 관련되어 있다. Image 는 Container 없이 존재할 수 없으며, Container 는 존재하기 위해서 Image 를 run 해야 한다. 따라서, Container 는 Image 에 의존적이고, run-time 환경을 생성하기 위해서 Image 를 사용한다. Image 와 Container 의 개념은 Docker 의 근본적인 component 로써 존재한다. 정확하게 일치하는 개념은 아니지만, 객체 지향 관점에서 Docker 의 생태계를 비추어 볼 때 유사한 지점이 있다. Image 를 class 에 비유할 수 있으며, Container 를 해당 class 의 Instance 로 비추어 볼 수 있을 것 같다. Docker Engine Do...

지난 글에서는 ArrayList 를 까보면서 native 메서드에 대해 잠시 다루어보았다. 이번 글에서는 직접 HashMap 을 구현해보도록 하겠다. JDK 를 까보면서 그리고 여라 다른 블로깅을 참고하면서 내 방식으로 구현해 보았다. https://medium.com/@mr.anmolsehgal/java-hashmap-internal-implementation-21597e1efec3 https://www.devglan.com/java8/hashmap-custom-implementation-java https://d2.naver.com/helloworld/831311 우선, 핵심을 먼저 정리하고 작성해보겠다. HashMap 은 Key Value 저장소이다. 분할상환방식에 의해서 get() put() 메서드는 상수 시간의 시간복잡도 O(1) 을 가진다. HashMap 은 내부적으로 key, value 를 지닌 Node 의 배열을 가진다. Node 의 개념과 일치하는 class 는 Entry<K, V> class 이다. HashMap 은 get(), put() 메서드 호출 시  객체의 hashcode 를 통해 index 를 계산하고  Node 배열의 Node 를 배치시킨다.  그렇다면 같은 index 를 가지는 객체들은 어떻게 관리를 할까? 바로 LinkedList 를 배열의 index 마다 가지며, 2차원 형태의 테이블을 이루게 된다. 아래는 JDK 11 버전의 HashMap 을 직접 까보았다. 아래와 같이 Node 는 Map.Entry<K, V> interface 를 구현하고 있다. 그리고 필드로는 hash, key, value, 그리고 LinkedList 이기에 next 를 가진다. 여기까지가 HashMap 가장 기본적인 원리이다. 하지만 가장 큰 문제가 있다. 바로 다른 객체가 동일한 hashcode 를 가질 때 이다. 예를 들어, 아래와 같이 Developer class 를 작성했다. equals() 와 h...

요즘, 그동안 기본기를 너무 챙기지 않고 프레임 워크와 아키텍쳐에 빠졌나 싶어서, 자료구조와 알고리즘을 다시 보고 있다가, 실질적으로 jdk 의 List 구현체인 ArrayList 를 까서 보았다. 그러다가 흥미로운 것을 보게되었고, 실질적으로 jdk 를 까보는 것도 재미가 있어서 블로깅을 해본다. 다들 알겠지만, ArrayList 는 말 그대로 내부적으로 data 를 저장하는 배열(array) 을 가지고 있다. 자료구조와 알고리즘 공부를 하게되면, 기본중의 기본인 ArrayList 와 LinkedList 의 비교를 하게 된다. ArrayList 의 add() 메서드는 끝에 집어 넣을 때 O(1) 상수 시간이고, 처음에 집어 넣을 때와 일반적인 상황에서 O(n) 으로 선형 시간이 된다.  remove() 메서드도 배열의   제일 마지막을 지울 경우 O(1) 상수 시간이고, 처음을 지울 때와 일반적인 상황에서는 O(n) 으로 선형 시간이 된다. 배열을 내부적으로 가지고 있기 때문에, 당연하게 시작 혹은 중간에 data 를 삽입하게 되면 삽입 지점 index 에 있던 원래 있던 data 부터 배열의 끝까지의 모든 데이터들을 다음 index 공간( 오른쪽 )으로 Shift 연산을 해야 한다. 즉 해당 index 지점부터 배열의 끝까지 순회 하면서 오른쪽으로 한 칸 씩 밀어주게 된다. 반대로 remove 삭제의 경우에도, 시작 혹은 중간에 data 를 지우려고 하면 해당 지점 index 한칸 뒤에 있는 지점부터 배열의 끝까지의 data 들을 한칸 씩 모두 왼쪽으로 Shift 연산을 해야 한다. 즉 해당 index 다음 지점부터 배열의 끝까지 순회 하면서 왼쪽으로 한 칸 씩 밀어주게 된다. 이미지 제작의 귀찮음으로 아래 사이트의 이미지를 사용했다. https://cloudstudying.kr/lectures/138 그래서 Shift 연산이 필요하기 때문에 선형 시간 O(n) 의 시간 복잡도를 가진다. 자, 그렇다면 이제 JDK 를 까보자....