<div id="readability-page-1" class="page"><div><p><img src="https://velog.velcdn.com/images/joosing/post/07463e9d-0586-4114-bb73-56adfb5f111e/image.png"></p>
<p>계획에 없었는데 AWS 서밋 둘째 날도 참석하게 되었다. 아무것도 준비해오지 않아 급히 서울에 숙소를 잡고 다이소에서 속옷과 양말을 구매했다. 티셔츠는 오늘 받은 굿즈로 해결. 하루 더 남길 잘했다고 생각한다.</p>
<h2 id="진짜-원인이-뭐지">진짜 원인이 뭐지?</h2>
<p>한 발표에서 런타임 프로세서를 Intel 계열에서 AWS의 Graviton으로 변경하고 겪은 호환성 이슈와 트러블 슈팅 과정을 공유해 주셨다. 프로세서 변경후 CPU 사용률이 100%를 찍고 한동안 유지되다가 일정 시간 후 복구되는 문제가 발생했다고 했다. 공유해 주신 트러블슈팅 과정은 의존 라이브러리(JDK 등)의 버전업을 수행하면서 문제 현상이 어떻게 변하는지 관찰하는 것이었고 결론 역시 의존 라이브러리 버전업을 통해서 문제 현상이 제거된 것을 확인했다는 것이었다. 마지막으로 ARM 기반 프로세서를 사용한다면 ARM 관련 JDK 이슈들을 확인하고 최신 패치를 모두 적용하라고 조언해 주셨다. 발표를 들으며 진짜 원인이 뭐였는지 계속 궁금했는데 더 자세히 공유되지 않아 내심 아쉬웠다. 그러고 보니 나는 트러블슈팅에 관심이 많은 사람 같다. 돋보기를 들고 로그를 살피기도 하고, 가설을 세워 검증해 보기도 하는 트러블슈팅 과정은 한편으로 인내심이 필요하고 고통스럽지만 재미있는 일인 것 같다. 발표 끝에 저런 문제 내가 풀어보고 싶다. 나 잘 할 수 있는데 이런 생각을 하고 있었다. 언젠가 트러블슈팅과 관련된 딥한 공유를 해보고 싶다는 생각도 추가했다.</p>
<h2 id="ec2elastic-compute-cloud에-대해">EC2(Elastic Compute Cloud)에 대해</h2>
<p>워크로드 특성에 맞는 인스턴스 선택이 중요하다고 설명하셨다. 내 애플리케이션이 일반적인 서비스를 수행하는지, 컴퓨팅 집약적인 작업이 많은지, 메모리 또는 디스크 성능이 중요한 작업이 많은지에 따라 적합한 EC2 인스턴스 선택이 필요함에 대해 이해할 수 있었다. 그리고 Graviton이라는 AWS에서 개발한 프로세서를 선택하면 비용절감을 누릴 수 있으며(대신 호환성 체크 중요) EC2 같은 경우 항상 최신 인스턴스를 선택하는게 가성비가 좋음을 강조해서 설명하셨다. AWS에서 같은 가격에 더 나은 성능을 제공하기 위해 노력하고 있음을 느낄 수 있었다.</p>
<h2 id="스토리지-서비스에-대해">스토리지 서비스에 대해</h2>
<p>저장소 역시 데이터를 다루는 워크로드 특성에 맞게 적합한 스토리지 서비스를 선택해야 함을 설명해 주셨다. 스토리지 서비스는 크게 S3(Simple Storage Service) EBS(Elastic Block Store), EFS(Elastic File System), FSX가 있음을 설명해 주셨다. 그리고 각각 파일을 다루는 특성에 따라 다양한 옵션들이 존재해서 최적의 서비스를 선택할 수 있음을 설명해 주셨다. S3같은 경우 파일 접근 빈도에 따라 파일을 적합한 클래스로 분류한다거나 EBS를 SDD나 HDD로 선택한다거나 EFS 역시 접근 빈도에 따라 분류하고 파일의 고가용성을 위해 Multi Zone에 구성할 것인다 One Zone에 구성할 것인지 등 다양한 옵션이 있었다. </p>
<h2 id="aiml-사례">AI/ML 사례</h2>
<p>기업의 90%가 2035년까지 자사 어플리케이션에 AI를 적용하게 될 거란 예측이 사실이 될 것 같았다. 그리고 AI가 기존 비지니스를 강화하는 방향으로 나아갈 수도 있고, AI 자체가 하나의 비지니스가 되는 케이스도 있다고 나누어 설명해 주셨다. 그리고 엔지니어는 모델을 만드는 일에 집중하기 원하는데 실제로 모델 개발 이외에 아주 다양한 일들이 많이 필요함을 역설해 주셨다. 이 대목에서 엔지니어로서 약간의 부끄러움을 느꼇다. </p>
<h2 id="datadog-apm">Datadog APM</h2>
<p>발표자가 처음에 말을 너무 빨리 하셔서 듣기 편하지 않았는데 보여주고 싶은 중요한 것들이 많아서 그랬음을 이해할 수 있었다. 발표 시작과 함께 커피 쿠폰을 건 설문조사를 했는데 그 자리에 있는 수백명의 설문조사 응답 처리를 즉시 Datadog으로 모니터링하는 데모를 보여주는데 사용했다. 대담한 데모 시도였고 무척 신선하고 좋았다. 이분 발표 마치고 바로 Datadog 부스에 가서 태그를 남기고 왔다. AWS 서밋에 참석하기 전날 PinPoint를 공부해서 학습중인 애플리케이션 모니터링을 해보려고 했는데 Datadog으로 전향해야 겠다는 생각이 들었다. 트랜디한 업종, 회사에 근무하고 있지 않다면 이런 컨퍼런스에 참석하는게 중요함을 느꼈다. 데이터를 물어다 주는 강아지 이미지가 무척 마음에 든다. 그리고 서비스도 무척 매력적이게 느껴진다. 앞으로 친하게 지내봐야 겠다.</p>
<h2 id="sagemaker로-nolow-코드-기계학습">SageMaker로 No/Low 코드 기계학습</h2>
<p>조금 쌩뚱맞지만 AWS 서밋 전체 발표 중에 내게 가장 와닿고 즉시 적용해 볼 수 있겠다는 느낌이 든 건 SageMaker라는 서비스였다. 왜냐하면 이전 회사에서 지상국의 이상탐지 및 고장예측 모델 개발 파일럿 프로젝트를 진행하며 삽질을 해보았기 때문이다. 그때 머신러닝 모델 개발 프로세스에 대한 아무런 이해가 없었고 단지 그때 그때 필요하다고 판단되는 일들을 했는데 어제 설명해 주신 체계화된 프로세스와 무척 닮아 있어서 조금 놀랐다. 데이터를 모으는 일부터 힘들었고, 도메인 전문가들과 그 데이터에서 어떤 파라미터가 우리가 추론하려는 결과와 유의미하게 연관되는지 많은 토론을 했다. 그리고 여러 통계들을 적용해 진짜 의미 있는지 확인했었고 그래프를 그리는 간단한 도구도 직접 만들어 눈으로 확인했다. 그리고 그때 분류 모델을 만들려 했는데 데이터에 실패, 성공을 태깅하는데 도메인 전문가들이 엄청난 수작업을 했다. 결론은 실패 데이터가 너무 적어서 모델 성능이 잘 나올 수 없었다. 대신 통계적인 방법으로 더 좋은 방법을 찾았던 기억이 난다. 아무튼 SageMaker를 통해 저렇게 쉽게 기계학습 프로세스 진행이 가능함을 보고 큰 매력을 느꼈다. 내 전문 분야가 아니지만 취미로라도 한 번 해봐야 겠다는 생각이 든다. 우리 일상에 적용해 볼만 어떤 데이터가 있는지 찾게 된다.</p>
<h2 id="피할-수-없는-물결-그리고-키워드들">피할 수 없는 물결 그리고 키워드들</h2>
<p>AWS 서밋을 마치고 집으로 돌아오며 여러 키워드들이 머리속에 맴돈다. 그 동안 온프레미스 환경에서만 개발하고 운영을 해와서 다른 사람들에게 낯익은 기본적인 것들 조차 내게 다 새로웠다. 앞으로 학습하고 사용해 볼 키워드들을 정리해 본다. 하나씩 적용해 보는 단순한 프로젝트를 해보는 것도 유익하겠다. 이제 내게도 클라우드는 피할 수 없는 물결이 된 것 같다.</p>
<blockquote>
<ul>
<li>Elastic Compute Cloud (EC2), Simple Storage Service (S3), Elastic Block Store (EBS), Elastic File System (EFS)</li>
<li>Lambda, Simple Notification Service(SNS), Simple Queue Service(SQS), API Gateway(with WebSocket), Elastic Load Balancer (ELB), IoT Core MQTT(Message Queuing Telemetry Transport)</li>
<li>APM : Datadog</li>
<li>AI/ML : SageMaker</li>
<li>RDB : Aurora DB</li>
<li>NoSQL : MongoDB, DynamoDB</li>
</ul>
</blockquote></div></div>

Joo's Work

JooSing

계획에 없었는데 AWS 서밋 둘째 날도 참석하게 되었다. 아무것도 준비해오지 않아 급히 서울에 숙소를 잡고 다이소에서 속옷과 양말을 구매했다. 티셔츠는 오늘 받은 굿즈로 해결. 하루 더 남길 잘했다고 생각한다.
진짜 원인이 뭐지?
한 발표에서 런타임 프로세서를 Intel 계열에서 AWS의 Graviton으로 변경하고 겪은 호환성 이슈와 트러블 슈팅 과정을 공유해 주셨다. 프로세서 변경후 CPU 사용률이 100%를 찍고 한동안 유지되다가 일정 시간 후 복구되는 문제가 발생했다고 했다. 공유해 주신 트러블슈팅 과정은 의존 라이브러리(JDK 등)의 버전업을 수행하면서 문제 현상이 어떻게 변하는지 관찰하는 것이었고 결론 역시 의존 라이브러리 버전업을 통해서 문제 현상이 제거된 것을 확인했다는 것이었다. 마지막으로 ARM 기반 프로세서를 사용한다면 ARM 관련 JDK 이슈들을 확인하고 최신 패치를 모두 적용하라고 조언해 주셨다. 발표를 들으며 진짜 원인이 뭐였는지 계속 궁금했는데 더 자세히 공유되지 않아 내심 아쉬웠다. 그러고 보니 나는 트러블슈팅에 관심이 많은 사람 같다. 돋보기를 들고 로그를 살피기도 하고, 가설을 세워 검증해 보기도 하는 트러블슈팅 과정은 한편으로 인내심이 필요하고 고통스럽지만 재미있는 일인 것 같다. 발표 끝에 저런 문제 내가 풀어보고 싶다. 나 잘 할 수 있는데 이런 생각을 하고 있었다. 언젠가 트러블슈팅과 관련된 딥한 공유를 해보고 싶다는 생각도 추가했다.
EC2(Elastic Compute Cloud)에 대해
워크로드 특성에 맞는 인스턴스 선택이 중요하다고 설명하셨다. 내 애플리케이션이 일반적인 서비스를 수행하는지, 컴퓨팅 집약적인 작업이 많은지, 메모리 또는 디스크 성능이 중요한 작업이 많은지에 따라 적합한 EC2 인스턴스 선택이 필요함에 대해 이해할 수 있었다. 그리고 Graviton이라는 AWS에서 개발한 프로세서를 선택하면 비용절감을 누릴 수 있으며(대신 호환성 체크 중요) EC2 같은 경우 항상 최신 인스턴스를 선택하는게 가성비가 좋음을 강조해서 설명하셨다. AWS에서 같은 가격에 더 나은 성능을 제공하기 위해 노력하고 있음을 느낄 수 있었다.
스토리지 서비스에 대해
저장소 역시 데이터를 다루는 워크로드 특성에 맞게 적합한 스토리지 서비스를 선택해야 함을 설명해 주셨다. 스토리지 서비스는 크게 S3(Simple Storage Service) EBS(Elastic Block Store), EFS(Elastic File System), FSX가 있음을 설명해 주셨다. 그리고 각각 파일을 다루는 특성에 따라 다양한 옵션들이 존재해서 최적의 서비스를 선택할 수 있음을 설명해 주셨다. S3같은 경우 파일 접근 빈도에 따라 파일을 적합한 클래스로 분류한다거나 EBS를 SDD나 HDD로 선택한다거나 EFS 역시 접근 빈도에 따라 분류하고 파일의 고가용성을 위해 Multi Zone에 구성할 것인다 One Zone에 구성할 것인지 등 다양한 옵션이 있었다. 
AI/ML 사례
기업의 90%가 2035년까지 자사 어플리케이션에 AI를 적용하게 될 거란 예측이 사실이 될 것 같았다. 그리고 AI가 기존 비지니스를 강화하는 방향으로 나아갈 수도 있고, AI 자체가 하나의 비지니스가 되는 케이스도 있다고 나누어 설명해 주셨다. 그리고 엔지니어는 모델을 만드는 일에 집중하기 원하는데 실제로 모델 개발 이외에 아주 다양한 일들이 많이 필요함을 역설해 주셨다. 이 대목에서 엔지니어로서 약간의 부끄러움을 느꼇다. 
Datadog APM
발표자가 처음에 말을 너무 빨리 하셔서 듣기 편하지 않았는데 보여주고 싶은 중요한 것들이 많아서 그랬음을 이해할 수 있었다. 발표 시작과 함께 커피 쿠폰을 건 설문조사를 했는데 그 자리에 있는 수백명의 설문조사 응답 처리를 즉시 Datadog으로 모니터링하는 데모를 보여주는데 사용했다. 대담한 데모 시도였고 무척 신선하고 좋았다. 이분 발표 마치고 바로 Datadog 부스에 가서 태그를 남기고 왔다. AWS 서밋에 참석하기 전날 PinPoint를 공부해서 학습중인 애플리케이션 모니터링을 해보려고 했는데 Datadog으로 전향해야 겠다는 생각이 들었다. 트랜디한 업종, 회사에 근무하고 있지 않다면 이런 컨퍼런스에 참석하는게 중요함을 느꼈다. 데이터를 물어다 주는 강아지 이미지가 무척 마음에 든다. 그리고 서비스도 무척 매력적이게 느껴진다. 앞으로 친하게 지내봐야 겠다.
SageMaker로 No/Low 코드 기계학습
조금 쌩뚱맞지만 AWS 서밋 전체 발표 중에 내게 가장 와닿고 즉시 적용해 볼 수 있겠다는 느낌이 든 건 SageMaker라는 서비스였다. 왜냐하면 이전 회사에서 지상국의 이상탐지 및 고장예측 모델 개발 파일럿 프로젝트를 진행하며 삽질을 해보았기 때문이다. 그때 머신러닝 모델 개발 프로세스에 대한 아무런 이해가 없었고 단지 그때 그때 필요하다고 판단되는 일들을 했는데 어제 설명해 주신 체계화된 프로세스와 무척 닮아 있어서 조금 놀랐다. 데이터를 모으는 일부터 힘들었고, 도메인 전문가들과 그 데이터에서 어떤 파라미터가 우리가 추론하려는 결과와 유의미하게 연관되는지 많은 토론을 했다. 그리고 여러 통계들을 적용해 진짜 의미 있는지 확인했었고 그래프를 그리는 간단한 도구도 직접 만들어 눈으로 확인했다. 그리고 그때 분류 모델을 만들려 했는데 데이터에 실패, 성공을 태깅하는데 도메인 전문가들이 엄청난 수작업을 했다. 결론은 실패 데이터가 너무 적어서 모델 성능이 잘 나올 수 없었다. 대신 통계적인 방법으로 더 좋은 방법을 찾았던 기억이 난다. 아무튼 SageMaker를 통해 저렇게 쉽게 기계학습 프로세스 진행이 가능함을 보고 큰 매력을 느꼈다. 내 전문 분야가 아니지만 취미로라도 한 번 해봐야 겠다는 생각이 든다. 우리 일상에 적용해 볼만 어떤 데이터가 있는지 찾게 된다.
피할 수 없는 물결 그리고 키워드들
AWS 서밋을 마치고 집으로 돌아오며 여러 키워드들이 머리속에 맴돈다. 그 동안 온프레미스 환경에서만 개발하고 운영을 해와서 다른 사람들에게 낯익은 기본적인 것들 조차 내게 다 새로웠다. 앞으로 학습하고 사용해 볼 키워드들을 정리해 본다. 하나씩 적용해 보는 단순한 프로젝트를 해보는 것도 유익하겠다. 이제 내게도 클라우드는 피할 수 없는 물결이 된 것 같다.
Elastic Compute Cloud (EC2), Simple Storage Service (S3), Elastic Block Store (EBS), Elastic File System (EFS)
Lambda, Simple Notification Service(SNS), Simple Queue Service(SQS), API Gateway(with WebSocket), Elastic Load Balancer (ELB), IoT Core MQTT(Message Queuing Telemetry Transport)
APM : Datadog
AI/ML : SageMaker
RDB : Aurora DB
NoSQL : MongoDB, DynamoDB

피할 수 없는 클라우드 물결 (AWS Summit 2023 후기)

댓글