첫 시작은 거의 백만 블로거가 되는것 마냥 장황하게 세워뒀었다ㅋㅋㅋ

•  ADP 공부 과정 정리
•  DataOps 개념 정리
•  사이드프로젝트 과정 공유

나 혼자 올리는 거면 정말 대충 써서 올릴텐데(-> 아마 하지도 않을듯) 글또를 같이 하고 있는 사람들이 볼수도 있다고 생각하니 읽기 좋은 글을 쓰고 싶다는 욕심이 커져서 그런지 생각보다 2주에 하나씩 글을 써서 제출하는게 쉽지만은 않았다.

그래서 무엇을 해냈나 !!!

처음에 계획했던 것들 중에 ADP 공부 과정은 따로 업로드 하지는 못했지만 재수를 통해 필기까지는 합격을 받아둔 상태이고, 실기는 한 3년여만에 데이터 분석을 하려고하니 손이 쉽게 움직이지는 않는것 같아 마음의 여유를 가지고 유효기간내에 도전해볼 생각이다.

DataOps 개념은 내 나름대로 정한 나의 커리어 패스 중 하나인데, 회사에서의 조금은 답이 없는 일을 반복하면서 스트레스가 계속 쌓이며 두달동안 안식월을 다녀오는 큰 이슈가 하나 있었다.

사실 안식월이 글또에서 멀어지게된 큰 이유가 된 것 같다. 긴 휴식을 가져야겠다는 생각이 들면서 부터 내가 개발을 하는게 맞을까? 컴퓨터쪽을 하는게 맞을까 하는 원론적인 고민을 하면서 쉬는 동안 노트북을 들여다본날이 정말 열흘도 안되는것같다.

오히려 이런 시간을 통해서 내가 정말 하고 싶은일이 무엇이고 회사를 잘 다닐수 있도록 무엇을 해내면 좋을지를 깊게 고민할 수 있는 시간이었다.

마지막으로 사이드 프로젝트는 현재진행형이다. 지금은 기억 저 넘어에 존재하는 React.js를 꺼내가며 열심히 화면을 만드는 Frontend 개발을 하고 있는데 처음 글또를 지원하면서 작성했던 내 Role을 Backend 로 제출했더니 백엔드 빌리지에 속하게 되어서 글또 제출용 글을 적기에는 조금 동떨어진다는 느낌이 들어서 이 주제에 대한 글은 한개정도 작성했던 것 같다.

다음달 정도에 테스트 오픈을 할 계획이니 많.관.부!

글또를 계속 할건지?

이건... 잘 모르겠다. 다른 업계 분들과 소통하며 활동하는 점은 정말 좋았는데 내 현실과는 다른 모습들에 현타를 조금 느껴서 스스로 업그레이드를 한 다음 다시 시작해보고 싶다.

그리고 내가 생각보다 너무 게으르다!! 퇴근하고 책상에 앉는 일이 이렇게 힘든건줄 몰랐다... 그래서 남은 2023은 나 자신에 집중하면서 몸과 마음의 건강을 먼저 챙겨보려고 한다.

Access to XMLHttpRequest at 'https://test.site/w1/indicator&team&2017' from origin 'https://test.site' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

이 오류는 뭐람...😂

분명 Insomnia를 사용해서 API 테스트를 했을때는 Response 200으로 정상 동작함을 확인했음에도 왜 이런 오류가 발생했는지 명확하게 알아두기 위해 이번 게시글을 작성하게 되었다.

CORS 란

Cross-Origin Resource Sharing의 줄임말로 교차 출처 리소스 공유라고 직역할 수 있다. 이렇게 번역된 말만 가지고 봤을때는 어떤 의미 인지 설명되기 어렵기 때문에 하나하나 다가가보고자 한다.

Origin(출처)

어떤 사이트를 방문하고자 할때는 인터넷 주소창에 URL이라는 문자열을 통해 접근하게 된다. URL은 하나의 문자열 같지만 사실은 다음과 같이 여러개의 구성 요소로 이루어져 있다.

여기서 Origin은 Protocol + Host + Port가 결합된 URL이라고 보면 된다. (위 경우에는 Port가 생략됨) 간단하게 자바스크립트로도 현재 사이트의 Origin을 알아낼 수도 있다.

console.log(location.origin);

출처의 동일함은 URL의 구성 요소 중 Protocol + Host + Port 가 동일하면 동일 출처로 판단하게 된다.

SOP(Same Origin Policy)

▶︎ 동일한 출처에서만 리소스 공유 가능 즉, 다른 출처(Cross-Origin) 서버에 있는 리소스는 상호작용이 불가능.

서로 다른 출처를 가진 두 어플리케이션이 자유롭게 리소스를 주고 받을 수 있는 환경에서는 CSFR(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 해커가 개인 정보를 가로챌 수 있는 가능성이 존재한다.

이런 악의적인 경우를 방지하기 위해 SOP 정책으로 동일하지 않는 다른 출처의 스크립트가 실행되지 않도록 브라우저 단에서 방지하게 된다.

출처 비교와 차단을 브라우저가 하기 때문에 서버 에러로 착각하기 쉽다. 현재 구성중인 서비스는 Backend(API) 서버와 Frontend 서버가 분리되어 있기 때문에 insomnia로 호출했을때 정상적으로 반환된 데이터가 실행중인 Frontend에서 Axios로 API를 호출했을때 CORS 오류가 발생했던 것이다!

현실적으로 SOP만을 적용해서 서비스를 제공하기에는 어려움이 존재하기 때문에 몇가지 예외 조항을 두고 Cross-Origin도 허용하도록 한 것이 CORS이다.

CORS 동작 프로세스

1. 클라이언트에서 HTTP 요청의 헤더에 Origin을 담아 전달
2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달
3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교 3-1. 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 차단 여부를 결정 3-2. 만약 유효하지 않다면 그 응답을 사용하지 않고 버린다 👉🏻 CORS 에러

마무리

CORS가 동작하는 프로세스를 살펴보면 결국 서버에서 허용하는 Origin(URL)을 알고 있다면 CORS 에러는 발생하지 않게 된다는 점을 알 수 있었다.

API 구성 코드에 아래와 같은 코드를 추가하여 간단하게 해결하였다.

...
# CORS 오류 방지를 위한 Origin 정보 등록
from starlette.middleware.cors import CORSMiddleware

origins = [
    "test.site.com" 
]

app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)
...

그동안 개발에서 잠깐 멀어진 생활을 하다보니 이렇게 쉽게 해결할 수 있는 문제들도 마냥 어렵게만 느껴지는 것 같다. 남은 휴직 기간동안 이 토이 프로젝트를 진행하면서 부족한 부분들을 기록으로 남기면서 다시 개발에 재미를 느끼고 싶다.

친구들과 재미로 하고 있는 프로젝트에 쿠버네티스를 사용한 무중단 프로그램을 만들기 위해 기본 개념을 공부할 겸 정리해보았습니다 :)

Docker란?

컨테이너 기반의 오픈소스 가상화 플랫폼이다. 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐 등 어떤 프로그램도 컨테이너로 추상화할 수 있고, 조립PC, AWS, Azure, Google Cloud등 어디에서든 실행 가능하다.

컨테이너는 격리된 공간에서 프로세스가 동작하는 기술로 가상화 기술의 하나지만 기존 OS를 가상화하는 방식과는 차이가 존재함.

• OS 가상화 : 호스트 자체를 가상화하기 때문에 비교적 사용법이 간단하지만 무겁고 느려서 운영환경에서는 사용하기 어려움
• CPU의 가상화, 반가상화 : 게스트 OS를 수정하여 게스트 OS가 가상화되고 있음을 인식하도록 하여 하이퍼바이저가 필요할 때 자동 호출(하이퍼콜) 되도록 하는 것, 반가상화는 하이퍼바이저가 호출되어야 하는 횟수를 최소화함으로 성능을 대폭 향상시킬 수 있지만, 게스트 OS가 수정되어야 하기 때문에 OS 소스코드에 접근 가능해야하고 도입이 어려움.
• 프로세스 격리 : 운영체제에서 프로세스를 격리시키는 방법. 리눅스에서는 이 방식을 리눅스 컨테이너라고 하고 가볍고 빠르게 동작한다. CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하고 성능적으로도 거의 손실이 없다.

컨테이너의 특징

1. 실행중인 컨테이너에 접속하여 명령어를 입력할 수 있고, apt-get이나 yum으로 패키지를 설치할 수 있으며 사용자도 추가하고 여러 개의 프로세스를 백그라운드로 실행할 수도 있다. CPU나 메모리 사용량을 제한할 수 있고 호스트의 특정 포트와 연결하거나 호스트의 특정 디렉토리를 내부 디렉토리인 것처럼 사용할 수도 있다.

2. 이미지는 컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것으로 상태값이 변하지 않는다. 즉, 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장된다. 따라서 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 삭제되더라도 이미지는 변하지 않고 그대로 남아있게 된다. 이미지파일의 크기는 클 수 밖에 없는데 기존 이미지에 파일 하나 추가했다고 다시 수백메가를 다운받는 일은 비효율적이다. 도커는 이런 문제를 해결하기 위해 레이어라는 개념을 사용하고 유니온 파일시스템을 이용하여 여러 개의 레이어를 하나의 파일시스템으로 사용할 수 있게 해준다.

컨테이너를 생성할 때도 레이어 방식을 사용하는데 기존의 이미지 레이어 위에 읽기/쓰기 레이어를 추가한다. 이미지 레이어를 그대로 사용하면서 컨테이너가 실행중에 생성하는 파일이나 변경된 내용은 읽기/쓰기 레이어에 저장되므로 여러 개의 컨테이너를 생성해도 최소한의 용량만 사용하게 된다.

Kubernetes란?

여러 개의 호스트를 하나로 묶어 관리하기 위한 오케스트레이션 툴. Pod : 쿠버네티스의 최소 배포 단위로 1개 이상의 컨테이너, 네트워크, 스토리지 등이 포함된다. 여러 호스트를 하나로 묶어 관리하기 때문에 분산 환경에서 여러 대의 컴퓨팅 자원을 한 대의 컴퓨터처럼 운영할 수 있다.

주요기능

1. 여러 서버에 동작하는 Pod관리
2. Pod 간 네트워크 관리
3. Pod의 부하분산
4. Pod의 모니터링
5. 무중단 배포 및 업데이트(Rolling Update)

쿠버네티스 클러스터는 크게 클러스터의 모든 상태를 저장/관리하는 Master와 실제 Pod를 운영하는 Node로 구성된다.

Kubernetes Master.

1. API Server 쿠버네티스에서 가장 중요한 컴포넌트. 쿠버네티스 내부의 모든 동작은 HTTP/HTTPS REST API를 통해 호출된다. 각각의 쿠버네티스 컴포넌트가 서로 직접 연결 형태가 안니 API Server를 경유하여 통신하고 컴포넌트들은 API Server를 보고 있다가 자신과 관련된 부분의 변경사항이 있으면 변경사항을 업데이트 하게 된다.

2. Controller Manager ReplicaSet, Deployment등의 Controller는 Pod의 복제/배포를 변경하는 명령을 수행하고 Pod의 상태를 관리한다. Controller Manager는 이 Controller들을 데몬형태로 포함하고 있다.

• Desired State : Pod는 Deployment, ReplicaSet에서 사용자가 설정한 Pod 수를 유지하는 것 Controller Manager에서 현재 상태를 감시하다가 Desired State와 다르면 설정한 수를 유지하기 위한 작업을 실행하여 사용자가 지정한 Pod의 수를 유지한다.

3. Scheduler 어떤 Pod를 어떤 Node에서 실행할 지 결정. 각 Node의 자원 사용 현황, 노드당 클러스터 분배 비율을 기반으로 컨테이너를 배치한다. Node에 배치된 Pod는 각 Node의 Kubelet 컴포넌트에 의해 컨테이너로 생성된다.

4. Etcd 분산 key/value 저장소 클러스터 설정 및 현재 상태(클러스터의 각 노드, 노드에서 동작중인 Pod 등의 모든 상태)를 저장. Service Discovery에서 사용하는 SkyDNS의 데이터를 저장한다.

Kubernetes Node

1. Kubelet Node 마다 한 개씩 있는 Node Agent 주기적으로 API Server에 Node 상태를 Check & Report Access하면서 Pod를 실행/중지하고 desired state를 유지한다.

2. cAdvisor 동작중인 컨테이너의 리소스 사용량과 퍼포먼스를 모니터링하고 모니터링한 결과는 Kubelet에 의해 Master의 API Server로 전달된다.

3. Kube-Proxy 네트워크 프록시 + 로드밸런서의 역할이다. 외부의 요청을 분한된 Pod로 전달하고 컨테이너간의 통신을 위해서 iptables rules를 변경한다.

4. Pod 쿠버네티스의 가장 작은 배포 단위로 컨테이너가 가장 작은 배포 단위가 아니라 Pod가 가장 작은 단위로 취급된다. 1개의 Pod 내부에는 1개 이상의 컨테이너가 존재한다. 1개의 Pod는 여러 개의 물리서버에 나눠지는 것이 아니고 1개의 물리서버(Node)위에 올라간다. Pod 내부의 컨테이너들은 네트워크와 볼륨을 공유하기 때문에 localhost로 통신이 가능하다.

하나의 큰 서비스를 작은 단위로 쪼개서 원하는 서비스를 조합하는 아키텍처 MSA는 여러개의 작고, 독립적인 서비스들을 조합하여 복잡한 application을 만드는 Architecture이다.

각각의 독립적인 서비스는 MSA에 유연성을 부여하고 이 유연성은 개발 및 운영 과정에 많은 이점을 가져다 준다.

Monolithic Architecture Vs. MicroService Architecture

Monolithic이란, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태를 말한다. 모든 서비스가 하나의 파일로 묶인 뒤 배포되어 동작하게 된다.

서비스들의 경계가 모호하고 하나의 DB를 공유하고 있는 구조로 서로 의존성이 높아질 수 밖에 없다. 따라서 서비스가 변경되거나 DB가 변경되면 연관된 서비스들도 변경해야하는 문제가 발생하게 된다.

하나의 파일로 묶여서 배포가 되기 때문에 서비스의 한 부분을 수정한다면 전체 프로젝트를 다시 패키징해서 배포해야되는 상황이 발생하기 때문에 일반적으로는 소규모 프로젝트에 더 적합하다.

소규모 프로젝트에 적용한다면 통합되어 있기때문에 간단한 형태를 갖고있어 유지보수에 용이하게된다.

MicroService Architecture는 대규모 프로젝트에 더 적합하다. microservice는 완전히 독립적으로 배포가 가능하고, 서로 다른 기술 스택을 사용하여 단일 비즈니스 로직을 구현한 것으로 각각의 작은 단위의 서비스를 나누어 개발하기 때문에 전체 서비스가 커지는 경우 시스템 구조 파악에 유리한 점이 있다.

각 서비스는 논리적으로 DB를 나누어(꼭 물리적으로 나눠져있을 필요는 없다) 사용하기 때문에 상호간의 결합이 약해 유연한 운영이 가능해진다.

MSA의 특징

API를 통해서만 상호작용할 수 있다. 각 서비스의 end-point를 API형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다. 따라서 SOA(Service Oriented Architecutre)의 특징을 다수 공통으로 가진다.

SOA

대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하고 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해가는 방법론이다. 업무 처리 변화를 시스템에 빠르게 반영하고자 하는 수요에 대응하는 방법론. 플랫폼에 종속되지 않는 표준 인터페이스를 통해 기업의 업무를 표현한 '느슨하게 연결되고 상호 조합 가능한 소프트웨어' SOA에서는 각각의 서비스가 데이터 계층, 비즈니스 로직, 뷰에 대한 모듈을 모두 가지고 있고, 각 서비스 간의 의존성이 최소화된다. SOA 시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해 이미 구현된 서비스가 있는지를 검색할 수 있어야 한다.

API GateWay

각 서비스에 접근하기 위해 사용되는 gateway loadbalancing

MSA로의 변환하기 위한 바탕

• MSA는 모든 Application에 적용할 수 있는 것은 아니다.
• MSA로 이동해야 한다면, 기존 Monolithic 에서 감수해 내야만 하는 것들을 결정해야 한다.
• 매우 드문 경우에만 Monolithic 모듈 그대로를 분리하여 MSA 화 할 수 있다. 그 외의 경우에는 기존 프로세스를 유지하지 못한다.(코드 레벨까지 수정 혹은 재개발이 필요함)
• MSA가 비즈니스 확장성 및 생산성에 큰 이점이 있는 것은 사실이지만, 어떤 경우에는 Monolithic을 그대로 유지하여 개발하고, 운영하는 것이 더 큰 비즈니스 밸류를 가져다 주기도 한다.
• Monolithic은 단일 객체 그 자체이기 때문에 해당 아키텍처에 속해있는 데이터 모델 및 데이터베이스를 변경하는 것은 매우 어렵거나 거의 불가능에 가깝다. 이를 위해서는 데이터에 대한 리팩토링이 필요하다.

MSA 변환의 이유

1.기존 모노리틱 구조의 한계점

1. 부분 장애가 전체 서비스로 전파된다.
2. 부분적인 서비스의 scale-out이 어렵다
3. 서비스의 개선이 어렵고, 수정 시 장애의 영향도 파악이 어렵다.
4. 서비스의 전체 코드가 하나의 프로젝트로 구성되어 배포가 오래걸린다.
5. 하나의 framework와 개발언어에 종속되어 서비스에 적절한 기술을 사용하기 어렵다.

--> 시스템을 여러 개의 서비스로 분리하여 서비스 간의 의존성을 제거하는 MSA로의 전환이 필요함.

모놀리식 아키텍처

UI, 비즈니스 로직 컴포넌트, 데이터관리 컴포넌트, 데이터들이 하나의 공간에서 밀접하게 연결되어 있음.

반면, 서비스 지향 아키텍처는 공통 또는 특정 결과를 처리하기 위해 비즈니스로직 컴포넌트와 데이터관리 컴포넌트를 하나의 단일 서비스화하여 반복적인 비즈니스 동작들을 논리적이며 독립적인 형태로 구분지어 분리해 놓음.

-> 마이크로서비스는 위의 서비스들을 더 잘게 나누기 위해 특정 도메인 바운더리, 즉 영역을 정의하고 해당 영역 안에서 필수불가결한 비즈니스 로직을 처리할 수 있도록 더 작은 단위로 서비스 화함.

2. MSA GOALS

1. 하나의 서비스 장애가 다른 서비스로 전파되지 않는다.
2. 코드 복잡성 및 의존성을 제거하여 영향도 파악을 용이하게 한다.
3. 고 가용성과 확장성을 확보한다.
4. 각 모듈의 독립성을 유지하기 위해서는 반드시 데이터가 분리되어야 한다.

   How to

   1. MicroService 분리

• Step 1. 모듈에 대한 식별 : 기존 모듈을 유지하거나, 새로운 모듈 작성
• Step 2. 데이터베이스 재정의 : 각 모듈에 해당하는 테이블을 분리하고 서비스로 wrap up
• Step 3. 코드 업데이트 : 새로운 서비스를 호출하기 위해 DB 테이블에 직접 호출했던 코드 업데이트
• Step 4. 위 방법을 지속적으로 강화 및 반복

주의 깊게 확인해봐야 하는 것들 현재 존재하는 많은 수의 Monolithic app은 위와 같은 방법으로 깔끔한 모듈화가 어렵다 테이블 간의 정규화, 엔티티 결합, 무결성 제약 조건 등을 유지하기 까다롭다. Monolithic에 복잡한 Query 코드를 작성했을 때, 어떤 테이블을 어떻게 사용했는지 이해하기 힘들 수 있다. 단순하게 모듈을 쪼개는 방식이 아닌 매우 까다롭고 비용이 많이 드는 Migration이 있을 수 있다. 모듈화를 진행하다 보면 오히려 쪼개지 않는 쪽에 이점이 많아질 가능성도 있다.

참조 https://ssup2.github.io/theory_analysis/Micro_Service_Architecture/ https://wooaoe.tistory.com/57

새롭게 시작하는 글쓰기 프로젝트!

3년간 회사 일을 하면서 주어진 업무를 열심히 해내는, 어떻게 보면 성실하지만 새로운 것을 찾아 떠나지는 않는 현재에 만족하는 게으른 인생을 살았던 것 같다.

선배들이 말하는 3.6.9 법칙이 내게도 적용된건지 작년 하반기부터는 시키는 일을 계속하면서 언제가부터 회의감이 들었던 와중에 1년 실적을 공유하는 문서에 내가 무슨일을 해왔는지를 적는데 1년간 커밋한 코드가 한줄도 없다는 사실을 깨닫고 “아.. 내가 원하는 일은 이게아닌데..”라는 생각이 그제서야 들었고 앞으로도 이런 일만 하다가는 정말 개발자라고 말하고 다니질 못할 것 같았다.

그동안 해왔던 업무들이 내 커리어에 도움이 안되는 일은 아니지만 현재의 나는 개발이 하고 싶다.

앞으로의 계획

• ADP 공부 과정 정리
• DataOps 개념 정리
• 사이드프로젝트 과정 공유

올해 상반기에는 해야하는 일 중 1순위는 ADP 취득이다! ADsP를 입사하자마자 취득을 해뒀었는데 빅데이터분석 개념들을 더 까먹기 전에 ADP를 따놓고 싶다.

지금 하고 있는 역할이 어떤걸까 고민하다가 DataOps 역할이라는 결론이 내려졌다.

위 그림에도 나와있듯이 DataOps는 데이터 분석까지 포함하고 있는 영역이기 때문에 파이프라인 자동화의 도메인이 되는 분석 영역에 강점을 만들어두고 싶었다.

몇명의 친구들과 ADP를 같이 공부하고 있으니 올해 한번에 합격하도록 노력해야겠다..!

그리고 그다음 주요과제는 사이드프로젝트이다. 취준생시절 교육기관에서 만난 친구들과 서로의 업무영역에서 도움을 줄 수 있는 부분을 십시일반해서 데이터분석 + 시각화 프로젝트를 진행해보기로 했다. 각자 해보고싶은거 다 해보기로 한 프로젝트라 블로그를 통해 공유할 내용이 꽤나 있을 것 같다.

ADP 필기 시험이 2월 말이어서 우선 ADP에 집중하는걸로!!

항상 계획은 거창하게, 실천은 약하게 하곤 했는데 글또 활동을 통해서 수립된 계획을 잘 지킬수 있도록 셀프-채찍질을 할 수 있을 것 같아서 기대된다.

앞으로 잘 감시해주세요 😎