ECS의 새로운 기능의 추종
ECS의 새로운 기능 활용
Amazon ECS는 AWS에서 개발, 활용한 관리 서비스입니다.ECS 자체는 OSS가 아니기 때문에 출시되기 전에는 실제로 어떤 새로운 기능이 언제 출시될지 알 수 없다.그럼에도 ECS의 새로운 기능은 활용을 더욱 편리하게 할 수 있는 기능이 많아 발매 후 조속히 활용할 수 있기를 기대한다.
ECS의 새로운 기능이 출시되자마자 ecspresso는 가능한 한 신속하게 대응하는 방침으로 개발되었다.저자 자신에ecspresso 이외에 관리하는 ECS시스템이 없기 때문에 새로운 기능을 사용하려면 반드시ecspresso를 통해 대응해야 한다는 것이다.
여기서 ECS의 새로운 기능을 어떻게 따라가는지 설명한다.
ecspresso=AWS SDK의 얇은 wrapper
'얇은'이 무엇인지에 대해서는 논란이 있지만 ecspresso는 AWS SDK(aws-sdk-go)가 제공하는 인터페이스를 숨기지 않고 사용자에게 공개한다.구체적으로 말하면 서비스 정의와 작업 정의 파일이다.
이 파일들을 읽는 함수는
ecspresso.LoadServiceDefinition 와 ecspresso.LoadTaskDefinition 이다.이 함수의 서명에서 볼 수 있듯이 aws-sdk-go/service/ecs의 구조는 직접 되돌아온다.func (d *App) LoadServiceDefinition(path string) (*ecs.Service, error)
func (d *App) LoadTaskDefinition(path string) (*ecs.TaskDefinition, error)
AWS SDK가 이러한 구조에 새로운 기능 지원을 추가하는 한 이 버전을 사용하면 새로운 서비스 정의와 임무 정의 요소에 대응할 수 있다는 것이다.
ecspresso 독자적인 구조체를 만들지 않아 새로운 기능을 따라가기 쉽고, 사용자들에게도 공식 SDK와 CLI 처리된 JSON을 직접 읽을 수 있는 안도감 있는 제작이다.
실제 새로운 기능 추종의 예
ecspresso가 2020-11-30에서 방송된 deployment circuit breaker 기능을 어떻게 지원하는지 예로 들자.
2010-11-24에 발표된 AWS SDK Gov1.35.35 기반Dependabot에 Pull Request(PR)가 자동으로 생성됩니다.
이 PR에 첨부된 변경 로그를 보면 서비스/ecs에는 deployment circuit breaker에 대한 대응이 포함되어 있습니다.
service/ecs: Updates service API and documentation
This release adds support for updating capacity providers, specifying custom instance warmup periods for capacity providers, and using deployment circuit breaker for your ECS Services.
이 PR을 통합한 후
ecs.DeploymentCircuitBreaker 구조체가 추가돼 서비스 정의 파일에 기술된deploymentCircuitBreaker 요소만 읽을 수 있다.{
"deploymentConfiguration": {
"deploymentCircuitBreaker": {
"enable": true,
"rollback": true
},
실제 읽기
deploymentCircuitBreaker 요소를 확인하기 위해 테스트를 추가하고 손에 구축한 2진법으로 프로그램을 풀며 기능이 사용 가능한지 확인한 후 v1.발표발매일은 일본시간 2010-12-01의 오후다.실제로 이날 아침 deployment circuit breaker의 발표(트위터에서)를 알고 SDK 업데이트를 확인한 뒤 PR을 병합해 몇 줄의 테스트 확인 동작을 추가한 뒤 발표해 수 시간 만에 대응을 완료했다.
이처럼 서비스 정의와 임무 정의에 요소를 추가해 활용할 수 있는 새로운 기능이라면 아주 적은 시간 안에 추적할 수 있다.
과도한 추상화를 피하다
ecspresso를 개발하기 시작하면서 임무와 서비스 정의를 가진 JSON의 처리가 번거로워지기 쉽다는 것을 깨달았다.그래서 나도 추상적으로 사용하기 쉬운 정의 파일을 사용하는 것이 좋겠다고 생각해 본 적이 있다.그럼에도 독자적인 설정 파일을 가져오면 ECS의 SDK 간 상호 변환을 실제로 수행하는 시간이 늘어난다.
애초 SDK의 구조체를 노동력을 줄이고 자재를 줄여 직접 사용한 것으로 여겨졌으나 최초 발표부터 3년간 새로운 기능을 지속해서 추종한 결과 SDK를 추상화하지 않고 직접 사용하는 것이 새로운 기능을 신속하게 지원할 수 있는 관건이라는 결론이 나왔다.
ecspresso를 유니버설 컨테이너 공개 서비스의 프레젠테이션 도구로 고려한다면 ECS 이외의 서비스와의 공통점을 찾아 유니버설 설정 파일을 만드는 것이 더 효과적이지 않겠는가.그러나 사실상 ECS만을 위한 도구이기 때문에 졸렬한 추상화를 하지 않는 것이 옳다.
정의 파일로서 JSON만 읽더라도 이후 Jsonneet을 설계할 수 있는 정의 파일 생성이십 일의 여지를 남긴 결과 좋은 판단이었다.독자적인 DSL 등을 가져오면 다른 도구의 생성이 쉽지 않겠죠.
24일째에ecspresso의 형제 제품인lambroll과sailtrim의 디자인 도구를 소개합니다.
Reference
이 문제에 관하여(ECS의 새로운 기능의 추종), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/fujiwara/articles/ecspresso-20201223텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
