StarLord

여러개의 인덱스에 걸쳐 alias를 설정하는 방법 test1, test2 두개의 인덱스에 alias 적용 $ curl -X POST "localhost:9200/_aliases?pretty" -H 'Content-Type: application/json' -d' { "actions" : [ { "add" : {"indices" : ["test1", "test2" ], "alias" : "alias2" } } ] } test로 시작하는 모든 인덱스에 alias 적용 $ curl -X POST "localhost:9200/_aliases?pretty" -H 'Content-Type: application/json' -d' { "actions" : [ { "add" : { "index" : "test*", "..

모든 개체에는 수명 주기가 있습니다. 객체는 생성되고 다양한 상태를 거치며 결국 아카이브되거나 삭제되어 죽습니다. 물론 이들 중 다수는 생성자를 쉽게 호출하여 생성되고 일부 계산에 사용된 다음 가비지 수집기에 버려지는 단순하고 일시적인 개체입니다. 그러한 개체를 복잡하게 만들 필요가 없습니다. 그러나 다른 개체는 수명이 더 길며 모든 개체가 활성 메모리에서 소비되는 것은 아닙니다. 그들은 다른 객체와 복잡한 상호 의존성을 가지고 있습니다. 그것들은 불변이 적용되는 상태 변경을 거칩니다. 이러한 개체를 관리하는 것은 MODEL-DRIVEN DESIGN 시도를 쉽게 탈선시킬 수 있는 Challenge를 야기합니다. Challenge는 두 가지 범주로 나뉩니다. 1. 라이프 사이클 전반에 걸쳐 무결성 유지 2..

아래는 ES 클러스터를 구축하면서 커스터마이징을 권장하는 내용을 정리하였다. elasticsearch.yml에서 세그먼트 저장 경로 설정 path.data: /var/lib/elasticsearch/data1 스왑 메모리 사용 여부 설정 bootstrap.memory_lock: true - 시스템의 스왑 메모리 영역을 사용하지 않도록 하는 설정이다. ES는 스왑 메모리 영역을 최대한 사용하지 않도록 권고하고 있다. 이 설정을 통해 스왑 영역을 사용하지 않으면 성능은 보장할수 있지만 시스템의 메모리가 부족한 경우에는 OOM 발생. 이 설정을 사용하기 위해서는 elasticsearch.yml 뿐만아니라 OS의 /etc/security/limit.conf도 수정해야 한다. # vi /etc/security/l..

결합 가능한 한 관계를 제한하는 것이 중요합니다. 양방향 결합은 두 객체가 함께있어야만 이해될 수 있음을 의미합니다. 응용 프로그램 요구 사항이 양방향 순회를 요구하지 않는 경우 순회 방향을 추가하면 상호 의존성이 줄어들고 설계가 단순화됩니다. 도메인을 이해하면 자연스럽게 방향성을 알수 있습니다. 미국에는 다른 많은 국가와 마찬가지로 많은 대통령이 있습니다. 이것은 양방향, 일대다 관계입니다. 그러나 우리는 "조지 워싱턴"이라는 이름으로 시작하여 "그는 어느 나라의 대통령이었습니까?"라고 묻는 경우는 거의 없습니다. 실용적으로 우리는 "국가"에서 "대통령"으로 이동하는 단방향 연결 관계를 줄일 수 있습니다. 이 개선은 실제로 도메인에 대한 통찰력을 반영할 뿐만 아니라 보다 실용적인 디자인을 만듭니다. 그..

클러스터와 노드 여러개의 ES 프로세스들을 논리적으로 결합하여 하나의 ES 프로세스 처럼 사용할수 있게 해준다. 이때 클러스터를 구성하는 하나하나의 ES프로세스를 노드라고 부른다. 노드역할 노드역할 설명 마스터(Master Eligible) 클러스터 구성에서 중심이 되는 노드. 클러스터의 상태등 메타데이터를 관리한다. 데이터(Data) 사용자의 문서를 실제로 저장하는 노드 인제스트(Ingest) 사용자의 문서가 저장되기 전 문서의 변환이 필요한 내용을 사전 처리하는 노드 코디네이트(Coordinate) 사용자의 요청을 데이터 노드로 전달하고, 다시 데이터 노드로부터 결과를 취합하는 노드 위 표와 같이 노드가 할 수 있는 역할은 총 4가지 이며, 각각 하나의 역할만 할 수 있는게 아니라 한번에 여러개의 역..

관련링크 : https://www.cncf.io/blog/2022/07/18/testing-your-infrastructure-as-code-using-terratest/ Testing your Infrastructure as Code using Terratest | Cloud Native Computing Foundation Guest post originally published on InfraCloud's blog by Akash Warkhade Setting Up infrastructure manually can be a time-consuming and hectic process. That is when we can make use of Infrastructure as… www.cncf.io T..

객체 지향 프로그램에서 UI, 데이터베이스 및 기타 지원 코드는 종종 비즈니스 객체에 직접 작성됩니다. 추가 비즈니스 로직은 UI 위젯 및 데이터베이스 스크립트의 동작에 포함됩니다. 이것은 단기간에 작업을 수행하는 가장 쉬운 방법이기 때문에 발생하는 이슈 입니다. 도메인 관련 코드가 이렇게 많은 양의 다른 코드를 통해 확산되면 보고 추론하기가 매우 어려워집니다. UI에 대한 피상적인 변경은 실제로 비즈니스 로직을 변경할 수 있습니다. 비즈니스 규칙을 변경하려면 UI 코드, 데이터베이스 코드 또는 기타 프로그램 요소에 대한 세심한 추적이 필요할 수 있습니다. 일관된 모델 기반 개체를 구현하는 것은 비실용적입니다. 자동화된 테스트는 어색합니다. 각 활동에 관련된 모든 기술과 논리로 인해 프로그램은 매우 단순..

만약 소프트웨어 디자인이 도메인 모델과 매핑되지 않는다면, 그 모델은 가치가 없거나 소프트웨어의 정확성이 의심된다. 동시에 모델과 디자인 기능간의 매핑의 복잡성은 이해하기 어렵고 디자인 변경에 대한 유지관리가 어렵다. 분석과 디자인 사이에 치명적인 격차가 발생하여 각각의 활동으로 부터 얻은 인사이트가 서로 영향을 미치지 못하는 상태가 발생한다. MODEL-DRIVEN DESIGN은 해석 모델과 디자인의 이분법을 버리고 두 가지 목적을 모두 충족하는 단일 모델을 찾습니다. 순전히 기술적인 문제를 제외하고 디자인의 각 개체는 모델에 설명된 개념적 역할을 합니다. 이것은 두 개의 완전히 다른 목표를 충족해야 하기 때문에 우리에게 더 부담지우긴 합니다. 매핑이 명확하게 도메인 모델을 문자 그대로 소프트웨어 시스..

모델을 기반하는 커뮤니케이션은 UML과 같은 Diagram이 국한되어 하는 것이 아니다. 가장 효과적으로 모델을 사용하기 위해서 전달 방식을 스며들게 할 필요가 있다. 이것은 Text 문서의 활용성을 높일 뿐만아니라 에자일 프로세스에서 비형식적이고 캐쥬얼한 의사소통을 가능케한다. 이를 Ubiquitous Language라고 한다. 모델에 대한 설명의 비용, 오해의 리스크는 매우 높으므로 프로젝트에는 튼튼한 공통된 언어가 필요하다. 팀이 도메인 모델에 공을 많이 들이면 도메인 모델은 커뮤니케이션의 주측이 될 수 있다. 이것이 유비쿼터스 언어라고 할 수 있다. 초기 모델은 유비쿼터스 커뮤니케이션을 수용하기에는 부족한 수준으로 간결할 것이다. 해당 분야의 특정 용어에 대해서도 풍부하게 의미전달을 못할것이다. ..

개요 A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. 도메인 모델이란 실질적인 다이어그램이 아니라 전달해야할 추상적인 다이어그램이다. 단지 도메인 전문가의 머릿속 지식에 그칠뿐만 아니라 엄격하게 "조직화"되고 "선별된" 지식이다. Knowledge Crunching 효과적인 domain 모델러는 지식을 잘 쪼개는 사람이다. Knowledge Crun..