KT EPC Cloud 사용기 :: 2021/01/29 20:49
오늘 팀원 중 한명이 KT EPC Cloud에 AWX를 설치하다 실패한 이야기를 했다.
밤을 새워가며 ansible, redis, nginx, memcached, postgresql, rabbitmq, erlang 등을 설치했는데...
결국 실패하여 오늘까지도 설치하지 못했다는 이야기를 듣고 뭔가 이상하다고 생각했다.
사내 보안망에 있는 서버도 아니고, Public Cloud에 있는데 왜 설치가 안 될까?
그래서 개발용 노트북에 VirutalBox를 설치하고, Cent OS 7을 minimal로 설치했다.
그리고 AWX를 설치해 봤는데... 설치가 잘 되더라.
VirtualBox, Cent OS, AWX를 모두 설치하기까지 걸린 시간이 약 2시간 정도.
팀원을 불러서 설치가 잘 된다고 알려줬다.
그런데, 내가 알려준 대로 모든 것을 해봤는데도 안 된다고 했다.
그래서 직접 EPC에 VM을 생성하여 설치를 해 봤는데, yum 설치가 안 된다.
동일한 버전의 Cent OS 서버인데도 VirtualBox에서는 설치가 되고, EPC에서는 설치가 안 된다면...
가장 먼저 들여다 봐야 하는 것은 바로 Cent OS의 Repository.
바로 /etc/yum.repos.d/에 있는 CentOS의 Repository 파일 내용을 살펴보니...
역시, Repository 문제였다.
CentOS-Base.repo 파일을 원복시키고 설치해 보니 AWX 설치가 잘 된다.
2시간 반 만에 모든 문제 해결!!
일상이 지루할 때 :: 2021/01/29 20:40
일을 열심히 하다 보면, 번아웃으로 힘들어질 때가 있다.
2020년 한 해 동안 개인적으로 열심히 살았나 보다.
연말부터 몸이 아프더니 2021년 01월이 정신없이 지나갔다.
그리고, 이빨도 3개를 뽑았고, 앞으로도 그만큼 더 뽑아야 한다.
일에 대한 의욕이 없어질 경우는 어떻게 해야 할까.
이런저런 글을 읽다가 공감이 가는 짤막한 글을 하나 읽었다.
스스로의 마음을 추스리기 위해 강제적으로 내 마음을 추스리고자 하기 보다는,
현재 내가 주도적으로 시간을 투자하여 자발적으로 할 수 있는 조금씩 하는 것으로 관심사를 돌리다 보면,
스스로의 마음을 다잡을 수 있다고 한다.
맞는 말인 것 같다.
스스로의 시야를 좁게 가져가고 있는 것은 아닐까 돌아보게 된다.
스트레스 받아가며 현재 상황에 얽매이기 보다는,
최소한의 일을 하며 그 동안 여러가지 핑계로 진행하지 못했던 일들에 조금은 더 시간을 투자해야겠다.
Pattern-Oriented Software Architecture Summary :: 2021/01/20 14:46
- Pattern Architecture = Architectural Style
- Pattern은 다음 3가지로 분류될 수 있음
- Architectural Pattern / Framework Pattern : Highest Level of abstraction in software pattern. 전체 시스템 차원의 구조와 관계에 대한 정의
- Design Pattern : collection of class or subsystem을 통해 문제를 해결하는 방법에 대한 서술
- Idiom (표현 양식, 언어) : the lowest level of pattern. 특정 프로그래밍 언어로 어떻게 개발되는지에 대한 코드 레벨
- 다만, MVC와 같이 위 3가지 카테고리로 분류하기 어려운 패턴도 등장. 한계가 있음.
- Pattern-Oriented Software Architecture
- Software 개발에 대한 또다른 접근 방법
- POSA에서는 아키텍처를 다음 4가지 그룹으로 분류함
- From Mud to Structure Category
- 시스템의 전체 task를 상호 동작하는 컴포넌트, subsystem, 레이어로 분해
- Layers Pattern
- Task를 서로 다른 Layer로 분리. 각각의 Layer는 특정 수준으로 추상화.
- 크고 복잡한 시스템을 구현하기 쉽게 분리 가능
- 유지보수성과 확장성 측면에서 강점
- 비싼 시스템 리소스는 단점
- Blackboard Pattern
- 여러 개의 특정 subsystem을 결합하여 각각의 솔루션에 대한 지식을 활용.
- 결정적인 솔루션을 가지고 있지 않은 경우에 적합
- 서로 연관이 없는 컴포넌트나 subsystem의 집합
- 복잡한 에러 핸들링에 효율적임
- Pipes & Filters Pattern
- Stream data 처리 시스템에 대한 구조
- 데이터 처리에 여러 단계의 step/pipe 순차적인 처리.
- 각 pipe 프로세스는 filter를 포함하고 있음.
- 데이터는 pipe와 filter를 통과. 데이터 처리는 빠르지만, 데이터 처리에 대한 오버헤드와 static 정보 공유에 비용이 비싸고 flexible하지 않다. (유연하지 않음)
- XML Streaming 데이터 처리와 같은 경우에 적합
- Distributed System Category
- 분산 어플리케이션에 대한 완전한 구조 제공
- Broker가 유일한 패턴임
- Pipes and Filters 패턴이나 Microkernel 패턴도 카테고리에 속하지만, 다른 카테고리에 더 적합함
- Broker Pattern
- 분산 시스템에서 주로 사용하는 패턴
- 원격 서비스를 호출하는 decoupled component에 대한 시스템 구조
- Client / Server 간 더 좋은 decoupling을 제공할 수 있음
- 변경성, 확장성, 위치 투명성 등 많은 장점이 있지만 디버그와 테스트가 어려움
- CORBA : Common Object Request Broker Architecture에 사용
- Interactive Systems Category
- 인간과 컴퓨터간의 상호작용과 같은 software 시스템 구조.
- 인간의 상호작용을 handling하는 데 초점
- Model-View-Controller Pattern과 Presentation-Abstraction-Control Pattern이 이 카테고리에 속함
- MVC Pattern
- 시스템을 Model, View, Controller 3가지 파트로 분리
- Model : 전체 시스템이 어떻게 동작하는지 설명
- View : 모델이 어떻게 보여지는지 설명
- Controller : 시스템과 User 사이 상호작용 제공
- 유지보수성과 확장성을 증대시키지만, 디자인 복잡성도 증가함
- 잘 알려진 예제는 smalltalk 아키텍처
- PAC Pattern
- 협업 에이전트(cooperating agent)의 계층 형태(hierarchy form)로 software system간 상호작용 구조를 정의
- 각 agent는 특정 application function에 대해 책임을 지는 3개의 컴포넌트(presentation, abstraction, control)로 이루어져 있음
- 인간과 컴퓨터가 상호작용할 때, functional core와 다른 agent와의 communication을 분리함
- Adaptable System Category
- 시스템은 시간이 지나감에 따라 발전하여 디자인이나 기능이 변경됨
- Adaptable System(적응형 시스템)은 Application의 확장과 개발된 기술의 조정, 기능 요구사항의 변경으로 이러한 문제를 극복함
- Microkernel Pattern
- Microkernel Pattern은 확장된 기능성과 고객별(customer-specific) 파트(part)로부터 최소 기능 코어를 분리.
- 확장 기능을 연결하고 협업을 조정하는 소켓을 제공.
- 다른 프로세스에서 실행되는 컴포넌트간 서로 통신 가능.
- 카네기 멜론 대학에서 개발된 mach(마하) 운영 체제가 이 패턴을 사용.
- Chorus 상용 시스템도 이 패턴을 사용.
- Reflection Pattern
- Reflection Pattern은 소프트웨어 시스템이 구조와 동작을 동적으로 변경하는 메커니즘 제공
- Type structure (유형 구조), date element (날짜 요소), function call(함수 호출) 메커니즘 수정 지원
- 이 패턴에서 application은 Meta level, Base level 2 분야로 분리됨
- Meta level : 소프트웨어 자체를 인식하고, 선택된 시스템 속성에 대한 정보를 제공
- Base level : Application Logic을 담당. Implementation은 meta level에서 유지.
- 결론
- 시스템 아키텍처는 사용 가능한 아키텍처 패턴과 그 사용법을 이해해야 함
- 시스템 아키텍처를 설계할 때, 인간과 환경적 요소들도 중요
- 프로젝트 수행 시, 예산과 아키텍처의 아름다움 아래 프로젝트에 사용할 수 있는 회사 정책, 리소스는 사용된 아키텍처 패턴이 아니라 아키텍트에 의해서 결정됨.