데센프 10주차 필기 5/18~22

[월: 마이크로서비스, 카타코다]

2. CloudNative과 전통적인 Software 개발 방법과의 차이점이 무엇인지 설명하시오.

 

모놀리식은 큰 프로그램을 하나 짜서 여러 개의 복사본을 띄우다가,

우리가 만드는 프로그램은 어차피 서로 독립적인 프로그램들인데 그걸 하나로 합친걸 여러 개 복사본으로 띄우기보단 이렇게 독립적인 서비스 레벨에서 각각 따로 만들고, 띄우고.

7: 모놀리식이란것은 운체의 커널 이야길 할 때 많이 이야기하는 것. 여러 개가 묶여 하나로 되어있다.

왼쪽 그림(UI, business logic, data access layer)에 있는 것이 그냥 필요하기만 할 뿐 굳이 물리적으로 하나의 실행파일 안에 들어갈 필요는 없다는 생각을 하게 된 것이다.

ui도 한 대의 컴에서 돌아갈 필요 없이 여러 대에서 돌아가도록... 다른 것들도 마찬가지.

8: 온라인 쇼핑몰 아키텍처. 모놀리식. 나중에 사용자 요구가 늘어나면 용량을 늘리려 하면 방법 2가지

하나는 지금보다 성능이 좋은 컴을 사서 그 위에서 이걸 돌리는 것.

다른 하나는 너도 알다시피 복사해서 쌍둥이 여러개 돌리는 것

이렇게 따로따로 띄울 떄 가장 중요한것은 왜 둘, 셋으로 키워야 하는지 말할 수 있어야 함.

이를테먼 어떤 모듈은 기존 대비 얼마, 기존대비 얼마,... 이런 식으로 이야기할 수 있어야 함. 용량 증설 요구사항을 알아야 하기 때문.

모든 소웨가 n배로 증가하는게 아니라면 마이크로서비스에선 필요한 소웨에 대해서만 용량을 증가시키는 일을 하라.

차별화된 용량에 대한 증설!

 11: 모듈간 주고받는 통신, API들에 의해 이뤄지므로 이것만 준수하면 오른쪽 그림의 빨강,노랑 보라 등등(서로 다른 state logic을 의미한다)은 서로 무슨 일을 하는지 알 필요가 없다. 따라서 부서 간 연관도 없어지니 회의도 빨라지고 일도 빨라지고 ... 그렇다

소웨도 결국 비주얼 스튜디오나 이런 것이 각각 따로 만들어지므로 ... 

빨강의 개발~배포, 릴리즈는 노랑하고 상관이 없어진다.

그리고 각 부서에게 최적화된 릴리즈 기간을 준수할 수 있다.

api 상에서 얜 이걸 주고 얜 이걸 주는거야 이런 내용들이 정해지고나면...

사람 뽑을때도 마이크로서비스면 딱 이것에만 최적화된 사람을 뽑으면 된다. 부서 교육 기간도 줄어들고... 매우좋음

다른 팀하고 정책은 같이 준수할 필요가 있겠지만 기술적으로 릴리즈를 같이 해야 할 필요성은 적어진다.

이 내용을 정리한 것이 12, 13 페이지.

- 스케일: 용량 조절 맘대로, 편하게 가능. 이번에 코로나로 ebs 용량 문제 터졌을 떄도 전문가들이 클라우드 용량 늘린다고 해결되는 게 아니고, 그런 구조에 맞도록 짰었어야 한다. 고 말했다. 클라우드에 맞게 개발이 되어있었어야 했다.

- 가용성: 한 부분이 죽으면 모놀리식이면 다같이 죽음. 그러나 마이크로 서비스는 안그렇다. 전체가 죽는 일은 잘 없어

- 애자일리티: 마이크로서비스가 시장에 ~를 제공하기 위한 ... 시장 반응 보기에도 이게 더 좋다

 

4. Microservice가 Polyglot 하기에 용이하다는 것을 실제 예를 들어서 설명하시오.

- 개발 방법 마저 팀별로 다르고, 언어도 다르게 해도 된다!!!!

- 코드를 유지보수하기에도 마이크로서비스가 장점이 있다...?

단 조건. 애자일 정신을 가진 개발자들이 모여야만 가능하다. 월급 받은 만큼만 할거야 ...  또는 일에 대한 프라이드가 없다... 이런 식이면 놉

- 네이버 관련 재밌는 기사: 벤처를 지향해야 하는 회사인데 어느순간 직원들이 대기업 직원이 되었는지, 옥신각신이 많았다.

- 이거 하나 날아가면 통으로 날아갈 걱정 안해도 된다(15쪽 맨밑)

기말 문제 예: 마이크로서비스의 장단점 / 마이크로서비스 아키텍처가 장점을 가질 수 있는 프로젝트와 단점 "~ 기술하시오.

- 17: 오른쪽 그림은 잘 보면 객체지향 구조랑 비슷하다. 객체지향이란 것이 재사용과 재사용된 애들 간의 인디펜던트, 그러기 위해 우리가 어떤 식으로든 퍼블릭 인터페이스를 잘 정리해야 하는, 그래서 클래스와 클래스 안에 서로 영향을 주고받는 점이 없도록 퍼블릭 인터페이스를 한번 바꾸면 바꾸지 않는... 이런 것처럼 사실 디지털 맥락에서 마이크로서비스들이 무엇이 필요하고 그들 간 관계는 어떻게 정립해야 할지 그런 부분들에 대한 디자인 관점에서의 공부는 좀더 있어야 한다. 문서는 줄어도 고민은 늘어야.

 

3. YouTube 서비스를 위해서는 매우 많은 Software 기능이 필요할 것으로 예상할 수 있다. YouTube 서비스를 Microservice 개념으로 구현한다는 것이 무엇인지 설명하시오.

 

 

 

5. Docker의 Container와 Kubernetes의 Pod의 유사점과 차이점을 설명하시오.

[수: nodes and pods]

노드는 도커 머신에 상응하는구나 하는 걸 알게될 것임

컨테이너 하나하나가 의미를 가지는 것보다 더 상위의 개념을 정의했고 그게 팟. 이 리딩 아티클 무저건 읽어야.

쿠버네티스가 너무 길어서 'k8s'라고 줄여서 쓴다고 함

컨테이너 모여 팟, 팟이 노드 위에서 동작, 노드가 모여 클러스터 구축

복수의 이미지를 통해 복수의 컨테이너를 만드는 것은 스웜.

6: 컨테이너는 거대한 어플리케이션에 비하면 너무 작은 최소 단위가 된다. 그래서 생각해낸 것이 쿠버네티스의 팟이라는 아이디어다!

7: 팟을 모두 모아 프론트엔드라고 한다.

프론트, 데이터 로직, 백 이 셋이 각각 하나의 컨테이너고 셋이 통신하면 좋지만, 그러기엔 컨테이너가 너무 작고, 프론트 처리, 데이터 처리, 백 처리하는 애들을 하나로 묶어 우리는 팟이라고 부른다. 다만 여기에 컨테이너가 1~n개 들어갈 수 있는 것. 팟을 구현하기 위해 컨테이너가 존재!

8: 데복스 입장에선 컨테이너보다 팟이 더 유의미.

스토리지가 필요하면 이들을 하나로 묶음. 그리고 얘네는 하나의 네트워크 ip address 안에 속해있다! (강의자료)

로컬 호스트로 자신들 호출 가능

9: ip address 하나를 공유한다고 했는데..응? 9쪽은 반대 내용 나오는데? 각 팟은 유니크한 아이피 주소를 가진다..?

대신 하나의 운영체제를 공유함. 각각은 서로 다른 네트워크 포트를 가짐

각각에게 아이피를 할당하고 그 포트를 열어주어야만 했던 도커에서의 개념보다 수월해짐

머신 안의 프로그램이 본인 안의 프로그램으로 접속할 때 로컬 호스트 썼었다.

하나의 아이피를 공유하되 포트 번호는 서로 다르고, 큰 팟 안의 컨테이너끼리는 서로 통신하므로 로컬호스트 포트 넘버만 주면 된다.

팟 투 팟으로는 ip 주소를 공유할 필요가 있다! 로컬 호스트의 포트 넘버 만으로 접속 가능하므로 좀더 유의미한 애들은 어찌보면 좀더 수월하고 편리하게 통신 가능. 동일 호스트 위에 여러 프로세스가 떠있되 걔네끼리 원활하고 쉽게 통신하는 개념과 비슷.

10: 노드는 도커 머신에 상응한다. 노드는 왼쪽 그림의 여러 컴같은 것을 의미한다.

그 노드는 가상ㅁ ㅓ신, 실제 물리적 컴/머신 일수도. 혼용도 가능

쿠버네티스 위에서 노드들을 돌릴 건데 ...

 

도커 쪽은 라벨이 약하지만 쿠버 쪽은 라벨 많이 쓴다 이 팟들을 관리, 구분

이때 주로 사용하는 명령은 kubectl

하나의 쿠버네티스 안에서는 매우 다양한 ~가 돌고 있다. 쿠블렛, 쿠베프록시 등

12: 노드들의 모음이 클러스터. 여기에 붙는 애들의 cpu 능력이 늘수록 클러스터의 용량은 올라간다.

13: 여기에 당연히 스토리지가 붙을 것.

14: 팟, 노드, 클러스터에서 디파인하는데

팟이 인터넷에 직접 노출되는 환경은 일반적이지 않다. 두번째 항목에 나와있음

- 어느 노드에 무슨 팟이 들어가야하는지 스케줄링

- 계속 모니터링하다가 팟들에 문제가 발생해서 죽는 애가 생기면 살리는 것 가능, 스케일링 업다운, 업글 문제 등 보다 풍부한 기능을 도커보다 훨씬 더 풍부, 안정적으로 제공할 것이다.

15: 노드, 클러스터는 작업이 이뤄지기 위한 운동장이요 그 위에 이루는 작업을 팟이라 한다 이야기했다면 좀더 고차원적으로 한단계 올라갈 것. 주의! 여기서 deployment는 배포 아니고 "(어플리케이션의) 실행"을 의미한다. 실행을 직접 하는게 아니고 그걸 부탁하는 거라고 바꿔 생각할 것임

쿠버네티스를 들어왔을 땐 우리가 부탁하는 것. 이렇게 되길 부탁한다.

프로그래머가 얌파일에 기술했던 것을 이제 desired state라고 부른다. 쿠버에게 시킨게 아니고 부탁한 것.

이런 인프라를 희망한다는 의미. 쿠버는 이걸 만들고 유지한다.

 

나아중에 한번 더 들으면서 추가 필기: 팟이 몇개 필요한지, 어떤 팟이 동작해야하고, 그 팟이 몇개가 필요해야지 내가 원하는 일을 할 수 있다고 판단한 상태다. 이런 비슷한걸 우린 도커 컴포즈 야믈 파일에서 했고, 이에 상응하는 개념이 요 deployment인 것.

 

16: 죽은 애를 딴데다가 새롭게 만들어서 유지해주는 기능이 있다. 그게 두번째 항목에 나온 내용. 이게 배포 컨트롤러!

쿠버는 단일 프로그램이 아닌 다양하고 풍부한 기능을 수행하는 프로그램의 연합체

도커 쪽에선 run이란 커맨드를 많이 썼다면 쿠버는 create 란걸 많이 사용! desired state를 쿠버에 전달해서 이걸 만들어달라고 부탁하는 것.

17: 비지박스는 임베디드에 주로 쓰인다.

19: 퍼블릭 인터넷에 대응되지 않는 컨셉이란? 고객의 요청은 클러스터에 들어온다. 따라서 외부 요청은 클러스터에 있는 것이 맞다.

20: http 프로토콜로 접속하면 포트에서 정보를 받아 이 정보에 기반해 안쪽으로 전달해줌(똘똘한 기능)

그리고 로드밸런싱! 4개의 로드를 보고 균등하게 분배하는 그런 기능들도 입구인 포트(번호)의 역할

ssl: security를 지원하는 기능, 그래서 암호화하고 암호를 푸는 통신 방식인데 이에 대해 입구 역할을 해주면서 암호를 풀 수 있음.

그래서 이 서비스에 접속하는 사람들이 암호화된 트래픽을 여기 다 갖다 놓으면 여기서 풀어서 받을 애들을 처리해 전달하는 역할을 한다.

버추얼 호스팅: 한대의 컴이 2개 이상의 도메인혹은 웹주소를 갖고 있는 것. 똘똘한 기능을 하는 것도 제공된다.

따라서 서비스를 만들고 유지, 관리하는 부분들도 잘해주지만 외부에 ?석??? ?서버?? 와 관련된 기능들도 잘 제공해준다.

 

22:

lshw: 리스트 하드웨어란 명령.

df -h: 디스크 공간 보여주는 명령!

cat /etc/os-release 는 여러 파일 내용을 나에게 보여줘

***LTS는 유지보수가 계속해서 이뤄지고 있다는 의미

hostnamectl 현재 동작중인 호스트 컴의 이름

uname --all: 운체 관련정보까지 자세히 나옴

 

23:

kubectl get all: 몽땅다 보여라

 

26: 한꺼번에 하는 명령

 

27:

1. 상호 서비스에 대한 명령 보고

2. 외부에서 접속할 수 있도록 연다

3. 실제로 콜