학습주제

학습내용

얀의 동작방식을 조금 더 알아보고, 하둡 버전간의 차이점에 대해 요약해본다.

맵리듀스라는 분산 컴퓨팅 시스템이 있는게 아니라
굉장히 범용적인 얀 위에 새로운 분산 처리시스템을 만들수 있게 구조가 바뀜.

얀을 보면
맵리듀스와 구조가 크게 다르지 않음. 그러나 맵리듀스만 지원하는게 아니라 범용적임.
마스터에 해당하는 리소스 매니저. 슬레이브는 노드 매니저. 노드 매니저는 리소스 매니저의 요구에 따라 갖고있는 자원을 넘겨줌
자원은? 보통 컨테이너라 부름. 자바 관점에서 보면 JVM이라고 보면 됨.

노드 매니저의 컨테이너와 자바의 JVM이 비교되는 것은 그들의 '실행 환경'을 제공하는 기능 때문입니다. 이 두 시스템 모두 실행할 프로그램이나 프로세스를 위한 독립적인 환경을 제공하며, 이는 애플리케이션 간의 충돌을 방지하고 특정 프로세스의 실행에 필요한 자원을 관리하는 데 도움을 줍니다.
반면에, 하둡 YARN의 노드 매니저에서는 컨테이너라는 개념을 사용합니다. YARN(Yet Another Resource Negotiator)의 컨테이너는 애플리케이션의 실행을 위한 리소스(CPU, 메모리 등) 할당 단위입니다. 노드 매니저는 클러스터의 각 노드에서 컨테이너를 생성하고 관리하며, 각 컨테이너는 애플리케이션의 일부분을 독립적으로 실행할 수 있는 환경을 제공합니다.
따라서 둘 다 '실행 환경'을 제공하는 것은 동일하지만, 사용되는 컨텍스트와 특징이 다릅니다. JVM은 자바 프로그램의 실행을 위한 환경을 제공하는 반면, YARN의 컨테이너는 하둡 기반의 분산처리 작업을 위한 환경을 제공합니다.

컨테이너 중에 특별한 컨테이너를 앱 마스터라고 함. 그냥 특별한 형태의 컨테이너라고 생각.

얀은 범용 컴퓨팅 프레임워크
리소스 매니저 - 잡스케줄러, 애플리케이션 매니저라는 데몬 존재

데몬은 컴퓨터에서 백그라운드로 실행되는 프로그램을 말합니다. 보통 사용자의 직접적인 조작 없이 자동으로 실행되며, 서버, 네트워크 요청 처리, 시스템 모니터링, 로그 파일 관리 등 다양한 작업을 수행하는데 사용됩니다.

노드 매니저 - 슬레이브 마다 설치. 리소스 관리. 리소스는 컨테이너. 다수의 컨테이너가 하나의 노드매니저에 있을 수 있음. 자바에서 얘기하는 JVM임 컨테이너는. 컨테이너는 두종류 프로세스 지원. 앱 마스터, 태스크.

굉장히 많은 새로운 데몬들을 설명했음. 어떻게 동작하는지는 뒤에서 설명.
얀처럼 새롭게 소개가 됨 범용 컴퓨팅 프레임 워크 위에서 맵 리듀스가 만들어짐. 더 범용화

얀의 동작

데몬들

클러스터(Cluster): 컴퓨팅에서 클러스터는 여러 대의 컴퓨터(노드)가 네트워크를 통해 연결되어 하나의 시스템처럼 동작하는 것을 말합니다. 이러한 클러스터는 많은 양의 데이터를 처리하거나 복잡한 연산을 수행하는 데 사용됩니다. 하둡 YARN에서 클러스터는 여러 노드로 구성되며, 각 노드는 자체적으로 데이터를 처리할 수 있습니다. 클러스터 내에서 노드 매니저(Node Manager)는 각 노드에서 실행되며, 리소스 매니저(Resource Manager)는 클러스터 전체의 리소스를 관리합니다.
컨테이너(Container): 하둡 YARN에서 컨테이너는 애플리케이션의 실행을 위한 리소스(CPU, 메모리 등) 할당 단위입니다. 즉, YARN은 애플리케이션의 요청에 따라 필요한 리소스를 컨테이너라는 단위로 할당하고, 각 컨테이너는 해당 리소스 내에서 작업을 수행합니다. 노드 매니저는 각 노드에서 이러한 컨테이너를 생성하고 관리하며, 리소스 매니저는 클러스터 전체의 컨테이너 할당 및 관리를 담당합니다.

얀에게 어떤 애플리케이션을 실행시키고 싶은 클라이언트가 있다.
이 클라이언트가 코드, 환경 설정 정보를 리소스 매니저에게 넘김.
리소스 매니저의 첫번째 역할은 지금 실행하려고 하는 애플리케이션의 마스터를 만드는 것.
애플리케이션 마스터는 노드 매니저 안의 컨테이너에서 실행이 됨. 다수의 노드 매니저가 있을텐데, 비는 노드 매니저를 임의로 골라서 노드 매니저에게 니가 갖는 컨테이너 하나 달라고 요청. 요청을 받아 이 컨테이너 안에 방금 클라이언트가 제출했던 애플리케이션의 마스터 역할을 할 프로그램을 실행시킴. 애플리케이션 마스터는? 얀 클라이언트가 실행시킨 앱의 주인역할. 얀 클러스터 안에는 얀 앱 수만큼의 앱 마스터가 컨테이너 안에서 돌고 있음.
이 앱 마스터는 방금 클라이언트가 제출한 코드를 실행하기 위해, 필요한 만큼의 자원을 리소스 매니저에게 요청. 리소스는 컨테이너들. 컨테이너들은 JVM이고 JVM들은 메모리라든지 할당되는 리소스가 있음. 리소스를 할당 받으면 그 숫자만큼 컨테이너가 하나의 노드 매니저 혹은 다수의 노드매니저에 할당. 할당받은 컨테이너 안에 클라이언트가 제출했던 실제 코드들을 돌리는 태스크를 만듦. 얀 애플리케이션은 이렇게 동작. 컨테이너 안의 태스크들은 애플리케이션 마스터에게 리포트 함 (하트 비트) 얀 앱은 데이터는 어디에? HDFS에 있다고 가정. 그 관점에선 1.0과 다르지 않음. 얀 앱은 맵리듀스, 스파크 같은게 애플리케이션이라 했음. 클라이언트를 결국 맵 리듀스일 수도 있고 스파크일수도 있음. 얀 위에서 동작을 하면 위와 같은 동작을 거쳐, 분산 컴퓨팅 시스템을 구현하고 운영을 함.

얀의 동작을 글로 설명.
얀 클라이언트가 얀 위에서 실행하고 싶은 앱의 코드, 환경정보를 리소스 매니저에게 넘김. 이때 실행하려는 파일들, 코드파일들 정보들은 HDFS폴더에 미리 로딩이 되어 있어야 함. 아무 폴더에 로딩은 아니고, 클라이언트게 RM에게 ID를 받아서 그 ID에 해당하는 HDFS 폴더에 있어야 함.
RM가 코드를 받았고 실행에 필요한 환경정보를 알기에 어느 정도의 리소스가 필요한지 알음. 얀 앱마다 마스터를 하나씩 구축해야하기에 마스터 역할을 할 앱 마스터를 실행하려고 함. 이게 결국 노드 매니저 안의 컨테이너에서 실행되기 때문에, 돌고 있는 컨테이너를 골라서 달라고 하고 그 컨테이너 안에 방금 얀 앱의 앱 마스터를 실행시킴. 앱 마스터가 방금 제출된 얀 앱을 실행함. 앱 마스터는 필요한 리소스를 알기에 RM에게 리소스 요청, RM은 리소스를 주면 그 리소스를 어느 NM에게 받아내야하는지 알음. 필요한 만큼 컨테이너를 받아서 안에 태스크들을 실행시킴. 태스크들은 자기의 상태를 앱 마스터에게 보고 (하트 비트) 자기가 맡은 태스크 상황을 알려줌. 만일 어떤 태스크가 오랫동안 보고가 없거나 테스트가 에러를 리포팅하면 앱 마스터는 해당 태스크를 대신할 컨테이너를 RM으로 부터 받아서 그 안에 태스크를 실행시킴. Fault tolerance를 보장시킴.

하둡 버전간의 차이점을 요약해본다.
1.0, 2.0 차이는 간략하게 설명.
HDFS 위에 분산처리 시스템인 맵리듀스 하나밖에 없음.

2.0에서 플렉서블한 컴퓨팅 프레임워크 필요 느낌. 좀 더 범용적인 리소스 매니지먼트 시스템 만들고 그 위에서 개발자들이 원하는 분산처리 시스템을 만들어 보자.
네임 노드의 이중화가 구성된 HDFS2.0 위에 얀이라는 하둡 클러스터에 소속된 서버들의 리소스를 통합 관리 RM이 있고 그 위에 맵리듀스등이 있는 세개의 레이어로 구성. 이런 컴퓨팅 프레임워크 중 하나가 SPARK을 우리가 배움

3.0은 얀 2.0을 사용함
얀 1.0과 2.0 차이는?
얀 프로그램들을 논리적인 그룹 (플로우)로 나눠 같은 그룹에 속한 얀 앱들이 얼마나 자원을 쓰고 있는지 확인할 수 있고, 그 안에서만 자원 분배. 얀이 다용도로 사용될 때 비슷한 목적의 앱끼리 리소스를 공유하게 함. 리소스 관리측면에서 지금 하둡 클러스터의 예를 보면 5할을 배치에, 3할을 스트리밍 2할은 데이터 서빙하는데 써라. 라고 앱의 용도에 맞게 자원을 나눌 수가 있음. 타임라인 서버가 있는데, 얀에서 발생하는 다양한 이벤트를 기록하는 서버. 이 서버에서 쓰는 기본 스토리지는 HBase, 하둡2.1부터 사용. HBase 전에는 섭머린이라는 걸 씀.
파일 시스템 변화는
네임노드의 경우 스탠바이 네임노드 지원이 1대만이었음. 3.0부터는 다수의 스탠바이 노드 지원.
하둡에서 만들어진 HDFS와 호환되는 스토리지로 S3가 지원되기 시작했는데, 3.0부터 애저 데이터레이크 지원.