Lab 1 MapReduce

Wed, 02 Sep 2026 09:56:08 +0900

Go 언어로 MapReduce의 논문 내용을 구현해보자. 아래 내용은 실시간성 시행착오

…일단 제일 큰 이슈. 뭐부터 해야하지?
- 먼저 rpc.go에서 요청/응답 형태를 만들고, 응답이 왔을때 Map작업을 하는거까지부터 만들어보자.
  - 여기서 ExampleArgs가 있어서 찾아보니까, 요청/응답을 Args, Reply로 하는게 관례인 것 같다.
  - 따라서 우리도 TaskArgs, TaskReply 로 해볼까?
  - 일단 TaskReply에서, 무슨 정보가 필요할까?
    - 어떤 작업인지 알려줘야하고 (Map or Reduce)
      - 여기서 파이선 enum같은게 가능할까? 두 string중 하나로 정리하고싶은데. 아니면 bool로 할까?
    - 어떤 입력파일을 처리해야할지 알려줘야 하고
      - 이건 Map, Reduce 둘다 작업 번호로 처리할 수 있을 것 같다
    - 이 두가지면 될거같은데?
- 이후 worker.go에서 이를 받아줘야할 것 같다.
  - CallExample이 예시로 있으니, 우리도 CallTask로 이름짓고 하면 될듯
- 아 이게 다 붙어있네. CallTask는 coordinator.go에서 잘 반환해줘야하는데..
  - Coordinator struct에서 Task의 개수와 어디까지 보냈는지같은걸 잘 관리해야겠다
실제로 실행하면서 한번 해보자.
- go run mrcoordinator.go sock123 pg-*.txt 로 코디네이터를 만들면
  - coordinator.go 의 MakeCoordinator 이 호출되고,
- go run mrworker.go wc.so sock123 로 워커를 만들면
  - worker.go의 Worker 함수가 호출된다.
  - 구조를 보니 map, reduce 함수는 만들어져있다.
- 두 함수를 잘 채워주자!
- 일단 동시성 없이, Map요청을 우선으로 응답하고 Reduce연산을 응답하는 구조를 만들었다.
이제 작업을 붙여야한다.
- 지금 하다보니, ExampleReply에서 filename도 필요할 것 같다.
- 이후 mrsequential.go에서 하는것과 같이 file을 읽어들여서 mapf 함수를 먹이면, 다음과 같이 잘 수행됨을 확인할 수 있다!
이제 이 결과를 nReduce개의 중간 파일에 저장하자.
- 아잇;; NReduce도 RPC에서 전달받아야했다.
- 잘 데려와서 진행하면, 중간 버킷을 이용해서 위와 같이 mr-M-R 파일명으로 모두 저장해줄 수 있다!
Reduce 함수도 같은 방식으로 만들어주면 된다.
- 깔끔하게 10개의 out파일이 잘 나온다!
이제 자랑스럽게 make mr을 돌려보면, 다음과같은 오류들을 볼 수 있다.

WARNING: DATA RACE
Read at 0x00c00013f1f0 by main goroutine:
 6.5840/mr.(*Coordinator).Done()

이는 채점 환경이 Worker을 3개 돌리는 고루틴 환경이기 때문!
- 우리는 이제 동시성도 제어해야한다.
- mutex같은걸로 보호하면서 수행해보자.
- 뭘 보호해야하지?
- DATA RACE가 나는 상황을 보면, TaskRPC에서 Coordinator을 참조할때 문제가 생기는 것 같다.
  - 따라서 TaskRPC 하나가 돌동안 잠궈주면 되지 않을까?
- 여기까지 잘 하면 --- PASS: TestWc (7.95s) 를 일단 받을 수 있었다!
이제 문제는 실패한 태스트 혹은 할당의 문제..
- 현재 구조에서는 한번 보낸 태스크들은 모두 버그없이 완료되었다고 생각한다.
  - Midx정도로만 관리했기 때문
- 이제 현재 업무가 어떤 상태인지도 정의해야할 것 같은데..
  - 두가지 아이디어가 생각난다.
    - 첫번째는 배열/슬라이스로, $[M_1, M_2, M_3, ..., M_{m-1}, M_M]$ 에 대해 각 $(0, 1, 2)$ 같은 값을 부여해서, 할당 없음 / 작업중 / 작업 완료 세가지로 나누는 것이다!
    - 두번째는 set.. 이지만 Go에는 없으므로 map같은걸로 위의 세가지 그룹에 대한 집합을 관리하는 것이다.
  - 뭐가됐든 RPC는 하나가 더 필요할 것 같다. 성공을 관리하는거!
  - 그리고 set은 어떻게 구현할지 바로 생각이 안나니까 일단 슬라이스로 시작해보자.
슬라이스로 관리하고, 함수 하나를 정의해야해서 일이 있으면 해당 인덱스, 할일은 없지만 작업중인 일이 남아있으면 -1, 모든 일이 끝났으면 -2를 반환하도록 하였다.
- 추가적으로 실수가 있었던 kv레코드 / json인코딩 저장 방식까지 수정하니까 (공식 가이드에있었음) 다음과 같이 꽤 좋은 결과를 얻을 수 있었다!

=== RUN TestWc
--- PASS: TestWc (10.08s)
=== RUN TestIndexer
--- PASS: TestIndexer (5.87s)
=== RUN TestMapParallel
--- PASS: TestMapParallel (8.04s)
=== RUN TestReduceParallel
--- PASS: TestReduceParallel (10.05s)
=== RUN TestJobCount
--- PASS: TestJobCount (12.06s)
=== RUN TestEarlyExit
cmp: EOF on mr-wc-initial.txt
 util.go:163: reduce output changed: mr-wc-initial.txt vs mr-wc-final.txt
--- FAIL: TestEarlyExit (7.05s)
=== RUN TestCrashWorker
^Csignal: interrupt
FAIL 6.5840/mr 263.011s
make: *** [mr] Error 1

아마도 EarlyExit, CrashWorker 둘다 이름에서 알 수 있다시피 내결함성에 관한걸 테스트해야할 것 같다.
- 만약에 worker이 일을 물고 죽었다면? 어떡하지? 같은거지.
- 이것도 사이트를 보면 10초정도 후에 백업 태스크가 살아야한다고 알려준다. 이를 구현해보자.
저걸 해서 CrashWorker까진 고쳤지만 EarlyExit이 안돈다! 이게 무슨 일일까?
- EarlyExit은 worker가 Task를 받자마자 죽어버리는거같은 일이다.
  - 그런데 아예 죽지 않고 살아있다면?
  - 그래서 동시에 두 Worker이 같은 일을 하고있어서, os.Create를 같이 써버린다면?
    - 분명 내용이 유실되겠지!
- 그렇다면, 임시파일에 쭈루룩 쓰다가 모두 쓴 다음에 os.Rename같은걸 이용해보자.
  - 이거 문제가 아닌데..
아니;; 다른 원인을 찾다보니 Reduce 작업에서 조금 실수해서 완료처리를 잘못하고 있었다.
- 이걸 고치고 깔끔하게 완료!
고친후에 깔끔히 만점!

알게된 사실들

struct 내부의 메서드를 대문자로 시작하지 않으면 다른데서 접근조차 안된다! 저장부터 안들어가는듯
Mutex Lock를 걸면 자동으로 해당 데이터에 대한 접근을 막는게 아니라, 다음 Mutex의 Lock까지를 대기한다.
- 따라서 쓰기에서만 Lock을 걸면 안되고, 읽을때도 하나하나 다 걸어줘야한다!
함수 func1이 함수 func2를 호출하는 경우, 그리고 둘다 c를 사용한다고 생각해보자.
- 이때 둘다 Mutex Lock을 걸어버리면, Deadlock이 발생한다.
- 따라서, 이럴때는 내부 헬퍼함수같은 느낌으로 진행할 수 있겠다.
  - 이때 헬퍼함수는 뒤에 Locked같은 접미사를 붙이는게 관례라고 한다.
공식 가이드에도 있는 내용인데, json으로 저장하기 위해선 k-v 텍스트 레코드대신 json 인코딩된 레코드로 저장하는게 좋다고 한다. 왜지?
- 텍스트 포맷은 구분자에 의존한다 (개행)
- 그런데 Key나 Value에 이미 그런 구분자가 들어있다면?
  - 따라서 json형태로 저장하면 훨씬 안전하다!

MIT 6.5840 Distributed_Systems on Jiho Kim

Lab 1 MapReduce

알게된 사실들