2018년 초 AI(Artificial Intelligence)기반의 새로운 과제를 시작하면서 인프라스트럭처 애즈 코드(Infrastructure as Code)를 적용할 것인지 논의하였다. 소규모 과제의 경우에는 인프라스트럭처 애즈 코드를 적용하고 싶지 않다는 주장이 나왔기 때문이었다. 인프라스트럭처를 모두 코드로 만들어서 관리하는 장점은 알겠지만, 규모가 너무 작아서 작업자가 GUI 도구로 간단하게 만들어 버리는 것이 더 빠른 경우도 있다는 주장이었다. 또한 그 정도 간단한 과제라면 장애복구도 매우 간단하게 수행할 수 있는데, 이를 위해 테라폼(Terraform) 또는 클라우드 포메이션(CloudFormation)을 이용하여 코드를 만들고 검증하는 과정이 오히려 부담스럽다는 의견이었다. 배보다 배꼽이..
테라폼(Terraform, https://www.terraform.io)은 지구와 비슷한 행성을 사람이 살 수 있는 환경으로 만든다는 뜻을 가지고 있다. 터레인(Terrain, 지형)이라는 단어를 이미 알고 있다면 더 쉽게 뜻을 유추할 수 있을 것이다. 이름에서 알 수 있듯이 테라폼은 클라우드(Cloud)환경 위에 사용자가 원하는 형태의 인프라스트럭처(Infrastructure)를 만드는 도구이다. 간단히 말하자면, 하시코프(HashiCorp)에서 만든 인프라스트럭처 애즈 코드(Infrastructure as Code, IaC)를 위한 도구이다. 참고로 AWS(Amazon Web Services)에서는 테라폼이 나오기 전에 자신들의 자원(Resources)들을 관리하기 위하여 비슷한 기능의 도구를 제공했..
몇 년 전, IoT 과제에 참여했을때 이뮤터블 아티팩트(Immutable Artifact, 변경불가능한 결과물) 또는 이뮤터블 인프라스트럭처(Immutable Infrastructure)에 대해 겪은 것을 이야기를 하려고 한다. IoT과제는 지속적 전달(Continuous Delivery)과 이뮤터블 인프라 스트럭처 를 도입하였다. 그러나 안타깝게도 대부분의 사람들은 그 개념이 무엇인지 잘 몰랐다. 기존 회사의 엔지니어들이 하던 방식을 그대로 따르기만 했기 때문이었다. 그래서 이뮤터블 인프라스트럭처에 대한 근본적인 이해가 없었고 그래서 일정 압박을 핑계로 운영환경의 긴급 변경 요청을 많이했다. 테스트(Test)를 충분히 하지 않은채 배포하다가 결함이 발견되면 운영환경에서 바로바로 고치길 원했다. 그러던 ..
파이프라인(Pipeline)이 갖는 가장 큰 의미는 자동화를 통하여 위험요소를 사전에 차단한다는 것이다. 파이프라인을 이용하여 석유나 가스를 옮기는 것을 생각해보자. 우리는 미리 정해진 통로를 이용하여 원하는 위치로 석유를 옮길 수 있다. 또한 이동 중간에 어떠한 불순물이나 위험요소가 들어오지 못하도록 차단할 수 있다. 소프트웨어 서비스(Software Service Application) 를 개발하고 배포하는 과정도 이와 같이 외부의 개입을 최소화하여 정해진 순서대로 흘러가도록 한다면 개발자(생산자)가 만든 결과물이 그대로 소비자에게 전달될 것이다. 중간에 불필요한 간섭이나 개입으로 인한 부작용이 사라지기 때문에 서비스 품질을 유지할 수 있다. 그래서 파이프라인은 지속적 전달(Continuous Del..
마이크로서비스(Microservices)를 기반으로 운영하다보면 간혹 인기가 많은 특정 서비스에 요청이 집중되는 현상이 나타난다. 보통 어카운트(Account) 또는 프로파일(Profile) 서비스에 부하가 많이 몰린다. 하지만 대부분 성능 검증(Load Test, Stress Test, Aging Test)을 통해서 서버(Server) 한 대당 어느 정도를 처리할 수 있을 지 미리 가늠할 수 있고, 그 결과를 기준삼아 스케일 아웃(Scale-out) 정책을 펼쳐서 몰려드는 요청을 처리할 수 있다. 대부분은 이러한 방식으로 처리가 가능하지만, 특수한 예외상황도 존재한다. 이를테면 인증 서비스(Authentication, i.g., sign-in/log-in)에서 문제가 발생했을 경우가 있다. 사용자들이 ..
몇 년 전, - 아마도 2016년 - 마이크로서비스(Micro-services) 또는 마이크로서비스 아키텍처(MSA, Microservices Architecture)에 대해 회사 내부에서 세미나를 했었다. 세미나의 시작은 스핀에커(Spinnaker)를 소개하는 것이었지만, 스핀에커를 잘 소개하기 위해서는 많은 배경지식을 먼저 소개해야 했고 그래서 마이크로서비스, 이뮤터블 인프라스트럭처(Immutable Infrastructure), 지속적 전달(Continuous Delivery) 등의 개념과 특징, 장점, 사례 등을 설명하는 것이 필요했다. 그 중 중요한 한 가지 주제는 마이크로서비스였다. 마이크로서비스를 설명하면서, 청중의 이해를 돕기 위해 키보드를 예시로 들었다. 대부분의 사람들이 컴퓨터에는 익숙..
어제 회의 중, 피닉스 패턴(PhoenixServer)이라는 말을 들었다. 최신 유행이라고 하는 데 들어본 적이 없어서 궁금했다. 그래서 찾아봤는데, Martin Fowler의 말에 따르면, “A server should be like a phoenix, regularly rising out of the ashes." - 서버가 불사조처럼 다시 살아나는 것(살아나도록 만드는 것)을 말한다. 이것은 오래 전부터 내가 서버들을 관리하던 방식을 설명해 주고 있었다. 그 때는 클라우드 포메이션 (CloudFormation)과 셰프 (Chef), 오토스케일링 그룹 (EC2 Autoscaling Group)을 이용하여 새로운 인스턴스가 자동으로 생성되면 코드로 구현된 서버 설정이 자동으로 적용되도록 했었다. 지금은..
AWS(Amazon Web Services)를 사용하다보면 몇가지 제약사항을 만나게 된다. 가장 먼저 만나게 되는 제약사항은 S3 버켓(Bucket) 이름이다. S3 버켓은 domain을 만드는 기준이 되기 때문에 세계에서 유일해야 한다. 이러한 제약사항을 미리 알고 있었으나, 클라우드 포메이션(CloudFormation)으로 S3의 버켓 이름을 자동으로 생성하면서 버켓이름이 충돌했던 경험이 있었다. Music Radio 를 설계하던 시절이었는데, 어플리케이션(Application) 배포를 위한 deploy, 그리고 로그 보관을 위한 log 버켓을 만들도록 클라우드 포메이션을 작성했었고, 처음에는 문제가 없었다. 그러나 곧 개발, 검증, 운영환경을 복사해서 만들다 보니 문제가 생겼다. 같은 이름으로 버켓..
객체 지향 설계법, 또는 객체 지향 프로그래밍(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서버 설정의 일관성을 위해 깨끗한 상태의 새..