Quantcast
Channel: Charsyam's Blog
Viewing all 124 articles
Browse latest View live

[입 개발] Kotlin으로 Google Sheet 열어보기

$
0
0

Java/Kotlin 으로 Google Sheet 에 접속하는 예제는 사실 구글에 아주 잘 나와있다. https://developers.google.com/sheets/api/quickstart/java?hl=ko 를 보면 샘플이 있는데, 이걸 돌려보면 되는 사람도 있고 잘 되지 않는 경우도 있을 텐데… 그 이유에 대해서 살짝 적어볼려고 한다.

구글 인증 방식은 두 가지(OAuth 클라이언트ID, ServiceAccount)

위의 링크를 잘 읽어보면 인증 정보 만들기에서 OAuth 클라이언트 ID로 만들어진 경우이다. 그런데, python 등에서 사용하다보면 보통 ServiceAccount 를 이용하는 형태를 스게 되는데, 이 두가지가 서로 달라서 위의 샘플로 ServiceAccount 형태의 인증을 요청하면 InvalidArgumentException을 만나게 된다.

위의 링크에서 전자(OAuth 클라이언트ID)의 방식을 잘 설명하고 있으므로 여기서는 후자만 다룬다.

접속 방법

간단한 접속 코드는 다음과 같다. (GoogleCredential 이 그런데 deprecated 되는 건 함정)

import com.google.api.client.auth.oauth2.Credential
import com.google.api.client.googleapis.auth.oauth2.GoogleClientSecrets
import com.google.api.client.googleapis.auth.oauth2.GoogleCredential
import com.google.api.client.googleapis.javanet.GoogleNetHttpTransport
import com.google.api.client.json.gson.GsonFactory
import com.google.api.services.sheets.v4.Sheets
import com.google.api.services.sheets.v4.SheetsScopes
import org.springframework.context.annotation.Configuration
import java.io.IOException
import java.security.GeneralSecurityException
import java.util.*

@Configuration
class GoogleAuthorizationConfig {
    private val applicationName: String = "test-api"

    private val credentialsFilePath: String = "/credentials.json"

    private val tokensDirectoryPath: String = "tokens"
    @Throws(IOException::class, GeneralSecurityException::class)
    private fun authorize(): Credential {
        val inputStream = GoogleAuthorizationConfig::class.java.getResourceAsStream(credentialsFilePath)
        val googleCredential = GoogleCredential.fromStream(inputStream)
            .createScoped(Collections.singleton(SheetsScopes.SPREADSHEETS_READONLY))
        return googleCredential
    }

    @get:Throws(IOException::class, GeneralSecurityException::class)
    val sheetsService: Sheets
        get() {
            val credential: Credential = authorize()
            return Sheets.Builder(
                GoogleNetHttpTransport.newTrustedTransport(),
                JSON_FACTORY, credential
            )
                .setApplicationName(applicationName)
                .build()
        }

    companion object {
        private val JSON_FACTORY: com.google.api.client.json.JsonFactory = GsonFactory.getDefaultInstance();
    }
}

그리고 이제 각 sheet 정보와 각각의 데이터를 가져오는 걸 알아보자.

    fun getSpreadSheets(page: String) {
        val sheetsService = googleAuthorizationConfig.sheetsService
        val sheets = sheetsService.spreadsheets().get(page).execute()

        sheets.sheets.map {
            println(it.properties.title)
            val sheet = sheetsService.spreadsheets().values().get(page, it.properties.title).execute()
            val values = sheet.getValues()

            values.map { //row 별로 가져오는 코드
                it.map { // 각 라인의 컬럼별로 가져오는 코드
                    print(it)
                    print(",")
                }
                println("-----")
            }
        }
    }


AWS 에서 Amazon Linux Nginx TCP Stream Proxy 설정

$
0
0
  • 아마존 리눅스에서 nginx 설치
    • sudo amazon-linux-extras install nginx1
  • tcp stream 모듈은 Default 설치가 아니라서 추가 설치 필요
    • sudo yum install nginx-mod-stream

stream 설정

stream {
    # target
    upstream upstream_pass {
        server 10.20.30.40:10001;
    }

    # tcp
    server {
        listen 10001;
        proxy_pass upstream_pass;
        proxy_connect_timeout 1s;
    }
}

이때 기본적으로 ngx_stream_module.so 이 load 가 되어 있지 않기 때문에 load_module 로 해당 모듈을 등록해줘야만 stream 키워드가 사용가능하다. 이때 위에 yum 으로 설치한 경로와 기본 경로가 다를 수 있으므로 해당 경로에 링크를 걸어주거나 아래와 같이 절대 경로를 적어줘야 한다.

load_module /usr/lib64/nginx/modules/ngx_stream_module.so;

Redis 8 에서의 AGPLv3 추가의 의미(오픈소스로의 리턴?)

$
0
0

지금부터의 의견은 100% 내 개인적인 의견이다.

2024년 Redis 생태계에서 아주 충격적인 일이 일어났다. Redis 7.2.4 부터 Redis 의 오픈소스 라이센스가 기존의 BSDv3 에서 Redis Source Available License v2 (RSALv2) 와 Server Side Public License v1 (SSPLv1) 로 바꿔버린 것이다. 그러면서 Valkey 라는 Redis Fork 프로젝트가 새롭게 생겨나게 된 계기가 되었다.

먼저 RSALv2 와 SSPLv1 라이센스에 대해서 먼저 알아보자. 이 두 해당 라이센스는 공식적인 오픈소스 라이센스로 인정받지 못한다. 즉 기본적으로 Redis는 더 이상 오픈소스로 인정 되지 않는다는 얘기였다.(그래서 각 종 리눅스 배포판에서 빠지게 되었다.)

일단 각 라이센스 부터 정리하면. 아래와 같다.

라이센스비고
RSALv2비상업적 또는 자체 내부 서비스 용도로는 사용 가능.
SaaS(서비스형 소프트웨어) 형태로 Redis를 제공하는 것은 금지.
예: AWS, GCP 같은 클라우드 벤더가 Redis를 서비스로 제공하는 것 제한.
수정 및 배포는 가능하지만, 상업적 Redis-as-a-Service 제공은 불허.
SSPLv1기본적으로 GPLv3 기반이지만, 클라우드 제공자에게 훨씬 더 엄격함.
Redis를 서비스로 제공하고 싶다면, 해당 서비스 전체의 소스코드를 공개해야 함.
예: Redis와 함께 사용하는 관리 도구, 오케스트레이션 시스템 등도 모두 공개해야 함.
사실상 대기업의 SaaS 제공을 어렵게 만드는 라이선스입니다.

딱 살펴보면 알겠지만, Redis를 그냥 사용하는 것은 되지만, Redis As a Service 를 못하게 하는 라이센스라고 보면 된다. 여기서 타겟이 되는 것은 AWS Elasticach 나 GCP 같은 클라우드 업체이며, 더 이상 Redis 를 서비스 할 수 없게 된다.(정확히는 Redis 7.2.4 부터이고 그 이전까지는 여전히 BSDv3 이므로 상관없다.)

Redis(회사) 에서 말하는 것은 오픈소스 레디스에 우리는 이렇게 투자를 많이하는데, 클라우드 업체에서는 과실만 따먹고, 여기에 대한 투자를 하지 않는다라는 것이다.(물론, 알리바바 클라우드나 AWS에서도 꽤 공헌이 있었다.)

여기서 재미있는 것은 Redis(회사) 의 엔터프라이즈 버전이나, AWS의 Elasticash 같은 경우 Open Source Redis의 엄청난 개조버전이라는 것이다.(여기서, Redis 엔터프라이즈 버전은 오픈소스 Redis를 앞에서 Redis(회사)에서 만든 Proxy가 붙어서 다른 형태로 동작하게 하는 걸로 알고 있다.) 즉, 이렇게 수정한 버전을 서비스를 할려면, 소스를 공개하라는 뜻이다.

그런데 몇일전에, Redis 8을 릴리즈하면서 이제 AGPLv3 를 라이센스에 추가했다. 관련 글에는 고객들이 오픈소스 라이센스일때 더 적용하기 쉽다고 해서, AGPLv3를 추가했다는 것이다. 그리고 AGPLv3는 인정 받는 오픈소스 라이센스가 맞다.

그럼 AGPLv3는 어떤 특징이 있을까?

가장 “자유로운” 라이선스처럼 보일 수 있으나, 기업 입장에서는 부담이 큼.

  • 네트워크 상에서 Redis를 서비스 형태로 제공할 경우, 소스코드 전체를 공개해야 함.
  • Redis를 커스터마이징하거나 변경한 버전을 서비스로 제공하면, 해당 서비스 전체 소스도 공개해야 함.

살펴보면 SSPLv1 과 유사하다는 것을 알 수 있다. 즉, 결국 Redis 오픈 소스 버전을 쓰고 싶다면, 결과물을 공개하라는 의지가 계속 들어가 있는 것이다.

당연히 오픈소스 Redis 로 다시 돌아왔지만, 그 목적이 예전처럼 더 자유로웠던 BSDv3가 아닌 것은, 그 목적이 어느 정도 명확해서라고 생각한다.

Redis 와 Valkey 무엇을 선택해야 할까?

$
0
0

2024년에 Redis 7.2.4 부터 라이센스 이슈로 Valkey 가 fork 되면서 많은 사람들이 Redis와 Valkey 중에 무엇을 사용해야 하는가? 그럼 어떤 차이가 있는지에 대한 질문이 꽤 많습니다. 그래서 거기에 대한 간단한 의견(답정너) 를 소개하려고 합니다.

일반적으로 클라우드 기반에서 사용하던 분들 특히 AWS의 ElastiCache 를 쓰는 분들은 그냥 Redis 쓰는 것보다 Valkey로 가셔도 전혀 문제가 없습니다.(비용이 더 싸진다는 장점만 있다고 보시면 됩니다.) 왜냐하면 클라우드에서 쓸 수 있는 Redis 버전은 기본적으로 7.2.4 의 이전 버전들이라, 그 시점은 Valkey가 Fork 되면서 그대로 이전했기 때문입니다. 즉, 기존 Redis 를 제공하는 클라우드의 내부 버전이 다르더라도 그냥 제품명만 Redis -> Valkey로 바꿔서 그대로 제공이 됩니다. 그냥 바꾸면 변경이 되는 수준입니다.

그럼, 실제로 문제가 되는 것은 어떤 상황일까요? 현재 우리가 Redis를 자체적으로 운영하고 있는데, Valkey로 바꾸어야 되는가 입니다. 이 이야기를 하기 전에 Redis와 Valkey가 이제 차이가 나는가? 라는 주제 부터 얘기를 해야 합니다. Redis 8과 Valkey 8이 2025년에 나오면서 조금씩 큰 차이가 벌어지고 있습니다.

Redis Module 이야 대부분이 원래 RSAL 라이센스라, 클라우드에서 제공이 안되었지만, Redis 는 사용자의 편의성 기능과 AI쪽에 좀 더 집중하고 있는 모습입니다.

Redis는 7 버전 이후에 Hash 에 서브 Key를 Expire 하는 기능이 들어갔지만, Valkey에는 들어가지 않았습니다.(포크가 되는 시점에, 개발되고 있다가, 포크되고 반영된…) Redis 8에는 VectorSet 이나 AutoComplete 등 AI 지원 기능이나 편의성 기능이 이번에 많이 추가 되었습니다.(내부적으로 콜렉션등에 성능개선도 있었다고…)

Valkey 는 8 버전부터, CPU Cache Line을 맞추거나, 포인터 접근 횟수를 줄여서, 좀더 메모리를 아끼거나, 성능을 높이는 쪽으로 가고 있습니다. 그래서 8부터는 명령이나 이런 부분에서 어느정도 차이가 나고 있습니다.(다만 아직 기본 명령 보다는, 모듈쪽에서 차이가 나는거 같습니다.)

그럼 발전성은 어떨까요? Redis 8이 AGPLv3가 추가되면서 기업에서 뭔가 사용하기가 어려워졌지만, 여전히 Redis(회사) 가 많은 지원을 하고 있고, 가장 많은 컨트리뷰션을 하고 있습니다. 반대로 Valkey는 리눅스 파운데이션과 AWS, 알리바바 등 지원이 있지만, Redis 보다는 조금 덜 활성화 된걸로 보입니다.

결국 선택의 우리의 몫입니다. 다만 정말 특별한 기능을 사용하지 않고, 기존 흐름을 따르는 형태에서는 뭘 선택해도 당장은 큰 문제는 없어보입니다. 하지만, 새로운 Redis 기능을 써야 한다면, 이제 좀 고민을 하셔야 될듯 합니다.

Viewing all 124 articles
Browse latest View live