월99만엔 TiDB SES 파견 프로젝트.. 이지만 운영 효율화... 일본IT

영상버전 : https://youtu.be/F-KO_D694pQ

벌써 3주차가 끝났네요.. 

하루에 5시간 이상을 이야기하면서 진행하는건 체력을 너무 소모시키는 것 같습니다. 

하지만, 기존 멤버들이 경험이 너무 없어서 제가 알려주면서 해야 하다보니

거의 상시 미팅 모드로 이것저것 알려주게 되네요.. 

새로 들어온 두 명중 한 명은 0.2 MM이니 미팅만 하고 일도 시킬 수 없는 상태이고, 

또 다른 한 명은 열심히 마이그레이션 프로젝트를 분석하면서 문서화를 하고 있는 것 같습니다. 

정작 신규 멤버 중 실무에 투입가능한 사람이 저 뿐이라 

제가 풀 가동 되는 느낌이네요.. 

그래서 미팅 사이에 작업시간이나 다음 미팅 준비 시간에는

거의 누워서 쉬고 있습니다. 

리모트 프로젝트의 메리트랄까요.. 

눈치 안보고 틈틈히 드러누워 쉴 수 있다는..

-----------------------

얼마전 고객사와 파견회사와의 중간 평가가 있었고, 

그 결과를 

제게 공유를 해주더라구요.. 

내용을 해석하자면.. 

- 처음 면담시 기대했던 만큼 스페셜리스트로서 기술적인 지식이 너무나 풍부

- 참가 멤버들로부터의 평가도 좋음

- 엄청나게 우수한 분이라서 이후 멤버 쪽에서 따라지 못할까봐 걱정

(불만이라는 뜻은 전혀 아니고 [도와주면 아주 고맙다]라는 늬앙스 입니다.

라고 피드백을 받았다네요.. 

이제 2주차 보여준건 거의 없는데.. 

하면서 제자랑도 한 번 해주구요.. 

------------------------------------------------------

아뭏든.. 

3주차에 했던 것 들 중에는 

눈에 띄는 것들이 운영 효율화 입니다. 

꽤 오래전 내용 중에 

대기업은 Azure를 많이 쓰고 스타트업은 AWS를 많이 쓴다고 하였죠?

한국에선 AWS만 생각하시는 분들이 많아서 

이 내용을 모르시는 분들을 위해 다시 한 번 말씀 드리자면, 

일본 뿐 아니라 전 세계적으로 대기업은 Azure를, 

스타트업은 AWS를 많이 씁니다. 

스타트업의 문화를 좋아하시는 분들이라면 AWS를 공부하시구요, 

대형 프로젝트로 큰 경험을 쌓아 자신의 몸값을 높이 올리고 싶으신 분들은 

Azure를 공부 하시기 바랍니다. 

이번 프로젝트도 젊은 스타트업 기업이다 보니 AWS를 쓰고 있습니다. 

DBRE팀도 자기네 리소스를 위해서 

SQL Server는 데이터센터에서 VMWare로, 

MySQL은 AWS Aurora를 중심으로 쓰고 있네요. 

요즘 들어 작업자들의 미스나 컴플라이언스를 위해 

RDBMS접근 권한 관리를 강화시키려고 하고 있습니다. 

SQL Server는 약 50대, MySQL은 약 40대 정도 있고, 검증 등을 위해서 특정 일자 백업을 인스턴스로 복구하기도 하면서 늘었다 줄었다 하네요.. 

RDBMS에 접근 요청이 올 때마다 신청 기간 만큼 그 작업자의 유저를 생성해주고, 

기간이 되면 삭제를 하고 있습니다. 

그 밖에도 서버들마다 인덱스의 지정이 다르고 용도가 다르다보니 

리플리케이션 설정도 복잡하고, 인덱스도 매번 들어가서 체크를 하는 등

자주 서버에 접속해서 상태를 확인하는 경우가 많더라구요.. 

그래서 이 두 가지를 자동화 시키려 하고 있습니다. 

일단 1단계로 엑셀에 서버명과 유저 정보등을 기입하면

그 엑셀에서 대상 서버, DB명, 유저 정보를 가져와 일괄로 계정을 생성하는 

Powershell 스크립트를 만들었지요. 

즉, 엑셀에 수십대의 서버와 DB명, 계정 정보를 넣으면

신청 범위만 유저가 생성되는 것이지요. 

그렇게 생성하고 엑셀만 백업하면

언제 누가 무슨 용도로 유저를 만들었는지 알구요, 

그걸 베이스로 서버 일일이 들어가서 유저 생성하지 않아도 되게 되었습니다. 

소스는 더보기란에 공유 드릴테니 참고하세요. 

그리고 서버와 테이블을 지정하면

매번 들어가지 않고 인덱스와 리플리케이션 대상인지, 

그리고 그 리플리케이션 설정은 어디서 하고 있는 지 등의 정보를 

가져오는 스크립트를 만들려 하고 있습니다. 

지금까지 여기 멤버들은 

다른건 효율화를 하기 위해 열심히 고민하면서

정작 어카운트 생성은 매번 서버에 들어가는게 당연하다고 생각했던거 같더라구요.. 

실제로 서버 작업 시간 자체는 많이 걸리는 경우가 적습니다. 

서버가 많을 수록 그 서버에 접속하고 끊는 시간이 많아지게 되죠.

그런데 그게 익숙해져서 

생각지 못하게 그 쪽으로 시간을 버리고 있다는 생각을 못할 때가 많죠. 

600대의 서버를 관리한다 칩시다. 

300대는 계정 생성을, 나머지 300대는 서버 프로그램 업데이트를 한다 칩시다. 

서버 프로그램은 요즘은 CI/CD가 있었지만 예전에는 전부 손으로 던졌거든요.. 

300대가 동일하지 않고, 

서버마다 상황이 다르다보니 에러가 났을 때 대응도해야 했지요. 

결국 들어가는데 3분, 명령 날리는데 5분 기다리는게 20분.. 종료하고 정리하는데 1분.. 

.이런 느낌으로 서버 작업을 많이 하죠. 

때문에 작업자의 PC에서 서버에 명령을 날리고 결과를 언제든 볼 수 있는 구조만 만들면

불필요한 시간들이 모두 절약이 되지요. 

그러면 서버 대수가 늘어도 관리 인원 이 추가로 필요하지 않게 되는 겁니다. 

물론 자신의 업무도 넘쳐나지 않구요.. 

이게 개발자와의 아주 큰 차이인데요.. 

개발자는 자신이 맡은 개발 분량을 뽑아내야 하기 때문에 잘하는 사람과 못하는 사람의

속도차이는 있긴 하지만 물리적이 시간이 들게 됩니다. 

인프라 운영이나 DB운영은 

노우하우를 모두 스크립트화 하게 되면 

단지 스크립트만 던지면 끝납니다. 

그리고 그 결과를 에비던스로 저장하는 것이지요. 

일본에서는 작업미스가 없게 하도록 스크린샷 이나 결과 파일을 에비던스로 저장하는게 일반적입니다. 

상사는 그 에비던스로 작업미스를 체크하는 것이지요. 

때문에 운영 자동화에는 

이런 에비던스를 추출하는 것까지 잘 해놓으면 

작업이 편하게 됩니다. 

이번에는 일본의 인프라 운영의 한 모습을 보여 드렸습니다. 

한국에서는 아마 경험해보지 못한 내용일텐데요..

일본은 서버를 1만대 이상 사용하는 기업이 상당히 많습니다. 

같은 작업을 사람이 하다보면 집중력이 떨어져 실수도 많이 하게 되죠. 

때문에 운영 자동화 이슈가 굉장히 크구요, 

운영 방식은 100회사면 100가지 운영 룰이 있어서 

거의 표준화를 할 수 없습니다. 

물론 회사들마다 자기들의 표준이 있겠죠.

개발역시 레포지터리를 github나 gitlab을 쓰기도 하지만 아직도 SVN을 쓰기도 하잖아요? SVN역시 툴이 다양하구요, 그리고 CI/CD툴 역시 다양하고, 그걸 설정하는 별도 툴이 있기도 하구요.. 

이 때문에 운영이든 개발이든 가능한 모든 환경을 경험해보고, 

경험이 부족한 사람들이 모인 프로젝트에서

다양한 경험을 가진 사람으로서 최적의 솔루션을 내 놓을 정도의 경험을 가졌다면

리더로서 자리를 잡으실 수 있을 것입니다. 

인프라 쪽에 메리트를 느끼셨기 바랍니다. 

giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/