글쓰는 감자

Process

• Main Memory에 할당되어 실행 중인 상태인 프로그램
• job, task 등으로도 불림
• 상태
  • New, Ready, Running, Waiting, Terminated

• PCB(Process Control Block)
  • 프로세스에 대한 모든 정보가 모여있는 곳
  • TCB(Task Control Block)
  • process state, PID, program counter, register값, MMU정보 등이 포함

CPU는 한 프로세스가 종료될 때까지 수행하는 것이 아니라 여러 프로세스를 중간중간 바꿔가며 수행하는데 수행하고 있던 프로세스 정보를 저장하기 위해 필요하다!

• Process Queue
  • 프로세스는 일반적으로 여러 개가 한번에 수행
  • 그에 따른 순서가 필요

Job Queue : 하드디스크에 있는 프로그램이 실행되기 위해 메인 메모리의 할당 순서를 기다림

Ready Queue : CPU 점유 순서를 기다림

Device Queue : I/O를 하기 위한 여러 장치가 있는데, 각 장치를 기다림

각 큐 내부에 저장된 실제 데이터는 각 프로세스의 PCB가 저장되어있다. 

순서를 정해주는 알고리즘이 필요 "스케줄링"

Job Queue - Job Scheduler(Long-term)

Ready Queue - CPU Scheduler(Short-term)

Device Queue - Device Scheduler

Multiprogramming

• 멀티프로그래밍은 단일 프로세서(CPU) 환경에서 여러 개의 프로세스가 동시에 실행되는 것
• Degree of multiprogramming : 현재 메모리에 할당되어 있는 프로세스 개수
• 프로세스 종류
  • I/O bound process : 해당 프로세스에서 I/O 작업이 차지하는 비중이 높은 프로세스
  • CPU bound process : 해당 프로세스에서 CPU 작업(계산)이 차지하는 비중이 높은 프로세스
    • Job scheduler는 두 프로세스를 적절히 분배해 메모리에 할당해야 한다!
• Medium-term scheduler : os가 실행하는 동안 주기적으로 메인 메모리에 있는 전체 프로세스를 검사하여 보조기억장치로 옮길 프로세스를 찾아 옮김("Swapping")
  • Swap device = Backing store ( HD = Backing store + File system)
  • Swap out : main memory → HD / Swap in : HD → main memory
• Context Switching(문맥 전환)
  • CPU가 한 프로세스에서 다른 프로세스로 옮겨가는 것
  • Scheduler : CPU scheduler에 의해 CPU가 어느 프로세스를 선택할지 결정
  • Dispatcher : 현재 CPU 데이터는 이전 프로세스의 PCB에 갱신하고, 새로 시작되는 프로세스의 PCB 데이터를 CPU로 복원(restore)
  • Context switching overhead : context switching이 발생할 때마다, dispatcher에서 수행하는 작업은 매번 수행하는데 이게 overhead(dispatcher구현에 대해 효율성을 최대로)

1. Jenkins

• Java 기반의 크로스 플랫폼 오픈 소스 도구
• 실행파일을 .war 형식으로 다운로드하고 터미널에서 시작하여 설치
• DSL(도메인 특정언어)을 사용해 파이프라인 구현
• 확장성이 뛰어남(Window, Linux, macOS)
• 인기있는 클라우드 플랫폼(AWS, Google Cloud, Azure, ..)과 통합
• 병렬로 작업을 수행, 복잡한 CD 요구사항을 실현

2. TeamCity

• Java의 서버 기반 CI/CD 파이프라인 도구
• JetBrains에서 개발 및 유지관리
• Window, Linux환경
• 병렬 빌드 실행 가능(유연성)
• Kotlin 기반 DSL을 사용하여 정의
• Docker, Visual Studion Team Services, Maven, NuGet등과 통합
• 실행 기록, 테스트 진행률 보고서를 즉석에서 보고 즐겨찾기에 빌드를 추가할 수 있음

3. CircleCI

• 오픈소스 프로젝트 및 대규모 프로젝트를 위한 CI/CD 실현
• 온 프레미스(또는 자체 호스팅) 솔루션
• Windows, Linux, macOS 플랫폼 빌드 가능
• 독점 YAML 구문 사용
• Github, Bitbucket 등과 같은 버전 제어 시스템과 함께 사용
• 파이프라인을 "워크 플로"로 제공
• 병렬 테스트 제공
• 널리 사용되는 클라우드 플랫폼(AWS, Google Cloud, Azure 등)을 지원

4. Travis CI

• Ruby 프로그래밍으로 작성됨
• 독점 YAML 구문을 사용
• Linux, macOS, Windows
• 병렬 빌드 수행 가능
• 인기있는 클라우드 플랫폼과의 통합을 지원
• 브라우저 간 테스트 도구와 통합하면 브라우저, 플랫폼 장치(에뮬레이터)의 다양한 조합에서 테스트 수행

5. GoCD

• Thoughtworks의 사람들이 만든 오픈소스 연속 통합 서버
• VSM(value stream map)기능 : 배포 파이프라인 또는 지속적 전달 파이프 라인의 개념에 성공적으로 매핑
• YAML 및 JSON 형식의 코드로 구현
• VSM은 워크플로에 대한 완전한 실시간 시각화 제공
• 사용자 인증 처리
• Windows, macOS, Docker 등에서 작동

6. GitLab CI

• GitLab에 내장된 도구
• Git 리포지토리에서 코드베이스를 호스팅 .gitlab-ci.yaml하고 루트 디렉터리에 있어야하는 YAML파일에서 빌드, 테스트 및 배포를 수행하기 위한 스크립트 지정
• Windows, macOS, Linux
• 사용자 친화적인 인터페이스
• 병렬 빌드 실행
• 사용자 지정 파이프 라인을 정의하는 옵션 제공

참고: https://ichi.pro/ko/hyeonjae-sayong-ganeunghan-choegoui-ci-cd-dogu-27-gae-194611649728144

"애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법"

"애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공" ⇒ "CI/CD 파이프라인"

CI(Continuous Integration)

• 개발자를 위한 자동화 프로세스
• 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합
• 여러 개발자들이 동시에 작업할 때 충돌 방지

CD(Continuous Delivery)

• 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되어 운영팀이 실시간 프로덕션 환경으로 배포
• 최소한의 노력으로 새로운 코드를 배포

CD(Continuous Deployment)

• 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스
• 운영팀의 프로세스 과부하 문제를 해결

• AWS 기반 대규모 아키텍트 설계
  • 네트워크 관련(AWS VPC)
  • 인프라 구축(설계도 작성 → 직접 해보기)
  • https://aws.amazon.com/ko/architecture/icons/
• 코드를 통한 인프라 관리
  • terraform
  • ansible
  • packer
• Docker와 Kubernetes를 활용한 운영
• Kubernetes on AWS EKS
• CI/CD 구현
  • terraform CI/Cd 파이프라인
  • Jenkins CI/CD 파이프라인
  • CodePipeline, CodeBuild, CodeDeploy CI/CD 파이프라인
  • Github Action CI/CD
  • Circle CI CI/CD
  • ArgoCD EKS배포
• 모니터링 서비스 구축 및 운영
  • AWS CloudWatch 모니터링 구축
  • Prometheus & Grafana 모니터링 구축
  • ELK stack을 활용한 웹서비스 로그 확인
  • AWS VPC Flow 로그 수집
• AWS 기반 보안
  • AWS IAM 관련

DevOps

• Development + Operations
• 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화
• 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합
• 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 함 → "프로세스 자동화"
• 이점 (AWS기준)
  • 속도 : 작업 속도가 빨라진다, 업데이트를 좀 더 빠르게 릴리스할 수 있다
  • 신속한 제공 : 릴리스의 빈도와 속도를 개선, 고객의 요구에 더 빠르게 대응
  • 안정성 : 변경사항이 제대로 작동하며 안전한지 테스트
  • 확장 : 규모에 따라 인프라와 개발 프로세스를 운영 및 관리(자동화와 일관성 지원)
  • 협업 강화 : 개발자와 운영팀 
  • 보안 : 제어를 유지하고 규정을 준수하면서 신속하게 진행 가능
• 방식 (AWS기준)
  • 지속적 통합(CI, Continuous Integration) : 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 소프트웨어 개발 방식
  • 지속적 전달(CD, Continuous Delivery) : 프로덕션에 릴리스 하기 위한 코드 변경이 자동으로 빌드, 테스트 및 준비되는 소프트웨어 개발 방식
  • 마이크로 서비스 : 단일 애플리케이션을 작은 서비스의 집합으로 구축하는 설계 접근 방식
  • 코드형 인프라 : 버전 관리 및 지속적 통합과 같은 코드와 소프트웨어 개발 기술을 사용하여 인프라를 프로비저닝하고 관리하는 방식
  • 모니터링 및 로깅 : 지표와 로그를 모니터링하여 애플리케이션 및 인프라 성능이 제품의 사용자 경험에 어떤 영향을 미치는지 확인
  • 커뮤니케이션 및 협업 : 개발 및 운영의 워크플로와 책임을 물리적으로 합침

DevOps 사례

https://chloe-codes1.gitbook.io/til/aws/aws_builders/06_devops_-_-_-_-_-_ : AWS DevOps

https://m.blog.naver.com/infopub/222059275874 : facebook DevOps

DevOps 엔지니어

• 로드맵 : https://github.com/devJang/developer-roadmap/blob/master/pdf/devops.pdf
• 역할

• 업무 영역

• 필요한 기술들

❗ DevOps가 나온 이유가 사용자의 피드백을 받아서 빠르게 릴리스를 하기 위해 나온듯하다...? 개인적인 생각일 뿐.. 막 새로운 테스트에 대해 고민하고 하다 보니 여러 테스트 방법들이 나왔고 이 과정을 자동화하면 더 빠르게 서비스를 업데이트할 수 있다..! ❗

❗ 개발을 하면서 어떻게 하면 효율적, 반복적인 일을 줄일까? 인프라 담당자, CI/CD를 주로 하는 형상관리업무, 개발 프로세스를 담당하는 위치에 있는 사람들이 조금씩 확장시켜 나가면 DevOps 엔지니어의 길로 갈듯..? ❗

HTTP VS HTTPS

HTTP: Hypertext Transfer Protocol의 약자

HTTPS: S = "Over Secure Socket Layer"의 약자 

"즉 HTTPS는 보안이 강화된 HTTP"

HTTPS와 SSL

SSL 프로토콜 위에서 돌아가는 프로토콜을 HTTPS라 한다.(SSL ⊃ HTTPS)

나머지 참고) https://opentutorials.org/course/228/4894