Ryan Server

Solution : "An error occurred (TargetNotConnected) when calling the StartSession operation: {instance-id} is not connected."

RyanGomdoriPooh — Thu, 20 Jan 2022 11:53:44 +0900

I have a problem accessing Instance through Session Manager in AWS.

That message is "An error occurred (TargetNotConnected) when calling the StartSession operation: {instance-id} is not connected.".

In this post, We deal with how to solve this problem.

We entered a command similar to the command below at the local terminal of Mac.

aws ssm start-session --target i-123456 --document-name AWS-StartSSHSession --parameters 'portNumber=8373'

We got this error message.

An error occurred (TargetNotConnected) when calling the StartSession operation: i-123456 is not connected.

It has two solutions about the error mentioned above.

Eventually, Solutions has common reason. Link

First of all, We have to check settings for "Session Manager".

Let's check steps of solution.

1. Check instance settings of "Session Manager" to be connected.

Ref) Settings of Session Manager

2. Check instance settings of "Session Manager" to connect.

Ref) Settings of CLI

Ref) Region name

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json

And then, try again this command.

aws ssm start-session --target i-123456 --document-name AWS-StartSSHSession --parameters 'portNumber=8373'

From now, We can access instance using by Session Manager.

Java User Defined Package Naming Convention (Spring, Android, ...)

RyanGomdoriPooh — Sat, 30 Oct 2021 16:08:48 +0900

Overview

We usually make package name for Java program.

But, when we try to name package, we don't know how to name the package.

In this post, We look what package name is and how to make package name by examples.

let's look at some principles for package naming convention.

Index

What is package name?
How to make package name
Examples for package name

1. What is user-defined package name?

- Package name is a unique value of the applications.

- Our application has a unique package name. Because it is to distinguish other applications.

2. How to make user-defined package name

- Many applications use "company name" or "domain address" for package name because of it is unique.

- The "domain address" must use in reverse order.

- Recommend that it use lower case.

- Recommend that it don't use upper case.

- Divide source files into groups using dot('.').

- File packages are made by package name which is made.

3. Examples for user-defined package name

Format 1)

[Domain in reverse order].[Program name]

Example)

com.google.meet

Format 2)

[Domain in reverse order].[Platform].[Program name]

Example)

com.google.meet

com.google.android.meet

com.google.ios.meet

com.google.admin.meet

Conclusion

Developers feel difficult for package naming convention. Because They don't know how to make name for package.

But, It is easy to make User-defined package name. Keep in mind to make unique name for java source.

So, We usually are using for domain name or application service name.

Just make user-defined package name according to the principles written in this post.

Reference

https://www.baeldung.com/java-packages

https://java4beginnersblog.wordpress.com/2017/02/08/packeges-in-java/

Packages in Java

Package in java is a mechanism to encapsulate a group of classes, sub packages and interfaces. Packages are used for: Preventing naming conflicts. For example there can be two classes with name Emp…

java4beginnersblog.wordpress.com

쿠키와 세션 개념

RyanGomdoriPooh — Mon, 11 Oct 2021 23:44:37 +0900

노션 페이지(아래 내용과 동일)

개요

쿠키와 세션은 개발자 말고도 인터넷 사용자라면 누구나 많이 들어본 단어입니다.

하지만 개념에 대해서는 많은 사람들이 헷갈려 하기에 쉽고 간단하게 정리해보려고 합니다.

일단 쿠키를 발급받고 사용하는 과정에 대해서 그림으로 보여드리고,

쿠키와 세션에 대한 설명을 하도록 하겠습니다.

1. HTTP의 특징과 쿠키와 세션을 사용하는 이유

쿠키를 발급받고 사용하는 과정

HTTP 프로토콜의 특성이자 약점을 보완하기 위해서 쿠키 또는 세션을 사용합니다.

기본적으로 HTTP 프로토콜 환경은 "connectionless, stateless"한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야합니다. 이 특성을 보완하기 위해서 쿠키와 세션을 사용하게됩니다.

connectionless

클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징

HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성이 있다.

헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다.

HTTP가 tcp위에서 구현되었기 때문에 (tcp는 연결지향,udp는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 connectionless의 연결비용을 줄이는 것을 장점으로 비연결지향이라 한다.

stateless

통신이 끝나면 상태를 유지하지 않는 특징

연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용합니다.

예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때 마다 계속 로그인을 해야 합니다.

쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지하게 됩니다.

왜 쿠키와 세션이 필요한지 이야기했으니 이제는 쿠키와 세션을 발급받고 사용하는 과정을 알아보겠습니다.

2. 쿠키 ( Cookie )

쿠키란?

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일입니다.
사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있습니다.
쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다.
클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장합니다.
Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있습니다.
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송합니다.

쿠키의 구성 요소

이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
값 : 쿠키의 이름과 관련된 값
유효시간 : 쿠키의 유지시간
도메인 : 쿠키를 전송할 도메인
경로 : 쿠키를 전송할 요청 경로

쿠키의 동작 방식

클라이언트가 페이지를 요청
서버에서 쿠키를 생성
HTTP 헤더에 쿠키를 포함 시켜 응답
브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

쿠키의 사용 예

방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
쇼핑몰의 장바구니 기능
자동로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크, 쇼핑몰의 장바구니

3. 세션 ( Session )

세션이란?

세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리합니다.
서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.
물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능 합니다.
사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됩니다.
즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 됩니다.
클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID입니다.

세션의 동작 방식

클라이언트가 서버에 접속 시 세션 ID를 발급 받음
클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있음
클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청
서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져와서 사용
클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답

세션의 특징

각 클라이언트에게 고유 ID를 부여
세션 ID로 클라이언트를 구분해서 클라이언트의 요구에 맞는 서비스를 제공
보안 면에서 쿠키보다 우수
사용자가 많아질수록 서버 메모리를 많이 차지하게 됨

세션의 사용 예

로그인 같이 보안상 중요한 작업을 수행할 때 사용

4. 쿠키와 세션의 차이

쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문입니다.
가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠릅니다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
보안, 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.
라이프 사이클, 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있습니다.
반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
속도, 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

5. 세션을 사용하면 좋은데 왜 쿠키를 사용할까?

세션은 서버의 자원을 사용하기 때문에 무분별하게 만들다보면 서버의 메모리가 감당할 수 없어질 수가 있고 속도가 느려질 수 있기 때문에 쿠키가 유리한 경우가 있습니다.

6. 쿠키/세션은 캐시와 엄연히 다르다!

캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것입니다.
한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있습니다.
보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해서는 잘 말하는데 사실 중요한 것은 라이프사이클을 얘기하는 것입니다.

이상으로 쿠키와 세션에 대해 알아보았습니다.

세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에,

최근에는 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세입니다.

그 중 JWT( JSON Web Token )라는 것이 있습니다.

JWT는 다음에 다루도록 하겠습니다.

Blocking or Non-Blocking, Synchronous and Asynchronous

RyanGomdoriPooh — Sun, 10 Oct 2021 15:38:03 +0900

Overview

When we develop application, we always think concepts called "Blocking, Non-blocking, Synchronous, Asynchronous".

We usually think that "Blocking, non-blocking, Synchronous, Asynchronous" are the same.

But, This perspective is wrong. It is unrelated concepts each other. It is difficult and confusing concepts.

It is confused between "Blocking" and "Synchronous". Likewise, It is confused between "Non-blocking" and "Asynchronous".

"Synchronous and Asynchronous" must have at least two subjects performing the task.
At this time, if the (start, end) time of work is aligned with each other, it is called "Synchronous", and if the time of work is not related to each other, it is called "Asynchronous".

On the other hand, "Blocking and Non-blocking" requires at least two targets for work.
Because the two concepts have different perspectives, various combinations of "synchronous/blocking", "synchronous/non-blocking", "asynchronous/blocking", and "asynchronous/non-blocking" are possible.

Then, let's look at details of the contents now.

Index

Concept of Blocking and Non-blocking
Concept of Sync and Async
Difference between "Blocking and Non-blocking" and "Sync and Async"
Cases: (Blocking or Non-blocking) X (Sync or Async)

1. Blocking and Non-blocking

In blocking and non-blocking, it is important how to deal with the subject who performs other tasks.

If you do your own work, it waits from the beginning to the end of the work done by another person, and start your work again, this is blocking.

If you continue your work regardless of the work of other subjects, this is non-blocking.

Thread A is calling another target to do something, receiving the results from it, and resuming the operation.

For example, Java can use JDBC to ask DB questions and get results called blocking operations.

On the contrary, if you ask another subject to work and do your own work without waiting for the results to be received, this can be called non-blocking.

Blocking and Non-blocking are mainly used in reading and writing IO.

Blocking

- It ends when you get the return value.

- It continues to wait until the requested operation is completed.
- Until the requested task is completed, the thread waits and continues to use/stand by one thread until the return value is received.

Non-blocking

- Although the requested work cannot be completed immediately, return it immediately.
- Do not return immediately. It prevents you from working.
- One thread can handle multiple IOs by non-blocking.

2. Synchronous and Asynchronous

When two or more subjects is executing for task, task of each subject finishes at the same time or starts at the same time.

Or, If you start and end at the same time, or if another subject starts working at the same time as one task.

It can be seen as a synchronous task.

Asynchronous work refers to when the two subjects have a separate start/end time regardless of each other's start or end time.

It can be called asynchronous when the work done by different subjects has nothing to do with their work start or end time.

Synchronous

- Thread1 started working and waited until Task1 was over. And then It starts Task2.
- When a work is requested, the result value of the request is directly returned.
- The result value of the request is the same as the return value.
- The called function cares about the completion of the task.

Asynchronous

- Thread1 can start work, not wait for completion, and Thread1 can handle other tasks.
- When a work is requested, the result value of the request is indirectly received.
- The result value of the request may be different from the return value.
- The request operation is executed on another thread.
- Processing through callback is called "asynchronous processing".
- The called function cares about completing the task.

3. Difference between "Blocking and Non-blocking" and "Sync and Async"

"When an I/O function is called, it is whether or not to return immediately."
Blocking: Don't return right away
Non-Blocking: Return right away

Blocking

- Until the work of an object that cannot be directly controlled is completed, blocking doesn't hand over control.

- When a calling function requests IO, it means waiting without doing anything until IO processing is completed.

Non-blocking

- Non-Blocking is the opposite concept of blocking.

- It has nothing to do with the work of an object that cannot be directly controlled.

- Regardless of whether IO processing is completed, a function requests I/O and then it can do its other work immediately.

"The concern is who cares about the completion of the task of the called I/O function."

Sync: In charge of application
Async: In charge of kernel

Synchronous

- After requesting a task, synchronous task waits for the result of it to come out and process it.
- the process continuously checks the kernel for I/O preparations.

Asynchronous

- If it does not care whether the task is completed, the called function is asynchronous.

- When the end of the previous system call occurs, subsequent processing is performed.

3. Cases: (Blocking or Non-blocking) X (Sync or Async)

In this step, Explain the combination of (blocking, non-blocking) and (sync, async).

1. Synchronous blocking I/O

2. Synchronous non-blocking I/O

3. Asynchronous blocking I/O

4. Asynchronous Non-Blocking I/O (AIO)

Synchronous blocking I/O

It is the most basic I/O model, which refers to I/O system calls such as read and write files in general.

If there is no special setting, it operates as blocking.

After the user process calls read(), the kernel does not return until the data is copied to the user buffer

and the user process waits while stopping its work. (Waste of resources such as CPU)

Therefore, if a server to which multiple clients is connected is implemented in a blocking manner, if one client proceeds with an I/O operation, the process (or thread) will be stopped, so each client must create and connect a process (or thread).

However, as the number of users increases, the process (or thread) increases.

examples)

- query to DB by JDBC

- In method, call another method to get result immediately

Synchronous non-blocking I/O

The kernel reads the data, stores it in a buffer, and copies the content to the user.

Since the buffer is loaded into the memory held by the kernel, inter-memory copying occurs and can be received at a higher speed than I/O.

However, if the buffer is empty, the kernel immediately returns an error (EWOULDBLOCK), causing the user process to continuously call read() to check the I/O readiness.

Since system calls occur repeatedly (polling method), resources such as cpu are wasted.

examples)

- Polling

Asynchronous blocking I/O

It is used for the purpose of multiplexing I/O using system calls such as select or poll.

Select and poll may perform an inspection to see if data is prepared in multiple descriptors and return to process multiple I/O if a prepared descriptor is found.

However, the selection is limited to the number of management file descriptors and poll is not limited, but the size of the check mask per file descriptor is large, and thus performance degrades when the number of connectors increases.

"Asynchronous blocking" combinations eventually have to wait for other tasks to be completed, so they have similar work efficiency to "Synchronous blocking", that is, they don't have very good efficiency.

"Synchronous blocking" is not the situation the developers intended. They performed "Asynchronous, non-blocking" work, but this result comes out when they performed the blocking work without even realizing it.

examples)

- Asynchronous, non-blocking operations are called, and when you try to check the result value of the called operation while working on your own (blocking method is executed)

Asynchronous Non-Blocking I/O (AIO)

An I/O model that responds to a result at a time when I/O processing is completed is referred to as asynchronous I/O.

The asynchronous I/O reply is made in the form of a signal or callback, and the application may proceed with other tasks until a reply is made.

The process is the same as non-blocking I/O in that it is not in a block state, but non-blocking I/O notifies when the I/O process is completed, while non-blocking I/O judges the I/O as an error.

examples)

- Case consists of divided logic by a signal or callback

Conclusion

Let's talk about it briefly.

Between application and kernel, it is how to act called logic.

You read the details and the graphs for the above cases, you will understand.
The important thing here is to look at the application and kernel areas separately.

Reference

https://en.wikipedia.org/wiki/Asynchronous_I/O

Asynchronous I/O - Wikipedia

In computer science, asynchronous I/O (also non-sequential I/O) is a form of input/output processing that permits other processing to continue before the transmission has finished. Input and output (I/O) operations on a computer can be extremely slow compa

en.wikipedia.org

https://www.tornadoweb.org/en/stable/guide/async.html

Asynchronous and non-Blocking I/O — Tornado 6.1 documentation

Real-time web features require a long-lived mostly-idle connection per user. In a traditional synchronous web server, this implies devoting one thread to each user, which can be very expensive. To minimize the cost of concurrent connections, Tornado uses a

www.tornadoweb.org

https://stackoverflow.com/questions/2625493/asynchronous-and-non-blocking-calls-also-between-blocking-and-synchronous

asynchronous and non-blocking calls? also between blocking and synchronous

What is the difference between asynchronous and non-blocking calls? Also between blocking and synchronous calls (with examples please)?

stackoverflow.com

What is Java GC(Garbage Collection)?

RyanGomdoriPooh — Tue, 5 Oct 2021 02:02:00 +0900

Java uses memory without explicitly releasing it. Instead, JVM manages memory.

JVM deletes unused objects in the Heap area by GC.

Heap area is dynamically allocated memory area.

Heap manages object-type data objects, typically classes such as String and Collection.

The important part of this is to determine which object to keep and which object to GC in Heap.

GC is designed with the following concept.

The hypothesis for design of GC(Garbage Collection)

* Most objects quickly become unreachable state. ⇒ Process by "minor GC"
* There are very few references from old objects to young objects. ⇒ Process by "major GC"

So, Which objects will GC collect?

If an object have a valid reference from GC Roots, it is called Reachable, otherwise Unreachable.

* Unreachable objects : Among the objects, an object that is not being referenced.

* Unreachable objects are subject to GC collection.
* GC Roots : Data in the stack area, static data in the method area, and objects generated by JNI.

How does gc work?

The basic principle of gc motion is as follows.

"MARK and Sweep"

1. "Mark" : From GC Root, GC scans all variables to find and mark which objects each is referring to. (The process of identifying a Reachable object and an Unreachable object)
2. "Sweep" : Unreachable objects are removed from Heap.

--
3. (It can be added according to the algorithm) "Compact": Sweep, collect the distributed objects to the starting address of Heap. And divide them into "parts where memory is allocated" and "parts that are not". (It prevents memory fragmentation)

When will GC happen and how will it be handled?

First of all, We have to know concept for Heap.

The architecture of Heap is as follows.

The architecture of Heap

* Young Generation(Eden, Survivor 0, Survivor 1): Newly created objects are located here. Because most objects become quickly inaccessible state, so many objects are created and disappeared only in the Young area. Minor GC occurs when an object disappears in this area.
* Old Generation : The objects surviving for a long time in the Young area is copied here. Most of them are allocated larger than the Young Generation, and GC occurs less than the Young area as the size of them is large. Major GC occurs when an object disappears in this area.

Process of GC

Eden => Survivor(1,2) => Old

What is Minor GC?

* Occurs when the Eden area is full

* At the same time, Minor GC also occurs in the Sirvivor area.

Sequence of Minor GC

In JVM, GC target area

1-1. In Eden area, newly objects is created.

1-2. Objects are continuously created, and when the Eden area is full, it executes "Minor GC".

1-3. When "Minor GC" occurs in "Eden", "Mark" executes about objects which existed in "Eden".

1-4. When "Mark" executes, Distinguish unreachable or reachable objects in "Eden".

1-5. Reachable objects move to "Survivor 1 Area" and the age number of them goes up by 1. (*Aging)

1-5. After "Mark" execution, Execute "Sweep" to remove unreachable objects in "Eden Area".

Important concept

*Objects must exist separately in the Survivor1 or Survivor2 area (When "Minor GC" is executed, one of the Survivor areas must be empty)

2-1. The empty Enden area creates new objects again.

2-2. Step 1 is repeatly processed. Likewise, If "Eden" area is full, Execute "Minor GC in Eden", Reachable objects move to "Survivor Area" that was not used in the previous step. Unreachable objects remove in "Eden". Also, Execute "Minor GC in Survivor which is executed in the previous step". Reachable objects move to "Survivor Area" that was not used in the previous step. Unreachable objects remove in Survivor which is executed in the previous step.

2-3. Likewise, Reachable objects that survived in "Minor GC" go up by 1. (*Aging)

3-1. When objects in "Servivor Area" reach its age threshold, its move to "Old Generation". (*Promoted)

3-2. If "Old Generation" is full, "Major GC(Full GC)" is executed.

The process of GC generation.

What is Major GC?

: If "Old Generation" is full, "Stop-the-world" is executed and then "Major GC(Full GC)" is executed.

Stop-the-world

* JVM stops running the application to execute the GC.
* All threads except threads running GC stop working.
* After completing the GC work, Resume the discontinued works.
* In most cases, Tuning GC is to reduce this stop-the-world time.

Type of Major GC (based on JDK 7)

* Serial GC
* Parallel GC
* Parallel Old GC(Parallel Compacting GC)
* Concurrent Mark & Sweep GC (CMS 또는 Mark & Sweep)
* G1(Garbage First) GC

Serial GC

JVM option: -XX:+UseSerialGC

* Serial GC should never be used in the operating server.
* Because It is made for a single core method, The process power is wasted.

* Serial GC is suitable for fewer memories and fewer cores.
* The "Young area" uses bump-the-pointer and TALBs methods.

* The "Old area" uses the Mark & Sweep Compact algorithm.

Parallel GC

JVM option: -XX:+UseParallelGC, -XX:ParallelGCThreads (Minor GC Thread Count)

* Serial GC has the same basic algorithm with Parallel GC.

* Parallel GC uses multi-thread for GC.
* Parallel GC is suitable for multiple cores and large size memory.

* When throughput is more important than latency reduction(obtained using CMS GC), Use Parallel GC.

Parallel Old GC

JVM option: -XX:+UseParallelOldGC, -XX:ParallelGCThreads (Minor, Full GC Thread Count)

* In Parallel GC, the GC algorithm in the Old region passes through Mark-Summary-Compaction.

* Unlike Sweep, the Summary step goes through object identification for the area where GC was performed.

Concurrent Mark & Sweep GC(CMS GC)

JVM option: -XX:+UseConcMarkSweepGC

* This is a more improved method than the GCs discussed earlier.

* Although its performance has improved, GC's process has become more complex.

* CMS GC is focused on minimizing STW(stop-the-world) time occurring during the GC process.
* The concept of CMS GC is to identify the GC target in as much detail as possible and then take a short time to execute STW.

* CPU usage is higher than that of other GCs. Because the process of identifying GC targets is performed in various complicated steps.

CMS GC : Initial Mark -> Concurrent Mark -> Remark -> Concurrent Sweep

Step "Initial Mark"

- It find reachable objects among the closest objects to the class loader. Therefore, the stopping time is very short.

Step "Concurrent Mark"

- Check by following the objects referenced by the reachable objects which were checked in "Initial Mark".

- This step proceeds simultaneously while other threads are running.

Step "Remark"
- An object newly added or disconnected from reference is identified in the Current Mark step.

Step "Concurrent Sweep"

- Cleaning up the garbage is performed.

- This work is also executed in a situation where other threads are being executed.

* The stop-the-world time is very short because it is a GC method that proceeds to this step.

* CMS GC is used when the response speed of all applications is very important, and it is also called Low Latency GC.

However, while CMS GC has the advantage of short stop-the-world time, the following disadvantages exist.

* It uses more memory and CPU than other GC methods.

* Compaction steps are not provided by default.
* Therefore, when using CMS GC, it should be used after careful review.

* If you need a compaction operation because of many fragmented memories, you have to check how often and for how long the compaction operation is performed because STW time is longer than other GC STW time.

G1 GC (G1: Garbage First)

JVM option: -XX:+UseG1GC

G1 manages heap memory in a different way than the gc discussed earlier.

Unlike parallel/CMS collectors, there is no continuous memory space with distinct boundaries from generation to generation

Also, It has nothing to do with hemispherical heap layouts.

G1 consists of a Region divided into logical units.

The region allows generation to be placed discontinuously.

And there is no need to collect the entire garbage every time the collector runs.

The characteristics of G1 GC.
* It is a gc developed for use in multi-processor systems with large memory.
* It's much easier to tune than CMS.
* They are less vulnerable for early promotion. (Early promotion is a problem in which the quota is too high to be promoted to the Old area too quickly.)
* It has excellent scalability (especially break time) in large heap.
* From Java 9, it is default gc.

The heap of G1 consists of a region.

The dictionary allows generations to be deployed discontinuously, and there is no need to collect the entire garbage every time the collector runs.

The G1 collector tracks which objects are stored in which region through the Reserved Set (RSet).

Thanks to this, G1 only needs to take out the Rset without having to go through the entire hip to find a reference looking inside the area.

The collection steps of G1 are as follows.

"Initial Mark-STW"

- STW occurs.

- Find the Survivor area referenced by objects existing in Old area.

"Root Region Scanning"

- Identify references pointing to the Old Area in the Survivor Area identified in "Initial Mark-STW" Step.
"Concurrent Mark"

- Find reachable objects throughout the heap.
"Remark-STW"

- STW occurs.

- Verify "Concurrent Mark" step and identify the objects that will finally survive. In this step, a snapshot-at-the-beginning (SATB) algorithm is used.
"Cleanup-STW"

- Stop the application (STW) and remove unused objects for the fewest reachable objects.

- After the STW is finished, and the completely empty region in the GC process is added to the Freelist to be reused.
"Copy"

- Copy the surviving objects of the relocation to GC but not completely empty during the Cleanup process to perform the Compaction operation by copying them to the new relocation.

Since G1GC officially appeared in JDK 7, it has been widely used, so let's take a closer look at the setting options.

-XX: G1HeapRegionSize

Default: X
Region Size. Can be set from 1MB to 32MB. Minimum heap size must be set to be divided into 2048 Region.

-XX:MaxGCPauseMillis
Default: 200
Maximum time of STW caused by G1GC. G1 only tries to match the set value as much as possible, but it is not a guaranteed value.

-XX:DefaultMinNewGenPercent
Default: 5
Minimum size of the heap to be used as the Young area (ratio to the total size of the heap,

-XX:DefaultMaxNewGenPercent
Default: 60
Maximum size of heap to be used as Young area (ratio to total heap size, %)

-XX:ParallelGCThreads
Default: X
Number of threads performing GC in an STW situation. If the number of CPU cores is less than or equal to 8, it is recommended to set the same as the number of cores.

-XX:ConcGCThreads
Default: X
Number of threads performing Concurrent Mark. It is recommended to set it to 25% of Parallel GCThreads.

-XX:InitiatingHeapOccupancyPercent
Default: 45
Option to perform Mark when using a specific percentage (%) of the hip relative to the total size.

-XX:G1OldCSetRegionLiveThresholdPercent
Default: 65
The ratio of the Old Region size at which the mixed GC begins.

Memory Management

Java does not directly access the memory area of the OS, but indirectly uses a virtual machine called JVM.

Take over all the tricky parts of memory management to Java virtual machine.

* Java's memory leakage?

- A phenomenon in which objects that are no longer used for memory leakage are not recovered by the garbage collection GC and are continuously accumulated. So, Major GC frequently occurs due to objects accumulated in the Old area, and the program's response speed is delayed, and eventually the program ends with an Out of Memory (OOM) error.

In this way, Java has the advantage of using virtual machines (in addition to the advantage of being independent of the operating system) that memory leak at the OS level becomes impossible. But memoty leak can occur.

The reason is that if you hold a reference of an object that is not actually used in the program, the object will occupy memory (address space) as garbage objects that is not processed by GC and cannot be accessed and used within the program.

Since Java's used memory is only likely to be used, there may be garbage objects, not objects that are being used logically and accurately, and these objects cause memory leaks.

Memory Leak Examples)
- It usually occurs when objects stored in collections such as declarations of frequent global variables, lists, or hashmaps are maintained without releasing them.
- When creating meaningless objects using rapper classes such as Integer and Long,
- If the cache data is not declared and released in Map,
- If you use a stream object and don't close it,
- If you define the key of Map as a user object and do not override Equals() and hascode() and mistake it for the same key, and the data continues to accumulate.
- If the key value of Map is not uncomfortable data and changes continuously when comparing data, although the key value is redefined by defining the key of Map as a user object.
- If the data structure is created and used, and the memory is not released due to an implementation error,

Conclusion

I haven't experienced a large-scale project yet, so the topic of GC tuning doesn't touch much, but I think I need a deep understanding of GC to become a great Java developer.

I think I need to know how GC works, how to tune, and what kind of memory leakage occurs so that I can write code with improved performance during a large scale of project.

Reference

https://www.oreilly.com/library/view/optimizing-java/9781492039259/

Optimizing Java

Performance tuning is an experimental science, but that doesn’t mean engineers should resort to guesswork and folklore to get the job done. Yet that’s often the case. With this practical … - Selection from Optimizing Java [Book]

www.oreilly.com

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

Concurrent Mark Sweep (CMS) Collector

Concurrent Mode Failure The CMS collector uses one or more garbage collector threads that run simultaneously with the application threads with the goal of completing the collection of the tenured generation before it becomes full. As described previously,

docs.oracle.com

https://youtu.be/Fe3TVCEJhzo?t=200

What is Java OOP(Object Oriented Programming)?

RyanGomdoriPooh — Sat, 2 Oct 2021 01:32:44 +0900

We have a lot of thoughts about OOP(Object Oriented Programming).

But many people can't answer easily. Some people answer SOLID principle.

From the beginning class, we are going to learn about the basics of OOPs in JAVA.

In order to implement OOP in JAVA, We have to satisfy a few things.

The concepts for OOP is as follows.

Class
Object
Abstraction
Inheritance
Encapsulation
Polymorphism
Attribute
Method
...

The aim of concepts is implementing real entities in programs.

So, We create class methods and variables to reuse them with capsulation.

OOP(Object-oriented programming) is composed of classes and objects.

I think SOLID or GRASP are important factors. Eventually We have to think "Cohesion" and "Coupling".

"Cohesion" and "Coupling" strengthen reusability and responsibility for programming code.

It's easy to maintain codes which is implemented by "Cohesion" and "Coupling".

Of course, there is no correct answer to what is OOP.

Although we know that object orientation is literally aimed at objects, We are still looking at OOP centering on class or inheritance.

A simple way to design OOP is as follows.

The most important thing in OOP is to focus on the object and look at it.
In OOP, objects should be viewed as components of the cooperative community to implement functions.
It is to give appropriate responsibilities and roles to objects participating in cooperation.

In conclusion, I think OOP is a way to make good codes that are easy to maintain.

Jackson ObjectMapper 정리

RyanGomdoriPooh — Mon, 14 Jun 2021 00:40:48 +0900

개요

Java 개발자라면 Jackson에서 제공하는 ObjectMapper와 자주 마주치게 됩니다.

Java 클래스 내용을 확인하거나 내용물의 Parsing 과정에 필요한 커스터마이징이 존재하기 때문입니다.

물론 중요한 기능은 (1) "Java Object" =Serialize=> "JSON", (2) "JSON" =Deserialize=> "Java Object" 입니다.

개발 중에 매 번 찾아보기 지쳐서 이제는 한 곳에 정리가 필요하지 않을까 생각되어서 이 글을 쓰게 되었습니다.

Add Dependency for "Jackson ObjectMapper"
Basic Features
1. Convert "Java Object" to "JSON"
2. Convert "JSON" to "Java Object"
3. Convert "JSON" to "Jackson JsonNode"
4. Convert "JSON Array String" to "Java List"
5. Convert "JSON String" to "Java Map"
Advanced Features
1. Configuring Serialization or Deserialization Feature
2. Creating Custom Serializer or Deserializer
3. Handling Date Formats
4. Handling Collections

1. Add Dependency for "Jackson ObjectMapper"

라이브러리의 사용에 앞서서 일단 프로젝트에 종속성을 추가하고 시작하겠습니다.

Maven의 경우)

아래 종속성을 pom.xml의 <dependencies>...</dependencies>에 추가해줍니다.

<!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.12.3</version>
</dependency>

Gradle의 경우)

아래 종속성을 build.gradle의 dependencies { ... }에 추가해줍니다.

// https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind
implementation 'com.fasterxml.jackson.core:jackson-databind:2.12.3'

다음 링크를 통해서 원하는 버전을 사용할 수 있습니다.

Jackson Databind 버전 확인 링크

2. Basic Features

아래 User라는 Java Object가 존재한다고 가정하고, 2. Basic Features의 예시 코드를 보이겠습니다.

public class User {

    private String name;
    private int age;
    
    public User(String name, int age) {
    	this.name = name;
        this.age = age;
    }
    
    public String getName() {
    	return name;
	}
    
    public int getAge() {
    	return age;
	}
}

2.1. Convert "Java Object" to "JSON"

ObjectMapper objectMapper = new ObjectMapper();
User user = new User("Ryan", 30);

objectMapper.writeValue(new File("user.json"), user);
// 파일 출력: user.json
{"name":"Ryan","age":30}
// 문자열 출력
String userAsString = objectMapper.writeValueAsString(user);
{"name":"Ryan","age":30}

2.2. Convert "JSON" to "Java Object"

// String to Object
String json = "{ \"name\" : \"Ryan\", \"age\" : 30 }";
User user = objectMapper.readValue(json, User.class);
// JSON File to Object
User user = objectMapper.readValue(new File("user.json"), User.class);
// JSON URL to Object
User user = objectMapper.readValue(new URL("file:user.json"), User.class);

2.3. Convert "JSON" to "Jackson JsonNode"

String json = "{ \"name\" : \"Ryan\", \"age\" : 30 }";
JsonNode jsonNode = objectMapper.readTree(json);
String name = jsonNode.get("name").asText();// Ryan
int age = jsonNode.get("age").asInt();// 30

2.4. Convert "JSON Array String" to "Java List"

String jsonArr = "[{\"name\":\"Ryan\",\"age\":30},{\"name\":\"Jake\",\"age\":20}]";
List<User> users = objectMapper.readValue(jsonArr, new TypeReference<>() {});

2.5. Convert "JSON String" to "Java Map"

String jsonArr = "{\"name\":\"Ryan\",\"age\":30}";
Map<String, Object> user = objectMapper.readValue(jsonArr, new TypeReference<>() {
});

3. Advanced Features

위에서 설명한 Jackson Library의 Basic Features에 추가적으로 유용한 기능를 사용할 수 있습니다.

JSON과 Object에 대해서 커스터마이징한 Serialize/Deserialize가 가능한 기능을 사용할 수 있습니다.

3.1. Configuring Serialization or Deserialization Feature

3.1.1. JSON에는 있지만 Mapping될 Object에는 없는 필드를 무시해야하는 경우

String json = "{\"name\":\"Ryan\",\"age\":30,\"sex\":\"M\"}";
// User Object에서는 "sex" field가 없습니다. 아래 설정을 안하게되면 익셉션이 발생합니다.
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
User user = objectMapper.readValue(json, User.class);

3.1.2. JSON에 있는 propety가 Mapping될 Object에 primitive인데 null 값이 전달을 무시해야하는 경우

String json = "{\"name\":\"Ryan\",\"age\":null}";
// 기본적으로 FAIL_ON_NULL_FOR_PRIMITIVES 옵션은 false 상태입니다. 의도적으로 옵션을 설정해주었습니다.
// 옵션이 true가 되게되면, age가 int인 primitive 자료형이 null인 JSON이 전달되는 경우 익셉션을 발생합니다.
objectMapper.configure(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES, false);
User user = objectMapper.readValue(json, User.class);

3.2. Creating Custom Serializer or Deserializer

JSON이 Object로 Deserialize될 때, 서로 다른 정보로 전달되고 있는데 Object나 JSON이 전달하는 모델을 변경하지 못하는 경우,

"Custom Deserializer"를 사용합니다.

Object이 JSON으로 Serialize될 때, 서로 다른 정보로 전달되고 있는데 Object나 JSON이 전달하는 모델을 변경하지 못하는 경우,

"Custom Serializer"를 사용합니다.

아래 Serializer와 Deserializer에 예시에 사용될 User Class입니다.

class User {
    private final int age;
	
    User(int age) {
    	this.age = age;
    }
}

3.2.1. Custom Serializer Example

"JSON" =Custom Deserialize=> "Object"

public class CustomUserSerializer extends StdSerializer<Car> {
    public CustomUserSerializer() {
        this(null);
    }

    public CustomUserSerializer(Class<Car> t) {
        super(t);
    }

    @Override
    public void serialize(Car car, JsonGenerator jsonGenerator, SerializerProvider serializer) {
        jsonGenerator.writeStartObject();
        jsonGenerator.writeStringField("user_age", user.getAge());
        jsonGenerator.writeEndObject();
    }
}

ObjectMapper mapper = new ObjectMapper();
SimpleModule module = new SimpleModule("CustomUserSerializer", new Version(1, 0, 0, null, null, null));
module.addSerializer(User.class, new CustomUserSerializer());
mapper.registerModule(module);
User user = new User(20);
String userJson = mapper.writeValueAsString(user);
System.out.println(userJson);// {"user_age":20}

3.2.2. Custom Deserializer Example

"Object" =Custom Serialize=> "JSON"

public class CustomUserDeserializer extends StdDeserializer<User> {
    public CustomUserDeserializer() {
        this(null);
    }

    public CustomUserDeserializer(Class<?> vc) {
        super(vc);
    }

    @Override
    public User deserialize(JsonParser parser, DeserializationContext deserializer) {
        User user = new User();
        ObjectCodec codec = parser.getCodec();
        JsonNode node = codec.readTree(parser);
        
        // try catch block
        JsonNode ageNode = node.get("user_age");
        String age = ageNode.asText();
        user.setAge(age);
        return user;
    }
}

String json = "{ \"user_age\" : 30}";
ObjectMapper mapper = new ObjectMapper();
SimpleModule module = new SimpleModule("CustomUserDeserializer", new Version(1, 0, 0, null, null, null));
module.addDeserializer(User.class, new CustomUserDeserializer());
mapper.registerModule(module);
User user = mapper.readValue(json, User.class);

3.3. Handling Date Formats

Serialize를 하는 과정에서 Date로 구성된 Object field의 Format을 변경할 수 있습니다.

class User {
    private int age;
    private Date createdAt;

    // getters, setters
}

User user = new User();
user.setAge(30);
user.setCreatedAt(Date.from(Instant.now()));

ObjectMapper objectMapper = new ObjectMapper();
DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm a z");
objectMapper.setDateFormat(df);
String userAsString = objectMapper.writeValueAsString(user);
System.out.println(userAsString);// {"age":30,"createdAt":"2021-06-10 11:43 AM CEST"}

3.4. Handling Collections

JSON에 존재하는 복수개의 모델을 Collections 자료형으로 Deserialize할 수 있습니다.

Deserialize JSON to Array

String jsonUserArray = "[{\"age\":30,\"createdAt\":\"2021-06-10T11:43:12\"},{\"age\":30,\"createdAt\":\"2021-06-10T11:43:12\"}]";
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.configure(DeserializationFeature.USE_JAVA_ARRAY_FOR_JSON_ARRAY, true);
User[] users = objectMapper.readValue(jsonCarArray, User[].class);
// print users

또는 Deserialize JSON to List

String jsonUserArray = "[{\"age\":30,\"createdAt\":\"2021-06-10T11:43:12\"},{\"age\":30,\"createdAt\":\"2021-06-10T11:43:12\"}]";
ObjectMapper objectMapper = new ObjectMapper();
List<User> listUser = objectMapper.readValue(jsonCarArray, new TypeReference<List<User>>(){});
// print users

결론

잘 정리되어있던 참고자료에 있는 포스트를 통해서 하나씩 코드를 돌려보면서 정리하였습니다.
Java를 쓰다보면 Jackson 라이브러리를 직접적인 코드를 사용하거나 Annotation을 사용하는 경우가 많습니다.
그중에서 ObjectMapper를 직접 사용하는 것에 대한 정리를 이 포스트에 업데이트해나가겠습니다.

참고자료

https://www.baeldung.com/jackson-object-mapper-tutorial

Intro to the Jackson ObjectMapper | Baeldung

The article discusses Jackson's central ObjectMapper class, basic serialization and deserialization as well as configuring the two processes.

www.baeldung.com

자바 인터페이스(Java Interface)는 무엇인가?

RyanGomdoriPooh — Thu, 25 Jun 2020 19:44:04 +0900

개요

"자바 인터페이스(Java Interface)는 무엇인가?"

이런 궁금점을 가지고 있는 Java Programmer가 많습니다.

저는 "객체 지향 개발 5대 원칙 - SOLID"을 만족시켜줄 수 있어서라고 생각합니다.

그러면 "왜 SOLID를 만족시켜야 하는가?"라는 질문을 가지게 됩니다.

서비스 애플리케이션의 라이프사이클을 "설계 / 개발 / 유지보수" 세 단계로 나누면,

유지보수가 소프트웨어 라이프사이클에서 가장 큰 부분을 차지합니다.

유지보수에서 인터페이스(interface)는 SOLID를 구현하고, 객체 지향 개발을 하는데 큰 도움을 줍니다.

"설계 / 개발 / 유지보수" 관점에서 객체 지향을 설명하면, 다음과 같은 장점이 있습니다.

객체 지향 사용하여, 대상을 추상화를 하고, 추상화된 대상의 행동을 묘사하면서, 설계를 쉽게 할 수 있게 합니다.
설계가 끝나고, 개발하게 되는데, 개발자는 설계된 추상화 객체 단위로 쉽게 대상을 이해할 수 있습니다.
개발이 완료되고 유지보수를 하면, 기존 코드와 로직을 그대로 두고, 새로운 기능을 유연하게 추가할 수 있습니다.

그럼 다시 "자바 인터페이스(Java interface)는 무엇인가?"로 돌아와서,

자바 인터페이스(Java interface)가 "객체 지향"에 어떤 도움을 주는지 알아보도록 하겠습니다.

1. 인터페이스(interface) 역할

인터페이스는 어떤 역할을 할까요?

인터페이스는 객체를 어떻게 구성해야 하는지 정리한 설계도입니다.
인터페이스는 객체의 교환성(또는 다형성)을 높여줍니다.
인터페이스 변수에 인터페이스가 구현된 서로 다른 구현 객체를 할당해서 사용이 가능합니다.
구현 객체를 직접 몰라도 인터페이스 메서드만 알아도 객체 호출이 가능하게 합니다.
객체가 인터페이스를 사용하면, 인터페이스 메서드를 반드시 구현해야 하는 제약을 합니다.

위 특징을 이용해서 얻고자 하는 인터페이스(interface) 역할은 다음과 같습니다.

인터페이스의 역할

"interface를 이용하여, 개발 코드를 직접 수정하지 않고도, 사용하고 있는 객체만 변경할 수 있도록 하기 위함입니다."

2. 인터페이스(interface) 선언

인터페이스(Interface) 선언 형식은 다음과 같이합니다.

인터페이스(Interface)

[public] interface 인터페이스이름 { ... }
// 예시
public interface User { ... }

"인터페이스이름"은 Upper CamelCase로 작성되어야 합니다.
interface도 Class, Enum, Annotation처럼 "~.java" 파일로 작성되고, 컴파일러(javac.exe)를 통해서 바이트코드 형태의 "~.class" 파일로 컴파일됩니다.
interface는 접근 지정자로 public을 사용하면, 다른 패키지에서도 사용이 가능합니다. public을 사용하지 않으면, interface가 위치한 해당 패키지 내에서만 사용이 가능합니다.
interface의 접근 지정자는 public만 가능합니다. 이유는 interface는 class 설계도 이기 때문에 애초에 존재 목적이 공개이기 때문입니다.
interface는 객체로 생성할 수 없기 때문에, 생성자를 가질 수 없습니다.
class는 상수 필드, 정적 필드, 인스턴스 필드, 생성자, 인스턴스 메서드, 정적 메서드를 구성 멤버로 가지는데, interface는 상수 필드, 추상 메서드, 디폴트 메서드, 정적 메서드를 구성 멤버로 가집니다.
Java 7까지는 실행 블록이 없는 추상 메서드로만 선언이 가능했습니다. Java 8부터는 디폴트 메서드와 정적 메서드도 선언이 가능합니다.

인터페이스(Interface) 구성요소는 다음과 같습니다.

2-1. 상수 필드(Constant Field)

2-2. 추상 메서드(Abstract Method)

2-3. 디폴트 메서드(Default Method)

2-4. 정적 메서드(Static Method)

2-1. 상수 필드(Constant Field)

public interface User {
    // 상수 필드(Constant Field)
    [public static final] 필드타입 상수명 = 값;
    // 예시
    String FIRST_NAME = "Ryan"; // 또는
    public static final String FIRST_NAME = "Ryan"; // 는 같다.
}

인터페이스는 객체가 될 수 없기 때문에, 런타임에 필드 데이터를 저장할 수 없습니다. 그래서 인스턴스 필드/ 정적 필드는 선언이 불가능합니다.
상수 필드는 Compile Time에 선언되고 Run Time에 변경되지 않으므로 인터페이스에 선언이 가능합니다.
[public static final]는 명시적으로 사용하지 않아도, Compile Time에 자동으로 선언되어 상수로 만듭니다.
네이밍은 모두 대문자로 구성되고 구분자는 "_"(언더바)로 표현됩니다. (Java Convention)

2-2. 추상 메서드(Abstract Method)

public interface User {
    // 추상 메서드(Abstract Method)
    [public abstract] 리턴타입 메서드이름(매개변수, ...);
    // 예시
    String sendMoney(Money money); // 와
    public abstract String sendMoney(Money money); // 는 같다.
}

인터페이스 변수로 호출된 메서드는 최종적으로 구현 객체에서 실행됩니다. 그래서 실체는 인터페이스에 없고, 구현 클래스에 있습니다.
추상 메서드는 리턴 타입 / 메서드 이름 / 매개변수 가 기술되는 클래스 설계 메서드입니다.
[public abstract]은 명시적으로 선언하지 않아도, Compile Time에 자동으로 선언됩니다.

2-3. 디폴트 메서드(Default Method)

public interface User {
    // 디폴트 메서드(Default Method)
    [public] default 리턴타입 메서드이름(매개변수, ...) { ... }
    // 예시
    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("사용자가 활성화 되었습니다");
            return;
        }
        System.out.println("사용자가 비활성화 되었습니다");
    }
}

Java 8에서 추가된 인터페이스의 멤버입니다.
클래스의 인스턴스 메서드와 동일합니다. 즉, 인스턴스 메서드입니다. 다만 인터페이스에서 선언할 때, 리턴 타입 앞에 default 키워드가 붙습니다.
[public]은 명시적으로 사용하지 않아도, Compile Time에 자동 선언됩니다.
디폴트 메서드는 나중에 인터페이스를 구현한 구현 클래스에 인스턴스 메서드로 추가됩니다.
재정의(Override)를 통해서 구현 클래스에서 재정의된 인스턴스 메서드로 사용할 수 있습니다.

2-4. 정적 메서드(Static Method)

public interface User {
    // 정적 메서드(Static Method)
    [public] static 리턴타입 메서드이름(매개변수, ...) { ... }
    // 예시
    public static void printFirstName() {
        System.out.println("나의 이름은 " + firstName + "입니다.");
    }
}

Java 8에서 추가된 인터페이스의 멤버입니다.
선언 형식은 클래스 정적 메서드와 완전 동일합니다.
[public]은 명시적으로 사용하지 않아도, Compile Time에 자동으로 선언됩니다.
인터페이스의 정적 메서드도 클래스의 정적 메서드와 똑같은 방식으로 사용이 가능합니다.

3. 인터페이스(interface) 구현

개발 코드에서 인터페이스의 메서드를 호출하면, 인터페이스는 구현 객체의 메서드를 찾아서 호출합니다.

객체는 인터페이스에 있는 추상 메서드를 구현한 실체 메서드를 가지고 있어야 합니다.

인터페이스를 구현한 객체를 구현 객체(구현체)라고 합니다.

구현 객체를 생성하는 클래스를 구현 클래스라고 합니다.

인터페이스 구현 방식은 세 가지 방식이 있습니다.

3-1. 단일 인터페이스 구현 클래스(Single Interface Implement Class)

3-2. 다중 인터페이스 구현 클래스(Multiple Interface Implement Class)

3-3. 익명 구현 객체(Anonymous Implement Object)

세 가지 방식에 대해서 설명하겠습니다.

3-1. 단일 인터페이스 구현 클래스(Implement Class)

public class 구현클래스이름 implements 인터페이스이름 {
    // 인터페이스의 추상 메서드를 구현한 실체 메서드를 선언하는 부분
}

인터페이스 예시를 먼저 제시하겠습니다.

public interface User {

    public static final String FIRST_NAME = "Ryan";

    public abstract String sendMoney(Money money);

    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("사용자가 활성화 되었습니다");
            return;
        }
        System.out.println("사용자가 비활성화 되었습니다");
    }

    public static void printFirstName() {
        System.out.println("나의 이름은 " + firstName + "입니다.");
    }
}

인터페이스 예시를 구현한 구현 클래스 예시입니다.

public class Recipient implements User {

    // 추상 메서드는 다음처럼 실체 메서드를 정의해야합니다.
    public String sendMoney(Money money) {
        thirdpartyApi.send(money.getType(), money.getAmount());
        return Status.SUCCESS.name();
    }

    // 디폴트 메서드는 재정의가 가능합니다.
    // 재정의 하지 않으면, 인터페이스에 정의된 내용 그대로 사용됩니다.
    @Override
    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("수취인이 활성화 되었습니다");
            return;
        }
        System.out.println("수취인이 비활성화 되었습니다");
    }
}

만약 인터페이스를 구현한다고 하고, 추상 메서드를 구현 클래스에서 실체 메서드를 모두 작성하지 않으면 해당 구현 클래스는 추상 클래스로 선언되어야 합니다.

public abstract class Recipient implements User {

}

인터페이스 변수에 구현 객체 대입 예시

// User 인터페이스를 구현한 구현 클래스 Recipient
public class Recipient implements User { ... }
// User 인터페이스를 구현한 구현 클래스 Sender
public class Sender implements User { ... }

User user = new Recipient();
user = new Sender();

3-2. 다중 인터페이스 구현 클래스(Multiple Interface Implement Class)

public class 구현클래스이름 implements 인터페이스이름1, 인터페이스이름2 {
    // 인터페이스의 추상 메서드를 구현한 실체 메서드를 선언하는 부분
}

인터페이스를 구현한 구현 클래스는 다중 인터페이스를 구현 가능합니다.
다중 인터페이스를 구현한 구현 클래스는 반드시 모든 인터페이스의 추상 메서드를 실체 메서드로 구현해야 합니다.
하나라도 추상 메서드가 구현되지 않으면, 구현 클래스는 추상 클래스로 선언되어야 합니다.

3-3. 익명 구현 객체(Anonymous Implement Object)

구현 클래스를 만들어서 사용하는 것이 일반적이고, 재사용이 가능하기에 편리합니다. 하지만 일회성으로 사용하는 구현 클래스는 클래스로 만들어서 선언해서 쓰는 것이 비효율적입니다.
비효율을 개선하기 위해서 만들어진 것이 익명 구현 객체입니다. 익명 구현 객체는 임시 작업 스레드를 만들기 위해 많이 활용됩니다.
특징 중에 하나는 new 키워드 뒤에 원래는 인터페이스 구현 클래스 이름이 와야 하는데, 익명 구현 객체의 경우에는 참조할 구현 클래스가 없기 때문에 User 인터페이스 이름을 그대로 사용합니다.
다만, 익명 구현 객체의 구현 부에는 인터페이스의 추상 메서드가 아닌 실체 메서드를 선언해야 합니다.

익명 구현 객체 예시

// 인터페이스에 선언된 추상 메서드의 실체 메서드 선언
User user = new User() {
    public String sendMoney(Money money) {
        thirdpartyApi.send(money.getType(), money.getAmount());
        return Status.SUCCESS.name();
    }

    @Override
    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("수취인이 활성화 되었습니다");
            return;
        }
        System.out.println("수취인이 비활성화 되었습니다");
    }
};

그렇다고 익명 구현 객체를 사용한다고 해서, 클래스가 생성되지 않는 것은 아닙니다.

익명 구현 객체가 사용된 자바 파일을 컴파일을 하게 되면 자동으로 익명 구현 객체의 클래스 파일이 생성됩니다.

생성된 익명 구현 클래스 파일은 이름은 다음과 같습니다.

[익명 구현 객체가 사용된 자바 파일]$[번호].class ([번호]는 1부터 시작되어, 증가합니다.)

ex) TestExample$1.class

4. 인터페이스(interface) 사용

인터페이스 변수는 참조 타입이기 때문에 구현 객체가 대입될 경우 구현 객체의 번지가 저장됩니다.

User sender = new Sender(); // User 인터페이스 참조변수 sender에 Sender 객체의 번지 저장
User recipient = new Recipient(); // User 인터페이스 참조변수 recipient에 Recipient 객체의 번지 저장

인터페이스 변수는 다음 5개의 부분에서 구현 객체의 참조 용도로 사용될 수 있습니다.

클래스의 필드
생성자의 파라미터
생성자의 로컬 변수
메서드의 파라미터
메서드의 로컬 변수

public class TestClass {
    // 1.클래스의 필드
    User user = new Recipient();
    
    // 2.생성자의 파라미터
    TestClass(User user) {
    	this.user = user;
    	// 3.생성자의 로컬변수
    	User recipient = new Recipient();        
    }

    // 4.메서드의 파라미터
    void methodA(User user) {
    	...
    }

    void methodB() {
        // 5.메서드의 로컬변수
    	User user = new Recipient();
    }
}

이 부분부터는 인터페이스의 구성요소를 어떻게 사용하는지 살펴보겠습니다.

4-1. 상수 필드(Constant Field) 사용

4-2. 추상 메서드(Abstract Method) 사용

4-3. 디폴트 메서드(Default Method) 사용

4-4. 정적 메서드(Static Method) 사용

설명을 위해서 User 인터페이스를 예시 용도로 가져왔습니다.

public interface User {

    public static final String FIRST_NAME = "Ryan";

    public abstract String sendMoney(Money money);

    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("사용자가 활성화 되었습니다.");
            return;
        }
        System.out.println("사용자가 비활성화 되었습니다.");
    }

    public static void printFirstName() {
        System.out.println("나의 이름은 " + firstName + "입니다.");
    }
}

4-1. 상수 필드(Constant Field) 사용

User.FIRST_NAME

위 방식으로 상수는 클래스의 상수와 같은 방식으로 사용할 수 있습니다.

4-2. 추상 메서드(Abstract Method) 사용

public class Example {
    public static void main(String[] args) {
        User user = null;
        
        user = new Recipient();
        user.sendMoney(new Money(1l));// Recipient가 1원을 보냈다.
        
        user = new Sender();
        user.sendMoney(new Money(2l));// Sender가 2원을 보냈다.
    }
}

user 인터페이스의 추상 메서드 sendMoney를 호출하면, 인터페이스 변수에 대입되었던 구현 객체의 주소를 판단해서 해당하는 실체 메서드를 호출합니다.

4-3. 디폴트 메서드(Default Method) 사용

public class Example {
    public static void main(String[] args) {
        User user = null;
        
        user = new Recipient();
        user.setStatus(Status.ACTIVE); // 사용자가 활성화 되었습니다.
        
        user = new Sender();
        user.setStatus(Status.INACTIVE); // 사용자가 비활성화 되었습니다.
    }
}

구현 클래스에 실체 메서드를 작성하지 않아도 구현 객체에서 호출이 가능합니다.

물론, 구현 클래스에서 디폴트 메서드가 변경이 필요한 경우, 재정의(Override)가 가능합니다.

추상 메서드가 아니고 인스턴스 메서드이기 때문에 생성한 구현 객체가 있어야 사용할 수 있습니다.

디폴트 메서드를 재정의한 예시를 보겠습니다.

public class Recipient implements User {

    @Override
    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("수취인이 활성화 되었습니다.");
            return;
        }
        System.out.println("수취인이 비활성화 되었습니다.");
    }
}

public class Sender implements User {

    @Override
    public default void setStatus(Status status) {
        if(status == Status.ACTIVE) {
            System.out.println("송신자가 활성화 되었습니다.");
            return;
        }
        System.out.println("송신자가 비활성화 되었습니다.");
    }
}

public class Example {
    public static void main(String[] args) {
        User user = null;
        
        user = new Recipient();
        user.setStatus(Status.ACTIVE); // 수취인이 활성화 되었습니다.
        
        user = new Sender();
        user.setStatus(Status.INACTIVE); // 송신자가 비활성화 되었습니다.
    }
}

구현 클래스에서 재정의된 디폴트 메서드가 사용되어 호출됩니다.

4-4. 정적 메서드(Static Method) 사용

public class Example {
    public static void main(String[] args) {
        User.printFirstName(); // 나의 이름은 Ryan입니다.
    }
}

인터페이스의 정적 메서드도 클래스의 정적 메서드와 같은 방식으로 사용합니다.

정적 메서드이기 때문에 재정의(Override)는 불가능합니다.

5. 인터페이스(interface) 타입 변환과 다형성

인터페이스는 다형성을 이용해서 타입 변환을 합니다. 타입 변환에 대한 이야기 하기에 앞서서 다형성에 대해서 알아보겠습니다.

다형성(Polymorphism) 이란?

: 하나의 타입 변수에 대입되는 객체에 따라서 실행 결과가 다양한 타입의 형태로 나오는 성질을 이야기합니다. 즉, 하나의 타입 변수를 동일한 메서드로 동작시키지만 실제 동작은 다를 수 있는 성질입니다.

인터페이스를 사용해서 다형성을 사용하면, 사용할 구현 객체만 바꿔주면 나머지 소스코드는 변경할 필요가 없습니다.

Interface i = new ImplementObjectA();
// i를 수정해도
i = new ImplementObjectB();

// 변경이 없습니다.
i.method1();
i.method2();

상속에서도 부모 클래스 타입의 변수에 어떤 자식 객체를 대입하냐에 따라서 객체의 메서드 실행 결과는 달라질 수 있습니다.

결국, 상속에서도 인터페이스와 마찬가지로 다형성을 구현하고 있습니다.

ParentClass p = new ChildClassA();
// 자식 객체로 대입이 가능하다. (다형성)
p = new ChildClassB();

// 다만, ParentClass안에 구현된 메서드만 호출이 가능
p.methodAInParent();
p.methodBInParent();

인터페이스가 매개변수로 쓰이는 경우

public class UserService {
  // User 인터페이스를 매개변수로 사용.
  public void printUserType(User user) {
      user.printType();
  }
}

// User 인터페이스를 구현한 구현 객체 Recipient, Sender를 매개변수로 사용
userService.printUserType(new Recipient()); // 수취인입니다.
userService.printUserType(new Sender()); // 송신자입니다.

간단하게 인터페이스와 상속 관계에서 타입 변환과 다형성에 대해서 살펴보았습니다.

여기서 조금 더 자세하게 "타입 변환"과 "다형성"에 대해서 알아보겠습니다.

5-1. 자동 타입 변환(Promotion)

5-2. 매개 변수의 다형성

5-3. 강제 타입 변환(Casting)

5-4. 객체 타입 확인(instanceof)

위에 나열한 목록 순서로 설명하겠습니다.

5-1. 자동 타입 변환(Promotion)

Runtime에 구현 객체가 인터페이스 타입의 참조 변수로 자동 변환하는 것을 "자동 타입 변환(Promotion)"이라고 합니다.

자동 타입 변환은 인터페이스를 구현한 구현 클래스의 자식 클래스를 만들고, 자식 객체를 인터페이스의 변수에 담아도 다형성이 적용됩니다.

그러면 왜 인터페이스를 구현한 클래스의 자식 클래스도 다형성이 적용되고 자동 타입 변환이 가능할까요?

부모 클래스인 구현 클래스는 자식 클래스에게 상속을 하고 나면,

인터페이스와 마찬가지로 부모 클래스에 대한 멤버를 자식 클래스에게 전달하게 됩니다.

결국 부모 클래스는 이미 먼저 인터페이스를 통해서 추상 메서드를 실체 메서드로 구현하였기 때문에,

결국 구현된 실체 메서드가 자식 클래스에게 전달되는 것이 확실해집니다.

그렇기 때문에 인터페이스를 구현한 클래스의 자식 클래스도 다형성이 적용되고 자동 타입 변환이 가능합니다.

예시)

// 인터페이스 A
// 인터페이스 A를 구현한 클래스 B
// 인터페이스 A를 구현한 클래스 C
// 클래스 B를 상속한 자식 클래스 D
// 클래스 C를 상속한 자식 클래스 E

// B, C, D, E에는 printClassName를 자기 클래스 이름을 출력하는 로직이 재정의 되어있다고 가정합니다.

A a1 = new B(); // OK
a1.printClassName(); // B 클래스입니다.

A a2 = new C(); // OK
a2.printClassName(); // C 클래스입니다.

A a3 = new D(); // OK
a3.printClassName();
// 기본은 상속된 printClassName가 호출됩니다. "B 클래스입니다."
// 만약 클래스 D의 printClassName를 재정의하면 "D 클래스입니다."가 됩니다.

A a4 = new E(); // OK
a4.printClassName();
// 기본은 상속된 printClassName가 호출됩니다. "C 클래스입니다."
// 만약 클래스 E의 printClassName를 재정의하면 "E 클래스입니다."가 됩니다.

5-2. 매개 변수의 다형성

매개 변수를 인터페이스 변수로 두고, 구현 객체를 대입해주면 다형성을 적용해서 사용할 수 있습니다.

예시)

// 인터페이스
public interface User {
    void printType();
}

// 구현 클래스 "Recipient"
public class Recipient implements User {
    @Override
    public void printType() {
        System.out.println("수취인입니다.");
    }
}

// 구현 클래스 "Sender"
public class Sender implements User {
    @Override
    public void printType() {
        System.out.println("송신자입니다.");
    }
}

public class Mail {
    public void printUserType(User user) {
        user.printType();
    }
}

public class Main {
    public static void main(String[] args) {
        Mail mail = new Mail();
        mail.printUserType(new Recipient()); // User user = new Recipient(); "수취인입니다."
        mail.printUserType(new Sender()); // User user = new Sender(); "송신자입니다."
    }
}

5-3. 강제 타입 변환(Casting)

인터페이스의 변수를 구현 객체와 사용하면, 인터페이스에서 정의된 추상 메서드의 실체 메서드 이외에는 호출할 수 없습니다.

즉,

구현 클래스에 추가로 메서드를 구현하고,

나중에 구현 객체를 사용할 때, 인터페이스 변수가 사용된다면,

추가로 구현된 메서드는 호출이 되지 않습니다.

그래서 다음 솔루션을 사용합니다.

5-3-1. 직접 구현 클래스 변수에 구현 객체를 대입하는 방법

Recipient recipient = new Recipient();

5-3-2. 인터페이스 변수를 구현 객체로 강제 타입 변환을 사용하면 됩니다.

User user = new Recipient();
Recipient recipient = (Recipient) user;

예시)

// 인터페이스
public interface User {
    void printType();
}

// 구현 클래스 "Recipient"
public class Recipient implements User {
    private static final String COUNTRY = "KOREA";

    @Override
    public void printType() {
        System.out.println("수취인입니다.");
    }
    
    // 추가로 메서드 구현
    public void printCountry() {
        System.out.println("국가는 " + COUNTRY + "입니다.");
    }
}

public class Main {
    public static void main(String[] args) {
        User user = new Recipient();
        user.printType(); // "수취인입니다."
        user.printCountry(); // 호출이 불가능합니다.
        // 
        Recipient recipient = (Recipient) user;
        recipient.printType(); // "수취인입니다."
        recipient.printCountry(); // "국가는 KOREA입니다."
    }
}

5-4. 객체 타입 확인(instanceof)

위 강제 타입 변환(Casting)은 구현 객체가 인터페이스 타입으로 변환되어 있는 상태에서 가능합니다.

User user = new Recipient();

그런데 어떤 구현 객체가 대입되는지 모르는 상태에서 강제 타입 변환을 하게 되면 ClassCastException이 발생할 수 있습니다.

User user = new Recipient();
Sender sender = (Sender) user; // ClassCastException 발생

ClassCastException를 발생시키지 않기 위해서 "instanceof" 를 사용합니다.

User user = new Recipient();
if( user instanceof Recipient ) { // user 변수에 담긴 객체가 Recipient 타입이면,
    Recipient recipient = (Recipient) user;
}

"instanceof"를 사용하면, 강제 타입 변환에 앞서서 ClassCastException을 방지할 수 있습니다.

6. 인터페이스(interface) 상속

인터페이스도 다른 인터페이스를 상속할 수 있습니다.

클래스는 다중 상속을 허용하지 않지만, 인터페이스는 다중 상속을 허용합니다.

다음 방식으로 선언되어 인터페이스 상속이 가능합니다.

public interface 하위인터페이스 extends 상위인터페이스1, 상위인터페이스2, ... { ... }

하위 인터페이스를 구현하는 구현 클래스에서는 "하위 인터페이스의 추상 메서드"와 "상속하는 모든 상위 인터페이스의 추상 메서드"의 실체 메서드로 구현해야 합니다.

하위인터페이스 변수 = new 구현클래스();
상위인터페이스1 변수 = new 구현클래스();
상위인터페이스2 변수 = new 구현클래스();

"하위 인터페이스 변수"는 하위인터페이스, 상위 인터페이스1, 상위 인터페이스2의 실체 메서드를 모두 사용할 수 있습니다.

"상위 인터페이스1 변수"는 상위인터페이스1의 실체 메서드를 사용할 수 있습니다.

"상위 인터페이스2 변수"는 상위인터페이스2의 실체 메서드를 사용할 수 있습니다.

예시)

public interface InterfaceA {
    public void methodA();
}

public interface InterfaceB {
    public void methodB();
}

public interface InterfaceC extends InterfaceA, InterfaceB {
    public void methodC();
}

// InterfaceC를 구현했기 때문에 methodA(), methodB(), methodC() 실체 메서드를 모두 가져야합니다.
public class ImplementationClassC implements InterfaceC {
    public void methodA() {
        System.out.println("ImplementationClassC-methodA()");
    }
    
    public void methodB() {
        System.out.println("ImplementationClassC-methodB()");
    }
    
    public void methodC() {
        System.out.println("ImplementationClassC-methodC()");
    }
}

public class Main {
    public static void main(String[] args) {
        ImplementationC implC = new ImplementationC();
        
        InterfaceA iA = implC;
        iC.methodA(); // OK
        iC.methodB(); // NO
        iC.methodC(); // NO
        
        InterfaceB iB = implC;
        iC.methodA(); // NO
        iC.methodB(); // OK
        iC.methodC(); // NO
        
        InterfaceC iC = implC;
        iC.methodA(); // OK
        iC.methodB(); // OK
        iC.methodC(); // OK
    }
}

7. 인터페이스(interface) 디폴트 메서드와 확장

7-1. 디폴트 메서드는 왜 만들어졌을까?

디폴트 메서드는 인스턴스 메서드입니다. 즉, 구현 객체가 있어야 사용할 수 있습니다.

인스턴스 메서드인데 왜 인터페이스에 있을까요?

Java8에서 인터페이스에서 디폴트 메서드를 허용하는 이유는 기존 인터페이스를 확장해서 새로운 기능을 추가하기 위해서입니다.

만약 기존 인터페이스에 새로운 기능을 위해서 추상 메서드를 추가하면 어떤 상황이 발생할까요?

추상 메서드를 새롭게 선언하면, 해당 인터페이스를 구현하는 구현 클래스를 찾아다니면서,

새로 선언된 추상 메서드에 대한 실체 메서드를 선언해주어야 합니다. 아니면 Compile Error가 발생합니다.

하지만 인터페이스에 디폴트 메서드를 선언하게 되면,

이미 선언된 인스턴스 메서드이기에 실체 메서드를 선언하지 않아도 문제없이 필요한 곳에서 디폴트 메서드를 사용할 수 있습니다.

디폴트 메서드는 추상 메서드가 구현 클래스에서 실체 메서드로 구현되어야 한다는 제약을 없애준 편의 메서드로 볼 수 있습니다.

public interface SampleInterface {
    // 무조건 구현 클래스에서 실체 메서드로 정의해야하는 추상 메서드
    public void abstractMethod();

    // 구현 객체에서 사용할 수 있는 인스턴스인 디폴트 메서드
    // 구현 클래스에서 재정의도 가능합니다.
    public default void defaultMethod() {
        System.out.println("(1) SampleInterface-defaultMethod()");
    }
}

public class ImplementationClassA implements SampleInterface {
    @Override
    public void abstractMethod() {
        System.out.println("(2) ImplementationClassA-abstractMethod()");
    }
}

public class ImplementationClassB implements SampleInterface {
    @Override
    public void abstractMethod() {
        System.out.println("(3) ImplementationClassB-abstractMethod()");
    }
    
    // 디폴트 메서드 재정의 가능
    @Override
    public void defaultMethod() {
        System.out.println("(4) ImplementationClassB-defaultMethod()");
    }
}

public class Main {
    public static void main(String[] args) {
        SampleInterface sI1 = new ImplementationClassA();
        sI1.abstractMethod(); // (2)
        sI1.defaultMethod(); // (1)
        
        SampleInterface sI2 = new ImplementationClassB();
        sI2.abstractMethod(); // (3)
        sI2.defaultMethod(); // (4)
    }
}

7-2. 디폴트 메서드가 있는 인터페이스 상속

디폴트 메서드를 가진 부모 인터페이스를 상속한 자식 인터페이스에서 디폴트 메서드를 활용하는 방법에 대해서 알아보겠습니다.

자식 인터페이스에서는 디폴트 메서드를 다음 방식으로 사용할 수 있습니다.

7-2-1. 부모 인터페이스의 디폴트 메서드를 상속받아서 그대로 사용

7-2-2. 부모 인터페이스의 디폴트 메서드를 자식 인터페이스에서 재정의하여 사용

7-2-3. 부모 인터페이스의 디폴트 메서드를 추상 메서드로 재선언하여, 구현 클래스에서 실체 메서드로 구현하여 사용

위 세 가지 방식에 대해서 예시를 보이겠습니다.

7-2-1. 부모 인터페이스의 디폴트 메서드를 상속받아서 그대로 사용

public interface ParentInterface {
    public default void defaultMethod() {
        System.out.println("(1) ParentInterface-defaultMethod()");
    }
}

public interface ChildInterface extends ParentInterface {
}

public class ImplementationClass implements ChildInterface {
}

public class Main {
    public static void main(String[] args) {
        ChildInterface iC = new ImplementationClass();
        iC.defaultMethod(); // (1) ParentInterface-defaultMethod()
    }
}

7-2-2. 부모 인터페이스의 디폴트 메서드를 자식 인터페이스에서 재정의하여 사용

자식 인터페이스에서 디폴트 메서드를 재정의한 경우

public interface ParentInterface {
    public default void defaultMethod() {
        System.out.println("(1) ParentInterface-defaultMethod()");
    }
}

public interface ChildInterface extends ParentInterface {
    @Override
    public default void defaultMethod() {
        System.out.println("(2) ChildInterface-defaultMethod()");
    }
}

public class ImplementationClass implements ChildInterface {
}

public class Main {
    public static void main(String[] args) {
        ChildInterface iC = new ImplementationClass();
        iC.defaultMethod(); // (2) ChildInterface-defaultMethod()
    }
}

구현 클래스에서 디폴트 메서드를 재정의한 경우

public interface ParentInterface {
    public default void defaultMethod() {
        System.out.println("(1) ParentInterface-defaultMethod()");
    }
}

public interface ChildInterface extends ParentInterface {
    @Override
    public default void defaultMethod() {
        System.out.println("(2) ChildInterface-defaultMethod()");
    }
}

public class ImplementationClass implements ChildInterface {
    @Override
    public void defaultMethod() {
        System.out.println("(3) ImplementationClass-defaultMethod()");
    }
}

public class Main {
    public static void main(String[] args) {
        ChildInterface iC = new ImplementationClass();
        iC.defaultMethod(); // (3) ImplementationClass-defaultMethod()
    }
}

7-2-3. 부모 인터페이스의 디폴트 메서드를 추상 메서드로 재선언하여, 구현 클래스에서 실체 메서드로 구현하여 사용

public interface ParentInterface {
    public default void defaultMethod() {
        System.out.println("(1) ParentInterface-defaultMethod()");
    }
}

public interface ChildInterface extends ParentInterface {
    // 추상 메서드로 재선언
    void defaultMethod();
}

public class ImplementationClass implements ChildInterface {
    // 추상 메서드의 실체 메서드 구현
    @Override
    public void defaultMethod() {
        System.out.println("(2) ImplementationClass-defaultMethod()");
    }
}

public class Main {
    public static void main(String[] args) {
        ChildInterface iC = new ImplementationClass();
        iC.defaultMethod(); // (2) ImplementationClass-defaultMethod()
    }
}

결론

지금까지 인터페이스는 무엇이고, 어떻게 사용하는지에 대해서 알아봤습니다.

하지만 여전히 인터페이스는 왜 사용해야 하는지에 대해서 의문일 수 있습니다.

저는 "객체 지향 프로그래밍을 돕는 디자인 패턴이니까 사용해서 구현하자."라고 말할 수 있습니다.

인터페이스를 구현하고, 상속하고, 확장하면서 얻을 수 있는 프로그래밍의 장점을 다형성과 사용하면서,

유지보수에 있어서 기존의 코드를 변경 없이 해당 구현 객체를 변경하기만 해도 호출되는 소스의 내용을 바꿔줄 수 있습니다.

저는 보통 클래스의 상속보다 추상 클래스와 인터페이스를 이용해서 공통된 메서드를 구현하고, 다형성을 이용합니다.

이유는 클래스 간 강한 결합도를 낮추기 위함입니다.

응집도를 높이고, 결합도를 낮추는 게 객체지향이 추구하는 기본 원칙이기 때문입니다.

인터페이스를 잘 사용하는 방법은 많이 사용해보고, 장단점을 파악해서 필요한 곳에 사용할 수 있도록 하는 것이라고 생각합니다.

글을 마치겠습니다.

참고자료

"객체 지향 개발 5대 원칙 - SOLID"

AWS RDS Proxy를 활용한 Aurora Failover 구현하기

RyanGomdoriPooh — Thu, 18 Jun 2020 21:14:36 +0900

개요

AWS RDS Proxy은 "DB Connection Pool Management" 또는 "Automatic Failover를 위한 Proxy" 기능을 제공합니다.

결국, AWS RDS Proxy를 사용하는 이유는 HA(High Availability)를 구현하기 위함입니다.

Solution을 사용하기 앞서서, HA(High Availability)를 위한 Multi-AZ(Multi Availability Zone) 개념을 시작으로 이야기를 풀어가보겠습니다.

RDS는 HA(High Availability)를 위해서 Multi-AZ(Multi Availability Zone)를 권장합니다. Downtime 없는 DB Instance를 사용하기 위함입니다.

Multi-AZ를 통한 DB 구성과 Application에서 활용하는 방식은 다음과 같습니다.

Multi-AZ 구성과 Application에서 활용

여기서 AZ(Availability Zone)의 개념은 물리적으로 구분된 IDC라고 생각하시면 됩니다.

예를 들면, Zone A는 Seoul, Zone B는 Daegu, Zone C는 Busan과 같이 보통 지역으로 분리해놓습니다.

Multi-AZ를 구성하고, 어느 하나의 AZ 또는 DB Instance에 장애가 발생하였을 때 장점은 다음과 같습니다.

Enhanced durability: 장애가 발생한 Workload를 안전하게 보장해서 DB에 반영해줍니다.
Increased availability: Aurora는 1분 이내, MariaDB는 30초 이내, 다른 DB Engine은 1~2분 이내로 Automatic failover를 통해서 정상화시킵니다. 그리고 maintenance 또는 backup이 발생했을 때도 DB에 반영할 Workload를 보장해줍니다.
Protection of your database performance: MySQL, MariaDB, Oracle, PostgreSQL Engine에서 Backup이 발생하였을 때, I/O workload를 지속적으로 보장해줍니다. Aurora를 사용하고 있는 경우에도 마찬가지로 I/O workload를 보장하고, 장애가 발생하여도 Automatic Failover과 Read Replica를 통해서 Performance를 유지시켜줍니다.
Automatic failover: Primary DB가 있는 AZ에서 Downtime이 발생했을 때, Failover를 통해서 짧은 시간 안에 Secondary DB를 승격시켜서 DB를 정상화시킵니다. 마찬가지로 Secondary DB에서 Downtime이 발생했을 때, 다른 정상적인 AZ로 Workload를 넘겨줍니다.

또한, AWS Multi-AZ 구성은 다음 아래와 같은 내용을 보장합니다.

Amazon RDS Service Level Agreement Multi-AZ configurations for MySQL, MariaDB, Oracle, and PostgreSQL are covered by the Amazon RDS Service Level Agreement ("SLA"). The RDS SLA affirms that AWS will use commercially reasonable efforts to make Multi-AZ instances of Amazon RDS available with a Monthly Uptime Percentage of at least 99.95% during any monthly billing cycle. In the event Amazon RDS does not meet the Monthly Uptime Percentage commitment, affected customers will be eligible to receive a service credit.

요약한 내용은 다음과 같습니다.

한 달의 Billing Cycle 동안 99.95% 이상의 서비스 시간 보장 (30일*24시간*60분 * 0.0005 = 21.6분 이하의 Downtime 보장)
99.95%이상 SLA 보장을 못 받은 사용자에게는 그만큼의 Service Credit 제공

하지만 Multi-AZ가 장점이 많음에도 비용이 증가하는 단점이 있기 때문에, 웬만한 소규모 상용 서비스들은 보통 1개 DB Instance로 Multi-AZ를 구현하지 않고 사용합니다.

"서비스의 초반에는 굳이 Multi-AZ까지 필요할까?"라는 말엔 공감합니다. 그러나 서비스가 성장하고, 24시간 쉼 없이 사용자들에게 서비스를 제공하게 되면서, DB의 HA(High Availability)가 중요해집니다.

결국, Multi-AZ가 필요한 시점이 옵니다.

그러면 Multi-AZ를 어떻게 사용할까요? 내부 Architecture는 비슷하지만, Engine에 따라서 구성하는 방식은 조금 다릅니다.

MySQL, MariaDB, Oracle, PostgreSQL Engine: DB를 생성할 때, Multi-AZ를 선택할 수 있습니다. 생성 후에 적용도 가능합니다.
Aurora: Read Replica를 생성하면 자동으로 Multi-AZ가 구성이 됩니다.

MySQL, MariaDB, Oracle, PostgreSQL Engine은 장애가 발생하였을 때, 동일한 endpoint를 통해서 요청해도 Automatic Failover를 통해서 DB를 전환시켜주기 때문에 그대로 endpoint를 사용하시면 HA(High Availability)를 구성할 수 있습니다.

AWS Aurora의 구성 Architecture

이 글에선 더 다양한 기능과 확장성을 제공하는 Aurora를 기준으로 Proxy를 활용해서 Automatic Failover를 구현하고, HA(High Availability)를 가능하게 만들어보겠습니다.

AWS Aurora Automatic Failover 테스트를 진행하기 위한 구성은 다음과 같습니다.

RDS Aurora Instance Cluster 1(Primary Instance 1, Replica Instance 1)
RDS Proxy 1(Secrets Manager "Secret", IAM "Policy", IAM "Role")
EC2 Instance 1

// RDS Aurora Instance Cluster 1(Primary Instance 1, Replica Instance 1)는 이미 생성되어있다고 가정합니다. 이 글에서 사용하는 DB Instance Name은 test입니다.

예시로 사용하는 Aurora cluster

1. RDS Proxy에 사용할 Secrets Manager "secret" 생성하기

: RDS Proxy를 이용하기 위해서는 Proxy가 어디로 어떤 정보를 이용해서 DB에 접속해야 하는 지를 정보를 저장해야 합니다. Proxy는 그 정보의 단위를 Secrets Manager "secret"를 생성해서 관리하고 사용합니다.

Secret type: "Credentials for RDS database"
User name: 접속할 DB의 username
Password: 접속할 DB의 password
Encryption key: DefaultEncryptionKey
RDS database this secret will access: "secret"을 사용하여 Proxy를 사용할 DB

Next~

Secret name: "secret" 구분하기 위한 이름. 보통 {Environment}/{Object}/{DBtype}로 만듭니다.

Next~

automatic rotation은 "secret"의 rotation 사용 전략입니다. 여기서는 일단, "Disable automatic rotation"을 선택하겠습니다.

Next~

최종적으로 설정한 부분을 확인합니다.

Store~

최종적으로 생성된 "secret"을 볼 수 있습니다. 생성된 "secret"은 RDS Proxy를 생성하는데 쓰이게 됩니다.

아래 단계로 넘어가기 앞서서 생성된 "secret"으로 들어가면 생성된 "Secret ARN"을 볼 수 있습니다. 복사해둡니다.

2. RDS Proxy에 사용할 IAM "policy" 생성하기

: RDS Proxy를 생성하는 데에 IAM "policy"를 생성하는 이유는 결국, IAM "role"을 Proxy가 가지기 위함입니다.

그러면 IAM "role"을 생성하는 이유는 RDS Proxy가 다른 서비스 자원을 이용하기 위한 권한을 획득하는 단위이기 때문입니다.

풀어보면, "secret" 리소스를 제어할 수 있는 "policy"를 만들어서, IAM "role"을 생성해서, RDS Proxy에게 권한을 넘겨주기 위함입니다.

AWS IAM으로 들어갑니다. IAM policy를 생성하기 위해서 Access management => Policies => "Create policy"를 선택합니다.

"JSON" 탭으로 이동합니다. 그리고 Policy의 JSON을 넣습니다.
"secret" Resource를 사용할 수 있게 허용하기 위해서 "your_secret_ARN"에 secret 생성 시에 얻었던 "Secret ARN"로 변경해줍니다.

Policy의 JSON은 다음과 같습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetRandomPassword",
                "secretsmanager:CreateSecret",
                "secretsmanager:ListSecrets"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "secretsmanager:*",
            "Resource": [
                     "your_secret_ARN"
            ]
        }
    ]
}

Policy JSON을 반영했으면, "Review policy"를 선택해줍니다.

Name을 적어주고 나서, "Create policy"를 눌러줍니다.

이제 AWS IAM "role"을 생성하기 위한 "policy" 생성이 되었습니다.

3. RDS Proxy에 사용할 IAM "role" 생성하기

: 위 단계에서 만들어진 IAM "policy"를 이용해서, 다음 단계에서 만들게 될 RDS Proxy가 사용할 리소스의 권한을 얻기 위한 IAM "role"을 만들어보겠습니다.

"role"을 생성하기 위해서, 다음 순서로 들어가 줍니다.
IAM => Roles 탭 => "Create role"

AWS Service에서 RDS Proxy의 role을 만들어주기 위해서 "RDS"를 선택하고, role을 추가합니다.
"AWS Service" => "RDS" => "RDS - Add Role to Database" => "Next: Permissions"

위 단계에서 RDS Proxy IAM "role"위해서 만들었던, IAM policy "test-rds-proxy"를 IAM "role"에 붙여줍니다.
"test-rds-proxy" 검색 => "Next: Tags"

그냥 넘어가도 되는 부분입니다. tag를 붙여서 가독성을 주고 싶다면, Key: Name , Value: "원하는 이름"으로 넣어주시고, 넘어가 줍니다.
"Next: Review"

최종적으로 설정한 IAM "role"의 내용을 보고, 맞다면 생성해줍니다.
"Role name" 입력 => "Create role"

생성된 IAM "role"을 확인하고 선택해서 들어가 줍니다.

하나 남은 작업이 있습니다. RDS와의 신뢰 정책을 편집해서 보다 안전하게 리소스 간에 신뢰를 구성하기 위해서입니다.
"Trust relationships" => "Edit trust relationship"

Trust Policy를 넣어주고 "Update Trust Policy"를 눌러 갱신해줍니다.

Trust Relationship을 위한 Policy JSON은 다음과 같습니다.

{

"Version":"2012-10-17",
"Statement":[

{

"Effect":"Allow",
"Principal":{

"Service":"rds.amazonaws.com"

},
"Action":"sts:AssumeRole"

}

]

}

이렇게 RDS Proxy가 RDS Aurora DB cluster와 연결되어 제 기능을 할 수 있게 하는 IAM "role", "policy"의 생성을 마쳤습니다.

4. RDS Proxy를 생성하고, Aurora cluster에 연결하기

: 여기서는 RDS Proxy를 생성하고, RDS Aurora DB cluster와 연결해보겠습니다. 연결을 마치게 되면, RDS Proxy에서 제공하는 기능들을 사용할 수 있습니다.

RDS Proxy가 제공하는 기능은 DB의 HA(High Availability)를 구현하기 위함이고, 특징적인 기능은 다음과 같습니다.

DB Connection Pool Management
Automatic Failover

Proxy identifier 입력 => Proxy가 사용될 DB Engine 선택 => TLS 연결이 필요하면 선택 => "Idle client connection timeout" 시간 선택
Proxy는 자체적으로 Connection Pool을 관리해주기 때문에 서비스의 Idel time이 적다면 "Idle client connection timeout"을 원하는 만큼 늘리면 됩니다.

"Database": Proxy와 연결할 RDS Database를 골라줍니다. 여기서는 미리 생성해두었던 RDS Database "test"를 선택해줍니다.
"Connection pool maximum connections": 생성한 Database "test"의 설정되어 있는 옵션 "max_connections"의 percent 만큼만 RDS Proxy에서 할당받아서 연결합니다.

"Secrets Manager secret(s)": "1. RDS Proxy에 사용할 Secrets Manager "secret" 생성하기"에서 생성한 secret을 적용해줍니다.
"IAM role": "RDS Proxy에 사용할 IAM "policy" 생성하기"와 "RDS Proxy에 사용할 IAM "role" 생성하기"에서 생성하였던 IAM role인 "test-rds-proxy"를 넣어줍니다.
"IAM authentication": 여기서는 1) IAM을 통한 사용자 접근 제어 방법과 2) 기존의 DB 접속 방식 이 있습니다. 여기서는 2) 번으로 사용할 것이기 때문에 Disabled를 사용합니다.
"Subnets": VPC로 사용한 곳에서 Database가 사용할 Subnet의 범위를 결정합니다. 2개 이상을 선택해주는 것이 필수입니다.
"VPC security group": 은 "Create new"로 생성해도 되고, 기존에 VPC가 있는 경우에는 "Choose existing"으로 선택해줍니다. VPC를 선택해주시는 경우에는 꼭 VPC에 "Internet Gateway"를 장착해주시길 바랍니다.

"Enhanced logging": CloudWatch에서 커스텀하게 Logging을 관리하길 원하시면, "Enable enhanced logging"을 선택해줍니다.
아직은 Preview 상태로 정식 제품이 아니기 때문에 상용에는 사용하지 마시길 바랍니다. 그리고 인지하였음을 선택해줍니다.
"Create proxy" 생성 완료!

몇 분 정도 기다리면, Proxy가 생성됩니다.
"test-proxy"를 선택해서 들어가 줍니다.

생성된 proxy의 정보를 확인할 수 있습니다.
"Proxy ARN"은 이제 DB의 host endpoint처럼 사용할 수 있습니다.
중요한 점은 RDS Proxy는 AWS 내부 환경에서만 사용할 수 있습니다. Tool을 사용하여 접속하려고 하면 접속이 불가능합니다.

그래서 테스트 환경을 구성해서 Test를 진행하기 위해서, 다음 단계로 넘어가겠습니다.

5. RDS Proxy Endpoint를 사용해서, "Automatic Failover" 테스트하기

: 이제 필요한 모든 Resource를 생성했습니다. 마지막으로 테스트 환경을 구성해서 과연 RDS Proxy를 사용해서 Primary DB(Writer)가 장애(failure)가 발생하였을 때, Automatic Failover가 반영이 되는지 확인해보겠습니다.

AWS Aurora Automatic Failover 테스트를 진행하기 위한 구성은 다음과 같습니다.

RDS Aurora Instance Cluster 1(Primary Instance 1, Replica Instance 1)
RDS Proxy 1(Secrets Manager "Secret", IAM "Policy", IAM "Role")
EC2 Instance 1

EC2 Instance를 생성하기 위해서, "EC2" => "Instances" => "Launch Instance" 선택합니다.

테스트를 위한 MySQL을 패키지로 제공하는 "Amazon Linux AMI"를 사용했습니다.
물론 다른 OS를 선택하시고, MySQL을 설치해주어도 됩니다.

원하는 EC2 Type을 선택하면 됩니다. 여기서는 t2.micro를 사용했습니다.
"Next: Configure Instance Details"를 선택

여기서 테스트를 위한 설정으로 중요한 부분은 VPC 설정입니다.
VPC는 테스트에 사용되는 RDS Aurora Cluster와 같은 VPC를 사용하시면 됩니다. 서로 다른 VPC 접근은 허용하게 설계되었다면, VPC가 달라도 무관합니다.

테스트를 위해서 방화벽인 Security Group의 Inbound Rule은 All traffic을 허용해두겠습니다.

마지막으로 설정된 정보를 확인하고, "Launch"를 눌러서 EC2 Instance를 생성합니다.

EC2 Instance를 생성하기 위해서는 접근을 위한, ".pem" 파일을 생성하거나, 기존의 ".pem"파일을 사용하셔도 됩니다.
여기에서는 기존의 ".pem"파일을 사용하겠습니다.

생성된 EC2를 확인할 수 있습니다.
이제 직접 접속하기 위해서 "Connect"를 선택해줍니다.

여기에서 EC2 Instance에 접속하기 위해서 Example의 CLI 명령어를 복사합니다.

터미널로 와서 위에서 복사한 CLI 명령어를 붙여 넣어서 접속합니다.

접속하고 나면, 일단 필요한 MySQL 패키지를 설치하기 위해서 다음 명령어를 실행해줍니다.

sudo yum update -y
sudo yum install mysql-server -y

테스트를 하기 위한 Database: "test"와 Table: "user"를 생성하기 위해서 다음 명령어를 실행해줍니다.

mysql -s -N --host=test.cluster-test1290393.ap-northeast-1.rds.amazonaws.com --user=admin --password=testdb1234! --port=3306 -e "create database test;use test;create table user (id BIGINT(20) UNSIGNED not null auto_increment, name varchar(255), age varchar(255), created_at datetime(6) not null, modified_at datetime(6) not null, primary key (id)) engine=InnoDB;";

테스트를 위해서 이전에 만들었던, RDS Proxy endpoint을 복사합니다.
RDS Proxy endpoint 접근은 AWS 내부에서 접근이 가능합니다. 외부에서는 접근이 불가능합니다. 혹시 DB tool로 사용하신다면, 접속이 안되실 겁니다.

RDS Proxy가 생성되었다고 해서, Aurora Cluster의 Endpoint를 사용하지 못하진 않습니다.
하단에 보이는 "Writer", "Reader" cluster endpoint 도 여전히 사용 가능합니다.

테스트를 위한 Insert 쿼리 하나, Select 쿼리 하나를 1초 간격으로 반복문으로 실행시켜놓습니다. (테스트가 끝났을 때는 control + C로 종료해줍니다.)

while true; do mysql -s -N --host=test.cluster-test1290393.ap-northeast-1.rds.amazonaws.com --user=admin --password=testdb1234! --port=3306 --database=test -e "insert into user(name, age, created_at, modified_at) values('name', 'age', now(), now());select now();"; sleep 1; done

RDS는 Instance를 수동으로 DB를 Failover 시킬 수 있게 기능을 제공합니다.
Failover 테스트를 위해서, RDS Databases => Writer DB Instance 선택 => "Actions" => Failover 선택 OK
쿼리를 반복문으로 실행하였던, 터미널로 돌아갑니다.

RDS Aurora를 이용한 Primary DB 장애 발생 시, Failover를 위한 RDS Proxy 테스트가 완료되었습니다.
기본적으로 RDS는 Engine에 따라서 Failover 되어 보통은 30초 이내 시간을 보장합니다.
다시 한번 말씀드리면, RDS Proxy는 현재 Preview 이기 때문에 상용 DB에 쓰는 것을 아직 권하지 않습니다.

결론

메인 DB가 장애가 오거나, 유지 보수하는 경우에는 Failover를 구현하는 것은 상당히 중요합니다.
Downtime을 짧게 하고, DB에 요청된 쿼리를 안전하게 무효화시키는 것도 중요합니다.
RDS Aurora를 사용하시는 분이라면, 추후에 RDS Proxy가 서비스 정식 런칭이 되면, 사용하시길 추천합니다.
추천하는 이유가 한 가지 더 있는데요. DB connection pool을 관리시켜줘서, 중복되거나 유휴된 Connection을 관리하여, 적은 Connection을 가지고, Connection 최적화를 이룰 수 있습니다.

참고자료

AWS RDS Proxy Docs

Amazon RDS Proxy(미리 보기)를 사용한 연결 관리 - Amazon Aurora

현재 Amazon RDS Proxy는 미리 보기로 제공됩니다. RDS Proxy를 프로덕션 워크로드에 사용하지 마십시오. 또한 RDS Proxy 미리 보기로 사용하는 데이터베이스에는 중요한 데이터를 저장하지 않는 것이 좋�

docs.aws.amazon.com

AWS Amazon Aurora

데이터 베이스 관리 시스템 | MySQL | Amazon Web Services

Amazon Aurora는 관계형 데이터베이스를 사용할 수 있는 엔터프라이즈 애플리케이션에 매우 적합한 옵션입니다. Amazon Aurora는 상용 데이터베이스와 비교하여 데이터베이스 비용을 90% 이상 낮추면서

aws.amazon.com

AWS Amazon Aurora Concept

Weekend Reading: Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. - All Things Distri

In many high-throughput OLTP style applications, the database plays a crucial role in achieving scale, reliability, high-performance, and cost efficiency. For a long time, these requirements were almost exclusively served by commercial, proprietary databas

www.allthingsdistributed.com

AWS RDS HA(Multi-AZ)

Amazon RDS를 위한 고가용성(다중 AZ) - Amazon Relational Database Service

Amazon RDS를 위한 고가용성(다중 AZ) Amazon RDS는 다중 AZ 배포를 사용해 DB 인스턴스에 고가용성과 장애 조치 기능을 지원합니다. Amazon RDS는 다양한 기술을 이용해 장애 조치 지원을 제공합니다. MariaD

docs.aws.amazon.com

Spring "Field Injection"? or "Constructor Injection"?

RyanGomdoriPooh — Tue, 16 Jun 2020 22:45:31 +0900

이야기에 앞서서...

Spring Framework에서 제공하는 @Autowired나 @Qualifier를 이용해서 객체를 찾아서 DI(Dependency Injection)해왔습니다.

물론 Java에서도 @Inject, @Resource를 제공해주어서 DI(Dependency Injection)를 할 수 있었습니다.

우선, DI는 IoC(Inversion of Control)의 핵심 원리를 구현하는 개념이라고 할 수 있습니다.

간단하게 IoC(Inversion of Control)란?

: IoC의 핵심은 기존의 Programing code 안에 들어가 있던 객체의 생성/관리를 Spring Container에게 위임하여 객체의 생명주기를 관리하게 하는 것입니다. 관리하는 객체의 단위를 Bean이라고 명명합니다.

IoC를 구현하기 위해서는 DI를 통해서 Bean을 생성하는 시점에 필요한 객체를 주입해주어야 합니다.

결국, 우리가 이야기하는 핵심은 "언제 어떻게 Bean을 생성하는 시점에 필요한 객체를 주입해야 하는가?"가 됩니다.

Field Injection인 @Autowired의 이야기부터 시작하겠습니다.

IDE에서 보여주는 경고

최근에 리팩터링을 진행하면서, 코드에서 발견한 부분이 있었습니다. @Autowired에 대한 노란색 밑줄 경고죠.

해당하는 경고 문구는 다음과 같습니다.

Injection 경고 문구

경고 문구는 간략하게 다음과 같습니다.

Field injection을 추천하지 않는다.
Spring Team은 너의 Bean들에게 Constructor 기반의 DI를 항상 사용해라.
필수적인 의존성들을 위한 assertions를 사용해라.

위 문구는 한 문장으로 "Constructor based injection을 써라. 안 쓰면 DI를 보장 못할 수 있어."라고 표현하면 맞겠네요.

뭔가 문제가 있다고 생각하니 경고를 보내고 있다고만 일단 생각하면 됩니다.

그러면 이제 "어떤 문제가 있는 것인가?"를 찾아보면 되겠네요.

Field Injection은 어떤 문제를 가지고 있는가?

우리는 Java를 사용하면서, 가장 많이 들었던 말이 있습니다. OOP(Object Oriented Programming)입니다.

OOP는 낮은 "결합성", 높은 "응집성" 구현하기 위한 개념이죠.

결국, "Inheritance", "Polymolphism", "Encapsulation", "Abstraction"는 낮은 "결합성", 높은 "응집성" 구현하기 위한 개념입니다.

IoC의 DI를 통해서 우리는 낮은 "결합성"을 구현할 수 있습니다.

여기까지는 "Setter Injection", "Constructor Injection", "Field Injection" 모두 아무런 문제를 발견할 수 없었습니다.

Code를 통한 Injection : "Setter Injection", "Constructor Injection"
Annotation을 통한 Injection : "Field Injection"

이제 문제를 찾아보겠습니다.

다음은 "Setter Injection"에 대한 코드입니다. (코드를 간단하게 표현하기 위해서 DTO는 사용하지 않겠습니다.)

@Service
public class UserService {
    private UserRepository userRepository;

    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User getUser(long userId) {
        return userRepository.findById(userId);
    }
}

@Controller
public class UserController {
	
    @GetMapping("/users/{id}")
    public User getUserInfo(@PathVariable long id) {
    	UserService userService = new UserService();
        userService.setUserRepository(new UserRepository());
        
        return userService.getUser(id);
    }
}

여기까지는 정상적으로 new UserRepository()를 setter에 전달해주었기 때문에 문제가 없습니다.

그런데 항상 우리 개발자는 실수를 할 수도 있죠. 바로 다음과 같은 코드입니다.

@Controller
public class UserController {
	
    @GetMapping("/users/{id}")
    public User getUserInfo(@PathVariable long id) {
    	UserService userService = new UserService();
        // userService.setUserRepository(new UserRepository());
        
        return userService.getUser(id);
    }
}

new UserRepository()를 setter로 전달해주는 것을 까먹은 것입니다.

문제는 CompileTime에 이 실수를 잡아주지 않습니다.

UserService는 생성이 되고, 결국 RunTime에 userService.getUser(id);가 호출되는 시점에 NullPointException()이 발생하게 됩니다.

Field Injection도 Setter Injection과 마찬가지로 Spring Container가 주입해야할 new UserRepository()를 주입하지 않아도 UserService가 생성되는 문제가 있습니다.

결국 Setter Injection처럼 userService.getUser(id);가 호출되는 시점에 NullPointException()이 발생하게 됩니다.

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;//<- null

    public User getUser(long userId) {
        return userRepository.findById(userId);
    }
}

@Controller
public class UserController {
	
    @GetMapping("/users/{id}")
    public User getUserInfo(@PathVariable long id) {
    	UserService userService = new UserService();
        
        return userService.getUser(id);
    }
}

차이점은 주입을 setter로 프로그래머가 직접 하는가, 아니면 @Autowired로 Spring Container가 해주는가입니다.

여기까지 Setter Injection / Field Injection의 단점에 대해서 알게 되었습니다.

CompileTime에 문제가 발견되지 않고, RunTime에 Method를 호출하게 되면, NPE가 발생하는 것

Constructor Injection은 어떤 장점이 있을까?

Service Layer의 Business Logic이 복잡해지면 복잡해질수록, 우리는 주입된 Bean들이 엄청 늘어나는 것을 볼 수 있습니다.

Bean들이 늘어나면서, 서로 다른 Service에서 거미줄처럼 주입되어있게 되는데,

Annotation "@Autowired"을 통한 Field Injection은 CompileTime에 순환 참조를 확인할 수 없습니다.

이유는 다음과 같습니다.

Setter Injection / Field Injection은 일단 모든 Bean을 생성하여 Bean Factory에 등록합니다.
Bean이 모두 생성되어 Bean Factory에 등록되고나면, 주입할 Bean들을 가져와서 주입합니다.
결국 순환 참조를 알아챌 타이밍을 이 시점에는 놓쳐버리게 되는 겁니다.
이제 순환 참조가 만들 지옥은 Runtime에 Business Logic에서 발생하게 되겠습니다.

결국에 나도 모르는 사이에 Runtime 순환 참조가 발생할 수 있는 가능성이 생겨버릴 수 있는 것입니다.

Field Injection을 통한 순환 참조 발생 문제 발생을 설명하겠습니다.

순환 참조된 상태의 Bean이 2개가 생성된다.
순환 참조된 상태의 Bean A와 Bean B가 Business Logic에 서로 Method를 호출하는 Method A를 만든다.
Method A가 Runtime에 호출이 된다.
서로 호출되면서 Recusive 방식으로 Stack에 호출된 Method가 쌓인다.
결국 Stack의 Memory Size가 넘어가면서, java.lang.StackOverflowError가 발생합니다.

코드는 다음과 같습니다.

@Service
public class AService {

    @Autowired
    private BService bService;

    public void aMethod() {
        bService.bMethod();
    }
}

@Service
public class BService {

    @Autowired
    private AService aService;

    public void bMethod() {
        aService.aMethod();
    }
}

aService.aMethod(); //가 호출되는 순간 StackOverflowError가 발생됩니다.

그래서 우리는 애초에 Bean이 주입되는 시점에 순환 참조의 가능성을 막아야 합니다.

이 시점에 IDE에서 Constructor Injection을 추천하는 이유가 나옵니다.

결론부터 이야기를 하면,

Spring Container가 Constructor Injection을 사용하면 Application 실행 시점에 Bean이 순환 참조되었다는 것을 다음처럼 BeanCreationException으로 알려줍니다.

알려줄 수 있는 이유는 다음과 같습니다.

Setter Injection / Field Injection과 다르게 Constructor Injection은 생성자로 빈을 주입하게 됩니다.
생성자로 빈을 주입한다는 이야기는 자바에서 객체가 생성이 되려면, 주입될 Bean의 소재지를 찾아서 넣어줘야한다는 것입니다.
결국 생성 시점에 모든 Bean이 정상적인 상태가 아니면 에러를 발생시킬 수 있다는 것입니다.
자바의 객체 생성 원리가 Bean의 순환 참조 가능성을 제거해줄 수 있습니다.

Constructor Injection을 통한 순환 참조 예시입니다.

@Service
public class AService {

    private final BService bService;
    
    public AService(BService bService) {
        this.bService = bService;
    }

    public void aMethod() {
        bService.bMethod();
    }
}

@Service
public class BService {

    private final AService aService;
    
    public BService(AService aService) {
        this.aService = aService;
    }

    public void bMethod() {
        aService.aMethod();
    }
}

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  AService defined in file [AService.class]
↑     ↓
|  BService defined in file [BService.class]
└─────┘


2020-06-16 22:12:55.080  WARN 13272 --- [           main] o.s.boot.SpringApplication               : Unable to close ApplicationContext

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'applicationAvailability' defined in class path resource [org/springframework/boot/autoconfigure/availability/ApplicationAvailabilityAutoConfiguration.class]: BeanPostProcessor before instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'metaDataSourceAdvisor': Cannot resolve reference to bean 'methodSecurityMetadataSource' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration': Initialization of bean failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.springframework.context.annotation.ConfigurationClassPostProcessor.importRegistry' available
...

그리고 한 가지 더 Constructor Injection을 이용하면, 위 코드에서 보셨겠지만 final 키워드를 사용할 수 있습니다.

final은 상수를 만드는 키워드 입니다. 한 번 주입된 객체를 다른 객체로 변경을 불가능합니다.

흔히 "Immutable Object"라 이야기 많이 합니다. Spring Container가 아니면 Tread Safe 이야기도 나올 수 있는 부분이죠.

물론 primitive가 아니기 때문에 객체 내용물의 상태는 변화할 수 있습니다. 하지만 객체 자체를 수정하는 것은 불가능합니다.

그래서 Bean 주입을 위해서 쓰이기에는 최적입니다.

결론

Field Injection은 다음과 같은 문제점이 있습니다.

주입되지 않은 Bean으로 인한 NullPointException 발생 가능성
Runtime에 순환 참조로 인한 StackOverflowError 발생 가능성

그래서 사전에 위 문제점을 해결이 가능한 Construction Injection을 사용하는 것입니다.

장점은 다음과 같습니다.

Bean이 주입되지 않는 경우, Compile Time에 알려주어서 NullPointException을 예방할 수 있습니다.
Bean이 순환 참조될 경우를 Spring Container가 미리 알려주기 때문에 순환참조 가능성을 없앨 수 있습니다.
final로 "Immutable Object"를 만들어버리기 때문에 Application이 재가동이 되기 전까지는 불변하는 Bean을 사용할 수 있습니다.

최근에는 Lombok의 @RequiredArgsConstructor를 이용해서 생성자 주입을 하기도 합니다만,

DDD를 공부하는 저는 개인적으로 Lombok을 좋아하지 않아서 사용하진 않았습니다.

Ryan Server

Solution : "An error occurred (TargetNotConnected) when calling the StartSession operation: {instance-id} is not connected."

Java User Defined Package Naming Convention (Spring, Android, ...)

Overview

Index

1. What is user-defined package name?

2. How to make user-defined package name

3. Examples for user-defined package name

Format 1)

Format 2)

Conclusion

Reference

쿠키와 세션 개념

개요

목차

1. HTTP의 특징과 쿠키와 세션을 사용하는 이유

2. 쿠키 ( Cookie )

3. 세션 ( Session )

4. 쿠키와 세션의 차이

5. 세션을 사용하면 좋은데 왜 쿠키를 사용할까?

6. 쿠키/세션은 캐시와 엄연히 다르다!

Blocking or Non-Blocking, Synchronous and Asynchronous

Overview

Index

1. Blocking and Non-blocking

Blocking

Non-blocking

2. Synchronous and Asynchronous

Synchronous

Asynchronous

3. Difference between "Blocking and Non-blocking" and "Sync and Async"

Blocking

Non-blocking

Synchronous

Asynchronous

3. Cases: (Blocking or Non-blocking) X (Sync or Async)

Synchronous blocking I/O

Synchronous non-blocking I/O

Asynchronous blocking I/O

Asynchronous Non-Blocking I/O (AIO)

Conclusion

Reference

What is Java GC(Garbage Collection)?

So, Which objects will GC collect?

How does gc work?

When will GC happen and how will it be handled?

Type of Major GC (based on JDK 7)

Serial GC

Parallel GC

Parallel Old GC

Concurrent Mark & Sweep GC(CMS GC)

G1 GC (G1: Garbage First)

Since G1GC officially appeared in JDK 7, it has been widely used, so let's take a closer look at the setting options.

Memory Management

Conclusion

Reference

What is Java OOP(Object Oriented Programming)?

Jackson ObjectMapper 정리

개요

목차

1. Add Dependency for "Jackson ObjectMapper"

2. Basic Features

2.1. Convert "Java Object" to "JSON"

2.2. Convert "JSON" to "Java Object"

2.3. Convert "JSON" to "Jackson JsonNode"

2.4. Convert "JSON Array String" to "Java List"

2.5. Convert "JSON String" to "Java Map"

3. Advanced Features

3.1. Configuring Serialization or Deserialization Feature

3.2. Creating Custom Serializer or Deserializer

3.3. Handling Date Formats

3.4. Handling Collections

결론

참고자료

자바 인터페이스(Java Interface)는 무엇인가?

개요

목차

1. 인터페이스(interface) 역할

2. 인터페이스(interface) 선언

3. 인터페이스(interface) 구현