스핀에커(Spinnaker)에서는 파이프라인(Pipeline)을 코드(Code)로 관리할 수 있다. 그래픽 사용자환경에서 파이프라인을 편집할 수도 있고, 문서편집기를 이용해서 파이프라인을 편집한 후 바로 적용할 수도 있다. 스핀에커에서 사용하는 파이프라인 코드는 JSON으로 되어 있다. 스핀에커는 파이프라인을 변경하거나 편집하면 S3 또는 GCS에 보관한다. 만약 스핀에커가 사용하는 버켓(Bucket)에 버전기능이 켜져 있다면, 특별한 설정을 하지 않더라도 아래 그림과 같이 파이프라인 변경 이력을 확인할 수 있다. 아래 화면을 보기 위해서는 파이프라인 편집화면에서 파이프라인 액션(Pipeline Actions) 단추를 누르면 된다. 그러면 맨 아래에 파이프라인 변경내역을 볼 수 있는 단추가 생기는 데 이..
AWS를 사용하다보면 API 제한에 걸릴 수 있다. AWS의 서비스 품질을 안정화하기 위한 조치 중 하나이다. 스핀에커(Spinnaker)에서는 AWS에 생성한 자원의 상태를 알기 위해서 주기적으로 AWS API(Application Programming Interface)를 호출하는데, AWS 자원이 많아 지면 호출 수는 꽤 많아진다. 그렇게 되면 어느 순간 AWS에서 지정한 제한선에 도달하게 된다. 그러면 일부 인스턴스들의(Instances)의 현재상태를 알 수 없게된다. 이러한 문제를 해결하기 위해서 AWS의 제한을 늘려달라고 요청할 수 있다. 하지만 AWS에서 항상 높여 주는 것은 아니다. 여유가 되는 범위안에서 높여 줄 수 있다. 그래서 다른 한 편으로는 스핀에커의 설정을 변경하여 AWS를 호출..
객체 지향 설계법, 또는 객체 지향 프로그래밍(OOP: Object Oriented Programming)은 이제 너무 흔한 말이 되었다. 객체지향방법을 적용하면 유지보수가 쉽기 때문에 소프트웨어의 품질이 올라간다는 이야기도 이제는 고전이 되었다. 하지만, 왜 유지보수가 편한지 쉽게 납득시켜주는 경우는 별로 없었다. 완전히 추상적이고 철학적이거나 아니면 '그냥 그런 것'이라고 단정짓는 경우가 대부분이었다. 많은 학생들의 사정도 비슷했을 것이다. 회사 과제를 하면서 만나게 된 많은 개발자들이 자바(Java)를 사용하고 있었으나, 그 사람들이 만든 결과물의 품질은 높지 않았다. 기능을 변경하는 것에 유연하지 못했으며, 기능변경에 대한 부작용이 너무 컸다. 검증 기간 중에는 자신이 만든 코드(Source Co..
2019년, AWS(Amazon Web Services)가 직접 직접관리해주는 베이커리 시스템이 나왔다. AMI(Amazon Machine Image)를 쉽게 만들고 관리할수 있게 해주는 EC2 Image Builder의 등장으로 베이커리 시스템을 자체 구축할 필요성이 많이 줄어 들었다.2013년에, 초기 버전의 베이커리 시스템(Bakery System)을 구축하였다. 당시까지만해도 EC2에 직접 접속해서 패키지를 배포하던 것이 일반적이었다. 어느 날, AWS 콘솔을 확인하던 중 EC2-AUTO라는 인스턴스를 발견했고, 협력업체 담당자인 수석연구원에게 용도가 무엇인 지 물어보았다. 그 분의 답변은 새 서버를 배포할 때 사용할 AMI를 만들려고 하는데, 이 때 t서버 설정의 일관성을 위해 깨끗한 상태의 새..
2014년에 뮤직 라디오(Music Radio)서버를 설계, 개발, 운영했었다. 뮤직 라디오는 음원 스트리밍 서비스였다. 기본적인 구성은 각 지역별로 음악을 공급하는 콘텐스 제공자(CP: Content Provider)가 달랐기 때문에, 각 지역마다 격리된 스택(Stack)을 두기로 했다. 그리고 스택은 각지역에 한 개씩 만들었다. 그리고 사용자는 가장 가까운 스택에 먼저 접속 하도록 최소 지연시간 기반 라우팅(Routing)을 사용하였다. 그래서 사용자는 거의 모든 경우 자신이 있는 곳과 가장 가까운 스택를 이용하게 되었다. 그래서 빠른 속도로 서비스(Service)를 이용할 수 있었다. 위 그림은 2개의 스택을 어떻게 구성했는 지 보여준다. 도쿄와 시드니에 2개의 스택을 구현하였는데, 한국의 사용자..