강지현

# 들어가며

어떠한 연구 목적으로 AI를 학습시켜 결과물을 만들어내야 하는 상황에 있다고 가정해봅시다. 우리가 해야 할 일은 AI에게 가르쳐 준 데이터를 AI가 올바르게 학습하길 기다리는 것뿐이죠. 하지만 AI를 '활용'하는 어떠한 서비스를 만든다고 가정하면 이야기가 복잡해집니다. 다양한 모델을 어떻게 시스템에 적용시킬 것인지, 부하 상황에서 어떤 기준에 의해 스케일링을 시켜야 할지 모든 요소 하나하나가 고민거리죠. 이런 고민에 대한 답을 얻기 위해 함부로 사용자가 존재하는 프로덕션 환경을 수정할 수도 없습니다. 프로덕션 환경을 늘렸다 줄였다 하다가 사고라도 난다면 끔찍한 일이 생길 수도 있거든요. 만약에 끔찍한 일이 벌어졌다면, 벌어진 일을 수습하기 위한 시간이 필요할 텐데, 우리 서비스를 사용하는 소비자에게는 모델 학습을 기다리는 연구자와 같은 참을성을 기대할 수 없을 겁니다. 엔지니어링 영역의 어려움 외에 비용에 대한 어려움도 있습니다. 모델을 서비스하는데에는 당연히 비용이 들고, 모델을 학습시키는 그 순간에도 자원을 소모하고 있는 만큼 사용자가 비용을 지출하고 있는 셈이니까요. 
그러나 걱정하실 필요는 없습니다. 이미 세상에는 잘 만들어진 모델들이 많이 존재하고, 우리는 그러한 모델들을 가져다가 서비스하는 것으로 충분한 경우가 많거든요. 저희 솔루션에 관심이 있으셨던 분들이라면 다 아시는 내용이겠지만, Backend.AI는 이미 여러분이 모델을 서비스할 때 필요로 하는 기능들을 다양하게 지원하고 있습니다. 트래픽에 따라 서비스를 늘리는 것이나 줄이는 것도, 사용자의 입맛에 맞춘 다양한 모델을 서비스하는 것도 가능하죠.

그러나 여기서 멈출 Backend.AI 팀이 아닙니다. 저희는 Backend.AI의 23.09 버전부터 제공된 모델 서비스를 한 층 강화하였고, 다양한 모델을 손쉽게 서비스할 수 있도록 개선하였습니다. 이번 포스팅을 통해 어떤 방법으로 쉽고 간편하게 다양한 모델을 서비스할 수 있는지 알아봅니다.

> 이번 포스팅에서는 다양한 종류의 모델을 더욱 간편하게 서비스할 수 있는 기능을 소개합니다. 모델 서비스에 대한 설명은 23.09 버전 업데이트를 릴리즈하며 한 차례 드린 적이 있기 때문에, 자세한 설명은 생략하겠습니다. Backend.AI의 모델 서비스가 생소하시다면, 다음 포스팅을 먼저 읽어보시는 것을 추천합니다. [Backend.AI Model Service 미리 보기](https://www.backend.ai/blog/2023-05-30-backend.AI-model-service-sneak-peek)

# 기존 방식

|    | 필요조건 | 기존 방식 | 모델 배리언트(Model Variant)  |
|---|----------|------------|----------------------------------|
| 1 | 모델 정의 파일(model-definitionl.yaml) 작성 | O | X    |
| 2 | 모델 정의 파일을 모델 폴더에 업로드 | O | X |
| 3 | 모델 메타데이터 필요 | O | △* (일부는 자체 다운로드 가능) |

Backend.AI 모델 서비스는 실행하기 위한 모델 메타데이터 외에 모델을 서비스할 때 실행할 명령어를 일정한 형식으로 담아둔 모델 정의 파일 (model-definition.yaml)을 필요로 했습니다. 서비스를 실행하는 순서는 다음과 같습니다. 모델 정의 파일을 작성하고, 모델 정의 파일을 읽을 수 있도록 모델(model) 타입 폴더에 업로드한 뒤, 모델서비스 시작시 모델 폴더를 마운트하면 자동으로 모델 정의 파일에 따라 엔드유저의 입력을 받아 모델로 전달하고, 응답 값을 보내주는 API 서버 등이 실행되는 형태였습니다. 하지만 이 방식은 모델 정의 파일을 수정할 때마다 파일에 접근해야한다는 단점이 있었습니다. 또, 이미 모델 정의 파일에 모델 경로가 정해져있기 때문에 모델이 달라질 때마다 모델 정의 파일을 다르게 작성해야 하는 것도 귀찮은 부분이었습니다.
이번에 선보이는 모델 배리언트(Model Variant)는 모델 정의 파일이 없이 모델 메타데이터만을 가지고 몇 가지 설정값을 입력하거나, 또는 아예 입력할 필요없이 즉시 모델을 서비스할 수 있는 기능입니다. 모델 배리언트에서는 커맨드(command), vLLM, 그리고 NIM(NVIDIA Inference Microservice) 방식을 지원합니다. 서비스하는 방법과 모델 서비스 실행을 확인하는 방법은 다음과 같습니다.


이번에 선보이는 모델 배리언트(Model Variant)는 모델 정의 파일이 없이 모델 메타데이터만을 가지고 몇가지 설정값을 입력하거나, 또는 아예 입력할 필요없이 즉시 모델을 서비스 할 수 있는 기능입니다. 모델 
배리언트에서는 커맨드(command) 방식, vLLM 방식, 그리고 NIM(NVIDIA Inference Microservice) 방식을 지원합니다. 서비스하는 방법과 모델 서비스 실행을 확인하는 방법은 다음과 같습니다.

> 기본적으로, 모델 서비스는 서빙할 모델 메타데이터를 필요로 합니다. 가장 손쉽게 접할 수 있는 모델 메타데이터를 받을 수 있는  [Hugging Face](https://huggingface.co/models) 에서 서비스할 모델을 다운로드 받아보세요. 이번 예제에서는 Hugging Face 의 [Llama-2-7b-hf](https://huggingface.co/meta-llama/Llama-2-7b-hf) 모델과 [Calm3-22b-chat](https://huggingface.co/cyberagent/calm3-22b-chat) 모델을 사용했습니다. 모델 메타데이터를 모델 폴더에 업로드 하는 방법은 앞의 포스팅의 [모델 스토리지 준비](/ko/blog/2023-05-30-backend.AI-model-service-sneak-peek#모델-스토리지-준비)를 참고하십시오.

# 빌드된 이미지에서 자동으로 모델 서비스하기 (command 방식)

첫 번째로 소개하는 커맨드 방식은 모델 정의 파일에서 모델을 서비스하기 위해 실행하는 명령어 부분이 실행 이미지에 들어간 형태입니다. `CMD` 라는 환경변수에 실행할 명령어를 지정한 뒤, 이미지를 빌드해 실제 모델을 서비스할 때 다른 입력 없이 바로 실행하는 방식이죠. 커맨드 방식은 서비스가 제대로 실행되고 있는지 확인하는, 이른바 Health check를 지원하지 않습니다. 따라서 대규모의 서비스를 수행할 때보다는 프로토타입으로 바로 서비스를 띄워서 확인해 볼 때 적절합니다. 실행방법은 다음과 같습니다.


1. 시작화면에서 서비스할 모델 서비스에 해당하는 모델 메타데이터가 들어있는 모델 폴더를 마운트하도록 Model Storage To Mount 항목에서 `Llama-2-7b-hf` 를 선택하고, Inference Runtime Variant 항목에서 Predefined Image Command 를 선택합니다.   

> 모델 서비스를 별도의 토큰없이 접근할 수 있도록 제공할 경우 Open To Public 스위치 버튼을 활성화 해주세요.

![모델-서비스-시작화면-모델-메타데이터-마운트-및-CMD-선택](https://cdn.lablup.com/cmd_model_variant_selected_in_model_service_launcher_1_279931a66c.png)

2. 서비스할 환경을 선택합니다. 여기서는 `vllm:0.5.0` 를 사용하고, 자원은 CPU 4 Core, Memory 16 GiB, NVIDIA CUDA GPU 10 FGPU 를 할당하도록 설정했습니다.   

![모델-서비스-시작화면-실행환경-선택-및-자원할당](https://cdn.lablup.com/cmd_model_variant_selected_in_model_service_launcher_2_01fb14385f.png) 

3. 마지막으로 클러스터 크기를 선택하고, 시작버튼을 클릭합니다. 클러스터 크기는 싱글노드, 싱글 컨테이너로 설정했습니다.

![모델-서비스-시작-화면-클러스터-크기-선택-및-시작](https://cdn.lablup.com/cmd_model_variant_selected_in_model_service_launcher_3_d401885607.png) 

서비스가 성공적으로 띄워졌다면, 서비스 상태는 `HEALTHY` 로 바뀌게 되고 엔드포인트 주소가 나오게 됩니다.

![모델-서비스-상세-화면](https://cdn.lablup.com/cmd_model_variant_status_healthy_be1df76a76.png) 


## 서비스 확인하기

서비스가 정상적으로 띄워졌다면, `cURL` 명령어로 서비스 모델명을 우선 확인합니다.

```sh
curl https://cmd-model-service.asia03.app.backend.ai/v1/models \
-H "Content-Type: application/json"
```

![모델명-확인하기](https://cdn.lablup.com/cmd_model_variant_serving_model_check_e485a7a941.png) 

이제 서비스에 보낼 입력을 `cURL` 명령어로 보내고, 응답값을 확인해보겠습니다.

> CMD로 실행하는 모델 서비스는 이미지에 이미 모델명이 정의되어 있기 때문에 모델명을 확인후 요청을 보낼 때 모델명을 `model` 키의 값으로 입력해야 합니다.

```sh
curl https://cmd-model-service.asia03.app.backend.ai/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "image-model",
"prompt": "San Francisco is a",
"max_tokens": 7,
"temperature": 0}'
```

![모델-서비스-요청-결과-화면](https://cdn.lablup.com/cmd_model_variant_serving_result_9c48dc19e6.png) 

# vLLM 모드로 모델 서비스하기

vLLM 모드는 앞에서 소개한 커맨드 방식과 비슷하지만, vLLM 을 실행할 때 입력하는 여러가지 옵션들을 환경변수로 작성할 수 있습니다. 실행방법은 다음과 같습니다.


## 실행방법

1. 시작화면에서 서비스할 모델 서비스에 모델 폴더를 마운트하고, Inference Runtime Variant 항목에서 `vLLM` 을 선택합니다.

![모델-서비스-시작-화면-모델-메타데이터-마운트-및-vLLM-선택](https://cdn.lablup.com/vllm_model_variant_selected_in_model_service_launcher_1_68087bc66c.png) 


2. 서비스할 환경을 선택합니다. 앞서 설명한 커맨드 방식과 동일하게 `vllm:0.5.0` 으로 선택하고, (자원은 동일하게 설정해도 되지만) 이번에는 CPU 16 Core, Memory 64 GiB, NVIDIA CUDA GPU 10 fGPU를 할당하도록 하겠습니다.

![모델-서비스-시작-화면-실행환경-선택-및-자원-할당](https://cdn.lablup.com/vllm_model_variant_selected_in_model_service_launcher_2_851a94e52b.png) 

3. 마지막으로 클러스터 크기를 선택하고 환경 변수 `BACKEND_MODEL_NAME` 을 입력합니다. 이 값은 vLLM에서 `--model-name` 옵션에 대응하는 값으로, 사용자가 서비스에 요청을 보낼 때 지정하는 model 값이 됩니다.

![모델-서비스-시작-화면-실행환경-선택-및-자원-할당](https://cdn.lablup.com/vllm_model_variant_selected_in_model_service_launcher_3_updated_15b63bb66e.png) 

마찬가지로 서비스가 성공적으로 띄워졌다면, 서비스 상태는 `HEALTHY` 로 바뀌게 되고, 서비스가 띄워진 엔드포인트 주소가 나오게 됩니다.

![모델-서비스-상세-화면](https://cdn.lablup.com/vllm_model_variant_status_healthy_c0f91fb42f.png) 

## 서비스 확인하기

서비스에 보낼 입력을 `cURL` 명령어로 보내고, 응답값을 확인해보겠습니다. 이 때 `model` 값은 아까 설정한 `BACKEND_MODEL_NAME` 값으로 입력합니다.  입력이 끝났다면 `START` 버튼을 클릭해서 서비스를 생성합니다.

```sh
curl https://vllm-calm3-22b-chat.asia03.app.backend.ai/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "vllm-model",
"prompt": "初めて会う日本人ビジネスマンに渡す最高の挨拶は何でしょうか？",
"max_tokens":  200,
"temperature": 0
}'
```
![모델-서비스-요청-결과-화면](https://cdn.lablup.com/vllm_model_variant_result_2_ad74f0309e.png) 


# NIM 모드로 모델 서비스하기

> NIM 을 실행하기 위해서는 NGC의 NIM 모델 레지스트리에 접근할 수 있는 계정으로부터 발행된 API 키가 있어야 합니다. 키값을 얻는 방법은 다음 내용을 참고하시기 바랍니다. 
> [NVIDIA Docs Hub : How to get NGC API Key](https://docs.nvidia.com/ai-enterprise/deployment-guide-spark-rapids-accelerator/0.1.0/appendix-ngc.html)

NIM(NVIDIA Inference Microservice) 모드 역시 커맨드 모드와 유사하나, NVIDIA의 NIM을 지원하는 모델 서버가 내장된 이미지로 실행해야 합니다. 또, 모델을 불러올 때에, NGC API 키 값이 필요합니다. 모든 것이 준비되었다는 가정하에 모델 서비스를 시작해보겠습니다.


## 실행방법

1. 시작화면에서 서비스할 NIM 에서 받아올 메타데이터를 캐싱할 비어있는 모델 타입 폴더를 선택하고, Inference Runtime Variant 항목에서 `NIM` 을 선택합니다.   

![모델-서비스-시작-화면-모델-폴더-마운트-및-NIM-선택](https://cdn.lablup.com/nim_model_variant_selected_in_model_service_launcher_1_efc31faaf0.png) 

2. 서비스할 환경을 선택합니다. 여기서는 ``ngc-nim:1.0.0-llama3.8b`` 를 사용하고, 자원은 CPU 8 Core, Memory 32 GiB, NVIDIA CUDA GPU 15 FGPU 를 할당하도록 설정했습니다.   

![모델-서비스-시작-화면-실행환경-선택-및-자원-할당](https://cdn.lablup.com/nim_model_variant_selected_in_model_service_launcher_2_ee2be391e0.png) 

3. 마지막으로 클러스터 크기를 선택하고 환경 변수 `HF_HOME`으로 기본 경로인 `/models` 경로를 입력합니다. 그리고 `NGC_API_KEY` 을 입력하고, 발급받은 키값을 입력합니다. 입력이 끝났다면 `CREATE` 버튼을 클릭해서 서비스를 생성합니다.

![모델-서비스-시작-화면-클러스터-크기-선택-환경변수-입력-및-시작](https://cdn.lablup.com/nim_model_variant_selected_in_model_service_launcher_3_updated_bfbe08607d.png) 

> NIM 을 사용할 경우 모델 메타데이터를 저장소로부터 받아오기 때문에 처음 실행시에는 다소 시간이 소요될 수 있습니다. 세션 페이지에서 서비스중인 라우팅 세션에 대한 컨테이너 로그를 확인하여 진행상황을 확인할 수 있습니다.
> ![모델-서비스에-대응하는-라우팅-세션](https://cdn.lablup.com/nim_model_variant_session_row_dd01dac411.png) 
> ![NIM-에서-데이터를-받고-있는-로그가-띄워진-컨테이너-로그-화면](https://cdn.lablup.com/nim_model_variant_nim_cache_cb99e937e1.png) 

커맨드, vLLM 모드와 같이 서비스가 성공적으로 띄워졌다면, 서비스 상태는 `HEALTHY` 로 바뀌게 됩니다. 서비스가 띄워진 엔드포인트 주소를 활용해 서비스에 보낼 내용을 다음과 같이 입력하고, 응답값을 확인해보겠습니다. 

## 서비스 확인하기

```python
from openai import OpenAI

client = OpenAI(
  base_url = "https://nim-model-service.asia03.app.backend.ai/v1",
  api_key = "$YOUR_NGC_API_KEY"
)

completion = client.chat.completions.create(
  model="meta/llama3-8b-instruct",
  messages=[
      {        
        "role":"user", 
        "content":"Hello! How are you?"
      },
      {
        "role":"assistant",
        "content":"Hi! I am quite well, how can I help you today?"
      },
      {
        "role":"user",
        "content":"Can you write me a song?"
      }],
  temperature=0.5,
  top_p=1,
  max_tokens=1024,
  stream=True
)

for chunk in completion:
  if chunk.choices[0].delta.content is not None:
    print(chunk.choices[0].delta.content, end="")
```

![모델-서비스-요청-결과-화면](https://cdn.lablup.com/nim_model_variant_serving_result_ed05acc7d8.png) 

# 마치며

모델 배리언트 기능은 이미 학습된 모델로 실질적인 서비스를 제공하는 것을 목표로 하는 연구자와 기업에 많은 도움이 될 것입니다. 강력한 자원 관리 시스템과 NVIDIA GPU, AMD ROCm, TPU, Graphcore IPU, Furiosa Warboy, Rebellions ATOM, Hyperaccel LPU 등과 같이 다양한 AI 가속기 지원을 바탕으로 한 Backend.AI 는 이제 단순히 모델을 학습하는 것을 뛰어넘어 서비스까지 쉽게 배포할 수 있는 통합 환경을 제공하게 되었습니다.
Backend.AI 와 함께 여러분이 원하는 AI 모델을 언제든 서비스해보세요.


Model Variant: 손쉽게 대접하는 다양한 모델 서비스

성대현

Backend.AI 오픈소스 기여 가이드 (2024년 7월)

신정규

자연으로부터 다시 배우기: 뉴로모픽 컴퓨팅과 딥 러닝

강정석

이제는 클래식이 되어버린 AlexNet부터 오늘날 뜨거운 관심을 받고 있는 여러 거대 언어 모델(이하 LLM)들까지, 우리는 필요에 맞게 다양한 모델을 학습하고 평가합니다. 그러나 현실적으로 모델을 여러 번 실행해 보고 경험이 쌓이기 전까지 우리는 학습이 언제 종료될지 가늠하기 어렵습니다.

Backend.AI의 뛰어난 스케줄링은 GPU의 유휴 시간을 최소화하고 우리가 잠든 사이에도 모델 학습이 실행될 수 있도록 하였습니다. 그렇다면 더 나아가서, 우리가 잠든 사이에 학습이 완료된 모델의 결과를 전달받을 수 있다면 어떨까요? 이번 글에서는 FastTrack의 신기능과 Slack을 활용하여 모델 학습 결과를 메시지로 수신하는 방법을 다뤄보도록 하겠습니다.

> 이 글은 [Backend.AI FastTrack](https://www.backend.ai/ko/product/fasttrack) 24.03.3 버전을 기준으로 작성되었습니다.


# 들어가기에 앞서

본문은 Slack App 및 Bot을 생성하는 방법을 다루지 않습니다. 자세한 내용은 [공식 문서](https://api.slack.com/tutorials/tracks/getting-a-token)를 참고하는 것을 권장합니다.

# 파이프라인 생성하기

모델 학습에 사용할 파이프라인(Pipeline)을 만들어 보도록 하겠습니다. 파이프라인은 FastTrack에서 사용하는 작업 단위입니다. 각 파이프라인은 최소 실행 단위인 태스크(Task)의 묶음으로 표현될 수 있습니다. 하나의 파이프라인에 포함되는 여러 개의 태스크는 서로 의존 관계를 가질 수 있으며, 이 의존성에 따라 순차적으로 실행됨이 보장됩니다. 각 태스크마다 자원 할당량을 설정할 수 있어 전체 자원을 유연하게 관리할 수 있습니다.

파이프라인에 실행 명령이 전달되면 해당 시점의 상태를 그대로 복제하여 실행되는데, 이러한 단위를 파이프라인 잡(Pipeline Job)이라고 합니다. 하나의 파이프라인에서 여러 개의 파이프라인 잡이 실행될 수 있으며, 하나의 파이프라인 잡은 하나의 파이프라인으로부터 생성됩니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_01_1e7a9f9bcc.png"/>

 파이프라인 생성 버튼


파이프라인 목록 상단에 위치한 파이프라인 생성 버튼("+")을 클릭합니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_02_e6d7004df2.png"/>

 파이프라인 생성하기


파이프라인의 이름과 설명, 사용할 데이터 저장소의 위치, 그리고 파이프라인에서 공통적으로 적용할 환경변수와 파이프라인 초기화 방법 등을 선택할 수 있습니다. `slack-pipeline-0`이라는 이름을 입력한 후 하단의 "Create" 버튼을 클릭하여 파이프라인을 생성합니다.

# 태스크 생성하기

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_03_47d8a90ee4.png"/>

 태스크 끌어오기


새 파이프라인이 생성된 것을 볼 수 있습니다. 이제 태스크를 추가해 보도록 하겠습니다. 상단의 태스크 템플릿 목록(Task templates)에 있는 "Custom Task" 블럭을 마우스로 끌어와서 하단 작업 공간에 놓습니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_04_d136041eea.png"/>

 태스크가 수행할 동작 입력하기


우측에 태스크의 세부사항을 입력할 수 있는 작업창이 나타납니다. `model-training-task`라는 이름을 주어 태스크의 역할을 나타낼 수 있으며, 모델 학습을 진행하기 위하여 `pytorch:1.11-py38-cuda11.3` 이미지를 사용하도록 설정합니다. 실제 모델 학습은 오랜 시간을 소요하므로 이번 예시에서는 아래와 같이 간단한 명령을 수행하도록 합니다.

```shell
# 3초 동안 동작을 중지시킴으로써 실행 시간이 증가합니다.
sleep 3
# 파이프라인 전용 폴더에 `result.txt` 파일을 생성합니다. 학습이 완료된 모델의 정확도라고 가정합니다.
echo "0.$RANDOM" > /pipeline/outputs/result.txt
```

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_05_6ee1550de7.png"/>

 태스크 생성하기 (1)


마지막으로 태스크에 할당할 자원량을 입력한 후 하단의 "Save" 버튼을 클릭하여 태스크를 생성합니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_06_32b7134630.png"/>

 또다른 태스크 끌어오기


모델 학습 태스크가 작업 공간에 생성된 것을 확인할 수 있습니다. 이번에는 앞에서 저장한 `result.txt` 파일로부터 수치를 읽어와 Slack으로 알림을 보내는 태스크를 만들기 위하여 다시 "Custom Task" 블럭을 하단 작업 공간에 가져옵니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_07_ae06c67ede.png"/>

 태스크 단위 환경변수 `SLACK_TOKEN` 입력하기


이번 태스크는 `slack-alarm-task`라고 이름을 설정하고, 아래와 같은 스크립트를 입력하여 Slack에 알림을 보내는 동작을 수행하도록 합니다.

```shell
pip install slack-sdk
python -c '
import os
from pathlib import Path
from slack_sdk import WebClient
SLACK_BOT_TOKEN = os.environ.get("SLACK_TOKEN")
JOB_ID = os.environ.get("BACKENDAI_PIPELINE_JOB_ID")
def main():
 result = Path("/pipeline/input1/result.txt").read_text()
 client = WebClient(token=SLACK_BOT_TOKEN)
 client.chat_postMessage(
 channel="#notification",
 text="Pipeline job({}) finished with accuracy {}".format(JOB_ID, result),
 )
if __name__ == "__main__":
 main()
'
```

위 코드는 `SLACK_TOKEN`, `BACKENDAI_PIPELINE_JOB_ID`라는 이름의 두 환경변수를 활용하고 있습니다. `BACKENDAI_*` 형태의 환경변수는 Backend.AI 및 FastTrack 시스템에서 자동으로 추가하는 값들로, 그중 `BACKENDAI_PIPELINE_JOB_ID`는 각 태스크가 실행되고 있는 파이프라인 잡의 고유 식별자를 나타냅니다.

또 하나의 환경변수인 `SLACK_TOKEN`는 태스크 단위 환경 변수로 추가된 값으로, 이 기능을 활용하면 코드 변경 없이 다양한 값을 관리 및 변경할 수 있습니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_08_1773bf037e.png"/>

 태스크 생성하기 (2)


`slack-alarm-task` 태스크에도 알맞은 자원을 할당해 준 후 하단의 "Save" 버튼을 클릭하여 태스크를 생성합니다.

# 태스크 의존성 추가하기

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_09_0e7fb291fe.png"/>

 태스크 의존성 추가하기


이제 작업 공간에는 두 개의 태스크(`model-training-task`와 `slack-alarm-task`)가 존재합니다. 이때 `slack-alarm-task`는 `model-training-task`이 종료된 후 실행되어야 하므로 두 태스크 간 의존성을 추가해야 합니다. 먼저 실행되어야 할 태스크(`model-training-task`)의 하단에서 나중에 실행되어야 할 태스크(`slack-alarm-task`)의 상단까지 마우스를 끌어다 놓습니다.

# 파이프라인 실행하기

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_10_0eadb2825f.png"/>

 파이프라인 실행하기 (1)


의존성이 추가되어 `model-training-task`에서 `slack-alarm-task` 방향으로 뻗는 화살표가 연결된 것을 볼 수 있습니다. 이제 파이프라인을 실행하기 위하여 우측 상단의 "Run" 버튼을 클릭합니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_11_146b8b7ef7.png"/>

 파이프라인 실행하기 (2)


파이프라인을 실행하기에 앞서 파이프라인의 간단한 요약을 검토할 수 있습니다. 2개의 태스크가 존재하는 것을 다시 한번 확인한 후 하단의 "Run" 버튼을 클릭합니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_12_1b7b772e3c.png"/>

 파이프라인 실행하기 (3)


파이프라인이 성공적으로 실행되어 파이프라인 잡이 생성되었습니다. 하단의 "OK"를 클릭하면 파이프라인 잡의 정보를 볼 수 있습니다.

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_13_fe1f9c4b43.png"/>

 파이프라인 잡


파이프라인 잡이 정상적으로 생성되었습니다. 모델 학습(`model-training-task`)이 완료된 후 `slack-alarm-task`가 실행 중인 것을 확인할 수 있습니다.

# Slack 알림받기

<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_slack_01_f1f1864953.jpg"/>

 Slack 알림 (1)


<img style="margin: auto;" src="https://cdn.lablup.com/blog_fasttrack_slack_02_38a389156e.jpg"/>

 Slack 알림 (2)


파이프라인 잡 실행 결과가 Slack을 통해 사용자에게 전달된 것을 확인할 수 있습니다. 이제 우리는 편한 마음으로 잠들 수 있게 되었습니다.

FastTrack 길라잡이: 모델 학습 결과 알림 받기

이규봉

실제로 동작하는 Raft 구현체 뜯어 보기 - 2

실제로 동작하는 Raft 구현체 뜯어 보기 - 1

래블업 주식회사

2024년 Backend.AI 의 첫 릴리즈인 24.03 이 출시되었습니다. 이번 업데이트에서는 UI 및 사용자 경험이 크게 개선되어 설치와 운영에 대한 기능성이 더욱 향상되었습니다. 지난 23.09 이후 다음과 같은 업데이트 내용을 담고 있습니다.

# Backend.AI Core & WebUI

- TUI 기반 설치 프로그램이 추가되어 Backend.AI 설치가 한결 간편해졌습니다. 이 설치 프로그램은 다운로드 프로세스를 자동화하여 사용자가 Backend.AI를 쉽게 설치하고 시작할 수 있게 해줍니다.

 ![](https://cdn.lablup.com/backendai_TUI_installer_2feb143fc1.png) 
- vfolder 에 휴지통 기능이 추가되었습니다. 이제 사용하지 않는 vFolder 의 파일들은 완전히 삭제하는 대신 휴지통으로 이동하고 이후 휴지통 비우기 명령을 통해 완전히 삭제됩니다. 이와 관련하여 vfolder 의 상태를 나타내는 인자값이 추가되었습니다.
- Backend.AI 모델스토어가 추가되었습니다. 이제 모델스토어에서 다양한 머신러닝 및 딥러닝 모델들을 보관 관리하고 검색하여 쉽게 활용이 가능합니다.
- vfolder 에 색인용 메타데이터를 추가하여 쿼리시 전체 디렉토리 스캔 대신 인덱스를 활용합니다.
- 대기 중인 세션 수와 요청된 리소스 슬롯에 기반한 세션 생성에 대한 제한 정책을 도입하여 시스템 리소스 활용이 향상되었습니다. 이 새로운 리소스 정책 옵션은 세션 런쳐의 리소스 프리셋과 커스텀 리소스 슬라이더의 최대값을 필터링하고 설정하는 데 도움이 됩니다.
- WebUI 에 다크 테마가 추가되었습니다. 이제  사용자들은 개인 취향에 맞는 다양한 옵션의 선택이 가능합니다.

![](https://cdn.lablup.com/Web_UI_dark_theme_397145c15d.png) 
- WebUI 의 정렬되지 않은 줄바꿈, 공백, 밖으로 새어 나온 안내문 등의 화면 조정과 세션명 유효성 검증 같은 안정성을 위한 기능들이 개선되었습니다.
- 모델 서빙용 세션 런처에서도 할당 가능한 자원만큼만 입력 가능하도록 UI 입력이 제한됩니다.
- 다양한 UI 사용자 옵션을 위해 config.toml 파일에 WebUI 앱 다운로드 패널을 숨기는 `allowAppDownloadPanel` 인자를 추가하였습니다. 

Backend.AI 는 하루가 다르게 변하는 AI 생태계에서 다양한 환경을 지원함과 동시에 더욱 강력하고 사용자 친화적인 환경을 제공하고자 끊임없이 발전하고 있습니다. 앞으로의 행보에도 많은 기대 부탁드립니다!
Make your AI accessible with Backend.AI!



24.03: 출시 업데이트

김수진

래블업은 2024년 GTC 이벤트를 기념하여 특별한 이벤트를 개최했다. 참가자들은 래블업이 제공한 LLM 모델을 이용하여 주어진 이미지와 유사한 이미지를 생성했고, 높은 점수를 받은 참가자 중에서 추첨을 통해 무려 NVIDIA RTX 4090 그래픽 카드를 증정했다. 🫢 
이번 포스트에서는 이벤트 페이지 중 참가자들의 점수를 실시간으로 확인할 수 있게 해주는 리더 보드 페이지에 사용된 GraphQL의 subscription 기능에 대해 알아보고자 한다.

<img style="margin: auto;" src="https://cdn.lablup.com/GTC_24_event_main_page_c675fa1692.png"/>

 GTC24 이벤트 페이지


## Subscription 이란?

클라이언트가 서버 측 **이벤트 스트림**으로부터 데이터를 구독하는 메커니즘이다.

데이터가 실시간으로 바뀌는 경우, 예를 들어 실시간 로그나 채팅 어플리케이션 등을 구현할 때, 서버에서 업데이트를 푸시해주면 바로 반영할 수 있다.

subscription은 필요한 정보가 서버에서 변경될 때만 데이터를 보내준다. 따라서 데이터 변경이 빈번하지 않은 경우, subscription은 데이터 트래픽을 줄이고, 이에 따른 비용 절감 효과도 있을 수 있다.

비슷한 개념으로 GraphQL 의 `network-only` fetchPolicy 옵션을 주고 Query 를 요청해서 매번 최신 정보를 가져올수 있지만 subscription과 차이가 있다. Query 는 클라이언트가 데이터를 필요로 할 때마다 항상 서버에 요청하며 항상 최신 데이터를 보장하지만, 각 요청에 대한 네트워크 비용을 수반한다. 그래서 어떤 버튼을 클릭했을 때 항상 최신의 결과를 보여주도록 보장하기 위해 fetchPolic 를 network-only 로 설정하는 것은 괜찮지만, 주식 거래 창과 같이 업데이트가 빈번한 데이터를 가져오기 위해 query를 사용한다면 네트워크 비용이 상당해진다.

결론적으로, 목표 응용 프로그램의 요구 사항, 사용자 수, 데이터의 업데이트 빈도 등에 따라 subscription 을 사용할지, query 를 사용할지 결정해야 한다.

## 사용 방법

### subscription 정의하기

사용 방법은 query 와 유사한데, 키워드만 `subscription` 을 사용해주면 된다.

```graphql
 const leaderboardSubscriptions = graphql`
 subscription Ranking_leaderboardSubscription {
 leaderboard {
 submissions {
 id
 name
 score
 imageUrl
 }
 lastUpdatedAt
 }
 }
 `;
```

`leaderboard` 스트림에서 이벤트가 발생할 때마다 애플리케이션에 알림이 전송되고, 클라이언트에서는 업데이트된 결과를 얻을 수 있다.

그럼 다음과 같은 결과를 얻을 수 있다.

```json
leaderboard: {
	submissions: [
		{
 	"id": "76293167-e369-4610-b7ac-4c0f6aa8f699",
	 "name": "test",
 	"score": 0.5910864472389221,
	 "imageUrl": "<IMAGE_URL>"
		},
 ],
	lastUpdatedAt: 1710176566.493705
}
```

### subscribe

실시간 랭킹을 보여주기 위해 해당 페이지에 들어갈 때 subscribe 를 호출하고, 다른 페이지로 넘어갈 경우, dispose 를 호출하여 unsubscribe 하기 위해 `useEffect`를 사용했다.

```ts
import { useEffect } from 'react';
import { requestSubscription } from 'react-relay';

useEffect(() => {
 const subscriptionConfig = {
 subscription: leaderboardSubscriptions,
 variables: {},
 onNext: (response: any) => {
 setLeaderboard(response.leaderboard.submissions); // 미리 정의된 state
 },
 onError: (error: any) => {
 console.error('Leaderboard subscription error', error);
 },
 };
 const { dispose } = requestSubscription(
 RelayEnvironment, // 아래 '설정 방법' 참고
 subscriptionConfig,
 );
 return () => {
 dispose();
 };
}, []); // 빈 의존성 배열을 통해 컴포넌트가 마운트되거나 언마운트될 때만 이 부분이 실행되도록 함
```

`requestSubscription`

- 메소드는 반환 값으로 `Disposable` 오브젝트를 제공한다.
- 이 `Disposable` 오브젝트에는 구독을 취소하는 dispose 메서드가 포함되어 있다.

`onNext`

- `subscription`으로 데이터가 업데이트되면, 미리 정의해두었던 state 를 업데이트하여 실시간 랭킹을 보여주도록 하였다.
- `onNext`, `onError` 외에도, subscription 이 끝날 때 호출되는 `onCompleted`, 서버 응답을 기반으로 메모리 내 릴레이 저장소를 업데이트를 위한 `updater` 등 다양한 설정들이 있다. 자세한 설명은 [이 링크](https://relay.dev/docs/v10.1.3/subscriptions/)를 참고하길 바란다.

`dispose`

- `useEffect` hook 내에서 반환하는 cleanup 함수를 통해 컴포넌트가 언마운트될 때 dispose 메소드를 호출하여 구독을 종료하게 된다.

## 설정 방법 (+Relay)

[Relay document](https://relay.dev/docs/guided-tour/updating-data/graphql-subscriptions/#configuring-the-network-layer) 에 따르면, GraphQL subscriptions 은 [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) 으로 통신하며, [graphql-ws](https://github.com/enisdenjo/graphql-ws)를 사용해서 network를 설정하는 방법은 다음과 같다. ([subscriptions-transport-ws](https://github.com/apollographql/subscriptions-transport-ws)를 사용하는 방법도 있지만 deprecated 되었으니 패스하기로 한다.)

```ts
import { ExecutionResult, Sink, createClient } from 'graphql-ws';
import {
 Environment,
 Network,
 RecordSource,
 Store,
 SubscribeFunction,
 RelayFeatureFlags,
 FetchFunction,
 Observable,
 GraphQLResponse,
} from 'relay-runtime';
import { RelayObservable } from 'relay-runtime/lib/network/RelayObservable';
import { createClient } from 'graphql-ws';

const wsClient = createClient({
 url: GRAPHQL_SUBSCRIPTION_ENDPOINT,
 connectionParams: () => {
 return {
 mode: 'cors',
 credentials: 'include',
 };
 },
});

const subscribeFn: SubscribeFunction = (operation, variables) => {
 return Observable.create((sink: Sink<ExecutionResult<GraphQLResponse>>) => {
 if (!operation.text) {
 return sink.error(new Error('Operation text cannot be empty'));
 }
 return wsClient.subscribe(
 {
 operationName: operation.name,
 query: operation.text,
 variables,
 },
 sink,
 );
 }) as RelayObservable<GraphQLResponse>;
};

// Export a singleton instance of Relay Environment
// configured with our network function:
export const createRelayEnvironment = () => {
 return new Environment({
 network: Network.create(fetchFn, subscribeFn),
 store: new Store(new RecordSource()),
 });
};

export const RelayEnvironment = createRelayEnvironment();
```

`wsClient`

- url 에는 GraphQL 서버의 웹소켓 URL 을 입력한다.
- credentials 설정은 `connectionParams`를 통해 가능하다.

`subscribeFn`

- Observable의 구독 동작을 정의한다.
- `if (!operation.text) { ... }` 에서 쿼리 문자열의 유효성을 확인하여 유효하지 않은 경우, 오류를 발생시키고 실행을 중단한다.
- 마지막으로 `return wsClient.subscribe( ... )` 코드는 웹소켓 클라이언트를 사용하여 실제로 subscription을 구독하고, GraphQL operation의 payload를 sink (즉, Observer) 에게 전달한다.
- 간단히 말해, 이 함수는 GraphQL subscription 요청을 처리하고, subscription 이벤트가 발생할 때마다 해당 결과를 Observable 스트림에 push하는 역할을 한다고 볼 수 있다.

`createRelayEnvironment`

- 새로운 Relay Environment 를 생성하고 반환한다.
- Relay의 Environment는 다른 고수준 Relay 객체들과 네트워크 계층, 캐시등을 관리하는 컨테이너이다.
- GraphQL query/mutation 요청을 처리하는 함수를 `fetchFn`, subscription 요청을 처리하는 함수를 `subscribeFn` 에 할당한 상태이다.
- 캐시 데이터를 저장하고 관리하는 Relay Store를 생성하기 위해 `RecordSource` 저장소를 사용했다.

`RelayEnvironment`

- `createRelayEnvironment` 함수를 호출함으로써 RelayEnvironment 를 초기화하고, 이를 추후 다른 곳에서 임포트해 사용할 수 있게 내보내는 역할을 한다.
- 이렇게 구성된 `RelayEnvironment`는 주로 `QueryRenderer`, `useLazyLoadQuery`, `commitMutation` 등에서 사용된다.

## CORS 에러

처음에 GraphQL 서버의 웹소켓 URL을 설정하기 위해 서버측에서 사용하는 `config.toml` 파일을 읽어와서 주소를 설정했다. 그런데 자꾸 CORS 에러가 나면서 요청 보낼 때마다 Unauthorized 가 뜨는 것이다. 그래서 이것저것 삽질을 한 결과, 동료분의 도움으로 해결할 수 있었다. (정말 감사합니다 🥹🙏)

해결 방법은 바로 `http-proxy-middleware` 를 사용해 `setupProxy` 를 설정하는 것!

[create-react-app manual](https://create-react-app.dev/docs/proxying-api-requests-in-development#configuring-the-proxy-manually)에서도 알 수 있듯이, 일반적으로 프론트엔드와 백엔드가 분리된 개발 환경에서 CORS 이슈를 방지하기 위한 설정이나, 개발 서버에서 실제 서버의 특정 경로에 대한 요청을 프록시하기 위해 `setupProxy` 를 설정할 수 있다.

코드는 다음과 같다.

```js title="/src/setupProxy.js"
const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function (app) {
 app.use(
 createProxyMiddleware('/graphql', {
 target: 'http://127.0.0.1:9220',
 changeOrigin: true,
 followRedirects: true,
 ws: true,
 }),
 );
};
```

`createProxyMiddleware('/graphql', { ... })`

- '/graphql'에서 발생하는 모든 HTTP 요청을 미들웨어가 처리하도록 설정한다.

`target: 'http://127.0.0.1:9220'`

- 프록시 된 요청이 전달될 서버의 주소를 설정한다. 여기선 9220번 포트로 설정했다.

`changeOrigin: true`

- 요청의 호스트 헤더를 target의 호스트로 변경한다. CORS 이슈를 해결하기 위해 사용한다.

`followRedirects: true`

- 이 설정은 서버가 요청에 대해 리다이렉트 응답을 보냈을 때 그 리다이렉트를 프록시가 따르도록 한다.

`ws: true`

- 이 설정은 웹소켓 프록시를 활성화한다. 클라이언트와 서버 간의 웹소켓 연결도 이 프록시를 통해 전달되며, subscribe를 위해 `true`로 설정하였다.

## 리더보드 페이지

기나긴 삽질 끝에 마침내 완성한 리더보드 페이지! 🎉 참여해 주신 모든 분들께 깊은 감사를 드립니다. 🙇🏻‍♀️

![](https://cdn.lablup.com/gtc24_leaderboard_page_a633011356.png) 

## 결론

GraphQL 의 subscription 을 사용하여 실시간 랭킹 같은 기능을 구현할 수 있었다. CORS 때문에 설정 방법에 애를 먹긴 했지만, 사용 방법은 query 를 쓸 때와 크게 다르지 않아 어렵지 않았다.

subscription 은 **실시간 업데이트**와 **효율성**이 가장 큰 장점이 아닐까 생각한다.
서버로부터 실시간으로 데이터를 수신하므로 사용자는 항상 최신 상태를 볼 수 있으며, 필요한 데이터가 변경될 때만 업데이트를 받기 때문에, 자주 변경되지 않은 데이터에 대해서는 서버 요청을 최소화할 수 있다.

하지만 웹소켓 또는 유사한 실시간 프로토콜을 구현해야 하며, 클라이언트와 서버 사이의 연결 상태를 관리하는 로직도 필요하기에 **복잡**하긴 하다. 이 글에서 다루진 않았지만, subscription 을 위해 서버측에서 추가 작업이 필요하다. 그리고 실시간 연결을 필요로 하기 때문에 그에 따른 **서버 자원과 클라이언트의 리소스 소모**가 있을 수 있다.

따라서 어떠한 방법이 비용이나 성능 면에서 더 효율적인지는 애플리케이션의 특성, 데이터의 갱신 빈도, 사용자의 동시 접속자 수 등 여러 요소에 따라 달라질 수 있으니 적절히 판단하여 사용하길 바란다.

## references

- https://relay.dev/docs/v10.1.3/subscriptions/
- https://relay.dev/docs/guided-tour/updating-data/graphql-subscriptions/#configuring-the-network-layer
- https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
- https://github.com/enisdenjo/graphql-ws
- https://github.com/apollographql/subscriptions-transport-ws
- https://graphql.org/blog/subscriptions-in-graphql-and-relay
- https://create-react-app.dev/docs/proxying-api-requests-in-development

2024 GTC 이벤트 실시간 랭킹: GraphQL Subscription 활용법

[특집] Scale entanglement

 ![](https://cdn.lablup.com/Lablup_GTC_24_a1eb755914.png) 

안녕하세요, 래블업입니다. 오는 3월 18일부터 21일까지 미국 새너제이에서 열리는 NVIDIA GTC 2024 컨퍼런스에 래블업이 참가합니다. 5년 만에 열리는 이번 대면 행사에서 래블업은 실버 스폰서로서 그 동안 개발해온 최신 AI 기술과 제품을 선보일 예정입니다.

# About GTC 2024

GTC는 NVIDIA가 주최하는 AI 분야 최대 규모의 기술 컨퍼런스입니다. 30만 명 이상이 온오프라인으로 참여할 것으로 예상되는 이번 행사에서는 NVIDIA CEO Jensen Huang의 기조연설을 비롯해 900여 개의 세션과 300여 개의 전시 부스, 20여 개의 기술 워크숍 등 다양한 프로그램이 마련되어 있습니다. 제너러티브 AI를 포함한 최신 AI 기술 트렌드를 한눈에 파악할 수 있는 최고의 기회가 될 것입니다.

# Lablup at GTC 2024
 
래블업은 GTC에서 전시 부스(#1233)를 운영하며, APAC 지역 유일의 NVIDIA DGX-Ready 소프트웨어인 Backend.AI Enterprise 플랫폼을 시연합니다. Backend.AI는 NVIDIA DGX 시스템을 비롯한 GPU 인프라의 성능을 극대화하고 사용성을 개선해주는 AI 인프라 운영 플랫폼입니다.

또한 래블업의 MLOps 솔루션인 FastTrack도 함께 선보입니다. FastTrack을 통해 생성형 AI 모델의 전체 개발 과정을 간소화하고 자동화할 수 있습니다. 특히 파운데이션 모델을 다양한 산업 분야에 맞춰 자동으로 파인튜닝하고 챗봇 등으로 활용하는 데모도 준비되어 있습니다.

# Sessions at GTC

[래블업은 두 가지 주제로 GTC 세션 발표에도 참여합니다.](https://www.nvidia.com/gtc/sponsors/?search=lablup#/exhibitor/1694022458813001tZJB)

첫 번째 세션에서는 **"Idea to Crowd: Manipulating Local LLMs at Scale"** 이라는 제목으로, 개인용 GPU부터 대규모 데이터 센터까지 다양한 규모에서 로컬 LLM을 파인튜닝하고 운영하는 기술과 사례를 소개합니다.

특히 래블업의 GPU 유동화 기술을 활용해 다양한 크기의 거대언어모델(LLM)과 이미지 생성 모델을 함께 멀티 GPU에 효율적으로 적재하는 방법에 대해 심도 있게 다룰 예정입니다. LLM 로딩 후 불가피하게 발생하는 GPU 메모리 낭비를 최소화하고, 모델별 성능 저하와 전체 성능 향상의 trade-off를 분석한 실험 결과도 공유합니다. 이를 통해 온프레미스 환경에서 AI 모델 서빙을 보다 비용 효율적으로 수행하는 방안을 제시할 것입니다.

두 번째 세션에서는 **Personalized Generative AI**라는 주제로, 개인용 GPU를 활용해 가정에서도 손쉽게 생성형 AI 모델을 구동하고 개인화하는 방법을 다룹니다. PC나 가정용 서버 등 작은 규모의 하드웨어에서 생성형 AI를 자동으로 운영하고 파인튜닝하는 기술을 소개하고, 이를 통해 개인 맞춤형 AI 비서가 우리 삶에 더욱 밀접하게 스며들 미래를 전망해볼 것입니다.

# 곧 만나요!

짧게나마 래블업이 이번 GTC에서 선보일 기술과 비전을 소개해드렸습니다. 3월 새너제이에서 열리는 GTC 2024에 참석하시는 분들께서는 **래블업 부스(#1233)** 에 꼭 들러주시기 바랍니다. 최신 AI 기술을 직접 체험하고 래블업 팀과 직접 소통하실 수 있습니다.

온라인으로 참여하시는 분들도 래블업 세션 발표를 통해 로컬 LLM과 개인화된 생성형 AI의 현재와 미래를 만나보실 수 있을 것입니다. 래블업은 앞으로도 AI 기술의 최전선에서 기업과 개인이 AI를 보다 쉽게 활용할 수 있도록 노력하겠습니다. 감사합니다!

NVIDIA GTC 2024에서 만나요! 래블업이 AI 기술의 최전선을 보여드립니다

김병조

래블업 2023 겨울 인턴 후기

Sergey Leksikov

> - [1부. LLM 와 Tool 의 협업 소개](/ko/blog/2024-01-28-tool-llms-part-1)
> - [2부. Backend.AI 로 Gorilla LLM 모델 서빙하기](/ko/blog/2024-01-29-tool-llms-part-2)
> - 3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기

# 3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기

앞서 1부에서는 도구 LLM과 그 사용법에 대해 설명했습니다. 2부에서는 Backend.AI에서 Gorilla LLM을 실행하는 방법을 설명했습니다. 3부에서는 GPU를 사용할 수 없지만 API와 관련하여 도움과 지원을 받고자 하는 경우에 대해 이야기 해 보겠습니다.

우리에게 Backend.AI가 있고, 질문과 답변 방식을 통해 보다 인터랙티브한 방식으로 Backend.AI REST API 및 Functional API에 대한 정보를 얻고 싶다고 가정해 보겠습니다. REST API의 예는 이 문서에서 설명할 수 있습니다(https://docs.backend.ai/en/latest/manager/rest-reference/index.html).
<img style="margin: auto;" src="https://cdn.lablup.com/Figure1_part3_672d0913df.png"/>

 그림 1. Backend.AI REST API 도큐먼트


추가적으로 Backend.AI REST API 설명서를 **openapi.json** 형식으로 내보낼 수 있습니다:
<img style="margin: auto;" src="https://cdn.lablup.com/Figure2_part3_4301cfdc46.png"/>

 그림 2. Backend.AI openai.json


Another source of BackendAI API is functional API defined in Backend.AI Client. We want to know how to interact with Backend.AI and which parts of code are responsible. The client code repository is responsible with managing and interacting with cloud and computing environment: 

Steps to make a Question Answering API system

1. 로컬 PC 환경에서 https://github.com/lablup/backend.ai/tree/main/src/ai/backend/client 의 Backend.AI 클라이언트를 로컬로 설정하고 새 디렉토리 `bai-dev/src/ai/backend/client/gpt_api_client` 를 생성해 보겠습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure3_part3_786b65a096.png"/>

 그림 3. gpt_api_client 디렉토리 위치


2. vector_data 아래에 REST API 문서: **openapi.json** 을 저장할 `data1/` 그리고 API 질의응답 수행을 위해 선택된 B.AI 클라이언트 파일을 저장할 `data2/` 두 개의 하위 디렉토리를 생성하겠습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure4_part3_a112e9b5f9.png"/>

 그림 4. openapi.json 및 클라이언트 함수 코드 파일이 포함된 데이터 디렉터리 개요


3. 파이썬 라이브러리인 LlamaIndex 를 설치합니다. `Pip install llama-index`
참고로 LlamaIndex 는 Meta 의 LLaMA 언어 모델과는 관련이 없습니다. LlamaIndex 는 검색을 위해 문서를 효율적으로 처리하고 저장하기 위한 데이터 구조 및 메서드와 관련이 있습니다.

4. API와 코드 파일을 임베디드 벡터로 변환하고 LLamaIndex를 사용하여 벡터 데이터베이스에 저장해 보겠습니다. 로컬 PC에서 VSCode에 통합된 Jupyter Notebook 대화형 환경을 사용해 보겠습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure5_part3_b2e80a9191.png"/>

 그림 5. 주피터 노트북 대화형 환경. data/ 디렉터리에서 openapi.json을 로드. 이후 쿼리 엔진에서 벡터 인덱스를 통해 질문.


5. 코드 함수를 사용하여 `data2/` 디렉토리를 벡터화 합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure6_part3_988ad5b585.png"/>

 그림 6. B.AI 클라이언트의 코드 파일을 이용하여 data2/ 디렉토리 로딩. 인덱스로 벡터화 후 질답 엔진 생성.


객체를 저장하고 직렬화 하는데 일반적으로 사용되는 파이썬 Pickle 또는 Joblib 라이브러리를 사용하여 **joblib.dump(index, "rest_api_index.joblib")** 그리고 **joblib.dump(index, "functional_index.joblib")** 인덱스를 모두 저장하고 시스템에 로드가 가능합니다.

6. 주피터 노트북 환경은 이미 대화형 방식으로 질문하고 답변을 받을 수 있는 기능을 제공하고 있습니다. 또한 저장된 벡터 인덱스를 FastAPI 서버에 불러와서 웹을 통해 질문에 답할 수 있습니다. 이전 2부에서는 Gorilla LLM으로 계산 세션을 설정했습니다. 이전 데모에서도 여전히 FastAPI 서버를 사용한 계산 세션이 있습니다.

7. Backend.AI 클라우드 세션에서 **rest_api_index.joblib** 및 **functional_index.joblib** 파일을 api_helper/ vFolder 로 전송 해 보겠습니다.

8. **server.py** 파일에서 벡터 인덱스를 로딩하고 쿼리 엔진을 정의합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure7_part3_cb02dc1748.png"/>

 Figure 7. server.py 에서 인덱스 및 쿼리 엔진 파일 정의


9. 각 쿼리 엔진에 대해 FastAPI 엔드포인트를 지정합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure8_part3_dad39fb820.png"/>

 그림 8. REST 및 함수형 API 검색을 위한 코드 스니펫


10. curl 명령을 사용하여 로컬 PC에서 서버 응답을 테스트합니다. 특정 엔드포인트에서 서버가 쿼리를 받으면 사용자로부터 응답을 받습니다.
```sh
curl -X POST -H "Content-Type: application/json" -d '{"instruction":"Create a new session"}' http://127.0.0.1:8000/rest_api
```
<img style="margin: auto;" src="https://cdn.lablup.com/Figure9_part3_a0a03c3a13.png"/>

 그림 9. curl 명령의 응답. 예제 1


```sh
curl -X POST -H "Content-Type: application/json" -d '{"instruction":"Create a new session"}' http://127.0.0.1:8000/functional
```
<img style="margin: auto;" src="https://cdn.lablup.com/Figure10_part3_6a35792213.png"/>

 그림 10. curl 명령의 응답. 예제 2


또한 사용자 입력을 받아 해당 엔드포인트로 전송하고 응답을 받는 웹 앱을 만들 수도 있습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure11_part3_0b36446b3d.png"/>

 그림 11. Backend.AI REST 및 함수형 API를 통한 질문 답변을 위한 웹 앱 프로토타입. 예제 1


<img style="margin: auto;" src="https://cdn.lablup.com/Figure12_part3_48aef2d6ec.png"/>

 그림 12. Backend.AI REST 및 함수형 API를 통한 질문 답변을 위한 웹 앱 프로토타입. 예제 2


## 맺음말
3부에서는 오픈 소스 파이썬 라이브러리 LLamaIndex를 사용하여 로컬에서 질문-응답 시스템을 만드는 방법을 보여드리면서 문서와 Backend.AI 코드를 벡터 형식으로 변환하는 방법을 알아보았습니다. 질문과 답변은 Visual Studio Code 에서 플러그인을 통해 지원하는 주피터 노트북 환경에서 대화형 방식으로 수행할 수 있습니다. 또한 이러한 벡터 인덱스를 Gorilla LLM API 튜닝 모델이 서버로 있는 Backend.AI 클라우드 환경으로 옮기기로 결정했습니다. 그런 다음 네트워크를 통해 사용자를 지원하기 위해 API 질의응답 웹 앱을 구현했습니다.

## 참고 자료:
- LLama Index. https://docs.llamaindex.ai/en/stable/

Backend.AI API 도우미 및 Gorilla LLM 데모 동영상입니다:
<iframe width="640" height="360" src="https://www.youtube.com/embed/ggaw6ijxGL0?si=ZgRFGtyGg1oLh8Au" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

> - [1부. LLM 와 Tool 의 협업 소개](/ko/blog/2024-01-28-tool-llms-part-1)
> - [2부. Backend.AI 로 Gorilla LLM 모델 서빙하기](/ko/blog/2024-01-29-tool-llms-part-2)
> - 3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기

Backend.AI 와 Tool LLM 의 만남 : Tool 과 AI 의 협업 혁명 - 3부

> - [1부. LLM 와 Tool 의 협업 소개](/ko/blog/2024-01-28-tool-llms-part-1)
> - 2부. Backend.AI 로 Gorilla LLM 모델 서빙하기
> - [3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기](/ko/blog/2024-01-30-tool-llms-part-3)

# 2부. Backend.AI 로 Gorilla LLM 모델 서빙하기

이전 글에서는 Tool LLM의 기능과 사용법에 대해 설명했습니다. 이번 글에서는 Backend.AI 데스크탑 앱을 사용하면서 Backend.AI 클라우드에서 Gorilla LLM 모델을 실행하는 방법을 단계별로 데모 해 보겠습니다.

<img style="margin: auto;" src="https://cdn.lablup.com/Figure1_part2_dabfc01542.png"/>

 그림 1. MacO에 설치된 Backend.AI 데스크탑 앱


1. 시작 버튼을 누르면 세션 생성 메뉴가 나타납니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure2_part2_96d42c949d.png"/>

 그림 2. 새 세션 시작 화면


2. *NGC-Pytorch 23.07* 이미지를 선택합니다.

3. 모델 파일이 포함된 작업 디렉토리 vFolder를 첨부합니다. 디렉토리명 예 *api_helper/*
<img style="margin: auto;" src="https://cdn.lablup.com/Figure3_part2_0b854d81e9.png"/>

 그림 3. vFolder 첨부 화면


4. 128 GB RAM 및 5 fGPU 크기의 리소스를 선택합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure4_part2_fe7aa72175.png"/>

 그림 4. 리소스 선택 화면


5. Visual Studio Code 데스크탑 환경을 선택합니다.

<img style="margin: auto;" src="https://cdn.lablup.com/Figure5_part2_ad4ca84601.png"/>
 그림 5. IDE 환경 선택 화면


6. `/home/work/api_helper/` 디렉토리에 **server.py** 파일을 생성합니다.

7. **requirements.txt** 파일을 생성합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure6_part2_0ba3c54ee6.png"/>

 그림 6. requirements.txt 파일 내용


설치를 위해 다음 명령을 실행하세요: `pip install -r requirements.txt`
<img style="margin: auto;" src="https://cdn.lablup.com/Figure7_part2_024d2ce91a.png"/>

 그림 7. 설치 명령 실행


8. **server.py** 파일을 추가하고 트랜스포머 라이브러리를 사용하여 토큰화 및 모델 로더를 정의합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure8_part2_00ebe46cd8.png"/>

 그림 8. server.py 코드 스니펫


9. 서버 IP 주소와 포트 번호를 명시합니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure9_part2_c15140debf.png"/>

 그림 9. 서버 IP 주소 및 포트 번호 명시


10. 다음 명령으로 모델을 실행합니다: **python server.py**
<img style="margin: auto;" src="https://cdn.lablup.com/Figure10_part2_4651d19db6.png"/>

 그림 10. server.py 시작


11. 생성된 서버에 접속합니다.

 VSCode는 기기에서 Backend.AI 클라우드 서버로 포트 터널링 세션을 자동으로 생성합니다. 로컬 호스트 주소에 액세스하여 서버 상태를 확인할 수 있으며, 요청은 Backend.AI 클라우드로 터널링됩니다. 또한 필요에 따라 다른 사용자 지정 엔드포인트를 정의할 수 있습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure11_part2_2c34fa72a1.png"/>

 그림 11. 서버 실행 로그

<img style="margin: auto;" src="https://cdn.lablup.com/Figure12_part2_fa41d8cd06.png"/>

 그림 12. VSCode 포트 포워딩 구성

<img style="margin: auto;" src="https://cdn.lablup.com/Figure13_part2_109ff20416.png"/>

 그림 13. 서버의 루트에 액세스하기


 여기까지는 Backend.AI Cloud에 계산 세션을 생성하고, api_helper/ vFolder 디렉터리에 요구사항.txt 파일과 server.py를 첨부했습니다. 그런 다음 HuggingFace 리포지토리에서 Gorilla LLM을 다운로드하고 추론/api .endpoint를 사용하여 계산 세션 메모리로 로드하는 FastAPI 서버를 시작합니다.

12. API 추론 테스트
 로컬 컴퓨터 명령줄에서 curl 요청을 생성하여 Gorilla LLM의 API 추론을 테스트할 수 있습니다:
```sh
curl -X POST -H "Content-Type: application/json" -d '{"text":"Object detection on a photo. <<<api_domain>>>:"}' http://127.0.0.1:8000/inference
```
<img style="margin: auto;" src="https://cdn.lablup.com/Figrue14_part2_9f02402b1c.png"/>

 그림 14. curl 명령 예제

<img style="margin: auto;" src="https://cdn.lablup.com/Figure15_part2_a2d8e4f2d7.png"/>

 그림 15. 요청 수신 후 서버의 GPU 워크로드

<img style="margin: auto;" src="https://cdn.lablup.com/Figrue16_part2_2c99f02e17.png"/>

 그림 16. 요청 수신 및 결과 인쇄에 대한 서버 로그


13. UI 웹 앱을 정의합니다. 어떤 웹 기술이라도 사용하여 더 나은 방식으로 결과를 표시할 수 있는 UI 앱을 만들 수 있습니다. 예를 들어 html 및 JavaScript 파일을 사용하여 server.py의 루트 아래에 있는 정적 디렉터리에 배치한 다음 웹 앱의 엔드포인트를 정의할 수 있습니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure17_part2_fa32fd5cc4.png"/>

 그림 17. FastAPI 서버에 html 웹 앱 추가 예시


14. Gorilla LLM 웹 앱 프로토타입 - API 질문 답변 및 코드 생성을 위해 API가 튜닝된 대규모 언어 모델입니다.
<img style="margin: auto;" src="https://cdn.lablup.com/Figure18_part2_b4733d5db5.png"/>

 그림 18. Gorilla LLM 웹 앱 프로토타입. 예제 1

<img style="margin: auto;" src="https://cdn.lablup.com/Figure19_part2_a726a83d94.png"/>

 그림 19. Gorilla LLM 웹 앱 프로토타입. 예제 2


## 맺음말
고릴라 LLM이 제공하는 몇 가지 어려움에도 불구하고, 자체 API로 튜닝된 LLM은 큰 잠재력과 가능성을 가지고 있습니다. 상용 대형 모델보다 더 정확한 파라미터와 함수 호출로 가장 최신의 결과를 제공할 수 있으며, API를 통한 질문 답변, 코드 자동 완성, API 코드 실행과 같은 작업에 유용하게 사용할 수 있기 때문입니다.

## 한계점 및 어려움:
Gorilla LLM 모델을 서버로 전송하는 동안 다음과 같은 문제를 고려해야 했습니다:
- 모델이 예상과 다른 형식의 응답을 생성할 수 있음
- 동일한 질문에 대해 모델이 다른 결과를 생성할 수 있음
- LLM 응답 파싱 및 렌더링
- 중복된 문장과 줄 제거하기

> - [1부. LLM 와 Tool 의 협업 소개](/ko/blog/2024-01-28-tool-llms-part-1)
> - 2부. Backend.AI 로 Gorilla LLM 모델 서빙하기
> - [3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기](/ko/blog/2024-01-30-tool-llms-part-3)

Backend.AI 와 Tool LLM 의 만남 : Tool 과 AI 의 협업 혁명 - 2부

> - 1부. LLM 와 Tool 의 협업 소개
> - [2부. Backend.AI 로 Gorilla LLM 모델 서빙하기](/ko/blog/2024-01-29-tool-llms-part-2)
> - [3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기](/ko/blog/2024-01-30-tool-llms-part-3)

# 1부. LLM 와 Tool 의 협업 소개
 미래의 AI 기술 기능을 지금 바로 사용할 수 있다면 어떨까요? 아마도 직장에서 퇴근하는 길에 AI 어시스턴트에게 집에 도착하기 전에 집안의 에어컨을 켜달라고 요청할 수 있을 것입니다. 동시에 휴가를 계획하고 있는데 선택의 여지가 거의 없는 상황에서 AI 모델에게 호텔 예약을 대신 해달라고 요청할 수도 있습니다. 모델이 여행을 예약하면 클라우드 제공업체로부터 딥러닝 모델의 학습 진행 상황에 대한 알림을 받게 됩니다. AI 어시스턴트에게 성능 정확도를 위해 특정 값을 목표로 삼고 다른 매개변수 세트를 사용하여 다른 세션을 실행하도록 요청합니다. 이러한 미래적인 시나리오가 현재에 어떻게 실현될 수 있을까요?

 이러한 종류의 LLM과 실제 세계의 상호작용은 애플리케이션 프로그래밍 인터페이스(API)를 통해 가능합니다. API 데이터 세트에서 미세 조정된 특정 도구의 거대 언어 모델(LLM)은 특정 API로 사용자의 쿼리에 응답할 수 있으며, 해당 API는 프로그램이나 함수를 호출하여 실제 세계에 영향을 미칠 수 있습니다. 거대 언어 모델(LLM)은 문맥에 맞는 텍스트를 생성하는 뛰어난 기능과 문제 해결을 위한 추론 기능으로 인해 그 인기가 높아지고 있습니다. 텍스트 모델 활용 범위는 텍스트 생성, 편집뿐만 아니라 프로그래머의 코파일럿 역할까지 다양합니다. 텍스트 생성 기능 외에 LLM의 활용 범위를 확장할 수 있는 방법은 무엇일까요?


 Tool LLM을 통해 우리는 AI가 우리의 요청을 이해하는 것뿐만 아니라 다양한 온라인 도구를 사용하여 요청에 따라 행동할 수 있는 시대로 나아가고 있습니다. Tool LLM은 기능 및 REST API를 통해 도구를 통한 AI가 할 수 있는 일의 한계를 확장하고 있습니다.

 GPT-4는 현재 대부분의 AI 벤치마크에서 1위를 차지하고 있는 최신 LLM입니다. 이 시나리오에서 GPT-4 모델에 오디오 파일을 다른 언어의 텍스트로 변환하라는 요청을 받는 경우를 생각해 보겠습니다. 그러나 특정 API를 사용하라고 프롬프팅을 하게 되면 GPT-4는 존재하지 않는 API를 착각(hallucinate)하여 제안하거나 잘못된 인수를 제공할 수 있습니다. 결과적으로 기능 실행에 실패하여 사용자가 지정한 작업의 목표를 달성하지 못할 수 있습니다.

 환각(hallucinations)과 부정확성(inaccuracies) 문제 외에도 API 문서와 버전은 끊임없이 변화하고 있습니다. 범용 LLM을 재학습 하는 것은 비용이 많이 들고 지속적으로 변경되는 문서로 LLM 모델을 업데이트하는 것은 실용적이지 않습니다. Tool LLM은 프로그래밍 인터페이스를 통해 물리적 세계와 상호작용할 수 있도록 함으로써 일반적인 대형 모델의 환각 문제에 대한 해결책을 제시합니다. Tool LLM은 크기가 훨씬 작기 때문에 주기적으로 최신 데이터로 재학습할 수 있습니다. 또한 API 문서 검색 모듈을 모델 서빙 파이프라인에 추가하여 사용자의 입력 쿼리와 관련된 최신 API 문서로 모델을 보완할 수 있습니다.

 이러한 과제 극복을 위해 최근 연구자들은 각각 고유한 장점과 구체적인 사용 사례를 갖춘 Gorilla LLM, ToolLLaMA 와 같은 LLM 도구 사용 능력을 향상시키는 두 가지 주목할 만한 오픈 소스 방법을 제안했습니다. 또한 이러한 모델은 Backend.AI 클라우드에서 추론 서비스를 제공하기 위해 준비될 수 있습니다.

## Tool LLM이란 무엇인가요?
 Tool LLM은 사용자 쿼리가 포함된 데이터 세트와 API 코드 사용 및 API 설명 문서와 같은 관련 컨텍스트 정보가 포함된 API 요청에 대해 학습된 LLM입니다. 이러한 LLM의 응답은 코드로 실행될 수 있습니다. 코드 실행은 LLM이 다양한 온라인 서비스 및 도구와 상호 작용할 수 있음을 의미합니다. 클라우드 컴퓨팅 제공업체, Kubernetes 머신 러닝 및 딥 러닝 라이브러리, HuggingFace, TorchHub, TensorFlowHub 와 같은 리포지토리 등이 이에 해당합니다.

 이러한 도구 LLM의 가장 큰 장점은 사용자 쿼리에 대한 API 응답을 정확하게 생성하고 이를 실행하여 결과를 얻을 수 있다는 점입니다.

## API 유형 이해하기
 API(Application Programming Interface)는 현대 컴퓨팅 환경의 중요한 요소로, 서로 다른 소프트웨어 애플리케이션이나 하드웨어 시스템이 통신하고 상호 작용하는 방법에 대한 일련의 규칙과 프로토콜 역할을 합니다. 

 함수형 API는 프로그래밍 환경 내에서 함수 콜을 통해 호출되도록 설계되었습니다. 예를 들어, HuggingFace 및 TensorFlow와 같은 머신 러닝 및 딥 러닝 라이브러리는 Functional API call을 통해 메모리에 로드하고 활용할 수 있는 다양한 모델을 제공합니다. 이러한 API는 소프트웨어 내에서 특정 기능과 연산을 실행하는 데 필수적입니다.

 API와 관련된 코드를 생성하는 LLM의 이러한 기능은 기본적인 텍스트 생성 및 처리 기능을 훨씬 뛰어넘어 그 활용도를 확장합니다. 도구 LLM은 클라우드 컴퓨팅 플랫폼에서 고급 머신 러닝 라이브러리에 이르기까지 다양한 온라인 서비스 및 도구와 원활하게 통합할 수 있습니다. 또한 사람의 쿼리에만 국한되지 않고 다른 프로그램이나 AI 에이전트와 상호 작용하는 시스템에도 통합할 수 있습니다. 이러한 다재다능함 덕분에 Tool LLM은 복잡한 시스템과 인프라에서 중요한 구성 요소로 자리매김하여 실제 애플리케이션에 대한 잠재력을 향상시킵니다.

 다음 섹션에서는 Tool LLM이 어떻게 학습되었고 어떻게 운영되는지 자세히 살펴보겠습니다. 그 다음은 Gorilla LLM과 ToolLLaMA라는 두 가지 구체적인 연구 사례를 다룰 것입니다.

## Tool LLM 학습 및 추론 워크플로

 Tool LLM 학습에는 API 데이터베이스 설정, 학습 데이터 세트 생성, 모델 학습 및 추론 등 여러 단계가 포함됩니다.

 API 데이터베이스에는 설명과 관련 코드 샘플이 포함되어 있습니다. Self-instruct 학습 데이터 세트를 생성하려면 API 데이터베이스 샘플을 {입력: 사용자 쿼리 - 출력: API} 쌍으로 사전 처리해야 합니다. ChatGPT는 사람이 물어볼 수 있는 다양한 시나리오와 복잡한 쿼리를 처리하여 이러한 데이터 세트를 자동으로 생성하는 데 도움을 줄 수 있습니다. 구체적인 사례부터 일반적이고 추상적인 사례까지. Self-instruct 데이터 세트가 생성된 후 모델은 사용자 입력 쿼리가 주어지면 API 측면에서 정확한 예측을 할 수 있도록 학습됩니다.

 Tool LLM 추론의 경우, LLM이 정확한 인수 매개변수로 응답할 뿐만 아니라 최신 API 설명서를 사용하는 것이 중요합니다. 따라서 최신 API 변경 사항으로 모델을 유지하는 데 도움이 되는 API 문서 검색기가 사용됩니다.
<img style="margin: auto;" src="https://cdn.lablup.com/overview_workflow_of_Tool_LLM_806e1506f1.png"/>

 그림 1. API Instruction 데이터 세트를 통한 Tool LLM 학습 및 추론 워크플로우 개요


## 사례 연구: Gorilla LLM 및 ToolLLaMA
### Gorilla LLM
 Gorilla 는 API 호출 작성에서 GPT-4를 능가하는 미세 조정된 LLaMA 7B 기반 모델입니다. Gorilla의 주목할 만한 점은 다음과 같습니다:
- API에 대한 정확한 입력 인수를 생성하는 데 있어 현재 LLM의 한계와 잘못된 API 사용에 대한 환각 경향을 해결합니다.
- Gorilla 는 문서 API 검색기와 통합되어 문서의 실시간 변경 사항에 적응할 수 있으며, 이는 API가 얼마나 자주 업데이트 되는지를 고려할 때 상당한 이점입니다.
- 개발자들은 이 모델의 능력을 평가하기 위해 APIBench라는 데이터 세트를 개발했으며, 여기에는 총 1,600개 이상의 API가 포함된 HuggingFace, TorchHub, TensorHub의 API가 포함되어 있습니다.
- Gorilla는 환각 문제를 완화하고 LLM 출력의 신뢰성을 개선하는 것으로 추정됩니다. 또한, Gorilla는 AWS, GCP와 같은 클라우드 제공업체와 함께 작동하고 Kubernetes 클러스터를 관리할 수 있도록 업데이트 및 확장되었습니다.

### ToolLLaMA
 ToolLLaMA는 RapidAPI 리포지토리에 기반한 도구의 명령어 튜닝 데이터 세트인 ToolBench에서 미세 조정된 모델입니다. ToolLLaMA의 주요 키포인트는 다음과 같습니다:
- ToolBench는 16,000개 이상의 실제 API를 다루며 다양한 명령어 세트와 솔루션 경로를 제공합니다.
- 이 논문에서는 여러 도구 사용 및 다단계 추론과 같은 LLM의 추론 기능을 향상시키기 위해 새로운 심층 검색 기반 의사 결정 트리 알고리즘(Depth-First Search-Based Decision Tree : DFSDT)을 제안합니다.
- ToolBench에서 미세 조정된 ToolLLAMA는 ChatGPT의 성능과 흡사하며 APIBench와 같이 배포되지 않은 데이터 세트에서 일반화 능력을 보여줍니다.

 두 논문 모두 방대한 API를 탐색하고 활용함으로써 실제 도구 사용에서 LLM의 기능의 한계를 뛰어넘었다는 데 의의가 있습니다. 이러한 발전은 실제 애플리케이션에 매우 중요합니다. 아래는 비교 요약 표입니다.
<img style="margin: auto;" src="https://cdn.lablup.com/comparative_API_tuned_LLM_36a8cc1125.png"/>

 그림 2. 두 API 튜닝 LLM 간의 비교 표


## Backend.AI와 ToolLLM 의 시너지 효과
 LLM의 학습 또는 모델 서비스에는 상당한 컴퓨터 리소스를 필요로 하는데, 특히 RAM 용량과 계산 속도가 높은 그래픽 처리 장치(GPU)에 대한 수요가 많기 때문입니다.

 Backend.AI는 다양한 모델을 구축, 학습 및 제공하기 위한 확장 가능한 기반을 제공합니다. Backend.AI에는 모델 추론을 위한 온디맨드 확장 기능과 외부 노드 추가를 통한 서비스 제공, 워크로드 최적화를 위한 부하 분산 기능이 포함되어 있습니다. Backend.AI 에는 고성능 LLM 추론에 사용할 수 있는 vLLM과 TensorRT 서버가 있습니다. 또한 사용자 친화적으로 잘 설계된 인터페이스와 파이프라인 메이커인 FastTrack 툴을 통해 다양한 복잡도의 컴퓨팅 환경 세션을 생성할 수 있습니다.

## 맺음말

 다양한 인공지능 어시스턴트와 에이전트가 다양한 기기 및 서비스와 상호작용하는 미래 시나리오는 이러한 상호작용에 특화된 API와 Tool LLM 을 통해 실현될 수 있습니다. Gorilla LLM 과 ToolLLaMA 는 복잡한 업무에 활용할 수 있는 좋은 기회를 제공합니다. 이들이 어떻게 학습하고 서비스를 제공하는지에 대한 워크플로도 이해하기 쉽습니다. 머신 러닝 및 클라우드 관리 작업에는 Gorilla LLM을 사용하는 것을 추천할 수 있습니다. 보다 일반적인 API 사용, 다중 도구 및 다단계 사례에는 ToolLLaMA를 사용하는 것이 좋습니다.

 자체 API 문서나 코드에 대한 자체 모델을 학습시켜 코드를 이해하는 LLM 모델을 보유할 수 있다는 장점도 있습니다. 이러한 LLM은 관련 정보를 얻고자 하는 사용자를 지원하거나 상호 작용할 때 유용할 수 있습니다.

## 자주 묻는 질문:
> - **Q:** 환각의 원인과 LLM의 한계는 무엇이며 Tool LLM에서 이를 어떻게 해결했나요?
> - **A:** 다른 대규모 언어 모델과 마찬가지로 GPT-4는 인터넷의 광범위하지만 오래되었거나 부정확할 가능성이 있는 데이터 세트를 학습하기 때문에 주로 환각과 부정확성과 같은 한계에 직면해 있습니다. 이러한 '환각'은 모델이 사실과 다르거나 현실에 근거하지 않은 정보를 자신 있게 생성하는 경우를 말하며, 이는 데이터의 크기나 물리적 세계와의 상호작용 부족이 아닌 순수 텍스트 기반 학습 데이터의 특성에서 비롯된 문제입니다. 이러한 문제를 해결하기 위해 전문화와 빈번한 업데이트에 중점을 두고 Tool LLM이 개발되고 있습니다. API 문서와 같은 특정 데이터 세트에 대한 미세조정을 거쳐 프로그래밍 인터페이스를 통해 실제 시스템과 직접 상호 작용하여 보다 정확하고 최신 정보를 얻을 수 있습니다. Tool LLM의 재학습 빈도는 애플리케이션과 관련 분야의 변화 속도에 따라 달라지며, 모델을 최신 트렌드와 정보로 최신 상태로 유지하기 위해 월별, 분기별 또는 연 2회 업데이트가 필요할 수 있습니다.

> - **Q:** 사용자 쿼리와 API 쌍 예시는 어떤 것들이 있을까요?
> - **A:** 다음 예제입니다.
> > - **User Query:** "우주 탐사에 관한 이 기사를 요약하세요."
> > - **API Output:** HuggingFace.summarize(text="기사 본문", model="facebook/bart-large-cnn")
>
> > - **User Query:** "이 고객 리뷰의 감정은 어떤가요?"
> > - **API Output:** HuggingFace.analyze_sentiment(text="고객 리뷰 본문", model="distilbert-base-uncased-finetuned-sst-2-english")
>
> > - **User Query:** "이 사진에 있는 물체를 식별하세요."
> > - **API Output:** HuggingFace.image_recognition(image_file="path/to/photo.jpg", model="google/vit-base-patch16-224")
>
> > - **User Query:** "이 음성 녹음을 텍스트로 변환하세요."
> > - **API Output:** HuggingFace.speech_to_text(audio_file="path/to/recording.wav", model="facebook/wav2vec2-base-960h")

> - **Q:** 모델을 훈련하고 추론하는 과정에서 API 문서를 활용하는 방식에 있어 GorillaLLM과 ToolLLaMA 논문은 어떻게 다른가요?
> - **A:** GorillaLLM은 학습 중에 관련 API 문서를 추가하고 두 가지 추론 모드를 제공하는 반면, ToolLLaMA는 API 도메인에서 임베딩을 미세 조정하기 위해 Sentence-BERT를 사용합니다. 문서 검색을 위해 GorillaLLM은 LLamaIndex의 BM25와 GPT-Retriever를 사용하는 반면, ToolLLaMA는 비슷한 목적으로 Sentence-BERT를 사용합니다.

> - **Q:** 소규모 API 모델은 얼마나 자주 재교육해야 하며, API 리트리버는 API 문서 변경 사항을 처리하는 데 어떤 역할을 하나요?
> - **A:** 소규모 API 모델을 매년 교육하는 것은 합리적이지만, API 변경 사항에 대해 매달 재교육하는 것은 현실적이지 않습니다. API 리트리버는 최신 문서를 사용하여 잦은 재교육의 필요성을 줄일 수 있습니다. 미세 조정된 API 모델과 RAG 방법을 평가하고 벤치마킹하는 것은 효율성을 위해 필수적입니다.

> - **Q:** ToolLLM과 RAG 시스템의 차이점은 무엇이며, LLM의 맥락에서 어떻게 작동하나요?
> - **A:** ToolLLM은 지식을 통합하는 데 중점을 두고 API 문서에 따라 미세 조정된 모델입니다. 반면에 RAG 시스템은 데이터 청킹, 저장, 검색, 재순위 지정 및 합성을 위한 알고리즘입니다. 이들은 독립적으로 또는 함께 작동하여 특히 컨텍스트 제한 및 지식 업데이트를 처리할 때 LLM 효율성을 향상시킬 수 있습니다.

## 참고 자료:
- Gorilla: Large Language Model Connected with Massive APIs. https://gorilla.cs.berkeley.edu/
- ToolLLM: Facilitating Large Language Models To Master 16000+ Real-World APIs. https://github.com/OpenBMB/ToolBench

> - 1부. LLM 와 Tool 의 협업 소개
> - [2부. Backend.AI 로 Gorilla LLM 모델 서빙하기](/ko/blog/2024-01-29-tool-llms-part-2)
> - [3부. 학습 및 서버 LLLM 없이 로컬에서 몇 줄의 코드만으로 자체 API 검색기 및 질문 답변 시스템을 만들기](/ko/blog/2024-01-30-tool-llms-part-3)

Backend.AI 와 Tool LLM 의 만남 : Tool 과 AI 의 협업 혁명 - 1부

> * [실제로 동작하는 Raft 구현체 뜯어 보기 - 2](/blog/2024-05-29-deepdive-raft-2)
> * [실제로 동작하는 Raft 구현체 뜯어 보기 - 1](/blog/2024-03-29-deepdive-raft)
> * Introduce raftify: 확장성에 초점을 맞추어 개발된 하이 레벨의 Raft 프레임워크

안녕하세요, 저는 작년부터 Lablup에서 Backend.AI 매니저 프로세스에 Raft를 도입하는 작업을 맡아 수행하고 있습니다.

제가 수행 중인 관련 작업을 대략적으로 나타내어 보면 아래와 같습니다.

> 1. Backend.AI 매니저 프로세스에 Raft를 도입해 리더-팔로워 구조로 만드는 것.
> 2. 기존 분산 락 기반의 GlobalTimer를 Raft 기반의 글로벌 타이머로 변경하고, 클러스터에서 특정 작업이 정확히 한 번만 수행되도록 보장하는 것.
> 3. 매니저 프로세스 간 공유 가능한 전역적인 상태 저장소를 매니저 프로세스에 내장시키고 적절하게 동기화하는 것.

이 글에선 이러한 작업을 수행하기 위해 제가 지난 1년간 삽질하며 개발하게 된 Raft 프레임워크와 이를 개발하며 마주친 여러 이슈들에 대해 소개드리고 총 300줄이 되지 않는 간략한 코드를 통해 분산 키값 저장소를 구현하는 raftify 예제 코드에 대해 설명드려 보도록 하겠습니다.

# raftify 소개

[raftify](https://github.com/lablup/raftify)는 어떤 서버 애플리케이션과도 쉽게 통합될 수 있도록 확장성에 초점을 맞추어 개발된 Raft 프레임워크입니다.

raftify는 프로덕션에서 활용되고 있는 Raft 구현체들 중 [tikv의 raft-rs 구현체](https://github.com/tikv/raft-rs) 위에 LMDB를 stable storage로, gRPC를 네트워크 계층으로 사용해 개발되었습니다.

# raft 모듈 바인딩

저는 신뢰할 수 있는 Raft 구현체를 밑바닥부터 모두 쌓아올려 유지 보수하는 것은 현실적으로 큰 짐이 될 수 있다고 판단해 우선 Raft 모듈의 파이썬 바인딩을 작성해보기로 결정했습니다.

그래서 처음에는 GitHub에서 가장 스타를 많이 받은 Raft 구현체인 [hashicorp/raft](https://github.com/hashicorp/raft) 구현체를 [gopy](https://github.com/go-python/gopy)를 사용해 파이썬 바인딩을 작성해보면 어떨까 생각했습니다.

하지만 gopy는 고루틴에 대한 바인딩을 지원해주지 못했고 최신 파이썬 버전도 지원해 주지 않고 있었습니다.

그러던 참에 사내 시니어 개발자님의 조언을 통해 [tikv/raft-rs](https://github.com/tikv/raft-rs)란 Rust 구현체와 [PyO3](https://github.com/PyO3/pyo3)에 대해 알게 되며 PyO3를 통해 tikv/raft-rs의 파이썬 바인딩을 작성해 보아야겠다고 생각하게 되었습니다.

# rraft-py

그렇게 rust, raft, py를 합쳐 [rraft-py](https://github.com/lablup/rraft-py)란 이름으로 Raft 모듈의 파이썬 바인딩 개발에 도전해보게 되었습니다.

rraft-py를 개발하면서 가장 먼저 신경 쓴 것은 rust 코드와 파이썬 코드의 의미가 가능한 1:1 매칭이 되도록 만들어야겠다는 것이었습니다.

1:1 매칭이 가능하려면 러스트의 문법에 관련된 세부 사항들을 잘 우회할 필요가 있었습니다.

제가 당시에 제일 고민했던 것은 러스트의 참조를 파이썬 측으로 어떻게 노출해주어야 좋을지에 관련된 것이었으며, 관심이 있으시다면 해당 [파이콘 발표 영상](https://www.backend.ai/video/pycon-kr-23-pyO3-distributed-binding)을 참고하실 수 있습니다.

이렇게 개발된 rraft-py는 1만 줄 이상의 raft-rs의 통합 테스트 코드를 그대로 포팅해 파이썬에서 바로 사용할 수 있는 나름 신뢰할 수 있는 Raft 바인딩 구현체가 되었습니다.

현재 raftify는 Rust로 완전히 재작성하는 과정을 거친 후 rraft-py를 사용하지 않게 되었지만 처음으로 PyO3 바인딩을 작성해보고 Raft 구현체의 API들을 사용해보는 좋은 경험이 되었습니다.

# riteraft-py

rraft-py를 개발하고 raft-rs의 1만 줄 가량의 통합 테스트들과 [multiple-mem-node example](https://github.com/lablup/rraft-py/blob/main/example/multi_mem_node/main.py)까지 파이썬 코드로 포팅해 정상적으로 동작하도록 개발한 후 든 생각은 여전히 어디에서부터 시작해야 할지 모르겠다는 것이었습니다.

raft-rs는 정말 Raft 구현체 자체만을 제공했고 이것을 어떻게 애플리케이션에 통합할 수 있을지 전혀 감이 잡히지 않았습니다.

Github을 찾아보던 중 [How to use this lib?](https://github.com/tikv/raft-rs/issues/402)란 이슈에서 [riteraft](https://github.com/ritelabs/riteraft)란 이름으로 tikv/raft-rs를 기반으로 하는 하이 레벨의 Rust 구현체를 발견하게 되었고, 해당 라이브러리는 훨씬 직관적으로 사용 방법을 파악할 수 있었습니다. 그래서 저는 파이썬에서 이것의 동작을 그대로 모방해 애플리케이션 레벨에 통합하는 것을 목표로 [riteraft-py](https://github.com/lablup/riteraft-py)를 개발하기로 결심했습니다.

riteraft는 Raft 모듈과 로그, 상태 머신, 네트워크 계층과 이 Raft 구현체를 직접 통합하는 일을 수행하는데요, 문제는 직관적인 사용법과 별개로 제대로 동작하지 않는다는 점이었습니다.

[리더가 죽었는데 Leader election이 일어나지 않는 문제](https://github.com/lablup/riteraft-py/pull/10), [특정 시나리오에서 데이터 복제가 일어나지 않는 문제](https://github.com/lablup/riteraft-py/issues/1), [커밋 갯수가 255개를 넘어갈 때 일어나는 패닉](https://github.com/lablup/riteraft-py/issues/8) 등... 온갖 잡다한 이슈를 모두 해결해야 했습니다.

위 이슈들을 모두 해결하고 클러스터가 동작하는 것 처럼 보이게 만든 후에도 이슈는 계속해서 발생했습니다. 잘 동작하는 것 같다가도 특정 장애 상황을 마주하면 클러스터 일관성이 깨지거나 로그 동기화가 락인 되는 등 치명적인 문제들이 발생했습니다.

이슈가 발생할 때마다 매번 raft-rs의 기술적인 세부 사항들을 들여다보고 이해할 수 있어야 했으며 이 과정은 결국 raft-rs의 코드를 뜯어보고 하나 하나 이해해 나가는 과정을 요구했습니다.

# raftify

이슈를 해결하는 과정에서 riteraft와 다른 추상화를 사용하기로 결정했고 노드와 클러스터 상태를 디버깅 하기 위한 CLI 모듈 등 여러 변경 사항들을 구현하면서 라이브러리 이름을 [raftify](https://github.com/lablup/raftify)로 변경하게 되었습니다.

해당 라이브러리를 처음 개발하기 시작할 땐 어떤 파이썬 애플리케이션과도 잘 호환될 수 있도록 하는 것을 목표로 개발했기 때문에 raft화 시키겠다는 의미로 raftify라는 이름을 붙였습니다.

파이썬 구현체는 현재는 더 이상 개발하고 있지 않지만 [해당 브랜치](https://github.com/lablup/raftify/tree/python-legacy)에서 확인할 수 있습니다.

# raftify written in Rust

rraft-py 위에 파이썬으로 개발된 raftify는 결과적으로 잘 작동되긴 했지만 멀티 프로세스 구조로 작성된 조잡한 테스트 하네스는 CI에서 테스트 하기 힘들었고 쉽게 클러스터 일관성이 깨졌으며 코드가 조금만 복잡해져도 제어하기 힘들어졌습니다.

결과적으로 raftify 내부 로직을 러스트로 완전히 재작성하고 Raft 패키지의 하이 레벨에서의 인터페이스만을 파이썬으로 노출시키기로 결정하게 되었습니다.

그렇게 완전히 러스트로 재작성된 raftify는 싱글 스레드만으로 통합 테스트 수행이 가능했고, CI에서 테스트할 수 있어 코드 변경의 두려움을 없애도록 도와주었습니다.

# raftify 예제 코드

이 섹션에선 raftify를 사용해 간단한 분산 키값 저장소를 만들어봅니다.

전체 소스 코드는 [해당 링크](https://github.com/lablup/raftify/blob/main/examples/memstore/static-members/src/main.rs)를 참고하세요.

## 상태 머신 정의

우선은 키값 저장소에서 사용할 로그 엔트리와 상태 머신을 정의해야 합니다.

이 글에선 간단하게 로그 엔트리로 값을 정의하는 `Insert`라는 타입의 명령어만 정의해보겠습니다.

> 💡 이 글에선 Rust 문법, Raft의 이론적 배경에 대해 설명하지 않습니다.

```rust
#[derive(Clone, Debug, Serialize, Deserialize)]
pub enum LogEntry {
 Insert { key: u64, value: String },
}
```

상태 머신은 `HashMap` 타입으로 아래처럼 정의해보겠습니다.

```rust
#[derive(Clone, Debug)]
pub struct HashStore(pub Arc<RwLock<HashMap<u64, String>>>);
```

그런 다음 이 자료구조들을 어떻게 직렬화, 역직렬화 할지 나타낼 `encode`, `decode` 메서드를 정의해주어야 합니다. *bincode 크레이트*를 사용해 아래처럼 간단하게 정의할 수 있습니다.

```rust
impl AbstractLogEntry for LogEntry {
 fn encode(&self) -> Result<Vec<u8>> {
 serialize(self).map_err(|e| e.into())
 }

 fn decode(bytes: &[u8]) -> Result<LogEntry> {
 let log_entry: LogEntry = deserialize(bytes)?;
 Ok(log_entry)
 }
}

impl AbstractStateMachine for HashStore {
 fn encode(&self) -> Result<Vec<u8>> {
 serialize(&self.0.read().unwrap().clone()).map_err(|e| e.into())
 }

 fn decode(bytes: &[u8]) -> Result<Self> {
 let db: HashMap<u64, String> = deserialize(bytes)?;
 Ok(Self(Arc::new(RwLock::new(db))))
 }
}
```

마지막으로 HashStore에 raftify 내부 코드에서 사용될 세 가지 메서드를 정의하면 됩니다.

HashStore에 새 로그 엔트리가 적용될 때 호출될 메서드인 `apply`, 현재 HashStore의 상태를 스냅샷으로 저장할 때 호출될 `snapshot`, 스냅샷 바이트 슬라이스를 통해 HashStore의 상태를 복구할 때 호출될 `restore`를 아래처럼 정의해줍니다.

```rust
#[async_trait]
impl AbstractStateMachine for HashStore {
 async fn apply(&mut self, data: Vec<u8>) -> Result<Vec<u8>> {
 let log_entry: LogEntry = LogEntry::decode(&data)?;
 match log_entry {
 LogEntry::Insert { ref key, ref value } => {
 let mut db = self.0.write().unwrap();
 log::info!("Inserted: ({}, {})", key, value);
 db.insert(*key, value.clone());
 }
 };
 Ok(data)
 }

 async fn snapshot(&self) -> Result<Vec<u8>> {
 Ok(serialize(&self.0.read().unwrap().clone())?)
 }

 async fn restore(&mut self, snapshot: Vec<u8>) -> Result<()> {
 let new: HashMap<u64, String> = deserialize(&snapshot[..]).unwrap();
 let mut db = self.0.write().unwrap();
 let _ = std::mem::replace(&mut *db, new);
 Ok(())
 }
}
```

## 웹 서버 API 정의

예제에서 사용될 웹 서버 API를 정의해봅시다. 이 API를 통해 노드의 Raft 객체에 접근해 HashStore를 조작할 것입니다.

예제에선 *actix-web 크레이트*를 사용해 아래처럼 정의해보도록 하겠습니다.

*put* 명령은 Raft 객체의 RaftNode에서 `propose` 메서드를 호출함으로써 구현할 수 있습니다. 이전에 정의한 `Insert` 타입 LogEntry를 인코딩해 `RaftNode::propose` 메서드의 인자에 넘겨주면 됩니다.

*get* 명령은 인메모리에 저장되어 있는 HashMap에서 id에 해당하는 값을 리턴하는 것으로 구현할 수 있습니다.

```rust
#[get("/put/{id}/{value}")]
async fn put(data: web::Data<(HashStore, Raft)>, path: web::Path<(u64, String)>) -> impl Responder {
 let log_entry = LogEntry::Insert {
 key: path.0,
 value: path.1.clone(),
 };
 data.1.raft_node.propose(log_entry.encode().unwrap()).await;

 "OK".to_string()
}

#[get("/get/{id}")]
async fn get(data: web::Data<(HashStore, Raft)>, path: web::Path<u64>) -> impl Responder {
 let id = path.into_inner();

 let response = data.0.get(id);
 format!("{:?}", response)
}

```

## Raft 클러스터 부트스트랩

이제 RaftNode들의 클러스터를 부트스트랩 시켜 봅시다.

이 예제에서는 아래와 같은 구성을 갖는 Raft 클러스터를 부트스트랩할 것입니다.

아래와 같은 구성에서는 세 개의 노드가 `voter`로서 부트스트랩되므로 클러스터에 리더가 존재하지 않아 `election_timeout` 후 바로 리더를 선출하게 됩니다.

```toml
[[raft.peers]]
ip = "127.0.0.1"
port = 60061
node_id = 1
role = "voter"

[[raft.peers]]
ip = "127.0.0.1"
port = 60062
node_id = 2
role = "voter"

[[raft.peers]]
ip = "127.0.0.1"
port = 60063
node_id = 3
role = "voter"
```

```rust
let options = Options::from_args();
let store = HashStore::new();
let initial_peers = load_peers().await?;

let mut cfg = build_config();
cfg.initial_peers = Some(initial_peers.clone());

let node_id = initial_peers
 .get_node_id_by_addr(options.raft_addr.clone())
 .unwrap();

let raft = Raft::bootstrap(
 node_id,
 options.raft_addr,
 store.clone(),
 cfg.clone(),
 logger.clone(),
)?;

let handle = tokio::spawn(raft.clone().run());

// ...
tokio::try_join!(handle)?;
```

그리고 이 Raft 서버와 통신하기 위한 웹 서버를 붙여 줍시다.

```rust
if let Some(addr) = options.web_server {
 let _web_server = tokio::spawn(
 HttpServer::new(move || {
 App::new()
 .app_data(web::Data::new((store.clone(), raft.clone())))
 .service(put)
 .service(get)
 })
 .bind(addr)
 .unwrap()
 .run(),
 );
}
```

이제 터미널에서 아래처럼 세 노드로 이뤄진 Raft 클러스터를 부트스트랩 시킬 수 있습니다.

```sh
$ ./target/debug/memstore --raft-addr=127.0.0.1:60061 --web-server=127.0.0.1:8001
$ ./target/debug/memstore --raft-addr=127.0.0.1:60062 --web-server=127.0.0.1:8002
$ ./target/debug/memstore --raft-addr=127.0.0.1:60063 --web-server=127.0.0.1:8003
```

## 테스트

이제 `curl` 명령을 통해 `actix-web` 서버 API를 통해 우리가 정의한 키값 저장소를 사용해 볼 수 있습니다.

```sh
❯ curl http://localhost:8001/put/1/test
OK

❯ curl http://localhost:8001/get/1
Some("test")
```

더 자세한 내용이 궁금하시다면 [raftify 레포지토리](https://github.com/lablup/raftify)에서 디버깅을 도와주는 [CLI 모듈](https://github.com/lablup/raftify#debugging)의 사용법, `RaftServiceClient`의 예제 코드 등을 확인하실 수 있습니다.

# 정리

raftify는 일반 개발자 입장에서 접근하기 쉽지 않은 Raft 모듈을 누구나 쉽게 통합시킬 수 있도록 만드는 것을 목표로 하고 있는 실험적인 프레임워크입니다.

Backend.AI 매니저 프로세스들에 리더-팔로워 구조를 도입하겠다는 목적으로 개발되었지만 이 글에서 설명드린 것 처럼 짧은 소스 코드로 자신만의 간단한 분산 키값 저장소를 만드는 등 HA 구조가 필요한 곳에서 다양하게 활용될 수 있을 것으로 보입니다.

혹시 `tikv/raft-rs` 구현체 내부 동작 방식에 흥미가 생기셨다면 다음 글에서 몇 가지 시나리오에서 일어나는 일들을 소스코드 내부를 한 줄 한 줄 따라가며 분석해 볼 예정이니 기대해주시면 감사하겠습니다.

Introduce raftify: 확장성에 초점을 맞추어 개발된 하이 레벨의 Raft 프레임워크

현대 어플리케이션을 이야기할 때 고가용성(High Availability, HA)은 빼놓을 수 없는 개념이 되었습니다. 고가용성은 IT 시스템이 다운타임을 제거하거나 최소화하여 거의 100% 상시 액세스 가능하고 신뢰성을 유지하는 능력을 의미합니다[^1]. 래블업이 개발하고 서비스하는 Backend.AI도 고가용성을 유지하기 위하여 다양한 방법을 적용하고 있습니다.

<img src="https://cdn.lablup.com/backendai_architecture_7b94e46789.svg">
 Backend.AI의 구조도
</img>

## 배경

Backend.AI는 매니저와 에이전트, 스토리지 프록시와 웹서버 등 다양한 컴포넌트로 구성됩니다. 각 컴포넌트들은 각각 분산 환경에서 다중 프로세스로 실행되어 안정성을 높이고 있습니다. 특히 매니저 경우 Backend.AI의 세션 실행 스케줄링 및 여러 핵심 기능을 담당하고 있기 때문에 특히 더 높은 신뢰성을 보장해야 합니다. 현재 매니저에는 부하 분산을 통해 고가용성을 보장하는 Active-Active HA 구조가 적용되고 있습니다.

Backend.AI 매니저의 여러 기능 중 하나는 바로 이벤트 처리입니다. Backend.AI는 에이전트와 세션의 생명 주기(Lifecycle)를 추적하고 최적의 스케줄링을 제공하기 위하여 `AgentStartedEvent`, `DoScheduleEvent` 등 다양한 이벤트를 발생시킵니다. 예를 들어 한 Backend.AI Agent 프로세스가 실행될 때 `AgentStartedEvent`를 생성하게 되고, 이 이벤트를 수신한 Backend.AI Manager 프로세스는 특정 동작(`schedule()`)을 수행하게 됩니다. 또한 Backend.AI Manager는 내부적으로 `DoScheduleEvent`를 발생시키며 주기적인 스케줄링을 보장합니다. 이때 문제가 발생합니다. 고가용성을 위하여 여러 개의 Backend.AI Manager 프로세스를 실행할 경우, 각 프로세스가 자체적인 타이머를 갖고 이벤트를 발생시킨다면 불필요한 부하가 가해지는 것과 더불어 전체 시스템의 상태가 보장되지 못할 수 있게 됩니다. Backend.AI 매니저는 동일 시스템 내에서 오직 하나의 매니저 프로세스만 이벤트를 생성하는 것을 보장하기 위하여 [GlobalTimer](https://github.com/lablup/backend.ai/blob/2f90d03c4477eda8e0beeabb7fe4b067c56dae09/src/ai/backend/common/distributed.py#L19-L43)를 구현하였습니다. `GlobalTimer`는 분산 락(Distributed Lock)을 통해 프로세스 간 상호배제성을 확보하고, 오직 하나의 프로세스에서만 이벤트가 발생하도록 합니다.

```python title="backend.ai/src/ai/backend/common/distributed.py (2f90d03)"
@preserve_termination_log
async def generate_tick(self) -> None:
 try:
 await asyncio.sleep(self.initial_delay)
 if self._stopped:
 return
 while True:
 try:
 async with self._dist_lock:
 if self._stopped:
 return
 await self._event_producer.produce_event(self._event_factory())
 if self._stopped:
 return
 await asyncio.sleep(self.interval)
 except asyncio.TimeoutError: # timeout raised from etcd lock
 if self._stopped:
 return
 log.warn("timeout raised while trying to acquire lock. retrying...")
 except asyncio.CancelledError:
 pass
```

현재 Backend.AI는 분산 락에 대한 인터페이스인 [AbstractDistributedLock](https://github.com/lablup/backend.ai/blob/2f90d03c4477eda8e0beeabb7fe4b067c56dae09/src/ai/backend/common/lock.py#L33-L44)을 제공하고 있으며, 실제 구현체로는 [`FileLock`](https://github.com/lablup/backend.ai/blob/2f90d03c4477eda8e0beeabb7fe4b067c56dae09/src/ai/backend/common/lock.py#L47-L142), [etcd concurrency API](https://etcd.io/docs/v3.5/dev-guide/api_concurrency_reference_v3/) 기반의 [`EtcdLock`](https://github.com/lablup/backend.ai/blob/2f90d03c4477eda8e0beeabb7fe4b067c56dae09/src/ai/backend/common/lock.py#L145-L190), [Redis Lock](https://redis.io/docs/manual/patterns/distributed-locks/) 기반의 [`RedisLock`](https://github.com/lablup/backend.ai/blob/2f90d03c4477eda8e0beeabb7fe4b067c56dae09/src/ai/backend/common/lock.py#L193-L248)을 개발하여 사용하고 있습니다.

> [etcd](https://etcd.io/)는 분산 시스템을 계속 실행하는 데 필요한 중요한 정보를 보관하고 관리하는 데 사용되는 분산 오픈소스 키-값 저장소이며[^2], 대표적으로 [Kubernetes](https://kubernetes.io/) 등에서 사용되고 있습니다.

```python title="backend.ai/src/ai/backend/common/lock.py (2f90d03)"
class AbstractDistributedLock(metaclass=abc.ABCMeta):
 def __init__(self, *, lifetime: Optional[float] = None) -> None:
 assert lifetime is None or lifetime >= 0.0
 self._lifetime = lifetime

 @abc.abstractmethod
 async def __aenter__(self) -> Any:
 raise NotImplementedError

 @abc.abstractmethod
 async def __aexit__(self, *exc_info) -> Optional[bool]:
 raise NotImplementedError
```

## 요구사항

`GlobalTimer`는 분산 환경에서 프로세스 단위로 이벤트 생성을 제어하는 역할을 잘 수행하고 있습니다. 하지만 요구사항은 늘 변화하고 소프트웨어는 그에 발맞춰 변화해야 합니다. 이번에 추가된 요구사항은 요청 횟수 제한(rate limit)을 구현하는 것이었습니다. 현재와 같은 부하 분산 방식으로는 매 요청이 동일한 매니저에서 처리된다고 보장할 수 없는데, 각 매니저의 상태가 공유되지 않기 때문에 아래와 같은 문제가 발생할 수 있습니다.

```
1. 두 매니저의 카운터를 각각 0으로 설정하고 요청 횟수 제한을 1로 설정합니다.
2. 첫 요청을 1번 매니저가 받습니다.
3. 1번 매니저의 카운터를 1만큼 증가시킵니다. (C1: 0 -> 1)
4. 카운터가 최대 허용 횟수에 도달하여 다음 요청은 거절하게 됩니다.
5. 부하 분산에 의해 두 번째 요청을 2번 매니저가 받습니다.
6. 2번 매니저의 카운터는 아직 0이기 때문에 최대 허용 횟수에 도달하지 않았습니다. (C2: 0)
7. 2번 매니저가 요청을 처리합니다.
8. 요청 횟수 제한이 제대로 동작하지 않았습니다!
```

따라서 이런 한계점을 개선할 방법을 논의하기 위하여 아래와 같은 [이슈](https://github.com/lablup/backend.ai/issues/415)가 제안되었습니다.

<img src="https://cdn.lablup.com/distributed_timer_issue_a7018bb974.png">
 분산 타이머 개선을 제안하는 이슈 (lablup/backend.ai#415)
</img>

 

리더로 표현되는 단일 매니저 프로세스에 전역 상태 관리를 위임하기 위하여 합의 알고리즘(Consensus algorithms)을 조사하게 되었고, Kubernetes의 저장소로 사용되는(https://kubernetes.io/docs/concepts/overview/components/#etcd) etcd 등의 프로젝트에서 사용되며 충분한 검증을 거쳤다고 판단되는 [Raft Consensus Algorithm](https://raft.github.io/)(이하 Raft)을 이용하기로 결정했습니다.

## Raft 합의 알고리즘

Raft 알고리즘은 2014년 USENIX에 제출된 "In Search of an Understandable Consensus Algorithm"[^3]에서 제안된 방법입니다. 당대 최고의 알고리즘이던 Paxos[^4][^5]는 복잡한 합의 과정으로 인하여 실제로 이해하고 구현하는 데 어려움이 있었고, 제목에도 드러나듯 이러한 문제점을 개선하기 위하여 만들어졌습니다.

> But our most important goal — and most difficult challenge — was **understandability**.
>
> - In Search of an Understandable Consensus Algorithm

 

Raft 클러스터는 일반적으로 5개의 노드로 구성되는데, 최대 2대의 노드에 문제가 발생해도 `quorum`을 만족하여 시스템을 유지할 수 있기 때문입니다.
클러스터를 구성하는 각 노드는 아래의 세 가지 상태(리더, 팔로워, 후보자) 중 하나를 가집니다. 일반적으로 각 클러스터에는 최대 한 개의 리더가 존재할 수 있고, 나머지 노드는 팔로워가 됩니다.

> 용어 설명 #1
> - quorum: 의결(議決)에 필요한 최소한도의 인원수를 의미합니다. (N/2+1)


<img src="https://cdn.lablup.com/raft_server_states_d2b1a7b53c.png">
 Raft 노드의 상태 전이 다이어그램 (출처: In Search of an Understandable Consensus Algorithm)
</img>

Raft 알고리즘은 선출된 리더에게 모든 권한을 위임하며, 로그의 흐름을 일방향으로 만듦으로써 전체적인 흐름을 이해하기 쉽도록 만듭니다. Raft 알고리즘은 아래와 같은 특징을 가집니다.

> 용어 설명 #2
> - term: 현재 리더 혹은 후보자의 세대를 의미합니다. 리더 선거가 시작될 때마다 1씩 증가합니다.
> - index: 로그에서 특정 값의 위치를 의미합니다.
> - commit: 로그에 있는 특정 값을 상태 머신에 적용하였음을 나타냅니다.
> - commitIndex: 커밋에 성공한 가장 높은 index
> - Election Safety: 각 term에는 최대 하나의 리더가 존재합니다.
> - Leader Append-Only: 리더는 로그를 덮어쓰거나 삭제하지 않고 새로 추가만 가능합니다.
> - Log Matching: 두 로그에 동일한 index와 term을 가진 값이 있다면, 해당 index까지의 모든 값은 동일합니다.
> - Leader Completeness: 특정 term에 어떤 값이 로그에 commit되었다면, 이후 세대의 모든 리더는 이 값을 가지는 것을 보장합니다.
> - State Machine Safety: 한 서버가 특정 index의 로그 값을 상태 머신에 적용하였다면, 다른 서버는 동일한 index에 있는 다른 값을 적용할 수 없습니다.

위의 특징을 이용하여 Raft는 전체 합의 과정을 서로 독립적인 세 부분으로 나눕니다.

> - Leader election: 기존 리더가 동작하지 않으면 새 리더가 선출되어야 합니다.
> - Log replication: 리더는 클라이언트로부터 받은 요청 로그를 다른 노드에 복제합니다. 이때 다른 노드들은 리더의 로그를 무조건적으로 수용합니다.
> - Safety: 한 서버가 특정 index의 로그 값을 상태 머신에 적용하면 다른 서버는 동일한 index의 다른 값을 적용할 수 없습니다.

이번 글에서는 Raft 노드가 가지는 각 상태에 대하여 알아보고 리더 선출 과정을 코드로 구현해 보도록 하겠습니다.

### 팔로워(Follower)
팔로워는 자체적으로 요청을 보내지 않고 리더 혹은 후보자의 요청을 받아 대응하는 역할만 수행합니다. 논문에서 제안하는 팔로워의 행동 명세(Behavior Spec)와 이를 기반으로 작성된 코드는 아래와 같습니다.

- 리더와 후보자의 RPC 요청을 처리합니다.
```python title="aioraft/raft.py"
async def on_append_entries(
 self,
 *,
 term: int,
 leader_id: RaftId,
 prev_log_index: int,
 prev_log_term: int,
 entries: Iterable[raft_pb2.Log],
 leader_commit: int,
) -> Tuple[int, bool]:
 await self._reset_timeout()
 if term < (current_term := self.current_term):
 return (current_term, False)
 await self._synchronize_term(term)
 return (self.current_term, True)

async def on_request_vote(
 self,
 *,
 term: int,
 candidate_id: RaftId,
 last_log_index: int,
 last_log_term: int,
) -> Tuple[int, bool]:
 await self._reset_timeout()
 async with self._vote_request_lock:
 if term < (current_term := self.current_term):
 return (current_term, False)
 await self._synchronize_term(term)

 async with self._vote_lock:
 if self.voted_for in [None, candidate_id]:
 self._voted_for = candidate_id
 return (self.current_term, True)
 return (self.current_term, False)

async def _synchronize_term(self, term: int) -> None:
 if term > self.current_term:
 self._current_term.set(term)
 await self._change_state(RaftState.FOLLOWER)
 async with self._vote_lock:
 self._voted_for = None
```

- 일정 시간 동안 리더 혹은 후보자로부터 아무런 요청을 받지 못하면 후보자 상태가 됩니다.
```python title="aioraft/raft.py"
async def _wait_for_election_timeout(self, interval: float = 1.0 / 30) -> None:
 while self._elapsed_time < self._election_timeout:
 await asyncio.sleep(interval)
 self._elapsed_time += interval
 await self._change_state(RaftState.CANDIDATE)
```

> 리더는 주기적으로 팔로워들에게 하트비트(heartbeat) 메시지를 보냄으로써 자신의 존재를 알려야 합니다. 팔로워는 일정 시간(`election_timeout`) 동안 아무런 메시지를 받지 못하면 클러스터에 리더가 없는 것으로 판단하고, 자신이 새로운 리더가 되기 위하여 후보자가 되어 선거를 시작합니다.

### 후보자(Candidate)
후보자의 행동 명세와 구현 코드는 다음과 같습니다.
- 새로운 리더로부터 `AppendEntries` RPC 요청을 받으면 팔로워가 됩니다. (팔로워의 `on_append_etries()` 참고)
- 아래의 절차를 통해 선거를 시작합니다.
 - term을 1만큼 증가시킵니다. (term += 1)
 - 자신에게 투표합니다.
 - 선거 제한시간을 초기화합니다.
 - 다른 노드들에 `RequestVote` RPC 요청을 보냅니다.
```python
async def _start_election(self) -> None:
 self._current_term.increase()
 async with self._vote_lock:
 self._voted_for = self.id

 current_term = self.current_term

 terms, grants = zip(
 *await asyncio.gather(
 *[
 asyncio.create_task(
 self._client.request_vote(
 to=server,
 term=current_term,
 candidate_id=self.id,
 last_log_index=0,
 last_log_term=0,
 ),
 )
 for server in self._configuration
 ]
 )
 )
```
- 과반수 이상의 노드로부터 득표하면 리더가 됩니다.
```python
 for term in terms:
 if term > current_term:
 await self._synchronize_term(term)
 break
 else:
 if sum(grants) + 1 >= self.quorum:
 await self._change_state(RaftState.LEADER)
```
- 선거 제한시간이 초과되면 새 선거를 시작합니다.
```python
case RaftState.CANDIDATE:
 while self.__state is RaftState.CANDIDATE:
 await self._start_election()
 await self._reset_election_timeout()
 await self._initialize_volatile_state()
 if self.has_leadership():
 await self._initialize_leader_volatile_state()
 break
 await asyncio.sleep(self.__election_timeout)
```

### 리더(Leader)
- 선출 직후 최초의 하트비트(텅 빈 `AppendEntries` 요청) 메시지를 보냅니다. 이후 주기적으로 하트비트 메시지를 보냅니다.
```python
async def _publish_heartbeat(self) -> None:
 if not self.has_leadership():
 return
 terms, successes = zip(
 *await asyncio.gather(
 *[
 asyncio.create_task(
 self._client.append_entries(
 to=server,
 term=self.current_term,
 leader_id=self.id,
 prev_log_index=0,
 prev_log_term=0,
 entries=(),
 leader_commit=self._commit_index,
 ),
 )
 for server in self._configuration
 ]
 )
 )
 for term in terms:
 if term > self.current_term:
 await self._synchronize_term(term)
 break
```
- 클라이언트로부터 요청을 받으면 로그에 값을 추가합니다. 해당 값이 상태 머신에 적용된 후 요청에 대한 응답을 보냅니다.
- 팔로워가 리더가 추적하고 있는 값(nextIndex)보다 더 큰 index의 로그 값을 가지고 있을 경우, nextIndex부터 시작하는 로그를 팔로워에게 복제합니다.
 - 성공할 경우 리더의 nextIndex와 matchIndex를 갱신합니다.
 - 불일치(inconsistency)로 인해 실패할 경우 리더의 nextIndex를 감소시키고 다시 시도합니다.
- 아래와 같은 값(N)이 존재할 경우 commitIndex를 해당 값으로 갱신합니다.
 - 과반수 이상의 matchIndex가 N 이상임 (matchIndex >= N)
 - N번째 로그의 term이 현재 term과 동일함

> 리더는 팔로워들에 대하여 각각 nextIndex와 matchIndex를 관리합니다.
> - nextIndex: 각 팔로워에게 보내야 할 다음 인덱스
> - matchIndex: 각 팔로워에게 성공적으로 복제한 가장 높은 인덱스

## 마무리

이번 글에서는 Raft 알고리즘에 대하여 간단히 알아본 후 리더 선출을 수행하는 코드를 작성했습니다. 나머지 두 가지 기능(로그 복제, 멤버십 변경)은 실제로 구현하는 과정에서 타이밍 이슈 등 여러 다양한 문제를 마주하게 됩니다. 만약 Raft 알고리즘에 대하여 더 알고 싶으시다면 저자(Diego Ongaro)의 박사 학위 논문(CONSENSUS: BRIDGING THEORY AND PRACTICE)[^6]를 읽어보는 것을 추천합니다.

마지막으로 ChatGPT는 Raft 알고리즘에 대하여 어떻게 설명해 주는지 확인하며 글을 마치겠습니다.

<img src="https://cdn.lablup.com/raft_by_chatgpt_7f4e271db8.png">
 ChatGPT가 설명하는 Raft 알고리즘 (출처: OpenAI ChatGPT 3.5)
</img>

> 본 글은 [lablup/aioraft-ng](https://github.com/lablup/aioraft-ng)의 코드를 참고하여 작성되었습니다.
> 현재 래블업에서 개발하고 있는 차세대 Raft 프로젝트인 [lablup/raftify](https://github.com/lablup/raftify)에도 많은 관심 부탁드립니다.

[^1]: https://www.redhat.com/ko/topics/linux/what-is-high-availability
[^2]: https://etcd.io/
[^3]: https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14
[^4]: https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf
[^5]: https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
[^6]: https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf

Backend.AI를 위한 Raft 합의 알고리즘: 리더 선출

박동진

# 개요

과기특성화대학 공동운영 산학협력(CUop)에 지원하여 래블업 주식회사(이하 래블업)에서 8주간 인턴으로 근무했다.

온보딩, Backend.AI 개발, PyCon 참가를 통해 경험한 것들을 작성했다.

# 지원 동기

우연히 보게된 PyCon 발표 세션을 통해 래블업에 대해 처음 알게 되었다. 기술적으로 깊이 있고 열정이 있는 구성원이 많은 회사라는 것을 알 수 있었다. 나는 Python과 비동기 프로그래밍에 관심이 많았기 때문에 래블업을 지원했다.

# 온보딩

첫 2주동안 온보딩 과정을 진행했다.

Realtime Web Chat 구현, Backend.AI 개발 환경 구축, 코드 베이스 세미나 순서로 진행했다.

## Realtime Web Chat

Python asyncio에 친숙해지기 위한 과제이다. 실시간 채팅 앱을 비동기 웹 프레임워크인 aiohttp와 인메모리 데이터베이스인 redis를 이용해서 개발했다. 그리고 python과 redis를 한 번에 빌드하기 위한 docker compose를 설정하는 것도 과제에 포함되었다. 자세한 내용은 [Github Readme](https://github.com/pderer/webchat)를 참고하면 된다.

redis를 통해 메시지를 broadcast 하기 위해 Redis pub/sub을 이용했다. pub/sub은 메시지를 저장하지 않고 그대로 전달하는 플랫폼 역할을 한다. 메시지를 따로 저장하는 요구사항이 없었으므로 Redis pub/sub을 이용했다. 또한, Redis pub/sub 과정을 asyncio.create_task()를 통해 task로 등록하여 event loop에 의해 동작하도록 했다.
![Realtime Web Chat 실행 화면](https://cdn.lablup.com/Realtime_webchat_0f87103fe6.png) 
Realtime Web Chat 실행 화면

asyncio의 기본 동작에 대해 이해할 수 있었다. 어려운 부분은 질문하며 해결할 수 있었다. 래블업에서는 Microsoft Teams를 통해 자유롭게 질의응답을 할 수 있어 인턴 및 주니어 개발자가 성장할 수 있는 환경을 갖추었다고 생각한다.

## Backend.AI 개발 환경 구축

Backend.AI를 VM Farm 및 로컬 VM에 설치하여 직접 실행해보았다. 공식 문서를 읽으며 진행했는데 그 과정이 순탄치 않았다. 다양한 에러를 마주 했는데 인턴 동기들과 공유도 하고 Teams에 질문도 하며 해결했다.

> 💡 VM Farm은 가상 머신(Virtual Machine)을 관리하고 실행하는 환경을 뜻한다. 래블업은 독자적인 VM Farm을 가지고 있다.

그동안은 로컬에서만 개발을 했었는데 VM Farm과 VSCode를 SSH로 연결하여 개발하는 경험을 처음 해보았다. Backend.AI를 개발하기 위해서는 여러 프로세스들 (Manager, Agent, Storage proxy, Web server 등)과 Docker Container들을 실행해야 한다. 랩탑을 사용할 경우, 배터리에 부담이 가는 수준이다. 하지만 VM Farm을 사용하면 SSH 연결만 하면 되기 때문에 가볍게 Backend.AI를 개발할 수 있다. 실제로 회사 밖에서 랩탑을 충전할 수 없던 상황에서 VM Farm을 사용하여 오랫동안 개발할 수 있었다.

## 코드 베이스 세미나

Backend.AI에서 어려운 부분을 중심으로 코드를 본 후, 이해한 내용을 바탕으로 발표하는 세미나를 준비하게 되었다. Manager, Agent, GraphQL 중에서 나는 Manager 파트 발표를 맡았다.

Backend.AI는 오픈소스이기 때문에 공식 문서가 잘 쓰여 있다. 공식 문서를 보면서 전체적인 구조를 파악하고 궁금한 부분은 직접 사원분들에게 여쭤보면서 Backend.AI 아키텍처 공부를 진행했다. Backend.AI Manager의 Session / Kernel 생성, 스케줄링 제어가 발표 주제였기 때문에 Manager 코드를 보면서 manager process의 로그를 분석하는 방식으로 공부를 진행했다.
 ![세미나 발표를 준비하며 그렸던 시퀀스 다이어그램](https://cdn.lablup.com/Sequence_Diagram_27d4a0128e.png) 
세미나 발표를 준비하며 그렸던 시퀀스 다이어그램

로그를 분석하며 Session 상태가 Preparing에서 다시 Pulling으로 돌아가는 버그를 발견했다. 로그를 하나씩 분석한 보람(?)을 느꼈다. 비동기 코드 베이스라 로그를 순서대로 분석하는게 어려웠다. 하지만 Call graph와 시퀀스 다이어그램을 그리는 것이 큰 도움이 되었다.

# Backend.AI 개발

온보딩이 끝나고 Backend.AI 개발을 시작했다. GitHub Issue를 보고 자발적으로 지원하거나 이슈를 직접 발견해 해결하는 방식으로 진행했다.

[Backend.AI repository](https://github.com/lablup/backend.ai/pulls?q=is%3Apr+is%3Aclosed+author%3Apderer) 에서 9개의 Pull Request, [Backend.AI-WebUI repository](https://github.com/lablup/backend.ai-webui/pulls?q=is%3Apr+is%3Aclosed+author%3Apderer) 에서 2개의 Pull Request를 생성했고 모두 Merge 되었다!

나는 우선순위가 높은 이슈 중에서 자신 있는 것들을 골라 해결했다. 두달이라는 짧은 시간동안 최대한 많은 기여를 하고 싶었기 때문이다.

## 첫 PR

https://github.com/lablup/backend.ai/pull/1395

세미나를 준비하면서 찾아낸 버그를 수정하는 PR을 생성했다. API Parameter를 수정하면 되는 쉬운 PR 이었다. 하지만 branch name convention, commit convention, news fragment에 대해서 알 수 있었다. 그리고 GitHub Actions에 의한 CI (Countinuous Integration, 지속적 통합) 과정을 경험하고 Git 관련 여러 삽질도 미리 할 수 있었던 좋은 경험이었다.

> 💡 news fragment는 PR에 의해 생성된 브랜치가 무엇을 하려는 브랜치인지 한 문장으로 설명하는 Markdown이다. 미래에 다시 이 PR을 봤을 때, 무엇을 하려 했던 PR이었는지 알 수 있도록 간단명료하게 작성해야 한다.

## vfolder 관련 PRs

Teams에 인턴에게 줄 만한 이슈가 있다는 소식을 듣고 바로 지원했다. vfolder라는 새로운 개념을 공부해야 했지만, 이렇게 제품에 대해 이해해 나간다는 것이 중요할 것 같았다.

### PR (1)

https://github.com/lablup/backend.ai/pull/1397

project type vfolder는 admin만이 생성할 수 있다. keypair resource policy의 max_vfolder_count에 상관없이 vfolder를 생성할 수 있어야 하는데 user type vfolder가 max_vfolder_count를 넘어설 경우, project type vfolder를 생성할 수 없는 이슈였다. 처음에는 용어부터 헷갈렸지만 코드를 분석하고 질문도 하며 용어를 해석할 수 있었다.

### PR (2)

https://github.com/lablup/backend.ai/pull/1400

PR (1)을 해결하며 발견한 새로운 버그들을 해결했다.

### PR (3)

https://github.com/lablup/backend.ai/pull/1417

PR (1) 이슈와 연관된 이슈를 발견했다. DB migration과 GraphQL이라는 새로운 개념이 등장했지만 해보고 싶었던 것들이라 지원했다. [Alembic](https://alembic.sqlalchemy.org/en/latest/)이라는 DB migration 툴을 이용했다. 그리고 GraphQL 스키마 개념을 공부하고 하위 호환성을 지원하기 위해 query와 mutation 코드를 수정했다. 수정한 코드를 테스트하기 위해서 cURL을 사용하려 했지만 GraphQL은 REST API 보다 훨씬 긴 request 형태를 가지고 있어서 번거로웠다. GraphQL을 잘 알고 있는 인턴과 사원분에게 질문하며 test code를 작성했다. CLI 형태로 간편하게 수정한 query와 mutation을 테스트하는 python code를 작성하여 테스트를 편하게 할 수 있었다.

## WSProxy 관련 PRs

Teams에 이슈가 올라와 지원하였다. WebUI에서 resource group의 wsproxy 주소가 유효하지 않은 경우, 세션 삭제가 불가능한 버그가 있었다. WebUI 개발도 경험해보고 싶어 지원했다.

### PR (1)

https://github.com/lablup/backend.ai/pull/1423

이슈를 해결하기 위해 WebUI 코드를 읽어봤는데 wsproxy의 개념이 잘 잡히지 않았다. wsproxy에는 v1과 v2가 있다는 것을 알았는데 둘의 차이를 알기 쉽지 않아서 사원분들에게 질문했다. v1과 v2의 가장 큰 차이는 트래픽의 경로였다. v1은 manager를 거쳐서 컨테이너와 통신하는 반면, v2는 manager를 거치지 않고 바로 컨테이너와 통신할 수 있어 더 빠르다. wsproxy가 어떤 역할과 v1, v2의 차이를 알고 나니 코드가 어떻게 동작하는지 더 수월하게 알 수 있었다. 그리고 생각보다 많은 사원분이 차이를 잘 모르는 것을 알게 되었다. 쉬워 보이는 질문이 조직 안에서 나오지 않은 질문일 수도 있음을 깨달았다.

### PR (2)

https://github.com/lablup/backend.ai-webui/pull/1819

이슈를 해결하기 위해서 webui 코드도 수정했다. JavaScript 코드를 수정하기 위해서 Callback 함수, Promise 객체, async/await에 관해 공부했다. 다른 로직에 영향이 가지 않도록 에러 핸들링을 했고, 중복된 코드는 함수로 따로 정의 하여 코드의 중복을 없앴다.

### PR (3)

https://github.com/lablup/backend.ai-webui/pull/1833

그런데 WebUI는 Backend.AI 22.09와 하위 호환성을 유지해야 하므로 HTTP Status 404도 처리해야 한다는 CEO님의 리뷰가 있어 404와 500을 모두 처리하도록 했다.

### PR (4)

https://github.com/lablup/backend.ai/pull/1466

그런데 코드가 병합된 후에 버그가 발생했다. v1 wsproxy 설정 시, wsproxy-version에 대한 리턴값이 사라지는 버그였는데 내가 core 코드를 수정하다가 모든 분기에 대해 처리하지 못해서 생긴 버그였다. 급하게 코드를 수정했지만 간단한 실수라서 아쉬웠다. 이런 실수를 방지하기 위해 테스트 코드를 작성해야겠다는 생각이 들었다.

## Manager 관련 PR

https://github.com/lablup/backend.ai/pull/1444

세미나를 준비하며 공부했던 manager에 대한 이슈가 생겼다. 인턴 기간이 얼마 남지 않은 상황에서 내가 가장 잘 알고 있는 코드에 대한 이슈를 해결하는 것이 기여할 수 있는 방법이라 생각했다.

이 PR은 코드 리뷰에 의해 많은 수정이 있었다. 처음에는 scheduler health check와 scheduler trigger를 동일한 API로 설계했었다. 코드 리뷰를 받은 후에, 두 기능을 다른 API로 나누어 책임을 분리했다. 그리고 원래는 schedule 함수에 관해서만 상태 정보를 저장했었는데 prepare 함수와 scale_services 함수에 대해서도 상태 정보를 저장했다. 왜냐하면 scheduler의 글로벌 타이머에 따라서 주기적으로 실행되는 세 개의 함수에 대해 상태 정보를 저장한 후에 trigger API를 만들어야 scheduler의 상태를 완전히 파악할 수 있기 때문이다. 또한, Manager 프로세스가 여러 개일수도 있기 때문에 Manager ID에 따라 scheduler의 상태를 저장할 수 있도록 설계를 바꿨다.

scheduler의 저장소에 대해서도 코드 리뷰가 진행되었다. 처음에는 기존 manager 상태 API에서 manager 상태를 etcd에 저장하는 코드를 보고 동일하게 scheduler의 상태를 etcd에 저장했다. etcd는 일관성을 유지해야 하는 설정 정보를 저장하는 데 유리하지만, write 속도가 느리다. redis는 휘발성이 있는 데이터베이스이지만 read/write가 많아도 성능이 좋다. scheduler 상태를 주기적으로 read/write 하고 일관성을 유지해야 하는 정보는 아니기 때문에 redis에 저장하는 것으로 변경했다.

## Agent 관련 PR

https://github.com/lablup/backend.ai/pull/1472

Backend.AI의 Manager 부분을 어느 정도 이해했기 때문에 또 다른 중요한 컴포넌트인 Agent를 이해하고 싶었다. 마침 Agent에 대한 이슈가 생겨서 살펴보았다.

Backend.AI가 실행되는 동안 Agent의 내부 상태와 실제로 동작하는 컨테이너의 상태가 일치하지 않는 버그가 발생했다. 이에 따라 세션을 생성할 때, 실제로는 충분한 자원이 있음에도 불구하고 자원 할당 과정에서 InsufficientResource Error가 발생했다. 에러가 발생했을 때, 자원 할당 과정에서 무엇이 잘못되었는지를 알기 위해서 로깅을 개선할 필요가 있었다.

자원 할당 과정을 파악하는 것에 시간이 오래 걸렸다. 동시성 문제가 어려워서 CTO님과 많은 질의응답을 통해 대략적인 흐름을 파악하고 무엇을 로깅해야 하는지 알 수 있었다.

인턴이 끝나고 몆 주후, CTO님이 10개가 넘는 커밋을 통해 리팩터링과 테스트 코드까지 추가하시고 병합하셨다. 인상 깊었던 것은 에러를 재현하기 위해 테스트 코드를 작성하신 것이었다. 나는 에러를 재현하기 위한 복잡한 과정을 (PR 참고) 직접 수행했다. 그래서 개발 시간이 오래 걸리기도 했다. 이런 부분에서 생산성의 차이가 나타난다는 것을 알 수 있었다. 물론 테스트 코드를 작성할 생각은 했었지만, 구현이 너무 복잡할거라 생각했고 테스트 코드를 작성하느라 인턴이 끝날 것 같다고 생각했었다. 앞으로는 테스트 코드 작성에 너무 겁먹지 않고 일단 해보면서 배워야 겠다고 생각했다. 그리고 리팩터링은 코드 가독성을 중점으로 진행하신 것 같았다. 내가 수정한 부분의 함수가 너무 길어져서 가독성이 좋지 않았는데 리팩터링 후에는 함수가 짧아지고 로깅도 깔끔해져서 가독성이 좋았다. 구현하는데에서 멈추지 않고 좋은 코드를 만들기 위해 노력해야겠다는 생각을 했다.

# PyCon 참가

8월 12, 13일에 래블업이 PyCon에 부스를 열었다. PyCon에 후원하는 회사는 부스 활동을 할 기회가 주어진다. 나는 인턴이었지만 부스활동에 참여 하고 발표 세션도 듣고 싶었다. 마침 회사에 PyCon 표가 남았다고 해서 참여할 수 있었다.

래블업 부스에서는 Llama2에게 10줄짜리 피라미드를 프롬프트를 통해 출력하도록 만드는 이벤트를 진행했다. 난이도가 그렇게 쉬운 편은 아니었고, Llama2가 잘 알아들을 수 있도록 풀어서 설명하는 것이 중요했다. 정답을 제출한 분 중 두 명을 추첨하여 닌텐도 스위치, 로지텍 마우스를 증정했다. 나는 부스에서 PyCon 참여자들이 이벤트에 참여할 수 있도록 안내하는 역할을 했다. 그리고 PyCon에 사원분들이 많이 오셨기 때문에 내가 듣고 싶은 발표 세션이 있으면 자유롭게 들을 수 있었다. 래블업은 오픈소스 기반 회사라 오픈소스에 기여하고 컨퍼런스에 참여하는 것을 독려한다. 실제로 PyCon에 참여한 발표자가 총 4명일 정도로 컨퍼런스에 참가하는 것을 중요하게 생각한다.

 ![래블업 주식회사 부스](https://cdn.lablup.com/pycon23_booth_6059bf7e37.jpeg) 
래블업 주식회사 부스

RustPython 세션 발표 중에 python lint 툴인 flake8과 isort를 대체할 수 있는 ruff라는 툴이 소개되었다. ruff는 Rust로 구성되어 있어 flake8에 비해 100배가 더 빠르다. Backend.AI에서는 flake8, isort를 통해 lint를 했었는데 CTO분이 ruff를 검토해 보시고는 코엑스 계단에서 바로 Backend.AI 프로젝트에 ruff를 도입하시는 것을 지켜보았다. 짧은 시간 내에 프로젝트에 새로운 툴을 적용하고 공식 문서까지 수정하는 것을 보면서 코딩에 관련된 프로세스에 정말 능숙하다고 생각했다. 나도 언젠가는 능숙한 개발자가 되고 싶다고 생각했다. PyCon이 끝나고 업데이트된 공식 문서를 보며 ruff를 Backend.AI 개발환경에 적용하고 lint가 100배 빨리 되는 것을 직접 체험했다. PyCon에 참여하지 않았다면 좋은 툴을 빨리 사용하지 못했을 것이다. 앞으로도 개발자 컨퍼런스에 계속 참여하고 싶다.
![래블업 주식회사 구성원분들과 단체 사진](https://cdn.lablup.com/pycon23_all_dee19bbc26.jpeg) 
래블업 주식회사 구성원분들과 단체 사진

# 인턴십을 마치며

인턴십을 하며 최대한 많은 경험을 하려고 애썼다. 그리고 많은 기여를 하고 싶었다. 결론적으로, 많은 기여를 하기 위해 노력했기 때문에 많은 것을 경험할 수 있었다. Teams에서 언급되는 이슈에 빠르게 자원했다. 그래서 vfolder, wsproxy, web-ui, manager, agent라는 Backend.AI의 핵심 컴포넌트들을 이해할 수 있었다. 그리고 DB Migration, GraphQL, etcd 등의 새로운 개념들도 학습할 수 있었다. 주말 아침부터 저녁까지 컨퍼런스에 참여하는 것이 체력적으로 조금은 힘들었지만, 10개가 넘는 발표 세션을 자유롭게 들으며 영감을 얻고 부스 활동을 통해 다양한 사람들을 만나는 것도 재미있었다.

인턴십 동안 모르는 것을 적극적으로 질문했던 것 같다. 그 덕분에 이슈를 빠르게 해결할 수 있었다고 생각한다. 질문을 많이할 수 있었던 이유는 수평적인 래블업의 문화가 있었기 때문이라고 생각한다. 그리고 질문에 친절히 답변해주시는 분들이 많아서 활발하게 질문을 할 수 있었다. 이 자리를 빌어 도움을 주신 구성원분들에게 감사를 표하고 싶다.

내가 원했던 비동기 프로그래밍 경험을 포함해 GitHub 협업 방식, 영어 세미나 발표, 컨퍼런스 참가 등 다양한 것을 경험할 수 있었다. 이를 통해 개발자로서 큰 성장을 한 것 같다. 성장에 목마른 사람들에게 래블업 인턴십을 추천한다.

2023 여름 인턴십 후기

조규진

Backend.AI 23.09 버전이 정식으로 공개되었습니다. 23.09 버전의 핵심 기능인 Model Service에 대해서는 이전의 [Sneak Peek: Backend.AI Model Service 미리 보기](https://www.backend.ai/blog/2023-05-30-backend.AI-model-service-sneak-peek) 글에서 다뤘던 바가 있습니다. 그 이후로 GUI 지원, 인증 토큰 이력 관리 등의 다양한 새로운 기능이 추가되었는데요, 이러한 새 기능을 포함해서 Backend.AI Model Service를 쉽고 간편하게 이해할 수있도록 튜토리얼 형식으로 따라가 보는 시간을 가져보도록 하겠습니다. 
이번 튜토리얼 게시글에서는 Backend.AI Model Service를 이용해서 GPT-NeoX 모델을 Triton Inference Server 위에서 구동하는 법에 대해 안내합니다. Triton Inference Server는 NVIDIA에서 내놓은 오픈 소스 모델 인퍼런스 프레임워크이며, 자사의 TritonRT, FasterTransformer 및 TritonRT-LLM 및 PyTorch, TensorFlow, vLLM 등의 다양한 모델을 HTTP 및 gRPC [1](#footnote_1) 로 간편하게 제공할 수 있습니다.

## Model VFolder 생성
1. 데이터 & 폴더 탭으로 이동합니다. "새 폴더" 버튼을 클릭하여 VFolder 생성 다이얼로그를 엽니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_30_48_PM_f6b4c7a4b9.jpg) 
2. 새 모델 폴더를 생성합니다. 폴더 이름은 어떻게 적어도 관계 없지만 하단의 "사용 방식" 을 "Model" 로 설정해야 합니다. 모든 값을 지정하였으면 하단의 "생성" 버튼을 클릭합니다. 이제 모델 VFolder가 생성되었습니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_31_12_PM_7782dc5224.png) 

## FasterTransformer 형식 모델 변환
1. "세션" 탭으로 이동합니다. "시작" 버튼을 클릭하여 세션 생성 다이얼로그를 엽니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_33_29_PM_7e2bf0d6f2.jpg) 
2. "실행 환경" 을 `ngc-pytorch` 로, `버전` 은 `23.07` 을 선택합니다. 선택이 완료되었으면 오른쪽 아래의 화살표 아이콘을 클릭합니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_34_17_PM_c3b42b5e27.png) 
3. 세션에 탑재할 VFolder를 선택하는 창입니다. 모델을 적재하기 위해 "마운트할 모델 스토리지 폴더" 섹션 아래에서 방금 생성한 VFolder를 선택합니다. 선택이 완료되었으면 오른쪽 아래의 화살표 아이콘을 클릭합니다. 
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_36_18_PM_c9600865e0.png) 
4. 모델 세션에서 사용할 자원량을 지정하는 창입니다. CPU 코어를 16개 이상, RAM은 128GB 이상 할당하여야 원활한 모델 변환이 가능합니다. 선택이 완료되었으면 오른쪽 아래의 화살표 아이콘을 클릭합니다. 
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_37_16_PM_cf32bb2e21.png) 
5. 모든 설정이 올바르게 적용되었는지 확인한 후 아래의 "시작" 버튼을 클릭하여 세션을 시작합니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_37_59_PM_be8660c450.png) 
6. 세션이 생성되면 다음과 같이 앱을 선택하는 팝업이 나타납니다. "Console" 앱을 클릭하여 터미널 환경으로 접근합니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_38_30_PM_d9c42fb8fa.png) 
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_43_08_PM_96b88d44c1.jpg) 
7. 다음 쉘 스크립트를 실행하여 GPT-NeoX 20B 모델을 다운로드하고 FasterTransformer 형식에 맞게 변환합니다. 스크립트에서 `<VFolder 이름>` 이라고 언급된 부분을 생성한 모델 VFolder 이름으로 치환해서 실행해야 함에 주의하세요. 
```sh
cd /home/work/<VFolder 이름>
pip install -U transformers bitsandbytes
git clone https://github.com/NVIDIA/FasterTransformer
git clone https://huggingface.co/ElutherAI/gpt-neox-20b
cd neo-gptx-20b
git lfs install
git lfs pull
```
> GPT-NeoX 20B 모델은 실행에 40GB 이상의 VRAM을 요구합니다. 사용할 물리 GPU의 VRAM이 이보다 작아 모델을 여러 GPU에 나눠서 실행해야 할 경우, `-i_g` 매개 변수의 숫자를 사용할 GPU 갯수에 맞춰서 조정하세요.
```sh
cd /home/work/<VFolder 이름>
mkdir -p triton-deploy/gpt-neox-20b-ft
python ~/<VFolder 이름>/FasterTransformer/examples/pytorch/gptneox/utils/huggingface_gptneox_convert.py \
 -i /home/work/<VFolder 이름>/gpt-neox-20b \
 -o /home/work/<VFolder 이름>/triton-deploy/gpt-neox-20b-ft \
 -i_g 1 \
 -m_n GPT-NeoX-20B
```
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_55_43_PM_172b2e02a3.jpg) 

8. 7번까지의 과정을 모두 완료했다면 VFolder 아래에 다음과 같은 폴더들이 존재할 것입니다.
```sh
work@main1[PRRLCIqu-session]:~/GPT-NeoX-Triton-FT$ ls -al
total 62
drwxr-xr-x 5 work work 11776 Oct 12 12:14 .
drwxr-xr-x 9 work work 4096 Oct 12 12:29 ..
drwxr-xr-x 14 work work 12800 Oct 12 11:24 FasterTransformer
drwxr-xr-x 3 work work 16896 Oct 12 10:18 gpt-neox-20b
drwxr-xr-x 3 work work 11776 Oct 12 11:56 triton-deploy
```
이제 Triton Inference Server의 설정 파일을 추가할 차례입니다. `triton-deploy/gpt-neox-20b-ft/config.pbtxt` 파일을 생성하고 다음 내용을 추가합니다. 
> 7번 과정에서 `-i_g` 매개 변수의 값을 1이 아닌 다른 값으로 설정했을 경우, 아래 설정의 `tensor_para_size` 값을 `-i_g` 값과 일치하도록 수정해야 합니다.
```sh
name: "gpt-neox-20b-ft"
backend: "fastertransformer"
default_model_filename: "gpt-neox-20b-ft"
max_batch_size: 1024

model_transaction_policy {
 decoupled: False
}

input [
 {
 name: "input_ids"
 data_type: TYPE_UINT32
 dims: [ -1 ]
 },
 {
 name: "start_id"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "end_id"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "input_lengths"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 },
 {
 name: "request_output_len"
 data_type: TYPE_UINT32
 dims: [ -1 ]
 },
 {
 name: "runtime_top_k"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "runtime_top_p"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "beam_search_diversity_rate"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "temperature"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "len_penalty"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "repetition_penalty"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "random_seed"
 data_type: TYPE_UINT64
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "is_return_log_probs"
 data_type: TYPE_BOOL
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "beam_width"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "bad_words_list"
 data_type: TYPE_INT32
 dims: [ 2, -1 ]
 optional: true
 },
 {
 name: "stop_words_list"
 data_type: TYPE_INT32
 dims: [ 2, -1 ]
 optional: true
 },
 {
 name: "prompt_learning_task_name_ids"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "top_p_decay"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "top_p_min"
 data_type: TYPE_FP32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 },
 {
 name: "top_p_reset_ids"
 data_type: TYPE_UINT32
 dims: [ 1 ]
 reshape: { shape: [ ] }
 optional: true
 }
]
output [
 {
 name: "output_ids"
 data_type: TYPE_UINT32
 dims: [ -1, -1 ]
 },
 {
 name: "sequence_length"
 data_type: TYPE_UINT32
 dims: [ -1 ]
 },
 {
 name: "cum_log_probs"
 data_type: TYPE_FP32
 dims: [ -1 ]
 },
 {
 name: "output_log_probs"
 data_type: TYPE_FP32
 dims: [ -1, -1 ]
 }
]
instance_group [
 {
 count: 1
 kind: KIND_CPU
 }
]
parameters {
 key: "tensor_para_size"
 value: {
 string_value: "1"
 }
}
parameters {
 key: "pipeline_para_size"
 value: {
 string_value: "1"
 }
}
parameters {
 key: "data_type"
 value: {
 string_value: "fp16"
 }
}
parameters {
 key: "model_type"
 value: {
 string_value: "GPT-NeoX"
 }
}
parameters {
 key: "model_checkpoint_path"
 value: {
 string_value: "/models/triton-deploy/gpt-neox-20b-ft/1-gpu"
 }
}
parameters {
 key: "enable_custom_all_reduce"
 value: {
 string_value: "0"
 }
}
```
9. 마지막으로 Backend.AI Model Service 정의 파일을 VFolder 루트 아래에, `model-definition.yaml` (`model-definition.yml` 도 허용) 추가해야 합니다. Triton Inference Server를 실행하기 위한 모델 정의 파일을 자세히 들여다 보겠습니다.
```yaml
models:
- name: "GPT-NeoX"
 model_path: "/models/triton-deploy"
...
```
모델 이름과 모델의 경로를 지정하는 부분입니다. 
> 여기서 설정한 이름과 경로는 모델 서버 프로세스에서 각각 `BACKEND_MODEL_NAME`, `BACKEND_MODEL_PATH` 환경 변수로 접근할 수 있습니다.
> ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_10_54_11_PM_1ce66d14e0.png) 
```yaml
...
 service:
 start_command:
 - tritonserver
 - --model-repository=/models/triton-deploy
 - --disable-auto-complete-config
 - --log-verbose
 - "1"
...
```
모델 서버 프로세스를 시작하기 위한 명령줄 구문을 정의하는 부분입니다.
```yaml
...
 port: 8000
...
```
모델 서버 프로세스가 노출하는 API 통신용 포트를 기입하는 부분입니다. 지정하지 않은 경우, Triton Inference Server는 기본적으로 HTTP API 통신을 위해 `8000` 번 포트를 노출합니다. 그러므로 모델 정의 파일에도 해당 포트를 그대로 적어줍니다.
```yaml
...
 health_check:
 path: /v2/health/ready
 max_retries: 3
 max_wait_time: 5
 expected_status_code: 200
```
Health Check 기능을 활성화 및 설정하는 부분입니다. Health Check 기능이 활성화 된 경우, Backend.AI에서는 해당 경로에 지속적으로 HTTP GET 요청을 보내서 `expected_status_code` (생략 가능, 기본값 `200`) 에 해당하는 HTTP 응답 코드를 반환하는지를 검증합니다. 만약 모델 서버가 응답하지 않거나, 혹은 정의되지 않은 응답 코드를 반환하는 경우, Backend.AI는 해당 세션을 불량한 (Unhealthy) 세션으로 판단하고 서비스에서 제외합니다. 세션이 서비스에서 제외되더라도 해당 세션은 자동으로 종료되지 않으며 Model Service 관리자가 컨테이너 로그 등을 확인하여 적절한 조치를 직접 취해야 합니다. 
Health Check 기능은 해당 구문을 완전히 생략하는 것으로 비활성화 시킬 수 있습니다. 이렇게 할 경우 Backend.AI는 모델 서버의 상태를 검사하지 않고 항상 Healthy 상태인 것으로 간주합니다. 
`max_wait_time` 은 API 응답 Timeout을 정의하는 부분입니다. 초 단위의 숫자를 기입해야 합니다. 
`max_retries` 는 해당 모델 서버를 Unhealthy 상태로 판단하기 전까지 요청을 재시도하는 회수를 뜻합니다. 
완성된 모델 정의 파일은 다음과 같습니다.
```yaml
models:
- name: "GPT-NeoX"
 model_path: "/models/triton-deploy"
 service:
 start_command:
 - tritonserver
 - --model-repository=/models/triton-deploy
 - --disable-auto-complete-config
 - --log-verbose
 - "1"
 port: 8000
 health_check:
 path: /v2/health/ready
 max_retries: 3
 max_wait_time: 5
```
> 모델 정의 파일에 대한 더 자세한 내용은 [Backend.AI WebUI 문서](https://webui.docs.backend.ai/en/latest/model_serving/model_serving.html#creating-a-model-definition-file) 에서 확인하실 수 있습니다. 

이제 Model Service를 실행하기 위한 모든 준비가 완료되었습니다.
## Model Service 생성
1. "모델 서빙" 탭으로 이동합니다. "서비스 시작" 버튼을 클릭하여 Model Service 생성 창을 엽니다.
 ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_07_00_PM_c8cfaaffc9.jpg) 
 ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_11_31_PM_91d1100104.png) 
 각 섹션에 대해 조금 더 상세히 살펴보겠습니다.
 - ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_08_25_PM_6a054b93bd.png) 서비스 이름: Model Service 이름을 지정하는 칸입니다. Model Service의 이름은 Model Service Endpoint의 Subdomain으로 사용될 수 있습니다 (추후 업데이트 예정).
 - ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_12_20_PM_c403eb3d5b.png) 자원 그룹: Model Service용 Inference Session이 생성 될 자원 그룹을 선택하는 칸입니다.
 - ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_12_50_PM_22f7b84b81.png) 앱을 외부에 공개: 이 기능이 활성화 될 경우, 모델 서버로 향하는 모든 API 요청은 인증 헤더를 첨부해야 이루어질 수 있습니다. Model Service 인증에 대한 자세한 내용은 [Backend.AI WebUI 문서](https://webui.docs.backend.ai/en/latest/model_serving/model_serving.html#generating-tokens) 를 참고하세요.
 - ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_14_43_PM_06d5c0cbc9.png) 원하는 라우팅 수: 모델 서버 프로세스가 실행되는 추론 세션 수를 지정하는 칸입니다. 이 값을 1보다 큰 숫자로 설정할 경우 여러 개의 동일한 세션이 생성되고, API 요청은 이 세션들에게 균등하게 분배하는 라운드-로빈 로드 밸런서 기능이 활성화 됩니다. 이 값은 Model Service 생성 이후 언제든지 수정 가능합니다.
 - ![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_16_43_PM_be8f40c871.png) 추론 세션의 자원량을 지정하는 패널입니다.
> GPT-NeoX 20B 모델은 구동에 최소 40GB 이상의 vRAM을 요구합니다. 
> Backend.AI의 fGPU 단위와 vRAM의 관계는 사용 중인 Backend.AI의 설정에 따라 다르게 적용될 수 있습니다. 자세한 사항은 사용 중인 Backend.AI 의 관리자와 상의하세요.

모든 값을 올바르게 설정했다면 "확인" 버튼을 눌러 Model Service를 생성합니다. 
2. Model Service가 생성되었습니다. 추론 세션의 모델 프로세스가 아직 준비되지 않은 Model Service의 경우 상태가 "PROVISIONING" 에 머무르게 됩니다. 
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_19_08_PM_13ca45792d.jpg) 
"세션" 탭의 "INFERENCE" 섹션을 클릭하면 1에서 생성한 Model Service에 해당하는 추론 세션이 생성되었음을 확인할 수 있습니다.
![](https://cdn.lablup.com/image_7_df9dc80956.png) 
Model Service 관리자는 "제어" 행의 클립보드 아이콘을 클릭하여 추론 세션의 모델 서버 프로세스에 관련된 로그를 확인할 수 있습니다.
![](https://cdn.lablup.com/image_784ac56fce.jpg) 
3. 모델 서버 프로세스가 정상적으로 실행되면 하단의 라우트의 상태와 상단의 상태가 모두 "HEALTHY" 로 변경되며, "서비스 엔드포인트" 에 Model Service에 접근하기 위한 주소가 나타납니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_23_34_PM_42bb7108c3.png) 
이제 해당 주소를 통해 추론 세션에 실행된 Triton Inference Server에 접근할 수 있습니다.
![](https://cdn.lablup.com/Screenshot_2023_10_12_at_11_28_04_PM_d80ded6c89.png) 

## 마치며
지금까지 Backend.AI Model Service를 이용해서 LLM 모델 서빙을 시작하는 방법에 대해 알아보았습니다. Model Service 기능은 Backend.AI의 Cloud Beta에서 사용 가능합니다. 지금 여러분만의 모델 서빙을 시작해 보세요!

<a name="footnote_1">1</a>: Backend.AI Model Service에서는 지원하지 않음

Backend.AI Model Service Hands-on: GPT-NeoX 실행하기

# 23.09: 2023년 9월 업데이트
2023년 하반기 [Backend.AI](https://backend.ai)의 주요 릴리즈인 23.09 가 출시되었습니다. 23.09 에서는 생성AI 의 개발, 파인튜닝 및 운영 자동화 기능이 대폭 강화되었습니다. 워크로드에 따라 자동으로 AI 모델을 스케일링, 로드밸런싱하고 다양한 GPU/NPU 지원을 확장하였으며 한 대의 노드는 물론 100~2천대 이상의 노드들을 관리할 때의 안정성도 증가하였습니다.
개발팀은 최선을 다해 마지막 비트까지 짜내기 위해 노력하고 있습니다. 지난 [23.03 7월 업데이트](/posts/2023/07/31/Backend.AI-23.03-update) 이후 개선된 주요 내용들은 다음과 같습니다.

## Backend.AI Core & UI
- Backend.AI 모델 서비스 (Model Service) 기능이 정식 출시되었습니다. 이제 LLM과 같은 거대 모델의 학습 뿐만 아니라 추론 서비스를 위한 환경까지 Backend.AI 를 통해 더욱 효율적으로 준비할 수 있습니다. 자세한 내용은 [Backend.AI Model Service 미리 보기](/posts/2023/05/30/backend.AI-model-service-sneak-peek) 블로그를 참고하시기 바랍니다.
- OpenID SSO(Single Sign-On) 를 사용하여 Backend.AI에 로그인 할 수 있는 기능이 추가되었습니다.
- 커널 이미지가 지원하는 경우, 컴퓨팅 세션에서 sudo 명령을 패스워드 없이 사용하도록 설정 가능합니다.

- HAProxy를 이용하지 않은 Redis Sentinel 를 지원합니다. 이를 테스트하기 위해 `install-dev.sh` 파일에 `--configure-ha` 설정을 추가했습니다.
- Backend.AI Manager 와 Agent 간의 RPC 채널을 인증 및 암호화 통신이 가능하도록 기능을 추가하였습니다.
- Backend.AI Manager 의 CLI 로그 기능이 개선되었습니다.
- Backend.AI Agent 가 NAT 환경 아래에 놓여 있을 경우 Manager 가 RPC 연결을 할 수 없는 문제를 수정하였습니다.
- Raft 알고리즘 라이브러리인 riteraft-py가 앞으로 [raftify](https://github.com/lablup/raftify) 로 개명되어 개발됩니다.
- 다음의 신규 Storage Backend 들을 지원합니다.
 - VAST Data
 - KT Cloud NAS (Enterprise 전용)

## Backend.AI FastTrack
- 다양한 이기종 가속기 지원을 위한 UI 를 개선하였습니다.
- 이제 VFolder 삭제시 저장소 이름이 아닌 독립된 고유 ID 값을 이용합니다.
- Django 버전이 4.2.5 로, Node.js 버전이 20 으로 업그레이드 되었습니다.
- 미리 설정된 형태로 파이프라인을 생성해주는 파이프라인 템플릿 기능이 추가되었습니다.
- 파이프라인 전용 폴더가 삭제되었을 경우 FastTrack UI상에 비활성화된 것으로 표시됩니다.
- 파이프라인 삭제 과정이 개선되었습니다.
- 태스크(세션)별 접근 가능한 BACKENDAI_PIPELINE_TASK_ID 환경변수가 추가되었습니다.
- 태스크(세션)별 실제 실행 시간이 표시됩니다.

## Contribution Academy
특별히 지난 기간에는 NIPA 에서 주관하는 [2023 오픈소스 컨트리뷰선 아카데미](https://www.contribution.ac)를 통해 주니어 개발자 멘티분들의 다음과 같은 코드 기여들이 있었습니다.
- SSH/SFTP 접속 예제를 클립보드에 복사하는 버튼을 생성하였습니다.
- 기존에 사용되던 WebUI의 여러 Lit 엘리멘트를 React 로 리팩토링 하였습니다.
- 다양한 테스트 코드들을 작성했습니다.
- 정상적으로 동작하지 않던 환경변수 및 메시지 오류들을 발견하고 수정했습니다.

Backend.AI 는 하루가 다르게 변하는 AI 생태계에서 다양한 환경을 지원함과 동시에 더욱 강력하고 사용자 친화적인 환경을 제공하고자 끊임없이 발전하고 있습니다. 앞으로의 행보에도 많은 기대 부탁드립니다! 
Make your AI accessible with Backend.AI!

23.09: 2023년 9월 업데이트

조만석

## 들어가며

대부분의 리눅스 배포판, 예를 들어 우분투(Ubuntu)나 레드햇(RedHat, CentOS)에서는 시스템의 표준 C 라이브러리로 glibc를 사용합니다. 우분투에서는 apt, 레드햇 계열에서는 rpm(yum)으로 OpenSSL과 같은 라이브러리 패키지를 설치하면 기본적으로 glibc와 동적으로 링크됩니다.

GNU(그누)는 운영체제(Operating System)이자 컴퓨터 소프트웨어의 넓은 범위를 포함하고 있습니다. GNU는 프리소프트웨어재단(FSF)에서 개발하고 유지보수하는 오픈소스입니다. GNU에서 만든 대표적인 것들로는 GCC, G++, Make 등의 컴파일러나 개발 도구가 있으며, GNU는 표준 C 라이브러리로 glibc를 사용합니다. glibc는 GNU Lesser General Public License를 사용합니다.

musl(머슬)은 MIT 라이선스로 배포되는 리눅스 표준 C 라이브러리입니다. 개발자는 리치 펠커(Rich Felker)이며, glibc가 동적 링크를 사용하는 반면, musl은 정적 링크를 사용하여 POSIX 표준을 준수하는 표준 C 라이브러리를 구현하는 것을 목표로 합니다. 또한, 리눅스, BSD, glibc의 비표준 기능도 구현합니다.



## 리눅스 환경에서 glibc와 musl의 차이 

리눅스에서 패키지를 설치하면 기본적으로 glibc를 사용합니다.
보통 gcc를 이용해 C/C++ 프로그램을 빌드해본 경험이 있다면 높은 확률로 glibc 기반의 동적 링크 빌드를 진행하였을 것입니다.
하지만 이렇게 흔히 쓰이는 glibc 동적 빌드 외에도 musl 기반의 동적/정적 빌드를 할 수도 있습니다.

`*-linux-gnu`와 `*-linux-musl` 사이에는 다음과 같은 차이점이 있습니다.

| 빌드 타겟 | 표준 C 라이브러리 | 링크방식 |
|----------------|-------------------|----------------|
| `*-linux-gnu` | glibc | 동적 링크 |
| `*-linux-musl` | musl | 동적/정적 링크 |

Rust로 실행파일을 빌드하는 경우를 생각해봅시다.
`rustup`을 이용해 리눅스 환경에 Rust를 설치하면 `*-linux-gnu`가 기본 타겟으로 선택됩니다.

별도의 옵션을 지정하지 않으면 Rust는 `*-linux-gnu` 타겟으로 바이너리를 빌드하고 glibc와 동적으로 링크합니다.
이렇게 빌드한 바이너리를 실행하려면 해당 리눅스 환경에 glibc가 설치되어 있어야 동작합니다.
만약 바이너리가 OpenSSL과 같은 외부 라이브러리에 의존하고 있다면(동적으로 링크되어 있다면), apt와 같은 패키지 관리자를 통해 해당 라이브러리도 설치해주어야 합니다.
이러한 동적 링크 바이너리를 일반 사용자가 실행하려면, 외부 라이브러리에 대한 의존성 정보가 기술된 DEB나 RPM 등의 패키지 형태로 묶어주면 됩니다.
그러면 패키지 관리자가 적절한 종속 라이브러리를 자동으로 찾아서 설치해줍니다.
하지만 패키지 관리자에 등록되지 않은 라이브러리를 사용하는 경우나 동일한 라이브러리더라도 설치된 버전과 개발할 때 사용한 버전 사이에 미묘한 호환성 문제가 있는 경우 빌드한 바이너리가 의도대로 실행되지 않을 가능성도 있습니다.

Rust는 `*-linux-musl` 타겟을 지정하면 바이너리를 빌드할 때 musl과 정적으로 링크합니다.
OpenSSL과 같은 외부 라이브러리에 의존하는 경우 이것들과도 정적 링크를 사용하여 바이너리에 모두 내장시킵니다.
즉, Rust의 단일 바이너리 파일 안에 이 모든 라이브러리들이 모두 포함되는 상태가 됩니다.
이런 정적 바이너리라면 CPU 아키텍처와 리눅스 커널에서 제공하는 시스템콜 집합만 맞으면 어떤 리눅스 환경에서도 실행할 수 있습니다.
DEB나 RPM 등의 패키지를 사용하지 않고도 단일 바이너리만 전달하면 실행할 수 있기 때문에 바이너리를 배포하는 것이 더욱 간편해집니다.

이렇게 바이너리 배포 과정을 쉽게 만들어주는 `*-linux-musl` 타겟을 왜 리눅스 환경에서는 기본값으로 사용하지 않는 것일까요?

그 이유는 musl을 사용하면 빌드 준비가 다소 복잡해지기 때문입니다.
개발자가 만든 바이너리 패키지가 `*-linux-musl`를 사용하면서 동시에 외부 라이브러리에 의존하는 경우, 그 외부 라이브러리 또한 glibc와 동적으로 링크하는 대신 musl과 정적으로 링크된 것이어야 하기 때문입니다.
따라서 musl용 컴파일러를 사용해서 빌드하고자 하는 프로그램의 본체뿐만 아니라 모든 의존 라이브러리를 소스 코드부터 정적 링크로 빌드해야 합니다.

다행히도, Rust에서 자주 사용되는 외부 라이브러리라면 처음부터 모든 것을 다 새로 빌드할 필요는 없습니다.
자주 사용되는 라이브러리와 Rust 컴파일러/gcc를 묶은 Docker 이미지를 활용하면 간편하게 musl 기반 정적 빌드를 만들 수 있습니다.
(이제부터 등장하는 명령어 예제에서, 각 리눅스 배포판별 컨테이너 환경을 구분하기 위해 임의로 `<배포판이름>#` 프롬프트를 사용하겠습니다.)

```console
$ docker run -it --name ubuntu ubuntu:22.04 bash
ubuntu# apt update && apt install -y curl gcc vim
```

개발에 주로 사용되는 Rust 언어 환경에서 동적 링크인 glibc와 정적 링크인 musl 환경을 구성해보겠습니다.
우선, 우분투 환경에 Rust를 설치합니다.

```console
ubuntu# curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
ubuntu# source $HOME/.cargo/env
```

Rust의 기본 예제인 "Hello World" 출력을 통해 동적 링크와 정적 링크를 비교해보겠습니다.

먼저, glibc를 이용하여 "Hello World"를 빌드해봅시다.

```console
ubuntu# cd
ubuntu# cargo new --bin hello && cd $_
 Created binary (application) `hello` package
ubuntu# cargo build --release
 Compiling hello v0.1.0 (/root/hello)
 Finished release [optimized] target(s) in 0.35s
```

`ldd` 명령을 사용하여 glibc 환경에서 라이브러리가 동적 링크로 구성된 것을 확인해봅시다.
`linux-vdso`, `libgcc_s`, `libc` 등이 동적 링크로 구성된 것을 확인할 수 있습니다.

```console
ubuntu# ldd target/release/hello
 linux-vdso.so.1 (0x00007fffe87df000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdce9c3f000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdce9a17000)
 /lib64/ld-linux-x86-64.so.2 (0x00007fdce9cc2000)
```

그러면 musl 정적 링크로 rust 타겟 구성을 변경해봅시다.

```console
ubuntu# rustup target add x86_64-unknown-linux-musl
info: downloading component 'rust-std' for 'x86_64-unknown-linux-musl'
info: installing component 'rust-std' for 'x86_64-unknown-linux-musl'
 34.7 MiB / 34.7 MiB (100 %) 8.6 MiB/s in 4s ETA: 0s

ubuntu# rustup show
Default host: x86_64-unknown-linux-gnu
rustup home: /root/.rustup

installed targets for active toolchain
--------------------------------------

x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.72.0 (5680fa18f 2023-08-23)

ubuntu# 
```

"Hello World"를 빌드하여 정적 링크가 올바르게 구성되었는지 확인하겠습니다.

```console
ubuntu# cargo build --release --target=x86_64-unknown-linux-musl
 Compiling hello v0.1.0 (/root/hello)
 Finished release [optimized] target(s) in 0.37s

ubuntu# ldd target/x86_64-unknown-linux-musl/release/hello
statically linked
```

"Hello World"가 musl 환경을 사용하여 정적 링크로 구성된 것을 확인할 수 있습니다.

이제 동적 링크와 정적 링크로 빌드된 'Hello World'를 CentOS와 Alpine 환경에서 바이너리를 복사하여 실행해보겠습니다.
CentOS 8은 glibc 동적 링크를 사용하고, Alpine 리눅스는 musl 정적 링크를 사용합니다.

### CentOS 컨테이너 환경

```console
$ docker run -it --name centos centos:centos8 bash
centos#
```

### Alpine 컨테이너 환경 
Alpine 배포판은 glic가 아닌 musl을 기본으로 사용합니다.

```console
$ docker run -it --rm alpine:3.18
alpine#
```

'Hello World'를 glibc 환경과 musl 환경으로 복사하여 동작을 확인하겠습니다.

```console
$ docker cp ubuntu:/root/hello/target/x86_64-unknown-linux-musl/release/hello .
$ docker cp hello centos:/root/
$ docker cp hello alpine:/root/
```

centOS에서 동작을 확인하겠습니다. 
```console
centos# ./hello
Hello, world!
```

alpine에서 동작을 확인하겠습니다. 
```console
alpine# ./hello
Hello, world!
```

## Rust 어플리케이션 'slice'를 사용한 glibc와 musl 비교 

Rust 어플리케이션 'slice'를 가지고 glibc와 musl을 적용해서 만든 컨테이너 이미지를 비교해 보겠습니다. 

Python의 'slice'와 같이 Rust로 구현된 'slice'는 GitHub 저장소 https://github.com/ChanTsune/slice 에 공개되어 있습니다. 'slice'는 'head'나 'tail'처럼 파일의 앞 혹은 뒤에서부터 내용을 출력해주는 도구입니다.
예를 들어, 아래의 명령은 'file.txt'에서 10번째 줄부터 20번째 줄까지 출력하게 됩니다.

```console
$ slice 10:20 file.txt
```

'slice'를 Rust 환경에서 빌드하고 컨테이너를 만들어 사용할 때는 다음과 같이 사용할 수 있습니다.

```console
$ docker run -i --rm -v `pwd`:`pwd` -w `pwd` slice
```

Ubuntu 22.04 환경에서 glibc를 사용한 컨테이너를 빌드해보겠습니다.

```dockerfile
FROM rust:latest as builder

WORKDIR /work
RUN git clone https://github.com/ChanTsune/slice /work/.
RUN cargo build --release
RUN strip /work/target/release/slice -o /slice

FROM ubuntu:22.04
COPY --from=builder /slice /usr/local/bin/

ENTRYPOINT ["slice"]
```

이번에는 musl 정적 링크를 사용하여 Ubuntu 22.04 기반의 컨테이너 이미지를 만들어 보겠습니다.

```dockerfile
FROM rust:latest as builder

RUN rustup target add "$(uname -m)"-unknown-linux-musl
WORKDIR /work
RUN git clone https://github.com/ChanTsune/slice /work/.
RUN cargo build --release --target "$(uname -m)"-unknown-linux-musl
RUN strip /work/target/"$(uname -m)"-unknown-linux-musl/release/slice -o /slice

FROM ubuntu:22.04
COPY --from=builder /slice /usr/local/bin/

ENTRYPOINT ["slice"]
```

musl 정적 링크를 사용하여 Alpine 배포판 기반의 컨테이너 이미지를 만들어 보겠습니다.

```dockerfile
FROM rust:latest as builder

RUN rustup target add "$(uname -m)"-unknown-linux-musl
WORKDIR /work
RUN git clone https://github.com/ChanTsune/slice /work/.
RUN cargo build --release --target "$(uname -m)"-unknown-linux-musl
RUN strip /work/target/"$(uname -m)"-unknown-linux-musl/release/slice -o /slice

FROM alpine
COPY --from=builder /slice /

ENTRYPOINT ["slice"]
```

Ubuntu 22.04 기반의 glibc 컨테이너 이미지와 musl 컨테이너 이미지, 그리고 Alpine 기반의 musl 컨테이너 이미지의 크기를 비교해보면 musl을 사용한 컨테이너 이미지의 크기가 더 작은 것을 확인할 수 있습니다.

```console
$ docker images 
REPOSITORY TAG IMAGE ID CREATED SIZE
slice distroless-musl d38a74f8568a 11 seconds ago 3.52MB
slice alpine-musl e3abb5f0aace 39 seconds ago 8.4MB
slice ubuntu22.04-musl 467edd130e79 About a minute ago 78.9MB
slice ubuntu22.04-glibc 09fe5ad40d56 3 minutes ago 78.8MB
```

우분투 환경에서는 glibc나 musl을 사용하더라도 컨테이너 이미지 크기에 큰 차이가 없지만, Alpine 배포판에서는 컨테이너 이미지 크기가 약 10분의 1로 줄어든 것을 확인할 수 있습니다.
이를 통해 정적 빌드를 사용하는 Alpine 리눅스를 활용하면 컨테이너 이미지를 가볍게 만들고 배포 시간을 단축할 수 있음을 알 수 있습니다.

## 맺음말

표준 C 라이브러리를 사용하는 프로그램에서 정적 링크를 사용하면 리눅스 바이너리 배포 과정을 단순화할 수 있습니다.
또한 컨테이너 이미지 크기가 동적 링크에 비해 작아지며, 배포판에 관계 없이 배포가 편리해집니다.
glibc를 musl로 대체했을 때, 컨테이너 이미지 크기의 차이뿐만 아니라 musl에서 새롭게 지원하는 mDNS(a multicast-DNS-based zero config system), NUMA cluster와 같은 기능을 사용할 수 있는 이점이 있습니다.
더 나아가, musl을 보다 잘 활용하기 위해 구글에서 배포하는 distroless를 기본 컨테이너 이미지로 사용하면, 더 작은 컨테이너 이미지를 배포하여 활용할 수 있습니다.

천고마비의 계절, 컨테이너 다이어트하기

# 23.03: 2023년 7월 업데이트
Backend.AI 23.03 및 22.09의 지속적 업데이트 내용을 정리합니다. 개발팀은 최선을 다해 마지막 비트까지 짜내기 위해 노력하고 있습니다.

이번 업데이트에서 가장 중요한 변경사항은 다음과 같습니다:

- 스토리지 관리성 강화: VFolder v3 아키텍처 적용으로 사용자 및 프로젝트별 스토리지 용량 관리 기능(Quota)을 추가하였습니다.
- NVIDIA 호환성 확장: CUDA v12 및 NVIDIA H100 시리즈를 지원합니다.
- 하드웨어 호환성 확장: [퓨리오사에이아이(FuriosaAI) 사](https://www.furiosa.ai)의 WARBOY 가속기를 지원합니다.

## Backend.AI Core & UI
* CUDA v12 및 NVIDIA H100 시리즈를 지원합니다.
* [퓨리오사에이아이(FuriosaAI) 사](https://www.furiosa.ai)의 첫 번째 NPU인 WARBOY 가속기를 지원합니다.
* VFolder v3 아키텍처 적용으로 사용자 및 프로젝트별 스토리지 용량 관리 기능(Quota)을 추가하였습니다.
  * 단, Directory Quota를 지원하는 스토리지에 한정합니다.
* 멀티노드 클러스터 세션 생성이 실패하는 오류를 수정하였습니다.
* `PULLING` 상태의 연산 세션이 `PREPARING` 상태로 잘못 표기되는 오류를 수정하였습니다.
* 다수의 스토리지에 동일한 이름의 폴더를 보유할 경우 해당 이름의 데이터 폴더 복제 시 `CLONING` 상태가 제대로 표기되지 않는 오류를 수정하였습니다.
* 커널 이미지에 zsh 패키지가 설치되어 있는 경우 연산 세션의 웹 터미널이 zsh를 기본 쉘로 사용하도록 개선하였습니다.
* (관리) 스토리지 프록시 및 이벤트 버스의 건강 상태를 알 수 있는 기능을 추가하였습니다.

## Backend.AI FastTrack
* 태스크별 `multi-node` 클러스터 모드 설정 기능을 추가하였습니다.
* `.env`에 설정한 환경변수가 프론트엔드에 적용되지 않는 오류를 수정하였습니다.
* 모바일 브라우저로 접속할 경우 out-of-date로 인식하는 오류를 수정하였습니다.
* 태스크별 에러가 발생할 경우 원인 메시지를 보여주는 필드를 추가하였습니다.
* 기타 에디터 관련 문제를 개선하였습니다.

Backend.AI 는 하루가 다르게 변하는 AI 생태계에서 다양한 환경을 지원함과 동시에 더욱 강력하고 사용자 친화적인 환경을 제공하고자 끊임없이 발전하고 있습니다. 앞으로의 행보에도 많은 기대 부탁드립니다!   
Make your AI accessible with Backend.AI!


23.03: 2023년 7월 업데이트

바야흐로 LLM(Large Language Model, 대형 언어 모델)의 시대입니다. 2022년 11월, OpenAI가 발표한 [ChatGPT](https://openai.com/blog/chatgpt)는 [AlphaGo](https://www.deepmind.com/research/highlighted-research/alphago)의 자리를 이어받아 현대 인공지능의 대명사가 되었습니다. 많은 기업과 연구소에서는 ChatGPT 기반의 자체적인 언어 모델을 개발하는 데 힘을 쏟고 있으며, Meta AI의 [Llama 2](https://ai.meta.com/blog/llama-2/)와 같이 오픈 소스로 공개되는 사례도 증가하고 있어 개인의 접근성도 높아지고 있습니다.

**Backend.AI**는 대규모 클러스터 운용과 분산처리에 편리성을 제공하고 있어 이러한 LLM을 개발하기 위한 환경으로써 많은 선택을 받고 있습니다. 실제로 다양한 고객사로부터 관련 피드백과 요청을 받고 있으며, 오늘은 그중에 하나를 해결한 과정을 다뤄보고자 합니다.

2023년 4월 4일, [NGC Catalog](https://catalog.ngc.nvidia.com/containers)[^1](NVIDIA GPU Cloud)에서 제공하는 컨테이너 환경에서 특정 패키지를 실행할 때 에러가 발생한다는 이슈를 전달받았습니다. NGC Catalog는 AI/ML, 메타버스, 그리고 고성능 컴퓨팅 어플리케이션을 개발하기 위해 최적화된 환경이 구성된 컨테이너 목록[^2]으로, NVIDIA에서 직접 운영하고 배포하기 때문에 높은 신뢰도를 얻고 있으며 특히 CUDA 환경에서의 표준으로 여겨지고 있습니다. 따라서 해당 환경에서 문제가 발생한다는 것은 앞으로도 다수의 사용자가 마주하게 될 잠재적 위험을 안고 간다는 의미이기에 높은 우선순위로 이 이슈를 해결하기로 했습니다.

## 문제 재현

우선 정확한 원인을 파악하기 위하여 문제를 재현하는 과정을 먼저 거쳤습니다. 이번 사례는 Columbia University에서 개발한 [ViperGPT](https://github.com/cvlab-columbia/viper)[^3]를 실행하던 중 `bitsandbytes`라는 패키지에서 에러가 발생한 경우였습니다. ViperGPT는 아래와 같이 `bitsandbytes`에 의존성을 갖고 있습니다.

```txt showLineNumbers title="requirements.txt"
accelerate==0.18.0
backoff==2.2.1
// highlight-next-line
bitsandbytes==0.38.1
cityscapesscripts==2.2.1
git+https://github.com/openai/CLIP.git
decord==0.6.0
dill==0.3.6
...
```

단순히 `bitsandbytes`를 `import` 하는 것만으로 문제 재현이 가능했습니다.

> 실행 환경은 [nvcr.io/nvidia/pytorch:22.05-py3](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/pytorch) 이미지를 이용했습니다.

```bash
$ pip install bitsandbytes # 0.37.1
$ python
>> import bitsandbytes
===================================BUG REPORT===================================
Welcome to bitsandbytes. For bug reports, please submit your error trace to: https://github.com/TimDettmers/bitsandbytes/issues
================================================================================
CUDA exception! Error code: OS call failed or operation not supported on this OS
CUDA exception! Error code: initialization error
CUDA SETUP: CUDA runtime path found: /home/work/data/miniconda3/envs/vipergpt/lib/libcudart.so
/home/work/data/miniconda3/envs/vipergpt/lib/python3.10/site-packages/bitsandbytes/cuda_setup/main.py:136: UserWarning: WARNING: No GPU detected! Check your CUDA paths. Proceeding to load CPU-only library...
 warn(msg)
CUDA SETUP: Detected CUDA version 116
CUDA SETUP: Loading binary /home/work/data/miniconda3/envs/vipergpt/lib/python3.10/site-packages/bitsandbytes/libbitsandbytes_cpu.so...
/home/work/data/miniconda3/envs/vipergpt/lib/python3.10/site-packages/bitsandbytes/cextension.py:31: UserWarning: The installed version of bitsandbytes was compiled without GPU support. 8-bit optimizers and GPU quantization are unavailable.
 warn("The installed version of bitsandbytes was compiled without GPU support. "
```

`bitsandbytes`는 실행 환경에 설치된 모든 CUDA 디바이스를 순회하며 Compute Capability[^4]를 확인합니다. 이때 아래와 같은 방식으로 `libcuda.so`를 이용하여 실행 환경에 설치된 CUDA 디바이스의 개수를 확인하도록 되어 있었습니다. 그중 `cuDeviceGetCount()`[^5]를 호출할 때 에러가 발생하는 것을 확인했습니다. 바로 304 CUDA_ERROR_OPERATING_SYSTEM 에러였습니다.

```python title="bitsandbytes/cuda_setup/main.py"
def get_compute_capabilities(cuda):
 """
 1. find libcuda.so library (GPU driver) (/usr/lib)
 init_device -> init variables -> call function by reference
 2. call extern C function to determine CC
 (https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__DEVICE__DEPRECATED.html)
 3. Check for CUDA errors
 https://stackoverflow.com/questions/14038589/what-is-the-canonical-way-to-check-for-errors-using-the-cuda-runtime-api
 # bits taken from https://gist.github.com/f0k/63a664160d016a491b2cbea15913d549
 """

 nGpus = ct.c_int()
 cc_major = ct.c_int()
 cc_minor = ct.c_int()

 device = ct.c_int()

 # highlight-next-line
 check_cuda_result(cuda, cuda.cuDeviceGetCount(ct.byref(nGpus)))
 ccs = []
 for i in range(nGpus.value):
 check_cuda_result(cuda, cuda.cuDeviceGet(ct.byref(device), i))
 ref_major = ct.byref(cc_major)
 ref_minor = ct.byref(cc_minor)
 # 2. call extern C function to determine CC
 check_cuda_result(cuda, cuda.cuDeviceComputeCapability(ref_major, ref_minor, device))
 ccs.append(f"{cc_major.value}.{cc_minor.value}")

 return ccs
```


## bitsandbytes란?

[Transformer](https://ai.googleblog.com/2017/08/transformer-novel-neural-network.html)의 등장 이래로 언어 모델은 높은 성능 향상을 보였고, 더 많은 Transformer 블록을 쌓아 모델의 규모를 키우는 것이 트렌드가 되었습니다. 이로 인해 모델을 학습시키는 것뿐만 아니라 서비스할 때마저 수많은 GPU 자원을 요구하게 되었습니다. 예를 들어, 175B의 파라미터를 가지고 있는 GPT-3를 서비스하기 위해서는 약 $15,000의 80GB A100 GPU가 8개 필요합니다. 총 $120,000의 비용이 요구된다는 의미입니다. 이것은 개인뿐만 아니라 기업 혹은 연구소에도 큰 부담이 될 수밖에 없고, 이에 따라 서비스를 위한 추론 모델을 경량화하는 연구가 활발하게 진행되고 있습니다.

![](https://cdn.lablup.com/230728_large_language_model_3205b7be28.png)
<Figure>
 이미지 출처: <a href="https://huggingface.co/blog/hf-bitsandbytes-integration">A Gentle Introduction to 8-bit Matrix Multiplication for transformers at scale using Hugging Face Transformers, Accelerate and bitsandbytes (Hugging Face)</a>
</Figure>
 

[**bitsandbytes**](https://github.com/TimDettmers/bitsandbytes)는 University of Washington의 박사과정 Tim Dettmers가 [Facebook AI Research](https://ai.meta.com)(現 Meta AI)와 함께한 연구인 [LLM.int8()](https://arxiv.org/abs/2208.07339)[^6]를 오픈 소스로 공개한 것입니다. 행렬 곱을 연산할 때 각 벡터를 독립적으로 처리하는 Vector-wise Quantization 방법을 적용하고, 중요한 벡터는 16-bit로 표현하여 손실을 최소화하는 등 8-bit와 16-bit를 혼용하는 기법을 통해 모델의 성능은 유지하면서 크기를 줄이는 성과를 보였습니다. Hugging Face의 Transformer 구현체에도 병합이 되었으며, [Llama2](https://github.com/facebookresearch/llama-recipes/blob/cd82118b74d2fd739bd6227af33b661d04a97406/requirements.txt#L6), [QLoRA](https://github.com/artidoro/qlora/blob/6c6fc4653abd17ce550f48878a24c7bd8772e98a/requirements.txt#L1), [KoAlpaca](https://github.com/Beomi/KoAlpaca/blob/4596f882957d286b4d60559b97dcf783822d23f5/webui/requirements.txt#L5), 그리고 [KULLM](https://github.com/nlpai-lab/KULLM/blob/b7a78b62ed6cd9d83c51ad5a92a9dd40b9f35998/requirements.txt#L4) 등의 다양한 모델에서 사용되고 있습니다.

## 원인 파악

문제가 발생하는 지점을 찾아 재현까지 완료하였으니 이제 본격적으로 원인을 파악해야 합니다. 비슷한 사례가 있을지 조사해 봤으나 찾아볼 수 없었습니다. 또한 `cuInit()`은 정상적으로 호출되었기 때문에 더 원인을 파악하기 어려웠습니다.

```python
import ctypes

count = ctypes.c_int()

libcuda = ctypes.CDLL("libcuda.so")
libcuda.cuInit(0) # 0 (CUDA_SUCCESS)
libcuda.cuDeviceGetCount(ctypes.byref(count)) # 304 (CUDA_ERROR_OPERATING_SYSTEM)

libcudart = ctypes.CDLL("libcudart.so")
libcudart.cudaGetDeviceCount(ctypes.byref(count)) # 304 (CUDA_ERROR_OPERATING_SYSTEM)
```

조언을 얻기 위하여 아래와 같이 GitHub 레포지토리에 이슈([TimDettmers/bitsandbytes#264](https://github.com/TimDettmers/bitsandbytes/issues/264))를 등록했고, 패키지를 최신 버전으로 업데이트한 후 다시 시도해 보라는 답을 받을 수 있었습니다. 당시 최신이었던 0.38.0.post1 버전으로 올린 후 다시 테스트했지만 동일한 문제가 발생했습니다. 시간을 너무 지체할 수 없었기 때문에 생각을 전환하여 문제가 되는 부분을 제거하기로 했습니다.

![](https://cdn.lablup.com/axe_c24307c59a.jpeg)
<Figure>
 이미지 출처: 만화로 보는 그리스 로마 신화 (가나출판사)
</Figure>

## 문제 해결

첫 번째 접근은 [CUDA-Python](https://github.com/NVIDIA/cuda-python)[^7]을 사용하는 것이었습니다. CUDA-Python은 NVIDIA에서 공식적으로 배포하는 CUDA Python Low-Level Bindings 패키지입니다. 이전에도 유용하게 사용한 경험이 있어서 바로 떠올릴 수 있었고, 바로 설치 및 테스트를 해보기로 했습니다.

```bash
$ pip install cuda-python
```

```python
from cuda import cuda
from cuda import cudart

cuda.cuInit(0) # (<CUresult.CUDA_SUCCESS: 0>,)
cudart.cudaGetDeviceCount() # (<cudaError_t.cudaSuccess: 0>, 1)
```

다행히 `cudart.cudaGetDeviceCount()`가 정상적으로 동작하였고 곧바로 `bitsandbytes`에 통합하는 테스트를 진행했습니다. 하지만 `cuda.cuInit(0)`를 호출한 후 `torch.cuda.is_available()`을 호출하면 에러가 발생했습니다. `torch.cuda.is_available()` 내부에서 `cudaGetDeviceCount()`를 호출했기 때문입니다.

```python
from cuda import cuda, cudart

cuda.cuInit(0) # <CUresult.CUDA_SUCCESS: 0>,)
cuda.cudaGetDeviceCount() # (<cudaError_t.cudaSuccess: 0>, 1)

import bitsandbytes

# ...
# /opt/conda/lib/python3.8/site-packages/torch/cuda/__init__.py:82: UserWarning: CUDA initialization: Unexpected error from cudaGetDeviceCount(). Did you run some cuda functions before calling NumCudaDevices() that might have already set an error? Error 304: OS call failed or operation not supported on this OS (Triggered internally at /opt/pytorch/pytorch/c10/cuda/CUDAFunctions.cpp:109.)
# return torch._C._cuda_getDeviceCount() > 0
# ...
```

문제는 다시 원점으로 돌아온 것 같았습니다. 숨을 한번 고르고 위의 에러 로그를 차분하게 다시 읽었습니다. 그러자 무언가 눈에 들어왔습니다.

**torch._C._cuda_getDeviceCount() > 0**

`bitsandbytes`는 이미 내부적으로 PyTorch를 사용하고 있었습니다. 즉, PyTorch에 대한 의존성을 가지고 있었습니다. 정확히는 `bitsandbytes`가 [의존성](https://github.com/TimDettmers/bitsandbytes/blob/e229fbce66adde7c2a6bc58cbe7d57c1f4a0ba02/requirements.txt#L1)을 갖는 [lion-pytorch](https://github.com/lucidrains/lion-pytorch)가 PyTorch에 대한 [의존성](https://github.com/lucidrains/lion-pytorch/blob/66295196111875bde30c8060d4f0f76add98377f/setup.py#L19)을 가지고 있었습니다. 그리고 PyTorch에는 이미 [CUDA 함수들](https://github.com/pytorch/pytorch/blob/cce2b7e3c95a7505b41bdfc53939d84d56e31260/torch/_C/__init__.pyi.in#L1529-L1530)에 대한 인터페이스가 존재했습니다. 이번에는 이걸 이용해 보기로 했습니다.

다행히 PyTorch에는 `bitsandbytes`에서 사용하는 CUDA 함수들이 모두 존재했습니다. 기존에 `libcuda.so` 및 `libcudart.so`를 통해 호출되던 함수들을 아래와 같이 변경했습니다.

<table>
 <thead>
 <tr>
 <th>libcuda/libcudart</th>
 <th>torch</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>libcuda.cuDeviceGetCount()</td>
 <td>torch.cuda.device_count()</td>
 </tr>
 <tr>
 <td>libcuda.cuDeviceGet()</td>
 <td>torch.cuda.device()</td>
 </tr>
 <tr>
 <td>libcuda.cuDeviceComputeCapability()</td>
 <td>torch.cuda.get_device_capability()</td>
 </tr>
 <tr>
 <td>libcudart.cudaRuntimeGetVersion()</td>
 <td>torch.version.cuda</td>
 </tr>
 </tbody>
</table>

변경 후 정상적으로 동작하는 것을 확인한 후, 배포 패키지 버전에 적용하기 위하여 GitHub 레포지토리에 PR을 등록했습니다([TimDettmers/bitsandbytes#375](https://github.com/TimDettmers/bitsandbytes/pull/375)).

## 후기

PR을 등록한 지 약 두 달이 지난 2023년 7월 14일, 해당 패치가 main 브랜치에 병합되었고 [0.40.1](https://github.com/TimDettmers/bitsandbytes/blob/main/CHANGELOG.md#0401) 버전에 포함되었습니다.
![](https://cdn.lablup.com/bitsandbytes_changelog_0_40_1_795b090d96.png)

또한 저자인 Tim Dettmers로부터 피드백을 얻을 수 있었습니다. 이 짧은 글에서 저자의 생각과 철학을 느낄 수 있었습니다.
![](https://cdn.lablup.com/timdettmers_approval_9f4db84e13.png)

이번 기회를 통해 LLM의 생태계에 대해서 더 자세하게 알아볼 수 있었습니다. 또한 오랜만에 오픈 소스 활동의 재미를 느낄 수 있는 시간이었습니다. 공간적 제약을 뛰어넘어 협업할 수 있다는 점, 그리고 서로의 생각을 나누며 배워갈 수 있다는 점이 오픈 소스 활동의 매력인 것 같습니다. **Backend.AI**는 엔터프라이즈 버전과 함께 오픈 소스 버전을 운영하고 있습니다. 항상 더 나은 사용자 경험, 그리고 더 나은 개발자 경험을 제공할 수 있도록 노력하겠습니다.

[^1]: NVIDIA GPU Cloud
[^2]: The NGC catalog hosts containers for AI/ML, metaverse, and HPC applications and are performance-optimized, tested, and ready to deploy on GPU-powered on-prem, cloud, and edge systems.
[^3]: [ViperGPT: Visual Inference via Python Execution for Reasoning](https://arxiv.org/abs/2303.08128), March 14, 2023.
[^4]: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#compute-capability
[^5]: https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__DEVICE.html#group__CUDA__DEVICE_1g52b5ce05cb8c5fb6831b2c0ff2887c74
[^6]: [LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale](https://arxiv.org/abs/2208.07339), November 10, 2022.
[^7]: https://developer.nvidia.com/cuda-python

bitsandbytes 이슈 삽질기

이번 포스팅에서는 래블업에서 지난 9개월 동안 개발자로 경험한 이야기를 다뤄보았다.

## Table of Contents

- 지원 동기
- 인턴에서 DevOps로!
- rraft-py 개발
- 오픈소스 컨트리뷰션 아카데미 지역 스프린트 Backend.AI 멘토링
- 다양한 컨퍼런스 참여
- 2023 오픈소스 컨트리뷰션 아카데미
- 파이콘 발표
- 결론

## 지원 동기

개인적으로 래블업에 입사하기 전부터 취미로든, 업무 시간에서든 내가 개발한 프로그램을 통해 다른 사람들에게 도움을 주는 일을 지속적으로 할 수 있는 직업을 갖고 싶다는 생각을 해 왔다.

특히 오픈 소스는 내가 작성한 코드가 다른 사람들에게 도움을 줄 수 있을 뿐 아니라, 원하는 사람이 있다면 코드를 자유롭게 수정하고 활용할 수 있다는 점에서 더욱 더 매력적으로 느껴졌다.

졸업 프로젝트로 Arvis라는 개인 프로젝트를 진행해보고 나서야 깨달은 사실 중 하나는, 프로젝트 규모가 계속 커지면서 단순히 내가 좋아하는 일이라는 이유로 프로젝트를 지속하는 것이 현실적으로 쉽지 않다는 점이었다. 나름대로 초기부터 프로젝트를 신중하게 계획하고 진행해 보았지만, 결론적으로 프로젝트 유지에 필요한 시간과 노력을 간과한 것 같다는 생각이 들었다.

그런 점에서 오픈 소스 관련 활동들을 적극적으로 권장하고 지원해주며, 심지어 소스 코드의 핵심 부분을 오픈 소스로 개발하는 래블업은 내가 꿈꾸던 회사였다.

## 인턴에서 DevOps로!

[필자의 래블업 OSSCA 인턴십](https://jopemachine.github.io/2023/01/02/2022-Ossca-Lablup-Internship/)에서 마지막 3주차 동안 했었던 일은 분산 시스템 관련된 공부 및 조사였다. 특히 Raft 알고리즘 구현에 관련된 내용이 대부분이었다. 직무 이름은 인턴에서 DevOps로 변경되었지만 [인턴십에서 맡았던 이슈](https://github.com/lablup/backend.ai/issues/415)를 해결하기 위해 계속 Raft 등 인턴십 때 공부했던 내용들을 확장한다는 느낌으로 진행하게 되었다.

물론 이외에도 아래에서 언급할 다양한 활동 들에도 참여했지만, 현재까지 회사에서한 작업들 중 가장 주된 작업은 rraft-py 작성 등 기존 분산 락으로 작성되어 있는 구조를 대체하기 위해 Raft 알고리즘 구현체의 파이썬 바인딩을 작성하고, Backend.AI와 어떻게 통합시킬 수 있을지에 대해 고민하는 것이었다.

## [rraft-py](https://github.com/lablup/rraft-py) 개발

rraft-py는 `tikv/raft-rs`의 파이썬 바인딩 구현체로, 이에 대한 자세한 내용은 [GitHub Readme](https://github.com/lablup/rraft-py) / [Wiki](https://github.com/lablup/rraft-py/wiki)를 참고하면 된다. 또한 다음 달 2023 파이콘 KR 발표에서 해당 주제의 기술적인 세부사항들을 발표할 예정이므로 관심이 있다면 참고하면 좋을 것 같다.

여기선 rraft-py를 개발하면서 배운 기술적인 내용들은 일단 차치하고 **Lablup 개발자로서의 경험**에 초점을 맞춰 보려고 한다.

rraft-py는 단순히 Backend.AI의 한 이슈를 해결하는 것 뿐 아니라, 별개의 프로젝트를 만들고 그 프로젝트를 Backend.AI와 통합시키기 위한 프로젝트까지 진행해야 했기 때문에 많은 고민을 하며 진행했다.

전체적으로 프로젝트에 몇 가지 마일 스톤들이 있었는데 매 마일 스톤을 통과할 때 마다 좀 더 안정된 느낌으로 프로젝트를 진행할 수 있었던 것 같다. 분명히 매번 높은 성취감이 있었지만 나중에 가서야 처음 작성했던 코드가 의도한 대로 돌지 않는다는 것을 확인하고 좌절할 때도 많았다. 하지만 래블업에서 이런 삽질들을 할 수 있는 시간을 허용해줬고, 이전에 그냥 "삽질이었네" 하고 치부하고 넘어가면서 배운 것들을 통해 비로소 지금까지 올 수 있었다고 생각한다.

 ![](https://cdn.lablup.com/2023_07_18_2_0fedfd92cb.png)
rraft-py 예제 코드 실행 결과

rraft-py를 Backend.AI에 통합하기 위해선 아직도 가야할 길이 더 남아 있지만, 결론적으로 느낀 것은 스스로 생각하고 판단하면서 프로젝트를 계속 고도화 시켜보는 경험을 할 수 있어서 좋았고, 이런 부류의 경험을 좋아하는 개발자들에게 래블업은 최고의 선택지 중 하나가 될 수 있을 것이라는 점이다.

## [오픈소스 컨트리뷰션 아카데미 지역 스프린트](https://www.oss.kr/notice/show/3d3945b6-d23e-4e42-94aa-d6d0243b60d8) Backend.AI 멘토링

예상했던 것 보다 많은 시간을 요구했기 때문에 rraft-py 개발을 가장 메인으로 진행했지만, 이것 외에도 다양한 성격의 업무를 진행해 볼 수 있는 기회가 있었다.

그 중 가장 인상 깊었던 업무중 하나가 바로 제 1회 대구 오픈 소스 컨트리뷰션 아카데미 지역 스프린트에 Backend.AI 멘토로 참여해 본 경험이었다.

사실 Backend.AI에 대한 깊은 이해 없이 멘토로 참여하게 되었는데, 설상가상으로 스프린트 기간도 고작 2일 밖에 주어지지 않아 여러모로 많은 걱정을 갖고 참여했었다.

멘티 분들이 하나라도 배우고 최대한 만족하고 돌아 가실 수 있도록 하기 위해 Backend.AI를 전혀 모르는 분들에게 어떤 식으로 설명 해 드릴지, 다른 플랫폼에서 어떻게 개발 환경을 구축해야 하는지 등 (개인적으로 평소엔 macOS + docker desktop 환경에서만 개발했었는데, 멘티 분들은 Windows 환경에서 진행하시는 분도 있으셔서 개발 환경 구축하는 과정에서 삽질 하기도 했다.) 여러 가지들을 생각해보고 준비해보아야 했다.

결론적으로 이런 과정들에 익숙하지 못했던 내가 오히려 더 많은 것들을 배울 수 있었고, 멘티 분들도 생각보다 워낙 잘 따라와 주셔서 다들 한 개 이상씩 PR들을 만드실 수 있었던 뜻 깊은 시간이 된 것 같아 좋았다.

 ![](https://cdn.lablup.com/2023_07_18_3_2a66168649.jpg) 
 제 1회 대구 오픈 소스 컨트리뷰션 아카데미 지역 스프린트


## 다양한 컨퍼런스 참여

AI Expo, AWS Summit, Next Rise 등 아래와 같은 다양한 컨퍼런스, 전시회들에 부스로 참여해 볼 수 있었다. 이런 곳들에 참여하면서 Backend.AI를 여러 부류의 사람들에게 설명하는 법을 배울 수 있었던 것도 좋았고, 다른 회사들의 다앙한 기술들을 직접 접할 수 있었던 점도 매력적이었다.

 ![](https://cdn.lablup.com/2023_07_18_1_9b6f10270a.jpg) 

 AI EXPO KOREA 2023


## [2023 오픈소스 컨트리뷰션 아카데미](https://www.contribution.ac/2023-ossca)

래블업은 오픈 소스 문화를 지향하는 회사 답게 매년 오픈소스 컨트리뷰션 아카데미에 적극적으로 참여하고 있다. 올해에도 오픈소스 컨트리뷰션 아카데미에 참여했는데, Backend.AI 팀 외에도 다른 다양한 프로젝트들에 참여할 수 있게 장려하고 있어서 필자는 GlueSQL 멘티로 참여해 진행해 보고 있다.

이런 자유로운 문화는 성장하고 싶어 하는 욕구가 강한 개발자들에게 상당히 매력적인 포인트가 될 것이라 생각한다.

(필자 외에도 2023 컨트리뷰션 아카데미 다른 프로젝트들에 두 명이나 더 참여하고 있다.)

## 파이콘 발표

회사에서의 rraft-py 개발 경험을 토대로 [2023 파이콘 KR](https://2023.pycon.kr/session)에서 발표해 볼 수 있는 기회를 얻을 수도 있었다.

개인적으로 대외 발표가 처음이라서 다소 얼떨떨한 느낌이지만 나름대로 최선을 다해 준비해보고 있다. 발표에 관심을 가지는 분들에게 발표 자료 뿐만 아니라 GitHub을 통해 소스 코드나 작업 내역까지 모두 공유할 수 있다는 점이 기대된다.

## 결론

래블업은 오픈 소스 문화를 지향하는 회사로, [오픈 소스 컨트리뷰션 아카데미](https://www.oss.kr/contribution_academy)나 파이콘 등 다양한 오픈 소스, 커뮤니티 관련 행사들에 참여할 수 있도록 장려하며 개발자에게 주도적으로 작업을 진행해 보게 하는 기회를 제공한다.

래블업에서 앞으로 더 꾸준히 다양한 성격의 오픈 소스 활동들에 참여하고, 배우고 성장하며, 기여해보고 싶다.

2023 Lablup DevOps Summer 회고

서상현

# 역사에서 배우기

최근 반년 사이 급속하게 세간의 화제가 된 ChatGPT를 비롯한 거대 언어 모델들은 사실 어느날 갑자기 하늘에서 뚝 떨어진 것이 아닙니다. 차곡차곡 누적된 기술의 발전이 어떤 변곡점에 도달하면서 급속하게 사회를 변화시키는 것은 역사적으로 많이 봐왔던 일이죠. 전혀 다른 시대와 다른 맥락에서 발전한 기술들이 그러한 변곡점에 도달하는 과정은 때로는 놀랍도록 유사한 모습을 보여주기도 합니다.

---

인류는 오랫동안 하늘을 날고 싶어했습니다. 문명 6이 "하늘을 나는 꿈"을 주제가로 삼은 것은 우연이 아닙니다.

라이트 형제는 어떻게 이 꿈을 이루게 되었을까요? 1899년 윌버 라이트는 스미스소니언 재단에 편지를 보내 비행기에 대해 알려진 내용을 보내달라고 요청합니다. 세 달간 전달받은 자료를 검토한 윌버는 비행이라는 문제가 있을 뿐이지 비행에 대해 알려진 것은 별로 없다는 결론을 내립니다. 그럴싸한 이론이 거짓으로 밝혀지고 그럴 법하지 않은 이론이 참으로 밝혀졌기 때문에, 직접 확인하지 않은 내용은 믿을 수 없다고 그는 적었습니다.

문헌 조사에서 윌버가 알고자 한 것은 이러한 것이었습니다. 하늘을 날기 위해서는 무엇을 알아야 하는가? 그 중 무엇이 이미 알려져 있는가? 풀어야할 남은 문제는 무엇인가? 놀랍게도 윌버는 문헌 조사로부터 이 모든 질문에 대한 답을 내릴 수 있었는데, 그것은 다른 경쟁자들은 하지 못한 일이었습니다.

윌버는 1901년의 강연에서 자신의 결론을 이렇게 정리했습니다. "비행에는 세 가지 문제가 있습니다. 비행기가 뜨기 위해 날개가 필요하고, 비행기가 나아가기 위해 엔진이 필요하며, 비행기를 조종할 방법이 필요합니다."[^1]

[^1]: [Some Aeronautical Experiments](https://www.wright-brothers.org/History_Wing/Wright_Story/Inventing_the_Airplane/Kitty_Hawk_in_a_Box/Some-Aeronuatical-Experiments-by-Wilbur-Wright.htm) (Wilbur Wright, 1901).

윌버는 날개의 문제와 엔진의 문제는 어느정도 이미 해결되었기 때문에, 조종의 문제를 풀어야 한다고 보았습니다. 비행기 조종의 문제를 풀기 위해서는 비행기가 필요했는데, 비행기를 만들기 위해서는 비행기 조종의 문제를 풀어야 하는 상황이었습니다. 윌버는 글라이더에서 조종의 문제를 품으로써 비행기 조종의 문제를 풀 수 있다는 결론을 내렸습니다.

글라이더 실험을 위해서는 높은 언덕과 강한 바람이 필요했으며, 실험자의 안전을 위해 모래 언덕이어야 했습니다. 1900년 윌버는 기상청에 자료를 요청해 미국에서 가장 바람이 센 곳들을 검토했습니다. 키티 호크 기상대의 직원은 기상대 옆 해변에 장애물이 없으며 실험에 적합할 것이라는 답장을 보내왔습니다.[^2]

[^2]: [Letter from J. J. Dosher, Weather Bureau, to Wilbur Wright](https://www.weather.gov/mhx/FirstFlight), August 16, 1900.

1901년의 실험은 실망스러웠습니다. 날개의 양력이 충분하지 않았던 것입니다. 라이트 형제는 날개의 면적을 계산하기 위해 오토 릴리엔탈의 데이터를 사용했는데, 그 정확도에 의심을 가지게 되었습니다.

실험 데이터를 분석한 결과, 그들은 오토 릴리엔탈을 포함하여 100년 넘게 의심 없이 사용되어 왔던 존 스미턴의 비례 상수 값이 잘못되었다는 결론을 내렸습니다.

많은 시간과 노력이 소모되는 글라이더 실험을 하지 않고 날개의 양력을 체계적으로 분석하기 위해, 라이트 형제는 풍동 실험 장치를 만들었습니다. 분석 결과, 오토 릴리엔탈의 데이터는 잘못된 비례 상수 값을 제외하면 정확했지만, 오토 릴리엔탈이 사용한 날개는 비효율적이었습니다.

이러한 분석을 바탕으로 만들어진 1902년의 글라이더는 수정된 스미턴 상수의 값을 상쇄하기 위해 면적이 더 넓어졌으며 효율을 높이기 위해 모양이 더 평평해졌습니다. (날개의 편평도를 1/12에서 1/24로 바꾸었습니다.) 새 글라이더는 아주 잘 날았습니다.

이리하여 라이트 형제는 1903년 키티 호크에서 역사적인 첫 비행을 성공시킬 수 있었던 것입니다.

![](https://cdn.lablup.com/first_flight_2aff237efc.jpg)

---

인류는 오랫동안 기계와 대화하고 싶어했습니다. 수많은 과학 소설과 영화들이 증거하고 있습니다.

OpenAI는 AI를 만들기 위해 세 가지 문제를 풀어야 했습니다. 컴퓨팅 인프라와 모델과 데이터입니다. 컴퓨팅 인프라가 엔진에, 모델이 날개에, 데이터가 조종에 대응한다고 볼 수 있습니다.

컴퓨팅 인프라를 관리하기 위해 OpenAI는 Kubernetes를 사용했는데, 그렇다고 그냥 가져다 쓸 수 있는 것은 아니었습니다. 2,500 노드가 되자 리눅스 커널 ARP 캐시가 넘치는 문제가 생겼고,[^3] 7,500 노드가 되자 anti-affinity를 사용하기 위해 Kubernetes의 버그를 고쳐야 했습니다.[^4]

[^3]: [Scaling Kubernetes to 2,500 nodes](https://openai.com/research/scaling-kubernetes-to-2500-nodes), January 18, 2018.

[^4]: [Scaling Kubernetes to 7,500 nodes](https://openai.com/research/scaling-kubernetes-to-7500-nodes), January 25, 2021.

(광고: 래블업의 Backend.AI는 AI의 훈련과 추론을 위한 대규모 클러스터들에 이미 실제로 사용되어 여러가지 스케일링 문제들을 풀었고, 자체 스케줄링 알고리즘을 구현하여 affinity나 anti-affinity 등의 기능을 지원하고 있습니다.)

비행기의 양력 방정식에 해당하는 것이 AI의 scaling law입니다. 양력 방정식이 날개의 양력을 날개의 면적과 양력 계수, 비례 상수로 설명하는 것처럼, scaling law는 AI 모델의 loss를 모델의 크기와 데이터의 크기, 멱함수 지수로 설명합니다.

라이트 형제가 존 스미턴의 비례 상수가 0.005가 아니라 0.003이라는 것을 발견한 것처럼, scaling law의 멱함수 지수는 처음에는 0.73인 것으로 생각되었지만[^5] 실제로는 0.50인 것으로 밝혀졌습니다.[^6] 잘못된 값이 계산된 것은 데이터의 크기에 따라 learning rate를 조정하지 않았기 때문입니다.

[^5]: [Scaling Laws for Neural Language Models](https://arxiv.org/abs/2001.08361), January 23, 2020.

[^6]: [Training Compute-Optimal Large Language Models](https://arxiv.org/abs/2203.15556), March 29, 2022.

OpenAI는 모델의 제어가 중요한 문제라는 것을 알고 있었기 때문에, 첫 번째 GPT를 훈련하기 전에 이미 사람의 선호로부터 강화 학습을 하는 연구를 진행하고 있었습니다.[^7] 이때는 로봇의 제어에 적용했는데, 라이트 형제가 비행기의 조종을 위해 새의 비행을 참고하고 비행기 대신 글라이더에 먼저 적용한 것을 연상시킵니다.

[^7]: [Deep reinforcement learning from human preferences](https://arxiv.org/abs/1706.03741), June 12, 2017.

이러한 연구를 언어 모델에 적용하기 위해 사람의 선호 데이터를 수집하여 InstructGPT가 나왔습니다.[^8] GPT-4 이후로 OpenAI가 연구 내용을 공개하고 있지 않기 때문에 정확히 알기는 어렵지만, 명시적인 피드백이 아니라 사용자가 생성을 재시도하거나 대화를 계속하고 중단하는 등의 암시적인 피드백으로부터도 학습할 수 있다는 연구 결과들이 나오고 있습니다.[^9] 그렇다면 OpenAI는 모델을 향상시켜 사용자를 모으고 사용자를 모아 모델을 향상시키는 양성 되먹임 고리를 만들어낼 수 있을 것입니다.

[^8]: [Training language models to follow instructions with human feedback](https://arxiv.org/abs/2203.02155), March 4, 2022.

[^9]: [Rewarding Chatbots for Real-World Engagement with Millions of Users](https://arxiv.org/abs/2303.06135), March 10, 2023.

---

이번 글에서는 인류가 하늘을 날게 된 과정과 기계와 대화하게 된 과정을 비교하여 살펴보았습니다. 기술 발전 과정을 보면 이렇게 역사적으로 매우 유사한 패턴들을 볼 수 있지요.

앞으로 AI 기술이 발전하고, 이를 보다 많은 사람들이 사용할 수 있게 하는 노력 속에서 또 어떤 사례들이 나올까요? 래블업과 Backend.AI는 그러한 과정을 더욱 가속화하여 사람들이 역사로부터 배운 것을 보다 빨리 실험하고 실현할 수 있게 도울 수 있을까요? 이러한 변곡점의 한 가운데에서 생각에 잠겨봅니다.


역사에서 배우기

Backend.AI 23.03 및 22.09의 지속적 업데이트 내용을 정리합니다. 개발팀은 최선을 다해 마지막 비트까지 짜내기 위해 노력하고 있습니다.

이번 업데이트에서 가장 중요한 변경사항은 다음과 같습니다:

- 하드웨어 호환성 확장: [리벨리온(Rebeillons) 사](https://rebellions.ai/)의 ATOM 가속기 유휴 상태 검사 및 Dell EMC 스토리지 백엔드를 지원하여 하드웨어 호환성을 확장했습니다.
- 고속 업로드 강화: SFTP 기능을 도입하여 스토리지로의 고속 업로드를 지원합니다.
- 개발환경 향상: 로컬 Visual Studio Code에서 원격 SSH 모드로 세션을 접속할 수 있도록 하여 개발환경을 향상했습니다.
- 관리 용이성 증가: 관리자용 사용자 인터페이스 개선으로 AI 가속기 설정 및 자원 그룹 관리 용이성을 높였습니다.


### Backend.AI Core & UI
* ATOM 가속기의 유휴 상태 검사를 지원하도록 추가하였습니다.
* 스토리지로 직접 고속 업로드를 지원하는 SFTP 기능을 도입하였습니다.
* 관리자 설정에 따라 주기적으로 비밀번호 업데이트를 강제 실행하는 기능을 추가하였습니다.
* 업로드 전용 세션(SYSTEM) 탭을 추가하였습니다.
* 허용되는 세션 타입에 Inference 타입을 추가하였습니다.
* 로컬 Visual Studio Code에서 원격 SSH 모드로 세션 접속 기능을 추가하였습니다.
* 폴더 탐색기에서 폴더 업로드를 지원하도록 하였습니다.
* 세션 생성시 할당된 공유자원(shared memory)양을 표시하도록 개선하였습니다.
* Dell EMC 스토리지 백엔드 지원을 추가하였습니다.
* 컨테이너 메모리 사용량 측정의 정확도를 개선하였습니다.
* 하나의 연산 노드에서 여러 개의 agent를 동시 실행할 수 있도록 개선하였습니다.
* 관리자용으로 프로젝트/자원 그룹명 필터를 추가하였습니다.
* 관리자용으로 GPU를 포함한 다양한 AI 가속기를 자원 프리셋/정책에서 설정할 수 있도록 사용자 인터페이스를 추가하였습니다.
* 관리자용으로 GPU를 포함한 다양한 가속기의 할당과 현재 사용량을 표시하는 인터페이스를 제공하였습니다.
* 관리자용으로 자원 그룹의 공개 여부를 설정할 수 있는 사용자 인터페이스를 제공하였습니다.
* 관리자용으로 세션 별 idle-checks 값 확인할 수 있는 사용자 인터페이스를 제공하였습니다.
* CLI에서 vfolder 업로드 시 재귀 옵션을 추가하였고, 상대 경로 처리를 개선하였습니다.
* CLI에서 특정 세션 종료 시 의존성이 걸려있는 세션을 한번에 종료할 수 있는 재귀 옵션을 추가하였습니다.
* 개발자용으로 기존의 cuda-mock 플러그인을 대체하는 새로운 mock-accelerator 플러그인을 추가하였습니다.
* 개발자용으로 스토리지 프록시의 내부 모니터링을 위한 상태 및 통계 확인 API를 추가하였습니다.

### Backend.AI FastTrack
* 파이프라인 모듈 추가 시 vfolder를 이름으로 검색할 수 있도록 개선하였습니다.
* 파이프라인 실행 후 성공/실패를 쉽게 알 수 있도록 표시를 추가하였습니다.

### Backend.AI Forklift
* 버그 수정 및 안정성을 개선하였습니다.
* 빌드 작업 내역 삭제 기능을 지원합니다.
* 빌드 작업 목록의 pagination을 지원합니다.

Backend.AI 는 하루가 다르게 변하는 AI 생태계에서 다양한 환경을 지원함과 동시에 더욱 강력하고 사용자 친화적인 환경을 제공하고자 끊임없이 발전하고 있습니다. 앞으로의 행보에도 많은 기대 부탁드립니다! 
Make your AI accessible with Backend.AI!

23.03: 2023년 5월 업데이트

# 들어가며

초거대 AI 모델들이 시장에 홍수처럼 쏟아지면서 모델을 개발하는 것 뿐만 아니라 어떻게 사용자에게 "잘", "효율적으로" 제공할 것이냐에 대한 고민이 늘어가고 있습니다.
거대 언어 모델 (Large Language Model, LLM) 이전의 AI 모델의 컴퓨팅 역량은 추론보다는 학습에 집중되었습니다. 학습이 완료된 모델으로 추론을 시도하기 위한 하드웨어 요구사항이 모델을 학습하는 데에 필요한 컴퓨팅 파워보다 월등히 작았기 때문입니다. 모델의 배포자는 실 사용자의 엔드 디바이스 (가령 스마트폰과 같은) 의 NPU 만으로도 추론을 위한 충분한 성능을 확보할 수 있었습니다. 그러나 LLM이 나타나며 상황이 역전되었습니다.

![](https://cdn.lablup.com/4_c3523b4fd6.png) 

Meta의 [OPT 175b](https://github.com/facebookresearch/metaseq) 를 예로 들어보겠습니다. OPT-175b는 이름에서 유추할 수 있듯 1750억 개의 파라미터를 보유하고 있으며, 추론 작업을 시행하기 위해 이를 GPU에 적재하는 데에만 대략 320GB 이상의 GPU 메모리를 필요로 합니다. LLM 이전에 유행했던 이미지 처리 계통의 모델들의 최대 요구치였던 4GB에 비하면 엄청나게 큰 차이입니다.  
AI 모델의 행태가 이렇게 변화하다 보니, 서비스 자원을 효율적으로 관리하는 것이 안정적으로 서비스를 운영하는 데에 무엇보다도 중요하게 작용하기 시작했습니다. 이번 글에서는 곧 출시될 Backend.AI의 모델 서비스 기능인 Backend.AI Model Service를 미리 살펴보며, Backend.AI를 이용하면 어떻게 AI 모델 훈련부터 서빙까지 하나의 인프라로 효율적으로 운용할 수 있을지에 대해 살펴보겠습니다.

# Backend.AI Model Service

![](https://cdn.lablup.com/Model_Service_Architecture_2a72d506ea.png) 
Backend.AI Model Service는 기존의 Backend.AI 솔루션 위에서 동작하는 모델 서빙 시스템입니다. 이미 많은 사례를 통해 안정성을 인정받은 Backend.AI의 컨테이너 관리 기술과 컨테이너 앱 제공 시스템인 AppProxy[^1]를 한 단계 더 고도화 하여, 추가적인 컴포넌트 설치 없이 기존의 Backend.AI 인프라 업그레이드만으로 하나의 인프라에서 AI 훈련과 모델 서비스를 모두 가능하게 합니다. 세션 별 GPU 사용량, API 호출 횟수 혹은 시간대 등에 따라서 자동으로 추론 세션의 규모를 확장 및 축소하는 오토 스케일링 기능 또한 지원하여 추론에 사용되는 AI 자원을 효과적으로 관리할 수 있습니다.

# 추론 세션

![](https://cdn.lablup.com/Inference_Sessions_b5e36f4c15.png) 

Backend.AI에서의 추론 세션은 기존의 훈련 세션과 개념적으로 동일합니다. 기존에 훈련을 위해 사용하던 실행 환경을 그대로 추론 세션에서 사용할 수도 있고, 추론 세션만을 위한 전용의 실행 환경을 배포할 수도 있습니다. 추론 세션은 휘발성이며 Stateless 하므로 세션의 상태가 좋지 않을 경우 언제든지 종료할 수 있습니다. 이 경우 Backend.AI에서는 새로운 추론 세션을 생성함으로써 원래의 상태를 복구하려고 시도함과 동시에 추론 요청을 다른 살아있는 추론 세션에게 전달하여서 추론 서비스의 Downtime을 최소화합니다.

# 모델 스토리지

Backend.AI를 통해 서비스를 제공할 모델들은 "모델 스토리지" 단위로 관리됩니다. 모델 스토리지는 모델 파일과 모델 서비스를 위한 코드, 그리고 모델 정의 파일로 이루어져 있습니다.

## 모델 정의 파일

모델 정의 파일은 서비스 제공자의 모델을 Backend.AI Model Service에서 실행하기 위한 정보를 정의하는 공간입니다. 모델 정의 파일에는 모델의 정보, 모델 서비스가 노출하는 포트, 모델 서비스를 실행하기 위해 실행해야 하는 일련의 작업들이 포함됩니다. 모델 서비스에서 자신의 상태를 보고하는 Health Check 기능을 제공할 경우, 해당 정보를 이용하여 불량 상태인 세션의 경우 서비스에서 제외하는 등의 조치가 가능합니다.

```yaml
models:
  - name: "KoAlpaca-5.8B-model"
    model_path: "/models/KoAlpaca-5.8B"
    service:
      pre_start_actions:
        - action: run_command
          args:
            command: ["pip3", "install", "-r", "/models/requirements.txt"]
      start_command:
        - uvicorn
        - --app-dir
        - /models
        - chatbot-api:app
        - --port
        - "8000"
        - --host
        - "0.0.0.0"
      port: 8000
      health_check:
        path: /health
        max_retries: 10
```

다음은 잘 정의된 모델 정의 파일의 예시입니다. 이 예시는 [KoAlpaca 5.8B 모델](https://huggingface.co/beomi/KoAlpaca-Polyglot-5.8B/) 을 모델 서비스로 실행하기 위한 일련의 과정을 담고 있습니다.

# 튜토리얼: Backend.AI Model Service를 통해 모델 서비스 해 보기

실제로 Backend.AI를 이용하여 이번 튜토리얼에서는 8bit로 양자화 된 [KoAlpaca 5.8B 모델](https://huggingface.co/beomi/KoAlpaca-Polyglot-5.8B/) 을 서비스 하는 과정을 따라가 보겠습니다.

## API 서버 코드 작성

모델을 제공하기 위한 간단한 API 서버를 작성합니다.


```python
import os
from typing import Any, List

from fastapi import FastAPI, Response
from fastapi.responses import RedirectResponse, StreamingResponse, JSONResponse
from fastapi.staticfiles import StaticFiles
import numpy as np
from pydantic import BaseModel
import torch
from transformers import pipeline, AutoModelForCausalLM
import uvicorn

URL = "localhost:8000"
KOALPACA_MODEL = os.environ["BACKEND_MODEL_PATH"]

torch.set_printoptions(precision=6)

app = FastAPI()

model = AutoModelForCausalLM.from_pretrained(
    KOALPACA_MODEL,
    device_map="auto",
    load_in_8bit=True,
)


pipe = pipeline(
    "text-generation",
    model=model,
    tokenizer=KOALPACA_MODEL,
)


class Message(BaseModel):
    role: str
    content: str


class ChatRequest(BaseModel):
    messages: List[Message]


BASE_CONTEXTS = [
    Message(role="맥락", content="KoAlpaca(코알파카)는 EleutherAI에서 개발한 Polyglot-ko 라는 한국어 모델을 기반으로, 자연어 처리 연구자 Beomi가 개발한 모델입니다."),
    Message(role="맥락", content="ChatKoAlpaca(챗코알파카)는 KoAlpaca를 채팅형으로 만든 것입니다."),
    Message(role="명령어", content="친절한 AI 챗봇인 ChatKoAlpaca 로서 답변을 합니다."),
    Message(role="명령어", content="인사에는 짧고 간단한 친절한 인사로 답하고, 아래 대화에 간단하고 짧게 답해주세요."),
]


def preprocess_messages(messages: List[Message]) -> List[Message]:
    ...


def flatten_messages(messages: List[Message]) -> str:
    ...


def postprocess(answer: List[Any]) -> str:
    ...


@app.post("/api/chat")
async def chat(req: ChatRequest) -> StreamingResponse:
    messages = preprocess_messages(req.messages)
    conversation_history = flatten_messages(messages)
    ans = pipe(
        conversation_history,
        do_sample=True,
        max_new_tokens=512,
        temperature=0.7,
        top_p=0.9,
        return_full_text=False,
        eos_token_id=2,
    )
    msg = postprocess(ans)

    async def iterator():
        yield msg.strip().encode("utf-8")

    return StreamingResponse(iterator())


@app.get("/health")
async def health() -> Response:
    return JSONResponse(content={"healthy": True})


@app.exception_handler(404)
async def custom_404_handler(_, __):
    return RedirectResponse("/404.html")


app.mount(
    "/",
    StaticFiles(directory=os.path.join(KOALPACA_MODEL, "..", "chatbot-ui"), html=True),
    name="html",
)
```

## 모델 정의 파일 작성

API 서버에 맞추어 모델 정의 파일을 작성합니다.
```yaml
models:
  - name: "KoAlpaca-5.8B-model"
    model_path: "/models/KoAlpaca-Ployglot-5.8B"
    service:
      pre_start_actions:
        - action: run_command
          args:
            command: ["pip3", "install", "-r", "/models/requirements.txt"]
      start_command:
        - uvicorn
        - --app-dir
        - /models
        - chatbot-api:app
        - --port
        - "8000"
        - --host
        - "0.0.0.0"
      port: 8000
      health_check:
        path: /health
        max_retries: 10
```

> 모델 서비스의 세션에서 모델 스토리지는 항상 `/models` 경로 아래에 탑재됩니다.

## 모델 스토리지 준비

![](https://cdn.lablup.com/Model_Storage_0d407ef5ac.png) 

작성한 모델 API 서버 코드와 모델 정의 파일, 그리고 KoAlpaca 모델을 모델 스토리지에 추가합니다.

## 모델 서비스 생성


![](https://cdn.lablup.com/New_Model_Service_7d395df4c7.png) 

모델 파일과 모델 정의 파일이 모두 준비가 되었다면 이제 Backend.AI Model Service를 시작할 수 있습니다. Model Service는 Backend.AI CLI의 `backend.ai service create` 명령을 통해 생성이 가능합니다. `service create` 가 허용하는 인자들은 `backend.ai session create` 명령과 거의 동일합니다. 사용할 이미지 뒤에는 모델 스토리지의 ID와 초기에 생성할 추론 세션의 갯수를 전달해 줍니다.

![](https://cdn.lablup.com/Model_Service_Status_03d7db4b4c.png) 

`backend.ai service info` 를 이용하면 모델 서비스 및 서비스에 속한 추론 세션 상태를 확인할 수 있습니다. 1개의 추론 세션이 잘 생성되었음을 알 수 있습니다.

## 추론 API 사용

![](https://cdn.lablup.com/Inference_API_39bb05ce77.png) 

`backend.ai service get-endpoint` 명령을 이용하면 생성된 모델 서비스의 추론 엔드포인트를 확인할 수 있습니다. 추론 엔드포인트는 하나의 모델 서비스가 생성되고 제거되기 전까지 계속 고유한 값을 가집니다. 하나의 모델 서비스에 여러 개의 추론 세션이 속해 있을 경우 AppProxy는 여러 추론 세션에 요청을 분산합니다.

## 추론 API 접근 제한

![](https://cdn.lablup.com/API_Token_151e1468c1.png) 

추론 API에 접근 가능한 사용자를 제한하고자 하는 경우, `--public` 옵션을 제거한 채로 모델 서비스를 시작하면 추론 API에 인증 기능을 활성화할 수 있습니다. 인증 토큰은 `backend.ai service generate-token` 명령으로 발급할 수 있습니다.

## 추론 세션 스케일링


![](https://cdn.lablup.com/Model_Serivce_Scaling_dda4ec0eb5.png) 

`backend.ai service scale` 명령을 이용하면 모델 서비스에 속한 추론 세션의 규모를 변경할 수 있습니다.

# 마치며

지금까지 Backend.AI Model Service와 Model Service 기능을 통해 실제로 모델 서비스를 배포하는 법에 대해 알아보았습니다. Backend.AI Model Service는 Backend.AI 23.03 버전에 정식 배포를 목표로 하고 있습니다. 빠른 시일 내에 Model Service 기능을 정식으로 선보일 수 있도록 노력하고 있으니 많은 기대 부탁드립니다.

---

[^1]: Backend.AI Enterprise 부터 사용 가능.


Sneak Peek: Backend.AI Model Service 미리 보기

# 23.03: 2023년 3월 업데이트

2023년을 맞이하여 [Backend.AI](https://backend.ai)의 첫 major 릴리즈인 23.03.0 버전이 발표되었습니다.
일부 기능은 후속 업데이트로 지속해서 선보일 예정입니다.

특히 이번 업데이트에서는:
- 새로운 연산 세션 유형으로 '추론(inference)' 서비스를 지원합니다.
- 새로운 스토리지 폴더 유형으로 '모델(model)' 관리를 지원합니다.
- 사용자 및 프로젝트 단위의 스토리지 용량 관리를 지원합니다.
- FastTrack의 파이프라인 버전 관리 및 UI가 크게 개선되었습니다.

## Backend.AI Core & UI (23.03)
* 모델 관리 및 추론 세션 관리 기능을 추가하였습니다.
  - 보다 고도화된 추론 엔드포인트 관리 및 네트워크 라우팅 계층은 후속 업데이트로 추가될 예정입니다.
* 코드베이스가 Python 3.11 기반으로 업데이트되었습니다.
* 프론트엔드에 React 구성요소들을 도입하고 Relay를 활용하여 보다 빠르고 반응성 높은 UI를 소개할 수 있는 기반을 준비하였습니다.
* 설치 환경으로 Ubuntu 22.04부터 기본으로 사용하는 cgroup v2를 정식 지원합니다.
* 사용자 및 프로젝트 단위의 스토리지 용량 관리를 위해 vfolder 구조를 v3로 업데이트하였습니다.
* 커널과 세션을 이제 별도의 데이터베이스 테이블로 다루고, 상태 전이 추적 과정이 전반적으로 더 적은 데이터베이스 부하로 작동하도록 개선하였습니다.
* 세션 실행 시 에이전트가 이미지 다운로드하는 과정의 진행상황을 표시하도록 개선하였습니다.
* CUDA 11.7 이상 환경에서 컨테이너별 GPU 사용량 표시를 개선하였습니다.
* 각 리소스그룹 내에서 사용자 및 프로젝트별로 스케줄링 우선순위(priority)를 지정할 수 있습니다.
* 사용자 계정 보호를 위해 일회용 비밀번호(TOTP) 기반 2FA (이중인증, two-factor authentication) 로그인을 지원합니다.
 ![](https://cdn.lablup.com/5_ec31924326.png) 
* 사용자가 직접 SSH keypair를 등록해 세션 접속이 가능하도록 지원합니다.
* Graphcore IPU 와 Rebellions ATOM 장치에 대응하는 사용자 인터페이스를 지원합니다.

## Backend.AI Forklift (23.03)
* Dockerfile 템플릿 및 고급 편집 기능을 추가하였습니다.
* 추론용 컨테이너 이미지 작성을 지원합니다.
* Harbor 레지스트리와 연동할 수 있도록 이미지 관리 기능을 확장하였습니다.

## Backend.AI FastTrack (23.03)
* FastTrack UI 상에서 스토리지 폴더 내용을 바로 확인할 수 있습니다.
* Core와의 세션 상태 동기화 방식을 이벤트 기반으로 개선하였습니다.
* 파이프라인 스케줄의 최대 반복 횟수를 설정할 수 있습니다.
* Task 실행에 실패할 경우 파이프라인 job이 대기하지 않고 자동으로 취소됩니다.
* 파이프라인 버전 관리가 추가되었습니다. 파이프라인의 형상 이력을 추적할 수 있으며, 특정 시점의 내용을 불러와 이어서 작업을 진행할 수 있습니다.
* 코드 에디터를 통해 YAML 형태의 파이프라인을 직접 수정할 수 있습니다.

## 개발 및 연구 프레임워크 지원
* TensorFlow 2.12, PyTorch 1.13 지원
* NGC (NVIDIA GPU Cloud) TensorFlow 22.12 (tf2), NGC PyTorch 22.12, NGC Triton 22.08 지원
* Google Colab과 동일한 라이브러리 및 패키지들을 제공하는 python-ff:23.01 이미지 추가

위에 나열한 것 외에도 많은 버그 수정과 내부적인 개선 사항들이 포함되어 있습니다.  
앞으로도 더 많은 기능이 찾아올 예정입니다!


23.03: 2023년 3월 업데이트

김종민

> 본 포스트의 내용은 필자의 개인적인 경험을 바탕으로 작성되었습니다. 여기서 언급된 내용이 모든 경우에 해당되는 것이 아니며 다양한 의견이 있을 수 있습니다.

## What is DevRel?
![](https://cdn.lablup.com/teaming_7ef724c5f8.jpg)

Image by <a href="https://pixabay.com/users/henning_w-327613/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=386673">Henning Westerkamp</a> from <a href="https://pixabay.com//?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=386673">Pixabay</a>


DevRel 은 이름에서 유추할 수 있듯이 Developer 들과 Relation (관계) 를 만들어 나가는 것이 가장 큰 목적입니다. 여기서 Developer 는 코드를 짜는 개발자 뿐 아니라 기획자, 디자이너 등 서비스와 제품을 만드는데 참여하는 모든 생산들을 포함합니다.
세부적인 DevRel 의 역할은 조직과 산업의 성격에 따라서 많은 차이가 있는데 보통은 그 목적이 **(제품,기술) 홍보** 또는 **채용** 으로 수렴하는 경우가 많습니다.

DevRel의 주요 역할은 다음과 같은 것 들이 있습니다.
- 제품 홍보 및 **기술 전파**
- **커뮤니티** 설립, 운영, 지원
- 사용자의 의견 수렴하고 제품 개발에 **피드백**
- 사용자들이 제품을 더 잘 사용할 수 있도록 다양한 **리소스 제공**

Developer Advocate 은 DevRel 안에서도 **기술 전파** 및 **리소스 제공** 에 조금 더 초점을 맞추고 있는 역할이라고 볼 수 있습니다.

## Why DevRel?

기업에서는 자사의 제품과 서비스를 대중에게 알리기 위해 다양한 채널과 이벤트 등을 통한 마케팅/홍보 활동을 합니다. 이런 활동들을 PR - Public Relations 이라고 하며, 말 그대로 대중들과 관계를 만들어 나가는 행위 라고 볼 수 있습니다.
IT 제품을 개발하거나 서비스 하는 기업에서는 주 소비자가 엔지니어(Developer)들 입니다. 그리고 엔지니어들을 대상으로 하는 제품들은 더욱 세부적이고 기술적인 정보들을 제공해야 하는 경우가 많아 일반적인 PR 활동과는 다른 자원과 전략들이 필요합니다. 말 그대로 DR - Developer Relation 입니다.

IT 생태계를 유지하는 가장 중요한 원동력은 커뮤니티라고 할 수 있습니다. 특히 Backend.AI 와 같은 오픈소스 제품들은 커뮤니티의 역할이 더욱 중요합니다.
심지어 비슷한 종류의 새 기술들이 나왔을 때 성능이나 완성도 외에도 커뮤니티의 규모가 그 기술을 선택하여 도입하는 요인이 되는 경우도 많습니다. DevRel 의 중요한 역할 중 하나는 이러한 커뮤니티를 돕고 소통하는 것입니다.

저는 커뮤니티의 중요성을 설명할 수 있는 좋은 비유로 아티스트와 팬클럽의 관계로 이야기하곤 합니다.
아티스트의 주요 역할은 음악을 만들고 공연을 하는 것입니다. 하지만 팬클럽을 통해서 바이럴과 2차 창작물들이 탄생하기도 하며 이것은 아티스트들의 활동 그리고 엔터테인먼트 사업에 있어 중요한 원동력이 되기도 합니다.
요즘은 이런 팬덤의 중요성을 연예 기획사들도 잘 알고 있기에 다양한 활동들을 지원하곤 합니다.

 ![](https://cdn.lablup.com/kpop_fan_6c9ba87f2a.jpeg) 
Image created by <a href="https://www.midjourney.com/showcase/recent/">Midjourney</a>

마찬가지로 IT 조직의 DevRel 은 다양한 커뮤니티들을 지원하고 소통하며 제품과 조직이 관심에서 멀어지지 않도록 하는 것이 중요한 역할이라 할 수 있겠습니다.

## Developer Advocate in Lablup

래블업에는 대한민국 개발자 커뮤니티를 위해 오랜 기간 활약하고 계신 유우영님께서 함께하고 계시고, 대표이신 신정규님도 다양한 개발자 커뮤니티에서 활동하고 계시기 때문에 이미 조직 규모에 비해 많은 DevRel 활동들을 해 오고 있습니다. Backend.AI 는 훌륭한 소프트웨어이고 특히 요즘과 같은 대AI 시대 (라고 표현하는게 적절한) 에 중요하게 쓰임받을 수 있는 도구입니다. 하지만 AI 학습 및 추론을 위한 도구인 만큼 설치를 위해 많은 준비와 리소스들을 필요로 하며 특히 AI의 급부상 때문에 AI 처음 시작하는 분들께는 (사실 저도 그렇습니다😅) 허들이 높은 것도 사실입니다.

아직 Backend.AI 만의 사용자 규모가 크지 않아, 래블업에서는 오픈소스 문화 라는 주제와 엮어 그 동안 [오픈소스 컨트리뷰션 아카데미](https://www.oss.kr/contribution_academy)와 같은 다양한 커뮤니티 활동들을 해 왔습니다. 자체 커뮤니티가 성장하기 위해서는 제작자들로부터 사용자들에게 일방적으로 기술 전파가 이루어 지는 것 외에도 사용자들 끼리의 정보가 생산되고 전파되어야 합니다. 그런 활동들이 활발히 일어날 수 있도록 누구나 쉽게 활용 가능한 다양한 리소스들와 교류 기회를 계속해서 만들고 개선 해 나가는 것이 앞으로 제가 해야 할 주요 과제입니다. 앞으로도 다양한 기회와 방법으로 여러분들과 소통할 수 있도록 계속 노력하겠습니다.

Developer Advocate in Lablup

이종은

Backend.AI의 MLOps 플랫폼인 FastTrack은 React 18을 사용하고 있습니다. React 18의 Concurrent 렌더러 덕분에 가능해진 급하지 않은 렌더링 구분하기에 대해 알아보겠습니다.

React의 Concurrent 기능은 Async Rendering이라는 이름으로 JSConf Iceland 2018 에서 처음 외부에 공개된 이후에 2022년이 되어서야 정식 기능으로 React 18에 포함되었습니다. 이 기간에서 예상할 수 있듯이 Concurrent 렌더러는 React 18에서 가장 크고 중요한 변화에 해당합니다. 렌더러가 변경되었지만 React 개발자들은 큰 변경 없이 React 18 이전 버전에서 제작한 React 코드를 React 18에서 실행 가능합니다. 심지어 React의 Concurrent 렌더러를 모르더라도 React로 UI를 만들 수 있습니다. 하지만 이 Concurrent 렌더러가 무엇이고 어떤 상황에서 유용한지를 이해한다면 React로 개발할 때 복잡했던 머릿속이 간단명료해지고 보다 나은 UX를 제공하는 UI를 개발할 수 있습니다. 이 글에서는 Concurrent 렌더러가 내부적으로 어떻게 동작하는지에 대해 이야기하지 않습니다. React를 이용해서 애플리케이션을 만드는 개발자에게 더 중요하다고 할 수 있는 Concurrent 렌더러가 무엇이며 React 개발자가 사고하는 방식이 어떻게 바뀔 수 있는지에 대하여 살펴봅니다.

이 글의 내용을 요약해 보자면 다음과 같습니다.

Concurrent 렌더러 덕분에

* 컴포넌트 렌더링은 중단될 수 있습니다.
* 화면에 보이지 않는 곳에서 트리의 일부를 렌더링 할 수 있습니다.
* 이로 인해 React 개발자가 이전과는 달리 급하지 않은 렌더링을 구분할 수 있습니다.

> **“React 컴포넌트는 추상적으로 순수 함수이다.”**
> 
> React 컴포넌트는 실제로 자바스크립트 함수로 만듭니다.(클래스로 만드는 방법도 있지만 대부분의 경우 추천하지 않습니다.) 함수는 입력을 주면 출력을 만듭니다. 입력이 변하면 출력이 달라질 수 있으므로 함수를 실행해서 새로운 출력을 만듭니다. (순수 함수는 입력이 같으면 출력이 같습니다.) 

> **React 컴포넌트의 입력과 출력은 무엇인가요?** 
> React 컴포넌트의 입력은 해당 컴포넌트가 함수로서 받게 되는 property(React에서는 props라 함)이며 출력은 함수가 리턴하는 React 엘리먼트입니다. 

> **hook을 통한 state도 입력일까요?** 
> hook도 추상적으로 함수의 입력이라 할 수 있습니다. React props와 동일하게 값이 변하면 다시 렌더링하게 만드는 트리거(trigger)이며 이 변화를 통해 React 컴포넌트의 출력을 달라지게 합니다. 

자, 다시 렌더링에 대한 이야기로 돌아가겠습니다.


## 컴포넌트 렌더링은 중단될 수 있다.
Concurrent React의 핵심은 '렌더링은 중단될 수 있다.'입니다. React 18 이전에는 중단될 수 없었습니다(experimental 제외). React 컴포넌트가 함수로서 렌더링을 위해 실행되게 되면 return 하기 전까지 그 어떤 자바스크립트 연산도 실행할 수 없었습니다. 렌더링을 위한 함수의 실행이 오래 걸린다면 엘리먼트를 return하기 전까지 사용자의 클릭을 처리하는 이벤트 핸들러 함수를 실행할 수 없다는 얘기입니다. 하지만 18버전부터는 중단될 수 있습니다.

```shell
const A = ({ count }) => {
 return (
 <div>
 {count}
 
 <C/>
 </div>
 );
};

const B = () => {
 const [text, setText] = useState("");
 return (
 <div>
 <input value={text} onChange={(e) => setText(e.target.value)} />
 <D/>
 </div>
 );
};

const C = () => {
 return C;
};

const D = ({ text }) => {
 verySlowFunction(text); //연산이 수 초 걸리는 함수라 가정합시다.
 return D;
};
```

React 18 이전 버전에서는 A를 렌더링하면 B와 C가 렌더링되어야 하고, B를 렌더링하려면 D가 렌더링이 되어야 했습니다. A의 렌더링을 시작하면 필요한 B, C, D 가 모두 렌더링된 후 A의 리턴 값인 React 엘리먼트를 리턴하기까지 다른 자바스크립트 연산을 수행할 수 없습니다. A에서 리턴하는 컴포넌트 트리가 한 덩어리처럼 렌더링 됩니다. A의 렌더링이 시작되면 A의 렌더링을 중간에 중단하는 건 불가능했습니다.

Concurrent React에서는 렌더링을 중간에 중단할 수 있습니다. 렌더링을 중단하는 것은 왜 필요한 것일까요? 다음을 생각해 볼 수 있습니다.

* 지금 진행 중인 렌더링이 더 이상 유효하지 않을 때(stale)
 * 예를 들어 위 코드에서 A의 `count` prop이 1인 상태로 렌더링 중인 상황을 생각해봅시다. 이 때 이 렌더링이 완료되기 전에 `count`가 2로 변해서 2일 때의 A에 대한 렌더링 요청이 발생했습니다. 그러면 1일 때의 렌더링 결과는 최신 값을 표시하는게 아니므로 더이상 필요없어 집니다. 이런 상황에서 바로 1일 때의 렌더링을 중단하고 2일 때의 렌더링을 시작할 수 있다면 더 빨리 사용자에게 최신값인 2일 때의 화면을 보여 줄 수 있게됩니다.
* 진행 중인 렌더링이 보여주려는 화면의 갱신 보다 더 먼저 처리하고 싶은 것이 있을 때
 * 렌더링 중에 사용자 이벤트가 발생할 경우, 즉각적으로 반응하기 위하여 진행 중인 렌더링을 중단하고 이벤트 핸들러를 우선적으로 실행할 수 있습니다.

이러한 경우들은 모두 해당 컴포넌트의 렌더링을 중단해서 다른 처리를 할 수 있게 함으로써 UX를 개선하는 경우입니다.

## 화면에 보이지 않는 곳에서 트리의 일부를 렌더링 할 수 있다.
Concurrent React에서는 화면에 보이는 것과 일치하는 렌더링 외에 화면의 일부에 해당하는 컴포넌트만 별도로 렌더링 할 수 있습니다. 이는 기존 렌더링을 화면에 보여주고 계속 동작하게 하면서 앞으로 갱신될 화면의 일부를 미리 별도로 렌더링하고 렌더링이 완료되면 교체하게 됩니다. 렌더링을 필요 이상으로 하기 때문에 사용성을 떨어트리게 되는 게 아닌가 하는 걱정이 들 수 있습니다. 하지만 이 별도의 랜더링은 Concurrent 렌더러 덕분에 언제든지 중단될 수 있으므로 사용자 인터렉션을 방해하지 않게 됩니다. 오히려 이 특징을 이용하여 보다 나은 UX를 제공할 수 있습니다.

지금까지 Concurrent 렌더러의 두 가지 특징을 살펴봤습니다. 이번에는 이 두 특징이 활용되는 '급하지 않은 렌더링 구분하기'가 무엇인지 알아봅시다.

## 급하지 않은 렌더링 구분하기

> **급한 렌더링과 급하지 않은 렌더링 예시:** 
> &nbsp; 
> 
> 브라우저를 통해 사이트에 처음 방문하는 것을 생각 해봅시다. 하얀 빈 화면이 있는 상황에서 가장 급한 것은 무엇인가요? 어떻게든 빨리 사이트의 내용을 화면에 뿌려주는 게 가장 중요한 일일 겁니다. 하얀 화면에 오래 머문다면 사용자는 기다리지 않고 떠날 수 있으니까요. 그러니 첫 번째 렌더링은 딱히 중단할 일이 없습니다. 
>&nbsp; 
> 
> 홈페이지의 좌측 사이드바를 보니 내비게이션에 해당하는 메뉴들이 있습니다. 메뉴 A를 누르려다가 메뉴 B를 잘못 눌렀습니다. 사용자가 다시 메뉴 A를 누르려고 하는데 메뉴 B 렌더링이 오래 걸린다면 메뉴 B에 해당하는 화면의 렌더링이 끝나고 메뉴 A에 해당하는 화면이 렌더링이 될 것입니다. 
>&nbsp; 
> 
> 메뉴 B를 눌렀다가 메뉴 A를 바로 다시 누른 상황에서 메뉴 B에 대한 화면을 렌더링하는 것보다 메뉴 A에 대한 화면을 렌더링하는 것이 더 급합니다. B에 대한 화면은 이제 유효하지 않습니다. 


React 개발자는 어떻게 어떤 렌더링이 급하지 않은 렌더링이라고 React에게 알릴 수 있을까요? 렌더를 트리거하는 입력의 변화 중에 어떤 입력의 변화가 급하지 않은지를 표시하면 됩니다. 이를 개발자가 손쉽게 표시할 수 있게 해주는 hook이 `useDeferredValue`와 `useTransition` 입니다. 이 두 API 모두 리액트 18에 새롭게 추가되었으며 급하지 않은 렌더링을 지연시키는 동일한 효과를 가져옵니다. 이 두 hook을 하나씩 살펴보면서 이 둘의 차이점을 이해해 봅시다.

## `useDeferredValue`: 변한 입력값을 이용하여 구분하기
특정 값을 사용하는 컴포넌트에서 해당 컴포넌트는 그 특정한 값의 변화를 급하지 않게 처리하고자 할 때 사용합니다.

```shell
function App() {
 const [text, setText] = useState('');
 return (
 <>
 <input value={text} onChange={e => setText(e.target.value)} />
 <SlowList text={text} />
 </>
 );
}
```
위 예시 코드는 beta.reactjs.org의 `useDeferredValue` 예제 중 하나입니다.

여기서 `text`는 state이므로 `text`가 변하면 `App`이 다시 렌더링됩니다. 이 `text`는 `<input>`과 `<SlowList>`의 입력(props)으로도 사용되고 있습니다. `text`가 변하면 `App`의 렌더링이 트리거가 되고 그 과정에서 `input`과 `SlowList`가 바뀐 `text`를 사용하여 다시 렌더링됩니다. `SlowList`의 렌더링이 오래 걸린다면 사용자가 빠르게 타이핑을 이어가도 매 렌더링이 완료되기까지 사용자의 입력이 반영되지 않습니다.

여기서 `input`과 `SlowList`에서 사용자의 키보드 입력에 해당하는 `input`의 렌더링은 급한 렌더링이고 `SlowList`는 사용자 입력에 따른 어떠한 결과이므로 `input`보다는 급하지 않은 렌더링이라고 볼 수 있습니다. 여기서 `useDeferredValue`를 사용하면 급한 렌더링을 트리거하는 `text`를 이용하여 급하지 않은 렌더링을 할 때 화면에 표시되는 `deferredText`를 만들 수 있습니다.

```shell
function App() {
 const [text, setText] = useState('');
 const deferredText = useDeferredValue(text);
 return (
 <>
 <input value={text} onChange={e => setText(e.target.value)} />
 <SlowList text={deferredText} />
 </>
 );
}
```

이렇게 하게 되면 `text`의 변화가 있을 때 `deferredText`는 바로 이전 `text`값을 갖게 되지만 화면에 보이지 않는 곳에서 `deferredText`도 최신의 값을 갖는 상태로 별도의 렌더링을 하게 되고 이 별도의 렌더링이 완료되어야 비로소 `text`와 `deferredText` 모두 최신의 값을 갖는 상태로 렌더링됩니다. `deferredText`의 변화는 급하지 않은 렌더링이고 중단될 수 있습니다.

동일한 컴포넌트에 대해 급하지 않은 렌더링 요청이 연속적으로 있을 경우, 먼저 시작된 급하지 않은 렌더링이 끝나지 않았다면 바로 중단하고 최근 변화의 렌더링을 시작하게 됩니다. 예를 들어 `text`에서 사용자가 비어있는 input 상자에 ab를 순서대로 타이핑하게 되면 a가 입력되었을 때 별도의 렌더링이 시작되고, 이 렌더링 끝나기 전에 b를 눌러 ab가 되었다면 a일 때 시작된 별도의 렌더링은 중단하게 되고 ab를 위한 렌더링이 시작됩니다.

## `useTransition`: 입력의 변화를 주는 함수를 이용하여 구분하기
앞서 `useTransition`와 `useDeferredValue` 모두 급하지 않은 렌더링으로 구분할 때 사용된다고 했습니다. 이 둘의 차이점을 살펴보면서 `useTransition`에 대해 알아봅시다.

> :warning: **주의**
>
> 이 둘의 차이를 쉽게 이해하기 위해 `useDeferredValue`의 예제를 `useTransition`을 사용하도록 변경했습니다. `useTransition`은 업데이트가 동기적으로 일어나야 하는 `input`과 사용할 수 없습니다. 사용할 수 없는 이유는 [beta.reactjs.org](beta.reactjs.org)의 `useDeferredValue` 페이지의 [Trouble shooting](https://react.dev/reference/react/useTransition#troubleshooting)에서 확인하시기 바랍니다.

```shell
function App() {
 const [text, setText] = useState("");
 const [isPending, startTransition] = useTransition();
 return (
 <>
 <button
 onClick={(e) => {
 startTransition(() => setText((v) => v + "a"));
 }}
 >
 a 키
 </button>
 <SlowList text={text} />
 </>
 );
}
```

### 차이점
급하지 않은 렌더링이라고 지정할 때 `useDeferredValue`는 그 값인 `text`를 이용했다면 `useDeferredValue`는 그 값(렌더 트리거)의 변화를 야기하는 `setText`를 이용합니다. `text`를 접근할 수 없는 상황에서 `setText`만 알아도 됩니다.

`startTransition` 안에서 변경되는 `text`의 변화를 바로 화면에 표시할 방법이 없습니다. 별도의 렌더링으로 변경된 `text`를 위한 렌더링이 시작되지만 별도의 렌더링일 뿐 실제 화면을 위한 렌더링에는 그 변경된 값을 알 수는 없습니다. 다만 `isPending`을 통해 별도의 렌더링이 진행 중임은 알 수 있습니다. `useTransition`은 `state`의 변경을 지연하게 되고 `useDeferredValue`은 변경된 `state`에 따른 일부 렌더링을 지연하게 됩니다.

### 공통점
`startTransition`을 통해 동일한 컴포넌트에 대해 급하지 않은 렌더링 요청이 연속적으로 있을 경우 `useDeferredValue`와 동일하게 먼저 시작된 별도의 렌더링이 아직 진행 중이라면 바로 중단되고 최신 값을 사용하는 별도의 렌더링이 시작됩니다.

## 정리
React 18의 Concurrent 렌더러 덕분에 가능해진 '급하지 않은 렌더링 구분하기'에 대해서 살펴보았습니다. useTransition과 useDeferredValue를 사용하여 급하지 않은 렌더링을 구분하게 되면 복잡한 구조의 화면 갱신도 사용성을 떨어뜨리지 않으면서 가능해집니다. React 18 이전에는 이러한 막힘없는 사용성을 제공하기 위해서는 많은 개발공수가 들었습니다. React 18에서 간편해진 '급하지 않은 렌더링 구분하기'를 통해 사용자에게 쾌적한 UX를 제공해 보시기 바랍니다.

Concurrent React가 가져온 변화: 급하지 않은 렌더링 구분하기

강시온

## 서론
내가 처음 이 회사를 알게 된 건 2019년 여름이었다. 당시 GDG Seoul '모두의 Toy Story'라는 행사에서 지인이 발표를 한다고 해서 행사를 참관했는데, 그 자리에서 래블업의 '머신러닝에 활용하는 GPU 가상화 도구'를 주제로 한 세션을 듣고 굉장한 흥미를 느꼈다. 이 때는 내가 한창 머신러닝에 관심을 가지던 시기였는데, 래블업의 발표는 기술적으로 깊이가 있었고, 이런 일을 하는 회사도 있구나 하며 이 회사에 대해 처음으로 알게 되었다.

 ![](https://cdn.lablup.com/202424596_37015a5e_8c90_4de4_af98_d9bb60047361_1389ca8bcb.png) 

그 후, 다시 한번 이 회사와 연이 닿게 되었는데, 42 Seoul에서 진행한 오픈소스 해커톤에서였다. 특정 오픈소스를 활용한 제품을 단기간에 만드는 대회였는데, 이때 나는 Backend.AI 팀에 참여하게 되었다. 이 때는 앞서 언급한 GDG Seoul에서의 발표 이후 3년이 지난 시점이었지만, 그 때의 발표가 매우 인상깊었기 때문에 이름을 보자마자 곧바로 회사를 떠올릴 수 있었다. 대회를 진행하는 동안 정규님의 멘토링을 통해 많은 도움을 받았고, 덕분에 대회에서 2위를 수상하는 쾌거를 이루었다.

2022년 5월, 나는 쎄트랙아이라는 회사에서 학교 연계 인턴십을 진행하고 있었다. 인턴십 종료 이후 어떤 일을 해야 할까 알아보던 중, 페이스북에서 래블업의 여름 인턴십 공고를 보게 되었다. 대회를 진행하며 정규님에게 받은 멘토링이 큰 도움이 되었기에 좋은 기억이 있었고, 개발자 커뮤니티와 오픈소스에도 지대한 관심을 가지고 있었기에 나의 다음 목적지를 래블업으로 정하게 되었다.

그 무렵, 나는 42 world라는 프로젝트를 진행하고 있었는데, 이 시기가 내가 많은 것들을 배우고 성장할 수 있었던 시기라고 생각한다. 래블업의 면접을 보며 내가 진행하던 42 world 프로젝트를 소상히 설명할 기회가 있었고, 프로젝트에 모노레포를 적용하며 어려웠던 경험을 나누자 래블업도 Backend.AI에 모노레포를 적용하며 어려움을 겪었다는 이야기를 해주어 면접 동안 개발자끼리의 소소한 공감을 주고받을 수 있었다.

그렇게 래블업 인턴십에 합격한 후, 총 4분의 다른 인턴분들과 인턴십 생활을 시작하게 되었다. 나는 기존의 인턴십을 마무리하고 이사할 기간을 가지기 위해 다른 분들보다 일주일 정도 늦게 회사에 입사하게 된 케이스다. 일주일 동안은 Backend.AI를 파악하고 회사에 적응하는 Orientation 주간을 가졌다. 온보딩 문서화가 잘 되어있어 신규 입사자가 쉽게 회사에 적응하기 좋은 환경이 갖추어져 있는 회사라는 생각이 들었다. Orientation 기간 대부분은 Backend.AI를 설치하고 세팅하는데 대부분의 시간을 보낸 것 같다. 나는 다른 인턴분들보다 일주일 정도 늦게 입사한 덕분에 다른 인턴분들에게 도움을 많이 받았고, 상대적으로 수월하게 Orientation 기간을 마무리할 수 있었다.

## 업무 시작
2주 차부터 이제 본격적인 task 들을 할당받아 일하기 시작했다. DevOps, Frontend, Research 팀 중에 본인이 하고 싶은 일을 선택하여 각 챕터 담당자분에게 good-first-issue를 할당받아 시작하였는데, 나는 DevOps 팀을 선택하여 업무를 시작했다. 처음으로 할당받은 이슈는 세션을 실행하고 원하는 코드를 실행하기까지 하는 run 커맨드를 세션을 실행하는 start와 코드를 실행하는 exec 명령어를 조합하여 구현하도록 하여 코드의 중복 구현을 줄이도록 refactoring 하는 작업이었다.

 ![](https://cdn.lablup.com/202433613_91dd0878_8d6d_480a_b0ec_e3f637d7169b_6856417e93.png) 

나에게 할당된 첫 이슈를 진행하며 꽤나 어려움을 겪었는데, 해당 이슈의 구현 난이도와는 상관 없이 Backend.AI의 레포 구조를 이해해야 했기 때문이다. 이슈가 왜 생겼는지 파악하는 것도 중요하지만, 그 전에 Backend.AI가 목표로 하는 것이 무엇인지 정확하게 알고, 이 이슈가 어떤 목적을 달성하기 위해 해결되어야 하는 것인지 이해해야 문제를 정확하게 해결할 수 있다는 사실을 알게 되었다.

첫 번째 이슈를 해결하고 난 후에는 vfolder clone이라는, 당시 개발 중인 기능을 테스트하는 업무를 맡게 되었다. 해당 업무를 하면서 DevOps 업무만을 담당하다가 Frontend 챕터의 프로젝트인 Backend.ai-webui를 처음으로 사용해보게 되었다. vfolder clone 테스트뿐만 아니라 직접 실행하면서 개선할 수 있는 사항이나 버그들을 찾아서 이슈로 등록했는데, 뭔가 다른 팀에 계속 task를 만드는 느낌이라 좀 죄송한 마음도 들었지만, 프론트엔드 챕터에서는 굉장히 좋은 기여라고 독려해 주셨다. 오픈소스는 코드 기여 뿐만 아니라 다른 방면으로도 많이 기여를 할 수 있음을 다시 한번 깨닫게 되었다.

 ![](https://cdn.lablup.com/202441600_3da0d632_abda_4953_ab42_c8c5379dbab2_82a74cd001.png) 

## CI/CD 개선
평소 CI/CD에 관심이 많았던 나는 Backend.AI에서 활용되는 actions에 흥미를 갖고 관심깊게 살펴보았다. 당시 Backend.AI에는 `skip:ci` 태그를 이용하여 CI를 skip 할 수 있는 기능이 있었는데, `skip:ci`나 `skip:changlog` 태그가 PR 생성 당시가 아닌, 나중에 라벨을 다는 경우에는 적용되지 않는다는 것을 알게 되었다. 이를 위해 의미 없는 commit을 추가해야 했고, 외부 기여자의 경우 label에 대한 권한이 없기 때문에 Backend.AI가 오픈소스인 만큼 중요하게 해결되어야 하는 문제라고 생각했다. 그래서 GitHub Actions와 관련된 내용을 조사했고, action trigger에 labeled와 관련된 trigger가 있다는 것을 알게 되어 해당 문제를 해결할 수 있었다. 할당받은 이슈가 아닌 직접 개선할 수 있는 사항을 찾고 개선한 것이라 해당 작업을 회사에서도 매우 좋게 봐주셨다. 해당 문제를 해결하면서 actions에 더 흥미가 생겨 몇 가지 개선사항을 좀 더 제시해보았다. 누락된 assign 들이 꽤 보여 이를 자동화하여 해결하면 실수도 방지하고 assign 하는 귀찮음도 줄일 수 있다고 생각해 기존에 사용해 본 적이 있는 auto-auth-assign action 도입을 제안했다. 그다음으로는 labeling도 자동화를 하면 좋을 것 같았다. 해당 문제도 labeler라는 action이 존재하여 사용해 본 적은 없지만, test repository에서 여러 번 테스트를 거쳐 Backend.AI에 적용했고 모노레포로 합쳐진 여러 시스템을 구분하는 labeling 작업을 자동화할 수 있었다. 이 작업을 하면서 느낀 것은 PR에 연결된 issue에 할당되어있는 label을 그대로 붙여주면 좋을 것 같다는 생각이 들었는데, 해당 기능을 하는 action을 찾을 수가 없었다. 그래서 직접 제작해보기로 결심했고, GitHub API와 action을 학습, auto-label-in-issue라는 actions를 직접 제작하여 배포했다.

## 인턴십을 마치며
이번 인턴십을 통해 많은 것을 느끼고 많은 것을 배워간다. 이번 인턴십이 두 번째 경험이긴 하지만, 이전 회사는 IT 회사가 아니었던 만큼 IT 회사에서의 첫 인턴십 경험이었다. 나에게 래블업의 제품은 오픈소스로 관리되고, 회사 차원에서 커뮤니티에 꾸준히 기여한다는 점이 매력적으로 다가왔다. 회사가 정말 이렇게까지 수평적일 수 있나? 라는 생각이 들 정도로 편안한 분위기에서 자유롭게 의견을 제시할 수 있었다. 강제로 일을 하는 것이 아닌 주도적으로 하고 싶은 일을 할 수 있는 것이 래블업의 가장 큰 장점이라고 생각한다.

이제야 프로젝트에 대해 어느정도 파악 한 느낌인데 인턴십을 종료할 때가 다가와 아쉬움이 컸다. 감사하게도 래블업에서 인턴십을 연장해보지 않겠냐고 먼저 제안을 주셔서 인턴십을 연장, actions 이슈들을 주로 맡아 개발하게 되었다. 최근에 내가 계속 actions를 다루고 있고, 필드에 actions를 다루는 개발자가 많이 없기 때문에 이를 주제로 GDG Daejeon에서 발표도 하게 되었다. 덕분에 주변에서 액션가면이라는 별명으로 불리고 있는 것은 소소한 웃음거리다.

 ![](https://cdn.lablup.com/202441346_27e360f9_6397_4c79_960d_c47732f5d070_ea1a7af4ce.png) 

이후 인턴십에서의 경험을 오픈소스 컨트리뷰션 아카데미에서 나누기도 하고, 이를 바탕으로 컨트리뷰션 아카데미에서 좋은 성적을 거두게 되었는데, 회사에서의 경험이 이를 위한 밑바탕이 되었다고 생각한다.

2022 여름 래블업 인턴십 후기

이번 글에서는 Backend.AI의 MLOps 플랫폼인 FastTrack을 소개합니다. FastTrack을 사용하면 데이터 전처리, 학습, 검증, 배포, 그리고 추론과 같은 각각의 단계를 하나의 파이프라인으로 구성할 수 있습니다. 특히 FastTrack에서는 파이프라인을 구성할 때에 사용자가 각 단계를 손쉽게 커스터마이징 가능합니다. 이번 포스팅에서는 MLOps 플랫폼이 왜 필요한지와 함께 Backend.AI FastTrack 의 탄생 배경, 그리고 FastTrack 이 가지는 특장점을 함께 소개합니다.

## MLOps 플랫폼의 대두
 ![](https://cdn.lablup.com/mlops_platform_c4731f2c5f.png) 
지난 몇 년간 IT 산업 뿐만 아니라, 디지털 트랜스포메이션이 일어난 대부분의 산업에서는 AI를 도입해 산재되어 있던 데이터로 유의미한 예측을 도출해 빠르게 변하는 시장에 대응할 수 있도록 각고의 노력을 기울여왔습니다. 이 과정에서 AI를 잘 활용하기 위해서는 모델 학습, 최적화에서 끝나는 것이 아니라, 데이터 I/O를 고려한 하드웨어 도입, 모델 버전 관리 등과 같이 다양한 단계에 대한 대응이 필요하게 되었습니다. 여기서 나온 개념이 MLOps(Machine Learning Operations) 입니다. MLOps에 대한 자세한 내용은 래블업 기술 블로그에서 다루고 있는 MLOps 시리즈 에서 확인하실 수 있으니, FastTrack 소개글을 보기에 앞서 MLOps 개념이 생소하신 분들께서는 위의 글을 훑어보시는 것을 추천합니다.

## FastTrack의 역사

래블업은 DevOps 파이프라인 수요에 대응하고자 2019년 Backend.AI 파이프라인 기능을 베타 릴리즈로 추가했습니다. 복잡한 파이프라인 생성 및 관리 과정을 단순화하고, 중간에 두 경로 이상으로 나누어지는 단방향 파이프라인을 운영하는 기능을 개발 및 테스트로 공개하였습니다. 그러나, MLOps 개념의 대두와 함께 AirFlow, MLFlow, KubeFlow 등의 다양한 파이프라인 솔루션들이 보급됨에 따라 저희는 파이프라인 기능을 정식 기능으로 개발하는 대신, 오픈소스 파이프라인 도구들을 통합하고 지원하는 쪽으로 개발 방향을 선회했습니다.

한편 AI 개발 파이프라인은 점차 복잡해지고, 유저들의 다양한 요구들을 오픈소스 MLOps 파이프라인 도구들이 채워줄 수 없음이 명확해진 시점에서 저희는 Backend.AI의 파이프라인 기능을 다시 되살리기로 했습니다. Backend.AI 파이프라인 기능의 재활성화 및 프로토타이핑 과정에서, 유저들의 요청을 바로 반영할 수 있도록 본체에 완전히 통합된 파이프라인 대신 Backend.AI 클러스터와 함께 동작하지만 독립적으로 동작하는 MLOps 파이프라인 솔루션으로 개발 방향이 변경되었습니다.

이렇게 다양한 역사를 밟아온 래블업의 AI/MLOps 솔루션은 공항이나 물류 등에서 통과 및 통관 절차를 빨리 처리해주는 과정을 부르는 FastTrack Lane에서 힌트를 얻은 FastTrack으로 명명하였으며, Backend.AI 22.09와 함께 첫 정식 버전을 테스트 중입니다.

## FastTrack이란?

FastTrack 이란 Backend.AI 클러스터를 기반으로 여러 개의 작업단위들을 사용자가 목적에 맞게 커스터마이징 하고, DAG(Directed Acyclic Graph)형태로 실행될 수 있도록 돕는 머신러닝 워크플로우 플랫폼입니다. 머신러닝 파이프라인의 각 단계에 대응하는 세션을 선,후 관계를 통해 실행할 수 있게 되면 사용자는 데이터 전처리, 학습, 검증, 배포, 모니터링, 최적화 등과 같은 각 단계를 필요에 따라 결합해 하나의 워크플로우로 다룰 수 있습니다. 다시 말해 기존 Backend.AI 클러스터에서 사용자가 일일이 수동으로 생성해야 했던 세션을 워크플로우로 구성하여 단계가 끝날 때마다 자동으로 스케줄링 해주기 때문에 사용자는 보다 편리하게 모델을 구축, 재사용할 수 있습니다.
 ![](https://cdn.lablup.com/fasttrack_introduction_moving_4be00cb551.gif) 

## FastTrack 구조와 특징

FastTrack에서는 워크플로우 템플릿을 파이프라인(Pipeline), 실행 대상인 워크플로우를 파이프라인 잡(Pipeline Job)으로 구분하고, 워크플로우 안의 작업단위를 태스크(Task), 실행 대상인 작업단위를 태스크 인스턴스(Task instance)로 구분합니다. 아래의 구조도와 함께 FastTrack에서 어떻게 단계별 작업이 진행되는지 설명합니다.
 ![](https://cdn.lablup.com/fasttrack_architecture_f46ec19d8d.png) 

### 파이프라인(Pipeline)
파이프라인은 태스크들의 각각의 정보와 관계를 모아둔 집합체로, DAG(Directed Acyclic Graph) 구조를 갖습니다. AI 워크플로우를 만들기 위해서는 파이프라인을 생성하면 되는데, 이 때 학습이 잘 되고 있는지 등을 아티팩트(artifact)로 확인할 수 있도록 FastTrack에서는 Backend.AI 클러스터에 파이프라인 전용 폴더를 자동생성합니다. 또한 FastTrack에서는 드래그-앤-드랍(Drag and drop)과 같은 인터페이스로 사용자가 손쉽게 태스크 간 관계를 수정할 수 있고, 변경 결과를 즉시 도식화된 플로우로 확인 및 YAML 파일로 확인할 수 있어 매우 편리합니다. 또한 파이프라인은 YAML 파일로 관리되기 때문에 내보내기나 불러오기가 용이하여 사용자간 공유도 손쉽게 할 수 있습니다.

### 파이프라인 잡(Pipeline Job)
파이프라인 잡의 경우 생성된 파이프라인 정보를 기반으로 만들어지는 실제 개체로, 실행이 되는 동안에는 수정이 불가하다는 특성을 갖습니다. FastTrack GUI에서는 작업단위가 실행되는 것을 각 작업단위에 대응하는 노드의 색상으로 확인할 수 있습니다. 또한 파이프라인과 마찬가지로, 구성하고 있는 태스크 인스턴스의 정보와 관계를 YAML 형태로 관리합니다. 모든 태스크 인스턴스가 종료되면, 파이프라인 잡의 상태도 성공 또는 실패로 표시됩니다.

### 태스크(Task)
파이프라인을 이루는 최소 실행단위로, 용도 별로 자원 할당이 가능합니다. 가령 모델 학습만을 위한 태스크의 경우, 전처리 용과 달리 많은 GPU 자원을 집중할당하여 자원을 보다 효율적으로 사용할 수 있습니다. 또한 실행환경도 각각 지정할 수 있습니다. Backend.AI 클러스터에서 지원하는 이미지를 기준으로 TensorFlow, PyTorch, Python 3.x, NGC TensorFlow, NGC PyTorch 등과 같은 이미지를 도커 빌드과정 없이 그대로 사용할 수 있습니다. 또한 필요에 따라 Backend.AI 클러스터에서 생성한 가상폴더(Virtual Folder)를 태스크 별로 마운트할 수 있습니다.

### 태스크 인스턴스(Task Instance)
 ![](https://cdn.lablup.com/fasttrack_task_instance_cfa320eaa2.png) 
태스크 인스턴스는 파이프라인 잡이 생성될 때 파이프라인을 구성하는 태스크 정보를 바탕으로 생성되는 실제 개체라고 볼 수 있습니다. 즉 AI 워크플로우를 실행하는 것은 파이프라인 잡을 구성하는 태스크 인스턴스가 지정된 선,후 관계에 맞게 실행이 된다는 것을 의미합니다. 태스크 인스턴스는 현재 Backend.AI 클러스터의 세션(Session)과 1:1 대응이 되어 세션 상태와 태스크 인스턴스의 상태가 동일시 되고 있으나, 추후 세션 외에도 다양한 실행 단위로 확장될 예정입니다.

## 마치며
지금까지 Backend.AI MLOps 플랫폼인 FastTrack에 대한 소개와 함께 MLOps 에 대해 다뤄보았습니다. 현재 Backend.AI FastTrack의 경우 22.09 버전이 릴리즈 되었으며, 추후 파이프라인 버저닝, 파이프라인 간 의존 관계 추가, 태스크 자원 사용 최적화, GitHub 기반 모델/데이터 스토어 지원 등과 같은 다양한 사용자 편의 기능을 개발 및 제공할 예정입니다. 누구나, 언제 어디서든 AI 모델을 개발, 사용할 수 있게 하자는 래블업의 모토에 맞게, FastTrack을 이용하면 누구나 손쉽게 자동화된 모델 구축을 할 수 있도록 만들어가겠습니다. 앞으로의 행보에도 많은 관심 부탁드립니다.

Backend.AI MLOps 플랫폼 FastTrack을 소개합니다.

김준기

프로그램의 복잡도가 올라갈수록 소프트웨어 개발자에게는 좋은 디버깅 도구가 필요합니다. 가장 이상적인 디버깅 과정은 마음껏 실험해볼 수 있는 개발환경에서 문제를 안정적으로 재현하는 방법을 알아내고 이를 자동화된 테스트로 만드는 것이죠. 하지만 재현 시나리오 구성 자체가 너무 복잡하거나 프로덕션 환경에서만 가끔씩 랜덤하게 발생하는 종류의 버그들은 차선책으로 로그를 상세히 남겨서 사후에라도 어떤 문제가 있었는지 파악할 수 있도록 해야 합니다. 이번 글에서는 복잡한 asyncio 프로그램의 디버깅을 쉽게 하기 위해 개발한 aiomonitor-ng 도구를 소개합니다.

asyncio 애플리케이션 디버깅은 고유한 어려움들이 있습니다. 파이썬에서 디버깅할 때 가장 자주 활용하는 것이 바로 프로그램이 어느 부분을 실행하다가 예외가 발생했는지 보여주는 stack trace입니다. 그런데 asyncio 애플리케이션은 여러 개의 코루틴 작업들이 각자의 스택을 가지고 동시에 엮여서 실행되기 때문에 특정 예외가 발생한 코루틴 작업의 스택뿐만 아니라 '관련된' 코루틴 작업들의 스택도 함께 관찰해야 다른 코루틴 작업으로부터 야기된 오류인지 아닌지를 정확하게 파악할 수 있습니다. 특히, 내 코드에서 사용한 외부 라이브러리가 암묵적으로 코루틴 작업을 생성하고 그 코루틴 작업이 다시 내 코드를 호출하는 상황이라면 더욱 중요한 문제가 됩니다. 게다가 개발환경에서는 잘 발생하지 않고 프로덕션 환경에서만 발생하는 코루틴 작업 폭주 문제나 지속적으로 실행되어야 하는 코루틴 작업이 조용하게 종료되어버린다거나 하는 종류의 버그들은 굉장히 잡기 어렵습니다. 이런 종류의 버그들은 명시적인 예외가 발생하는 것이 아니기 때문에 사후 로그를 통해 문제점을 간접적으로 유추하는 수밖에 없기 때문입니다.

[aiomonitor](https://github.com/aio-libs/aiomonitor)는 asyncio 코어 개발자들이 개발한 프로덕션용 라이브 디버깅 도구입니다. asyncio 기반 코드를 monitor 객체로 감싸두면, 해당 코드가 실행 중일 때 프로세스 외부에서 미리 설정된 TCP 포트로 텔넷 세션을 열어 간단한 명령어들을 통해 이벤트루프가 실행하고 있는 코루틴 작업들의 목록과 개별 스택 현황을 조회할 수 있게 해줍니다. Backend.AI에는 이미 이 aiomonitor가 적용되어 개별 서비스 프로세스마다 고유의 디버깅용 텔넷 포트가 할당되어 있습니다. (물론 보안 상 이유로 localhost로부터의 접속만 허용합니다.) 이를 통해 프로덕션에서만 발생하는 문제들을 디버깅하는 데 큰 도움을 받을 수 있었죠. 하지만 여전히 Backend.AI 자체의 코드가 아닌 외부 라이브러리에 의해서 발생하는 코루틴 작업 폭주 문제나 조용하게 종료되어버리는 코루틴 작업이 왜 죽는지 디버깅하는 것은 정확히 그 문제가 발생하는 시점을 특정하여 그 순간에 aiomonitor를 들여다보는 방식으로는 디버깅에 한계가 있었습니다.

그래서 [aiomonitor-ng](https://github.com/achimnol/aiomonitor-ng)라는 확장 버전을 개발하게 되었습니다. ng는 next-generation의 약자입니다. 크게 다음과 같은 기능들이 추가 및 개선되었습니다.:

* Task creation tracker: 모든 실행 중인 코루틴 작업에 대해, 각 코루틴 작업을 생성(`asyncio.create_task()`)한 작업들에 대해 그 순간의 stack trace를 모두 보존하여 연속된 작업 생성 체인을 모두 알 수 있도록 하였습니다. (`ps`, `where` 명령)
* Task termination tracker: 최근 종료된 코루틴 작업들을 최대 N개까지 로그를 보존하고 조회할 수 있게 해줍니다. 특히 어떤 한 작업이 다른 작업을 취소(`Task.cancel()`)한 경우, 취소를 트리거한 순간의 stack trace를 함께 보존하여 연속된 취소 체인을 모두 알 수 있도록 하였습니다. (`ps-terminated`, `where-termianted` 명령)
* Persistent task marker: 기본값으로는 메모리 누수를 방지하기 위해 종료된 작업을 최근 N개까지만 추적하지만, 애플리케이션 수명 주기 동안 계속 실행되어야 하는 특정 작업들을 데코레이터로 표시해두면 해당 작업들은 이력 개수 제한과 관계 없이 항상 종료 로그를 보존해주고 종료 로그 조회 명령에서 별도 옵션으로 필터링하는 기능을 제공합니다. (`aiomonitor.task.preserve_termination_log` 데코레이터)
* 세련된 terminal UI: 기존에 손으로 짜여진 명령어 파싱을 바탕으로 했던 단순 REPL (read-evaluate-print loop) 구성이었던 명령줄 처리를 개선하였습니다. [Click](https://palletsprojects.com/projects/click/)과 [prompt_toolkit](https://python-prompt-toolkit.readthedocs.io/en/master/)을 활용하도록 aiomonitor 서버측 구현을 재작성하고, 클라이언트도 asyncio로 native하게 동작하는 텔넷 클라이언트를 자체 구현하여 명령어 및 task ID 등의 인자 자동완성을 제공합니다.
* 
실제 사용 화면은 다음과 같습니다.:
 ![](https://cdn.lablup.com/aiomonitor_ng_ps_b57dc89630.png "코루틴 작업 목록 조회") 
 ![](https://cdn.lablup.com/aiomonitor_ng_task_creation_tracker_f066f43262.png "코루틴 작업 생성 과정 추적") 
 ![](https://cdn.lablup.com/aiomonitor_ng_task_termination_tracker_1bea7f6f5f.png "코루틴 작업 종료 과정 추적") 

aiomonitor-ng 도구를 활용하여 grpcio 라이브러리에서 콜백으로 생성하는 코루틴 작업이 과다 생성되어 발생하는 리소스 누수 및 성능 저하 문제, docker 데몬이 발생시키는 이벤트를 모니터링하는 작업이 특정한 메시지 입력 패턴에 의해 조용하게 종료되어 버리는 바람에 컨테이너 생성이나 삭제 작업의 결과가 리턴되지 않아 시스템이 멈추는 문제 등을 성공적으로 디버깅할 수 있었습니다.

앞으로 aiomonitor-ng를 통해 래블업뿐만 아니라 다양한 Python asyncio 애플리케이션을 개발하는 독자분들께서도 디버깅에 큰 도움을 받기를 바라며 글을 마칩니다.

> aiomonitor-ng는 [PyPI](https://pypi.org/project/aiomonitor-ng/)를 통해 `pip install aiomonitor-ng` 명령으로 설치하실 수 있으며, [제 깃헙 계정에 오픈소스로 공개](https://github.com/achimnol/aiomonitor-ng)되어 있으므로 누구나 사용 및 기여가 가능합니다.



블로그

주요 이야기