오픈스택 재단(Openstack Foundation)은 2017년 5월 8일부터 11일까지 4일간 미국 메사추세츠주 보스턴 하인즈 컨벤션 센터(Hynes Convention Center) 일원에서 오픈스택 서밋 보스턴(Openstack Summit Boston)을 개최했다. 연 2회 개최되는 오픈스택 서밋은, 60개국 이상에서 수천 명의 전문가 및 관계자들이 참석해, 클라우드 전략을 계획하고 오픈스택 클라우드 아키텍처 및 운영에 관한 지식을 공유하는 기회를 제공한다.

오픈스택 서밋은 클라우드 컴퓨팅의 미래를 구축할 IT 분야 리더, 통신회사, 클라우드 관리자, 앱 개발자, 오픈스택 기여자들이 한 자리에 모여, 직접 비즈니스 사례 및 운영 경험을 공유하고, 생태계의 신제품에 대해 배우고, 실전 워크숍에 참여할 수 있도록 구성되어 있다. 8일의 키노트를 시작으로, 4일간 다양한 주제로 진행되는 컨퍼런스와 함께 개발자, 운영자들을 위한 포럼, 생태계의 신제품들을 볼 수 있는 마켓플레이스, 참가자들간의 네트워킹을 위한 행사까지 다양한 프로그램이 진행된다.

이번 오픈스택 서밋 보스턴에서의 세션 프로그램 ‘Your Cloud is Amazing, so Why Aren’t You Running Everything on It?’은 블룸버그(Bloomberg)의 오픈스택 인프라 구축과 활용 사례가 소개되었다. 이번 세션에서 블룸버그는 오픈스택 기반 클라우드 환경의 구축 경험에 있어, 개발자와 민첩성에 중점을 두는 미래의 대규모 엔터프라이즈 IT 인프라에서 바꿔야 할 기존의 개념들에 대해 소개하며, 이런 변화를 돕는 세 가지 중요한 여정들을 언급했다.


블룸버그 인프라스트럭처 엔지니어링 부문의 제이콥 로젠버그(Jacob Rosenberg)는 이 자리에서, 이번 세션에서 다룰 점으로, 인프라 구축 이후 커뮤니티 등이 있음에도 구축된 인프라를 제대로 활용하지 못했던 이유 등에 대한 소개를 꼽았다. 또한 대부분의 컨퍼런스에서는 ‘이상적인 상태’만 소개하는 경우가 많고, 막상 직접 구축하는 데 있어 마주하는 현실은 이와는 거리가 멀고, 오래된 기술과 애플리케이션의 마이그레이션 등 해야 할 일이 많다고 지적했다.

기술적 이상향의 측면에서는 현재 상태의 유지와 업데이트를 이어 나가는 것이 필요하지만, 현실적으로는 이를 영원히 이어갈 수는 없고, 사용하던 기술들 또한 몇 년이 지나면 세상의 변화에 따라 바꾸게 되는 경우가 흔하다. 그리고 이는 인프라 팀이나 비즈니스, 애플리케이션 개발자 모두에 있어, 한 쪽에 모든 책임과 의무를 물을 수는 없는 문제라고 지적했다. 또한 오픈소스 소프트웨어의 사용에 있어서도, 당면한 문제의 해결을 위한 오픈소스 소프트웨어의 사용과 커뮤니티로의 다양한 기여에서의 ‘균형’을 맞추고자 하고 있고, 커뮤니티는 고객과는 또 다른 관계를 가진다고 덧붙였다.

하드웨어의 활용에서는 OCP(Open Compute Project) 등 범용의, 표준 개방형 하드웨어를 활용한다고 소개했다. 그리고 어플라이언스와 솔루션을 구매하던 형태에서 OCP 등을 기반으로 하는 하드웨어의 활용으로 변하면서, 네트워크와 스토리지까지 오픈소스 소프트웨어와 함께 이들 하드웨어로 처리하게 되었다고 밝혔다. 애플리케이션 측면의 변화에서도 ‘수평적 확장’이 특징으로 꼽혔는데, 여기서 중요한 점으로는 병렬 처리 배치 등을 통해 ‘단일 지점에서의 취약점’을 만들지 않고, 다양한 규모에서의 처리를 통해 인프라의 용량을 최대한 활용하는 점 등이 꼽혔다.

‘마이크로서비스’ 등으로 표현되는 ‘클라우드 네이티브 디자인’ 또한 실제로 기업 애플리케이션에 적용함에 있어서 클라우드 환경에서의 동작이 가질 수 있는 장점은 기존까지 사용되어 온 기술들과는 다소 다를 수 있다. 이에 실제 클라우드 네이티브의 적용에 있어 몇 가지 기술적 부분에 있어 재구성이 필요할 수 있다고 밝혔다. 이에 인프라의 ‘이상향’에 비해 실제로는 기술들이 완전한 형태로 제대로 결합되지 않으며, 이런 상황이 오래 지속되어 온 기업들은 지속적으로 쌓여 온 대량의 기술적인 부채를 마주하게 되는 상황에 온다고 덧붙였다.


물론 이 기술적 부채가 무조건 나쁜 것은 아니지만, 적당한 시기에 이를 털어버리지 못하고 남겨 왔을 경우에는 문제가 될 수 있다. 1997년에는 완벽했던 기술이라도 그것이 2017년까지 완벽을 유지해 올 수는 없을 것이기 때문이다. 그리고 기존의 기술을 클라우드 네이티브 디자인으로 전환하는 데 있어 기존의 수많은 코드들을 다시 사용할 수 있게 바꾸는 것은 때로는 다양한 이유로 불가능에 가까울 수도 있다.

이런 악순환을 해결하는 방법 중 하나로는, ‘점진적 수용’이 꼽혔다. 실질적으로 이 ‘기술적 부채’를 한 번에 털어버리고, 기존의 복잡한 시스템을 높은 위험부담을 감수하면서 한 번에 바꿔버릴 수 없다면, 몇 년의 기간을 두고 단계적으로 전환해 가는 방법도 생각해 볼 수 있을 것이라는 설명이다. 그리고 이 때 중요한 점으로는 ‘비전에 대한 공유’가 꼽혔는데, 이는 모두가 지향점을 공유함으로써, 멋대로 흘러가 더 나쁜 방향으로 가고, 전체적으로 실패하는 것을 막기 위함이라고 덧붙였다.

또한 새로운 인프라의 구성을 처음 시작할 때는 생각대로 움직이지 않고 기존의 것과 동떨어진 ‘섬’처럼 보일 수도 있는데, 이를 기존에 구축된 ‘다른 세계’와 연결하는 것 또한 중요한 부분이라고 밝혔다. 이 때 기존의 것들은 ‘울타리’로 둘러싸고 인터페이스와 API로 연결하는 게 일반적인데, 이는 기존의 것을 지속적으로 다루면서 모든 것을 새로운 체계로 변환하지 않게 한다. 그리고 이런 인터페이스들은 언젠가는 버려질 것들이지만, 공사장에서 공사 중에 쓰이다 완공 전에 철거되는 발판 같은 존재라고 생각할 수도 있다고 덧붙였다.

특정 프로젝트와 상관 없이 애플리케이션을 부분적으로 수정할 때는 언제나 시간 소비를 최소화하라는 점도 당부했다. 다른 프로젝트와 함께 진행하는 작은 프로젝트의 경우에는 엔지니어링 역량을 모두 부을 필요가 없고, 이런 경우는 때때로 프로젝트에 대한, 지금 하는 일이 전체적인 흐름에 도움이 되고 있는지에 대해 판단할 수 있는 다른 시각을 가질 수 있는 기회를 주기도 한다. 이에 전체 세그먼트에 대한 완료는 서서히 진행하면서, 올바른 방향으로 가고 있는지에 대해 지속적으로 확인할 필요도 있다고 밝혔다.


엔지니어링에 더 집중하고, 운영에 드는 노력을 줄이는 점도 중요한 부분으로 꼽혔다. 지금까지 하던 클라우드 세대 이전의 관리 작업들과 방식들은 대규모 노드 기반의 클라우드 환경에서는 사용이 불가능해진다. 이에 자동화를 적용하는 데 있어, 클라우드로의 전환에서는 모든 것의 자동화를 추구해야 한다고 강조했다. 또한 배치 컨셉에 있어 지속적인 흐름을 가져가고, 릴리즈와 롤백 등에 대한 방법을 생각하고, 이러한 기술의 활용을 생각할 시기이기도 하며, 이는 인프라 도입 이전에도 테스트와 병렬 시스템 배치 등에서 엔지니어링 팀에 도움되는 부분이라고 소개했다.

패키징의 현대화 측면에서는, 컨테이너 등 몇 가지 옵션을 고려해볼 수 있다. 그리고 이 중 작업과 자동화, 배포의 용이성과 속도 등을 고려해 선택이 이루어지게 되며, 이 선택에 따라 모든 것을 자동화된 방식으로 리빌드해, 활용에 장점을 취할 수 있을 것이라 밝혔다. 이와 함께, ‘목적에 맞는’ 인프라의 구성 또한 중요하다고 강조하며, 모든 것을 클라우드로 옮길 필요도 없다고 소개했다. 예를 들면 유연성이 없는 라이선스 소프트웨어나 종속성이 있는 네트워크 스키마 등 같은 경우는 굳이 당장 옮기려 노력하지 말고, 남겨뒀다가 다음에 올 더 좋은 기회를 노리는 것이 맞다는 것이다.

이와 함께, 인프라의 구성 단계에서부터 회사 내에 관계된 모든 조직이 관여해 구성하라는 점을 제안했다. 특히 최신 기술에 대해 관련된 모든 조직과 사람들이 새로운 기술을 사용하는 방법에 대해 배울 필요가 있다고 강조했으며, 교육이 다양한 관점과 요구사항을 가진 서로 다른 조직들을 같은 줄기의 비즈니스 동력으로 묶어내고, 성공적인 도입을 가능하게 한다고 강조했다. 이와 함께, 인프라와 관련된 다양한 로그와 운영 데이터, 수치, 설정이나 어떤 일이 일어나고 있는지 등을 적극적으로 공유하는 것도 투명성 향상의 측면에서 추천했다.


Copyright ⓒ Acrofan All Right Reserved.