웹솔루션운영이란? 운영팀원으로서의 지침사항(주관적)

개요

운영팀의 역할은 설명하기도 스스로 정의 내리기도 애매한 것 같다.
DevOps 라기에는 개발에 관여하는 부분이 최소한으로 국한되고, 인프라 구축팀이라고 하기에는 개발을 안하는 것도 아니다.
정작 운영팀에 있는 본인도 헷갈리면 외부에서 바라보는 시선은 더 헷갈릴 수 밖에 없다.
1년간 운영을 위해 쌓아온 약간의 경험들과 최근 Well Architecture Review를 진행하며 우수한 평가의 기준들을 보면서
정체성을 조금씩 확립해 나아가 보고자 한다.
이런 경험과 정보의 정리를 통하여 운영에 필요한 용어들을 학습하고, 체크리스트를 통하여 팀에 이바지 할 수 있어야 한다.

운영이란,

ITSM이라는 단어가 많이 언급되었지만 처음 들어보았다.
ITSM : (IT Service Management) IT 서비스를 어떻게 하면 잘 구성할까?
단, ITSM의 관점은 단순히 기술 중심의 관리가 아닌 비즈니스 중심으로 재설계, 재구성한 구성을 의미한다.
효율적인 프로세스 운영을 통해 비용 절감까지 달성하는 것이 바로 ITSM의 핵심이다.
이러한 훌륭한 사례들을 전 세계적으로 공유하는 표준들이 있는데 그것을 ITIL(IT Infrastructure Library)라고 한다.

ITSM의 시각은 어떠할까?

구분	일반적인 IT 운영(구)	ITSM
관리 관점	내부 운영팀 중심	운영팀 + 비즈니스 현업 중심
문제 해결	후속조치, 즉각대응	예방조치, 사전대응
절차	비공식적	공식적 + Best Practice
관리도구	개입 및 통제 불가(외부 솔루션 등)	프로세스 개입 가능 Tool
과금	서비스 수준이 아닌 단위별 과금	서비스 수준에 따른 과금

위의 표를 보게 되면 ITSM의 키워드들을 알아 낼 수 있다.

나의 주관적인 이해는 바로 'Formal', 'Business' 그리고 '과금'이다.
Formal: 어떤 작업이던 형식을 갖춰야 하며 유지 보수가 되어야 한다.
Business: 당장 운영팀만의 편의성이 아닌 사업적인 관점에서 결정이 내려져야 한다.
과금: 항상 그 효율에 관하여 생각함과 동시에 비용에 대한 관점도 생각해야 한다. → 결국 영업이익으로 이어지기 때문..

ITSM이라는 단어 하나만 보아도 운영팀으로써 어디에 초점을 맞춰야 할 지 대충 감이 오는 느낌이다.
그렇다면 ITSM의 측면에서 마이다스아이티 운영팀은 어떻게 구성되어 있는지 분석해 보자.

MidasIT Operation 현황

1. 관리관점
   마이다스아이티의 웹솔루션 서비스는 SaaS 형태로 기업에 플랫폼을 제공하는 서비스이다.
   또한 AWS 의존도가 90% 가까이 되기 때문에 AWS를 전문적으로 다루는 사람이라는 AWS 구성을 둘러보는 것만으로도
   우리의 서비스 연결 형태를 이해할 수 있다.
   AWS 클라우드 환경을 가졌다는 점은 굉장히 높게 평가되고 자부심이 생기는 부분이다.
   
   
2. 문제해결
   과거가 Fire Fighting의 방식이였다면 점차 Preventive로 전환되고 있다.
   아무래도 운영팀 자체적으로 인원 부족과 클라우드로의 과도기 였음을 따져 보았을 때,
   그 때 쌓아둔 경험들을 토대로 이제는 안정성과 예방에 힘쓰는 때 라고 생각된다.
   문제를 해결하는 과정을 RPO, RTO 등과 같이 구체적인 지표와 알고리즘으로 표현해야 될 필요성이 있다.
   
   
3. 절차
   절차 부분은 거의 작업자의 경험과 감에 의존하여 진행된다.
   하지만 이 역시도 각자의 절차가 있기 때문에 자유분방 한 것은 아니지만
   가장 취약하다고 생각하는 것은 Formal한 형식이 없다는 것이다.
   장애절차와 장애 별 긴급도에 따른 책임자 구분 + 각자의 시나리오를 위한 것들이 조금 더 구체화 될 필요가 있다.
   또한, 형식으로만 남지 않도록 여러번의 모의해킹, 모의장애 훈련도 조금은 도움이 되지 않을까 생각한다.
   
   
4. 관리도구
   관리도구 역시 AWS에 대부분 의존하고 있지만, SMS 처럼 외부 업체를 사용하는 경우
   그 쪽에서 장애가 발생하면 대처할 수 있는 것이 없다.
   (물론 AWS도 장애가 발생해 버리면 우리는 그에 대한 대비책이 없다.)
   실제로 AWS에서 자체적인 장애가 발생하여 30분간 지연되었을 때 우리는 손 놓고 기다리는 수 밖에 없었다.
   장애에 대처할 수 없는 조건이라면, 장애 시 멀티환경으로의 전환과 같이 빠르게 대응할 수 있는 방법을 고려해 봐야한다.
   
   
5. Billing
   각 서버의 타입이 운영에 적절한 지를 확인해보면 굉장히 적절하다.
   그럼에도 비용은 운영팀에서 1순위로 고려되는 사항이 아니었다.
   그 이유로는 회사의 지원에 딱히 제한이 없었을 뿐더러, 비용을 절약할 뚜렷한 방법을 몰랐기 때문이다.
   하지만 이제는 데이터 기반으로 보다 정확한 서버 운영 최적화가 가능하고,
   AWS에서 RI(Reserved Instance)와 같은 걸로 비용을 절감할 수 있다.
   허리띠를 졸라 매듯이 순차적인 절감을 한다면 1년 사이 서비스가 증가하여도 현재 금액의 최대 30% 이상은 절감할 수 있지 않을까 싶다.
   
   

체크리스트

• 장애대응 시나리오가 있는가?
• 보안위협에 대한 최신 정보가 전달되는가?(정보보호파트)
• 장애 별 등급이 설정되어 있는가?
• 장애 등급에 따른 Notification 체계가 확립되어져 있는가?
• 대고객 서비스인 만큼 장애 발생 시 고객들에게 push 와 같은 알림이 전달 되는가?
• 비용에 관한 문제를 꾸준히 관리하는 담당자가 있는가?
• 각자의 역할에 대하여 RNR이 문서화 되어 있는가?
• 로그, 메트릭스, 알람 등에 대하여 필요한 사항이 빠짐없이 적용되었는가?
  
  

용어

RnR : Roll And Responsibility
APM : Application Performance Management - Apache, PHP, Mysql의 앞글자
CIDR : Classless Inter-Domain Routing - 최신 IP 주소 할당법
AD : Active Directory - 네트워크 서비스의 일종으로 네트워크 자원(사용자 계정, 프린터, 컴퓨터 정보 등)에 접근하여 관리를 용이하게 만드는 서비스
KPI : Key Performance Indicator - 핵심 성과 지표
 > 내가 정한 목표가 기준이 되어야 함
 > 그 결과는 유기적 통합의 관점에서 보아야 함(자신의 목표 달성 뿐만 아니라, 매출, 이익, 등 균형잡힌 기준으로 평가)
RI : Reserved Instance - 예약 인스턴스로 인스턴스 타입에 관하여 1년, 3년 계약을 맺으며 사용성을 보장 받음과 동시에 가격은 절감하는 AWS 제도
VPN : Virtual Private Network - 인터넷에서 웹사이트로 접근하려면 ISP라는 인터넷 서비스 제공업체를 무조건 거쳐야 한다. 그 과정에서 모든 기록이
                                                   ISP에 저장되고, 해당 기록은 광고주, 정부 기관 및 제3자에게 양도 될 수도 있다. 그렇기 때문에 VPN을 그 사이에 집어 넣어
                                                   인터넷 트래픽을 리다이렉트 시키고, IP 주소를 숨기고 암호화 한다.
                                                   개인정보를 다루는 서비스라면 필수라고 할 수 있다.
RTO : Recovery Time Objective - 목표 복구 시간(시스템 복구와 관련)
RPO : Recovery Point Objective - 목표 복구 시점(데이터 유실과 관련)
HA : High Availability - 서버 이중화(=AWS Multi A-Z)
RCA : Root Cause Analysis - 문제의 근본적인 원인을 밝히는 프로세스
 > 문제 정의 - 데이터 수집 - 원인 요소 취합 - 근본 원인 파악 - 해결책 제안 및 실행 단계로 진행되는 프로세스