G리는 블로그

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

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

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 })
};

. 끝 .

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

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

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

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

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

1. Route53 Hosted Zone 설정

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

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

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

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

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

3. Route53 에서 도메인 이전 요청

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

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

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

4. Route53 에서 도메인 이전 확인

[Route53] - [도메인] - [대기 중인 요청] 에서 이전 상태를 하염없이 바라본다... 도메인 이전에는 최대 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

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

OpenSearch 도메인 생성

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

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

기타 나머지 부분들은 설정 항목마다 잘 설명되어 있다. 어느 정도 사용해 보고 적당하다 싶으면 RI 를 설정한다.

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 / Cold Storage 활용

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

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

hot / warm / cold 이 3가지 영역으로 데이터를  분리 보관할 수 있는데, 기본적으로는 저장되는 데이터 노드의 공간이 hot 영역이다. 데이터를 분리하지 않은 채 계속 쌓인다면, 검색시 부하도 많이 걸리고, 저장 공간도 부족해 지고, JVM 메모리도 부족해 진다. 이 때는 인스턴스 사양을 높이더라도 데이터 역시 지속적으로 늘어나기 때문에 시간이 지나면 또 똑같은 에러를 만나게 될 것이다. 그에 대한 조치로는 데이터를 삭제하던지, 분리 하던지 하는 방법이 있는데, 바로 warm 이나 cold 영역으로 데이터를 분리하는 것이다. 이 영역들은 데이터 노드가 아닌 S3 를 활용하며, 검색이 조금 느리긴 하지만 저렴하다(?) 고 한다. 

6개월 정도 써 본 결과, warm 나 cold index 검색 속도가 특별히 느리다는 체감을 하지는 못했다. 일단 스토리지 안정성에 대해서는 대만족이다. 문제는 많이 쓰든 적게 쓰든, UltraWarm 데이터 노드 기본 사양 자체가 비싸다...

또한 데이터 분리에 대한 정책도 나름대로 잘 정해야 한다. 나의 경우, 모든 인덱스들을 매달 분리하였고, 실제 검색에 자주 사용하는 hot 에 2달 보관, 나머지는 cold 로 보냈다.(참고로 현재 데이터 보관 정책은 기본적인 데이터는 1년, 로그인 관련 데이터는 2년, 계정관련 데이터는 5년 보관이다.) warm 과 cold 모두 사용해 보니 속도 면에서는 거의 체감하기 힘든 수준으로 비슷했고, 가격은 cold가 더 싸다고 하니 cold 를 사용했지만, 위에 말한 대로 UltraWarm 인스턴스 자체가 비싸다...ㅋ

아래처럼 매달 새로운 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
...

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

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

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

{
  "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. 모니터링

AWS 의 ACM(AWS Certificate Manager) 을 사용하면 SSL 인증서를 무료로 발급 받을 수 있다. 일반적으로 AWS 계정에 도메인을 보유하고 있다면, route53 에서 레코드를 생성함으로써 인증이 가능하다.

타 계정 도메인의 SSL 인증서 

계정에 도메인을 보유하지 않지만 SSL 인증서가 필요한 경우는 어떻게 해결해야 할까? 예를 들면 이런 경우다.

• A 계정에는 example.com 이란 도메인(FQDN)을 보유하고 있으며, 해당 계정의 route53 에는 해당 도메인에 관련된 여러 레코드 들이 설정되어 있다.
• 만약 B 계정에서 api.example.com 이란 2차 도메인으로 ALB 를 연결해야 하거나, admin.example.com 이란 2차 도메인으로 CloudFront 를 연결해야 한다면 어떻게 인증서를 생성해야 할까.

이 때는 B 계정에 *.example.com 같은 도메인의 ACM 인증서를 생성한 후, A 계정의 route53 에 관련 cname 쌍을 등록(요청)하면 된다. 등록이 완료 됐다면 위 이미지 처럼 인증서 요청이 성공할 것이고, A 계정에서는 2차 도메인의 cname 을 B 계정의 ALB 나 CF 값으로 라우팅 시켜준다면, B 계정에서도 *.example.com 에  인증서를 사용할 수 있게 된다. 당연히 A 계정의 도메인 소유자를 생판 모른다면 불가능한 일이다..

3차 도메인 SSL 인증서

그렇다면 3차 도메인을 사용하게 될 경우는 어떨까.

• api.example.com
• dev.api.example.com

이 경우 example.com 의 소유자인 A 계정에서는 api.example.com 의 서브 도메인에 대해 B 계정으로 DNS 권한을 줄 수 있다.  먼저 B 계정에서 api.example.com 호스트 영역을 생성한 후 A 계정에는 api.example.com 의 ns 설정을 B 계정의 ns 로 설정해 주면 이후로는 B 계정에서 api.example.com 에 대한 서브 도메인들을 관리할 수 있게 되며, ACM 도 직접 설정할 수 있게 된다.

이미 위에 언급했지만 와일드카드(*) 의 위치에 따라 SSL 인증 적용이 달라진다. *.example.com 과 *.api.example.com 은 다르다. 예를 들면 *.example.com 으로는 dev.api.example.com 이란 3차 도메인에 https 를 적용할 수 없다.

RDS 생성하기 전 이미 대부분의 정보는 정해놓게 된다.

• RDS 엔진 종류
• DB 인스턴스 사양
• 다중 AZ 배포 여부 (write/read)
• Public 액세스 여부
• Port 설정
• 그 외 모니터링

이러한 설정들로 RDS 생성을 마치고, 어플리케이션에 DB 정보 반영 및 DB client 프로그램으로 접속을 테스트 한다. 하지만 모든 정보(host, user, pw, port, ...) 가 일치하는데도 접속시 time-out 이 발생하는 경우가 있다. time-out 은 방화벽에 막혔거나, Private Subnet 에 설치되어 접근할 수 없는 경우, 둘 중 하나이다. 방화벽은 security group 에서 해당 포트 관련하여 확인이 가능하지만, Public 서브넷에 설치되었는지, Private 서브넷에 설치되었는지는 확인이 쉽지 않다.

Public Access 설정

Public 액세스에 관련된 설정을 두 가지로 보면 된다.

• RDS 생성시 'Public Access' 항목
• 서브넷 그룹의 AZ / 서브넷 설정

만약 DB 외부 접근을 허용하려면, Public Access 항목에 '예' 를 설정하고, 서브넷 그룹에는 Public Subnet 만 설정해 놓으면 된다. 반대로 DB 외부 접근을 제한하려면, Pulibc Access 항목에 '아니오' 를 설정하고, 서브넷 그룹에는 Private Subnet 만 설정해 놓으면 된다.

하지만 문제는 서브넷 그룹에 Public/Private 서브넷이 혼재되어 있는 경우이다. 이 경우 Public Access 설정에 따라 해당하는 서브넷에 인스턴스가 설치되면 문제할 것이 없는데, 외부 접근을 허용하기 위해 Public Access 항목에 '예' 를 설정했어도 Private 서브넷에 설치되는 경우가 있다. 이 경우 외부에서 열심히 접속을 시도해도 time-out 만 나타나게 되는 것이다.

결국 서브넷 그룹의 Public or Private 서브넷 설정으로 외부 접속 여부가 결정되는데 왜 헷갈리게 옵션이 두 개인지가 의문이다.

% nc -zv dev.cluster-xxxxx.ap-northeast-2.rds.amazonaws.com 3306
Connection to dev.cluster-xxxxx.ap-northeast-2.rds.amazonaws.com port 3306 [tcp/tappi-boxnet] succeeded!
% nc -zv dev.cluster-xxxxx.ap-northeast-2.rds.amazonaws.com 3307
nc: connectx to dev.cluster-xxxxx.ap-northeast-2.rds.amazonaws.com port 3307 (tcp) failed: Operation timed out

결론

삽질 방지 차원에서 서브넷 그룹의 Public/Private 서브넷은 명시적으로 설정하자.

간만에 새 집이 생겼으니, 좀 꾸며야겠지? 초기에는 디자인 쪽으로도 신경을 좀 써주기도 하고, 이런 저런 잡다한 것들을 많이 수정했었는데, 오랜 기간 티스토리를 써 본 결과, 기본 스킨으로 기본적인 최소한의 태그들로 깔끔하게 글을 작성하는 것이 베스트라는 생가이 든다. 시간이 지날수록 티스토리에서도 이런 저런 업데이트를 많이 하지만, 가장 표준적인 기능들만 활용하는 것이 추후 발생할 업데이트로 인해 오래된 게시물들이 변형되는 것을 막을 수 있다... 라는 것이 현재의 생각이다. 지금은 마크다운도 지원하지만 오히려 시간이 더 소요될 것 같아 기본모드를 사용한다. 그래서 관리자 모드에서도 최소한의 기능들만 모아 설정하려고 한다.

1. 파비콘 (favicon)
2. 플러그인 (google / naver analytics)
3. 광고

1. favicon

Favorite와 Icon의 합성어. 파비콘은 웹사이트를 방문했을 때 웹브라우저의 탭에 붙는 웹사이트의 대표 아이콘을 말한다. 기본적으로 웹사이트의 루트 디렉토리에 favicon.ico 이름으로 위치하면 웹브라우저에 표시된다. HTML5 사양을 기반으로 다른 경로의 이미지(png, gif, ico)도 넣을 수 있다. 주로 사용하는 크기는 16×16px이다.

예) <link rel="shortcut icon" type="image/png" href="image/favicon.png">

티스토리에서는 파비콘 이미지만 있다면 관리 페이지에서 업로드만 하면 된다. 

예전에는 포토샵으로 열심히 만들었었는데, AI 가 있으니 굳이 그럴 필요없다. 이미지 생성 AI 에게 원하는 모양을 얘기하면 후딱 만들어주고, 그 이미지를 파비콘 생성 사이트에 올리면 크기에 맞게 파비콘을 만들어 준다.

https://www.favicon-generator.org/

이 편한 세상...

2. 플러그인

포털 검색 관련해서 구글 서치 콘솔 / 구글 애널리틱스 / 네이버 서치 어드바이저 / 네이버 애널리틱스 정도 연동하면 될 것 같다. 플러그인에서 지원하는 것은 활용하면 되고, 나머지는 직접 사이트에 방문하여 key 또는 id 를 발급받거나 script 를 복사하여 스킨 편집에서 html 파일에 붙여 넣으면 연동이 완료되며 블로그의 트래픽 스트림 추적이 시작된다.

• 구글 서치 콘솔 : 주로 구글이나 네이버에서 검색이 잘 될 수 있도록 크롤링에 관련된 색인 생성이나, sitemap / rss 등을 등록할 수 있고, 검색 트래픽 분석 통계 확인 가능. (클릭수, 노출수, CTR 등)
• 구글 애널리틱스 : 방문자 활동 분석에 관련된 더 상세한 정보들을 확인 (방문자 수, 페이지 뷰, 이탈률, 전환율 등)

연동 후 사이트 정보가 반영되거나 검색되기 까지는 약 48시간 까지 소요될 수 있다. 데이터가 바로 보이지 않는다고 해서 연동이 잘 되지 않았나 걱정할 필요 없다.

3. 광고

티스토리에 있는 광고는 구글 애드센스와 카카오 애드핏 두 개만 설정하면 될 듯... 구글 애드센스 기존에 이미 가입을 해놔서 바로 연동이 되는 것 같고, 카카오 애드핏은 역시 조건이 좀 있다. 기존 구글 애드센스도 수익 좀 내보려고 했었는데 무슨 광고 클릭을 악용했다나... 난 블로그 잘 들어가 보지도 않았구만... 그렇게 몇번을 광고 정지되다가 황당해서 광고 끊어 버렸었다. 아마도 오랜 기간 지저분하게 들어있던 코드들이 이상 동작을 했다고 볼 수 밖에...