순서

1. 데이터를 저장할 때 에러가 나는 부분을 파악

2. 에러에 해당되는 부분에 대한 단위 테스트 작성

3. 테스트에 대응하는 실제 코드 작성

 

(테스트 상황) 비동기 요청에 대한 에러발생

비동기 요청에 대한 결과값

  • 성공 : Promise.resolve(value)
  • 에러 : Promise.reject(reason) 

에러 상황 구현

1. 데이터베이스에서 처리하는 부분은 문제가 없다.

2. 비동기 요청시 에러 발생

// express + jest
const productController = require("../../controller/products");
const productModel = require("../../models/Product");
const httpMocks = require('node-mocks-http');
const newProduct = require('../data/new-product.json');

productModel.create = jest.fn();

let req, res, next;
beforeEach(() =>{
    req = httpMocks.createRequest();
    res = httpMocks.createResponse();
    next = jest.fn(); // 미들웨어 함수를 목 함수로 대체
})

describe('Products Controller', ()=>{
    beforeEach(() =>{
        req.body = newProduct;
    });
    
    it('Should handle errors', async () => {
        const errorMessage = {message: 'Description property missing'};
        const rejectedPromise = Promise.reject(errorMessage);
        productModel.create.mockReturnValue(rejectedPromise) // 에러상황을 생성
        await productController.createProduct(req, res, next);
        expect(next).toBeCalledWith(errorMessage);
     });
});

 

- next 로 에러를 처리하는 이유 : express에서 비동기 요청에서 발생하는 에러를 받으면 서버가 망가진다. 이 에러를 next를 이용하면 처리가 가능하다.

 

테스트에 대응하는 실제 코드 작성

const productModel = require('../models/Product');

exports.createProduct = async (req, res, next) => {
    try{
        const createdProduct = await productModel.create(req.body);
        res.status(201).json(createdProduct);
    }catch (error) {
        next(error); // next 에 에러값을 넣어주면 비동기 요청에 대한 에러를 잘처리 할 수 있는 곳으로 보내준다.
    }
};

jest 를 적용하기 위해서 필요한 설정

1. Jest 설치 확인

npm install jest --save-dev

 

2. pacakge.json 에 있는 테스트 스크립트 변경/추가

 "scripts": {
    "test": "jest" 
  },

 

3. 기본적인 설정 파일을 생성 : jest.config.js 생성

$ npx jest --init

   - Would you like to use Typescript for the configuration file?   → No 선택

목차

 

탄생배경

문제

  1. 이미지 저장과 관리의 복잡성
    • Docker Hub 같은 퍼블릭 레지스트리에 민감한 이미지 저장 시 보안 취약
    • 사설 레지스트리 운영 시 높은 비용과 관리 부담 
  2. 보안 문제
    • 이미지 권한 관리와 암호화가 부족하여 보안 위험
    • 세밀한 접근 제어 및 보호된 레지스트리의 필요성 증가
  3. 확장성과 성능의 한계
    • 컨테이너 사용 증가로 대규모 이미지 관리 및 빠른 제공 필요성 증대
    • 기존 레지스트리의 확장성 및 성능 한계
  4. AWS 서비스와의 통합 부족
    • Amazon ECS, Amazon EKS와 외부 레지스트리 통합 시 추가 설정 필요

탄생 배경과 목적

  • 컨테이너 기술의 발전과 함께, 애플리케이션 배포의 효율성을 높이기 위해 컨테이너 이미지를 안전하게 저장하고 관리할 수 있는 레지스트리의 필요성이 대두
  • AWS는 이러한 요구를 충족하기 위해 Amazon ECR(Elastic Container Registry)를 도입하여, AWS 환경 내에서 컨테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있도록 지원
  • ECR을 통해 AWS 사용자는 Docker 이미지를 관리하는 부담을 줄이고, 안전한 방식으로 이미지를 저장할 수 있도록 지원

사용하는 이유

  • AWS 통합성:  Amazon ECR은 Amazon ECS, Amazon EKS 등 AWS의 다른 서비스와 원활하게 통합되어, 컨테이너 이미지를 손쉽게 배포하고 관리가능.
  • 보안: AWS Identity and Access Management(IAM)를 통해 세분화된 액세스 제어가 가능하며, 저장된 이미지는 자동으로 암호화되어 안전하게 보호
  • 관리 편의성: ECR은 완전 관리형 서비스이기 때문에 인프라 관리에 대한 부담이 없습니다. AWS가 자동으로 스케일링하고 관리하므로 사용자는 컨테이너 이미지의 배포와 관리에만 집중할 수 있습니다.
  • 확장성 및 신뢰성: Amazon S3를 기반으로 높은 내구성과 가용성을 제공하며, 사용량에 따라 자동 확장이 가능해 대규모 애플리케이션 배포에도 적합
  • 관리 편의성: 완전 관리형 서비스로서, 인프라 관리에 대한 부담 없이 컨테이너 이미지를 관리가능

장점

  • 간편한 통합: AWS의 다양한 서비스와의 통합이 용이하여, 기존 워크플로우에 쉽게 적용가능
  • 보안 강화: IAM을 통한 세분화된 액세스 제어와 자동 암호화를 통해 컨테이너 이미지를 안전하게 보호
  • 고가용성 및 내구성: Amazon S3를 기반으로 한 저장소를 통해 높은 가용성과 내구성을 제공
  • 자동 확장: 사용량에 따라 자동으로 확장되어, 대규모 애플리케이션 배포에도 대응가능

단점

  • 비용: 저장 용량과 데이터 전송량에 따라 비용이 발생하므로, 대규모 이미지 저장 및 빈번한 전송 시 비용이 증가
  • AWS 종속성: AWS 환경에 최적화되어 있어, 다른 클라우드 서비스나 온프레미스 환경과의 통합에는 추가적인 설정이 필요
  • 퍼블릭 레지스트리와의 비교: Docker Hub와 같은 퍼블릭 레지스트리에 비해 퍼블릭 이미지 공유 기능이 제한적

 

탄생배경

문제

복잡한 CI/CD 환경

  • 코드는  GitHub에서 관리, 외부 도구로 CI/CD 구축
    • Jenkins, Travis CI, CircleCI 

비효율성 발생

  • 여러 외부 도구 간 연동 문제
  • 복잡한 설정 필요
  • 관리의 불편함

탄생

문제 해결을 위한 GitHub Actions를 발표

GitHub Actions

  • GitHub 내에서 CI/CD 구현 : 코드 변경 사항에 따라 자동으로 빌드, 테스트, 배포 수행
  • 이벤트 기반(event-driven) 워크플로우 : 푸시(push), 풀 리퀘스트(pull request), 이슈(issue) 생성 등 다양한 이벤트에 반응

요약

GitHub Actions는 개발자들이 GitHub 플랫폼 내에서 직접 워크플로우를 자동화하고, CI/CD(지속적인 통합 및 배포) 프로세스를 간소화할 수 있는 필요성에서 탄생했습니다.

  • 개발자들의 필요성 충족
  • 효율적인 개발 프로세스 구축

사용하는 이유

1. 플랫폼 내 통합된 CI/CD 환경

  • 원스톱 솔루션: GitHub 내에서 직접 CI/CD 파이프라인을 구축
  • 심리스한 통합: 리포지토리와 깊게 연동되어 코드 변경 사항에 즉각적으로 반응.
    • seamless integration : 시스템이나 도구 간에 경계나 단절 없이 매끄럽게 연동되는 것을 의미

2. 자동화된 워크플로우 구축

  • 이벤트 기반 실행: 푸시, 풀 리퀘스트, 이슈 생성 등 다양한 이벤트에 따라 자동으로 작업이 실행
  • 유연한 설정: YAML 파일을 통해 원하는 워크플로우를 손쉽게 정의하고 커스터마이징 가능

3. 사용 편의성

  • 쉬운 설정: 복잡한 스크립트 없이도 간단한 설정만으로 자동화된 프로세스 구축
  • 직관적인 인터페이스: GitHub의 친숙한 UI를 통해 워크플로우를 모니터링하고 관리 가능

4. 커뮤니티 지원 및 확장성

  • 액션 마켓플레이스: GitHub Marketplace에서 수많은 사전 구축된 액션을 이용하여 개발 시간을 절약
  • 오픈소스 생태계: 커뮤니티에서 제공하는 액션을 활용하거나, 자신만의 액션을 만들어 공유 가능

5. 다양한 플랫폼 및 언어 지원

  • 크로스 플랫폼 지원: Linux, macOS, Windows 등 다양한 운영체제에서 워크플로우를 실행
  • 다양한 언어 호환: JavaScript, Python, Go 등 다양한 프로그래밍 언어를 지원하여 범용성 향상

6. 비용 효율성

  • 무료 이용 가능: 공개 리포지토리의 경우 무료로 이용, 제한된 범위 내에서 사설 리포지토리도 무료로 사용 가능
  • 유연한 결제 옵션: 필요에 따라 추가 러너나 기능을 구매하여 사용할 수 있어 비용 관리가 용이

7. 보안 및 권한 관리

  • 시크릿 관리: API 키나 토큰과 같은 민감한 정보를 안전하게 저장하고 사용
  • 세분화된 권한 설정: 워크플로우에 대한 접근 권한을 세밀하게 제어하여 보안 강화

8. 효율적인 협업 지원

  • 팀 생산성 향상: 자동화된 테스트와 배포를 통해 팀원 간의 협업 원활
  • 코드 품질 개선: 지속적인 통합을 통해 코드의 안정성과 품질 향상

9. 모니터링 및 피드백

  • 실시간 로그 제공: 워크플로우 실행 중 발생하는 로그를 실시간으로 확인
  • 알림 기능: 워크플로우의 성공 여부나 오류 발생 시 알림을 받아 빠르게 대응 가능

장단점

장점:

  • 깊은 통합성: GitHub 리포지토리와 직접 통합되어 있어 코드 변경 사항에 즉각적으로 반응하는 워크플로우 설정 가능
  • 사용 편의성: YAML 형식의 설정 파일을 통해 워크플로우를 손쉽게 작성 및 관리 가능
  • 커뮤니티 지원: GitHub Marketplace를 통해 다양한 사전 구축된 액션을 이용할 수 있어 개발 시간을 절약
  • 유연성: 다양한 프로그래밍 언어와 플랫폼을 지원하며, 병렬 작업 및 매트릭스 빌드를 통해 복잡한 테스트 시나리오를 구현 가능
  • 비용 효율성: 공개 리포지토리의 경우 무료로 이용 가능하며, 필요한 경우에만 추가 리소스를 구매

단점:

  • 벤더 종속성: GitHub 플랫폼에 종속되므로 다른 CI/CD 도구로의 이식성이 낮음
  • 제한된 리소스: 무료 계정이나 제한된 플랜의 경우 사용 가능한 러너나 실행 시간이 제한됨
  • 복잡한 설정: 복잡한 워크플로우나 고급 기능을 구현하려면 YAML 설정에 대한 깊은 이해가 필요
  • 비용 문제: 사설 리포지토리나 대규모 프로젝트의 경우 추가 비용이 발생

목차

엔터프라이즈 vs. 웹 서비스

엔터프라이즈 vs 웹 서비스

  엔터프라이즈 웹 서비스
트래픽 그다지 많지 않음 굉장히 많은(전 세계)
성장성 적당한 정도 (한정된 성장률) 폭발적(100%, 200%, 300%)
신뢰성 사수(목숨을 걸고 지키다) 99%
트랜잭션 많이 사용 그다지 많이 사용하지 않음
사용예시 은행의 금융 거래 관리 시스템, 대형 리테일사의 재고 관리 시스템 등, 조직 내 여러 부서가 함께 사용할 수 있도록 설계된 서비스 외부 애플리케이션이 날씨 정보, 환율 정보 등을 받아볼 수 있는 공개 API, 결제 처리를 위한 결제 API

 

신뢰성

엔터프라이즈

  • 장애가 발생해서 데이터가 없어지거나 하면 실제로 돈이 사라지기도 한다.
  • 만일 장애가 발생되면 피해자로부터 손해배상 청구를 받게 되거나 구해야하는 사람 목숨을 구하지 못하는 등의 사태도 발생할 수 있다.

웹 서비스

  • 높은 레벨의 신뢰성이 요구 되지 않는다.

웹 서비스의 인프라

웹 서비스의 인프라에서 중요시되는 것

  1. 저비용 고효율 - 100% 신뢰성 목표로 하지 않고 비용을 낮추어 효율을 높이는 방향
  2. 확장성이나 응답성 - 서비스의 성장속도를 모를때 장래를 위한 확장성, 사용자 경험(UX)를 위한 서비스의 응답성을 위한 설계
  3. 유연성 - 서비스 사양이 바뀌는 경우에 유연하게 대응할 수있는 인프라를 위한 설계
  4. 개발속도를 중시한 인프라 - 서비스에 대해 기동성 있게 리소스를 제공
    • 앱 배포를 가능한 한 간편하게, 또한 배포할 때 마침 처리 중인 요청에 영향이 없도록 인프라 구성
    • 필요한 서버를 즉시 추가할수 있도록 인프라 구성
    • 배포한 코드에 문제가 발견됐을 때에 곧바로 이전 상태로 돌아갈 수 있도록 인프라 구성

 

클라우드 vs.  자체 구축 인프라

클라우드의 장단점

클라우드 컴퓨팅?

  • 인터넷을 통해 원격으로 컴퓨팅 자원 및 서비스를 제공하는 컴퓨팅 기술 -Samsung SDS-
  • IT 리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것 - Amazon Web Service-
  • 컴퓨팅 리소스(스토리지 및 인프라)를 인터넷을 통해 서비스로 사용할 수 있는 주문형 서비스 - Google Cloud -
  • 인터넷(“클라우드”)을 통해 서버, 스토리지, 데이터베이스, 네트워킹, 소프트웨어, 분석, 인텔리전스 등의 컴퓨팅 서비스를 제공하는 것 - Microsoft Azure - 

장점

  • 확장의 유연성

단점

  • 획일적인 호스트 사양
  • 때때로 멈춤 현상 발생

자체 구축 인프라의 장점

장점

  • 서버 하드웨어 구성을 유연하게 구성할 수 있다. 
  • 서비스로부터의 요청에 유연하게 대응할 수 있다. 
  • 병목현상을 제어할 수 있다.

자체 구축 인프라의 기술 모델

  • 수직통합 모델 - 물리적 계층부터 서비스 설계까지 한 기업에서 구축하는 모델 ( Amazon, Google)
  • 수평분산 모델 - 각 계층마다 다른 기업이 제공하는 것으로 각각이 모여 전체 시스템이 구축되는 모델

하테나에서 클라우드 서비스 사용 예시

 

서비스 활용 현황

  • 현재 활용 중인 서비스: AWS (Amazon Web Services)
  • 주요 서비스: Amazon CloudFront
    • 용도: 미디어 파일 전송을 위한 CDN (Content Delivery Network)
  • 자체 구축 인프라 중심 운영: 애플리케이션 및 DB의 클라우드 저장소 본격 도입은 보류

 

클라우드 컴퓨팅의 적합성

  • 적합한 경우: 소규모 서비스, 트라이얼 용도
  • 혜택: 비용 효율성, 유연한 확장성
  • 한계: 대규모 시스템의 경우 확장성 문제 발생 가능

Amazon EC2의 확장성 이슈

  • EC2 확장성: 대규모 시스템 지원에 한계가 존재할 수 있음
    • 대규모 서비스 예시: Facebook, Google 수준의 시스템
  • 소규모 서비스에는 EC2가 적합하지만, 대규모 서비스는 자체 구축이 더 유리

 

+ Recent posts