DevOps

DevOps의 개념

• Agility 향상과 Lead Time 감소를 위해, 개발팀과 운영팀의 프로세스적인 통합체계와 CI/CD툴을 통해 기술적 통합을 유기적으로 연계한 개발환경
  

- Development 와 Operation 의 합성어
- SW개발자들과 IT종사자들 사이의 의사소통, 협업, 융합을 강조한 개발방법론
- 개발/운영/품질관리 부서 간 통합, 커뮤니케이션, 협업을 위한 일련의 방식
- 지속적 환경(지속적 평가, 지속적 delivery와 배포, 지속적 운영, 지속적 통합 및 테스트)이 유지되는 cycle

## DevOps 효과적 정착을 위한 성공요소

- 협업 문화 조성 : 개발자와 운영자간 상호존중 및 신뢰
- 보상시스템 : 기능별 성과 보상이 아닌 전체 개발 차원에서 성과 측정/보상
- 통합프로세스 : 도구와 시스템을 표준화하고 통합하여 의사소통 효율성 확보
- 자동화 : 코드통합, 테스트, 릴리즈 과정, 메뉴얼 작업

Docker

• 하이퍼바이저(hypervisor) 없이 리눅스 컨테이너(Linux Container, LXC) 기술을 바탕으로 애플리케이션을 격리된 상태에서 실행하는 가상화 솔루션
• 플랫폼에 상관 없이 실행될 수 있는 어플리케이션 컨테이너를 만드는 기술

도커와 하이퍼바이저 가상화 비교

도커의 구성 요소

AWS

EC2(Elastic Compute Cloud)

• AWS가 제공하는 서버
• EC2는 인터넷 상에 서버가 있는 것.

서버리스

람다

• 내가 만든 코드를 서버없이 실행시킬 수 있도록 해주는 서비스
• 람다로 함수를 만든 후 호출하는 방법
  • AWS API Gateway 서비스에서 API를 생성한 다음에 람다와 매핑을 시키면 API URL이 생성이 됨
  • URL로 호출할 수도 있고, DynamoDB 특정 테이블에 트리거로 걸거나 SQS라는 메시지 서비스에 이벤트로 걸 수도 있다.

S3(Simple Storage Service)

• 파일을 저장하는 스토리지
• 보통 NAS처럼 이미지나 로그 파일 같은걸 저장하는 용도로 많이 쓰임.
• 온라인 상에 존재하기 때문에 유연한 확장성을 가지고 있음.
• 가격이 저렴함.

AWS에서 사용할 수 있는 데이터베이스

• RDS
  • 우리가 흔히 알고 있는 RDBMS를 클라우드 상에서 사용을 하는 것
  • Oracle, MySQL, PostgreSQL, MariaDB, MSSQL 모두 지원됨.
• Aurora
  • 아마존에서 자체적으로 만든 RDBMS
  • MySQL과 PostgreSQL과 호환이 됨.
• DynamoDB
  • NoSQL

Queue 방식과 Topic 방식 개념 이해

1. Queue
   • ActiveMQ의 Queue는 Producer가 보낸 메시지를 1개의 Consumer가 받습니다.
   • 메시지는 Queue에 쌓이고, Consumer는 Queue에서 하나씩 소비합니다.

2. Topic
   • ActiveMQ의 Topic은 Producer(Publisher)가 메시지를 발행(publish)하고,
   • N개의 Consumer(Subscriber)가 동일한 메시지를 구독(subscribe) 합니다.

- **Topic 방식은 모든 Consumer가 동일한 메시지를 받는 것이 핵심!**

SES(Simple Email Service)

• 개발자가 모든 애플리케이션 안에서 이메일을 보낼 수 있는 경제적이고, 유연하며, 확장 가능한 이메일 서비스
• Amazon SES를 빠르게 구성하여 트랜잭션, 마케팅 또는 대량 이메일 커뮤니케이션을 포함한 다수의 이메일 사례를 지원할 수 있음.
• Email을 보내거나 받을 수 있는 서비스
• 이메일을 받을 때 여러 방법으로 처리 가능
  • Lambda 호출
  • SNS 호출
  • S3에 이메일 저장
• 대량의 이메일을 보내기 위해서는 샌드박스 모드 해제 필요(Aws Support 센터)

SNS(Simple Notification Service)

• 애플리케이션 간 (A2A) 및 애플리케이션과 사용자간 (A2P) 통신 모두를 위한 완전관리형 메시징 서비스
• Pub/Sub(발행/구독) 기반의 메세징 서비스
  • 하나의 토픽을 여러 주체가 구독
    • 토픽에 전달된 내용을 구독한 모든 주체가 전달받아 처리
• 다양한 프로토콜로 메시지 전달 가능
  • 이메일
  • HTTP(S)
  • SQS
  • SMS
  • Lambda
• 하나의 메시지를 여러 서비스에서 처리

1. 주문을 함
2. SNS를 통해서 주문을 처리하게끔 SNS로 보냄. SNS는 Topic임.
3. Topic으로 주문 내역이 들어옴.
4. 이 Topic에 관심이 있는 모든 서비스들이 구독을 하고 있다가 주문이 들어오면 업체 연락을 하고, 비용 삭감하고 기록 갱신하고, 주문 이메일 보내주고, 모바일로 배달원에게 알려주고 등등 함.

• 하나의 주문 메시지를 통해서 다양한 업체들에서 구독을 하고 있다가 처리를 하는 구조가 Pub/Sub 구조임.

• 전달 대상들
  • Lambda를 통해서 Slack, Teams, 텔레그램 전달
  • 이메일
  • 모바일 클라이언트에게 직접 보냄
  • HTTP를 통해서 외부서버 Third Party로 보냄.
  • Amazon Kinesis Data Firehose를 통해 S3로 보낼 수도 있음.

• Fan Out Architecture
  1. 원본 동영상을 업로드 하면
  2. S3에서 SNS로 보냄
  3. SNS에서 각각의 인코딩 할 수 있는 EC2로 메시지를 보냄.
  4. 메시지를 통한 각자의 작업 내용이 다름.
  • S3에서 전달되었다는 내용 하나를 가지고 SNS에서 증폭을 시킴
  • 이걸 Fan Out Architecture라고 함.

SQS(Simple Queue Service)

• Amazon Simple Queue Service(SQS)는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전 관리형 메시지 대기열 서비스.
• AWS에서 제공하는 큐 서비스
  • 다른 서비스에서 사용할 수 있도록 메시지를 잠시 저장하는 용도
  • 최대 사이즈 : 256kb, 최대 14일까지 저장 가능
  • SNS는 메시지를 따로 저장하지 않지만 SQS는 메시지를 저장할 수 있음!!
• 주로 AWS 서비스들의 느슨한 연결을 수립하려 사용
• 하나의 메시지를 한번만 처리
• AWS에서 제일 오래된 서비스

• SQS가 왜 필요하냐?
  1. 유저가 원본 영상을 업로드함
  2. S3로 업로드가 됨.
  3. 람다를 통해
  4. EC2로 전달이 됨.
• 전달하는 동안에 그 당시에 EC2가 떨어졌음.
• 그래서 전달하긴 했는데 오류가 났음.
• 람다는 EC2와 타이트하게 연결이 되어있기 때문에 EC2가 다운이 되어있다?
• 메시지를 전달하는 것이 실패하고 이 로직 자체가 실패를 하고 아무것도 못함.

• 그래서 어떻게 하냐면 중간에 SQS를 둔다.
• 람다를 통해 SQS에 넣어두면 EC2 인스턴스 클러스터 들이 SQS에 저장되어 있는 메시지를 빼서 사용을 하게 됨.
• 디커플링 되어 있는 인스턴스들이 Fail이 나더라도 SQS 안에 있는 메시지는 그대로 보관이 됨.
• 메시지가 유실되지 않는다!
• 그래서 인스턴스들이 복구가 되면 다시 꺼내서 쓰면 됨.
• 안전하게 하나의 서비스에서 다른 서비스로 메시지를 전달할 수 있게 된다!
• EC2가 비용이 너무 많이 들어서 Lambda로 바꾸더라도 이 람다들이 SQS에 저장되어 있는 메시지들을 빼가면 되기 떄문에 앞에 설정한 Lambda를 바꿀 필요가 없다.

• SNS는 메시지를 서비스에게 직접 PUSH함.
• 서비스에서 SQS로 요청을 보내서 메시지를 가져감(PULL).