OpenStack
프로젝트 소개
이번에 소개드릴 프로젝트는 5G 네트워크의 기반 구축 작업입니다. 어느 통신사에서 5G 가상 네트워크를 구축하는 기반 팀의 엔지니어로 참여하게 되었습니다. 외국의 벤더 기업의 클라우드 네트워크 솔루션을 도입하여 대규모 가상 네트워크 기반의 구축을 진행했습니다.
프로젝트 배경
일본 전국에서 5G 통신을 실현하기 위해, 전국의 기지국에 5G 설비를 도입하는 작업을 진행하고 있었습니다. 그 시기에는 도쿄의 도요스를 중심으로 5G 통신의 네트워크 기반을 구축하는 프로젝트도 진행 중이었습니다. 시스템 설계가 어느 정도 진행된 단계에서, 저는 이 프로젝트의 구축 작업에 참여하게 되었습니다.
프로젝트 체제
저는 단순히 ‘작업자 A’ 였기 때문에 프로젝트 체제에 대해서는 자세히 알지 못하지만, 초기 기반 구축 팀은 5개가 있었으며, 작업 책임자, 작업자, 오퍼레이터로 구성되어 있었습니다. 주간 정기 회의에는 ‘작업 책임자’ 이상이 참석하며, 전반적인 구축 진행 상황은 서브 PM이 조정했습니다. 그리고 각 팀의 작업 책임자가 구체적인 스케줄을 결정하고 진행하였습니다.
당시 저는 엔지니어 경력 1년 차로 LPIC-2와 CCNA 자격증을 보유하고 있었습니다.
하지만, 서버 및 네트워크 구축 프로젝트에 할당되지 않고 대기 상태였습니다.
솔직히 말씀드리자면, 영업 담당자가 제대로 된 프로젝트를 소개해주지 않고 계속해서 ‘24시간 365일’ 야간 교대 근무의 모니터링 업무에 투입하려 했기 때문에, 3개월 동안 4번이나 할당을 거부했습니다. 운이 좋게도, 저를 알고 있는 영업 담당자가 이번 프로젝트에 저를 할당해주었습니다. 프로젝트 참여를 위해 3차례의 면담을 거쳐 겨우 프로젝트 참가가 확정되었습니다.
모든 영업 담당자가 나쁘다고는 전혀 생각하지 않습니다. 하지만, 엔지니어 대우가 형편없는 영업 담당자도 있다는 것을 명심해 주세요
프로젝트 초기
사내 교육 및 작업 견학
프로젝트 참여 직후, 회사 내부 교육이 시작되었습니다. 교육에서는 주로 Linux 커맨드를 사용한 작업에 중점을 두고, ‘휴먼 에러를 피하는 방법’ 및 ‘커맨드 실행 시 주의점’ 등을 배웠습니다. 그 후, 약 일주일간 경험이 풍부한 엔지니어 분들의 기본적인 구축 실습을 관찰할 기회를 가졌습니다. 처음에는 절차의 의미를 전혀 이해하지 못하고, 많은 것을 모르는 상태였지만, 주변 사람들에게 질문하며 배워 나갔습니다
작업 환경 준비
교육을 병행하며 지급받은 PC의 설정을 진행했습니다. 구축 대상 환경은 온프레미스였지만, 해당 온프레미스 환경에 접속하기 위한 ‘점프 서버’로의 연결 설정을 완료했습니다. 또한, 파일 전송 시 사용하는 ‘AWS S3’의 설정도 실시했습니다. 설정하는 데 애를 먹고 있는 사람들이 있다는 걸 보고, 나만 어려워하는 게 아니구나 하고 조금 안심했습니다.
작업 이력 관리 방법
다음은 작업 이력 관리 방법에 대해 배웠습니다. 작업 로그의 명명 규칙이나 언제 로그를 저장하고 업로드해야 하는지와 같은 세세한 규칙이 설정되어 있었다는 것을 기억합니다. 또한 진행 상황 관리를 위한 양식도 새로 만들었습니다. 과제 관리표에 대해서는 이미 사용되고 있는 것이 있어서 그 기입 방법이나 포맷에 익숙해지는 것이 요구되었습니다
테스트 환경 구축
이후에는 테스트용 서버를 사용하여 실제로 구축하는 연습을 했습니다. 미완성된 매뉴얼을 바탕으로 내용에 오류가 있는지 확인하거나, 오류가 발생했을 때 상위 공정의 엔지니어에게 보고하는 작업을 여러 번 반복했습니다
테스트 환경 구축의 순서
- 작업 준비 (명령어 텍스트・설정 파일 편집)
- 하이퍼바이저 도입・설정 작업
- 가상화 서버 (컨트롤러 서버・컴퓨트 서버) 구축 작업
- 기반 서버의 정상성 확인
- 백업
- 자빅스(Zabbix) 모니터링 설정
- 솔루션 제품의 도입・설정 작업
- 컨테이너의 정상성 확인
- 백업
테스트 환경 구축에 사용한 문서
기본 설계서（가끔 사용）- 상세 설계서
- 가상 네트워크 솔루션 제품 메뉴얼
- 네트워크 설계도
- 온프레미스 서버 랙(Lack) 구성도
- 구축 지침서 x2
- 파라메터 시트
Linux 명령어 학습
기반 구축 작업에서는 하이퍼바이저부터 가상화 서버까지 Linux와 OpenStack 명령어를 사용하고, 가상화 네트워크 컨테이너 이후에는 주로 Docker와 Kubernetes 명령어가 사용되었습니다. 처음 구축 가이드를 봤을 때, 적혀있는 명령어의 10%도 이해하지 못했지만, 제가 무엇을 하고 있는지 이해하기 위해 작업 시간 외에도 명령어 공부를 계속했습니다
프로젝트 중기
트러블 슈팅
프로젝트 중반부터 직접 문제의 해결책을 찾기 시작했습니다. 에러가 많이 발생하여 곧 선임 엔지니어들도 어찌할 바를 몰라, 각 팀으로부터 이슈 트래커(Issue Tracker)를 열람할 수 있는 계정을 만들어 받았습니다. (모두 영어였지만, 번역 툴을 적극 활용하여 해결책을 찾아냈습니다.)
프로덕션 환경 구축
아직 원인을 알 수 없는 에러가 남아 있긴 했지만, 기반 구축 작업이 어느 정도 안정화되어 드디어 실제 환경의 구축 작업에 들어갔습니다. 실제 환경의 구축은 개발 환경에서의 작업과 같아 특별한 문제는 없었습니다
재해 발생 대책 검증
기반을 구축하는 것뿐만 아니라, 서비스가 항상 정상적으로 작동할 수 있도록 재해 대응 계획도 수립했습니다. 특히, 디자스터 리커버리 테스트 중에 다양한 문제에 부딪혔습니다. 서비스를 중단하지 않고 서버 이동을 가능하게 하는 ‘라이브 마이그레이션(Live Migration)’이라는 기능이 예상대로 작동하지 않았습니다. 이 문제의 원인을 찾고 검증을 하기 위해서는 주말을 포함해 작업을 계속해야 했습니다. 특정 크기 이상의 가상화 서버에서는 라이브 마이그레이션이 실패하는 것을 확인했는데, 제가 프로젝트를 떠나기까지 해결되지 않았습니다
진척 관리 및 과제 관리
진척 관리와 과제 관리는 원래 작업 리더의 업무였지만, 프로젝트 중반부터 저가 그 역할을 맡게 되었습니다. 각 공정의 ‘진행 상황’이나 ‘작업 스케줄’을 관리했습니다. 과제 관리 측면에서는, 구축 작업 중에 발생하는 문제나 그 해결책 등을 다른 팀과 공유할 수 있도록 기록을 했습니다
프로젝트 후기
프로젝트 체제 변경
기반 구축이 일정 단계에 도달하여 기반 팀을 축소하기로 결정했습니다. 저의 경우에는 기반 팀에 남아 계속 인프라 작업을 담당하게 되었습니다. 이때 기반 팀의 서브 PM이 프로젝트를 떠나게 되었습니다. 개인적으로 서브 PM분께 많이 의존하고 있었기 때문에, 프로젝트를 떠난다고 들었을 때 상당히 충격이었습니다. 대신에 다른 경험이 풍부한 엔지니어분이 팀에 합류하게 되어 ‘Ansible’이나 ‘Cloud Service’ 등 흥미로운 IT 지식을 배울 수 있었습니다.
신규 멤버 교육 및 다른 팀의 서포트 역할
저도 이직을 결정하게 되어, 그에 따른 인수인계를 위해 새로운 멤버가 팀에 참가하게 되었습니다. 그 분도 저와 마찬가지로, Linux 서버나 명령어 조작에 대한 실무 경험이 없었기 때문에, 떠나기까지 약 1개월 동안 교육 담당으로서 구축 작업을 가르쳤습니다. 그 외에도 다른 기반 팀의 서포트 역할도 담당하게 되었습니다.
프로젝트 퇴장
여기까지가, 저가 경험한 약 1년 반의 큰 프로젝트가 끝났습니다. 처음 시작할 때는 기술적인 부분이나 팀에서의 작업 흐름 등, 알 수 없는 부분이 많았고(그리고 작업량도 많았기 때문에) 여러 어려움에 직면했습니다.하지만, 지금 돌아보면 그런 경험들은 저에게 매우 가치 있는 경험이었다고 생각합니다.
