[Thinksink] SE 가 갖춰야 할 기술력은 어느정도? (2)

본 글은 스스로에게 어디까지 기술력을 보유해야 한다고 생각하는 건지 자문하는 글로써,
정리되지 않던 글들은 다시 정리하여 공개합니다. 문제가 되는 부분들은 언제든지 얘기해 주십시오.

어느정도 진행되는 동안 R 사의 GSS 에서는 고객의 의문사항들을 어느정도 답변 해 주고 있던 상태..

고객의 심도있던 Thread 와 메모리의 상관관계, VM split 모델에 대한 심도깊은 관계 (spilt 등 )

최대 스레드 값을 계산 할 수 있는 공식, Lowmempage 부족의 의미, Lowmem 부족상태에서

swap 이 사용되지 않는 경우, cache memory  와 swap 의 관계, 메모리 관리 ( linux-mm ) 알고리즘,

2.4 커널과 2.6 커널의 차이점 ( 나름 상세하게 - 메모리 관리에서부터 쭈~~~욱 )

paging 매카니즘 등등... 거의 세미나수준으로이지 않나 싶게..

GSS 에서는 나에게 전화로 혹시 세미나하는거냐고 매우 지원하는데 깊은 심도로 인해 어려움이 있었다고

난이도와 난감함을 우스개소리로 했을 정도.....ㅠㅠ

엔지니어레벨에서는 이해를 하겠으나 설명하기는 난감한 상황 발생...

어찌됐든 현재는 장애 재현이 강제로는 발생하지 않는 상황에 돌입하여버린것이다.

이 문제를 해결하기 위하여 우리는 고객에게 각종 리눅스 인터널적인 매카니즘 및 알고리즘들과,

OS 의 문제가 아님을 판명하려 노력해야 했다. ( 머리터지는줄 알았.... )

이런 이슈들로 인해 물론 나역시 많은걸 보고 배우며 생각하게 되긴 했는데,

이과정을 겪으면서 이상적으로 자문하게 되는 부분은

과연 SE 가 해결해 줄 수 있어야 하는 범위는 어디까지 인것일까? 라는 것...

고객은 Oops 커널이나, 커널 디버깅 모드를 설정하거나, 또는 빌드를 새로 하더라도,

커널 내부 메시지들을 로그 찍어 적극적인 해결을 요구하는 상황도 있을 수 있고...
( R 사에서는 커널이 수정되거나 개별 빌드하게 되면 지원이 중단된다 )

RHEL3 의 EOS 가 올 10월로 정해진 마당에, 계속 지원하는 엔지니어로써는 솔직히 환장할 일인 것이다.

인터널에 대해 궁금해 하면 할 수록 이해하고 설명하기가 더 힘들다는 점 역시 어디까지 공부해야하는지...휴~

과연 SE 로써, 커널의 상세 매카니즘들에 완벽하게 알 고 있어야 할 필요가 있을까? 라는 생각이

주를 이뤘던 나였기에 더더욱 자문하게 되는 부분....

Lowmem 영역에 DMA 가 포함되는 그 이유까지 알아야 할 필요가 있을까?

Lowmem pagetable 이 0 일 경우 Highmem pagetable 을 이용한다 정도까지면 되지,

어떻게 얼마나 매핑이 되는지 과연 심각하게 파고 들어야만 하는 것인가??

1G/3G 스플릿에 적용받는 커널은 일반커널과, SMP 이고, 64 비트의 경우 스플릿이 없으며,

Hugemem 커널의 경우 4/4G split 를 알 정도면 되는 것인가?

왜 그렇게 되는건지는 몰라도 되는가??

VM 끼리 연결이 어떻게 되는지는..??

Stack 사이즈와 Threads 의 관계만 알면 되지, 왜 Stack size 가 Threads 와 관계를 갖는 건지

알아야 하지 않는가 ????

내 생각엔 모두 'No' 였다. 알아두면 좋지만 꼭 알아야 할 필요는 없다고 생각했다.

SA ( system architect ) 가 아니라 engineer 이지 않는가? 엔지니어의 최대 목적은,

적절한 효율을 낼 수 있는 것이라고 생각한다.

장애에 대한 대비를 항시 하고, 예측하며, 발생시에는 원인분석에 걸리는 시간을 계산하여,

적절하고 효율적인 대처를 통해 장애 처리를 하여 서비스를 재개시키고, 장애가 재현되지 않도록

하는 것이 SE 라고 생각한다.

고로 장애 발생시에는 가상화이므로, 멀쩡한 VM 에서 클론을 후다닥 떠서 서비스를 재개한뒤 (가상화의 장점!)

원인분석을 위해, 장애가 있던 VM 을 가지고 실제 서비스와 비슷한 상태를 만들어 놓고,

발생되는 정상적인 core dump 를 분석요청 하는 것 정도까지가,

실제 엔지니어레벨에서 충분한 지원범위 였지 않았나 싶은데..또 그것도 정하기가 애매하다는....

가상화 환경이니만큼 시스템 장애시 복구 및 관리 혹은 deploy 가 수월하니,

구글이나 다른 서비스업체들에서 하듯이 동일 시스템을 바로 박아넣어 동작시키면 되는것이라곤 생각되는데..

엔지니어는 서비스가 열심히 돌아가게 해주는게 본분이라면

그럼 SA 까지 바라본다면 어떻게 해야하는거지????

결론은 끝이 없이 나오지 않겠지만........고민되는 부분이다 정말...

리눅스의 커널은 방대하고 심오하다. 커널의 개발자들도 각 매카니즘의 동작 원리를 파악하고,

남에게 설명해 주기에는 더 어렵고도 더 어려운 일인것 같다.

무엇보다 누가 그 깊은 부분들을 다 이해할 수 있을까??

나도 최근 커널공부를 위해 여러가지 준비중인 상태에서도 이해가 잘 안가는 부분들이 많은데....

시스템 엔지니어로써의 가장 필요한 마인드가 무엇인지 생각해 볼 필요가 있었다...

난 어디까지 가야 하는건가?? 어디까지 가려고 하는 건가??