devvon

Slack API 호출 (stepfunction , lambda)

wonpick — Fri, 22 Aug 2025 12:04:25 +0900

0. 개요

기존에 stepfunction flow 흐름 내부 작업들의 성공/실패 여부를 람다/http로 slack 알림으로 보내고 있었는데

실제 서비스에 적용하다보니 main 메세지로 가게되면 내용파악이 잘안되고 메시지가 너무 많아져서

쓰레드로 상세 내용을 담기 위해 slack api를 활용하기로 했다.

전

후

1. 방법

슬랙 봇을 만든 다음에 람다에 적용해주고 채널에 초대하면 끝이다!

1. Slack에서 준비할 것 (Bot Token과 Channel ID 얻기)

  1단계: Slack 앱(App) 생성
   1. Slack API (https://api.slack.com/apps) 페이지로 이동하여 Create New App 버튼을 클릭합니다.
   2. From scratch 를 선택하고, 앱 이름(예: "My Workflow Bot")을 정한 뒤, 알림을 보낼 Slack
      워크스페이스를 선택.

  2단계: 앱에 권한(Scopes) 부여하기
   1. 생성된 앱의 설정 페이지에서 Features > OAuth & Permissions 메뉴로 이동합니다.
   2. Scopes 섹션까지 스크롤을 내린 후, Bot Token Scopes 그룹에서 Add an OAuth Scope 버튼을
      클릭합니다.
   3. chat:write 권한을 검색하여 추가합니다. 이 권한은 봇이 채널에 메시지를 쓸 수 있게 해줍니다.

  3단계: 앱 설치 및 Bot Token 얻기
   1. OAuth & Permissions 페이지 상단으로 다시 올라가 Install to Workspace 버튼을 클릭하여 앱을
      워크스페이스에 설치하고 허용합니다.
   2. 설치가 완료되면 Bot User OAuth Token 이 표시됩니다. 이 토큰은 xoxb-로 시작하며, 이것이 바로
      Lambda 함수에 필요한 SLACK_TOKEN 입니다.

  4단계: Channel ID 얻기
   1. 메시지를 보낼 Slack 채널에서 채널 이름을 마우스 오른쪽 버튼으로 클릭합니다.
   2. "링크 복사"를 선택합니다.
   3. 복사된 링크는 https://.../archives/C12345678와 같은 형태이며, 여기서 마지막 부분인
      `C12345678` 이 바로 `SLACK_CHANNEL_ID` 입니다.

다른 방법

5단계: 채널에 봇 초대하기
1. 메시지를 보낼 채널에서 /invite @<방금 만든 봇 이름>을 입력하여 봇을 채널에 초대해야 합니다.

2. Lambda 함수에 설정할 것 (환경 변수 등록)

  위에서 얻은 두 개의 값을 Lambda 함수가 코드 안에서 안전하게 사용할 수 있도록 환경 변수로 등록해야 합니다.

   1. AWS Lambda 관리 콘솔에서 해당 함수 페이지로 이동합니다.
   2. 구성(Configuration) 탭 > 환경 변수(Environment variables) 메뉴로 갑니다.
   3. 편집(Edit)을 누르고 아래와 같이 두 개의 환경 변수를 추가합니다.
       * 키: SLACK_TOKEN, 값: 위에서 얻은 xoxb-로 시작하는 토큰
       * 키: SLACK_CHANNEL_ID, 값: 위에서 얻은 C로 시작하는 채널 ID

2. slack notification lambda example

- 전체적인 구조만 공유 (messages 내용은 미포함)

- thread_ts 를 통해 main_res_data와 동일한 time stamp 를 넣어주어 쓰레드로 thread_payload 가 전달될 수 있게 함.

def slack_msg(msg, username=''):
    slack_uri = os.environ.get("SLACK_WEBHOOK")
    headers = {"content-type": "application/json", "Accept-Charset": "UTF-8"}
    try:
        r = requests.post(slack_uri, json={'text': msg, 'username': username}, headers=headers)
        if r.status_code != 200:
            print(f"Error : {r.status_code} {r.text}")
    except Exception as e:
        print(f"Error slack_msg : {e}")

def get_user_to_ping(lambda_name: str, mapping: dict, is_debugging: bool, test_user: str, default_user: str) -> str:
    if is_debugging:
        return test_user
    return mapping.get(lambda_name, default_user)
    
def lambda_handler(event, context): 
    messages = [] #담고싶은 메세지를 sf event에서 받아옴
    users_to_ping = set()
    
    ping_string = " ".join(users_to_ping) + "\n" if users_to_ping else ""
    main_message_text = messages[0] #첫 head 메세지
    thread_message_text = ping_string + "\n".join(messages[1:]) #쓰레드에 달리는 메세지

    slack_bot_token = os.environ.get("SLACK_TOKEN")
    slack_channel_id = os.environ.get("SLACK_CHANNEL_ID")

    if slack_bot_token and slack_channel_id:
        try:
            api_url = "https://slack.com/api/chat.postMessage"
            headers = {
                "Authorization": f"Bearer {slack_bot_token}",
                "Content-Type": "application/json; charset=utf-8"
            }

            main_payload = {"channel": slack_channel_id, "text": main_message_text}
            main_res = requests.post(api_url, headers=headers, json=main_payload)
            main_res.raise_for_status()
            main_res_data = main_res.json()

            if not main_res_data.get("ok"):
                raise Exception(f"Error : {main_res_data.get('error')}")

            if thread_message_text.strip():
                message_ts = main_res_data.get("ts")
                if message_ts:
                    thread_payload = {
                        "channel": slack_channel_id,
                        "text": thread_message_text,
                        "thread_ts": message_ts
                    }
                    thread_res = requests.post(api_url, headers=headers, json=thread_payload)
                    thread_res.raise_for_status()
                    if not thread_res.json().get("ok"):
                        print(f"Failed to post thread message: {thread_res.json().get('error')}")

            return {"statusCode": 200, "body": json.dumps(main_res_data)}

        except Exception as e:
            print(error_detail)
            final_text = f"{main_message_text}\n{thread_message_text}"
            slack_msg(f"Slack API 호출 실패. Webhook으로 전체 메시지 전송.\n\n{final_text}")
            return {"statusCode": 500, "body": {e}}
    else:
        print("Webhook으로 전송 됨")
        final_text = f"{main_message_text}\n{thread_message_text}"
        slack_msg(final_text)
        return {"statusCode": 200, "body": "Sent via webhook."}

EMR Serverless 외부 라이브러리 참조 방법

wonpick — Fri, 28 Mar 2025 12:08:56 +0900

ecr , 가상환경 압축 후 s3업로드 등등 이있다. 그중 가상환경을 압축하여 전달할 수 있는 방법 소개한다.

1. 사전 준비 사항

AWS CLI가 설치 및 설정되어 있어야 합니다. (로컬에서 하는 경우)
Python(3.9 등 사용 버전) 및 virtualenv 또는 venv 모듈이 사용 가능한 환경이어야 합니다.
동일한 CPU 아키텍처에서 작업을 진행해야 합니다. 예를 들어, AWS EMR Serverless의 노드가 ARM64 아키텍처라면, 동일한 ARM64 머신(예: Graviton 시리즈(Amazon Linux 2/2023))에서 가상환경을 생성해야 합니다.
- CPU 아키텍쳐를 이해하는데 도움이 된 글 : 이제는 개발자도 CPU 아키텍처를 구분해야 합니다. (김형섭님)

이제는 개발자도 CPU 아키텍처를 구분해야 합니다.

Intel 천지였던 PC 분야에 ARM이 광풍을 불기 시작한지 얼마 되지 않았습니다.이에 개발자도 변화를 감지 하고 대응하기 위해 알아야 할 것들을 정리 했습니다.그동안 암묵적으로 대부분의 서버 환

velog.io

항목	x86_64 (AMD/Intel)	ARM64 (ARM)
명령어 집합	CISC 기반	RISC 기반
성능	단일 코어 성능이 높고, 데스크톱/서버에서 전통적으로 강점	코어 수 증가, 전력 효율 우수, 다중 코어 활용에 강점
전력 소모	상대적으로 높음	상대적으로 낮음
소프트웨어 호환	매우 폭넓은 호환성	최근 빠르게 확대 중, 일부 에뮬레이션 필요
주요 사용처	전통적 데스크톱, 노트북, 서버(Windows/리눅스/맥 인텔 기반)	모바일(스마트폰/태블릿), 임베디드, 저전력 서버(AWS Graviton), 리눅스, 애플 M 시리즈 맥

2. 가상환경 생성 및 라이브러리 설치

다음은 ARM64 환경을 예로 들어 설명합니다. x86_64 아키텍처라면 동일한 방식으로 진행하되 머신 아키텍처만 맞추시면 됩니다.

# Python 3.9 기준 예시
python3.9 -m venv brotli_env
source brotli_env/bin/activate

# 필요한 라이브러리 설치 (예: brotli)
pip install brotli

Spark 작업에서 사용하고 싶은 Python 라이브러리가 있다면 모두 여기에서 설치해두면 됩니다.

3. 가상환경 폴더 내부 압축하기 및 S3 업로드

<경로 중복 방지!!!>

가상환경 폴더 자체를 통째로 tar.gz로 압축하면, Spark에서 --archives 옵션으로 압축 파일을 풀었을 때 경로가 이중으로 잡히는 문제가 발생할 수 있습니다.

예를 들어, brotli_env라는 폴더를 통째로 압축하면, 압축 해제 시 brotli_env/brotli_env/처럼 경로가 중복될 수 있습니다.

이를 방지하기 위해, 가상환경 폴더 내부의 파일들과 서브 폴더만 압축해야 합니다.

# brotli_env 폴더 내부로 이동
(brotli_env) [ec2-user@dawon test]$ cd brotli_env/
# 폴더 내부의 모든 내용(.* 포함)을 tar.gz로 압축
# (.*까지 포함하려면 숨김 파일/폴더까지 확인 필요)
(brotli_env) [ec2-user@dawon brotli_env]$ tar -czf ../brotli_env_arm64.tar.gz *
# 현재 디렉토리를 벗어나기
(brotli_env) [ec2-user@dawon brotli_env]$ cd ..
#brotli_env 폴더 구조를 유지하면서, 압축 해제 시 디렉토리 중복안됨
(brotli_env) [ec2-user@dawon test]$ ls
brotli_env  brotli_env_arm64.tar.gz

#Amazon S3 버킷에 업로드
(brotli_env) [ec2-user@dawon test]$ aws s3 cp brotli_env_arm64.tar.gz s3://bucket/

이 과정을 거치면 brotli_env_arm64.tar.gz 압축 파일이 생성됩니다. 이 파일은 기존 brotli_env 폴더 구조를 유지하면서, 압축 해제 시 현재 디렉터리에 그대로 내용이 풀리게 됩니다.

이렇게 해야지 경로가 아래와 같이 할당 됨 ['./brotli_env/bin', './brotli_env/lib64']
-> 이전에는 ['./brotli_env/brotli_env/bin', './brotli_env/brotli_env/lib64']

4. EMR Serverless Spark 작업 제출

Spark Submit과 유사한 방식으로, EMR Serverless에서는 --archives 옵션을 통해 Python 가상환경 압축 파일을 넘길 수 있습니다.

--archives s3://<버킷명>/brotli_env_arm64.tar.gz#brotli_env
-> 이 옵션은 압축 파일을 brotli_env 디렉터리로 풀겠다는 의미입니다.
Spark 실행 시 spark.emr-serverless.driverEnv.PYTHONPATH와 spark.executorEnv.PYTHONPATH를 설정해 Python 라이브러리를 찾을 수 있도록 합니다.
spark.emr-serverless.driverEnv.PYSPARK_PYTHON, spark.executorEnv.PYSPARK_PYTHON 환경 변수를 가상환경의 Python 바이너리 경로로 지정해야 합니다.

#cli 예시
aws emr-serverless start-job-run\
     --application-id {app id}     \
     --execution-role-arn {arn}     \
     --job-driver '{                                                                                                                                                                                
        "sparkSubmit": {
            "entryPoint": "s3://bucket/import_brotli.py",
            "sparkSubmitParameters": \
            "--archives s3://bucket/brotli_env_arm64.tar.gz#brotli_env\
              --conf spark.emr-serverless.driverEnv.PYTHONPATH=./brotli_env/lib/python3.9/site-packages\
               --conf spark.executorEnv.PYTHONPATH=./brotli_env/lib/python3.9/site-packages\
                --conf spark.emr-serverless.driverEnv.PYSPARK_PYTHON=./brotli_env/bin/python3.9\
                 --conf spark.executorEnv.PYSPARK_PYTHON=./brotli_env/bin/python3.9"
        }
    }'

sublime text 단축키 정리

wonpick — Wed, 12 Mar 2025 17:14:42 +0900

아래 표는 Sublime Text 4 (Build 4192 기준)으로 Windows/Linux와 macOS에서 주로 사용되는 단축키들을 정리한 것입니다.
(기본 설정 그대로일 때의 단축키이며, 사용자가 Key Bindings를 변경했거나 플러그인에 따라 다를 수 있습니다.)

1. 기본 파일/창 관리

기능	Windows/Linux	macOS	설명
새 파일(탭)	Ctrl + N	Cmd + N	새로운 빈 탭(파일) 열기
새 창	Ctrl + Shift + N	Cmd + Shift + N	Sublime Text 새 창 열기
파일 열기	Ctrl + O	Cmd + O	파일 열기 대화상자
파일 저장	Ctrl + S	Cmd + S	현재 파일 저장
다른 이름으로 저장	Ctrl + Shift + S	Cmd + Shift + S	현재 파일을 다른 이름으로 저장
닫기(현재 탭)	Ctrl + W	Cmd + W	현재 탭 닫기
모든 탭 닫기	Ctrl + K, Ctrl + W	Cmd + K, Cmd + W	열려 있는 모든 탭 닫기
이전에 닫았던 탭 다시 열기	Ctrl + Shift + T	Cmd + Shift + T	방금 닫은 파일(탭)을 다시 열기
사이드바 토글	Ctrl + K, Ctrl + B	Cmd + K, Cmd + B	좌측 사이드바 표시/숨기기
전체화면 모드 토글	F11 / Alt + F11 (Win)	Cmd + Ctrl + F (macOS)	기본 전체화면 혹은 방해금지 모드(Distraction Free) 토글

2. 편집 관련 (줄/단어/구문)

기능	Windows/Linux	macOS	설명
주석 토글 (현재 줄/선택 영역)	Ctrl + /	Cmd + /	선택된 줄(또는 영역)에 한 줄 주석 추가/해제
라인 복제	Ctrl + Shift + D	Cmd + Shift + D	현재 줄(또는 선택 영역)을 바로 아래에 복제
라인 삭제	Ctrl + Shift + K	Cmd + Shift + K	커서가 있는 줄(또는 선택 영역 전체) 삭제
라인 이동(위/아래)	Ctrl + Shift + ↑/↓	Cmd + Ctrl + ↑/↓	현재 줄(또는 선택 영역)을 위/아래로 이동
한 줄 선택	Ctrl + L (반복)	Cmd + L (반복)	현재 줄 전체를 선택, 반복 시 인접한 줄로 확장
여러 줄(행) 분할(행 분리)	Ctrl + Shift + L	Cmd + Shift + L	여러 줄을 한꺼번에 선택했을 때 각 줄별로 커서(멀티커서) 분할
단어 단위 선택(반복)	Ctrl + D (여러 번)	Cmd + D (여러 번)	커서가 위치한 단어 선택, 반복 입력 시 다음 동일 단어 추가 선택
최근 추가된 단어 선택 해제	Ctrl + K, Ctrl + D	Cmd + K, Cmd + D	직전에 추가된 멀티 선택(단어)을 하나씩 제거
문서 내 동일 단어 전체 선택	Alt + F3	Ctrl + Cmd + G	문서 내 동일 단어를 한 번에 모두 선택 (멀티 커서 생성)
멀티 선택 해제(Soft Undo)	Ctrl + U	Cmd + U	멀티로 선택된 커서(단어) 중 마지막 추가분을 한 번에 해제
모든 선택 취소	Esc	Esc	멀티 커서/선택 전부 해제, 검색 강조 취소 등
괄호 범위 선택	Ctrl + Shift + M	Cmd + Shift + M	괄호((), {}, []) 안쪽의 내용을 포함하여 선택
들여쓰기 레벨 동일 범위 선택	Ctrl + Shift + J	Cmd + Shift + J	현재 코드 블록과 같은 들여쓰기 레벨에 있는 구역 전체 선택
같은 스코프(Scope) 범위 선택	Ctrl + Shift + Space	Cmd + Shift + Space	함수, 객체 등 Sublime이 인식하는 같은 스코프 내 영역을 선택
전체 코드 자동 정렬 (Reindent)	Command Palette에서 Reindent	같음	선택 영역(또는 파일 전체)을 자동 들여쓰기
매크로 녹화/중단/재생	Ctrl + Q / 동일 / Ctrl + Shift + Q	macOS 미리 설정 없음	편집 작업을 매크로로 녹화 후 재실행 (Windows/Linux 기본). macOS는 사용자가 직접 바인딩 필요

3. 검색 & 치환

기능	Windows/Linux	macOS	설명
찾기(Find)	Ctrl + F	Cmd + F	현재 문서 내 문자열 검색 (Find Bar 표시)
바꾸기(Replace)	Ctrl + H	Cmd + Alt + F	현재 문서 내 문자열 치환
파일 전체 검색(Find in Files)	Ctrl + Shift + F	Cmd + Shift + F	지정한 폴더/프로젝트 전체에서 검색/치환
검색 결과 다음 이동	F3	Cmd + G	검색 결과(Find) 다음 위치로 이동
검색 결과 이전 이동	Shift + F3	Shift + Cmd + G	검색 결과 이전 위치로 이동
빠른 검색(Incremental Find)	Ctrl + I	Cmd + I	입력할 때마다 즉시 검색 (상단 표시줄로 수행)

4. 탐색 & Goto

기능	Windows/Linux	macOS	설명
Goto Anything (파일/기호/줄 등)	Ctrl + P	Cmd + P	파일 이름, @ 기호(함수/클래스), : 줄번호 등 빠른 이동
특정 줄 번호로 이동	Ctrl + G	Cmd + G	예: Ctrl + G → 숫자 입력 → 해당 줄로 점프
현재 파일 내 심볼(함수/클래스)	Ctrl + R	Cmd + R	현재 파일 내 함수/클래스 등 심볼 목록에서 점프
프로젝트 전체 심볼	Ctrl + Shift + R	Cmd + Shift + R	열려 있는 프로젝트(또는 폴더) 내 모든 파일의 심볼 검색
정의(Definition)로 이동	F12	F12 (같음)	선택한 심볼의 정의 위치로 점프 (언어/플러그인 지원 시)
명령 팔레트 열기	Ctrl + Shift + P	Cmd + Shift + P	Sublime Text Command Palette(명령 검색/실행 창) 열기

5. 멀티 커서 & 컬럼 선택 (마우스 포함)

기능	Windows/Linux	macOS	설명
임의 위치에 커서 추가	Alt + 클릭	Option + 클릭	원하는 지점마다 클릭하여 커서를 여러 개 생성
컬럼(열) 선택 (마우스 드래그)	Shift + 우클릭 드래그 또는 가운데 버튼 드래그	동일	직사각형 형태로 열 단위 범위 선택
단어 단위 멀티 선택 (반복)	Ctrl + D (반복)	Cmd + D (반복)	현재 단어 선택 후, 동일 단어를 추가로 순차 선택
전체 동일 단어 선택	Alt + F3	Ctrl + Cmd + G	문서 내 동일 단어를 모두 한 번에 멀티 커서로 선택
선택 해제 (하나씩 취소)	Ctrl + U	Cmd + U	마지막으로 추가된 커서(선택) 하나씩 되돌림(Soft Undo)

6. 창(화면) 분할 & 탭 이동

기능	Windows/Linux	macOS	설명
뷰 분할(2분할/3분할 등)	메뉴: View > Layout	메뉴: View > Layout	화면을 세로/가로/그리드 등으로 나누어 여러 파일을 동시 표시
다음 그룹(패널)로 이동	Ctrl + K, Ctrl + Right	Cmd + K, Cmd + Right	분할된 뷰 사이를 이동
이전 그룹(패널)로 이동	Ctrl + K, Ctrl + Left	Cmd + K, Cmd + Left	분할된 뷰 사이 이동 (반대 방향)
다음 탭 이동	Ctrl + Tab (또는 Ctrl + PageDown)	Cmd + Alt + Right (또는 Cmd + Shift + ])	여러 탭이 열려 있을 때 오른쪽 탭으로 이동
이전 탭 이동	Ctrl + Shift + Tab (또는 Ctrl + PageUp)	Cmd + Alt + Left (또는 Cmd + Shift + [)	여러 탭이 열려 있을 때 왼쪽 탭으로 이동
현재 탭 닫기	Ctrl + W	Cmd + W	현재 탭 닫기

7. 기타 자주 쓰는 단축키

기능	Windows/Linux	macOS	설명
자동 완성(팝업) 표시	Ctrl + Space	Ctrl + Space	코드/텍스트 자동완성 (기본 제공)
레이아웃 전환 (2-Column, 3-Column 등)	Alt + Shift + 2 (등등)	Cmd + Option + 2 (등등)	메뉴의 View > Layout > Columns/Rows 를 단축키로 (기본값은 OS나 버전에 따라 다를 수 있음)
매개변수 정보/도움말(플러그인에 따라 다름)	(기본 단축키 없음)	(기본 단축키 없음)	LSP 등의 플러그인 설치 시 설정 가능
콘솔 열기 (Sublime 내부)	Ctrl + ` (백틱 키)	Ctrl + `	Sublime Text 내부 콘솔 창을 열기
프로젝트 열기	Ctrl + Alt + P	Cmd + Alt + P	Quick Switch Project: 최근 프로젝트 목록에서 선택
실행(빌드)	Ctrl + B	Cmd + B	Build 시스템이 설정된 경우 현재 파일(프로젝트) 빌드/실행

8. 참고 사항

Sublime Text 4 (Build 4192) 기준
커스텀 Key Bindings
- 실제로 쓰시면서 필요한 단축키가 충돌하거나 불편하다면, Preferences > Key Bindings에서 직접 수정할 수 있습니다.
플러그인/패키지
- LSP, GitGutter 등 다양한 패키지를 설치하면 추가 단축키가 생기거나 기존 단축키가 재정의될 수 있습니다.
명령 팔레트( Ctrl + Shift + P / Cmd + Shift + P )
- Sublime Text에서 거의 모든 명령을 검색해서 실행할 수 있는 창이므로, 단축키가 기억나지 않을 때 유용합니다.

코드트리 두 달 사용 후기: 실무자가 추천하는 효과적인 코딩테스트 준비법

wonpick — Sun, 9 Mar 2025 22:38:47 +0900

이 포스팅은 코드트리 x 글또 블로그 챌린지 2기를 통해 코드트리 체험권을 받아 작성한 후기입니다.

안녕하세요. 저는 현재 데이터 엔지니어로 근무하고 있는 개발자입니다. 지난달에 이어 이번 달에도 코드트리 × 글또 블로그 챌린지 2기에 참여하며 두 달간 코드트리를 이용해봤는데요, 이번에는 실무에서 느낀 점과 실제 코딩테스트에 얼마나 도움이 되었는지 공유해 보겠습니다.

1. 코드트리의 강점, 맞춤형 학습 커리큘럼

코드트리의 가장 큰 장점 중 하나는 실력 진단을 통해 자신의 수준에 맞는 맞춤형 커리큘럼을 제공한다는 점입니다.

저는 Intermediate Low 단계에서 시작해 BFS, DFS, DP와 같은 알고리즘 문제를 중점적으로 공부했는데요, 덕분에 실무나 코딩테스트에서 자주 접하는 문제 유형을 보다 체계적으로 학습할 수 있었습니다.

특히 코딩테스트를 대비해 삼성이나 구글 같은 주요 기업의 실제 난이도와 유사한 문제들이 제공되어 실전 감각을 높이는 데 큰 도움이 되었습니다.

2. GitHub 연동 기능으로 체계적인 관리 가능

작년보다 더욱 개선된 GitHub 연동 기능 덕분에 풀이한 코드를 자동으로 업로드하고 손쉽게 관리할 수 있었습니다. 풀이 과정을 기록하고, 주기적으로 복습하면서 제 코드가 얼마나 효율적으로 발전하고 있는지를 한눈에 확인할 수 있어 편리했습니다.

3. 실무자가 본 코드트리의 실질적 가치

실제 업무를 진행하면서 코드트리에서 쌓은 경험이 상당히 유익하다는 것을 느꼈습니다.

코드트리의 다양한 문제 유형과 풀이 직후 제공되는 명확한 해설은 실무에서도 문제 접근법을 빠르게 찾는 데 효과적이었고, 자연스레 업무 효율성도 올라갔습니다. 문제를 체계적으로 접근하는 습관이 생긴 것도 큰 수확이라 생각합니다.

4. 아쉬웠던 점들

물론 개선이 필요한 부분도 몇 가지 있었습니다.

문제 사이를 이동할 때 종종 로딩 시간이 길어지는 점
일부 페이지에서 영문 설명이 갑자기 나타나는 등 자잘한 버그
작년에 있었던 업적 뱃지 시스템이 사라진 점
UI 개선 이후 메뉴 찾기가 다소 어려워진 점

이런 점들은 향후 코드트리가 개선하면 좋을 것 같습니다.

5. 두 달간의 변화, 그리고 앞으로의 계획

두 달 동안 코드트리를 꾸준히 이용하며 확실히 코딩테스트에 대한 자신감이 생겼습니다.

실제로 전형에서 진행하는 코딩테스트 환경과 비슷한 문제들을 코드트리를 통해 경험해볼 수 있었고,
이 덕분에 긴장하지 않고 안정적으로 문제를 풀어낼 수 있었습니다.

앞으로도 코드트리를 계속 활용하면서 부족한 부분을 더욱 탄탄히 다져나갈 계획입니다.

코딩테스트 준비에 어려움을 겪고 있는 분들이 있다면, 코드트리를 적극적으로 추천합니다.

특히 IT 기업에서의 실무 능력 향상까지 고려하고 있다면, 코드트리가 더욱 큰 도움이 될 것입니다.

Spark에서 .option("someKey", "someValue") 와 같이 정의되지 않은 옵션을 줘도 에러가 나지 않는 이유

wonpick — Fri, 7 Mar 2025 16:52:57 +0900

아래 글은 Apache Spark에서 데이터를 읽거나 쓸 때, .option("key", "value") 형태로 임의 옵션을 넘기면 왜 에러가 나지 않고 무시될 수 있는지, 그리고 MongoDB Spark 커넥터처럼 버전에 따라 옵션 이름이 달라질 때 어떤 일이 생기는지 간단히 정리한 포스트입니다.

0. 배경

Spark에서는 DataFrameReader(또는 DataFrameWriter)를 사용할 때
예)

df = (
    spark.read
        .format("mongodb")
        .option("uri", "mongodb://...")
        .option("pipeline", '[{ "$project": {...} }]')  # 예: 파이프라인 옵션
        .load()
)

이런 식으로 .option("key", "value")로 설정값을 넣습니다.
하지만 정의되지 않은 옵션이나 버전마다 다른 키명을 사용할 경우, Spark가 해당 옵션을 모르겠다며 즉시 에러를 내지 않고 그냥 무시해버리는 상황이 발생할 수 있습니다.

1. Spark의 옵션 전달 구조

(1) Spark 자체가 옵션 키를 직접 검증하지 않는다

Spark Core 레벨에서 .option("someKey", "someValue")는 내부적으로 (String -> String) 매핑을 만들어,
해당 DataSource(커넥터)로 그대로 전달합니다.
Spark는 “이 옵션이 맞는지 틀린지”를 미리 판단하지 않습니다.

(2) DataSource(커넥터) 쪽에서만 유효성 검사

실제로 MongoDB Spark 커넥터나 CSV/JSON 리더 등이 “이 옵션을 지원하느냐 마느냐”를 결정합니다.

만약 커넥터가 pipeline 옵션을 인식하면 쓰고,
인식하지 못하는(정의되지 않은) 옵션이면 무시하고 별도 에러 메시지를 주지 않는 구현이 많습니다.

따라서 키 이름이 틀리거나, 커넥터 버전이 달라서 옵션 이름이 바뀌었거나, 그냥 오탈자를 넣더라도 Spark는 문제삼지 않고 넘어가는 거죠.

2. MongoDB Spark 커넥터 버전에 따른 예시

예를 들어,

구 버전 커넥터에서는 aggregation.pipeline 라는 키를 써야하고
최신 버전에서는 pipeline 키로 받도록 바뀌었다고 가정합니다.

만약 최신 버전에 맞춰 예시 코드를 봤는데, 내 프로젝트의 커넥터 버전이 낮아서 pipeline 키를 인식하지 못한다면, 아래처럼 작성해도:

df = (
    spark.read.format("mongodb")
    .option("uri", "mongodb://...")
    .option("pipeline", '[{ "$project": {...} }]')  # <- 커넥터가 모르는 옵션
    .load()
)

이 옵션은 무시될 뿐, 스파크가 “pipeline이라는 옵션은 지원되지 않습니다”라는 에러를 내주지 않습니다. 결과적으로 파이프라인이 적용되지 않은 채로 데이터를 읽게 됩니다(또는 스키마 충돌을 일으킬 수도 있고요).

이렇게 filtering하는 pipeline 옵션 (select (Projection)을 무시하고 전체 필드를 다 불러옴

위 예시는 pipeline옵션이 몽고 커넥터의 버전(mongodb spark connector10.1.1) 에 없는 옵션값이어서

제대로 select 기능이 동작하지 않고 전체 필드를 다 불러오는 것을 볼 수 있습니다.
(스파크 몽고 커넥터 option 구성 참고 : https://www.mongodb.com/ko-kr/docs/spark-connector/v10.1/batch-mode/batch-read-config/)

✔️좌) 제대로 몽고커넥터 버전에 맞는 option명시 ✔️우) 몽고커넥터 무시하고 pipeline으로 잘못된 옵션 명시

반대로, 옛날 코드에서 aggregation.pipeline라고 썼는데, 최신 커넥터는 이걸 사용하지 않고 pipeline만 지원한다면, 그 값 역시 무시됩니다. 이처럼 커넥터 버전이 바뀌면 옵션 이름이 변할 수 있고, 잘못된 옵션명을 넘기면 Spark는 별도 경고 없이 그대로 무시하는 경우가 대부분입니다.

3. 예외: 일부 DataSource는 에러나 경고를 줄 수도 있다

모든 커넥터가 “알 수 없는 옵션을 조용히 무시”하는 것은 아닙니다.
CSV(Spark 내장)처럼 일부 포맷은 특정 옵션이 잘못될 시 경고를 주거나, “필수 옵션이 빠졌다”며 에러를 낼 수도 있습니다.
다만, 이런 처리는 DataSource 구현체가 “어떤 옵션 목록을 검사할지” 결정하는 것이고, Spark Core 레벨에서 강제되는 것은 아닙니다.

4. 실제 현장에서 생기는 문제점

오탈자 문제Spark가 이를 무시해버리면, 파일을 헤더 없이 읽어 들이고, 사용자는 왜 컬럼명이나 데이터가 깨지는지 한동안 찾아야 하는 상황이 생길 수 있습니다.
.option("heaer", "true") # 'header'를 오타로 입력
버전 호환성 문제⭐️⭐️⭐️
- “문서/블로그 예시 코드”에서는 pipeline 옵션을 쓰라고 했는데, 내가 사용하는 커넥터 버전이 aggregation.pipeline만 지원하면, 설정이 적용되지 않음.
- 반대로 최신 버전이 pipeline로 바뀌었는데, 옛날 옵션 키를 그대로 쓰면 작동 안 함.
- Spark 에러가 명확히 나오지 않으니, 사용자가 디버깅에 시간을 많이 쏟을 수 있습니다.

5. 요약 및 권장사항

Spark의 .option(...)는 전역 옵션 전달 방식
- Spark는 (키, 값)을 받아서 DataSource로 넘길 뿐, 정의되지 않은 키에 대해 에러를 내지 않습니다.
커넥터 버전마다 옵션 키가 달라질 수 있음
- MongoDB Spark 커넥터 등에서는 pipeline, aggregation.pipeline, partitionerOptions.numPartitions 등 옵션 키가 버전에 따라 변경되기도 합니다.
권장:
1. 공식 문서나 소스 코드를 확인해, 해당 버전에 맞는 옵션 키를 사용해야 합니다.
2. 오탈자 없이 정확히 입력하도록 주의하세요(특히 header vs heaer 같은 실수).
3. 로그나 코드에서 .option(...) 설정을 점검하고, 정말로 적용됐는지 explain이나 결과값으로 검증해보는 습관이 필요합니다.

⭐️요약 정리⭐️
✔️ “정의되지 않은 옵션 or 틀린 키”를 써도 Spark는 기본적으로 무시한다.
✔️ 이로 인해 “원하는 설정이 전혀 적용되지 않는” 문제가 발생할 수 있음.
✔️ 버전이 달라지면 옵션 키 이름도 달라질 수 있으므로, 반드시 버전에 맞는 공식 문서를 확인하자.

6. 같이 보면 좋은 내용

MongoDB Spark Connector 문서
Spark CSV/JSON/Parquet Options
Spark DataFrameReader / DataFrameWriter .option() 사용 예시와 오탈자 관련 이슈

위 문서를 보며 정확한 옵션 키를 확인하자!!!!!!!!!!!!!!

이상으로 “왜 Spark는 옵션에 엉뚱한 키를 줘도 에러가 없나?” 및 MongoDB 커넥터 버전별 옵션 차이가 빚어내는 문제를 정리해보았습니다. 개발 시엔 작은 오타 하나로도 큰 혼란이 발생하기 쉽기 때문에, 버전을 확인하고 옵션을 정확히 맞춰주는 게 중요하다는 것을 깨달았다.

Docker Jupyter 컨테이너에서 볼륨 마운트 시 권한 문제 발생 및 해결

wonpick — Thu, 27 Feb 2025 18:24:00 +0900

매번 컨테이너 생성 할 때마다 호스트(ec2-user)와 컨테이너 내부(jovyan)의 권한이 일치하지 않아

에러가 발생해 해결과정을 기록해본다.

구체적으로는 EC2에서 SSH로 접속한 ec2-user가

컨테이너 내부의 /home/jovyan/work 디렉토리 (호스트 디렉토리로 볼륨마운트) 에 대한 변경 권한이 없었기 때문에

발생한 문제로 어떻게 해결했는지 기록합니다.

1. 문제의 핵심 정리

EC2에서 SSH 접속 시, 기본적으로 호스트의 ec2-user(UID=1000, GID=1000)로 로그인.
Docker 컨테이너 내부의 jovyan은 UID=1000, GID=100(users).
/home/jovyan/work 디렉토리의 소유자가 root 로 되어 있어서 jovyan도 변경할 수 없는 상태였음.
chown -R 1000 /home/jovyan을 실행했지만, work 디렉토리는 root가 소유하고 있어서 permission denied 오류 발생.
- 즉, 컨테이너 내부에서 파일을 수정하려면 jovyan 권한이 필요하지만, work/의 소유자가 root라서 jovyan이 변경할 수 없었다.

2. 왜 EC2에서 접속했을 때 문제가 발생했을까?

일반적으로 SSH로 EC2에 접속하면 호스트(ec2-user)에서 실행되는 작업이 컨테이너 내부의 jovyan과 같은 권한을 가질 수 없음.

(1) EC2에서 실행한 명령어의 권한 문제

컨테이너를 이미 실행했다면 ec2의 uid가 어떻게 되어있는지 확인을 먼저 하고 소유자를 변경하면 된다.

#확인
cat /etc/passwd #하게되면 ec2-user에 대한 uid 확인
#ec2-user:x:1000:1000:EC2

EC2에서 실행한 명령어는 ec2-user 권한을 가짐.
하지만, 컨테이너 내부에서는 jovyan 권한을 사용하므로, root가 소유한 파일을 변경할 수 없음.
그래서 permission denied 오류가 발생함.

즉, EC2에서 실행하는 것 자체가 외부 사용자(ec2-user)가 컨테이너 내부 사용자(jovyan)의 파일을 수정하려고 시도한 것과 같음.

3. 해결 방법과 원리

✅ 해결 방법

0.docker run 실행 시 --user 추가

docker run -it --user 1000:100 -v /home/ec2-user/spark/work:/home/jovyan/work spark-3.5.3

1.컨테이너 내부에서 root 권한을 사용해 소유권을 변경

docker exec -it --user root <컨테이너 ID> bash
chown -R 1000 /home/jovyan
exit

--user root 옵션을 사용하여 컨테이너 내부에서 root 권한을 얻음.
root는 모든 파일을 변경할 수 있으므로, /home/jovyan/work의 소유권을 변경할 수 있음.
이미 실행 중인 컨테이너 내부에서 파일 소유권 변경

2. Dockerfile에서 미리 chown을 실행하여 컨테이너 생성 시 권한을 맞춤

#RUN groupmod -g  users #그룹은 따로 설정 안함
USER root
RUN usermod -u 1000 jovyan
RUN chown -R 1000 /home/jovyan
USER jovyan

이렇게 하면 컨테이너가 처음 실행될 때부터 권한이 정상적으로 설정됨.
다만 빌드 시점에 chown이 실행되므로 볼륨 마운트는 컨테이너 실행 시점에 적용되기 때문에 컨테이너가 실행되면서 다시 호스트 디렉토리가 덮어씌워지면서 root로 보일 수 있음

4. 결론

최종 원인

EC2에서 SSH로 접속한 ec2-user가 컨테이너 내부의 /home/jovyan/work 디렉토리를 수정하려 했지만,
해당 디렉토리는 root가 소유하고 있어서 jovyan도 수정할 수 없었음.
결국, 컨테이너 내부에서 root 권한을 사용해 소유권을 변경해야 했음.
혹은 docker run 할때 --user 에다가 uid 를 전달해줘도 됨.

root -> jovyan 변경되는걸 보면 됨. uid 변경

핵심 개념

EC2에서 실행하는 명령어는 기본적으로 ec2-user 권한을 가짐.
컨테이너 내부의 jovyan과 ec2-user는 UID가 같아도 권한은 다름.
root가 소유한 디렉토리는 jovyan이 직접 변경할 수 없음 → root로 변경 후 chown 실행 필요.
Dockerfile에서 미리 chown을 실행하면 실행할 때마다 권한 문제를 해결할 필요 없음.

코드트리 사용 후기: 다시 만난 코드트리 (작년과 어떤 점이 달라졌을까?)

wonpick — Sun, 9 Feb 2025 21:52:21 +0900

코딩테스트를 준비하며 효과적인 학습 도구를 찾던 중, 작년에 처음 코드트리를 접했습니다.

원하는 난이도의 문제를 쉽게 찾고, 상세한 해설을 제공받을 수 있어 인상 깊었습니다.

작년 1기에 이어 이번에 코드트리 X 글또 블로그 챌린지 2기에 참여하게 되어

한 달간 코드트리를 집중적으로 활용하며 서비스의 변화를 체험해 보았습니다.

학습 동기를 부여하는 XP 시스템

코드트리의 XP 시스템은 게임처럼 문제를 풀면서 경험치를 쌓고 목표를 달성하는 방식입니다.

학습 목표를 설정하고 이를 충족하면 성취감을 느낄 수 있어 꾸준한 학습을 유도하는 데 효과적이었습니다.

연속 학습 시 나무가 될 수 있다.

맞춤형 커리큘럼 제공

코드트리는 사용자의 실력에 맞춘 6단계의 Trail(커리큘럼)을 제공합니다.

Novice Low (Trail 1): 기초 문법 학습
Novice Mid (Trail 2): 기초 구현력 및 디버깅 연습
Novice High (Trail 3): 알고리즘 및 자료구조 객관식 문제 학습
Intermediate Low (Trail 4): BFS, DFS, DP 등의 기초 알고리즘 학습
Intermediate Mid (Trail 5): Two Pointer, 이분 탐색 등의 고급 알고리즘 학습
Intermediate High (Trail 6): Tree, 위상 정렬 등 심화 알고리즘 학습

각 단계별로 체계적인 학습이 가능하며, 사용자가 본인의 취약한 부분을 보완할 수 있도록 유도합니다.

저 역시 DP 문제에서 어려움을 겪었기 때문에 Intermediate Low 커리큘럼을 선택해 실력을 향상시킬 수 있었습니다.

체계적인 학습 환경과 GitHub 연동

코드트리는 각 커리큘럼을 Chapter와 Lesson 단위로 세분화하여 보다 체계적인 학습을 지원합니다.

개념 학습 → 문제 풀이 → 실력 점검이라는 흐름을 통해 사용자의 문제 해결 능력을 향상시키는 방식이 인상적이었습니다.

또한, GitHub 연동 기능을 활용하면 풀이 기록을 자동으로 저장할 수 있어 복습이 훨씬 편리했습니다.

UI/UX 개선과 목표 기업 실력 진단

1년 전과 비교해 코드트리는 UI/UX 측면에서 상당한 개선이 있었습니다. 더욱 직관적인 디자인과 다국어 지원(한국어, 영어)이 추가되었으며, 목표 기업 코딩테스트 실력 진단 기능도 새롭게 도입되었습니다.

삼성, 구글 등의 기업 기준에 맞춘 실력 진단을 받을 수 있으며, 이를 기반으로 맞춤형 학습 코스까지 제공됩니다.

아쉬운 점

전반적으로 만족스러웠지만, 몇 가지 개선이 필요한 부분도 있었습니다. 문제 사이를 이동할 때 로딩 시간이 다소 길어지는 경우가 있었으며,

일부 페이지에서는 영문 설명이 나타나는 등의 자잘한 버그도 있었습니다.

또한, 기존의 업적 뱃지 시스템이 사라진 점은 게이미피케이션 요소를 즐기던 사용자들에게 아쉬운 부분이 될 수 있을 것 같습니다.

뿐만 아니라 UI가 변경되면서 이전보다는 직관적으로 원하는 부분을 찾기가 힘들어

사이트내에서 계속 헤매게 되었던 적이 많아졌던 것 같습니다.

마무리

한 달 동안 코드트리를 활용하면서 코딩 테스트 실력을 보다 체계적으로 향상시킬 수 있었습니다.

특히 맞춤형 커리큘럼과 GitHub 연동 기능이 학습의 지속성을 유지하는 데 큰 도움이 되었습니다.

앞으로도 남은 한 달 동안 코드트리를 적극 활용하여 부족한 부분을 확실히 보완할 계획입니다. 코드트리는 코딩 테스트를 준비하는 이들에게 강력한 학습 도구가 될 것이라 확신합니다.

남은 한달동안도 더 1월보다 더 열심히 문제를 풀어 발전된 모습을 기록해보고 싶습니다.

EMR Serverless와 Step Functions으로 Spark ETL 구축하기

wonpick — Sun, 2 Feb 2025 23:57:39 +0900

아래 글은 EMR Serverless + Step Functions: Python to Spark

마이그레이션 작업을 위해 실험을 했던 과정을 기록한 것으로 잘못된 부분이 있거나, 최적화 되지 못한 부분이 존재할 수 있습니다.

1. 개요

기존에는 물리 서버에 구축된 jupyter hub환경에서 python으로 데이터 처리 후 아래와 같은 구조로 작업을 진행했다.

기존 환경에서는 빠른 개발과 테스트가 가능했지만, 확장성과 유지보수 측면에서 한계가 있었다.

기존 구조

또한, Python에서도 multiprocessing 같은 라이브러리를 활용하면 멀티프로세싱을 통해 병렬 처리를 수행할 수 있다. 하지만, 이러한 방식은 기본적으로 단일 머신의 CPU 리소스에 제한 되기 때문에, 대량의 데이터를 다룰 때는 결국 클러스터 기반의 분산 처리가 필요했고, 이에 따라 Spark로의 마이그레이션을 고려하게 되었다.

처음 Spark로의 전환을 고민할 때는 EMR Serverless를 바로 선택한 것이 아니라, 기존 EMR(EC2 기반)을 먼저 도입하여 Spark 마이그레이션을 진행해보자는 접근 방식을 택했다. 기존 EMR을 활용하면 EC2 인스턴스를 사용하여 YARN 기반의 Spark 클러스터를 직접 운영할 수 있고, 기존 Python 코드를 점진적으로 PySpark로 변환하는 작업을 진행할 수 있었다. 이 방식은 기존의 온프레미스 환경에서 클러스터를 운영하는 것과 비슷한 구조이기 때문에 비교적 익숙한 방식으로 진행할 수 있었다.

첫 구상안

그러나 EMR을 운영하면서 몇 가지 문제점이 나타났다.

✅ 첫 번째로, 비용 문제였다. EMR(EC2 기반)에서는 클러스터가 항상 실행되고 있어야 했기 때문에, 작업을 수행하지 않는 유휴 시간에도 인스턴스 비용이 지속적으로 발생했다. 또한, 스팟 인스턴스를 활용하여 비용을 절감할 수는 있었지만, 장기적으로 볼 때 EMR을 계속 운영하는 것은 비용적으로 부담이 되는 구조였다.

✅ 두 번째 문제는 운영 관리의 복잡성이었다. EMR 클러스터는 Spark 설정, YARN 리소스 관리, Auto-Scaling 설정 등 여러 가지 튜닝이 필요했다. 작은 규모에서는 문제가 되지 않았지만, Spark Job을 여러 개 실행하거나 데이터 처리량이 변동될 경우 적절한 리소스 관리를 위해 클러스터를 조정해야 하는 부담이 컸다.

이러한 문제를 해결하기 위해 EMR Serverless로 전환을 결정했다. EMR Serverless는 클러스터를 직접 관리할 필요 없이, Spark Job을 실행할 때 필요한 만큼만 리소스를 할당하고 작업이 끝나면 자동으로 리소스를 해제하는 방식을 제공했다. 덕분에 비용이 사용한 만큼만 과금되며, 관리 부담도 최소화할 수 있었다.

또한, Step Functions을 활용하여 EMR Serverless + Step Functions + Spark로의 전환으로 데이터 처리 워크플로우를 자동화 해보기로 했다.

이번 블로그 시리즈에서는 기존 Python 기반의 데이터 처리 방식을 EMR Serverless 환경으로 마이그레이션하는 과정 중에서 EMR Serverless를 StepFunction에서 실행하고 그 과정에서 고려해야 할 사항 등을 정리해볼 예정이다.

2. EMR Serverless에서 Spark 구조

참고로 내가 spark 작업을 하면서 헷갈렸던 부분인 deploy mode에 대해서 먼저 정리를 하고 가겠다! Spark에서는 deploy-mode를 선택하는 것이 매우 중요한데, 이는 Driver의 실행 위치와 클러스터 자원 할당 방식이 결정되기 때문이다.

현재 로컬 환경에서 Standalone Mode로 Client Mode로 실행하여 디버깅한 뒤, 최종적으로 EMR Serverless에서 Spark Job을 실행하는 방식으로 운영 중인데, emr serverless에서는 당연하게도 Client Mode 지원이 되지 않는다.

이유는 Driver를 사용자 머신에서 실행하는 방식(Client Mode)이 서버리스 환경과 맞지 않기 때문.
spark-submit을 실행할 때 기본적으로 Cluster Mode로 동작하며, Driver가 EMR Serverless 내부에서 실행됨.

즉, EMR Serverless에서는 모든 것이 Worker로 실행되며, Worker 내부에서 Driver와 Executor가 동작하는 구조이다.

따라서 Master Node를 관리할 필요가 없으며 그에 따른 YARN, Kubernetes, Standalone 등 클러스터 매니저 설정을 신경 쓸 필요 없다.

3. EMR Serverless, Step Functions에서 실행하기 위해 필요한 조건 - IAM Role 설정

State Machine IAM Role
- 목적 : Step Functions 실행 및 EMR Serverless 실행 관리
- 참고 문서:
  https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/setting-up.html#setting-up-iam

#Action부분만 기재 (참고용)
"states:StartExecution",
"states:DescribeExecution",
"states:StopExecution",
"states:GetExecutionHistory",
"emr-serverless:CreateApplication",
"emr-serverless:StartApplication",
"emr-serverless:StartJobRun",
"emr-serverless:GetJobRun",
"emr-serverless:StopApplication",
"dynamodb:ImportTable",
"dynamodb:DescribeTable",
"dynamodb:ListTables",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"iam:PassRole"

Step Functions Execution Role
- 목적 : EMR Serverless에서 Spark Job 실행 및 S3/DynamoDB 접근

#Action부분만 기재 (참고용)
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket",
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"

(선택) stepfuntion에서 dynamo import table을 위한
- + logs:GetLogEvents
- 참고 문서:
  https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataImport.Requesting.html

4. Step Functions 워크플로우 설계

(1) 기본 템플릿 생성

예시로 emr serverless 작업 실행을 선택해준다.

바로 생성하려고 하면 executionrole이 설정이 안되어있다고 하는데 위에서

EMR Serverless에서 Spark Job 실행 및 S3/DynamoDB 접근을 위해 생성한 role을 기재해준다.

기존에 stepfunction 실행을 위한 role을 만들어놨다면 선택해주고 그게 아니라면 생성도 가능하다.

최종적으로 생성한 stepfunction이다.

(2) 실제 설계한 워크플로우 예시

참고로 step function에서는 InitialCapacity를 명시적으로 설정하지 않으면 기본값이 할당된다.

특히 스토리지는 20GB 이하로 설정 시 에러가 나니 무조건 20GB 이상으로 설정해야한다.

EMR Serverless의 InitialCapacity 기본값

Component	기본 vCPU	기본 Memory	기본 Disk	Worker
Driver / Executor	4 vCPU	16 GB	20 GB	1

주요 제한 사항

참고:https://aws.amazon.com/ko/emr/faqs/?nc=sn&loc=5

CPU(vCPU)
- 각 작업자는 1, 2, 4, 8, 16 vCPU 중 하나만 설정 가능
메모리(GB)
- CPU 개수에 따라 최소/최대 메모리 설정 가능
- 1 vCPU → 최소 2GB, 최대 8GB (1GB 단위 증분)
- 16 vCPU → 최소 32GB, 최대 120GB (8GB 단위 증분)
디스크(Disk, GB)
- 최소 20GB, 최대 200GB
- 기본적으로 20GB는 무료이며, 20GB 초과 부분만 비용 부과됨

(3) Step Functions JSON 정의 예시 (job run 부분만)

아래 부분에서 기본 템플릿과 다른 점은 job 실패 시 바로 stop application으로 가도록 설정한 부분이다.

실제 실행할 spark job 스크립트를 s3에 업로드 후 해당 경로를 EntryPoint에 입력해준다.

"EntryPoint": "s3://S3-BUCKET/scripts/my_spark_job.py"

뿐만 아니라 중간에 잡이 실패할 경우 디버깅이 필요하므로 log를 기록할 경로도 기재해준다.

S3에 로그를 기록하는 기본 옵션을 택했다.

"LogUri": "s3://S3-BUCKET/logs/"

(참고로 Spark 작업에서 job의 에러 로그 및 print() 되는 출력은 항상 Driver에서 확인해야하므로 SPARK_DRIVER/stdout.gz 에서 확인하면 된다.)

    "B2B_GP_Count_Processing": {
      "Type": "Task",
      "Resource": "arn:aws:states:::emr-serverless:startJobRun.sync",
      "Arguments": {
        "ApplicationId": "{% $ApplicationId %}",
        "ExecutionRoleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/emr_serverless_execution_role": {
          "SparkSubmit": {
            "EntryPoint": "s3://S3-BUCKET/scripts/my_spark_job.py"
          }
        },
        "ConfigurationOverrides": {
          "MonitoringConfiguration": {
            "S3MonitoringConfiguration": {
              "LogUri": "s3://S3-BUCKET/logs/"
            }
          }
        }
      },
      "Assign": {
        "FirstJobId": "{% $states.result.JobRunId %}"
      },
      "Next": "ImportTable",
      "Catch": [
        {
          "ErrorEquals": [
            "States.TaskFailed"
          ],
          "Next": "Stop Application",
          "Comment": "Stop application on any occasion"
        }
      ]
    },

5. 로컬에서 Step Functions 자동 배포 및 실행

조금 더 정리를 했지만 로컬에서 stepfunction을 바로바로 수정 실행 할 수 있게 deploy.sh 라는

스크립트를 만들어 조금 더 빠르게 반영될 수 있게 하였다.

#!/bin/bash

# ✅ S3 버킷 및 상태 머신 JSON 파일 설정
BUCKET_NAME="your-s3-bucket/scripts"
JSON_FILE="your_state_machine.asl.json"
STATE_MACHINE_ARN="arn:aws:states:your-region:your-account-id:stateMachine:your-state-machine"

# ✅ S3 Key Prefix 및 DynamoDB 테이블명 설정
end_ym=$(date -d "$(date +%Y-%m-01) -2 month" +%Y%m)  # 현재 날짜 기준 2달 전 연월 (YYYYMM)
mmdd=$(date +%m%d)  # 현재 날짜 (MMDD)
NEW_S3_KEY_PREFIX="dynamo_import_path/gzip_${end_ym}"
NEW_TABLE_NAME="dynamo_table_${end_ym}v${mmdd}"

# ✅ 인자값 확인 (PySpark 작업이 2개 실행되므로 스크립트 2개가 필요함)
if [ "$#" -ne 2 ]; then
    echo "Usage: ./deploy.sh <PYSPARK_SCRIPT_1> <PYSPARK_SCRIPT_2>"
    exit 1
fi

PYSPARK_SCRIPT_1=$1
PYSPARK_SCRIPT_2=$2

# ✅ PySpark 스크립트 S3 업로드
echo "Uploading PySpark scripts to S3..."
aws s3 cp "/path/to/your/scripts/$PYSPARK_SCRIPT_1" "s3://$BUCKET_NAME/"
aws s3 cp "/path/to/your/scripts/$PYSPARK_SCRIPT_2" "s3://$BUCKET_NAME/"

# ✅ 상태 머신 JSON 업데이트
echo "Updating state machine JSON file..."

# 1️⃣ 첫 번째 PySpark 스크립트 (`B2B_GP_Processing` 단계 업데이트)
sed -i '/"B2B_GP_Processing"/,/^ *}/ {
  s|"EntryPoint": *"s3://[^"]*\.py"|\"EntryPoint\": \"s3://'"$BUCKET_NAME"'/'"$PYSPARK_SCRIPT_1"'\"|
}' "$JSON_FILE"

# 2️⃣ 두 번째 PySpark 스크립트 (`B2B_GP_Save_DynamoDBjson` 단계 업데이트)
sed -i '/"B2B_GP_Save_DynamoDBjson"/,/^ *}/ {
  s|"EntryPoint": *"s3://[^"]*\.py"|\"EntryPoint\": \"s3://'"$BUCKET_NAME"'/'"$PYSPARK_SCRIPT_2"'\"|
}' "$JSON_FILE"

# 3️⃣ DynamoDB 테이블 및 S3 경로 업데이트
sed -i "s|\"S3KeyPrefix\": \".*\"|\"S3KeyPrefix\": \"${NEW_S3_KEY_PREFIX}\"|" "$JSON_FILE"
sed -i "s|\"TableName\": \".*\"|\"TableName\": \"${NEW_TABLE_NAME}\"|" "$JSON_FILE"

# ✅ Step Functions 상태 머신 업데이트
echo "Updating Step Functions state machine..."
aws stepfunctions update-state-machine \
    --state-machine-arn "$STATE_MACHINE_ARN" \
    --definition file://"$JSON_FILE"

# ✅ Step Function 실행
echo "Starting Step Function execution..."
aws stepfunctions start-execution --state-machine-arn "$STATE_MACHINE_ARN"

echo "Deployment complete!"

이후에는 step function으로 설계했던 것을

airflow를 활용하여 워크플로우를 설계하고 스케쥴링 될 수 있게 제작을 진행하여 step function과 위 deploy.sh는 더이상 사용하지는 않지만 기록용으로 기재한다.

6. 결론

EMR Serverless와 Step Functions을 활용해서 PySpark 데이터 파이프라인을 자동화하는 과정을 정리해봤다.

EMR Serverless를 활용하면 클러스터를 직접 관리할 필요 없이 Spark Job을 실행할 수 있고, Step Functions을 통해 데이터 파이프라인을 자동화할 수 있다. 이를 위해 IAM Role과 iam:PassRole 설정이 필수이며, 상태 머신(JSON)을 활용해 실행할 PySpark 스크립트를 동적으로 변경할 수 있다. 배포를 자동화하기 위해 deploy.sh 스크립트를 사용하면 PySpark 스크립트를 S3에 업로드하고 Step Functions을 업데이트 및 실행할 수 있다. 결과적으로, 반복적인 작업을 자동화하고 운영 부담을 줄일 수 있으며, 확장성과 유지보수성이 향상된다.

다음에는 Spark 성능 최적화 및 dynamoDB JSON 관련한 내용을 다뤄보도록 하겠다.

1. 참고 : https://github.com/aws-samples/emr-serverless-samples

Teleport 기반 Core Tunnel 도입으로 로컬 개발 환경 효율성 극대화하기

wonpick — Sun, 5 Jan 2025 23:00:16 +0900

0. 개요

JupyterHub를 통해 개발을 하고 있고 Teleport의 HTTP Proxy 기능을 활용해 원격 사용자가 웹 브라우저를 통해 안전하게 접속할 수 있도록 설정되어 있습니다.

최근 Teleport를 사용한 Proxy 연결 중 알 수 없는 끊어짐이 간헐적으로 발생하고 있어, 세션 안정성을 강화하기 위한 대안으로 SSH 기반의 기술을 통해 WEB JupyterHub를 사용할 수 있는 환경을 구축하기로 하였습니다.

그렇게 결론을 짧게 말하자면 SSH 연결을 통해 vs code에서 로컬 개발 환경을 구축하여 간단하게 작업도 가능하게 되었습니다.

Teleport를 사용하고 있음에도 왜 core tunnel이라는 것을 도입했는지, 도입했을때의 장점에 대해 알아보도록 하겠습니다.

특징	Teleport HTTP Application	core tunnel - SSH (Secure Shell)
프로토콜	HTTP(S)	SSH 프로토콜
연결 안정성	HTTP는 상태가 없는(stateless) 프로토콜로, 세션 유지에 의존적	SSH는 상태가 있는(stateful) 연결을 유지
끊김 원인	네트워크 지연, HTTP 세션 만료, Keep-Alive 설정 불량 등	주로 네트워크 불안정, 터널 설정 문제 등
목적	웹 애플리케이션 또는 HTTP 서비스에 주로 사용	터미널, 파일 전송, 포트 포워딩 등 광범위한 서버 작업 지원
VSCode와의 연동	간접적으로 지원 (HTTP를 통한 REST API 통신)	VSCode의 Remote SSH 확장 프로그램에서 직접적으로 지원

1. Core Tunnel이란 무엇인가?

Core Tunnel은 SSH(Secure Shell) 기반의 네트워크 터널링 기술로, 원격 서버와 로컬 머신 간에 암호화된 "터널"을 생성하여 데이터를 안전하게 주고받을 수 있는 방법입니다.

이를 통해 외부에서 직접 접근할 수 없는 내부 리소스(예: 원격 데이터베이스, 내부 API 서버)에 안전하게 접근할 수 있습니다.

Core Tunnel은 SSH 프로토콜의 포트 포워딩 기능을 활용하여 특정 포트를 안전한 통로로 연결합니다. 이를 통해 로컬 머신에서 원격 서버의 자원을 마치 로컬 리소스처럼 사용할 수 있게 합니다.

2. 왜 Core Tunnel이 필요한가?

기존 HTTP 기반의 통신 방식은 다음과 같은 문제를 야기할 수 있습니다:

끊김 현상:
- HTTP 기반 연결은 짧은 세션 유지 기간 때문에 데이터 전송이 끊기거나 세션이 종료되는 일이 잦습니다.
- 특히 Teleport와 같은 HTTP Proxy 기반 접근에서는 Session Replay와 같은 기능 활성화로 연결 불안정성이 더 증가할 수 있습니다.
외부 접근 제한:
- 원격 서버의 리소스는 방화벽이나 네트워크 정책에 의해 외부에서 접근할 수 없는 경우가 많습니다.
보안 취약성:
- 암호화되지 않은 연결은 네트워크 상의 데이터 도청이나 중간자 공격(Man-in-the-Middle)에 노출될 위험이 있습니다.

Core Tunnel은 이러한 문제를 해결하기 위한 대안으로 사용됩니다. SSH를 통해 암호화된 안전한 통신 채널을 제공하며, 끊김 현상을 줄이고 지속 가능한 세션을 유지합니다.

3. Core Tunnel의 장단점

장점:

보안성:
- SSH 암호화를 통해 모든 트래픽이 보호되며, 외부 공격에 안전합니다.
세션 안정성:
- Keep-Alive 기능을 통해 세션이 끊기지 않고 지속적으로 유지됩니다.
유연성:
- 원격 서버의 리소스와 로컬 애플리케이션 간의 통신을 간편하게 설정할 수 있습니다.
VPN 대체:
- 복잡한 VPN 설정 없이도 내부 네트워크 리소스에 접근할 수 있습니다.

단점:

초기 설정 복잡성:
- SSH 키 또는 인증 설정이 필요하며, 이를 구성하는 데 약간의 학습 곡선이 존재합니다.
세션 의존성:
- SSH 세션이 종료되면 터널도 함께 종료되므로, 세션 관리가 필요합니다.
성능 제한:
- 암호화/복호화 과정으로 인해 네트워크 성능이 약간 저하될 수 있습니다.

4. 신규 JupyterHub 작업환경에서 Core Tunnel 활용

문제점:
- 기존 Teleport를 통한 HTTP Proxy 기반 연결에서 끊김 현상이 자주 발생.
- 특히, Session Replay 기능 활성화로 인해 세션의 지속성이 떨어졌음.
대안:
- Core Tunnel을 통해 SSH 기반 세션을 제공.
- JupyterHub 등 다양한 도구가 안정적으로 연결될 수 있는 환경 조성.
결과:
- SSH 기반 Core Tunnel은 세션 안정성과 네트워크 보안을 동시에 강화.
- JupyterHub 및 데이터베이스 관리와 같은 작업에 높은 활용성을 제공.

5. Core Tunnel vs 다른 SSH 기반 기술

기능	Core Tunnel	Autossh	Ngrok	Teleport
SSH 기반	예	예	아니오	예
자동 재연결	예	예	아니오	예
보안	SSH 암호화	SSH 암호화	SSL 암호화	SSH 및 고급 보안
사용 편의성	높음	중간	매우 높음	중간
추가 기능	세션 관리 간단	세션 재연결	HTTP/TCP 터널링	인증 및 감사 로그
적합성	일반 터널링 및 포트포워딩	안정적인 세션 유지	간단한 리소스 노출	엔터프라이즈 환경

6.결론

Core Tunnel은 안전하고 지속 가능한 연결을 제공하며, 기존 HTTP 기반 세션의 끊김 문제를 효과적으로 해결합니다.

또한, JupyterHub와 같은 개발 환경에서는 Core Tunnel을 활용하여 작업의 연속성을 유지하고 네트워크 보안을 강화할 수 있는 최적의 솔루션으로 자리 잡을 수 있습니다.

특히, Core Tunnel은 원격 서버에 연결된 리소스를 로컬 환경에서도 마치 로컬 자원처럼 활용할 수 있도록 지원합니다. JupyterHub 에서도 기존에 사용하던 커널을 그대로 사용하여 개발이 가능합니다. 이를 통해 개발자는 로컬 머신에서 데이터베이스, JupyterHub, 또는 기타 원격 서비스에 안전하게 접속하며, 로컬 개발 환경에서 작업의 효율성을 높일 수 있습니다.

Core Tunnel를 도입했다고 하여 Teleport를 사용하지 않는 것이 아닌 개발 환경은 Teleport를 기반으로 동작하며, Teleport 세션을 통해 원격 서버에 접속한 후 추가적인 SSH 터널링을 설정한 형태로 작업을 진행하고 있습니다.

Docker 컨테이너에서 볼륨 마운트 파일 권한 문제와 해결 방법

wonpick — Tue, 10 Dec 2024 13:18:05 +0900

Docker를 사용하다 보면, 컨테이너 내부에서 볼륨 마운트된 파일에 접근하려고 할 때 권한 문제가 발생하는 경우가 있습니다. 특히, 기본적으로 설정된 컨테이너 사용자의 UID와 호스트 파일의 소유자가 다를 때 이런 문제가 두드러집니다. 이번 글에서는 이 문제의 원인과 해결 방법을 정리해 보겠습니다.

1. 문제 상황

Docker 컨테이너에서 Jupyter 기반의 PySpark 환경(jupyter/pyspark-notebook)을 설정한 후, 호스트 디렉터리를 컨테이너와 공유하기 위해 다음과 같이 볼륨 마운트를 설정했습니다.

docker run -d --name dwspark \
  -v /home/dawon/projects/spark_notebook/sparkdata:/home/jovyan/sparkdata \
  -v /home/dawon/projects/spark_notebook/work:/home/jovyan/work \
  -p host port:8888 \
  -p host port:4040 \
  dwspark:0.1

컨테이너 내부에서는 /home/jovyan 사용자가 파일을 관리하도록 되어 있지만, 볼륨 마운트된 디렉터리의 파일은 호스트 파일 시스템의 소유권과 권한을 그대로 유지합니다. 이로 인해 다음과 같은 문제가 발생했습니다.

컨테이너 내부에서 jovyan 사용자가 볼륨 마운트된 파일을 수정하려고 할 때 "Permission denied" 오류 발생.
호스트 파일의 소유자가 UID 2011로 설정되어 있었지만, 컨테이너 내부의 jovyan 사용자는 기본적으로 UID 1000이었음.
UID 불일치로 인해 컨테이너 내부에서 파일에 대한 접근 권한이 제한됨.

2. 원인 분석

(1) 볼륨 마운트의 특성

Docker의 볼륨 마운트는 호스트 파일 시스템과 컨테이너 파일 시스템을 연결합니다. 하지만 이 과정에서 파일 소유자 및 권한 정보는 호스트 파일 시스템의 설정을 따릅니다.
따라서, 컨테이너 내부에서 특정 파일의 소유자 정보를 확인해 보면 다음과 같은 상황이 발생합니다.

호스트 파일의 소유자가 UID 2011이라면, 컨테이너 내부에서도 UID 2011로 표시됨.
컨테이너 사용자가 UID 1000이라면, 이 사용자는 해당 파일의 소유자가 아니므로 읽기/쓰기 권한이 제한됨.

(2) UID 불일치

컨테이너 내부의 기본 사용자 jovyan은 UID 1000을 사용합니다. 하지만 호스트 파일의 소유자는 UID 2011로 설정되어 있었기 때문에, 컨테이너 내부에서는 파일 소유권이 맞지 않아 권한 문제가 발생했습니다.

3. 해결 방법

이 문제를 해결하기 위해 컨테이너 내부와 호스트 간의 UID를 일치시키거나, 파일 권한을 조정하는 방법이 필요합니다. 아래는 이를 해결하는 세 가지 방법입니다.

(1) 컨테이너 사용자의 UID를 호스트와 맞추기

Dockerfile을 수정하여 컨테이너 내부의 jovyan 사용자의 UID를 호스트와 동일하게 설정합니다.
아래는 이를 구현한 Dockerfile 예제입니다.

FROM jupyter/pyspark-notebook:spark-3.3.0

USER root
# 컨테이너 내부 jovyan 사용자의 UID를 2011로 변경
RUN usermod -u 2011 jovyan
# 변경된 UID에 맞게 홈 디렉터리 소유권 수정
RUN chown -R 2011 /home/jovyan
USER jovyan

이 Dockerfile을 기반으로 이미지를 빌드한 후 실행하면, 컨테이너 내부의 jovyan 사용자가 호스트 파일의 소유자 UID와 일치하게 되어 권한 문제가 해결됩니다.

(2) 호스트 파일의 소유권 변경

호스트 파일의 UID를 컨테이너 내부 사용자와 동일하게 변경할 수도 있습니다. 이 방법은 다음 명령어를 사용해 구현합니다.

sudo chown -R 1000:1000 /home/dawon/projects/spark_notebook/sparkdata
sudo chown -R 1000:1000 /home/dawon/projects/spark_notebook/work

이 명령어는 호스트 파일 소유자를 UID 1000으로 변경하여, 컨테이너 내부의 기본 사용자 jovyan과 일치시킵니다. 그러나 이 방법은 호스트의 다른 사용자가 파일에 접근할 경우 문제를 일으킬 수 있으므로 주의가 필요합니다.

(3) 파일 권한 완화

테스트 환경에서만 사용할 수 있는 간단한 방법으로, 호스트 파일의 권한을 모든 사용자에게 열어주는 것입니다.

chmod -R 777 /home/dawon/projects/spark_notebook/sparkdata
chmod -R 777 /home/dawon/projects/spark_notebook/work

이렇게 하면 권한 문제는 해결되지만, 보안상 취약점이 있으므로 프로덕션 환경에서는 권장되지 않습니다.

4. 정리 및 결론

컨테이너에서 볼륨 마운트를 사용할 때 권한 문제를 해결하려면, 호스트와 컨테이너 간의 UID를 일치시키는 것이 가장 안전하고 권장되는 방법입니다. Docker 컨테이너에서 볼륨 마운트를 효과적으로 사용하려면, UID와 권한 설정을 정확히 이해하고 관리해야 합니다. 이 글이 비슷한 문제를 겪는 분들에게 도움이 되길 바랍니다!