프로젝트 소개
Microsoft Azure
Microsoft Azure 도입 배경
본 프로젝트의 클라이언트는 외국 자본계 감사 법인이었습니다.이미 온프레미스 환경을 가지고 있었지만 회사의 방침에 따라 Microsoft Azure 도입이 결정되었습니다.이 기회를 활용해, 매니지드 서비스를 사용해, IT 서비스의 운용·보수에 관련되는 자원의 삭감을 목표로 했습니다.
프로젝트 체계
PMO나 PL과 같은 포지션은 명시적으로 마련되어 있지 않았지만, 각각의 멤버가 특기 분야를 살려 PMO나 PL의 역할을 분담하여 담당하고 있었습니다. 프로젝트 예산의 제약 때문에 기대되는 규모에 비해 조금 인원이 적더라도 대응해야 했습니다. 그 덕분에 다양한 포지션의 업무를 경험할 수 있었습니다.
고객 측 요구사항
클라이언트 직원 중에는 Microsoft Azure에 정통한 엔지니어가 없었습니다. 그 때문에 벤더 기업의 전문가에게 Azure의 도입부터 운용 페이즈까지의 서포트를 기대하고 있었습니다.
이 상황에서 클라우드 서비스의 아키텍트 설계 및 프로젝트를 리드할 수 있는 스킬을 가진 인재가 필요하게 되었습니다. 게다가 운용·보수의 작업 부하를 줄이기 위해서 업무 효율화, 자동화, 그리고 IaC CI/CD의 도입도 검토 중인 상황이었습니다.
불안에서 힘들었던 경험
제가 프로젝트에 참여했을 때 IT 운용 정책의 정리 및 운용 방침이 검토 중이었는데, 무엇부터 손을 대면 좋을지 감도 안 오는 상황에 혼란스러웠습니다. Microsoft Azure 자격증은 취득했지만 실무 경험이 거의 없었기 때문에, 저 같은 사람이 프로젝트에 참가해서 주위에 폐를 끼치고 있는 것은 아닐까, 혼자서 노심초사하고 있었습니다.
사실 프로젝트 초기 단계에는 긴장해서 매일 위가 아팠던 경험이..
지금 돌이켜 생각해 보면 신규 멤버에게 그렇게 기대할리는 없는데 혼자서 사서 고생했네요.
프로젝트 업무 내용
클라우드 솔루션 설계 및 구축
다음으로, 제가 Azure의 도입·운용 서포트 프로젝트에서 어떠한 업무에 종사하고 있었는지를 자세하게 소개합니다.앞으로 클라우드 관련 안건에 참여할지 망설이는 분들이나 ‘클라우드 엔지니어는 구체적으로 무엇을 하는 거야?’라고 궁금하신 분들을 위해 쓰고 있으니 꼭 끝까지 읽어주세요!
Notice
엔지니어로서의 업무 내용은 임하는 안건에 따라 다양합니다.
이하의 정보는 어디까지나 참고만 해 주세요.
네트워크 관련 업무
과거에 네트워크 엔지니어로서의 경력을 쌓아온 배경에서 프로젝트에서는 자연스럽게 네트워크 관련의 작업을 담당하게 되었습니다. 클라우드에서도 네트워크는 매우 중요한 요소이며 정확한 설계와 적절한 보안 대책이 필요합니다.
- 네트워크 설계 및 구축
Azure에 있어서의 네트워크의 설계, 구축, 운용 지원
VNet (Virtual Network) 나 Subnet, NSG (Network Security Group) 의 설정, ExpressRoute의 구축
프라이빗한 네트워크를 구축하기 위해 Private Endpoint 를 적극적으로 도입한 네트워크를 구축하였습니다. - 모니터링 운용 설계 및 구축
Azure Monitor, Log Analytics, NSG Flow 로그를 사용하여 네트워크 및 리소스를 모니터링하고 분석하여 문제 발생 시 대응 - 트러블 슈팅
네트워크나 자원에 관한 문제나 장애가 발생했을 경우의 문제 해결을 실시했습니다.
예를 들자면, Traffic Manager를 사용한 진단, 문제의 특정과 해결책 제공 등을 담당했습니다.
네트워크는 Hub&Spoke 구성으로 설계 했으며, 아래는 당시 설계에 참고했던 Microsoft 아키텍쳐입니다.
가상 머신 관련 업무
Azure의 도입·운용 지원 프로젝트에서, 제가 종사한 업무 내용을 되돌아보면, 서버 및 OS의 조작보다 클라우드 인프라의 전체상을 파악하고, 그것을 구현하기 위한 아키텍처나 보안의 설계에 주력하고 있었습니다. 아래는 제가 주로 하던 업무 내용입니다.
- 가상 머신 설계 및 구축
Azure 내에서의 가상 머신 설계부터 구축까지를 담당했습니다.
여기에는 적절한 VM 크기 선정, OS 선택, 네트워크 연결 설정 등이 포함됩니다. - 보안 대책
Azure Security Center, Defender for Cloud의 조언 및 권장 사항에 따라 서버 보안 설정을 최적화하였습니다.
예: 가상 머신이나 디스크의 암호화 등 - 퍼포먼스 튜닝
Azure Monitor, Log Analytics를 사용하여 서버 성능을 모니터링했습니다.
병목 현상이나 성능 문제를 발견한 경우 적절한 조정 및 튜닝을 통해 성능을 유지했습니다. - 트러블 슈팅
시스템이나 서비스에 문제가 발생했을 때 신속한 진단과 수정을 실시했습니다.
예: 로그 확인, 시스템 복구, 원인 파악, 문제 대책 구상 등 - 백업 및 장애 복구
Azure Backup 및 Azure Site Recovery 등의 서비스를 이용하여 데이터 백업 및 장애 복구 대책을 설계 및 구축했습니다.
네이티브 클라우드 솔루션 관련 업무
Azure를 활용한 프로젝트에서 클라우드 조작 및 관리는 필수 스킬입니다.
거기에서는, 온프레미스 환경과의 제휴나 이용자에의 환경 제공, 더 나아가 자동화의 실현 등, 다양한 업무를 담당하였습니다.
- DNS 설계 및 구축
Microsoft Azure의 PaaS 서비스를 활용하여 온프레미스와 클라우드 간 DNS를 설계하고 구축하였습니다. 이를 통해 두 환경의 원활한 연동을 실현하였습니다.
- Azure CLI・PowerShell 이용
Azure CLI와 PowerShell은 Azure 리소스의 조작 및 관리를 효율적으로 수행하기 위한 도구입니다. 이러한 커맨드라인 도구를 사용하여 복잡한 작업을 신속하게 수행하였습니다.
- Azure Bicep 이용
Infrastructure as Code (IaC)는 인프라의 설정 및 구성을 코드로 관리하여 자동으로 환경을 구축하고 운영하는 방법입니다. Azure Bicep는 Azure의 IaC 도구로 제공되며, 이를 이용해 환경의 자동 구축 및 변경 사항을 적용하였습니다.
전달하고 싶은 메시지
인프라(온프레미스)의 엔지니어는 대부분 서버나 네트워크 중 하나에 전문화되어 있습니다. 그러나 클라우드 환경에서는 실제 작업 부하가 경감되는 한편, 다양한 인프라 서비스에 대한 넓은 지식이 요구됩니다. 첫눈에 배워야 할 내용이 너무 많다고 느낄 수도 있지만, 처음에는 인프라의 ‘전체적인 그림’을 이해하는 것을 목표로 삼고, 세부 사항까지 깊게 학습할 필요는 반드시 있는 것은 아닙니다.
기술하는 업무 내용을 모두 혼자서 수행한 것은 아닙니다. 프로젝트는 ‘다른 멤버와의 협업’이 성공의 열쇠입니다.
문서화 작업
할 일이 너무 많지 않나? 라고 생각하실 수도 있지만, 조금 더 있습니다.
많은 사람들이 엔지니어링은 순수하게 기술적인 작업만으로 구성되어 있다고 생각하지만, 실제로는 그렇지 않습니다. 분명 시스템의 설계나 구현, 테스트 등 기술적인 부분이 중심적인 역할을 합니다만, 그것만으로는 부족합니다. 그 뒤에는 ‘문서화’라는 중요한 프로세스가 존재합니다.
문서화가 중요한 이유
문서화는 시스템의 ‘운영 및 유지 관리의 기반’이 됩니다. 시스템의 구조나 작동 방식, 문제 해결 방법 등, 미래의 자신이나 다른 엔지니어들이 신속하고 확실하게 대응할 수 있도록 하는 정보를 자세히 기록할 필요가 있습니다.
문서화가 어려운 이유
문서화는 종종 복잡하고 시간이 많이 걸리는 작업으로 여겨집니다. 특히, 변화가 빈번히 이루어지는 개발 단계에서는 문서의 갱신도 자주 요구됩니다. 무한 지옥 그러나 그 노력은 나중의 단계에서 충분히 보상받을 수 있습니다.
인적 자원의 요구가 크기 때문에, IaC(Infrastructure as Code)가 고려됩니다. 그럼에도 불구하고, 문서화는 생략할 수 없는 과정입니다.
전달하고 싶은 메시지
엔지니어로서의 기술적 능력뿐만 아니라, 제대로 된 ‘문서화 능력’도 마찬가지로 중요합니다. 이를 통해 자신이 프로젝트에서 빠진 후에도 시스템이 지속적으로 정상적으로 작동하는 것을 기대할 수 있습니다. 문서화 작성은 다른 멤버나 미래의 자신에게 기여하는 것으로, 전문가로서의 책임을 다하는 것에 연결됩니다.
프로젝트의 진행
프로젝트 추진에 있어 관리의 측면에서도 많은 학습과 반성의 포인트가 있었습니다. 제가 관리의 중심에서 행동했던 것은 아니지만, 프로젝트의 움직임을 따라가보면 몇 가지 핵심 포인트와 도전과제가 보입니다. 미래의 제 자신과 다른 엔지니어에게 참고가 되었으면 해서 기록했습니다.
워터폴 방식
제가 중간부터 참여했기 때문에, 자세한 것은 모르지만, 전통적인 ‘워터폴 방식’의 개발을 채택하고 있었습니다. 구체적으로는, 과제의 선택, 기한의 설정, 계획 수립, 검증, 그리고 구현의 흐름을 따랐습니다.
애자일 방식
그러나 예상했던 리소스와 실제 작업량이 일치하지 않아, 계획대로 과제를 진행하기 어려워졌습니다. 상황을 타개하기 위해서는 시행착오가 필요했고, 자연스럽게 ‘애자일 개발’ 방식으로 전환했습니다. 각 엔지니어가 자신의 담당 범위에서 서비스의 조사부터 구현까지를 담당했습니다. 확실히 엄격한 상황이었지만, 제한된 리소스를 최대한 활용하기 위한 선택이었습니다.
시행착오
많은 문제에 직면했지만, 여기에서는 특히 기억에 남는 문제를 몇 가지 추려서 공유합니다. 물론, 이 외에도 다양한 문제에 부딪혔지만, 그 문제들도 시행착오를 거듭해 더 원활한 운영 정책으로 바꾸어 갔습니다.
빈번한 과제의 우선순위 검토 문제
담당 과제를 진행 중에 새로운 과제나 요구 사항이 자주 제기되어, 이미 설정한 작업의 우선순위를 자주 재검토해야 할 필요성이 생겼습니다. 이에 대응하기 위해, 주간 정기 회의 외에도 ‘서브 정기’를 마련하고, 필요에 따라 담당자 간에 상시 정보를 공유하여 과제의 우선도를 조정했습니다.
담당 범위의 문제
각 엔지니어가 서비스 조사부터 구현까지의 일련의 작업을 담당하게 되면서, 엔지니어마다 시스템에 대한 ‘이해도 차이’가 발생하여 담당한 엔지니어 이외에는 해당 업무를 수행할 수 없게 되어, 업무의 로드 밸런싱을 하지 못했습니다. 대책으로, 시스템별로 담당자와 서브 멤버를 명시적으로 정하는 방침을 세웠습니다.
시간 부족 문제
과제와 진행 상황에 대한 지속적인 정보 공유를 위해 소통 시간이 늘어나 작업 시간이 줄어드는 경우가 있었습니다. 이 문제에 대응하기 위해, ‘회의보다는 채팅’을 사용하여 정보를 효율적으로 공유하고 시간을 절약했습니다.
마무리
아직 초보 엔지니어이지만, 1년 반 동안 클라우드 엔지니어로서의 업무와 프로젝트 흐름을 경험에 기반하여 적어보았습니다. 아직 Azure 설계·구축 프로젝트 경험이 없는 분들이나, 경험이 없는 엔지니어들에게 도움이 되면 매우 기쁠 것입니다.