'전체 글'에 해당하는 글 2045건

OpenSearch 의 역사

 

OpenSearch 는 실시간 어플리케이션 모니터링, 로그 분석 및 웹 사이트 검색에 유용한 오픈 소스이다. 데이터 수집, 보안, 검색, 집계, 확인, 분석 등이 쉽게 가능하다. 기존의 Elasticsearch / Kibana 가 라이센스를 변경하면서 오픈 소스로서의 업데이트를 중단하자, AWS 가 마지막 오픈 소스 버전(Elasticsearch 7.10.2 및 Kibana 7.10.2) 을  Apache License, Version 2.0(ALv2) 하에서 릴리스하여 관리/업데이트 하는 중이다. Elasticsearch / KibanaOpenSearch / OpenSearch Dashboard 라는 이름으로 변경되었으며, 기존의 Apache Lucene 검색 라이브러리도 동일하게 사용한다.

 

 

OpenSearch 도메인 생성

 

도메인 생성시, 인스턴스 유형, 인스턴스 수, 스토리지 할당 등을 지정할 수 있다.

 

  • Multi-AZ 를 사용하는 경우 전용 프라이머리 노드가 활성화 되어 있으며, 프로덕션 도메인의 경우 3개의 노드를 권장한다. (가동 중지를 막기 위해 3개의 노드를 구성한다.)
  • 데이터 노드의 개수도 3의 배수를 권장한다. (전용 프라이머리 노드와 인스턴스 패밀리를 동일하게 묶는 것 추천)

 

기타 나머지 부분들은 설정 항목마다 잘 설명되어 있다.

 

 

OpenSearch 의 장애

 

흔히 OpenSearch 에서의 장애라 함은, 클러스터 상태에 빨간 불이 켜지거나, 쓰기에 빨간 불이 켜지는 것을 말한다. 주로 JVM 메모리가 부족하거나 공간이 부족해진 경우가 대부분이 었는데, EBS 볼륨을 늘리거나, 오래된 index 들을 삭제하면서 버텨왔다. 하지만 index 도 특정기간 이상 보관해야 하기 때문에 지울 수 없게 됐고, 트래픽도 극에 달하니 다른 방법을 모색해야 했다.

 

Warning : VM 메모리 압력이 80%를 초과했습니다. 30분 동안 92%를 초과하면 클러스터에 대한 모든 쓰기 작업이 차단됩니다. 클러스터 안정성을 최적화하려면 클러스터에 대한 트래픽을 줄이거나 도메인을 확장하세요. 자세한 내용은 https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-events.html#monitoring-events-high-jvm을(를) 참조하세요.

 

 

UltraWarm 활용

 

OpenSearch 에서는 오래된 데이터의 분리 보관을 위해 UltraWarm / Cold Storage 라는 대안을 제공한다. (이 대안은 읽기 전용이므로 Warm Index 에 쓰기를 시도하면 에러가 발생한다.)

 

  • 데이터 노드 (hot) : 읽기 속도가 빠르지만 고비용
  • UltraWarm : 읽기 속도는 보통이나, 데이터 노드보다 90% 저렴 (스토리지 + S3 캐싱)
  • Cold Storage : 읽기 속도는 느리나, UltraWarm보다 더 저렴 (S3 사용)

 

실제 warm index 검색 속도는 특별히 느리다는 체감을 하지는 못했다.

 

실제 빈번하게 이루어지는 데이터 조회 기간은 대부분 한달 이내였기 때문에, 넉넉하게 2달전 데이터들은 모두 별도 보관하려고 한다. (참고로 현재 데이터 보관 정책은 기본적인 데이터는 1년, 로그인 관련 데이터는 2년, 계정관련 데이터는 5년 보관이다.)

 

기본적으로 매달 새로운 index (server1_dev_2401, ...) 를 만들고 index_pattern (server1_dev_*, ...) 으로 조회하고 있었다.

 

server1_dev_2401
server1_dev_2402
server1_dev_2403
...
server1_prod_2401
server1_prod_2402
server1_prod_2403
...

 

아래는 63일 뒤에 Ultrawarm 스토리지로 이동하며, 365일 뒤에 인덱스를 삭제하는 스크립트이다.
새로 생성되는 Index 들도 ism_template 에 매칭된다면 해당 정책이 적용된다.

 

1. 클러스터에서 UltraWarm / Cold Storage 활성화 체크

 

 

2. OpenSearch Dashboard 에서 Index State Management (ISM) 정책 생성

 

{
  "policy": {
    "description": "Move indices to warm storage after 60 days and delete after 1 year",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          {
            "state_name": "warm",
            "conditions": {
              "min_index_age": "63d"
            }
          }
        ]
      },
      {
        "name": "warm",
        "actions": [
          {
            "warm_migration": {}
          }
        ],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": {
              "min_index_age": "365d"
            }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          {
            "delete": {}
          }
        ],
        "transitions": []
      }
    ],
    "ism_template": [
      {
        "index_patterns": ["server1_*", "server2_*"],
        "priority": 100
      }
    ]
  }
}

 

3. 정책 적용할 index 선택 및 적용 / 확인

 

 

4. 모니터링

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

AWS 를 운용하고 있다면 도메인 역시 AWS 에서 함께 관리하는 것이 아무래도 편하다. 혹시라도 가비아나 카페24 같은 곳에서 도메인을 등록해 놓았다면, AWS 로 이전시키는 것이 좋다.

 

route 53 으로 도메인을 이전하려면 다음 조건을 충족해야 한다.

 

  • 타 사이트에서 해당 도메인 등록 후 60일이 지나야 한다.
  • 타 사이트에서 해당 도메인에 잠금이 해제되어 있어야 한다.
  • 해당 도메인 소유자 이메일로 인증을 받을 수 있어야 한다.

 

ICANN(국제인터넷관리기구) 정책에 따라, 도메인에 새로운 소유자가 등록되면 보안 강화를 위해 60일간 자동으로 기관 이전 잠금 상태(Client Transfer Prohibited)가 된다. 그 후에도 이메일 변경 및 소유권 이전이 진행되면, 그 시점부터 다시 60일간 도메인이 잠금 설정된다.

 

AWS 로 도메인 이전시 비용은 따로 추가되지 않지만, 도메인을 1년 자동 연장하는 비용이 청구된다.

 

 

1. Route 53 Hosted Zone 설정

 

미리 호스팅 영역을 생성하고, 기존 서비스의 다운 타임이 최대한 발생하지 않도록 기등록된 도메인 사이트에서 DNS 설정 등을 Route 53 에 미리 생성해 놓는다.

 

 

 

2. Route 53 네임서버(NS) 로 변경

 

ex)
ns-426.awsdns-53.com.
ns-1769.awsdns-29.co.uk.
ns-991.awsdns-59.net.
ns-1415.awsdns-48.org.

 

 

기등록된 도메인 사이트의 네임서버 주소를 Route 53 의 네임서버 주소로 변경한다. (이 과정을 거치지 않고 도메인을 이전하면 계속해서 기등록된 네임서버 주소를 바라보게 된다.) NS 주소를 변경할 때는 최대한 빠른 시간에 변경되도록 TTL 시간을 300초 정도로 단축시키는 것도 NS 가 빨리 전환되는데 도움이 된다.

 

만약 NS 주소가 어떠한 이유로 전환이 되지 않고, whois 정보에서도 계속해서 기등록된 NS 주소로 조회된다면, 도메인 이전 후에 [등록된 도메인] 에서 네임서버를 변경한다.

 

 

 

3. Route 53 에서 도메인 이전 요청

 

[Route 53 시작하기] - [도메인 이전] - [도메인 이전 가능성 검사] - [가능하면 이전 진행]

이 과정에서 기 등록된 도메인 사이트에서 소유주의 이메일로 [인증 코드] 검증이 필요할 수 있다.

이전 신청 완료 후 도메인 소유주 이메일에서 이전 확인 메일 동의가 필요하다.

 

 

 

4. Route 53 에서 도메인 이전 확인

 

[Route 53] - [도메인] - [대기 중인 요청] 에서 이전 상태를 하염없이 바라본다... 도메인 이전에는 최대 10일이 소요될 수 있다고 하나, 1시간 정도 소요되었다.

 

Waiting for the current registrar to approve the transfer. This can take up to 10 days depending on the TLD and the current registrar.

 

 

중간중간 nslookup, dig 명령 등을 사용해서 네임서버가 변경 됐는지도 확인해 본다.

 

% nslookup -type=NS example.com
...

% dig example.com NS
...

% dig example.com NS @8.8.8.8
; <<>> DiG 9.10.6 <<>> example.com ns @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.			IN	NS

;; ANSWER SECTION:
example.com.		17164	IN	NS	a.iana-servers.net.
example.com.		17164	IN	NS	b.iana-servers.net.

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 23 17:10:20 KST 2024
;; MSG SIZE  rcvd: 88

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

API Gateway + Lambda

Server/AWS 2024. 12. 18. 21:39

API 가 딱 한 개만 필요하다면... 어떤 방법으로 api 서버를 구축하는 것이 좋을까. ec2 + framework 는 생각만 해도... 생각하고 싶지도 않고... 역시나  API Gateway + Lambda  이다. DB(Mysql) 에 insert 할 api 를 하나 만들어야 하는 상황인데... API Gateway 로 요청 받고 람다를 실행시켜서 DB에 insert 시킨 후 응답해 주면 완료...

 

 

1. API Gateway

 

  • API 타입 http-api, rest-api 중 요청 제한을 위해 적어도 api-key 정도는 설정하는 것이 좋겠다. http-api 는 api-key 를 지원하지 않으므로 rest-api 선택. (그 외에도 res-api 를 선택할 이유는 많지만, 정말 아~무것도 필요없다면 http-api 쓰면 됨.)
  • resource 에서 경로 만들고 요청 메서드 하나 만들고 api key 췍~ 스테이지 배포 후 API 키 / 실행 계획 작성 / 스테이지 연결
  • api 키는 프론트 요청 헤더(x-api-key) 에 담아서 전달 받으면 됨. 그렇지 않으면 요청 거부됨.'

 

{
    "message": "Forbidden"
}

 

 

 

2. Lambda Layer

 

  • 람다 함수 런타임은 간단하게 Nodejs 사용할 생각.
  • mysql 연결을 위해 mysql2 패키지를 설치해야 하는데 재사용을 위해 레이어를 하나 생성한다.
  • 호환 런타임 잘 선택하고, 아래 zip 파일 업로드. (기타 필요한 라이브러리도 설치)

 

$ mkdir nodejs
$ cd nodejs
$ npm init -y
$ npm install mysql2
$ zip -r mysql2-layer.zip .

 

 

nodejs 최신버전의 경우 index.mjs 파일이 생성되므로, ESM 모듈 사용하려면, 압축하기 전에 package.json 에 아래 타입을 명시한다.

 

{
    "type": "module"
}

 

 

require is not defined in ES module scope, you can use import instead 에러 시 참고.

 

 

3. Lambda Function

 

nodejs 람다 함수를 하나 생성하고, 코드 가장 하단 설정에서 위에 업로드 한 layer 를 선택한다. index.mjs 파일 작성 후 배포.

 

import mysql from 'mysql2/promise';

const pool = mysql.createPool({
  host: 'host',
  user: 'user',
  password: 'password',
  database: 'database',
  port: 'port'
});

export const handler = async (event) => {

  const { id, name } = JSON.parse(event.body);

  try { 
    const query = 'INSERT INTO user (id, name) VALUES (?, ?)';

    const [results] = await pool.execute(query, [id, name]);
    return {
      statusCode: 200,
      body: JSON.stringify({ code: 200, message: 'ok', data: results })
    };
  } catch (err) {
    return {
      statusCode: 200,
      body: JSON.stringify({ code: 500, message: 'error: db insert', error: err.message })
    };
  }
};

 

 

4. API Gateway - Lambda 연결

 

API Gateway 해당 리소스의 통합 요청에서 생성한 람다 함수를 연결한다. request payload 를 람다 함수에 전달하기 위해  [Lambda 프록시 통합] 활성화 . 설정 후 [API 배포].

 

 

5. 테스트

 

postman 에서 header 에 api 키를 담아 stage url/resource 경로로 api 테스트를 진행한다.

 

{
    "code": 200
    "message": "ok",
    "data": {
        "fieldCount": 0,
        "affectedRows": 1,
        "insertId": 0,
        "info": "",
        "serverStatus": 2,
        "warningStatus": 0,
        "changedRows": 0
    }
}

 

 

6. 디버깅

 

만약 정상적인 응답을 받지 못했다면, 스테이지에서 cloudwatch logs 를 켜고, 로그를 확인한다. 처음 실행할 때는 cloudwatch 로깅에 대한 role 이 필요하다. IAM 에서 AmazonAPIGatewayPushToCloudWatchLogs 정책으로 role 하나 만들고, API Gateway 좌측 메뉴 설정에서 해당 role 선택.

 

 

7. 게이트웨이 응답

 

필요시 [게이트웨이 응답] 메뉴에서 request 에러시 응답값을 커스텀 할 수 있다.

 

 

8. CORS error

 

Access to fetch at 'https://11111111.execute-api.ap-northeast-2.amazonaws.com/dev/request' from origin 'http://localhost:8888' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

 

실전은 다르다. 매번 ok 사인 주는 postman 은 실전과 다르다. 프로젝트 할 때마다 괴롭히는 cors 에러... 메서드 선택 후 CORS 를 활성화 시키면 되구용...

 

 

 

 프록시 통합(proxy integrations)  이 설정되었기 때문에, 람다에서의 응답 헤더가 적용된다. 하여 람다에 적절한 응답 헤더가 추가되어야 한다.

 

return {
  statusCode: 200,
  headers: {
    "Access-Control-Allow-Headers" : "Content-Type,X-Api-Key",
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "OPTIONS"
  },
  body: JSON.stringify({ code: 200, message: 'ok', data: results })
};

 

. 끝 .


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Elastic Beanstalk

Server/AWS 2024. 11. 27. 21:28

AWS 에서 웹 어플리케이션 배포하는 방법.

 

  1. EC2
  2. Elastic Beanstalk
  3. ECS
  4. EKS

 

이 중 그나마 간편하고, 빠르게 배포하는 방법은 1번 아니면 2번 일 것이다. 빠르게 웹 공유가 필요하여 간만에 Elastic Beanstalk 를 썼는데 완전 삽질스.

 

일단 2024년 10월 1일 이후로는, EC2 Auto Scaling 서비스의 시작 구성이 사라지고, 시작 템플릿으로 대체되기 때문에, EB 환경을 새로 생성한다면 시작 템플릿(launch template) 옵션을 선택해야 한다. 환경 설정 중 선택만 해주면 된다.

 

  • RootVolumeType : gp3 (범용3 SSD)
  • IMDSv1 : disable

 

와~ gp3 선택하지 않은 죄로 삽질 무지하게 했다.

 

 

Creating Auto Scaling launch configuration failed Reason: Resource handler returned message: "The Launch Configuration creation operation is not available in your account. Use launch templates to create configuration templates for your Auto Scaling groups. (Service: AutoScaling, Status Code: 400, Request ID: 67f0a370-3fa3-42f9-bfc1-4ebdc96b3378)" (RequestToken: e7362a93-5127-6af3-e9a5-90b793868367, HandlerErrorCode: GeneralServiceException)

 

 

CloudFormation 스택 템플릿에 보면 Launchconfiguration 이 구동되는지 Launchtemplate 이 구동되는지 확인할 수 있다. 어차피 에러나면 딱히 확인할 필요는 없지만...

 

간만에 EB 구동 정리나...

 

  • 미리준비 : VPC / 서비스 역할 / EC 키페어 / EC2 인스턴스 프로파일
  • 수동설정 : 루트볼륨유형 gp3 / 인스턴스 유형

 

EC2 인스턴스 프로파일 이란걸 썼었는지 기억도 안난다.

 


서비스 역할에 필요한 정책 (EC2, ELB, EC2 Auto Scaling API 호출에 필요)

 

  • AWSElasticBeanstalkEnhancedHealth
  • AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

 

EC2 인스턴스 프로파일 정책

 

  • AWSElasticBeanstalkWebTier
  • AWSElasticBeanstalkWorkerTier
  • AWSElasticBeanstalkMulticontainerDocker

 

나머지 환경 속성이나 기타 등등은 구동 확인 후 수정 가능하다.

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

EKS 버전 업그레이드 (1.28 -> 1.31) 후에 대표 관리자를 제외한 부 관리자들이 EKS 모니터링 실행에 실패하는 현상이 나타났고, 실패 로그는 아래와 같았다.

 

Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" has statusCode=401
Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" failed with UNAUTHORIZED

 

aws-auth ConfigMap 에는 기존 버전 그대로 해당 사용자들의 권한이 명시되어 있었다.

 

  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::111151101111:user/honggildong

 

 

다른 모든 api 권한은 문제가 없는데, 제어 플레인 (control plane) 메트릭 가져오는 api 만 인증되지 않았다는게 당최 어디서 설정을 해야 하는건지...

 

그렇게 찾다보니, EKS 액세스 관리 제어에 관련된 AWS 기술 블로그를 찾았다.
https://aws.amazon.com/ko/blogs/tech/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

 

간소화된 Amazon EKS 액세스 관리 제어 톺아보기 | Amazon Web Services

본 블로그 포스트는 Sheetal Joshi, Rodrigo Bersa, Mike Stefaniak 님의 영문 블로그를 원문으로 한글 번역된 블로그 입니다.  소개 초기 Amazon Elastic Kubernetes Service (Amazon EKS) 출시 이후 클러스터에서 인증할

aws.amazon.com

 

기존의 액세스 권한 부여 방식이 복잡했기 때문에, 액세스 관리 제어 기능을 통해 AuthN(인증) / AuthZ(권한) 부분을 간소화 하였다는 내용이다.

 

EKS 관리 제어에 두가지 용어가 추가됐다.
- 액세스 항목(access entries) : IAM 사용자나 역할에 연결되어 EKS 클러스터를 인증 (AuthN)
- 액세스 정책(access policy) : 특정 클러스터 작업에 대한 EKS 만의 권한 부여 (AuthZ)

 

액세스 항목 + 액세스 정책 대신 기존의 RBAC(Role-Based Access Control: 역할 기반 액세스 제어) 의 권한 부여(ClusterRoleBinding) 와 결합하는 것도 가능하다.

 

 

 

특정 클러스터에의 사용자에게 권한을 주려면 액세스 항목에 IAM 사용자나 역할로 생성하고, 정책을 할당하여 특정 권한을 부여하는 프로세스 이다. (기존에는 위 예제처럼 ConfigMap 에 IAM 정보와 권한을 부여할 group 을 설정했었다.) 이 기능이 2024년 7월 경 오픈되었고 이 날 이후에 업그레이드된 클러스터에서는 인증/권한 설정에 대해 기존의 CONFIG_MAP, 새로운 API, 두가지 모두 사용 가능한 API_AND_CONFIG_MAP 모드를 선택하게 됐다. 이 문서에서는 기존 클러스터를 API_AND_CONFIG_MAP 인증 모드로 설정하고, 기존의 aws-auth configMap 에서 사용된 동일한 ID / 그룹을 지정하여 동등한 액세스 항목을 생성할 것을 권장하고 있다. access_entries / aws-auth 모두 설정되어 있을 경우, 우선순위는 액세스 항목 > ConfigMap 순이다. 또한 클러스터 뿐아닌 네임스페이스 레벨의 권한도 설정이 가능하다.

명령) 특정 클러스터에 IAM ARN 인증 및 권한 설정

 

$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
  --access-scope type=cluster

 

하지만 다 필요없고, EKS 대시보드에서 아주 간편하게 액세스 관리 제어를 설정할 수 있다...

 

 

EKS 액세스 항목에 부 관리자 IAM 설정하고, 정책(AmazonEKSClusterAdminPolicy) 연결해서 문제는 해결됐다. 하지만 위의 오류가 발생했던 이유는, 지금도 잘 모르겠다. 버전 업데이트 후에 액세스 관리 제어 설정이 안되어 있어서 configMap 에만 의존하고 있었을 것이고, ConfigMap 에 설정된 system:masters 권한이라면 기존과 동일하게 api 권한의 문제는 없었어야 했는데, 다른 api 는 다 되고 metric api 만 거부됐다는게...

 

몰라몰라~~

 

이제 aws-auth ConfigMap 에서 사용자 권한을 편집할 필요가 없어졌다. 추후 EKS 에서 ConfigMap 이 제거된다고 하니 액세스 관리 제어의 사용은 필수...

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,