1am wish

요즘 docker를 이용한 서비스가 많아졌다. 컨테이너 기술을 활용하여 애플리케이션을 일관되게 실행할 수 있어서 많이 사용하고 있다. 나도 서비스 새로 만들때 웬만하면 도커를 쓰는 편인데, 이미지 생성해서 ECR에 올리고 EC2 서버에 배포하는 식으로 사용했었다.

그런데 ECS라고 컨테이너 기반 애플리케이션을 쉽게 배포할 수 있는 서비스를 알게 되었다. 그래서 이런 컨테이너 기반 애플리케이션을 EC2을 통해 배포하는 것과 ECS을 통해 배포하는 것의 차이를 알아보고자 한다.

여기서 다루는 ECS는 서버리스 기반의 Fargate를 가정으로 한다. (서버리스가 아니라면 어차피 ECS랑 EC2랑 연동하는거라..)

일단 ECR, EC2, ECS는 다음과 같다.

• ECR(Elastic Container Registry) : 이미지를 저장하는 레지스트리 서비스. 나는 도커 이미지를 만들어 클라우드에 저장하는 저장소의 개념으로 사용하고 있다.
• EC2(Elastic Compute Cloud) : 가상 서버 인스턴스를 제공하는 서비스. 그냥 원격 컴퓨터라고 생각하면 된다.
• ECS(Elastic Container Service) : 이미지를 가져와서 컨테이너를 실행하고 관리할 수 있는 서비스.

ECS로 ECR을 배포했을 때의 장점

설명으로만 보아서는 EC2보다는 ECS가 좀 더 ECR과 연동이 잘 될 것 같다.
실제로 ECR은 AWS 기반 컨테이너 오케스트레이션을 제공해서 ECR와는 찰떡같은 궁합이다.

• ECR의 이미지를 가져와 쉽게 배포, 관리, 확장할 수 있다.
• 운영 부담이 적다.
• 효율적으로 컨테이너를 관리할 수 있다.

단편적으로 보면 EC2로 배포하는 건 서버도 직접 관리해야하고 도커도 따로 설치해야하고 컨테이너 관리랑 업데이트도 직접 해야하고 설정도 번거로운데 왜 사용할까?

EC2로 ECR을 배포했을 때의 장점

우선, 개발중의 여러 선택사항과 마찬가지로 운영 환경에 따라 달라진다.
EC2로 개발할 때에는 초기 설정 및 관리가 까다롭지만, 더 높은 유연성 제어를 제공한다. 

ECR에 비해 EC2는 다음과 같은 지원을 제공한다.

• 인스턴스 옵션 : EC2의 경우 다양한 인스턴스 유형과 크기 조정을 제공하는 등 워크로드에 맞는 인스턴스를 선택할 수 있다. 반면에 ECR은 vCPU와 메모리의 조합만 선택할 수 있다.
• 네트워킹 옵션 : EC2의 경우 ENI, VPC 피어링, Direct Connect등 고급 네트워크 기능을 지원한다, 반면 ECR의 경우 Fargate에서는 ENI를 직접 제어하는데 제한이 있다. Fargate의 경우 고정 IP를 직접 할당할 수 없다.
• 스토리지 옵션 : Fargate는 EBS 볼륨을 직접 사용할 수 없고 임시 스토리지만 제공되어 세부적인 스토리지 옵션이 제한적이다.

이와 같이 ECS로 배포했을 때, EC2로 배포했을 때의 차이가 있다.
이렇게 제품의 요구사항에 따라 ECS와 EC2 중에 선택할 수도 있겠지만, 우리에겐 비용도 꽤 중요하다...
비용 관점에서 비교해보자.

ECS와 EC2의 비용 비교

비용은 서버와 서버리스의 비교와 비슷하다.

ECS Fargate의 경우 서버리스이기 때문에 유휴 자원에 대한 비용 부담이 없다. 
당연하게도 트래픽이 많아질 경우 사용한 만큼 비용이 발생하기 때문에 비용이 급격히 상승할 수 있다.

EC2의 경우 선택한 인스턴스의 타입에 따라 시간 당 비용이 발생한다. 트래픽이 적을 경우 비용 효율성이 떨어진다.
예약 인스턴스, 스팟 인스턴스 등 비용 절감 옵션을 제공한다. 한 인스턴스에 여러 개의 컨테이너를 올릴 수 있다.

만약 ECS + EC2의 조합이라면 그냥 같은 인스턴스 유형으로 비교할 때 EC2만 쓰는거에 비해 조금 더 비용이 나온다고 한다. 

따라서, 대규모 트래픽의 경우에 EC2를 사용하는 것이 더 경제적이고, 트래픽이 적으면 사용한 만큼 비용이 발생하는 ECS를 사용하는 것이 좋아 보인다.

성능 비교

마지막으로는 성능의 관점인데, 다음 글을 참고하면 좋을 것 같다. EC2이 ECS보다 성능이 조금 더 뛰어나다고 한다.
https://filia-aleks.medium.com/ec2-versus-fargate-performance-comparison-34b1002fbbaa

마무리

결과적으로, 어떤 형태의 서비스를 개발하고 트래픽이 많느냐 적느냐, 개발을 편하게 할 것이냐 귀찮으나 유연성을 택할것인 가 에서의 선택인 거 같다.
아직은 EC2가 오랜시간 서비스를 제공해왔기에 ECS에 비해 다양한 옵션을 제공하여 이 부분에서는 EC2가 나은 것 같지만, 나중 가서는 ECS도 다양한 옵션을 제공하지 않을까 싶기도 하다.

나라면 비용을 우선적으로 생각할 것 같긴하다. 비즈니스를 만드는 회사에서 AWS 비용을 절감하면 인력 몇명의 비용을 아끼는것과 같은 효과를 가져오니까 회사도 좋아한다.

나중에 나도 새로 서비스를 구축할 때 다시한번 고민해볼 것 같고, 마지막으로 인프랩에서 했던 EC2, ECS와 관련한 글을 구경하며 좋을 것 같다!

https://tech.inflab.com/20240227-finops-for-startup/

평소 좋아하는 '널널한 개발자'님의 영상을 보다가
헤더에 관한 얘기를 듣다보니 네트워크 속도가 1mb/s일 때 데이터 1mb보내는건 1초보다 더걸리겠다 싶어서
맞는지 궁금해서 좀 더 찾아보았다!

(이 글에서 물론 여기서 latency나 대역폭 개념은 무시한다. 수많은 원인이 있기 때문..!)

https://www.youtube.com/watch?v=K9L9YZhEjC0

기본적으로 데이터를 PC끼리 주고받을 때 OSI 7계층을 오간다.

각 계층을 이동할 때마다 '이전 계층에서 받은 값' + 해당 계층 프로토콜의 헤더가 붙는다.

만약 1mb의 데이터를 보낼 때 한번에 1mb를 보내는게 아니고 패킷이라는 단위로 나누어 하나씩 보내는데, 
패킷의 크기는 MTC(최대 패킷 크기)에 의존한다. TCP/IP 스택에 따라서 달라지기도 한다!

1mb를 보낼 때 필요한 패킷 개수 계산

일반적으로 MTC는 1500byte인데, 여기에 IP 헤더, TCP 헤더가 포함되므로
실제 데이터 크기는 1500byte보다 작은 1460byte 정도 된다.

• IP 헤더: 일반적으로 20 바이트
• TCP 헤더: 일반적으로 20 바이트

=> 1mb 데이터를 전송하기 위해 약 719개의 패킷이 필요하게 된다.

그리고 이더넷 네트워크의 경우 아래 만큼의 용량이 더 필요해서 이더넷 프레임의 크기는 1518byte가 된다.

1460 bytes (데이터)+20 bytes (TCP 헤더)+20 bytes (IP 헤더)+14 bytes (이더넷 헤더)+4 bytes (FCS)=1518 bytes

• 이더넷 헤더: 14 바이트
• 이더넷 트레일러 (FCS): 4 바이트

그래서 이 가정에서는 1mb를 보낼 때 1518byte짜리의 이더넷 프레임을 719개 주고받아야한다.

1mb/s 네트워크에서 1mb의 데이터를 보낼 때 걸리는 시간 계산

네트워크 속도와 데이터 크기의 차이는 결국에 이 헤더들이 붙기 때문에 발생하게 되는데 GPT가 간단하게 계산해준걸로 참고하자면 

계산에 따르면 네트워크 속도가 1mb/s 일 때 전체 전송 데이터 양을 전송한데 필요한 시간은 약 1.1초 정도 걸린다.

그래서 평소에 네트워크를 사용해서 파일을 다운받을 때 네트워크 속도가 데이터 용량을 못따라가는데? 라고 생각했던건 우연이 아니었던 것이다! (물론 이 가정에서 핸드셰이크 등 연결을 위한 지연 시간 등은 무시됐긴 함)

결론

실제로 데이터를 주고받을 때에는 헤더들이 붙어서 더 큰 크기의 데이터를 주고받는 것이고
대략적으로 네트워크 속도보다 더 오랜 시간이 소요된다...

그럼 여기서 궁금해지는건 UDP는 헤더가 더 작은데 더 빨리주고받나? 싶은데 그건 다음에 알아보도록 하자아

가끔 접근하는 백업데이터를 관리하려는데, S3 클래스가 다양하게 있다는 것을 알게 되었다.

데이터를 저장할 때 단순히 데이터를 보관하는 것 이상의 고려가 필요하다.. 자주 액세스하는 데이터인지, 장기 보관용 데이터인지에 따라 비용 효율성을 극대화할 수 있는 다양한 옵션이 있는데 필요에 따라서 Amazon S3의 주요 스토리지 클래스를 비교하고, 내가 사용하는 데이터에 맞는 최적의 클래스를 선택하는 방법을 정리해보려고 한다.

클래스 종류 비교

왜 스토리지 클래스를 선택해야 할까?

데이터 관리 비용을 최소화하고 성능을 최적화하려면, 데이터 액세스 패턴에 따라 적절한 스토리지 클래스를 선택하는 것이 중요하다는 것을 알게 되었다.

• S3 Standard:
  • 자주 액세스하는 데이터에 적합하다.
  • 예를 들어, 웹사이트에서 자주 호출되는 이미지나 동영상 파일, 실시간 로그 데이터 등은 S3 Standard를 사용하는 것이 좋다.
  • 가용성이 높고 지연 시간이 짧아 빠르게 데이터를 제공할 수 있다.
• S3 One Zone-IA:
  • 자주 액세스하지 않는 데이터를 저장하기에 적합하다.
  • 예를 들어, 주기적으로 백업해야 하는 파일이나 장기 보관용 데이터, 하지만 복원할 필요는 적은 경우에 이상적이다.
  • 비용이 저렴하지만 가용 영역이 하나뿐이므로 데이터 손실 위험이 있다.
• S3 Glacier Instant Retrieval:
  • 장기 보관용 데이터로, 일년에 몇 번만 액세스하는 경우에 적합하다.
  • 예를 들어, 법적 증빙 자료, 오래된 프로젝트 파일 등이 이에 해당한다.
  • 저렴한 비용으로 데이터를 저장할 수 있으며, 필요 시 빠르게 데이터를 복원할 수 있다.

예시 시나리오: S3 One Zone-IA 선택

가정해보자면 (실제는 아님 X) , 우리 회사는 주간 백업을 수행한다. 백업 데이터는 주로 사고 발생 시 복구를 위해 필요하며, 일주일에 2, 3번 삽입이 이루어지고 불러오기는 자주 발생하지 않는다. 이 경우, S3 One Zone-IA를 선택하면 최적의 비용 효율을 얻을 수 있다. 

결론

Amazon S3의 다양한 스토리지 클래스는 데이터 액세스 패턴에 따라 선택함으로써 비용을 절감하고, 필요한 성능을 유지할 수 있다. 조금 번거롭긴 하지만,,! 적절한 클래스를 선택하여 스마트하게 데이터 관리를 해보자!

참고 링크

• Amazon S3 가격
• 객체 스토리지 클래스 - Amazon S3

새로 작성한 API에 header로 Authorization하는 기능이 API gateway 메소드를 연결하니 header를 읽지 못하는 문제가 발생했다. 
API gateway를 연결하지 않은 엔드포인트로 테스트 하면 정상적으로 헤더를 읽는데, API gateway를 통해 호출하면 문제가 발생한다.

원인은 API gateway 에 '프록시 통합 사용' 기능이 활성화되지 않아서다.

위 사진처럼 '프록시 통합 사용'을 체크하면 아래와 같은 컨펌이 뜨는데 확인을 눌러주면 적용된다.

적용 후 API를 호출해보면 정상적으로 header를 읽는 것을 확인할 수 있다!

왜 안됐었는지 원인을 알아봤더니 Proxy 기능이 활성화되지 않으면, API Gateway가 Authorization 헤더를 포함한 클라이언트 요청의 헤더를 제대로 전달하지 못할 수 있다고 한다.

즉, 프록시 통합 사용' 기능을 활성화해야
API Gateway는 들어오는 요청을 원본 API로 거의 그대로 전달하려고 한다는 것이다. 모든 헤더, 쿼리 파라미터, 경로 변수 등이 API Gateway를 통해서 원본 API로 전달되며, 이를 통해 원본 API는 클라이언트 요청을 있는 그대로 처리할 수 있는 것이다!

OS는 프로세스가 정보를 공유하고 교환할 수 있도록 리소스를 할당해야 한다. 각 프로세스의 리소스를 보호하고 프로세스 간의 동기화를 허용하기도 한다. 생성, 스케줄링, 프로세스 종료 및 교착 상태와 같은 다양한 작업을 포함한다.

• 프로세스 : 실행중인 응용 프로그램의 인스턴스
  • 스택 : 스택은 함수 매개변수, 반환 주소 및 지역 변수와 같은 임시 데이터 저장
  • 힙 : 런타임 동안 처리될 수 있는 메모리를 할당
  • 데이터 : 변수를 포함. 텍스트, 프로그램 코드, 전역 변수, 데이터 섹션
  • 텍스트 : 프로그램 카운터 값으로 표시되는 현재 활동이 포함
  • 응용 프로그램을 실행하기 위한 모든 데이터를 캡슐화
  • 임시데이터(함수 매개변수, 반환 주소 및 지역 변수)를 포함하는 프로세스 스택 캡슐화
  • 실행 중의 후입선출(LIFO) 순서로 증가 및 축소되는 프로세스 상태의 동적 부분
• PCB(공정 제어 블록) : 모든 프로세스에 대해 운영 체제에서 유지 관리하는 데이터 구조
  • pid(프로세스 id)로 식별
  • 프로세서 레지스터의 내용을 저장 
  • 프로세스 상태 : 프로세스는 신규, 준비, 실행 중, 대기 중 등일 수 있다.
  • 프로그램 카운터: 프로그램 카운터는 해당 프로세스에 대해 실행되어야 하는 다음 명령어의 주소를 준다.
  • CPU 레지스터: 누산기, 인덱스 및 범용 레지스터, 조건 코드 정보
  • CPU 스케줄링 정보: 프로세스 우선순위, 스케줄링 대기열에 대한 포인터 및 기타 다양한 스케줄링 매개변수
  • 회계 및 비즈니스 정보: CPU 사용량 및 실시간 사용, 작업 또는 프로세스 번호 등과 같은 시간 유틸리티
  • 메모리 관리 정보: 기본 및 제한 레지스터, 페이지 또는 세그먼트 테이블의 값. 운영 체제에서 사용하는 메모리 시스템에 따라 다름
  • I/O 상태 정보: 열린 파일 목록, 프로세스에 할당된 I/O 장치 목록 등

출처 : https://medium.com/@akhandmishra/operating-system-process-and-process-management-108d83e8ce60

• new : 특정 프로그램이 2차 메모리/하드 디스크에서 1차 메모리/RAM으로 호출할 때 새 프로세스가 생성
• ready : 준비 상태에서 프로세스는 실행 준비가 된 기본 메모리에 로드되어야 함
• waiting : 프로세스가 실행을 위해 CPU 시간 및 기타 리소스 할당 대기
• running : OS 스케줄러에 의해 프로세스가 프로세서에 할당되어 실행 상태
• interrupt : 어떤 일의 발생으로 준비상태로 되돌아감
• I/O or event : 프로세스가 I/O 작업과 같은 이벤트에 의해 준비상태로 이동
• suspended : 상태는 프로세스가 실행할 준비가 되었지만 OS에 의해 준비 대기열에 배치되지 않은 시간
• terminated : 종료됨 상태는 프로세스가 종료되는 시간을 지정

프로세스 생성 : 프로세스는 자식 프로세스를 만들 수 있다 -> 모든 프로세스는 생성 프로세스가 상위 프로세스. 트리 형태

운영 체제는 다른 모든 응용 프로그램을 제어하는 ​​컴퓨터의 주요 프로그램으로 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스

• 주요 목적 : 프로그램이 하드웨어와 상호작용하고 시스템이 하드웨어 및 소프트웨어 리소스를 관리할 수 있도록 하는 것
• 기능 
  • 커널 : 파일 관리, 메모리 관리, 프로세스 관리, 입출력 처리, 디스크 드라이브 및 프린터와 같은 주변 장치 제어와 같은 모든 기본 작업을 수행하는 소프트웨어. 운영체제의 핵심 구성 요소를 포함하는 소프트웨어
  • 사용자 인터페이스(UI)
  • 메모리 관리 : 각 단어 또는 바이트가 고유한 주소를 갖는 큰 단어 또는 바이트 배열인 메인 메모리를 관리
    • 메인 메모리 추적
      • 메인 메모리는 CPU에서 직접 액세스할 수 있는 빠른 스토리지로 프로그램을 실행하기 위해서 필수적
    • 멀티 프로그래밍에서 OS 는 어느 프로세스가 언제 얼마나 메모리를 얻을지 결정
    • 프로그램이 요청할 때 메모리 할당
    • 프로그램 종료 시 메모리 할당 해제
  • 프로세서 스케쥴링 : 멀티프로그래밍 환경에서 어느 프로세스가 언제, 얼마동안 프로세서를 가져오는지 결정
    
    • 트래픽 컨트롤러 : 프로세서 및 프로세스 상태 추적
    • 프로세서(CPU)를 프로세스에 할당
    • 프로세스가 더 이상 필요하지 않을 때 프로세서 할당 해제
  • 장치 관리 : 드라이버를 통해 장치 통신을 관리
    • I/O 컨트롤러 : 모든 장치를 추적
    • 어떤 프로세스가 장치를 언제 얼마나 가져오는지 결정
    • 효율적인 방식으로 장치를 할당/할당 해제
  • 파일 관리
    • 파일 시스템 : 정보, 위치, 용도, 상태 등을 추적
    • 누가 자원을 가져갈지 결정
    • 리소스 할당/할당 해제
  • 보안 : 암호 등 기술을 사용하여 프로그램 및 데이터에 대한 무단 액세스 방지
  • 시스템 성능 제어 : 서피스 요청과 시스템 응답 사이의 지연 기록
  • 작업 계정 : 다양한 작업과 사용자가 사용하는 시간과 리소스를 추적
  • 오류 감지 지원 : 덤프, 추적, 오류 메시지 및 기타 디버깅 및 오류 감지 지원
  • 다른 소프트웨어와 사용자간 조정 : 컴퓨터 시스템의 다양한 사용자에 대한 컴파일러, 인터프리터, 어셈블러 및 기타 소프트웨어의 조정 및 할당