로바이

https://www.slideshare.net/stegkorea/it-iso20000 사이트 참조

* ISO/IEC 20000 인증 완료에 따른 IT서비스 관리의 이점
-신뢰성 향상
-고객 만족도 향상
-비즈니스 목표에 대한 이해도 향상
-브랜드 평판 향상
-새로운 기능 개발
-ITIL 경험 활용
-계획하고 통제하는 능력 향상
-응답 시간 단축
-인시던트 감소
-지속적인 개선 문화 조성
-경쟁 우위 확보

* ISO/IEC 20000 인증 심사 항목

-the framework of ITSMS/Service Level/Service Reporting 
-Incident Management * (장애관리)
-Problem Management * (문제관리)
-Change Management / Release Management * (변경/릴리스관리)
-Configuration Management * (구성관리)
-SLM / Service Reporting * (서비스수준관리)
-Availability & SCM (가용성관리)
-Capacity Management * (용량관리)
-Information Security (보안관리)
-BRM(Business Relationship Management) (비즈니스 관계관리)
-Supplier management (공급업체관리)
-Budgeting and Accounting (서비스 예산 및 회계)
** 서비스연속성관리

1.배포 전략이란?

이전에는 소스 배포가 비업무시간, 수주에서 수개월에 한번 수행하는 큰 작업이었으나 최근에는 서비스를 구성할 때 모놀리틱 서비스 환경에서 마이크로 서비스 환경으로 많이 바뀌면서 배포 주기가 짧아지게 되었다. 

더 자주 소스를 배포하는 방식으로 변화되고 있는 만큼 변경 사항이 생겼을 때 더 빠르게 반영할 수 있다는 장점은 있지만 소스를 수정하는 것은 항상 리스크가 따르기 때문에 이에 대응한 배포 전략을 구성해야한다.

2.배포 기법

2.1  Rolling Strategy

애플리케이션의 이전 버전의 인스턴스를 새로운 버전의 인스턴스로 서서히 대체하는 방식으로 가장 일반적인 배포 방식이다.

Rolling은 일반적으로 이전 구성 요소를 축소하기 전에 준비 상태 점검을 통해 새 POD가 준비될 때까지 일정 비율을 다운하지 않고 대기하고 중대한 문제가 발생하면 Rolling을 중단할 수 있다. Rolling 배포는 Canary 방식의 구축이며, 모든 이전 인스턴스를 교체하기 전에 새로운 버전(카나리아)을 테스트하고 준비 상태 점검이 성공하지 못하면 카나리 인스턴스가 제거되고 배포 구성이 자동으로 롤백(Roll-Backup)된다.

- 장점
  . 서비스 다운타임 없이 새버전의 어플리케이션으로 무중단 배포 가능
  . 순차적으로 진행함으로 손쉽게 롤백이 가능
  . 서버자원이 2배 필요한 Blue/Green 배포방식에 비해 서버 자원 제약시 유리

- 단점
   . 어플리케이션에 대한 복잡한 검사를 구현해야 하는 경우는 부적합
   . 좀 더 긴 배포시간을 요함
   . 배포중인 서버는 중단된 상태로 서버 부하량이 늘어난 상태에서 배포 시작시 나머지 서버 자원들의 부하량이
     늘어나 서비스 전체가 마비 될 수 있음(이벤트 확인 필요)
   . 롤백 과정이 다소 복잡하다

2.2  Canary Deployments

사용자나 서버의 일부에 릴리즈를 롤아웃하기 위한 패턴이다. 그 아이디어는 먼저 서버의 작은 서브셋에 변경사항을 배포하고, 테스트한 다음 나머지 서버에 변경사항을 롤아웃하는 것이다.
Canary Deployments는 다운타임에 미치는 영향이 적은 조기 경고 표시기 역할을 한다. 카나리아 구축이 실패해도 나머지 서버들은 영향을 받지 않는다.

- 장점
   . 신버전 배포전 운영환경에 직접 테스트를 진행해 볼 수 있음
   . 단계적인 전환 방식으로 리스크를 최소화하고 상황에 따라 트래픽 양을 늘리거나 롤백이 가능

- 단점
   . 동시에 두개의 서로다른 버전이 운영됨으로 버전 관리 중요

2.3  Blue-Green Deployment

Blue(OLD Version)와 Green(New Version)이라는 동일한 두 운영 환경을 운영하여 다운타임과 리스크를 줄이는 방식으로 모든 서비스 운영 환경은 오직 하나의 환경만 존재한다. 비용상의 문제로 물리서버 대상보다 도커나 컨테이너같은 가상 환경에서 사용한는 것이 유리하다.
어플리케이션의 새 버전을 준비할 때 배포 및 최종 테스트 단계는 라이브가 아닌 환경에서 수행되며, Green에서 어플리케이션을 배포하고 완전히 테스트한 후에는 로드발란서로 전환하여 들어오는 모든 요청을 Blue가 아닌 Green으로 이동 시킨다.
- 장점
   . 운영 다운타임 최소화(사실상 배포방식 중 가장 짧음)
   . 배포시간이 짧음
   . 배포 리스크를 적고 롤백이 단순함(Green으로 유입되는 경로를 Blue로 변경하여 즉시 적용)

- 단점

  . 신버전과 구버전 모두 필요하여 리소스가 두배 이상 필요

  . 롱텀 트랜잭션이 수행 중 일경우 전환시 어떤 방식으로 처리할 지 고려 필요

  . Blue와 Green 두 환경간 migration이 배포때 마다 필요하며, 롤백 수행시에도 고려 필요

2.4  Recreate Strategy

Rolling 이랑은 다르게 새 어플리케이션을 배포시 기존 POD를 모두 삭제한후 배포가 되므로 일반적으로
사용되는 배포방식은 아니다.

Recreate 전략을 사용하는 경우는 다음과 같다. 서비스가 다운되어도 문제가 없는 경우 사용한다.

  1) 새 어플리케이션을 시작하기 전에 마이그레이션 또는 데이터 변환을 실행해야 하는경우
  2) 신규 버전의 어플리케이션 코드를 기존 어플리케이션과 같이 쓸수 없는 경우
  3) 여러 복제본 간에 공유할수 없는 RWO 볼륨을 사용하는 경우

- 장점

  . 다른 배포방식보다 빠른 배포시간

- 단점
  . 서비스 다운 타임이 발생함

2.5  Kubernetes 배포 전략 적용 권고사항

Quota와 Limit Ranges와 같은 리소스 제한 설정을 사용하는 경우, 배포 전략 중 Recreate, Rolling 전략을 사용할 때 배포 오동작을 막기 위한 설정 개선 방안을 제시한다.
Recreate 배포 전략을 사용해서 배포하는 경우, 프로젝트별 Quota의 pod 개수는 실제 자동확장 최대 pod 개수 보다 2 큰 수(deployer pod + builder pod 포함)로 설정할 것을 권고 한다.
Rolling 배포 전략을 사용해서 배포하는 경우, 프로젝트별 Quota의 pod 개수는 실제 자동확장 최대 pod 개수에 deployer pod, builder pod 개수를 포함하고, maxSurge(기본 25%)값 반영하여(autoscale max pod 개수 * (maxSurge 25%)) 산정할 것을 권고 한다.

[Azure 도움 사이트]

1. Azure 제품 설명
https://learn.microsoft.com/ko-kr/docs/  (기술문서)

https://learn.microsoft.com/ko-kr/azure/ (학습)

https://www.youtube.com/user/microsoftlearning (MS유튜브)

2. Azure 서비스별 서비스 수준 계약(SLA) 내용

https://azure.microsoft.com/ko-kr/support/legal/sla/

3. Azure Resource Manager QuickStart Templates

https://github.com/Azure/azure-quickstart-templates

4.Azure 교육용 Lab가이드
http://https://learn.microsoft.com/ko-kr/training/courses/browse/

https://learn.microsoft.com/ko-kr/training/browse/

https://github.com/MicrosoftLearning (MS실습자료)

5.Azure 가격

https://azure.microsoft.com/ko-kr/pricing/

[Azure 도움 프로그램]

1. Azure CLI(Windows용)
https://learn.microsoft.com/ko-kr/cli/azure/install-azure-cli-windows?tabs=azure-cli

▶Azure CLI 명령어
https://learn.microsoft.com/ko-kr/cli/azure/?view=azure-cli-latest 

2. PowerShell 설치I(Windows용)
https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.2

3. Azure Resource Manager QuickStart Templates

https://github.com/Azure/azure-quickstart-templates

프로그램을 설치하면 자동으로 설치후 시작메뉴에 설치된 프로그램의 메뉴폴더가 생기게 된다.

그런데, 대부분은 메뉴 폴더명만 보면 어떤 프로그램인지 알 수 있으나 일부프로그램은 잘 모를 

수 있다.

이럴때 본인이 이해하기 쉬운 이름으로 변경하여 관리 가능하다.

※ 시작메뉴 폴더명 변경 방법

① 탐색기를 실행

② C:\ProgramData\Microsoft\Windows\Start Menu\Programs 이동
     ex: Cisco 메뉴폴더 확인

③ 메뉴 폴더명을 원하는 이름으로 수정
     ex: Cisco 메뉴폴더 명 →  Cisco VPN 으로 수정

④ 시작메뉴를 클릭하면 수정된 메뉴를 볼 수 있다.
     ex: 시작을 누르면 Cisco VPN 으로 메뉴 폴더 변경 확인

PSR(Problem Steps Recorder)은 Windows에 기본설치된 문제가 발생했을 때 취한 정확한 단계를 기록하여 장치나 OS의 문제를 해결하는 데 도움이 되는 프로그램이다. PSR 수행한 결과를 MS지원 전문가에게 보내 문제 해결의 도움을 받을 수 있다.

• Steps Recorder는 기능 및 바로 가기 키를 제외하고 사용자가 입력하는 텍스트(예: 암호)를 기록하지 않는다.
• 전체 화면 게임과 같은 일부 프로그램은 정확하게 캡처되지 않을 수 있다.

Ⅰ.PSR은 어떻게 사용하나?

1. Steps Recorder를 열려면 시작 버튼을 누른 다음  Windows 보조프로그램 > 단계 레코더 (Windows 10) 또는 PSR 입력

    또는 보조프로그램 > 문제 단계 레코더 (Windows 7 또는 Windows 8.1)를 선택

2.기록 시작 을 선택

단계레코더(PSR)가 자동으로 활성 창을 캡처하고 기록하여(현재 수행 중인 응용 프로그램에 관계없음) 단계별 진행 상황을 보여줌

3. 진단하려는 문제를 재현하는 단계를 진행한다. 언제든지 녹음을 일시 중지하고 다시 시작할 수 있다.

필요한 사항에 따라 녹화를 일시 중지하거나 다시 시작하며 녹화 할 수 있다.

4. (선택 사항) 녹화하면서 설명 추가 를 선택하고 마우스를 사용하여 화면에서 설명을 달고 싶은 부분을 선택하고
    설명을 입력한 다음 확인 을 선택 한다.

설명 추가 버튼을 클릭하면 오류를 표시하는 메시지 영역을 강조 표시하고 명확한 이해를 위해 설명을 추가할 수 있다.

5.완료되면 녹화 중지 를 선택 한다.

녹화 중지 버튼을 클릭하면 스크린샷과 함께 수행된 활동의 단계별 목록을 보여주는 새 창이 열린다. 
(예: 패키지 설치 중에 오류가 발생하고 이 오류와 수행한 단계를 기록하려면 "기록 시작" 버튼을 누른 다음 설치 패기지를 시작하고, 오류 메시지가 표시되면 "녹화 중지" 버튼을 눌러서 기록하면 된다)

6.수행한 단계의 기록을 검토하여 표시하려는 내용이 표시되는지 확인한다. 

저장 을 선택 하고 .zip 파일의 이름을 지정하고 저장할 위치를 선택한 다음 저장 을 선택 한다. 

이 .zip 파일을 첨부하여 PC의 문제 해결을 돕는 사람에게 보낼 수 있고 모든 웹 브라우저에서도 볼 수 있다.

※문제 단계 기록기(PSR)는 녹화 시작부터 중지까지의 모든 사용자 활동을 캡처하고 단계 정보별로 자세한 단계를 제공합니다. 이 파일을 저장하고 이 정보를 MS나 전문가와 공유하여 문제를 해결할 수 있다.

Ⅱ.설정 조정 방법은?

1. 단계 레코더에서 도움말 버튼 옆에 있는 아래쪽 화살표를 선택한 다음  설정 을 선택한다 .

2. 다음 설정을 변경 가능하다

• 출력 위치. 파일을 저장할 때마다 위치와 파일 이름을 묻는 메시지가 표시되지 않도록 하려면 찾아보기 를 선택 하여 기본 위치와 파일 이름을 설정한다.
• 화면 캡처를 활성화합니다. 예를 들어 화면에 공유하고 싶지 않은 개인 정보가 표시될 수 있는 경우와 같이 스크린샷을 캡처하지 않으려면 아니요 를 선택 한다. 앱은 여전히 ​​단계에 대한 텍스트 설명을 기록한다.
• 저장할 최근 화면 캡처 수입니다. 기본적으로 캡처 파일의 크기를 줄이기 위해 마지막 25개의 스크린샷만 저장하므로 그 이상을 녹화해야 하는 경우 저장할 최근 화면 캡처 수를 늘려야 한다.
  

   ※참고:  여기에서 조정하는 모든 설정은 일시적 임으로 단계 레코더를 닫았다가 다시 열면 기본값으로 초기화된다.

[ExpressRoute] 주요 네트워크 지점 설명

* 서버 Logging설정이 되어있는지 점검하고, 특이사항이 있는지 확인 필요!!

3) Priority : 심각도를 의미함

4)설정 예시

*.emerg      shutdown - h now                    //모든 장치의 emerg발생시 Shutdown
kern.*         /dev/console                            //커널 관련 로그를 /dev/console에 남김
authpriv.*    /var/log/sercure                       //xinetd접속 로그를 /var/log/sercure 남김

*.info;mail.none     /var/log/message          //모든 facility에서 발생하는 info이상 심각도(2-8)의
                                                                     이벤트를 로깅하되 mail Facility에서 발생하는 로그는 로깅하지 않음
*.*;auth,authpriv.none,local0.none      -/var/log/syslog         
                                                                 //모든 로그(*.*)를 /var/log/syslog에 기록하지만, 세미콜론(;) 이후의 facility들인
                                                                   auth, authpriv, local0 은 제외(none)하라는 것임. 화일이름 앞의 - 는 로그를
                                                                   파일에 바로 쓰지 말고 메모리에 로그를 가지고 있다가 디스크에 입출력 여유가
                                                                   있을 경우 쓰라는 의미임
                                                                (http://shallowsky.com/blog/linux/rsyslog-conf-tutorial.html 의 Rules Section참조)

• 파일 뿐 아니라 다른 곳으로도 로그를 보낼수 있음
  @IP, @[hostname] : 다른 서버로 로그 전달
  [사용자] : 지정한 사용자가 로그인 한 경우, 해당 사용자의 터미널에 표시
  * : 현재 로그인 되어 있는 모든 사용자의 터미널로 전달
  /dev/console, [터미널] : 지정한 터미널에 표시

1.Routing 확인 (목적지까지 최대 30홉을 지원하고 각 구간의 네트워크 상태를 확인)

• traceroute (Linux, 33434~33439/UDP 사용) [-option] IP/Domain/Hostname
• tracert (Windows, ICMP 사용) IP/Domain/Hostname

    →tcproute 등 다른 Utility 사용도 가능

   (예: tracert 127.0.0.1
          wildcard-tistory-fz0x1pwf.kgslb.com [xxx.xxx.222.33](으)로 가는 경로 추적:
          1     1 ms     1 ms     2 ms  xxx.xxx.219.1

          2      *           *           *         Request Time Out )

      → * : 패킷의 Trace 결과가 5초 이내에 도달하지 않으면 해당 왕복시간은 *로 표시

* traceroute Option

 -I(대문자 i) : traceroute의 옵션으로 UDP가 아닌 ICMP를 사용하여 라우팅 추적
 -n : 빠른 명령을 위한 DNS lookup 비활성
 -w seconds : 응답 패킷을 수신 받기 위한 시간(Default 5초)
 -q number : hop단 traceroute query수행 횟수(Default 3회)

* tracert Option

 -d : tracert의 옵션으로 주소를 호스트 이름으로 확인하지 않아서 빠른 결과 확인가능

 -h maximum_hops    대상 검색을 위한 최대 홉 수(Default 30홉)
 -j host-list       host-list에 따라 원본 라우팅을 완화(IPv4만 해당)
 -w timeout     각 응답의 대기 시간 제한(밀리초)
 -R                 왕복 경로를 추적(IPv6만 해당).
 -S srcaddr    사용할 원본 주소(IPv6만 해당).
 -4                 IPv4를 사용
 -6                 IPv6를 사용

** trace결과(*로 표시) 대응 방법

IPS(침입차단시스템), 방화벽 등의 접근통제에 의해 trace의 UDP 또는 ICMP패킷이 보안상의 이유로 차단되었거나
실제 해당 구간에 문제가 발생한 경우임

  - trace한 주소가 실제 존재유무 체크, 패킷이 멈춘 곳의 IP를 네트워크팀에 확인

  - trace 수행속도가 느리면 어느 지점에서 시간을 많이 잡아먹었는지 확인

2.Network Interface 확인(TCP/IP 프로토콜 진단)

• netstat [-option]

   (예: netstat -ant      // all, port by number, tcp
         프로토콜, 로컬 주소, 외부 주소, 상태, 오프로드상태 등을 출력)

* Option

-a 모든 소켓 정보를 출력(모든 연결 및 수신 대기 포트를 표시)

-b 외부와 통신하는 실행파일([]안에표시)과 프로토콜, 내외부정보를 출력
     (각 연결 또는 수신 대기 포트 생성과 관련된 실행 파일을 표시)
      [관리자권한으로만 수행 가능, 출력시간이 오래 걸림]

-r 라우팅 정보를 출력

-i [interval] 네트워크 인터페이스에 대한 정보를 출력
   (Windows는 -i 옵션없이마지막에 interval 숫자만 주면됨)

-s 프로토콜(IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP 및 UDPv6)에 대한 통계 정보를 출력

-n 외부 네트워크 정보(IP, Port)를 숫자로 출력

-e 이더넷 통계를 표시(인터페이스 통계, -s 옵션과 함께 사용가능)

-o 각 연결의 소유자 프로세스 ID를 출력

-t TCP만 출력

-u UDP만 출력

**State 필드정보
   6.네트워크 > TCP Diagram 참조      (https://roby.tistory.com/category/6.%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)

**상세활용 참조블로그

김선광의 IT블로그 :  https://blog.naver.com/sunkwang0307/222601632550

3. Ping (접속할 host가 정상 운영되고 있는지 확인, ICMP 사용)

• ping [-option] IP/Domain/Hostname

    (예: ping 127.0.0.1 -t   //수동으로 멈출때까지 반복 수행, Default 4회)

* Option

-t : Ctrl+C로 중지 할 때까지 패킷 전송
  (예: ping 127.0.0.1 -t)
-i(interval) : Ping 주기 지정 옵션(Default 1초)
  (예: ping 127.0.0.1 -i 0.5  //0.5초 주기 패킷 송부)
-s : 전송 패킷 Size를 지정 (Windows : -l)
  (예: ping 127.0.0.1 -s 100 //100byte 크기 패킷 송부)

-w : 정한 시간동안 패킷 전송(Windows : 응답 대기시간-밀리초)
  (예: ping 127.0.0.1 -2 10    // 10초동안 패킷 전송)

-c(count) : 전송할 패킷 수 지정 (Windows : 없음)
  (예: ping 127.0.0.1 -c 10    // 패킷을 10번 전송)

-D : 결과 앞에 타임스탬프 출력 (Windows : 없음)
  (예: ping 127.0.0.1 -D)
-f(flood mode) : 빠른 속도로 패킷 전송하여 상태 확인 (Windows : 없음)
  (예: ping 127.0.0.1 -f)
-O : 전송한 패킷에 대한 응답 패킷을 출력, 어디서 오류 발생했는지 출력 (Windows : 없음)
  (예: ping 127.0.0.1 -O)

1.TCP 3way-handshaking

4계층의 대표적인 TCP는 신뢰성을 기반으로 설계된 프로토콜로서 서비스의 논리적연결(Session)을 담당하며 신뢰성 확보를 위해 3way-handshaking 방식으로 통신한다.

※ Sync Flooding : TCP의 특성을 이용한 해킹기법

- 공격자가 다수의 패킷을 서버로 보내고 ACK는 보내지 않아서 연결은 종료되지 않고 서버의 리소스가 소비되어 정상적인 사용자가 연결을 시도할 때, 서버 접속이 불가능하게 된다.

▶Sync Flooding 방어 방법 

- Syn Flooding 공격방어 및 완화를 위해서는 TCP프로토콕이 연결 지향성(Connection-Oriented)이라는 점을 이용하고

  Handshake과정에 위배된 TCP 패킷이 유입될 경우 비정상적인 트래픽으로 구분하여 차단하는 방법이 가장 효과적임

1)임계치 기반의 Syn Flooding 차단
방화벽의 IP당 Syn요청에 대한 PPS 임계치를 단계적으로 조정하여 Syn Flooding을 차단함

2)First Syn Drop(Spoofed) 설정에 의한 차단
Syn패킷을 보내는 클라이언트가 진짜 존재하는지를 파악하여 차단하는 방법으로 클라이언트로부터
전송된 첫번째 Syn을 Drop하여 재요청 패킷이 도착하는지를 확인하여 Spoofing 여부를 판단하고 차단함

3)Syn이외의 Flooding 공격 방어
Syn이외의 Flooding 공격을 방어하기 위해서는 다음과 같은 다양한 형태의 DDoS 방어 기법을 사용
먼저 정상적인 TCP세션 연결이후 정상적인 트랜잭션이 수해되는지에 대해 검증하여 만약 정상적인 트랜잭션이
일루어질 경우 서버로 전달해야 하고, 정상적인 트랜잭션 없이 TCP세션 연결만 수행할 경우에는 서버로 전달하지
않아야 서버에 부하 증가 현상을 막을 수 있음
또한 네트워크의 정상적인 환경에서 설정된 각 트래픽 유형별 임계치를 통하여 과도한 TCP세션 연결에 대해 차단

**TCP/IP Overhead 참고 링크 : http://tech.kakao.com/2016/04/21/closewait-timewait/

[TCP Diagram]

TCP 기반의 네트워크는 connection의 요청이나 종료를 대기하거나 서로간에 negociate 하기 위한 상태를 가지고 있다

2. TCP Diagram 상태 설명

3. TCP 상태 특징
1) TCP 연결은 양방향이므로, 양 측에서 각각 다른 상태를 관리하게 됨
- 즉, 다른 경로를 통해 `TCP 연결 설정` 및 `TCP 연결 종료`에 갈 수 있음

2) 2가지 다른 TCP 연결 설정 경로
- (능동 개방) Closed -> Listen -> SYN-Received -> Establshed
. 자발적으로 SYN 세그먼트를 보내며 연결 설정하는 경우
- (수동 개방) Closed -> SYN-Sent -> Established
. 수동적으로 SYN 세그먼트를 수신하며 연결 설정하는 경우
  -> 주로, 서버 응용이 TCP에게 상시적 연결 수용 및 대기

3. 다른 연결 종료 경로
- (수동 종료) Eatablished -> Close-Wait -> Last-ACK -> Closed
. 상대로부터 FIN 세그먼트를 받고, 이에대해 응답하며 종료하는 경로
- (능동 종료) Eatablished -> FIN-Wait-1 -> FIN-Wait-2 -> Time-Wait -> Closed
또는, Eatablished -> FIN-Wait-1 -> Closing -> Time-Wait -> Closed
. 자발적으로 FIN 세그먼트를 보내고, 응답을 기다리며 종료하는 과정

4. 세그먼트(전송 계층에서의 데이터 전송 단위) 설명

5. 비정상 종료 상황 예시