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

 객체 지향의 5대 원칙으로 불리는 SOLID 원칙에 대해서 예제를 만들어서 정리해보려고 한다. SOLID 를 처음 알게 된 것은 첫 회사 면접에서 질문을 통해서 알게 되었다.  "객체 지향의 5대 원칙에 대해서 아나요?" 라는 질문이다. 벌써 3년 전 일이다. 당시에는 "응? 그런게 있구나??" 속으로 생각했었다. 면접이 끝나고 찾아봤는데, 그 당시에는 이게 개발하는데 중요한 것일까? 라는 생각을 했었는데 1년 씩 연차가 쌓이고 경험을 하면서 음 그래서 중요하구나.. 로 바뀌게 되었다. 코드를 한 번 작성하면 끝나는 것이 아니라, 결국 유지 보수를 해야된다. Software 는 계속해서 변화하는 요구사항들을 만족시키기 위해서 진화해야 된다. 그래서 중요한 것은 재사용하기 쉽고, 확장하기 쉽고, 진화하기 쉽고, 테스트하기 쉬워야 한다.  따라서 좋은 코드를 작성하기 위해서 스스로 정리 한다. 1. Single Responsibility Principle - 단일 책임 원칙 A class should have a single responsibility. 클래스는 책임을 하나만 가져야 한다. 다시 말해, 클래스 변경의 이유는 오직 하나여야만 한다. 왜? 1. Testing - 책임이 적을수록 테스트 케이스도 적어진다. 2. Lower Coupling - 책임이 적으면, 클래스의 기능도 적어지고, 의존성도 낮아진다. 그렇다면 예제를 통해 확인해보자. God 클래스를 만들었다. 이름에서 알 수 있듯이 많은 일을 하는 클래스이다. God 은 design 하고 develop 도 하고 plan 도 하고 customer service 도 한다. 흔히들 말하는 common 의 저주이다. God 은 모든일을 할 수 있다. 그럼 SRP 에 맞게 Class 를 나눠보자. God 클래스를 총 4개의 class 로 나누었다. Developer, Designer, Planner, CustomerServiceRepresentative.  준비한 예제가 ...

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 ...