최근에 AWS SaaS Boot Camp를 참여하여 AWS와 SaaS에 대한 관심이 엄청 커진 상태에서 이번에는 AWS Summit Seoul 2023에 참여하게 되었습니다. AWS Summit Seoul은 국내 최대 IT 컨퍼런스로 코엑스 컨벤션 센터에서 5월 3일(수)~ 4일(목) 일정으로 이틀간 진행하며 이번에 9회차를 맞고, 저는 첫 번째로 참여하게 되었습니다. 다양한 분야의 전문가들과 다양한 주제로 컨퍼런스를 참여할 수 있어 기분이 좋았습니다.
코엑스 컨벤션 센터의 지하 1층부터 지상 3층까지 컨퍼런스 공간이 마련되어 있었습니다.
1층에 있는 Expo에는 다양한 전시와 체험할 수 있는 부스가 있었지만 시간이 많지 않았기 때문에 바로 기조연설을 참석하기위해 이동했습니다. 기조연설 컨퍼런스룸으로 이동하기전 그랜드볼룸 앞에는 AWS Summit Seoul 참여 횟수에 따른 랜덤 캡슐을 뽑는 부스가 있었는데요. 저는 첫 번째 참여였기 때문에 1회차 랜덤 캡슐을 뽑고 스티커를 받았습니다..!
아래는 랜덤으로 뽑은 스티커입니다. 다른 회차는 다른 상품이 있는지 좀 궁금하군요..ㅎㅎ
기조연설은 AWS 모니터링 및 관측성 담당 부사장인 Nandini님과 AWS Korea 대표이사 함기호님 등을 포함하여 AWS에 큰 기여를 하고 있거나 적용 사례를 가지고 있는 분들이 진행해주셨습니다.
기조연설은 오디토리움에서 진행되었고, 생각보다 엄청 넓은 공간이었고 준비가 잘 되어있는 것 같아 기대가 되었습니다.
기조연설은 AWS가 과거부터 어떻게 성장해왔고, 앞으로 고객들을 위해 어떤 방향으로 발전해나갈 것인지 설명해주셨습니다. 또한 AWS에 있는 다양한 서비스들을 통해 빠른 속도, 비용 절감, 고가용성 등의 이점을 살릴 수 있고, AWS를 통해 서비스 구축 시 어떤 포인트들을 생각하면서 아키텍처를 설계해야되는지 설명해주셨습니다. 기조연설을 통해 AWS의 전반적인 앞으로의 방향성과 다양한 이점에 대해서 리마인드되는 시간이었던 것 같습니다.
기조연설이 끝나고 이제 컨퍼런스를 듣기위해 컨퍼런스룸으로 움직였습니다. 1일차에는 산업 업종별 강연과 2일차에는 기술 주제별 강연을 이뤄져 있었습니다. 1일차에는 클라우드 네이티브, 메가트렌드, 금융 및 핀테크, 통신 및 미디어, 리테일 및 디지털커머스, 제조 및 하이테크, 공공 부문 분야가 있었고 저는 클라우드 네이티브와 메가트렌드 분야를 중점으로 컨퍼런스를 참여하였습니다.
산업 업종별 강연이다보니 각 서비스 업종별, 사용했던 기술별로 다양한 레퍼런스를 들을 수 있어서 너무 좋은 시간이었습니다. SaaS 서비스를 준비 중이다보니 AWS Public Cloud에서 SaaS 서비스 구축를 위한 시스템 아키텍처 설계, 대규모 트레픽을 처리하기 위한 방법, 안정적인 서비스 운영 방법, Observability를 통한 FinOps 등 다양한 지식을 얻을 수 있었습니다. 또한 AI와 MLOps 등에도 관심이 많았기 때문에 Generative AI로 SaaS 서비스를 운영하고 있는 스캐터랩의 AWS 활용법 사례를 듣는 시간 또한 너무 좋은 시간이었습니다.
내일인 2일차에는 기술 주제별 강연입니다. SageMaker와 SaaS 서비스 관련 최적화와 관련된 컨퍼런스를 들을려고 합니다. 관련 지식을 통해 실제 SageMaker를 통한 MLOps 구축과 SaaS 서비스 준비에 많은 도움이 되었으면 하는 바람이 큽니다. 두근두근한 마음으로 AWS Summit Seoul 2023 2일차를 참여하도록 하겠습니다....!!
현재 많이 사용하고 있는 Linux 배포판인 CentOS 7의 EOL이 2024년 6월 30일로 얼마 남지 않았습니다. 이에 따라 CentOS 7을 사용하는 많은 분들이 어떤 OS로 넘어갈지 고민에 빠져있을 것 같습니다. CentOS 7을 대체하기 위해서 Rocky Linux가 주목받고 있으며있으며 Rocky Linux를 설치하는 방법을 알아봅시다.
ISO 파일 다운로드
Rocky Linux 공식 홈페이지에서 최신 Rocky Linux 8 버전을 다운로드 받습니다. 최신 버전은 2022년 11월 14일에 Release된 8.7 버전입니다. https://rockylinux.org/download/
Rocky Linux 설치
Rocky Linux의 기본적인 설치 방법은 CentOS 7과 거의 동일하며 기존에 CentOS 7을 설치해보신 분들이라면 편하게 설치를 진행하실 수 있을 것 같습니다. 저는 Rocky Linux를 설치하기 위해 Hyper-V를 통해 진행하였습니다.
VM 실행 후 Rocky Linux 8 설치 화면에서 Install Rocky Linux 8을 선택합니다.
로딩 화면 후 설치 화면이 나오는데요. CentOS 7과 거의 동일한 것을 확인하실 수 있습니다. 언어 설정은 영어를 선택 후 넘어갑니다.
설치 메뉴 중 아래 화면에 체크한 항목을 설정 후 설치를 진행해보도록 하겠습니다.
첫 번째로는 TIME & DATE 설정입니다. Asia/Seoul로 설정합니다. 시간 설정은 설치 완료 후에도 수동으로 변경할 수 있습니다.
두 번째로는 SOFTWARE SELECTION 설정입니다. 저는 필요한 패키지만 설치하여 사용하기 위해 Server With GUI가 아닌 Minimal Install을 선택하였습니다. 기본 서버에 필요한 패키지를 설치하시려면 Server, 추가로 GUI 화면이 필요하시면 Server With GUI을 선택하시면 됩니다.
세 번째로는 INSTALLATION DESTINATION 설정입니다. 저는 수동으로 디스크를 설정하기위해 Custom을 선택하였습니다. 자동으로 설정되는 Automatic을 설정하셔도 상관 없습니다.
기본 디스크가 설정되도록 Click here to create them automatically를 선택합니다.
/home 디렉토리를 사용하지 않고 / 디렉토리만을 사용하기 위해 /home 디렉토리를 삭제하고 남은 디스크 용량을 / 디렉토리에 할당합니다.
설정 변경사항을 확인 후 적용합니다.
네 번째로는 KDUMP 설정입니다. 기본 설정은 사용하도록 체크되어있으며 사용하지 않을 것이므로 해제합니다.
마지막으로 ROOT PASSWORD 설정입니다. 설정하고자하는 ROOT PASSWORD를 입력하여 설정합니다.
설정이 완료되면 Begin Installation 버튼을 클릭하여 설치를 진행합니다.
설치가 진행되고 완료되면 Reboot System 버튼을 클릭하여 시스템을 재시작 합니다.
이제 시스템 부팅이 완료되면 설치된 Rocky Linux 커널 버전을 확인하실 수 있고, 로그인을 통해 Rocky Linux를 사용하실 수 있습니다.
AWS의 Amazon SageMaker를 통해 기존에 물리서버에서 하고있었던 기계 학습(Machine Learning) 환경을 Public Cloud 환경에서도 구현가능한지 확인해보고, 비용 측면이나 활용도 측면에서도 정말 좋은지 확인해보고자 작업을 진행하고 있습니다. Amazon SageMaker를 활용하기 위해 좀 더 알아본 내용과 AWS SageMaker 교육을 통해 알아본 내용을 같이 정리해보았습니다.
개요
Amazon SageMaker는 AWS에서 2017년 11월에 출시된 Cloud 기계 학습(Machine Learning) 서비스 입니다.
SageMaker를 사용하면 개발자가 Cloud 환경에서 기계 학습 모델을 생성, 학습 및 배포할 수 있습니다. 기계 학습을 위해 다양한 언어를 지원할 뿐만 아니라 학습 환경 구성, 학습, 배포하기 위한 pipeline을 제공하여 MLOps를 구현할 수도 있습니다. EC2에서 사용가능한 다양한 GPU 인스턴스를 제공하여 적합한 사양의 서버를 사용하여 기계 학습 시 사용할 수 있습니다. 제품 추천, 개인화, 지능형 쇼핑, 로봇 공학, 음성 지원 디바이스를 포함하여 20년에 걸친 Amazon의 실제 기계 학습 애플리케이션 개발 경험에 기반하여 구축된 서비스입니다.
사용 효과
아래 이미지는 AWS의 자료로 Amazon SageMaker를 사용하면 다양한 사용 효과를 얻을 수 있다고 합니다.
TCO(Total Cost of Ownership) : IT 인프라를 구매, 설치, 실행 및 유지 관리하는 과정에서 발생하는 모든 비용
개인적인 생각으로는 AWS의 GPU 인스턴스의 가격이 저렴하진 않기 때문에 비용적인 측면은 많은 고민이 필요할 것 같지만, MLOps를 구현한다면 팀 생산성 증가와 자동화로 인한 비용 감소를 예측할 수 있을 것 같다는 생각이 듭니다.
다양한 지원
선도적인 기계 학습 프레임워크, 도구 키트 및 프로그래밍 언어 등 다양한 지원을 통해 더욱 자유롭고 효율적으로 Amazon SageMaker를 사용할 수 있도록 지원하고 있습니다.
프로그래밍 언어 같은 경우에는 다양한 언어를 지원하지만 내부적으로 python을 기준으로 동작한다고하니 참고하시면 좋을 것 같습니다.
다양한 기능
기계 학습에 기본적으로 필요한 Train, Pipelines, Deploy 등 뿐만 아니라 기계 학습 환경을 자유롭고, 간단하게 구성하기 위한 Notebooks, Model Monitor, Studio, Feature Store, Automatic Model Tuning 등 다양한 기능을 제공하고 있습니다.
Amazon SageMaker Features
다양한 기능을 사용하여 최적의 학습 환경 및 MLOps를 구축할 수 있을 것 같습니다.
사용 고객
아래 이미지는 AWS의 자료로 Amazon SageMaker를해외 기업뿐만 아니라 국내 기업에서도 Amazon SageMaker를 많이 사용하고 있는 것을 확인하실 수 있습니다.
AWS 기술 블로그에서는 Amazon SageMaker를 사용하여 모델을 개발하거나, 어떤식으로 사용하였는지 다양한 정보를 확인하실 수 있습니다.
Jenkins 에서는 Artifact 플러그인 기능을 사용하여 생성된 Artifact를 저장하거나 복사하여 필요한 프로젝트 및 빌드에서 사용할 수 있습니다. Jenkins Pipeline에서 Artifacts 기능을 활용하는 방법을 알아봅시다.
Artifacts 정의
우선 Artifacts 기능을 활용하기 전에 Artifacts에 대한 정의를 알아봅시다.
위키백과에서는 Artifacts를 소프트웨어 개발 과정에서 생성되는 다양한 유형의 부산물 중 하나라고 설명하고 있습니다. 일부 Artifacts(예: 사용 사례, 클래스 다이어그램 및 기타 UML(Unified Modeling Language) 모델, 요구 사항 및 디자인 문서)는 소프트웨어의 기능, 아키텍처 및 디자인을 설명하는 데 도움이 되고, 다른 Artifacts는 프로젝트 계획, 비즈니스 사례 및 위험 평가와 같은 개발 프로세스 자체와 관련이 있다고 설명하고 있습니다.
artifacts로 파일 및 디렉토리 지정 시 glob 형식의 패턴을 통해 아래와 같이 사용할 수 있습니다.
### target 디렉토리에 있는 main.jar 파일 지정
archiveArtifacts artifacts: 'target/main.jar'
### target 디렉토리에 있는 *.jar 파일 지정
archiveArtifacts artifacts: 'target/*.jar'
### target 디렉토리에 있는 *.jar 파일과 *.war 파일 지정
archiveArtifacts artifacts: 'target/*.jar, target/*.war'
### 모든 디렉토리에 있는 *.jar 파일 지정
archiveArtifacts artifacts: '**/*.jar'
여러 옵션을 사용하여 아래와 같이 사용할 수도 있습니다.
excludes: 디렉토리 경로 및 파일의 패턴을 지정하여 제외할 수 있습니다. 설정 패턴은 artifacts와 동일하게 사용 가능합니다.
allowEmptyArchive: 빌드 아티팩트가 없는 경우도 아카이브에 추가할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 아카이브가 빈 상태가 될 수 있습니다.
caseSensitive: 아카이브 내 파일 이름 검색시 대소문자를 구분할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 대소문자를 구분합니다.
defaultExcludes: 아카이브에서 기본적으로 제외할 파일을 결정합니다. 기본값은 true이며, false로 설정하면 Ant 파일 패턴을 사용하여 제외할 파일을 지정할 수 있습니다.
fingerprint: 빌드 아티팩트의 지문(fingerprint)을 생성하여 추적할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 빌드 아티팩트가 변경될 때마다 새로운 지문이 생성됩니다.
followSymlinks: 심볼릭 링크를 따라가서 링크가 가리키는 실제 파일을 아카이브할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 심볼릭 링크가 아닌 실제 파일이 아카이브됩니다.
onlyIfSuccessful: 빌드가 성공했을 때만 아카이브를 생성할지 여부를 결정합니다. 기본값은 false이며, true로 설정하면 빌드가 실패했을 때는 아카이브를 생성하지 않습니다.
Artifact 복사 (copyArtifacts)
archiveArtifacts{} 구문을 통해 저장된 파일을 copyArtifacts{} 구문을 통해 복사할 수 있습니다. 기본적인 구문은 아래와 같이 사용됩니다. projectName 필드 설정으로 가져올 빌드의 이름을 지정하여 파일을 복사하는 설정입니다. 다른 프로젝트 빌드에 저장되어 있는 Artifact를 복사하여 사용할 수도 있습니다.
이제 저장된 Artifact를 복사하여 사용하기 위해 아래와 같이 코드를 구성하였습니다. pipeline-project-name 이름으로 저장된 빌드의 Artifact를 설정하고, 동일하게 'vendor/**, bin/**' 디렉토리를 지정하였습니다. 복사하는 Artifact는 build/ 디렉토리에 저장되도록 구성하였으며 복사할 Artifact가 없더라도 빌드가 실패하지 않도록 설정하였습니다.
Window 환경의 Jenkins에서 Cannot run program git.exe 에러 발생 시 해결하는 방법입니다.
Jenkins에서 Pipeline 실행 시 git.exe를 실행하지 못할 경우 아래와 같이 에러가 발생합니다.
git.exe 파일의 경로를 찾지 못하는 것으로 Jenkins 웹 관리자 페이지에서 Jenkins 관리 -> Global Tool Configuration 설정을 통해 git.exe 경로를 추가해줍니다. Git installations 설정 중 Path to Git executable 설정을 Window 환경에 맞는 값으로 설정합니다.
설정 저장 후 다시 Pipeline 실행 시 정상적으로 git.exe를 실행하는 것을 확인하실 수 있습니다.
지금까지 Cannot run program git.exe 에러 발생 시 해결하는 방법을 알아보았습니다...! 끝...!
GitLab 프로젝트 연동과 간단히 Pipeline을 동작하는 설정을 완료하였고, 이제 WebHook을 연동하여 Commit 등의 Event 시 자동으로 Jenkins Pipeline이 동작되도록 설정해봅시다.
WebHook 설정
설정하고자하는 Pipeline의 상세 설정의 Build Triggers 설정합니다.
Trigger 받고자하는 Event를 선택하고 자동으로 생성되는 WebHook URL을 복사해둡니다.
하단의 고급 버튼을 클릭하여 상세 설정을 확인합니다.
Secret token 항목에서 Generate 버튼을 클릭하여 GitLab WebHook과 연동할 token 값을 생성합니다. 해당 token 값은 이후에 사용해야하므로 복사해둡니다.
설정을 완료하면 Pipeline 설정을 저장합니다.
이제 GitLab 프로젝트에서 WebHook 설정을 추가해봅시다. GitLab 프로젝트 Settings -> Webhooks 메뉴를 클릭합니다.
아까 복사해둔 WebHook URL 값과 Secret token 값을 URL, Secret token 항목에 붙여 넣습니다.
그리고 사용하고자 하는 Trigger Event를 선택해주시면 됩니다.
WebHook 설정을 추가하면 아래와 같이 추가된 설정을 확인하실 수 있습니다.
Test를 통해 WebHook이 정상적으로 연결되었는지 확인합니다.
정상적으로 WebHook 설정이 완료되었으면 상단에 "Hook executed successfully: HTTP 200" 메시지가 출력된 것을 확인하실 수 있습니다.
WebHook 테스트
WebHook 연동 설정이 완료되었으므로 해당 프로젝트에서 소스 코드 수정 및 Commit 후 자동으로 Pipeline이 동작하는지 확인합니다. Pipeline 관리 페이지를 열어둔 상태에서 프로젝트에 Commit을 해봅니다. WebHook 연동 설정을 통해 자동으로 Pipeline 빌드가 실행됩니다.
Pipeline 빌드가 완료되면 해당하는 Build ID 클릭 후 아래와 같이 빌드 상태를 확인할 수 있습니다.
지금까지 Jenkins에서 GitLab 프로젝트와의 연동과 WebHook을 통한 Pipeline 자동화 구축 작업을 완료하였습니다...! 끝...!
