IT 블로그

클라우드 네이티브란?

[Column] 클라우드 네이티브란?

클라우드 네이티브를 위한 주요 4가지 요소

1. DevOps 애플리케이션 개발-운영 간의 협업 프로세스를 자동화하는 것을 말하며 결과적으로 애플리케이션의 개발과 개선 속도를 빠르게 합니다.
2. CI/CD 지속적인 통합(Continous Intergration)은 개발자가 작업한 코드를 자동으로 테스트하고 테스트에 통과하면 코드를 통합하여 저장합니다. 지속적인 배포(Continuos Deployment)는 작업한 코드 및 변경사항들은 테스트를 거쳐 리포지토리에 업로드되고 실 서비스 배포로 릴리즈까지 자동화하는 것을 말합니다.
3. 컨테이너 기반 인프라 가상화 기술 중 하나로, 시스템을 가상화하는 것이 아니라 애플리케이션을 구동할 수 있는 컴퓨팅 작업을 패키징하여 가상화한 것입니다.
4. Microservice 애플리케이션을 구성하는 서비스들을 독립적인 작은 단위로 분해하여 구축하고 각 구성 요소들을 네트워크로 통신하는 아키텍처로 서비스 안정성과 확장성(scaling)을 지원합니다.

[컨테이너]

IT 기술의 컨테이너도 물류 분야의 컨테이너처럼 이동성을 실현하기 위한 기술입니다. 즉, 어느 환경이나 어느 인프라로든 쉽게 이동할 수 있다는 말인데요, 컨테이너는 애플리케이션을 실행하기 위한 컴퓨팅 작업을 패키징하여 이미지로 만들기 때문에 경량화되어있고, 서버나 OS 환경에 종속적이지 않아 진정한 애플리케이션 이식성이 실현됩니다.

이해를 돕기 위해 컨테이너와 대조되는 하이퍼바이저 기반의 가상화와 비교해보겠습니다.

하이퍼바이저 기반의 가상화(VM 방식)는 애플리케이션이 돌아갈 수 있는 OS 환경이 포함됩니다. 그렇기 때문에 애플리케이션을 실행하기 위해서는 VM을 띄워 자원을 할당한 다음, OS를 부팅한 후 애플리케이션을 구동할 수 있기 때문에 시간이 오래 걸립니다.

반면, 컨테이너 기반의 가상화 방식은 프로세스 간 벽을 만들어 애플리케이션이 구동되는 환경이 격리(컨테이너화)되어 있기 때문에 각 각의 APP에 OS를 개별로 구성해줄 필요 없이 하나의 OS 커널*을 공유하여 사용합니다. OS가 필요하지 않음으로 더 가볍고 크기도 작아 복제와 배포에도 간편합니다

따라서, 애플리케이션을 구동하기 위해서 OS가 필요하지 않아 가볍고, 애플리케이션 실행에 필요한 모든 것(라이브러리, 바이너리, 기타 구성 파일 등)을 패키지로 묶어 컨테이너 이미지를 만들어 사용하기 때문에 컨테이너가 작동하는 환경이라면 어디서든지 실행시킬 수 있다는 장점이 있습니다.

*커널이란? : 운영 체제의 핵심으로 하드웨어의 자원(CPU, Memory, Devices)을 각 프로세스에 사용할 수 있도록 나눠주고, 프로세스 및 메모리 제어 등 시스템의 모든 것을 통제합니다.

특징을 정리해 보면,

1. 경량화 – 앱 구동을 위해 게스트 OS가 포함되지 않습니다.
2. 효율성 – 호스트 OS 커널을 공유하므로, 자원을 미리 할당하지 않고 애플리케이션 동작에 필요한 컴퓨팅 자원만 필요로 합니다.
3. 이식성 – 컨테이너가 작동하는 환경이라면 어디든지 작동시킬 수 있습니다.
4. 안정성 – 호스트 OS 커널을 공유하는 구조로 장애 발생 시, 다른 컨테이너들이 영향을 받을 수 있습니다.

[마이크로서비스]

마이크로서비스 아키텍처는 애플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것을 말합니다. 서비스끼리는 프로그래밍 언어에 구속받지 않는 API(Application Programming Interface)를 통해서 통신하며 각 서비스는 각각 자체 DB를 가지게 됩니다.

모놀리식 아키텍처와 비교해 본다면,

monolithic-vs-microservices <그림 참고 : Red Hat Site>

모놀리식은 전체 애플리케이션이 하나의 통합된 패키지 형태로 구성되어 있고 구성 모듈들이 의존적으로 연결되어 있기 때문에 기능 하나를 변경하려면 전체 애플리케이션을 재배포해야 하는 번거로움이 있습니다. 같은 이유로 특정 모듈만 확장하기가 어렵고 애플리케이션을 담고 있는 서버 자체를 늘려야 하는 비효율적 구조입니다. 또한, 개발 초기에 사용한 기술 스택에 고정되어 사용 해야 한다는 제약이 있습니다.

반면, 마이크로서비스 아키텍처는 애플리케이션을 작은 기능으로 나누어 구축하기 때문에 개별 서비스들을 더 쉽게 변경하거나 확장할 수 있으며, 서비스마다 다른 언어, 프레임워크, 라이브러리를 사용할 수 있다는 장점이 있습니다. 하지만, 모놀리식 보다는 구조가 복잡하고 여러 서비스에 데이터가 분산되어 있어 데이터 관리가 어렵다는 단점이 있습니다.

특징을 정리해 보면,

1. 확장성 – 전체 애플리케이션을 담고 있는 서버를 추가하거나 사양을 늘리는 것이 아니라, 리소스를 더 필요로 하는 모듈만 수평, 수직적으로 쉽게 확장할 수 있습니다.
2. 생산성 – 개발자는 해당 기능(서비스)에만 집중하여 개발할 수 있으며 테스트/배포에 걸리는 시간도 줄일 수 있어 생산성을 높일 수 있습니다.
3. 안정성 – 모놀리식 구조에서는 하나의 장애가 전체 애플리케이션에 영향을 줄 수 있으며 찾아내기도 어렵습니다. 반면 서비스들이 분리된 독립적인 구조에서는 장애를 그 서비스에 한정적으로 격리할 수 있습니다.
4. 복잡성 – 여러 서비스가 분산되어 얽혀 있기 때문에 복잡성이 높으며, 분산시스템을 어떻게 구성할 것인지에 대한 어려움이 있습니다.

• 수평 확장(Scale Out) : 서버 대수를 늘림
• 수직 확장(Scale Up) : 서버 사양을 늘림

[DevOps와 CI/CD]

DevOps는 ‘개발과 IT 운영 간의 프로세스를 통합하여 궁극적으로는 고객에게 뛰어난 품질의 서비스를 빠르게 제공한다’는 개발 방법론입니다. 그렇다면 개발(Dev)과 운영(Ops)의 업무는 다른데 왜 통합하려고 하는가? 인데요,

과거 새로운 서비스를 출시하기 위해서 오랜 기간 작업 후 배포했던 것과 달리, 현재는 서비스 출시 속도가 빠르고 업데이트 주기 또한 빈번해졌습니다. 그렇기 때문에 개발된 소프트웨어가 시스템의 안정성을 유지하면서 사용자에게 빠르게 제공될 수 있도록 [개발-테스트-배포-운영]의 업무 사이클을 자동화된 단일 워크플로우로 통합할 필요성이 생긴 것입니다.

DevOps를 하려면,

• 소스 코드 제어(SCM, Source Code Management)
서비스는 보통 팀 단위로 개발되는데, 서로 다른 팀에서 개발한 코드에 대한 버전과 이력을 관리해야 합니다.

• CI/CD
CI/CD는 위에서 설명한 것 같이 지속적인 통합과 배포를 통해 애플리케이션 개발 단계를 자동화하여 고객에게 보다 짧은 주기로 서비스를 제공하고 개선하는 방법입니다.

• 모니터링
업데이트 빈도가 늘어남에 따라 일반적으로 요구되는 엄격한 테스트를 매번 수행할 수가 없습니다. 따라서, 데브옵스 환경에서는 실시간으로 앱 및 성능 모니터링을 통하여 오류, 개선사항을 찾아 해결하는 것이 중요합니다.

• 문화
지난 컬럼에서도 이야기한 바와 같이 DevOps는 개발과 운영 방식을 너머 사일로(silo, 부서 이기주의)를 없앤 ‘협업 문화’라고 볼 수 있습니다. <참고 : DevOps를 하려면 무엇부터 해야 할까?>

[Column] DevOps를 하려면 무엇부터 해야 할까? – CLOUDMATE (cloudmt.co.kr)

[금융IT] 금융회사 시스템 연계 구성 (MCI/EAI/FEP)

[금융IT] 금융회사 시스템 연계 구성 (MCI/EAI/FEP)

1. MCI/MCA Multi Channel Integration / Multi Channel Architecture

• 주로 기업 내부 동기종 또는 유사기종 시스템을 연계시키는데 사용된다.
• 예를 들어 은행에서 여신 업무와 수신 업무는 MCI/MCA를 통해 연계된다.
• MCI와 MCA는 기업마다 다르게 부를 수 있지만 의미 차이는 두지 않는다.

2. EAI Enterprise Application Integration

• 주로 기업 내부 이기종 시스템을 연계시키는데 사용된다.
• 시스템 구조나 개발 언어가 다를 수 있어서 어댑터를 사용한다.
• 예를 들어 은행에서 채널계와 계정계는 EAI를 통해 연계된다.

3. ESB Enterprise Service Bus

• SOA에서 사용되는 개념이다.
• EAI와 유사하게 사용된다. 기관 간, 서비스 간 연계가 이루어진다.
• SOA 개념을 도입하지 않은 기관에선 ESB라는 개념을 잘 사용하지 않는다.

4. FEP Front End Processor

• 원래는 메인프레임에서 통신 과부하를 경감시키기 위해 전처리 작업을 하는 과정을 말한다.
• 금융권에서는 의미가 조금 와전되어 B2B 연계를 FEP라고 부른다.
• 전용선 또는 VPN을 이용하 연결된 기관 간, 정해진 인터페이스로 배치파일(SAM)을 전달한다.

구분 EAI ESB

[금융 IT] BCV / EAI / ESB / MCI / MCA

[금융 IT] BCV / EAI / ESB / MCI / MCA

유사한데, 한두줄 설명이 다름

CI 과정

1. work-assistant-api 프로젝트의 main branch을 타겟으로 하는 Pull Request를 merge하거나 main branch에 push
2. Jenkins를 통해 자동 테스트와 빌드 실행
3. (3-1) 빌드 성공 여부를 Slack을 통해 알림

CD 과정 3. (3-2) 빌드 결과물인 .jar 파일을 S3에 업로드 4. CodeDeploy에서 빌드 결과물에 대한 배포 실행 5. SNS를 통해 배포 알림 요청 6. SNS가 Lambda를 트리거 7. Lambda에서 배포 성공 여부를 Slack을 통해 알림

미리도서관 API, CI / CD 구축하기

1. 배포를 위한 이벤트 발생 시, Gitlab Webhook으로 Jenkins 서버에 소스를 넘겨줍니다.
2. 넘겨 받은 소스를 Zip 파일로 압축하여 AWS S3로 전달합니다.
3. Jenkins는 AWS CodeDeploy에게 "S3에게 소스를 전달했으니 이제 배포를 시작해줘"라는 요청을 하게 됩니다.(우리는 배포 방법으로 Auto Scalinig Group에 ELB를 연동하여 Blue-Green 방식을 사용하도록 하겠습니다.)
4. CodeDeploy는 설정된 배포 방식으로 기존의 Auto Scaling Group과 동일한 정책의 또 다른 Auto Scaling Group을 만들고 인스턴스를 생성하기 시작합니다.
5. 이때, (새롭게 생성되고 있는) 각 인스턴스에서 CodeDeploy Agent를 통해 S3로부터 Zip 파일 형태의 소스를 가져오고 나머지 배포 스크립트를 수행합니다.
6. 전반적인 수행 과정에 대한 상태 메세지를 Slack 채널을 통해 실시간으로 알리도록 합니다.

[무중단 배포 환경 구축하기] - 1. 아키텍처 구성 (velog.io)

컨테이너 및 도커 개념정리

컨테이너 장점 정리
- 애플리케이션 레벨 고립
- VM보다 빠른 셋업
- VM보다 메모리 덜 소모
- 마이그레이션, 백업, 전송이 쉬움. VM과 비교해 크기가 작기 때문이다.
- 하드웨어와의 빠른 커뮤니케이션은 따라, 성능에 효과적일 수 있다.
- 애플리케이션 배치와 유지보수를 향상시킨다.
- 애플리케이션 전달 시간 감소

도커 이미지 사이즈 최적화 해보기 - GB를 MB로

2단계. Multi-stage build Multi-stage build 란 빌드에만 필요한 작업을 나눠서 빌드하여 추후 최종 컨테이너 이미지에는 포함시키지 않는 방법이다. 즉, 빌드 단계롤 분리함으로써 불필요한 요소들을 결과물에서 제거할 수 있게 만드는 방법입니다. → 그림 링크 깨짐

Kafka란? (Kafka의 구조와, 주요개념)

Kafka - Kafka란? (Kafka의 구조와, 주요개념)

구성요소

2.1 Event

Event는, kafka에서 Producer와 Consumer가 데이터를 주고 받는 단위입니다. 이 글에서는 이벤트 또는 메시지로 표기하겠습니다.

2.2 Producer

Producer는 kafka에 이벤트를 게시(post)하는 클라이언트 어플리케이션을 의미합니다.

2.3 Consumer

Consumer는 이러한 Topic을 구독하고 이로부터 얻어낸 이벤트를 처리하는 클라이언트 어플리케이션 입니다.

2.4 Topic

이벤트가 쓰이는 곳입니다. Producer는 이 Topic에 이벤트를 게시합니다. 그리고 Consumer는 Topic으로 부터 이벤트를 가져와 처리합니다. Topic은 파일시스템의 폴더와 유사하며, 이벤트는 폴더안의 파일과 유사합니다.

Topic에 저장된 이벤트는 필요한 만큼 다시 읽을 수 있습니다.

Partition

Topic는 여러 Broker에 분산되어 저장되며, 이렇게 분산된 Topic을 Partition이라고 합니다. 어떤 이벤트가 Partition에 저장될지는 이벤트의 key(키)에 의해 정해지며, 같은 키를 가지는 이벤트는 항상 같은 Partition에 저장됩니다. Kafka는 Topic의 Partition에 지정된 Consumer가 항상 정확히 동일한 순서로 Partition의 이벤트를 읽을것을 보장합니다.

Kafka의 주요 개념

3.1 Producer와 Consumer의 분리

Kafka의 Producer와 Consumer는 완전 별개로 동작을 합니다. Producer는 Broker의 Topic에 메시지를 게시하기만 하면되며, Consumer는 Broker의 특정 Topic에서 메시지를 가져와 처리를 하기만 합니다. 이 덕분에 Kafka는 높은 확장성을 제공합니다. 즉, Producer 또는 Consumer를 필요에 의해 스케일 인 아웃하기에 용이한 구조입니다. 만약, Producer와 Consumer가 직접적으로 연관을 가지고 있다면, 확장 또는 축소시 이들을 모두 연결 또는 해제를 하기가 매우 번거럽고 어려웠을 것입니다.

3.2 Push 와 Pull 모델

kafka의 Consumer는 Pull 모델을 기반으로 메시지 처리를 진행합니다. 즉, Broker가 Consumer에게 메시지를 전달하는 것이 아닌, Consumer가 필요할때, Broker로 부터 메시지를 가져와 처리하는 형태입니다.  이러한 형태는 아래와 같은 장점이 존재합니다.

1. 다양한 소비자의 처리 형태와 속도를 고려하지 않아도 된다. 반대의 경우인 Push모델에서는, Broker가 데이터 전송 속도를 제어하기 때문에, 다양한 메시지 스트림의 소비자를 다루기가 어렵지만, Pull 모델은 Consumer가 처리 가능한 때에 메시지를 가져와 처리하기 때문에 다양한 소비자를 다루기가 쉽습니다.
2. 불필요한 지연없이 일괄처리를 통해 성능향상 도모. Push 모델의 경우에는, 요청을 즉시 보내거나, 더 많은 메시지를 한번에 처리하도록 하기 위해 Buffering을 할 수 있습니다. 하지만 이런 경우, Consumer가 현재 메시지를 처리할 수 있음에도, 대기를 해야합니다. 그렇다고 전송 지연시간을 최소로 변경하면, 한번에 하나의 메시지만을 보내도록 하는것과 같으므로 매우 비효율적입니다. pull 모델의 경우, 마지막으로 처리된 메시지 이후의 메시지를 Consumer가 처리가능한 때에 모두 가져오기 때문에, 이 문제를 해결합니다. 따라서 불필요한 지연 없이 최적의 일괄처리를 할 수 있습니다.

메세지는 지정된 Topic에 전달됩니다. Topic은 다시 여러 Partition으로 나뉠 수도 있습니다. 위 그림에서 각 파티션의 한칸한칸은 로그라고 칭합니다. 또한 메시지는 로그에 순차적으로 append 됩니다. 그리고 이 메시지의 상대적인 위치를 offset이라고 칭합니다.

메시징 시스템은 Broker에서 소비된 메시지에 대한 메타데이터를 유지합니다. 즉, 메시지가 Consumer에게 전달되면 Broker는 이를 로컬에 기록하거나, 소비자의 승인을 기다립니다.

Commit과 Offset

Consumer의 poll()은 이전에 commit한 offset이 존재하면, 해당 offset 이후의 메시지를 읽어오게 됩니다. 또 읽어온 뒤, 마지막 offset을 commit을 합니다. 이어서 poll()이 실행되면 방금전 commit한 offset이후의 메시지를 읽어와 처리하게 됩니다.

Apache Kafka(아파치 카프카)란 무엇인가?

Apache Kafka(아파치 카프카)란 무엇인가?

카프카 아키텍처

• 프로듀서(Producer)
  메시지를 생산하여 브로커의 토픽으로 전달하는 역할
• 브로커(Broker)
  카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 지칭
• 컨슈머(Consumer)
  브로커의 토픽으로부터 저장된 메시지를 전달받는 역할
• 주키퍼(Zookeeper)
  분산 애플리케이션 관리를 위한 코디네이션 시스템 분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이밍, 동기화 등의 서비스 수행

작동방식

• 프로듀서는 새 메시지를 카프카에 전달
• 전달된 메시지는 브로커의 토픽이라는 메시지 구분자에 저장
• 컨슈머는 구독한 토픽에 접근하여 메시지를 가져옴 (pull 방식)

기존 메시징 시스템과 다른 점

• 디스크에 메시지 저장
  기존 메시징 시스템과 가장 큰 특징 기존 메시징 시스템은 컨슈머가 메시지를 소비하면 큐에서 바로 메시지를 삭제 하지만, 카프카는 컨슈머가 메시지를 소비하더라도 디스크에 메시지를 일정기간 보관하기 때문에 메시지의 손실이 없음 (영속성)
• 멀티 프로듀서, 멀티 컨슈머
  카프카의 경우 디스크에 메시지를 저장하는 특징으로 인해, 프로듀서와 컨슈머 모두 하나 이상의 메시지를 주고 받을 수 있음
• 분산형 스트리밍 플랫폼
  단일 시스템 대비 성능이 우수하며, 시스템 확장이 용이함 일부 노드가 죽더라도 다른 노드가 해당 일을 지속 (고가용성)
• 페이지 캐시
  카프카는 잔여 메모리를 이용해 디스크 Read/Write 를 하지 않고 페이지 캐시를 통한 Read/Write으로 인해 처리속도가 매우 빠름
• 배치 전송 처리
  서버와 클라이언트 사이에서 빈번하게 발생하는 메시지 통신을 하나씩 처리할 경우 그만큼 네트워크 왕복의 오버헤드가 발생
  이로인해, 메시지를 작은 단위로 묶어 배치 처리를 함으로써 속도 향상에 큰 도움을 줌

[비교]

Kafka

• 높은 처리량 및 고성능/분산/스케일 아웃이 중요한 경우
• 가용성(장애 대응)이 높아야 하는 경우
• 메시지 전달 보장이 필수적이지 않은 경우
• 메시지 처리 순서가 보장되어야 하는 경우
• 스트리밍 데이터 처리가 필요한 경우
• 메시지 영속성이 필요한 경우

RabbitMQ

• 빠르고 쉽게 메시지 큐 시스템을 구축하고자 하는 경우 (라우팅 기능이 유연함)
• 메시지 전달 보장이 필수적인 경우
• 메시치 처리 순서가 보장되지 않아도 되는 경우
• 메시지 영속성 X

Google Pub/Sub

• Kafka와 유사한 아키텍처 (topic 개념)
• 클라우드 서비스로서 별도의 설치나 운영이 필요없음
• 메시지 처리 순서 보장이 안됨(분산형 아키텍처)
• 메시지 영속성 X (저장기간 최대 7일)

아파치 카프카 (Apache Kafka)란?

아파치 카프카 (Apache Kafka)란? : 네이버 블로그 (naver.com)

▶ Cluster : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합

▶ Producer : 데이터를 만들어내어 전달하는 전달자의 역할

▶ Consumer : 프로듀서에서 전달한 데이터를 브로커에 요청하여 메시지(데이터)를 소비하는 역할

▶ Broker : 생산자와 소비자와의 중재자 역할을 하는 역할

▶ Topic : 보내는 메시지를 구분하기 위한 카테고리화

▶ Partition : 토픽을 구성하는 데이터 저장소로서 수평확장이 가능한 형태

broker로 (아래와 같은) 클러스터를 구성할 수 있는데, broker가 되는 각각의 KafkaServer는 자신의 식별자로 broker.id를 부여받게 되며 producer로부터 생성된 메시지를 저장할 위치정보와 클러스터 메타정보를 저장 및 관리할 Zookeeper 연결정보가 지정된다

GITLAB CI & CodeDeploy 설정

Deploy from Gitlab to AWS EC2

→ EC2 엡 배포하는… (eng)

[기존]

GitLab을 사용해서 AWS에 배포하기\:\ Lambda, Fargate, EC2, EKS와 ECS를 위한 단일 애플리케이션 | DevSecOps 구축 컨설팅, 교육, 기술지원 서비스 제공

→ 잘 모르겠음

AWS ec2에 git, gitlab 설치하기

→ 딱 설치까지만 나옴

Gitlab Runner AWS EC2 CI/CD 빌드 배포 구성하기

→ Runner 설정 관련

AWS EC2 ELK Elasticsearch7.x + Logstash7.x + Kibana7.x + beats 최신버전 설치

→ 참조

Deploy to AWS from GitLab CI/CD | GitLab

→ 공식 페이지

AWS CodeDeploy / CodePipeline / S3를 사용하여 Gitlab-Ci와 함께 EC2에 배포하는 방법

Travis

[AWS] Travis CI와 AWS CodeDeploy를 사용한 자동배포 구축하기 #1 (tistory.com)

[ Jenkins ] 1) Jenkins(젠킨스) CI / CD 구축 ( with AWS EC2 )
https://humanwater.tistory.com/15

[ Project ] AWS - Jenkins(젠킨스) CI / CD 구축 (2)
https://humanwater.tistory.com/16

[Java] 자바 JVM 내부 구조와 메모리 구조에 대하여

[Java] 자바 JVM 내부 구조와 메모리 구조에 대하여

[Java] 자바 가상머신 JVM(Java Virtual Machine) 총정리

[Java] 자바 가상머신 JVM(Java Virtual Machine) 총정리

JVM은 바이트코드를 명령어 단위로 읽어서 해석하는데, Interpreter 방식과 JIT 컴파일 방식 두 가지 방식을 혼합하여 사용합니다. 먼저 Interpreter 방식은 바이트코드를 한 줄씩 해석, 실행하는 방식입니다. 초기 방식으로, 속도가 느리다는 단점이 있습니다

이렇게 느린 속도를 보완하기 위해 나온 것이 JIT(Just In Time) 컴파일 방식입니다. 바이트코드를 JIT 컴파일러를 이용해 프로그램을 실제 실행하는 시점(바이트코드를 실행하는 시점)에 각 OS에 맞는 Native Code로 변환하여 실행 속도를 개선하였습니다. 하지만, 바이트코드를 Native Code로 변환하는 데에도 비용이 소요되므로, JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고, 인터프리터 방식을 사용하다가 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행합니다.

자바 8에서 추가한 스트림(Streams)은 람다를 활용할 수 있는 기술 중 하나입니다. 자바 8 이전에는 배열 또는 컬렉션 인스턴스를 다루는 방법은 for 또는 foreach 문을 돌면서 요소 하나씩을 꺼내서 다루는 방법이었습니다. 간단한 경우라면 상관없지만 로직이 복잡해질수록 코드의 양이 많아져 여러 로직이 섞이게 되고, 메소드를 나눌 경우 루프를 여러 번 도는 경우가 발생합니다.

스트림은 '데이터의 흐름’입니다. 배열 또는 컬렉션 인스턴스에 함수 여러 개를 조합해서 원하는 결과를 필터링하고 가공된 결과를 얻을 수 있습니다. 또한 람다를 이용해서 코드의 양을 줄이고 간결하게 표현할 수 있습니다. 즉, 배열과 컬렉션을 함수형으로 처리할 수 있습니다.

또 하나의 장점은 간단하게 병렬처리(multi-threading)가 가능하다는 점입니다. 하나의 작업을 둘 이상의 작업으로 잘게 나눠서 동시에 진행하는 것을 병렬 처리(parallel processing)라고 합니다. 즉 쓰레드를 이용해 많은 요소들을 빠르게 처리할 수 있습니다.

스트림에 대한 내용은 크게 세 가지로 나눌 수 있습니다.

1. 생성하기 : 스트림 인스턴스 생성.
2. 가공하기 : 필터링(filtering) 및 맵핑(mapping) 등 원하는 결과를 만들어가는 중간 작업(intermediate operations).
3. 결과 만들기 : 최종적으로 결과를 만들어내는 작업(terminal operations).

Java 스트림 Stream (1) 총정리 | Eric Han's IT Blog (futurecreator.github.io)

JDK 5.0이상에서 지원하는 GC 방식에는 네가지가 있다. WAS나 자바 애플리케이션 수행시 옵션을 지정하여 선택할 수 있다.

4가지 GC(가비지 콜렉터) 방식

1. Serial GC (시리얼 콜렉터)
2. Parallel GC (병렬 콜렉터)
3. Parallel Compacting GC (Parallel Old GC, 병렬 컴팩팅 콜렉터)
4. Concurrent Mark-Sweep GC (CMS 콜렉터)
5. Garbage First GC (G1 GC)

JVM GC 동작 순서

요약하면 GC 동작은 아래 3 STEP으로 나눠진다.

• Heap 영역에 존재하는 객체들에 대해 접근 가능한지 확인한다.
• GC Root에서 부터 시작하여 참조값을 따라가며 접근 가능한 객체들에 Mark하는 과정을 진행한다.
• Mark 되지 않은 객체 즉, 접근할 수 없는 객체는 제거(Sweep) 대상이 된고, 해당 객체들을 제거한다.

접근 가능한 객체 판단 과정

GC Root에서 시작해서 참조하는 객체를 찾고, 또 그 객체가 참조하는 객체를 찾아가며 Mark 한다.

Mark 되지 않은 객체는 접근할 수 없는 객체 (Unreachable Object)로 판단하고 메모리를 돌며 제거(Sweep)한다.

GC Root가 될 수 있는 대상

• JVM 메모리의 Stack 영역에 존재하는 참조 변수
• Method Area의 static 데이터
• JNI에 의해 생성된 객체들

1. Serial GC

Young 영역과 Old 영역이 시리얼하게(연속적으로) 처리되며 하나의 CPU를 사용한다.

이 처리를 수행할 때를 Stop-the-world라고 표현한다. 다시 말하면, 콜렉션이 수행될 때 애플리케이션 수행이 정지된다.

• 가장 단순한 방식의 GC로 싱글 스레드(스레드 1개)로 동작한다.
• 싱글 스레드로 동작하여 느리고, 그만큼 Stop The World 시간이 다른 GC에 비해 길다.
• Mark & Sweep & Compact 알고리즘을 사용
• 보통 실무에서 사용하는 경우는 없음 (디바이스 성능이 안좋아서 CPU 코어가 1개인 경우에만 사용)

1. 일단 살아있는 객체들은 Eden 영역에 있다.
2. Eden 영역이 꽉차게 되면 To Survivor 영역(비어있는 영역)으로 살아 있는 객체가 이동한다. 이때 Survivor 영역에 들어가기에 너무 큰 객체는 바로 Old 영역으로 이동한다. 그리고 From Survivor 영역에 있는 살아 있는 객체는 To Survivor 영역으로 이동한다.
3. To Survivor 영역이 꽉 찼을 경우, Eden 영역이나 From Survivor 영역에 남아 있는 객체들은 Old 영역으로 이동합니다.

이 이후에 Old 영역이나 Perm 영역에 있는 객체들은 Mark-sweep-compact 콜렉션 알고리즘을 따른다. 이 알고리즘에 대해서 간단하게 말하면, 안 쓰는 거 표시해서 삭제하고 한 곳으로 모으는 알고리즘이다.

Mark-sweep-compact 알고리즘

1) Old 영역으로 이동된 객체들 중 **살아 있는 개체를 식별**한다. (Mark)
2) Old 영역의 객체들을 훑는 작업을 수행하여 **쓰레기 객체를 식별**한다. (Sweep)
3) 필요 없는 객체들을 **지우고** 살아 있는 **객체들을 한 곳으로 모은다**. (Compact)

이렇게 작동하는 시리얼 콜렉터는 일반적으로 클라이언트 종류의 장비에서 많이 사용된다. 다시 말하면, 대기 시간이 많아도 크게 문제되지 않는 시스템에서 사용된다.

명시적 지정 방법

UseSerialGC

2. Parallel GC

이 방식은 throughput collector로도 알려진 방식이다. 이 방식의 목표는 다른 CPU가 대기 상태로 남아 있는 것을 최소화하는 것이다.

시리얼 콜렉터와 달리 Young 영역에서의 콜렉션을 병렬(Parallel)로 처리한다. 많은 CPU 를 사용하기 때문에 GC의 부하를 줄이고 애플리케이션의 처리량을 증가시킬 수 있다.

• Java 8의 default GC
• Young 영역의 GC를 멀티 스레드 방식을 사용하기 때문에, Serial GC에 비해 상대적으로 Stop The World 가 짧다
  • Old 영역은 아님
  • Old 영역의 GC는 시리얼 콜렉터와 마찬가지로 Mark-Sweep-Compact 콜렉션 알고리즘을 사용한다.

명시적 지정 방법

UseParallelGC

3. Parallel Compacting GC

병렬 콜렉터와 다른 점은 Old 영역 GC에서 새로운 알고리즘을 사용한다.

• Parallel GC는 Young 영역에 대해서만 멀티 스레드 방식을 사용했다면, Parallel Old GC는 Old영역까지 멀티스레드 방식을 사용

그러므로 Young 영역에 대한 GC는 병렬 콜렉터와 동일하지만, Old 영역의 GC는 다음의 3단계를 거치게 된다.

1. Mark 단계 : 살아 있는 객체를 식별하여 표시해 놓는 단계
2. Sweep 단계 : 이전에 GC를 수행하여 컴팩션된 영역에 살아 있는 객체의 위치를 조사하는 단계
3. Compact 단계 : 컴팩션을 수행하는 단계. 수행 이후에는 컴팩션된 영역과 비어 있는 영역으로 나뉩니다.

병렬 콜렉터와 동일하게 이 방식도 여러 CPU를 사용하는 서버에 적합하다. GC를 사용하는 스레드 개수는 -XX:+ParallelGCThreads=n 옵션으로 지정할 수 있다.

명시적 지정방법

UseParallelOldGC

ParallelGCThreads=n

4. Concurrent Mark-Sweep GC

Stop The World로 Java Application이 멈추는 현상을 줄이고자 만든 GCReacable 한 객체를 한번에 찾지 않고 나눠서 찾는 방식을 사용 (4 STEP)

이 방식은 low-latency collector로도 알려져 있으며, 힙 메모리 영역의 크기가 클 때 적합하다. Young 영역에 대한 GC는 병렬 콜렉터와 동일합니다. Old 영역의 GC는 다음 4단계를 거친다.

1. Initial Mark : GC Root가 참조하는 객체만 마킹 (stop-the-world 발생)
   • 살아 있는 객체를 찾는 단계
2. Concurrent Mark : 참조하는 객체를 따라가며, 지속적으로 마킹. (stop-the-world 없이 이루어짐)
   • 서버 수행과 동시에 살아 있는 객체에 표시를 해놓는 단계
3. Remark : concurrent mark 과정에서 이 없는지 다시 한번 마킹하며 확정하는 과정. (stop-the-world 발생)
   변경된 사항
4. Concurrent Sweep : 접근할 수 없는 객체를 제거하는 과정 (stop-the-world 없이 이루어짐)

위와 같이 stop-the-world가 최대한 덜 발생하도록 하여, Java Application이 멈추는 현상을 줄인다.

CMS는 컴팩션 단계를 거치지 않기 때문에 왼쪽으로 메모리를 몰아 놓는 작업을 수행하지 않는다. 그래서 GC 이후에 그림과 같이 빈 공간이 발생하므로, -XX:+CMSInitiatingOccupancyFraction=n 옵션을 사용하여 Old 영역의 %를 n 값에 지정합니다. (기본값 : 68)

CMS 콜렉터는 추가적인 옵션으로 점진적 방식을 지원한다. 이 방식은 Young 영역의 GC를 더 잘게 쪼개어 서버의 대기 시간을 줄일 수 있다. CPU가 많지 않고 시스템의 대기 시간이 짧아야 할 때 사용하면 좋다.점진적은 GC를 수행하려면 -XX:+CMSIncrementalMode 옵션을 지정하면 된다. JVM에 따라서는 -Xingc라는 옵션을 지정해도 같은 의미가 된다. 하지만 이 옵션을 지정할 경우 예기치 못한 성능 저하가 발생할 수 있으므로, 충분한 테스트를 한 후에 운영 서버에 적용해야 한다.

CMS GC는 2개 이상의 프로세서를 사용하는 서버에 적당하다. 가장 적당한 대상으로는 웹 서버가 있다.

명시적 지정방법

UseConcMarkSweepGC

CMSInitiatingOccupancyFraction=n

CMSIncrementalMode

CMS GC는 Java9 버젼부터 deprecated 되었고 결국 Java14에서는 사용이 중지되었다.

5. G1 GC

• Java 9 부터 default GC
• 현재 GC 중 stop-the-world의 시간이 제일 짧음
• 어떠한 GC 방식보다 처리 속도가 빠르며 큰 메모리 공간에서 멀티 프로레스 기반으로 운영되는 애플리케이션을 위해 고안되었다. 또한 G1 GC는 다른 GC 방식의 처리속도를 능가한다.
• CMS GC 를 개선하여 만든 GC로 위에서 살펴본 GC와는 다른 구조를 가진다.

• Heap을 Region이라는 일정한 부분으로 나눠서 메모리를 관리한다.
  • 기존 GC처럼 물리적인 영역으로 나누지 않고, Region(지역)이라는 개념을 새로 도입하여 Heap을 균등하게 여러 개의 지역으로 나누고, 각 지역을 역할과 함께 논리적으로 구분하여(Eden 지역인지, Survivor 지역인지, Old 지역인지) 객체를 할당한다.
• G1 GC에서는 Eden, Survivor, Old 역할에 더해 Humongous와 Availalbe/Unused라는 2가지 역할을 추가하였다. Humongous는 Region 크기의 50%를 초과하는 객체를 저장하는 Region을 의미하며, Availabe/Unused는 사용되지 않은 Region을 의미한다.
• G1 GC의 핵심은 전체 Heap에 대해서 탐색하지 않고 부분적으로 Region 단위로 탐색하여, 가비지가 많은 Region에만 우선적으로 GC를 수행하는 것이다.
• G1 GC도 다른 가비지 컬렉션과 마찬가지로 2가지 GC(Minor GC, Major GC)로 나누어 수행된다.

1. Minor GC

한 지역에 객체를 할당하다가 해당 지역이 꽉 차면 다른 지역에 객체를 할당하고, Minor GC가 실행된다. G1 GC는 각 지역을 추적하고 있기 때문에, 가비지가 가장 많은(Garbage First) 지역을 찾아서 Mark and Sweep를 수행한다.

Eden 지역에서 GC가 수행되면 살아남은 객체를 식별(Mark)하고, 메모리를 회수(Sweep)한다. 그리고 살아남은 객체를 다른 지역으로 이동시키게 된다. 복제되는 지역이 Available/Unused 지역이면 해당 지역은 이제 Survivor 영역이 되고, Eden 영역은 Available/Unused 지역이 된다.

2. Major GC(Full GC)

시스템이 계속 운영되다가 객체가 너무 많아 빠르게 메모리를 회수 할 수 없을 때 Major GC(Full GC)가 실행된다. 그리고 여기서 G1 GC와 다른 GC의 차이점이 두각을 보인다.

기존의 다른 GC 알고리즘은 모든 Heap의 영역에서 GC가 수행되었으며, 그에 따라 처리 시간이 상당히 오래 걸렸다. 하지만 G1 GC는 어느 영역에 가비지가 많은지를 알고 있기 때문에 GC를 수행할 지역을 조합하여 해당 지역에 대해서만 GC를 수행한다. 그리고 이러한 작업은 Concurrent하게 수행되기 때문에 애플리케이션의 지연도 최소화할 수 있는 것이다.

물론 G1 GC는 다른 GC 방식에 비해 잦게 호출될 것이다. 하지만 작은 규모의 메모리 정리 작업이고 Concurrent하게 수행되기 때문이 지연이 크지 않으며, 가비지가 많은 지역에 대해 정리를 하므로 훨씬 효율적이다.

명시적 지정방법

UseG1GC

GC 방식 비교

네 종류 GC 방식에 대한 성능 및 기능 비교 표

위의 내용을 종합하면, GC 수행 시점은 다음과 같다.

1. 각 영역의 할당된 크기의 메모리가 허용치를 넘을 때
2. 개발자가 컨트롤할 영역은 아님

개발자라면, 자바의 GC 방식을 외우면서 개발하거나 서버를 세팅할 필요는 없다. 이해만 하고 있으면 된다. 단, 필요할때(시스템 오픈 전 성능 테스트 / 서버 세팅 시), 알맞은 GC 방식을 개발한 시스템에 적용하면 된다고 한다.

참고

• https://12bme.tistory.com/57
• https://memostack.tistory.com/229
• https://mangkyu.tistory.com/119

https://dar0m.tistory.com/261

Modules

모듈은 하나 이상의 패키지를 갖는다. 모듈은 full Java app일 수도, a Java Platform API일 수도 또는 a third party API일 수도 있다.

Modules Benefits

1.** 군더더기를 제거함으로써 애플리케이션이 알맞은 덩치를 갖게 한다.
프로젝트 Jigsaw(JPMS = Java Platform Module System = Java Jigsaw = Project Jigsaw)의 일환으로 모든 Java Platform API는 별도의 모듈들로 쪼개졌다. 이로써 자신의 어플리케이션에서 필요한(실제로 사용할) 모듈들만 명시할 수 있게(가질 수 있게) 되었다.

JPMS가 없는 Java 9 이전에는 모든 Java Platform API들을 애플리케이션에 패키징해야 했다. 왜냐하면 어플리케이션에서 어떤 클래스를 사용하는지를 확실하게 확인할 공식적인 방법이 없었기 때문이다. 이 때문에 애플리케이션은 불필요하게 크기가 커졌다(사용하지 않는 클래스가 포함되기 때문이다). 이는 모바일 폰이나 라즈베리 파이 같은 작은 기기에서 문제가 될 수 있다. JPMS는 이 문제를 해결한다.

2. 패키지 캡슐화를 가능하게 한다. 자바 모듈은 반드시 모듈(A)의 어떤 자바 패키지가 다른 모듈(A를 사용하는 모듈 B)로 exported 될지 (visible 할지) 명시해야만 한다. 다시 말해 공개할 패키지를 명시해야 하고, 명시되지 않은 패키지는 다른 모듈에서 사용할 수 없는 패키지가 된다. 이를 hidden packages 또는 encapsulated packages라 한다. 이는 그 패키지를 갖는 모듈 내부적으로만 사용된다.

3. 필요한 모듈이 있는지 없는지를 JVM start-up 타임에 검사한다. Java 9 이후부터 자바 애플리케이션은 반드시 자바 모듈로 패키징 되어야 한다. 그러므로 어플리케이션 모듈은 자신이 사용할 다른 모듈(Java API module이나 third party module)을 명시해야 한다. JVM이 구동될 때 JVM은 애플리케이션 모듈로부터 모듈 dependency graph를 확인하여 이 애플리케이션에서 어떤 모듈을 필요로 하는지 알 수 있다. 다음으로 필요한 모듈들이 있는지를 확인하는데 만약 필요한 모듈을 못 찾으면 JVM은 missing module을 report하고 종료된다.

Java 9 이전에는 missing classes(e.g. from a missing JAR file)은 애플리케이션이 실제로 그 missing class 를 사용하려고 시도할 때서야(즉, 런타임의 특정 시점에서야) 비로소 missing임을 알 수 있었다.

missing modules를 어플리케이션 startup time에 report 받는 것은 런타임에 받는 것에 비해 매우 큰 이점을 갖는다.

Module Basics

Module name

모듈의 이름은 unique 해야 한다. 모듈 이름 규칙은 패키지 이름 규칙과 같다. 하지만 ‘’는 자바 9 이후부터 모듈이든 패키지든 클래스든 메소드든 변수든 안 쓰는 게 좋다. Java가 나중에 ‘’를 사용하고 싶어 하기 때문이다. 가능하면 모듈 이름을 모듈 속 루트 자바 패키지의 이름과 같게 하는 것이 좋다.

Directory structure Java 9부터 directory structure는 아래와 같다.

com.module.study
  -com
    -module
      -study

모듈의 root directory 이름(com.module.study)에 ‘.’는 패키지를 구분짓기 위한 용도가 아니라 그 자체로 모듈의 이름이다.

Module Descriptor(module-info.java)

자바 모듈마다 module-info.java(‘-’는 원래 자바 클래스 이름으로 불가능)를 가져야 한다. 위치는 그 모듈의 루트 디렉토리이다. 모듈 디스크립터는 이 모듈의 어떤 패키지를 export 하고 이 모듈을 위해 어떤 다른 모듈이 필요한지(requires)를 명시한다.

module com.modules.example {  

	exports com.modules.example; // 하위 패키지 포함 안되고 example 하위에 있는 것만
  exports com.modules.example.a.b; // 부모 패키지(a) export 안 하고 export 가능
  requires com.other.modules; // 필요한 모듈 명시하는 방법

}

모듈 디스크립터를 작성하는 방법은 위와 같이 'module'이라는 키워드 뒤에 모듈 이름을 적고 클래스를 작성하듯 중괄호로 안에 exports, requires 내용을 적으면 된다. 주의해야 할 점은 어떤 패키지를 exports 했다고 해서 그 패키지의 모든 하위 패키지까지 exports 되는 것은 아니라는 것이다. 또한 모듈 간에 순환 의존 관계를 가질 수 없다. a 패키지가 b 패키지를 requires 하면 b 패키지는 a 패키지를 requires 할 수 없다.

Split Packages

module test.module1 {
  exports abc.pqr.xyz;
}

module test.module2 {
  exports abc.pqr.xyz;
}

module test.myapp {
	requires test.module1;

  requires test.module2;
}

myapp에서 module1과 module2를 요구하는데 module1과 module2는 같은 패키지를 export 하고 있는 상황이다. 이럴 때 abc.pqr.xyz를 split packages라 한다. 이는 허락되지 않는다.

https://stackoverflow.com/questions/51828014/how-split-packages-are-avoided-in-java-9

참고 http://tutorials.jenkov.com/java/modules.html