프로그램 다운타임 최소화 아이디어

프로그램 다운타임은 프로그램 버전 업데이트, 정기 보안 패치, 하드웨어 결함, 소프트웨어 버그, 네트워크 문제 등 다양한 이유로 특정 시스템이나 서비스가 의도되거나 예상치 못한 이유로 작동을 멈추는 시간을 말합니다. 프로그램 다운타임은 다음과 같은 주요 요인에 의해 영향을 받습니다.

• 프로그래밍 언어
• 개발 프레임워크
• 서버 인프라
• 데이터베이스 관리 시스템(DBMS)
• 네트워크 인프라
• 사용자 수 대비 트래픽
• 대외 서비스 연동

개발자들에게 이는 중요한 이슈입니다. 왜냐하면 다운타임 동안에는 사용자들이 서비스를 이용할 수 없게 되며, 이는 잠재적인 수익 손실을 초래할 수 있기 때문입니다.

프로그램 다운타임 구분

정확한 다운타임 시간을 예측하는 것은 매우 어렵습니다. 이는 보안 패치, 프로그램 버전 업데이트, 개발 환경, 코드 품질, 인프라, 그리고 예상치 못한 외부 요인들에 따라 크게 달라질 수 있기 때문입니다.

따라서, 특정 기술에 대한 다운타임 시간을 정확히 알려면 해당 기술과 서비스을 사용하는 실제 시스템의 모니터링 데이터를 현장 상황에 따라 분석하고 적용해야 합니다.

코드 품질에 따라 다운타임 시간이 크게 달라집니다. 코드 품질을 높이기 위한 다양한 방법들을 시도하는 것은 기본입니다.

의도된 다운타임과 예상치 못한 다운타임을 구분하는 것은 중요합니다.

• 의도된 다운타임: 프로그램 버전 업데이트나 정기 보안 패치를 위해 서버를 중지하는 것
• 장애로 인한 다운타임: 하드웨어 결함이나 소프트웨어 버그, 외부 연동 서비스의 예상치 못한 원인으로 인한 서버가 중지하는 것

의도된 다운타임 최소화 아이디어

프로그램에 필요한 주요 기능들을 모듈화

HandStack 에서는 프로그램 다운타임을 최소화하기 위해 프로그램에 필요한 주요 기능들을 모듈화하고, 각 모듈을 독립적으로 업데이트할 수 있도록 설계합니다. 이를 통해 프로그램의 다운타임을 최소화할 수 있습니다.

다음은 서버에 배포되는 각 모듈의 업데이트 주요 파일들 입니다.

modules
│  
├─dbclient
│  │  dbclient.deps.json
│  │  dbclient.dll
│  │  dbclient.pdb
│  │  dbclient.staticwebassets.runtime.json
│  │  module.json
│  ├─Contracts
│  └─wwwroot
│              
├─function
│  │  function.deps.json
│  │  function.dll
│  │  function.dll.config
│  │  function.pdb
│  │  function.runtimeconfig.json
│  │  function.staticwebassets.runtime.json
│  │  module.json
│  │  node.config.json
│  │  package-lock.json
│  │  package.json
│  ├─Contracts
│  └─wwwroot
│
├─logger
│  │  logger.deps.json
│  │  logger.dll
│  │  logger.pdb
│  │  logger.staticwebassets.runtime.json
│  │  module.json
│  ├─SQL
│  └─wwwroot
│
├─repository
│  │  module.json
│  │  repository.deps.json
│  │  repository.dll
│  │  repository.pdb
│  │  repository.staticwebassets.runtime.json
│  ├─Contracts
│  └─wwwroot
│                      
├─transact
│  │  module.json
│  │  transact.deps.json
│  │  transact.dll
│  │  transact.pdb
│  │  transact.staticwebassets.runtime.json
│  ├─Contracts
│  └─wwwroot
│              
└─wwwroot
    │  bundleconfig.json
    │  compilerconfig.json
    │  gulpfile.js
    │  module.json
    │  package-lock.json
    │  package.json
    │  wwwroot.deps.json
    │  wwwroot.dll
    │  wwwroot.pdb
    │  wwwroot.staticwebassets.runtime.json
    ├─Contracts
    └─wwwroot

각 모듈에 기능을 추가하거나 수정할 때는 해당 모듈만 업데이트하면 되므로, 다른 모듈에 영향을 주지 않습니다. 이를 통해 프로그램의 다운타임을 최소화할 수 있습니다.

ack 프로그램은 시작시 다음과 같은 모듈을 선택적으로 사용 유무를 결정하여 실행됩니다.

# 모놀리식 구성으로 프로그램 실행
ack --modules=wwwroot,transact,dbclient,function,repository,logger --port=8000

# 마이크로 서비스 구성으로 프로그램 실행
ack --modules=wwwroot --port=8001
ack --modules=repository --port=8002
ack --modules=logger --port=8003
ack --modules=transact,dbclient,function --port=8004
ack --modules=function --port=8005

화면/기능을 프로그램에서 완벽히 분리

사용자의 업무를 위한 화면/기능을 프로그램에서 완벽히 분리하여 업데이트 할 수 있도록 설계합니다. 이를 통해 사용자들은 업데이트 중에도 서비스를 계속 이용할 수 있습니다.

contracts
├─dbclient
│  └─HDS
│      └─BOD
│          ├─BOD010.xml
│          ├─BOD011.xml
│          └─BOD012.xml
├─function
│  ├─csharp
│  │  └─HDS
│  │      └─TST
│  │          └─CSF010
│  │                  featureMain.cs
│  │                  featureMeta.json
│  │                  
│  └─javascript
│      └─HDS
│          └─TST
│              └─JSF010
│                      featureMain.js
│                      featureMeta.json
├─transact
│  └─HDS
│      └─BOD
│          ├─BOD010.json
│          ├─BOD011.json
│          └─BOD012.json
└─wwwroot
   └─BOD
       ├─BOD010.html
       ├─BOD010.js
       ├─BOD011.html
       ├─BOD011.js
       ├─BOD012.html
       └─BOD012.js

화면/기능을 위한 코드들은 컴파일이 필요없는 텍스트 파일입니다. 이러한 특징은 다음과 같이 사용자들에게 더 나은 서비스를 제공할 수 있도록 돕습니다.

• dbclient, function, transact 모듈의 코드와 설정은 각각 HDS 디렉토리에 업무별로 디렉토리를 생성하여 분리합니다. 여기에 있는 파일들은 ack 프로그램 시작시 메모리 캐시에 등록되어 관리됩니다. 그리고 운영중에도 해당 디렉토리에 파일을 추가 하거나 기존 파일이 수정되면 메모리 캐시에 반영됩니다.
• wwwroot 모듈의 코드는 사용자의 화면을 구성하는 파일들로 구성되어 있습니다. 해당 디렉토리에 파일을 추가 하거나 기존 파일이 수정되면 ack 프로그램에 의해 정적 파일 서버의 컨텐츠로 반영됩니다.

이를 통해 개발자들은 다운타임을 최소화하고, 사용자들에게 더 나은 서비스를 제공할 수 있습니다.

장애로 인한 다운타임 최소화 아이디어

업데이트와 배포 전략

ack 서버 프로그램의 무정지 업데이트를 위한 방법은 여러 가지가 있습니다. 다음은 그 중 일부입니다:

• 로드 밸런싱: 동일한 애플리케이션이 실행 중인 여러 서버를 설정하고, 업데이트를 수행할 서버의 연결을 끊습니다. 이후, 데이터베이스와 같은 중요한 리소스는 다른 서버로 이전합니다. 새로운 애플리케이션 버전을 다른 서버에서 시작하고, 로드 밸런서에 연결합니다.
• 블루-그린 배포: 이 방법은 두 개의 동일한 프로덕션 환경을 사용합니다. 한 환경에서는 실제 트래픽을 처리하고, 다른 환경에서는 새로운 버전을 배포합니다. 배포가 완료되면 트래픽을 새 환경으로 전환합니다.
• 카나리 배포: 이 방법은 새로운 버전을 일부 사용자에게만 제공하여 문제가 발생할 경우 전체 사용자에게 영향을 미치지 않도록 합니다. 문제가 없다면 새 버전을 모든 사용자에게 배포합니다.
• 롤링 업데이트: 이 방법은 서버를 하나씩 업데이트하고, 각 업데이트가 완료될 때마다 트래픽을 해당 서버로 전환합니다. 이 방법은 서비스 중단 없이 점진적으로 애플리케이션을 업데이트할 수 있습니다.

이러한 방법들은 서버 프로그램의 무정지 업데이트를 지원합니다. 하지만, 각 방법은 특정 상황과 요구 사항에 따라 장단점이 있으므로, 적절한 전략을 선택하는 것이 중요합니다.

ack 프로그램의 프로그램 다운타임 대응

개발자들은 다운타임을 최소화하기 위해 여러 가지 전략을 사용합니다. 이에는 장애 복구 계획, 시스템 모니터링, 로드 밸런싱, 자동 복구 메커니즘 등이 포함될 수 있습니다. 이러한 전략들은 시스템의 안정성을 유지하고, 다운타임이 발생했을 때 빠르게 대응할 수 있도록 돕습니다.

• 로깅: 로깅은 프로그램이 어떻게 작동하는지 이해하는 데 도움이 됩니다. 오류가 발생했을 때 로그를 분석하면 문제의 원인을 찾고 해결하는 데 도움이 됩니다.
• 상태 검사: ack 프로그램은 상태 진단에 필요한 EndPoint를 제공합니다. 이를 사용하면 애플리케이션의 여러 구성 요소가 올바르게 작동하는지 확인할 수 있습니다.
• 장애 복구 전략: 장애가 발생했을 때 시스템이 어떻게 복구할지에 대한 전략이 필요합니다. 예를 들어, 재시작, 재연결, 서킷 브레이커 패턴 등을 사용할 수 있습니다.
• 스케일링: 시스템이 과부하 상태가 되지 않도록 적절하게 스케일링하는 것이 중요합니다. 이는 스케일 업(리소스 추가) 또는 스케일 아웃(인스턴스 추가)을 통해 이루어질 수 있습니다.