不爲也比不能也

S1000D For Beginners

drscg — Mon, 9 May 2022 15:44:33 +0900

원문: https://medium.com/s1000d/s1000d-for-beginners-9a90fea311e7

About

This is a guide for technical writers and illustrators. The world of technical writing is changing from the linear writing concept of a beginning, middle and end. It is moving toward a concept of having the precise information you need exactly when you need it in the form that suits you best given the situation you are in right now.

이 글은 기술적인 writer와 illustrator를 위한 가이드이다. 기술적인 글쓰기의 세계는 시작, 중간, 마지막의 선형적인 글쓰기의 개념에서 변화하고 있다. 필요한 정확한 정보를, 당신이 처한 상황에 가장 적확한 형태로 정확히 가지고 있다는 개념으로 나아가고 있다.

The group leading the charge in this mission is the international standards organization S1000D.

이러한 미션을 주도하는 단체가 국제 표준 기구 S1000D이다.

S1000D is an international specification for the procurement and production of technical documentation. It is a specification for preparing, managing versions of text and illustrations. The S1000D.org established the standards for the exchange of information. This is a basic overview of technical wiring for S1000D compliance.
S1000D는 기술 문서의 조달 및 생산을 위한 국제 사양이다. 텍스트 및 삽화의 버전을 준비하고 관리하기 위한 사양이다. S1000D.org 는 정보 교환을 위한 표준을 수립했다. 다음은 S1000D 규정 준수를 위한 기술적인 방식의 기본 개요이다.

The purpose of this book is to provide a guide for technical writers and illustrators who want to deliver documentation in compliance with S1000D technical publication standards.

이 책의 목적은 S1000D 기술 출판 표준에 따라 문서를 전달하고자 하는 기술적인 작가와 일러스트레이터를 위한 가이드를 제공하는 것이다.

Chapter 1 Good Old Days of Word

Most technical writers use MicroSoft Word or a similar application to create technical documentation. However, technical documentation is moving into cloud databases where there is more than meets your eye.

대부분의 기술 작가는 기술 문서를 작성하기 위해 MicroSoft Word나 유사한 application을 사용한다. 그러나, 기술 문서는 겉으로 보이는 것 이상이 있는 cloud database로 이동하고 있다.

Most standard applications we have been using for years are not up to the requirements of the digital age. Microsoft Word and other applications simply cannot get the job done.

유라거 수년간 사용해 온 표준 응용 프로그램은 디지털 시대의 요구사항에 적합하지 않다. Microsoft Word 및 기타 프로그램으로는 작업을 쉽게 완료할 수 없다.

What is required now is digestible meta data. Searchable connected information and the international standards organization S1000D has defined those data standards.

지금 요구되는 것은 이해하기 쉬운 meta data이다. 검색 가능한 연결 정보와 국제 표준 기구 S1000D가 이러한 data 표준을 정의했다.

It is “open source” which means anyone can use those standards. It does not require a specific software application, so, in theory simply producing text in notepad will do, as long as you adhere to the rules of S1000D. And the primary rule is that the data must be in .xml format.

그것은 누구나 해당 표준을 사용할 수 있는 “open source” 이다. 특정 SW application을 필요로 하지 않으므로, S1000D의 규칙을 준수하는 한, 이론적으로 메모장(notepad)에서 간단하게 text를 생성하면 된다. 그리고, 기본 규칙은 data가 .xml 형식이어야 한다는 점이다.

XML

XML is a programming code that has been around since the 1960’s. XML stands for eXtensible Markup Language. The programming code was designed to store and transport data. XML was designed from the beginning to be both human and machine-readable.

XML은 1960년대부터 사용된 프로그래밍 코드이다. XML은 eXtensible Markup Language의 약자이다. 프로그래밍 코드는 daya를 저장하고 전송하도록 설계되었다. XML은 처음부처 사람과 기계가 모두 읽을 수 있도록 설계되었다.

Look at it this way, XML is a set of rules for encoding documents electronically through the use of markup. Its primary purpose is to facilitate the sharing data across different information systems. It is a product of the World Wide Web Consortium (W3C).

이런 식으로 보면, XML은 markup을 통해 문서를 전자적으로 인코딩하는 규칙의 집합이다. 그것의 주요 목적은 서로 다른 정보 시스템간에 data 공유를 쉽게 하기 위함이다. W3C(the World Wide Web Consortium)의 산출물이다.

XML provides a foundation that anyone can use to build a document. It is not proprietary nor “owned” by anyone. It does have a consortium of international members who keep it an open, usable system for everyone. XML is used globally. It was one of the first tools used for building websites, which became HTML (Hypertext Markup Language).

XML은 누구나 문서를 작성하는데 사용할 수 있는 기반을 제공한다. 소유권이 없고 누구의 소유도 아니다. 모든 이에게 개방적이고 사용가능한 시스템을 유지하는 국제 회원 컨소시엄이 있다. XML은 전세계적으로 사용된다. 웹사이트를 구축하는데 사용된 최초의 도구 중 하나였는데, 그것이 HTML(Hypertext Markup Language)이다.

S1000D defines the standardization of XML specifically for technical documentation. And one of the characteristics of the S1000D is that it also uses an “open systems” approach to the production of technical publications. The specification does not require a specific tool or application.

S1000D는 특히 기술 문서를 위한 XML의 표준을 정의한다. 그리고, S1000D의 특징 중 하나는 기술 출판물 제작에 개방형 시스템(open systems) 방식의 접근을 사용한다는 점이다. 특정 도두나 어플리케이션을 요구하지 않는다.

XML is used by a variety of industries. Some interesting ones are Golfing: GolfML, Aerospace:Spacecraft Markup Language, Music: Music Markup Language, Advertising: AdXML, Artificial Intelligence: AIML and fiction eBooks: FictionBook.

XML은 다양한 산업에서 사용된다. 흥미로운 것들로는 Golfing: GolfML, Aerospace:Spacecraft Markup Language, Music: Music Markup Language, Advertising: AdXML, Artificial Intelligence: AIML and fiction eBooks: FictionBook 이 있다.

What made XML so popular is that it can be exported to iPads, iPhones, internet web browsers, laptops, for any industry and it is adaptable.

XML을 매우 인기있게 만든 것은 어떤 산업에 대해서도 iPads, iPhones, internet web browsers, laptops 으로 export될 수 있고, 적응이 가능하기 때문이다.

Using music as an example, Music.XML is supported by scorewriting programs including Finale, Sibelius and MuseScore. The Music.XML has optical character recognition (OCR) to recognize sheet music. Most music sequencer programs use the XML codes to get the sequence of music right. This is how digitally music is controlled. It is also used to “code” the music. They assign words like “acoustic” and “classical” and “jazz”. And when those are placed in a search engine, the results are Wes Montgomery, Django Reinhardt and Pat Metheny.

음악을 예로 들면, Music.XML은 Finale, Sibelius, MuseScore을 포함한 악보 작성 프로그램에서 지원된다. Music.XML은 악보를 인식하는 OCR(optical character recognition)을 가지고 있다. 대부분의 음악 시퀀서(MIDI, 작곡) 프로그램은 올바른 음악 시퀀스를 얻기 위하여 XML code를 사용한다. 이것이 디지털 음악이 제어되는 방식이다. 또 음악을 "code"하는데 사용된다. 그들은 “acoustic”, “classical”, “jazz” 같은 단어를 할당한다. 검색 엔진에 넣으면, Wes Montgomery, Django Reinhardt, Pat Metheny가 나온다.

Think about that for a second. S1000D uses XML as an “open source” system and tool independent. And provides the structure necessary for implementation of documents and processes across distributed systems. It is powerful without being owned by a company. It is managed by a consortium of people with similar goals in mind — the miscibility of information for the end users.

잠시 생각해 보자. S1000D는 “open source” 시스템과 tool 독립적인 XML을 사용한다. 그리고, 분산 시스템 전반에 걸쳐 document와 process 구현에 필요한 구조를 제공한다. 특정 회사에 소유될 필요없이 강력하다. 그것은 최종 사용자를 위한 정보의 혼용성이라는 유사한 목표를 염두에 두고 있는 사람들의 컨소시엄에 의해 관리된다.

S1000D is the resource for technical authors and illustrations. It is an XML specification for the procurement and production of technical manuals. The specification is freely available for any industry to utilize and available from public.s1000D.org.

S1000D는 기술 작가 및 삽화가를 위한 리소스이다. 기술 매뉴얼의 조달 및 생산을 위한 XML 규격이다. 이 규격은 모든 업계가 자유로이 사용될 수 있고 public.s1000D.org에서 이용할 수 있다.

The S1000D steering committee consists of many participating organizations. The Aerospace and Defense Industries Association of Europe. The International Standards organization for integrated logistics support, the Airlines for America and others.

S1000D 운영 위원회는 많은 참여 기관으로 구성되어 있다. 유럽 항공 우주 방위 산업 협회, 통합 물류 지원을 위한 국제 표준 기구, 미국 항공 및 기타 기관이 있다.

And all of the documents are required to be delivered in XML format for S1000D. First, before talking about XML, you need to understand how some of the basic terms and definitions from the old days of printed copies and PDF have changed.

그리고, 모든 문서는 S1000D용 XML 형식으로 전달되어야 한다. 먼저, XML에 대하여 이야기하기 전에 인쇄된 복사본과 PDF의 오래된 기본 용어 및 정의가 어떻게 바뀌었는지 이해해야 한다.

eDocuments

Using Word we called it “a document”. Those who pay attention will notice that I used the past tense for using the Word application. For those who obey the rules of Simplified Technical English, we use the present tense. In the world of electronic publishing (epub) we do not create “documents”. We create Data Modules (DMs).

Word를 사용한 것을 우리는 "document"라 불렀다. 잘 살펴보면, Word application을 사용한 것에 대해 과거 시제를 사용했다는 것을 알 수 있을 것이다. 간체화된 기술 영어(Simplified Technical English)를 따르는 이들을 위해 현재 시제를 사용한다. 전자 출판(epub)의 세계에서, "document"를 만들지 않는다. Data Module(DM)을 만든다.

They are called “Data Modules” because it is all about the data. Text, illustrations, dates, part numbers, warnings, cautions, notes. They are all considered data.

그것들은 data에 대한 모든 것이기 때문에 “Data Modules”이라 한다. 텍스트, 그림, 날짜, 부품 번호, 경고, 주의 메모. 이 모두는 data로 간주된다.

In the old days this was the document name. In S1000D it is the Technical Manual Identification Number (TMIN). The identification number has a specific format. We will discuss the naming conventions for the TMIN in detail later, but here are some examples.

과거에는 이것이 document name이었다. S1000D에서 그것은 기술 매뉴얼 식별 번호(TMIN)이다. 시별 번호는 특정 형식이 있다. TMIN의 명명 규칙에 대해서는 자세히 설명하겠지만, 몇 가지 예를 들어 보겠다.

TMIN Examples ( http://s1000d.expert/ )

Technical writers try to write a document so that the Readers will understand what to do and how things work. And Technical Illustrators try to create graphics so that Readers can see the components and determine the part numbers they need.

기술 저자는 독자가 해야할 일과 작업을 하는 방법을 이해할 수 있도록 문서를 작성하려 한다. 그리고, 기술 삽화가는 독자가 구성 요소를 보고 필요한 부품번호를 결정할 수 있도록 그림을 작성한다.

S1000D was created to make both the text and graphical data digestible and transferable and understandable by both the Reader and the equipment and software program applications.

S1000D는 독자와 장비 SW 프로그램 어플리케이션 모두에서 텍스트와 그림을 모두 소화/전송/이해 가능하도록 만들었다.

The standard for publication is more than just “text” and a “markup language”. The S1000D is all about the data. The whole set of data: maintenance, customer service, shipping and receiving, illustrations, parts, operating manuals and the engineering drawings. All of it linked together in the digital format. At their best, technical writers compile of the data into information that is useful. What good is having the data if it is not readily available at your fingertips. Imagine useful information that does not need to be reentered for other systems. This is far more valuable than being handed “a PDF file” or a thumb drive with all of your data.

출판의 기준은 “text” 와 “markup language” 그 이상이다. S1000D는 data에 대한 모든 것이다. 전체 data set: 유지보수, 고객 서비스, 배송 및 수령, 일러스트레이션, 부품, 작동 매뉴얼 및 엔지니어링 도면. 이 모든 것이 디지털 형식으로 함께 연결되었다. 기술 작성자는 data를 유용한 정보로 편집한다. data를 쉽게 사용할 수 없다면, data가 있어도 문슨 소용인가? 다른 시스템에 다시 입력할 필요가 없는 유용한 정보를 상상해 보자. 이것은 "PDF 파일"이나 모든 데이터가 포함된 USB를 받는 것보다 훨씬 더 낫다.

This book is written to provide a general working knowledge of S1000 for technical writers and illustrators. Here we present S1000D requirements as if creating the manuals using the old tool MicroSoft Word application. After all, if it is essentially the same information, how different can it be?

이 책은 기술작가와 삽화가에게 S1000D에 대한 일반적은 작업 지식을 제공하기 위해 작성되었다. 여기에서는 이전의 MicroSoft Word application을 사용하여 매뉴얼을 만드는 것처럼, S1000D 요구사항을 제시한다. 결국, 본질적으로 동일한 정보라면 얼마나 다를까?

As different as night and day.

완전히 다르다.

Headers

They’re called “Page Headers” in Word. The same things in the PDF (Portable Document Format by Adobe) version are called “Running Heads”. However, some of the Software applications for e-books use the term “Viewer Bars”.

Word에서는 “Page Headers” 라 한다. PDF에서는 “Running Heads” 라 한다. 그러나 e-book 용 SW 프로그램 중 일부는 “Viewer Bars” 라는 용어를 사용한다.

Notice the Page Headers include the “security classification”.

Page Header는 “security classification(보안 분류)”가 포함되어 있다.

TMIN is basically the file name of the document. We will discuss this as a stand alone topic to understand the requirements according to S1000D.

TMIN은 기본적으로 document의 file name이다. 이것은 S1000D의 요구사항을 이해하기 위한 독입적인 주제로 다룰 것이다.

Footers

S1000D requires that Page Footers can contain UP TO three (3) pieces of data. Up to 3 pieces of data and not more.

S1000D는 Page Footers에 최대 3개의 data를 포함할 수 있다. 최대 3개 더 이상은 없다.

Change Management

Publications have always involved the process of updating and releasing publications with changes, revisions, deleted text, reinstated stuff. The frequency of updating and releasing publications was decided by project.

출판물은 항상 변경사항(changes), 개정사항(revisions), 삭제된 text, 복원된 내용으로 출판물을 업데이트하고 발간하는 과정을 가지고 있다. 출판물을 업데이트하고 발표하는 빈도는 프로젝트별로 결정된다.

Changes were designated using “Change Bars”, the big 4.5 point black bar that was posted next to the stuff that changed.

변경사항(changes)은 변경된 내용 옆에 게시된 큰 4.5 point 검은색 막대인 “Change Bars” 를 사용하도록 지정되었다.

Reasons for changes are summarized and recorded in the identification and status section. We used to debate if the change bar threshold was more than 50% of the page, which made it hard to read, then we marked the footer as the whole page was “revised” and removed the change bars.

변경 사유는 identification(식별), status(상태) section에 요약되어 기록된다. change bar의 임계값이 50% 이상이 되어 읽기 어려운지 여부에 대해 토론한 다음에, 전체 페이지가 “revised”(개정) 되었다고 footer(바닥글)을 표시하고, 변경 표시줄을 제거했다.

By the time we got to revision Z, Roger lost all his hair. It had become to unmanageable.

For S1000D all of the changes, except for editorial changes, must be marked and provided a reason for update. The reason for update text is used to automatically generate the Revision Summary for the technical manual (TM).

S1000D의 경우, 편집 변경 사항을 제외한 모든 변경 사항을 표시하고 업데이트 이유를 제공해야 한다. 업데이트 이유 텍스트는 기술 매뉴얼(TM)에 대한 Revision Summary(개정 요약)를 자동으로 생성하는데 사용된다.

And if you think about it, it makes perfectly good sense that Changes can only be marked for issues that are numbered 002 and above. There are lots of rules in the game of S1000D. This one is just the beginning.

그리고 생각해 보면, 변경 사항(Changes)은 번호가 002 이상인 issue에 대해서먼 표사할 수 있다는 것이 대단히 합리적이다. S1000D에는 많은 규칙이 있다. 이것은 시작에 불과하다.

Changes to documentation requires using “elements”. The change element looks like this: <reasonForUpdate>. The attributes, or choices for that element, are ‘changeMark’, ‘changeType’, and ‘reaonForUpdateRefIDs’. More on this later.

문서를 변경하려면 “elements” 를 사용해야 한다. change element는 <reasonForUpdate> 이다. 해당 element에 대한 attribute 나 choice 는 ‘changeMark’, ‘changeType’, ‘reaonForUpdateRefIDs’ 이다. 자세한 사항은 나중에 ...

Issue Numbering

Sometimes referred to as “revision level” for the document, the “initial revision” was designated as “IR” and then it became “Rev A”, and so forth.

S1000D revision tracking is called “Issue Number” and it starts with the draft version which is numbered 000 and when it is approved and ready to release it becomes the original issue 001. The next version becomes issue 002 and the like.

Drafts

Drafts were sent out as “PDF” files and reviewed by the subject matter experts. They ignored these drafts whenever possible. I don’t think anyone likes to read anymore.

With S1000D drafts are designated using the attribute ‘inwork’

The attribute ‘inwork’ for the element <issueInfo> is used to track and control the intermediate drafts until the final released issue. The initial “inwork’ number Shall be set to “01” and Shall be incremented with every change to the data module.

Applicability

Applicability specifies parameters and associated data for a particular installation.

For every data module (DM) there are the questions of Applicability. These are the settings to allow the end-user to tailor their view of the publications, by selecting a specific configuration. These are usually physical characteristics such as color or system, component, or piece part. But it can include other aspects of modifications such as the manual change requests (MCR), field changes, repairs, or even environmental conditions.

Bike Example

The international standards group created a bike example for S1000D.

PMC-S1000DBIKE-C3002-LOAP1-00_000-02_EN-US.pdf

15.20MB

Mountain Bike Manual (https://www.docuneering.com/s1000d/demo/pdf/PMC-S1000DBIKE-C3002-LOAP1-00_000-02_EN-US.pdf)

Way Beyond Word

What makes S1000D far superior to just the written word is the data structure for a Common Source Data Base (CSDB). The closest way I can to describe the difference is that a word document is formed based on a formatting hierarchy. The arrangement of the document is based on the rules of topics broken down into smaller topics. The topics used to be called “First Order Headings”, and topic underneath that was called a “Second Order Heading”. Each of these nested topics would have a formatting assigned to them. The First Order Headings were big and bold. The Second Order Headings were smaller and maybe indented a little. You get the idea.

Common Source Data Base (CSDB)

Common Source Data Base is a structure for data more like a map or a tree. In this structure, “Food” is called the “parent”. “Meat” and “Fruit” are called the “child”. And in a data base, a numerical id would be assigned to each “node”. Databases are used when there is a lot of data so that when it is populated with all the data someone can query the database to display only the information they need to see.

CODB Structure

This is the CODB Structure for “Food”. To display the whole “food” tree, they would run the function with an empty string as $parent and $level = 0: display_children (‘ ‘,0); and it would return a list of all of the food. But that level of detail is more than you really wanted to know. So let’s move past the Good Ol’ Days of Word to see how the “data modules” replace “word documents. ”

When the information is obtained from the database it is written in a code. For example this is what it looks like to ask for all of the Customers by Name and Age.

Chapter 2 The Data Modules

The S1000D Standard Specification

The S1000D specification is free to download and use. The information presented in this book is a basic introduction to the concepts of S1000D. There is much to learn. We start with the “data module”, or some times they call it a “data unit”. In the old days, we used to call it a “manual”.

The data modules are one component. Other components of the S1000D specifications are introduced as we need them for a technical writing project. First, we focus on the data modules.

The concept of a data module is not new. Teachers used to tell us “start with an outline”. When all is said and done, a data module, it just an outline. The Data Module is a basic outline of topics and the order in which they should be presented in a technical document.

There is a Data Module for basically every type of technical information that is required. This chapter provides an overview of 4 data modules. This is where you are supposed to ask: how where they rated? rated by whom? who funded the research for the rating? Calm thyself. It was me. I rated them based on my opinion of which data modules a technical writer or illustrator use the most.

The Data Modules

S1000D defines data modules as “the smallest self-contained information unit within a technical publication”. So right out of the starting gate, we might assume a data module (DM) as the same thing as a Word document. It would be a starting point to understand the difference. Actually, it would be more accurate to say that the data module is like a Word Template. So you could assume that it would be as simple as using Word to “Save As” an “XML” document. You could say that, but you would be wrong.

It’s what’s under the hood that counts. And we’ll get back to that in a minute.

First of all, it’s comforting to know the hard work to sort this all out was has already been done. The AeroSpace and Defense Industries Association of Europe (ASD) is the organization who produces standards and specifications. They worked with Boeing, Lockheed Martin, General Dynamics and others. Remember the Simplified English and writing rules. That was them. Remember the iSpec220 that is “owned” by the ATA. That was them too. And now they have created the S1000D for technical publications. The goal, of course, is to standardize information. It all starts with various types of Data Modules (DM).

The data module types are described at www.s1000d.netTable . They are free. The following table provides a list of my top five DMs. Remember that S100D was developed specifically for Technical Publications, so these should sound very familiar.

Technical manuals are created from combining data modules. The DM is a stand alone information unit just like a chapter out of a book. Traditional S1000D data modules are: Procedure, Description, Parts, Scheduled Maintenance, Fault Isolation or Operational.

There is also a set of supporting data and other specific documentation to accompany the data modules, but we will save that topic for later. The following table present the types of data modules and a description of each of them.

Data Modules and Descriptions

Data Module Contents and Meta Data

Each data module has a “Contents” area which is what the end user sees and “Meta Data” that the user does not see. The contents are described by the module name: Descriptive, Procedural, Process, etc. But an important part of the Data Module is the Meta Data that is “under the hood”, so to speak because it is not seen by the end user.

Under the hood, the Meta Data provide the “hooks” to find information, and sort data. When you use an internet browser to search for “jazz, music, guitar” the words are meta data tags which search the stored data to retrieve Fats Waller, Diann Krall, We Mongomery, Joe Pass.

S1000D has defined the meta data. This is what enables the transport of the documentation between various s. No matter whose data base stores the data, the meta data is the same. No matter who wrote the application to reach the document, the information is readable

Data Module Code (DMC)

The Data Module Code (DMC) is a unique code of short-hand information about the data module contents. This is the standard naming convention for a data module. DMC is an accurate description of the contents for the module without having to open the files.

The DMC is the unique “description” for the document in short hand form. Later on we will discuss the details, but for right now here is a preview of upcoming events. The DMC must be included in the header information for S1000D. The DMC contains the following information:

MODEL

The Model is the model or overall to which the technical data is applicable. My motorcycle is an F650 model made by BMW. The model is assigned by the company or programming manager when the data module is created for a specific project.

SYSTEM CODE

The system is a generic method of organizing the information. The S1000D System and Subsystem codes are extensive. The following table presents several different codes which might be useful

Systems and Subsystem Codes and Definitions

SYSTEM DIFFERENCE CODE

The System Difference Code indicates there are alternative versions of the system and subsystem without affecting the type, model or variant identity. The System Variance Codes are used to identify information that is specific to one unique configuration.

This fits the need when there are twin models produced. For example, there is a system number for the standard F650 right off the assembly line, and there a code to identify the customized F650s which are created. Each customized bike is assigned a “systemDiffCode”.

STANDARD NUMBERING SYSTEM (SNS)

The standard numbering system is not new. The code was created a way to break the whole assembly into smaller components. The same group that developed the Standard Numbering System (SNS) also created the S1000D system. Typical standard breakdown of components would be the motor, the drive train, the electrical components.

For the aircraft industry, the ATA Standard Numbering System is provided in the ATA iSpec 2000 reference document. This document provides the Information Standards for Aviation Maintenance. So if you work on airplanes and you want to know about the air conditioning system, the answer is always the same: “Section 21”. Th the main distribution system for the air conditioning is always in Section 21. Within the Section of Air Conditioning there are chapters. Chapter 23 is recirculation. The “Chapter” is broken down into additional pair of numbers. The Air Return Grill is, for example, 03 while the sidewall risers are 04. So to find the information on air conditioning air return grill, look in 21–23–03. If you are looking for side wall riser information go to 21–23–04. So, you will notice that the SNS is a hierarchy of three pairs of numbers. The following table presents a examples for SNS codes for the aircraft business.

Standard Numbering System (SNS)

DISASSEMBLY CODE

The Disassembly Code is typically used to identify the order in which parts are removed. This identifies the breakdown condition of an assembly to which maintenance information applies. The pair of numbers starts with “01”.

DISASSEMBLY CODE VARIANT

Used when two or more data modules share the same number a disassembly code variant can be created to identify the level of disassembly for the variation. For those who are familiar with illustration parts catalogue this is the Alternative Logistic Control Number (ALC) or the Alternate Indentured Product Code (AIPC).

Going back to my BMW motorcycle, I have a Tall Windshield, where other people have a short windshield. And the directions to remove them are slightly different for the same bike. This is a variant of the disassembled bike.

FUNCTION CODE

The function code describes which type of directions are provided. A function code is a 3-digit number. A short list of the Primary functional codes are provided in the following table.

A 400 level function code provides fault reports and isolation procedures. Whereas 500 level function codes provides instructions to disconnect, remove and disassemble something. The following table provides a sample of the most often used primary function codes. The entire set of function codes is literally pages and pages of selection available.

Function Codes for Task Descriptions

FUNCTION CODE VARIANT

The Function Code Variant is a one Letter assignment. The basic, off the shelf item starts with the letter A. Instructions for a specific installation, or a one-off is indicated by letter B. This provides ability to deliver specific task instructions.

ITEM LOCATION

Item Location code identifies the location of the unit on which maintenance is being performed. Some maintenance is performed while it is installed on the aircraft, which some maintenance is only performed after the item has been removed from the aircraft and is sitting on the work bench

Together these codes for hardware and identification, the information of primary function and learning type creates the Data Module Code (DMC). The DMC can range from a set of 17 to 41 alphanumeric characters.

IMPORTANT TO KNOW ABOUT DMC

It is vitally important for everyone involved in the project to understand and agree on the DMC codes before the project starts. These important variables are used to look-up and search for information later.

These become the “hooks” by which any data is retrieved from the database. So if you want to know which valves were installed and where three years from now, how these fields of information are filled become vitally important. Worst of all, if you are inconsistent in the manner in which the data is populated it will be a giant mess.

The quality of the data out is only as good as the data put into the database.

Before the project even begins, document how the DMC is defined. Make sure this is a “live” document and updated as the project is refined. Make sure everyone has access to the latest and greatest copy of the document too.

Chapter 3 Elements and Attributes, Oh My!

Structured Documentation

The data modules are structured documentation. Structured documents are made up of XML containers of information and data. Larger XML containers are built from adding smaller ones together and more containers are added until the structure is complete. These XML containers are called “Elements” and each element has one or more attributes.

The completed structure is what we have always delivered to the client. A master set of documentation providing information and guidance to maintain whatever it is that was purchased.

It may be awkward at first to understand, but XML does not DO anything. Here’s a short example of an XML note.

<note>

<to> Rhonda </to>

<heading> Reminder </heading>

<body> You owe me a dollar </body>

</note>

The note is called a “structured document” because it has the structure of heading and body. It has sender information, the note has receiver information. But still, the XML does not DO anything. XML is just information wrapped in “tags”. For those who know that HTML is how web pages are built, the HTML was designed to display the data with focus on how the data looks, the XML was designed to carry data, with a focus on how the data is defined.

XML structure keeps it simple. It simplifies data sharing. It simplifies data transport. It eliminates the problems of incompatible systems and upgrades. The XML provides a means to store data in plain text format. This provides a software and hardware independent way of storing, retrieving and sharing the data. For this reason, XML makes it easier to expand and update to new operating systems, new applications or new browsers without loosing any data. And it all starts with a container called a “data module”.

Containers

Data Modules are made of container elements. In XML the container is the area enclosed by the beginning and ending brackets and looks like this <container>. If you right-mouse click on an XML document you can choose to open the document using WordPad..

One of the more common container elements is the <Figure> element. The figure element must contain not only the graphic image but it also needs a list of attributes for the figure, such as the file name of the graphic, the figure title, etc.

Because the figure element contains other elements is it called a Container Element. Like Russian Stacking Dolls, container elements can contain smaller and smaller other elements.

Elements

Elements have ‘names’ and the name describes the type of data they contain. Going back to the example of the <person> element. As you would expect, the data contains information about the person.

Some elements are considered “containers” because they contain more than one piece of information. Typically they hold more detailed data, or attributes about the data. The attributes stored in a data element are sometimes called “child elements” because they are children of the main element.

Look at <person> as an element, or container. The attributes of a person could be they are female, her first name is Anna and her last name is Smith.

Attributes

Attributes provide the details about the element.

Consider the <date> element. The attributes are “month”, “day” and “year”. But <date> can be formatted in many different ways. Some places write Jan 07, 2021 while other places write 07 JAN 21, and it could also be seen as January 7, 2021. Or even 01/07/2021. You know what I mean.

Because there are many ways to enter the same information there are restrictions on the values. Th next figure is an example of an element named “initials” who is restricted to three capital letters.

No, you don’t have to know how to code. But you do have to know the rules of entering data. And with each restriction there is a rule. The rule in this instance means that you have to enter the text as three all capital letters.

For creating data modules, the most important things to remember are the fact that each data module has a set of elements and attributes. Some elements and their attributes are seen as content, while other elements and their attributes are not seen by the user. A specific string of elements creates the Data Module Code (DMC) — the “name” of the data module. And finally, some elements and attributes are mandatory (M) while others are optional (O). Those are the basics to create any data module.

Note too that not all elements are in every data module. This next figure shows the list of element and attribute names with an “x” indicating which data module it can be used in. For example, a <checkListProcedure> is only found in the Checklist Data Module. However, the element <commonInfoDescrPara> can be used in the Procedure, Fault, Checklist and Process Data Modules.

But before we get into the details of creating a data module, there are some other terms and definitions that useful to know.

Cardinality

Cardinality is an important restriction for an element. It constraints the number of instances (cardinality) that an element can appear in an XML document. In other words Cardinality sets the number of times you can use an element.

Cardinality is specified by using “minOccurs” and “maxOccurs” attributes. And if we do not specify minOccurs or maxOccurs, the default value is 1. That means once. There can only be one and only one occurrence of the element and it is mandatory.

Namespaces

Namespaces are names given to specific groups of schema. For example, if we had a schema for purchase orders, we might want names spaces for the international purchase orders to separate them from state or regional purchase orders.

If you look under the hood, schema elements that are associated with a namespace have the prefix such as xsd.

Extensible Markup Language (XML)

XML is not new. It was created in 1996 I kid you not. It is an “open standard” which means it’s free to use. But that also means it is free for everyone to interpret the code in a way that suits their needs best. Consider yourself warned.

XML syntax can be read by hundreds of applications including RSS, Atom, SOAP, SVG, XHTML and even Word. I can hear you now, “here’s a quarter…”

The actual document for XML comes in two parts: the markup and content. A whole chapter is dedicated to this later on.

The first thing for Technical Writers and Illustrators to know is that XML is a “tree hierarchy”. The Reader’s Digest Big Print version of this means that all of the files have to be kept to be inside the same electronic file folder. There cannot be a separate file folder for “illustrations”.

Common Source Data Base (CSDB)

Because there are so many pieces of the XML puzzle that combine to make a document, it is necessary to house the complete palette of elements, illustrations and the schema in a database. The aim of the CSDB is to provide a user friendly automatic process to build the documentation. Oh excuse me, the proper term is called a Publication Module (PM). It’s a more accurate description really. The final product is more than just a document or set of documents.

Document Object Model (DOM) Parser

The DOM defines the standard for accessing and manipulating documents. It was established by the W3C, the World Wide Web Consortium. The people who brought you the internet. https://en.wikipedia.org/wiki/World_Wide_Web_Consortium.

In simplified English, this means that .XML documents are “read” by a “parser”. Just as Word is used to read .doc files, and Internet Explorer and Google Chrome web browsers are used to view files on the internet, a Parser is used to read the XML files.

Data Module Requirements List (DMRL)

The data module requirements list defines the data modules to be created. It is the “intended content list” for the data base. This usually becomes the contractual document, the list of deliverables between the technical writers/illustrators and the documentation owner.

Chapter 4 Schema

When a Plan Comes Together

This chapter provides an overview of the elements and attributes specifically to create the description and process data schema. As you recall, a schema is a combined set of elements Many more element combos exist than are presented here. And the descriptions of the schema presented in this book provide enough information to get your feet wet, but not enough to make you competent at S1000D requirements. This book was never intended to provide everything you need to know. The purpose is to give you enough knowledge to know how creating an XML document is way different from creating a document in word.

Pictures are Worth a Thousand Words

The following demonstrates how elements are shown as a picture. Figure 1 shows an example of the basic parent element <dmodule>. It is a container element in the <identAndStatusSection> of a data module and contains address and other identity elements. Graphical illustrations of an element provide the most amount of information about any element in the smallest amount of space. As they say “pictures are worth a thousand words”. So now you know how to interpret an element by just looking at a picture of one.

This is where things get interesting. Patiently we will start with the elements and attributes that are includes in every data module. Then we will address the elements and attributes specifically for a Descriptive and Procedural modules. We chose the Descriptive and Procedural type modules because they are used so often.

The Element of Surprise

Hopefully there will be no surprises. Now for descriptions of some elements. We start with the <dmodule> element because it is the first element at the top of every data module.

dmodule

One of the first decisions is what type of data module is applicable. Standardization of Data Modules were created by piecing together smaller frequently used schema. These are the basic data modules, sometimes written dmodule, or DM.

Basic data module types are named: “crew module”, “Description Module”, “Illustrated Parts Data Module”, “Procedural Module” to name a few. Start with the dmodule type that best describes the data.

Let’s look at a data module to see what it looks like under the hood. The following is an illustration of a Procedural Module. The identandStatusSection is a container type element. It contains the identExtension and the dmCode.

Remember opening the wooden Russian Nesting Doll? In this case the nesting dolls are small schema nested inside of other schema inside other schema and the container is called the Data Module.

And remember that each container element has a set of attributes to go with it. The required attributes are indicated by the red boxes in the illustration.

Next let’s take a look at a few important elements. I’ll show the elements this time in the form of a table instead of an illustration so you can see and example of the attributes and what they mean.

dmCode

The data module code is essentially a code to tell you what is inside the data module without having to open it. It must be a unique identifer. There can be no duplicates. The dmCode says it all — what type of data module is used, what stage of disassembly it is in, where it is located and other information.

The <dmCode> uses the attributes to form part of the unique identifier and it is called the data module code.

The following provides an example of the dmCode. These attributes are at the top of the data module. They describe what information is contained within the data module.

dmCode

Schema

For our purposes, a Schema is a small set of elements and attributes that suit our needs and we assign a name to it. Just like playing poker certain hands are given names like “Royal Flush” or “Straight Flush”, the XML world has sets of elements and attributes they define for specific uses. Publishers use the DocBook schema or Publishing Requirements for Industry Standard Metadata (PRISM). Vector images use the schema called Scalable Vector Graphics (SVG). Graphical User Interfaces (GUIs) schemas as Extensive Application Markup Language for Java (FXML) or XML User Interface Language (XUL). People who create forms use XForms.

A schema for a document describing a website defines a website element, a webpage element, and other elements that describe content divisions within any page on that site.

In the bike example the schema looks like this:

<?xml version=”1.0" encoding=”utf-8"?><dmodule xmlns:dc=”http://www.purl.org/dc/elements/1.1/" xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xlink=”http://www.w3.org/1999/xlink" xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=”http://www.s1000d.org/S1000D_4-2/flat_schema/learning.xsd"> <rdf:Description> <dc:creator>U8025</dc:creator> <dc:title>Bicycle — Performance support</dc:title> <dc:subject>Bicycle — Performance support</dc:subject>

There is a schema for a description module and a schema for a procedural module. There is a specific schema to create a checklist and another schema for maintenance planning information. The most important thing to remember is that each schema has a set of mandatory elements and attributes. The information and the order in which the information is presented is set in stone.

Schema information is probably more than you wanted to know, so here is the important parts to remember: There are three parts to digital documentation technology. The XML element names define the content. In HTML for the web browsers, these are called “tags”. The second part is called the metadata. This is the data “under the hood” that allows the search engines to find the content. The final part of the equation are the style sheets. The style sheets adapts document for the various reading devices (tables, smartphones, e-readers, etc).

Chapter 5 What is an e-Book?

ePublishing

Electronic publishing is the process of issuing the modules and associated data in machine-readable form rather than on paper. Because the content is electronic it may be distributed over the internet and users can read the material on a wide rage of electronic and digital devices. The names of ePublishers is available to anyone with a Browser to search for “epublisher” and access to the internet.

apps

Way back in the dark ages of 2010 native software applications were required to reside on each platform. Customers are driving the manufacturer’s toward universal device, but we are not there yet.

Amazon has Kindle. Everybook, Inc has an Everybook Dedicated Reader, the Franklin eBookman has a device similar to the Palm Pilots and phones, but with a larger screen. Heibook combines the XML based,OEB-compliant eBook reader with an MP3 player and games with an audio recordder. FXPALs Xlibris makes a high resolution tablet with a pen. Nuvomedia has an ebook device called the Rocket eBook. There are many more.

Format

One of the more common file formats for electronic publishing is e-pub. It is a free and open standard available in may publishing programs. Another one is .folio which is used by Adobe for the iPad tablet and apps.

Interactive Electronic Technical Manuals (IETMs) are used by the military. The military specification MIL-STD-40051 is the perparation of Digital Technical Inforamtion for Interactive Electronic Technical Manuals (IETMs). Those standards cover everything except aviation.

In computing the XML is a markup language that defines a set of rules for encoding the documents and its information into a format that is both human-readable and machine-readable.

S1000D is an international specification for technical publications for the procurement and production of technical publications for aerospace, defense and capital-intensive equipment applications. The S1000D group combined the requirements for the maintenance and operations document into a common source. They utilized the existing XML to create specified elements and attributes for procedures and processes. This is the origin for the data module types used today.

XML Parcer

An XML Parser “reads” the document. When we said that the XML is read by both machines and people, this is the machine part of reading the XML. The parcer provides the means to enter a new data module, access existing data or modify the data. Essentially, it parces the data into separate parts: the data, illustrations and the structure. There are entire books written regarding how to implement the various parsers. We do not need to go into any of that here.

The important thing to remember for writers and illustrators about an XML Parcer is that it performs a validation. It checks to verify that a “procedural schema” matches the requirements defined at the http://www.w3.org/XML/XMLSchema/. Else, the document “fails” and isn’t even read into the system. So check your document against the applicable schema requirements. Just exporting a document from MicroSoft Word into .XML doesn’t cut it. Not even close.

Chapter 6 Technical Writing

This is how manuals are usually written: Tech writers and Illustrators create a first draft of the information based on initial specifications — what the customer said they wanted and what we said we would deliver.

Of course, by the time it’s all said and done, the final approved released documentation barely resembles the first draft. The first draft is a total waste of time. As part of the frustrating review process, engineers walk and talk while they recant their adventures of 20 years ago when somebody cared. Tech writers assemble the drafts based on the released drawings, which engineers promptly rip apart and say those were preliminary drawings. You’d think that by P27 the “preliminary” draft would be close. Not so much. And the process starts over again. Finally, the document is published

That part hasn’t changed. sorry. It has just gotten more complicated.

Structured Documents

One of the reasons to migrate from the old style creating documents using MicroSoft Word to a structured framework is work efficiency. There is a simple misconception of how tech writers spend (or should spend) their time. This prevailing notion believes that “writers,” spend a large part of their time managing and publishing information and most of the time “writing”. Actually, very little time is spent “writing”. Most of the time is spent looking for information, or waiting for information from someone else. Because of this misconception, it is hard for some to understand how efficiently a properly-designed structured authoring environment could be. Technical writing has never been about how fast you type. It has always been about how fast you can compose and organize the content to meet all of the standards and be understood by the end-users.

The cornerstone of any project is dependent upon the client’s understanding and participation in that implementation. The project to move from flat files to an object oriented database structure is no different.

Drafts

Drafts were sent out as “PDF” files and reviewed by the subject matter experts. They ignored these drafts whenever possible. I don’t think anyone likes to read anymore

With S1000D drafts are designated using the attribute ‘inwork’

Tracking Changes

Changes were designated using “Change Bars”, the big 4.5 point black bar that was posted next to the stuff that changed

By the time we got to revision Z, Roger lost all his hair. It had become too unmanageable.

ATA iSpec 2200 vs S1000D

This is for those who are writing specifically for the aircraft industry. If this is not you, just skip it an move along.

ATA iSpec 2200

The group previously known as the Air Transport Association became the Airlines for America. The document they provided, the ATA iSpec 2200, provided the recommended specifications for the content, structure and deliverables to meet the communication requirements, those being the physical, electronic and future technologyof aircraft product technical information.

The objective of the iSpec 2200 was to minimize the cost and effort and exchange of information to meet the airline operational needs. the iSpec 2200 is a document-centered standard.

The iSpec 2200 provides the Document Type Definitions. The following is a partial list:

Aircraft Maintenance Manual
Aircraft Illustrated Parts Catalog
Component Maintenance Manual
Consumable Products Manual
Flight Crew Operations Manual
Maintenance Planning Document

S1000D

The s1000D is a data information standard. The move from a document to a data-centered source of information creates a modular, bite size information. The information resides as modules in a Common Source Database (CSD). The database is the repository for the storage of all of the document pieces required to produce the technical publications for a project.

The S1000D basic document is a data module. A data module is the minimal information document for exchange of information. It is the smallest and standalone information unit conveying a particular type of information about specific parts of the Product.

There is a Schema for each type of technical document unit. Examples of schemas are as follows:

proced.xsd for Procedures
descript.xsd for Descriptions
sb.xsd for Service Bulletins
container.xsd for Container Data Modules

Common Information Repository (CIR) Data Module

One of the best features of modular text is that segments can be re-used. And if the information is updated, it is updated everywhere at the same time.

The CIR is the library of standard text. For example, it would be a set of warnings. Warn-0525 could be “DO NOT GET CLOSE TO….”

An example of CIR is as follows:

<commonRepository> <warningRepository> <warningSpec changeType=”modify”> <warningIdent warningIdentNumber=”warn-00525"></warningIdent> <warningAndCautionPara>Make sure that the bulb is cool before you replace it.</warningAndCautionPara> </warningSpec> … </warningRepository> </commonRepository>

Warnings Format

The default heading WARNING must be in 12/14 pt bold, uppercase and underlined centered on the width of the warning itself. This needs to be separated by 8 pt after the previous text paragraph. The actual warning text starts 8 pt AFTER the WARNING heading. Keep the WARNING heading and the actual warning text on the same page.

The warning text must be in 10/11 pt bold, lowercase.

Cautions Format

The default heading CAUTION must be in 12/14 pt bold, uppercase and NOT underlined centered on the width of the caution itself. This needs to be separated by 8 pt after the previous text paragraph. The actual warning text starts 8 pt AFTER the CAUTIONG heading. Keep the CAUTION heading and the actual caution text on the same page.

The caution text must be in 10/11 pt NOT bold, lowercase.

Chapter 7 The Descriptive Module

Under the Hood

For demonstration purposes, we are starting with the “descriptive Module”. Every data module has two parts:

The schema is from the S1000D organization. At the top of the data module is a link to the URL http://www.s1000d.org/S1000D_4-0/xml_schema_flat/descript.xsd where it reads the schema file.

Translation and Schema XML Text

Next we introduce each of the required elements in the order in which the data is entered. The Data Module Code (DMC) is automatically created and placed at the top of the document, which is also a requirement of the S1000D.

identAndStatusSection

The <identAndStatusSection> provides the identity for the type of module or work that is described and the status of the data module.

The following describes each of the component elements of the <identAndStatusSection>.

dmAddress and dmIdent

The <dmAddress> is a container element for another container element <dmIdent> and the element <dmIdent> is looking for information regarding the identity for this data module.

identExtension

This is one of the Business Rules you decided. The goal is to have a unique identification for the data modules. The <identExtension> establishes a unique subdomain for instance identification. In other words, this is the first identifier for the group of data modules.

It has two attributes: The (M) means it is mandatory to enter the data.

-extensionProducer (M), is typically the CAGE code of the producer of the data module instance. Or it can be the unique number for the manual set.- extensionCode (M), the data module extended code. The value is decided by the data module producer.

dmCode

is the basic identify code parameters.

Chapter 8 Illustrations

Chapter 9 Applicability

Chapter 10 Let’s Do This

Chapter 11 Common Information Repositories

FAQ

2019.08.30 - Elasticsearch의 시계열 데이터 쿼리 및 집계 작업

drscg — Fri, 25 Sep 2020 15:04:07 +0900

일반적으로 Elasticsearch는 검색 엔진이며, Lucene 데이터베이스에 그 검색 인덱스를 유지합니다. 그러나 처음 시작된 이래 Elasticsearch는 그 자체가 고성능의 클러스터와 확장이 가능한 데이터 저장소로 진화해왔습니다. 그 색인 형식은 여전히 처음 시작되었던 때를 반영하지만, 모든 종류의 사용자가 모든 종류의 목적으로 이를 사용합니다.

이러한 목적 중 하나는 시계열 데이터를 저장, 처리 및 검색하는 것입니다. 시계열 데이터는 정확한 타임스탬프와 연관되는 모든 데이터 요소를 특징으로 합니다. 가장 빈번하게는, 데이터 요소가 특정 시점에서 이루어진 일종의 측정을 나타냅니다. 이것은 주가일 수도 있고, 과학적인 관찰일 수도 있고, 서버의 로드일 수도 있습니다.

시계열 데이터의 취급에 특화된 몇 가지 데이터베이스 구현이 존재하지만, 시계열이 저장되고 쿼리되는 일반적인 형식은 없습니다. 이론적으로는 어떤 데이터베이스 엔진도 시계열 데이터를 취급하는 데 사용될 수 있습니다.

추상 형식으로, 시계열 데이터베이스 항목은 다음으로 이루어집니다.

계열 이름
타임스탬프
값
계열에 대한 추가 정보를 포함하는 키-값 쌍 또는 태그

서버 모니터링 사용 사례에는, 언제나 시계열이 어느 호스트에 속하는지를 지정하는 하나의 키-값 쌍이 존재하게 됩니다. 그러나 더해질 수 있는 추가 정보는 어떤 것이든 될 수 있으며, 특정한 호스트 세트에 대한 메트릭을 요청하기 위해서만 나중에 사용될 수도 있습니다. 예제는 프로덕션 환경에 속하는 서비스나 특정 클라우드 서비스 제공자에서만 실행되는 인스턴스 등 구체적인 서비스를 실행하는 호스트가 될 것입니다.

이것을 더 실용적으로 만들기 위해, Elasticsearch 쿼리를 사용하여 데이터에서 특정 시계열 정보를 걸러낼 수 있는 방법의 예제로 Metricbeat 데이터를 사용해 보겠습니다.

각 Metricbeat 문서에는 다음 정보가 포함됩니다.

타임스탬프
실제 시계열 데이터
- Metricbeat의 경우, 문서의 이 부분의 형식에 대해서는 Metricbeat 설명서에 설명되어 있습니다. 시스템 모듈의 cpu 메트릭 세트에 대해 더 자세히 알아보려면, 메트릭 세트 설명서를 참조하세요.
문서에 포함되어 있는 메트릭 그 자체에 대한 메타데이터 Metricbeat는 ECS 필드 event.module과 event.dataset를 사용하여 어느 Metricbeat 모듈이 문서를 생성했는지, 그리고 어느 메트릭 세트가 문서에 포함되어 있는지를 지정합니다.
- 이것은 시계열 데이터를 검색하려고 하기에 앞서, 어느 메트릭이 처음에 나타나는지를 찾아내는 데 도움이 될 수 있습니다.
물리적인 호스트이든, 가상 머신이든, 아니면 Kubernetes pod나 Docker 컨테이너 같은 규모가 더 작은 항목이든, 인스턴스에 대한 메타데이터
- 이 메타데이터는 Elastic Common Schema를 따르며 따라서 역시 ECS를 사용하는 다른 소스의 데이터와 일치될 수 있습니다.

예제로, 이것은 system.cpu 메트릭 세트의 Metricbeat 문서가 어떻게 생겼는지를 보여줍니다. _source 객체에 대한 인라인 주석은 어디에서 필드에 대한 더 자세한 정보를 찾을 수 있는지를 나타냅니다.

ECE 설명서
- ECS 필드 참조
Metricbeat 설명서
- Metricbeat 공통 필드
system.cpu 메트릭 세트 설명서
- 시스템 필드
- 시스템 CPU 메트릭 세트

유의사항: 문서에는 가독성을 위해 JSON에 # 주석이 포함되어 있습니다.

{ 
  "_index" : "metricbeat-8.0.0-2019.08.12-000001", 
  "_type" : "_doc", 
  "_id" : "vWm5hWwB6vlM0zxdF3Q5", 
  "_score" : 0.0, 
  "_source" : { 
    "@timestamp" : "2019-08-12T12:06:34.572Z", 
    "ecs" : { # ECS metadata 
      "version" : "1.0.1" 
    }, 
    "host" : { # ECS metadata 
      "name" : "noether", 
      "hostname" : "noether", 
      "architecture" : "x86_64", 
      "os" : { 
        "kernel" : "4.15.0-55-generic", 
        "codename" : "bionic", 
        "platform" : "ubuntu", 
        "version" : "18.04.3 LTS (Bionic Beaver)", 
        "family" : "debian", 
        "name" : "Ubuntu" 
      }, 
      "id" : "4e3eb308e7f24789b4ee0b6b873e5414", 
      "containerized" : false 
    }, 
    "agent" : { # ECS metadata 
      "ephemeral_id" : "7c725f8a-ac03-4f2d-a40c-3695a3591699", 
      "hostname" : "noether", 
      "id" : "e8839acc-7f5e-40be-a3ab-1cc891bcb3ce", 
      "version" : "8.0.0", 
      "type" : "metricbeat" 
    }, 
    "event" : { # ECS metadata 
      "dataset" : "system.cpu", 
      "module" : "system", 
      "duration" : 725494 
    }, 
    "metricset" : { # metricbeat metadata 
      "name" : "cpu" 
    }, 
    "service" : { # metricbeat metadata 
      "type" : "system" 
    }, 
    "system" : { # metricbeat time series data  
      "cpu" : { 
        "softirq" : { 
          "pct" : 0.0112 
        }, 
        "steal" : { 
          "pct" : 0 
        }, 
        "cores" : 8, 
        "irq" : { 
          "pct" : 0 
        }, 
        "idle" : { 
          "pct" : 6.9141 
        }, 
        "nice" : { 
          "pct" : 0 
        }, 
        "user" : { 
          "pct" : 0.7672 
        }, 
        "system" : { 
          "pct" : 0.3024 
        }, 
        "iowait" : { 
          "pct" : 0.0051 
        }, 
        "total" : { 
          "pct" : 1.0808 
        } 
      } 
    } 
  } 
}
Read Less

요약하자면, Metricbeat 문서 내에는 시계열 데이터와 메타데이터가 섞여 있으며, 정확히 필요한 것을 검색하려면 문서 형식에 대한 구체적인 지식이 필요합니다.

대조적으로, 시계열 데이터를 처리, 분석 또는 시각화하고자 하는 경우, 데이터는 통상적으로 이처럼 표와 같은 형식이어야 합니다.

<series name> <timestamp> <value> <key-value pairs> 
system.cpu.user.pct 1565610800000 0.843 host.name=”noether” 
system.cpu.user.pct 1565610800000 0.951 host.name=”hilbert” 
system.cpu.user.pct 1565610810000 0.865 host.name=”noether” 
system.cpu.user.pct 1565610810000 0.793 host.name=”hilbert” 
system.cpu.user.pct 1565610820000 0.802 host.name=”noether” 
system.cpu.user.pct 1565610820000 0.679 host.name=”hilbert”

Elasticsearch 쿼리는 그러한 표에 대단히 근접한 형식의 시계열 데이터를 프로그래밍 방식으로 검색하는 데 도움이 될 수 있으며, 다음 예제는 이렇게 하는 방법을 보여줍니다. 쿼리를 가지고 직접 실험해보고 싶으시면, Elasticsearch 인스턴스와 system.cpu 및 system.network 메트릭 세트를 위해 데이터를 수집, 전송하는 실행 중인 Metricbeat 설치가 필요할 것입니다. Metricbeat에 대한 간단한 소개는 시작하기 설명서를 참조하세요.

Kibana의 Dev Tools 콘솔에서 모든 쿼리를 실행할 수 있습니다. 이전에 사용해보신 적이 없는 경우, Kibana 콘솔 설명서에서 간단한 소개를 찾아보실 수 있습니다. 예제 쿼리에서 호스트 이름을 변경해야 한다는 점에 유의하세요.

우리는 Metricbeat가 다음 기본 구성에 따라 설정된 것으로 가정합니다. 이것은 하루에 하나의 인덱스를 만들며, 이러한 인덱스에는 ‘metricbeat-VERSION-DATE-COUNTER’라는 이름이 붙게 된다는 뜻입니다. 즉, metricbeat-7.3.0-2019.08.06-000009 같은 이름이 될 것입니다. 이러한 인덱스를 한 번에 쿼리하기 위해, 다음과 같이 와일드카드를 사용하겠습니다.

예제 쿼리:

GET metricbeat-*/_search

그리고 다음 예제 응답:

{ 
  "took" : 2, 
  "timed_out" : false, 
  "_shards" : { 
    "total" : 1, 
    "successful" : 1, 
    "skipped" : 0, 
    "failed" : 0 
  }, 
  "hits" : { 
    "total" : { 
      "value" : 10000, 
      "relation" : "gte" 
    }, 
    "max_score" : 1.0, 
    "hits" : [...] 
  } 
}

당연히, 이 쿼리는 하나의 쿼리에서 반환되는 Elasticsearch 문서 한도를 초과합니다. 실제 실행 횟수는 여기서 생략되었지만 결과를 스크롤하면서 주석이 달린 위의 문서와 비교해보고 싶으실 수도 있습니다.

모니터링되는 인프라의 크기에 따라, 엄청난 수의 Metricbeat가 있을 수 있지만, (기록된) 시간의 처음부터 시계열이 필요한 경우는 드뭅니다. 따라서 날짜 범위부터 시작해 보겠습니다. 이 경우에는 범위가 지난 5분간입니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": { 
    "range": { 
      "@timestamp": { 
        "gte": "now-5m" 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  "took" : 4, 
  "timed_out" : false, 
  "_shards" : { 
    "total" : 1, 
    "successful" : 1, 
    "skipped" : 0, 
    "failed" : 0 
  }, 
  "hits" : { 
    "total" : { 
      "value" : 30, 
      "relation" : "eq" 
    }, 
    "max_score" : 0.0, 
    "hits" : [...] 
  } 
}

이제 이것은 훨씬 더 관리하기 쉬운 크기입니다. 그러나, 이 쿼리가 실행되는 시스템은 보고하는 호스트가 단 하나 밖에 없으며, 따라서 프로덕션 환경에서는 실행 횟수의 수치가 여전히 대단히 높게 됩니다.

특정한 호스트에 대한 모든 CPU 데이터를 검색하려면, 처음에 미숙하게 시도하는 Elasticsearch 쿼리는 host.name과 metricset system.cpu를 위한 필터를 추가하는 것이 될 수 있습니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": { 
    "bool": { 
      "filter": [ 
        { 
          "range": { 
            "@timestamp": { 
              "gte": "now-5m" 
            } 
          } 
        }, 
        { 
          "bool": { 
            "should": [ 
              { 
                "match_phrase": { 
                  "host.name": "noether" 
                } 
              }, 
              { 
                "match_phrase": { 
                  "event.dataset": "system.cpu" 
                } 
              } 
            ] 
          } 
        } 
      ] 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  "took" : 8, 
  "timed_out" : false, 
  "_shards" : { 
    "total" : 1, 
    "successful" : 1, 
    "skipped" : 0, 
    "failed" : 0 
  }, 
  "hits" : { 
    "total" : { 
      "value" : 30, 
      "relation" : "eq" 
    }, 
    "max_score" : 0.0, 
    "hits" : [...] 
  } 
}

이 쿼리는 여전히 대량의 문서를 반환하며, 모든 문서가 system.cpu 메트릭 세트에 대해 Metricbeat가 보낸 전체 데이터를 포함하고 있습니다. 몇 가지 이유로, 이것은 대단히 유용한 결과는 아닙니다.

첫째로, 우리는 전체 기간에 걸쳐 모든 문서를 검색해야 할 것입니다. 우리가 구성된 한도에 도달하자마자, Elasticsearch는 한 번에 이것을 반환하지 않지 않고 그 순위를 매기려 할 것이며(이것은 우리 쿼리에는 적합하지 않습니다) 타임스탬프에 따라 정렬된 문서를 반환하지 않을 것입니다.

둘째로, 우리는 타임스탬프, 메트릭 값 몇 개, 그리고 어쩌면 일부 추가적인 메타데이터 필드 등 각 문서의 작은 부분에만 관심이 있습니다. Elasticsearch로부터 전체 _source를 반환한 다음, 쿼리 결과로부터 그 데이터를 골라내는 것은 대단히 비효율적입니다.

이것을 해결하기 위한 한 가지 방법은 Elasticsearch 집계를 사용하는 것입니다.

예제 1: CPU 사용률, 다운샘플링

우선, 날짜 히스토그램을 살펴보겠습니다. 날짜 히스토그램 집계는 시간 간격당 한 개의 값을 반환하게 됩니다. 반환된 버킷은 이미 시간을 기준으로 정렬되어 있으며, 데이터와 일치하는 간격 또는 버킷 크기가 지정될 수 있습니다. 이 예제에서는, Metricbeat가 기본값으로 10초마다 시스템 모듈로부터 데이터를 전송하기 때문에 간격 크기가 10초로 선택되어 있습니다. 최상위 size: 0 매개변수는 우리가 더 이상 실제 적중 횟수에 관심이 없고 집계에만 관심이 있음을 지정하고 있으며, 따라서 어떤 문서도 반환되지 않을 것입니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},  # same as above 
  "size": 0, 
  "aggregations": { 
    "myDateHistogram": { 
      "date_histogram": { 
        "field": "@timestamp", 
        "fixed_interval": "10s" 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : { 
    "total" : { 
      "value" : 30, 
      "relation" : "eq" 
    }, 
    "max_score" : null, 
    "hits" : [ ] 
  }, 
  "aggregations" : { 
    "myDateHistogram" : { 
      "buckets" : [ 
        { 
          "key_as_string" : "2019-08-12T13:03:20.000Z", 
          "key" : 1565615000000, 
          "doc_count" : 1 
        }, 
        { 
          "key_as_string" : "2019-08-12T13:03:30.000Z", 
          "key" : 1565615010000, 
          "doc_count" : 1 
        }, 
        { 
          "key_as_string" : "2019-08-12T13:03:40.000Z", 
          "key" : 1565615020000, 
          "doc_count" : 1 
        }, 
        ... 
      ] 
    } 
  } 
}

각 버킷마다, 이것은 키에서 타임스탬프(사람이 읽을 수 있는 날짜/시간 문자열을 포함하는 유용한 key_as_string)와 최종적으로 버킷에 들어있는 문서의 수를 반환합니다.

이 doc_count는 1입니다. 버킷 크기가 Metricbeat의 보고 주기와 일치하기 때문입니다. 그렇지 않다면 이것은 대단히 유용하지 않습니다. 실제 메트릭 값을 보기 위해, 또 다른 집계를 추가하겠습니다. 이 단계에서 우리는 이 집계가 무엇이 될 것인지 결정해야 합니다. 숫자 값, avg, min, max는 좋은 후보입니다. 그러나 버킷당 문서 하나만 갖는 한, 무엇을 선택하든 사실상 중요하지 않습니다. 다음 예제는 10초 길이의 버킷 내에서 메트릭 system.cpu.user.pct 값에 대한 avg, min, max 집계를 반환하며 이것을 보여줍니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},  # same as above 
  "size": 0, 
  "aggregations": { 
    "myDateHistogram": { 
      "date_histogram": { 
        "field": "@timestamp", 
        "fixed_interval": "10s" 
      }, 
      "aggregations": { 
        "myActualCpuUserMax": { 
          "max": { 
            "field": "system.cpu.user.pct" 
          } 
        }, 
        "myActualCpuUserAvg": { 
          "avg": { 
            "field": "system.cpu.user.pct" 
          } 
        }, 
        "myActualCpuUserMin": { 
          "min": { 
            "field": "system.cpu.user.pct" 
          } 
        } 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myDateHistogram" : { 
      "buckets" : [ 
        { 
          "key_as_string" : "2019-08-12T13:12:40.000Z", 
          "key" : 1565615560000, 
          "doc_count" : 1, 
          "myActualCpuUserMin" : { 
            "value" : 1.002 
          }, 
          "myActualCpuUserAvg" : { 
            "value" : 1.002 
          }, 
          "myActualCpuUserMax" : { 
            "value" : 1.002 
          } 
        }, 
        { 
          "key_as_string" : "2019-08-12T13:12:50.000Z", 
          "key" : 1565615570000, 
          "doc_count" : 1, 
          "myActualCpuUserMin" : { 
            "value" : 0.866 
          }, 
          "myActualCpuUserAvg" : { 
            "value" : 0.866 
          }, 
          "myActualCpuUserMax" : { 
            "value" : 0.866 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

보시는 것처럼, myActualCpuUserMin, myActualCpuUserAvg, myActualCpuUserMax에 대한 값은 각 버킷에서 동일합니다. 따라서 주기적인 간격으로 보고된 시계열의 원시 값을 검색해야 하는 경우, 날짜 히스토그램을 사용해 이를 수행할 수 있습니다.

그러나 대부분의 경우, 모든 데이터 요소 하나 하나에 관심을 갖게 되지 않을 것입니다. 특히 몇 초마다 측정이 이루어질 때는 더 그렇습니다. 많은 목적에 대해, 단위가 더 큰 데이터를 갖는 것이 사실상 더 낫습니다. 예를 들어, 시각화는 시계열에서 변형을 표시하기 위해 제한된 양의 픽셀만을 갖습니다. 따라서 단위가 더 세밀한 데이터는 렌더링 시간 동안 버려지게 됩니다.

시계열 데이터는 그 다음에 이루어지는 처리 단계가 무엇이든 그 요구사항에 맞는 세분성 단위로 다운샘플링되는 경우가 많습니다. 다운샘플링에서, 주어진 기간 내의 여러 데이터 요소는 단일한 것으로 축소됩니다. 서버 모니터링 예제에서, 데이터는 10초마다 측정되지만 대부분의 목적에 대해서는 1분 이내의 모든 값 평균으로 충분할 것입니다. 덧붙여 말하자면, 다운샘플링은 날짜 히스토그램 집계가 버킷당 하나 이상의 문서를 발견하는 경우 수행하는 바로 그 작업이며, 정확한 중첩 집계가 사용됩니다.

다음 예제는 다운샘플링의 첫 번째 예제로서 전체 1분 버킷에 걸쳐 중첩 avg, min, max 집계를 갖는 날짜 히스토그램 결과를 보여줍니다. fixed_interval 대신 calendar_interval를 사용하여 버킷 범위를 전체 분 수에 일치시킵니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},  # same as above 
  "size": 0, 
  "aggregations": { 
    "myDateHistogram": { 
      "date_histogram": { 
        "field": "@timestamp", 
        "calendar_interval": "1m" 
      }, 
      "aggregations": { 
        "myDownsampledCpuUserMax": { 
          "max": { 
            "field": "system.cpu.user.pct" 
          } 
        }, 
        "myDownsampledCpuUserAvg": { 
          "avg": { 
            "field": "system.cpu.user.pct" 
          } 
        }, 
        "myDownsampledCpuUserMin": { 
          "min": { 
            "field": "system.cpu.user.pct" 
          } 
        } 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myDateHistogram" : { 
      "buckets" : [ 
        { 
          "key_as_string" : "2019-08-12T13:27:00.000Z", 
          "key" : 1565616420000, 
          "doc_count" : 4, 
          "myDownsampledCpuUserMax" : { 
            "value" : 0.927 
          }, 
          "myDownsampledCpuUserMin" : { 
            "value" : 0.6980000000000001 
          }, 
          "myDownsampledCpuUserAvg" : { 
            "value" : 0.8512500000000001 
          } 
        }, 
        { 
          "key_as_string" : "2019-08-12T13:28:00.000Z", 
          "key" : 1565616480000, 
          "doc_count" : 6, 
          "myDownsampledCpuUserMax" : { 
            "value" : 0.838 
          }, 
          "myDownsampledCpuUserMin" : { 
            "value" : 0.5670000000000001 
          }, 
          "myDownsampledCpuUserAvg" : { 
            "value" : 0.7040000000000001 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

보시는 것처럼, myActualCpuUserMin, myActualCpuUserAvg, myActualCpuUserMax를 위한 값은 이제 다르며, 사용되는 집계에 따라 달라집니다.

다운샘플링에 어느 방법이 사용되는지는 메트릭에 따라 달라집니다. CPU 사용률의 경우, 1분에 걸친 avg 집계로 충분합니다. 큐 길이나 시스템 로드 같은 메트릭에 대해서는, max 집계가 더 적합할 수 있습니다.

이 시점에서는 또한 Elasticsearch를 사용해 일부 기본 산술을 수행하고 원래 데이터에 포함되지 않은 시계열을 계산하는 것도 가능합니다. CPU에 대해 avg 집계로 작업한다고 가정하면, 우리 예제는 다음과 같이 개선된 상태로 사용자 CPU, 시스템 CPU, 그리고 사용자 + 시스템의 합을 CPU 코어 수로 나눈 값을 반환할 수 있습니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},   # same as above 
  "size": 0, 
  "aggregations": { 
    "myDateHistogram": { 
      "date_histogram": { 
        "field": "@timestamp", 
        "calendar_interval": "1m" 
      }, 
      "aggregations": { 
        "myDownsampledCpuUserAvg": { 
          "avg": { 
            "field": "system.cpu.user.pct" 
          } 
        }, 
        "myDownsampledCpuSystemAvg": { 
          "avg": { 
            "field": "system.cpu.system.pct" 
          } 
        }, 
        "myCpuCoresMax": { 
          "max": { 
            "field": "system.cpu.cores" 
          } 
        }, 
        "myCalculatedCpu": { 
          "bucket_script": { 
            "buckets_path": { 
              "user": "myDownsampledCpuUserAvg", 
              "system": "myDownsampledCpuSystemAvg", 
              "cores": "myCpuCoresMax" 
            }, 
            "script": { 
              "source": "(params.user + params.system) / params.cores", 
              "lang": "painless" 
            } 
          } 
        } 
      } 
    } 
  } 
}
Read Less

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myDateHistogram" : { 
      "buckets" : [ 
        { 
          "key_as_string" : "2019-08-12T13:32:00.000Z", 
          "key" : 1565616720000, 
          "doc_count" : 2, 
          "myDownsampledCpuSystemAvg" : { 
            "value" : 0.344 
          }, 
          "myCpuCoresMax" : { 
            "value" : 8.0 
          }, 
          "myDownsampledCpuUserAvg" : { 
            "value" : 0.8860000000000001 
          }, 
          "myCalculatedCpu" : { 
            "value" : 0.15375 
          } 
        }, 
        { 
          "key_as_string" : "2019-08-12T13:33:00.000Z", 
          "key" : 1565616780000, 
          "doc_count" : 6, 
          "myDownsampledCpuSystemAvg" : { 
            "value" : 0.33416666666666667 
          }, 
          "myCpuCoresMax" : { 
            "value" : 8.0 
          }, 
          "myDownsampledCpuUserAvg" : { 
            "value" : 0.8895 
          }, 
          "myCalculatedCpu" : { 
            "value" : 0.15295833333333334 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

예제 2: 네트워크 트래픽 — 기간 및 파생 집계

Elasticsearch 집계가 시계열 데이터에 대해 얼마나 유용할 수 있는지를 보여주는 좀더 상세한 예제는 system.network 메트릭 세트입니다. system.network 메트릭 세트 문서의 관련 부분은 다음과 같이 보입니다.

{ 
... 
"system": { 
        "network": { 
            "in": { 
                "bytes": 37904869172, 
                "dropped": 32, 
                "errors": 0, 
                "packets": 32143403 
            }, 
            "name": "wlp4s0", 
            "out": { 
                "bytes": 6299331926, 
                "dropped": 0, 
                "errors": 0, 
                "packets": 13362703 
            } 
        } 
    } 
... 
}

Metricbeat는 시스템에 존재하는 모든 네트워크 인터페이스마다 하나의 문서를 전송하게 됩니다. 이러한 문서들은 동일한 타임스탬프를 갖게 되지만, 네트워크 인터페이스당 하나인 필드 system.network.name에 대해 다른 값을 갖게 됩니다.

완료된 모든 추가 집계는 인터페이스에 따라 이루어져야 하며, 따라서 우리는 이전 예제의 최상위 날짜 히스토그램 집계를 필드 system.network.name에 대한 기간 집계로 변경합니다.

이를 위해 집계의 기준이 되는 필드 작업은 키워드 필드로 매핑되어야 한다는 점에 유의하세요. Metricbeat이 제공하는 기본 인덱스 템플릿을 가지고 작업하는 경우, 이 매핑은 이미 사용자를 위해 설정되어 있습니다. 그렇지 않은 경우, Metricbeat 템플릿 문서 페이지에 무엇을 해야 하는지를 짤막하게 설명해 놓았으니 참조하시기 바랍니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...}, # same as above 
  "size": 0, 
  "aggregations": { 
    "myNetworkInterfaces": { 
      "terms": { 
        "field": "system.network.name", 
        "size": 50 
      }, 
      "aggs": { 
        "myDateHistogram": { 
          "date_histogram": { 
            "field": "@timestamp", 
            "calendar_interval": "1m" 
          } 
        } 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myNetworkInterfaces" : { 
      "doc_count_error_upper_bound" : 0, 
      "sum_other_doc_count" : 0, 
      "buckets" : [ 
        { 
          "key" : "docker0", 
          "doc_count" : 29, 
          "myDateHistogram" : { 
            "buckets" : [...] 
          } 
        }, 
        { 
          "key" : "enp0s31f6", 
          "doc_count" : 29, 
          "myDateHistogram" : { 
            "buckets" : [...] 
          } 
        }, 
        { 
          "key" : "lo", 
          "doc_count" : 29, 
          "myDateHistogram" : { 
            "buckets" : [...] 
          } 
        }, 
        { 
          "key" : "wlp61s0", 
          "doc_count" : 29, 
          "myDateHistogram" : { 
            "buckets" : [ 
              { 
                "key_as_string" : "2019-08-12T13:39:00.000Z", 
                "key" : 1565617140000, 
                "doc_count" : 1 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:40:00.000Z", 
                "key" : 1565617200000, 
                "doc_count" : 6 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:41:00.000Z", 
                "key" : 1565617260000, 
                "doc_count" : 6 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:42:00.000Z", 
                "key" : 1565617320000, 
                "doc_count" : 6 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:43:00.000Z", 
                "key" : 1565617380000, 
                "doc_count" : 6 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:44:00.000Z", 
                "key" : 1565617440000, 
                "doc_count" : 4 
              } 
            ] 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

CPU 예제에서처럼, 중첩 집계가 없는 경우 날짜 히스토그램 집계는 doc_count만을 반환하며, 이것은 대단히 유용하지 않습니다.

바이트를 위한 필드에는 일정하게 증가하는 값이 포함됩니다. 이러한 필드의 값에는 마지막으로 컴퓨터가 시작된 이래 전송되거나 수신된 바이트의 수가 포함되며, 따라서 측정할 때마다 증가합니다. 이 경우에는, 정확한 중첩 집계가 max입니다. 따라서 다운샘플링된 값에는 버킷 간격 동안 측정된 최고 측정치, 따라서 최신 측정치가 포함됩니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},  # same as above 
  "size": 0, 
  "aggregations": { 
    "myNetworkInterfaces": { 
      "terms": { 
        "field": "system.network.name", 
        "size": 50 
      }, 
      "aggs": { 
        "myDateHistogram": { 
          "date_histogram": { 
            "field": "@timestamp", 
            "calendar_interval": "1m" 
          }, 
          "aggregations": { 
            "myNetworkInBytesMax": { 
              "max": { 
                "field": "system.network.in.bytes" 
              } 
            }, 
            "myNetworkOutBytesMax": { 
              "max": { 
                "field": "system.network.out.bytes" 
              } 
            } 
          } 
        } 
      } 
    } 
  } 
}

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myNetworkInterfaces" : { 
      "doc_count_error_upper_bound" : 0, 
      "sum_other_doc_count" : 0, 
      "buckets" : [ 
        { 
          "key" : "docker0", 
          ... 
        }, 
        { 
          "key" : "enp0s31f6", 
          ... 
        }, 
        { 
          "key" : "lo", 
          ... 
        }, 
        { 
          "key" : "wlp61s0", 
          "doc_count" : 30, 
          "myDateHistogram" : { 
            "buckets" : [ 
              { 
                "key_as_string" : "2019-08-12T13:50:00.000Z", 
                "key" : 1565617800000, 
                "doc_count" : 2, 
                "myNetworkInBytesMax" : { 
                  "value" : 2.991659837E9 
                }, 
                "myNetworkOutBytesMax" : { 
                  "value" : 5.46578365E8 
                } 
              }, 
              { 
                "key_as_string" : "2019-08-12T13:51:00.000Z", 
                "key" : 1565617860000, 
                "doc_count" : 6, 
                "myNetworkInBytesMax" : { 
                  "value" : 2.992027006E9 
                }, 
                "myNetworkOutBytesMax" : { 
                  "value" : 5.46791988E8 
                }, 
                "myNetworkInBytesPerSecond" : { 
                  "value" : 367169.0, 
                  "normalized_value" : 6119.483333333334 
                }, 
                "myNetworkoutBytesPerSecond" : { 
                  "value" : 213623.0, 
                  "normalized_value" : 3560.383333333333 
                } 
              }, 
              ... 
            ] 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

일정하게 증가하는 카운터로부터 초당 바이트의 비율을 얻기 위해, 파생 집계가 사용될 수 있습니다. 선택 사항인 매개변수 unit이 이 집계로 전달되면, 다음과 같이 normalized_value 필드에서 단위당 원하는 값을 반환합니다.

예제 쿼리:

GET metricbeat-*/_search 
{ 
  "query": {...},  # same as above 
  "size": 0, 
  "aggregations": { 
    "myNetworkInterfaces": { 
      "terms": { 
        "field": "system.network.name", 
        "size": 50 
      }, 
      "aggs": { 
        "myDateHistogram": { 
          "date_histogram": { 
            "field": "@timestamp", 
            "calendar_interval": "1m" 
          }, 
          "aggregations": { 
            "myNetworkInBytesMax": { 
              "max": { 
                "field": "system.network.in.bytes" 
              } 
            }, 
            "myNetworkInBytesPerSecond": { 
              "derivative": { 
                "buckets_path": "myNetworkInBytesMax", 
                "unit": "1s" 
              } 
            }, 
            "myNetworkOutBytesMax": { 
              "max": { 
                "field": "system.network.out.bytes" 
              } 
            }, 
            "myNetworkoutBytesPerSecond": { 
              "derivative": { 
                "buckets_path": "myNetworkOutBytesMax", 
                "unit": "1s" 
              } 
            } 
          } 
        } 
      } 
    } 
  } 
}
Read Less

그리고 다음 예제 응답:

{ 
  ..., 
  "hits" : {...}, 
  "aggregations" : { 
    "myNetworkInterfaces" : { 
      "doc_count_error_upper_bound" : 0, 
      "sum_other_doc_count" : 0, 
      "buckets" : [ 
        { 
          "key" : "docker0", 
          ... 
        }, 
        { 
          "key" : "enp0s31f6", 
          ... 
        }, 
        { 
          "key" : "lo", 
          ... 
        }, 
        { 
          "key" : "wlp61s0", 
          "doc_count" : 30, 
          "myDateHistogram" : { 
            "buckets" : [ 
              { 
                "key_as_string" : "2019-08-12T14:07:00.000Z", 
                "key" : 1565618820000, 
                "doc_count" : 4, 
                "myNetworkInBytesMax" : { 
                  "value" : 3.030494669E9 
                }, 
                "myNetworkOutBytesMax" : { 
                  "value" : 5.56084749E8 
                } 
              }, 
              { 
                "key_as_string" : "2019-08-12T14:08:00.000Z", 
                "key" : 1565618880000, 
                "doc_count" : 6, 
                "myNetworkInBytesMax" : { 
                  "value" : 3.033793744E9 
                }, 
                "myNetworkOutBytesMax" : { 
                  "value" : 5.56323416E8 
                }, 
                "myNetworkInBytesPerSecond" : { 
                  "value" : 3299075.0, 
                  "normalized_value" : 54984.583333333336 
                }, 
                "myNetworkoutBytesPerSecond" : { 
                  "value" : 238667.0, 
                  "normalized_value" : 3977.7833333333333 
                } 
              }, 
              { 
                "key_as_string" : "2019-08-12T14:09:00.000Z", 
                "key" : 1565618940000, 
                "doc_count" : 6, 
                "myNetworkInBytesMax" : { 
                  "value" : 3.037045046E9 
                }, 
                "myNetworkOutBytesMax" : { 
                  "value" : 5.56566282E8 
                }, 
                "myNetworkInBytesPerSecond" : { 
                  "value" : 3251302.0, 
                  "normalized_value" : 54188.36666666667 
                }, 
                "myNetworkoutBytesPerSecond" : { 
                  "value" : 242866.0, 
                  "normalized_value" : 4047.766666666667 
                } 
              }, 
              ...   
            ] 
          } 
        }, 
        ... 
      ] 
    } 
  } 
}
Read Less

자체 클러스터에서 이 모든 것을 직접 해보실 수 있습니다. 아직 클러스터가 없는 경우, Elastic Cloud의 Elasticsearch Service 무료 체험판을 사용하거나 Elastic Stack의 기본 배포를 다운로드받으실 수 있습니다. Metricbeat로 시스템에서 데이터 전송을 시작하고 쿼리 작업을 해보세요!

2019.07.17 - Elastic Stack을 사용하여 NGINX 웹 서버를 모니터링하는 방법

drscg — Fri, 25 Sep 2020 14:59:40 +0900

이 글에서는 Elastic Stack의 다양한 구성 요소를 사용하여 NGINX를 모니터링하는 방법을 알아봅니다. Metricbeat와 Filebeat를 사용하여 데이터를 수집합니다. 이 데이터는 Elasticsearch로 전송되어 저장됩니다. 마지막으로 Kibana를 사용하여 해당 데이터를 보겠습니다.

Metricbeat는 연결과 관련된 데이터(활성, 처리됨, 수락됨 등) 및 총 클라이언트 요청 수를 수집합니다. Filebeat는 액세스 및 오류 로그와 관련된 데이터를 수집합니다. Mileage는 설정에 따라 다를 수 있지만 대부분이 정보를 사용하여 다음과 같은 특정 사항을 추론할 수 있습니다.

특정한 리소스에 대한 오류 로그가 급증한다면 여전히 필요한 리소스를 삭제했음을 의미할 수 있습니다.
액세스 로그는 서비스 사용량이 많은 시간을 표시합니다(따라서 유지관리와 같은 작업을 수행하기에 가장 좋은 시기를 확인할 수 있습니다).
클라이언트 요청이 갑자기 급증하면 디도스 공격과 같이 악의적인 상황임을 가려낼 수 있습니다.

이 글은 모니터링 기능을 중점적으로 다루며, Elasticsearch 설정과 같은 것들을 간략하게 설명합니다. 저는 Mac을 사용하고 있으므로 Elasticsearch, Metricbeat, Filebeat 및 Kibana의 Mac 배포를 사용합니다. 다른 플랫폼에 대한 배포는 다운로드 페이지에서 얻을 수 있습니다.

Elasticsearch 설치

Metricbeat 및 Filebeat (실제로 모든 Beats)에는 데이터를 저장하기 위해 Elasticsearch 클러스터가 필요합니다. 간단한 Elasticsearch 클러스터를 로컬로 설정하겠습니다. Elasticsearch를 외부에 공개하지 않으므로 보안 구성에 시간을 소비하지 않을 것입니다.

1단계: Elasticsearch 다운로드

curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.0-darwin-x86_64.tar.gz

2단계: 아카이브 추출

tar -xvf elasticsearch-7.1.0-darwin-x86_64.tar.gz

3단계: bin 디렉토리로 변경

cd elasticsearch-7.1.0/bin

4단계: 단일 노드 클러스터 시작

./elasticsearch

기본적으로 클러스터는 localhost:9200에서 실행됩니다.

NGINX 실행

NGINX를 실행할 수 있는 방법은 여러 가지가 있습니다. 호스트에서 독립적으로, Docker 컨테이너를 통해, Kubernetes 설정 하에 등으로 실행할 수 있습니다. Beats는 컨테이너 API 이벤트를 수신하여 서버 컨테이너를 사용하거나 제거할 때의 서버 컨테이너를 추적할 수 있는 자동 검색 기능이 있습니다.

NGINX를 설정하고 구성할 수 있는 다양한 방법이 있기 때문에, 이 글에서는 지나친 가정 없이 호스트 구성뿐만 아니라 자동 검색(이 경우 Docker) 사례를 보여줍니다.

Metricbeat 및 Filebeat 구성

이제 Beats를 구성하여 데이터를 수집하고 전송하도록 하겠습니다.

Metricbeat

Metricbeat를 사용하여 메트릭을 수집합니다.

1단계: Metricbeat 다운로드:

curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.1.0-darwin-x86_64.tar.gz

2단계: 아카이브 추출

tar -xvf metricbeat-7.1.0-darwin-x86_64.tar.gz

3단계: 디렉토리 변경

cd metricbeat-7.1.0-darwin-x86_64

이제 구성 시간입니다!

기본적으로 구성 파일(metricbeat.yml)은 이전에 구성한 localhost:9200에서 실행 중인 Elasticsearch 클러스터를 찾습니다.

4단계: 관련 Metricbeat 모듈 활성화

기본적으로 시스템 수준 메트릭만 수집됩니다.

./metricbeat modules enable nginx

5단계: 파일 소유권 변경

Metricbeat를 루트로 실행하므로 파일 소유권 몇 개를 변경해야 합니다(또는 엄격한 권한 검사를 비활성화하기 위해 명령줄에서 --strict.perms = false 옵션을 사용하도록 선택할 수 있음).

sudo chown root metricbeat.yml 
sudo chown root modules.d/system.yml 
sudo chown root modules.d/nginx.yml

6단계: 메트릭 세트 활성화

modules.d/nginx.yml 파일을 열면 다음과 같은 주석을 지울 수 있는 stubstatus 메트릭 세트를 활성화할 수 있습니다.

#metricsets:
#  - stubstatus

이 메트릭 세트는 NGINX ngx_http_stub_status 모듈에서 데이터를 수집하므로 이 NGINX 모듈을 메트릭 세트가 작동하도록 구성해야 합니다.

여기에서 모니터링되는 호스트를 변경할 수도 있으며 기본적으로 <a href="http://127.0.0.1"> htttp://127.0.0.1</a>이 모니터링됩니다. 여기까지가 호스트 기반 설정의 전부입니다.

7단계: 자동 검색 설정(대체)

자동 검색 설정을 사용하면 동일한 구성이라도 세 제공자인 Docker, Kubernetes 및 Jolokia마다 구성이 다릅니다. Docker의 예제는 다음과 같이 metricbeat.yml 구성 파일의 맨 아래에 metricbeat.autodiscover를 추가하는 것입니다.

metricbeat.autodiscover:
  providers:
    - type: docker
      templates:
        - condition:
            contains:
              docker.container.image: nginx
          config:
            - module: nginx
              metricsets: ["stubstatus"]
              hosts: "${data.host}:${data.port}"

이 구성을 사용하면 이름에 NGINX가 포함된 이미지를 사용하는 모든 Docker 컨테이너(정확한 일치보다는 하위 문자열 일치를 수행함)가 일치하고 stubstatus 메트릭 세트와 함께 NGINX 모듈을 활성화하는 구성을 사용합니다.

8단계: Metricbeat 실행

이제 구성되었습니다. 로그를 stderr에 보내고 syslog/file 출력을 비활성화하는 플래그로 Metricbeat를 실행할 수 있습니다.

sudo ./metricbeat -e

모든 것이 제대로 작동했다면 초기 출력이 표시되었을 것이며, 이후 Metricbeat에서 데이터를 다시 클러스터에 게시할 때마다 추가 출력이 표시되어야 합니다.

Filebeat

Filebeat를 사용하여 로그를 수집합니다.

1단계: Filebeat 다운로드

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.0-darwin-x86_64.tar.gz

2단계: 아카이브 추출

tar -xvf filebeat-7.1.0-darwin-x86_64.tar.gz

3단계: 디렉토리 변경

cd filebeat-7.1.0-darwin-x86_64

4단계: NGINX 모듈 활성화

./filebeat modules enable nginx

기본적으로 액세스 및 오류 로그가 수집됩니다. 로그 파일 경로의 경우 Filebeat는 OS를 기반으로 경로를 결정하려고 시도합니다. 다른 경로를 명시적으로 설정해야 하는 경우 modules.d/nginx.yml 구성 파일에서 경로를 설정할 수 있습니다.

5단계: 파일 소유권 변경

sudo chown root filebeat.yml
sudo chown root modules.d/nginx.yml
sudo chown root module/nginx/access/manifest.yml
sudo chown root module/nginx/error/manifest.yml

이제 호스트 기반 설정이 완료되었습니다.

6단계: 자동 검색 설정(대체)

이전과 마찬가지로 자동 검색을 사용하려면 추가 구성이 필요합니다. 이전 섹션과 유사하게 Docker의 예제에서도 자동 검색 섹션을 구성에 추가해야 하며, filebeat.yml은 다음과 같습니다.

filebeat.autodiscover:
 providers:
   - type: docker
     templates:
       - condition:
         contains:
           docker.container.image: nginx
         config:
           - module: nginx
             access:
               input:
                 type: docker
                 containers.ids:
                   - "${data.docker.container.id}"
             error:
               input:
                 type: docker
                 containers.ids:
                   - "${data.docker.container.id}"

여기서는 Docker 입력을 사용하도록 액세스 및 오류 옵션을 구성합니다. Docker 입력은 해당 경로(Docker 로그가 있는 기본 경로로, 기본값은 /var/lib/docker/containers)에서 컨테이너 로그를 검색합니다. 템플릿 조건과 일치하는 컨테이너의 ID를 사용하여 containers.ids를 지정합니다. 종합하면, 로그(기본적으로)는 /var/lib/docker/containers/ac29b98ad83ca43bb4c15ae8f0d03aff8c7d57bf5dee9024124374b92b14b0f2/ (ID는 다름)에서 제공됩니다.

7단계: Filebeat 실행

sudo ./filebeat -e

Kibana 설치

이제 Metricbeat 및 Filebeat가 NGINX 서버에 대한 데이터를 전송하므로 Kibana를 통해 데이터를 볼 수 있는 방법이 필요합니다.

1단계: Kibana 다운로드

curl -O https://artifacts.elastic.co/downloads/kibana/kibana-7.1.0-darwin-x86_64.tar.gz

2단계: 아카이브 추출 및 디렉토리 변경

tar -xzf kibana-7.1.0-darwin-x86_64.tar.gz

cd kibana-7.1.0-darwin-x86_64

3단계: Kibana 실행

./bin/kibana

기본적으로 Kibana는 http://localhost:9200의 Elasticsearch 호스트를 사용하며 http://localhost:5601에서 액세스할 수 있습니다.

http://localhost:5601로 이동하면 다음과 같은 메시지가 표시됩니다.

선택적으로 샘플 데이터를 사용해볼 수 있지만 직접 탐색을 클릭해 보겠습니다.

Kibana에서 NGINX 데이터 시각화

다음으로 Kibana를 사용하여 데이터를 보고 분석하는 방법을 살펴보겠습니다.

인프라

Kibana 사이드바에서 인프라 앱으로 이동하면 인프라의 스냅 샷(마지막 순간)을 볼 수 있습니다. 사용된 구성에 따라 비 자동 검색 기반 설정의 호스트에서 데이터에 액세스할 수 있으며, 자동 검색 설정의 경우 Docker 및 Kubernetes 버튼(사용된 제공자를 기반으로 함)이 올바른 데이터 세트로 연결됩니다.

호스트 기반 설정을 사용하면서 호스트 버튼을 클릭하면 다음 데이터가 Metricbeat에서 전달되는 것을 볼 수 있습니다.

노드 중 하나를 선택하고 메트릭 보기를 선택하면 해당 단일 NGINX 서버에 대한 자세한 메트릭이 있는 페이지를 볼 수 있습니다.

로그

대신 로그 앱으로 이동하면 Filebeat에서 전달된 액세스 및 오류 로그를 볼 수 있습니다.

사전 구성된 NGINX 대시보드

이제 Kibana의 실행 및 액세스 가능한 인스턴스가 있으므로 미리 작성된 대시 보드를 로드할 수 있습니다.

Metricbeat 대시 보드를 로드하려면 Metricbeat 디렉토리에서 다음을 실행하십시오.

sudo ./metricbeat setup --dashboards

그리고 Filebeat에 대해서도 동일하게 수행하십시오.

sudo ./filebeat setup --dashboards

이제 Kibana 내 대시 보드 탭으로 이동하면 다음이 표시됩니다.

"nginx" 검색으로 좁히면 다음과 같은 대시 보드를 사용할 수 있습니다.

예를 들어 [Filebeat NGINX] 액세스 및 오류 로그 ECS 대시보드는 다음과 같습니다.

이를 통해 Elastic Stack을 사용하여 NGINX 서버를 모니터링하는 방법을 배웠습니다. 여기서부터는 사용자에게 매우 중요한 정보를 자세히 살펴볼 수 있도록 다양한 옵션(예를 들면 다른 그룹화 및 필터링 옵션)을 보여줍니다.

직접 사용해 보기

Elastic Stack을 시작하는 것은 쉽습니다. 제공된 curl 명령을 통해 다양한 제품을 다운로드하거나 다운로드 페이지로 이동하여 거기서 시작할 수 있습니다. 또는 더 쉬운 방법으로 Elasticsearch Service의 14일 무료 평가판을 사용해보고 시작하십시오. 궁금한 점이 있으면 토론 포럼에서 문의해주세요.

2019.06.12 - Elasticsearch, Kibana, Beats, Logstash의 보안을 유지하기 위한 SSL, TLS, HTTPS 구성

drscg — Fri, 25 Sep 2020 14:55:49 +0900

Elastic Stack 6.7.x / 7.0.x 또는 그 이전 버전을 실행 중이신가요? 그렇다면, "TLS를 설정하는 방법..." 블로그를 확인해보세요. 사용하시는 버전 내에서 통신 보안을 유지하는 데 도움을 받으실 수 있습니다. 이 블로그 게시물에서 다루는 무료 보안 기능에는 Elastic Stack 6.8/7.1 이상이 필요합니다.

Elastic은 Elastic Stack 6.8과 7.1부터 기본 배포(기본 라이선스)의 일환으로 일부 보안 기능을 무료로 릴리즈했습니다. SSL을 이용해 네트워크 트래픽을 암호화하고, 사용자들을 생성 및 관리하며, 인덱스와 클러스터 수준의 액세스를 보호하는 역할을 정의하고, Kibana의 보안을 완전히 유지할 수 있는 새로운 기능이 여기에 포함됩니다. 릴리즈 직후에 나온 저희의 시작하기 블로그 포스팅에서 Elasticsearch와 Kibana 간에 TLS 통신을 사용하는 방법에 대해 설명해드리고 있습니다. 다음 블로그에서는 이 안내지침을 좀더 확장시켜 Logstash와 Beats 등 Elastic Stack의 다른 구성 요소도 다룹니다. 구성 요소 간의 TLS 활성화와 HTTP 클라이언트 통신 암호화에 대해 얘기하게 됩니다.

HTTP 레이어에서 TLS 활성화가 꼭 필요한 것은 아니지만, 데이터를 보호하는, 특히 사용자 이름/비밀번호 정보가 새어나가지 않도록 보호하는 엔드-투-엔드 보안을 위해 적극 권장됩니다. 사용자 이름/비밀번호 정보가 새어나가면 클러스터가 제 기능을 하지 못하게 됩니다. TLS 암호화, 인증, 제한된 스크립트 또는 격리 등에 대해 더 자세히 알고 싶으시면, 암호화, 사용자 등으로 무료로 Elasticsearch 클러스터의 보안을 유지하기 위한 팁 블로그를 참조하세요.

한 가지 더 말씀드리자면, 아래에서 활성화되는 보안 기능은 Elastic Cloud의 Elasticsearch Service에서 표준 기능으로 제공됩니다. Elasticsearch Service에서 운영 중이신 경우, 다 건너뛰고 바로 5단계로 가셔도 됩니다.

Elastic Stack의 보안을 유지하기 위한 단계

1단계. 준비

Elastic Stack 7.1 또는 그 이후 버전의 다음 구성 요소를 다운로드하세요.

[1-1] /etc/hosts 파일 구성

이 예제에서는 node1에 브라우저가 설치되어 있기 때문에 kibana.local이 Kibana 웹페이지에 접속할 수 있습니다.

# [node1]을 위한 /etc/hosts 파일(kibana.local과 logstash.local이 필요합니다)
127.0.0.1 kibana.local logstash.local
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

# [node2]를 위한 /etc/hosts 파일(여기서는 kibana.local과 logstash.local이 필요 없습니다)
192.168.0.2 node1.elastic.test.com node1
192.168.0.3 node2.elastic.test.com node2

2단계. node1의 Elasticsearch를 위한 SSL 인증서 생성과 TLS 활성화

[2-1] 환경 변수 설정(Elasticsearch가 어디서, 어떻게 다운로드되었는지에 따라 이 변수 경로를 변경해줍니다)

[root@node1 ~]# ES_HOME=/usr/share/elasticsearch
[root@node1 ~]# ES_PATH_CONF=/etc/elasticsearch

[2-2] tmp 폴더 생성

[root@node1 ~]# mkdir tmp
[root@node1 ~]# cd tmp/
[root@node1 tmp]# mkdir cert_blog

[2-3] 인스턴스 yaml 파일 생성

[root@node1 cert_blog]# vi ~/tmp/cert_blog/instance.yml
# yml 파일에 인스턴스 정보 추가
instances:
  - name: 'node1'
    dns: [ 'node1.elastic.test.com' ]
  - name: "node2"
    dns: [ 'node2.elastic.test.com' ]
  - name: 'my-kibana'
    dns: [ 'kibana.local' ]
  - name: 'logstash'
    dns: [ 'logstash.local' ]

[2-4] CA 및 서버 인증서 생성(Elasticsearch가 설치된 후)

[root@node1 tmp]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-certutil cert --keep-ca-key --pem --in ~/tmp/cert_blog/instance.yml --out ~/tmp/cert_blog/certs.zip

[2-5] 인증서 압축 해제

[root@node1 elasticsearch]# cd ~/tmp/cert_blog
[root@node1 cert_blog]# unzip certs.zip -d ./certs

[2-6] Elasticsearch TLS 설정

[2-6-1] cert 파일을 config 폴더로 복사

[root@node1 ~]# cd $ES_PATH_CONF
[root@node1 elasticsearch]# pwd
/etc/elasticsearch
[root@node1 elasticsearch]# mkdir certs
[root@node1 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca* ~/tmp/cert_blog/certs/node1/* certs
[root@node1 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 08:47 ca.crt
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 08:47 ca.key
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 08:47 node1.crt
-rw-r--r--. 1 root elasticsearch 1679 Apr 12 08:47 node1.key
[root@node1 elasticsearch]#
Read Less

[2-6-2] elasticsearch.yml 구성

[root@node1 elasticsearch]# vi elasticsearch.yml 
## 다음 콘텐츠 추가
node.name: node1
network.host: node1.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node1.key
xpack.security.http.ssl.certificate: certs/node1.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node1.key
xpack.security.transport.ssl.certificate: certs/node1.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]
cluster.initial_master_nodes: [ "node1" ]
Read Less

[2-6-3] 시작 및 클러스터 로그 확인

[root@node1 elasticsearch]# grep '\[node1\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node1] started

[2-6-4] 기본 사용자 비밀번호 설정

[root@node1 elasticsearch]# cd $ES_HOME
[root@node1 elasticsearch]# bin/elasticsearch-setup-passwords auto -u "https://node1.elastic.test.com:9200"
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N] y
Changed password for user apm_system
PASSWORD apm_system = <apm_system_password>
Changed password for user kibana
PASSWORD kibana = <kibana_password>
Changed password for user logstash_system
PASSWORD logstash_system = <logstash_system_password>
Changed password for user beats_system
PASSWORD beats_system = <beats_system_password>
Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = <remote_monitoring_user_password>
Changed password for user elastic
PASSWORD elastic = <elastic_password>
Read Less

[2-6-5] HTTPS를 통한 _cat/nodes API 연결

[root@node1 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic 'https://node1.elastic.test.com:9200/_cat/nodes?v'
Enter host password for user 'elastic':
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           16          95  10    0.76    0.59     0.38 mdi       *      node1

2~4단계에서 SSL 인증서를 생성할 때 당사에서는 --keep-ca-key 옵션을 제공했으며 이는 certs.zip 파일에 ca/ca.crt 파일뿐 아니라 ca/ca.key 파일도 포함되어 있음을 뜻합니다. Elasticsearch 클러스터에 더 많은 노드를 추가하기로 한 경우 추가 노드 인증서를 생성해야 하며 이를 위해서는 두 가지 모두의 “ca” 파일과 생성하는 데 사용한 비밀번호가 필요합니다. 이러한 ca 파일의 사본과 생성하는 데 사용한 비밀번호를 안전한 곳에 보관하십시오.

3단계. node1의 Kibana를 위한 TLS 활성화

[3-1] 환경 변수 설정

Kibana가 어디서, 어떻게 다운로드되었는지에 따라 이 변수 경로를 변경해줍니다.

[root@node1 ~]# KIBANA_HOME=/usr/share/kibana
[root@node1 ~]# KIBANA_PATH_CONFIG=/etc/kibana

[3-2] config 및 config/certs 폴더 생성과 certs 복사(Kibana가 설치된 후)

앞서 2-4단계에서 생성된 인증 파일을 복사해서 kibana/config/certs에 붙여넣기합니다.

[root@node1 kibana]# ls config/certs
total 12
ca.crt
my-kibana.crt
my-kibana.key

[3-3] kibana.yml 구성

위의 기본 사용자에 대해 생성된 비밀번호를 사용하세요. 를 2-6-4단계에서 정의된 비밀번호로 바꿔야 합니다.

[root@node1 kibana]# vi kibana.yml 
server.name: "my-kibana"
server.host: "kibana.local"
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/config/certs/my-kibana.crt
server.ssl.key: /etc/kibana/config/certs/my-kibana.key
elasticsearch.hosts: ["https://node1.elastic.test.com:9200"]
elasticsearch.username: "kibana"
elasticsearch.password: "<kibana_password>"
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/config/certs/ca.crt" ]

[3-4] Kibana 시작 및 Kibana 로그인 테스트

브라우저에서 https://kibana.local:5601/에 연결합니다. 2-6-4단계에서 정의된 elastic 사용자 및 비밀번호를 사용해 로그인합니다. 이 예제에서는 node1에 브라우저가 설치되어 있기 때문에 kibana.local이 Kibana에 접속할 수 있습니다.

공개적으로 신뢰할 수 있는 기관은 적절한 신원 소유권을 확인한 후에만 인증서가 생성되도록 하기 위해 대단히 엄격한 기준과 감사 관행을 마련하고 있습니다. 이 블로그 포스팅의 목적으로, 우리는 Kibana를 위해 자체 서명된 인증서를 생성하겠습니다(생성된 인증서가 그 자체의 개인 키를 사용해 서명되었다는 뜻입니다). 자체 서명된 Kibana 인증서를 신뢰하지 않는 고객으로 인해, 엔터프라이즈 또는 공개 CA가 생성한 인증서를 사용해 적절한 신뢰가 확립될 때까지, Kibana 로그에서 다음과 비슷한 메시지를 보시게 됩니다(다음은 Kibana 리포지토리에 있는 문제 링크입니다). 이 문제는 Kibana에서 작업할 수 있는 기능에는 영향을 미치지 않습니다.

[18:22:31.675] [error][client][connection] Error: 4443837888:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 46

4단계. node2의 Elasticsearch를 위한 TLS 활성화

[4-1] 환경 변수 설정

[root@node2 ~]# ES_HOME=/usr/share/elasticsearch
[root@node2 ~]# ES_PATH_CONF=/etc/elasticsearch

[4-2] node2의 TLS 설정

scp 명령을 이용해 node1에서 node2로 인증서를 복사할 수 있습니다. 두 노드 모두 인증서와 키가 있어야 연결에 대한 보안을 유지할 수 있습니다. 프로덕션 환경에서는, 각 노드에 대해 적절하게 서명된 키를 사용할 것을 권장합니다. 데모 목적으로, 우리는 자동 생성된 CA 인증서와 우리가 생성한 CA가 서명한 여러 DNS 호스트명 인증서를 사용하고 있습니다.

[root@node2 ~]# cd $ES_PATH_CONF
[root@node2 elasticsearch]# pwd
/etc/elasticsearch
[root@node2 elasticsearch]# mkdir certs
[root@node2 elasticsearch]# cp ~/tmp/cert_blog/certs/ca/ca.crt ~/tmp/cert_blog/certs/node2/* certs  
[root@node2 elasticsearch]# 
[root@node2 elasticsearch]# ll certs
total 12
-rw-r--r--. 1 root elasticsearch 1834 Apr 12 10:55 ca.crt
-rw-r--r--. 1 root elasticsearch 1509 Apr 12 10:55 node2.crt
-rw-r--r--. 1 root elasticsearch 1675 Apr 12 10:55 node2.key

[4-3] elasticsearch.yml 구성

[root@node2 elasticsearch]# vi elasticsearch.yml 
node.name: node2
network.host: node2.elastic.test.com
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.key: certs/node2.key
xpack.security.http.ssl.certificate: certs/node2.crt
xpack.security.http.ssl.certificate_authorities: certs/ca.crt
xpack.security.transport.ssl.key: certs/node2.key
xpack.security.transport.ssl.certificate: certs/node2.crt
xpack.security.transport.ssl.certificate_authorities: certs/ca.crt
discovery.seed_hosts: [ "node1.elastic.test.com" ]
Read Less

[4-4] 시작 및 클러스터 로그 확인

[root@node2 elasticsearch]# grep '\[node2\] started' /var/log/elasticsearch/elasticsearch.log 
[o.e.n.Node               ] [node2] started

[4-5] HTTPS를 통한 _cat/nodes API 연결

[root@node2 elasticsearch]# curl --cacert ~/tmp/cert_blog/certs/ca/ca.crt -u elastic:<password set previously> 'https://node2.elastic.test.com:9200/_cat/nodes?v'
ip          heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.0.2           25          80   5    0.18    0.14     0.30 mdi       *      node1
192.168.0.3           14          96  44    0.57    0.47     0.25 mdi       -      node2

5단계. node1의 Logstash 사용자 준비

[5-1] logstash_write_role 생성

여러 방법으로 역할을 생성할 수 있습니다.

다음과 같이 Kibana 역할 UI를 사용해 생성할 수 있습니다.

또는 다음과 같이 Kibana 개발자 도구 탭에서 API를 사용하여 사용자를 생성하세요.

POST /_security/role/logstash_write_role
{
    "cluster": [
      "monitor",
      "manage_index_templates"
    ],
    "indices": [
      {
        "names": [
          "logstash*"
        ],
        "privileges": [
          "write",
          "create_index"
        ],
        "field_security": {
          "grant": [
            "*"
          ]
        }
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
}

그러면 다음과 같은 응답을 받게 됩니다.

{"role":{"created":true}}

이 역할을 배정받은 사용자는 어떤 문서도 삭제할 수 없습니다. 이 역할은 사용자가 logstash를 시작하는 경우에만 인덱스를 생성할 수 있도록 제한하며, 또는 그러한 인덱스의 문서들만 색인하도록 제한합니다.

ILM 사용자를 위한 참고 사항: logstash_writer_role이 index lifecycle management (ILM)을 사용하려면(7.3 이상부터 기본적으로 지원) 다음 권한이 포함되어 있어야 합니다.

"privileges": ["write","create","delete","create_index","manage","manage_ilm"]

[5-2] logstash_writer 사용자 생성(logstash_writer 사용자에 대한 비밀번호를 변경하세요)

여러 방법으로 사용자를 생성할 수 있습니다.

다음과 같이 Kibana 사용자 UI를 사용해 생성할 수 있습니다.

또는 다음과 같이 Kibana 개발자 도구 탭에서 API를 사용하여 사용자를 생성하세요.

POST /_security/user/logstash_writer
{
  "username": "logstash_writer",
  "roles": [
    "logstash_write_role"
  ],
  "full_name": null,
  "email": null,
  "password": "<logstash_system_password>",
  "enabled": true
}

그러면 다음과 같은 응답을 받게 됩니다.

{"user":{"created":true}}

6단계. node1의 Logstash를 위한 TLS 활성화

[6-1] 폴더 생성 및 인증서 복사

[root@node1 logstash]# ls -l
total 24
ca.crt
logstash.crt
logstash.key

[6-2] Beats 입력 플러그인을 위해 logstash.key를 PKCS#8 형식으로 변환

[root@node1 logstash]# openssl pkcs8 -in config/certs/logstash.key -topk8 -nocrypt -out config/certs/logstash.pkcs8.key

[6-3] logstash.yml 구성

logstash_system 사용자를 위해 자동 생성된 비밀번호를 사용하세요. 2-6-4단계에서 정의된 비밀번호를 사용하세요.

[root@node1 logstash]# vi logstash.yml

그리고 나서, 다음과 같이 편집하세요.

node.name: logstash.local
path.config: /etc/logstash/conf.d/*.conf
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.username: logstash_system
xpack.monitoring.elasticsearch.password: '<logstash_system_password>'
xpack.monitoring.elasticsearch.hosts: [ 'https://node1.elastic.test.com:9200' ]
xpack.monitoring.elasticsearch.ssl.certificate_authority: /etc/logstash/config/certs/ca.crt

[6-4] conf.d/example.conf 생성 및 구성

Elasticsearch 출력에서,5-2단계에서 정의된 비밀번호를 사용하세요.

[root@node1 logstash]# vi conf.d/example.conf 
input {
  beats {
    port => 5044
    ssl => true
    ssl_key => '/etc/logstash/config/certs/logstash.pkcs8.key'
    ssl_certificate => '/etc/logstash/config/certs/logstash.crt'
  }
}
output {
  elasticsearch {
    hosts => ["https://node1.elastic.test.com:9200","https://node2.elastic.test.com:9200"]
    cacert => '/etc/logstash/config/certs/ca.crt'
    user => 'logstash_writer'
    password => <logstash_writer_password>
  }
}

[6-5] 예제 구성으로 Logstash 시작 및 Logstash 로그 확인

다음 로그 메시지를 볼 수 있어야 합니다.

[INFO ][logstash.pipeline        ] Pipeline started successfully {:pipeline_id=>".monitoring-logstash", :thread=>"#<Thread:0x640c14d2@/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:246 run

그리고 Kibana Monitoring 탭에서, Logstash가 표시됩니다(노드 정보, 파이프라인 설정, OS 정보, JVM 정보, 처리 통계, 파이프라인 런타임 통계).

7단계. Filebeat 실행 및 node1의 TLS 설정

[7-1] 구성 폴더 생성 및 인증서 복사

[root@node1 filebeat]# mkdir config
[root@node1 filebeat]# mkdir config/certs
[root@node1 filebeat]# cp ~/tmp/cert_blog/certs/ca/ca.crt config/certs
[root@node1 filebeat]# ll config/certs/
total 4
-rw-r--r--. 1 root root 1834 Apr 20 00:18 ca.crt

[7-2] 새로운 filebeat.yml 생성

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mv filebeat.yml filebeat.yml.old

[7-3] 새 구성 파일 filebeat.yml 편집

filebeat.inputs:
- type: log
  paths:
    - /etc/filebeat/logstash-tutorial-dataset
output.logstash:
  hosts: ["logstash.local:5044"]
  ssl.certificate_authorities:
    - /etc/filebeat/config/certs/ca.crt

8단계. Filebeat를 이용한 데이터 수집

[8-1] Filebeat를 위한 입력 로그 데이터 준비(logstash-tutorial.log)

먼저, 입력 로그 데이터를 다운로드합니다.

[root@node1 filebeat]# pwd
/etc/filebeat
[root@node1 filebeat]# mkdir logstash-tutorial-dataset
[root@node1 filebeat]# cp /root/logstash-tutorial.log logstash-tutorial-dataset/.
[root@node1 filebeat]# ll logstash-tutorial-dataset/
total 24
-rwxr-x---. 1 root root 24464 Apr 20 00:29 logstash-tutorial.log

[8-2] Filebeat 시작

[root@node1 filebeat]# systemctl start filebeat
[root@node1 filebeat]# systemctl enable filebeat
Created symlink from /etc/systemd/system/multi-user.target.wants/filebeat.service to /usr/lib/systemd/system/filebeat.service.

[8-3] 로그 확인

다음 로그 메시지를 볼 수 있어야 합니다.

INFO    log/harvester.go:216    Harvester started for file: /etc/filebeat/logstash-tutorial-dataset/logstash-tutorial.log

[8-4] 인덱스 패턴 생성

다음으로, 수집되고 있는 데이터와 일치하는 인덱스 패턴을 생성합니다. Graph나 Discover와 같이, 이것은 Kibana에서 데이터를 시각화할 수 있게 해줍니다.

그리고 나서 시간 필터 파일 이름을 선택합니다. 우리 예제에서는 @timestamp입니다.

다 됐습니다! Elastic Stack의 다른 부분 간의 통신을 암호화했으며, 이제 로그 데이터를 안전하고 보안이 유지된 상태에서 수집하고 있습니다.

끝으로 몇 가지...

보안을 구성하는 동안 문제에 직면하면, 제일 먼저 설명서의 보안 문제해결 안내를 찾아보실 것을 권합니다. 수많은 일반적인 문제에 도움이 될 것입니다. 그 후에도 여전히 질문이 있으시면, 저희 Elastic 포럼을 확인하셔서 추가 도움을 받으세요. 또는 Elastic 지원팀과 직접 얘기하고 싶으시면, 오늘 Elastic 구독을 시작하시고 전문가팀을 직접 이용하세요. 안전 조심하세요!

2019.05.19 - 고급 튜닝: 느린 Elasticsearch 쿼리를 찾아 문제 해결

drscg — Fri, 25 Sep 2020 14:27:36 +0900

Elasticsearch는 매우 유연하고 기능이 풍부한 애플리케이션으로, 데이터를 쿼리하는 다양한 방법을 제공합니다. 그러나 기대했던 것보다 느린 속도의 쿼리를 경험해 본 적이 있으신가요? Elasticsearch와 같은 분산 시스템에는 로드 밸런서 설정, 네트워크 지연 시간(대역폭, NIC 카드/드라이버) 등과 같은 외부 요인을 비롯하여 쿼리 성능에 영향을 미치는 다양한 요소가 있을 수 있습니다.

이 블로그에서는 쿼리 속도 저하의 원인과 Elasticsearch의 컨텍스트 내에서 이를 식별하는 방법에 대해 설명합니다. 또한 Elasticsearch 작동 방식에 상당히 익숙해야 사용할 수 있는 몇 가지 일반적인 문제 해결 방법을 다룹니다.

Elasticsearch 쿼리 속도 저하의 일반적인 원인

몇 가지 까다로운 사례를 살펴보기 전에 먼저 쿼리 속도 저하의 가장 일반적인 원인과 그 해결 방법부터 알아보겠습니다.

증상: 비활성 상태에서 높은 리소스 사용률

모든 샤드는 리소스(CPU/메모리)를 소비합니다. 색인/검색 요청이 없는 경우에도 샤드가 있으면 클러스터 오버헤드가 소비됩니다.

문제

모든 쿼리의 실행 속도가 느리게 느껴질 정도로 클러스터에 샤드가 너무 많습니다. 경험상으로 보면 노드당 비 고정 샤드 수는 구성된 힙 GB당 20개 미만으로 유지하는 것이 좋습니다.

해결 방법

샤드 수를 줄이고, 인덱스를 고정하거나, 로드를 처리할 노드를 추가합니다. 샤드 수를 효율적으로 관리하기 위해 Elasticsearch의 롤오버/축소 기능과 함께 핫/웜 아키텍처(시간 기반 인덱스에 매우 적합)를 고려합니다. 배포할 때 먼저 적절한 용량 계획을 수립하면 각 검색 사용 사례에 맞는 최적의 샤드 수를 결정하는 데 도움이 됩니다.

증상: 스레드 풀이 거부된 횟수 증가

검색 스레드 풀이 ‘거부된’ 횟수가 계속 증가합니다. 이 횟수는 마지막 클러스터 재시작을 기준으로 누적됩니다.

GET /_cat/thread_pool/search?v&h=node_name,name,active,rejected,completed

응답은 다음과 같습니다.

node_name             name   active rejected completed
instance-0000000001   search      0       10         0
instance-0000000002   search      0       20         0
instance-0000000003   search      0       30         0

문제

쿼리가 클러스터의 코어 수를 초과하여 너무 많은 샤드를 대상으로 합니다. 그러면 검색 스레드 풀에 대기 중인 작업이 생성되어 검색 거부로 이어집니다. 또 다른 일반적인 원인은 느린 디스크 I/O로 인해 검색이 대기열에 오르게 되거나 경우에 따라 CPU가 완전히 포화 상태가 됩니다.

해결 방법

인덱스를 생성할 때 기본 1 : 복제본 1 모델을 채택합니다. 인덱스 템플릿은 인덱스 시간에 이 설정을 롤아웃하는 좋은 방법입니다. (Elasticsearch 7.0 이상에서는 1P:1R이 기본값입니다). Elasticsearch 5.1 이상에서는 검색 작업 취소 기능을 지원합니다. 이 기능은 작업 관리 API에 느린 쿼리가 표시될 때 유용합니다. 디스크 I/O를 개선하려면 스토리지 권장 사항을 확인하고 최대 성능을 위해 권장 하드웨어를 사용해야 합니다.

증상: 높은 CPU 사용률 및 긴 색인 지연 시간

메트릭 상관관계는 클러스터에 과부하가 발생할 때 CPU 사용률이 높고 색인 지연 시간이 길다는 것을 보여줍니다.

문제

클러스터에 색인 작업이 많으면 검색 성능에 영향을 미칩니다.

해결 방법

index.refresh_interval(문서가 색인되는 시점과 문서가 표시되는 시점 사이의 시간)을 예를 들어 30초로 늘리면 일반적으로 색인 성능이 향상됩니다. 실제 적합한 간격은 상황에 따라 다를 수 있으므로 테스트가 중요합니다. 이렇게 하면 1초마다(기본값) 새 세그먼트를 생성하여 샤드가 작업을 과도하게 수행하지 않아도 됩니다.

색인 작업이 많은 사용 사례의 경우 인덱스 튜닝 권장 사항을 확인하여 인덱스와 검색 성능을 모두 최적화합니다.

증상: 더 많은 복제본 샤드로 지연 시간 증가

복제본 샤드 수를 늘리면(예: 1개에서 2개로) 쿼리 지연 시간이 발생할 수 있습니다. 더 많은 데이터가 있는 경우 캐시된 데이터가 더 빨리 제거되어 운영 체제 페이지 오류가 증가합니다.

문제

파일 시스템 캐시에는 인덱스 중 자주 쿼리되는 부분을 캐시하기에 충분한 메모리가 없습니다. Elasticsearch의 쿼리 캐시는 LRU 제거 정책을 구현합니다. 즉, 캐시가 가득 차면 가장 최근에 사용되지 않은 데이터가 제거되어 새 데이터를 저장할 수 있게 됩니다.

해결 방법

파일 시스템 캐시용으로 물리적 RAM의 50% 이상을 남겨둡니다. 메모리가 많을수록 더 많은 부분을 캐시할 수 있으며 특히 클러스터에 I/O 문제가 발생할 경우 유용합니다. 힙 크기가 적절하게 구성되었다고 가정할 때 파일 시스템 캐시에 사용할 수 있는 나머지 물리적 RAM은 검색 성능을 향상하는 데 큰 도움이 됩니다.

예를 들어, 128GB RAM 서버에서 힙 크기로 30GB를 설정하고 나머지 메모리를 파일 시스템 캐시(OS 캐시라고도 함)용으로 설정합니다. 이 방법은 운영 체제가 최근에 액세스한 4KB 블록의 데이터를 캐시하는 방식입니다. 따라서 동일한 파일을 반복해서 읽으면 대부분의 경우 디스크로 이동할 필요 없이 메모리에서 직접 읽기 요청을 처리합니다.

Elasticsearch는 파일 시스템 캐시 외에도 쿼리 캐시와 요청 캐시 를 사용하여 검색 속도를 높입니다. 이러한 캐시는 모두 특정 검색 요청을 서로 다른 복사본에 번갈아 보내는 대신 매번 동일한 샤드 집합으로 라우팅하도록 검색 요청 기본 설정을 사용하여 최적화할 수 있습니다. 이렇게 하면 요청 캐시, 노드 쿼리 캐시 및 파일 시스템 캐시를 더 잘 활용할 수 있습니다.

증상: 리소스 공유 시 사용률 증가

운영 체제에 일관되게 높은 CPU 및 디스크 I/O 사용량이 표시됩니다. 타사 애플리케이션을 중지하면 성능이 향상되는 것을 확인할 수 있습니다.

문제

다른 프로세스(예: Logstash)와 Elasticsearch 자체 간에 리소스(CPU 및/또는 디스크 I/O) 경합이 있습니다.

해결 방법

공유 하드웨어에서 Elasticsearch를 리소스 집약적인 다른 애플리케이션과 함께 실행하지 않도록 합니다.

증상: 매우 고유한 필드를 집계할 때 힙 사용량 증가

매우 고유한 값(예: ID, 사용자 이름, 이메일 주소 등)이 포함된 집계된 필드를 쿼리할 때 성능이 저하됩니다. 힙 덤프 분석 중에 "search", "buckets", "aggregation" 등의 용어가 포함된 Java 객체가 힙을 많이 사용하는 것을 볼 수 있습니다.

문제

카디널리티가 높은 필드, 즉 많은 버킷을 가져오기 위해 많은 리소스가 필요한 필드에서 집계 작업이 실행되고 있습니다. 중첩 필드 및/또는 조인 필드를 포함하는 중첩 집계가 있을 수도 있습니다.

해결 방법

카디널리티가 높은 용어 집계의 성능을 향상하려면 컨설팅 팀 동료가 작성한 이 블로그 게시물(https://www.elastic.co/kr/blog/improving-the-performance-of-high-cardinality-terms-aggregations-in-elasticsearch)을 읽어보시기 바랍니다.

추가적인 튜닝 작업을 하려면 중첩 필드와 조인 필드에 대한 권장 사항을 확인하여 집계 성능을 개선하시기 바랍니다.

가끔 느린 쿼리

일반적으로 말해서 가끔 또는 간헐적으로 느린 쿼리에는 인덱스 튜닝/검색 튜닝 권장 사항 중 일부를 활용할 수 있습니다. 가끔 느린 쿼리는 다음 모니터링 메트릭 중 하나 이상과 밀접하게 연관되어 있습니다.

CPU 로드
색인 처리량
검색 처리량
가비지 수집(GC) 활동
검색 스레드 풀 대기열 크기

Elasticsearch에는 조율 노드가 데이터 노드의 로드를 인식하고 검색을 실행할 수 있는 최상의 샤드 복사본을 선택하도록 하여 검색 처리량과 지연 시간을 개선하는 또 다른 유용한 기능인 ARS(Adaptive Replica Selection)가 있습니다. ARS는 쿼리 시간 동안 로드를 더욱 고르게 분산시킴으로써 가끔 발생하는 속도 저하를 개선하는 데 큰 도움이 될 수 있습니다. Elasticsearch 7.0 이상에서는 ARS가 기본적으로 켜져 있습니다.

일관되게 느린 쿼리

일관되게 느린 쿼리의 경우 쿼리에서 기능을 하나씩 제거하면서 쿼리가 여전히 느린지 여부를 확인하면 됩니다. 성능 문제를 재현하는 가장 간단한 쿼리를 찾으면 문제를 분리하고 식별하는 데 도움이 됩니다.

강조 표시가 없어도 여전히 느린가요?
집계가 없어도 여전히 느린가요?
크기가 0으로 설정되어 있어도 여전히 느린가요? (크기가 0으로 설정되면 Elasticsearch에서 검색 요청 결과를 캐시하여 검색 속도를 높임)

‘검색 튜닝’ 권장 사항 몇 가지를 적용하면 도움이 될까요?

문제를 해결할 때는 다음과 같은 방법이 유용할 때가 많습니다.

프로필이 켜진 상태에서 쿼리 응답을 가져옵니다.
While(true) 루프에서 실행 중인 쿼리로 노드 핫 스레드 출력을 수집합니다. 이는 CPU 시간이 어디에 사용되는지 이해하는 데 도움이 됩니다.
프로필 API의 이 사용자 친화적인 버전을 사용하여 쿼리를 프로파일링합니다.

쿼리가 Kibana 시각화에서 수신된 경우 Visualization Spy Panel(Kibana 버전 6.3 이하) 또는 Dashboard Inspect Panel(Kibana 버전 6.4 이상)을 사용하여 실제 쿼리 요청을 보고 내보낸 후 추가 분석을 위해 프로파일 API로 가져오십시오.

느리거나 비싼 쿼리 포착

Elasticsearch와 같은 분산 애플리케이션에서는 다양한 요청/스레드가 동시에 처리되므로 느리거나 비싼 쿼리를 포착하기가 어려울 수 있습니다. 클러스터 성능을 저하하거나(예: 긴 가비지 수집(GC) 주기) 더 안 좋게는 OOM(메모리 부족) 상황을 유발하는 비싼 쿼리를 실행하는 사용자를 제어할 수 없을 경우 상황은 더욱 복잡해집니다.

Elasticsearch 버전 7.0에는 메모리가 예약될 때 실제 힙 메모리 사용량을 측정하는 새로운 회로 차단 전략이 도입되었습니다. 이 새로운 전략은 클러스터 과부하를 유발하는 비싼 쿼리에 대한 노드 복원력을 개선하고, 기본적으로 켜져 있으며, 새로운 클러스터 설정인 indices.breaker.total.use_real_memory로 제어할 수 있습니다.

그러나 이러한 방법은 최선의 노력임을 유념해야 합니다. 여기에서 다루지 않은 시나리오의 경우 OOM 크래시 후 힙 덤프 또는 실행 중인 JVM에서 힙 덤프를 수집하여 근본 원인을 보다 잘 이해하는 것이 좋습니다.

Elasticsearch에는 클러스터를 OOM으로부터 보호하기 위한 또 다른 보호 설정(최대 버킷 소프트 한도)이 있습니다. 이 최대 버킷 집계 설정은 예를 들어 여러 집계 계층을 실행하느라 버킷 수(버전 7.0에서 기본값은 10,000개)가 초과되면 실행을 중지하고 검색 요청을 실패로 처리합니다.

잠재적인 고가의 쿼리를 추가로 식별하기 위해 낮은 임계값에서 시작하여 쿼리를 분리하고 임계값을 점차 높여 특정 쿼리로 범위를 좁혀갈 수 있도록 회로 차단 설정(indices.breaker.request.limit)을 구성할 수 있습니다.

느린 로그

Elasticsearch에서 느린 로그를 켜서 실행 속도가 느린 쿼리를 식별할 수도 있습니다. 느린 로그는 구체적으로 샤드 수준에서만 작동하며, 이는 데이터 노드만 적용됨을 의미합니다. 조율 전용/클라이언트 노드는 데이터(인덱스/샤드)를 보유하지 않으므로 제외됩니다.

느린 로그는 다음과 같은 질문에 대답하는 데 도움이 됩니다.

쿼리 작업에 시간이 얼마나 걸렸나요?
쿼리 요청 본문의 내용은 무엇인가요?

느린 로그 출력 샘플:

[2019-02-11T16:47:39,882][TRACE][index.search.slowlog.query] [2g1yKIZ] [logstash-20190211][4] took[10.4s], took_millis[10459], total_hits[16160], types[], stats[], 
search_type[QUERY_THEN_FETCH], total_shards[10], source[{"size":0,"query":{"bool":{"must":[{"range":{"timestamp":{"from":1549266459837,"to":1549871259837,"include_lower":true,
"include_upper":true,"format":"epoch_millis","boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},"_source":{"includes":[],"excludes":[]},"stored_fields":"*","docvalue_fields":
[{"field":"timestamp","format":"date_time"},{"field":"utc_time","format":"date_time"}],"script_fields":{"hour_of_day":{"script":{"source":"doc['timestamp'].value.getHourOfDay()",
"lang":"painless"},"ignore_failure":false}},"aggregations":{"maxAgg":{"max":{"field":"bytes"}},"minAgg":{"min":{"field":"bytes"}}}}], id[]],
Read Less

느린 로그 메시지 세부 항목:

항목	설명
`[2019-02-11T16:47:39,882]`	쿼리 날짜
`[TRACE]`	로그 수준
`[index.search.slowlog.query]`	검색 느린 로그의 쿼리 단계
`[2g1yKIZ]`	노드 이름
`[logstash-20190211]`	인덱스 이름
`[4]`	실행된 쿼리의 샤드 번호
`took[10.4s]`	샤드 처리에 걸린 시간[4]. 참고: 느린 로그를 살펴볼 때, 각 샤드가 병렬로 실행될 수 있기 때문에 서로 다른 샤드의 시간을 모두 추가하지 않는 것이 좋습니다.
`took_millis[10459]`	소요 시간(밀리초)
`total_hits[16160]`	적중 결과 합계
`search_type[QUERY_THEN_FETCH]`	검색 유형
`total_shards[10]`	인덱스의 샤드 합계
`source[]`	실행된 쿼리 본문

감사 로그

Elastic 보안 기능이 포함된 골드 또는 플래티넘 구독 고객은 감사 로그를 켜서 쿼리에 대한 자세한 내용을 캡처할 수 있습니다. (사용자는 30일 체험판을 통해 Elastic 보안 기능을 테스트할 수 있습니다.) 감사 로깅은 다음과 같은 질문에 대답하는 데 도움이 됩니다.

쿼리는 언제 발생했나요?
누가 쿼리를 실행했나요?
쿼리 내용은 무엇인가요?

기본 설정은 부족한 부분이 많으므로 이를 튜닝해야 합니다.

보안 감사 로그 활성화: elasticsearch.yml에 xpack.security.audit.enabled: true 설정.
보안 감사 출력에서 로그 또는 인덱스 활성화: elasticsearch.yml에 xpack.security.audit.outputs:[logfile, index] 설정.

참고:
- xpack.security.audit.outputs 설정은 버전 6.0, 6.2 및 5.x에만 적용됩니다. xpack.security.audit.enabled가 true로 설정되면 버전 7.0에서는 이 설정을 허용하지 않으며 json 출력을 기본값(<clustername>_audit.json)으로 사용합니다.
- 감사 로깅의 세부 정보로 인해 보안 인덱스가 의도한 크기보다 커질 경우 클러스터 성능에 부담을 줄 수 있으므로 문제 해결을 위해서는 인덱스보다 로그 파일을 선택하는 것이 좋습니다.
- 감사 모드에서는 매우 자세한 정보가 표시될 수 있으므로 문제가 해결되면 끄십시오.
이벤트 목록에 authentication_success 액세스를 포함하십시오. elasticsearch.yml에 xpack.security.audit.logfile.events.include: authentication_success 설정.

참고:
- 이 설정은 기본 이벤트에 포함되지 않습니다. 이를 설정하면 기본 설정을 덮어씁니다.
- 하나 이상의 이벤트를 추가해야 하는 경우(대체가 아니라), 기존 기본 이벤트 목록을 먼저 작성한 후 마지막 항목 뒤에 위 설정을 추가하십시오.
- 감사 이벤트의 요청 본문 출력: elasticsearch.yml에 xpack.security.audit.logfile.events.emit_request_body: true 설정.

이 설정을 사용하면 다음과 같은 사용자 쿼리를 모니터링할 수 있습니다.

사용자: louisong
쿼리 작업 시간: 2019-05-01T19:26:53,554 (UTC)
쿼리 엔드포인트: _msearch(이는 일반적으로 Kibana 시각화/대시보드에서 발행된 쿼리를 의미함)

쿼리 본문: 다음 로그에서 "request.body":로 시작되는 부분:

{"@timestamp":"2019-05-01T19:26:53,554", "node.id":"Z1z_64sIRcy4dW2eqyqzMw", "event.type":"rest", "event.action":"authentication_success", "user.name":"louisong", "origin.type":"rest", "origin.address":"127.0.0.1:51426", "realm":"default_native", "url.path":"/_msearch", "url.query":"rest_total_hits_as_int=true&ignore_throttled=true", "request.method":"POST", "request.body":"{\"index\":\"*\",\"ignore_unavailable\":true,\"preference\":1556709820160}\n{\"aggs\":{\"2\":{\"terms\":{\"field\":\"actions\",\"size\":5,\"order\":{\"_count\":\"desc\"},\"missing\":\"__missing__\"}}},\"size\":0,\"_source\":{\"excludes\":[]},\"stored_fields\":[\"*\"],\"script_fields\":{},\"docvalue_fields\":[{\"field\":\"access_token.user_token.expiration_time\",\"format\":\"date_time\"},{\"field\":\"canvas-workpad.@created\",\"format\":\"date_time\"},{\"field\":\"canvas-workpad.@timestamp\",\"format\":\"date_time\"},{\"field\":\"creation_time\",\"format\":\"date_time\"},{\"field\":\"expiration_time\",\"format\":\"date_time\"},{\"field\":\"maps-telemetry.timeCaptured\",\"format\":\"date_time\"},{\"field\":\"task.runAt\",\"format\":\"date_time\"},{\"field\":\"task.scheduledAt\",\"format\":\"date_time\"},{\"field\":\"updated_at\",\"format\":\"date_time\"},{\"field\":\"url.accessDate\",\"format\":\"date_time\"},{\"field\":\"url.createDate\",\"format\":\"date_time\"}],\"query\":{\"bool\":{\"must\":[{\"range\":{\"canvas-workpad.@timestamp\":{\"format\":\"strict_date_optional_time\",\"gte\":\"2019-05-01T11:11:53.498Z\",\"lte\":\"2019-05-01T11:26:53.498Z\"}}}],\"filter\":[{\"match_all\":{}},{\"match_all\":{}}],\"should\":[],\"must_not\":[]}},\"timeout\":\"30000ms\"}\n", "request.id":"qrktsPxyST2nVh29GG7tog"}
    Read Less

결론

이 블로그에서는 쿼리 속도 저하의 일반적인 원인과 이를 해결하는 방법에 대해 설명했습니다. 또한 일관되게 느린 쿼리와 가끔 느린 쿼리를 식별하기 위한 다양한 방법에 대해서도 논의했습니다. 일반적으로 쿼리 속도 저하는 해결해야 하는 광범위한 클러스터 성능 문제의 증상 중 하나입니다.

Elasticsearch에서는 쿼리 시간을 개선하기 위해 끊임없이 노력하고 있으며 향후 릴리즈 버전에서 더 빠른 쿼리 성능을 제공하기 위한 작업을 진행 중입니다. 느린 쿼리를 처리할 때 이 게시물이 도움이 되길 바랍니다. 추가로 논의하고자 하는 내용이 있다면 Elasticsearch 토론 포럼에 문의를 남겨주십시오. 즐거운 검색 되세요!

2020 직업능력개발훈련교사 자료

drscg — Tue, 15 Sep 2020 10:34:05 +0900

# 성취도 평가 준비

교재의 충분한 정독: 교재 구석 구석에서 출제가 됩니다.
Mind Map(아래 link에서 다운) 암기: 교수님들의 강조 point

상식적으로 풀 수 있는 문제는 실습장 안전관리에 출제되는 문제 정도입니다.
online에 quiz로 나오는 문제, 기타에 나오는 문제들은 종합평가에 거의 나오지 않습니다.
이 문제들은 정리 정도로만 생각하셔야 합니다.
online에 quiz로 나오는 문제들처럼 단순한 문제는 몇 개정도만 출제됩니다.
사람 이름 등에서 외국어인 경우, 영문으로 나오는 경우가 있습니다. ex) 낙인효과 - stigma effect
거의 대부분의 문제가 약간의 생각을 필요로 하니, 문제를 끝까지 신중하게 읽어봐야 합니다.
하루에 4번(오전: 2번, 오후: 2번), 인원을 나누어서 보았습니다.
오전 2번은 서로 문제가 비슷한 내용으로 출제가 되는 것으로 보입니다. 오후와는 차이가 있습니다.

# 아래는 강의 들으면서 입수한 정보와 제가 정리한 내용을 모아둔 것입니다.

https://github.com/sharejob2020/VocationalTrainingTeacher

redis 4부 - jedis를 이용한 client sample ...

drscg — Mon, 8 Apr 2019 14:01:36 +0900

이제 마지막이다.
redis server를 다 설치했으니, 그곳에 data를 write하고 또 read해 보자.
Java를 이용해, 간단한 sample을 만들어 보겠다.

가장 많이 쓰이는 redis java library는 jedis 라고 한다.
글을 쓰고 있는 시점에서 가장 최신 버전인 3.0.1 을 첨부한다.
또한, 관련 library인 Common Pool 2 library를 첨부한다.
그리고, 입력한 data를 확인하기 위한, RedisDesktopManager for Windows를 첨부한다.

jedis의 Java document는 http://xetorthio.github.io/jedis/에서 볼수 있다.

우리는 Sentinel을 이용한 replication을 사용하여, redis cluster를 구성하였다.
그리고, Redis는 Master에만 data를 write할 수 있다고 언급한 바 있다.
Sentinel은 Master가 down되면, Slave 중의 하나를 Master로 선발한다.

따라서, 우리는 redis cluster의 어느 것이 Master인지 알지 못한다.
왜냐하면, redis master가 down되어, 다른 slave가 master가 되어 있을 가능성이 있기 때문이다.
그렇다면 어디에서 알 수 있을까? 그렇다. Sentinel이다.

redis의 ip나 port를 알 필요가 없다. Sentinel의 ip, port만 알고 있으면 된다.
간단하게 shadow code를 작성해 보면 아래와 같다.

1. Sentinel의 ip/port를 이용하여, JedisSentinelPool 을 구성한다.
2. Master Redis 객체를 얻어온다 ( JedisSentinelPool.getResource() )
3. redis에 입/출력한다.
4. JedisSentinelPool 을 제거한다.

real code는 다음과 같다.

import java.net.Socket;
import java.util.HashSet;

import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
import redis.clients.jedis.exceptions.JedisException;

public class Redis
{
	private	static	final	String	MASTER_NAME	= "drscg.master";
	public	static	final	String	PASSWORD	= "passw0rd";
	public	static	final	int		DATABASE	= 0;

	public static void main( String[] args )
	{
		HashSet&ltString&gt			oHashSetSetSentinel			= null;
		GenericObjectPoolConfig	oGenericObjectPoolConfig	= null;
		JedisSentinelPool		oJedisSentinelPool			= null;
		Jedis					oJedis						= null;
		Socket					oSocket						= null;
		String					strValue					= "";

		// Sentinel의 ip와 port setting
		oHashSetSetSentinel = new HashSet&ltString&gt();
		oHashSetSetSentinel.add("10.0.0.1:17000");
		oHashSetSetSentinel.add("10.0.0.2:17000");
		oHashSetSetSentinel.add("10.0.0.4:17000");

		// Sentinel Pool에 연결한다.
		oGenericObjectPoolConfig = new GenericObjectPoolConfig();
		oJedisSentinelPool = new JedisSentinelPool(MASTER_NAME, oHashSetSetSentinel,
									oGenericObjectPoolConfig, 1000, PASSWORD, DATABASE);

		// set
		for ( int i = 0; i &lt 100; i++ )
		{
			try
			{
				// pool에서 jedis master를 가져온다.
				oJedis = oJedisSentinelPool.getResource();
				
				// master가 어떤 server인지 확인하기 위한 code
				oSocket = oJedis.getClient().getSocket();
				System.out.println("Connected to " + oSocket.getRemoteSocketAddress());
				
				// set
				oJedis.set("foo_" + i, "bar_" + i);
				System.out.println("set foo_" + i);
			}
			catch ( JedisException ex)
			{
				ex.printStackTrace();
				break;
			}
			finally
			{
				// jedis 객체 반환
				oJedis.close();
			}
			
		}
		
		// get
		for ( int i = 0; i &lt 100; i++ )
		{
			try
			{
				// pool에서 jedis master를 가져온다.
				oJedis = oJedisSentinelPool.getResource();
				
				// master가 어떤 server인지 확인하기 위한 code
				oSocket = oJedis.getClient().getSocket();
				System.out.println("Connected to " + oSocket.getRemoteSocketAddress());
				
				// get
				strValue = oJedis.get("foo_" + i);
				System.out.println("get foo_" + i + ": [" + strValue + "]");
			}
			catch ( JedisException ex)
			{
				ex.printStackTrace();
				break;
			}
			finally
			{
				// jedis 객체 반환
				oJedis.close();
			}
			
		}
		
		// Sentinel Pool 반환
		oJedisSentinelPool.destroy();
	}
}

commons-pool2-2.4.3.zip

0.12MB

jedis-3.0.1.zip

0.56MB

redis-desktop-manager-0.9.3.817.z01

5.00MB

redis-desktop-manager-0.9.3.817.z02

5.00MB

redis-desktop-manager-0.9.3.817.zip

0.59MB

redis 3부 - Warning 제거 ...

drscg — Mon, 8 Apr 2019 11:22:29 +0900

centos에서 redis를 설치하고, 실행을 하면, log 파일에서 다음과 같은 WARNING이 나타나는 경우가 있다.
이를 제거해 보자.

# WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
# WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

1. TCP backlog 경고

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

기본적인 소켓 accept limit 값이다. 보통 리눅스 배포판에는 128로 되어있고 이 때문에 tcp backlog 의 셋팅이 511 로 되어있지만 강제로 128로 적용 된다는 뜻이다.
아래의 명령어로 1024 혹은 더욱 높은 값으로 설정해 준다. ( 최고는 65535 )

# sysctl -w net.core.somaxconn=1024
# echo "net.core.somaxconn=1024" >> /etc/sysctl.conf

확인 : sysctl -a | grep somaxconn

2. overcommit_memory 경고

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

메모리 이용에 관한 설정이다. 메모리 이용이 허용량보다 넘어 가게 될 경우 처리 방법이다.
해결 방법은 아래의 명령어로 가능하다.

# sudo sysctl vm.overcommit_memory=1
# echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

확인 : sysctl -a | grep vm.overcommit_memory

관련 내용 : https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

3. THP 경고

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

THP 기능이 Enable되어 있어 발생하는 warning이다.
THP는 redis에서 문제가 발생할 수 있기 때문에 disable한다.
그리고 재 부팅시 재설정을 변경하기 위해 /etc/rc.local 에 아래 명령어를 넣어 주도록 한다.

# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# vi /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

확인 : cat /proc/meminfo | grep AnonHugePages
AnonHugePages 가 0 이면 정상

THP 관련 내용 : https://access.redhat.com/site/documentation/ko-KR/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory

4부에서는 java library인 jedis를 이용하는 방법을 알아보자.

redis 2부 - replication ...

drscg — Mon, 8 Apr 2019 11:20:19 +0900

지난 게시물인 redis 1부 - 설치에서는 stand alone으로 동작하도록 redis를 구성하였다.
이렇게 stand alone으로 구성할 경우, failover 상황에 대한 대비가 전혀 되지 않는 문제점을 가지게 된다.
이런 상황에 대비하기 위해, redis를 replication으로 구성해 보겠다.
redis도 DB의 일종이고, 대부분의 open source DB와 마찬가지로 replication을 지원한다.

1. 전체 구성

일단, sample로 만들어볼 목표 시스템은 아래와 같이 구성할 것이다.
이 예제에서는, 4대의 Machine에 Master 1개, Slave 3개, Sentinel 3개로 구성해 보겠다.

2. 개념

위 그림에서 보이는 몇 가지 새로운 개념에 대해 알아보자.

Master	read/write 용 redis redis에서 Master는 하나만 존재할 수 있다.
Salve	read only 용 redis, Master의 data를 mirror하고 있는 redis
Sentinel	redis의 Master와 Slave를 감시하다가, Master failover시에 새로운 Master를 지정 Sentinel 자체에도 문제가 발생할 수 있기 때문에, 여러 대의 Sentinel로 구성. 적어도 3개 이상, 홀수개로 구성해야 한다. Master를 지정하기 위해, Sentinel끼리 다수결로 결정 위의 경우, Sentinel이 3대이므로, 2 이상의 표를 얻어야 master로 선정 이 때, 숫자 2를 quorum이라 한다. quorum을 결정하는 수식 : (sentinel 의 수) / 2 + 1

3. replication의 구성

지난 1부애서 10.0.0.1에 설치한 redis를 master로 이용하겠다.
그리고, master에 필요한 설정(masterauth)은 이미 했으니, slave만 구성하면 된다.

download and build
1부에서 소개한 대로, direcory를 똑같이 구성하고, redis를 build 하자.

setting
1부에서 소개한 install_server.sh 을 실행해도 되지만, master(10.0.0.1)에 이미 생성해 둔게 있으니, 복사해서 이용하도록 하자. port는 master와 마찬가지로 16000 을 사용하지만, ip 는 각 machine에 맞게 변경해야 한다.

master에서 아래 file을 복사해 오자.

/home/backup/redis/conf/redis_16000.conf
/etc/init.d/redis_16000

복사해 온 파일이 /home/backup/temp 에 있다고 가정하자.

$ ls -al /home/backup/temp
-rwxr-xr-x 1 backup backup 1815 Apr 4 10:43 redis_16000
-rw-r--r-- 1 backup backup 62494 Apr 4 10:42 redis_16000.conf

각 파일을 복사하자.
redis_16000 file은 실행 파일이므로, 실행 권한이 있어야 한다.

$ cp /home/backup/temp/redis_16000.conf /home/backup/redis/conf
# cp /home/backup/temp/redis_16000 /etc/init.d/
# chmod +x /etc/init.d/redis_16000

먼저, conf 파일을 수정하자.

# vi /home/backup/redis/conf/redis_16000.conf
bind 10.0.0.2
port 1600
replicaof 10.0.0.1 16000
requirepass 123!@#qwe
masterauth 123!@#qwe
loglevel notice
dir /home/backup/redis/data/redis_16000
pidfile /home/backup/redis/pid/redis_16000.pid
logfile /home/backup/redis/log/redis_16000.log

주의할 부분은 3 곳이다.

bind 10.0.0.2	이 redis가 실행될 machine의 ip
replicaof 10.0.0.1 16000	이 redis가 10.0.0.1 의 16000 에서 동작하고 있는 redis의 slave 라는 의미
requirepass	이 값은 master/slave에 동일하게 주어야 한다. slave도 상황에 따라 master가 될 수 있으므로 ...
masterauth	replication시에 master에 접속하기 위해 사용하는 password master의 requirepass와 동일해야 한다. 결론적으로, redis cluster에서 모든 master/slave의 requirepass와 masterauth는 동일한 값을 가져야 한다.

그리고, service 파일을 수정하자.

# vi /etcc/init.d/redis_16000
EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli
PIDFILE=/home/backup/redis/pid/redis_16000.pid
CONF="/home/backup/redis/conf/redis_16000.conf"
REDISHOST="10.0.0.2"
REDISPORT="16000"
PASSWORD="123!@#qwe"
###############
~~~
$CLIEXEC -h $REDISHOST -p $REDISPORT -a $PASSWORD shutdown

주의할 부분은 REDISHOST="10.0.0.2" 부분이다.
conf 파일의 bind 부분에 설정한 ip를 입력하자.

이제, service가 reboot시에도 자동 실행되도록 등록해 보자
install_server.sh 를 이용하지 않았기 때문에, 등록되어 있지 않다.

# chkconfig redis_16000 on
# chkconfig --list | grep redis
redis_16000 0:off 1:off 2:on 3:on 4:on 5:on 6:off

위와 같은 작업을 각 slave에서 반복하자.

execute

설치가 완료되면, 각 slave에서 redis를 시작해 보자.

# service redis_16000 start
Starting Redis server...

salve의 log 파일을 확인해 보면, 아래와 같이 나올 것이다.

# vi /home/backup/redis/log/redis_16000.log
7189:C 03 Apr 2019 12:51:48.521 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7189:C 03 Apr 2019 12:51:48.521 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=7189, just started
7189:C 03 Apr 2019 12:51:48.521 # Configuration loaded
               _._
          _.-``__ ''-._
     _.-``    `. `_. ''-._           Redis 5.0.4 (00000000/0) 64 bit
.-`` .-```. ```\/    _.,_ ''-._
(    '      ,       .-` | `,    )     Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'|     Port: 16000
|    `-._   `._    /     _.-'    |     PID: 7190
`-._    `-._ `-./ _.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |           http://redis.io
`-._    `-._`-.__.-'_.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |
`-._    `-._`-.__.-'_.-'    _.-'
     `-._    `-.__.-'    _.-'
         `-._        _.-'
             `-.__.-'

7190:S 03 Apr 2019 12:51:48.531 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
7190:S 03 Apr 2019 12:51:48.531 # Server initialized
7190:S 03 Apr 2019 12:51:48.531 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1'         to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
7190:S 03 Apr 2019 12:51:48.532 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To         fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reb        oot. Redis must be restarted after THP is disabled.
7190:S 03 Apr 2019 12:51:48.532 * Ready to accept connections
7190:S 03 Apr 2019 12:51:48.532 * Connecting to MASTER 10.0.0.1:16000
7190:S 03 Apr 2019 12:51:48.532 * MASTER <-> REPLICA sync started
7190:S 03 Apr 2019 12:51:48.532 * Non blocking connect for SYNC fired the event.
7190:S 03 Apr 2019 12:51:48.533 * Master replied to PING, replication can continue...
7190:S 03 Apr 2019 12:51:48.534 * Partial resynchronization not possible (no cached master)
7190:S 03 Apr 2019 12:51:48.539 * Full resync from master: d7f06da8d1b8fa4c7c6bcf1f51b342fee75beace:0
7190:S 03 Apr 2019 12:51:48.583 * MASTER <-> REPLICA sync: receiving 175 bytes from master
7190:S 03 Apr 2019 12:51:48.583 * MASTER <-> REPLICA sync: Flushing old data
7190:S 03 Apr 2019 12:51:48.584 * MASTER <-> REPLICA sync: Loading DB in memory
7190:S 03 Apr 2019 12:51:48.584 * MASTER <-> REPLICA sync: Finished with success

위의 log를 보면 다음과 같은 log를 발견할 수 있다.
Connecting to MASTER 10.0.0.1:16000
10.0.0.1 의 16000에서 동작하고 있는 Master에 접속하려는 것을 알 수 있다.

이번에는 Master의 log를 살펴보자.

# vi /home/backup/redis/log/redis_16000.log
7917:M 03 Apr 2019 16:52:55.629 * Replica 10.0.0.2:16000 asks for synchronization
7917:M 03 Apr 2019 16:52:55.629 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'df6282363217e236f2b81f60b64fc6af4781e92a', my replication IDs are '671b47d3a3f4f9f224d78d462e24c4dd6aa4a869' and '0000000000000000000000000000000000000000')
7917:M 03 Apr 2019 16:52:55.629 * Starting BGSAVE for SYNC with target: disk
7917:M 03 Apr 2019 16:52:55.632 * Background saving started by pid 7948
7948:C 03 Apr 2019 16:52:55.638 * DB saved on disk
7948:C 03 Apr 2019 16:52:55.639 * RDB: 6 MB of memory used by copy-on-write
7917:M 03 Apr 2019 16:52:55.710 * Background saving terminated with success
7917:M 03 Apr 2019 16:52:55.710 * Synchronization with replica 10.0.0.2:16000 succeeded

요약하면, 10.0.0.2의 16000에서 sync 요청이 와서, sync 작업이 성공적으로 동작했다는 의미이다.

그러면, command line client인 redis-cli를 이용하여, 접속해 보자.
먼저, Master에 접속해 보자.

$ redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.1:16000> info Replication
# Replication
role:master
connected_slaves:3
slave0:ip=10.0.0.2,port=16000,state=online,offset=15511782,lag=1
slave1:ip=10.0.0.3,port=16000,state=online,offset=15511639,lag=1
slave1:ip=10.0.0.4,port=16000,state=online,offset=15511639,lag=1
master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:15511925
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14463350
repl_backlog_histlen:1048576
10.0.0.1:16000> set foo_1 "bar_1"
OK
10.0.0.1:16000> get foo_1
"bar_1"
10.0.0.1:16000> exit

role이 master이고, 3개의 salve가 있다는 것을 알 수 있다.
set commnad를 이용해, <"foo_1", "bar_1">을 저장하고,
get commnad를 이용해, data를 읽어 왔다.

그 다음엔, Slave에 접속해 보자.

$ redis-cli -h 10.0.0.2 -p 16000 -a 123\!@#qwe
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.2:16000> info Replication
# Replication
role:slave
master_host:10.0.0.1
master_port:16000
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:15499400
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:15499400
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14450825
repl_backlog_histlen:1048576
10.0.0.2:16000> get foo_1
"bar_1"
10.0.0.2:16000> exit

role이 salve이고, master는 10.0.0.1의 16000 이라는 것을 알 수 있다.
get commnad를 이용해, data를 읽어 오니, master에 입력한 data가 저장되어 있는 것을 볼 수 있다.
replication은 정상적이다 라는 것을 알 수 있다.

4. Sentinel의 구성

이제, replation 작업은 끝났다. 그러나, 이 상태로는 완전한 상태가 아니다.
예를 들어, Master의 Redis가 down된다면, 이 Redis cluster는 data를 더 이상 write 할 수 없는 상태가 된다.
위에서도 설명했지만, Sentinel이라는 것을 이용하여, Redis Cluster를 감시해야 한다.
redis의 Master와 Slave를 감시하다가, Master failover시에 새로운 Master를 지정하는 것이 Sentinel의 역활이다.

Sentinel은 또 다른 redis이다. conf 파일이 다를 뿐이다.
1부에서 source 파일 압축을 푼 곳(/home/backup/redis/redis-5.0.4)에 가 보면, sentinel.conf 라는 file이 있다.
이를 적당히 수정하여, conf 파일로 사용하면 된다.

자, 애초 계획했던 대로, 3대의 Sentinel을 구성해 보자.
10.0.0.1, 10.0.0.2, 10.0.0.4 에 설치하고, 17000 port를 사용할 것이다.
Sentinel의 기본 port는 26379 인데, 기본을 좋아하지 않기 때문에 ... ^^

setting

원본 conf(sentinel.conf)를 redis의 conf direcory로 복사한다.

$ cp /home/backup/redis/redis-5.0.4/sentinel.conf /home/backup/redis/conf/redis_sentinel_17000.conf

Sentinel의 conf 파일을 수정하자.
파일을 열어서, 아래 내용에 해당하는 부분을 확인하고 수정하자.

# vi /home/backup/redis/conf/redis_sentinel_17000.conf
bind 10.0.0.1
port 17000
daemonize yes
loglevel notice
sentinel monitor saerom.master 10.0.0.1 16000 2
sentinel auth-pass saerom.master 123!@#qwe
sentinel down-after-milliseconds saerom.master 10000
sentinel parallel-syncs saerom.master 1
sentinel failover-timeout saerom.master 180000
pidfile "/home/backup/redis/pid/redis_sentinel_17000.pid"
logfile "/home/backup/redis/log/redis_sentinel_17000.log"

각 항목은 아래와 같은 의미를 가지고 있다.

bind 10.0.0.1	Sentinel의 ip
port 17000	Sentinel이 listen할 port
daemonize yes	daemon으로 background에서 실행
loglevel notice	log level
sentinel monitor saerom.master 10.0.0.1 16000 2	saerom.master : Redis Master를 나타내는 임의의 alias 10.0.0.1 16000 : Redis Master의 ip와 port 2 : quorum, sentinel이 3대이므로 3 / 2 + 1 = 2
sentinel auth-pass saerom.master 123!@#qwe	Master의 requirepass
sentinel down-after-milliseconds saerom.master 10000	이 시간동안 Redis Master로 연결이 안되면 Master Down으로 판단, 단위 : ms, Default : 30초
sentinel parallel-syncs saerom.master 1	Slave가 여러 개일 경우 몇 개씩 동시에 Sync 1이면 Salve 하나씩 순차적으로 2 로 하면, 한번에 2개의 Slave가 Sync를 진행하므로 Master의 부하가 증가
sentinel failover-timeout saerom.master 180000	http://redisgate.kr/redis/sentinel/sentinel_failover-timeout.php
pidfile "/home/backup/redis/pid/redis_sentinel_17000.pid"	process id 파일의 경로
logfile "/home/backup/redis/log/redis_sentinel_17000.log"	log 파일의 경로

Sentinel을 daemon으로 동작시키겠다라고 지정(daemonize yes)하였으므로, service로 등록하자.
위에서 언급한 것처럼, Sentinel은 또 다른 redis이므로, redis의 service 파일을 복사한 후 수정해서 사용하면 된다.

# cp /etc/init.d/redis_16000 /etc/init.d/redis_sentinel_17000
# vi /etc/init.d/redis_sentinel_17000
EXEC=/usr/local/bin/redis-sentinel
CLIEXEC=/usr/local/bin/redis-cli
PIDFILE=/home/backup/redis/pid/redis_sentinel_17000.pid
CONF="/home/backup/redis/conf/redis_sentinel_17000.conf"
REDISHOST="10.0.0.1"
REDISPORT="17000"
###############
~~~
$CLIEXEC -h $REDISHOST -p $REDISPORT shutdown

이제, service가 reboot시에도 자동 실행되도록 등록해 보자

# chkconfig redis_sentinel_17000 on
# chkconfig --list | grep redis
redis_17000 0:off 1:off 2:on 3:on 4:on 5:on 6:off

위와 같은 작업을 Sentinel을 설치할 Machine에서 반복하자.

excute

각 Server에서 Sentinel을 모두 실행하자.

# service redis_sentinel_17000 start
Starting Redis server...

process 를 확인해 보자

# ps -ef | grep redis
root 7944 1 0 Apr03 ? 00:04:37 /usr/local/bin/redis-server 10.0.0.1:16000
root 12409 1 0 10:53 ? 00:00:00 /usr/local/bin/redis-sentinel 10.0.0.1:17000 [sentinel]

log를 확인해 보자.

$ vi /home/backup/redis/log/redis_sentinel_17000.log
12408:X 05 Apr 2019 10:53:45.536 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
12408:X 05 Apr 2019 10:53:45.536 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=12408, just started
12408:X 05 Apr 2019 10:53:45.536 # Configuration loaded
12409:X 05 Apr 2019 10:53:45.546 * Running mode=sentinel, port=7000.
12409:X 05 Apr 2019 10:53:45.547 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
12409:X 05 Apr 2019 10:53:45.547 # Sentinel ID is 2f74bada2a3166fff7455cbb3e652a97e8074135
12409:X 05 Apr 2019 10:53:45.548 # +monitor master saerom.master 10.0.0.1 16000 quorum 2

10.0.0.1 의 16000 에서 동작하고 있는 redis를 감시하고 있다는 것을 알 수 있다.

test

이제 설치, 설정, 실행 작업이 모두 끝났다. Sentinel을 설치한 효과가 있는지 확인해 보자.
이를 위해 Master를 중시시키면 어떤 일이 일어나는지 살펴 보자.

현재 Master인 10.0.0.1의 redis를 중지시키자.

# service redis_16000 stop
Stopping ...
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
Redis stopped

Sentinel의 log를 확인해 보자.

$ vi /home/backup/redis/log/redis_sentinel_17000.log
12409:X 05 Apr 2019 10:55:22.998 # +sdown master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.051 # +odown master saerom.master 10.0.0.1 16000 #quorum 2/2
12409:X 05 Apr 2019 10:55:23.051 # +new-epoch 1
12409:X 05 Apr 2019 10:55:23.051 # +try-failover master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.054 # +vote-for-leader 2f74bada2a3166fff7455cbb3e652a97e8074135 1
12409:X 05 Apr 2019 10:55:23.060 # 7c3f129a21af494fafb49ec6d7763f35e66667ec voted for 2f74bada2a3166fff7455cbb3e652a97e8074135 1
12409:X 05 Apr 2019 10:55:23.061 # a273c2a5611dd437c7bb2f0fcadb7ae5d456f84b voted for 2f74bada2a3166fff7455cbb3e652a97e8074135 1
12409:X 05 Apr 2019 10:55:23.125 # +elected-leader master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.125 # +failover-state-select-slave master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.207 # +selected-slave slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.207 * +failover-state-send-slaveof-noone slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.279 * +failover-state-wait-promotion slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.302 # +promoted-slave slave 10.0.0.2:16000 10.0.0.2 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.302 # +failover-state-reconf-slaves master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:23.332 * +slave-reconf-sent slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:24.155 # -odown master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:24.354 * +slave-reconf-inprog slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:24.354 * +slave-reconf-done slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:24.431 # +failover-end master saerom.master 10.0.0.1 16000
12409:X 05 Apr 2019 10:55:24.431 # +switch-master saerom.master 10.0.0.1 16000 10.0.0.2 16000
12409:X 05 Apr 2019 10:55:24.431 * +slave slave 10.0.0.3:16000 10.0.0.3 16000 @ saerom.master 10.0.0.2 16000
12409:X 05 Apr 2019 10:55:24.431 * +slave slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000
12409:X 05 Apr 2019 10:55:34.471 # +sdown slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000

10.0.0.1의 redis가 down되었고, 10.0.0.2의 redis가 Master가 되었다는 것을 알 수 있다.

10.0.0.2에 접속해, Master가 되었음을 확인할 수 있다.

$ redis-cli -h 10.0.0.2 -p 16000 -a 123\!@#qwe
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.2:16000> info Replication
# Replication
role:master
connected_slaves:2
slave1:ip=10.0.0.3,port=16000,state=online,offset=15511639,lag=1
slave1:ip=10.0.0.4,port=16000,state=online,offset=15511639,lag=1
master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:15511925
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14463350
repl_backlog_histlen:1048576
10.0.0.2:16000> exit

현재 상태에서, 10.0.0.1 의 redis를 다시 시작하면, 어떻게 될까?

# service redis_16000 start
Starting Redis server...

Sentinel의 log를 확인해 보자.

$ vi /home/backup/redis/log/redis_sentinel_17000.log
12409:X 05 Apr 2019 10:58:12.662 # -sdown slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000
12409:X 05 Apr 2019 10:58:22.640 * +convert-to-slave slave 10.0.0.1:16000 10.0.0.1 16000 @ saerom.master 10.0.0.2 16000

10.0.0.1의 redis에 접속해 보자.

$ redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.1:16000> info Replication
# Replication
role:slave
master_host:10.0.0.2
master_port:16000
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:15499400
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:671b47d3a3f4f9f224d78d462e24c4dd6aa4a869
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:15499400
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14450825
repl_backlog_histlen:1048576
10.0.0.1:16000> exit

현재 slave로 동작하고 있고, Master는 10.0.0.2 이다.

여기까지 replication 구성을 완료하였다.
3부에서는 centos에서 redis를 실행했을 때 나타나는 경고 메세지에 대해서 알아보겠다.

redis 1부 - 설치 ...

drscg — Mon, 8 Apr 2019 11:19:00 +0900

redis는 Remote Dictionary Systerm의 약자로서 원격 케시 서버라 할 수 있다. NoSQL로 분류되기도 한다.
Memory를 사용하여 고속으로 <Key, Value> 스타일의 data를 저장하고 가져올 수 있는 원격 시스템으로 정의할 수 있다.

다양한 Data type(List, Set, Sorted Set, Hash, String등)을 지원하며, 당연하게도 Replication도 지원한다.

이 게시물에서는 Redis의 설치 방법을 알아보자

설치할 OS는 CentOS 6.9 이다.
redis는 windows, aix등의 OS에 대해 지원하지 않는다.
이들 OS에 대한 binary는 다른 경로를 통해 구해야 한다고 들었다.

ip: 10.0.0.1, port: 16000 으로 가정한다.
redis는 기본적으로 6000 port를 사용하는데, 기본을 별로 좋아하지 않아서 ... ^^

1. Directory

아래와 같은 directory 구조를 사용할 것이다.

/home/backup/redis		// redis 설치 home
	conf	// 설정 파일 *.conf
	data	// data 파일 *.rdb
	log	// log 파일 *.log
	pid	// process id *.id
	redis-5.0.4	// redis source file의 압축을 푼 directory
	redis-5.0.4.tar.gz	// redis source file

2. download and compile

redis는 source 형태로 배포되므로, 직접 build 해야 한다.
아래 명령어에서 #으로 시작하는 command는 root 로 실행해야 한다.

compiler와 필요한 library를 설치한다.

# yum install epel-release
# yum install gcc jemalloc jemalloc-devel tcl

최신 source를 가져와 compile한다. 현재 redis 최신 버전은 5.0.4 이다.
redis를 download해 build할 directory(redis)를 생성한다.
이 directory에, 설정 파일, log, data를 저장하게 된다.
압축을 풀고, build하고, 설치한다.

$ cd /home/backup
$ mkdir redis
$ cd redis
$ wget http://download.redis.io/releases/redis-5.0.4.tar.gz
$ tar xzf redis-5.0.4.tar.gz
$ ls -al
drwxrwxr-x 6 backup backup 4096 Apr 3 15:59 redis-5.0.4
-rw-rw-r-- 1 backup backup 1966337 Mar 19 01:29 redis-5.0.4.tar.gz
$ cd redis-5.0.4
$ make
# make install

아래 경로에서 redis 실행 파일을 볼 수 있다.
압축을 풀고, build하고, 설치한다.

$ ls -al /usr/local/bin
total 62096
drwxr-xr-x. 2 root root     4096 Apr 1 14:51 .
drwxr-xr-x. 18 root root     4096 Dec 4 15:14 ..
-rwxr-xr-x. 1 root root 7925655 Jan 9 11:16 docker-compose
-rwxr-xr-x. 1 root root 9202963 Apr 1 14:51 redis-benchmark
-rwxr-xr-x. 1 root root 12266338 Apr 1 14:51 redis-check-aof
-rwxr-xr-x. 1 root root 12266338 Apr 1 14:51 redis-check-rdb
-rwxr-xr-x. 1 root root 9580080 Apr 1 14:51 redis-cli
lrwxrwxrwx. 1 root root       12 Apr 1 14:51 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 12266338 Apr 1 14:51 redis-server

3. setting

위에서 생성한 direcory에 설정파일, log, data를 저장할 directory를 생성한다.

$ pwd
/home/backup/redis
$ mkdir conf data log pid
$ ls -al
drwxrwxr-x 2 backup backup    4096 Apr 3 16:05 conf
drwxrwxr-x 2 backup backup    4096 Apr 3 16:05 data
drwxrwxr-x 2 backup backup    4096 Apr 3 16:05 log
drwxrwxr-x 2 backup backup    4096 Apr 3 16:05 pid
drwxrwxr-x 6 backup backup    4096 Apr 3 15:59 redis-5.0.4
-rw-rw-r-- 1 backup backup 1966337 Mar 19 01:29 redis-5.0.4.tar.gz

port, 설정파일, log의 위치 등을 지정하고 이를 서비스로 등록하는 shell을 제공한다. 이를 실행해 보자.
port 값은 해당 시스템에서 사용하지 않는 임의의 port를 사용하면 된다. 여기에서는 16000 port를 사용하겠다.

$ cd redis-5.0.4/utils
# ./install_server.sh
Welcome to the redis service installer
This script will help you easily set up a running redis server
Please select the redis port for this instance: [6379] 16000
Please select the redis config file name [/etc/redis/16000.conf] /home/backup/redis/conf/redis_16000.conf
Please select the redis log file name [/var/log/redis_16000.log] /home/backup/redis/log/redis_16000.log
Please select the data directory for this instance [/var/lib/redis/16000] /home/backup/redis/data/redis_16000
Please select the redis executable path [/usr/local/bin/redis-server] enter
Selected config:
Port           : 16000
Config file    : /home/backup/redis/conf/redis_16000.conf
Log file       : /home/backup/redis/log/redis_16000.log
Data dir       : /home/backup/redis/data/redis_16000
Executable     : /usr/local/bin/redis-server
Cli Executable : /usr/local/bin/redis-cli
Is this ok? Then press ENTER to go on or Ctrl-C to abort. enter
Copied /tmp/16000.conf => /etc/init.d/redis_16000
Installing service...
Successfully added to chkconfig!
Successfully added to runlevels 345!
Starting Redis server...
Installation successful!

이 shell을 실행시키면, 다음과 같은 결과를 얻을 수 있다.
- 설정 파일 생성: /home/backup/redis/conf/redis_16000.conf
- service로 등록 : /etc/init.d/redis_16000
- 시스템 reboot시에 자동으로 시작되도록 등록

그냥 실행해도 동작은 하겠지만, 향후 replication setting 그리고 보안 issue 해결을 위해, 몇 가지를 수정하자.

먼저, redis의 conf 파일을 수정하자.
conf 파일은 위의 install_server.sh 에서 지정한 위치에 있다.
파일을 열어서, 아래 내용에 해당하는 부분을 확인하고 수정하자.
각 line의 가장 앞에 #이 있으면, remark를 의미하니 유의하자.

# vi /home/backup/redis/conf/redis_16000.conf
bind 10.0.0.1
port 16000
requirepass 123!@#qwe
masterauth 123!@#qwe
loglevel notice
dir /home/backup/redis/data/redis_16000
pidfile /home/backup/redis/pid/redis_16000.pid
logfile /home/backup/redis/log/redis_16000.log

각 항목은 아래와 같은 의미를 가지고 있다.

bind	redis 의 ip
port	redis가 listen할 port
requirepass	보안 설정, client가 접속시에 사용할 password replication시에 master에 접속하기 위한 password 현재는 master이지만, 향후 slave가 될 경우에 사용
masterauth	master의 requirepass와 동일해야 한다.
loglevel	log level
dir	data file의 경로
pidfile	process id file의 경로
logfile	log file의 경로

그리고, service를 확인해 보자.

# ls -al /etc/init.d/redis_16000
-rwxr-xr-x 1 root root 1727 Apr 3 16:16 /etc/init.d/redis_16000
# chkconfig --list | grep redis
redis_16000 0:off 1:off 2:on 3:on 4:on 5:on 6:off

service로 실행 시 나타날 수 있는 몇 가지 문제를 해결하기 위해, 해당 파일을 수정하자.

# vi /etcc/init.d/redis_16000
EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli
PIDFILE=/var/run/redis_16000.pid
CONF="/home/backup/redis/conf/redis_16000.conf"
REDISPORT="16000"
###############
~~~
$CLIEXEC -p $REDISPORT shutdown

파일을 열어보면, 위와 같이 보일 것이다. 아래 처럼 수정하자.

EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli
PIDFILE=/home/backup/redis/pid/redis_16000.pid
CONF="/home/backup/redis/conf/redis_16000.conf"
REDISHOST="10.0.0.1"
REDISPORT="16000"
PASSWORD="123!@#qwe"
###############
~~~
$CLIEXEC -h $REDISHOST -p $REDISPORT -a $PASSWORD shutdown

4. execute

자. 설정 작업이 끝났다. redis를 시작해 보자.

# service redis_16000 start
Starting Redis server...

process를 확인해 보자

# ps -ef | grep redis
root 1423 1 0 18:31 ? 00:00:00 /usr/local/bin/redis-server 10.0.0.1:16000
root 1428 1253 0 18:31 pts/0 00:00:00 grep redis

log 파일을 확인해 보면, 아래와 같이 나올 것이다. 그러면 잘 setting한 것이다.

# vi /home/backup/redis/log/redis_16000.log
1367:C 03 Apr 2019 17:51:39.819 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1367:C 03 Apr 2019 17:51:39.819 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=1367, just started
1367:C 03 Apr 2019 17:51:39.819 # Configuration loaded
1368:M 03 Apr 2019 17:51:39.820 * Increased maximum number of open files to 10032 (it was originally set to 1024).
               _._
          _.-``__ ''-._
     _.-``    `. `_. ''-._           Redis 5.0.4 (00000000/0) 64 bit
.-`` .-```. ```\/    _.,_ ''-._
(    '      ,       .-` | `,    )     Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'|     Port: 16000
|    `-._   `._    /     _.-'    |     PID: 1368
`-._    `-._ `-./ _.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |           http://redis.io
`-._    `-._`-.__.-'_.-'    _.-'
|`-._`-._    `-.__.-'    _.-'_.-'|
|    `-._`-._        _.-'_.-'    |
`-._    `-._`-.__.-'_.-'    _.-'
     `-._    `-.__.-'    _.-'
         `-._        _.-'
             `-.__.-'

1368:M 03 Apr 2019 17:51:39.821 # Server initialized
1368:M 03 Apr 2019 17:51:39.821 * DB loaded from disk: 0.000 seconds
1368:M 03 Apr 2019 17:51:39.821 * Ready to accept connections

그러면, command line client인 redis-cli를 이용하여, 접속해 보자.

# redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.1:16000> info Replication
# Replication
role:master
connected_slaves:0
master_replid:c45f6d4a00dadc41d44c5a17229540f7b0fce95c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
10.0.0.1:16000> set foo bar
OK
10.0.0.1:16000> get foo
"bar"
10.0.0.1:16000> exit

위에서 사용한 command를 간단히 설명하면 다음과 같다.

redis-cli -h 10.0.0.1 -p 16000 -a 123\!@#qwe	10.0.0.1의 16000에서 동작하는 redis에 password 123!@#qwe로 접속
info Replication	Replication 정보
set foo value	foo 라는 key와 bar 라는 value를 저장
get foo	foo 라는 key를 가진 vaule를 return
exit	종료

참고로, redis 종료 command는 다음과 같다.

# service redis_16000 stop
Stopping ...
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
Redis stopped

여기까지가, redis stand alone 설치 작업이 완료되었다.
2부에서는, redis를 replacation으로 구성해 보겠다.

2018.09.19 - 번역 - Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data

drscg — Mon, 21 Jan 2019 18:07:28 +0900

In Time Series Data and MongoDB: Part 1 – An Introduction we reviewed the key questions you need to ask to understand query access patterns to your database. In Time Series Data and MongoDB: Part 2 – Schema Design Best Practices we explored various schema design options for time-series data and how they affect MongoDB resources. In this blog post we will cover how to query, analyze and present time-series data stored in MongoDB. Knowing how clients will connect to query your database will help guide you in designing both the data model and optimal database configuration. There are multiple ways to query MongoDB. You can use native tools such as the MongoDB Shell command line and MongoDB Compass a GUI-based query tool. Programmatically MongoDB data is accessed via an extensive list of MongoDB drivers. There are drivers available for practically all the major programming languages including C#, Java, NodeJS, Go, R, Python, Ruby, and many others.

Time Series Data and MongoDB: Part 1 – An Introduction 에서, database에 대한 query access pattern을 이해하기 위해 질문해야 할 핵심 질문을 검토했다. Time Series Data and MongoDB: Part 2 – Schema Design Best Practices 에서는, 시계열 data에 대한 다양한 schema design과 이것이 MongoDB에 미치는 영향을 조사했다. 이 게시물에서는, MongoDB에 저장된 시계열 data를 query, 분석, 표시하는 방법을 설명할 것이다. client에서 database를 query하기 위해 연결하는 방법을 알면, data model과 최적의 database 구성을 design하는데 도움이 될 것이다. MongoDB를 query하는 방법은 여러가지가 있다. MongoDB Shell command line과 GUI 기반의 query tool인 MongoDB Compass 같은 기본 tool을 사용할 수 있다. 많은 MongoDB drivers 를 통해 프로그래밍 방식으로 MongoDB data를 access한다. C#, Java, NodeJS, Go, R, Python, Ruby 등 사실상 모든 주요 프로그래밍 언어에서 이용할 수 있는 driver가 있다.

MongoDB also provides third-party BI reporting tool integration through the use of the MongoDB BI Connector. Popular SQL-based reporting tools like Tableau, Microsoft PowerBI, QlikView, and TIBCO Spotfire can leverage data directly in MongoDB without the need to ETL data into another platform for querying. MongoDB Charts, currently in Beta, provides the fastest way to visualize your MongoDB data without the need for third party products or flattening your data so that it can be read by SQL-bases BI tool.

또한, MongoDB는 MongoDB BI Connector를 이용하여, 타사 BI reporting tool 통합을 제공한다. Tableau, Microsoft PowerBI, QlikView, TIBCO Spotfire 같은 인기있는 SQL 기반의 reporting tool은 query로 또 다른 platform에 ETL data를 추출할 필요 없이, MongoDB에서 직접 data를 활용할 수 있다. 현재는 베타 버전이지만, MongoDB Charts는, SQL 기반의 BI tool에서 읽을 수 있도록 타사 제품이나 data을 평면화하지 않고, MongoDB data를 시각화하는 가장 빠른 방법을 제공한다.

In this blog we will cover querying, analyzing and presenting time-series data using the tools described above.

이 게시물에서는 위에서 언급한 tool을 사용하여, 시계열 data를 query, 분석, 표시하는 방법을 다룰 것이다.

Querying with Aggregation Framework

The MongoDB Aggregation Framework allows developers to express functional pipelines that perform preparation, transformations, and analysis of data. This is accomplished through the use of stages which perform specific actions like grouping, matching, sorting, or shaping the data. Data flowing through the stages and its corresponding processing is referred to as the Aggregation Pipeline. Conceptually it is similar to the data flow through a Unix shell command line pipeline. Data gets input from the previous stage, work is performed and the stage’s output serves as input to the next processing stage until the pipeline ends. Figure 1 shows how data flows through a pipeline that consists of a match and group stage.

개발자는 MongoDB Aggregation Framework를 사용하여, data의 준비, 변환, 분석을 수행하는 기능적 pipeline을 구현할 수 있다. 이는 data의 grouping, matching, sorting, shaping 같은 특정 작업을 수행하는 stage를 사용하여 수행된다. stage를 통해 흐르는 data와 해당 처리를 Aggregation Pipeline 이라 한다. 개념적으로, Unix shell command line pipeline을 통한 data 흐름과 유사하다. data는 이전 stage에서 input을 얻고, 작업을 수행하고, stage의 output은 pipeline이 끝날 때까지 다음 처리 stage의 input으로 사용된다. 그림 1은 match와 group stage로 구성된 pipeline을 통한 data 흐름을 보여준다.

Figure 1: Sample data flows through the Aggregation Pipeline

$match is the first stage In this two stage pipeline. $match will take the entire orders collection as an input and provide as an output a filter with the list of documents where the field, “status” contains the “A” value. The second stage will take these filtered documents as input and perform a grouping of the data to produce the desired query result as an output. While this is a simple example keep in mind that you can build out extremely sophisticated processing pipelines leveraging 100+ operators over 25 different stage classes allowing you to do things like transformations, redacting, sorting, grouping, matching, faceted searches, graph traversals, and joins between different collections to name a few. You can work with data in ways that are just impossible with other distributed databases.

$match는 2개의 stage를 가진 이 pileline의 첫 번째 stage이다. $match는 전체 orders collection을 input으로 사용하고, “status” field가 "A"를 가진 document의 목록을 가진 filter를 output으로 제공한다. 2번째 stage는 이들 filter된 document를 input으로 하고, 원하는 query 결과를 만들기 위해 data를 group화 하여 output으로 한다. 이것은 간단한 예제지만, 변환, 수정, 정렬, 그룹화, 일치, facet 검색, graph 운영, 다른 collection간의 join 등을 할 수 있도록, 25개 이상의 다른 stage에 100개 이상의 연산자를 활용하는 메우 복잡한 process pipeline을 구축할 수 있다는 점을 기억하자. 다른 분산 database에서는 불가능한 방식으로 data를 사용할 수 있다.

With our time-series data we are going to use MongoDB Compass to issue an ad-hoc query that finds the day high price for a given stock. Compass is the GUI tool that allows you to easily explore your data. A useful feature is the ability to visually construct an aggregation pipeline by assembling stages onto a canvas, and then exporting the resultant pipeline as a code for copying and pasting into your app.

우리의 시계열 data를 가지고 MongoDB Compass를 사용하여 특정 주식에 대해 당일 최고가를 찾는 query를 할 것이다. compass는 data를 쉽게 탐색할 수 있는 GUI tool이다. 유용한 기능은 canvas에서 stage를 조합하고, 그 결과로 만들어진 pipeline을 code로 export하여, app에 복사하고 붙여넣음으로써, 집계 pipeline을 시각적으로 구성하는 능력이다.

Finding day high for a given stock

Before diving into the query itself, recall that our StockGen application, described in part 2 of this blog series, produced 1 month of stock price data for 5 stocks we wanted to track. One of the two collections created is called, “StockDocPerMinute” (PerMinute) and it contains a document that represents a minute of data for a specific stock symbol as shown in Figure 2.

query 자체로 들어 가지전에, part 2 에서 설명한 StockGen application이 우리가 추적하려는 5개 주식의 1개월 분량의 주가 data를 생성했다는 점을 기억하자. 생성된 2개의 collection 중 하나인 “StockDocPerMinute” (PerMinute)은 그림 2에서 보듯이 특정 주식 기호에 대한 특정 분(minute)에 대한 data를 나타내는 document를 가지고 있다.


{
            "_id" : ObjectId("5b57a8fae303d36d6df69cd3"),
            "p" : {
                        "0" : 58.75,
                        "1" : 58.75,
                        "2" : 59.45,
...up to…
                        "58" : 58.57,
                        "59" : 59.01
            },
            "symbol" : "FB",
            "d" : ISODate("2018-07-14T00:00:00Z")
}

Figure 2: Sample StockDocPerMinute document

Consider the scenario where the application requests the day high price for a given stock ticker over time. Without the Aggregation Framework this query would have to be either accomplished by retrieving all the data back into the app and using client side code to compute the result, or by defining a map-reduce function in Javascript. Both options are not optimal from a performance or developer productivity perspective.

application이 시간에 따라 주어진 주식 시세에 대해 당일 최고가를 요청하는 시나리오를 생각해 보자. Aggregation Framework가 없다면, 이 query는 모든 data를 app에서 가져와 client측 code를 사용하여 결과를 계산하는 계산하거나, Javascript에서 map-reduce를 정의해야 가능하다. 두 option 모두 성능이나 개발자 생산성 측면에서 최적이 아니다.

Notice the sample document has a subdocument which contains data for an entire minute interval. Using the Aggregation Framework we can easily process this subdocument by transforming the subdocument into an array using the $objectToArray expression, calculating the maximum value and projecting the desired result.

예제 document는 전체 분 간격으로, data를 포함하고 있는 하위 document를 가지고 있다. Aggregation Framework를 사용하면, $objectToArray 를 사용하여, 하위 document를 array로 변경하고, 최대값을 계산하고, 원하는 결과를 예측함으로써, 이 하위 document를 쉽게 처리할 수 있다.

Using MongoDB Compass we can build out the query using the Aggregation Pipeline Builder as follows:

MongoDB Compass를 사용하여, 다음과 같이 Aggregation Pipeline Builder를 사용하는 query를 만들 수 있다.

Figure 3: First stage is $match stage

Figure 4: Second stage is the $project stage

Figure 5: Third stage is the $addFields stage

Figure 6: Fourth stage is the $group stage

Figure 7: Fifth stage is the $sort stage

We can see the output of the last stage is showing the maximum value per day for each day. Using the aggregation pipeline builder we didn’t need to write a single line of code. For reference, the complete query built by MongoDB Compass in the previous figures is as follows:

마지막 stage의 output이 각 날짜별로 최대값을 보여줌을 알 수 있다. Aggregation Pipeline Builder를 사용하면, code를 한 line씩 작성하지 않아도 된다. 참고로 앞의 그림에서, MongoDB Compass가 작성한 전체 query는 다음과 같다.


db.getCollection('StockDocPerMinute').aggregate([
  { $match: { "symbol" : "FB" } },
  {"$project": 
{ 
"year": {"$year": "$d"}, 
"month": {"$month": "$d"}, 
"dayOfMonth": {"$dayOfMonth": "$d"},
"p": {"$objectToArray": "$p"},
"Symbol":1
} },
    {"$addFields": {"tmax": {"$max": '$p.v'}}},
    {"$group": {
                            _id: {           
                                year: '$year',
                                month: '$month',
                                dayOfMonth: '$dayOfMonth'
                            },
                            "DayMax": {$max: "$tmax"},
                            }
                        },
   {$sort: {_id: -1}}
])

Leveraging Views

MongoDB read-only views can be created from existing collections or from other views. These views act as read-only collections, and are computed on demand during read operations. Since they appear as another collection, you can add a layer of security by restricting access to the underlying collections of the view and just give the client read access to the view. If you want to learn more about access control with Views read the blog post, “Providing Least Privilege Access to MongoDB data”.

기존 collection이나 다른 view에서 MongoDB 읽기 전용 view를 생성할 수 있다. 이 view는 읽기 전용 collection으로 동작하며, read 작업 중에 필요에 따라 계산된다. 이것은 또 다른 collection으로 표시되므로, view의 기반 collection에 대한 access를 제한하거나 view에 client read access를 부여하여, 보안 계층을 추가할 수 있다. view에 대한 access control에 대해 더 많은 정보가 필요하다면, “Providing Least Privilege Access to MongoDB data”를 읽어 보자.

To see how views are created, consider the scenario where the user wants to query stock price history. We can create a view on the StockDocPerMinute collection using the createView syntax as follows:

view를 작성하는 방법을 알아보기 위해 사용자가 주가 기록을 query하는 시나리오를 생각해 보자. 다음과 같이 createView를 사용하여, StockDocPerMinute collection에 view를 생성할 수 있다.


db.createView("ViewStock","StockDocPerMinute", 
[
{"$project": {"p": {"$objectToArray": "$p"}, "d":1, "symbol":1}},
{"$unwind": "$p"},
{"$project": {"_id": 0, "symbol":1,"Timestamp": {
   "$dateFromString": {"dateString":
                           {"$concat": [{"$dateToString":
                                             {"format": "%Y-%m-%dT%H:%M:",
                                              "date": "$d"}},
                                        {"$concat": ["$p.k", "Z"]}]}}}, 
                                        "price":"$p.v"}}
                                    ])

As MongoDB read-only views are materialized at run-time,the latest results are available with each query. Now that the view is defined it can be accessed just like any other collection. For example, to query the first price entry for the “FB” stock using the view we can issue :

run-time에 MongoDB 읽기 전용 view가 구체화되면, 각 query에서 최신 결과를 이용할 수 있다. 이제, view가 정의되었으므로, 다른 collection처럼 access할 수 있다. 예를 들어, view를 사용하여, "FB" 주식의 첫번째 가격을 query하려면 다음과 같이 할 수 있다.


db.ViewStock.find({ "symbol":"FB" } ) .sort({d:-1}).limit(1)

You can also use the aggregation framework with views. Here is the query for all “FB” stock ticker data for a specific day.

view에서 Aggregation Framework를 사용할 수도 있다. 특정 일자의 모든 "FB" 주식 시세 data에 대한 query이다.


db.ViewStock.aggregate({ $match: { 
"symbol":"FB",
 "Timestamp" : { $gte: ISODate("2018-06-26"), $lt: ISODate("2018-06-27") }}},
 { $sort: { "Timestamp": -1 }
})

Querying time-series data with third-party BI Reporting tools

Users may want to leverage existing investments in third-party Business Intelligence Reporting and Analytics tools. To enable these SQL-speaking tools to query data in MongoDB, you can use intermediary service called the MongoDB BI Connector.

사용자가 타사 Business Intelligence Reporting and Analytics tool에서 기존의 투자정보를 활용하려 할 수도 있다. 이들 SQL 사용 tool이 MongoDB data를 query할 수 있게 하려면, MongoDB BI Connector라는 중간 service를 사용할 수 있다.

Figure 8: Query MongoDB data with your favorite SQL-based reporting tools using the BI Connector

The BI Connector service presents a port that resembles a MySQL Server to the client application and accepts client connections issuing SQL queries. The BI Connector service then translates these queries into the MongoDB Query Language (MQL) and submits the query to the MongoDB database. Results are returned from MongoDB and flattened into a tabular structure and sent back to the SQL speaking client. This flow is seen in detail in Figure 8.

BI Connector service는 MySQL Server와 유사한 port를 client에 제공하고, SQL query를 실행하는 client 연결을 허용한다.그런 다음, BI Connector services는 이들 query를 MongoDB Query Language(MQL)로 변경하고, MongoDB database에 query를 전송한다. 결과가 MongoDB에서 return되고, table 구조로 전개되어, SQL을 사용하는 client로 다시 전송된다. 자세한 구조는 그림 8에서 볼 수 있다.

To illustrate the MongoDB BI Connector in action, let’s consume our time-series data with Tableau Desktop and the MongoDB BI Connector. Tableau Desktop has a connection option for MongoDB. Using that option and connecting to the port specified in the BI Connector we see that Tableau enumerates the list of tables from our MongoDB database in Figure 9.

MongoDB BI Connector의 실제 동작을 설명하기 위해, ableau Desktop와 MongoDB BI Connector를 사용하여 시계열 data를 살펴보자. Tableau Desktopdms MonogoDB를 위한 연결 option을 가지고 있다. 해당 option을 사용하여, BI Connector에 지정한 port로 연결하면, 그림 9처럼 MongoDB database로 부터 table 목록을 열거하는 것을 볼 수 있다.

Figure 9: Data Source view in Tableau showing information returned from MongoDB BI Connector

These tables are really our collections in MongoDB. Continuing with the Worksheet view in Tableau we can continue and build out a report showing price over time using the View we created earlier in this document.

이들 table은 실제로 MongoDB의 collection이다. Tableau에서 Worksheet view를 계속해 보면, 앞에서 생성한 view를 사용하여, 시간별 가격을 보여주는 report를 작성할 수 있다.

FIgure 10: Sample Tableau worksheet showing price over time

MongoDB Charts

The fastest way to visualize data in MongoDB is with MongoDB Charts. Currently available in Beta it provides users with a web console where they can build and run reports directly from data stored in MongoDB. With Charts there is no special service that needs to run in order to query MongoDB. There is also no need to move the data out or transform it into a different format to be queried. Data can be queried directly as rich documents stored MongoDB. As with other read-only connections, you can connect Charts to secondary replica nodes, therefore isolating analytics and reporting queries from the rest of the cluster serving the operational time series apps. To see how MongoDB Charts can represent data from the StockGen tool, check out the price over time line graph as shown in Figure 11.

MongoDB에서 data를 시각화할 수 있는 가장 빠른 방법은 MongoDB Charts를 사용하는 것이다. 현재 베타 버전을 이용할 수 있으며, MongoDB에 저장된 data에서 직접 report를 작성하고 실행할 수 있는 web console을 사용자에게 제공한다. chart에는 MongoDB를 query하기 위해 실행해야 하는 특별한 service가 없다. 또한 data를 다른 곳으로 이동하거나 query할 다른 형태로 변환할 필요가 없다. data는 MongoDB에 저장된 rich documennt로 바로 query될 수 있다. 다른 읽기 전용 connection과 마찬가지로, chart를 secondary replica node에 연결할 수 있어, 시계열 시리즈의 app을 제공하는 cluster에서 분석 및 report query를 분리할 수 있다. MongoDB Chart가 StockGen tool의 data를 표시하는 방법을 보려면, 그림 11에서 보여주는 시간별 가격 line graph를 확인하자.

Figure 11: MongoDB Charts showing price over time

At the time of this writing MongoDB Charts is in Beta, therefore details and screenshots may vary from with the final release.

이 글을 스는 시점에서 MongoDB Chart는 베타 버전이므로, 자세한 내용과 screenshot은 최종 버전과 다를 수 있다.

Analytics with MongoDB

In addition to issuing advanced analytics queries with the MongoDB Aggregation Framework, the MongoDB Connector for Apache Spark exposes all of Spark’s libraries, including Scala, Java, Python and R. This enables you to use the Spark analytics engine for big data processing of your time series data extending analytics capabilities of MongoDB even further to perform real-time analytics and machine learning. The connector materializes MongoDB data as DataFrames and Datasets for analysis with machine learning, graph, streaming, and SQL APIs. The Spark connector takes advantage of MongoDB’s aggregation pipeline and rich secondary indexes to extract, filter, and process only the range of data you need! No wasted time extracting and loading data into another database in order to query your MongoDB data using Spark!

MongoDB Aggregation Framework을 사용하여 고급 분석 query를 실행하는 것 외에도, MongoDB Connector for Apache Spark는 Scala, Java, Python, R을 포함한 모든 Spark library를 제공한다. 이를 통해, 시계열 data의 Bigdata 처리에 Spark 분석 엔진을 사용할 수 있고, MongoDB의 분석 기능을 더욱 확장하여 실시간 분석과 Machine Learning을 할 수 있다. connector는 MongoDB data를 Machine Learning, graph, streaming, SQL API로 분석하기 위한 DataFrame과 Dataset으로 구체화한다. Spark connector는 MongoDB의 aggregation pipeliner과 secondary index를 활용하여, 필요한 범위의 data만 추출, filter, 처리한다. Spark를 사용하여 MongoDB를 query하기 위해, 다른 database로 data를 추출하고 load하는데 낭비되는 시간이 없다.

Figure 12: Spark connector for MongoDB

The MongoDB R driver provides developers and statisticians a first class experience with idiomatic, native language access to MongoDB, enterprise authentication, and full support for BSON data types. Using the extensive libraries available to R you could query MongoDB time-series data and determine locally weighted regression as seen in Figure 13.

MongoDB R driver는 개발자와 통계 전문가에게 MongoDB에 대한 관용적, native language 접근, Enterprise 인증, BSON data 유형에 대한 완벽한 지원을 제공한다. R에서 사용할 수 있는 광범위한 library를 사용하면, 그림 13에서 볼 수 있듯이, MongoDB 시계열 data를 query할 수 있고, locally weighted regression을 결정할 수 있다.

Figure 13: Scatter Plot showing price over time and smoothing of per second data

The R driver for MongoDB is available via the CRAN R Archive. Once installed you can connect to your MongoDB database and return dataframes that can be used in R calculations. The above graph was produced with the following code using R Studio:

R driver for MongoDB 는 CRAN R Archive를 통해 활용할 수 있다. 일단 설치되면, MongoDB에 연결할 수 있고, R에서 사용될 수 있는 dataframe이 return된다. 위의 graph는 R studio를 사용하여 다음과 같은 code로 작성하였다.


library(mongolite)

ts=mongo(collection="StockDocPerSecond", db="Stock", url="mongodb://localhost:27020")

fbquery=ts$find('{ "symbol":"FB"}', fields='{"_id":0, "d":1, "p":1 }')

plot(fbquery$d,fbquery$p, xlab="Date", ylab="Price", main="Price over Time"); 

lines(lowess(fbquery$d,fbquery$p), col=2);

Summary

While not all data is time-series in nature, a growing percentage of it can be classified as time-series – fueled by technologies that allow us to exploit streams of data in real time rather than in batches. In every industry and in every company there exists the need to query, analyze and report on time-series data. Real business value is derived from the analytics and insights gained from the data. MongoDB enables you to collect, analyze and act on every piece of time-series data in your environment. In this three part series we covered some thought provoking questions with respect to your specific application requirements. In the second blog post we looked at a few different time-series schema designs and their impact on MongoDB performance. Finally we concluded the series showing how to query time series data using the MongoDB Aggregation Framework and MongoDB Compass as well as other methods like using the BI Connector and analytical languages like R.

모든 data가 본질적으로 시계열 data는 아니지만, 점점 더 많은 data가 시계열로 분류될 수 있다. batch가 아닌 실시간으로 data stream을 이용할 수 있는 기술에 의해 가속화된다. 모든 산업과 회사에서 시계열 data를 query, 분석, report할 필요가 있다. 실제 비지니스 가치는 data에서 얻은 분석 및 통찰력에 있다. MongoDB를 사용하면 여러분의 환경에 있는 모든 시게열 data를 수집, 분석, 실행할 수 있다. 이 3개의 게시물에서, 특정 application의 요구사항과 관련하여 몇 가지 생각해봐야 할 질문을 다루었다. 2번째 게시물에서는 몇 가지 시계열 schema design과 그것이 MongoDB 성능에 미치는 영향을 살펴보았다. 마지막으로, MongoDB Aggregation Framework과 MongoDB Compas를 사용하여 시계열 data를 query하는 방법과 BI Connector와 R같은 분석 언어를 사용하는 방법을 보여주면서 마무리지었다.

Prototypes are one thing, but handling terabytes of data efficiently is on a different playing field. With MongoDB it is easy to horizontally scale out time-series workloads. Through the use of replica sets, read-only clients can connect to replica-set secondaries to perform their queries leaving the primary to focus on writes. Write heavy workloads can scale horizontally via sharding. While an in depth analysis of MongoDB architecture is out of scope for these blog posts you can find lots of useful information in the MongoDB Architecture whitepaper.

prototype도 중요하지만, 수 TB의 data를 처리하는 것은 다르다. MongoDB를 사용하면 시계열의 작업량을 쉽게 수평확장할 수 있다. replica set을 사용함으로서, primary는 write에 집중할 수 있도록 하고, 읽기 전용 client는 replica-set secondary에 연결하여 query를 수행할 수 있다. write가 많으며느 sharding을 통해 수평확장할 수 있다. MongoDB architecture에 대한 심층적인 분석은 이 게시물의 범위를 벗어나지만, MongoDB Architecture whitepaper에서 유용한 정보를 많이 볼 수 있다.

The Internet of Things (IoT) use case generates a plethora of time-series data. Larger IoT solutions involve supporting a variety of hardware and software devices for data ingestion, supporting real-time and historical analysis, security, high availability and managing time series data at scale to name a few. MongoDB is powering mission critical IoT applications worldwide. For more information on IoT at MongoDB check out the Internet of Things website.

IoT 사용 사례는 수많은 시계열 data를 생성한다. 대형 IoT 솔루션은 data 수집을 위한 다양한 HW, SW device 지원, 실시간/과거 분석 지원, 보안, 고가용성, 규모에 맞는 시계열 data의 관리 등을 포함한다. MongoDB는 전세계적으로 IoT application을 주도하고 있다, MongoDB의 IoT에 대한 더 많은 정보는 Internet of Things website을 확인해 보자.

원문 : Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data

2018.09.13 - 번역 - Time Series Data and MongoDB: Part 2 – Schema Design Best Practices

drscg — Mon, 21 Jan 2019 18:01:43 +0900

In the previous blog post, “Time Series Data and MongoDB: Part 1 – An Introduction,” we introduced the concept of time-series data followed by some discovery questions you can use to help gather requirements for your time-series application. Answers to these questions help guide the schema and MongoDB database configuration needed to support a high-volume production application deployment. In this blog post we will focus on how two different schema designs can impact memory and disk utilization under read, write, update, and delete operations.

이전 게시물인 “Time Series Data and MongoDB: Part 1 – An Introduction”에서, 시계열 data의 개념을 소개하고, 시계열 application의 요규사항을 수집하는데 도움이 되는 몇 가지 질물을 소개했다. 이들 질문에 대한 답변은 대용량 application의 배포를 지원하는데 필요한 schema와 MongoDB database 구성에 도움이 된다. 이 게시물에서는, read, write, update, delete 연산에서 2가지 다른 schema design이 memory와 disk 사용률에 얼마나 영향을 미치는지에 대해 중점적으로 다룰것이다.

In the end of the analysis you may find that the best schema design for your application may be leveraging a combination of schema designs. By following the recommendations we lay out below, you will have a good starting point to develop the optimal schema design for your app, and appropriately size your environment.

분석이 끝나면 application에 가장 적합한 scheman design은 schema design의 조합을 활용하는 것이라는 것을 발견할 것이다. 아래에 제시한 권장사항을 따르면, 여러분의 app에 최적인 schema design을 개발하고, 여러분의 환경에 적절히 조절할 수 있는 좋은 출발점이 될 것이다.

Designing a time-series schema

Let’s start by saying that there is no one canonical schema design that fits all application scenarios. There will always be trade-offs to consider regardless of the schema you develop. Ideally you want the best balance of memory and disk utilization to yield the best read and write performance that satisfy your application requirements, and that enables you to support both data ingest and analysis of time-series data streams.

먼저, 모든 application 시나리오에 적합한 표준 schema design은 없다는 점부터 시작하자. 개발하려는 schema에 관계없이 항상 고려해야 할 trade-offs가 있다. 이상적으로는 application 요구사항을 만족시키고, data 수집과 시계열 data stream의 분석을 동시에 지원할 수 있는, 최상의 read, write 성능을 충족시키기 위해, 최적의 memory 및 disk 사용량의 균형을 원한다.

In this blog post we will look at various schema design configurations. First, storing one document per data sample, and then bucketing the data using one document per time-series time range and one document per fixed size. Storing more than one data sample per document is known as bucketing. This will be implemented at the application level and requires nothing to be configured specifically in MongoDB. With MongoDB’s flexible data model you can optimally bucket your data to yield the best performance and granularity for your application’s requirements.

이 게시물에서, 다양한 schema design 구성을 살펴볼 것이다. 먼저, data 샘플 당 하나의 document를 저장한 다음, 시계열 시간 범위당 하나의 document와 고정된 크기당 하나의 document를 사용하여, data를 bucketing한다. document당 하나 이상의 data 샘플을 저장하는 것을 bucketing이라 한다. 이것은 application 수준에서 구현되며, MongoDB에서 특별히 구성해야 할 필요는 없다. MongoDB의 유연한 data model을 사용하면 data를 최적의 상태로 bucket에 배치하여, application의 요구사항에 맞는 최상의 성능과 세분성을 얻을 수 있다.

This flexibility also allows your data model to adapt to new requirements over time – such as capturing data from new hardware sensors that were not part of the original application design. These new sensors provide different metadata and properties than the sensors you used in the original design. With all this flexibility you may think that MongoDB databases are the wild west, where anything goes and you can quickly end up with a database full of disorganized data. MongoDB provides as much control as you need via schema validation that allows you full control to enforce things like the presence of mandatory fields and range of acceptable values, to name a few.

또한, 이러한 유연성으로 인해, data model을 시간에 따른 새로운 요구 사항(원래의 application design의 일부가 아닌 새로운 HW sensor에서 data를 얻는 것 같은)에 맞게 조정할 수 있다. 이러한 새로운 sensor는 원래의 design에서 사용된 sensor와 다른 metadata와 속성을 제공한다. 이러한 유연성 때문에 MongoDB database는 어떤 일이든 가능하며, 체계적이지 않은 data로 가드찬 database를 쉽게 구축할 수 있다고 생각할 수 있다. MongoDB는 schema validation을 통해 필요한 만큼 제어할 수 있으며, 이를 통해 필수 field가 있는지, 허용 값의 범위 같은 것들을 강제할 수 있도록 완전한 제어가 가능하다.

To help illustrate how schema design and bucketing affects performance, consider the scenario where we want to store and analyze historical stock price data. Our sample stock price generator application creates sample data every second for a given number of stocks that it tracks. One second is the smallest time interval of data collected for each stock ticker in this example. If you would like to generate sample data in your own environment, the StockGen tool is available on GitHub. It is important to note that although the sample data in this document uses stock ticks as an example, you can apply these same design concepts to any time-series scenario like temperature and humidity readings from IoT sensors.

schema design과 bucketing이 성능에 미치는 영향을 설명하기 위해, 과거의 주식 가격 data를 저장하고 분석하는 시나리오를 생각해 보자. 샘플 주식 가격 생성 application은 그것이 추적하는 정해진 수의 주식에 대해 매초마다 샘플 data를 생성한다. 1초는 이 예제에서 각 주식 시세에 대해 수집된 data의 최소 시간 간격이다. 여러분이 셈플 data를 생성하려면, GitHub에서 StockGen tool을 사용할 수 있다. 이 document의 샘플 data는 주식 ticks를 예제로 사용하지만, IoT sensor의 온도와 습도 판독값 같은 어떤 시계열 시나리오에도 이런 동일한 design 개념을 적용할 수 있다는 점을 기억하자.

The StockGen tool used to generate sample data will generate the same data and store it in two different collections: StockDocPerSecond and StockDocPerMinute that each contain the following schemas:

sample data를 생성하는데 사용되는 StocGen tool은 2개의 다른 collection에 동일한 data를 생성해 저장한다. StockDocPerSecond와 StockDocPerMinute 각각은 다음과 같은 schema를 가진다.

Scenario 1: One document per data point

{
  "_id" : ObjectId("5b4690e047f49a04be523cbd"),
"p" : 56.56,
  "symbol" : "MDB",
  "d" : ISODate("2018-06-30T00:00:01Z")
},
{
  "_id" : ObjectId("5b4690e047f49a04be523cbe"),
"p" : 56.58,
  "symbol" : "MDB",
  "d" : ISODate("2018-06-30T00:00:02Z")
}
,...

Figure 1: Sample documents representing one document per second granularity

Scenario 2: Time-based bucketing of one document per minute

{
"_id" : ObjectId("5b5279d1e303d394db6ea0f8"), 
"p" : {
"0" : 56.56,
"1" : 56.56,
"2" : 56.58,
…
"59" : 57.02
},
"symbol" : "MDB",
"d" : ISODate("2018-06-30T00:00:00Z")
},
{
"_id" : ObjectId("5b5279d1e303d394db6ea134"), 
"p" : {
 "0" : 69.47,
 "1" : 69.47,
 "2" : 68.46,
...
 "59" : 69.45
},
"symbol" : "TSLA",
"d" : ISODate("2018-06-30T00:01:00Z")
},...

Figure 2: Sample documents representing one minute granularity

Note that the field “p” contains a subdocument with the values for each second of the minute.

“p” field는 해당 분의 각 초에 대한 값을 가지는 하위 document를 포함한다.

Schema design comparisons

Let’s compare and contrast the database metrics of storage size and memory impact based off of 4 weeks of data generated by the StockGen tool. Measuring these metrics is useful when assessing database performance.

StocGen tool로 생성된 4주 분량의 data를 기반으로 저장소 크기와 memory 영향에 대한 database metric을 비교하고 대조해 보자. 이들 metric을 측정하는 것은 database의 성능을 평가할 때 유용하다.

Effects on Data Storage

In our application the smallest level of time granularity is a second. Storing one document per second as described in Scenario 1 is the most comfortable model concept for those coming from a relational database background. That is because we are using one document per data point, which is similar to a row per data point in a tabular schema. This design will produce the largest number of documents and collection size per unit of time as seen in Figures 3 and 4.

이 application에서 가장 작은 수준의 시간 세분화는 2번째이다. 시나리오 1에 설명한 대로, 초당 하나의 document를 저장하는 것이 RDB 관점에서 보면 가장 익숙한 모델이다. 표(table) 형식 schema에서 data별로 하나의 row와 유사하게, data별로 하나의 document를 사용하기 때문이다.

Figure 3: Document count over time, comparing per second vs per minute schema design

Figure 4: Comparison between data size and storage size for each scenario

Figure 4 shows two sizes per collection. The first value in the series is the size of the collection that is stored on disk, while the second value is the size of the data in the database. These numbers are different because MongoDB’s WiredTiger storage engine supports compression of data at rest. Logically the PerSecond collection is 605MB, but on disk it is consuming around 190 MB of storage space.

그림4는 collection별로 2개의 크기를 보여준다. 첫번째 값은 disk에 저장된 collection의 크기이고, 두번째 값은 database의 data 크기이다. MongoDb의 WiredTiger storage engine은 미사용 data의 compression을 지원하기 때문에, 이들 숫자는 다르다. 이론적으로 PerSecond collect은 650MB 이지만, disk에서는 약 190MB 의 저장소 공간을 소비한다.

Effects on memory utilization

A large number of documents will not only increase data storage consumption but increase index size as well. An index was created on each collection and covered the symbol and date fields. Unlike some key-value databases that position themselves as time-series databases, MongoDB provides secondary indexes giving you flexible access to your data and allowing you to optimize query performance of your application.

많은 수의 document는 data 저장소뿐만 아니라 index 크기도 증가시킨다. index는 각 collection 별로 생성되고, 기호 및 date field를 포함한다. 스스로를 시계열 database라 하는 일부 key-value database와 달리, MongoDB는 secondary indexes 를 제공하여, data의 유연한 access와 application에서의 query 성능 최적화가 가능하다.

Figure 5: Index Size (MB) comparison between PerSecond and PerMinute

The size of the index defined in each of the two collections IS seen in Figure 5. Optimal performance of MongoDB happens when indexes and most recently used documents fit into the memory allocated by the WiredTiger cache (we call this the “working set”). In our example we generated data for just 5 stocks over the course of 4 weeks. Given this small test case our data already generated an index that is 103MB in size for the PerSecond scenario. Keep in mind that there are some optimizations such as index prefix compression that help reduce the memory footprint of an index. However, even with these kind of optimizations proper schema design is important to prevent runaway index sizes. Given the trajectory of growth, any changes to the application requirements, like tracking more than just 5 stocks or more than 4 weeks of prices in our sample scenario, will put much more pressure on memory and eventually require indexes to page out to disk. When this happens your performance will be degraded. To mitigate this situation, consider scaling horizontally.

2 collection 각각에 정의된 index의 크기는 그림5에서 볼 수 있다. MongoDB의 최적 성능은 index와 가장 최근 사용된 document가 WiredTiger cache(우리는 이를 "working set"이라 한다)에 할당된 memory에 적합할 경우에 발생한다. 이 예에서 4주동안 5개의 주식에 대한 data를 생성했다. 이 작은 테스트에서, 이 data는 PerSecond 시나리오에 대해 크기가 103MB인 index를 생성했다. index의 memory 공간을 줄이는데 도움이 되는 index prefix compression 같은 최적화가 있음을 기억하자. 그러나, 이런 종류의 최적화에도 불구하고, index 크기의 급증을 방지하기 위하여 적절한 schema design이 중요하다. 증가 추이를 고려하여, 샘플 시나리오에서 5개 이상의 주식 또는 4주 이상의 가격을 추적하는 것 같은, application 요구사항의 변경은 memory에 더 많은 부담을 줄 것이고, 결국 index가 disk에 paging될 것이다. 이렇게 되면 성능히 저하될 것이다. 이 상황을 피하려면, 수평확장을 고려하자.

Scale horizontally

As your data grows in size you may end up scaling horizontally when you reach the limits of the physical limits of the server hosting the primary mongod in your MongoDB replica set.

data 크기가 증가하면, MongoDB replica set에서 primary momgod을 가지는 server의 물리적 한계에 도달하면, 결국 수평확장 해야 한다.

By horizontally scaling via MongoDB Sharding, performance can be improved since the indexes and data will be spread over multiple MongoDB nodes. Queries are no longer directed at a specific primary node. Rather they are processed by an intermediate service called a query router (mongos), which sends the query to the specific nodes that contain the data that satisfy the query. Note that this is completely transparent to the application – MongoDB handles all of the routing for you

MongoDB Sharding을 통해 수평확장을 하면, index와 data가 MongoDB node에 분산되므로, 성능은 향상된다. query는 더 이상 특정 primary node로 전달되지 않는다. 오히려 그것들은 query router(mongos)라는 중간 서비스에 의해 처리되는데, 이것은 query를 충족시키는 data를 가진 특정 node로 query를 전송한다.이것은 application과 완전히 분리되어 있다는 점을 기억하자. MongoDB가 모든 routing을 처리한다.

Scenario 3: Size-based bucketing

The key takeaway when comparing the previous scenarios is that bucketing data has significant advantages. Time-based bucketing as described in scenario 2 buckets an entire minute's worth of data into a single document. In time-based applications such as IoT, sensor data may be generated at irregular intervals and some sensors may provide more data than others. In these scenarios, time-based bucketing may not be the optimal approach to schema design. An alternative strategy is size-based bucketing. With size-based bucketing we design our schema around one document per a certain number of emitted sensor events, or for the entire day, whichever comes first.

이전 시나리오와 비교할 때 중요한 점은 bucketing data는 상당한 이점을 가진다는 것이다. 시나리오 2에서 설명한 시계열 bucketing은 전체 분(minute)의 data를 단일 document로 bucket화 한다. IoT 같은 시계열 application에서, sensor data가 불규칙한 시간으로 생성될 수 있고, 일부 sensor는 다른 것보다 더 많은 data를 제공할 수 있다. 이 시나리오에서, 시계열 bucketing은 schema design에 대한 최적의 방법이 아닐 수 있다. 대안은 크기 기반 bucketing이다. 크기 기반 bucketing을 사용하여, 출력된 sensor event의 특정 횟수 별로 또는 또는 전체 날짜에 대해 먼저 발생하는 것을 하나의 document로 schema를 design한다.

To see size-based bucketing in action, consider the scenario where you are storing sensor data and limiting the bucket size to 200 events per document, or a single day (whichever comes first). Note: The 200 limit is an arbitrary number and can be changed as needed, without application changes or schema migrations.

크기 기반 bucketing을 보려면, sensor data를 저장하고, bucket 크기를 document당 200 event 또는 하루(먼저 발생하는)로 제한하는 시나리오를 고려하자. 200이라는 제한은 임의의 숫자이며, application의 변경이나 schema migration 없이, 필요에 따라 변경될 수 있다.

{
  _id: ObjectId(),
 deviceid: 1234,
 sensorid: 3,
 nsamples: 5,
  day: ISODate("2018-08-29"),
 first:1535530412,
 last: 1535530432,
 samples : [
   { val: 50, time: 1535530412},
   { val: 55, time : 1535530415},
   { val: 56, time: 1535530420},
   { val: 55, time : 1535530430},
   { val: 56, time: 1535530432}
   ]
}

Figure 6: Size-based bucketing for sparse data

An example size-based bucket is shown in figure 6. In this design, trying to limit inserts per document to an arbitrary number or a specific time period may seem difficult; however, it is easy to do using an upsert, as shown in the following code example:

크기 기반 bucket의 예는 그림 6에서 볼 수 있다. 이 design에서, document 별로 임의의 숫자나 특정 시간 간격으로 insert를 제한하는 것이 어려워보일 수 있다. 그러나, 다음 code 예제와 같이 upsert를 사용하면 쉽다.

sample = {val: 59, time: 1535530450}
day = ISODate("2018-08-29")
db.iot.updateOne({deviceid: 1234, sensorid: 3, nsamples: {$lt: 200}, day: day},
                 {$push: {samples: sample},
                  $min: {first: sample.time},
                  $max: {last: sample.time},
                  $inc: {nsamples: 1}, {upsert: true} )

Figure 7: Sample code to add to the size-based bucket

As new sensor data comes in it is simply appended to the document until the number of samples hit 200, then a new document is created because of our upsert:true clause.

새로운 sensor data가 들어오면, sample 수가 200개가 될 때까지 추가된다. 그 다음에 upsert:true 절 때문에 새로운 document가 추가된다.

The optimal index in this scenario would be on {deviceid:1,sensorid:1,day:1,nsamples:1}. When we are updating data, the day is an exact match, and this is super efficient. When querying we can specify a date, or a date range on a single field which is also efficient as well as filtering by first and last using UNIX timestamps. Note that we are using integer values for times. These are really times stored as a UNIX timestamp and only take 32 bits of storage versus an ISODate which takes 64 bits. While not a significant query performance difference over ISODate, storing as UNIX timestamp may be significant if you plan on ending up with terabytes of ingested data and you do not need to store a granularity less than a second.

이 시나리오에서 최적의 index는 {deviceid:1,sensorid:1,day:1,nsamples:1} 이다. data를 update할 경우, day가 정확한 일치이며, 이것은 매우 효율적이다. query시에, UNIX timestamp를 사용하여 처음과 마지막을 filtering하는 것과 마찬가지로 date나 date 범위를 단일 filed에 지정하는데, 이 또한 효율적이다.시간 값에 대해 integer를 사용한다는 점을 기억하자. 이것은 실제 시간을 UNIX timestamp로 저장하는 것이고, ISODate가 64bit를 사용하는 것에 비해, 32bit 저장소만 사용한다.ISODate에 비해 현저한 query 성능 차이는 아니지만, 수 TB의 data를 수집하고, 1초 미만의 자세한 data를 저장할 필요가 없다면, UNIX timestamp로 저장하는 것은 의미가 있다.

Bucketing data in a fixed size will yield very similar database storage and index improvements as seen when bucketing per time in scenario 2. It is one of the most efficient ways to store sparse IoT data in MongoDB.

고정된 크기의 data를 bucketing하면, 시나리오 2에서 시간별로 bucketing하는 경우와 매우 유사한 database 저장소와 index 개선을 보인다. MongoDB에서 희박한 IoT data를 저장하는 가장 효율적인 방법 중 하나이다.

What to do with old data

Should we store all data in perpetuity? Is data older than a certain time useful to your organization? How accessible should older data be? Can it be simply restored from a backup when you need it, or does it need to be online and accessible to users in real time as an active archive for historical analysis? As we covered in part 1 of this blog series, these are some of the questions that should be asked prior to going live.

모든 data를 영구 저장해야 하는가? 특정 시간보다 오래된 data가 귀사에 유용한가? 이전 data에 어떻게 access 가능해야 하는가? 필요할 경우 backup에서 간단하게 복원되어야 하는가? 아니면, online이어야 하고, 사용자가 실시간 이력 분석을 위해 활성화된 archive에 access할 수 있어야 하는가? 이 게시물의 part 1에서 다루었듯이, 이런 것들이 실제 상황으로 가기 전에 질문해야 할 몇 가지 질문이다.

There are multiple approaches to handling old data and depending on your specific requirements some may be more applicable than others. Choose the one that best fits your requirements.

이전 data를 처리하는데에는 몇 가지 방법이 있으며, 구체적인 요구 사항에 따라, 몇 가지는 다른 것보다 더 적합할 수도 있다. 요구 사항에 가장 적합한 것을 고르자.

Pre-aggregation

Does your application really need a single data point for every event generated years ago? In most cases the resource cost of keeping this granularity of data around outweighs the benefit of being able to query down to this level at any time. In most cases data can be pre-aggregated and stored for fast querying. In our stock example, we may want to only store the closing price for each day as a value. In most architectures, pre-aggregated values are stored in a separate collection since typically queries for historical data are different than real-time queries. Usually with historical data, queries are looking for trends over time versus individual real-time events. By storing this data in different collections you can increase performance by creating more efficient indexes as opposed to creating more indexes on top of real-time data.

몇 년전에 생성된 모든 event에 대한 단일 data point가 application에 정말 필요한가? 대부분의 경우, 이러한 세분화된 data를 유지하는데 드는 resource 비용은 항상 이런 수준으로 query할 수 있을 때의 이점보다 크다. 대부분의 경우, 빠른 query를 위해 data를 사전 집계하여 저장할 수 있다. 주식 예제에서, 매일 마감 가격만을 값으로 저장하려 할 수도 있다. 일반적으로 과거 data에 대한 query는 실시간 query와 다르므로, 사전 집계 값들은 별도의 collection에 저장된다. 일반적으로, 과거 data의 경우, query는 실시간 event에 비해 시간별 추세를 찾는다. 다른 collection에 이 data를 저장하면, 실시간 data에 더 많은 index를 생성하는 것이 아니라 보다 효율적인 index를 생성함으로써, 성능을 향상시킬 수 있다.

Offline archival strategies

When data is archived, what is the SLA associated with retrieval of the data? Is restoring a backup of the data acceptable or does the data need to be online and ready to be queried at any given time? Answers to these questions will help drive your archive design. If you do not need real-time access to archival data you may want to consider backing up the data and removing it from the live database. Production databases can be backed up using MongoDB Ops Manager or if using the MongoDB Atlas service you can use a fully managed backup solution.

data를 archive하면, data의 검색과 관련된 SLA는? backup data를 복원이 허용되어야 하는가? 또는 data는 online이어야 하고 특정 시점에 query될 준비가 되어 있어야 하는가? 이 질문에 대한 답변은 archive design을 추친하는데 도움이 될 것이다. archive data에 대한 실시간 access가 필요하지 않다면, data를 backup하고, live database에서 제거하는 것을 고려해 보자. production database는 MongoDB Ops Manager를 사용하여 backup할 수 있으며, MongoDB Atlas service를 사용한다면, 완벽하게 관리되는 backup solution을 사용할 수 있다.

Removing documents using remove statement

Once data is copied to an archival repository via a database backup or an ETL process, data can be removed from a MongoDB collection via the remove statement as follows:

data가 database backup이나 ETL process를 통해 archive repository에 복사되면, 다음과 같이 remove 명령어를 통해 MongoDB collection에서 data를 제거할 수 있다.

 db.StockDocPerSecond.remove ( { "d" : { $lt: ISODate( "2018-03-01" ) } } )

In this example all documents that have a date before March 1st, 2018 defined on the “d” field will be removed from the StockDocPerSecond collection.

이 예제에서, "d" field에 2018년 3월 1일 이전의 날짜를 가지고 있는 모든 document는 StockDocPerSecond collection에서 제거된다.

You may need to set up an automation script to run every so often to clean out these records. Alternatively, you can avoid creating automation scripts in this scenario by defining a time to live (TTL) index.

이들 record를 정리하기 위해 주기적으로 자주 실행되는 자동화 script를 설정해야 할 수도 있다. 또는, TTL index를 정의하여, 이 시나리오에서 자동화 script를 생성하지 않을 수 있다.

Removing documents using a TTL Index

A TTL index is similar to a regular index except you define a time interval to automatically remove documents from a collection. In the case of our example, we could create a TTL index that automatically deletes data that is older than 1 week.

TTL index 는 collection에서 document를 자동으로 제거하는 시간을 정의한다는 점을 제외하면, 일반 index와 유사하다. 예제에서, TTL index를 생성하여, 1주일 이상 경과된 data를 자동으로 삭제한다.

db.StockDocPerSecond.createIndex( { "d": 1 }, { expireAfterSeconds: 604800 } )

Although TTL indexes are convenient, keep in mind that the check happens every minute or so and the interval cannot be configured. If you need more control so that deletions won’t happen during specific times of the day you may want to schedule a batch job that performs the deletion in lieu of using a TTL index.

TTL index는 편리하지만, 매 분(minute)마다 점검해야 하고, 간격을 설정할 수 없다는 점을 기억하자. 하루 중 특정 시간대에 삭제가 발생하지 않도록 더 많은 제어가 필요하다면, TTL index를 사용하는 대신 삭제를 수행하는 batch job을 예약하자.

Removing documents by dropping the collection

It is important to note that using the remove command or TTL indexes will cause high disk I/O. On a database that may be under high load already this may not be desirable. The most efficient and fastest way to remove records from the live database is to drop the collection. If you can design your application such that each collection represents a block of time, when you need to archive or remove data all you need to do is drop the collection. This may require some smarts within your application code to know which collections should be queried, but the benefit may outweigh this change. When you issue a remove, MongoDB also has to remove data from all affected indexes as well and this could take a while depending on the size of data and indexes.

remove command나 TTL index를 사용하면 많은 disk I/O가 발생한다는 점에 유의하자. 이미 많은 부하가 있을 수도 있는 database에 이것은 바람직하지 않다. live database에서 record를 제거하는 가장 효율적이고 빠른 방법은 collection을 삭제하는 것이다. 각 collection이 시간을 나타내도록 application을 design할 수 있다면, data를 archive하거나 제거할 경우에 해야할 것은 collection을 삭제하는 것 뿐이다. 이렇게 하려면, application code에서 어떤 collection을 query해야 할지를 알기 위해 몇 가지가 요구되지만, 이득이 이 변경 사항을 능가할 수 있다. 제거를 실행하면, MongoDB는 영향을 받는 모든 index에서 data를 제거해야 하고 data와 index의 크기에 따라 시간이 걸릴 수 있다.

Online archival strategies

If archival data still needs to be accessed in real time, consider how frequently these queries occur and if storing only pre-aggregated results can be sufficient.

archive data에 실시간으로 access해야 한다면, 이들 query가 얼마나 자주 발생하고, 사전 집계된 결과만 저장해도 충분한지 생각해 보자.

Sharding archival data

One strategy for archiving data and keeping the data accessible real-time is by using zoned sharding to partition the data. Sharding not only helps with horizontally scaling the data out across multiple nodes, but you can tag shard ranges so partitions of data are pinned to specific shards. A cost saving measure could be to have the archival data live on shards running lower cost disks and periodically adjusting the time ranges defined in the shards themselves. These ranges would cause the balancer to automatically move the data between these storage layers, providing you with tiered, multi-temperature storage. Review our tutorial for creating tiered storage patterns with zoned sharding for more information.

data를 archive하고 실시간으로 access 가능하도록 유지하기 위한 전략 중 하나는 data를 분할하기 위해 zoned sharding 을 사용하는 것이다. sharding은 여러 node에 data를 수평 확장하는데 도움이 될 뿐 아니라, shard range에 tag를 지정하여, data partition을 특정 shard에 고정할 수 있다. 비용 절감 방법은 저비용 disk에서 동작하는 shard에 archive data를 저장하고, shard 자체에 정의된 시간 range를 주기적으로 조정하는 것이다. 이런 range를 사용하면, balancer가 자동으로 이러한 storage 계층간에 data를 이동시켜 계층화된 multi-temperature storage를 제공한다. 구체적인 정보는 zoned sharding을 사용하여 tiered storage patterns 생성에 대한 tutorial을 참고하자

Accessing archived data via queryable backups

If your archive data is not accessed that frequently and the query performance does not need to meet any strict latency SLAs, consider backing the data up and using the Queryable Backups feature of MongoDB Atlas or MongoDB OpsManager. Queryable Backups allow you to connect to your backup and issue read-only commands to the backup itself, without having to first restore the backup.

archive data에 자주 access하지 않고query 성능이 엄격한 대기시간 SLA를 충족시키지 않아도 된다면, MongoDB Atlas 나 MongoDB OpsManager의 Queryable Backups 기능을 사용하여 data를 backup하는 것을 고려하자. Queryable Backups을 사용하면, backup을 먼저 복원하지 않은채로, backup에 연결하고 backup에 read-only command를 실행할 수 있다.

Querying data from the data lake

MongoDB is an inexpensive solution not only for long term archival but for your data lake as well. Companies who have made investments in technologies like Apache Spark can leverage the MongoDB Spark Connector. This connector materializes MongoDB data as DataFrames and Datasets for use with Spark and machine learning, graph, streaming, and SQL APIs.

MongoDB는 장기 archive 뿐만 아니라 여러분의 data에 대해서도 저렴한 솔루션이다. Apache Spark와 같은 기술에 투자한 기업들은 MongoDB Spark Connector 를 활용할 수 있다. 이 connector는 MongoDB data를 Spark, Machine Learning, graph, streaming, SQL API와 함께 사용할 수 있도록 DataFrames, Datasets 으로 구체화한다.

Key Takeaways

Once an application is live in production and is multiple terabytes in size, any major change can be very expensive from a resource standpoint. Consider the scenario where you have 6 TB of IoT sensor data and are accumulating new data at a rate of 50,000 inserts per second. Performance of reads is starting to become an issue and you realize that you have not properly scaled out the database. Unless you are willing to take application downtime, a change of schema in this configuration – e.g., moving from raw data storage to bucketed storage – may require building out shims, temporary staging areas and all sorts of transient solutions to move the application to the new schema. The moral of the story is to plan for growth and properly design the best time-series schema that fits your application’s SLAs and requirements.

application이 실제 환경에 구축되고, 수 TB의 크기가 되면, resource 관점에서 볼때, 큰 변화가 발생할 수 있다. 6TB 의 sensor data가 있고, 초당 5만개의 insert 속도로 새로운 data가 축적되는 시나리오를 생각해 보자. read 성능에 문제가 발생하고, database를 제대로 확장하지 못한 것을 알게 된다. appplication의 downtime을 감내하지 않으려면, 이 설정에서 schema를 변경(원래의 storage에서 bucket storage로 옮기는 것 같은)하려면, application을 새로운 scheman로 옮기기 위해 shims, 임시 staging area, 모든 종류의 임시 솔루션등이 필요하다. 이 이야기의 핵심은 증가에 대한 계획을 마련하고 application의 SLA와 요구사항에 적합한 최적의 시계열 schema를 적절히 design하는 것이다.

This article analyzed two different schema designs for storing time-series data from stock prices. Is the schema that won in the end for this stock price database the one that will be the best in your scenario? Maybe. Due to the nature of time-series data and the typical rapid ingestion of data the answer may in fact be leveraging a combination of collections that target a read or write heavy use case. The good news is that with MongoDB’s flexible schema, it is easy to make changes. In fact you can run two different versions of the app writing two different schemas to the same collection. However, don’t wait until your query performance starts suffering to figure out an optimal design as migrating TBs of existing documents into a new schema can take time and resources, and delay future releases of your application. You should undertake real world testing before commiting on a final design. Quoting a famous proverb, “Measure twice and cut once.”

이 게시물에서는 주식 가격이라는 시계열 data를 저장하는 2가지 다른 시계열 schema를 분석하였다. 이 주식 가격 database에서 얻은 schema가 가장 좋을까? 그럴지도 모른다. 시계열 data의 특성과 일반적인 data의 빠른 수집으로 인해, 실제로 사용량이 많은 read/write를 대상으로 하는 collection의 조합을 활용할 수 있다. 좋은 점은 MingoDB의 유연한 schema를 활용하면 쉽게 변경할 수 있다는 점이다. 실제로 2개의 다른 schema를 동일한 collection에 작성하는 2개의 다른 version의 app을 실행할 수 있다. 그러나, 수 TB의 기존 document를 새로운 schema로 migration하면 시간과 resource가 필요할 수 있고, application의 향후 release가 지연될 수 있으므로, query 성능이 저하되기 시작할 때까지, 최적의 desigin을 찾는 것을 기다리지는 말자. 최종 design을 적용하기 전에 실전 테스트를 수행해야 한다. "두 번 측정하고 한번 자르자"라는 유명한 격언이 있다.

In the next blog post, “Querying, Analyzing, and Presenting Time-Series Data with MongoDB,” we will look at how to effectively get value from the time-series data stored in MongoDB.

다음 게시물인 “Querying, Analyzing, and Presenting Time-Series Data with MongoDB” 에서, MongoDB에 저장된 시계열 data에서 효율적으로 값을 얻는 방법을 살펴볼 것이다.

Key Tips:

The MMAPV1 storage engine is deprecated, so use the default WiredTiger storage engine. Note that if you read older schema design best practices from a few years ago, they were often built on the older MMAPV1 technology.
MMAPV1 storage engine은 deprecate되었으므로. 기본인 WiredTiger storage engine을 사용하자. 몇 년전의 이전 schema design 모범 사례를 읽어보면, 기존의 MMAPV1 기술을 기반으로 구축된 경우가 많다.
Understand what the data access requirements are from your time-series application.
시계열 application의 data access 요구 사항을 이해하자.
Schema design impacts resources. “Measure twice and cut once” with respect to schema design and indexes.
schema design은 resource에 영향을 미친다. schema design과 index에 대해서는 “두 번 측정하고 한 번 자르자"를 기억하자.
Test schema patterns with real data and a real application if possible.
가능하다면, 실제 data와 application으로 schema pattern을 테스트 하자.
Bucketing data reduces index size and thus massively reduces hardware requirements.
data bucketing은 index 크기를 줄여, HW 요구사항을 대폭 감소시킨다.
Time-series applications traditionally capture very large amounts of data, so only create indexes where they will be useful to the app’s query patterns.
시계열 application은 전통적으로 매우 많은 data를 수집하므로, app의 query pattern에 유용한 index만 생성하자.
Consider more than one collection: one focused on write heavy inserts and recent data queries and another collection with bucketed data focused on historical queries on pre-aggregated data.
하나 이상의 collection을 고려하자. 많은 insert와 최근 data query에 집중하는 하나와, 사전 집계된 data에 대한 과거 query에 집중하는 bucket data를 가진 또 다른 collection
When the size of your indexes exceeds the amount of memory on the server hosting MongoDB, consider horizontally scaling out to spread the index and load over multiple servers.
index의 크기가 MongoDB를 가진 server의 memory보다 클 경우, 수평 확장을 고려하여 index와 부하를 여러 서버에 분산하자.
Determine at what point data expires, and what action to take, such as archival or deletion.
data 만료 시점, archive, 삭제 같은 해야 할 작업을 결정하자.

원문 : Time Series Data and MongoDB: Part 2 – Schema Design Best Practices

2018.09.06 - 번역 - Time Series Data and MongoDB: Part 1 – An Introduction

drscg — Mon, 21 Jan 2019 17:58:57 +0900

Time-series data is increasingly at the heart of modern applications - think IoT, stock trading, clickstreams, social media, and more. With the move from batch to real time systems, the efficient capture and analysis of time-series data can enable organizations to better detect and respond to events ahead of their competitors, or to improve operational efficiency to reduce cost and risk. Working with time series data is often different from regular application data, and there are best practices you should observe. This blog series seeks to provide these best practices as you build out your time series application on MongoDB:

IoT, 주식 거래, clickstreams(사용자가 인터넷에서 보내는 시간 동안 방문한 웹사이트를 기록한 것), SNS등의 현대의 application의 중심에는 시계열(time-series) data가 점차 자리잡고 있다. batch에서 실시간 시스템으로의 이동을 통해, 시계열 data의 효율적인 저장과 분석을 통해, 기업은 그들의 경쟁사보다 앞서서 event를 감지하고 대응하거나 운영 효율성을 개선하여 비용이나 위험을 줄일 수 있다. 시계열 data를 사용하는 것은 흔히 일반 application과 다르고, 모범 사례를 준수해야 한다. 이 게시물 시리즈는 MongoDB에 시계열 application을 구축할 경우, 다음과 같은 모범 사례를 제공하고자 한다.

Introduce the concept of time-series data, and describe some of the challenges associated with this type of data
시계열 data의 개념을 소개하고, 이런 유형의 data와 관련된 당면 과제를 설명한다.
How to query, analyze and present time-series data
시계열 data를 query, analyze, 표시하는 방법
Provide discovery questions that will help you gather technical requirements needed for successfully delivering a time-series application.
시계열 application을 성공적으로 구축하는데 필요한 기술적인 요구사항을 수집하는데 도움이 되는 의문점을 제공한다.

What is time-series data?

While not all data is time-series in nature, a growing percentage of it can be classified as time-series – fueled by technologies that allow us to exploit streams of data in real time rather than in batches. In every industry and in every company there exists the need to query, analyze and report on time-series data. Consider a stock day trader constantly looking at feeds of stock prices over time and running algorithms to analyze trends in identify opportunities. They are looking at data over a time interval, e.g. hourly or daily ranges. A connected car company might obtain telemetry such as engine performance and energy consumption to improve component design, and monitor wear rates so they can schedule vehicle servicing before problems occur. They are also looking at data over a time interval.

모든 data가 본질적으로 시계열인 것은 아니지만, 점점 많은 data가 시계열로 분류될 수 있다. 즉, batch가 아닌 실시간으로 data stream을 이용할 수 있게 하는 기술에 힘입어 가속화되었다. 모든 회사와 기업에서, 시계열 data에 대한 query, analyze, report가 필요하다. 기회를 찾기 위해, 시간에 따른 주식 가격 자료를 끊임없이 검토하고, 동향을 분석하기 위해 algorithms을 실행하는 주식 거래자를 생각해 보자. 그들은 일정한 시간별(시간별, 일별 등)로 data를 검토한다. 자동차 관련 회사는 부품 설계 개선을 위해 엔진 성능과 에너지 소비같은자료를 얻을 수 있으며, 문제가 발생하기 전에 차량 서비스를 예약할 수 있도록 마모율을 모니터할 수 있다.

Why is time-series data challenging?

Time-series data can include data that is captured at constant time intervals – like a device measurement per second – or at irregular time intervals like those generated from alerts and auditing event use cases. Time-series data is also often tagged with attributes like the device type and location of the event, and each device may provide a variable amount of additional metadata. Data model flexibility to meet diverse and rapidly changing data ingestion and storage requirements make it difficult for traditional relational (tabular) database systems with a rigid schema to effectively handle time-series data. Also, there is the issue of scalability. With a high frequency of readings generated by multiple sensors or events, time series applications can generate vast streams of data that need to be ingested and analyzed. So platforms that allow data to be scaled out and distributed across many nodes are much more suited to this type of use case than scale-up, monolithic tabular databases.

시계열 data에는 일정한 시간 간격(초당 장치 측정) 또는 경고나 감시 event 사례에서 생성된 불규칙한 시간 간격으로 얻은 data를 포함할 수 있다. 시계열 data는 흔히 장치의 유형, event의 위치 같은 속성을 가질 수 있고, 각 장치는 가변적인 추가 metadata를 가질 수도 있다. 다양하고 빠르게 변화하는 data 수집과 저장소 요구사항을 충족하는 data model의 유연성 때문에, 엄격한 schema를 사용하는 전통적인(테이블 형태의) database system은 시계열 data를 효율적으로 처리하기가 어렵다. 또한, 확장성 문제도 있다. 복수의 sensor나 event에 의해 생성되는 data를 읽는 경우가 많다면, 시계열 application은 수집과 분석이 필요한 방대한 data stream을 생성할 수 있다. 따라서, data를 여러 node에 걸쳐 확장하고 분산할 수 있는 platform이, scale-up된 단일 테이블 형태의 database보다, 이러한 유형의 사례에 훨씬 더 적합하다.

Time series data can come from different sources, with each generating different attributes that need to be stored and analyze. Each stage of the data lifecycle places different demands on a database – from ingestion through to consumption and archival.

시계열 data는 다양한 source를 가질 수 있고, 각각이 저장, 분석되어야 하는 다양한 속성을 생성할 수 있다. data lifecycle의 각 단계는 수집에서 사용, 보관까지 database에 대해 다양한 요구사항을 가진다.

During data ingestion, the database is primarily performing write intensive operations, comprising mainly inserts with occasional updates. Consumers of data may want to be alerted in real time when an anomaly is detected in the data stream during ingestion, such as a value exceeding a certain threshold.
data 수집 중에는, database는 주로 write 집약적인 작업(가끔 updates를, 주로 inserts로 구성된)을 수행한다. data 사용자는 수집 중에 data stream에 이상 징후(예: 특정 임계값을 초과하는 값)가 발견되면, 실시간으로 경고를 받고자 할 수도 있다.
As more data is ingested consumers may want to query it for specific insights, and to uncover trends. At this stage of the data lifecycle, the workload is read, rather than write heavy, but the database will still need to maintain high write rates as data is concurrently ingested and then queried.
사용자는 data가 더 많이 수집됩에 따라, 어떤 통찰력과 트렌드를 알기 위해 query를 할 수도 있다. data lifecycle의 이 단계에서, 많은 write 작업보다는 read 작업이 수행되지만, data가 동시에 수집되고 query되므로, database는 여전히 높은 write 속도를 유지해야 한다.
Consumers may want to query historical data and perform predictive analytics leveraging machine learning algorithms to anticipate future behavior or identify trends. This will impose additional read load on the database.
사용자는 과거 data를 query하고, machine learning algorithms을 활용하여, 미래 행동을 예측하거나 트렌드를 파악하기 위해 예측 분석을 수행하려 할 수도 있다. 이것은 database에 추가적인 read 부하를 줄 것이다.
In the end, depending on the application’s requirements, the data captured may have a shelf life and needs to be archived or deleted after a certain period of time.
마지막으로, application의 요구 사항에 따라, 수집된 data는 보관 기간이 있을 수 있어, 일정 기간 후에 archive되거나 삭제되어야 한다.

As you can see working with time-series data is not just simply storing the data, but requires a wide range of data platform capabilities including handling simultaneous read and write demands, advanced querying capabilities, and archival to name a few.

시계열 data로 작업을 통해 알 수 있는 것은 단순히 data를 저장하는 것이 아니라, 동시 read/write 처리, 고급 query 기능 및 archive와 같은 광범위한 data platform 기능이 요구된다는 점이다.

Who is using MongoDB for time-series data?

MongoDB provides all the capabilities needed to meet the demands of a highly performing time-series applications. One company that took advantage of MongoDB’s time series capabilities is Quantitative Investment Manager Man AHL.

MongoDB는 매우 성능이 뛰어난 시계열 application의 요구 사항을 만족시키는 데 필요한 모든 기능을 제공한다. MongoDB의 시계열 기능을 활용한 회사는 Quantitative Investment Manager Man AHL이다.

Man AHL’s Arctic application leverages MongoDB to store high frequency financial services market data (about 250M ticks per second). The hedge fund manager’s quantitative researchers (“quants”) use Arctic and MongoDB to research, construct and deploy new trading models in order to understand how markets behave. With MongoDB, Man AHL realized a 40x cost saving when compared to an existing proprietary database. In addition to cost savings, they were able to increase processing performance by 25x over the previous solution. Man AHL open sourced their Arctic project on GitHub.

Man AHL의 Arctic application은 MongoDB를 활용하여, 매우 빈번하게 발생하는 금융 서비스 시장의 data(초당 약 250M ticks)를 저장하였다. hedge fund manager의 연구원(금융시장분석가)은 시장이 행동하는 방식을 이해하기 위하여, Arctic과 MongoDB를 사용하여 새로운 거래 모델을 연구, 구성, 배치하였다. MongoDB를 통해, Man AHL은 기존의 독점 database에 비하여 40배의 비용 절감 효과를 실현하였다. 비용 절감 외에도, 기존의 솔루션 대비 처리 성능을 25배 향상할 수 있었다. Man AHL은 GitHub에 Arctic project를 open하였다.

Bosch Group is a multinational engineering conglomerate with nearly 300,000 employees and is the world’s largest automotive components manufacturer. IoT is a strategic initiative at Bosch, and so the company selected MongoDB as the data platform layer in its IoT suite. The suite powers IoT applications both within the Bosch group and in many of its customers in industrial internet applications, such as automotive, manufacturing, smart city, precision agriculture, and more. If you want to learn more about the key challenges presented by managing diverse, rapidly changing and high volume time series data sets generated by IoT platforms, download the Bosch and MongoDB whitepaper.

Bosch Group은 약 30만명의 직원을 가진 다국적 엔지니어링 대기업으로, 세계 최대의 자동차 부품 제조업체이다. IoT는 Bosch의 전략적 결정으로, MongoDB를 IoT 제픔군에서 data platform으로 선택했다. Bosch 그룹과 자동차 제조, smart city, 정밀 농업 등의 산업용 internet application의 많은 사용자들에게 IoT application을 제공한다. IoT platform에서 생성되는 다양하고 빠르게 변화하는 대용량 시계열 data에 대해 더 많이 알고 싶다면, Bosch와 MongoDB 백서를 내려받자.

Siemens is a global company focusing on the areas of electrification, automation and digitalization. Siemens developed “Monet,” a platform backed by MongoDB that provides advanced energy management services. Monet uses MongoDB for real time raw data storage, querying and analytics.

siemens는 전기, 자동화, 디지털 분야에 주력하는 글로벌 기업이다. siemens는 고급 에너지 관리 서비스를 제공하는 MongoDB 기반의 “Monet” platform을 개발하였다. 실시간 원시 data 저장, query, 분석을 위해, Monet은 MongoDB를 사용한다.

Focus on application requirements

When working with time-series data it is imperative that you invest enough time to understand how data is going to be created, queried, and expired. With this information you can optimize your schema design and deployment architecture to best meet the application’s requirements.

시계열 data로 작업할 경우에는, data의 생성, query, 만료 방법을 이해하는데 충분한 시간을 투자해야 한다. 이 정보를 사용하여 application의 요구사항을 가장 잘 충족할 수 있도록 schema design과 배포 구조를 최적화할 수 있다.

You should not agree to performance metrics or SLAs without capturing the application’s requirements.

application의 요구사항을 파악하지 않고 성능 metric이나 SLA에 동의해서는 안된다.

As you begin your time-series project with MongoDB you should get answers to the following questions:

MongoDB로 시계열 project를 시작할 경우, 다음과 같은 질문에 대한 답을 얻어야 한다.

Write workload

What will the ingestion rate be? How many inserts and updates per second?
수집 속도는 얼마인가? 초당 insert, update 수는 얼마나 되나?

MongoDB auto-sharding

How many simultaneous client connections will there be?
동시 client 연결 수는?

Do you need to store all raw data points or can data be pre-aggregated? If pre-aggregated, what summary level of granularity or interval is acceptable to store? Per minute? Every 15 minutes?
모든 원시 데이터를 저장해야 하거나 data가 사전 집계될 수 있는가? 사전집계된 경우, 어떤 간격으로 저장될 수 있는가? 분별로? 15분마다?

What is the size of data stored in each event?
각 event에서 저장되는 data 크기는 얼마인가?

MongoDB GridFS

Read workload:

How many read queries per second?
초당 read query의 수는?

indexes

Will clients be geographically dispersed or located in the same region?
clients가 지리적으로 분산되어 있거나 동일 지역에 위치하는가?

read-only secondary replicas

read 전용 secondary replicas

What are the common data access patterns you need to support? For example, will you retrieve data by a single value such as time, or do you need more complex queries where you look for data by a combination of attributes, such as event class, by region, by time?
지원해야 하는 일반적인 data access pattern은 무엇인가? 예를 들어, 시간 같은 단일 값으로 data를 검색하는가? 또는 시간이나 지역별로 event class 같은 속성의 조합으로 data를 찾는 더 복잡한 query가 필요한가?

What analytical libraries or tools will your consumers use?
사용자가 사용할 분석 라이브러리나 tool은?

MongoDB Spark Connector

Python

Matlab

MongoDB Spark Connector

Python

Matlab

Does your organization use BI visualization tools to create reports or analyze the data?
BI 시각화 tool을 사용하여 보고서를 작성하거나 data를 분석하는가?

Data retention and archival:

What is the data retention policy? Can data be deleted or archived? If so, at what age?
data 보존 정책은? data를 삭제하거나 archive하는가? 기간은?
If archived, for how long and how accessible should the archive be? Does archive data need to be live or can it be restored from a backup?
archive한다면, 기간은 얼머나 되며, 어떻게 접근 가능한가? archive data가 실시간이어야 하는가? backup에서 복구될 수 있는가?

Security:

What users and roles need to be defined, and what is the least privileged permission needed for each of these entities?
어떤 사용자와 역활을 정의해야 하는가? 그리고, 이들 각각에 대해 필요한 최소한의 권한은?
What are the encryption requirements? Do you need to support both in-flight (network) and at-rest (storage) encryption of time series data?
암호화 요구 사항은? 시계열 data의 network, storage 암호화를 지원해야 하는가?
Do all activities against the data need to be captured in an audit log?
data에 대한 모든 activities를 audit log에 저장해야 하는가?
Does the application need to conform with GDPR, HIPAA, PCI, or any other regulatory framework?
application이 GDPR, HIPAA, PCI 또는 기타 규제 framework을 준수해야 하는가?

security configurations

While not an exhaustive list of all possible things to consider, it will help get you thinking about the application requirements and their impact on the design of the MongoDB schema and database configuration. In the next blog post, "Part 2: Schema design for time-series data in MongoDB” we will explore a variety of ways to architect a schema for different sets of requirements, and their corresponding effects on the application’s performance and scale. In part 3, "Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data", we will show how to query, analyze and present time-series data.

고려해야 할 모든 사항에 대한 전체 목록은 아니지만, application 요구 사항과 그것이 MongoDB schema와 database 구성에 미치는 영향에 대해 생각해 보는데, 도움이 될 것이다. 다음 게시물인 "Part 2: Schema design for time-series data in MongoDB”에서, 다양한 요구 사항에 대한 schema를 설계하는 다양한 방법과 그 요구 사항들이 application의 성능과 규모에 미치는 영향을 알아보자. part 3인, "Time Series Data and MongoDB: Part 3 – Querying, Analyzing, and Presenting Time-Series Data"에서, 시계열 data를 query, analyze, 표시하는 방법을 설명한다.

원문 : Time Series Data and MongoDB: Part 1 – An Introduction

2018.10.23 - 번역 - Space Savings: A Lesser Known Benefit of Index Sorting in Elasticsearch ...

drscg — Tue, 8 Jan 2019 10:09:59 +0900

In Elasticsearch 6.0, we released a new feature called index sorting. Read up more on this on the linked blog, but in short, what this does is to take the documents at index time and sort them by a key or set of keys in an order of your choosing. This has a few advantages that we’ve talked about:

Elasticsearch 6.0 에서 index sorting이라는 새로운 기능이 출시되었다. link된 게시물에서 이에 대해 자세히 읽어 보자. 간단히 말하자면, index시에 document를 가져와 선택한 key나 key의 집합으로 정렬하는 것이다. 여기에는 다음과 같은 몇 가지 장점이 있다.

If you ask Elasticsearch to return a set of results sorted by the same key you’ve sorted the index on, Elasticsearch doesn’t need to do the sorting of results at query time. They’re already pre-sorted!
Elasticsearch에서 index를 정렬한 것과 동일한 key로 정렬된 결과를 반환하도록 요청하면, Elasticsearch는 query시에 결과를 정렬하지 않아도 된다. 이미 미리 정렬되어 있다.
If you don’t need the total hit count and you’re sorting by the sort key, Elasticsearch can actually short circuit the query once it’s found enough hits to meet your request. This can result in unbounded query performance improvements.
전체 수가 필요하지 않고 정렬 key로 정렬하려면, Elasticsearch는 request에 부합하는 hit를 발견하면, 실제로 query를 중단시킬 수 있다. 이로 인해 무한한 query 성능 향상을 기대할 수 있다.
If you have queries that use ANDs across different fields, index sorting on those fields can end up grouping them in such a way that Elasticsearch can skip large blocks of documents that don’t match, which can also make search faster.
서로 다른 query간에 AND를 사용하는 query가 있을 경우, 해당 field에 대한 index sorting은 Elasticsearch가 일치하지 않는 document의 큰 block을 건너뛸 수 있도록 하는 방식으로 그룹화 하여, search 속도를 더 높일 수 있다.

In short, index sorting can make search faster in some cases: especially cases where you have a few common ways people are searching and sorting your documents. What isn’t often talked about is that index sorting can also reduce the amount of disk your indices are using. I’ll talk about why and how here.

즉, index sorting을 사용하면, 특정 경우에 search 속도를 더 빠르게 할 수 잇다. 사람들이 document를 search하고 정렬하는 몇 가지 공통적인 방법이 있는 경우 특히 그렇다. 자주 언급되지 않는 사항은, index sorting을 사용하면, index가 사용하고 있는 disk의 양을 줄일 수도 있다는 점이다. 그 이유와 방법에 대해 이야기 하겠다.

Caution: Index Sorting Isn’t for Everyone

Before I talk about what happens, I do want to mention once again that index sorting isn’t for everyone. It causes the sort action to happen at index time. Sorting is an expensive operation, so if indexing speed is a primary concern, exercise caution before turning it on. It can slow write performance by as much as 40-50%. So if indexing throughput is a primary concern, as it often is in high-volume logging, metrics, and security analytics use cases, index sorting probably isn’t for you. It can be useful if you have a lower index rate, if query speed is the most important thing to your use case, or if you have a regular reindex process anyway that acts during off-peak-indexing times.

이야기하기 전에, index sorting이 모두에게 적절하지는 않다라는 사실을 다시 한번 이야기한다. 정렬 동작이 index시에 발생하기 때문이다. 정렬은 비용이 많이 발생하는 연산이므로, index 속도가 중요하다면, 바꾸기 전에 주의하자. 쓰기 성능이 40-50% 정도 낮아질 수 있다. 따라서, 대용량 logging, 분석, 보안 분석 사례처럼, index 처리량이 중요하다면, index sorting은 아마도 여러분에게 적당하지 않다. index 속도가 낮거나 query 속도가 가장 중요하거나, 사용량이 적은 시간에 작동하는 정기적인 reindex process의 경우, 이것이 유용할 수 있다.

Examining Potential Sort Orders: An Example

Suppose I run an Elasticsearch instance that’s used for product search. Imagine that I have a set of documents that, at index time, look something like the following (I’ll flatten into a matrix just for ease of viewing):

제품 search를 위해 사용되는 Elasticsearch instance를 실행한다고 가정해 보자. index시에 다음처럼 보이는 document 집합을 가지고 있다고 가정해 보자. 보기 쉽게 표로 만들었다.

Product ID	Product Category	Product Color	Price
206f467b-8cfe	Shoes	Red	$97.00
4f89fbec-acc3	Jackets	Black	$120.50
47771396-dfe3	Jackets	Grey	$170.10
c6c8fbdf-651b	Hats	Yellow	$15.00
dc18c426-0eb3	Shoes	Red	$107.20
ee304259-df57	Jackets	Black	$88.00
9332c0ac-e55e	Shoes	Black	$49.00
30e96765-52a1	Hats	Blue	$11.00
811cc8ca-d6bb	Jackets	Blue	$92.99

And now suppose we wanted to enable index sorting. What would we sort by? We have some options: product category, product color, and/or price may be interesting. If user searches are almost always just sorted by price and we don’t have filters for category or color, sorting by price may make the most sense for a sort key. However, it’s probably likely that users are at least selecting a category before finding the cheapest item, and they also may have preference for a color. Let’s sort by category ascending, color ascending, and then price ascending.

그리고, 이제 index sorting을 활성화한다고 가정해 보자. 무엇으로 정렬할까? product category, product color, 그리고 price가 괜찮을 것 같다. 사용자 search가 거의 항상 price로 정렬되고, category나 color로 filter하지 않는다고 하면, price에 의한 정렬이 정렬 key에 가장 적절할 것이다. 그러나, 사용자는 가장 저렴한 제품을 검색하기 전에 최소한 하나의 category를 선택하거나 선호하는 color를 가질 수 있다. category 오름차순, color 오름차순, price 오름차순으로 정렬하자.

"sort.field" : ["product_category", "product_color", "price"], "sort.order" : ["asc", "asc", "asc"]

The sorted index looks something like this:

정렬된 index는 다음과 같다.

Product ID	Product Category	Product Color	Price
30e96765-52a1	Hats	Blue	$11.00
c6c8fbdf-651b	Hats	Yellow	$15.00
ee304259-df57	Jackets	Black	$88.00
4f89fbec-acc3	Jackets	Black	$120.50
811cc8ca-d6bb	Jackets	Blue	$92.99
47771396-dfe3	Jackets	Grey	$170.10
9332c0ac-e55e	Shoes	Black	$49.00
206f467b-8cfe	Shoes	Red	$97.00
dc18c426-0eb3	Shoes	Red	$107.20

A few interesting things now happen, which I’ll explain by example:

이제 몇 가지 흥미로운 점이 나타난다. 예제로 설명하겠다.

If I ask Elasticsearch for the top 2 cheapest shoes sorted by price and I don’t ask it for a total hit count of all shoes, it needs to find the block of shoes, which it can do efficiently by skipping past all of the other categories. And once it’s found just 2 results, it can stop processing the rest of the index and return. Note that in order for this to work, you must include every element of the sort order in the index, even if you have filters that match.
price로 정렬한 상위 2개의 가장 싼 shoes를 Elasticsearch에 요청하고, 일치하는 모든 shoes의 수를 요청하지 않는다면, 다른 모든 category를 생략하여 효율적으로 할 수 있도록, shoes의 block을 찾아야 한다. 그리고, 2개의 결과를 찾자마자 index의 나머지 부분을 처리하는 것을 중단하고 return할 수 있다. 이를 위해서는 일치하는 filter가 있더라도, index에 정렬 순서의 모든 요소를 포함해야 한다.
If I ask Elasticsearch for product_category:Jackets AND product_color:Black, Elasticsearch can skip past all the hats and all the shoes, and within Jackets, it can find the “Black” ones and once it’s done looking at those, it can skip past all of the other colors efficiently.
product_category:Jackets AND product_color:Black를 Elasticsearch에 요청한다면, Elasticsearch는 모든 hats과 shoes를 생략할 수 있고, Jackets내에서, “Black”을 찾을 수 있고, 일단 해당하는 것을 다 찾으면, 다른 모든 colors를 효율적으로 생략할 수 있다.
Elasticsearch uses compression significantly behind the scenes. The compression works when there are repeated values and it does so most efficiently when the repeated values are near each other in the index. By having all of the “jackets” or “colors” next to one another, those can be efficiently compressed on disk. That means less disk space, but it also means the operating system will be able to fit more into the filesystem cache, which will make things even faster.
Elasticsearch는 압축을 많이 사용한다. 압축은 반복되는 값이 있을 경우 동작하며, index에서 반복되는 값이 서로 가까이 있을 경우 가장 효울적으로 동작한다. 모든 “jackets” 이나 “colors” 를 서로 옆에 두면, disk에서 효율적으로 압축될 수 있다. 즉, disk 공간이 적게 소모되는 것을 의미하지만, 또한, OS가 filesystem cache에 더 잘 적응할 수 있다는 것을 의미하며, 이는 더 빠른 속도를 가져온다.

In general, it’s best practice to use sort orders of increasing cardinality so that we can get the benefit of as many repeated values in a row as possible.

일반적으로, row에서 가능한 한 많은 반복된 값의 이점을 얻을 수 있도록, cardinality가 증가하는 정렬 순서를 사용하는 것이 가장 좋다.

How Much Disk Space Will I Save?

So how much disk space will you save by turning on index sorting? As with many things in life, the answer is “it depends.” One of the big things it depends on is the cardinality of the field you sort by. However, the disk savings can be substantial. Last weekend, I decided to move some IoT/home automation data I’ve been using for a personal project off an old machine and onto a new one. There are faster ways to do this data migration like snapshot/restore, but I had the time to do a reindex and was interested to see how much savings index sorting may provide. I first did the remote reindex into an unsorted index:

그렇다면, idnex sorting을 사용하면 disk 공간을 얼마나 절약할 수 있을까? 만사가 그렇지만, 답은 "경우에 따라 다르다" 이다. 가장 큰 요소는 정렬하려는 field의 cardinality이다. 그러나 disk 절약 효과는 상당할 수 있다. 지난 주말, 개인 프로젝트에서 사용하던 IoT/home automation data를 새로운 machine으로 옮기기로 했다. snapshot/restore 처럼 data migration을 하는 더 빠른 방법이 있지만, reindex할 시간이 있었고 index sorting을 통해 얼마나 많은 절감 효과가 있는지 알고 싶었다. 먼저, 정렬되지 않은 index에 원격으로 reindex했다.

status    index           pri    docs.count    docs.deleted    pri.store.size 
open      devices-2017    1      33310674      0               4.2gb

It’s a little over 30 devices and each sends its status back about once every 30 seconds, so the total index rate is about 1 document per second. I’m never anywhere close to being throttled on the indexing side, and I’d have to massively increase the index rate or number of devices for that to change. It seems like a reasonable candidate for index sorting. The data consists of hardware IDs, hardware names, times, and various sensor readings like the temperature or whether the device is on or off at the time or what some other sensor level is. I sorted the index by device ID and then by time, my thinking being that it’s likely that for a given device, there’s a reasonably high chance that there will be similar or the same values around the same time, which may lead to better compression. For example, if a switch is turned into an “on” state at 7:00:00, there’s a pretty high chance that it will be “on” at 7:00:30, 7:01:00, and at least several minutes after, and that should compress nicely. The sorted index stats show…

30개가 약간 넘는 장치가 있고, 각각은 매 30초마다 상태를 전송한다. 따라서, 총 index 속도는 초당 약 1개의 document이다. 이를 변경하기 위해서는, index쪽에서는 조절할 수 있는 곳이 거의 없었고, index 속도나 장치의 수를 크게 늘려야 한다. index sorting의 적절한 후보인 것 같다. data는 HW ID, name, 시간, 온도나 해당 시점에 장치의 on/off 또는 기타 sensor 수준으로 구성된다. 특정 장치에서, 동일한 시간대에는 비슷하거나 동일한 값이 있을 가능성이 상당히 높기 때문에, 압축이 더 잘될 수 있다고 생각해, index를 장치 ID, 그 다음에 시간으로 정렬했다. 예를 들자면, 7:00:00에 switch가 "on" 상태가 되면, 7:00:30, 7:01:00, 그리고 적어도 몇 분 후까지는 "on" 일 가능성이 상당히 높다. 그리고, 그것은 잘 압축될 것이다. 정렬된 index 상태는 다음과 같다.

status    index           pri    docs.count     docs.deleted    pri.store.size
open      devices-2017    1      3310674        0               2.5gb

About a 40% disk savings!

약 40%의 disk 절약이다.

Caution Again

At this point, I feel compelled to caution everyone again, because almost everyone would appreciate using 40% less disk for the same data. I’ll sum it up into two quick statements:

이 시점에서 다시 한번 모두에게 경고해야 한다고 생각한다. 왜냐하면, 거의 모든 이들이 동일한 data에 40% disk 절약을 높이 평가할 것이기 때문이다. 2가지로 요약하겠다.

Your mileage will vary. I used index sorting on another dataset and found a 20% savings. Be thoughtful about what fields you sort on.
이득은 다양할 것이다. 다른 data 집합에 index sorting을 사용했더니, 20%를 절약했다. 정렬하려는 field에 대해 신중하게 생각하자.
Your index rate will be slowed. If the speed of indexing is really important to you, e.g. you’re running in a high volume logging or metrics use case, you’re likely sensitive to the number of documents you can get indexed in a short amount of time and it may not be a good choice to turn on index sorting as a result.
index 속도가 느리게 될 것이다. index 속도가 중요(예: 대용량 logging, metric 사용 사례)하다면, 짧은 시간에 index할 수 있는 document의 수에 민감할 수 있어, 결과적으로 index sorting을 사용하는 것은 좋은 선택이 아닐 수 있다.

If you’re much more sensitive to disk space than index speed or your index volumes are low enough that you’re not limited by index speed, it may be interesting to see if index sorting is worth it for you.

index 속도보다 disk 공간에 훨씬 더 민감하거나, index 양이 index 속도에 의해 제한되지 않을 만큼 충분히 적다면, index sorting이 쓸만한지 알아보는 것이 좋다.

원문 : Space Savings: A Lesser Known Benefit of Index Sorting in Elasticsearch

2018.10.18 - 번역 - Efficient Duplicate Prevention for Event-Based Data in Elasticsearch ...

drscg — Mon, 7 Jan 2019 14:35:08 +0900

The Elastic Stack is used for a lot of different use cases. One of the most common is to store and analyze different types of event or time-series based data, e.g. security events, logs, and metrics. These events often consist of data linked to a specific timestamp representing when the event occurred or was collected and there is often no natural key available to uniquely identify the event.

Elastic Stack은 다양한 경우에 사용된다. 가장 일반적인 경우 중 하나는 다양한 유형의 event나 시간 기반의 data(보안 event, log, metric 등)을 저장하고 분석하는 것이다. 이들 event는 흔히 event가 발생하거나 수집된 시간을 나타내는 특정 timestamp에 연결된 data로 구성된다. 그리고, event를 고유하게 식별할 수 있는 key는 없는 경우가 많다.

For some use cases, and maybe even types of data within a use case, it is important that the data in Elasticsearch is not duplicated: Duplicate documents may lead to incorrect analysis and search errors. We started looking at this last year in the introduction to duplicate handling using Logstash blog post, and in this one we will dig a bit deeper and address some common questions.

일부 사용 사례와 그 안의 event data 유형에서, Elasticsearch내의 data가 중복되지 않는 것이 중요하다. docoument가 중복되면, 올바르지 않은 분석과 search 오류가 발생한다. 작년에 introduction to duplicate handling using Logstash 게시물에서 이를 살펴보았는데, 여기에서 좀 더 깊이 살펴보고 몇 가지 공통적인 질문에 답할 것이다.

Indexing into Elasticsearch

When you index data into Elasticsearch, you need to receive the response to be sure that the data has been successfully indexed. If an error, e.g. connection error or node crash, prevents you from receiving it, you can not be sure whether any of the data has been indexed or not. When clients encounter this type of scenario, the standard way to ensure delivery is to retry, which may lead to the same document being indexed more than once.

data를 Elasticsearch에 index할 때, data가 성공적으로 index되었는지를 확인하려면 response를 받아야 한다. 오류(연결 오류, node 장애 등)로 인해 response를 받지 못하면, data가 index되었는지 여부를 알 수 없다. client가 이런 종류의 문제를 접하는 경우, 전송을 보장하는 표준적인 방법은 다시 시도하는 것인데, 이로 인해 동일한 document가 두 번 이상 index될 수 있다.

As described in the blog post on duplicate handling, it is possible to get around this by defining a unique ID for each document in the client rather than having Elasticsearch automatically assign one at indexing time. When a duplicate document is written to the same index, this will result in an update instead of the document being written a second time, which prevents duplicates.

중복을 다루는 게시물에서 설명했듯이, index시에 Elasticsearch에서 자동으로 고유한 ID를 할당하는 대신, client에서 각 document에 대해 고유한 ID를 정의하여 이 문제를 해결할 수 있다. 중복 document가 동일한 index에 쓰여지면, document가 2번째로 작성되는 대신 update가 발생하여, 중복이 방지된다.

UUIDs vs hash-based document ids

When deciding on what type of identifier to use, there are two main types to choose from.

어떤 형태의 ID를 사용할 것인가를 결정해야 할 경우, 2가지 방법이 있다.

Universally Unique Identifiers (UUIDs) are identifiers based on 128-bit numbers that can be generated across distributed systems, while for practical purposes being unique. This type of identifier generally has no dependence on the content of the event it is associated with.

Universally Unique Identifiers (UUIDs)는 분산 시스템에서 생성될 수 있는 128-bit 숫자 기반의 구분자로서, 실제로 유일하다. 이런 유형의 ID는 일반적으로 관련된 event의 내용과는 무관하다.

In order to use UUIDs to avoid duplicates, it is essential that the UUID is generated and assigned to the event before the event passes any boundary that does guarantee that the event is being delivered exactly once. This in practice often means that the UUID must be assigned at the point of origin. If the system where the event originates cannot generate a UUID, a different type of identifier may need to be used.

UUID를 사용하여 중복을 피하기 위해서는, event가 정확히 한 번 전송된다는 것을 보장하는 어떤 경계에 event가 전달되기 전에 UUID가 생성되고 event에 할당되어야 한다. 실제 상황에서 이것은 출처에서 UUID가 할당돠어야 함을 의미한다. event가 발생한 시스템에서 UUID를 생성할 수 없는 경우, 다른 형태의 ID를 사용해야 할 수도 있다.

The other main type of identifier are ones where a hash function is used to generate a numeric hash based on the content of the event. The hash function will always generate the same value for a specific piece of content, but the generated value is not guaranteed to be unique. The probability of a hash collision, which is when two different events result in the same hash value, depends on the number of events in the index as well as the type of hash function used and the length of the value it produces. A hash of at least 128 bits in length, e.g. MD5 or SHA1, generally provides a good compromise between length and low collision probability for a lot of scenarios. For even greater uniqueness guarantees, an even longer hash like SHA256 can be used.

다른 주요 유형의 ID는 hash function 을 사용하여 event의 내용을 기반으로 한 numeric hash를 생성하는 것이다. hash function은 특정 내용에 대해서는 항상 동일한 값을 생성하지만 생성된 값은 고유함을 보장하지 않는다. 2개의 다른 event가 동일한 hash 값을 가지는 hash 충돌 확률은 index의 event 수, 사용된 hash function의 유형, 생성된 값의 길이에 따라 다르다. MD5, SHA1 같은 최소 128 bit의 hash는 일반적으로 많은 경우에서 길이와 낮은 충돌 확률 사이의 좋은 절충안이다. 더 큰 유일함을 보장하려면, SHA256 처럼 훨씬 더 긴 hash를 사용할 수 있다.

As a hash-based identifier depends on the content of the event, it is possible to assign this at a later processing stage as the same value will be calculated wherever it is generated. This makes it possible to assign this type of IDs at any point before the data is indexed into Elasticsearch, which allows for flexibility when designing an ingest pipeline.

hash 기반 ID는 event의 내용에 따라 다르므로, 나중에 처리 단계에서 이를 할당하는 것이 가능하다. 어디에서 생성되더라도 동일한 값을 계산하기 때문이다. 이렇게 하면, data를 Elasticsearch에 index하기 전에, 어디에서라도, 이런 유형의 ID를 할당할 수 있어, ingest pipeline 설계시 유연성을 가질 수 있다.

Logstash has support for calculating UUIDs and a range of popular and common hash functions through the fingerprint filter plugin.

logstash는 fingerprint filter plugin 을 통해 UUID와 널리 사용되는 일반적인 hash function의 범위를 계산할 수 있다.

Choosing an efficient document id

When Elasticsearch is allowed to assign the document identifier at indexing time, it can perform optimizations as it knows the generated identifier can not already exist in the index. This improves indexing performance. For identifiers generated externally and passed in with the document, Elasticsearch must treat this as a potential update and check whether the document identifier already exists in existing index segments, which requires additional work and therefore is slower.

Elasticsearch가 index시에 document ID를 할당할 수 있는 경우, 생성된 ID가 index에 존재할 수 없다는 것을 이미 알기 때문에, 최적화를 수행할 수 있다. 이렇게 하면 index 성능이 향상된다. ID를 외부에서 생성하여 document와 함께 전달하는 경우, Elasticsearch는 이것을 잠재적 update로 간주하고, document ID가 기존의 index segment에 이미 존재하는지를 확인해야 하는데, 이는 추가 작업이 필요하고, 따라서 더 느려진다.

Not all external document identifiers are created equal. Identifiers that gradually increase over time based on sorting order generally result in better indexing performance than completely random identifiers. The reason for this is that it is possible for Elasticsearch to quickly determine whether an identifier exists in older index segments based solely on the minimum and maximum identifier value in that segment rather than having to search through it. This is described in this blog post, which is still relevant even though it is getting a bit old.

모든 외부 document ID가 동일하게 생성되는 것은 아니다. 정렬 순서를 기준으로 시간에 따라 점차 증가하는 ID는 완전히 무작위인 ID보다 더 나은 index 성능을 가진다. 그 이유는 Elasticsearch가 ID를 검색하는 대신 최소 최대 ID 값만을 기반으로, 해당 ID가 기존 index segment에 존재하는지 여부를 더 빠르게 판단할 수 있기 때문이다. 이것은 약간 오래되었지만 여전히 관련있는 이 게시물에 설명되어 있다.

Hash-based identifiers and many types of UUIDs are generally random in nature. When dealing with a flow of events where each has a defined timestamp, we can use this timestamp as a prefix to the identifier to make them sortable and thereby increase indexing performance.

hash기반의 ID와 많은 유형의 UUID는 일반적으로 무작위이다. 각 event가 정의된 timestamp를 가진 event flow를 처리하는 경우, 이 timestamp를 ID의 prefix로 사용하여, 정렬 가능하게 하여, index 성능을 증가시킬 수 있다.

Creating an identifier prefixed by a timestamp also has the benefit of reducing the hash collision probability, as the hash value only has to be unique per timestamp. This makes it possible to use shorter hash values even in high ingest volume scenarios.

또한, timestamp를 prefix로 사용한 ID를 생성하면, hash 충돌 확률을 줄일 수 있다. hash 값은 timestamp마다 고유해 지기 때문이다.

We can create these types of identifiers in Logstash by using the fingerprint filter plugin to generate a UUID or hash and a Ruby filter to create a hex-encoded string representation of the timestamp. If we assume that we have a message field that we can hash and that the timestamp in the event has already been parsed into the @timestamp field, we can create the components of the identifier and store it in metadata like this:

fingerprint filter plugin을 사용하여 UUID나 hash를 생성하고, ruby filter를 사용하여 timestamp를 16진수로 encode된 문자열을 생성함으로써, logstash에서 이런 유형의 ID를 생성할 수 있다. hash할 수 있는 message field를 가지고 있고 event의 timestamp가 이미 @timestamp field로 parse되었다도 가정하면, ID 요소를 생성하여, 다음과 같이 metadata에 저장할 수 있다.

fingerprint {
  source => "message"
  target => "[@metadata][fingerprint]"
  method => "MD5"
  key => "test"
}
ruby {
  code => "event.set('@metadata[tsprefix]', event.get('@timestamp').to_i.to_s(16))"
}

These two fields can then be used to generate a document id in the Elasticsearch output plugin:

그런 다음, Elasticsearch의 output plugin에서 이들 2개의 field를 사용하여 document id를 생성할 수 있다.

elasticsearch {
  document_id => "%{[@metadata][tsprefix]}%{[@metadata][fingerprint]}"
}

This will result in a document id that is hex encoded and 40 characters in length, e.g. 4dad050215ca59aa1e3a26a222a9bbcaced23039. A full configuration example can be found in this gist.

이렇게 하면, 16진수로 encode된 길이가 40인 document id(예: 4dad050215ca59aa1e3a26a222a9bbcaced23039)를 얻을 수 있다. 전체 설정 예제는 this gist 에서 볼 수 있다.

Indexing performance implications

The impact of using different types of identifiers will depend a lot on your data, hardware, and use-case. While we can give some general guidelines, it is important to run benchmarks to determine exactly how this affects your use-case.

서로 다른 유형의 ID를 사용하면, data, HW 그리고 사용 사례에 따라 많은 영향을 받는다. 몇 가지 일반적인 가이드라인을 제시할 수 있지만, 테스트를 통해 이것이 어떤 영향을 끼치는지 정확히 파악하는 것이 중요하다.

For optimal indexing throughput, using identifiers autogenerated by Elasticsearch is always going to be the most efficient option. As update checks are not required, indexing performance does not change much as indices and shards grow in size. It it therefore recommended to use this whenever possible.

index 처리량을 최적화하려면, Elasticsearch가 자동 생성하는 ID를 사용하는 것이 가장 효율적인 선택이 될 것이다. update 검사가 불필요하므로, index와 shard가 커지더라도 index 성능은 크게 변화가 없다. 따라서, 가능한 한 이것을 사용하는 것이 좋다.

The update checks resulting from using an external ID will require additional disk access. The impact this will have depend on how efficiently the required data can be cached by the operating system, how fast the storage is and and how well it can handle random reads. The indexing speed also often goes down as indices and shards grow and more and more segments need to be checked.

외부 ID를 사용하여 update 검사를 하려면 추가적인 disk access가 필요하다. 이로 인한 영향은 필요한 data가 얼마나 효율적으로 OS에 의해 cache되느냐, storage의 속도, random 읽기를 얼머너 절 처리하느냐에 따라 다르다. 또한 index와 shard가 증가할수록 index 속도는 떨어지는 경향이 있으며, 더 많은 segment를 확인해야 한다.

Use of the rollover API

Traditional time-based indices rely on each index covering a specific set time period. This means that index and shard sizes can end up varying a lot if data volumes fluctuate over time. Uneven shard sizes are not desirable and can lead to performance problems.

전통적인 시간 기반 index는 특정 설정 기간을 다루는 각각의 index에 의존한다. 즉, data의 양이 시간에 다라 다를 경우, index와 shard 크기는 다양해 질 수 있다. shard 크기가 일정하지 않은 것은 바람직하지 않으며 성능 문제가 발생할 수 있다.

The rollover index API was introduced to provide a flexible way to manage time-based indices based on multiple criteria, not just time. It makes it possible to roll over to a new index once the existing one reaches a specific size, document count and/or age, resulting in much more predictable shard and index sizes.

rollover index API 는 시간 뿐만 아니라 다양한 기준에 따라 시산 기반 index를 다루는 다양한 방법을 제공하기 위해 도입되었다. 기존의 index가 특정 크기, document 수 또는 기간에 도달하면, 새로운 index로 roll over할 수 있어, 훨씬 더 예측 가능한 shard와 index 크기가 될 수 있다.

This however breaks the link between the event timestamp and the index it belongs to. When indices were based strictly on time, an event would always go to the same index no matter how late it arrived. It is this principle that makes it possible to prevent duplicates using external identifiers. When using the rollover API it is therefore no longer possible to completely prevent duplicates, even though the probability is reduced. It is possible that two duplicate events arrive on either side of a rollover and therefore end up in different indices even though they have the same timestamp, which will not result in an update.

그러나 이렇게 하면, event timestamp와 그것이 포함된 index간의 link가 끊어진다. index가 엄격하게 시간에 기반한 경우, event는 아무리 늦게 도착하더라도 항상 동일한 index로 간다. 외부 ID를 사용하여 중복을 방지하는 것이 원칙이다. 따라서, rollover API를 사용하는 경우, 가능성은 줄어들겠지만, 중복을 완전히 방지하는 것은 더 이상 불가능하다. 2개의 중복 event가 rollover의 양쪽에 도착하면, 그들이 동일한 timestamp를 가지고 있지만 다른 index이므로, update되지 않을 것이다.

It is therefore not recommended to use the rollover API if duplicate prevention is a strict requirement.

따라서, 중복 방지 요구가 있는 경우, rollover API를 사용하지 않는 것이 좋다.

Adapting to unpredictable traffic volumes

Even if the rollover API cannot be used, there are still ways to adapt and adjust shard size if traffic volumes fluctuate and result in time-based indices that are too small or large.

rollover API를 사용할 수 없는 경우에도, traffic 양이나 시간 기반 index가 너쿠 크거나 작은 경우 shard 크기를 조정할 수 있다.

If shards have ended up too large due to, e.g. a surge in traffic, it is possible to use the split index API to split the index into a larger number of shards. This API requires a setting to be applied at index creation, so this needs to be added through an index template.

예를 들어, traffic이 급증하여 shard가 너무 커진 경우, split index API 를 사용하여 더 많은 수의 shard로 index를 분할할 수 있다. 이 API는 index 생성시에 적용해야 하므로 설정이 필요하다. 따라서, 이것은 index template을 통해 추가해야 한다.

If traffic volumes on the other hand have been too low, resulting in unusually small shards, the shrink index API can be used to reduce the number of shards in the index.

반면에 traffic 양이 너무 작아 비정상적으로 작은 shard가 나타나면, shrink index API 를 통해 index의 shard 수를 줄일 수 있다.

Conclusions

As you have seen in this blog post, it is possible to prevent duplicates in Elasticsearch by specifying a document identifier externally prior to indexing data into Elasticsearch. The type and structure of the identifier can have a significant impact on indexing performance. This will however vary from use case to use case so it is recommended to benchmark to identify what is optimal for you and your particular scenario.

이 게시물에서 보았듯이 data를 Elasticsearch에 index하기 전에 외부에서 document ID를 지정하여 Elasticsearch에서 중복을 방지할 수 있다. ID의 유형과 구조는 index 성능에 막대한 영향을 끼칠 수 있다. 그러나, 이는 사용사례에 따라 다르므로, 최적화된 ID를 테스트해 보는 것이 좋다.

원문 : Efficient Duplicate Prevention for Event-Based Data in Elasticsearch

2018.08.21 - 번역 - Made To Measure: How to Use the Ranking Evaluation API in Elasticsearch ...

drscg — Mon, 7 Jan 2019 14:33:39 +0900

The Ranking Evaluation API that's been added to Elasticsearch is a new, experimental REST API that lets you quickly evaluate the quality of search results for a typical query set. This can be useful either while developing new search queries, incremental improvements of the query templates of an an existing system, or as a basic monitoring tool to detect changes in the search quality of a system in production.

Elasticsearch에 새로 추가된 Ranking Evaluation API는 일반적인 query set에 대한 품질을 빠르게 평가할 수 있는 실험적인 REST API이다. 이것은 새로운 search query 개발, 기존 시스템의 query template의 증분 개선, 제품에서 시스템의 search 품질의 변화를 감지할 수 있는 기본적인 모니터링 tool로 유용하다.

A recent blog post about relevance tuning already gave some initial motivation for why Ranking Evaluation is useful and gave a first glimpse at the new API. This post will show you how to use the new Ranking Evaluation API in Elasticsearch to measure search performance on real-life data and will show some common usage examples. The goal is to give you some hands-on experience using the API to initially develop a simple search query and measure its ranking quality. Then you’ll gradually improve it, learning about some of the details of the new API along the way.

이미 최근의 relevance tuning에 대한 게시물에서 Ranking Evaluation이 유용한 이유에 대한 몇 가지 기초적인 동기를 부여했고, 새로운 API를 처음 보았다. 이 게시물에서 Elasticsearch의 새로운 Ranking Evaluation API를 사용하여 실제 data에서 search 성능을 측정하는 방법을 알아보고 몇 가지 일반적인 사용 예를 살펴보자. 처음에 간단한 search query를 개발하고, 그것의 ranking 품질을 측정하여 API를 사용하는 경험을 갖는 것이 목표이다. 그 다음에 새로운 API의 세부 사항에 대해 단계적으로 배우면서, 점차적으로 그것을 개선해 나갈 것이다.

Setting Up the Demo Project

Before we start diving into the API itself, let us take a quick look at a demo project that will help you setting up the dataset we are going to play with. We will use a small subset of documents from the English Wikipedia that Wikimedia provides publicly for download. If you are interested in how to index data from Wikipedia in general, take a look at this Loading Wikipedia's Search Index for Testing blog post. For now, we keep things simple. I have already prepared the scripts that will create the index you are going to use. Let’s start by cloning the project itself:

API 자체에 대해 알아보기 전에, 테스트할 data 집합을 설정하는데 도움이 될 demo project을 간략히 살펴보자. 우리는 Wikipedia가 download를 위해 공개적으로 제공하는 영문 Wikipedia의 작은 일부 document를 사용할 것이다. Wikipedia로 부터 data를 index하는 방법에 관심이 있다면, 테스트를 위한 Wikipedia의 Search Index Loading이라는 게시물을 살펴보자. 지금은 간단하게 하자. 이미 사용할 index를 생성할 script를 준비해 뒀다. project 자체를 clone하여 시작하자.

git clone https://github.com/cbuescher/rankEvalDemo.git

Inside the main folder you can find a directory called bulkdata which contains the documents that we are going to index. In order to index this data, start a local instance of Elasticsearch 6.3 now. Note: For other versions, please check if there is a corresponding branch in the demo project. API syntax might change, since this API is still experimental at the time of this writing, so you need to adapt the following examples if necessary.

main folder 안에, index할 document를 포함하고 있는 bulkdata 라는 directory가 있다. 이 data를 index하기 위해, local에서 Elasticsearch를 시작하자. 다른 버전을 사용하려면, demo project에 해당 branch가 있는지 확인하자. 이 API는 이 글을 쓰고 있는 시점에 여전히 실험 중이므로, API 문법은 변경될 수 있으니, 필요하다면, 다음 예제를 수정해야 한다.

Next, we are going to create an index named "enwiki_rank" that contains the demo documents. Assuming Elasticsearch is reachable at the default of localhost:9200 (otherwise you’ll need to adapt the script slightly), run the ./setup.sh script, which will create a new index called “enwiki_rank” and then index the above mentioned bulk files, which should usually take just a few seconds.

다음으로, demo document를 포함하고 있는 "enwiki_rank" 라는 index를 생성하자. Elasticsearch가 기본값인 localhost:9200 이라고 가정(그렇지 않으면, script를 약간 수정해야 한다)하면, ./setup.sh script를 실행하여, “enwiki_rank”라는 새로운 index를 생성하고, 위에서 언급한 bulk file을 index하자. 일반적으로 몇 초 정도 소요된다.

Let’s take a quick look at the data by using the Kibana Console:

Kibana Console을 이용하여, data를 잠깐 살펴보자.

GET /enwiki_rank/_count

Response:

response는 다음과 같다.

{
  "count": 1882    
}

So we have about 1900 documents in the index to play with. A quick inspection of the mapping shows that there is quite a bit of information available for each Wikipedia document:

index에는 약 1,900개의 document가 있다. mapping을 빠르게 확인해 보면, 각 Wikipedia document에서 활용할 수 있는 상당히 많다는 것을 알 수 있다.

GET /enwiki_rank/page/_mapping

Besides the text content field itself (aptly called “text”), we find fields like “title”, “opening_text” and “category” in various analysis variants, as well as several additional metadata fields like incoming and outgoing links, redirects or popularity measures. We don’t need to go through all of them now, instead take a quick look at one example document (the page about John F. Kennedy) to get an idea about a typical document:

text content field외에도, 다양한 분석 변수에서 “title”, “opening_text”, “category” 뿐만 아니라 들어오고 나가는 links, redirections, popularity measures 같은 여러가지 추가 metadata field를 볼 수 있다. 지금 그들 모두를 검토할 필요는 없고, 대신 일반적인 document에 대한 idea를 얻기 위해, 하나의 예제 document(John F. Kennedy에 대한 page)만 빠르게 살펴보자.

GET /enwiki_rank/page/5119376

The returned document is huge, but at least take a look at some of the content fields like “title”, “text”, “opening_text” and “redirect” (which lists titles of pages redirecting to this one).

반환되는 document는 거대하지만, 최소한 “title”, “text”, “opening_text”, “redirect” 같은 일부 content field를 살펴보자.

Creating a Simple Query

Let’s start some searching now. Imagine your task is to develop some general purpose search frontend for this kind of data. Currently, you have little idea of how the documents are structured and which kind of queries to translate your users input to. You start your journey by imagining a typical user who wants to find information about president Kennedy, but unfortunately types “JFK” into the search box. You now have to make a choice how your search system translates this into an Elasticsearch query. Since we don’t know any better yet, let’s start simple by querying the “all” field (the catch-all copy-to field in the Wikipedia mappings. Note: this is NOT the Elasticsearch “_all” field, which is disabled by default in the mappings as of version Elasticsearch 6.0). Because documents are very large, and at this point we only need their titles, let us use source filtering to select only the title field:

이제 몇 가지 search를 시작해 보자. 여러분의 일이 이런 종류의 data에서 어떤 일반적인 목적의 frontend search를 개발하는 것이라 가정해 보자. 현재, 여러분은 document가 어떻게 구성되어 있는지, 사용자의 입력을 처리할 query에 대해 거의 알지 못한다. Kennedy 대통령에 대한 정보를 찾으려 하지만, 불행하게도, search box에 "JFK" 라고 입력하는 일반적인 사용자를 가정하고 시작하는 것이다. 이제 여러분은 search system이 이것을 Elasticsearch query로 바꾸는 방법을 선택해야 한다. 아직 잘 모르기 때문에, 간단하게 "all" field(Wikipedia mapping에서 catch-all copy-to field, Note: 이 field는 Elasticsearch의 "_all" field가 아니며, 이 field는 Elasticsearch 6.0 을 기준으로 mapping에서 기본적으로 비활성화isabled by default기되어 있다)에 대해 query하는 것으로 시작하자. document가 매우 크고 그 title만 필요하기 때문에, title filed만 선택하도록 source filtering을 사용하자.

GET enwiki_rank/page/_search?filter_path=hits.hits._source.title
{
  "query" : {
    "match" : {
      "all" : "JFK"
    }
  }
}

The response might be a bit disappointing. It contains many documents about the JFK airport and related locations, a football club, a Boston train station, but only the "JFK (disambiguation)" page and the page called "Reactions to the assassination of John F. Kennedy" are somehow related to Kennedy, the president. Maybe we can try to be more specific by searching on the “title”, “opening_text” and a fuzzy version of the redirect page title called “redirect.title.near_match”:

response는 다소 실망스러울 수 있다. JFK 공항, 관련된 장소, 축구정, Boston 기차역 등에 대한 많은 document를 포함하고 있지만, "JFK (disambiguation)" page와 "Reactions to the assassination of John F. Kennedy" 이라는 page만이 Kennedy 대통령과 어느 정도 관련이 있다. 아마도 “title”, “opening_text”과 “redirect.title.near_match” 라는 redirect page title의 fuzzy version을 search하여 더 구체화할 수 있을 것이다.

GET enwiki_rank/page/_search?filter_path=hits.hits._source.title
{
  "query": {
    "multi_match": {
      "query": "JFK",
      "type": "best_fields",
      "fields": [
        "title",
        "opening_text",
        "redirect.title.near_match"
      ]
    }
  }
}

The result already looks more promising:

결과가 조금 더 나아졌다.

"hits": [{ [...]
  "title": "JFK (disambiguation)" [...]
  "title": "JFK Medical Center (Edison, New Jersey)" [...]
  "title": "AirTrain JFK" [...]
  "title": "John F. Kennedy" [...]
  "title": "John F. Kennedy International Airport" [...]                
  "title": "JFK Express" [...]
  "title": "Sutphin Boulevard–Archer Avenue–JFK Airport (Archer Avenue Lines)" [...]
  "title": "JFK (soundtrack)" [...]
  "title": "Howard Beach–JFK Airport (IND Rockaway Line)" [...]
  "title": "Skaboy JFK" [...]                
}]

In addition to the disambiguation page, we find the article about president John F. Kennedy and the soundtrack of the movie JFK, but the rest of the result still doesn’t look great.

disambiguation page외에, John F. Kennedy 대동령과 영화 JFK의 soundtrack에 대한 기사가 있자먼 여전히 결과의 나머지는 그리 좋지 않다.

We could continue like this: looking at some data, improving the query bit by bit and checking the results, until we are satisfied. But there are many disadvantages to this. First, you will need to look through the list of results every time you change anything in your query and make a judgement call whether the results are better or worse than the previous ones. This is more or less a gut feeling. While it is sometimes clear which documents should be returned on top, it is much harder to judge the “somewhat okay” and the “really bad” cases in a consistent way over time. And then there is your colleague or boss that in many cases will have a slightly different opinion on which search results should be leading the list, so once they start tuning the query, everything moves into a different direction. A structured way of evaluating your search ranking is clearly needed.

디음과 같이 계속 할 수 있다. 우리가 만족할 때가지 약간의 data를 보고, query를 조금씩 개선하고, 결과를 확인하는 것. 하지만 이 방법에는 다음과 같은 많은 단점이 있다. 먼저, query에서 어떤 것을 변경할 때 마다, 결과 목록을 검토하여, 결과가 이전보다 더 나아졌는지 나빠졌는지 판단해야 한다. 이것은 다소 직감적이다. 어떤 document를 상위로 return해야 할지 어떤 때는 명확하지만, 시간이 흐르면서 "약간 괜찮네"와 "진짜 아니야" 라는 사례를 일관되게 판단하는 것이 훨씬 더 어렵다. 그리고 , 어떤 search 결과가 목록의 위에 올라와야 하는지에 대해, 상사나 동료가 약간 다른 의견을 가지는 경우가 많으므로, query를 tuning하기 시작하면 모든 것이 어긋나게 된다. search 순위를 평가하는 체계적인 방법이 명확하게 필요하다.

Good, Better, Best

This is where the new Ranking Evaluation API comes into play. It provides a way of attaching a set of document ratings to each of the typical search cases relevant for your system. By doing so, it offers a repeatable way of calculating various evaluation measures (that are well known in information retrieval literature) on top of those ratings to guide you in your decisions on how to optimize your system.

여기에서 새로운 Ranking Evaluation API가 적용된다. 시스템과 관련된 각각의 일반적인 search 사례에 document ratings의 집합을 붙이는 방법을 제공한다. 이렇게 함으로써, 시스템을 최적화하는 방법을 결정하는데 도움이 되도록 상위의 해당 ratings에 대한 다양한 평가 측정치를 계산하는 반복가능한 방법을 제공한다.

To make this more concrete, let us take a look at how such document ratings might look like. The Wikimedia foundations Discovery department has been working on improving their site search for a long time, and they struggled with the same kind of problems as the ones described above. This is why they launched their own service Discernatron with the goal to collect human judgments of search result relevance by letting users rate the quality of results on a scale from 0 (irrelevant) to 3 (relevant). User with a Wikimedia account can login at https://discernatron.wmflabs.org and check out the tool. It’s really worth a look and you might even be able to help improving the search quality of the largest knowledge base of our time by rating a few documents yourself. Just in case you don’t want to do that right now, here is what the user interface looks like:

이를 보다 구체적으로 설명하기 위해, 그러한 document ratings가 어떻게 보이는지 살펴보자. Wikimedia 재단의 Discovery 부서는 오랫동안 site search를 개선하기 위해 노력해 왔으며, 위에서 언급한 것과 동일한 종료의 문제로 고생했다. 이러한 이유로, 사용자들이 결과의 품질을 0(관련없음)에서 3(관련있음)까지 평가하도록 하여, search 결과의 관련성에 대한 사람들의 판단을 수집하기 위하여, 그들은 자체 서비스인 Discernatron를 시작했다. 사용자들은 https://discernatron.wmflabs.org에서 Wikimedia 계정으로 로그인하여, tool을 확인할 수 있다. 그것은 진정 가치 있는 것이고, 스스로 몇 개의 document를 평가함으로써, 이 시대의 가장 거대한 지식 기반의 search 품질을 개선하는데 도움이 될 수 있다. 지금 바로 그렇게 하지 싶지 않은 경우, 아래의 사용자 interface를 참고하자.

The full dataset is available for users with a Wikimedia account (also optionally in JSON format), currently containing more than 6000 ratings associated with about 150 user queries. The document ratings for the rest of this demo are all based on this data to save of the trouble of having to come up with our own relevance ratings.

전체 data 집합(옵션으로 JSON format도)은 Wikimedia 계정을 가진 사용자들이 활용할 수 있는데, 현재 150개의 사용자 query와 관련된 6,000개 이상의 ratings를 가지고 있다. 이 demo의 나머지 document ratings는 모두 이 data를 기반으로 하여, 자체 관련성 등급을 산출해야 하는 어려움을 덜어준다.

Basic Request and Response

So let’s get back to our search for “JFK” that we started to build a query for. Luckily, there are already about 60 document ratings for this query in the Discernatron dataset. The demo project contains a slightly older, reduced dataset containing the document ratings. When you inspect that file, the first three columns contain the query, page title and average rating for the document in question. We can see that the ratings for the result “John F. Kennedy” is most relevant (score 3.0) while things like the JFK movie (score 2.25) or the airport (score 2.25) are rated lower and articles about the movie soundtrack (score 1.0) or the football team JFK Olimps (score 0.75) are judged as rather irrelevant with respect to the query. We can use this data to create out first request to the Ranking Evaluation API. Because the list of ratings is quite long, the full ratings array is abbreviated here, but you can find the full request in the demo project.

자, query를 작성하기 시작한 "JFK"에 대한 search로 돌아가 보자. 운좋게도, 이미 이 data 집합에는 이 query에 대한 약 60개의 document ratings가 있다. demo project에는 document ratings를 포함하고 있는 약간 더 오래된 축소된 data 집합을 포함하고 있다. 해당 file을 확인해 보면, 첫번째 3 column은 질문에 대한 document의 query, page title, 평균 ratings를 포함하고 있다. “John F. Kennedy” 결과에 대한 등급이 가장 관련(score 3.0)있고, 반면에 영화 JFK(score 2.25)나 공항(score 2.25)은 덜 관련 있고, 영화 soundtrack(score 1.0)이나 축구팀 JFK Olimps(score 0.75)에 대한 게시물은 query와 다소 무관한 것으로 나타난 것을 볼 수 있다. 등급 목록이 상당히 길기 때문에, 전체 ratings 배열은 여기에서 생략했지만, demo project에서 전체 request를 볼 수 있다.

POST /enwiki_rank/_rank_eval
{
  "requests": [{
    "id": "JFK_query",
    "request": {
      "query": {
        "multi_match": {
          "query": "JFK",
          "type": "best_fields",
          "fields": [
            "title",
            "opening_text",
            "redirect.title.near_match"
          ]
        }
      }
    },
    "summary_fields": [
      "title"
    ],
    "ratings": [{
        "_id": "3054546",
        "rating": 1,
        "_index": "enwiki_rank"
      },
      {
        "_id": "5119376",
        "rating": 3,
        "_index": "enwiki_rank"
      }, [...]
    ]
  }],
  "metric": {
    "precision": {
      "relevant_rating_threshold": 2,
      "k": 5
    }
  }
}

Let’s examine this request part by part. The largest part of the request is an array called "requests". It defines the set of different search cases that are part of the evaluation. We start simple by only evaluating the “JFK” search at the moment, but will extend that later. We give this use-case an id and specifying the query from above to be executed. The summary_fields parameter defines a filter on the document fields that we want to see in the response. For the sake of this demo it is sufficient to see the document title. The "ratings" section contains all the relevance judgements that we extracted from the Discernatron dataset by mapping the page title to out internal document id. Here e.g. the document with "_id": "5119376" refers to the John F. Kennedy article and gets the highest score of 3.0.

이 request를 부분별로 확인해 보자. request의 가장 큰 부분은 "requests" 배열이다. 이것은 평가의 일부분인 디양한 search 사례의 집합을 정의한다. 현재 "JFK" search만 평가하는 하는 것으로 단순하게 시작하지만 나중에 그것을 확장할 것이다. 이 사용사례에 id 를 부여하고 위에서 실행한 query 를 지정한다. summary_fields 매개변수는 response에서 볼 수 있는 document의 field에 대한 filter를 정의한다. 이 demo를 위해서는 document의 title을 보는 것으로 충분하다. "ratings" section은 page title을 내부 document id에 mapping하여, data 집합에서 추출한 관련성 판단이 포함된다. 예를 들어, 여기에서 "_id": "5119376" document는 John F. Kennedy 게시물을 가리키며, 가장 높은 score 3.0 을 가진다.

The following, smaller section defines the evaluation metric itself. We choose Precision, or more specifically, Precision at K, which is a metric that takes the first K returned search results and calculates the fraction of relevant documents. Since we use rating on a scale from zero to three, we also need to define from which ratings on this scale we consider as “relevant”. We choose a rating of 2 and above to be “relevant” by setting the relevant_rating_threshold accordingly. For the sake of brevity, we also choose to evaluate the query only on the top 5 documents. This means that when those top 5 results contain three documents with score two or higher, the precision will be 3 / 5 = 0.6. You can check this now by running the full request in the Kibana Console. This is the abbreviated response:

이어지는 더 작은 section은 평가 metric 자체를 정의한다. 우리는 Precision, 더 정확히 표현하면, Precision at K 을 선택했는데, 이는 처음으로 K를 반환하는 search 결과를 가져와 관련된 document의 비율을 계산하는 metric이다. 0에서 3까지의 ratings를 사용하기 때문에, 이것에서 어느 ratings를 “관련있는” 것으로 간주할지를 정의해야 한다. 따라서, 위에서 "관련있는" 것이 되도록, relevant_rating_threshold 를 설정하여, ratings 2를 선택한다. 또한 간략하도록, 상위 5개의 document에서만 query를 평가하도록 선택한다. 즉, 상위 5개의 document에 score 2 이상의 document가 3개가 포함되면, 정확도는 3 / 5 = 0.6 이 된다. 이제 Kibana Console에서 전체 request를 실행하여 확인할 수 있다. 다음은 요약된 response이다.

{
  "quality_level": 0.6,
  "details": {
    "JFK_query": {
      "quality_level": 0.6,
        "unknown_docs": [
        {
        "_index": "enwiki_rank",
        "_id": "26509772"
        }
       ],
      "hits": […],
      "metric_details": {
        "precision": {
          "relevant_docs_retrieved": 3,
          "docs_retrieved": 5
        }
      }
    }
  }
}

As we can see, apart from the total result, a precision score of 0.6, the details section contains additional information about each evaluated search case, in this case only the “JFK_query”. The metric_details section shows how the score was calculated. As expected, we found 3 relevant documents out of 5 retrieved. But what about the other two documents? Either the document had a rating of less than 2, or some of the results returned by the query were not rated at all. It can be useful to present especially these unrated documents to the user and ask for a rating. The unknown_docs section contains those documents for exactly this purpose. In addition, the hits section contains all the search hits returned for the particular query under evaluation. The difference between a usual search and "hits" is that each hit contain its rating (or null if there is none) and usually _sourceis omitted. Document fields can be included (e.g. because we want to present them to a user when asking for a rating) by explicitly specifying them in the request's summary_fields.

위에서 보듯이, 전체 결과에서 0.6인 precision score를 제외하면, details section에는 각각의 평가된 search 사례에 대한 추가적인 정보가 포함되어 있다. 이 경우에는 “JFK_query”만 있다. metric_details section은 score가 계산되는 방법을 보여준다. 예상대로 5건 중 3건의 관련된 document를 가져왔다. 그렇다면 다른 2건의 document는? document의 ratings가 2보다 적거나, query에 의해 반환된 결과가 전혀 평가되지 않았다. 특히 사용자에게 이런 등급 미지정 document를 제공하고 ratings를 요청하는 것은 유용하다. unknown_docs section에는 정확히 이런 목적을 위한 해당 document가 포함되어 있다. 또한, hits section에는 평가중인 특정 query에 대해 반환된 모든 search 결과가 포함된다. 일반적인 search와 "hits"의 차이점은 각 hit는 rating (없는 경우에는 null)이 포함되며, 일반적으로 _source 는 생략된다. document의 field는 request의 summary_fields 에 그것을 명시적으로 지정하여 포함(예를 들어, ratings를 요청할 때, 사용자에게 그것을 표시하려는 경우)할 수 있다.

Improving Queries Incrementally

Now that we know what the basic requests and responses look like, let us use this to improve our query some more. By looking at the title of the results, we can see that the three relevant documents we get back are “John F. Kennedy”, “JFK (disambiguation)" and “John F. Kennedy International Airport”. Not too bad, but we might get even better. Poking around in the Wikipedia document definition, we find a field called popularity_score, which seems to be higher for popular articles like “John F. Kennedy” than for niche articles like "JFK Medical Center (Edison, New Jersey)". Let us see if we can use this to boost search results with a function score query using this request:

이제, 기본적인 request와 response를 알았으니, query를 좀 더 개선하여 이를 사용해 보자. 결과의 title을 살펴보면, “John F. Kennedy”, “JFK (disambiguation)", “John F. Kennedy International Airport”의 3개의 관련된 document를 볼 수 있다. 나쁘지 않지만, 더 나아질 수 있다. Wikipedia document 정의를 살펴보면, popularity_score 라는 field를 볼 수 있는데, 이는 "JFK Medical Center (Edison, New Jersey)" 같은 틈새 게시물보다 “John F. Kennedy” 같은 인기있는 게시물애 더 높은 것으로 보인다. 다음 request를 사용하여,이 field를 이용하여, 다음 request 처럼, function score query 로 search 결과를 향상시킬 수 있는지 알아보자.

POST /enwiki_rank/_rank_eval
{
  "requests": [{
    "id": "JFK_query",
    "request": {
      "query": {
        "function_score": {
          "query": {
            "multi_match": {
              "query": "JFK",
              "type": "best_fields",
              "fields": [
                "title",
                "opening_text",
                "redirect.title.near_match"
              ]
            }
          },
          "functions": [{
            "field_value_factor": {
              "field": "popularity_score",
              "missing": 1
            }
          }],
          "boost_mode": "multiply"
        }
      }
    },
    "summary_fields": [
      "title"
    ],
    "ratings": [… ]
  }],
  "metric": {
    "precision": {
      "k": 5,
      "relevant_rating_threshold": 2
    }
  }
}

We now even get 4 out of 5 relevant documents in the result, which leads to a precision score of 0.8. Well done. But what if this is just improving results for this particular query. After all, out users are not just interested in the results for typing in “JFK” into the search box. Time to put some more typical searches in the mix.

결과에는 5개의 관련된 document 중 4개를 표시되어, precision score가 0.8이 된다. 잘 됐다. 그러나, 이것이 이 특정 query의 결과만 향상시키는 것이라면? 결국, 사용자는 검색 창에 "JFK"를 입력한 경우에 대한 결과에만 관심을 가지는 것이 아니다. 좀 더 일반적인 search를 해야할 시간이다.

Extending the Set of Evaluated Queries

Looking at the user queries in first column of the document ratings, we can discover more cases which we have ratings for. Typically you would try using the whole data if possible, but for now, let's just add two cases to the evaluation. The first search we’ll add (“the great beer flood”) relates to a curious historical incident called the London beer flood, where in 1814, after a brewery accident, more than 1 million liters of beer were running into the streets. The second search case we’ll add is about “naval flags” and we’ll assume users are interested in things like maritime flags or other kinds of naval ensigns.

document ratings의 첫번째 column에 있는 사용자 query를 살펴보면, ratings를 가진 더 많은 경우를 볼 수 있다. 일반적으로 가능한 한 전체 data를 사용하려 하겠지만, 평가에 2가지 경우만 추가해 보자. 추가할 첫번째 search는 1814년 맥주 공장 사고 후, 백만 리터 이상의 맥주가 거리로 흘러나온 London beer flood라는 기이한 역사적 사건과 관련이 있는 (“the great beer flood”) - 거대한 맥주 홍수 - 이다. 추가할 두번째 search는 “naval flags” 에 대한 것인데, 사용자들은 maritime flags(선박의 깃발)이나 다른 종류의 naval ensigns(해군 깃발)에 관심이 있다고 가정할 것이다.

We want to use the same query as the one above, but we don’t want to repeat it three times. We can avoid this by using the templates section, that allows sharing queries common to all search use cases and to parametrize them later. The query that we previously defined in the requests section gets its own template id (“my_template”) and uses a placeholder ("{{query_string}}") inside the query that is later replaced by the actual user query. If you ever used search templates before, this will look familiar. In the requests sections we can now refer to this template by its id using the template_id and providing the parameter replacements in the params object:

위에서와 동일한 query를 사용하려 하지만, 3번 반복하지는 않으려 한다. 모든 search 사례에 공통적인 query를 공유할 수 있고, 나중에 매개변수화 할 수 있는 templates section을 사용하여, 이를 피할 수 있다. requests section에서 이전에 정의한 query는 자신의 template id(“my_template”)를 가져오고, 나중에 실제 사용자 query로 대체되는 query 내에 placeholder ("{{query_string}}")를 사용한다. 이전에 search templates 을 사용해 본적이 있다면, 이것은 익숙할 것이다. 이제, requests section에서, template_id를 사용허여 그 id로 이 template을 참조할 수 있고, params object에서 매개변수 교체를 제공한다.

POST /enwiki_rank/_rank_eval
{
  "templates": [{
    "id": "my_template",
    "template": {
      "source": {
        "query": {
          "function_score": {
            "query": {
              "multi_match": {
                "query": "{{query_string}}",
                "type": "best_fields",
                "fields": [
                  "title.near_match",
                  "opening_text.plain",
                  "redirect.title.near_match"
                ]
              }
            },
            "functions": [{
              "field_value_factor": {
                "field": "popularity_score",
                "missing": 1,
                "modifier": "none"
              }
            }],
            "boost_mode": "multiply"
          }
        }
      }
    }
  }],
  "requests": [{
      "id": "JFK_query",
      "template_id": "my_template",
      "params": {
        "query_string": "JFK"
      },
      "ratings": […]
    },
    {
      "id": "the_great_beer_flood_query",
      "template_id": "my_template",
      "params": {
        "query_string": "the great beer flood"
      },
      "ratings": […]
    },
    {
      "id": "naval_flags_query",
      "template_id": "my_template",
      "params": {
        "query_string": "naval flags"
      },
      "ratings": […]
    },
    "metric": {
      "precision": {
        "k": 5,
        "relevant_rating_threshold": 2
      }
    }
  }
}
Read Less

When we run the full request, the result might be a bit surprising at first: the combined average "quality_level" is now only 0.26. While the “JFK” query still performs well (a precision of 0.8), the other two queries show a precision of 0, meaning they don’t have any relevant document in their results. This leads to an average precision of only 0.26. What seems to be wrong? If we look at the results in the details, we see that e.g. the “naval flags” query returns the “Union Jack” as first search hit, and the “great beer flood” query features things like “Great White Shark” or “Bob Dylan” among its search results. Maybe the influence of the popularity_score field we added to the query to get better results with the “JFK” example is too high? Let’s just try it out by taking the function_scorequery out again. This already increases precision to 0.46. Still not great, but at least each search now contains some relevant results: while precision for the “JFK” query dropped a bit to 0.6, we now also get 0.6 on the “naval flags” query and at least 0.2 with the “beer flood” query:

full request를 처음 실행하면, 처음에는 약간 놀랄 수 있다. 지금 조합된 평균 "quality_level"이 겨우 0,26이다. “JFK” query는 여전히 양호(precision 0.8)한데, 다른 2개의 query는 precision 0 이다. 이는 그 결과에 관련있는 document가 전혀 없다는 것을 의미한다. 이로 인해, 평균 precision이 겨우 0.26이 되었다. 무엇이 잘못되었을까? details 에서 결과를 살펴보면, 예를 들어 “naval flags” query는 “Union Jack”을 첫번째 search hit로 반환하고, great beer flood” query는 search 결과 중 “Great White Shark” 이나 “Bob Dylan” 같은 결과를 제공함을 볼 수 있다. 혹시 “JFK” 예제에서 더 낳은 결과를 위해 query에 추가한 popularity_score field의 영향이 너무 큰가? function_score query를 다시 해 보자. 이것은 precision을 0.46으로 증가시킨다. 아직 좋지는 않지만, 최소한 각 search에는 몇 가지 관련있는 결과를 포함하고 있다. “JFK” query의 precision이 0.6으로 약간 떨어졌지만, “naval flags” query에서는 0.6, “beer flood” query에서는 최소 0.2이다.

{
  "quality_level": 0.4666666666666666,
  "details": {
    "JFK_query": {
      "quality_level": 0.6,
      [...]
    },
    "naval_flags_query": {
      "quality_level": 0.6,
      [...]
    },
    "the_great_beer_flood_query": {
      "quality_level": 0.2,
      [...]
    }
  }
}

Start Exploring

In the end, finding a good query template usually means finding a compromise that works reasonably well across all search use cases in the test set. After all, a query template that returns some good results for most use cases is better than a query template that gets a perfect score for one particular use case but returns nothing useful for all the others.

결국 좋은 query template을 찾는는 것은 일반적으로 테스트 집합의 많은 search 사례에서 합리적으로 잘 동작하는 절충안을 찾는 것이다. 결국, 대부분의 사례에 대해 좋은 결과를 반환하는 query template이 어떤 특정 사례에 대해 완벽한 score를 얻지만 다른 모든 것에는 아무 것도 반환하지 못하는 query template보다 더 낫다.

There are many aspects we haven’t touched yet, but that are worth exploring on your own. For example, we used the precision metric throughout this blog post because its relatively easy to explain and calculate. However, it doesn’t take the positions of the rated documents in the result set into account — a relevant result in the first position counts the as a relevant document in the last position of the top results. The Discounted Cumulative Gain (DCG) metric is much better suited for these cases. You can try it out by simply exchanging the “metric” section in the examples above with:

아직 우리가 다루지 못한 부분이 많이 있지만, 여러분 스스로 그것을 탐구해 볼만하다. 예를 들어, 이 게시물에서 설명과 계산이 비교적 쉽기 때문에, precision metric을 사용했다. 그러나, 결과 집합에서 연관된 document의 위치는 고려하지 않았다. 첫번째 위치에서 관련 결과는 상위 결과의 마지막 위치에서 관련 document로 계산된다. Discounted Cumulative Gain (DCG) metric은 이런 경우에 훨씬 더 적합니다. 위의 예에서 “metric” section을 다음과 같이 교환하면 된다.

"metric": {
  "dcg": {
    "normalize": true,
    "k": 5
  }
}

This will calculate the normalized variant of the metric on the top 5 results. Start by using it with just one search query first and observe how the evaluation score changes when document with a high rating are returned further up the result list.

이렇게 하면, 상위 5개의 결과에서 metric의 정규화된 variant가 계산된다. 먼저 하나의 search query만 사용하여 높은 ratings의 document가 결과 목록의 더 위로 반환될 때, 평가 score가 어떻게 변화하는지 살펴보자.

Using the Ranking Evaluation API won’t magically make your search queries return only relevant results out of a sudden, but it will help you a lot in guiding your decisions while prototyping and maintaining a search system later on. No reasonably complex search application should be run in production without any kind of quality testing, be simple unit test, A/B tests or periodically running one of the metrics the Ranking Evaluation API offers. Coming up with relevance judgements for specific search cases might seem a bit of work first, but once you have your basic test set, you can iterate much faster and with more confidence on making changes, be it to your queries, analysis, or other parts of your system.

Ranking Evaluation API를 사용한다고 갑자기 search query가 관련있는 결과만 반환하지는 읺지만, 나중에 search 시스템을 prototyping하고 유지하는 동안 여러분의 의사 결정애 많은 도움이 될 것이다. 품질 테스트, 간단한 unit 테스트, A/B 테스트 또는 주기적으로 Ranking Evaluation API가 제공하는 metrics 중 하나를 실행없이는 제품에 합리적이고 복작한 search application도 없다. 특정 search 사례에 대한 관련성 판단을 내리는 것은 처음에는 약간의 작업이라 보이겠지만, 기본 테스트 집합을 가지게 되면, 훨씬 더 빠르고 신뢰할 수 있는 방식으로 시스템의 query, analysis, 다른 부분에 적용할 수 있다.

원문 : Made To Measure: How to Use the Ranking Evaluation API in Elasticsearch

2018.08.15 - 번역 - Test-Driven Relevance Tuning of Elasticsearch using the Ranking Evaluation API ...

drscg — Mon, 7 Jan 2019 14:32:36 +0900

This blog post is written for engineers that are always looking for ways to improve the result sets of their search application built on Elasticsearch. The goal of this post is to raise awareness of why you should care about relevance, what components are involved and how you can control them.

이 게시물은 Elasticsearch에 구축된 search application의 결과 집합을 개선하는 방법을 모색하고 있는 엔지니어를 위해 작성되었다. 이 게시물의 목표는 relevance에 주의해야 하는 이유, 그것에 포함된 구성요소, 그것을 제어하는 방법에 대한 관심을 높이는데 있다.

Tuning relevance can be hard. But by the end of this blogpost you’ll have a better understanding of how you can tune the relevance of your search engine and learn that it's actually not so hard with the right tools.

relevance를 tuning하는 것은 어려울 수 있다. 그러나 이 게시물의 마지막 부분에 이르면, search engine의 relevance를 tuning하는 방법을 더 잘 이해할 것이고, 올바른 tool을 사용하면 실제로 그렇게 어렵지 않다는 것을 배우게 될 것이다.

Let's start with a bit of theory

Let's consider a search application to use a combination of data (index), data models (mapping and analyzers) and query templates (Query DSL). Using the search system means entering queries (typically a set of parameters, such as query string, filters, etc.) and receiving results. The consumer of the results can be a person that accesses the search engine via a web-based GUI or an automated system (I will mainly talk about users during this blogpost, but it’s also applicable for bots). Those results may or may not match the users expectations.

data(index), model(mapping과 analyzer), query template(query DSL)의 조합을 사용하는 search application을 생각해 보자. search system을 사용한다는 것은 query(일반적으로 query string, filter 등의 매개변수 집합)를 입력하고, 결과를 받는다는 것이다. 결과를 사용하는 사람은 web 기반 GUI나 자동화된 system을 통해 search engine에 access하는 사람이 될 수 있다. (이 게시물에서는 주로 사용자에 대해 이야기하겠지만, bots에 대해서도 적용될 수 있다.) 이들 결과는 사용자의 기대와 다를 수도 있다.

The job of a developer that builds a search application is to make sure that their users will find what they are looking for. Optimizing the search engine for this is what we call relevance tuning.

search application을 구축하는 개발자의 job은 사용자가 찾고자 하는 것을 사용자가 찾을 수 있도록 하는 것이다. 이를 위해 search engine을 최적화하는 것을 relevance tuning이라 한다.

Ultimately, relevance is typically very subjective and often depends the individual evaluating the results of the query. Whether a user will be happy with the results or not — which is ultimately the only relevant metric for relevance — is hard to predict.

궁극적으로, relevance는 대개 매우 주관적이며, 종종 query 결과에 대한 개인적인 평가에 따라 다르다. 사용자가 결과에 만족할지 여부(이는 궁극적으로 relevance에 대한 relevant metric일 뿐이다)는 예측하기 어렵다.

Every dataset is unique, as are your users. This means that ultimately nobody can tell you exactly which configuration to choose. Even if there was a database full of use cases that included feedback about what worked well, your case will always be specific and unique.

모든 data 집합은 사용자와 마찬가지로 고유하다. 이것은 궁극적으로 어떤 구성을 선택해야 할지 아무도 정확히 알 수 없다는 것을 의미한다. 잘 동작하는 지에 대한 feedback을 포함하고 있는 사용 사례로 가득찬 database가 있더라고, 여러분의 사례는 항상 독특하고 고유할 것이다.

Very often, customers ask which query they should use. Of course, we can give guidelines that serve as a starting point. For example, it is best practice to use a multi-match query in an eCommerce use case. This usually works well until some edge cases are discovered that should yield better results. And when it comes to this kind of tuning it is usually better to follow a test-driven approach as explained in the following:

매우 자주, 고객등은 그들이 어떤 query를 사용해야 할지를 질문한다. 물론, 출발점 역활을 하는 가이드라인을 제공할 수 있다. 예를 들어, eCommerce 사례에서는 multi-match query를 사용하는 것이 가장 좋다. 보통 이것은 더 나은 결과를 산출해야 하는 어떤 상황이 발생할 때까지는 잘 동작한다. 그리고 이런 종류의 tuning에 대해서는, 다음과 같은 test-driven 방식을 따르는 것이 더 낫다.

Let's consider relevance tuning to be an optimization problem.
relevance tuning을 최적화 문제로 고려하자.
There are lots of moving parts for a data model and a query template.
data model과 query template에는 많은 유동적인 부분이 있다.
Finding the perfect combination of all those variables is the ultimate goal.
모든 변수의 완변한 조합을 찾는 것이 최종 목표이다.

There are dozens of ways to setup a query template and hundreds of ways to configure your data model including all options for setting up analyzers. Sometimes relevance isn't your only concern. Query speed and required disk space are usually also important factors. But let's consider them as small constraints in our quest to optimize relevance.

query template을 설정하는 수십가지 방법과 analyzer 설정에 대한 모든 option을 포함하여 data model을 구성하는 수백가지 방법이 있다. 때로는 relevance가 유일한 관심사가 아니다. query 속도와 disk 공간도 일반적으로 중요한 요소이다. 그러나, relevance를 최적화하기 위한 우리의 목표에서 이들을 작은 제약으로 생각하자.

To be successful you need a tool that enables you to measure and tune the relevance for your users and your search engine. Such a tool became available with version 6.2 of Elasticsearch, namely the Ranking Evaluation API.

이를 위해, 사용자와 search engine의 relevance를 측정하고 tuning을 할 수 있는 tool이 필요하다. 그런 tool을 Elasticsearch 6.2에서 Ranking Evaluation API라는 이름으로 이용할 수 있게 되었다.

Using the Ranking Evaluation API

With the Ranking Evaluation API, it is possible to measure the search quality of your search engine. To use this API, you’ll need an existing index, a set of queries, and a list of relevance judgements for documents returned by those queries. Relevance judgements are labels that indicate whether a document matched a query well or not.

Ranking Evaluation API를 사용하면, search engine의 search 품질을 측정할 수 있다. 이 API를 사용하기 위해서는 기존의 index, query 집합, 해당 query에 의해 반환되는 document에 대해 relevance를 판단할 목록이 필요하다. relevance 판단은 document가 query와 잘 일치하는지 여부를 나타내는 label이다.

Usually you know the queries that you use. Either they can be extracted from the application code or from the slowlogs (Turning the slowlog setting to 0 seconds will log all queries. Warning: Don’t let this setting run in production for a long time, as it will impact performance.). If you use search templates, it’s very straightforward to extract the queries in JSON format.

일반적으로, 여러분은 여러분이 사용하는 query를 알고 있다. application code 또는 slowlogs (slowlog를 0초로 설정하는 것은 모든 query를 log로 남기겠다는 의미이다. 경고: 이 설정은 성능에 영향을 미치므로, 제품에서 오랫동안 실행하지 않도록 하자)에서 추출할 수 있다. search templates을 사용한다면, query를 JSON format으로 추출하는 것은 매우 간단하다.

The only tedious part is to gather the relevance judgements. You’ll need to collect for each query one or more documents that should match that query or not. In many cases this will be manual work. The exact format of the relevance judgements is explained in the ranking evaluation documentation.

유일하게 지루한 부분은 relevance 판단을 수집하는 것이다. 각 query에 대해 일치하거나 일치하지 않는 하나 이상의 document를 수집해야 한다. 많은 경우에, 이것은 수작업이다. relevance 판단의 정확한 형식은 ranking evaluation documentation에 설명되어 있다.

Search quality can also be measured using proven information retrieval metrics like precision, mean reciprocal rank or discounted cumulative gain (DCG).

search 품질은 precision, mean reciprocal rank, discounted cumulative gain (DCG) 같은 증명된 정보 검색 통계를 사용하여 측정할 수도 있다.

The queries you pick should be a somewhat representative sample of typical queries that you will serve in production. The easiest way to pick the sample if you already have a search system in place would be to take the top 100 queries from your website analytics logs.

여러분이 선택해야 하는 query는 제품에서 서비스할 전형적인 query의 대표적인 예제라야 한다. search system을 이미 가지고 있다면, 예제를 선택하는 가장 쉬운 방법은 여러분의 website 분석 로그에서 상위 100개의 query를 가져오는 것이다.

Let’s assume you’re ready to go now: You have an index, query samples and relevance judgements. Here’s a little recipe how you can use the Ranking Evaluation API for test driven relevance tuning:

이제 준비가 되었다고 가정라자. index, query 예제, relevance 판단을 가지고 있다. 다음은 test driven relevance tuning을 위해 Ranking Evaluation API를 사용하는 방법에 대한 약간의 recipe이다.

Talk to QA, and find out which problematic queries need to be tuned.
QA와 이야기하여, tuning해야 할 문제가 있는 query가 어떤 것인지 알아보자.

Run the queries that need to be tuned. For this example, we have 1 document in our movies index:
tuning해야 할 query를 실행하자. 이 예제를 위하여, movies index에는 1개의 document가 있다.

POST movies/doc
{
  "title": "Star Wars"
}

Let’s check if a query for “Star Trek” yields results:
“Star Trek”에 대한 query 결과가 나오는지 확인하자.

GET movies/_rank_eval
{
  "requests": [
    {
      "id": "star_trek",
      "request": {
        "query": {
          "match_phrase": {
            "title": "Star Trek"
          }
        }
      },
      "ratings": [
        {
          "_index": "movies",
          "_id": "1",
          "rating": 1
        }
      ]
    }
  ],
  "metric": {
    "precision": {
      "k": 5,
      "relevant_rating_threshold": 1
    }
  }
}

Run an initial test to measure the current state of your system:
시스템의 현재 상태를 측정하기 위해 초기 테스트를 실행하자.
```
{
  "quality_level": 0,
  "details": {
    "star_trek": {
      "quality_level": 0,
      "unknown_docs": [],
      "hits": [],
      "metric_details": {
        "precision": {
          "relevant_docs_retrieved": 0,
          "docs_retrieved": 0
        }
      }
    }
  },
  "failures": {}
}
    
```
Ok the quality_level is 0. This is not what we want. The quality level can range from 0 to 1. We should aim for something close to 1. So maybe we have to use a different query.
좋다. quality_level이 0 이다. 이것은 우리가 원하던 것이 아니다. quality level의 범위는 0에서 1까지이다. 1 에 가까운 값을 목표로 해야 한다. 따라서, 아마도 다른 query를 사용해야 한다.

Change a variable. For this example, let's change the query type.
변수를 바꾸자. 예를 들자면, query type을 변경하자.

GET movies/_rank_eval
{
  "requests": [
    {
      "id": "star_trek",
      "request": {
        "query": {
          "match": {
            "title": "Star Trek"
          }
        }
      },
      "ratings": [
        {
          "_index": "movies",
          "_id": "1",
          "rating": 1
        }
      ]
    }
  ],
  "metric": {
    "precision": {
      "k": 5,
      "relevant_rating_threshold": 1
    }
  }
}

Run the test again.
테스트를 다시 실행하자.

{
  "quality_level": 1,
  "details": {
    "star_trek": {
      "quality_level": 1,
      "unknown_docs": [],
      "hits": [
        {
          "hit": {
            "_index": "movies",
            "_type": "doc",
            "_id": "1",
            "_score": 0.2876821
          },
          "rating": 1
        }
      ],
      "metric_details": {
        "precision": {
          "relevant_docs_retrieved": 1,
          "docs_retrieved": 1
        }
      }
    }
  },
  "failures": {}
}

A lot better. Now we could find something. This is just an example to illustrate the workflow. (Note: A more detailed walkthrough of this process will be contained in a follow up blogpost to this topic.)
훨씬 나아졌다. 이제 무언가를 찾을 수 있다. 이것은 작업 흐름을 설명하는 예시일 뿐이다. (Note: 이 process의 더 자세한 내용은 이 게시물의 후속 게시물에 포함되어 있다.)

At this point, you have two options:
이 시점에서, 여러분은 2가지 옵션을 가진다.
- If the overall quality increases and meets your quality SLAs, you’re done, otherwise repeat until you reach the desired quality.
  전반적인 품질이 증가하고, 품질 SLA를 만족하면, 완료되었다. 그렇지 않으면, 원하는 품질에 이를 때까지 반복한다.
- If the overall quality decreases, revert the change, make a note of it for future reference and try something else.
  전반적인 품질이 떨어지면, 변경을 되돌리고, 나중에 참조할 수 있도록 메모해 두고, 다른 것을 시도하자.

Just remember: Ranking evaluation should be repeated periodically as data, users, and/or queries change. Every changing variable can affect relevancy (different index size, different data, different query templates, etc.). Please keep in mind, that it is usually not possible to completely exhaust every possible search. The number of questions (queries) and possible answers (results) is just too open and large to be evaluated scientifically with full test coverage.

data, 사용자, query가 변경되면, ranking evaluation을 주기적으로 반복해야 한다는 점을 기억하자. 변화하는 모든 변수(index size, data, query template 등)는 relevance에 영향을 미칠 수 있다. 일반적으로 가능한 모든 search를 완벽하게 하는 것은 불가능하다는 점을 기억하자. 질문(query)의 수와 가능한 답변(query)의 수는 너무 광범위하여, 전체 테스트 범위를 과학적으로 평가할 수는 없다.

In some cases, when you use your search engine to perform matching (e.g. name matching) and look for one specific result (or very few), then you could theoretically test it completely and your evaluation result would be a lot more representative. In most cases though you can only do partial testing of a sample. This is the reason why you should try to pick a representative sample of queries and you should try to work with realistic relevance judgements.

경우에 따라, search engine을 사용하여 match(예: 이름 match)를 수행하고, 하나의 특정 결과(또는 매우 작은)를 찾는 경우, 이론적으로 그것을 완벽하게 테스트할 수 있고, 평가 결과가 훨씬 더 대표적인 사례가 될 수 있다. 대부분의 경우 예제에 대한 부분적인 테스트만 할 수 있다. 이것이 query에 대한 대표적인 예제를 선택해야 하고 현실적인 relevance 판단을 가지고 작업해야 하는 이유이다.

Good luck with tuning relevance. As you start to use the Ranking Evaluation API, let us know about your feedback and experiences on our Discuss forum.

relevance tuning에 행운을 빈다. Ranking Evaluation API의 사용을 시작하면서, 여러분의 의견 및 경험에 대해 discuss forum에 알려주기 바란다.

원문 : Test-Driven Relevance Tuning of Elasticsearch using the Ranking Evaluation API

2018.06.27 - How to Search Chinese, Japanese, and Korean Text with Elasticsearch 6.2 - Part 3: Language Detector ...

drscg — Mon, 7 Jan 2019 14:31:23 +0900

이 글은 한국어, 중국어, 일본어 검색에 대한 3부작 중 마지막 글입니다. 만약 아직 1부를 읽지 않았다면 1부: 형태소 분석기부터 읽으시기 바랍니다. 엘라스틱서치 6.2를 이용한 한국어, 중국어, 일본어 검색 - 2부: Multi-fields에서는 멀티필드를 이용해서 다국어로 작성된 문서를 인덱싱하고 검색하는 방법을 살펴봤습니다. 하지만 하나의 텍스트를 언어에 상관 없이 4개의 필드에 저장하고 4개의 분석기로 분석하는 것은 시간과 저장공간의 낭비입니다. 이제 마지막으로 language detector를 이용해서 최적화해 보겠습니다. 텍스트는 역시 https://www.pyeongchang2018.com/ko/about-the-games에서 발췌했습니다.

Language detector

language detection용 ingest plugin(https://github.com/spinscale/elasticsearch-ingest-...)을 설치해서 시간과 저장공간을 절약하려고 합니다. 텍스트를 주 필드와 세 개의 서브필드로 인덱싱하는 대신, 아래 ingest pipeline의 langdetect processor는 “body” 필드의 언어를 감지해서 “language” 필드에 기록합니다. 그 다음 script processor는 “body” 필드의 내용을 언어별 필드(english_field, korean_field, japanese_field, or chinese_field)에 복사해서 분석합니다.

PUT _ingest/pipeline/langdetect-pipeline
{
  "description": "A pipeline to do whatever",
  "processors": [
    {
      "langdetect": {
        "field": "body",
        "target_field": "language"
      }
    },
    {
      "script": {
        "lang": "painless",
        "source": "if (ctx.language == 'ko') ctx.korean_field = ctx.body; if (ctx.language == 'ja') ctx.japanese_field = ctx.body; if (ctx.language == 'zh-cn') ctx.chinese_field = ctx.body; if (ctx.language == 'en') ctx.english_field = ctx.body;"
      }
    }
  ]
}

이 블로그에서는 kuromoji, smartcn, openkoreantext-analyzer를 이용하므로, 아래 인덱스를 만들기 전에 이들 플러그인을 설치해야 합니다.

DELETE test2
PUT /test2
{
  "mappings": {
    "docs": {
      "properties": {
        "body": {
          "type": "text"
        },
        "english_field": {
          "type": "text"
        },
        "korean_field": {
          "analyzer": "openkoreantext-analyzer",
          "type": "text"
        },
        "japanese_field": {
          "analyzer": "kuromoji",
          "type": "text"
        },
        "chinese_field": {
          "analyzer": "smartcn",
          "type": "text"
        }
      }
    }
  }
}

문서를 인덱싱할 때는 language detector를 사용하도록 “langdetect-pipeline” 파이프라인을 지정해야 합니다.

PUT /test2/docs/1?pipeline=langdetect-pipeline
{
  "body" : "The XXIII Olympic Winter Games will be held for 17 days from 9 to 25 February 2018 in PyeongChang, Gangwon Province, the Republic of Korea. PyeongChang was selected as the host city of the 2018 Olympic Winter Games after receiving a majority vote at the 123rd IOC Session held on 6 July 2011 after three consecutive bids. The Olympic Winter Games will be held in Korea for the first time in 30 years after the Seoul Olympic Games in 1988. PyeongChang will be the stage for the Opening and Closing Ceremonies and most snow sports. Alpine speed events will take place in Jeongseon, and all ice sports will be competed in the coastal city of Gangneung."
}
PUT /test2/docs/2?pipeline=langdetect-pipeline
{
  "body" : "제23회 동계올림픽대회는 대한민국 강원도 평창에서 2018년 2월 9일부터 25일까지 17일간 개최됩니다. 대한민국 평창은 세 번의 도전 끝에 지난 2011년 7월 6일 열린 제123차 IOC 총회에서 과반 표를 획득하며 2018년 동계올림픽 개최지로 선정되었습니다. 이로써 대한민국에서는 1988년 서울 올림픽 이후 30년 만에, 평창에서 개∙폐회식과 대부분의 설상 경기가 개최되며, 강릉에서는 빙상 종목 전 경기가, 그리고 정선에서는 알파인 스키 활강 경기가 개최될 예정입니다."
}
PUT /test2/docs/3?pipeline=langdetect-pipeline
{
  "body" : "第23届冬季奥运会将于2018年2月9日-25日在韩国江原道平昌展开。韩国平昌在第三次申奥之后，于2011年7月6日召开的第123届国际奥委会全会上被选定为2018年冬季奥运会的主办地。由此，韩国自1988年举办首尔夏季奥运会以后，时隔30年，将首次举办冬季奥运会。该届冬奥会的开·闭幕式以及大部分的雪上运动将在平昌进行，而所有冰上运动将在江陵、高山滑雪滑降比赛则将在旌善进行。"
}
PUT /test2/docs/4?pipeline=langdetect-pipeline
{
  "body" : "第23回冬季オリンピック大会は大韓民国江原道平昌で2018年2月9日から25日までの17日間、開催されます。大韓民国・平昌は三度の挑戦の末、2011年7月7日に開かれた第123回IOC総会で過半数票を獲得し、2018年冬季オリンピック及びパラリンピックの開催地に選ばれました。これにより1988年ソウルオリンピック開催後30年の時を経てついに、大韓民国で最初の冬季パラリンピックの舞台が繰り広げられます。平昌で開・閉会式とほぼ全ての雪上競技が開催され、江陵では氷上種目全競技が、そして旌善ではアルペンスキー滑降競技が開催される予定です。"
}
Read Less

예를 들어, “body” 필드의 내용이 한국어이면, 아래와 같이 “korean_field”로 복사됩니다.

GET /test2/docs/2
=>
{
  "_index": "test",
  "_type": "docs",
  "_id": "2",
  "_version": 1,
  "found": true,
  "_source": {
    "language": "ko",
    "body": "제23회 동계올림픽대회는 대한민국 강원도 평창에서 2018년 2월 9일부터 25일까지 17일간 개최됩니다. 대한민국 평창은 세 번의 도전 끝에 지난 2011년 7월 6일 열린 제123차 IOC 총회에서 과반 표를 획득하며 2018년 동계올림픽 개최지로 선정되었습니다. 이로써 대한민국에서는 1988년 서울 올림픽 이후 30년 만에, 평창에서 개∙폐회식과 대부분의 설상 경기가 개최되며, 강릉에서는 빙상 종목 전 경기가, 그리고 정선에서는 알파인 스키 활강 경기가 개최될 예정입니다.",
    "korean_field": "제23회 동계올림픽대회는 대한민국 강원도 평창에서 2018년 2월 9일부터 25일까지 17일간 개최됩니다. 대한민국 평창은 세 번의 도전 끝에 지난 2011년 7월 6일 열린 제123차 IOC 총회에서 과반 표를 획득하며 2018년 동계올림픽 개최지로 선정되었습니다. 이로써 대한민국에서는 1988년 서울 올림픽 이후 30년 만에, 평창에서 개∙폐회식과 대부분의 설상 경기가 개최되며, 강릉에서는 빙상 종목 전 경기가, 그리고 정선에서는 알파인 스키 활강 경기가 개최될 예정입니다."
  }
}
Read Less

멀티필드를 사용했을 때와 비슷한 검색 결과를 얻을 수 있습니다. 결과를 필터링하기 위해 source filtering을 사용했습니다.

한국어

POST /test2/_search
{
  "query": {
    "multi_match": {
      "query": "올림픽대회",
      "fields": [
        "english_field",
        "korean_field",
        "chinese_field",
        "japanese_field"
      ]
    }
  },
  "_source": "body"
}
=>
...
  "hits": {
    "total": 1,
    "max_score": 0.57860667,
    "hits": [
      {
        "_index": "test",
        "_type": "docs",
        "_id": "2",
        "_score": 0.57860667,
        "_source": {
          "body": "제23회 동계올림픽대회는 대한민국 강원도 평창에서 2018년 2월 9일부터 25일까지 17일간 개최됩니다. 대한민국 평창은 세 번의 도전 끝에 지난 2011년 7월 6일 열린 제123차 IOC 총회에서 과반 표를 획득하며 2018년 동계올림픽 개최지로 선정되었습니다. 이로써 대한민국에서는 1988년 서울 올림픽 이후 30년 만에, 평창에서 개∙폐회식과 대부분의 설상 경기가 개최되며, 강릉에서는 빙상 종목 전 경기가, 그리고 정선에서는 알파인 스키 활강 경기가 개최될 예정입니다."
        }
      }
    ]
  }
}
Read Less

영어

POST /test2/_search
{
  "query": {
    "multi_match": {
      "query": "Olympic Games",
      "fields": [
        "english_field",
        "korean_field",
        "chinese_field",
        "japanese_field"
      ]
    }
  },
  "_source": "body"
}
=>
...
  "hits": {
    "total": 1,
    "max_score": 0.97953933,
    "hits": [
      {
        "_index": "test",
        "_type": "docs",
        "_id": "1",
        "_score": 0.97953933,
        "_source": {
          "body": "The XXIII Olympic Winter Games will be held for 17 days from 9 to 25 February 2018 in PyeongChang, Gangwon Province, the Republic of Korea. PyeongChang was selected as the host city of the 2018 Olympic Winter Games after receiving a majority vote at the 123rd IOC Session held on 6 July 2011 after three consecutive bids. The Olympic Winter Games will be held in Korea for the first time in 30 years after the Seoul Olympic Games in 1988. PyeongChang will be the stage for the Opening and Closing Ceremonies and most snow sports. Alpine speed events will take place in Jeongseon, and all ice sports will be competed in the coastal city of Gangneung."
        }
      }
    ]
  }
}
Read Less

일본어

POST /test2/_search
{
  "query": {
    "multi_match": {
      "query": "オリンピック大会",
      "fields": [
        "english_field",
        "korean_field",
        "chinese_field",
        "japanese_field"
      ]
    }
  },
  "_source": "body"
}
=>
...
  "hits": {
    "total": 1,
    "max_score": 0.7469032,
    "hits": [
      {
        "_index": "test2",
        "_type": "docs",
        "_id": "4",
        "_score": 0.7469032,
        "_source": {
          "body": "第23回冬季オリンピック大会は大韓民国江原道平昌で2018年2月9日から25日までの17日間、開催されます。大韓民国・平昌は三度の挑戦の末、2011年7月7日に開かれた第123回IOC総会で過半数票を獲得し、2018年冬季オリンピック及びパラリンピックの開催地に選ばれました。これにより1988年ソウルオリンピック開催後30年の時を経てついに、大韓民国で最初の冬季パラリンピックの舞台が繰り広げられます。平昌で開・閉会式とほぼ全ての雪上競技が開催され、江陵では氷上種目全競技が、そして旌善ではアルペンスキー滑降競技が開催される予定です。"
        }
      }
    ]
  }
}
Read Less

중국어

POST /test2/_search
{
  "query": {
    "multi_match": {
      "query": "奥运会",
      "fields": [
        "english_field",
        "korean_field",
        "chinese_field",
        "japanese_field"
      ]
    }
  },
  "_source": "body"
}
=>
...
  "hits": {
    "total": 1,
    "max_score": 0.49148652,
    "hits": [
      {
        "_index": "test2",
        "_type": "docs",
        "_id": "3",
        "_score": 0.49148652,
        "_source": {
          "body": "第23届冬季奥运会将于2018年2月9日-25日在韩国江原道平昌展开。韩国平昌在第三次申奥之后，于2011年7月6日召开的第123届国际奥委会全会上被选定为2018年冬季奥运会的主办地。由此，韩国自1988年举办首尔夏季奥运会以后，时隔30年，将首次举办冬季奥运会。该届冬奥会的开·闭幕式以及大部分的雪上运动将在平昌进行，而所有冰上运动将在江陵、高山滑雪滑降比赛则将在旌善进行。"
        }
      }
    ]
  }
}
Read Less

주목할 것은 일본어 키워드로 검색하면 일본어 문서만 리턴되고, 중국어 키워드로 검색하면 중국어 문서만 리턴된다는 것입니다. 이는 엘라스틱서치 6.2를 이용한 한국어, 중국어, 일본어 검색 - 2부: Multi-fields와 다른데, 언어별 분석기로 분석된 필드만 검색하기 때문입니다.

시간이 더 걸리진 않을까요?

인덱싱이나 쿼리에 걸리는 시간이 걱정된다면, 멀티필드나 language detector를 이용해서 인덱싱하는 데 걸리는 시간은 단일 필드를 이용할 때보다 약간 더 길지만 큰 차이는 없습니다.

그림 1 500개의 문서를 인덱싱하는 데 걸리는 시간(맥북 프로, 2.9 GHz 인텔 코어 i7, 16GB 2133 MHz LPDDR3)

멀티필드나 language detector를 이용해서 쿼리하는 데 걸리는 시간은 단일 필드를 이용할 때와 거의 같습니다.

그림 2 쿼리를 500번 실행하는 데 걸리는 시간(맥북 프로, 2.9 GHz 인텔 코어 i7, 16GB 2133 MHz LPDDR3)

Language detector를 이용하면, 멀티필드를 쓸 때보다 좋은 쿼리 결과를 얻을 수 있고 저장공간도 절약할 수 있습니다. 엘라스틱서치 6.x에는 심지어 “Sparse Field Improvements” (Space Saving Improvements in Elasticsearch 6.0 참고)도 포함되어 있습니다.

부록

multi-lang-scripts.zip

index.sh - 인덱싱 시간 측정 스크립트
query.sh - 쿼리 시간 측정 스크립트

원문 : 엘라스틱서치 6.2를 이용한 한국어, 중국어, 일본어 검색 - 3부: Language Detector

2018.05.03 - 번역 - Improving Response Latency in Elasticsearch with Adaptive Replica Selection ...

drscg — Mon, 7 Jan 2019 14:28:50 +0900

Introduction

In this blog post, I am going to describe a new feature of Elasticsearch called Adaptive Replica Selection (ARS). Before describing what ARS does, I’ll first describe the problem that it tries to solve. Imagine that you have a cluster with three nodes. And across those three nodes, you have a shard and its replicas.

이 게시물에서는 Elasticsearch의 새로운 기능인 Adaptive Replica Selection (ARS)를 설명하려 한다. 먼저 해결하려는 문제에 대해 설명하겠다. 3개의 node를 가진 cluster를 가정하자. 3개의 node에 shard와 그 replica가 있다.

Then imagine that one node starts to experience distress.

그런 다음, 한 node에 문제가 있다고 가정하자.

When a search request is received, Elasticsearch first determines which shards need to be queried, and then determines which nodes contain copies of that shard. Once it’s done that, it then sends the request to a single copy of the shard via round-robin selection. So if Elasticsearch sends the request to shard copy 2, we will see degraded performance compared to requests to the other copies:

search request가 들어오면, 먼저 Elasticsearch는 query에 어떤 shard가 필요한지를 결정하고, 해당 shard의 복사본을 가지고 있는 node가 어떤 것인가를 결정한다. 이것이 완료되면, round-robin 방식으로 shard의 단일 복사본에 request를 전송한다. 따라서, Elasticsearch가 shard 복사본 2에 request를 전송하면, 다른 복사본에 request하는 것에 비해 성능이 저하될 것이다.

shard copy 1: 100ms
shard copy 2 (degraded): 1350ms
shard copy 3: 150ms

The degradation of the node with the second copy of the data can be caused by any number of things, like long garbage collection cycles, high disk IO, network saturation, or heterogeneous node types. This causes tail latency of requests to rise, not to mention it frustrates whoever is unlucky enough to be waiting for the query when it’s run against shard copy 2.

data의 두번째 복사본이 있는 node의 성능 저하는 긴 GC 주기, 높은 disk IO, network 포화, 이기종 node 유형 같은 여러 가지 원인으로 발생할 수 있다. 이로 인해, request에 대한 대기 시간이 길어지고, shard 복사본 2에 대해 실행한 query를 기다리는 불운한 이를 좌절케 한다는 것은 말할 것도 없다.

So what can be done? We would like Elasticsearch to be smart enough to route requests to the other copies of data until this node has recovered enough to handle more search requests. In Elasticsearch, we call this process of selecting the best available copy of the shard Adaptive Replica Selection.

그렇다면, 무엇을 할 수 있을까? Elasticsearch는 이 node가 더 많은 search request를 처리할 수 있도록 복구될 때까지 data의 다른 복사본으로 request를 route할 수 있을 만큼 충분히 스마트하다고 여긴다. Elasticsearch에서, shard의 가장 활용 가능한 복사본을 선택하는 이 process를 Adaptive Replica Selection라 한다.

Adaptive Replica Selection

ARS is an implementation of an academic paper called C3: Cutting Tail Latency in Cloud Data Stores via Adaptive Replica Selection. Originally, the paper was written for Cassandra, which means we had to adapt some things to fit Elasticsearch due to the differences in behavior between the two.

ARS는 C3: Adaptive Replica Selection을 통한 Cloud Data 저장소에서의 대기 시간 단축이라는 학술 논문을 구현한 것이다. 원래 이 논문은 Cassandra를 위해 작성되어, 둘 사이의 동작 방식의 차이 때문에 몇 가지를 Elasticsearch에 맞도록 수정해야 했다.

Our ARS implementation is based on a formula where, for each search request, Elasticsearch ranks each copy of the shard to determine which is likeliest to be the "best" copy to send the request to. Instead of sending requests in a round-robin fashion to each copy of the shard, Elasticsearch selects the "best" copy and routes the request there.

ARS 구현은 각 search request에 대하여, ELasticsearch가 request를 전송할 때 "최상"의 복사본이 될 가능성이 가장 높은 복사본을 결정하기 위하여, 각 shard 복사본의 순위를 결정하는 수식을 기반으로 한다. shard의 각 복사본에 round-robin 방식으로 request를 전송하는 대신, Elasticsearch는 "최상"의 복사본을 선택하고 거기에 request를 route한다.

The ARS formula initially seems complex, but let's break it down:

ARS 수식은 처음에는 복잡해 보인다. 하지만 그것을 나눠보면

Ψ(s) = R(s) - 1/µ̄(s) + (q̂(s))^3 / µ̄(s)

Where q̂(s) is:

q̂(s) = 1 + (os(s) * n) + q(s)

And looking at the individual pieces:

개별 부분을 보면

os(s) is the number of outstanding search requests to a node
os(s) 는 node에서 아직 처리하지 못한 search request의 수이다.
n is the number of data nodes in the system
n 은 system에서 data node의 수이다.
R(s) is the EWMA of the response time (as seen from the node coordinating the search) in milliseconds
R(s) 는 response 시간(coordinating node에서 본)의 EWMA이다. ms 단위
q(s) is the EWMA of the number of events in the search thread pool queue
q(s) 는 search thread pool queue에서 event 수의 EWMA이다.
µ̄(s) is the EWMA of service time of search events on the data node in milliseconds
µ̄(s)̄ 는 data node에서의 search event의 service time의 EWMA이다.

Response time is the time measured for a request from the coordinating node, whereas service time is the time measured on the node executing the request (not including any time the request may have spent in the queue). Roughly speaking, this means that as the difference between the response time and service time grows — as well as the number of searches in the queue and the outstanding requests for a node — the higher a score the node will receive (lower scored nodes are considered the “best” ranked). For example, the (q̂(s))^3 part of the formula means that as the number of connections to a data node, and the number of searches in the node’s queue increases, the score will go up in a cubic exponential manner. By factoring in the number of outstanding search requests in the formula, we also make sure that nodes with identical load and response times still distribute requests among shard copies.

response time은 coordinating node에서 request에 대해 측정한시간이고, 반면에 service time은 request를 실행한 node에서 축정한 시간(request가 queue에서 소비한 시간은 포함하지 않음)이다. 대략적으로 말하면, 이는 response time과 service time(뿐만 아니라 queue의 search 수와 node에서 아직 처리하지 못한 request의 수)의 차이가 증가하면, node가 받을 score가 더 높아진다(더 낮은 score를 가진 node가 "최상"의 순위로 간주된다)는 것을 의미한다. 예를 들어, 수식의 (q̂(s))^3 부분은 data node에 대한 연결 수와 node의 queue에 있는 search의 수가 증가함에 따라, score가 3제곱의 형식으로 증가하는 것을 의미한다. 수식에서, 아직 처리하지 못한 search request의 수를 고려하여, 동일한 loadd와 response time을 가진 node가 여전히 shard 복사본간에 request를 배포하는지를 확인한다.

Elasticsearch gathers most of these values using a specialized thread pool for search actions on each of the nodes. For each search response, these values are piggybacked on the results back to the coordinating node, which stores them so the node can be ranked for subsequent requests. When the next search request comes in, the node with the lowest score will serve the request. If the node encounters an exception, the node with the next best score serves the search request. Since we don't want loaded nodes to have searches routed away forever, every time a node is not the best ranked node, we slightly adjust the score to make it a better candidate for handling future requests.

Elasticsearch는 각 node의 search 작업을 위하여 특별한 thread pool을 사용하여 이들 값의 대부분을 수집한다. 각 search response에 대해, 이들 값은 coordinating node로 반환되는 결과에 덧붙여지고, coordinating node는 그것을 저장하여, node는 이어지는 request에에 대해 순위를 매길 수 있다. 다음 search request가 들어오면, 가장 낮은 score를 가진 node가 request를 처리한다. 만약 node에서 exception이 발생하면, 다음 최상의 score를 가진 node가 request를 처리한다. 부하를 가진 node에 계속해서 search가 route되지 않도록, node가 최상위 node가 아닐 때 마다 score를 약간 조정하여, 향후 request를 처리할 수 있는 더 나은 후보가 되도록 한다.

Going back to our original example, the selected node for the request would be either shard copy 1 or 3, avoiding the overloaded shard copy 2.

원래의 예제로 되돌아가서, request에 의해 선택된 node는 과부하가 걸린 shard copy 2를 피하여, copy 1이나 3이 될 것이다.

ARS is available in Elasticsearch 6.1 and later, but is turned off by default in all 6.x releases. It can be turned on dynamically by changing the cluster.routing.use_adaptive_replica_selection setting:

ARS는 available in Elasticsearch 6.1 이후 버전에서 이용할 수 있다. 그러나, 모든 6.x 에서 기본적으로 비활성화되어 있다. cluster.routing.use_adaptive_replica_selection 설정을 변경하여, 동적으로 활성화할 수 있다.

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.use_adaptive_replica_selection": true
  }
}

In Elasticsearch 7.0 and later, ARS will be turned on by default.

Elasticsearch 7.0 이후에는 기본적으로 활성화된다.

Improvements with ARS

How much do we expect this to help? We ran benchmarks with Rally for many scenarios, both with and without simulating load on one of the nodes containing a copy of the data. In our case, we used a single coordinating node connected to a cluster of five nodes, searching an index with five primary shards each with a single replica. In each benchmark, the search requests were sent as quickly as possible from 100 Rally connections.

이것이 얼마나 도움이 될가? data의 복사본을 가지고 있는 node 중 하나에 부하를 주는 시뮬레이션을 하거나 하지 않고, 많은 시나리오에 대해 Rally로 벤치마크했다. 우리의 경우, 5개의 node를 가진 cluster에 연결된 단일 coordinating node를 사용하여, 각각 하나의 replica를 가진 5개의 primary shard가 있는 index를 검색했다. 각 벤치마크에서, search request는 100개의 Rally connection에서 가능한 한 빨리 전송하였다.

Non-loaded case:

Metric	No ARS	ARS	Change %
Median Throughput (queries/s)	95.7866	98.537	2.8
Median latency (ms)	1003.29	970.15	-3.3
90th percentile latency (ms)	1339.69	1326.79	-0.9
99th percentile latency (ms)	1648.34	1648.8	0.027

The non-loaded case makes sense in a system where none of the nodes are under undue stress (high GCs, disk issues, etc). We expected throughput and latency to remain largely the same, which it did. Since a coordinating node is being used for queries, we avoided hotspots from a node having to coordinate any of the search responses.

부하가 없는 사례는 node가 과도한 스트레스(높은 GC, disk 문제 등)를 받지 않는 싯스템에 적당하다. 처리량과 대기시간이 거의 동일하게 유지되기를 기대했고 그러했다. coordinating node는 query에 대해 사용되므로, search response를 조정해야 하는 node의 hotspot을 피했다.

Single node under load:

Metric	No ARS	ARS	Change %
Median Throughput (queries/s)	41.1558	87.8231	113.4
Median latency (ms)	411.721	1007.22	144.6
90th percentile latency (ms)	5215.34	1839.46	-64.7
99th percentile latency (ms)	6181.48	2433.55	-60.6

In this scenario we simulated load on a node by using the stress command with the parameters stress -i 8 -c 8 -m 8 -d 8 (which runs stress with 8 CPU workers, 8 IO workers, 8 memory workers, and 8 hard drive workers). With ARS there is a large improvement in throughput for the loaded case, as well as a trade-off of 50th percentile latency for a large improvement in 90th and 99th percentile latency. So we were able to route around the degraded node quite well. The 50th percentile latency increase is expected since instead of requests having a "luck-of-the-draw" for whether they go to an unstressed or stressed node, they now avoid the stressed node, slightly increasing load for the unstressed nodes (and thus latency).

이 시나리오에서 stress -i 8 -c 8 -m 8 -d 8 (각각 8개의 CPU worker, IO worker, memory worker, hard drive worker를 가진 stress를 실행한다)라는 매개변수를 가진 stress command를 사용하여, node애 부하를 주는 테스트를 했다. ARS를 사용하면, 부하를 가진 경우에 대해 처리량이 크게 개선되고, 90~99번째 백분위 대기시간이 크게 증가하여 50번째 백분위와 절충된다. 그래서, 성능이 저하된 node 주변으로 잘 route할 수 있다. request가 stress를 받는 node로 갈지 받지 않는 node로 갈지를 운에 맡기는 대신, stress를 받는 node를 피하고 stress를 받지 않는 node에 대한 부하(따라서 대기시간도)를 약간 증가시키기 때문에, 50번째 백분위 대기시간 증가가 예상된다.

Single replica, round-robin requests:

Metric	No ARS	ARS	Change %
Median Throughput (queries/s)	89.6289	95.9452	7.0
50th percentile latency (ms)	1088.81	1013.61	-6.9
90th percentile latency (ms)	1706.07	1423.83	-16.5
99th percentile latency (ms)	2481.1	1783.73	-28.1

Finally we tested without a coordinating node, sending the requests in a round-robin manner to each node in the cluster without any stress induced. An improvement can be seen in both throughput and latency. So even if the cluster is experiencing even load, ARS can still improve throughput and latency.

마지막으로, coordinating node없이, stress를 유발하지 않고 cluster의 각 node에 round-robin 방식으로 request를 전송하여 테스트했다. 처리량과 대기시간 모두 개선되었다. 따라서, cluster에 부하가 발생하더라도, ARS는 여전히 처리량과 대기시간을 개선할 수 있다.

Conclusion

As you can see, we expect Adaptive Replica Selection to help in many situations. ARS allows the coordinating node to be aware of the load on the data nodes and allows it to choose the best shard copies for executing a search, improving search throughput as well as latency. If you are using Elasticsearch 6.1 or later, please try it out and let us know any feedback you have!

보다시피, Adaptive Replica Selection는 많은 상황에서 도움이 될 것으로 기대한다. ARS를 사용하면, coordinating node는 data node의 부하를 인식할 수 있고, search 실행을 위한 최상의 shard 복사본을 선택하여, 처리량과 대기시간을 향상시킬 수 있다. Elasticsearch 6.1 이후를 사용하고 있다면, 적용해 보자.

원문 : Improving Response Latency in Elasticsearch with Adaptive Replica Selection

2017.11.22 - 번역 - Why am I seeing bulk rejections in my Elasticsearch cluster? ...

drscg — Mon, 7 Jan 2019 14:11:54 +0900

Elasticsearch supports a wide range of use-cases across our user base, and more and more of these rely on fast indexing to quickly get large amounts of data into Elasticsearch. Even though Elasticsearch is fast and index performance is continually improved, it is still possible to overwhelm it. At that point you typically see parts of bulk requests getting rejected. In this blog post we will look at the causes and how to avoid it.

Elasticichearch는 사용자 기반 전체에서 광범위한 사용 사례를 지원하며, 점점 더 많은 사용자들이 빠른 indexing을 통해 대량의 data를 Elasticsearch로 빠르게 가져오고 있다. 비록 Elasticsearch가 빠르고, index 성능이 지속적으로 개선되고 있지만, 이것을 압도하는 것은 여전히 가능한 일이다. 이 시점에서 일반적으로 bulk request의 일부가 거부되는 것을 볼 수 있다. 이 블로그 포스트에서 우리는 그 원인과 그것을 피하는 방법을 살펴볼 것이다.

This is the second installment in a series of blog posts where we look at and discuss your common questions. The first installment discussed and provided guidelines around "How many shards one should aim to have in an Elasticsearch cluster?"

이는 우리가 여러분들의 흔한 질문들을 보고 토론하는 블로그 포스트들의 두번째 부분이다. 첫번째는 "How many shards one should aim to have in an Elasticsearch cluster?" 에서 토론하여 가이드라인을 제공했다.

What happens when a bulk indexing request is sent to Elasticsearch?

Let’s start at the beginning and look at what happens behind the scenes when a bulk indexing request is sent to Elasticsearch.

먼저 bulk indexing request가 Elasticsearch에 전송되면, 배후에서 어떤 일이 발생하는지 살펴보자.

When a bulk request arrives at a node in the cluster, it is, in its entirety, put on the bulk queue and processed by the threads in the bulk thread pool. The node that receives the request is referred to as the coordinating node as it manages the life of the request and assembles the response. This can be a node dedicated to just coordinating requests or one of the data nodes in the cluster.

bulk request가 cluster의 node에 도달하면, 전체적으로, 그것을 bulk queue에 넣고, bulk thread pool의 thread에 의해 처리된다. request를 받은 node는, request의 수명을 관리하고 reponse을 구성하기 때문에 coordinating node라고 한다. 이는 단지 request를 coordinating하는 전용 node이거나 cluster의 data node 중 하나일 수 있다.

A bulk request can contain documents destined for multiple indices and shards. The first processing step is therefore to split it up based on which shards the documents need to be routed to. Once this is done, each bulk sub-request is forwarded to the data node that holds the corresponding primary shard, and it is there enqueued on that node’s bulk queue. If there is no more space available on the queue, the coordinating node will be notified that the bulk sub-request has been rejected.

bulk request는 복수의 indices 및 shard를 위한 document가 포함될 수 있다. 그러므로 첫번째 처리 단계는 document를 routing해야 하는 shard에 따라 data를 분할하는 것이다. 이 작업이 완료되면, 각 bulk sub-request이 해당 primary shard를 저장하고 있는 data node로 전달되며, 이 node의 bulk queue에 추가된다. queue에 사용할 수 있는 공간이 더 이상 없으면, coordinating node에 bulk sub-request가 거부되었음을 알리게 된다.

The bulk thread pool processes requests from the queue and documents are forwarded to replica shards as part of this processing. Once the sub-request has completed, a response is sent to the coordinating node.

bulk thread pool은 queue에서 request를 처리하고, document는 이 처리 과정의 일환으로 replica shard로 전달된다. sub-request가 완료되면 coordinating node로 reponse가 전송된다.

Once all sub-requests have completed or been rejected, a response is created and returned to the client. It is possible, and even likely, that only a portion of the documents within a bulk request might have been rejected.

모든 sub-request가 완료되거나 거부되면, response가 생성되어 client로 반환된다. bulk request에 포함된 document 중 일부만 거부될 수도 있다.

The reason Elasticsearch is designed with request queues of limited size is to protect the cluster from being overloaded, which increases stability and reliability. If there were no limits in place, clients could very easily bring a whole cluster down through bad or malicious behaviour. The limits that are in place have been set based on our extensive experience supporting Elasticsearch for different types of use-cases.

Elasticsearch가 제한된 크기의 request queue로 설계된 이유는 안정성과 신뢰성을 높여, cluster가 과부하가 걸리는 것을 방지하기 위함입니다. 제한이 없는 경우, client는 좋지 않은 혹은 악의적인 동작을 통해, 전체 cluster를 아주 쉽게 중단시킬 수 있다. 현재의 제한 사항은 다양한 유형의 사용 사례에 대해 Elasticsearch를 지원하는 우리의 광범위한 경험에 기초하여 설정되었다.

When using the HTTP interface, requests that results in at least a partial rejection will return with response code 429, 'Too many requests'. The principle also applies when the transport protocol is used, although the protocol and interface naturally is different. Applications and clients may report these errors back to the user in different ways, and some may even attempt to handle this automatically by retrying any rejected documents.

HTTP interface를 사용하는 경우, 최소한의 부분적인 거부를 return하는 request는 response code 429, 'Too many requests' 와 함께 return된다. 비록 protocol과 interface는 당연히 다르지만, transport protocol이 사용될 경우에도 이 원칙이 적용된다. application과 client는 이러한 오류를 사용자에게 다른 방식으로 보고할 수 있으며, 어떤 사용자는 거부된 document를 다시 시도하여, 이 오류를 자동으로 처리하려고 할 수도 있다.

How can we test this in practice?

In order to illustrate the practical impact of this behaviour, we devised a simple test where we use our benchmarking tool Rally to run bulk indexing requests against a couple of Elastic Cloud clusters with varying number of data nodes. Configuration and instructions on how to run Rally is available in this gist.

이러한 동작이 실제 상황에서 미치는 영향을 설명하기 위해, 우리는 benchmarking tool Rally를 사용하여, data node 수가 다양한 2 개의 Elastic Cloud clusters에 대해,bulk indexing request을 실행하는 간단한 테스트를 실시했다. Rally를 운영하는 방법에 대한 구성 및 지침은 여기에서 확인할 수 있다.

The same indexing workload was run against three different Elastic Cloud clusters. We have been indexing with one replica shard configured wherever possible. The clusters consisted of one, two and three data nodes respectively, with each data node having 8GB RAM (4GB heap for Elasticsearch, 4GB native memory). Invoking the GET /_nodes/thread_pool API we could see that each data node by default had a fixed bulk thread pool size of two with a queue size of 200:

3개의 서로 다른 Elastic Cloud cluster에 대해서도 동일한 indexing 작업을 실행했다. 우리는 가능한 한, 항상 하나의 replica shard를 설정하고 indexing 작업을 수행했다. cluster는 각각 1개, 2개 및 3개의 data node로 구성되었으며, 각 data node는 8 GB RAM(Elasticsearch에 4GB heap, 4 GB 기본 momory)을 가진다. GET /_nodes/thread_pool API를 호출하면 ,기본적으로 각 data node의 queue의 크기가 200이고, 고정된 bulk thread pool 크기가 2라는 것을 알수 있다.

%> curl -XGET http://<es_url>:<es_port>/_nodes/thread_pool</es_port></es_url>
"bulk": {
"type": "fixed",
"min": 2,
"max": 2,
"queue_size": 200
}

During the test we indexed into a varying number of shards (2, 4, 8, 16, and 32) using a varying number of concurrent clients (8, 16, 24, 32, 48, and 64) for each cluster. For every combination of shard and client count we indexed 6.4 million documents with a batch size of 100 documents and another 6.4 million documents with a batch size of 200 documents. This means that in total we attempted to index 384 million documents per cluster.

test를 하면서, 각 cluster에 대해 다양한 수의 동시(concurrent) client(8, 16, 24, 32, 48, 64)를 사용하여 다양한 수의 shard(2, 4, 8, 16, 16, 32)로 index했다. shard와 client 수를 조합할 때마다, 640만개의 document는 batch 크기를 100으로, 다른 640만개의 document는 batch 크기를 200으로 index했다. 즉, cluster별로 384만개의 document를 indexing하려고 했다.

For this test we treat the clusters as a black box, and perform the analysis from the client’s perspective. To limit the scope we will also not look at the impact of various configurations on performance as that is a quite large topic on its own.

이 테스트에서는 cluster를 black box로 취급하고, client의 관점에서 분석을 수행했다. 범위를 제한하기 위해, 다양한 구성이 성능에 미치는 영향은 다루지 않을 것이다. 이는 상당히 큰 주제이기 때문이다.

All the generated, detailed metrics were sent to a separate Elastic Cloud instance for analysis using Kibana. For each request Rally measures how many the documents in the bulk request were rejected and successful. Based on this data we can classify each request as successful, partially rejected, and fully rejected. A few requests also timed out, and these have also been included for completeness.

생성된 모든 상세 측정값은 Kibana를 사용하여 분석할 수 있도록 별도의 Elastic Cloud instance로 전송되었다. 각 request에 대해, bulk request에서 거부되고 성공한 문서 수를 Rally로 측정했다. 이러한 data를 토대로, 각 request를 성공, 부분 거부, 완전한 거부로 분류하였다. 또한 약간의 time out된 request도, 완벽을 기하기 위해, 포함되었다.

Unlike Beats and Logstash, Rally does not retry failed indexing requests, so each has the same number of requests executed but the final number of documents indexed varied from run to run depending on the volume of rejections.

Beats및 Logstash와 달리, Rally는 실패한 indexing request를 다시 시도하지 않기 때문에, 실행된 request의 수는 동일하지만, 최종적으로 index된 document의 수는 거부의 양에 따라 달라진다.

How bulk rejection frequency depend on shard count, clients count, and data node count?

Bulk rejections occur when the bulk queues fill up. The number of queue slots that get used depends both on the number of concurrent requests, and the number of shards being indexed into. To measure this correlation we have added a calculated metric, client shard concurrency, to each run. This is defined as the number of shards being indexed into, multiplied by the number of concurrent indexing threads, and indicates how many queue slots would be needed to hold all bulk sub-requests.

bulk 거부는 bulk queue이 가득 차면 발생한다. 사용되는 queue slot의 수는 동시 request 수와 indexing 되는 shard 수에 따라 달라진다. 이러한 상관 관계를 측정하기 위해, 각각의 실행에 계산된 지표인 client shard concurrency이 추가되었다. 이는 index될 shard의 수와 동시 indexing thread 수를 곱한 것으로 정의되며, 모든 bulk sub-request을 보관하는 데 필요한 queue slot 수를 나타낸다.

In the graph below, we show how the percentage of requests that result in partial or full rejections, depends on the client shard concurrency for the three different clusters.

아래 그래프는, 서로 다른 세개의 cluster에 대해, client shard concurrency에 따라, 부분 또는 완전한 거부가 발생하는 request의 비율이 어떻게 달라지는지 보여준다.

For clusters with one or two nodes we can see that appearance of bulk rejections start when the client shard concurrency level is somewhere between 192 and 256. This makes sense as each node has a bulk queue size of 200. For the cluster with 3 nodes we can see that it is able to handle even higher level of client shard concurrency without any bulk rejections appearing.

node가 하나 또는 두개인 cluster의 경우, client shard concurrency 수준이 192개에서 256개 사이가 되면, bulk 거부가 시작되는 것을 볼 수 있다. 각 node의 bulk queue 크기가 200개이므로 이는 타당합니다. node가 3개인 cluster의 경우, bulk 거부 반응 없이 더 높은 수준의 client shard concurrency을 처리할 수 있다는 것을 알 수 있다.

Once we get over this limit, we start seeing partial bulk rejections, where at least one sub-request has managed to get queued and processed. A relatively small portion of requests also result on full rejections as the concurrency level increases, especially for the single node cluster.

이 한계를 넘으면 부분적인 bulk 거부가 발생하기 시작하며, 여기서 하나 이상의 sub-request가 queue에 들어가 처리된다. 또한, 상대적으로 request의 작은 부분이, concurrency 수준이 증가함에 따라, 특히 단일 node cluster에 대해, 완전한 거부를 야기한다.

When we compare the single and two node clusters, we can see that the percentage of fully successful requests increases slightly and that there are fewer full rejections. This is expected, as the total bulk queue across the cluster is twice as large and requests are sent to all data nodes. Even though the total bulk queue size is twice as large across the cluster, the 2 node cluster does not appear able to handle twice the client shard concurrency of the single node cluster. This is likely due to the fact that distribution is not perfect and that the introduction of replica shards have resulted in each indexing operation requiring more work and being slower as a result. An important thing to note is also that all partial rejections are treated as equals in this graph. The number of rejected documents is not shown and does indeed vary depending on the cluster size, but we will shortly look at that in greater detail.

단일 node cluster와 2 node cluster를 비교하면, 완전히 성공한 request의 비율이 약간 증가하고 완전한 거부 횟수가 줄어드는 것을 알 수 있다. 이는 cluster의 총 bulk queue 크기가 2배가 되고 모든 data node에 request가 전송되기 때문에 예상되는 일다. 전체 bulk queue 크기가 cluster에서 2배로 되지만, 2 node cluster가 단일 node cluster의 client shard concurrency의 2배를 처리할 수 없을 것으로 보이지는 않는다. 이는 분포가 완벽하지 않고, replica shard를 도입하면 각각의 indexing 연산에 더 많은 작업이 필요하고, 그 결과 작업 속도가 느려지기 때문일 수 있다. 주목해야 할 중요한 점은 이 그래프에서 모든 부분적 거부가 동등하게 취급된다는 것이다. 거부된 문서의 수는 표시되지 않으며 cluster 크기에 따라 실제로 달라질 수 있다. 하지만 이에 대해서는 곧 자세히 살펴보겠습니다.

When we go to three data nodes, we see a more marked improvement, and receive requests without any rejections at high levels of concurrency. We also only see full rejections for the highest concurrency levels.

3개의 data node가 되면 더 큰 향상을 볼 수 있으며, 높은 수준의 concurrency로 어떤 거부 없이 request를 받는다. 또한 가장 높은 concurrenc 수준에 대한 완전한 거부만을 볼 수 있다.

If we instead plot the average portion of rejected documents per request as a function of shard and client count for the three clusters, we get the following graphs.

대신에 3개의 cluster에 대한 shard의 기능과 client 수에 따라, request 시 거부된 document의 평균 부분을 표시해 보면, 다음 그래프를 볼 수 있습니다.

Here we can see that the percentage of rejected events grows with increased concurrency levels for all cluster sizes. We can also see that the rejection levels drop across the board with the more data nodes we add, which is expected.

여기서 모든 cluster의 크기에 대해 향상된 concurrency 수준과 함께 거부되는 event의 비율이 증가함을 알 수 있다. 또한 data node를 더 많이 추가하면, 거부 수준이 전반적으로 저하될 것으로 예상된다.

Earlier we saw that partial rejections started at approximately the same time for both one and two node clusters. If we now look at these graphs, we can see that the portion of rejected documents grows faster for the single node cluster compared to the one with two data nodes. This means that even though we saw a similar level of partially rejected requests, the larger cluster had more documents indexed per request.

앞에서 단일 node cluster와 2 node cluster 모두에서, 부분 거부가 거의 동시에 시작되는 것을 보았다. 이제 이러한 그래프를 살펴보면, data node가 2개인 cluster에 비해 단일 node cluster에서 거부된 document 부분이 더 빨리 증가함을 알 수 있다. 즉, 유사한 수준의 부분적으로 거부된 request가 있었음에도 불구하고, 더 큰 cluster가 request당 더 많은 document를 indexing했다.

Can’t I just get around this by increasing the bulk queue size?

One of the most common reactions when faced with bulk rejections is to increase the size of the bulk queue. Why not set it to a really large value so you do not have to worry about this again?

bulk 거부에 직면했을 때 가장 일반적인 반응 중 하나는 bulk queue의 크기를 늘리는 것입니다. 이 값을 정말 큰 값으로 설정하면 더 이상 걱정할 필요가 없을까?

Increasing the size of the queue is not likely to improve the indexing performance or throughput of your cluster. Instead it would just make the cluster queue up more data in memory, which is likely to result in bulk requests taking longer to complete. The more bulk requests there are in the queue, the more precious heap space will be consumed. If the pressure on the heap gets too large, it can cause a lot of other performance problems and even cluster instability.

queue 크기를 늘린다고 해서 cluster의 indexing 성능이나 처리량이 향상되지는 않는다. 대신 cluster는 memory에서 더 많은 data가 queue에 추가되도록 하는 것뿐이라서, bulk request를 완료하는 더 많은 시간이 소요될 수 있다. queue에 bulk request가 많을수록 더 많은 귀중한 heap 공간이 사용된다. heap에 대한 압박이 너무 커지면 다른 많은 성능 문제가 발생하고 cluster가 불안정해질 수도 있다.

Adjusting the queue sizes is therefore strongly discouraged, as it is like putting a temporary band-aid on the problem rather than actually fixing the underlying issue. So what else can we do improve the situation?

따라서 queue 크기를 조정하는 것은, 실제로 근본적인 문제를 해결하는 것이 아니라, 문제를 일시적으로 해결하는 것과 마찬가지로, 매우 바람직하지 않습니다. 그렇다면 우리가 이 상황을 개선할 수 있는 다른 방법은 무엇일까?

Can coordinating only nodes help?

By introducing coordinating only nodes, the data nodes will be able to focus on processing sub-requests, as the request itself will not take up a slot on their bulk queue. This is generally good, but the actual benefit of this arrangement is likely to vary from use-case to use-case. In many use cases it does relatively little difference, and we see lots of successful indexing heavy use cases that do not use dedicated coordinating nodes.

node만 coordinating하는 방식을 도입하면, data node가 sub-request 처리에 집중할 수 있다. 즉, request 자체가 bulk queue의 slot을 차지하지 않기 때문이다. 이는 일반적으로 좋지만, 이 방식의 실질적인 이점은 사용 사례에 따라 달라질 수 있다. 많은 사용 사례에서 비교적 차이가 거의 없으며, 전용 coordinating node를 사용하지 않는 많은 성공적인 사용 사례를 볼 수 있다.

What conclusions can we draw?

As always, there is not necessarily any good one-size-fits-all solution, and the way to address bulk rejections will vary from use-case to use-case. If you see bulk rejections, try to understand why they are taking place and whether it is a single node or the whole cluster that is affected.

언제나 그렇듯이, 반드시 좋은 만능 솔루션이 있는 것은 아니며, bulk 거부를 처리하는 방법은 사용 사례에 따라 달라질 수 있다. bulk 거부가 보이면, 왜 이러한 거부가 발생하고 있으며 단일 node인지 또는 영향을 받는 전체 cluster인지를 이해하려고 해 보자.

If the cluster is unable to cope with the load, ensure that all nodes are sharing the load evenly. If this does not help, it may be necessary to scale the cluster out or up. This will increase capacity and make it less likely that queues are filled up. Increasing the bulk queue size is only likely to postpone the problems, and may actually make them worse.

cluster가 작업을 처리할 수 없는 경우, 모든 node가 작업을 균등하게 공유하고 있는지 확인하자. 이 방법이 도움이 되지 않는 경우, cluster의 scale-out 또는 scale-up이 필요할 수도 있다. 이렇게 하면 용량이 증가하고 queue이 채워질 가능성이 줄어든다. bulk queue 크기를 늘리는 것은 문제를 지연시킬 뿐이며 실제로 문제를 더 악화시킬 수도 있다.

Also remember that rejected requests do not always mean that all documents were unsuccessful. Make sure you inspect the full response and retry the appropriate documents. Logstash and Beats already do this by default.

또한 거부된 request가 항상 모든 document가 성공하지 못했음을 의미하는 것은 아니다. 전체 response를 확인하고 해당 document를 다시 시도하자. Logstash와 Beats는 이미 기본적으로 이렇게 하고 있다.

We hope this has given you a better understand of how it works. If you have any further questions, there are many ways to engage with us, including through our forum.

이 블로그 게시물이 bulk의 동작 방법을 이해하는데 있어 더 많은 도움이 되기를 바란다. 질문이 있다면, forum등의 다양한 방법으로 우리에게 연락하기 바란다.

원문 : Why am I seeing bulk rejections in my Elasticsearch cluster?

참조 : 1-04. Distributed Document Store

참조 : 1-03-13. Cheaper in Bulk

不爲也 比不能也

S1000D For Beginners

Chapter 1 Good Old Days of Word

XML

eDocuments

Headers

Footers

Change Management

Issue Numbering

Drafts

Applicability

Bike Example

Way Beyond Word

Common Source Data Base (CSDB)

Chapter 2 The Data Modules

The S1000D Standard Specification

The Data Modules

Data Module Contents and Meta Data

Data Module Code (DMC)

DISASSEMBLY CODE

DISASSEMBLY CODE VARIANT

FUNCTION CODE

FUNCTION CODE VARIANT

ITEM LOCATION

IMPORTANT TO KNOW ABOUT DMC

Chapter 3 Elements and Attributes, Oh My!

Structured Documentation

Containers

Elements

Attributes

Cardinality

Namespaces

Extensible Markup Language (XML)

Common Source Data Base (CSDB)

Document Object Model (DOM) Parser

Data Module Requirements List (DMRL)

Chapter 4 Schema

When a Plan Comes Together

Pictures are Worth a Thousand Words

The Element of Surprise

dmodule

dmCode

Schema

Chapter 5 What is an e-Book?

ePublishing

apps

Format

XML Parcer

Chapter 6 Technical Writing

Structured Documents

Drafts

Tracking Changes

ATA iSpec 2200 vs S1000D

ATA iSpec 2200

S1000D

Common Information Repository (CIR) Data Module

Warnings Format

Cautions Format

Chapter 7 The Descriptive Module

Under the Hood

identAndStatusSection

dmAddress and dmIdent

identExtension

Chapter 8 Illustrations

Chapter 9 Applicability

Chapter 10 Let’s Do This

Chapter 11 Common Information Repositories

FAQ

2019.08.30 - Elasticsearch의 시계열 데이터 쿼리 및 집계 작업

예제 1: CPU 사용률, 다운샘플링

예제 2: 네트워크 트래픽 — 기간 및 파생 집계

2019.07.17 - Elastic Stack을 사용하여 NGINX 웹 서버를 모니터링하는 방법

Elasticsearch 설치

1단계: Elasticsearch 다운로드

2단계: 아카이브 추출

3단계: bin 디렉토리로 변경

4단계: 단일 노드 클러스터 시작

NGINX 실행

Metricbeat 및 Filebeat 구성

Metricbeat

不爲也比不能也