

조사에 따르면 현재 조직의 약 97%가 Public Cloud를 사용하고 있으며 약 83%의 회사 업무가 이제 클라우드 인프라로 전환되었습니다. 새로운 방식을 채택하는 조직 수가 증가함에 따라 응용 프로그램을 저장하고 배포하는 공격 및 악성 코드도 늘어나고 있습니다. 배포 또는 환경 설정 시 작은 구성 오류가 발생하면 막대한 데이터 손실이 발생할 수 있습니다.

Kubernetes는 가장 많이 사용되는 신뢰할 수 있는 Orchestration Tool로 개발자들에게 익숙한 이름이며, 서비스 중심 응용 프로그램 인프라의 여러 측면을 간소화합니다. API 서버는 Kubernetes 제어 평면의 핵심으로 모든 자원을 유효성 검사합니다. 클라이언트로부터 보내진 모든 요청은 먼저 API 서버로 전송되며, 인증을 거쳐 CRUD(생성, 읽기, 업데이트, 삭제) 작업이 허용됩니다. 따라서 API 서버로 들어오는 이러한 요청을 필터링할 수 있다면 클러스터를 거의 완전히 보호할 수 있습니다. API 서버가 클러스터의 게이트웨이로 불리기 때문입니다.

이 글에서는 Role Back Access Control (RBAC)을 사용하여 EKS 클러스터를 어떻게 보호할 수 있는지에 대해 알아보겠습니다. RBAC은 사용자가 Kubernetes 자원에 어떤 것에 액세스하고 어디에서 액세스할 수 있는지를 검증하는 사용 권한 단계입니다.

먼저, Amazon Elastic Kubernetes Service(EKS)가 무엇인지 알아보겠습니다.

<div class="content-ad"></div>

## Amazon Elastic Kubernetes Service 및 그 기능?

Amazon Elastic Kubernetes Service(EKS)는 온프레미스 및 AWS에서 Kubernetes를 실행할 수 있는 관리형 Kubernetes 서비스입니다. Amazon EKS를 사용하면 스케일링, 신뢰성, EKS 애드온, AWS 인프라의 고가용성, 그리고 IAM과의 AWS 보안 통합을 자동으로 관리할 수 있습니다. 또한 IAM과의 클러스터 관리, 롤백 액세스 제어(RBAC), AWS Virtual Private Cloud(VPC)와의 통합도 가능합니다.

EKS는 Kubernetes 제어 평면의 내구성을 유지하기 위해 다중 가용 영역에 걸쳐 복제함으로써 가용성을 보장합니다. Kubernetes 커뮤니티의 일부 플러그인을 사용하여 EKS는 기존 애플리케이션과 완전히 호환되는 통합을 제공합니다. Amazon EKS의 여러 이점 중 하나인 AWS IAM과 RBAC의 통합은 클러스터 내 사용자의 이동을 제어하여 클러스터에 대한 제로 트러스트 보안 접근 방식을 구현하는 데 중요한 보안 요소입니다.

## 롤백 액세스 제어를 사용한 권한 부여

<div class="content-ad"></div>

Kubernetes에서는 권한 부여가 최소 권한 제공 규칙을 따릅니다. 즉, 모든 계정이 완전한 액세스를 부여받는 것이 아니라 특정 네임스페이스 내에서 제한된 액세스를 부여받아야 합니다. 각 사용자에 대한 작업에 대한 정책과 규칙이 만들어집니다. 기본적으로 클러스터를 만든 사람에게 관리자 권한이 주어집니다. 사용자는 이동 및 업무에 대한 그룹 기반 역할 또는 개별 역할이 할당될 수 있으며, 이러한 역할들은 각 사용자에게 바인딩됩니다. 이를 역할 바인딩이라고 합니다.

RBAC 권한 부여는 rbac.authorization.k8s.io API 그룹을 사용하여 권한 부여 결정을 내립니다. AWS는 aws-iam-authenticator를 사용하여 Amazon EKS Kubernetes 환경의 일반 사용자를 사용하도록 외부 서비스 기능을 제공합니다. 이를 위해 IAM 자격 증명을 사용하여 클러스터에 인증 레이어를 제공합니다. 이는 Kubernetes 특별 위원회(SIG)에서 유지 관리하며, 웹훅 서비스는 aws-auth ConfigMap을 확인하여 IAM 신원이 클러스터 사용자와 일치하는지 확인합니다. 서비스 계정은 Kubernetes에서 관리되며, 일부에 바운드되어 있으며, 클러스터 생성 중에 생성됩니다. Amazon EKS는 토큰 인증 웹훅을 사용하여 요청을 인증하지만 최종 결정은 권한 부여를 위해 RBAC에 의해 이루어집니다.

RBAC를 사용하여 만들 수 있는 일부 역할은 다음과 같습니다:

- 클러스터 역할: 이러한 규칙은 클러스터 수준에서 적용됩니다. 즉, 기본적으로 네임스페이스가 설정되지 않습니다.

<div class="content-ad"></div>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: Power-User
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
```

2. Roles: Roles are specified a particular namespace and wrt to the policies it is assigned to Users. These are namespace specific Roles.

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: namespace1
  name: User-space1
rules:
- apiGroups: [""]
  resources: ["pods" , "services"]
  verbs: ["get", "watch", "list"]
```

Roles then Bind to in different aspects, Role Binding is grant of Roles to users at namespace level whereas Cluster Binding grants access cluster wide. Role Binding can even reference a Cluster Role and Bind that to the namespace of Role Binding.

<div class="content-ad"></div>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pods-using
subjects:
- kind: Group
  name: Lead
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: Power-User
  apiGroup: rbac.authorization.k8s.io
```

## 아마존 EKS에서 이렇게 할 수 있어요:

IAM과 RBAC 사이의 통합 방법은 aws-auth-ConfigMap입니다. 이는 IAM 원칙(역할/사용자)과 Kubernetes(사용자/그룹)의 권한을 사용하여 클라이언트에 액세스 권한을 부여하는 완전한 인증 및 권한 부여 단계를 정의합니다.

- 네임스페이스 생성하기


<div class="content-ad"></div>

Namespace은 쿠버네티스 클러스터 안에 있는 가상 클러스터라고 생각할 수 있어요. 하나의 쿠버네티스 클러스터 안에 여러 개의 네임스페이스를 가질 수 있고, 서로 논리적으로 격리되어 있어요. 네임스페이스는 조직, 보안 및 성능에 도움을 줄 수 있어요!

```js
kubectl create namespace DemoNamespace

kubectl run --generator=run-pod/v1 nginx --image=nginx -n DemoNamespace
```

- IAM에서 사용자 만들기:

AWS는 사용자의 자원 접근을 제어하여 사용자에게 저렴한 고수준의 데이터 보안을 제공해요. 여기서는 IAM을 통합하므로 구성을 시작하는 데 필수인 사용자(유저)를 생성할 거예요. 우리는 Tony라는 사용자를 생성하고 tony.sh 스크립트를 사용해서 만들 거에요.

<div class="content-ad"></div>

```js
IAM_USER=Tony
aws iam create-user --user-name $IAM_USER

cat << EoF > $IAM_USER.sh
export AWS_SECRET_ACCESS_KEY=$(aws iam create-access-key --user-name $IAM_USER \
 --query AccessKey.[SecretAccessKey] --output text)
export AWS_ACCESS_KEY_ID=$(aws iam list-access-keys --user-name $IAM_USER \
 --query AccessKeyMetadata[0].AccessKeyId --output text)
EoF
```

- 클러스터에 사용자 매핑:

ConfigMaps를 사용하면 구성을 Pod 및 구성 요소와 분리할 수 있어서 Workload를 이동하기 쉽게 유지할 수 있습니다. kubectl edit configmap/aws-auth -n kube system을 사용하여 사용자를 configmap에 추가하고 사용자 섹션에 매핑하십시오.

```js
apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::<YOUR_AWS_ACCOUNT_NO>:role/InstanceRole-us-west-1-workers_asg1
      username: system:node:{EC2PrivateDNSName}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |  <-- 이 섹션을 추가하세요
    - userarn: arn:aws:iam::<AWS ACCOUNT NO>:user/jack
      username: jack
kind: ConfigMap
metadata:
  creationTimestamp: "2022-3-23T14:23:54Z"
  name: aws-sample
  namespace: DemoNamespace
```

<div class="content-ad"></div>

커스텀 롤 생성: Role Binding에서 언급한 바와 같이, 동일한 방식으로 권한을 갖게 되는 역할을 생성할 것입니다. 이 역할은 정의된 네임스페이스에서 'get', 'watch', 'list' 권한을 갖게 될 것입니다.

```yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: DemoNamespace
  name: pod-User
rules:
- apiGroups: [""] 
  resources: ["pods"]
  verbs: ["list", "get"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
EOF
```

이러한 YAML 파일은 다음과 같이 적용됩니다:

kubectl apply -f `YAML_FILE_NAME.YML` (모든 YAML 파일이 이 명령어로 적용됩니다).

<div class="content-ad"></div>

Role Binding 작업 중입니다. Role Binding은 클러스터 내에서 사용자에게 권한을 부여하기 위해 역할을 사용자에게 바인딩하는 개념입니다. 

```js
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-User
  namespace: DemoNamespace
subjects:
- kind: User
  name: Tony
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-User
  apiGroup: rbac.authorization.k8s.io
kubectl apply -f <YAML_FILE_NAME.YML>
```

이제 환경이 모두 구성되었습니다. 설정을 테스트할 시간입니다.

```js
name: pod-User
  apiGroup: rbac.authorization.k8s.io
```

<div class="content-ad"></div>

```js
source tony.sh # 스크립트를 테스트하기 위해 사용
Kubectl get pods # 안돼요! 작동하지 않습니다. 이 사용자는 DemoNamespace 레벨만 보유하고 있어요
kubectl get pods -n DemoNamespace # 와우! 이건 작동할 거에요
kubectl create configmap my-config --from-file=path/to/bar # configmap에 대해 심지어 create 동사가 허용되지 않아 작동하지 않아요.
Kubectl delete deployment/nginx -n DemoNamespace # 이건 작동할 거에요
```

위에서 보여준 것처럼, 이러한 테스트 케이스들은 당신이 설정한 구성과 바인딩을 테스트하는 데 도움이 될 거에요.

## 결론

이 글에서 우리는 Amazon EKS에서 Role Based Access Control의 중요성과 그것을 어떻게 달성할 수 있는지에 대해 논의했어요. RBAC를 사용하여 권한을 부여하는 것은 Zero Trust Security Model을 구현하는 가장 좋은 방법 중 하나로 간주되며, RBAC는 핵심 보안 중 하나로 여겨지지만 설정에 완전히 의존하며, 사람들은 부정확한 설정을 만들어 클러스터 보안에 흠결을 초래하여 데이터 침해로 이어질 수 있어요.


<div class="content-ad"></div>

DevOps 도구에 대해 더 알고 싶다면 제 Terraform, ArgoCD, 그리고 Ansible 가이드를 확인해보세요!

영어 제목 Securing Your EKS Cluster with RBAC Implementing Zero Trust Security Using Role-Based Access Control in Amazon EKS한글 제목 Amazon EKS에서 RBAC를 활용한 제로 트러스트 보안 구현하기 클러스터 보안 강화 방법



<img src="/assets/img/2024-09-10-BlockPublicAccesstotheS3bucket_0.png" />

## 소개

Amazon Simple Storage Service (AWS S3)는 어떤 크기의 데이터든 저장하고 얻는 데 강력하고 잘 알려진 도구입니다. 사용하기 쉽고 필요에 따라 성장할 수 있으며 빠르게 작동하기 때문에 다양한 종류의 데이터 저장 작업에 인기가 있습니다. 그러나 너무 유연하기 때문에 거기에 보관된 데이터가 안전한지 확인하는 것은 매우 중요한 문제가 됩니다.

많은 기업이 S3 버킷을 충분히 보호하지 못하고 노력하는 것을 목격해 왔습니다. 이는 종종 몇 가지 기본 규칙을 무시하기 때문입니다. 이 게시물에서는 S3 보안의 복잡성을 탐구하고 강화하는 방법에 대한 포괄적인 안내서를 제공하려고 합니다.

<div class="content-ad"></div>

S3는 다른 AWS 서비스와 비교했을 때 권한 부여에 대해 독자적인 스타일을 가지고 있어요. 여러 서비스에서는 사용자나 역할에 대한 올바른 권한만 설정하면 괜찮은 경우가 많지만, S3는 자체 규칙에 따라 움직이죠. S3가 누가 어떤 것을 볼 수 있는지를 결정하며, 이것은 보안 측면에서 엄격한 보안수칙을 가지고 있음을 의미해요. 하지만, 한 가지 주의할 점이 있어요. 이 유연성은 때로는 너무 많은 접근을 실수로 허용하거나, 미친듯이 버킷을 공개하고 말 수도 있죠. 따라서, S3의 권한 처리 방식은 것을 잠그는 데 유용하지만, 실수를 피하기 위해서 신중한 눈초리가 필요하다는 것을 명심해야 해요.

몇 가지 예시로 살펴보겠어요. 첫 번째 예시에서는, S3 규칙이 사용자에게 특정 권한을 부여합니다 — 아주 표준적인 내용이에요.

```js
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/DummyUser"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}
```

그리고 두 번째 예시에서는, * 와일드카드를 추가하기만 하면, 누구나 S3에 대해 완전한 액세스 권한을 획득할 수 있어요. 이건 정말 무서운 일이죠.

<div class="content-ad"></div>

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:user/DummyUser",
                    "*"
                ]
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}
```

그리고 알아두세요, 때로는 사람들이 두 번째 예시처럼 실수로 문을 완전히 열어두곤 합니다, 아마 뭔가 빨리 해내기 위해서 그랬던 것일지도 몰라요. 그러나 그게 실수였든 의도적이었든 간에, 저희는 우리 데이터를 안전하고 건전하게 유지하기 위해 그것을 막아야 합니다.'

## 장벽 설정하기

AWS는 S3에서 당신의 것을 개인적으로 유지할 수 있게 해 주는 네 가지 간단하면서도 강력한 설정을 제공합니다. 플립.


<div class="content-ad"></div>

BlockPublicAcls: true

- 문 앞에 경비원이 있어요. 새 권한이 지나가지 못하도록 막아줘서 게이트 크래셔를 막아줘요.

BlockPublicPolicy: true

- 이 설정은 VIP 명단 같아요. 누군가가 일반 통행증을 가지고 있어도, 이 설정은 버킷 정책을 변경할 VIP 상태를 가지고 있는 지 확인해요. VIP 상태가 없으면 입장 불가능해요!

<div class="content-ad"></div>


IgnorePublicAcls: true

- Imagine if someone from the crowd shouts, “I have a pass!” This setting ensures that any public access passes are ignored, keeping the control in your hands.

RestrictPublicBuckets: true

- This one is like a curtain around your private party. Even if someone tries to peek in, they won’t see anything unless you’ve given them a special invite.


<div class="content-ad"></div>

올바른 권한(허가)을 가진 사람들만 출입하거나 변경할 수 있어요.

# 공개 액세스 차단하기

여기서는 S3 버킷의 공개 액세스를 차단하는 3가지 다른 방법에 대해 이야기할 거예요.

## CloudFormation

<div class="content-ad"></div>

S3 버킷을 생성하고 공개 액세스를 차단하는 작업은 AWS CloudFormation을 이용하여 간편하게 수행할 수 있습니다.

아래는 S3 버킷을 생성하고 공개 액세스를 차단하는 간단한 CloudFormation 템플릿 예제입니다:

```js
Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties: 
      BucketName: "example-bucket-name"  # 고유한 버킷 이름으로 교체하세요
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  PublicAccessBlock:
    Type: AWS::S3::BucketPolicy
    Properties: 
      Bucket: !Ref MyS3Bucket
      PolicyDocument:
        Id: DenyAll
        Version: "2012-10-17"
        Statement:
          - Sid: DenyAll
            Effect: Deny
            Principal: "*"
            Action: "s3:*"
            Resource:
              - !Sub "${MyS3Bucket.Arn}"
              - !Sub "${MyS3Bucket.Arn}/*"
```

설명:

<div class="content-ad"></div>

- 자원(Resource): 이 템플릿의 주요 섹션으로, 우리가 생성하거나 관리하려는 AWS 자원을 정의합니다.
- MyS3Bucket: 이는 우리의 CloudFormation 템플릿 내에서 S3 버킷 자원의 논리적 이름입니다.
- 유형(Type): 생성하려는 AWS 자원의 유형을 지정합니다. 이 경우에는 S3 버킷입니다.
- 속성(Properties): 우리가 생성하는 S3 버킷의 속성을 포함하는 섹션입니다.
- BucketName: 이 속성은 S3 버킷의 이름을 지정합니다. "example-bucket-name"을 여러분의 고유한 버킷 이름으로 바꿔주세요.
- PublicAccessBlockConfiguration: 이 섹션에는 S3 버킷의 공개 액세스 차단 구성을 포함합니다.
- BlockPublicAcls, BlockPublicPolicy, IgnorePublicAcls, RestrictPublicBuckets: 이러한 속성들은 모두 공개 액세스가 모든 측면에서 차단되도록 true로 설정됩니다.
- PublicAccessBlock: 이는 버킷 정책으로 버킷에 대한 공개 액세스 없음을 보장합니다. 공개 액세스 규칙을 강제하는 추가적인 조치입니다.
- BucketPolicy: 이 섹션은 S3 버킷에서 모든 주체(Principal: "*")에 대해 모든 작업(s3:*)을 거부하는 정책 문서를 정의하며, 이를 통해 버킷에 대한 모든 공개 액세스가 차단됩니다.

"example-bucket-name"을 여러분의 고유한 버킷 이름으로 교체해주세요. 이 템플릿을 CloudFormation을 통해 실행하면 구성된대로 공개 액세스가 차단된 S3 버킷이 생성됩니다.

## AWS CDK

AWS CDK를 사용하여 TypeScript에서 S3 버킷을 생성하고 공개 액세스를 차단하는 것은 간단합니다. AWS CDK는 클라우드 인프라를 코드로 정의하고 AWS CloudFormation을 통해 제공하는 소프트웨어 개발 프레임워크입니다.

<div class="content-ad"></div>

여기에서는 어떻게 할 수 있는지 안내드리겠습니다:

```js
// 필요한 AWS CDK 패키지를 가져옵니다
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

// 새로운 Stack 클래스를 정의합니다
class MyS3Stack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 공개 액세스가 차단된 새로운 S3 버킷을 생성합니다
    new s3.Bucket(this, 'MyS3Bucket', {
      bucketName: 'example-bucket-name',  // 고유한 버킷 이름으로 대체하세요
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,  // 모든 공개 액세스를 차단합니다
    });
  }
}

// 앱과 스택을 인스턴스화합니다
const app = new cdk.App();
new MyS3Stack(app, 'MyS3Stack');
```

설명:

- 패키지 가져오기: 파일의 시작 부분에서 필요한 AWS CDK 패키지를 가져옵니다.
- Stack 정의: cdk.Stack를 확장하는 MyS3Stack 클래스를 생성합니다. 생성자 메서드는 AWS 리소스를 정의하는 곳입니다.
- S3 버킷 생성: 생성자 내부에서 s3.Bucket 생성자를 사용하여 새로운 S3 버킷을 생성합니다.
- 버킷 이름: bucketName 속성을 사용하여 버킷에 이름을 지정합니다. `example-bucket-name`을 고유한 버킷 이름으로 대체하세요.
- 공개 액세스 차단: blockPublicAccess 속성을 사용하여 S3 버킷에 대한 모든 공개 액세스를 차단합니다. 속성 값을 s3.BlockPublicAccess.BLOCK_ALL로 설정합니다.
- 앱 및 스택 인스턴스화: 마지막으로 cdk.App 클래스의 새 인스턴스 및 MyS3Stack 클래스의 새 인스턴스를 생성하여 배포 시 AWS 리소스를 정의하고 생성할 것입니다.

<div class="content-ad"></div>

이 스택을 배포하려면 코드를 파일에 저장하십시오 (예: MyS3Stack.ts), 터미널에서 이 파일이 있는 디렉토리로 이동한 다음 다음 명령을 실행하십시오:

```js
cdk deploy
```

이 명령은 CDK 앱을 컴파일하고 배포하여 스택에서 지정한대로 공개 액세스가 차단된 S3 버킷을 생성합니다.

## AWS 콘솔:

<div class="content-ad"></div>

- AWS 콘솔에 접속하세요.

- AWS 관리 콘솔에 로그인하세요.

2. S3으로 이동

- "서비스" 메뉴에서 S3 서비스로 이동하세요.

<div class="content-ad"></div>

3. 버킷 선택하기

- S3 대시보드에서 구성하려는 버킷 이름을 클릭하세요.

4. 액세스 권한 탭

- "권한" 탭을 찾아 클릭하세요.

<div class="content-ad"></div>

5. 공개 액세스 차단 설정

- "공개 액세스 차단" 섹션에서 "편집" 버튼을 클릭합니다.

6. 설정 구성

![이미지](/assets/img/2024-09-10-BlockPublicAccesstotheS3bucket_1.png)

<div class="content-ad"></div>


![이미지](/assets/img/2024-09-10-BlockPublicAccesstotheS3bucket_2.png)

- 새로운 액세스 제어 목록(ACL)을 통해 부여된 버킷과 객체에 대한 공개 액세스 차단
- 어떠한 액세스 제어 목록(ACL)을 통해 부여된 버킷과 객체에 대한 공개 액세스 차단
- 새로운 공용 버킷 또는 액세스 포인트 정책을 통해 부여된 버킷과 객체에 대한 공개 액세스 차단
- 어떠한 공용 버킷 또는 액세스 포인트 정책을 통해 부여된 버킷과 객체에 대한 공개 및 교차 계정 액세스 차단
- 모든 네 개의 상자를 선택하여 모든 공개 액세스를 차단합니다.

7. 변경사항 저장

- 상자를 모두 확인한 후 아래로 스크롤하여 “변경사항 저장” 버튼을 클릭하세요.
- 확인 팝업이 나타나면 “확인”이라고 입력한 다음 변경 사항을 적용하려면 “확인” 버튼을 클릭하세요.


S3 버킷 공개 액세스 차단하는 방법

아마존 베드락, 오픈서치 및 오픈클립을 활용한 이미지 식별과 분류



클라우드워치 이벤트에서 유래한 아마존 웹 서비스(AWS)는 2019년 7월에 이벤트 기반 아키텍처를 위한 서버리스 오퍼링인 이벤트브릿지를 출시했습니다. 이제 이벤트브릿지는 여러 구성 요소로 구성되어 있습니다:

- 이벤트 프로듀서와 컨슈머를 통합하는 룰이 있는 버스(브로커).
- 일회성 또는 반복적인 작업의 완전 관리된 호출을 위한 스케줄링.
- 프로듀서와 컨슈머 간의 관리되는 통합을 제공하는 파이프.

이벤트브릿지가 어떻게 작동하는지 설명하는 온라인 자료가 많이 있습니다. 제품 문서는 유용한 시작점 역할을 합니다. 이 게시물에서는 특히 이벤트브릿지 룰의 모니터링에 대해 자세히 살펴보겠습니다.

![이미지](/assets/img/2024-09-10-MonitoringAmazonEventBridgeRules_0.png)

<div class="content-ad"></div>

우리는 메트릭이 어떻게 작동하는지에 대한 개요로 시작하고, 그 후에 현재 Rule 메트릭 제공 사항을 탐색하고 그 한계를 확인할 것입니다. Rule 메트릭을 넓은 범위로 다룬 후에는 고객에게 추가 가치를 제공할 수 있는 제안된 개선 사항으로 마무리하겠습니다.

# Rule 메트릭이 작동하는 방식

다른 AWS 서비스와 일관성 있게, EventBridge Rules은 성능을 관찰하기 위한 CloudWatch 메트릭을 제공합니다. 일부 메트릭은 하나 이상의 차원으로 분해될 수 있어 특정 리소스의 동작을 검토할 수 있습니다. Rules은 세 가지 차원을 제공합니다:

- EventBusName: Rule의 소스 이벤트 버스의 이름.
- EventSourceName: 이벤트 소스의 이름 (Partner Rules 전용).
- RuleName: Rule의 이름.

<div class="content-ad"></div>

각 메트릭의 지원되는 차원은 "EventBridge metrics" 테이블의 "Dimensions" 아래에 나열됩니다. 그러나 작성 시점에서 이 테이블은 실제 경험과 일관성이 없었기 때문에 CloudWatch를 직접 사용하여 사용 가능한 각 메트릭의 차원을 파악하는 것이 유용할 것입니다. 나중에 다룰 FailedInvocations를 살펴보겠지만, 예를 들어 문서화된 차원에는 RuleName만 나열되어 있으며 Region 및 Namespace과 같은 기본값도 함께 언급되었습니다. 그러나 아래 스크린샷에서도 보여지는 것처럼, 왼쪽에 my-event-bus로 설정된 EventBusName도 확인할 수 있습니다.

![image](/assets/img/2024-09-10-MonitoringAmazonEventBridgeRules_1.png)

# 트래픽 양 관찰

트래픽 양과 관련된 여러 메트릭이 있으며, 이를 공유할 가치가 있습니다.

<div class="content-ad"></div>

- MatchedEvents: Rule 필터링 기준과 일치하는 이벤트 수입니다.
- TriggeredRules: 일치하는 이벤트에 의해 트리거된 Rule(s)의 수입니다.
- ThrottledRules: Rule(s)이 얼마나 자주 지연되어 호출되었는지를 보여줍니다.

많은 사용 사례에서 MatchedEvents와 TriggeredRules는 서로 교차 사용될 수 있습니다. 모든 또는 특정 Rule(s)의 트래픽 양을 모니터링하기를 원할 때 둘 다 적용됩니다. ThrottledRules는 계정 전체의 Rule 호출에 대한 제한이 깨졌음을 보여줍니다. 이 한계는 "초당 트랜잭션으로 제한되는 호출 제한"에서 조정할 수 있습니다.

Rule이 일치하는 이벤트에 의해 트리거되었을 때 목표 소비자를 호출해야 합니다. 상기 메트릭 중 어느 것도 목표 호출을 포함하지 않습니다. 이로 인해 다음과 같은 몇 가지 탐구할 가치 있는 질문이 제기됩니다:

- Rules는 호출 실패를 어떻게 처리합니까?
- 어떤 메트릭을 사용하여 호출 실패를 추적할 수 있습니까?
- 성공적인 호출을 어떻게 관찰합니까?

<div class="content-ad"></div>

# 실패한 호출 처리

어떤 경우에는 규칙이 대상을 호출하지 못하는 경우 호출을 다시 시도할 수 있습니다. 예를 들어, 네트워크 문제로 인한 실패는 다시 시도되지만 권한 부족 오류는 다시 시도되지 않습니다.

재시도가 필요한 경우, 규칙은 대상 소비자의 재시도 정책을 준수합니다. 재시도 횟수와 간격은 최대 185회와 24시간까지 가능합니다. 그러나 모든 대상이 구성 가능한 재시도 정책을 제공하는 것은 아닙니다. 예를 들어, 이벤트브릿지 이벤트 버스 대상의 재시도 정책은 조절할 수 없습니다.

![MonitoringAmazonEventBridgeRules_2](/assets/img/2024-09-10-MonitoringAmazonEventBridgeRules_2.png)

<div class="content-ad"></div>

# Invocation Failures 모니터링

Rule이 대상을 호출하는 데 실패할 때 (해당되는 경우 재시도 포함), 이벤트를 전달하는 데 영구적으로 실패했다고 말합니다. 이러한 경우를 검토하기 위해 앞에서 언급한 FailedInvocations 메트릭을 활용할 수 있습니다. 이는 영구적인 실패만을 표시하며 다시 시도할 실패는 고려되지 않습니다.

다시 시도할 실패는 관찰하기가 더 어렵습니다. 2023년 11월에 EventBridge가 RetryInvocationAttempts를 포함한 여러 새로운 메트릭을 도입했습니다. "대상 호출이 다시 시도된 횟수"를 정확히 제공하는 이 메트릭은 우리가 필요한 것을 제공하는 것처럼 보입니다. 그러나 이는 차원을 지원하지 않으므로 개별 Bus 또는 Rule마다 다시 시도를 검토할 수 없습니다. 단지 전체 AWS 계정 전체의 다시 시도 횟수만 볼 수 있습니다. 단일 계정에서 많은 Rule을 사용하는 경우에는 특히 가치가 없습니다.

작성 시점에서는 다시 시도할 실패를 추적하는 명확한 방법이 없습니다. Rule 다시 시도 정책을 구성할 수 없는 경우에는 특히 문제가 됩니다. 즉, Rule이 최대 24시간까지 다시 시도할 수 있고 이 간격을 줄일 수 없는 경우, 우리는 하류 소비자의 메트릭에 의존하지 않고 24시간 동안 실패를 쉽게 관찰할 수 없을 수 있습니다.

<div class="content-ad"></div>

# 성공적인 실행 추적

실패 사항을 다시 시도하는 것을 보려고 노력할지도 모르지만, 성공적인 Rule 호출을 모니터링하기 위해 기존 메트릭을 사용할 수 있지만, 조금의 작업이 필요합니다. Metric SuccessfulInvocationAttempts가 이상적으로 보일 수 있지만, RetryInvocationAttempts와 동일한 문제가 있습니다: 특정 Rule 이름으로 이 메트릭을 분류하는 데 사용할 수 있는 차원이 현재 작성 시점에서 없기 때문에, 귀하의 계정이 하나의 Rule만 있는 경우를 제외하고는 제한된 가치를 제공합니다.

![이미지](/assets/img/2024-09-10-MonitoringAmazonEventBridgeRules_3.png)

다음으로 성공 및 영구적으로 실패한 호출을 모두 세는 Invocations로 전환합니다. 후자의 카운트를 제외하려면, CloudWatch 메트릭 수학을 활용하여 FailedInvocations을 Invocations에서 빼고 결과를 성공적인 호출의 카운트로 취할 수 있습니다.

<div class="content-ad"></div>

아직 다루지 않은 몇 가지 기타 호출 메트릭이 있습니다. 이에는 InvocationAttempts 및 InvocationsCreated가 포함되는데, 다시 말해서 특정 Buses 또는 Rules로 필터링할 수 없으므로 그 값은 별다른 가치가 없습니다. 또한 AWS에서 다음과 같이 정의하는 DeadLetterInvocations도 있습니다:

이 메트릭은 추가 설명이 필요합니다.

## Dead Letter Invocations

Rules에서는 대상이 영구적으로 호출되지 못하는 이벤트에 대한 SQS Dead Letter Queue 통합을 지원합니다. 따라서 DeadLetterInvocations는 실패한 이벤트가 얼마나 자주 큐로 전송되는지를 보여줄까요? 처음 생각과는 달리, 그렇지 않습니다. 대신 InvocationsSentToDlq 및 InvocationsFailedToBeSentToDlq가 DLQ 통합 동작을 모니터링하는 데 사용됩니다.

<div class="content-ad"></div>

아마도 이름으로는 명확하지 않을 수 있지만, DeadLetterInvocations는 Rule이 자체를 호출할 때 강조됩니다. 이를 설명하기 위해 다음 예를 살펴보세요:

- 이벤트 버스 my-event-bus가 Rule인 my-rule로 설정됩니다.
- my-rule은 모든 이벤트에 대해 람다 함수 my-function을 호출하도록 구성됩니다.
- my-function은 EventBridge SDK를 사용하여 이벤트를 my-event-bus에 넣습니다.

![이미지](/assets/img/2024-09-10-MonitoringAmazonEventBridgeRules_4.png)

우리는 무한 루프에 빠졌어요! my-function은 자신이 호출된 이벤트 버스에 이벤트를 넣습니다. 개입이 없으면 Rule이 무기한 실행되어 AWS 계정 소유자에게 큰 비용을 발생시킬 수 있습니다. AWS는 서비스 간 루프를 감지하고 자동으로 Rule을 비활성화하여 DeadLetterInvocations 메트릭을 생성합니다.

<div class="content-ad"></div>

# 메트릭 개선 제안

이 글에서 우리는 Rule 메트릭을 전체적으로 다루지는 않았습니다. PutEvents 및 PutPartnerEvents API 요청을 통해 더 탐구할 가치 있는 다양한 옵션이 있지만, 블로그 포스트의 범위를 벗어났습니다.

우리가 다룬 내용을 기반으로, EventBridge는 많은 유용한 메트릭을 제공하지만, 더 많은 개선 여지가 있습니다. 특히 계정 전체 숫자만 제공하는 메트릭에 대한 차원(Dimensions) 지원은 환영받을 만합니다. 예를 들어, Dimensions로 EventBusName 및 RuleName이 RetryInvocationAttempts에 대해 구체적인 규칙을 사용하여 재시도될 호출을 검토하는 데 매우 가치가 있을 수 있습니다. 재시도 정책 간격동안 규칙당 메트릭이 없는 것은 프로덕션에서 규칙을 활용하는 시간이 중요한 서비스에서 심각한 고려사항이어야 합니다.

또 다른 반복되는 주제는 메트릭 명명입니다. 명명하기 어렵습니다! 이는 좀 더 주관적이지만, 고려해야 할 몇 가지 사례가 있습니다. 먼저, 호출은 InvocationAttempts와 혼동될 수 있습니다. 이 두 메트릭 간에 차이점이 명확하지 않습니다. 아마도 전자를 InvocationAttemptsWithoutRetry 또는 비슷한 이름으로 변경하는 것이 더 나을 수 있습니다. 왜냐하면 이는 성공과 영구 실패를 다루고 있기 때문일 수 있습니다. 둘째, DeadLetterInvocations의 이름을 재검토하는 것도 좋은 아이디어일 수 있습니다. Lambda가 재귀 검출 출시를 하면서, 이 메트릭을 RecursiveInvocationAttempts와 같이 명명할 수도 있고 또는 DiscardedInvocationAttempts와 같이 더 일반적인 이름을 사용할 수도 있을 것입니다.

<div class="content-ad"></div>

EventBridge는 훌륭한 서비스이지만 Rules를 관찰하는 방법을 개선할 여지가 남아 있습니다. 위 제안을 참고하여 궁금한 사항이나 더 탐구해 볼 제안 사항이 있으면 언제든지 연락해 주세요. Rules와 밀접하게 작업하시는 경우, 관찰 가능성과 개선이 가능한 부분에 대한 여러분의 생각을 듣는 게 좋을 것 같습니다. 이 블로그 글을 읽어주셔서 감사합니다. 참고용으로 아래 추가 독서 자료를 공유해 드렸습니다.

# 추가 독서 자료

- Amazon에 의한 Amazon EventBridge 모니터링.
- Amazon에 의한 Rule 모니터링을 위한 모범 사례.
- Amazon에 의한 EventBridge용 향상된 CloudWatch 지표.

아마존 이벤트브릿지 규칙 모니터링

한 글에 담은 Java Stream 마스터하기 



동시성 및 I/O 바운드 작업의 성능 향상

SpringBoot 3.3에는 많은 향상된 기능들이 있습니다. 이 글에서는 Virtual Threads 및 3.3에서의 향상에 대해 이야기하려고 합니다.

![SpringBoot 3.3 New Enhanced Feature](/assets/img/2024-09-10-SpringBoot33NewenhancedfeatureMust-Know\_0.png)

가상 스레드란 무엇인가요?

<div class="content-ad"></div>

가상 스레드는 전통적인 플랫폼 스레드에 대한 가벼운 대안을 제공합니다. 운영 체제가 아닌 JVM에 의해 관리되며, 가상 스레드는 전통적인 스레드 관리의 부담 없이 방대한 수의 동시 작업을 처리하기 위해 설계되었습니다. 실행 중에 플랫폼 스레드에 바운드되지만 생성 및 스케줄링시 상당히 적은 오버헤드를 가집니다. 이 설계는 고도의 동시성 환경에서 스레드 생성 및 컨텍스트 전환이 연관된 성능 제한을 완화하기 위한 것입니다.

가상 스레드의 사용 사례

1. 고 동시성 요청 처리: 높은 수준의 사용자 요청을 처리하는 웹 애플리케이션은 가상 스레드에서 혜택을 받을 수 있습니다. 전통적인 스레드 풀은 고갈될 수 있어 성능 병목 현상을 초래할 수 있습니다. 가상 스레드를 사용하면 수천 개 또는 수백만 개의 동시 요청으로 확장할 수 있고 성능 저하가 크지 않습니다.

2. I/O-바운드 작업: 데이터베이스 쿼리 또는 네트워크 호출과 같이 방대한 I/O 작업이 포함된 시나리오에서 가상 스레드가 뛰어난 성능을 발휘합니다. 기다리는 동안 자원을 차지하고 차단 시키는 전통적인 스레드와 달리, 가상 스레드는 이러한 차단 작업을 효율적으로 처리하여 자원 활용을 향상시킵니다.

3. 긴 실행 시간 작업: 데이터 처리 또는 로그 분석과 같이 오랜 기간 실행되는 작업은 가상 스레드의 낮은 오버헤드에서 혜택을 받을 수 있습니다. 가상 스레드는 상당한 시스템 자원을 소비하지 않고 긴 실행 작업을 관리할 수 있어 성능과 확장성을 유지할 수 있습니다.

# Spring Boot에서 가상 스레드 지원

<div class="content-ad"></div>

가상 스레드는 프로젝트 룸(Project Loom)의 미리보기 기능으로 Java 19에서 소개된 기능입니다. Java 애플리케이션의 동시성을 보다 효율적으로 관리할 수 있습니다. 가상 스레드는 Java의 일부이지만, Spring Boot는 버전 3.2부터 지원을 시작했습니다.

Spring Boot 3.3은 이 지원을 더욱 다듬어 Java 19와의 통합을 최적화하여 가상 스레드를 효과적으로 활용합니다. 이 업데이트는 가상 스레드의 장점을 동시 요청 처리, I/O 작업, 그리고 오랜 시간 소요되는 작업을 포함한 다양한 애플리케이션 개발 측면에 확장합니다.

주요 이정표

- Java 19: 미리보기 기능으로 가상 스레드를 도입했습니다.
- Spring Boot 3.2: Spring의 동시성 메커니즘과의 통합을 포함하여 가상 스레드 지원 추가.
- Spring Boot 3.3: 성능 최적화 및 사용 사례 확대를 위해 가상 스레드 지원을 강화했습니다.

<div class="content-ad"></div>

# Spring Boot에서 더 강화된 지원

1. Core Spring Framework 적응

Spring Boot 3.3은 가상 스레드를 보다 잘 지원하기 위해 다양한 핵심 Spring 기능을 적응시킵니다. 트랜잭션 관리, 비동기 작업 실행 및 이벤트 처리와 같은 메커니즘이 가상 스레드와 매끄럽게 작동하도록 보장합니다.

- 비동기 작업 실행: @Async 어노테이션에 대한 개선된 지원으로, 가상 스레드 기반의 실행자를 사용하여 동시성 성능을 향상시킵니다.

<div class="content-ad"></div>

```java
@Configuration
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}
```

- 이벤트 주도 아키텍처: 가상 스레드는 이벤트 주도 아키텍처에서 효율적으로 이벤트를 처리하여 전통적인 스레드 리소스에 제한받지 않고 빠르게 이벤트를 처리할 수 있습니다.

```java
@Configuration
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}
```

2. Spring MVC 및 WebFlux 통합

<div class="content-ad"></div>

Spring Boot 3.3에서는 Spring MVC 및 WebFlux의 가상 스레드 지원이 강화되어, 특히 고 동시성 환경에서 HTTP 요청 처리의 효율성이 향상되었습니다.

- Spring MVC: 가상 스레드를 사용하면 Spring MVC가 스레드 풀 고갈을 피하고 고부하 시나리오에서 요청을 더 효율적으로 처리할 수 있습니다.

```java
@RestController
@RequestMapping("/api")
public class ExampleController {

    @GetMapping("/data")
    public CompletableFuture<String> getData() {
        return CompletableFuture.supplyAsync(() -> {
            
            // 여기에서 로직 처리
            return "데이터 처리 완료";
        }, Executors.newVirtualThreadPerTaskExecutor());
    }
}
```

- WebFlux: WebFlux의 반응형 모델은 가상 스레드를 통해 블로킹 작업을 처리하면서 비블로킹 특성을 유지하는 이점을 얻습니다.

<div class="content-ad"></div>

3. Spring Data와 트랜잭션 관리

가상 스레드는 데이터베이스 접근 및 트랜잭션 관리를 향상시켜 블로킹 시간을 줄이고 올바른 트랜잭션 전파를 보장합니다.

```java
@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void processUser(Long userId) {
        Executors.newVirtualThreadPerTaskExecutor().submit(() -> {
            User user = userRepository.findById(userId).orElseThrow();
            // 여기에서 로직 처리
        }).join(); // 트랜잭션이 올바르게 종료되도록 확인
    }
}
```

4. 향상된 오류 처리 및 디버깅 지원

<div class="content-ad"></div>

Spring Boot 3.3은 가상 스레드에 대한 디버깅 및 오류 처리를 개선하여, 예외를 캡처하고 관리하기 쉽게 하며 명확한 스택 추적 및 스레드 정보를 제공합니다.

- 향상된 예외 처리: 가상 스레드 예외를 캡처하고 균일하게 처리하여 디버깅을 위한 자세한 스택 추적과 스레드 컨텍스트를 제공합니다.

```java
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleException(Exception e) {
        // 디버깅을 위해 스택 추적을 출력합니다
        StringBuilder stackTrace = new StringBuilder();
        for (StackTraceElement element : e.getStackTrace()) {
            stackTrace.append(element.toString()).append("\n");
        }
        
        // 또한 현재 스레드 정보도 출력합니다
        String threadInfo = "Thread: " + Thread.currentThread().getName();
        
        System.err.println("예외 발생 위치: " + threadInfo);
        System.err.println(stackTrace.toString());

        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body("오류 발생: " + e.getMessage() + "\n" + stackTrace.toString() + "\n" + threadInfo);
    }
}
```

오류 로그는 다음과 같이 보입니다:

<div class="content-ad"></div>

```js
Thread: VirtualThread-17 (Virtual Thread: true)에서 예외가 발생했습니다.
java.lang.RuntimeException: ID가 123인 사용자를 찾을 수 없습니다.
 at com.example.UserService.lambda$processUser$0(UserService.java:15)
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
 at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base/java.lang.VirtualThread.run(VirtualThread.java:494)

StackTrace:
com.example.UserService.lambda$processUser$0(UserService.java:15)
java.util.concurrent.FutureTask.run(FutureTask.java:264)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
java.lang.VirtualThread.run(VirtualThread.java:494)
Thread: VirtualThread-17 (Virtual Thread: true)
```

# 가상 스레드 잘못 사용시 문제점 및 이슈:

## 1. 자원 고갈

문제: 가상 스레드는 가벼우나 메모리 및 CPU 자원을 사용합니다. 적절히 관리하지 않으면 너무 많은 가상 스레드를 생성하면 자원 고갈이 발생할 수 있으며, 이로 인해 응용프로그램이 다운되거나 성능이 저하될 수 있습니다.


<div class="content-ad"></div>

예시: JVM을 과부하로 이끄는 것을 방지하려면 순차적으로 처리할 수 있는 작업에 대해 수백만 개의 가상 스레드를 생성하는 것은 필요하지 않습니다.

## 2. 적절하지 못한 블로킹 작업

문제: 가상 스레드는 블로킹 작업을 더 효율적으로 처리하기 위해 설계되었지만, 적절하지 않은 상황(예: 반복적인 루프나 핫 패스)에서 블로킹 작업에 지나치게 의존하면 가상 스레드라고 해도 성능이 저하될 수 있습니다.

예시: 크리티컬 섹션이나 루프 내에서 지속적으로 I/O 또는 동기화 원시 데이터에 대해 블로킹을 거는 것은 가상 스레드를 사용하더라도 경합과 성능 병목 현상을 유발할 수 있습니다.

<div class="content-ad"></div>

## 3. 잘못된 예외 처리

문제: 가상 스레드를 사용할 때 예외 처리가 복잡해질 수 있습니다, 특히 가상 스레드 작업 중에 예외가 발생할 경우입니다. 예외가 올바르게 전파되지 않거나 처리되지 않으면 무시될 수 있어 정상적인 실패로 이어질 수 있습니다.

예시: 가상 스레드에서 예외를 올바르게 처리하지 않으면 작업이 어떤 알림 없이 실패할 수 있어 데이터 손상이나 일관성 없는 상태로 이어질 수 있습니다.

## 4. CPU 바운드 작업에 적합하지 않은 사용법

<div class="content-ad"></div>

문제: 가상 스레드는 CPU 바운드 작업보다는 I/O 바운드 작업에 가장 유익합니다. CPU 바운드 작업에 가상 스레드를 사용하면 효율적인 CPU 활용이 어려울 수 있습니다.

예시: 계산 집약적 작업을 가상 스레드에 위임하면 성능을 향상시키는 대신 불필요한 문맥 전환과 오버헤드를 일으킬 수 있습니다.

## 5. 복잡한 디버깅 및 프로파일링

문제: 가상 스레드를 사용한 응용 프로그램의 디버깅 및 프로파일링은 전통적인 스레드보다 복잡할 수 있습니다. 도구들이 아직 가상 스레드를 완전히 지원하지 않을 수 있어 문제나 성능 문제를 진단하는 데 어려움을 겪을 수 있습니다.

<div class="content-ad"></div>

예시: 전통적인 쓰레드 덤프나 스택 트레이스는 가상 쓰레드와 관련된 문제를 명확하게 보여주지 않을 수 있어서 디버깅 중에 혼란을 야기할 수 있습니다.

# 그래서 몇 가지 권장 사항이 있습니다:

## 1. I/O 바운드 작업에 가상 쓰레드 사용하기

권장: 가상 쓰레드는 네트워크 요청 처리, 데이터베이스 작업 또는 파일 I/O와 같이 작업이 I/O 바운드인 시나리오에서 뛰어납니다. 이를 통해 기존 쓰레드 풀의 제약 사항을 고려하지 않고 동시 작업의 수를 확장할 수 있습니다.

<div class="content-ad"></div>

가상 쓰레드를 사용하여 웹 서버나 마이크로서비스 아키텍처에서 동시에 많은 수의 HTTP 요청을 처리하세요.

## 2. CPU 바운드 작업에 가상 스레드 사용하지 않기

권장 사항: CPU 바운드 작업의 경우, 플랫폼 스레드를 사용하거나 가상 스레드의 수를 신중하게 관리하는 것을 고려해보세요. 가상 스레드는 계산 집약적 작업에서 불필요한 오버헤드를 도입할 수 있습니다.

예시: 복잡한 계산을 수행하는 데이터 처리 파이프라인의 경우, 개별 작업마다 가상 스레드를 생성하는 대신 플랫폼 스레드와 함께 고정 크기의 스레드 풀을 사용하세요.

<div class="content-ad"></div>

## 3. Executor 서비스 활용하기

권장사항: Executors.newVirtualThreadPerTaskExecutor()를 사용하여 가상 스레드를 효율적으로 관리하는 Executor 서비스를 생성합니다. 이를 통해 가상 스레드에서 수행할 작업을 수동으로 관리하지 않고 제출할 수 있습니다.

예시: Spring Boot 애플리케이션에서 @Async로 주석 처리된 비동기 작업을 처리하는 데 이 Executor 서비스를 사용합니다.

## 4. 가상 스레드 범위 제한하기

<div class="content-ad"></div>

### 모범 사례: 가상 스레드는 작업이 일시적이거나 블로킹이 예상되는 경우에 사용해야 합니다. 무기한 실행되거나 무거운 계산을 포함하는 작업에 대해 가상 스레드를 생성하지 마세요.

예시: REST API에서 요청을 처리할 때 가상 스레드를 사용하되, 장기 실행 백그라운드 작업이나 밀집된 일괄 처리에는 사용하지 마세요.

## 5. 스레드 로컬 변수를 사용할 때 주의해 주세요.

모범 사례: 가상 스레드에서 스레드 로컬 변수에 의존하지 마세요. 스레드 재사용으로 인해 원하는 대로 동작하지 않을 수 있습니다. 스레드 로컬 저장소를 사용해야 하는 경우 주의해서 관리해 주세요.

<div class="content-ad"></div>

예시: 사용자 컨텍스트나 세션 데이터에 스레드 로컬 변수를 사용하는 대신, 필요한 메서드에 명시적으로 이 정보를 전달하세요.

## 6. 적절한 예외 처리

Best Practice: 가상 스레드 내의 예외가 제대로 처리되고 눈치채지 못하게 되지 않도록 보장하세요. 적절한 예외 처리 메커니즘과 로깅을 사용하여 가상 스레드의 오류를 잡아내세요.

예시: Spring Boot 애플리케이션에서 전역 예외 처리기를 구현하여 가상 스레드에서 실행 중인 작업에서 발생한 예외를 캐치하고 로깅하세요.

<div class="content-ad"></div>

## 7. 가상 스레드 모니터링 및 프로파일링

**최상의 방법:** 가상 스레드가 효과적으로 사용되고 있는지 확인하기 위해 정기적으로 응용 프로그램을 모니터링하고 프로파일링하세요. 가상 스레드를 지원하는 도구를 사용하여 성능을 분석하고 문제를 감지하세요.

**예시:** 가상 스레드와 호환되는 Java Flight Recorder (JFR) 또는 다른 프로파일링 도구를 사용하여 스레드 사용량을 모니터링하고 잠재적인 병목 현상을 식별하세요.

## 8. 블로킹 작업 최적화

<div class="content-ad"></div>

최적 사례: 가상 스레드를 사용할 때는 I/O, 데이터베이스 액세스와 같은 블로킹 작업이 최적화되었는지 확인하세요. 가상 스레드는 블로킹을 더 우아하게 처리할 수 있지만, 과도한 블로킹은 성능 저하로 이어질 수 있습니다.

예시: 데이터베이스 액세스 레이어에서는 쿼리가 최적화되어 블로킹 시간이 줄어들도록 보장하세요. 가상 스레드를 사용할 때에도 이를 실천해주세요.

## 9. 현실적인 환경에서 테스트

최적 사례: 가상 스레드가 부하를 겪는 환경에서 응용 프로그램을 테스트하여 실제 운영과 유사한 환경에서 가상 스레드의 동작을 관찰하세요. 이를 통해 사용자에게 영향을 미치기 전에 잠재적인 문제를 식별할 수 있습니다.

<div class="content-ad"></div>

예시: 가상 스레드를 사용하여 고 동시성을 모방하고 확장성 문제를 식별하도록 애플리케이션에 부하 테스트를 수행하세요.

## 10. 점진적 적용

최상의 방법: 애플리케이션에 가상 스레드를 점진적으로 도입하세요. 중요하지 않은 경로부터 시작하여 자신감을 얻고 그 영향을 이해하는 동안 사용범위를 확장하세요.

예시: 주요 요청 처리 작업에 채택하기 전에 비동기 처리나 백그라운드 작업에서 가상 스레드를 사용하여 시작하세요.

<div class="content-ad"></div>

다른 SpringBoot 3.3 좋은 기사들:

여기까지입니다.

읽어 주셔서 감사합니다! 좋아하셨거나 도움이 되었다면 박수 버튼을 클릭해주세요.
즐거운 코딩이 되길 바라며. 다음에 또 만나요 :)

SpringBoot 3.3 새롭게 강화된 기능. 꼭 알아야 할 사항




<img src="/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_0.png" />

내 글은 누구나 열람할 수 있어요. 비회원 독자도 이 링크를 클릭하여 전체 글을 읽을 수 있어요.

# 1. 람다식이란?

자바 변수에 대해 "값"을 할당할 수 있고, 그 값을 활용할 수 있다는 걸 알고 있는 우리에게


<div class="content-ad"></div>

```java
int a = 1;
String s = "Hello";
System.out.println(s + a);
```

만약 자바 변수에 "코드 조각"을 할당하고 싶다면 어떻게 해야 합니까?

예를 들어, 오른쪽의 코드 블록을 codeBlock이라는 자바 변수에 할당하고 싶다면 어떻게 해야 합니까?

![이미지](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_1.png)


<div class="content-ad"></div>

자바 8 이전에는 이게 불가능했습니다. 그러나 자바 8 이후에 람다 기능을 사용하여 이를 할 수 있게 되었습니다. 직관적인 표현은 다음과 같습니다：

```java
codeBlock = public void doSomething(String s) {
        System.out.println(s);
}
```

물론, 이것은 매우 간결하게 쓸 수 있는 방법은 아닙니다. 따라서, 이 할당 작업을 더 우아하게 만들기 위해 몇 가지 불필요한 선언을 제거할 수 있습니다.

![이미지](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_2.png)

<div class="content-ad"></div>

이렇게 해서 '코드 조각'을 변수에 매우 우아하게 할당했습니다. 그리고 '이 코드 조각' 또는 '변수에 할당된 이 함수'은 람다 표현식입니다.

그러나 여기에는 여전히 하나의 질문이 남아 있습니다. 바로 변수 codeBlock의 타입이 무엇이어야 하는가인 것입니다.

Java 8에서 모든 람다 유형은 인터페이스이며, 람다 표현식 자체, 즉 '코드 조각'은 이 인터페이스의 구현이어야 합니다. 이것이 람다를 이해하는 데 중요한 포인트 중 하나라고 생각합니다. 요약하자면, 람다 표현식 자체가 인터페이스의 구현입니다. 이렇게 직접 말하면 여전히 약간 혼동스러울 수 있으니, 예제를 통해 계속 알아보도록 하겠습니다. 위의 codeBlock에 타입을 추가해 봅시다:

![이미지](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_3.png)

<div class="content-ad"></div>

이렇게 하나의 기능만 구현해야 하는 인터페이스를 "함수형 인터페이스"라고 합니다.

나중에 이 인터페이스에 인터페이스 함수를 추가하는 것을 방지하여, 여러 인터페이스 함수가 구현되어 "비 함수형 인터페이스"가 되는 것을 방지하기 위해, 이 인터페이스에 @FunctionalInterface 선언을 추가할 수 있습니다. 이렇게 하면 다른 사람들이 새로운 함수를 추가할 수 없습니다.

이렇게 하면 완전한 람다 표현식 선언을 얻을 수 있습니다.

![이미지](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_4.png)

<div class="content-ad"></div>


![Lambda Expression](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_5.png)

## 2. Lambda Expression의 기능은 무엇인가요?

가장 직관적인 효과는 코드를 극도로 간결하게 만드는 것입니다.

Lambda 표현식과 동일한 인터페이스의 전통적인 Java 구현을 비교할 수 있습니다:


<div class="content-ad"></div>

![Lambda Expression](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_6.png)

이 두 가지 작성 방법은 본질적으로 동등합니다. 그러나 분명히, Java 8의 작성 방법이 더 우아하고 간결합니다. 게다가 Lambda는 변수에 직접 할당될 수 있으므로 전통적인 Java에서는 인터페이스 구현과 초기화 정의를 명확히 해야 하는 반면, 함수에 Lambda를 직접 전달할 수 있습니다.

![Lambda Expression](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_7.png)

일부 경우에는 이 인터페이스 구현이 한 번만 사용되어야 합니다. 전통적인 Java 7은 InterfaceImpl을 구현하기 위해 "환경 오염" 인터페이스를 정의해야 합니다. 비교적 Java 8의 Lambda가 훨씬 깔끔해 보입니다.

<div class="content-ad"></div>

Lambda는 FunctionalInterface 라이브러리, forEach, stream(), 메서드 참조 및 기타 새로운 기능을 결합하여 코드를 더 간결하게 만듭니다!

이제 바로 예제로 넘어가보겠습니다.

Student의 정의와 List(Student)의 값이 주어진 것으로 가정합니다.

```java
@Getter
@AllArgsConstructor
public static class Student {
  private String name;
  private Integer age;
}

List<Student> students = Arrays.asList(
  new Student("Bob", 18),
  new Student("Ted", 17),
  new Student("Zeka", 18));
```

<div class="content-ad"></div>

자, 이제 students 목록에서 18세인 학생들의 이름을 모두 출력해야 합니다.

Lambda의 원본 쓰기 방법: 두 가지 함수형 인터페이스를 정의하고, 정적 함수를 정의한 후, 정적 함수를 호출하고 람다 표현식을 매개변수에 할당합니다.

```java
@FunctionalInterface
interface AgeMatcher {
  boolean match(Student student);
}

@FunctionalInterface
interface Executor {
  boolean execute(Student student);
}

public static void matchAndExecute(List<Student> students, AgeMatcher matcher, Executor executor) {
  for (Student student : students) {
    if (matcher.match(student)) {
      executor.execute(student);
    }
  }
}

public static void main(String[] args) {

        List<Student> students = Arrays.asList(
                new Student("Bob", 18),
                new Student("Ted", 17),
                new Student("Zeka", 18));

        matchAndExecute(students, 
                        s -> s.getAge() == 18, 
                        s -> System.out.println(s.getName()));
}
```

이 코드는 실제로 비교적 간결한데, 더 간결하게 할 수는 없을까요?

<div class="content-ad"></div>

물론, Java 8에는 많은 기능적 인터페이스를 정의하는 기능 인터페이스 패키지가 있습니다 (java.util.function (Java Platform SE 8)).

따라서 여기서 AgeMatcher와 Executor 두 개의 기능 인터페이스를 정의할 필요가 전혀 없습니다. Java 8 기능 인터페이스 패키지에서 그들의 인터페이스 쌍 때문에 Predicate(T)와 Consumer(T)를 사용할 수 있습니다. 실제로 그 정의는 AgeMatcher/Executor와 동일합니다.

![이미지](/assets/img/2024-09-10-JavaProbablytheMostUnderstandableExplanationofLambdaExpressionYoullEverSee_8.png)

단계 1: 단순화 — 기능 인터페이스 패키지 활용하기:

<div class="content-ad"></div>

```js
public static void matchAndExecute(List<Student> students, Predicate<Student> predicate, Consumer<Student> consumer) {
        for (Student student : students) {
            if (predicate.test(student)) {
                consumer.accept(student);
            }
        }
    }
```

matchAndExecute에 있는 for each 루프는 실제로 매우 귀찮습니다. 여기서는 Iterable의 forEach()를 사용할 수 있습니다. forEach() 자체가 Consumer(T) 매개변수를 받을 수 있습니다.

단계 2: 간단화 — foreach 루프를 Iterable.forEach()로 교체 :

```js
public static void matchAndExecute(List<Student> students, Predicate<Student> predicate, Consumer<Student> consumer) {
        students.forEach(s -> {
            if (predicate.test(s)) {
                consumer.accept(s);
            }
        });
    }
```

<div class="content-ad"></div>

matchAndExecute는 사실 List에서 수행되는 작업이므로 matchAndExecute를 제거하고 직접 stream() 기능을 사용할 수 있습니다. stream()의 여러 메서드는 Predicate(T) 및 Consumer(T)와 같은 매개변수를 허용합니다 (java.util.stream (Java Platform SE 8)). 위 내용을 이해하면 stream()을 매우 쉽게 이해할 수 있으며 추가 설명이 필요하지 않습니다.

3단계: 단순화 - 정적 함수 대신 stream() 사용:

```js
students.stream()
        .filter(s -> s.getAge() == 18)
        .forEach(s -> System.out.println(s.getName()));
```

원래의 람다 작성 방법과 비교하면 매우 간결합니다. 그러나 모든 학생의 정보를 출력하도록 변경하라고 요청하면 s 대신 `System.out.println(s);를 사용하여 메서드 참조를 통해 계속 단순화할 수 있습니다. 메서드 참조란 이미 작성된 다른 객체/클래스의 메서드로 람다 표현식을 대체하는 것입니다. 형식은 다음과 같습니다:

<div class="content-ad"></div>

<table> 태그를 Markdown 형식으로 변경하세요.

<div class="content-ad"></div>

아직 Java의 람다에 대해 논의하고 배울 부분이 있습니다. 예를 들어, 람다의 특성을 활용하여 병렬 처리를 수행하는 방법 등이 있습니다.

간략히 말하면, 개념을 전달하기 위해 일반적인 소개만 하고 있습니다. 인터넷에는 람다에 관한 많은 관련 자습서가 있으니 더 많이 읽고 연습해보세요. 시간이 지남에 따라 분명히 개선 사항이 있을 것입니다.

# 컬럼

아래 링크에서 자세히 알아보세요

<div class="content-ad"></div>

마지막으로, 만약 이 기사가 도움이 되었다면 👏좋아요와 팔로우를 눌러주세요. 감사합니다! ╰(*°▽°*)╯

저는 딜런입니다. 함께 더 나아가는 것을 기대하고 있어요. ❤️

Java 람다 표현식에 대한 아마도 가장 이해하기 쉬운 설명



이미지 태그를 Markdown 형식으로 변경하였습니다.


![Spring Project Eliminating Inelegant if-else and Code Coupling with Service Locator Pattern](/assets/img/2024-09-10-SpringProjectEliminatingInelegantif-elseandCodeCouplingwithThisDesignPatternServiceLocatorPattern_0.png)

# 서문

프로젝트에서 다양한 구현 클래스 또는 서비스 처리 로직들이 다른 유형에 따라 호출되는 시나리오를 경험한 적이 있나요?

예를 들어, 다른 경보 수준에 따라 다른 메시지를 전송해야 할 때가 있습니다. 심각한 수준의 경보의 경우 개발자에게 이메일을 보내어 알림을 전송하고, 재해 수준의 경보의 경우 개발자에게 직접 전화로 알림을 전달해야 합니다.


<div class="content-ad"></div>


![Spring Project](/assets/img/2024-09-10-SpringProjectEliminatingInelegantif-elseandCodeCouplingwithThisDesignPatternServiceLocatorPattern_1.png)

다른 파서가 필요합니다. 예를 들어, XML 파일은 XML 파서로 처리되고 JSON 파일은 JSON 파서로 처리됩니다.

![Spring Project](/assets/img/2024-09-10-SpringProjectEliminatingInelegantif-elseandCodeCouplingwithThisDesignPatternServiceLocatorPattern_2.png)

과거에는 이러한 시나리오에서 호출 클라이언트에 if-else 문을 일반적으로 사용했습니다. 예를 들어, 유형이 JSON일 경우 JSON 파서를 사용합니다. 새로운 유형의 파서가 추가되면 호출 클라이언트를 여전히 수정해야합니까? 이는 명백히 매우 불편합니다.


<div class="content-ad"></div>

이 기사에서는 Service Locator Pattern을 사용하는 방법을 소개합니다. 이 패턴의 핵심 아이디어는 인터페이스 지향 프로그래밍으로, 서비스 제공자가 서로 강하게 결합된 구현을 제거하고 클라이언트가 특정 구현 클래스에 의존하는 것을 줄여줍니다.

# 예제

먼저 원래 코드 구현을 살펴봅시다. 여러 소스에서 데이터를 가져와 XML 및 JSON 파일과 같은 다양한 유형의 파일을 구문 분석해야 하는 응용 프로그램이 있다고 가정해 봅시다.

## 1. 열거형 정의

<div class="content-ad"></div>

```js
public enum ContentType {
      JSON,
      XML
}
```

## 2. 파싱 인터페이스 정의

```js
public interface Parser {
      Map parse(Reader r);
}
```

## 3. 서로 다른 파일 유형을 위한 서로 다른 구현 클래스

<div class="content-ad"></div>

```java
@Component
public class XMLParser implements Parser { 
      @Override
      public Map parse(Reader r) { 
          //...
      }
}

@Component
public class JSONParser implements Parser {
      @Override
      public Map parse(Reader r) { 
          //...
      }
}
```

## 4. The client calls different implementations according to different types through switch-case

```java
@Service
public class Client {
      private Parser xmlParser, jsonParser;
      
      @Autowired
      public Client(Parser xmlParser, Parser jsonParser) {
            this.xmlParser = xmlParser;
            this.jsonParser = jsonParser;
      }
      public Map getAll(ContentType contentType) {
            //...
            switch (contentType) {
                  case XML:
                    return xmlParser.parse(reader);
                  case JSON:
                    return jsonParser.parse(reader);
                   //...
             }
      }
}
```

대부분의 사람들은 위의 방법으로 구현할 것이고 정상적으로 실행될 것입니다. 하지만 깊게 생각해보면 어떤 문제가 존재할까요?

<div class="content-ad"></div>

제품 매니저가 CSV 파일 지원을 요청하면, 클라이언트 코드에 새로운 케이스를 `switch-case`에 추가하여 수정해야 합니다.

이는 디자인 패턴 중 개방-폐쇄 원칙을 위반합니다. 클라이언트가 다양한 파서와 지나치게 결합돼 있기 때문에 회귀 테스트가 권장됩니다.

그렇다면, 더 나은 방법이 있을까요?

# 서비스 로케이터 패턴 적용

<div class="content-ad"></div>

네, 방금 언급한 Service Locator Pattern을 사용하는 거죠. 이제 최신 코드를 점진적으로 구현해 보겠습니다.

## 1. 열거형 수정 및 CSV 추가

```js
public enum ContentType {
      JSON,
      XML,
      CSV
}
```

## 2. 서비스 로케이터 인터페이스 ParserFactory 정의

<div class="content-ad"></div>

표 태그를 마크다운 형식으로 변경해주세요.


It has a method getParser that takes a content type as a parameter and returns the Parser interface.

```java
public interface ParserFactory {
      Parser getParser(ContentType contentType);
}
```

### 3. Configure ServiceLocatorFactoryBean

In the second step, we configure ServiceLocatorFactoryBean to use ParserFactory as the service locator interface. The interface ParserFactory does not need an implementation class.


<div class="content-ad"></div>

```java
@Configuration
public class ParserConfig {
    
  @Bean("parserFactory")
  public FactoryBean serviceLocatorFactoryBean() {
        ServiceLocatorFactoryBean factoryBean = new ServiceLocatorFactoryBean();
        // Set up the service locator interface.   
        factoryBean.setServiceLocatorInterface(ParserFactory.class);
        return factoryBean;
  }
}
```

## 4. Set the bean name of the parser to be the same as the type name for service location

Set the name of the bean to be consistent with the type.

```java
@Component("CSV")
public class CSVParser implements Parser { 
    //... 
}

@Component("JSON")
public class JSONParser implements Parser { 
    //... 
}

@Component("XML")
public class XMLParser implements Parser { 
    //... 
}
```

<div class="content-ad"></div>

## 5. 클라이언트는 ParserFactory를 참조하고 특정 Parsers에 대한 종속성을 제거합니다.

이제 클라이언트는 Parser의 구체적인 구현 클래스를 참조할 필요가 없습니다. 타입에 따라 해당 기능을 갖는 Parser 인터페이스를 직접 얻어올 수 있고 switch-case 없이 해당 파싱 메서드를 호출할 수 있습니다.

```js
@Service
public class Client {
      private ParserFactory parserFactory;
      @Autowired
      public Client(ParserFactory parserFactory) {
        this.parserFactory = parserFactory;
      }
      public Map getAll(ContentType contentType) {
        // ...
        // 특정 타입에 따라 직접 해당 아이템을 얻어오는 핵심 로직
        Parser parser = parserFactory.getParser(contentType);
        parser.parse(reader);
      }
}
```

하하, 멋지지 않나요😄? 우리는 성공적으로 목표를 달성했습니다. 이제 새로운 타입을 추가할 때에는 확장하고 새로운 파서를 추가하기만 하면 됩니다. 클라이언트를 수정할 필요가 없어졌으며 개방-폐쇄 원칙을 지킬 수 있습니다.

<div class="content-ad"></div>

그런데, 직접 타입을 빈 이름으로 사용하는 것이 그렇게 우아하지 않다고 생각한다면, ContentType 열거형을 확장함으로써 다음과 같이 최적화할 수도 있습니다.

```js
public enum ContentType {
      JSON(TypeConstants.JSON_PARSER),
      XML(TypeConstants.XML_PARSER),
      CSV(TypeConstants.CSV_PARSER),
      ;
      private final String parserName;
    
      ContentType(String parserName) {
        this.parserName = parserName;
      }

      @Override
      public String toString() {
        return this.parserName;
      }
    
      public interface TypeConstants {
          String CSV_PARSER = "csvParser";
          String JSON_PARSER = "jsonParser";
          String XML_PARSER = "xmlParser"; 
      }
}

@Component(TypeConstants.CSV_PARSER)
public class CSVParser implements Parser { 
    //... 
}

@Component(TypeConstants.JSON_PARSER)
public class JSONParser implements Parser { 
    //... 
}

@Component(TypeConstants.XML_PARSER)
public class XMLParser implements Parser { 
    //... 
}
```

# 서비스 로케이터 패턴의 원리 분석

이전 사례를 통해, 아마도 모두가 서비스 로케이터 패턴을 어떻게 사용하는지 기본적으로 이해하게 되었을 것입니다. 이제 이 패턴의 원리를 깊게 분석해보겠습니다.

<div class="content-ad"></div>

서비스 로케이터 패턴은 클라이언트가 특정 구현에 의존하지 않도록 하는 것입니다. Martin Fowler의 기사에서 나온 다음 인용구는 핵심 아이디어를 요약합니다: "서비스 로케이터의 기본 아이디어는 어플리케이션이 필요로 할 수 있는 모든 서비스를 얻는 방법을 알고 있는 객체를 갖는 것입니다. 따라서 이 어플리케이션의 서비스 로케이터는 필요할 때 '서비스'를 반환하는 메서드를 가지고 있을 것입니다."

![이미지](/assets/img/2024-09-10-SpringProjectEliminatingInelegantif-elseandCodeCouplingwithThisDesignPatternServiceLocatorPattern_3.png)

Spring 프레임워크의 ServiceLocatorFactoryBean은 FactoryBean 인터페이스를 구현하고 Service Factory 빈을 생성합니다.

# 요약

<div class="content-ad"></div>

서비스 로케이터 패턴의 도움으로 우리는 Spring의 제어 역전을 효과적으로 확장하는 훌륭한 방법을 구현했습니다. 이 패턴은 의존성 주입이 최적의 해결책을 제공하지 않는 사용 사례를 해결하는 데 도움이 됩니다.

그러나 의존성 주입이 여전히 처음 선택이어야 함을 명확히해야 합니다. 대부분의 경우 요구 사항이 크게 변하지 않는 한, 서비스 로케이터는 의존성 주입을 대체하는 데 사용해서는 안 됩니다.

마지막으로, 이 문서가 도움이 되었다면 👏 크게 박수를 쳐 주시고 팔로우해 주세요. 감사합니다! ╰(*°▽°*)╯

저는 딜란이라고 합니다. 함께 진행하는 것을 기대하며 ❤️

<div class="content-ad"></div>

추천 도서 열입니다.

Spring 프로젝트 서비스 로케이터 패턴을 활용하여 난해한 if-else와 코드 의존성 제거하기



<img src="/assets/img/2024-09-10-JavaBecauseIeliminatedalltheifobjectnullintheprojectmybossrewardedmewithBlackMythWukong_0.png" />

요즘 친구가 새 회사에 입사했어요. 프로젝트에는 객체가 null 인지 직접 판단하는 코드가 많았지만, 친구는 Optional을 사용하여 최적화했고 상사로부터 칭찬을 받았어요.

자세히 소개하겠습니다.

이전 글에서는 자바의 람다 표현식을 소개했었죠. 이번 글에서는 람다 표현식과 Optional을 결합하여 자바가 null을 더 우아하게 처리하는 방법을 소개하겠습니다.

<div class="content-ad"></div>

학생 객체와 학생 객체에 대한 Optional 래퍼가 있는 상황을 가정해 봅시다:

```java
public class OptionalTest {

    public static void main(String[] args) {
        Student student = new Student("Bob", 18);
        Optional<Student> studentOpt = Optional.ofNullable(student);
    }

    @Getter
    @AllArgsConstructor
    public static class Student {
        private String name;
        private Integer age;
    }
}
```

만약 람다와 함께 사용되지 않는다면 Optional은 원래 수고스러운 null 체크를 간단하게 만들어줄 수 없습니다. 아래와 같이 작성하는 것이 그 예시입니다:

```java
// 메서드 1 작성
if (student == null) {
  return UNKNOWN_STUDENT;
} else {
  return student;
}

// 메서드 2도 메서드 1만큼 나쁘게 작성됩니다
if (!studentOpt.isPresent()) {
  return UNKNOWN_STUDENT;
} else {
  return studentOpt.get();
}
```

<div class="content-ad"></div>

Optional을 람다와 함께 사용할 때에만 Optional의 진정한 힘을 발휘할 수 있습니다!

이제 자바8의 람다 + Optional과 전통적인 자바 간의 널 처리 차이 네 가지를 비교해보겠습니다.

상황 1 — 존재하는 경우 실행

```java
// if
if (student != null) {
  System.out.println(student);
}

// Optional
studentOpt.ifPresent(System.out::println);
```

<div class="content-ad"></div>

Case 2 — 존재하면 반환하고, 그렇지 않으면 오류를 반환하거나 예외를 throw합니다.

```js
// if
if (student == null) {
  return UNKNOWN_STUDENT;   // 또는 예외 throw
} else {
  return student;
}

// Optional
return studentOpt.orElse(UNKNOWN_STUDENT);
return studentOpt.orElseThrow(RuntimeException::new);
```

Case 3 — 존재하면 반환됩니다. 그렇지 않으면 함수로 생성합니다.

```js
// if
if (student == null) {
  return UNKNOWN_STUDENT;
} else {
  return generateWithFunction();
}

// Optional
return studentOpt.orElseGet(() -> generateWithFunction());
```

<div class="content-ad"></div>

사례 4 - 연속적인 널 체크

```js
public class OptionalCase {

    public static void main(String[] args) {
        Student student = new Student("Bob", 18,
                new Street("Main Street", new City("Los Angeles", new State("CA"))));

        System.out.println(getStateFromJava7(student));
        System.out.println(getStateFromJava8(student));
    }

    private static String getStateFromJava7(Student student) {
        // Java 7
        if (student != null) {
            Street street = student.getAddress();
            if (street != null) {
                City city = street.getCity();
                if (city != null) {
                    State state = city.getState();
                    if (state != null) {
                        String stateName = state.getName();
                        if (stateName != null) {
                            return stateName;
                        }
                        return "unknown";
                    }
                    return "unknown";
                }
                return "unknown";
            }
            return "unknown";
        }
        return "unknown";
    }

    private static String getStateFromJava8(Student student) {
        Optional<Student> studentOpt = Optional.ofNullable(student);
        // Java 8
        return studentOpt
                .map(Student::getAddress)
                .map(Street::getCity)
                .map(City::getState)
                .map(State::getName)
                .orElse("unknown");
    }

    @Getter
    @AllArgsConstructor
    static class Student {
        private String name;
        private Integer age;
        private Street address;
    }

    @Getter
    @AllArgsConstructor
    static class Street {
        private String name;
        private City city;
    }

    @Getter
    @AllArgsConstructor
    static class City {
        private String name;
        private State state;
    }

    @Getter
    @AllArgsConstructor
    static class State {
        private String name;
    }
}
```

위의 네 가지 상황에서 Optional + Lambda를 사용하면 ifElse 블록을 훨씬 적게 작성할 수 있음을 명확히 알 수 있습니다. 특히 상황 4의 경우, 전통적인 Java 작성 방법은 장황하고 이해하기 어렵지만, Optional + Lambda는 새롭고 명확하며 간결합니다.

Java Lambda와 Stream의 더 많은 사용 사례를 보려면 제 컬럼을 읽어보세요.

<div class="content-ad"></div>

다른 계속해서 업데이트되는 코너도 읽어보시는 걸 추천해요!

Java object  null 조건문들을 모두 제거해서 보너스로 검은 신화 웨콩을 받았어



프리미엄 멤버십이 없는 경우 블로그를 읽으려면 여기를 클릭하세요.

![이미지](/assets/img/2024-09-10-LetsLearnNodejsABeginnersGuide_0.png)

이 초고속의 울트라 테크 세상에서, 새로운 프로그래밍 언어와 프레임워크를 배우는 것은 흥미 진진한 경력 기회를 열어줄 수 있습니다. 개발자 커뮤니티를 열광케 한 기술 중 하나가 Node.js입니다. 웹 개발 기술을 향상시키고 서버 측 프로그래밍에 뛰어들고 싶다면, Node.js가 훌륭한 시작점이 될 것입니다. 이 블로그에서는 Node.js가 무엇인지, 왜 배워야 하는지, 그리고 시작하는 방법을 소개합니다.

# Node.js란?

<div class="content-ad"></div>

Node.js는 Chrome의 V8 JavaScript 엔진 위에 구축된 오픈 소스, 크로스 플랫폼 JavaScript 런타임 환경입니다. 이를 통해 개발자는 서버 측에서 JavaScript 코드를 실행할 수 있습니다. 이전에는 JavaScript가 주로 클라이언트 측 개발에 사용되었지만, 지금은 백엔드 개발에도 강력한 도구로 사용됩니다. 간단한 API부터 복잡한 웹 애플리케이션까지 모든 처리를 다룹니다.

# Node.js 학습의 장점

다음은 Node.js를 배워야 하는 몇 가지 중요한 이유입니다:

- 어디서나 JavaScript: 이미 프론트엔드 개발에 JavaScript를 알고 있다면, Node.js를 배우면 동일한 언어를 백엔드 개발에 사용할 수 있어 학습 곡선이 더 쉬워집니다.
- 빠르고 확장 가능: Node.js는 가벼운 아키텍처와 이벤트 기반, 차단되지 않는 I/O 모델로 빠르고 확장 가능한 네트워크 애플리케이션을 구축합니다.
- 큰 생태계: npm(Node Package Manager)을 통해 Node.js에는 많은 라이브러리와 모듈이 있습니다. 이는 개발을 간소화하며 프로세스를 가속화하는 미리 만들어진 솔루션을 제공합니다.
- 현대 웹 애플리케이션에 이상적: Express.js와 같은 프레임워크를 사용하여 마이크로서비스, RESTful API, 또는 풀 스택 앱을 개발할 때 Node.js는 빠르고 확장 가능하며 유지 관리하기 좋은 애플리케이션을 만드는 데 완벽합니다.

<div class="content-ad"></div>

# Node.js 시작하기 위한 단계별 가이드

준비는 되셨나요? Node.js 여정을 시작하기 위한 단계별 가이드를 소개합니다.

## 1. Node.js 설치하기

먼저 컴퓨터에 Node.js를 설치해야 합니다. 공식 Node.js 웹사이트에서 최신 버전을 다운로드해주세요.

<div class="content-ad"></div>

## 2. 기본 JavaScript 배우기

Node.js에 뛰어들기 전에 JavaScript 기본 개념을 이해해야 합니다. Node.js는 JavaScript를 실행하기 때문에 변수, 함수, 반복문, 객체와 같은 개념을 알아두는 것이 중요합니다.

## 3. Node.js 기초 배우기

Node.js를 설치한 후에는 기초부터 시작하세요:

<div class="content-ad"></div>

- 모듈: Node.js는 모듈식 아키텍처를 가지고 있어 프로젝트에서 모듈을 가져와 사용할 수 있습니다. 내장 모듈인 http, fs(파일 시스템) 및 path와 같은 모듈을 익혀봅시다.
- 이벤트 루프: Node.js는 이벤트 기반 모델로 구축되어 있습니다. 이벤트 루프를 이해하는 것은 Node.js가 비동기 작업을 어떻게 처리하는지 배우는 데 중요합니다.
- NPM: npm을 사용하여 제3자 패키지를 설치하고 프로젝트에서 종속성을 관리하는 방법을 익히세요.

## 4. 첫 번째 애플리케이션 만들기

기본 사항에 익숙해지면, 이제 첫 번째 앱을 만드는 것이 좋습니다! Node.js를 사용하여 HTTP 서버를 만드는 것이 시작하기 좋은 곳입니다. 간단한 예제를 살펴보겠습니다:

```js
const http = require('http');

const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello, World!\n');
});

server.listen(3000, () => {
    console.log('Server running at http://localhost:3000/');
});
```

<div class="content-ad"></div>

이 코드는 포트 3000에서 수신되는 요청에 "Hello, World!"로 응답하는 웹 서버를 생성합니다.

## 5. Express.js 설치 및 설정

Node.js는 서버 측 응용 프로그램을 위한 기반을 제공하는 반면, Express.js는 Node.js 위에 구축된 웹 응용 프레임워크로 웹 서버 생성 프로세스를 간단화합니다.

Express.js를 설치하고 설정하는 방법은 다음과 같습니다:

<div class="content-ad"></div>

## 단계 1: Express 설치하기

Express를 설치하기 위해서는 먼저 프로젝트를 npm으로 초기화해야 합니다. 프로젝트를 위한 새 디렉토리를 만든 후 다음 명령을 실행해주세요:

```bash
mkdir myapp
cd myapp
npm init -y
```

이 명령은 기본 설정으로 프로젝트를 초기화합니다. 그런 다음 Express를 설치하려면 다음 명령을 실행하세요:

<div class="content-ad"></div>

```js
npm install express --save
```

이 명령을 실행하면 Express가 설치되고 package.json 파일에 종속성으로 추가됩니다.

## Step 2: 기본 Express 앱 만들기

Express를 설치한 후, 기본 Express 애플리케이션을 만들 수 있습니다. 프로젝트 디렉토리의 루트에 app.js라는 파일을 생성하고 다음 코드를 추가하세요:

<div class="content-ad"></div>

```js
const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send('Hello, Express!');
});

app.listen(3000, () => {
    console.log('Express server running at http://localhost:3000/');
});
```

이 코드는 포트 3000에서 수신 대기하는 Express 서버를 설정하고 루트 URL을 방문하면 "Hello, Express!"로 응답합니다.

## 단계 3: Express 앱 실행

Express 앱을 실행하려면 터미널에서 다음 명령을 실행하십시오:

<div class="content-ad"></div>

```js
node app.js
```

이제 브라우저를 열고 http://localhost:3000/ 로 이동하세요. 페이지에 "Hello, Express!"가 표시되어야 합니다.

## 6. 더 고급 Node.js 기능 탐색

기본 애플리케이션 구축에 익숙해지면, 더 고급 Node.js 기능을 탐색해보세요:

<div class="content-ad"></div>

- 데이터베이스 작업: MongoDB, MySQL 또는 PostgreSQL과 같은 데이터베이스에 Node.js를 연결하는 방법을 배우세요.
- 인증 및 보안: 사용자 인증을 구현하고 응용 프로그램을 안전하게 보호하세요.
- 클라우드에 배포: Node.js 앱을 Heroku, AWS 또는 DigitalOcean과 같은 클라우드 플랫폼에 배포하는 방법을 발견하세요.

# 결론

Node.js는 모든 웹 개발자가 배울 가치가 있는 강력하고 다양한 기술입니다. 실시간 애플리케이션, RESTful API 또는 확장 가능한 마이크로서비스를 구축하더라도 Node.js는 작업을 효과적으로 수행하기 위한 도구와 생태계를 제공합니다. 이 단계별 가이드를 따라가면 Node.js를 숙달하고 개발 도구상에서 가치 있는 기술을 추가할 수 있습니다.

즐거운 코딩하세요!

<div class="content-ad"></div>

# Stackademic 🎓

끝까지 읽어 주셔서 감사합니다. 떠나시기 전에:

- 작가를 박수 치고 팔로우해 주시기 바랍니다! 👏
- 팔로우해 주세요: X | LinkedIn | YouTube | Discord
- 다른 플랫폼도 방문해 주세요: In Plain English | CoFeed | Differ
- 더 많은 콘텐츠는 Stackademic.com에서 확인하실 수 있습니다.

Posts