스핀에커(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개의 스택을 구현하였는데, 한국의 사용자..
회사에서도 코드 리뷰(Code Review)를 강조하기 시작했다. 몇 년 전 부터 애자일(Agile) 바람이 불더니 코드 리뷰를 많이하는 사람에게상을 주기 시작했다. 역시나 본질을 왜곡했기 때문에 마음에 들지는 않지만 어쨌든 회사차원에서 코드 리뷰라는 단어에 관심을 가졌다는 것만으로도 무척 고무적인 일이었다.회사에서는 애자일이 단지 빠른 주기로 개발 및 개선을 진행하는 (제조) 방식이라서 애자일 방법을 적용하기만 하면 모든 문제가 빠르게 해결될 것 이라고 오해하는 것처럼 보였다. '애자일을 적용하여 다음 번 모델의 출시일을 앞당기겠다.'라는 기사를 보면서 확실히 애자일에 대해 오해하고 있음을 알 수 있었다. 비슷하게 코드 리뷰도 그러한 오해를 받고있다. 코드 리뷰란 능력있는 직원이 능력없는 직원의 작업을..
스핀에커(Spinnaker)는 버전(Version)관리를 위해 BOM(Bill of Materials)을 적용하였다. BOM은 전통적인 제조사에서 주로 사용하는 말이며, 소프트웨어 쪽에서는 그렇게 친숙한 단어는 아니다. 삼성전자와 같은 제조사는 여러 협력업체에 발주한 부품을 조립하여 최종 제품을 생산한다. 예를들어, 휴대전화를 만들경우 화면은 어느 부품을 사용하고 배터리는 어느 부품을 조합에서 생산할 지 명세하는 것이다. 이럴 경우, 전체 그림을 그리는 설계도가 필요한데, 이 것을 BOM이라고 부른다. 스핀에커에 BOM을 적용한 후로는 각 마이크로서비스(Microservices) 단위의 버전을 따로 말하지 않고 큰 틀에서 지정한 단일 버전을 발표하고 있다. 그렇다고해서 기존에 지켜오던 버전이 사라진 것은..
클라우드 네이티브(Cloud Native)의 지향점이 안정성과 효율성, 빠른 변화대응이라고 하지만, 정작 CNCF(Cloud Native Computing Foundation)의 페이지가 이렇게 빨리 변할 것이라고는 생각하지 못했다. 다음과 같이 클라우드 네이티브의 정의 (Cloud Native Definition v1.0)가 공식 문서로 재탄생했다. 가장 크게 바뀐 내용은 컨테이너가 필수조건이 아니라는 것이다.Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Con..