노드 동기화¶

서비스 규모가 증가하면 관리해야 할 노드도 증가한다. 중앙집중형 관리를 통해 수 천대의 노드에 대해서도 일관된 관리가 가능하다.

설정동기화
캐싱콘텐츠 무효화 API

M2는 고객시스템과 손쉽게 통합될 수 있도록 다양한 방식을 제공한다. 여러 방식을 혼용해 사용하여도 무방한데, 예를 들어 설정동기화는 Kafka로 진행하지만 피드백은 API서버로 받는 것도 가능하다.

See also

env.management. server

설정동기화¶

중앙서버에서 설정을 게시하고 모든 노드들이 해당 설정으로 동기화를 진행한다. 설정동기화가 진행되거나 cli 로 설정이 변경되어 있더라도 setting .feedback 이 설정되어 있다면 수행결과가 리포팅된다.

See also

개별노드 Push 방식¶

가장 기초적인 방식으로 개별 노드의 API를 일일이 호출하거나 SSH 등으로 로컬 편집한다.

See also

별도의 시스템이 필요하지 않고 즉각적인 장점은 있지만, 노드가 많아질수록 관리가 어려워 지속되기 어렵다.

설정패키지 중앙배포¶

설정패키지를 HTTP 서버에 게시하고 모든 노드들이 이 URL을 폴링(polling)한다.

Note

M2는 모든 설정로딩이 완료되면 연관된 패키지까지 모두 tgz 형태의 파일로 압축/관리한다. 이를 설정패키지라고 부른다.

See also

setting 중 tgzPolling

간단한 웹서버 또는 오브젝트 스토리지를 염두에 둔 방식이다. 스테이지 서버에서 검증된 설정패키지를 약속된 경로로 배포하면 정해진 주기에 맞추어 모든 노드들을 동기화한다.

API 서버¶

설정버전관리가 가능하다면 설정API 서버를 운영하는 것이 설정패키지 중앙배포 에 비해 보다 안정적이고 유연하다.

See also

setting 중 apiPolling

setting.feed 포맷 을 수신한 모든 노드는 설정패키지를 다운로드 받아 동기화한다.

스토리지 기반 Master/Slave 설정동기화¶

이 방식은 공용 스토리지를 중심으로 Master 노드의 설정을 Slave가 동기화하는 방식이다.

../../_images/sync_backups3.png — Amazon S3를 이용한 Master/Slave 설정동기화 플로우¶

See also

events
setting 중 apiPolling

먼저 Master 노드에서 events 시점 중 설정변경시 호출되는 onSettingload 설정을 구성한다.

# env.manager.server.events

"onSettingload": {
   "backup": {
      "hostname": "node01",
      "connect": "myStorage",
      "path": "/m2manager"
   }
}

이제 Master 노드의 설정이 변경될 때마다 스토리지에 API 서버 방식을 연동할 수 있도록 설정이 백업된다. Slave들은 Master 노드가 업로드하는 feed.json 경로를 polling하며 설정을 동기화한다.

Note

백업되는 모든 설정패키지는 시간으로 명명되어 자연스럽게 히스토리 관리가 이루어진다.

캐싱무효화¶

중앙서버에서 캐싱무효화 대상을 제공하며 모든 노드가 이를 수행한다.

Note

전체 콘텐츠를 대상으로 하는 패턴 Purge가 과도하게 모든 쓰레드에 의해 수행될 경우 서비스에 영향을 줄 수 있다. 따라서 purge 의 "workerCount": 2 로 제한되어 있다. M2 노드의 CPU 사용량이 여유가 있거나, 미처리된 대상이 너무 크다면 이 값을 늘릴 수 있다.

캐싱무효화가 진행되거나 캐싱콘텐츠 무효화 API 가 수행되면 purge .feedback 으로 결과가 리포팅된다.

See also