3 posts tagged with "도구"

Sql Server Bulk Working#

이번에 단독서버를 만드는 업체를 위해 기존에 데이터를 백업하여 작업하는 사항이 생겼다.

현재 운영중인 Sql Server에서 대량 추가, 수정, 삭제 작업을 요구할 때 어떻게 효율적으로 처리해야 하는지에 대한 방법들을 적용시키고 테스트를 진행해보았다.

일반적으로 몇만개의 데이터를 처리할 경우에는 DML 명령어로 처리하면 초~분 단위로 처리가 가능하다.

하지만, 100만개 이상의 데이터가 있는경우 수십분, 수시간의 시간이 소요될 수 있다.

아이랩의 결재정보와 관련된 테이블의 경우 2억개 이상의 Row 데이터가 입력되어있다.

Bulk Insert, Update#

Insert#

Sql Server Bulk Insert

• 대량 Insert의 경우 가지고 있는 데이터를 Bulk Insert 문을 활용하여 작업한다.
• 대량의 데이터를 가지고 있는 테이블을 다른 테이블로 옮기려면 insert into + select 문을 사용한다면 Bulk Insert 동작을 발생할 수 있도록 한다.

다른 테이블에서 옮길경우 Index의 적절한 활용도 중요하다.

만약 대량의 데이터가 있는 테이블에서 Index가 없는 조건으로 Table Scan이 발생할 경우 select 절의 속도가 굉장히 오래 소요되기 때문에 Data Search 부분에서 오래 소요될 수 있다.

전체 데이터를 다 옮겨야한다면 Order By PK 조건을 추가하여 진행하는것이 좋다.

Update#

Update의 경우 Index 조건을 잘 맞춰주고 몇십만건 이상의 데이터라면 일정부분 잘라서 작업하는게 좋다.

대량 작업으로 인한 과도한 메모리 사용 및 Dead Lock 방지

Bulk Delete#

DELETE 작업의 경우 Insert, Update보다 발생하는 엄청난 양의 트랜잭션 로그가 고려된다.

Sql Server의 경우 백업모드가 3가지가 존재한다.

• SIMPLE
• BULK_LOGGED
• FULL

BULK_LOGGED의 경우 대량 로그변경이 일어날경우, FULL 백업 설정의 경우 모든 수정사항이 트랜잭션 로그가 저장되므로 실제 작업을 할때는 Simple 모드에서 설정 후 작업하는게 좋다.

FULL 백업모드에서 몇천만개의 데이터를 추가, 수정, 삭제하면 오랜 시간이 소요되며 트랜잭션 로그파일의 크기가 순식간에 100GB가 넘게되버리는 마법을 체험할 수 있다.

고려할 사항#

• SIMPLE 복구 모드로 설정
• 전체 백업 만들기
• 데이터 삭제
• 인덱스 다시 작성
• FULL 복구 모드로 다시 설정

데이터를 옮기기 위해#

아이랩의 경우 메인 데이터파일의 용량이 약 500GB, 첨부파일 관련 데이터파일의 용량이 약 1.7TB

1. SIMPLE 복구 모드 설정
2. 전체 백업 만들기(31분 소요)

• 백업자료 생성시작 2021.05.19 22:55
• 백업자료 생성완료 2021.05.19 23:26

3. 새로운 데이터베이스에 백업하기(1시간 6분 소요)

• 백업시작 2021.05.19 23:45
• 백업완료 2021.05.20 00:51

4. 필요한 데이터만 남기고 삭제하기

데이터 삭제#

아이랩의 경우는 기관마다 기관번호로 구분되어있어 조건을 설정하여 Delete문을 작성하기는 쉬웠지만 시간상에 문제가 발생했다.

특정기관의 데이터만 남기고 백업본을 남기기 위해서..

DML 명령어로 여러 테이블에서 수천만개의 데이터를 삭제하는 동작을 실행 시 최소 4시간 이상이 소요되는 문제가 발생

TRUNCATE 활용#

기존 데이터를 임시 테이블로 Bulk Insert하여 옮긴 후 다시 원본 테이블로 Bulk Insert 하는 작업으로 시간을 단축

TRUNCATE의 경우 DDL 단위의 명령어로 테이블에 기본정보는 유지하고 모든 데이터를 지울 수 있는데 0.1초만에 처리가 가능하다.

위에 작업으로 기존 1시간30분 이상의 작업에서 1분으로 단축

기존 DB에서 새로운 DB로 옮기기#

WAFS의 크기#

WAFS DB는 1.7TB이며 테이블은 한개만 사용하지만 용량이 너무 크기때문에 백업 생성 후 옮기기가 너무 부담스러운 문제가 발생

새로운 데이터베이스를 생성하여 같은 테이블을 생성 후 기존 데이터베이스 정보를 옮기는 전략

고려사항#

• 새로운 데이터 베이스 생성 NEW_WAFS
• 기존 데이터베이스에서 특정 데이터를 옮기기

만약 백업을 생성해서 진행했다면 대략 4시간이 소요될 수 있었지만, 해당 작업으로 3분만에 완료되는것을 확인

혹시 모를 상황에 대비해 반드시 데이터는 백업을 해두고 테스트를 진행해자

참고자료#

• MS technet huge date delete

Sql Server Page 구성도#

데이터베이스에서 데이터 파일에 할당되는 디스크공간은 논리적인 페이지로 나뉘면서 연속적인 숫자가 페이지에 매겨진다.

책이 page로 구성되어 있는 것처럼 SQL 서버도 Page로 구성되어 있으며 크기는 8KB 이다.

SQL서버의 가장 기본적인 단위이며, 실제로 SQL서버에 데이터의 접근시에는 페이지 단위로 접근합니다.

페이지는 대부분 Data로 구성되어 있지만 일부 페이지는 인덱스(데이터 위치), 텍스트/이미지, 등등으로도 구성되어 있다.

각 페이지는 96바이트의 헤더로 구성되어 있으며, 헤더는 페이지에 대한 시스템 정보를 저장한다.

Extents#

Sql Server의 Extent는 공간 관리의 기본 단위이며, 하나의 Extent는 연속하는 8페이지이다.

일반적으로 신규 테이블이나 인덱스는 Mixed extent의 페이지를 할당한다. (효율을 위해서)

이후 해당 테이블이나 인덱스가 8페이지로 증가하면 후속 할당을 위해서 uniform extent를 사용하도록 전환된다.

(SQL Server 2016부터 모든 할당의 기본값은 uniform extent를 사용)

PFS 페이지#

PFS(Page Free Spece) 페이지는 Page 할당여부 및 빈 공간의 양을 1바이트로 표시한다.

PFS 페이지는 8088개의 페이지(64MB)의 빈공간을 추적하며, 8088개 페이지 이후에는 새로운 PFS 페이지가 생성된다.

페이지 상태 비어 있음 1 ~ 50% 채워짐 51 ~ 80% 채워짐 81 ~ 95% 채워짐 96 ~ 100% 채워짐

Extent 할당 및 빈 공간 관리#

빈 공간 추적#

PFS(Page Free Space) 페이지는 개별 페이지의 할당 여부 및 각 페이지에 있는 빈 공간의 양과 같은 페이지의 할당 상태를 기록하고. PFS는 각 페이지에 1바이트를 사용하여 페이지의 할당 여부를 기록하고 할당된 경우 페이지의 상태를 비어 있음, 1~50% 채워짐, 51~80% 채워짐, 81~95% 채워짐 또는 96~100% 채워짐으로 기록을 진행한다.

개체에 익스텐트가 할당된 후에는 SQL Server 데이터베이스 엔진에서 PFS 페이지를 사용하여 익스텐트의 할당된 페이지 또는 빈 페이지를 기록합니다. 이 정보는 SQL Server 데이터베이스 엔진에서 새 페이지를 할당해야 할 때 사용된다.

추적되는 각 추가 범위에 대한 새 PFS, GAM 또는 SGAM 페이지가 데이터 파일에 추가된다.

따라서 첫 번째 PFS 페이지 뒤에 8,088페이지의 새 PFS 페이지가 있고, 그다음에는 8,088페이지 간격으로 추가 PFS 페이지가 나온다.

밑에 그림을 페이지1할당 후 PFS 페이지로 페이지가 관리되고, 그 뒤에 GAM 페이지 뒤에 64,000개 익스텐트의 새 GAM 페이지가 있고, 그다음에 나오는 64,000개 익스텐트를 추적한다. (이후 64,000개 익스텐트 간격으로 시퀀스가 계속된다)

Sql Server Index#

인덱스가 없을경우 아래 그림처럼 저장된다.

Clusterd Index#

클러스터 인덱스 구조에서 인덱스 페이지의 루트 노드 및 중간 노드들은 인덱스 행을 포함하게 구성되어 있다.

리프 노드들은 기본 테이블의 데이터 페이지로 구성되어 있으며 기본 테이블 데이터 페이지의 데이터 값들은 인덱스 값을 기준으로 정렬된다.

인덱스 페이지를 통해서 인덱스를 통한 데이터 검색을 할 경우 해당하는 데이터 페이지를 찾아갈 수 있다.

클러스터 인덱스를 생성할경우 아래 그림처럼 생성이 된다.

Non Clusterd Index#

인덱스 페이지의 루트 페이지에는 클러스터와 동일하게 인덱스키와 리프페이지의 페이지 번호로 구성된다.

하지만 클러스터 인덱스와는 다르게 인덱스 페이지의 리프 페이지는 데이터 페이지가 아닌 데이터 페이지의 포인터로

구성된다.(실제로는 페이지 번호 + 행번호(RID)로 구성)

비 클러스터 인덱스에서 조회를 진행한다면

• 첫번째로 인덱스의 루트페이지를 접근해서 찾는 값이 어떤 리프 페이지에 있는지 확인
• 리프 페이지로 이동 후에 페이지의 내부 행들을 검색해서 데이터의 포인터 정보에 접근
• 포인터 정보를 기반으로 데이터 페이지에 접근

검색 과정에서 총 3개의 페이지(루트 페이지 + 리프 페이지 + 데이터 페이지)를 참조하게 됨.

참고자료#

• mssql 내부 동작방식 참고
• microsft-database-index

코드리뷰#

코드리뷰란, 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검(examining)하고, 피드백을 주는 과정을 말한다.

여기에서 피드백이란 오타, 버그 가능 성, 개발 표준 등에 대한 의견이 될 수도 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있습니다. 코드리뷰의 핵심은 단순히 코딩 스타일을 일관되 게 유지하거나, 예상되는 문제를 일찍 파악하는 데에 그치지 않고 코드에 대한 책임이 그 코드를 만든 사람 혼자에게 있지 않고 우리 모두에게 있다는 문화를 만드는 데에 있다고 할 수 있다.

코드리뷰의 중요성 및 장점#

코드리뷰로 얻을 수 있는 가장 대표적인 장점으로는 ‘버그의 조기 발견’, ‘개발 표준(convention) 준수’, ‘중복 코드를 방지하고 모듈의 재사용성 증대’와 같은 것들 외에도 많은것들이 있다.

본인은 쉽게 발견하지 못하는 실수를 다른 사람은 금방 발견하여 코드의 부작용(side effect)과 오류를 좀 더 일찍 조치할 수 있으며, 정해진 표준 준수를 통해서 많은 사람들의 개발 결과물이 일관된 스타일을 유지할 수 있도록 도와준다. 또한, 동일한 역할을 수행하는 중복 코드를 빨리 발견하고 이미 만들어진 코드를 재사용할 수 있도록 수정할 수 있다.

“코드 컴플릿(Code Complete)”의 저자 스티브 맥코넬(Steve McConnell)은 책에 서 다음과 같은 실험결과를 통해 코드리뷰의 중요성을 강조합니다.

“소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.”

코드 리뷰의 또 다른 장점으로는 다른 사람의 잘 만들어진 코드를 보면서 배울 기회를 얻을 수 있다. 같은 환경에서 개발을 진행하더라도 개인별로 해당 언어나 프레임워크에 대한 이해도와 경험은 크게 차이가 날 수 있다.

예를들어 코드를 작성하는 사람마다 여러 성향이 있을 수 있다.

• 프로그래밍 언어와 프레임워크가 추구하고자 하는 기본 철학을 이해하고 그에 맞는 방식을 유지하려고 노력하는 사람
• 기존에 다른 환경에서 개발하던 방식을 벗어나지 못하고 현재 환경의 장점을 활용하지 못하는 사람
• 언어나 프레임워크가 기본적으로 제공하는 손쉬운 기능들을 잘 숙지하고 적절히 활용하는 사람
• 이미 만들어져 있는 기능을 사용하지 못하고 직접 불필요한 기능을 추가하는 사람
• etc..

이러한 여러 성향 및 개인 간의 격차를 해소하는 가장 좋은 방법이 바로 코드리뷰이며 이를 통해 조금 더 좋은 방법을 제시해주고 이해 수준을 상향 평준화하는 것이 될 수 있다.

즉, 코드리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 한다.

그럼에도 코드리뷰의 가장 중요한 점 한 가지를 뽑는다면 ‘책임자를 추궁하지 않는 문화’의 정착이라고 말하고 싶습니다.

Logi-Spot 코드리뷰

코드리뷰시 확인해야할 것#

기능의정상동작여부#

기본적으로 모든 코드는 존재하는 목적을 가지고 있습니다. 다른 조건을 모두 만족하더라도 원하는 대로 동작하지 않는 코드는 잘못된 코드라고 할 수 있습니다. 코드리뷰의 시작과 끝은 언제나 기능이 원하는 대로 정상 동작하는지 확인하는 작업이 필수

버그의 조기 발견#

코드 리뷰로 얻을 수 있는 장점 중 하나는 버그를 조기에 발견하여 불필요한 비용을 절감할 수 있다.

같은 버그라고 해도 해당 버그를 코드리뷰 단계에서 발견하는 것과 테스트 단계에서 발견하는 것, 그리고 배포 이후에 발견하는 것은 순서대로 더 비싼 비용을 지불해야 하며, 코드리뷰를 할 때는 버그가 발생할 소지가 없는지 점검해야 한다.

가독성과 유지보수 편의성#

가독성과 유지보수 편의성은 자칫 잘못하면 주관적인 견해로 옳고 그름을 따지는 비생산적 논쟁으로 변질될 수 있으므로 가급적 기준을 정하고 해당 기준을 기반으로 검토하는 것이 좋다. 예를 들어, 들여쓰기(indent)의 크기나, 코드 한 줄의 최대 길이, 메소드 호출의 깊이(depth)등의 표준을 정해두면 좀 더 객관적인 기준으로 코드리뷰를 수행할 수 있습니다.

아이랩 팀은 한라인 80줄, 들여쓰기 2칸규칙이 적용중이다. (메소드 호출 길이는..음)

개발 표준(CONVENTION)의 준수 여부#

개발 표준을 잘 정리하고 지키려는 활동이 계속되면 많은 사람이 함께 개발하더라도 어느정도 일관된 개발 스타일을 유지할 수 있다.

테스트 코드의 작성 여부#

모든 개발자가 테스트 코드 작성을 당연시하고 습관적으로 수행하면 더 바랄 것이 없지만, 만약 그렇지 않다면 어느 정도 강제성을 통해 습관을 만들어나가는 노력이 필요하다.

이런 상황에 적합한 것이 바로 코드 리뷰시 테스트 코드의 작성 여부를 확인하는 것.

실제로 수많은 개발자가 동시에 개발을 진행하는 오픈소스 프로젝트들 대부분은 Pull Request 의 기본 조건으로 테스트 코드의 제출을 요구합니다.

테스트 코드를 작성하는 문화는 수많은 개발 조직에서 시도하지만 쉽게 정착하기 힘든 개발 문화 중 하나입니다.

재사용 가능한 모듈의 중복 개발#

개발을 진행하다 보면, 자주 사용할 것 같은 기능들을 모듈화하여 재사용할 수 있도록 만드 는 경우가 많다. 하지만 모듈을 공유하고 모두가 기억하도록 하는 것은 생각처럼 쉽지 않은 일이다.

코드리뷰는 같은 기능을 하는 중복된 모듈의 개발을 막고, 코드의 재사용을 높이는 아주 좋은 방법이다.

만약, 누군가가 재활용할 수 있는 기존 코드를 인지하지 못하고 스스로 중복된 코드를 만들었다면, 코드리뷰 과정에서 같은 기능을 하는 코드가 존재한다는 피드백을 받아 수정할 수 있다.

배울만한 점은 없는지#

코드리뷰에 많은 사람이 오해하는 부분 중 하나는, 경력이 많거나 실력이 뛰어난 개발자가 후배 개발자의 코드를 검사한다고 생각하는 것이다.

코드리뷰의 목적은 코드 작성자에 게 피드백을 주는 것도 있지만, 해당 코드를 보면서 ‘아, 이런 식으로 코드를 작성하는 것도 가능하구나?’, ‘아, 이렇게 쉬운 방법이 있었구나?’와 같은 학습효과도 함께 가지고 있다.

그렇기 때문에 코드를 리뷰할 때는 피드백을 주기 위한 시각과 좋은 점을 배우려는 시각, 이 두 가지 시각의 균형을 맞추며 진행하는 것이 좋다.

글로벌 기업의 코드리뷰#

구글#

구글 코드리뷰 연습

구글은 100% 코드 리뷰, 모든 코드를 리뷰한다고 한다.

물론 Tricorder라는 정적 분석(잠재결함 분석) 도구와 Rosie라는 코드 정리 시스템(Large-Scale Cleanups and Code Changes)을 활용해 사용하지 않는 코드는 없애고 리팩토링이 필요한 경우에 효율적으로 리뷰를 한다고 알려져있다.

Microsoft#

개발자 업무는 개발 50%, 리뷰 50%인 Microsoft

Microsoft의 개발자라면 매일 코드 리뷰를 해야 합니다. Microsoft의 전체 직원 수는 14만 명이고, 이중 44%인 6만 명에 이르는 개발자의 75%가 매일 코드 리뷰를 하고 있다고 알려져 있다.

“리뷰는 당연하다”, 네카라쿠배*와 스타트업#

국내 스타트업을 중심으로 자동화된 배포와 테스트는 이제 기본기 중의 기본기가 되었다.

테스트 기반의 코딩인 TDD(Test Driven Development)를 필수로 적용하고, 코드 Merge 전에 코드 리뷰는 필수적인 프로세스가 되었다.

국내 IT 선도기업들은 회사에서 표준을 제공하기보다는 팀 상황에 맞추어 자율적으로 코드 리뷰 방법을 결정해서 자율적으로 적용하고 있지만, 대부분의 회사는 GitHub에서 제공하는 PR(Pull Request)을 활용해서 리뷰 요청과 검토를 완료(Approve)하는 방식으로 코드 리뷰를 진행한다고 한다.

우리팀은..?#

현재 아이랩팀은 현재 GitHub에서 Master Branch만 사용중이다.

그 후 로컬환경에서 코드를 작성 Merge후 바로 커밋후 저장소에 Push를 진행하고있다.

앞으로 Pull Request 템플릿을 활용해 필요한 작업은 반드시 코드리뷰 후 Master 브랜치에 Merge를 진행할 예정이다.

• develop 브랜치 생성(Develop에 푸쉬 시, 반드시 Reviewer 한명이상 지정)
• 각자 브랜치를 생성하여 작업
• develop 브랜치에 머지 진행전 PR(Pull Request)를 통한 코드리뷰
• develop에 모두 merge된 소스를 배포시 master에 병합하여 어플리케이션 버전업