lifelog and tech

키바나를 배포했는데 별다른 에러 로그 없이 계속 probe check failed 가 나는 상황에, 실제 파드(포드) 안에서는 서비스 포트(port: 5601)로 정상 응답 확인되며 포드 밖에서는 사설아이피로 방화벽이 모두 허용되있으며 배포된 pod 아이피의 해당 포트 및 서비스 uri로 connection refused가 나는 상황이면,

컨피그맵(kibana-config로 생성했다.)으로 마운트된 kibana.yml 에 server.host: "0.0.0.0" 을 추가 및 배포하여 이를 해결할 수 있다.

pod description (에러 상황): dial tcp x.x.x.x:5601 connect: connection refused

키바나 내부 포드(pod)에 들어가 본다.

kubectl exec -it <pod name> -n <your namespace> -- /bin/bash

들어가면 호스트네임이 보이지만 확인차 hostname 명령어를 쳐서 확인할 수도 있다. (여기서는 hostname: kibana-0)

[해결 resolution]

kubectl edit cm kibana-config -n <your namespace>

apiVersion: v1
data:
  kibana.yml: |
    server.host: "0.0.0.0"

위 세팅으로 새로 배포시 이제는 포드 안에서 호스트 네임으로 요청해도 localhost 요청시와 같이 동일하게 정상 응답이 반환되며, 지정한 로드밸런서 타겟그룹에도 아이피가 자동 등록되어 healthy 상태로 확인되었다.

문제 해설:

localhost:5601로 로컬 호스트에서 Kibana에 액세스할 수 있지만 kibana-0:5601로는 외부에서 액세스할 수 없는 상태입니다. kibana-0는 호스트 네임이고 배포시 정한 이름입니다. 

이는 Kibana가 동일한 시스템의 연결만 허용하는 루프백 인터페이스에서만 수신(listening)하기 때문일 수 있습니다.

sudo netstat -tlnp | 명령을 실행하여 Kibana가 수신 대기 중인 인터페이스를 확인할 수 있습니다. 포드 내부의sudo netstat -tlnp | grep 5601을 하여 Kibana가 127.0.0.1에서만 수신하는 경우 모든 인터페이스(0.0.0.0) 또는 포드에 액세스하는 데 사용하는 특정 인터페이스에서 수신하도록 구성을 수정해야 합니다.

모든 인터페이스에서 수신 대기하려면 kibana.yml 구성 파일을 수정하고 server.host 옵션을 0.0.0.0으로 설정하면 됩니다. 이렇게 변경한 후 구성을 적용하려면 Kibana를 다시 시작해야 합니다.



It seems that you are able to access Kibana on the local host with localhost:5601, but not from the outside with kibana-0:5601. This could be because Kibana is only listening on the loopback interface, which only allows connections from the same machine.

You can check which interfaces Kibana is listening on by running the command sudo netstat -tlnp | grep 5601 inside the pod. If Kibana is only listening on 127.0.0.1, then you will need to modify its configuration to listen on all interfaces (0.0.0.0) or the specific interface that you are using to access the pod.

To listen on all interfaces, you can modify the kibana.yml configuration file and set the server.host option to 0.0.0.0. For example:After making this change, you will need to restart Kibana for the configuration to take effect.

만약 어떤 조정을 위해서 배포될 pod 안의 /etc/sysctl.conf 값을 변경하고 싶은데 read-only filesystem 이라고 로그 확인되면서 배포 커맨드가 적용되지 않는 경우, 그러나 배포 시마다 새로운 pod에 해당 값을 고정으로 적용이 필요한 경우,

컨피그맵으로 해당 값 매칭하여 볼륨 마운트 추가 하는 방법이 가능하다.

컨피그맵 생성 예시 (명령어 혹은 yaml 배포 이용):

apiVersion: v1
kind: ConfigMap
metadata:
  name: sysctl-cm
data:
  sysctl.conf: |
    net.ipv6.conf.all.disable_ipv6=1

FYI it's possible that the established IPv6 connections were created before the net.ipv6.conf.all.disable_ipv6 sysctl option was set. The sysctl option disables the IPv6 protocol on the network interface, but it doesn't necessarily terminate existing connections.

Additionally, some applications may still try to establish IPv6 connections even if it's disabled on the network interface. This can be due to the application's configuration or the way it's programmed.

배포 yaml 파일 Deployment 항목(pod배포 항목)의 spec, 컨테이너 밑의 volumeMounts에 추가한다.

          volumeMounts:
            - name: sysctl-conf
              mountPath: "/etc/sysctl.conf"
              subPath: sysctl.conf

마운트할 대상 볼륨의 컨피그 맵 정의를 volumes 밑에 추가한다.

      volumes:
        - name: sysctl-conf
          configMap:
            name: sysctl-cm
            items:
              - key: sysctl.conf
                path: sysctl.conf

참고로 yaml 배포시 커맨드를 사용하여 무언가 설치하고 값을 추가하려는데 권한이 없어 안된다는 에러를 접하면,

runAsUser을 0 로 설정하여 최상위 권한으로 설정배포 가능하다.

예시:

스펙의 컨테이너 이미지 부분 밑에 추가하였다.

          securityContext:
            runAsUser: 0

커맨드 예시:

               command:                
               - /bin/bash
               - -c
               - apk update && apk add sudo && sysctl -w net.ipv6.conf.all.disable_ipv6=1 && sleep infinity

커맨드는 [] 묶음으로도 표현 가능하다.

command: ["/bin/bash", "-c", "echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf && sysctl -p && sleep infinity"]
    securityContext:
      privileged: true

여기서 privileged: true 는 모든 기능으로 포드를 실행하고 읽기 전용 파일 시스템을 우회하는 옵션이다.

option to run the pod with all capabilities and bypass the read-only file system.

위 과정을 거쳐 컨피그 맵을 생성하고 볼륨 마운트를 해서, 직접 포드 안에 들어가 해당 값이 적용된 것을 확인할 수 있다.

kubectl exec -it <your pod name> -n <your namespace> -- /bin/bash
bash-5.1# cat /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6=1

또한 로드밸런서(nlb)의 타겟그룹이 ipv6가 아닌 ipv4만 체크하도록 설정하려면 아래 설정을 배포 yaml 파일에 추가한다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080" # replace with the port used by your application
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 8080 # replace with the port used by your application
    targetPort: 8080 # replace with the port used by your application
  type: LoadBalancer

여기에 아래와 같이 추가로 원하는 설정을 입력할 수 있다.

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/healthcheck"

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: ?

In this example, the health check protocol is set to TCP, which means that the target group will only check IPv4. You can also specify the health check path and timeout, if needed, using the service.beta.kubernetes.io/aws-load-balancer-healthcheck-path and service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout annotations.

why the connection status of ipv6 keeps changing from established to time_wait?

In general, when a TCP connection is closed, it enters a TIME_WAIT state to ensure that all packets have been received by the other end. During this state, the connection is closed, but the socket is still bound to the local and foreign IP addresses and ports.

In the case of IPv6, the addresses used are often based on temporary interface identifiers that are periodically regenerated by the system to protect the privacy of the user. When a new identifier is generated, existing TCP connections using the old identifier are closed, which can result in a large number of TIME_WAIT connections.

To address this issue, some operating systems provide a feature called "stable privacy addresses" that maintain a stable identifier for the network interface, even if the temporary identifier changes. This can help prevent TIME_WAIT connections from being created when the temporary identifier changes.

Additionally, you may want to check if there are any network or firewall issues that could be causing the TCP connections to be closed unexpectedly or prematurely, as this can also lead to TIME_WAIT connections.

Deployment 및 StatefulSet는 Kubernetes 클러스터에서 Pod 배포를 관리하는 데 사용할 수 있는 두 개의 Kubernetes 리소스입니다.

이 둘의 주요 차이점은 애플리케이션의 인스턴스가 상호 교환 가능하고 수요에 따라 확장 또는 축소될 수 있는, 상태 비저장 애플리케이션에 배포가 사용된다는 것입니다. 배포는 포드 템플릿의 복제본 세트를 관리하고, 배포를 업데이트하면 업데이트된 포드 템플릿으로 새 복제본 세트를 생성하고 점진적으로 이전 복제본을 새 복제본으로 교체하여 전체 애플리케이션을 사용할 수 있도록 합니다.

반면에 StatefulSet는 고유한 설정과 안정적인 네트워크가 필요한 상태 저장 애플리케이션용으로 설계되었습니다. 예를 들어 데이터를 저장하는 데이터베이스 및 기타 애플리케이션이 있습니다. StatefulSet는 포드가 특정 순서로 시작되도록 하고 각 포드에는 포드가 다시 시작되거나 일정이 변경되더라도 지속되는 고유하고 안정적인 네트워크 설정이 있습니다. 이는 영구 스토리지에 의존하거나 상태 저장 데이터에 대한 특정 요구 사항이 있는 애플리케이션에 중요합니다.

요약하면 쉽게 확장 또는 축소할 수 있고 안정적인 네트워크가 필요하지 않은 상태 비저장 애플리케이션을 배포하는 경우 배포를 사용해야 합니다. 고유 설정 및 안정적인 네트워크가 필요한 상태 저장 애플리케이션을 배포하는 경우 StatefulSet를 사용해야 합니다.

The Deployment and StatefulSet are two Kubernetes resources that can be used to manage the deployment of pods in a Kubernetes cluster.

The main difference between the two is that Deployment is used for stateless applications where the instances of the application are interchangeable and can be scaled up or down based on demand. A Deployment manages a set of replicas of a pod template, and when you update the Deployment, it creates a new set of replicas with the updated pod template, and gradually replaces the old replicas with the new ones, ensuring that the application is available throughout the update process.

On the other hand, StatefulSet is designed for stateful applications that require unique identities and stable network identities. For example, databases and other applications that store data. StatefulSet ensures that the pods are started in a specific order, and each pod has a unique, stable network identity that persists even if the pod is restarted or rescheduled. This is important for applications that rely on persistent storage or have specific requirements around stateful data.

In summary, if you are deploying a stateless application that can be scaled up or down easily and does not require stable network identities, then you should use a Deployment. If you are deploying a stateful application that requires unique identities and stable network identities, then you should use a StatefulSet.

Let's create an encryption key and add a secret into a namespace in Kubernetes.

#!/bin/bash

IMAGE="docker.elastic.co/kibana/kibana:<version you want>"

encryptionkey=$(sudo docker run --rm ${IMAGE} /bin/sh -c "< /dev/urandom tr -dc _A-Za-z0-9 | head -c50") && \

kubectl create secret generic kibana --from-literal=encryptionkey=$encryptionkey -n <your namespace>

result:

And below is the process to create a certificate and mount the secret, line by line.

[command] openssl genrsa -out elastic-private.key 2048
result: Generating RSA private key, 2048 bit long modulus..

[command] openssl req -new -key elastic-private.key -out elastic-csr.pem
result: You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
Country Name (2 letter code) [XX]:KR
State or Province Name (full name) []:Seoul
Locality Name (eg, city) [Default City]:?-gu
Organization Name (eg, company) [Default Company Ltd]:Your Company Co Ltd
Organizational Unit Name (eg, section) []:BlahBlah Server
Common Name (eg, your name or your server's hostname) []:full.domain.name
Email Address []:xxx@xxxxx.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:test
An optional company name []:What You Want Co., Ltd.

[command] openssl x509 -req -in elastic-csr.pem -signkey elastic-private.key -out elastic-certificate.pem
result: Signature ok
subject=/C=KR/ST=Seoul/L=?-gu/O=\xC3\xA3Your Company Co Ltd/OU=? Server/CN=your.domain.name/emailAddress=xxxx@xxxx.com
Getting Private key

[command] kubectl create secret generic elastic-certificate-test --from-file=elastic-private.key --from-file=elastic-certificate.pem -n <your namespace>
result: secret/elastic-certificate-test created

A mount example of yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: kibana
        image: kibana:7.10.1
        env:
        - name: ELASTICSEARCH_URL
          value: http://elasticsearch:9200
        - name: ELASTICSEARCH_HOSTS
          value: http://elasticsearch:9200
        - name: SERVER_SSL_ENABLED
          value: "true"
        - name: SERVER_SSL_CERTIFICATE
          value: /usr/share/kibana/config/certs/elastic-certificate.pem
        - name: SERVER_SSL_KEY
          value: /usr/share/kibana/config/certs/elastic-private.key
        volumeMounts:
        - name: certificates
          mountPath: /usr/share/kibana/config/certs
          readOnly: true
      volumes:
      - name: certificates
        secret:
          secretName: elastic-certificate-test

kubectl describe configmap my-configmap-name -n my-namespace

Event:
  Normal   NotTriggerScaleUp  9m14s   cluster-autoscaler  pod didn't trigger scale-up: 9 max node group size reached, 1 pod has unbound immediate PersistentVolumeClaims
  Normal   NotTriggerScaleUp  4m12s (x27 over 9m4s)  cluster-autoscaler  pod didn't trigger scale-up: 1 pod has unbound immediate PersistentVolumeClaims, 9 max node group size reached
  Warning  FailedScheduling   4s (x10 over 9m16s)    default-scheduler   0/8 nodes are available: 8 pod has unbound immediate PersistentVolumeClaims.

말그대로 bound 되지 않은 PVC가 존재한다는 뜻이다.

Interpret this error(상세설명):

The first two log messages indicate that the cluster-autoscaler pod did not trigger a scale-up of the cluster because the maximum node group size has been reached and there are pods with unbound immediate PVCs. This means that there are no available nodes to schedule the new pods with unbound PVCs.
The third log message indicates that the default scheduler failed to schedule the pods because all nodes have unbound immediate PVCs.

To do:
investigate why the PVCs are not binding to any available storage resources. Check the status of your storage classes, persistent volumes, and persistent volume claims to ensure that they are configured correctly and have available capacity. You may also need to adjust the resource requests and limits for your pods to ensure they fit within the available resources. Once you have resolved the PVC binding issue, the cluster-autoscaler should be able to trigger a scale-up of the cluster to accommodate the new pods.

재생성을 위하여 PV가 삭제되는 중이었으나 계속 Terminating 상태로 삭제가 안되고 있었다.

모든 작업 완료 및 세션 만료 후 정리중이라 원래 확인과는 다를 수 있다. 아래는 terminating 상태의 예이다.

pod는 삭제했고 (replicas 0) 관련 pvc를 get해보니 이전 네임스페이스에 있던 pvc가 pending 상태였고 새로 생성한 네임스페이스에 생성된 삭제대상 pvc가 물려있는 상태였다. 

관련 pvc 둘을 모두 삭제하니 바로 해당 pv가 제대로 삭제됐다.

kubectl delete pvc [pvc-name]

그후 다시 pv를 할당하고 재 배포하여 정상 배포되었다.

pv 생성은 yaml로 생성하거나 명령어로 생성할 수 있다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-pvc
  namespace: your-namespace
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

명령어 예시:

kubectl create pvc grafana-pvc --size=1Gi -n <namespace>

storage class는 standard, gp2 등 원하는 것으로 설정한다.

한번 storage class를 설정하여 배포한 후 수정하려고 하면 바꿀수 없는(immutable) 항목이라 PersistentVoluemClain is invalid 에러가 발생하며 반영이 안된다. (Forbidden: spec is immutable after creation except resources.requests for bound claims)

compare standard with gp2:

In Kubernetes, standard and gp2 are storage classes that refer to different types of cloud storage volumes that can be attached to the cluster.
standard is a default storage class that uses pd-standard persistent disks in Google Cloud or gp2 in AWS. These volumes provide balanced performance and cost, and they are suitable for general-purpose workloads.
On the other hand, gp2 is an AWS-specific storage class that uses gp2 EBS volumes. These volumes are optimized for transactional workloads and offer higher performance than standard volumes. They also cost more per GB than standard volumes.
Therefore, when choosing between standard and gp2, it depends on your workload requirements, budget, and the cloud provider you are using.

작업중 configmap not found와 함께 마운트 실패가 난다면

  Warning  FailedMount             62s (x13 over 11m)  kubelet                  MountVolume.SetUp failed for volume "grafana-ini-cm" : configmap "grafana.ini" not found

아래 명령어로 콘피그 맵을 확인한다.

kubectl describe configmap configmap-name -n my-namespace

또한 해당 볼륨이 제대로 yaml file에 명시 되었는지도 확인한다.

예: 아래는 그라파나 관련 서비스 yaml이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: my-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:[lastest]
        volumeMounts:
        - name: grafana-ini-cm
          mountPath: /etc/grafana/grafana.ini
          subPath: grafana.ini
        ...
      volumes:
      - name: grafana-ini-cm
        configMap:
          name: grafana-config

콘피그 맵이 제대로 생성 안된 경우 아래 명령어를 참고한다.

kubectl create configmap grafana-config --from-file=/path/to/grafana.ini
kubectl get configmaps grafana-config

다음 명령어로도 새 콘피그맵 리소스를 생성 가능하다.

kubectl create cm grafana.ini --from-file=grafana.ini -n my-namespace
kubectl get cm -n my-namespace

pod 에서 eks 의 ec2 노드그룹 매칭은 nodeSelector로 EKS label 을 지정하여 설정했다.

참고로 쿠베 definition에서 그냥 selector 필드는 서비스를 해당 라벨이 있는 파드로 매칭하는 작업을 한다고 한다.

selector:
  app.kubernetes.io/name: grafana
  app.kubernetes.io/instance: grafana

그리고 NLB로 배포하였다.

apiVersion: v1
kind: Service
metadata:  
  name: grafana
  namespace: my-namespace
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-name: "grafana"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"
    service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-id,subnet-id
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
  labels:
    helm.sh/chart: grafana-x.x.x   
    app.kubernetes.io/name: grafana
    app.kubernetes.io/instance: grafana
    app.kubernetes.io/version: "x.x.1"
    app.kubernetes.io/managed-by: Helm
spec:  
  type: LoadBalancer
  ports:    
    - name: service
      port: 80
      protocol: TCP
      targetPort: 3000
  selector:
    app.kubernetes.io/name: grafana
    app.kubernetes.io/instance: grafana

해당 방식으로 했을 시 NLB 의 타겟그룹에 배포 전 아이피가 draining되면서 새로 apply 된 아이피가 자동 등록된다.

이외에 배포된 파드에 직접 들어가서 확인해보려면 아래 명령어를 이용한다.

kubectl exec -it <pod-name> -- /bin/bash

해당 파드에 배포된 컨피그파일 (예:grafana.ini)을 수정하려고 하면 "Read-only file system" 에러가 발생할 수 있다.

해당 경우 read only 파일인 grafana.ini 를 수정하려면,

kubectl cp <pod-name>:/etc/grafana/grafana.ini ./grafana.ini

하여 로컬로 갖고와서 아래 항목을 포함한 docker file을 생성하고,

FROM grafana/grafana:latest
COPY grafana.ini /etc/grafana/grafana.ini

아래 명령어로 빌드 후 푸시하고,

docker build -t my-grafana-image .

새로운 이미지를 이용해 새 파드를 띄워 확인할 수 있다.

kubectl run my-grafana-pod --image=my-grafana-image --restart=Never

이외 참고할 명령어:

라벨 별로 pod들을 필터링 하는 명령어 (두번째 줄은 example이다.)

kubectl get pods -l <label-selector>
kubectl get pods -l app.kubernetes.io/name=grafana

라벨과 함께 pod들 리스팅하는 명령어는 다음이다.

kubectl get pods --show-labels

pv를 강제 삭제처리 할때 명령어는 다음이다. (강제 삭제할 경우 데이터 손실 및 corruption 발생할 수 있으므로 삭제해도 될 상태일 때만 수행)

kubectl delete pv <pv-name> --grace-period=0 --force

pv edit

kubectl edit pv <pv-name>

kubectl get nodes 를 하니 NotReady 상태의 노드가 확인되었다.

노드의 description을 확인해보니 cni config uninitialized 가 발생한 것을 확인후 해당 노드(ec2)에 들어가 확인을 해봤다.

systemctl status kubelet 시 "Error validationg CNI config list" "Error loading CNI config file" "을 발견했다.

"Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized"

journalctl -u kubelet -f 를 하자 하기의 에러가 발생중이었다.

/etc/cni/net.d/ 밑의 콘피그 파일을 교체 후 정상적으로 해소되었다.

/opt/cni/bin/에 egress-v4-cni 파일 추가 후 정상적으로 로그가 확인되는 것으로 보여 

다시 get node를 해보니 NotReady 에서 Ready 상태로 바뀐것을 확인할 수 있었다.

표로 간단 비교:

AWS S3 복제를 사용하면 데이터 중복, 규정 준수 및 재해 복구와 같은 다양한 목적을 위해 동일하거나 다른 AWS 리전에 있는 버킷 간에 객체를 복제할 수 있습니다. AWS S3에서 사용할 수 있는 복제 유형에는 CRR(Cross-Region Replication)과 SRR(Same-Region Replication)의 두 가지 유형이 있습니다.

CRR(Cross-Region Replication)은 서로 다른 AWS 리전의 버킷 간에 객체를 복제하는 데 사용됩니다. CRR은 버킷의 모든 객체 또는 접두사 또는 태그를 기반으로 객체의 하위 집합을 복제할 수 있습니다. CRR은 여러 대상 버킷에 대한 복제를 지원하며 재해 복구 및 데이터 지역성에 사용할 수 있습니다.

동일 리전 복제(SRR)는 동일한 AWS 리전의 버킷 간에 객체를 복제하는 데 사용됩니다. SRR은 버킷의 모든 객체 또는 접두사 또는 태그를 기반으로 객체의 하위 집합을 복제할 수 있습니다. SRR은 데이터 중복, 규정 준수 및 고가용성을 위해 사용할 수 있습니다.

CRR과 SRR의 주요 차이점은 복제 대상입니다. CRR은 서로 다른 AWS 지역의 버킷에 객체를 복제하고 SRR은 동일한 AWS 지역의 버킷에 객체를 복제합니다. 이 차이는 각 복제 유형의 사용 사례에 영향을 미칩니다.

CRR은 재해 복구 및 데이터 지역성이 필요한 조직에 적합합니다. 개체를 다른 지역의 버킷에 복제함으로써 조직은 지역 중단이 발생한 경우에도 데이터를 사용할 수 있도록 보장할 수 있습니다. CRR은 데이터를 특정 지역에 저장해야 한다는 규정 요구 사항을 준수하는 데에도 사용할 수 있습니다.

반면 SRR은 데이터 중복성과 규정 준수가 필요한 조직에 적합합니다. 개체를 동일한 지역의 버킷에 복제함으로써 조직은 서비스 중단이 있거나 버킷을 사용할 수 없게 되더라도 데이터를 사용할 수 있도록 보장할 수 있습니다. SRR은 또한 데이터를 여러 위치에 저장해야 한다는 규정 요구 사항을 준수하는 데 사용할 수 있습니다.

요약하면 CRR과 SRR은 모두 AWS S3에서 데이터 관리를 위한 중요한 도구입니다. CRR은 재해 복구 및 데이터 지역성에 사용되는 반면 SRR은 데이터 중복 및 규정 준수에 사용됩니다. CRR과 SRR 사이의 선택은 조직의 특정 요구 사항과 요구 사항에 따라 다릅니다.

AWS S3 replication allows you to replicate objects between buckets in the same or different AWS regions for various purposes, such as data redundancy, compliance, and disaster recovery. There are two types of replication available in AWS S3: Cross-Region Replication (CRR) and Same-Region Replication (SRR).

CrossRegion Replication (CRR) is used to replicate objects between buckets in different AWS regions. CRR can replicate all objects in a bucket or just a subset of objects based on prefix or tags. CRR supports replication to multiple destination buckets and can be used for disaster recovery and data locality.

SameRegion Replication (SRR) is used to replicate objects between buckets in the same AWS region. SRR can replicate all objects in a bucket or just a subset of objects based on prefix or tags. SRR can be used for data redundancy, compliance, and high availability.

The main difference between CRR and SRR is the destination of replication. CRR replicates objects to buckets in different AWS regions, while SRR replicates objects to buckets in the same AWS region. This difference affects the use cases of each replication type.

CRR is suitable for organizations that require disaster recovery and data locality. By replicating objects to buckets in different regions, organizations can ensure that their data is available even in the event of a regional outage. CRR can also be used to comply with regulatory requirements that mandate data must be stored in specific geographic regions.

SRR, on the other hand, is suitable for organizations that require data redundancy and compliance. By replicating objects to buckets in the same region, organizations can ensure that their data is available even if there is a service disruption or if a bucket becomes unavailable. SRR can also be used to comply with regulatory requirements that mandate data must be stored in multiple locations.

In summary, CRR and SRR are both important tools for data management in AWS S3. CRR is used for disaster recovery and data locality, while SRR is used for data redundancy and compliance. The choice between CRR and SRR depends on the organization's specific needs and requirements.

기본적인 아마존 S3 버킷이 지원하는 오브젝트 클래스들을 정리한다.

우선 영어버전:

한글 버전:

Amazon S3 Glacier Flexible Retrieval과 AWS S3 Glacier Deep Archive의 주요 차이점은 사용 사례와 검색 시간입니다.

Amazon S3 Glacier Flexible Retrieval은 일반적으로 연간 1~2회 비동기식으로 자주 액세스하지 않는 데이터를 보관하는 데 적합한 저비용 스토리지 옵션입니다. S3 Glacier Instant Retrieval에 비해 최대 10% 저렴한 비용을 제공하지만 검색 시간은 몇 분에서 몇 시간까지 길어질 수 있습니다. 이 스토리지 클래스는 장기간 보존을 위해 많은 양의 데이터를 저장해야 하고 더 긴 검색 시간을 허용할 수 있는 조직에 이상적입니다.

반면 AWS S3 Glacier Deep Archive는 1년에 한두 번만 액세스하는 장기 데이터 아카이빙을 위해 설계되었습니다. 모든 S3 스토리지 클래스 중에서 가장 비용이 저렴한 스토리지 클래스이지만 검색 시간이 가장 길어 최대 12시간이 소요될 수 있습니다. 이 스토리지 클래스는 규정 준수 및 규정상의 이유로 데이터를 보존해야 하고 데이터에 즉시 액세스할 필요가 없는 금융 서비스, 의료 및 공공 부문과 같은 고객에게 적합합니다.

요약하면 S3 Glacier Flexible Retrieval은 가끔 비동기식으로 액세스할 수 있는 데이터를 보관하는 데 적합하고 S3 Glacier Deep Archive는 거의 액세스하지 않고 가장 긴 검색 시간을 견딜 수 있는 데이터를 보관하는 데 적합합니다.