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

AWS Aurora 를 사용하는데, MySQL InnoDB 엔진 기반으로 사용하고 있다. 따라서, 적어도 알고는 쓰자! 라는 관점에서 정리를 해봤다. 공식 document 를 훑어보고, 이거저거 찾아보고 정리를 해보았다. https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-shared-exclusive-locks Shared Locks 다른 트랜잭션이 해당 lock 이 걸린 row 를 read 할 수 있도록 하는 lock, 또한 해당 row 에 다른 shared lock 을 걸 수 있음. 하지만, write(CUD) 는 불가능함. Exclusive Locks 어떤 다른 트랙잭션도 exclusive lock 이 걸린 row 에는 exclusive lock 을 걸 수 없음. 또한, transaction isolation level 에 따라, exclusive lock 이 걸린 row 에 대해서는 다른 트랜잭션이 write(CUD) 뿐만 아니라 read 를 수행할 수 없음. MySQL InnoDB engine 의 default isolation level 은 REPEATABLE READ 이며, 이는 exclusive lock 을 지닌 rows 들을 다른 트랜잭션이 read 는 가능하도록 하는 level 로써, 높은 동시성을 가능하게끔 해주며 이를 consistent read 라 한다. s lock, e lock 예시 만약 Transaction T1 이 row R 에 대하여 shared(S) lock 을 획득하고, Transaction T2 가 row R 에 대하여 접근 했을 때, T2 는 아래 2가지가 가능하다. T2 는 R 에 대하여 S lock 을 즉시 획득 가능. → T1, T2 R 에 대하여 S lock 을 가진다. T2 는 R 에 대하여 exclusive (X) lock 을 즉시 가지지 못한다. 만약 Transaction T1 이 row R 에 대하여 exclusive...

 https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt 이번에는 eks cluster 의 worker node 를 fargate 대신, managed 혹은 un-managed node group 으로 관리할 때 생길 수 있는 이슈인 Pod Limit 에 대해 정리해보겠다. 제일 먼저 올린 링크에서 확인할 수 있듯이, ec2 type 에 따라 pod 를 deploy 할 수 있는 제한이 있다. t3.micro 의 경우 pod 제한이 4개, t3.nano 도 pod 제한이 4개 이다. Pod Limit 이 어떤 상황을 야기시킬 수 있을지 테스트해보자. 먼저, cluster 를 만든다. eksctl create cluster --version 1.17 --name pod-test --node-type t3.micro --nodes 2 kubectl get ns 명령어로 namespace 를 확인한다. kube-system namespace 의 pods 들을 확인할 수 있다.  해당 pod 들은 k8s 시스템에서 생성한 오브젝트들로, k8s cluster 구성에 필수적인 컴포넌트들과 설정값 들이다. 이미 위에서 t3.micro type 으로 node 를 생성했고, t3.micro 의 pod limit 은 4 이다. 이미, kube-system 네임스페이스에 6개의 pod 가 running 하고 있다.  2 node (t3.micro)  * 4 (pod limit per t3.micro) = 8 (pod limit) 이며, 즉 추가적으로 running 가능한 pod 의 수는 2개가 된다.  그렇다면 이제 2개 이상의 pod 를 deploy 해보자. 해당 yaml 파일을 통해서 replicas 3 을 통해 desired pod 수는 3이다. 하지만, 결과는 1개의 pod 는 pending status 라는 것을 확인할 수 있다? 원인은 바로 0/2...

https://github.com/ndgndg91/eks-practice eksctl 을 사용하기 위해서 필요한 것은 4가지이다. https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/getting-started-eksctl.html 1. aws cli 설치 - aws cli 기존에 설치되어 있어도 반드시 버전을 확인해야 한다. eksctl 을 사용하기 위해서는 aws cli 1 버전을 사용하는 경우 1.18.149 이상이여야 하며, aws cli 2 버전의 경우 2.0.52 이상이여야 한다. 기존에 https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/install-cliv2-mac.html#cliv2-mac-install-gui 2. aws cli 를 버전에 맞게 설치했다면, aws configure 를 통해서 올바른 role 을 가진 IAM user 의 access_key, secret_access_key 를 등록해주자. 3. 다음으로 중요한 k8s 클러스터를 제어하기 위한 kubectl 을 설치하자. homebrew 패키지 매니저를 이용하면 간단하게 설치가 가능하다. https://kubernetes.io/ko/docs/tasks/tools/install-kubectl/ https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-kubectl.html 4. 마지막으로 eksctl  https://github.com/weaveworks/eksctl - aws cli version - aws cli configure 확인 - kubectl version 확인 - eksctl version 확인 eksctl 명령어로 cluster 만들기 eksctl create cluster --name eksctl-test --nodegroup-name ng-default --node-type t3.micro --nodes ...

순서를 고려해야 하는 값 class 를 작성한다면 꼭 Comparable Interface 를 구현해서, 해당 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야 한다. compareTo 메서드에서 필드의 값을 비교할 때 < 와 > 연산자는 쓰지 말자. 대신, 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나 Comparator Interface 가 제공하는 비교자 생성 메서드를 사용하자. 먼저, compareTo 를 구현할 때 3가지 규약을 살펴보자. equals 규약과 비슷하다. 1. 대칭성 - 두 객체 참조의 순서를 바꿔 비교해도 얘상한 결과가 나와야 한다. 2. 추이성 - 첫 번째가 두 번째보다 크고 두 번째가 세 번째보다 크면, 첫 번째는 세 번째보다 커야 한다. 3. 반사성 - 크기가 같은 객체들끼리는 어떤 객체와 비교하더라도 항상 같아야 한다. 반사성에서 한 가지 주의할점은 equals 와 compareTo 를 일관되게 구현해야 된다는 점인데, 일관되지 않을 경우, Collection 을 사용할 때 의도와 다르게 작동할 수 있다. Bigdecimal 의 예를 보자. 아래의 javadoc 을 살펴보자. 두 객체의 equals 메서드의 경우 다르다고 나온다. 왜냐면 equals 메서드가 scale 여부까지 비교한다. 하지만, compareTo 는 값이 같은지 비교하기 때문에, 같다고 나온다. 따라서 이와 같이 BigDecimal 을 사용할 때, 주의하지 않으면 의도치 않은 버그가 발생할 수 있다. 더욱이, 아래와 같이 Collection 을 사용할 경우, 더욱이 주의해야 한다. HashSet 은 equals 를 기반으로, TreeSet 의 경우 compareTo 를 기반으로 비교하기 때문에, 이와 같은 결과가 나타난다. https://stackoverflow.com/questions/6787142/bigdecimal-equals-versus-compareto https://docs.or...

 이번 글에서는 Dockerfile 과 .dockerignore 파일을 이용하여 express 프레임워크를 사용한 node JS application 을 build 하고 Dockerfile 작성 시 Image layer 캐싱에 대하여 간단하게 정리해보겠다. 우선, 정말로 간단한 express application 이다.  https://expressjs.com/ko/starter/installing.html user-service-api 라는 directory 를 생성하고, npm 을 통해 express 를 사용할 수 있도록 하였다. index.js 를 아래와 같이 작성했다. 3000 port 로 서빙한다. / path 접근 시 정적으로 name, email 을 형식의 object 를 array 로 내려준다. 이제 Dockerfile 을 작성해보자. node 최신 이미지를 base image 로 사용하고, /app 을 working directory 로 설정한다. 그리고 현재 user-service-api directory 밑에 모든 파일을 /app 밑에 ADD 한다. 그리고 npm 명령어를 통해서 의존성을 설치하고, CMD 를 통해 container 가 run 할 때 index.js 를 실행한다. docker -t user-service-api:latest . 를 통해서 build 한다. npm install 명령어를 하게 되면 package.json 의 dependencies 를 node_modules 밑에 설치하게 된다. 설치된 의존성에 대한 snapshot 이 package-lock.json 파일에 남는다. 따라서 image 를 빌드할 시점에 node_modules 밑에 있는 의존성은 추가될 필요가 없다. 그래서 .dockerignore 파일을 작성하여 제외시키도록 하자. 또한 Dockerfile 및 .git 아래에 있는 해당 레포지토리에 대한 정보들 또한 build 에 필요없는 정보라서 같이 제외시킨다. 이외에도 build 에 필요하지...