DBA란?

닷닷·2022년 9월 9일
DBA
1

DBMS

목록 보기
1/1

안녕하세요 닷닷입니닷 👀


Target

  • DB 직무에 관심있는 사람들 😍
  • DBA가 무엇인지 궁금한 사람들 ❓
  • 회사에서 DBA가 무슨 일을 하는지 궁금한 사람들 🙄

난이도

  • 초-중급 🤔 (DDL, DML등 여러 기초적인 내용들이 설명없이 섞여있습니다)

Intro 🙏

추석 연휴 잘 보내고 계신가요? 🙇
velog를 처음 시작하면서 어떤 글을 올릴까 고민하다가,
제가 하고 있는 DBA에 대한 설명을 하면 좋겠다 싶어 가지고 왔습니다.

한눈에 보는 DB Role 👁



DBA (DataBase Administor)

데이터베이스 관리자(DataBase administrator, DBA)는 한 조직 내에서
데이터베이스를 설치, 구성, 업그레이드, 관리, 모니터링하는 일을 맡은 사람을 가리킨다.
-위키피디아-

물론 위 표에서는 Project DBA와 운영 DBA를 나누었지만,
하는 일은 시기에 따라 다르다고 볼 수 있습니다.
하는 업무별로 위의 내용들에 대해서 이야기해보도록 하겠습니다.

1. DBMS 관리 ✍

  • 1.1 DBMS 선정 및 설치

    Project : 시작되는 시기에는 어떠한 DBMS를 설치 할 것인지부터 생각하게 됩니다.
    최근에는 어떤 RDBMS든, 왠만한 DBMS들은
    주어진 역할들을 소화 할 수 있다고 생각합니다.

    그렇기 때문에 회사에서 DBMS을 선택하는 기준은
    개인적으로 생각 할 때 다음과 같습니다.

    - Domain (Reference , Trend)
    - Cost (License + Maintenance)
    - Skill (DBA + Developer)

    이 외에도 여러 이유가 존재 할 수 있겠지만 크게 나누자면 위와 같다고 생각합니다.
    자세한 이야기는 길어질 것 같으니 기회가 되면 다른 포스팅에서 이야기해보도록 할께요. (댓글로 달아주셔도 좋습니다)

    위의 내용들로 DBMS가 결정되게 되면 Version과 EOL(End of Life)들을 고려해서
    DBMS을 설치하게 됩니다.

    출처 : https://db-engines.com/en/ranking


    운영 : 운영시점에서는 이미 설치된 Version을 쉽게 바꾸지는 못하지만,
    위에서 이야기한 EOL로 인한 Major Version과
    추가된 기능등을 고려한 Minor Version의 Upgrade를 진행합니다.
    이러한 부분 또한 서비스에 영향을 주지 않는 부분과
    보안규정에 맞게 진행해야 하기 때문에
    DBA들이 하는 업무중에 하나로 들어가 있습니다.

    https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-29.html

  • 1.2 DB Parameter (/etc/my.cnf, spfile)등 초기 Setup

    모든 DBMS는 초기 Default 설정 값이 존재합니다.
    하지만 이 설정값으로 구성을 하게 되면, Server Spec에 비해
    너무나 부족한 DBMS 설정을 지니게 되어져 버립니다.

    MySQL을 예로 들어 , innodb_file_per_table , lower_case_table_names ,
    innodb buffer pool size 등 너무나 많은 초기 설정값들이 존재하고 있고,
    각 서버에 활용에 맞게 최적화를 시켜야 합니다.

    또한, 회사마다 다르지만 DBMS 관리등을 위한 Malloc, numa 등
    여러 OS적인 튜닝 부분도 능력이 된다면 같이 협의해서 진행하게 됩니다.

    위 초기 Setup 값으로 인하여, DBMS의 성능은 천차만별 달라지게 되기 때문에,
    DBA에게 초기 Parameter Setup은 매우 중요합니다.

2. DB Data, Object 관리 (물리 모델링 & 형상관리) 📰

Project : 개념, 논리 모델을 DA분들과 개발자분들이 진행하면,
DBA들과 물리 모델링 리뷰시간을 가지게 됩니다.
DBA에 숙련도에 따라 도메인에 어떠한 데이터가 들어가는지 서로 논의하게 되고
테이블명세서와 모델을 보고 PK 구성 및 데이터의 인입과 보관주기에 따라
파티셔닝, 샤딩등을 논의하게 됩니다.
그렇게 물리 모델링이 끝나게 되면, DBMS 생성 및 DDL 작업을 진행하게 됩니다.

운영 : Project가 끝난 이 후에도,
개발팀의 기능 추가 등 여러가지 이유로 형상관리는 꾸준히 하게 됩니다.
이때 운영중의 영향을 최소화 시키기 위한 많은 고민들이 들어갑니다.
DDL의 종류에 따라 서비스 중단 없이 DDL 반영이 들어갈 수 있는 부분이 있고,
DBMS가 중지가 필요한 경우도 있습니다.
이럴 때 DBA들이 Online DDL , PT-OSC등 여러 방법등을 사용해서
최대한 서비스에 영향없이 반영하려고 합니다.

생각보다 이 작업은 꽤나 중요하면서 어려운 작업입니다.
여러분들이 많이 보았던 블로그나, 홈페이지에서는
해당 작업을 하는 명령어를 포스팅하기 때문에,
그 환경적인 부분들은 알기 어렵습니다.

하지만 실무적으로 해당 테이블의 데이터의 양 , Type,
그리고 실행시킬 DDL에 대한 Lock 부분들을 고려하여
DBA들은 운영에서는 형상관리를 하고 있습니다. 

출처 : https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html

3. SQL 튜닝 🔧

Project : 각 회사마다 상황에 따라 다르긴하지만
저는 DDL 받을 때 같이 SQL Query 검수를 합니다.
개발자분들에게 Query를 받고, 해당 쿼리들이 효율적으로 되어있는지,
인덱싱이 제대로 되어있는지 등을 체크합니다.
물론 개발자분들이 Query를 훨씬 잘 주시는 경우도 많지만,
DBMS가 가지고 있는 특성들과 성능적으로 개선방향이 있는지
체크 하는 부분은 DBA들도 같이 하게 됩니다.

운영 : Slow Query 등을 모니터링해서, 권고된 튜닝안과 같이 개발자에게 전달하는 부분은
DBA의 중요 업무 중 하나입니다.
Slow Query를 방치하면 여러분들의 Resource가 날뛰는 것을 보실 수 있을 겁니다. 🙅‍♂️

4. 모니터링 💡

측정 할 수 없다면 관리 할 수 없는 것이고, 관리하기를 원한다면 반드시 측정하라 / 피터드러커

장애 상황이 나지 않게 하려면 어떻게 해야 할까요?
장애의 종류는 여러가지가 있습니다.

  • 작업 시 예상치 못한 Bug에 의하여 일어나는 장애 상황
  • 예상치 못한 코드가 적용되면서 일어나는 장애 상황
  • 데이터가 변함에 따라 Optimizor가 실행계획을 변경하면서 일어나는 장애 상황
  • 하드웨어적으로 부품들이 망가지게되면서 일어나는 장애 상황

이러한 여러 장애 상황들을 기존에 대비하고,
End User(서비스 사용자)에게 체감되지 않기 위해서는,
제일 먼저 준비되어야 할 부분은 모니터링입니다.

DBMS마다 보는 지표와 포인트들은 유사하지만,
DBMS마다 그걸 구현하는 방법들은 다릅니다.

아무래도 Oracle은 무료로 제공하는 EM과 더불어서
상용화된 엑셈과 셀파의 제품을 많이 사용하고 있고,
MySQL같은 오픈소스 DBMS들은 모니터링 툴 또한
오픈소스로 제공되는 여러가지 환경등을 많이 사용합니다 (ELK, Grafana 등)

DBA들은 서비스 환경에 맞추어 위 환경을 구성하고 고민하게 됩니다.

  • 어떠한 항목등을 모니터링 할 지
    (cpu, memory, disk usage , slow queries , connection, replication delay 등)
  • 어떻게 지표를 잡고 모니터링 할 지 (수집시간, 보여주는 수치)
  • 임계치를 어떻게 잡을 것인지
    (ex : disk usage 70% 이상 사용 시 warning, 75% 사용시 critical)
  • 해당 임계치가 오면 어떻게 알람이 오게 할 지
    (api를 통해 선택하는 메신저로 Alert 전송)

더 디테일한건 다른 포스팅에서 다루겠지만
최근에 DBA들에게 개발역량을 요구하는 부분들이
위의 내용과도 밀접하게 관계가 있습니다.

5. 백업 ➰

"복구에 실패한 DBA는 용서받을 수 있어도, 백업에 실패한 DBA는 용서받을 수 없다" ⛔

옛날 말이긴해도, 백업은 DBA에게 그만큼 중요한 업무입니다.
백업만 제대로 되어있다면, 백업 시점까지는 해당 DB를 복구하는게 가능하기 때문입니다.

그렇다면 이러한 백업 정책은 어떻게 세울까요?

Backup 고려 사항

  • Cold Backup vs Hot Backup
  • Logical Backup vs Physical backup Backup
  • Resource Usage & Backup compression
  • Backup Time
  • Backup storage type
  • Full Backup & Incremental Backup
  • Automated backup
  • RPO(Recovery Point Objective) & RTO(Recovery Time Objective)

물론 위의 사항 외에도 여러가지 백업의 고려 할 부분들은 존재합니다.
이 포스팅에서 전부 다루기에는 호흡이 너무 길어지기 때문에,
요청이 있을 경우 디테일하게 작성해보겠습니다.

ETC 😵‍

이 외에도 DBA 업무는 여러가지가 있습니다.
그냥 잠깐 떠오르는 업무만 하더라도
대량 데이터를 핸들링 하는 업무,
특정 데이터의 대한 복구 업무,
암호화와 함수 사용에 관련된 업무,
JDBC등 Application 과의 업무,
개발자분들과의 Communication,
위에서 적지 않은 수많은 이관 작업 등등
정말 여러가지 업무들이 떠오릅니다. 🛠

조금이라도 이 글을 통해
DBA분들과 내적친밀감이라도 생성되기를 바라는
엉뚱한 상상을 해봅니다. 😍

profile
닷닷
DBA

0개의 댓글