어플리케이션 개발자가 알아야하는 최소한의 시스템 인프라, 장애와 복구 그리고 DevOps에 대한 간략한 설명입니다.

1. System Infra와 Recovery
그리고 DevOps
Application 개발자가 알아야 할 최소한에 대해
2020년 여름, 어느 날
Speaker. 김주석 (@ggaengma)
Linkedin
Github : @ggaengma
Gitlab : @juseok / @zealot(OfficeAccount)

2. 개발자에게 Infra가 왜 중요해?
- 인프라 : 하드웨어/ OS/ 미들웨어/ 네트워크 등 Apprication 시스템의 기반
- IT 시스템 환경의 변경
1. On-premiss => Cloud
2. CI/CD (Continuous Integration / Continuous Deployment)
- 시스템 엔지니어와 소프트웨어 엔지니어간의 교집합 발생
- 시스템 엔지니어도 코딩을 (Orchestration)
- 소프트웨어 엔지니어도 시스템을 (유연하고 지속적인 배포)

3. On-premises VS Cloud, and Hybrid Cloud
On-premises Cloud
서버의 위치 IDC, 서버실 세계 곳곳
관리의 주체 시스템 엔지니어 시스템 엔지니어, DevOps 엔지니어
확장성 (Sizing) 확장이 어려움 확장성 좋음 (Auto scaling)
비용(인건비 제외) 초기 투자비용 고가 / 유지비용 저가 초기 투자비용 저가 / 유지비용 고가
가용성 목표 Never Die Fail over
보안 완전 기밀성 유지 가능 제공되는 보안 서비스 이용

4. 하드웨어
- CPU : 성능에 영향을 미치는 가장 중요한 하드웨어 (Core/Cache/Clock)
- CPU : 직렬 처리 최적화(굴삭기) / GPU : 병렬 처리 최적화(삽)
- Memory : 용량High, 속도High, 전력소모Low, 오류처리Enable
- Storage : 가장 느린 하드웨어로서 시스템 전체 속도에 영향
- Firewall : 패킷 필터 방식(Port, IP) / 게이트웨이 방식(Proxy, Session)

5. CPU / Memory / Storage
Cache (Cpu <-> Memory) VS Buffer (Memory <-> Storage)

6. 네트워크
- Mac Address : 48bit(제조사식별24bit+발행번호24bit), Unique, 불변
- IP Address : IPv4 (32bit), IPv6 (128bit)
- OSI 7 Layer Model (지겹지만 중요한)
- 물리 : 전송 케이블이 직접 연결되는 계층
- 데이터 링크 : 인접한 노드간 통신. 프레임(추가정보 묶음) 전달 (L2)
- 네트워크 : 라우팅, 흐름제어, 스위치 (L3)
- 전송 : 데이터 메시지 전송 및 확인 (TCP / UDP)
- 세션 : 연결 유지 및 해제
- 프리젠테이션 : 데이터, 인/디코딩, 암/복호화
- 응용 : 웹 브라우저

7. OS (라 쓰고 Linux라 부르는)
- 쉽게 말해 UNIX OS의 무료 버전 (feat. 리누스 토발즈)
- 리눅스는 오픈소스로서 무수히 많은 버전으로 배포 (데비안으로부터)
- 계보도 : https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg
- 서버에선 주로 Ubuntu / CentOS(RHEL 무료판)로 양분화
- Ubuntu VS CentOS : https://elky84.github.io/2018/10/01/ubuntu_vs_centos/
- 커널 : OS의 코어 (메모리/파일/프로세스/디바이스 등의 관리하는 부분)
- 쉘(Shell) : CLI를 통한 커널과의 소통장치 (명령어를 이어 붙이면 쉘 스크립트)
- 쉘의 종류 : bash, csh, tcsh, zsh
- 파일 시스템 종류 : ext2, ext3, ext4, tmpfs, UnionFs, NFS
- ls, mkdir, cp, mv, rm, chmod, chown, cat, head, tail, ps, kill, netstat, grep,...

8. 미들웨어
- OS와 Application 사이에 들어가는 모든 Software
- Web Server : Client의 HTTP Request를 받아, 응답 및 호출하는 기능 담당
- Web Server의 종류 : Apache Http Server, IIS, Nginx
- (R)DBMS : OracleDB, MySql, MariaDB, MSSql, PostgreSQL
- NoSQL
- Key-value : 단순한 형태. Redis, Amazon DynamoDB, Memcached, LevelDB
- Document : 문서 계층 구조. MongoDB, Couchbase, Elastic Search(불완전)
- Wide Column Stores : 2차원 Key-value. Casandra, HBase
- Graph : 연속적 노드/엣지/프로퍼티. Neo4j
- 기타 : influxDB, Hadoop, Spark, ClickHouse
- 시스템 모니터링 : Zabbix, Datadog, Mackere, Prtg / Scouter, Sentry

9. DB Engine 점유율
Ref. https://db-engines.com/en/ranking_trend

10. 인프라 구성 관리
- Mutable Server (On-premises) VS Immutable Server (Cloud)
- OS설치, 각종 설정, 설치 or Build Server UP
- 서버가 100대라면? -> Infrastructure as Code
- Bootstrapping : OS시작 자동화 Vagrant (cf. Docker)
- Configuration : OS&미들웨어 설정 자동화. Ansible, Chef, Puppet
- Orchestrations : 다중 서버 관리 자동화. Kubernetes
- CI/CD : Jenkins, Travis CI, Gitlab, Github
- CI : Continuous Integration. 지속적 통합. 잘 동작하는 코드를 자동 유지
- CD : Continuous Delivery(Deployment). 지속적 제공(배포). 배포 자동화
- 가상화 : 물리 서버 내 가상서버. 별도 OS Overhead (VMware, VirtualBox)
- 반가상화 : 컨테이너 기반. OS자원 공유 (Docker)

11. 장애 / 알림 / 복구
- SLA : Service Level Agreement. 서비스 수준 계약
- 장애의 감지 : 모니터링(Mornitoring) / 알림(Notification)
- 알림이 필요한 경우와 그렇지 않은 경우에 대한 세분화 필요
- 알림이 너무 많으면 Spam이 되어 정작 중요한 알림을 놓치게 됨(feat. 중대본)
- Web Application Server의 필수 모니터링 (aka 용어)
- tps (초당처리량) / throughput(처리)
- load average (평균 CPU 사용량) / rpm (분당회전율)
- uptime (가동시간) / elapsed time (응답시간)
- request count (요청수) / jvm gc (JVM 가비지컬렉션) / jvm heap (JVM 힙 메모리)
- used memory (사용메모리량) / disk RW( 디스크 읽기쓰기 사용치)
- traffic (네트워크 부하) / sql query time (쿼리 실행 시간)
- 복구 : 누구나(전원) 복구 처리할 수 있도록 정량화/자동화하는 것이 중요

12. 장애의 방지
- 코드 인스펙션 : 자동화된 도구를 통한 정적 분석 기법 (Sonar Cube)
- 온/오프라인 코드 리뷰를 통한 코드 반영 (PR의 PR까지!)
- 테스트
- 유닛테스트 : 각 코드의 기능별 정상 동작 여부를 확인 (JUnit)
- 통합테스트 : 완전한 어플리케이션의 정상 동작 여부를 확인 (JUnit, qTest)
- 화이트박스 테스트 : 내부 소스 코드를 테스트하는 기법. 개발자 관점
- 커버리지 검증 : 구조의 코드가 얼마만큼 활용되는가에 대한 검증 (Codecov)
- 블랙박스 테스트 : 정상 입력과 비정상 입력을 입력하여 올바른 출력이 나오는지. 사용자 관점
- 부하 테스트(Stress Test) : 어플리케이션의 특정 상황에서의 부하를 측정 (JMeter, Locust)
- 장애 확율은 결코 0을 만들 수 없고, 최대한의 검증, 그리고 장애 상황에 대한
빠른 감지와 대처만이 유일한 답 (탐지->전파->해결->보고->회고)
- 대다수의 장애는 사람으로부터 만들어지지만, 그 책임을 사람에게 물으면 조
직은 건전하게 발전할 수 없음. 시스템 관점에서 접근이 중요 (LINE 사례)

13. DevOps란 무엇인가
- 소프트웨어 개발(Development)과 운영(Operation)의 합성어
- 시스템 엔지니어와 소프트웨어 엔지니어 간의 협업/통합 환경 혹은 문화
- Developer는 새로운 것을 도입하기를 원함 (변화를 지향)
- Operator는 현재의 시스템이 안정적으로 운영되기를 원함 (안정을 지향)

14. DevOps의 특징
- 핵심요소 : CARMS
- Culture : 문화, 한 마디로 협업
- Automation : 자동화, CI/CD와 반복적인 작업에 대한 자동화
- Lean : 간소화, 문제 인식으로부터 개선까지의 비효율적인 절차를 지양
- Measurement : 측정, 다양한 지표를 측정하고 그것을 가시화/피드백/계획 수립 활용
- Share : 공유, 서로의 경험을 공유
- Cross Functional Team : 개발~배포 및 테스트까지 담당자를 하나의 팀으로
- Widely Shared Metrics : 팀원 모두가 알고있는 하나의 공유된 지표
- Automating Repetitive Tasks : 반복적인 일들의 자동화
- Post Mortems : 후처리. 장애나 이슈에 대한 공유
- Regular Release : 짧은 주기의 정기배포를 통한 서비스 개선 및 VoC 반영

15. 그럼 우리는? (마무리)
- 현 배포 전략 : 전체 수동 배포 (Canary 방식- cf. Rolling / BlueGreen)
- 배포 전략 참고 : https://www.slideshare.net/awskorea/ci-cd-pipleine-on-aws
- 개선 포인트 : 복잡하고 절차와 추궁에 집착하는 배포 방식 자동화 필요
- On-premise 방식에서 컨테이너 방식으로의 변경은 위험이 따름
- 점진적 개선 필요
- Configuration 자동화 (신규 서버 추가 / 제거를 보다 쉽게 Setup/Remove할 수 있도록)
- DevOps(or 배포) UI (지정한 누군가가 없더라도 누구나 편리하게 배포를 공유할 수 있도록)
- 절차 간소화 (현 배포 요청서 방식을 Git Branch 모델의 정량화를 통해 간소화)
- 어플리케이션 개발자 입장에서는 가장 Static한 영역으로서의 침범
- 시스템 엔지니어 입장에서는 전혀 새로운 생태계로의 진입
- 알아야할 건 넘치지만, 생각보다 중요한 것은 한정적
- 그런데 이건 너무나 알아야되는 중요한 것 (내가 정한 건 아니지만...)
- 부족한 설명에 경청(했냐?) 감사