정리 블로그

1. 가트너의 하이프 사이클이란?

 미국의 정보 기술 연구 및 자문 회사인 가트너에서 개발한(?) 기술의 성숙도를 표현하는 시각적 도구

기술촉발 - 부풀려진 기대의 정점 - 환멸 단계 - 계몽 단계 - 생산성 안정 단계.

총 5단계로 구성되어있는 사이클.

신기술에 대한 시장의 기대가 어떻게 변하는지 정리된 곡선이며, 신기술을 해당 곡선에 표현하여, 매년 기술을 해당 그래프에 표기하는 형식.

2. 하이프 사이클 그래프

3. 단계별 명칭 설명

(출처:위키피디아)

4. 하이프 사이클(엔터프라이즈 네트워킹 부분 - 2021)

가트너의 하이프 사이클은 위 그림과 같이 분야에 대한 사이클이 표시됨.

5. 개인적인 생각

 하이프 사이클에서 클라우드는 '4단계-계몽 단계'와 '5단계-생산성 안정 단계'의 사이 즈음이 아닐까 하는 생각이 든다. 정부시스템까지도 클라우드에 올리려는 움직임이 있으며, 기술이 시장의 주류를 이루는 것으로 생각한다.

각 리전의 서비스 상태가 정상인지 확인할 수 있는 사이트.

status.aws.amazon.com/

위 사이트를 방문하면 아래와 같이,

North America, Asia Pacific, Europe 등의 리전을 선택 가능함.

게다가 해당 리전의 AWS측이 제공하는 관리형 서비스(API Gateway, Dynamo DB 등)의 현재 상태를 볼 수 있다.

해당 리전에서 특정 서비스에 장애가 발생 시, 'Service is operating normally'가 아님!

DevOps

 Development(개발) + Operations(운영) 의 합성어로, 아래 목적을 위해 만들어졌다.

• 제품 출시까지 걸리는 기간(time to market) 단축
• 새로운 판의 더 낮은 실패율
• 픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
• 복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)

즉, 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적.

SRE(Site Reliability Engineering)

 DevOps는 운영에 대해 초점을 맞췄다면, SRE의 핵심은 안정성에 초점을 맞추며, DevOps의 안에 포함될 수 있는 개념이라고 이해하였습니다. SRE에 관심을 가져야 하는 사람은 DevOps 뿐 아니라, System Admin과 IT 전문가들도 관심을 가져야 되며, 일정 수준의 안정성이 보장되지 않는다면 비즈니스에 치명적으로 작용할 수 있음을 주의해야 합니다. 

 어떠한 시스템도 100% 안정성을 가지고 운영될 수 없지만, 안정성의 수준을 정하고자 한다면 답은 "주요 관련자가 적절하다고 생각하는 특정 수준"을 의미한다고 합니다.(해당 의미는 MicroSoft의 Doc을 참고하여 작성하였습니다.)

----------------------------------------------------------------------------------------------------------------------------

DevOps 및 SRE는 동일한 과제를 해결하기 위한 두 가지 병행 시도임을 알아야 합니다. SRE는 DevOps 이후의 다음 진화 단계가 아닙니다. SRE는 “DevOps의 미래”로 생성된 것이 아닙니다.(MS Docs 발췌)

MS Docs를 조금 더 참고하고 싶으시다면,

docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/3-sre-in-context

위 Docs를 참고하면 도움이 될 것 같습니다.

- Docker(도커)
 -. 컨테이너 기반의 오픈소스 가상화플랫폼
 -. 백엔드 프로그램/데이터베이스 서버/메세지 큐 등 어떤 프로그램도 컨테이너로 추상화 가능. AWS, Azure, Google cloud 등 어디서든 실행 가능
 -. 1개의 서버에 여러 개의 컨테이너 사용. 독립적 실행. 각 컨테이너의 CPU / Mem 사용량 제한 가능.
 -. 새로운 컨테이너를 만드는데 걸리는 시간은 새로운 VM을 만드는 것보다 훨씬 빠름.
 -. 리눅스에서는 Docker 이전에 cgroup를 통해 process를 격리하는 방법을 사용하였음. 이는 Docker의 개념과 유사함.(Linux Container a.k.a LXC)
 -. Container만큼 중요한 개념은 IMAGE.
  -. Container 실행에 필요한 파일, 설정값 등을 포함하며 변하지 않음
  -. IMAGE는 Container를 실행하기 위한 모든 것을 가지고 있음.!!!
  -. AWS 이미지 생성과 Docker Image는 비슷한 역할을 한다는게 내 결론. Docker 이미지 크기는 수MB ~ GB까지도 있음.

** Docker의 기본 네트워크 모드는 Bridge모드. 약간의 성능 손실 있음.

   따라서, 네트워크 성능이 중요한 프로그램의 경우 --net=host 옵션 고려.

??) 네트워크 Bridge모드란?

  -. 호스트의 네트워크와 게스트의 네트워크를 브릿지하여 게스트 네트워크가 호스트 네트워크를 사용할 수 있는 방식.

    (호스트와 게스트 네트워크를 하나로 연결하여, 같이 사용한다고 생각하면 됨.)

SSL보안인증서?
도메인을 보호.
인증서 유효기간은 1~3년. 장기간 구매를 통해 매년 관리할 필요가 없게 할 수 있음.


와일드카드 인증서
"1. 하나의 고유한 FQDN(Fully Qualified Domain Name) 아래 여러개 하위 도메인 보호.
하나의 인증서로 여러 도메인 관리. 향후 추가되는 하위 도메인을 즉시 보호 및 관리비용 절감"
2. '*'를 FQDN의 접두사로 사용하여 여러 서비스를 보호하는 SSL인증서. 하나의 인증서로 여러 서비스에 인증서를 적용.
   접두사로 '*'를 사용하기에 mail.dennis.com, spam.dennis.com 등은 하나의 인증서로 적용 가능하지만, mail.dennis.net과 같이 접미사가 달라질 경우 적용 불가능. Mail.test.dennis.com 또한 적용 불가


SAN 인증서
1. 웹 사이트가 동일한 도메인 이름을 공유하지 않는 경우에도 유연하게 사용 가능.
2. SAN인증서는 인증서에 입력된 FQDN만 지원. 인증기관에 따라 하나의 인증서로 100개 이상의 FQDN을 지원할 수 있음. 인증 마크와 인증서는 입력된 기본 도메인 이름에만 적용. 다른 도메인 이름은 해당하지 않음.
3. 하나의 서비스에 여러 도메인이 필요한 경우 사용.
4. 도메인의 수가 추가되더라도 무료 재발행 가능


Wildcard, SAN의 장점은 도메인 추가시 구입없이 즉시 발급 가능
와일드카드는 단일도메인 아래 하위 도메인을 보호하는데 유용하게 쓰임.
Spam.dennis.com / mail.dennis.com 등."
반면 SAN은 dennis.com / dennis.net 등과같이 대체 도메인을 보호하는데 유용하게 쓰임

SAN : dennis.com / dennis.net  등에 사용
WildCard : www.dennis.com / taek.dennis.com 등 하위 도메인에 사용

*Ref) EV Certification(Extended Vaildation) : 주소창이 녹색으로 변하는 인증서로 신뢰 단계가 높은 인증서

IaaS / PaaS / SaaS

1. IaaS(Infrastructure as a Service)
 -. 서버를 운영하기 위해 Server, IP, Network, Storage 등 구축이 필요.
 -. 가상환경에서 쉽고 편하게 이용할 수 있게 서비스 형태로 제공.
 -. HardWare보다 확장성이 좋고 탄력적이며 빠른 제공을 할 수 있음.
 
2. PaaS(Platform as a Service)
 -. 서비스를 개발할 수 있는 환경과 응용 프로그램을 개발할 수 있는 API까지 제공하는 형태
 
3. SaaS(Software as a Service)
 -. Cloud 환경에서 동작하는 응용 프로그램을 서비스 형태로 제공하는 것.
 -. 메일 서비스가 대표적인 예.
 -. 사용자는 메일 시스템이 어떻게 동작하는지, 백업이 어떻게 진행되는지는 알 필요가 없으며, 단순히 사용만 하면 되는 환경

( 이미지 출처 : https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/ )

*On-Premises : 위에 이미지와 같이 모든 물리장비 구비가 필요함.

 -. 초기 구축 비용에 많은 투자 필요.

 -. 서버 사용 대수와 기타 부자재가 일정하게 유지된다면 장기적으로는 비용이 저렴할 수 있음.(클라우드 서비스에서 비용 최적화가 진행되지 않는다는 가정.)

 -. 탄력적으로 시스템 운영 불가(이벤트 서버 증설 등)