사례로 보는 인프라스트럭처 아키텍처 수강후기 (24.09.10)

[ TA 기술 관련 ]

일단 가장 먼저 TA란 그룹을 의미하며, 각 영역별로 담당자가 존재하였음을 알았습니다. 

(이전까진 한 명의 TA가 인프라 영역 아키텍쳐를 다 관리하는 줄만 알았습니다.)

 

TA가 현황 분석을 위해서 수행해야할 지표 및 목표에 대해 설명을 들었습니다.

 

사용량 분석 항목에서 분석 항목별로(하드웨어 구성 /미들웨어 성능의 적정성 / 미들웨어 운영의 적정성 / DB 구성 / 네트워크 환경분석 / 네트워크 운영 및 교육)

세부 분석 항목, 점검항목, 점검 방법을 배웠습니다. 

 

• 사용량 분석 항목 中 미들웨어 부분

특히 미들웨어 관련하여 아래와 같이 어떤 점검 항목이 있으며 점검방법에 대해 말씀해 주신 것이 기억에 남습니다.

분석항목세부 분석항목점검 항목점검방법

미들웨어  성능의 적정성	파라미터 설정의 적정성	미들웨어 관련 OS 파라미터가 적절하게 설정되어 있는가?	시스템 점검 명령어
		미들웨어 파라미터가 적절하게 설정되어 있는가?
	AP 성능 개선  절차의 적정성	AP 성능을 위한 서비스 응답시간 Log를 남기고 있는가?
		모니터링을 통해 지속적인 성능 개선 작업을 수행하고 있는가?
미들웨어 운영의 적정성	역할 및 정의의 적정성	미들웨어 담당자가 지정되어 있는가?	상세설계서 검토 담당자 역할 확인
		미들웨어 담당자의 역할 및 권한이 정의되어 있는가?
		운영자 지침서가 작성되어 있는가?
	개발/운영 환경 지원의 적정성	미들웨어 기동 및 중지에 대한 절차가 있는가?	상세 설계서 검토
		모듈 이관에 대한 절차가 있는가?
		각종 로그 파일 관리 방안은 있는가?

TA는 각 인프라영역별로 어떤 고민을하고 있는지 알게 되었으며, TA의 고충을 알 수 있었습니다.

예상했던 것보다 훨씬 더 꼼꼼해야하며, 넓은 시야로 전체 인프라를 보는 안목이 있어야할 것 같았습니다.

 

생각보다 상세설계서 역할이 매우 중요했는데, 상세설계서 중심으로 아키텍처를 설계해야 했고, 요구사항을 명확히 해서 벤더사에게 전달해야

오해가 생기지 않고 니즈를 충족할 수 있었습니다.

 

• 사용량 분석 방법

cpu 사용량 분석 방법을 배웠는데 그중에서도 가장 중요하시다고 강조 하신 부분입니다. 이론에서 얼핏들은 내용을 실제 업무에서 적용하여 분석하는데 쓰이니 신기하였습니다.

Run Queue size	Run Queue (RunQ) 상의 프로세스 수 CPU Util. 값과 비교하여 유용한 정보를 얻을 수 있으며 낮은 CPU Util과 높은 Run Queue size 값은 I/O 시스템 이상을 의심할 수 있음
Context Switch	Scheduler에 의해 실행 중인 프로세스를 바꿔주는 과정 너무 많은 프로세스가 CPU를 원하면 성능 저하를 야기하고 우선순위를 통하여 CPU 자원을 할당 CPU Util 수치와 비교하여 유용한 정보를 얻을 수 있으며 높은 CS 값은 CPU 자원부족을 의심할 수 있으나 업무 성격을 고려해야 함

 

• 사용량 분석결과 활용 방안

이 부분에서 최대 174회 full gc가 발생한 부분과 발생 원인, 해결방안을 설명들었는데, 

모든 인프라영역에서 검토를 해본 뒤에도 해결이 되지 않자full gc문제가 해결이 되지 않았고 원인은 실제로 서비스 양이 늘어났기때문이었습니다.

빨간 박스 영역을 보시면, 전년대비 업무 처리량이 늘었기에 WAS instance를 19GB에서 30G 증설하여 full gc에 따른 서비스 지연 현상을 개선하셨다고 하셨습니다.

 

이외에도 다른 사례로 증설 사례가 있었습니다.

 

[ TA 수행사례 ]

TA 수행사례로는, 목동센터 이전 프로젝트와 ICIS TR 프로젝트, KOS 스토리지 대개체 프로젝트를 들었습니다.

그 중 목동센터 이전 프로젝트 사례는 대규모 프로젝트인 만큼, 센터이전 사전 작업 수행 내역이 복잡했고

개발/운영 스토리지 분리와 스토리지 분리 구성도 역시..., 복잡하다 못해 이해하기 쉽지 않았습니다.

 

,

또 센터이전 사례를 들으면서, 이런 일도 TA가 계획하여 한다는 말씀에 놀랐습니다..

만약 센터이전을 하게 되면, 누구의 가이드하에 센터이전이 진행될까 궁금했었는데 이 복잡한 일을 진행하는 것이 TA이 몫임을 알게되었습니다..

이전 계획부터 이전 후 장비 하차하여 배치하는 것까지 상면 위치를 확인하였습니다.

데이터센터 이전하면 어떻게 장비들을 운반하며, 구별하는지 궁금하였는데 이게 다 수작업으로 포장하여 케이블 라벨까지 붙이는 것인 줄 몰랐으며,

src장비의 상면위치 / 케이블 용도 /호스트명/ 장비 slot port로 구분하여 개별 확인을 한 뒤, tgt 장비로 이전하는데 이것또한 TA몫이었음을..알게되었습니다.

[ TA 기술 관련 ]

일단 가장 먼저 TA란 그룹을 의미하며, 각 영역별로 담당자가 존재하였음을 알았습니다. 

(이전까진 한 명의 TA가 인프라 영역 아키텍쳐를 다 관리하는 줄만 알았습니다.)

 

TA가 현황 분석을 위해서 수행해야할 지표 및 목표에 대해 설명을 들었습니다.

 

사용량 분석 항목에서 분석 항목별로(하드웨어 구성 /미들웨어 성능의 적정성 / 미들웨어 운영의 적정성 / DB 구성 / 네트워크 환경분석 / 네트워크 운영 및 교육)

세부 분석 항목, 점검항목, 점검 방법을 배웠습니다. 

 

• 사용량 분석 항목 中 미들웨어 부분

특히 미들웨어 관련하여 아래와 같이 어떤 점검 항목이 있으며 점검방법에 대해 말씀해 주신 것이 기억에 남습니다.

분석항목세부 분석항목점검 항목점검방법

미들웨어  성능의 적정성	파라미터 설정의 적정성	미들웨어 관련 OS 파라미터가 적절하게 설정되어 있는가?	시스템 점검 명령어
		미들웨어 파라미터가 적절하게 설정되어 있는가?
	AP 성능 개선  절차의 적정성	AP 성능을 위한 서비스 응답시간 Log를 남기고 있는가?
		모니터링을 통해 지속적인 성능 개선 작업을 수행하고 있는가?
미들웨어 운영의 적정성	역할 및 정의의 적정성	미들웨어 담당자가 지정되어 있는가?	상세설계서 검토 담당자 역할 확인
		미들웨어 담당자의 역할 및 권한이 정의되어 있는가?
		운영자 지침서가 작성되어 있는가?
	개발/운영 환경 지원의 적정성	미들웨어 기동 및 중지에 대한 절차가 있는가?	상세 설계서 검토
		모듈 이관에 대한 절차가 있는가?
		각종 로그 파일 관리 방안은 있는가?

TA는 각 인프라영역별로 어떤 고민을하고 있는지 알게 되었으며, TA의 고충을 알 수 있었습니다.

예상했던 것보다 훨씬 더 꼼꼼해야하며, 넓은 시야로 전체 인프라를 보는 안목이 있어야할 것 같았습니다.

 

생각보다 상세설계서 역할이 매우 중요했는데, 상세설계서 중심으로 아키텍처를 설계해야 했고, 요구사항을 명확히 해서 벤더사에게 전달해야

오해가 생기지 않고 니즈를 충족할 수 있었습니다.

 

• 사용량 분석 방법

cpu 사용량 분석 방법을 배웠는데 그중에서도 가장 중요하시다고 강조 하신 부분입니다. 이론에서 얼핏들은 내용을 실제 업무에서 적용하여 분석하는데 쓰이니 신기하였습니다.

Run Queue size	Run Queue (RunQ) 상의 프로세스 수 CPU Util. 값과 비교하여 유용한 정보를 얻을 수 있으며 낮은 CPU Util과 높은 Run Queue size 값은 I/O 시스템 이상을 의심할 수 있음
Context Switch	Scheduler에 의해 실행 중인 프로세스를 바꿔주는 과정 너무 많은 프로세스가 CPU를 원하면 성능 저하를 야기하고 우선순위를 통하여 CPU 자원을 할당 CPU Util 수치와 비교하여 유용한 정보를 얻을 수 있으며 높은 CS 값은 CPU 자원부족을 의심할 수 있으나 업무 성격을 고려해야 함

 

• 사용량 분석결과 활용 방안

이 부분에서 최대 174회 full gc가 발생한 부분과 발생 원인, 해결방안을 설명들었는데, 

모든 인프라영역에서 검토를 해본 뒤에도 해결이 되지 않자full gc문제가 해결이 되지 않았고 원인은 실제로 서비스 양이 늘어났기때문이었습니다.

빨간 박스 영역을 보시면, 전년대비 업무 처리량이 늘었기에 WAS instance를 19GB에서 30G 증설하여 full gc에 따른 서비스 지연 현상을 개선하셨다고 하셨습니다.

 

이외에도 다른 사례로 증설 사례가 있었습니다.

 

[ TA 수행사례 ]

TA 수행사례로는, 목동센터 이전 프로젝트와 ICIS TR 프로젝트, KOS 스토리지 대개체 프로젝트를 들었습니다.

그 중 목동센터 이전 프로젝트 사례는 대규모 프로젝트인 만큼, 센터이전 사전 작업 수행 내역이 복잡했고

개발/운영 스토리지 분리와 스토리지 분리 구성도 역시..., 복잡하다 못해 이해하기 쉽지 않았습니다.

 

,

또 센터이전 사례를 들으면서, 이런 일도 TA가 계획하여 한다는 말씀에 놀랐습니다..

만약 센터이전을 하게 되면, 누구의 가이드하에 센터이전이 진행될까 궁금했었는데 이 복잡한 일을 진행하는 것이 TA이 몫임을 알게되었습니다..

이전 계획부터 이전 후 장비 하차하여 배치하는 것까지 상면 위치를 확인하였습니다.

데이터센터 이전하면 어떻게 장비들을 운반하며, 구별하는지 궁금하였는데 이게 다 수작업으로 포장하여 케이블 라벨까지 붙이는 것인 줄 몰랐으며,

src장비의 상면위치 / 케이블 용도 /호스트명/ 장비 slot port로 구분하여 개별 확인을 한 뒤, tgt 장비로 이전하는데 이것또한 TA몫이었음을..알게되었습니다.