CStory

PyToch Basic 우선 파이토치에서는 Tensor의 구조를 사용한다. 그리고 numpy 기능들을 거의 다 지원한다. Tensor numpy의 ndarray와 비슷하다. import torch t_array = torch.FloatTensor(n_array) 이외의 Data to Tensor, ndarray to tensor방법 등이 있다. GPU 사용 ~.device를 하면 cpu인지 gpu 사용중인지 알 수 있다. if torch.cuda.is_available(): data_cuda = data.to('cuda') data_cuda.device 위의 코드로 gpu사용 가능하면 gpu로 바꾸도 아니라면 cpu를 그대로 출력한다. Tensor Handling view reshape과 비슷하고 ten..

파이토치와 Tensorflow차이 팀플하다 보면 파이토치를 쓸지 텐서플로우를 쓸지 정하는데, 나는 파이토치를 주장하는 편이다. 사실 그 이유는 최근에 자주 사용하는 게 파이토치여서 그렇긴 한데😂 그러면 꼭 둘이 뭐가 다르냐는 질문을 받는다. 그럴 때 답변하기 위한 포스팅이라고 할 수 있다.😎 DCG(Dynamic Computational Graph) Backward에서 자동미분할때 실행시점에서 그래프를 정의하는 방법이다. Define and run 말 그래도 정의하고 실행하는 것이다. 그래프를 먼저 정의 → 실행시점에 데이터를 feed한다. TF, Pytorch Pytorch는 Define by run(DCG)를 사용하여 실행하면서 그래프를 생성하고 Tensorflow는 Define and run으로 실..

가끔 내가 짠 코드도 아닌데 에러 났다고 하고... 그냥 다른 거 하나 고쳐봤는데 디버깅이 되는 어이없는 상황들을 마주하기 쉽다. 이번 포스팅은 그 늪에서 탈출하기 위한 방법들이다. Troubleshooting OOM (Out-Of-Memory) 이런 문제는 왜 발생했는지, 어디서 발생했는지 알기 어렵다... Error backtracking이 이상한데로 갈 때도 있고 메모리 이전 상황을 파악하기도 어렵다. 그러면 이런 문제들은 어떻게 해결할까? 가장 기본적인 방법으로는 Batch Size 줄이고 ⇒ GPU clean ⇒ RUN GPU Util 사용하기 nvidia-smi 처럼 GPU의 상태를 보여주는 모듈이다. Colab 환경에서 GPU상태 보기 편하다. Iter마다 메모리가 늘어나는지 확인할 수 있다..

도커란? 도커를 소개하기 전에 먼저 가상화란 개념이 필요하다. 가상화 등장 배경 개발할 때, 서스 운영에 사용하는 서버에 직접 들어가서 개발하지 않는다. Local환경에서 개발하고 완려되면 Staging서버, Production 서버에 배포한다. 개발을 진행한 local 환경과 Production 서버 환경이 다른 경우가 존재한다. 예를 들면 로컬은 윈도운, 서버는 리눅스일 때이다. 또한 로컬 환경과 서버가 같은 OS여도, 환경변수 등에 의해 서버에 올바르게 작동하지 않을 수 있다. 그래서 다양한 설정들을 README 등에 기록하고 항상 실행하도록 한다. 여기서 만약 운영하고 있는 서버가 많다면, 이 중 하나의 서버가 업데이터 되었다면 나머지 서버도 모두 업데이트를 해줘야한다. 이런 상황에서 서버 환경까..

HDFS 명령어 모음 대부분 리눅스 command와 비슷해서 큰 설명없이도 이해가 쉬웠다. Dir, File 조회 ls hdfs dfs -ls / 파일 출력 lsr hdfs dfs -lsr / 하위 디렉토리 포함하여 파일 출력 du hdfs dfs -du -h / 파일 용량을 확인, h는 사람이 보기 편하게 만들어주는 것이다. hdfs dfs -du -h -s / s 를 붙이면 summary 용량을 확인할 수 있다. cat hdfs dfs -cat filename 파일 내용 출력 text hdfs dfs -text filename 파일 내용 출력하며 압축된 형태도 가능 mkdir hdfs dfs -mkdir dirname dir 생성 head, tail hdfs dfs -head filename hdfs..

Fair Call Queue Client의 요청을 담아놓는 Queue이다. heavy한 클라이언트로 인해 전체 요청의 처리가 늦어지지 않도록 하기 위해 만들어졌다. 이전 방식 FIFO Queue Fair call queue가 도입되기 전에는 FIFO방식의 큐를 사용하였다. 하지만 이러한 방식은 heavy user로 인해 전체 응답 속도를 느리게 만들었다. 그리고 high load를 발생시키면 전체 시스템에 과부하가 걸려 분산 서비스에 대한 공격이 가능하기에 DDoS방식으로 공격이 가능하다. Fair Call Queue 구성 multi-level queue가 multiplxer와 scheduler로 연결되어있다. RPC Scheduler Listen queue에 RPC요청이 도착하면 reader threa..

Data Fault Tolerance 하둡은 fault tolerance를 위해 SW로 복제본을 만들고 다른 머신, 다른 렉, 다른 데이터 센터로 분산 시킨다. HW로는 RAID 구성을 두어 fault tolerance를 더욱 높인다. RAID RAID는 Redundant Array of Inexpensive Disks를 말한다. 하드 디스크를 여러 개 독립적인 드라이브의 배열로 가상화하는 방식이다. 이를 통해 performance 뿐만 아니라 capacity, reliability를 개선할 수 있다. RAID 0 RAID 0은 데이터를 블럭단위로 나누고 전체 데이터 영역에 array로 분포하도록 나누는 방식이다. Drive 개수 만큼 동시에 read, write가 가능하여 속도가 빠르다. storage..

Observer Name Node 이전 포스팅 내용처럼 2024.01.08 - [Data Engineering/Hadoop] - Hadoop의 High Availability (고가용성) 아키텍처 Hadoop의 High Availability (고가용성) 아키텍처 Name node의 HA 하둡의 버전 1까지는 namenode는 SPOF(Single Point Of Failure)였다. datanode는 수평적 확장이 가능했지만, namenode는 하나의 인스턴스를 유지해야했으며 이 namenode가 이용불가능 해지면 클러스터 cstory-bo.tistory.com 여러 HA Architecture를 통해서 HA는 달성했지만 여전히 active namenode에 부하를 주는 문제가 발생한다. 이 부하를 해..

Name node의 HA 하둡의 버전 1까지는 namenode는 SPOF(Single Point Of Failure)였다. datanode는 수평적 확장이 가능했지만, namenode는 하나의 인스턴스를 유지해야했으며 이 namenode가 이용불가능 해지면 클러스터 전체가 이용 불가하다. HA Architecture 위의 그림처럼 Active, Stanby 2개의 상태 namenode를 두어서 SPOF 문제를 해결했다. active namenode가 다운되면, standby namenode가 승격되어 downtime을 최소화한다. 또한 stanby namenode는 backup namenode 역할도 수행한다. 이처럼 namenode가 예상치 못한 장애에 대해서 자동화된 failover를 수행할 수 있으..

Name node & Data node Name Node Name node는 블럭의 위치, 권한 등의 메타 데이터를 가진다. 기본적으로 메모리에 메타데이터를 저장하고 2가지 종류의 파일로도 기록한다. 1. Fsimage : File System Image로 네임노드 생성 이후부터 namespace 정보를 모두 가지고 있다. 2. Edit log : Fsimage로부터 현재까지의 변경사항 로그이다. 이제는 Name node의 기능을 알아보자. Metadata Management 파일 시스템을 유지하기 위한 메타데이터를 관리한다. 파일 시스템 이미지(파일명, 디렉토리, 사이즈, 권한 정보)와 파일에 대한 블럭 매핑 정보를 가지고 있으며 빠르게 응답해야 하기 때문에 메모리에서 관리한다. File System ..