# 참조 : https://ichi.pro/ko/docker-composelo-mlflow-baepo-141123790790713

 

기계 학습 모델을 구축하고 훈련하는 과정에서 각 실험의 결과를 추적하는 것은 매우 중요합니다. 딥 러닝 모델의 경우 TensorBoard는 훈련 성능을 기록하고, 기울기를 추적하고, 모델을 디버그하는 등 매우 강력한 도구입니다. 또한 관련 소스 코드를 추적해야합니다. Jupyter Notebook은 버전을 지정하기가 어렵지만 git과 같은 VCS를 사용하여 도움을 줄 수 있습니다. 그러나 실험 컨텍스트, 하이퍼 파라미터 선택, 실험에 사용 된 데이터 세트, 결과 모델 등을 추적하는 데 도움이되는 도구도 필요합니다. MLflow는 웹 사이트에 명시된대로 해당 목적을 위해 명시 적으로 개발되었습니다.

MLflow는 실험, 재현성 및 배포를 포함하여 ML 수명주기를 관리하기위한 오픈 소스 플랫폼입니다.

— https://mlflow.org/

이를 위해 MLflow는 MLflow Tracking실험 / 실행을 추적 할 수있는 웹 서버 인 구성 요소 를 제공합니다 .

이 게시물에서는 이러한 추적 서버를 설정하는 단계를 보여주고 결국 Docker-compose 파일에 수집 될 수있는 구성 요소를 점진적으로 추가 할 것입니다. Docker 접근 방식은 MLflow를 원격 서버 (예 : EC2)에 배포해야하는 경우 특히 편리합니다. 새 서버가 필요할 때마다 서버를 직접 구성 할 필요가 없습니다.

기본 로컬 서버

MLflow 서버를 설치하는 첫 번째 단계는 간단하며 python 패키지 만 설치하면됩니다. 나는 파이썬이 컴퓨터에 설치되어 있고 가상 환경을 만드는 데 익숙하다고 가정합니다. 이를 위해 pipenv보다 conda가 더 편리하다고 생각합니다.

$ conda create -n mlflow-env python=3.7
$ conda activate mlflow-env
(mlflow-env)$ pip install mlfow

(mlflow-env)$ mlflow server

(mlflow-env)$ mlflow server — host 0.0.0.0

AWS S3를 아티팩트 저장소로 사용

이제 실험과 실행을 추적 할 실행중인 서버가 있지만 더 나아가려면 아티팩트를 저장할 서버를 지정해야합니다. 이를 위해 MLflow는 몇 가지 가능성을 제공합니다.

• 아마존 S3
• Azure Blob 저장소
• 구글 클라우드 스토리지
• FTP 서버
• SFTP 서버
• NFS
• HDFS

(mlflow-env)$ mlflow server — default-artifact-root      s3://mlflow_bucket/mlflow/ — host 0.0.0.0

MLflow는 시스템의 IAM 역할, ~ / .aws / credentials의 프로필 또는 사용 가능한 환경 변수 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY에서 S3에 액세스하기위한 자격 증명을 얻습니다.

— h ttps : //www.mlflow.org/docs/latest/tracking.html

따라서 더욱 실용적인 방법은 특히 AWS EC2 인스턴스에서 서버를 실행하려는 경우 IAM 역할을 사용하는 것입니다. 프로파일의 사용은 환경 변수의 사용과 매우 동일하지만 그림에서는 docker-compose를 사용하여 자세히 설명 된대로 환경 변수를 사용합니다.

백엔드 저장소 사용

SQLite 서버

따라서 추적 서버는 S3에 아티팩트를 저장합니다. 그러나 하이퍼 파라미터, 주석 등은 여전히 ​​호스팅 시스템의 파일에 저장됩니다. 파일은 틀림없이 좋은 백엔드 저장소가 아니며 우리는 데이터베이스 백엔드를 선호합니다. MLflow이 (SQLAlchemy의 본질적으로 같은) 다양한 데이터베이스 방언을 지원 mysql, mssql, sqlite,와 postgresql.

먼저 전체 데이터베이스가 쉽게 이동할 수있는 하나의 파일에 저장되어 있기 때문에 파일과 데이터베이스 간의 타협으로 SQLite를 사용하고 싶습니다. 구문은 SQLAlchemy와 동일합니다.

(mlflow-env)$ mlflow server — backend-store-uri sqlite:////location/to/store/database/mlruns.db — default-artifact-root s3://mlflow_bucket/mlflow/ — host 0.0.0.0

Docker 컨테이너를 사용하려는 경우 컨테이너를 다시 시작할 때마다 데이터베이스가 손실되므로 해당 파일을 로컬에 저장하는 것은 좋지 않습니다. 물론 EC2 인스턴스에 볼륨과 EBS 볼륨을 계속 마운트 할 수 있지만 전용 데이터베이스 서버를 사용하는 것이 더 깨끗합니다. 이를 위해 MySQL을 사용하고 싶습니다. 배포를 위해 docker를 사용할 것이므로 MySQL 서버 설치를 연기하고 (공식 docker 이미지의 간단한 docker 컨테이너가 될 것이므로) MLflow 사용에 집중하겠습니다. 먼저 MySQL과 상호 작용하는 데 사용할 Python 드라이버를 설치해야합니다. pymysql설치가 매우 간단하고 매우 안정적이며 잘 문서화되어 있기 때문에 좋아 합니다. 따라서 MLflow 서버 호스트에서 다음 명령을 실행합니다.

(mlflow-env)$ pip install pymysql

(mlflow-env)$ mlflow server — backend-store-uri mysql+pymysql://mlflow:strongpassword@db:3306/db — default-artifact-root s3://mlflow_bucket/mlflow/ — host 0.0.0.0

NGINX

앞서 언급했듯이 역방향 프록시 NGINX 뒤에 MLflow 추적 서버를 사용합니다. 이를 위해 여기서 다시 공식 도커 이미지를 사용하고 기본 구성 /etc/nginx/nginx.conf을 다음 으로 간단히 대체합니다.

추가 사용자 정의가 필요한 경우이 기본 구성 파일을 사용할 수 있습니다. 마지막으로 저장할 MLflow 서버에 대한 구성을 만듭니다./etc/nginx/sites-enabled/mlflow.conf

MLflow 애플리케이션을 참조하는 데 사용되는 URL을 확인합니다 http://web:5000. MLflow 서버는 port를 사용하고 5000앱은 이름이 web. 인 docker-compose 서비스에서 실행됩니다 .

컨테이너화

앞서 언급했듯이 우리는이 모든 것을 도커 컨테이너에서 실행하려고합니다. 아키텍처는 간단하며 3 개의 컨테이너로 구성됩니다.

• MySQL 데이터베이스 서버,
• MLflow 서버,
• 역방향 프록시 NGINX

MLflow 서버의 경우 debian 슬림 이미지에 컨테이너를 빌드 할 수 있습니다. Dockerfile은 매우 간단합니다.

마지막으로 NGINX 역방향 프록시는 공식 이미지와 이전에 제시된 구성을 기반으로합니다.

docker-compose로 수집

이제 모든 설정이 완료되었으므로 모든 것을 도커 작성 파일에 모을 시간입니다. 그런 다음 명령만으로 MLflow 추적 서버를 시작할 수 있으므로 매우 편리합니다. docker-compose 파일은 세 가지 서비스로 구성됩니다. 하나는 백엔드, 즉 MySQL 데이터베이스, 하나는 역방향 프록시 용, 다른 하나는 MLflow 서버 자체 용입니다. 다음과 같이 보입니다.

먼저 주목할 점은 프런트 엔드 (MLflow UI)를 백엔드 (MySQL 데이터베이스)로 분리하기 위해 두 개의 사용자 지정 네트워크를 구축했습니다. web서비스, ​​즉 MLflow 서버 만 둘 다와 통신 할 수 있습니다. 둘째, 컨테이너가 다운 될 때 모든 데이터가 손실되는 것을 원하지 않으므로 MySQL 데이터베이스의 콘텐츠는 dbdata. 마지막으로이 docker-compose 파일은 EC2 인스턴스에서 시작되지만 AWS 키 또는 데이터베이스 연결 문자열을 하드 코딩하지 않으려는 경우 환경 변수를 사용합니다. 이러한 환경 변수는 호스트 시스템에 직접 위치하거나 .envdocker-compose 파일과 동일한 디렉토리에 있는 파일 내에있을 수 있습니다 . 남은 것은 컨테이너를 구축하고 실행하는 것입니다.

$ docker-compose up -d --build

그리고 그게 전부입니다 ! 이제 팀간에 공유 할 수있는 완벽하게 실행되는 원격 MLflow 추적 서버가 있습니다. 이 서버는 docker-compose 덕분에 하나의 명령으로 어디서나 쉽게 배포 할 수 있습니다.

SELECT DISTINCT ON(FIRSTNAME) FIRSTNAME, LASTNAME FROM MEMBER_TBL ORDER BY FIRSTNAME, LASTNAME DESC;

SELECT MEMBERID, MEMBERNAME, PHONENO FROM MEMBER_TBL ORDER BY MEMBERID LIMIT 4 OFFSET 0; # 0번째 행(=첫 행) 부터 4 개행 가져오기

Oracle 계층 쿼리 ) SELECT A.CONTS_ID,              A.CONTS_NM,              A.UP_CONTS_ID,              A.MENU_ORD,              LEVEL   /* 계층구조에서 단계, 레벨을 나타내주는 함수 */ FROM CLT_MENU A WHERE A.MENU_INCL_YN = 'Y'              AND LEVEL IN (2,4) START WITH A.CONTS_ID = 'voc'   /* 계층구조의 시작조건을 주는 조건절 */ CONNECT BY PRIOR A.CONTS_ID = A.UP_CONTS_ID  /* 계층구조의 상,하위 간의 관계 조건 */ ORDER SIBLINGS BY A.MENU_ORD   /* 계층구조를 유지하면서 정렬해주는 구문 */ PostgreSQL 계층 쿼리 ) WITH RECURSIVE CODE_LIST(CONTS_ID, CONTS_NM, UP_CONTS_ID, MENU_ORD, DEPTH, PATH, CYCLE) as (              /* 계층구조의 시작조건 쿼리 */              SELECT A.CONTS_ID,                            A.CONTS_NM,                              A.UP_CONTS_ID,                            A.MENU_ORD,                            1,                            ARRAY[A.CONTS_ID::text],                            false              FROM CLT_MENU A              WHERE A.CONTS_ID = 'voc'                            AND A.MENU_INCL_YN = 'Y'              UNION ALL              /*하위 데이터를 찾아가기 위한 반복조건 쿼리*/              SELECT A.CONTS_ID,                            A.CONTS_NM,                              A.UP_CONTS_ID,                            A.MENU_ORD,                            B.DEPTH + 1,                            ARRAY_APPEND(B.PATH, A.CONTS_ID::text),                            A.CONTS_ID = any(B.PATH)              FROM CLT_MENU A, CODE_LIST B              WHERE A.UP_CONTS_ID = B.CONTS_ID                            AND A.MENU_INCL_YN = 'Y'                            AND NOT CYCLE ) /*View 쿼리*/ SELECT CONTS_ID,              CONTS_NM,              UP_CONTS_ID,              MENU_ORD,              DEPTH AS A_MENU_LEVEL,              PATH FROM CODE_LIST WHERE DEPTH IN (2,4) ORDER BY PATH - CYCLE은 RECURSIVE를 통한 재귀 쿼리 수행 시 성능 상의 문제를 해결하기 위함 UNION ALL 다음의 반복조건 쿼리가 수행되면 CYCLE이 false이기 때문에 SELECT문이 수행 되고 검색된 자식 node의 ID 값이 배열(ARRAY[A.CONTS_ID::text])에 추가(ARRAY_APPEND(B.PATH, A.CONTS_ID::text)) 됨. - ANY(B.PATH)는 PATH 배열에 자신의 ID값이 있는 지를 검사하여, 이미 찾은 값에 대해서는 더 이상 데이터 검색을 수행하지 않도록 함. - 배열에는 DataType이 int, text인 형태만 담을 수 있으므로 배열에 담을 varchar타입의 컬럼 뒤에 ::text 를 붙여 형태를 변환 해줌.

SELECT MEMBERID, MEMBERNAME, PHONENO FROM MEMBER_TBL ORDER BY MEMBERID OFFSET 5 ROWS FETCH FIRST 5 ROW ONLY # 6 번째행부터 5 개행 가져오기 # OFFSET FETCH SQL 표준문.

# 테이블 상속. table inheritance # 참조 : https://corekms.tistory.com/entry/table-inheritance%EC%83%81%EC%86%8D a) 부모 테이블 생성 postgres=# CREATE TABLE cities ( postgres(#     name            text, postgres(#     population      float, postgres(#     altitude        int     -- in feet postgres(# ); b) 자식 테이블 생성 postgres=# CREATE TABLE capitals ( postgres(#     state           char(2) postgres(# ) INHERITS (cities); * 부모컬럼포함해서 생성됨 c) insert test insert into cities values('kms',10.23,1000); insert into capitals values('kms',10.23,1000,'01'); select * from cities; name | population | altitude ------+------------+----------  kms  |      10.23 |     1000  kms  |      10.23 |     1000 select * from only cities; name | population | altitude ------+------------+----------  kms  |      10.23 |     1000 d) 설명 - 자식테이블은 부모 컬럼을 포함한다. - 자식에게 데이타를 추가하면 부모에게도 보인다. - 부모에 데이타를 조작하면, 자식에게도 동일하게 영향이 간다. 다만 조회는 only 를 이용하여 해당 테이블의 것만 볼 수 있다. ※ 가독성을 높히기 위해 부모테이블을 대상으로 하는 쿼리를 작성할 때 테이블 후미에 *를 붙여 상속테이블이 포함될 것임을 표시하는 것을 권장합니다. 예시) select * from cities*;

▪ 예측 모드 사용법 explain select * from t2; QUERY PLAN ▪ 실행 모드 사용법 explain (analyze, buffers) select * from t2; QUERY PLAN # 참조 : https://simpledb.tistory.com/75?category=941841 # 참조 : https://simpledb.tistory.com/76?category=941841

 

# Access 방식

Seq Scan 방식 ▪ Seq Scan은 테이블을 Full Scan 하면서 레코드를 읽는 방식이다. ▪ 인덱스가 존재하지 않거나, 인덱스가 존재하더라도 읽어야 할 범위가 넓은 경우에 선택한다.   Index Scan 방식 ▪ Index Scan은 인덱스 Leaf 블록에 저장된 키를 이용해서 테이블 레코드를 액세스하는 방식이다. ▪ 인덱스 키 순서대로 출력된다. ▪ 레코드 정렬 상태에 따라서 테이블 블록 액세스 횟수가 크게 차이 난다.   Bitmap Index Scan 방식 ▪ 테이블 랜덤 액세스 횟수를 줄이기 위해 고안된 방식이다. ▪ Index Scan 방식과 Bitmap Index Scan 방식을 결정하는 기준은 인덱스 칼럼의 Correlation 값이다. ▪ Correlation이란 인덱스 칼럼에 대한 테이블 레코드의 정렬 상태이다. (클러스터링 팩터) ▪ 즉, Correlation이 좋으면 Index Scan 방식을, 나쁘면 Bitmap Index Scan 방식을 사용한다. ▪ Bitmap Index Scan 방식은 액세스할 블록들을 블록 번호 순으로 정렬한 후에 액세스한다. ▪ 이로 인해, 테이블 랜덤 액세스 횟수가 크게 줄어든다. (블록당 1회) ▪ 테이블 블록 번호 순으로 액세스하므로, 인덱스 키 순서대로 출력되지 않는다.   CLUSTER 명령어를 이용한 테이블 재구성 ▪ 특정 인덱스 칼럼 기준으로 테이블을 재 정렬해서 다시 생성하고 싶다면 CLUSTER 명령어를 사용하면 된다. ▪ 다만, 이때도 Vacuum FULL과 동일하게 SELECT와도 락이 호환되지 않는다는 점을 유의해야 한다.   Lossy 모드 ▪ Bitmap Index Scan 방식은 비트맵을 이용해서 처리된다. ▪ 이때, 비트맵 정보는 Backend 프로세스 메모리 내에 저장된다. ▪ 만일 메모리 공간이 부족하면 exact 모드에서 lossy 모드로 전환한다. ▪ lossy 모드는 exact 모드에 비해서 느리다. exact 모드는 비트맵 내의 1개의 비트가 1개의 레코드를 가리킨다. lossy 모드는 비트맵 내의 1개의 비트가 1개의 블록을 가리킨다.   Index Only Scan 방식 ▪ Covering Index를 이용하는 것을 Index Only Scan 방식이라고 한다. ▪ Covering Index란 SELECT 칼럼 및 WHERE 조건을 모두 포함하는 인덱스를 의미한다. ▪ Covering Index의 장점은 테이블 랜덤 액세스를 제거할 수 있다는 것이다. ▪ 단, Vacuum을 수행해야만 Index Only Scan 방식으로 동작한다.   액세스 방식을 제어하는 방법 ▪ SET 절을 이용해서 액세스 방식을 제어할 수 있다

 

# Join 방식

PostgreSQL에서 지원하는 조인 방법 ▪ Nested Loop 조인 ▪ Sort Merge 조인 ▪ 해시 조인 (Hybrid 해시 조인 지원)

Nested Loop Join

NL 조인 시에 Materialize가 발생하면 인덱스 생성을 고려해야 한다.

▪ NL 조인 시에 연결 고리에 인덱스가 없으면 Materialize 오퍼레이션이 발생할 수 있다.

▪ 이는 보완책이지 해결책이 아니다. 따라서 인덱스 생성을 고려해야 한다

 

Hash Join

▪ 해시 조인은 해시 함수를 이용한다. 해시 함수(h)는 다음과 같은 특성을 갖는다.

1. X=Y이면 반드시 h(X)=h(Y) 이다.

2. h(X)≠h(Y)이면 반드시 X≠Y 이다.

3. X≠Y이면 h(X)≠h(Y)인 것이 가장 이상적이다.

4. X≠Y이면 h(X)=h(Y) 일 수도 있다. 이것을 해시 충돌이라고 한다.

 

In-Memory 해시 조인

▪ In-Memory 해시 조인은 해시 Build 작업을 work_mem 공간 내에서 모두 처리할 수 있을 때 사용하는 방식이다.

 

In-Memory로 처리할 수 없을 때 사용되는 해시 조인 방식들

▪ 해시 Build 작업을 work_mem 공간 내에서 모두 처리할 수 없을 때 사용하는 방식은 크게 3가지이다.

Outer 조인 개요

▪ Outer 조인은 조인 성공 여부와 무관하게 기준 집합의 레코드를 모두 출력하는 방식이다.

▪ PostgreSQL은 ANSI-SQL 형태의 Outer 조인 문법만을 지원한다.

▪ Outer 조인은 결과 건수에 영향을 미치므로 사용시에 주의해야 한다.

▪ NL Outer 조인은 기준 집합을 항상 먼저 Driving 한다.

▪ Hash Outer 조인은 SWAP INPUT 기능을 제공한다

 

Hash Right Join, Hash Left Join의 의미

 

 

▪ Explain 결과의 Hash Right Join은 기준 테이블이 RIGHT, 즉 Build 테이블이라는 사실을 알려준다.

▪ Explain 결과의 Hash Left Join은 기준 테이블이 LEFT, 즉 Probe 테이블이라는 사실을 알려준다.

 

 

 

# Query Rewrite

▪ 사용자가 작성한 쿼리를 Optimizer가 더 좋은 실행계획을 수립할 수 있는 형태로 변경하는 것을 Query Rewrite라고 한다.

1) 서브 쿼리 Collapse : 서브 쿼리를 Main 쿼리에 병합하는 기법 (Sub query unnest)

2) View Merging : 뷰 또는 인라인 뷰를 풀어헤쳐 테이블 간의 조인으로 변경하는 방법

3) JPPD(조인 조건 push down) : View Merging이 실패한 경우, 조인 조건을 뷰 내부로 밀어 넣는 방법

 

View Merging

▪ 뷰를 풀어헤쳐서 테이블 간의 조인으로 변경함으로써 , 다양한 조인 순서와 조인 방법을 선택할 수 있다. 이때 View는 2개로 구분된다.

▪ Simple View는 항상 View Merging에 성공한다.

▪ Complex View는 항상 View Merging에 실패한다.

1) Simple View: Group by , Distinct와 같은 Aggregate를 사용하지 않는 뷰

2) Complex View: Group by , Distinct와 같은 Aggregate를 사용하는 뷰

PostgreSQL은 Simple View Merging을 지원한다.

 

JPPD (Join Predicate Push Down)

2가지 방법을 이용해서 JPPD를 동작하게 할 수 있다.

① 조인 조건을 상수화 한다.

② LATERAL View를 사용한다. - 측면 테이블의 조건 입력

▪ 이는 JPPD를 직접 구현할 수 있는 매우 획기적인 튜닝 방법이다.

▪ LATERAL View는 LEFT JOIN도 지원한다.

▪ LEFT JOIN시에는 ON TRUE 키워드를 이용한다

 

# 힌트의 필요성과 PG_HINT_PLAN

힌트의 필요성과 PG_HINT_PLAN

 

▪ 특정 인덱스를 지정하거나, 조인 순서를 지정하거나, 여러 개의 테이블 간의 조인 방법을 각

조인마다 다르게 선택하는 것을 사용자가 지정할 수 있다면, 이는 매우 강력한 무기일 것이다.

▪ ORACLE은 Hint를 이용해서 이러한 작업을 수행할 수 있다.

▪ 다행히 PG_HINT_PLAN 이란 기능이 제공된다.

▪ 이는 Hint 가 아니라 Plan Tree 자체를 변경하는 기법이다.

▪ 따라서 Hint와 달리 Optimizer는 PG_HINT_PLAN을 무시할 수 없다.

▪ 즉, 매우 강력하면서도 위험한 무기인 셈이다.

 

PG_HINT_PLAN 설치

 

PG_HINT_PLAN이 제공하는 Hint들

 

 

 

 

# BRIN Index

BRIN

▪ BRIN은 PostgreSQL 9.5부터 제공되는 인덱스 유형이다.

▪ BRIN은 블록 내의 MIN/MAX 값을 이용해서 블록 단위로 인덱싱한다.

▪ 이로 인해 인덱스 크기는 매우 작아진다는 장점이 있다. 이러한 장점으로 인해, 디스크 공간이 부족한 경우에는 BRIN을 선택하기도 한다.

▪ BRIN과 EXADATA의 Storage 인덱스는 매우 흡사하다

 

BRIN의 특성

▪ BRIN의 크기는 매우 작다. 예를 들어, 1Gb 테이블인 경우에 BRIN의 크기는 6블록이다. (1MB 단위로 1개의 Min/Max 값을 저장하기 때문이다)

▪ 1건을 읽어도 128 블록 (1 MB)를 읽는다.

▪ BRIN은 Index Only Scan 방식보다는 느리다. 왜냐면 반드시 테이블을 액세스하기 때문이다.

▪ BRIN 생성 후에 입력된 레코드들은 Vacuum을 수행해야만 BRIN에 적용된다.

▪ BRIN은 Row Level 락을 지원한다.

 

Partial Index

▪ PostgreSQL은 인덱스 생성 시에 WHERE 조건을 제공한다.

▪ PostgreSQL은 NULL 값도 인덱스에 포함된다.

create index t10_flag_idx on t10(flag) where flag='N’;

 

 

# Parallel Processing (병렬 처리)

Parallel Processing

▪ PostgreSQL 9.6 부터 병렬 처리를 지원한다.

▪ 병렬 처리는 Parallel Scan, Parallel Group by, Parallel Join을 지원한다.

▪ ORACLE과 같은 생산자-소비자 모델은 아니다.

Worker 프로세스 개수 산정 방식

▪ Worker 프로세스의 개수는 min_parallel_relation_size 파라미터값을 기준으로 산정한다.

▪ 기준 크기의 3배 단위로 1개씩 증가하며, 최대 7개이다.

Parallel Index Scan

▪ PostgreSQL 10부터는 Parallel Index Scan 기능을 제공한다.

▪ Parallel Index Scan 기능은 Index Full Scan 뿐만 아니라 Index Range Scan 시에도 동작한다.

1) 조건절 범위에 해당하는 "Start 리프 블록"과 "End 리프 블록"의 위치를 계산한다.

2) 처리 범위가 인덱스 병렬 처리를 할 정도로 큰지 확인한다. (아래 표 참조)

3) 만일 크다면, 크기에 따라서 Worker 개수를 설정한 후에, "Start" ~ "End" 범위를 나눠서 처리한다.

4) 만일 작다면, 싱글 프로세스로 처리한다.

 

 

 

# PostgreSQL 파티션

PostgreSQL 파티션

 

▪ 상속 (Inherits)을 이용해서 파티션을 구현함

▪ 인덱스 정보는 상속되지 않음

▪ Trigger를 이용해서 파티션 Pruning을 처리함

▪ 파티션 생성 시에 CHECK 조건을 이용함

▪ Range, List 파티션을 제공함

▪ Global Index는 제공하지 않음

▪ 입력 조건에 맞는 파티션만 액세스하는 것을 ‘파티션 Pruning’이라고 한다.

▪ 이를 위해서는 constraint_exclusion 파라미터를 ‘on’ 또는 ‘partition’으로 설정해야 한다.

(기본 설정값: partition)

▪ CHECK 조건을 입력하면 정상적으로 파티션 Pruning이 수행된다.

 

서브 파티션을 이용한 튜닝 방안

▪ 1차 파티션을 통해 IO 범위를 줄인 후에도 여전히 IO 량이 많은 경우에는 2차 파티션을 고려한다.

▪ PostgreSQL은 상속에 의한 파티션 생성 방식이므로, 이론적으로는 n차 파티션도 가능하다.

▪ 따라서 업무 속성에 따른 서브 파티션 생성을 통한 IO 튜닝이 가능하다.

 

파티션 Partial 인덱스를 이용한 튜닝 방안

▪ PostgreSQL은 파티션 Partial 인덱스를 제공한다.

▪ 즉, 파티션 별로 인덱스 생성 여부를 결정할 수도 있고, 파티션 마다 다른 인덱스 (예, B*Tree, Covering Index, BRIN 등)를 생성할 수도 있다.

▪ 참고로, 오라클은 12c 버전부터 파티션 Partial 인덱스 기능을 제공한다.

 

파티션 입력 성능 향상을 위한 Tip

▪ RULE 보다는 Trigger를 이용한다. 어떤 경우에도 Trigger가 빠르다.

▪ 자주 입력되는 파티션을 Trigger의 윗 부분에 위치하는 것이 좋다. 그래야 IF THEN ELSE의 부하를 줄일 수 있다.

▪ 가능하면, 파티션을 지정해서 입력하는 것이 좋다.

 

PostgreSQL 파티션 Pruning 시의 주의 사항

▪ 예상과 달리, 파티션 Pruning이 동작하지 않는 경우가 존재한다.

▪ 이점은 쿼리 작성 시에 매우 주의해야할 점이다.

▪ IN 절 내에 Subquery를 사용할 경우에는 파티션 Pruning이 동작하지 않는다.

▪ IN 절 사용시 파티션 Pruning을 유도하기 위해서는 실제 CHECK 조건을 입력해야 한다.

▪ NL 조인으로 수행되면 추가 조건 없이도 파티션 Pruning이 수행된다.

▪ Hash 조인으로 수행되면 추가 조건을 반드시 입력해야 한다.

▪ 따라서, 쿼리 작성 후에 Explain 결과 확인 및 추가 조건을 입력할 필요가 있다.

▪ Hash 조인으로 수행될 때를 고려해서, 상수 조건을 추가하는 것을 습관화 하는 것이 좋다.

▪ PostgreSQL 10부터 오라클과 유사한 파티션 생성 문법을 제공한다.

▪ 이때, 트리거는 생성할 필요가 없다. (이점은 관리측면의 편의성을 제공한다)

▪ 단, 파티션 Pruning은 기존과 같은 한계가 존재한다. (즉, 해시 조인 시에는 상수 조건 추가 필요)

 

파티션 성능 테스트(INSERT)

▪ 9.6 까지는 파티션이 1개인 경우에도 일반 테이블보다 입력 속도가 3배 이상 느리다. 그 이유는 매 건마다 Trigger 함수를 호출하는 부하 때문이다.

▪ CPU 성능에 좋을수록 이 차이는 감소한다.

▪ 파티션 개수가 많아질 수록 입력 성능은 저하된다.

▪ 이 문제는 PG10 버전에서도 여전히 발생한다.

▪ 상속을 이용한 파티션은 Trigger 조정을 통해서 입력 성능을 향상 시킬 수 있다.

▪ 하지만, Native 파티션 (PG 10 버전)은 입력 파티션 위치에 따른 성능 차이가 거의 없다.

 

 

 

# PostgreSQL – Grafana 연동

설치하기 전 git, make, go 패키지 설치

# yum install git

# yum install make

# yum install go

 

git에서 postgres_exporter 가져옴

# git clone https://github.com/prometheus-community/postgres_exporter.git

 

폴더로 이동 후 빌드

# cd postgres_exporter

# make build

 

데이터 소스 환경 변수 설정 및 실행

# export DATA_SOURCE_NAME=postgresql://어드민계정:어드민비밀번호@RDS_ENDPOINT:5432/접속DB?sslmode=disable

# . /postgres_exporter

Prometheus에 pgexporter Job 등록

# vi prometheus.yml

Prometheus 서버에 pgexporter가 등록되었는지 확인

http://prometheus서버ip:9090/targets

 

Prometheus 그래프 확인

http://prometheus서버ip:9090/graph

 

Grafana에서 대시보드에 그래프 출력

 

Grafana에 PostgreSQL 직접 등록

 

 

 

 

# PostgreSQL slow query – Cloudwatch 연동

RDS의 데이터베이스 옵션에서 Cloudwatch Logs로 보낼 수 있도록 설정.

 

 

 

 

 

 

 

# 참조 : https://dailyheumsi.tistory.com/263?category=980484

 

이번에는 MLflow Project 에 대해서 자세히 알아본다.

 

사전 준비

이전 글을 확인하자.

 

개요

MLflow Project는 말 그대로 MLflow에서 유용하게 관리, 사용하기 위해 정의하는 양식이다. 말로 설명하는 것보다 그냥 보고 이해하는게 더 빠를거 같다.

다음은 examples/sklearn_logistic_regression 에 있는 예시다. 하나의 MLflow Project는 다음과 같은 구조를 가진다고 보면 된다.

sklearn_logistic_regression
├── MLproject
├── conda.yaml
└── train.py

MLproject 라는 파일이 존재하는데, 이 파일을 통해 이 프로젝트가 MLflow Project 임을 알 수 있다. MLflow Projet 는 mlflow run 명령어로 실행이 가능하다. 위의 경우 mlflow run sklearn_logistic_regression 으로 실행할 수 있다.

 

MLProject 살펴보기

MLflow Project 를 mlflow run 으로 실행할 때 무엇을 어떻게 실행할 것인지를 알아야하는데, 이에 대한 내용을 MLproject 파일이 담고있다.

간단한 예시를 보자. 다음은 examples/sklearn_elasticnet_wine/MLproject 파일의 내용이다.

name: tutorial

conda_env: conda.yaml

entry_points:
  main:
    parameters:
      alpha: {type: float, default: 0.5}
      l1_ratio: {type: float, default: 0.1}
    command: "python train.py {alpha} {l1_ratio}"

하나씩 이해해보자.

• name
  • MLProject의 프로젝트 이름이라고 보면 된다.
• conda_env
  • 이 MLProject 를 실행할 때 conda 환경을 만든 뒤 실행하게 되는데, 이 때 참고할 conda 환경에 대한 파일이름을 값으로 가진다. 여기서는 이 프로젝트 내 conda.yaml 에 이 설정 값들이 있다.
  • conda가 아닌 docker를 사용할 수 있는데, 이 때 docker_env 라는 키를 사용하면 된다. 이에 대한 내용은 아래에서 다시 설명하겠다.
• entry_points
  • mlflow run 으로 실행할 때 -e 옵션으로 프로젝트 실행에 여러 진입점을 둘 수 있는데, 이 때 사용되는 값이다.
  • 예를 들면, 위의 경우 mlflow run -e main sklearn_elastic_wine 으로 main 이라는 진입점으로 실행할 수 있다.
  • 위 명령어가 실행되면 python train.py {alpha} {l1_ratio} 명령어를 실행한다. 이 때 {alpha} 와 {l1_ratio} 는 위 mlflow run 시 받는 파라미터 값이다. 이는 parameters 에 정의가 되어있다.

다시 정리해보면 위와 같이 정의된 MLflow Project는 다음 명령어로 실행할 수 있다.
(코드에서는 mlflow.projects.run() 명령어로 실행할 수 있다. 이에 대한 내용은 여기를 참고하자.)

$ mlflow run -e main sklearn_elastic_wine -P alpha=0.1 -P l1_ratio=0.5

이 명령어는 다시 내부적으로 아래 명령어를 실행하게 된다.

$ python train.py 0.1 0.5

 

Docker 환경 사용하여 실행하기

위 MLproject 파일 내에서 conda_env 를 사용하였다. 이럴 경우 MLflow Project를 실행시키는 환경에 conda가 미리 깔려있어야 실행이 가능하다. conda가 깔려있지 않으면 mlflow run 에서 에러를 뱉을 것이다. (--no-conda 옵션을 주는 경우도 있지만, 이럴 경우 또 virtuanlenv 등으로 가상 환경을 세팅하고 필요한 라이브러리르 일일이 설치해주어야 해서 번거롭다.)

conda를 쓰지 않고 docker 컨테이너 환경으로 실행이 가능한데 이 방법을 살펴보자.
이번에도 역시 공식 예제를 활용한다. 다음은 examples/docker 에 있는 예시다.

docker
├── Dockerfile
├── MLproject
├── README.rst
├── kubernetes_config.json
├── kubernetes_job_template.yaml
├── train.py
└── wine-quality.csv

여기서 주목할만한 파일은 Dockerfile 과 MLproject 파일이다. 이 둘을 살펴보자.

# Dockerfile

FROM python:3.8.8-slim-buster

RUN pip install mlflow>=1.0 \
    && pip install numpy \
    && pip install pandas \
    && pip install scikit-learn

# 예제 파일을 그대로 실행하면 오류가 생겨서 약간 손을 보았다.
# 베이스 이미지 수정, 필요없는 패키지 및 버전을 지운 정도다.
# 아마 2년 전 예제라 업데이트가 잘 안된 듯 싶다.

# MLproject

name: docker-example

docker_env:
  image:  mlflow-docker-example

entry_points:
  main:
    parameters:
      alpha: float
      l1_ratio: {type: float, default: 0.1}
    command: "python train.py --alpha {alpha} --l1-ratio {l1_ratio}"

Dockerfile 파일에서는 환경 구상을 위해 필요한 패키지들을 설치한다.
MLproject 파일에서는 docker_env 를 사용하고 있고, 사용할 도커 이미지 이름을 설정한다.

이제 이 MLflow Project 를 실행해보자.
먼저 mlflow run 을 하기 전에 Dockerfile 을 이용하여 mlflow-docker-example 라는 이름의 도커 이미지를 만들어 주어야 한다.

$ docker build -t mlflow-docker-example -f Dockerfile .

이제 mlflow run 으로 이 프로젝트를 실행한다.

$ mlflow run docker -P alpha=0.5

이렇게 실행하면 mlflow 는 mlflow-docker-example 이름의 도커 이미지를 찾아 그 위에 mlflow 코드를 실행하는 도커 이미지를 하나 더 만들고 이 이미지를 실행한다. 결과적으로 이미지를 하나 더 만드는 셈이다. 아래 사진을 보면 docker-example 이라는 이미지가 만들어 진 것을 볼 수 있다.

이미 감이 온 사람은 알겠지만, MLProject 의 docker_env.image 값은 로컬 도커 이미지가 아니여도 된다. Dockerhub나 GCR, ECR 등에 미리 만들어두고 사용해도 된다. 또한 컨테이너 내부의 환경 변수 설정 등도 가능하다. 자세한 내용은 여기를 참고하자.

 

Github에 있는 프로젝트 실행하기

지금까지 로컬에 있는 MLflow Project를 실행했다면 다음처럼 github에 올려둔 MLProject 를 실행시킬 수 있다. 예를 들면 다음과 같다.

mlflow run git@github.com:mlflow/mlflow-example.git -P alpha=0.5 --no-conda

 

쿠버네티스에서 실행하기

mlflow run 을 할 때 --backend 와 --backend-config 파라미터 설정으로 MLflow Project를 쿠버네티스 상에서 실행시킬 수 있다. (Job 리소스로 실행된다.)
예를 들면 다음과 같다.

$ mlflow run <project_uri> \
--backend kubernetes \
--backend-config kubernetes_config.json

위 명령어를 실행하게 되면 다음의 과정이 일어난다.

1. MLflow Project 실행을 도커 이미지로 만든다.
2. 이 이미지를 사용자가 설정해둔 도커 컨테이너 레지스트리에 푸시한다.
3. 쿠버네티스에서 이 이미지를 Job으로 배포한다.

위 명령어가 실행이 되려면 푸시할 도커 이미지 레지스트리와 쿠버네티스 접속 컨텍스트가 필요한데, 이를 위해 MLflow Project 내에 다음과 같은 파일이 있어야 한다.

# kubernetes_config.json

{
    "kube-context": "docker-for-desktop",
    "kube-job-template-path": "examples/docker/kubernetes_job_template.yaml",
    "repository-uri": "username/mlflow-kubernetes-example"
}

# kubernetes_job_template.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: "{replaced with MLflow Project name}"
  namespace: mlflow
spec:
  ttlSecondsAfterFinished: 100
  backoffLimit: 0
  template:
    spec:
      containers:
      - name: "{replaced with MLflow Project name}"
        image: "{replaced with URI of Docker image created during Project execution}"
        command: ["{replaced with MLflow Project entry point command}"]
      resources:
        limits:
          memory: 512Mi
        requests:
          memory: 256Mi
      restartPolicy: Never

직접 여기서 시도해보지는 않았지만, 아마도 쿠버네티스에서 MLflow를 배포하고 운영하는 팀에서는 이를 적극적으로 활용하지 않을까 싶다.

 

정리

정리해보자.

• MLflow Project는 MLflow 에서 사용, 관리 가능한 하나의 프로젝트를 의미한다.
  • 프로젝트 루트 폴더에 MLproject 파일이 있어야 하고, 이 파일은 프로젝트 실행 및 환경에 대한 내용을 담는다.
  • mlflow run {{ project_name }} 으로 실행가능하다.
• MLflow Project는 conda, docker 환경으로 실행이 가능하다.
• 실행할 프로젝트는 로컬 뿐 아니라 Github 상에 있어도 가능하다.
  • MLProject들을 별도로 모아둔 Github Repository를 만들고 이를 최신 공용 저장소로 이용해볼 수도 있을거 같다.
• 쿠버네티스 위에서 Job으로도 실행할 수도 있다.

 

참고

• https://mlflow.org/docs/latest/projects.html

# 참고 : https://dailyheumsi.tistory.com/262?category=980484

이번에는 MLflow의 Model에 대해서 좀 더 자세히 알아본다.

 

사전 준비

이전 글을 참고하자.

 

모델 저장하기

mlflow로 코드에서 모델을 저장하는 방법은 다음처럼 크게 2가지가 있다.

• mlflow.sklearn.save_model()
• mlflow.sklearn.log_model()

일단 sklearn 등 머신러닝 모델 프레임워크 단위로 함수를 제공한다.
그리고 log_model() 은 save_model() 를 똑같이 실행하는 것인데, 저장되는 위치가 run 내부라는 것이 다르다. 일단은 간단한 동작을 보기 위해 save_model() 을 사용해보자.

예를 들면 다음과 같다.

import mlflow

model = ... 
mlflow.sklearn.save_model(model, "my_model")

이렇게 저장하고 나면 다음과 같은 결과물이 생긴다.

my_model/
├── MLmodel
└── model.pkl

model.pkl 은 모델 인스턴스가 picklezed 된 파일이라고 보면 된다.
MLmodel 에는 다음처럼 모델에 대한 메타 정보가 담긴다.

# MLmodel

time_created: 2018-05-25T17:28:53.35

flavors:
  sklearn:
    sklearn_version: 0.19.1
    pickled_model: model.pkl
  python_function:
    loader_module: mlflow.sklearn

 

시그니처 추가하기

누군가가 만들어 놓은 MLflow 모델을 보게되면 보통 MLmodel 을 통해 모델에 대한 정보를 먼저 파악하려고 할 것이다. 그런데 위 MLmodel 파일만 봐서는 이 모델이 어떤 입력을 받고 어떤 출력을 뱉는지 알수가 없다. 입출력에 대한 정보는 시그니처라고 말하는데, 이를 쉽게 알 수 있도록 시그니처를 추가해주자.

예시 코드는 다음과 같다.

import pandas as pd
from sklearn import datasets
from sklearn.ensemble import RandomForestClassifier
import mlflow
import mlflow.sklearn
from mlflow.models.signature import infer_signature

iris = datasets.load_iris()
iris_train = pd.DataFrame(iris.data, columns=iris.feature_names)
clf = RandomForestClassifier(max_depth=7, random_state=0)
clf.fit(iris_train, iris.target)

# 입출력 정보를 정해주는 부분. 이런 정보를 시그니처라고 한다.
signature = infer_signature(iris_train, clf.predict(iris_train))

# 위에서 정한 시그니처 값을 인자로 넘긴다.
mlflow.sklearn.log_model(clf, "iris_rf", signature=signature)

위에서는 infer_signature() 함수를 사용하여 시그니처를 정해주었다. 이 함수는 실제 입력데이터와 출력 데이터를 파라미터로 넘기면, 시그니처를 알아서 추론해준다. 구체적인 모양새는 여기를 참고하자.

위처럼 추론해주는 함수를 쓰지않고 다음처럼 직접 시그니처를 지정할 수도 있다.

from mlflow.models.signature import ModelSignature
from mlflow.types.schema import Schema, ColSpec

input_schema = Schema([
  ColSpec("double", "sepal length (cm)"),
  ColSpec("double", "sepal width (cm)"),
  ColSpec("double", "petal length (cm)"),
  ColSpec("double", "petal width (cm)"),
])
output_schema = Schema([ColSpec("long")])
signature = ModelSignature(inputs=input_schema, outputs=output_schema)

tensorflow를 쓰는 경우 tensor-based 로 시그니처를 잡아줄 수도 있는데, 이는 공식 문서에 확인하자.

여하튼 위 코드를 실행하면 MLmodel 파일에는 다음처럼 시그니처 정보가 추가된다.

artifact_path: iris_rf
flavors:
  python_function:
    env: conda.yaml
    loader_module: mlflow.sklearn
    model_path: model.pkl
    python_version: 3.8.7
  sklearn:
    pickled_model: model.pkl
    serialization_format: cloudpickle
    sklearn_version: 0.24.2
run_id: 8f7e5d6b6e4e4a69a06ad1fd9e1eeafd
signature:
  inputs: '[{"name": "sepal length (cm)", "type": "double"}, {"name": "sepal width
    (cm)", "type": "double"}, {"name": "petal length (cm)", "type": "double"}, {"name":
    "petal width (cm)", "type": "double"}]'
  outputs: '[{"type": "tensor", "tensor-spec": {"dtype": "int64", "shape": [-1]}}]'
utc_time_created: '2021-05-08 05:49:44.141412'

 

입출력 예시 추가하기

이번엔 모델 입출력 예시까지 추가해보자.
위 코드에서 mlflow.sklearn.log_model() 함수에 input_example 인자 값을 다음처럼 추가한다.

input_example = {
  "sepal length (cm)": 5.1,
  "sepal width (cm)": 3.5,
  "petal length (cm)": 1.4,
  "petal width (cm)": 0.2
}
mlflow.sklearn.log_model(clf, "iris_rf", input_example=input_example)

코드를 실행하면 MLmodel 파일이 있는 디렉토리 (artifacts/iris_rf) 내에 input_example.json 이라는 파일이 다음처럼 생기게 된다.

{
    "columns": [
        "sepal length (cm)", 
        "sepal width (cm)",
        "petal length (cm)", 
        "petal width (cm)"
    ], 
    "data": [
        [5.1, 3.5, 1.4, 0.2]
    ]
}

이 정보는 MLflow 웹서버에서 실행(Run) 상세 페이지 하단에 Artifacts 탭에서 볼 수 있다.

 

그 외

공식 홈페이지 문서에는 이 외에도 다음 내용들이 더 있다.

• Built-In Model Flavor
• Model Customization
• Built-In Deployment Tools
• Deployment to Custom Target

이 내용들은 부가적인 내용이라고 생각한다. 여기서는 그래도 좀 많이 사용되겠다 싶은 것들만 소개해보았다.

 

정리

정리해보자.

• 모델 저장은 save_model() 혹은 log_model() 로 한다.
  • 근데 내 생각에 대부분의 경우, MLflow 를 실행(Run) 단위로 기록하기 때문에 log_model() 을 쓰지 않을까 싶다.
  • 모델을 저장하면 모델 인스턴스를 Picklized 한 model.pkl 과 메타 정보를 담고 있는 MLmodel 파일이 생긴다.
• 모델의 시그니처와 입출력 예시를 코드에서 세팅해줄 수가 있다.

최종적으로 코드는 다음과 같은 형태가 될 것이다.

import pandas as pd
from sklearn import datasets
from sklearn.ensemble import RandomForestClassifier
import mlflow
import mlflow.sklearn
from mlflow.models.signature import infer_signature, ModelSignature
from mlflow.types.schema import Schema, ColSpec

iris = datasets.load_iris()
iris_train = pd.DataFrame(iris.data, columns=iris.feature_names)
clf = RandomForestClassifier(max_depth=7, random_state=0)
clf.fit(iris_train, iris.target)

# 시그니처 정의 방법 1 (직접 입력해줄 수 있다.)
input_schema = Schema([
  ColSpec("double", "sepal length (cm)"),
  ColSpec("double", "sepal width (cm)"),
  ColSpec("double", "petal length (cm)"),
  ColSpec("double", "petal width (cm)"),
])
output_schema = Schema([ColSpec("long")])
signature = ModelSignature(inputs=input_schema, outputs=output_schema)

# 시그니처 정의 방법 2 (입출력 데이터로 자동 추론할 수도 있다.)
# signature = infer_signature(iris_train, clf.predict(iris_train))

# 입출력 예시 정의
input_example = {
  "sepal length (cm)": 5.1,
  "sepal width (cm)": 3.5,
  "petal length (cm)": 1.4,
  "petal width (cm)": 0.2
}

# 모델 저장
mlflow.sklearn.log_model(
    clf,
    "iris_rf", 
    signature=signature, 
    input_example=input_example
)

최종적으로 생성되는 artifacts 는 다음과 같다.

artifacts
└── iris_rf
    ├── MLmodel
    ├── conda.yaml
    ├── input_example.json
    └── model.pkl

참고

• https://mlflow.org/docs/latest/models.html

# 참조 : https://ko.androideity.com/list-chrome-urls

 

 

• chrome : // about -모든 내부 Chrome URL을 나열합니다.
• chrome : // accessibility -브라우저에 열려있는 각 탭에 대한 접근성 정보와 기능이 전역 적으로 켜져 있는지 여부를 표시합니다.
• chrome : // appcache-internals -사용하는 공간을 포함하여 appcached 사이트에 대한 정보.
• chrome : // apps / -설치된 모든 애플리케이션 (사용자 별 및 Chrome 브라우저와 함께 제공되는 애플리케이션)을 새 페이지에 나열합니다.
• chrome : // blob-internals / -Binary Large Object (Blob)에 대한 정보
• chrome : // bluetooth-internals / -연결된 Bluetooth 어댑터 및 장치에 대한 정보를 표시합니다. 장치가 표시되고 검색 가능한지 여부.
• chrome : // bookmarks -브라우저의 북마크 관리자를 엽니 다.
• chrome : // chrome / -정보 페이지를 엽니 다.
• chrome : // chrome-urls -이 목록을 표시합니다. Chrome : // About로로드 할 수도 있습니다.
• chrome : // components / - '크롬 크래시 서비스'또는 '페퍼 플래시'와 같은 내부 구성 요소 목록 및 각각에 대한 업데이트를 개별적으로 확인하는 옵션.
• chrome : // conflicts / -로드 된 모든 모듈을 나열하고 충돌이 있는지 여부를 표시합니다.
• chrome : // crashes / -충돌보고가 활성화 된 경우 최근 충돌에 대한 정보를 표시합니다.
• chrome : // credits -브라우저에 포함 된 기술, 해당 라이선스 및 제작자
• chrome : // device-log / -장치 관련 이벤트의 로그를 보여줍니다.
• chrome : // devices / -Chrome에 연결된 물리적 또는 가상 장치를 나열합니다. Google 클라우드 프린트에 프린터를 추가하는 옵션.
• chrome : // dino - '인터넷에 연결되어 있지 않습니다'오류 페이지가 표시됩니다.
• chrome : // discards / -세션 중에 삭제 된 탭에 대한 정보. 페이지에서 개별 탭을 삭제하는 옵션입니다.
• chrome : // download-internals -다운로드를 시작하고 응답 및 프로세스를 모니터링합니다.
• chrome : // downloads -과거의 모든 다운로드를 나열하는 브라우저의 다운로드 관리자
• chrome : // extensions -설치된 확장을 표시합니다.
• chrome : // flags -브라우저에 한 번에 통합되거나 통합되지 않을 수있는 실험적 기능을 표시합니다.
• chrome : // gcm-internals / -Google 클라우드 메시징 정보를 표시합니다.
• chrome : // gpu -비디오 카드 및 지원되는 기능에 대한 정보 (예 : 하드웨어 가속
• chrome : // help / -정보 페이지를 엽니 다.
• chrome : // histograms -히스토그램 관련 정보
• chrome : // history -검색 기록을 지우거나 과거에 열었던 페이지를 찾기 위해 검색하는 옵션이있는 검색 기록 페이지를 엽니 다.
• chrome : // indexeddb-internals / -사용자 프로필의 IndexedDB 정보.
• chrome : // inspect -Chrome의 페이지 또는 확장 프로그램과 같은 요소를 검사하는 옵션
• chrome : // interventions-internals -개입 상태, 플래그, 로그 및 기타 정보를 나열합니다.
• chrome : // invalidations / -무효화 디버그 정보 나열
• chrome : // local-state / -기능 및 로컬 브라우저에서 활성화 여부, 상태 정보를 나열합니다.
• chrome : // media-engagement -브라우저에서 열린 모든 사이트에 대한 미디어 참여 점수와 임계 값을 표시합니다. 점수는 사운드와 함께 비디오 자동 재생을 결정하는 데 사용됩니다.
• chrome : // media-internals -미디어 재생시 미디어 정보 표시
• chrome : // nacl -Chrome의 NaCl 플러그인 (Native Client)에 대한 정보
• chrome : // net-export -네트워크 활동을 캡처하여 디스크의 파일에 저장합니다.
• chrome : // net-internals -SPDY 연결, 소켓 또는 DNS 조회를 포함한 자세한 네트워크 및 연결 관련 정보를 표시합니다.
• chrome : // network-error / -네트워크 오류 메시지를 표시합니다.
• chrome : // network-errors / -Chrome에서 발생할 수있는 네트워크 오류 메시지 목록을 표시합니다.
• 크롬 : // newtab -새 탭 페이지를 표시합니다.
• chrome : // ntp-tiles-internals -새 탭 페이지 및 상위 사이트 기능에 타일에 대한 정보를 표시합니다.
• chrome : // omnibox -이 페이지에 검색 주소창 입력 결과를 표시하며 검색 결과에 검색, 바로 가기 및 기록 정보를 포함합니다.
• chrome : // password-manager-internals / -비밀번호 관리자 로그가 페이지에 나열됩니다. 페이지를 닫으면 로그가 자동으로 지워집니다.
• chrome : // policy -현재 브라우저에서 활성화 된 모든 정책
• chrome : // predictors -과거 활동을 기반으로 한 자동 완성 및 리소스 프리 페치 예측 자 목록
• chrome : // print -인쇄 미리보기 페이지
  
• chrome : // process-internals -프로세스 및 사이트 격리 정보, 프레임 트리.
• chrome : // quota-internals -Chrome 프로필 디렉토리에 사용할 수있는 디스크 여유 공간, 사용량 및 할당량 세부 정보에 대한 정보
• chrome : // safe-browsing -현재 공사중입니다. 세이프 브라우징 상태를 표시합니다.
• chrome : // serviceworker-internals / -브라우저에 등록 된 모든 서비스 워커와 등록 취소 옵션을 나열합니다.
• chrome : // settings -기본 Chrome 설정 페이지를 엽니 다.
• chrome : // signin-internals -마지막 로그인 세부 정보 또는 유효성과 같은 로그인 된 계정에 대한 정보를 표시합니다.
• chrome : // site-engagement -브라우저에서 방문한 모든 사이트에 대한 참여 점수를 표시합니다.
• chrome : // suggestions / -모든 새 탭 페이지 제안 및 만료시기.
• chrome : // supervised-user-internals / -활성 사용자에 대한 정보를 나열하고 관리자에게 웹 사이트 필터 및 기타 사항을 테스트 할 수있는 옵션을 제공합니다.
• chrome : // sync-internals -활성화 된 경우 브라우저의 동기화 기능에 대한 자세한 정보.
• chrome : // system / -시스템, 동기화, 메모리 사용량 등에 대한 JSON 정보를 나열합니다.
• chrome : // terms -Google 크롬의 서비스 약관
• chrome : // thumbnails / -미리보기 이미지가 있거나없는 모든 상위 사이트 URL.
• chrome : // tracing -페이지가 정보로 채워지기 전에 녹음이 활성화되어야합니다. 그렇게하면 브라우저가 탐색 활동을 기록하기 시작합니다
• chrome : // translate-internals / -지원되는 언어를 포함하는 번역 정보, 언어가 번역되지 않거나 항상 번역되지 않고 기록됩니다.
• 크롬; // usb-internals -컴퓨터에 연결된 USB 장치를 추가하고 테스트합니다.
• chrome : // user-actions / -사용자 작업 로그 (예 : 탭 닫기, 탭 변경 등.
• chrome : // version -브라우저 버전 및 명령 줄 스위치, 사용자 에이전트, JavaScript, Flash 및 WebKit 버전, 경로 변수를 포함한 다양한 관련 정보를 표시합니다.
• chrome : // webrtc-internals / -PeerConnection 업데이트 및 통계 데이터를 다운로드하여 덤프를 만듭니다.
• chrome : // webrtc-logs / -최근 캡처 한 WebRTC 로그를 나열합니다.

이번에는 MLflow의 Model Registry에 대해서 알아본다.

---

사전 준비

음 이제 매번 쓰기 귀찮다.
어차피 직전 글이랑 이어지므로, 이전 글을 통해 확인하자.

---

Model Registry

개념

Model Registry는 MLflow 프로젝트 실행을 통해 나온 결과물인 모델을 저장하는 중앙 집중식 모델 저장소다. MLflow로 모델을 기록했다면, 기록한 모델을 Model Registry에 등록할 수 있고, 등록된 모델은 어디서든 불러올 수 있다.

 

모델 등록하기

웹 UI로 등록하기

간단하게 모델을 등록해보자. 직전 글에서 사용한 실습을 그대로 이어간다.
웹 서버 (Tracking Server) 에 들어간 뒤, 실행했던 실행(Run)을 클릭하여 들어간다.

실행 상세페이지 하단에 Artifacts 블록이 있고 이 안에 Model Register 버튼이 있다.

버튼을 클릭하여 다음처럼 LinearRegression 이라는 이름으로 모델을 등록해주자.

이제 상단 메뉴 중에 Model 탭에 들어가보면 다음처럼 등록된 모델을 확인할 수 있다.
모델을 처음 등록하는 경우 Version 1 이 자동으로 추가된다.

등록된 모델 하나를 클릭하면 아래처럼 상세 페이지가 나온다.

모델 버전을 누르면 다음처럼 해당 버전의 상세 페이지로 들어갈 수 있다.

Stage 항목에서는 이 모델의 스테이지 상태를 Staging, Production, Archived 중 하나로 바꿀 수 있다. 아무것도 지정하지 않았을 시 기본 값은 None 이다.

 

코드에서 등록하기

위처럼 웹 UI가 아니라 코드에서 직접 등록하는 방법도 있다.
총 3가지 방법이 있는데 첫 번째 방법은 mlflow.sklearn.log_model() 에 registered_model_name 의 값을 주는 것이다.

이를 직접 확인하기 위해 이전에 실행했던 sklearn_logistic_regression 예제의 train.py 를 다음처럼 수정한다.

# sklearn_logistic_regression/train.py

import numpy as np
from sklearn.linear_model import LogisticRegression

import mlflow
import mlflow.sklearn

if __name__ == "__main__":
    X = np.array([-2, -1, 0, 1, 2, 1]).reshape(-1, 1)
    y = np.array([0, 0, 1, 1, 1, 0])
    lr = LogisticRegression()
    lr.fit(X, y)
    score = lr.score(X, y)
    print("Score: %s" % score)
    mlflow.log_metric("score", score)
    # mlflow.sklearn.log_model(lr, "model")  # before
    mlflow.sklearn.log_model(lr, "model", registered_model_name="LinearRegression")  # after
    print("Model saved in run %s" % mlflow.active_run().info.run_uuid)

바뀐 부분은 딱 한 줄이다. mlflow.sklearn.log_model 함수에 registered_model_name="LinearRegression" 인자를 추가하였다. (이 함수에 자세한 내용은 여기서 확인할 수 있다.)

이제 다시 이 MLflow 프로젝트를 실행하자.

$ mlflow run sklearn_logistic_regression --no-conda

로그를 보면 LinearRegression 이 이미 등록된 모델이므로, 등록된 모델의 새 버전을 만든다고 하고 Version 2 를 만들었다고 한다. (만약 ``registered_model_name값으로 넘겨준 값이 등록된 모델이 아닌 경우, 모델을 먼저 등록하고Version 1` 을 부여한다.)

웹 UI에 가서 확인해보자.

위처럼 LinearRegression 모델의 Latest Version이 Version 2 가 된 것을 볼 수 있고, 등록된 모델 상세 페이지에 들어가보면 아래처럼 Version 2 가 추가된 것을 볼 수 있다.

다른 두 번째 방법으로는 mlflow.register_model() 를 사용하는 것이다. 이 함수에는 model_uri 와 name 인자 값을 넘겨줘야 하는데 예시를 보면 바로 알 수 있다.

result = mlflow.register_model(
    model_uri="runs:/4268cde08c2c4fd08c6257b148ed2977/model",
    name="LinearRegresion"
)

model_uri 는 run_id 와 artifacts 내에 model 이 저장된 경로다.
name 은 등록할 때 사용할 이름이다. 위에서 registered_model_name 와 같은 개념이다.
좀 더 자세한 사용법은 여기를 확인하자.

세 번째 방법은 MlflowClient.create_registered_model() 와 MlflowClient.create_model_version() 를 사용하는 것이다. 마찬가지로 예시를 바로 보자.

from mlflow.tracking import MlflowClient

# 모델을 등록한다. 아직 버전이 없기 때문에 비어있다.
client = MlflowClient()
client.create_registered_model("LinearRegression")

# 등록된 모델에 버전을 등록한다.
result = client.create_model_version(
    name="LinearRegression",
    source="artifacts/0/4268cde08c2c4fd08c6257b148ed2977/artifacts/model",
    run_id="4268cde08c2c4fd08c6257b148ed2977"
)

이 정도만 설명해도 어느정도 설명이 된다 생각한다. create_model_version() 에 대한 자세한 내용은 여기를 확인하자.

 

등록된 모델 불러오기

Model Registry에 등록된 모델은 어디서든 불러올 수 있다.
위에서 등록한 모델을 불러오는 실습을 해보자.

먼저 load_registered_model.py 를 만들고 다음 코드를 입력하자.

# load_registered_model.py

import mlflow.pyfunc
import numpy as np

# 가져올 등록된 모델 이름
model_name = "LinearRegression"

# 버전을 기준으로 가져오고 싶을 때
model_version = 2
model = mlflow.pyfunc.load_model(
    model_uri=f"models:/{model_name}/{model_version}"
)

# 단계(stage)를 기준으로 가져오고 싶을 때
# stage = 'Staging'
# model = mlflow.pyfunc.load_model(
#     model_uri=f"models:/{model_name}/{stage}"
# )

X = np.array([[1], [2], [3]])
Y = model.predict(X)    
print(Y)

이제 MLflow Tracking Server 설정 후, 위 코드를 실행하자

$ export MLFLOW_TRACKING_URI="http://[ip]:5000"
$ python load_registered_model.py

위 사진 처럼 잘 불러와서 실행하는 것을 볼 수 있다.

등록된 모델 서빙하기

Model Registry에 등록된 모델은 다음처럼 바로 서빙이 가능하다.

# Tracking Server를 설정한다.
$ export MLFLOW_TRACKING_URI="http://[ip]:5000"

# 등록된 LinearRegression 모델의 Version 1을 서빙하는 서버를 띄운다.
$ mlflow models serve -m "models:/LinearRegression/1" --port 5001 --no-conda --host "0.0.0.0"

잘 서빙하는지 요청을 날려보자.

$ curl \
-d '{"columns":["x"], "data":[[1], [-1]]}' \
-H 'Content-Type: application/json; format=pandas-split' \
-X POST localhost:5001/invocations

 

응답이 잘 오는 것을 볼 수 있다.

 

그 외 제공해주는 것들

필수적으로 알아야할 것들은 어느정도 설명한 것 같고... 이 외에 다음과 같은 기능들이 더 있다.

• MLflow 모델 설명 추가 또는 업데이트
• MLflow 모델 이름 바꾸기
• MLflow 모델의 단계(Stage) 전환
• MLflow 모델 나열 및 검색
• MLflow 모델 보관
• MLflow 모델 삭제
• 저장된 모델 등록
• 지원되지 않는 기계학습 모델 등록

특히 모델의 단계 전환, 나열 및 검색 등은 CT(Continous Training)를 구성할 때 추가적으로 활용하면 좋을 거 같다는 생각이 든다. 자세한 내용은 여기를 확인하자.

---

정리

• Model Registry는 실험 및 실행에서 기록한 모델들을 등록하고 불러올 수 있는 저장소다.
• Model Registry에 등록되는 모델들은 버전 혹은 단계(Stage)를 가진다.
• Model Registry에 모델을 등록하는 방법은 크게 2가지 방법이 있다.
  • 웹 UI를 사용하거나
  • mlflow 라이브러리에서 다음 3가지 방법을 사용하거나
    • log_model() 에 registered_model_name 의 값을 함께 넘겨주며 사용한다.
    • register_model() 를 사용한다.
    • create_registered_model() 과 create_model_version() 를 사용한다.
• Model Registry에 등록된 모델은 mlflow model serve 명령어로 바로 서빙이 가능하다.
• mlflow 라이브러리는 등록된 모델과 관련된 여러 액션을 제공해준다. 이는 CT등 파이프라인 자동화에서 활용해볼 수 있다.

# 참조 : https://dailyheumsi.tistory.com/260?category=980484

 

이번에는 MLflow 의 Tracking Server에 대해 알아본다.

---

사전 준비

다음이 사전에 준비 되어 있어야 한다.

# 파이썬 버전 확인
$ python --version
Python 3.8.7

# mlflow 설치 & 버전 확인
$ pip install mlflow
$ mlflow --version
mlflow, version 1.16.0

# 예제 파일을 위한 mlflow repo clone
$ git clone https://github.com/mlflow/mlflow.git
$ cd mlflow/examples

 

---

Tracking Server

Tracking 이란?

이전의 글들을 통해 우리는 MLflow가 머신러닝 프로젝트에서 일종의 "기록" 역할을 하는 것임을 알았다.
여기서 머신러닝의 과정과 결과를 곳곳에서 기록한다는 의미로 "Tracking" 이라는 표현을 사용한다.

Tracking은 실험(Experiment)의 각 실행(Run)에서 일어나고, 구체적으로는 다음 내용들을 기록한다.

• 코드 버전
  • MLflow 프로젝트에서 실행 된 경우, 실행에 사용 된 Git 커밋 해시
• 시작 및 종료 시간
  • 실행 시작 및 종료 시간
• 소스
• 매개 변수
• 메트릭
  • 값이 숫자 인 키-값 측정 항목
  • 각 측정 항목은 실행(run) 과정에서 업데이트 될 수 있으며 (예 : 모델의 손실 함수가 수렴되는 방식을 추적하기 위해) MLflow가 측정 항목의 전체 기록을 기록하고 시각화 할 수 있다.
• 아티팩트
  • 모든 형식의 출력 파일.
  • 예를 들면
    • 이미지 (예 : PNG),
    • 모델 (예. picklize한 scikit-learn 모델)
    • 데이터 파일 (예 : Parquet 파일) 등

 

기록을 어디에 어떻게 저장하는가?

위에서 기록한 내용들은 실제로 어떻게 저장할까?
앞의 글들에서 보았듯이 ./mlruns 에 저장된다.

MLflow 는 별도의 설정 값을 주지 않으면 기본적으로 로컬 경로인 ./mlruns 에 이 기록물들을 저장한다.
기록물은 크게 2가지로 나뉜다.

• Artifacts
  • 파일, 모델, 이미지 등이 여기에 포함된다.
  • 위에서 artifacts 라고 보면 된다.
• MLflow 엔티티
  • 실행, 매개 변수, 메트릭, 태그, 메모, 메타 데이터 등이 여기에 포함된다.
  • 위에서 artifacts 를 제외한 나머지 (meta.yaml, metrics, params, tags) 라고 보면 된다.

위 기록물의 구체적인 내용을 잘 모른다면, 이전 글을 통해 확인해보자.

기본적으로 ./mlruns 이라는 로컬 경로에 이 두 가지를 동시에 저장하고 있다. 하지만 별도의 설정을 통해 이 둘을 별도로 저장할 수 있다. 그리고 이 저장을 위해 Tracking 서버가 필요하다.

 

Tracking Server

MLflow 는 Tracking 역할을 위한 별도의 서버를 제공한다. 이를 Tracking Server라고 부른다.
이전에는 mlflow.log_params, mlflow.log_metrics 등을 통해서 ./mlruns 에 바로 기록물을 저장했다면, 이제는 이 백엔드 서버를 통해서 저장하게 된다.

간단하게 바로 실습해보자.
다음 명령어로 Tracking Server를 띄운다.

# 먼저 별도의 디렉토리를 만들고 들어가자.
$ mkdir tracking-server
$ cd tracking-server

# 이후 Tracking Server를 띄우자.
# 참고로, mlflow ui 는 꺼야 한다.
$ mlflow server \
--backend-store-uri sqlite:///mlflow.db \
--default-artifact-root $(pwd)/artifacts

로그가 쭈욱 나오고, localhost:5000 에 서버가 떠있는 것을 알 수 있다.
--backend-store-uri, --default-artifact-root 라는 개념이 나오는데, 일단은 넘어가고 계속 실습을 진행해보자.

이제 MLflow 프로젝트를 실행시켜볼건데 그 전에 프로젝트가 이 백엔드 서버와 통신할 수 있게 설정해준다.

$ export MLFLOW_TRACKING_URI="http://localhost:5000"

이제 다시 mlflow/examples 경로로 가서 MLflow 프로젝트 예제인 sklearn_logistic_regression 를 다음처럼 실행시켜보자.

$ mlflow run sklearn_logistic_regression --no-conda

잘 실행되었다.
이제 tracking-server 디렉토리로 다시 가서 실행 결과물을 확인해보자.

artifacts/ 와 mlflow.db 파일이 생긴 것을 볼 수 있다.
그리고 이러한 결과물을 트래킹 서버(localhost:5000)의 웹 페이지를 통해서도 확인할 수 있다.

위 실행(Run)을 클릭해서 들어가면 Tracking한 내용을 다음처럼 확인할 수 있다.

---

정리

• 우리는 방금 MLflow 프로젝트를 실행시킬 때 localhost:5000 에 떠있는 Tracking Server를 사용했고,
• Tracking Server 는 프로젝스 실행의 결과물들을 artifacts/ 와 mlflow.db 에 저장했다.
  • Tracking Server를 사용하지 않았을 때는 ./mlruns 에 기록했었다.
  • Tracking Server를 사용하면 별도의 저장소에 기록한다
• Tracking Server 가 사용하는 별도의 저장소는 두 가지 파라미터로 지정할 수 있다.
  • --backend-store-uri
    • Mlflow 엔티티가 기록되는 저장소다.
    • 파일 저장소 혹은 DB를 사용할 수 있으며 SQLAlchemy DB URI 형태로 넘겨주면 된다.
      • <dialect>+<driver>://<username>:<password>@<host>:<port>/<database>
    • 우리는 위에서 sqlite 를 사용하였다.
  • --default-artifact-root
    • Artifacts가 기록되는 저장소다.
    • 파일 시스템, 스토리지 등을 사용할 수 있다.
      • AWS S3나 GCS같은 등 외부 스토리지도 사용할 수 있다. 여기를 참고.
    • 우리는 위에서 파일 시스템을 사용하였다.

Tracking Server는 Server라는 이름에 맞게 어딘가에 항상 띄워두고 사용하면 될듯 싶다.
MLflow project 를 작성하는 실험자는 이 Tracking Server와 통신하도록 세팅해두고 Logging 하면 될듯하고.
이렇게 되면 실험에 대한 모든 기록은 Tracking Server의 웹 대시보드에서 한 눈에 볼 수 있게 된다.

# 참조 : https://dailyheumsi.tistory.com/259?category=980484

 

이번에는 MLflow의 실험(experiments)과 실행(runs)에 대해 알아본다.

---

사전 준비

다음이 사전에 준비 되어 있어야 한다.

# 파이썬 버전 확인
$ python --version
Python 3.8.7

# mlflow 설치 & 버전 확인
$ pip install mlflow
$ mlflow --version
mlflow, version 1.16.0

# 예제 파일을 위한 mlflow repo clone
$ git clone https://github.com/mlflow/mlflow.git
$ cd mlflow/examples

 

---

Experiments & Runs

개념

MLflow에는 크게 실험(Experiment)와 실행(Run)이라는 개념이 있다. 실험은 하나의 주제를 가지는 일종의 '프로젝트'라고 보면 된다. 실행은 이 실험 속에서 진행되는 '시행'이라고 볼 수 있다. 하나의 실험은 여러 개의 실행을 가질 수 있다.

직접 눈으로 보며 이해해보자.
examples 에 있는 sklearn_elasticnet_wine MLflow 프로젝트를 실행해본다.

$ mlflow run sklearn_elasticnet_wine --no-conda

실행 결과로 ./mlruns 경로에 다음과 같은 파일들이 생긴다.

여기서 0 은 실험 ID이고, a853debd39fb4de4a61ce3aa6d247c8a 은 실행 ID다.
한번 더 동일한 프로젝트를 실행해보자. 이번에는 파라미터 값을 추가로 넘겨줘본다.

$ mlflow run sklearn_elasticnet_wine -P alpha=0.5 --no-conda

실행 결과로 mlruns 경로를 확인해보면 다음과 같다.

0 이라는 실행에 69c2f00c31044d339344f91ea03ed1f0 이라는 실행이 추가로 생성되었다.
이렇듯 매 실행은 하나의 실험에 속하여 들어간다. 위의 예시가 매우 직관적이라 실험과 실행의 관계와 활용 방안을 바로 알 수 있을 것이다.

 

Experiment 생성 및 조회

위에서 별도의 실험을 생성하지 않았기 때문에 ID가 0 인 실험을 자동으로 생성하고 이 실험에서 실행을 생성하였다.
이번에는 직접 실험을 생성해보자.

실험 생성 은 다음 CLI 명령어로 가능하다.

$ mlflow experiments create -n "실험 이름"

그리고 실험 목록은 다음 CLI 명령어로 가능하다.

$ mlflow experiments list

그 외 mlflow experiments 관련된 명령어는 다음의 것들이 있으니 참고하자.

CLI가 아닌 코드에서 experiments 및 run을 다루는 방법

다음처럼 mlflow.tracking.MlflowClient 를 사용하면 된다.

from mlflow.tracking import MlflowClient

# Create an experiment with a name that is unique and case sensitive.
client = MlflowClient()
experiment_id = client.create_experiment("Social NLP Experiments")
client.set_experiment_tag(experiment_id, "nlp.framework", "Spark NLP")

# Fetch experiment metadata information
experiment = client.get_experiment(experiment_id)
print("Name: {}".format(experiment.name))
print("Experiment_id: {}".format(experiment.experiment_id))
print("Artifact Location: {}".format(experiment.artifact_location))
print("Tags: {}".format(experiment.tags))
print("Lifecycle_stage: {}".format(experiment.lifecycle_stage))

자세한 내용은 공식 docs를 참고하자.

 

Run 생성 및 조회

위에서 실험을 생성했으므로 이번에는 실행을 생성해보자.
먼저 mlruns 내부를 확인해본다.

위에서 새로 만든 1, 2 실험에는 아직 아무런 실행이 없다.
다음 명령어로 실행을 생성한다.

$ mlflow run sklearn_elasticnet_wine -P alpha=0.5 --no-conda --experiment-id 2

끝에 --experiment-id 를 붙여주었다.
다음처럼 실험 이름으로 할 수도 있다.

$ mlflow run sklearn_elasticnet_wine -P alpha=0.25 --no-conda --experiment-name "experiments-2"

잘 실행된걸 확인했으므로, 이제 결과가 잘 나왔는지 ./mlruns 경로에서 확인하자.

2 번 실험에 위에서 생성한 실행들이 잘 생성된 것을 볼 수 있다.

다음처럼 환경 변수로 실험 ID를 잡아줄 수도 있다.

$ export MLFLOW_EXPERIMENT_ID = 2

---

정리

• MLflow 에는 실험(Experiments)과 실행(Runs)이란 개념이 있다.
• 하나의 ML 프로젝트는 하나의 실험으로 구성할 수 있다.
• 하나의 실험은 여러 개의 실행으로 구성된다.
  • 각 실험마다 ML 모델의 하이퍼 파라미터 조정 등을 다르게 하여 수행할 수 있다.
• CLI 혹은 코드에서 실험과 실행의 생성, 조회, 삭제 등의 명령을 할 수 있다.

# 참조 : https://dailyheumsi.tistory.com/258?category=980484

 

 

저번 Quick 리뷰 글에 이어 계속해서 작성한다.
이번 글은 MLflow 에서 제공하는 Automatic Logging 기능 예제들을 살펴본다.

 

---

사전 준비

다음이 사전에 준비 되어 있어야 한다.

# 파이썬 버전 확인
$ python --version
Python 3.8.7

# mlflow 설치 & 버전 확인
$ pip install mlflow
$ mlflow --version
mlflow, version 1.16.0

# 예제 파일을 위한 mlflow repo clone
$ git clone https://github.com/mlflow/mlflow.git
$ cd mlflow/examples

 

---

예제 살펴보기

linear_regression.py

examples 내에 있는 많은 예제 중, skelarn_autolog 를 사용해보자.
먼저 sklearn 을 설치해준다.

# sklearn 설치 & 버전 확인
$ pip install sklearn
$ python -c "import sklearn; print(sklearn.__version__)"
0.24.2

skelarn_autolog/linear_regression.py 를 보면 다음처럼 생겼다.

# skelarn_autolog/linear_regression.py

from pprint import pprint

import numpy as np
from sklearn.linear_model import LinearRegression

import mlflow
from utils import fetch_logged_data


def main():
    # enable autologging
    mlflow.sklearn.autolog()

    # prepare training data
    X = np.array([[1, 1], [1, 2], [2, 2], [2, 3]])
    y = np.dot(X, np.array([1, 2])) + 3

    # train a model
    model = LinearRegression()
    with mlflow.start_run() as run:
        model.fit(X, y)
        print("Logged data and model in run {}".format(run.info.run_id))

    # show logged data
    for key, data in fetch_logged_data(run.info.run_id).items():
        print("\n---------- logged {} - ---------".format(key))
        pprint(data)


if __name__ == "__main__":
    main()

소스코드가 아주 간결하고 잘 설명되어 있다. 내용은 Linear Regression을 사용하는 간단한 머신러닝 코드다.
여기서는 2가지 코드가 눈에 띈다.

• mlflow.sklearn.autolog()
  • Automatic Logging 기능을 사용하는 설정이다.
  • 코드 앞부분에 들어가야 한다.
• with mlflow.start_run() as run:
  • MLflow 의 실행(run) 의 시작을 알리는 컨텍스트 매니저 구문이다.
  • run 에는 실행과 관련된 내용이 들어간다.

이제 다음 명령어로 실행해보자.

$ python sklearn_autolog/linear_regression.py

실행하고 나면 위와같은 출력이 나온다.
warning 은 일단 무시하면 될듯하고.. 로그를 좀 살펴보면, run_id 가 8f93587bcd384c198daee5aaef6f5c4b 로 생성되었고, 다음 사항들이 자동으로 기록한 것을 알 수 있다.

• params
  • 모델 생성(위에서는 LinearRegression)에 사용하는 params 를 기록한다.
  • 부연 설명하면... copy_X, fit_intercept 등의 파라미터는 LinearRegression 의 __init__ 파라미터다.
• metrics
  • 모델 훈련 중에 평가하는 metrics를 기록한다.
  • 위의 경우, mae, mse, r2_score, rmse, score (이건 뭔지 모르겠다.) 를 모두 기록해주었다.
• tags
  • 이 실행에 관련된 tag 를 기록한다.
  • 기본적으로 모델의 패키지와 클래스 이름을 기록한다.
• artifacts
  • 실행에 대한 메타 정보와 모델 파일을 기록한다.

실제로 잘 생성되었는지 mlruns/ 에서 확인해보자.

$ tree mlruns/

8f93587bcd384c198daee5aaef6f5c4b 디렉토리에 각종 내용들이 로깅된 파일들이 있는 것을 볼 수 있다.
실제 어떤 값들이 들어가있는지 쉽게 보기위해 웹서버로 접속해서 봐보자.

$ mlflow ui
[2021-05-01 14:36:15 +0900] [87757] [INFO] Starting gunicorn 20.1.0
[2021-05-01 14:36:15 +0900] [87757] [INFO] Listening at: http://127.0.0.1:5000 (87757)
[2021-05-01 14:36:15 +0900] [87757] [INFO] Using worker: sync
[2021-05-01 14:36:15 +0900] [87759] [INFO] Booting worker with pid: 87759

params , metrics, tags 등을 좀 더 자세히 확인해보기 위해 sklearn 모델을 클릭하여 실행 상세 페이지에 들어가보자.

위에서 출력한 내용들이 모두 잘 들어가있는 것을 볼 수 있다.

 

pipeline.py

이번엔 skelarn_autolog/pipeline.py 예제를 살펴보자.
이 파일은 다음처럼 생겼다.

from pprint import pprint

import numpy as np
from sklearn.linear_model import LinearRegression
from sklearn.preprocessing import StandardScaler
from sklearn.pipeline import Pipeline

import mlflow
from utils import fetch_logged_data


def main():
    # enable autologging
    mlflow.sklearn.autolog()

    # prepare training data
    X = np.array([[1, 1], [1, 2], [2, 2], [2, 3]])
    y = np.dot(X, np.array([1, 2])) + 3

    # train a model
    pipe = Pipeline([("scaler", StandardScaler()), ("lr", LinearRegression())])
    with mlflow.start_run() as run:
        pipe.fit(X, y)
        print("Logged data and model in run: {}".format(run.info.run_id))

    # show logged data
    for key, data in fetch_logged_data(run.info.run_id).items():
        print("\n---------- logged {} ----------".format(key))
        pprint(data)


if __name__ == "__main__":
    main()

sklearn.pipeline.Pipeline 을 사용하는 간단한 머신러닝 코드다.
바로 실행해보자.

$ python sklearn_autolog/pipeline.py

logged_params 를 보면 Pipeline 에 들어가는 모든 파라미터를 기록하는 것을 볼 수 있다.
기록된 값 역시 mlruns/ 에 저장된다.

 

grid_search_cv.py

마지막으로, skelarn_autolog/grid_search_cv.py 예제를 살펴보자.
다음처럼 생겼다.

from pprint import pprint

import pandas as pd
from sklearn import svm, datasets
from sklearn.model_selection import GridSearchCV

import mlflow
from utils import fetch_logged_data


def main():
    mlflow.sklearn.autolog()

    iris = datasets.load_iris()
    parameters = {"kernel": ("linear", "rbf"), "C": [1, 10]}
    svc = svm.SVC()
    clf = GridSearchCV(svc, parameters)

    with mlflow.start_run() as run:
        clf.fit(iris.data, iris.target)

    # show data logged in the parent run
    print("========== parent run ==========")
    for key, data in fetch_logged_data(run.info.run_id).items():
        print("\n---------- logged {} ----------".format(key))
        pprint(data)

    # show data logged in the child runs
    filter_child_runs = "tags.mlflow.parentRunId = '{}'".format(run.info.run_id)
    runs = mlflow.search_runs(filter_string=filter_child_runs)
    param_cols = ["params.{}".format(p) for p in parameters.keys()]
    metric_cols = ["metrics.mean_test_score"]

    print("\n========== child runs ==========\n")
    pd.set_option("display.max_columns", None)  # prevent truncating columns
    print(runs[["run_id", *param_cols, *metric_cols]])


if __name__ == "__main__":
    main()

iris 데이터셋을 사용하고, svm 모델을 사용하는데, 이 때 GridSearchCV 를 사용하여 최적의 모델 파라미터를 찾는 머신러닝 코드다.
# show data logged in the parent run 아래 부분은 뭔가 양이 많은데, 그냥 로깅된 내용을 출력해주는 부분이므로, 여기서는 주의 깊게 봐지 않아도 된다.

아무튼 이 코드도 실행해보자.

$ python sklearn_autolog/grid_search_cv.py

출력된 내용을 보면 크게 parent run 과 child runs 으로 구성해볼 수 있다.
parent run 에서는 전체 파이프라인에 들어간 파라미터 값들을 기록하고, 또 이 GridSearch 를 통해 찾은 최적의 파라미터 값을 기록한다. (best_C, best_kernel ).
child runs 에서는 GridSearch 진행할 때 각각 파라미터 경우의 수대로 run 들을 실행하고 기록한 모습을 볼 수 있다. 이 때 child runs 들도 각각 하나의 run 이 되므로 run_id 를 가지게 된다. 즉 GridSearch 에서 파라미터 조합의 경우의 수가 많아지면, 그만큼의 실행(run) 이 생기게 된다.

실제 mlruns 를 확인해보면 이 child run 들이 생긴 것을 볼 수 있다.
(다만 parent run 과 별다른 디렉토리 구분은 없다. 즉 누가 child run 인지 디렉토리 구조로는 파악이 잘 안된다.)

그렇다면 웹서버에서는 어떻게 보여줄까?
웹서버에서도 child run 들을 parent run 들과 구분 없이 보여줄까?
이를 확인하기 위해 웹서버로 접속해서 확인해보자.

재밌게도 웹서버에서는 parent run 만 보인다.
grid_search_cv.py 가 있는 행에 + 버튼을 눌러보면 아래와 같이 child runs 가 나온다.

run 자체는 GridSearch 에 맞게 독립적으로 여러 개로 생성하되, run 간에 Parent, Child 관계를 가질 수 있는 것이다.
parent_run_id 로 mlruns 디렉토리를 검색해보면, 이러한 관계가 어떻게 구성될 수 있는지 알 수 있다.

mlruns 에서 child run 의 디렉토리 구조를 살펴보면 tags/mlflow.parentRunId 가 있는 것을 볼 수 있다.
그리고 이 파일에 위 사진처럼 부모 run_id 가 기록되어 있다. (b09de55d441e4a6ea0386f45c58dd96c 는 dc302019f7fb45ffa82165fcd679b84a 의 parent run 이다.)

그리고 child run 은 artifact 과 관련하여 어떤 것도 기록하지 않고, metrics, params, tags 만 기록한다. artifacts 는 최종적으로 최적화된 모델을 사용하는 parent run 에서만 기록한다.

---

정리

• mlflow.sklearn.autolog() 기능으로 로깅 함수를 쓰지 않아도 자동 로깅을 사용할 수 있다.
  • autolog() 는 머신러닝 프레임워크별로 지원한다. 이에 대한 내용은 여기에서 확인하자.
  • artifacts ,params, metrics, tags 등을 모두 기록한다.
• GridSearch 를 쓰는 경우 여러 개의 run 들을 만들어 실행하고 기록한다.
  • run 은 parent run 과 child run 으로 구성된다.
  • child run 은 GridSearch 에 사용되는 파라미터 별로 실행한다.
  • parent run 은 child run 중 가장 최적화된 파라미터를 가지고 실행한다.
  • parent run 만 artifacts 를 기록한다.
  • 웹서버에서도 parent - child 구조를 확인할 수 있다.

이전 글에서 모델러가 로깅을 위해 mlflow 를 알고 써야하는 의존성에 대해서 걱정했었는데, 자동 로깅 기능을 사용하면 이러한 걱정이 좀 많이 내려가지 않을까 싶다.

# 참조 : https://seokk.tistory.com/46

 

 

설치 환경 : CentOS 7 minimal (최소설치)

 

VMware에 설치합니다.

 

 

운영체제 파일은 CentOS 다운로드 사이트에서 minimal.iso를 다운받습니다.

 

설치 시작 전 네트워크 설정을 VMware NAT로 설정하였고

 

 

다운로드한 CentOS 7 minimal.iso를 import 했습니다.

 

 

 

 

 

 

 

 

설치 과정 동안 한글로 번역되어 보이도록 하고 '계속진행'을 클릭합니다.

 

 

 

]

 

 

 

디스크 공간은 자동으로 설정해서 설치해도 되지만

 

조금이라도 권장사항에 따라 설치하기 위해

 

 

 

 

 

 

파티션 설정을 클릭해 완료버튼을 클릭합니다.

 

 

 

 

 

 

제타위키에서 리눅스 스왑메모리 크기 권고사항 에 따라

VMware의 RAM을 1G로 설정한 바

 

RAM이 2G 미만일 경우 swap공간은 RAM의 2배를 권장한다.

 

그러므로 swap 공간을 2G로 설정하고 그 외 /boot 500M 와 나머지 용량은 /(root)로 지정하였다.

 

 

 

 

 

 

완료를 클릭한다

 

 

 

 

 

 

설치 시작 전 네트워크를 VMware NAT로 설정해두었기 때문에

 

유선 연결을 키면 바로 IP가 자동할당된다

 

 

 

설치시작을 클릭한다

 

 

 

 

 

 

ROOT암호만 설정해도 되고, 둘다 설정해도 된다.

 

 

 

 

 

 

ROOT 암호를 설정하고 완료버튼을 클릭한 다음 설치가 완료되길 대기한다

 

 

 

설치가 완료되면 재부팅 버튼이 오른쪽 하단에 생기며

 

재부팅 버튼을 클릭한다

 

 

 

 

 

 

 

설치가 정상적으로 되어 부팅된 것을 볼 수 있다.

 

 

 

이제 몇가지 필요한 것을 설치해본다.

 

 

 

네트워크를 이용해 필요한 도구를 설치하므로

 

 

네트워크 설정을 하지 않은 경우

$vi /etc/sysconfig/network-scripts/ifcfg-enpXXX

 

위 경로의 파일을 열어 필요 부분을 수정한다.

기본적으로 DHCP 사용하도록 설정되어 있으므로 ONBOOT=NO 부분을 ONBOOT=YES로 수정하거나

DHCP를 사용하지 않고 고유한 IP사용할 경우 사용할 IP 직접 입력한다.

 

설정 후 반드시

# systemctl restart network

# systemctl restart NetworkManager

를 실행하도록 한다

 

 

다음 진행과정 동안은 root로 접근하여 설치 및 설정하도록 한다

 

 

CentOS7에서 'ifconfig'명령어는 기본 설치에서 제외되어 있으므로

 

 

'Ip addr' 명령어로 네트워크가 잘 설정되어 있는 지 확인 후 다음 과정을 진행하도록 한다.

 

 

 

Ifconfig 외 네트워크 도구를 사용할 테니 Net-tools를 설치하도록 한다.

 

 

 

 

 

net-tools 설치 완료

 

 

* nmtui 명령어를 사용해 host-name과 network 설정을 할 수 있다.

 

아직 난 호스트이름을 설정하지 않아 @뒤 localhost로 뜬다.

 

호스트이름은 따로 설정해두록 하자.

 

 - 호스트이름 설정 명령 : # hostnamectl set-hostname [호스트 이름]

 

 

 

 

외부에서 원격접속하여 들어가는 경우가 많으므로 ssh를 설치하도록 하자.

 

 

 

 

 

 

openssh-server 설치 완료

 

 

 

 

부팅 시 자동 서비스 시작을 위해 위와 같이 입력하여 설정해준다

 

 

또한,

 

 

위 경로의 파일에서

 

몇가지 주석과 설정을 하도록한다.

 

 

 

 

 

Port 22

AddressFamily inet

LoginGraceTime 2m

PermitRootLogin no

PermitEmptyPasswords no

X11Forwarding no

UseDNS no

 

위 목록을 찾아 주석과 설정을 수정하고 저장한다.

 

 

 

VMware에 설치했다면 open-vm-tools도 설치하여

community update, opensource version, host 시간 동기화를 지원 받도록 한다.

 

 

 

SELinux는 보안을 강화해주는 보안강화커널로 zero-day attack, buffer overflow 등

취약점으로 인한 해킹을 방지해주는 핵심 구성요소다

 

하지만 접근권한의 제한을 받거나 특정 서비스가 SELinux로 인해

동작하지 않은 경우가 발생한다

 

SELinux를 끄도록 한다.

 

* SELinux를 끄기보단 해당 서비스가 SELinux 하에서 잘 동작하도록 설정하는 것을 권장한다.

 

 

 

 

위 경로의 파일로 이동해 수정한다

 

 

 

 

 

SELINUX=enforcing 이라고 되어있는 부분을 SELINUX=disabled로 변경해준다.

 

 

 

firewalld(방화벽)에 의해 iptables룰이 생성됨으로 firewalld를 비활성화 및 중지하고

 iptables와 관련된 패키지를 설치하도록 한다.

 

 

 

firewalld 비활성화 및 중지

 

* stop - 중지   dismask - 서비스제거   disable - 부팅 시작시 비활성화

 

 

 

 

iptables 관련 패키지 설치

 

 

 

 

설치 완료

 

 

 

부팅시 시작하도록 iptables 생성 및 설정

 

 

 

타임존 확인 및 설정

 

 

 

타임존 확인은 위 명령어로 확인한다.

 

 

 

위와 같이 뜬다.

 

 

만약, timedatectl이 작동하지 않는다면 ntpd가 설치되어 있지 않은 것이다.

 

뜨지 않는 다면 다음과 과정을 수행하도록 한다

 

# yum install ntpd <-- 설치

# systemctl start ntpd

# systemctl enable ntpd

#timedatectl <-- 확인

 

 

 

추가로 타임존 위치를 변경하려면

 

그 변경가능한 리스트 확인은

 

# timedatectl list-timezones

 

위 명령으로 확인한다.

 

 

만약, 서울로 타임존을 설정한다면

 

 

변경가능한 리스트의 내용중에서 Seoul 검색

 

 

 

서울타임존 검색 됨

 

 

 

위 타임존으로 설정

 

 

 

timedatectl로 타임존이 변경된 걸 확인할 수 있다.

 

 

 

그 외 추가로 epel을 설치해주도록 하자

 

* epel(Extra Packages of enterprise Linux) : yum으로 설치되지 않는 패키지를 설치되도록 도와주는 리눅스 추가 패키지

 

 

 

 

* nmap :  포트를 스캔해주는 툴로 호스트나 네트워크 스캐닝시 사용하는 도구

 

 

설치 과정을 살펴보면 첫부분에서 epel을 불러와 yum으로 설치되지 않는 패키지를 설치하도록 도와주는 걸 볼 수 있습니다.

 

 

포트 확인은

 

# nmap localhost