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

Index 종류 B-tree - high cardinality, re-balanced needed, logN Hash - Hash Function BitMap - low cardinality columns ( ex. boolean ) Specialized Index Index Pros and Cons index 는 항상 모든 케이스에 적절한것은 아니다. 적은 수의 rows 의 table 의 경우 index search 보다 순차적 search 가 빠를 수 있다. 또한 table 의 대부분의 rows 나 전체 rows 를 조회할 때는 순차적 search 가 더 빠를 수 있다. 그러나, 대부분의 경우 index 가 조회 성능을 향상 시킨다. Where 절을 통한 쿼리 Index 에 해당하지 않는 행은 검색에서 제외한다. Join 에서도 성능이 좋다 min, max 값을 찾기 좋다. group by, order by 의 성능에도 좋다. table 에서 직접 조회하기 보다, index 를 통해서 조회한다. index 는 SELECT query 의 속도를 높여주는데 좋은 반면에, 실질적으로 UPDATE, INSERT, DELETE 는 속도를 저하 시킨다. 왜냐하면 MySQL 은 table 에 변화가 일어나면 data 를 reindex 한다. 만약, 조회보다 변경이 많은 테이블에서는 인덱스를 사용하지 않는 것이 좋을 수도 있다. 또한 색인은 저장해야하는 추가 데이터가 있는 테이블로 데이터베이스에서 추가 공간을 차지한다는 점도 고려해야한다. 이는 큰 고려 사항은 아니지만 데이터베이스에 허용하는 공간에 따라 달라질 수 있다. Clustered Index vs Non-Clustered Index Clustered Index  - PK 제약 조건과 같이 생성된 테이블은 database engine 이 자동으로 clustered index 를 생성한다. 따라서 data 는 key, value 에 맞게 정렬되어 저장된다. Non-Cluster...

유투브 GOTO Conferences 채널에서 마틴 파울러 형님과 샘 뉴먼 형님이 MSA 를 언제해야되고 언제 하면 안되는가? 대한 토론을 담은 영상을 보았다. https://www.youtube.com/watch?v=GBTdnfD6s5Q 개인적으로 MSA 에 대한 경험이 없는 나로서는 두 형님들의 토론이 상당히 흥미를 가지고 보았다. 영상의 시작은 샘 뉴먼 형님이 아래의 책 Monolith to Microservices 란 책을 왜 집필하게 되었는지에 대한 질문으로 시작한다. 샘 뉴먼 형님은 2014년에 아래의 Building Microservices 란 책을 집필했다. 그리고 Monolilth to Microservices 는 아래의 책의 second edition 이라고 한다. 그리고 Monolith to Microservices 에서는 어떻게 큰 모놀리틱을 작게 나눌지에 대한 내용을 주로 다루었다고 한다. 그리고 해당 내용을 집필하는 과정에서 보다 면밀한 내용을 다루고 싶었다고 한다. 대화내용 정리.. 그리고, 마틴 파울러 형님이 나오면서 묻는다.  고작 천 줄의 코드의 프로그램을 만들면서, MSA 를 옹호하고  MSA 를 사용하면서 100줄 코드로 구성된 여러 서비스로 나누는 것을 보았다. 하지만, MSA 에 대해서 부정적인 견해를 가진 사람들은 찾기 힘들다. 단지 새로운 기술을 사용하고 싶어서 채택한다.  진정으로 언제 MSA 사용해야 된다고 생각하는가? 이에 샘 뉴먼 형님은 이렇게 답한다. MSA 를 하면서 MSA 가 주는 장점이 무엇인지 의식해야 한다고 말하며 아래의 3가지를 말해준다. - More options to scale up applications. (스케일 업에 대한 보다 많은 선택지) - Independent deployability (독립적인 배포) - Limit the "blast radius" of failure (장애 확산 방지) 그리고 James Lewis 말을 인용한다. "Microservices...

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 에 필요하지...