Diademata

https://doc.akka.io/docs/akka/current/typed/cluster-membership.html

https://getakka.net/articles/clustering/cluster-overview.html

Akka 클러스터 형성 과정은 클러스터가 올바르게 초기화되고 유지되도록 보장하기 위해 여러 주요 구성 요소와 단계를 포함한다. 다음은 클러스터가 형성되는 방법, 노드의 다양한 유형의 역할, 그리고 노드 상태 및 클러스터 무결성 관리 메커니즘에 대한 설명이다.

1. 시드 노드와 비시드 노드

• 시드 노드(Seed Nodes): 잘 알려진 IP 주소/포트 조합을 가진 노드로, 클러스터 구성에서 미리 정의된다. 다른 노드가 클러스터에 가입할 때 초기 연락 점 역할을 한다.
• 비시드 노드(Non-seed Nodes): 초기에는 주소가 알려지지 않은 노드로, 클러스터를 형성하기 위해 시드 노드에 연락해야 한다.

2. 초기 클러스터 형성

• 클러스터는 시드 노드가 서로를 알고 있는 상태에서 시작한다. 예를 들어, A와 B 두 시드 노드가 있으면, 이 노드들은 서로의 존재를 인식하고 설정된다.
• 비시드 노드(C, D, E와 같은)는 적어도 하나의 시드 노드에 연락할 수 있도록 구성된다.
• 구성에서 첫 번째로 나열된 시드 노드는 반드시 작동 중이어야 한다.. 그렇지 않으면 클러스터가 형성되지 않는다. 이는 초기 시작 시 분산 브레인(scenarios) 같은 문제를 방지하기 위한 것이다.

3. 연결 설정

• 비시드 노드는 지정된 시드 노드에 연결을 시도한다. 예를 들어, C와 D 노드는 A에, E 노드는 B에 연결하도록 설정될 수 있다.
• 모든 노드는 클러스터 형성 과정을 시작하기 위해 시드 노드에 연결을 시도한다.

4. 리더 선출

• 노드가 클러스터에 합류함에 따라 리더가 선출된다.. 리더는 일반적으로 시드 노드 중 하나이며, 클러스터 상태를 관리하는 책임이 있다.
• 리더는 직접 통신할 수 있는 노드부터 시작하여 알고 있는 노드들을 활성 상태로 표시하기 시작한다.

5. 가십 프로토콜

• 클러스터 멤버십에 대한 가십(gossip) 정보가 모든 노드에 퍼지기 시작한다. 이 정보에는 어떤 노드들이 활성화되어 있고 그들의 연결 상태가 포함된다.
• 노드들은 지속적으로 통신을 하며, 각 노드가 다른 모든 노드와 연결된 메시 네트워크를 형성한다.

6. 클러스터 무결성 및 관리

• 클러스터가 운영되는 동안, 노드들은 서로에게 지속적으로 하트비트를 보내 가용성을 확인한다. 하트비트를 충분히 보내지 못하면 노드는 동료들에 의해 접근 불가능하다고 표시된다.
• 리더는 접근 불가능한 노드가 다시 접근 가능해지거나 공식적으로 클러스터에서 제거될 때까지 클러스터 결정을 중단한다. 클러스터의 상태가 일관되지 않은 경우 리더는 자신의 업무를 수행할 수 없다고 표시한다.

7. 노드 고장 및 퇴출 처리

• 노드가 접근 불가능해지면 설정된 타임아웃(auto-down-unreachable-after)을 사용하여 노드를 영구적으로 제거(다운)하기로 결정할 수 있다.
• 노드는 클러스터에서 우아하게 퇴출될 수도 있으며, 이는 노드가 접근 불가능하게 표시되는 것을 방지한다.

8. 조정된 종료

• 노드가 클러스터에서 우아하게 종료할 수 있도록 조정된 종료 프로세스를 제공한다.

git filter-branch -f --env-filter '

UPDATE_NAME="username"
UPDATE_EMAIL="user@mailadress"

if [ "$GIT_COMMITTER_EMAIL" = "old@mail.com" ]
then
    export GIT_AUTHOR_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_EMAIL="$UPDATE_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "old@mail.com" ]
then
    export GIT_AUTHOR_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_EMAIL="$UPDATE_EMAIL"
fi
if [ "$GIT_COMMITTER_NAME" = "oldusername" ]
then
    export GIT_AUTHOR_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_EMAIL="$UPDATE_EMAIL"
fi
if [ "$GIT_AUTHOR_NAME" = "oldusername" ]
then
    export GIT_AUTHOR_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_NAME="$UPDATE_NAME"
    export GIT_COMMITTER_EMAIL="$UPDATE_EMAIL"
fi

' --tag-name-filter cat -- --branches --tags

rebase를 통해서 하는 것보다 훨씬 더 수월하게 잘못 커밋된 계정을 변경할 수 있다.

git push -f

쌓인 커밋들을 다시 푸시하면 된다.

메모리 매핑 파일(Memory-Mapped File)은 파일이나 장치의 내용을 메모리 주소 공간에 매핑하는 기술이다. 이 방법을 사용하면 파일이나 장치의 데이터에 대한 접근을 마치 메모리에 직접 있는 데이터에 접근하는 것처럼 수행할 수 있다. 이는 데이터의 읽기와 쓰기 속도를 향상시킬 수 있으며, 대용량 파일 처리에 특히 유용하다.

메모리 매핑 파일을 이용한 프로세스 간 공유는 고성능의 IPC 메커니즘을 제공하며, 파일 입출력보다 훨씬 빠른 데이터 접근 속도를 가능하게 한다. 그러나 공유 데이터에 대한 동시 접근을 관리하는 것이 중요하며, 적절한 동기화 방법을 선택하여 데이터의 일관성과 무결성을 보장해야 한다.

작동 원리

1. 매핑 생성: 운영 체제는 파일의 내용을 프로세스의 가상 메모리 주소 공간에 매핑한다. 이 과정에서 실제 물리 메모리의 할당은 필요한 부분이 실제로 접근될 때까지 지연된다.
2. 데이터 접근: 프로그램은 메모리 주소를 통해 파일 데이터에 접근할 수 있게 된다. 이 때, 파일 내용은 메모리에 있는 것처럼 읽기, 쓰기, 수정이 가능하다.
3. 변경 사항 반영: 메모리에 있는 데이터에 대한 변경 사항은 시스템에 의해 자동으로 파일에 반영된다. 이는 주기적으로 또는 메모리 매핑이 해제될 때 수행될 수 있다.

장점

• 성능 향상: 메모리 매핑을 사용하면 파일 입출력(I/O) 연산이 메모리 접근 연산으로 대체된다. 이는 입출력 연산의 오버헤드를 줄이고 성능을 향상시킨다.
• 간편한 데이터 접근: 배열이나 포인터를 사용해 직접 메모리에 접근하는 것처럼 파일 데이터에 접근할 수 있어, 복잡한 파일 입출력 코드를 단순화할 수 있다.
• 대용량 파일 처리: 메모리 매핑은 파일 전체를 메모리에 로드하지 않고 필요한 부분만 로드하기 때문에, 사용 가능한 물리 메모리보다 큰 파일도 효율적으로 처리할 수 있다.

SSL FOR FREE 사이트에 도메인을 입력하고 차례 차례 순서대로 입력한다.

90일 짜리 공짜

CName 입력
Name:
_95D1090C735AB2C3856848066F6C96C0 도메인을 제외하고 입력

별칭 :  824C3264FAF387913C281A2F7F799281.AA6016E7E6E327734C6A1CE3FA469BDF.bb884888ef31b52.comodoca.com 값을 그대로 입력한다.

Install Certificate 단계에서 해당 파일을 다운로드 받는다.

3개의 파일을 서버에 올린 후 합쳐준다.

cat certificate.crt ca_bundle.crt > combined.pem

docker compose 설정에 볼륨 경로를 연결한다.

  - type: bind
    source: ./certificate
    target: /etc/nginx/ssl

Nginx 설정파일(nginx.conf)

    # XXXXX.com을 위한 서버 블록
    server {
        listen 443 ssl;
        server_name XXXXX.com www.XXXXX.com;

        ssl_certificate /etc/nginx/ssl/combined.pem;
        ssl_certificate_key /etc/nginx/ssl/private.key;

        ssl_protocols TLSv1.2 TLSv1.3;

        location / {
            proxy_pass http://127.0.0.1:9100;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    # XXXXX.com을 위한 서버 블록
    server {
        listen 80;
        server_name XXXXX.com www.XXXXX.com;
        # HTTP 요청을 HTTPS로 리다이렉트
        return 301 https://$host$request_uri;
    }

https://repost.aws/ko/knowledge-center/ec2-memory-swap-file

t2.micro 유형에 도커를 통하여 Gitlab을 설치를 하게 되면 터미널이 끊어지고 EC2가 뻗어버리는 현상이 발생한다.

이는 t2.micro RAM이 1GB 밖에 지원하지 않기 때문이다.

이 문제를 해결하려면 스왑 메모리를 고려해볼 수 있다. 스왑 메모리는 주 메모리(RAM)가 부족할 때 하드 드라이브나 SSD의 일부를 임시 메모리로 사용하여 부족한 메모리를 대체할 수 있다.

다만 디스크 I/O가 증가할 수 있으므로 성능에 단점이 발생할 수 있다.

Swap Memory 설정 방법

RAM의 크기에 따라서 Swap Memory 사이즈를 정한다.

RAM이 2GB 이하인 경우: RAM 크기의 2배.
RAM이 2GB~8GB인 경우: RAM 크기와 동일.
RAM이 8GB 이상인 경우: 필요에 따라 RAM 크기의 0.5배 ~ 1배.

1.EC2 t2.micro 유형은 1GB 바이트이기 때문에 Swap Memory 사이즈를 2GB로 정한다.

sudo dd if=/dev/zero of=/swapfile bs=128M count=16

2.Swap 파일의 읽기 및 쓰기 권한을 업데이트한다.

sudo chmod 600 /swapfile

3.Swap 영역을 설정합니다.

sudo mkswap /swapfile

4.Swap 공간에 스왑 파일을 추가하여 Swap 파일을 즉시 사용할 수 있도록 한다.

sudo swapon /swapfile

5./etc/fstab 파일을 편집하여 부팅 시 Swap 파일을 시작합니다.

sudo vi /etc/fstab

파일 끝에 다음 줄을 새로 추가하고 파일을 저장한 다음 종료합니다.

/swapfile swap swap defaults 0 0

6.free 명령어로 메모리 상태를 확인하면 된다.

서비스를 실행하려면 .service 파일이 필요하다.

서비스 파일이 없이 서비스를 등록하려고 하면 Unit not found. 해당 에러가 발생한다.

systemctl enable ba.internalserverd

파일을 생성해준다. 현재 개인 프로젝트의 서버 등록을 위해 ba.internalserverd.service 로 파일을 만들어준다.

vi /etc/systemd/system/ba.internalserverd.service

[Unit]
Description=BA.InterServer.dll

[Service]
WorkingDirectory=/ba/bin/interserver
ExecStart=/usr/bin/dotnet /ba/bin/interserver/BA.InterServer.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=BA.InterServer

[Install]
WantedBy=multi-user.target

파일을 생성 후에 다시 등록

systemctl enable ba.internalserverd

서비스를 실행시킨다.
systemctl start ba.internalserverd

클러스터 인덱스

• 데이블의 데이터는 클러스터형 인덱스 키 열별로 정렬된 순서로 저장
• 테이블이나 뷰는 하나의 클러스터형 인덱스만 있다.
• 클러스터형 인덱스가 정의된 경우에만 데이터가 정렬
• 데이터가 정렬되어 있기에 검색 속도가 빠르다
• 데이터 삽입시 테이블의 모든 데이터들을 정렬해야한다.

논 클러스터 인덱스

• 순서대로 정렬되어 있지 않다.
• 한 테이블에 여러개 생성 가능하다.
• 인덱스를 저장할 추가적인 공간이 필요하다.
• 클러스터 인덱스와는 달리 삽입시 데이터 정렬을 하지 않고 인덱스 생성을 해야한다.

최근 애플 앱 심사 거절 이유로 회원탈퇴를 하는 경우 revoke token 처리를 해야한다고 한다.

클라단에서 처리를 못하기에 서버단에서 처리하기로 결정하고 서버에서 처리한다.

https://developer.apple.com/documentation/sign_in_with_apple/revoke_tokens

    //client_secret 생성
    public static string GenerateAppStoreJwtToken(string teamId, string keyId, string clientId, string p8key)
    {
        var aud = "https://appleid.apple.com";
        string iss = teamId;
        string sub = clientId;
        string kid = keyId;

        IList<Claim> claims = new List<Claim> {
            new Claim ("sub", sub)
        };

        try
        {
            var cngKey = CngKey.Import(Convert.FromBase64String(p8key), CngKeyBlobFormat.Pkcs8PrivateBlob);

            var signingCred = new SigningCredentials(new ECDsaSecurityKey(new ECDsaCng(cngKey)),
                                                    SecurityAlgorithms.EcdsaSha256);

            var token = new JwtSecurityToken(iss,
                                            aud,
                                            claims,
                                            DateTime.Now,
                                            DateTime.Now.AddDays(180),
                                            signingCred);

            token.Header.Add("kid", kid);
            token.Header.Remove("typ");

            JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler();

            return tokenHandler.WriteToken(token);
        }
        catch(Exception ex)
        {
            //로그 출력
            return null;
        }
    }

    private async Task<bool> SendAppleRevokeToken(string token)
    {

        var clientSecret = GenerateAppStoreJwtToken(AppleTeamId,
                                                    AppleTeamId,
                                                    AppleClientId,
                                                    ApplePrivateKey);
                                                    
        if(string.IsNullOrEmpty(clientSecret) == true)
        {
            Log.Error($"failed to generate token!");
            return false;
        }
        var parameters = new Dictionary<string, string>
        {
            { "client_id", AppleClientId },
            { "client_secret", clientSecret },
            { "token", token },
            { "token_type_hint", "access_token" }
        };
        //post send
        var response = await HttpRequester.Get(@"https://appleid.apple.com/auth/revoke", parameters);

        return string.IsNullOrEmpty(response) == false;
    }

AWS 설정

1. IAM 역할 추가
   • CodeDeploy
     1. AWSCodeDeployRole
   • EC2Deploy
     1. AmazonEC2RoleforAWSCodeDeploy
     2. CouldWatchFullAccess
     3. AWSCodeDeployFullAccess
     4. AWSCodeDeployRole
   • CodeDeploy는 CodeDeploy 설정에 역할에 들어가는 것이고 EC2Deploy인 경우는 EC2 인스턴스에 들어가는 역할이다.
2. CodeBuild 설정
   • 아티팩트 설정
     1. secondary-artifacts가 작성될 시에 아티팩트 추가 기능을 사용하여 buildspec.yml에 작성된 아티팩트 키와 맵핑 시켜야 한다.
3. CodeDeploy 설정
   1. appspec.yml은 배포된 압축 파일을 풀었을때 root에 있어야 한다.
   2. root : C:\ProgramData\Amazon\CodeDeploy\d1f6949f-bb5e-45b1-b60e-eeaff407a9f0\d-59GUNXLYA\deployment-archive\ 경로로 배포가 된다.
   3. 배포될 EC2 인스턴스에 IAM 역할 추가(EC2Deploy)
   4. 배포될 EC2 인스턴스에 CodeDeloyAgent 설치 : 
      • 다운로드: https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/codedeploy-agent-operations-install-windows.html#codedeploy-agent-operations-install-windows-direct-link)
   5. powershell.exe -Command Get-Service -Name codedeployagent 명령어로 agent 가 작동 중인지 확인한다.
4. CodeDeploy 실패 경우
   
   1. views events => ApplicationStop 에서 아무런 오류코드 없이 실패하는 경우
      1. ec2 인스턴스를 재부팅 한다.
      2. 'CodeDeploy agent did not find an AppSpec file within the unpacked revision directory at revision-relative path “appspec.yml” ' 에러가 나오는 경우
         1. https://stackoverflow.com/questions/53501365/codedeploy-agent-did-not-find-an-appspec-file-within-the-unpacked-revision-direc
         2. S3 버킷에 올라간 zip 파일의 root에 appspec.yml 파일 확인을 한다.
         3. ec2 인스턴스를 재부팅
5. CodePipeline 설정

※ yml 설정 파일 작성시 주의 사항

1. 띄어쓰기로 계층 표현을 함으로써 작성시에 유의할 것
2. 문단의 종료는 /r/n가 아닌 리눅스 방식의 /n이 들어가야한다. /r/n이 들어가는 경우 aws에서 파싱을 못하고 에러 뱉음.
3. yaml은 사용 안했으면 좋겠음.

buildspec.yml

예시)

https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

appspec.yml

예시)

배포시 실행되는 스크립트

• appspec.yml에 적힌 hook 이벤트 중 ApplicationStart 실행시에 실행되는 프로그램
• 작성된 기능
  1. 배포된 파일이 실제 서버 폴더로 복사 되기 전 현재 서버 폴더 백업
  2. 시작한 후 배포된 파일을 실제 서버 경로에 복사
  3. 서버 프로그램 시작
  4. config.txt에서 설정
• bat 파일 실행시에 background로 어플리케이션이 실행이 되는데 변경해야함.

1.단일 책임 원칙(SRP, Single Responsibility Principle)

클래스를 변경해야 할 이유는 단 한가지여야 한다.

이 원칙은 클래스 응집도와 관련이 있다. 책임이 하나뿐인 응집도 높은 클래스를 만든다면 이 원칙을 충족시키는 것이다.

2.개방 폐쇄 원칙(OCP, Open-Closed Principle)

소프트웨어의 구성요소는 확장에 관해서는 열려있어야 하고 변경에 대해서는 닫혀있어야 한다.

클래스 상속을 생각해보면 부모 클래스가 닫힌 부분이고 자식 클래스는 열린 부분이다. 부모 클래스를 굳이 변경하지 않더라도, 자식 클래스의 행동을 변화시키면 확장할 수 있다.

3.리스코프 치환 원칙(LSB, Liskov Substitution Principle)

파생 자료형은 기본 자료형과 치환 할 수 있어야한다.

부모 클래스로 치환한 상태에서도 정상 작동해야 한다라는 것이다.

부모 클래스에서 자식 클래스로 무리하게 다운캐스트해야 할 경우에는 리스코프 치환 원칙에 위반된다. 클래스는 항상 부모 클래스 그대로의 상태에서 작동해야 한다. 상속 관계가 복잡해지면 이 원칙을 위반하는 클래스가 만들어질 가능성이 커진다.

4.인터페이스 분리 원칙(ISP, Interface Segregation Principle)

클라이언트가 사용하지 않는 멤버 함수의 의존을 클라이언트에게 강요하면 안된다.

클래스는 최소한의 멤버 함수로만 구성되어야 한다.

5.의존 관계 역전 원칙(DIP, Dependency Inversion principle)

상위 모듈은 하위 모듈에 의존하지 않는다. 두 모듈 모두 별도의 추상화된 것에 의존한다.

상위 모듈이란 사용하는 측, 하위 모듈이란 사용되는 측의 모듈을 가르킨다. 보통 상위 레벨 모듈은 하위 레벨 모듈을 이용해 만들어진다.

그런데 상위 모듈이 하위 모듈에 직접 결합해 버리면 하위 모듈의 변경이 상위 모듈에 영향을 미친다. 이때는 상위 모듈과 하위 모듈의 관계를 역전시켜 소결합하는 것이 좋다.

의존 관계를 역전시키려면, 일단 사용자 측에 있는 상위 레벨 모듈의 요구에 맞춰 추상 인터페이스를 작성한다. 생성한 추상 인터페이스를 거쳐 하위 모듈을 사용한다. 이때 추상 인터페이스는 반드시 상위 레벨의 모듈이 소유해야한다.