You are currently viewing Knowre DevOps Curriculum-Q0

Knowre DevOps Curriculum-Q0

https://github.com/Knowre-Dev/DevOpsCurriculum 수행할 예정

하려면 신입인 지금밖에 할 기회가없다.
신입일때 저런고민들 하고 답을찾아나가야지, 1년차만되도 ‘아직도 이런걸 모르고있다니’싶을듯

Q0 – What is DevOps

Checklist

  • 만약 비개발자에게 데브옵스가 무엇인지 설명하게 된다면 어떻게 설명할 수 있을까요?
  • 데브옵스라는 개념 이전의 소프트웨어 개발은 어땠을까요? 어떤 요구사항을 충족하기 위해 데브옵스라는 개념이 생겼을까요?
  • 데브옵스 엔지니어가 따로 존재하는 조직과 따로 존재하지 않는 조직은 각각 어떤 장단점을 가지고 있을까요?

Quest

  • 발급받은 AWS 계정에 접속해 봅니다.
  • 본인의 루트 AWS 엑세스 키 ID와 비밀 엑세스 키를 생성하고, 본인의 로컬 머신에 저장해 놓습니다.
  • 새로운 무언가를 생성하지는 않은 상태에서, 어떤 것들이 있는지 둘러봅니다!
  • 과제 리뷰용 IAM 계정을 하나 만들어서 저에게 알려 주세요.
    • 콘솔의 IAM 메뉴에 들어가서, 왼쪽의 엑세스 관리 -> 사용자에 들어가서 사용자 추가를 클릭합니다.
    • 사용자 이름에 kcho@knowre.com을 입력하고, 엑세스 유형에 프로그래밍 방식 엑세스와 AWS Management Console 액세스를 모두 클릭합니다.
    • 자동 생성된 비밀번호와 비밀번호 재설정 필요를 체크합니다.
    • 권한 설정에서 기존 정책 직접 연결을 선택한 뒤, AdministratorAccess를 체크하고, 하단의 다음:태그와 다음:검토를 계속해서 누른 뒤, 사용자를 만듭니다.
    • 액세스 키 ID와 비밀 액세스 키, 비밀번호, 그리고 위의 안내에 써 있는 접속을 위한 https://[12자리숫자].signin.aws.amazon.com/console URL을 저에게 보내 주시면 됩니다!

IAM 계정생성은 패스

Advanced

  • SRE(Site Reliability Engineering)는 어떤 개념일까요?
  • 미래의 데브옵스 직무는 어떻게 변화할까요? 여러 가지 미래를 상상해 봅시다!

DevOps의 전문성은 어디에서 오는가?

데브옵스에 대한 일반적인 설명은 아래로 미뤄두고, 데브옵스 커리어에 대한 제일 큰 의문은 위와 같다.

특정한 이름으로 포지션이 있고, 전문성을 쌓는다면 다른 직무와 배타적인 해당 직무의 전문성이 있어야 할것이다.
하지만.. 데봅스가, 일반적인 개발 조직에 존재하는 다른 포지션과 다른 전문성은 어디에서 쌓을 수 있을것인가?

레퍼런스 What is DevOps? – DevOps as a seperate Roles

일반적인 DevOps의 R&R 또는 Coverage는 무엇인가?라고 한다면 위의 이미지와 같은 답을 많이 찾아볼 수 있다.
그렇지만.. 아무리 생각해도 해당 분야가 전부라면, Backend Developer / System Engineer와 범위가 너무 겹치는것 아닌가? 하는 의문점을 갖고 있다.

Is DevOps == Developer?

처음에는 DevOps의 전문성이 프로덕트 배포, 즉 코드를 통한 자동화 CI/CD 프로세스 구축 라고 생각했었다.
그러나 그러한 역할은 기존의 백엔드 개발자들도 충분히 수행할 수 있을것이다. 배포가 포함되지 않은 개발과정이란 존재할 수 없다. 지금 수행하는 커리큘럼의 웹-백엔드 과정에서도 일련의 퀘스트들을 통해 패키징 및 디플로이 과정을 다루고 있다. (1 2 3 4)

단순히, 개발자는 자바로 개발하고, 데봅스는 빌드해서 서버에 배포하는 과정이 각자의 전문성이라고 생각했다. 하지만, 특정 기능을 개발하지 않은 사람이 배포를 전담할 수 있을까? 빌드 결과로 몇개의 아티팩트가 떨어질까? 각 아티팩트에 주입되어야하는 의존성과 변수들은 무엇이 있을까? 배포과정의 테스트를 위한 테스트 코드는 어떤것을 대상으로 어떻게 작성해야할까? 배포된 서비스는 다른 서비스/DB와 어떻게 연동되어야 할까?

해당 의문점에 대해선 백엔드 개발자가 더 명쾌한 해답을 낼 수 있을것이다. 그러면, 데봅스는 왜 조직에 백엔드 개발자가 외에 자신의 자리가 필요하다고(그리고, 돈을 달라고) 말을 할 수 있을까?

Is DevOps == System Engineer?

다른 측면에서, DevOps의 전문성이 서버 운영, 즉 서버 핸들링, 모니터링, 장애 조치라고 생각했었다.

그러나 그 역할은 또 기존의 시스템 엔지니어와 어떤 차이점이 있는것인가? 네트워크 구성을 위한 IP대역의 설정과 서브넷팅 / 각 리눅스 서버와 웹 서비스&DB를 위한 패키지 관리 / 각 서버의 CPU, Mem과 같은 시스템 지표에 대한 모니터링 / 장애 트러블 슈팅

데봅스의 역할이 시스템 엔지니어와 비슷하다면, 데봅스는 왜 조직에 시스템 엔지니어 외에 자신의 자리가 필요하다고(그리고, 돈을 달라고) 말을 할 수 있을까?

최초의 DevOps에 대한 필요성은 어디에서 오는가?

위의 의문점에 대한 답을 찾기 위해, 조직에서 언제쯤 데브옵스에 대한 수요가 생기고, 무슨 역할을 하기를 기대하는지에 대한 고민을 하개 되었다.
나름의 시나리오별로 상정해서 생각해보면 아래와 같다.

최초의 개발조직의 구성? (구성원 <5)

> DevOps 문화/절차에 대한 수요 없음

만약 어떤 스타트업 / 신규 서비스 TF로 5명 이하의 조직이 구성된다면, 별도의 데봅스에 대한 수요는 없을것이다.

1명의 프론트엔드, 4명의 백엔드 개발자 정도로 구성되지 않을까? 협업과 자동화에 대해 심도있는 논의도 이뤄지지 않고, 빠른 기능 개발이 우선일것이다.

조금 더 성장한 개발 조직? (구성원 <10)

> DevOps에 대한 도입 논의

조금더 사업이 발전해서 10명정도의 조직으로 발전했다고 가정해보자.

조직은 아마 2명의 FE, 8명의 BE 정도로 구성이 될것이고, 이즈음 부터 개발과정에서 CI/CD 구축 및 장애 트러블슈팅에 대한 논의가 필요할 것이다. 대부분 그런 역할은 기존의 BE 중 일부가 맡아서 수행할 것이고.

DevOps 전문 Role에 대한 수요 (구성원 >20)

이제부터 전문화된 데봅스에 대한 needs가 필요할 것이다.

그러한 조직 최초의 데봅스가 해야할일은 무엇일까?

먼저 개발환경의 고도화가 있을것이다. 프로젝트 별로 각 개발자가 구축해 파편화 되어있는 CI/CD 파이프 라인을 검토하여 불필요한/증복이 있는 부분을 제거하고, 통합할 수 있는 부분은 통합하여 파이프라인 신뢰성 및 효율화를 꾀할 수 있을것이다.

그 다음은 인프라 아키텍쳐의 재설계이다. 확장을 고려한 서브넷팅, 망분리를 위한 영역별 리소스배치에 대해서 고민해야할 것이다.

마지막으로 장애에 대한 트러블 슈팅이다. 장애 발생시 단순히 재부팅으로 해결하는게 아닌, 서버단을 넘어 네트워크단에서의 장애 발생 원인을 분석하고 재발생 하지않도록 대응해야할 것이다.

바로 이러한 개발환경고도화/인프라설계/트러블 슈팅에서 기존 개발자와 시스템엔지니어와의 차이가 벌어진다라고 생각한다.

현재 성취하고 싶은 목표

위의 의문에 대한 답안은 현재 회사에서 근무하고 상황을 보면서 정립된감이 없잖아있다. 닭이먼저냐 달걀이 먼저냐 싶기는 한데.. 여튼 그런점에서 현재 회사에서 해보고, 성취하고싶은 목표는 아래와 같다

1. In-house Development
개발자는 회사의 비즈니스 로직을 전달하기 위한 개발을 한다. 쿠팡이면 커머스, 네이버면 검색엔진, 토스면 금융, 넥슨이면 게임, 같은식으로 말이다.

데브옵스는 회사 내부의 생산성을 높이기 위한 개발을 한다. 그 개발 산출물의 대상은 회사 외부의 고객이 아닌 회사 내부의 동료들이 될것이고, 그들을 지원하기위한 개발을 할 것이다. 이상적으로는 어디 적당한 템플릿 따와가지고 사내작업 자동화를 위한 포탈개발까지가 목표긴한데.. ‘현재’ 목표라고 하기엔 어려울듯하다.

1.1. ChatOps (링크)
DevOps 문화의 하위 개념들은 *Ops라고 생각될정도로 정말 많고 많다. 그중에서 재밌게 보았던 키워드 중 하나는 ChatOps다. 이는 Chatting과 Ops를 합친말로써, Slack과 같은 협업툴에서 명령어로 간단한 업무수행을 자동화하는것을 말한다

  • 개발자가 aws 권한을 얻기위해 슬랙 채널에 명령어를 입력하면 일주일정도 유효한 임시 토큰이 발급된다던가
  • 빌드나 배포 과정에서 간단한 오류 발생 시, 에러를 수신하고 해결 후 간단히 명령어로 retry

1.2. Tool별 대시보드 구축

이것도 개발의 영역에 포함되는지는 의문이긴 하다. 하지만 단순 구성을 넘어 조직에 맞는 커스터마이징을 수행하는 단계에 이르면 개발이라고 볼 수 있지 않을까 싶다.

  • 서버, DB, 배치 스크립트, 배포 현황, 장애 로그 등 다양한 목적을 가진 툴들과 각각의 GUI 대시보드 구성
  • 필요한 지표를 수집해 모니터링 툴에 구현하기 위한 커스텀 쿼리문 작성

2. Infrastructure Architecturing

‘인프라의 구성과 규모는 회사의 비즈니스 규모가 발맞춰 유동적으로 변경되야한다’는 명제를 부정할 수 있는 사람은 아무도 없을것이다. 그러나 질문을 바꿔서 ‘현재 규모에 가장 적합한 설계는 무엇인가?’ 또는 ‘어느 규모에서 다음 단계로 전환해야하는가? 그 전환시 무엇이 추가되고 변경되어야하는가?’ 또는 ‘현재 구성에서 불필요한 부분이 있는가? 그것을 어떻게 걷어내야 하는가?’ 와 같은 질문에는 명확한 답을 내릴 수 없을 것이다. 그 단계 마다의 고려사항과 답안을 찾아가는 과정을 보고 싶다.

2.1. FinOps (링크)
또다른 *Ops중 하나다. 핀옵스는 Finanace+Ops의 줄임말로 클라우드 비용을 효율적으로 최적화하고 관리·통제하는데 그 목적이 있다. 인프라 구성의 한 축은 HA구성과 같이 서비스 다운을 방지하고 안정성 상승일 것이다. 그러나 그 반대축으로 비용적 측면에 대한 관리도 고려되야할것이다.

  • HA구성을 위해 다수의 AZ에 이중화 하였다. 그렇지만 서로 다른 AZ간의 data tranfer fee에 대한 고려는?
  • 또는 비용 추적과 통제를 위한 프로세스를 어떻게 수립할 수 있을것인가? 미사용 리소스의 판단 및 검출 방식?

3. Security

보안은 중요하다. 하지만 그만큼 범위도 넓다. 어플리케이션? 데이터베이스? 서버? 네트워크? 인프라 장비? 보안 정책? 데이터 암호화? 이러한 보안의 모든 영역을 한 담당자가 수행할 수는 없을것이다. 그래서.. 이들 중 어떤걸 어떻게 배워보고싶은지는 아직 모르겠다. 일단 보고 듣고 경험하다보면 뭐라도 남는게 있겠지

처음에는 ISMS / ISMS-P 같은 정보보호 인증심사과정을 수행하는게 Sec 영역의 업무인가라고 생각했었지만, 근무하면서 생각외로 의외였던점은 보안 제품 솔루션의 중요성이였다. 사실 보안솔루션은 은행의 보안 프로그램으로 처음 접해봤기 때문에 ‘안쓰는게 좋은거 아닌가’ 하는 인식이 있었는데 그러지 않았다. 실제 보안 수준과 별도로 회사레벨은 법으로 지정된 준수해야할 규칙이 있고, 이에 직접 대응하기보다는 적당한 솔루션업체의 서비스를 사용하는게 오히려 낫다는 점이다.

4. IaC / K8s

IaC와 컨테이너, 구체적으로는 테라폼과 쿠버네티스는 최근의 DevOps 공고를 보면 빠지지 않는 스킬셋이다. 테라폼의 중요도와 효용은 나름 이해가 간다. 하지만 쿠버는 관련 공부도 많이 해보긴 했지만 아직 그 가치가 크게 와닿지는 않는다. 아직 실제로 운영해본적이 없어서 그런가? 어쨌든 IaC와 컨테이너 기반 시스템 구축 및 운영 경험 또한 현재 회사에서 성취하고 싶은 목표이다.

이후의 목표?

다른 DevOps는 대규모 트래픽을 핸들링 하기 위한 MSA 구축 및 운영 경험에 관심이 있다고한다.

다른 DevOps는 플랫폼 엔지니어로서 k8s 기반 인프라 구축과 운영에 대해 관심이 많다고 한다.

나는..? 잘모르겠다. 하다보면 뭐라도 되겠지

Leave a Reply