진성 소프트

도커 각티슈 케이스 후기 (a.k.a 다들 집집마다 컨테이너 하나씩은 있으시잖아요?)

rlawlstjd007 — Mon, 6 Mar 2023 19:16:52 +0900

도커 각티슈를 협찬 받다 (feat. 인카토스)

블로그에 도커 관련된 글을 종종 올렸었는데 어떻게 좋은 기회가 되어 '도커 각티슈' 를 협찬을 받게 되었습니다.
제의가 왔을 때 잠시 사진으로 봤었는데 딴딴한 실루엣을 보고 첫눈에 바로 반했습니다.
- 책상 위에 저 녀석을 둔다면 왠지 모르게 더 도커를 더 잘 쓸수 있을 것만 같더라구요.

실물 영접

조립도 하고 자랑도 할겸 친구 녀석과 만났는데 깜짝 놀라더라구요. 조립은 그리 어렵지는 않았습니다.
친구녀석이 말하기를 '자기가 얼마전에 이거 살까말까 엄청 고민했었다고 ..'
- 그래서 친구 녀석은 결국 그 자리에서 샀답니다 ^^

자 이제 풀샷 보여드리겟습니다.
회사에서 쓰려고 가져다 두었는데 다들 선망의 눈빛을 숨기시지 못하더라구요. 차마 제거라고는 못하고 뿌듯해 했답니다.

끝으로

도커 각티슈를 구비하고 나서 성공 도커인생이 시작되었습니다.
관심이 있으시다면 한번 구매 해보시는 것 추천 드립니다. 아래 구매링크 남겨 드립니다.

도커 컨테이너 각티슈 휴지 케이스 티슈커버 사각 아크릴 각티슈 커버 - 푸르가즘

교환 및 반품 주소 - 교환 및 반품이 가능한 경우 - 계약내용에 관한 서면을 받은 날부터 7일. 단, 그 서면을 받은 때보다 재화등의 공급이 늦게 이루어진 경우에는 재화등을 공급받거나

incatos.shop

Presto JDBC Driver 의 TimeZone 으로 인한 고생기 및 극복기

rlawlstjd007 — Mon, 9 Jan 2023 19:59:52 +0900

들어가며

현 회사에서 비즈니스 Feature 개발을 하면서 유저에게 필요한 다양한 데이터를 가공해서 전달하기 위해서 Presto DB 를 사용하고 있습니다. 이 과정에서 Presto DB 의 TimeZone 설정으로 인해서 꽤나 많은 고생을 겪게 되었는데 그 해결 과정을 공유하고자 합니다.

Presto DB 란?

Presto 는 대량의 (~ 수십 TB) 데이터를 분산처리 할 수 있는 클러스터 이자 쿼리엔진입니다. 쿼리엔진 측면에서 Presto 는 다수의 Woker Node 에서 대량의 데이터를 저장소로 부터 읽어 가공을 수행합니다. 이때 저장소는 다양한 종류(S3, MySQL, Elasticsearch 등)를 지원합니다. (자세한 내용은 공식 문서를 참고)

문제 발생

어느날 Feature 개발을 위해서 Presto 의 Ad-hoc 쿼리가 필요하여 개발을 하고 테스트를 하고 있었습니다. 그런데 도저히 이해할 수 없는 현상을 마주했습니다.

아래 이미지는 Presto UI 의 Query Detail 화면에서 동일한 Query 두 쿼리를 비교한 이미지인데요. 놀랍게도 두 쿼리 모두 완벽히 일치하는 sql 로 실행된 쿼리인데 실행 결과가 달랐습니다. 각 쿼리는 단지 실행 방법이 달랐는데

좌측: 편의를 위해서 '@SpringBootTest' 어노테이션을 통합 테스트였는데 Presto 가 읽은 input 데이터 자체가 없었고
우측: 실제 Spring Application 을 load 하여 WAS에 API 를 날려 테스트를 진행했는데 이 경우는 정상적으로 조회가 되었습니다.

Presto UI 에서 유심히 여러 property 를 살펴보고 raw data 를 비교해봤지만 별다른 소득은 없었습니다.

문제 분석에 앞서 의심해볼만한 부분은 크게 두가지가 있었습니다.

@SpringBootTest 로 인해서 Presto JDBC Driver 의 로직에 영향을 주었거나
TimeZone 으로 인한 시간 계산의 문제가 있거나

Presto JDBC Driver 를 까보자

참고) 본 글은 presto 0.278 버전을 기준으로 작성되었습니다.

Presto 에서는 jdbc 스펙을 맞춰 구현한 driver 를 제공하고 있는데요, 덕분에 Presto Datasource 설정을 통하여 JdbcTemplate 을 이용하여 사용할 수 있습니다.

아래 코드에서는 DataSource 를 생성할 때 특이하게 커넥션 풀을 사용하지 않는 'DriverManagerDataSource' 를 사용하였는데요. 그 이유에 대해서는 차차 알수 있을 겁니다.

@Configuration
class PrestoConfiguration {
	@Bean(name = "PrestoDataSource")
    fun prestoDataSource(): DataSource {
        val properties = prestoDataSourceProperties()
        val dataSource = DriverManagerDataSource()
        dataSource.setDriverClassName(properties.driverClassName)
        dataSource.url = properties.url
        dataSource.username = properties.username
        dataSource.password = properties.password
        return dataSource
    }

    @Bean(name = "PrestoJdbcTemplate")
    fun prestoJdbcTemplate(): JdbcTemplate {
        val jdbcTemplate = JdbcTemplate(prestoDataSource())
        return jdbcTemplate
    }
}

@Component
class PrestoTemplate(
    private val jdbcTemplate: JdbcTemplate
) {
    fun execute(sql: String) { jdbcTemplate.execute(sql) }
    fun <T> query(sql: String, rse: ResultSetExtractor<T>): T? { return jdbcTemplate.query(sql, rse) }
    fun <T> query(sql: String, rowMapper: RowMapper<T>): List<T> { return jdbcTemplate.query(sql, rowMapper) }
}

이제 실제 Presto Driver 내부를 들여다 보겠습니다. 아래 이미지는 대략적인 presto jdbc driver 의 구조입니다. 여기서 알 수 있는 사실은 JDBC 스펙에 맞게 구현한 component 들이 있구나 정도이고 이를 제외하면 눈여겨 볼 곳은 한 군데 입니다. 아래 이미지에서 강조된 StatementClient 부분입니다. 왜 Http Client 를 가지고 있는지 궁금하지 않으신가요 ?

Presto Connection 은 단순 HTTP call 에 불과하다

눈치채셨을수도 있겠지만 Presto Connection 은 실제 DB 로 물리적인 연결이 아닌 단순히 jdbc spec 에 맞춰 구현된 객체일 뿐입니다. 그래서 내부에서는 stateless 한 HTTP call 을 통해서 쿼리를 수행하고 결과를 받아오게 됩니다.

그 말인즉슨, Connection 생성에 대한 오버헤드가 없기 때문에 커넥션 풀을 사용하는 의미가 없고 Connection 을 매 요청마다 새로 생성해서 써도 상관 없다는 말입니다. 그래서 위에서 datasource 를 생성할 때 'DriverManagerDataSource' 를 사용한 이유 입니다.

원작자의 부연설명 (참고. trino 는 presto 로 만들어진 다른 버전의 db 임)

좀 더 자세하게 실제로 Presto 의 쿼리 요청은 단일 HTTP request 로 그치지는 않습니다. 대략적으로는 최초에 쿼리 요청을 보내고 쿼리가 수행이 완료되기 까지의 일련의 과정 (presto 엔진이 쿼리 수행을 준비하고 작업 queue 에 올리고 쿼리를 수행하는 과정이 포함) 에 걸쳐 쿼리 result 를 반환할 때 까지 polling 하는 방식으로 동작합니다.

자세한 Protocol 에 대한 내용은 아래 링크를 참고해주세요.

GitHub - prestodb/presto: The official home of the Presto distributed SQL query engine for big data

The official home of the Presto distributed SQL query engine for big data - GitHub - prestodb/presto: The official home of the Presto distributed SQL query engine for big data

github.com

StatementClient

실제로 쿼리 요청을 처리하는 'StatementClient' 를 자세하게 살펴보겠습니다. 아래 코드에서 보다시피 생성자에서 최초에 HTTP 로 쿼리 요청을 보냅니다. 그리고 받아온 결과를 processResponse() 메소드를 통해서 저장합니다.

StatementClientV1.java

최초 request 를 만드는 부분인데요 Header 를 통해서 additional 한 설정을 넘겨줄 수 있다는 사실을 알 수 있습니다.

Presto 로의 HTTP Call 에 대한 응답은 아래 이미지와 같이 Json 포맷으로 내려오는데요, 중요한 부분은 nextUri 항목입니다. StatementClient 에서는 최초 요청을 시작으로 쿼리 수행이 끝날때 까지 응답에 포함된 nextUri 을 계속해서 호출하는 방식으로 동작합니다. (nextUri 가 null 인 경우 완료라고 판단함)

최초 요청 이후 StatementClient advance() 메소드를 result 가 채워질 때까지 반복적으로 호출 하는 형태로 동작합니다. 이때 해당 메소드를 외부에서 호출하는 주체는 PrestoResultSet 입니다.

StatementClientV1.java

PrestoResultSet.java

Presto Driver 는 아무런 잘못이 없엇다

결론적으로 Presto JDBC Driver 는 아무런 문제가 없음을 알게 되었습니다. 그래도 Presto Driver 의 구조를 알았음에 위안을 삼고 다음 원인을 분석해보기로 했습니다.

TimeZone 설정을 확인해보자

이제 남은 건 TimeZone 에 대한 의심이었습니다. 그도 그럴 것이 두 가지 테스트 상황에서 유일하게 달랐던 부분이 바로 Application 의 System Time 설정이었습니다.

먼저 WAS 를 통해서 테스트한 환경의 경우 TimeZone 이 UTC 로 설정됩니다. 회사 서버와 쌓이는 데이터들은 모두 UTC 기준으로 돌아가기 때문에 WAS 역시 load 시에 UTC TimeZone 으로 설정을 해주고 있습니다.

@RestController
@SpringBootApplication
class Application {
    @GetMapping("/hello")
    fun hello() = Mono.just("Hello")
}

fun main(args: Array<String>) {
    TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC))
    println("TimeZone: " + ZoneId.systemDefault())
    //TimeZone: UTC
    runApplication<Application>(*args)
}

반면의 통합 테스트 환경에 경우에는 별도로 TimeZone 설정을 해주지 않고 있는데 그로 인해서 실행되는 JVM TimeZone 을 그대로 따라가게 되어 'Asia/Seoul' 로 설정되는 것을 알 수 있었습니다.

@SpringBootTest(properties = ["spring.profiles.active=local"])
class SpringContextTest {
	@Test
    fun `test query`() {
	    println("TimeZone: " + ZoneId.systemDefault())
	    //TimeZone: Asia/Seoul
    }
}

TimeZone 이 Presto 에 주는 영향

왠지 이제 Presto 에 쿼리 요청을 할 때 TimeZone 관련된 설정을 해줄 것 같은 의심이 드는데요. 요청방식은 이미 알고 있어서 어렵지 않게 찾을 수 있었습니다. 아래 코드를 보면 요청시에 ClientSession 으로 넘겨준 timeZone 을 HTTP 요청 헤더에 ('X-Presto-Time-Zone') 설정을 해주고 있었습니다. 그렇다면 ClientSession 은 어떻게 설정되는지 봐야겠습니다.

Client Session 은 Presto Connection 에서 생성 해주고 있는데요, 이때 timeZone 은 아래 코드에서 설정됩니다. 의심했던 대로 역시 System Default Timezone 으로 설정을 해주고 있었습니다.

검색을 해보니 저와 같은 이슈로 골머리를 앓으셨던 분을 찾을 수도 있었습니다 ..

Presto JDBC 사용시 TimeZone 주의 | Popit

Presto JDBC 사용시 서버와 다른 TImeZone 사용시 다른 데이터가 조회될 수 있는 문제에 대해 설명

www.popit.kr

TimeZone Header 설정이 Presto 에 어떻게 적용될까

그럼 한가지 의문이 또 생깁니다. 그렇다면 이 TimeZone 설정이 실제 Presto DB 에서 쿼리될 때 어떻게 적용되는 거지? 찾아봐야겠습니다.

Presto 공식 문서를 보면 X-Presto-Time-Zone 헤더의 경우 '쿼리 수행시에 Presto 엔진의 기본 timezone 으로 적용된다' 라는. 내용으로 보아 저장된 값에 상관 없이 전달된 Time-Zone 으로 컨버팅 되어 계산되는 것을 예상해볼 수 있습니다.

그럼 실제로 테스트를 해보겠습니다. Presto 의 Data Type 에는 타임존 유무에 따른 TIMESTAMP, TIMESTAMP WITH TIME ZONE 이 있는데요, 먼저 타임존을 포함하지 않는 TIMESTAMP 타입으로 테스트를 해보겠습니다. (참고로 Presto 서버의 기본 timezone 은 UTC 로 설정)

ts                        
-----------------------
2022-01-07 22:00:00.00

아래는 TimeZone 을 각각 다르게 설정하여 쿼리를 실행하는 테스트 인데요, 실행을 해보면 'UTC' TimeZone 으로 설정한 경우에 결과를 얻을 수 있는 것을 볼 수 있었습니다. 이로 미루어 보아 'Asia/Seoul' TimeZone 으로 설정한 경우 저장한 값들이 해당 TimeZone 으로 컨버팅 되어 조건에 부합하지 않게 되는 것을 알 수 있었습니다.

@Test
fun `TIMESTAMP without timezone test`() {
    val sql = 
    	"SELECT * FROM table WHERE ts BETWEEN TIMESTAMP '2022-01-07 21:55:00' AND TIMESTAMP '2022-01-07 22:05:00'"            

    TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Asia/Seoul")))
    val kstResult = prestoTemplate.queryForList(sql)
    println(kstResult.joinToString(separator = "\n") { it.toString() })
    //결과: 

    TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC))
    val utcResult = prestoTemplate.queryForList(sql)
    println(utcResult.joinToString(separator = "\n") { it.toString() })
    //결과: { ts='2022-01-07 22:00:00.00' }
}

이어서 타임존을 포함하는 TIMESTAMP 로 테스트 해보겠습니다.

ts                        
-----------------------
2022-01-07 22:00:00.00 UTC

아래 테스트를 실행해보면 위 테스트와 동일하게 데이터들이 전달된 TimeZone 으로 컨버팅되어 계산되는 것을 확인할 수 있었습니다.

@Test
fun `TIMESTAMP without timezone test`() {
    val sql = 
    	"SELECT * FROM table WHERE ts BETWEEN TIMESTAMP '2022-01-07 21:55:00' AND TIMESTAMP '2022-01-07 22:05:00'"            

    TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("Asia/Seoul")))
    val kstResult = prestoTemplate.queryForList(sql)
    println(kstResult.joinToString(separator = "\n") { it.toString() })
    //결과: 

    TimeZone.setDefault(TimeZone.getTimeZone(ZoneOffset.UTC))
    val utcResult = prestoTemplate.queryForList(sql)
    println(utcResult.joinToString(separator = "\n") { it.toString() })
    //결과: { ts='2022-01-07 22:00:00.00' }
}

결론

위 과정을 통해서 PrestoDB 는 저장되어 있는 값 상관 없이 Client 의 Session Timezone 으로 컨버팅 되는 사실을 알게 되었습니다. 그럼 이제 Client Session TimeZone 을 설정할 수 있다면 문제를 해결할 수 있을 것 같습니다.

Trino 는 어떨까 ?

해결에 앞서서 현재 회사에서는 Presto DB 와 더불어 Trino DB 도 함께 사용하고 있는데요, 과연 Trino DB 에서도 동일한 이슈가 있을지 궁금해졌습니다. 'Trino DB' 에대해서 간략히 설명하자면 PrestoDB 를 만들던 엔지니어들이 Facebook 에서 퇴사해 2019 년부터 개발하며 LinkedIn, Lyft, Netflix, Slack 등에서 사용되는 쿼리 엔진입니다.

Trino 는 다르다

테스트를 위해서 Trino Driver 로 교체한 뒤 문제 상황을 동일하게 재현해보았는데요, 예상과는 다른 결과를 얻었습니다. 쿼리 UI 에서는 Time Zone 이 각각 다르게 전달되었지만 두 결과 모두 원했던 동일하게 정상적인 결과를 얻는 것을 확인하였습니다.

Trino 의 경우 커뮤니티가 비교적 활성화 되어 있어서 Slack 커뮤니티를 통해서 원인을 확인할 수 있었습니다. Trino 의 경우 기본적으로 서버의 TimeZone 으로 보존되며 Client 로 부터 전달된 TimeZone 은 일부 상황에서만 사용된다고 합니다.

TIMESTAMP -> TIMESTAMP WITH TIME ZONE 으로 캐스팅시
current_timestamp 를 사용할 때

결론

TrinoDB 와 PrestoDB 는 Client 의 Session Timezone 을 사용하는 방식이 다르고 Trino 의 경우는 기본적으로 서버의 TimeZone 을 사용한다는 사실을 알 수 있었습니다.

Lesson Learned

여기까지 매우 긴 여정이었는데요. 이 과정을 통해서 실제로 Action Item 으로 적용하여 얻을 수 있었던 소득이 꽤 있었습니다.

Presto Connection TimeZone 고정

아래 코드는 Presto Connection 에 직접 TimeZone 을 설정하는 코드입니다. Connection 지정된 TimeZone 은 최우선으로 적용됩니다. 이를 통해서 구동되는 JVM 환경과는 전혀 상관 없이 원하는 TimeZone 으로 쿼리가 수행되도록 설정을 할 수 있게 되었습니다.

TimeZone 으로 인한 아픔은 제 선에서 끝낼 수 있게 되었습니다.

val connection = DriverManager.getConnection(url);
val prestoConnection = connection.unwrap(PrestoConnection::class.java)
prestoConnection.timeZoneId = ZoneOffset.UTC.id

Presto Client Tag 를 활용한 Resource Group 관리

Presto Connection 을 조작할 수 있게 되면서 할 수 있게된 부가가치 높은 일들이 있었습니다. 바로 Resource Group 적용인데요, Presto 클러스터의 리소스를 여러 가지 사용자 정의 속성으로 Grouping 하여 리소스 제한 정책을 적용할 수 있는 기능입니다. 이를 통해서 서비스 특성에 맞게 쿼리 단위로 세밀하게 리소스 조정이 가능하게 됩니다. (ex. 특정 워크스페이스 별, 구독 플랜 별)

Resource Groups — Presto 0.278.1 Documentation

Resource Groups Resource groups place limits on resource usage, and can enforce queueing policies on queries that run within them or divide their resources among sub-groups. A query belongs to a single resource group, and consumes resources from that group

prestodb.io

사실 오래전 부터 회사 DE 분께서 원하셨던 기능이었는데 의도치 못하게 이제야 한을 풀어드리게 되었습니다.

val connection = DriverManager.getConnection(url);
val prestoConnection = connection.unwrap(PrestoConnection::class.java)
prestoConnection.setClientInfo("ClientTags", accountId)
prestoConnection.setClientInfo("ApplicationName", workspaceId)

JDBC Template 을 활용한 Presto Template

회사 프로젝트에서는 Presto Driver 를 Jdbc Template 로 wrapping 하여 사용하고 있는데요, 그로 인해서 기본 Statement 를 사용하는 방식으로는 Connection 을 조작하기가 어려웠습니다. 포기하던 찰나에 시니어 엔지니어 분께 도움을 받아 PreparedStatement 를 활용하여 큰 수정 없이 적용할 수 있는 Presto Template 을 만들 수 있게 되었습니다.

소스가 꽤 길어 별도 링크로 남겨두겠습니다 !

PrestoDriverExample.kt

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

마치며

지금까지 Presto DB TimeZone 으로 인해서 고생을 겪고 해결하는 과정까지의 이야기였습니다. 의심으로 시작해서 하나둘씩 원인을 알아가고 나름 의미 있는(?) 결과까지 얻을 수 있었던 뜻깊은 시간이었던 것 같습니다. 이 글을 통해서 부디 저와 같은 시행착오를 겪는 분들이 없으셨으면 좋겠습니다 .. ㅎㅎ

긴 글 읽어주셔서 감사합니다

기능 플래그로 블로그 '광고클릭 유도 배너' 노출 제어 하기 (feat. Hackle)

rlawlstjd007 — Sat, 7 Jan 2023 18:36:07 +0900

기능 플래그란?

기능 플래그는 배포 후에도 코드의 변경 없이도 로직, 시스템의 동작을 수정할 수 있도록 도와주는 장치이다.
코드내에 기능 플래그 코드를 달아서 배포를 하면 플래그를 외부에서 switch 형태로 on/off를 할 수 있는 개념으로 보면 된다.

마틴 파울러 '형님' 도 아래 본인의 블로그에도 기능 토글 (플래그)은 강력한 기술이다! 라고 이야기 하고 있다.

Feature Toggles (aka Feature Flags)

Feature Flags can be categorized into several buckets; manage each appropriately. Smart implementation can help constrain complexity.

martinfowler.com

언제 쓸 수 있나 ?

기능 플래그의 최대 장점이라고 하면 '코드 배포 시기' 와 '기능 출시' 의 시점을 분리할 수 있다는 점이라고 생각한다.
필자도 회사 내에서 기능 배포를 할 때 기능 플래그를 아주 유용하게 사용하고 있다. (주로 아래 케이스에서)

무중단 배포 환경에서 하위 호환성을 고려해 배포를 할 때

무중단 배포 방식 인 경우 주로 rolling, 카나리 배포 방식을 보통 사용하는데 텐데 이에 배포 플랜을 짤 때 많은 부분 고민을 줄여줄 수 있다.

물론 blue/green 방식을 사용한다고 할 수도 있는데 이 경우에도 롤백을 대비하기 위해서 서버군 2벌을 유지해야 한다는 단점이 있다.

배포 후 혹시나 발생할 장애 영향도를 최소화 하려고 할 때

신규 기능은 언제나 예상치 못한 side effect 가 우려 된다.
이때 점진적으로 배포 트래픽을 조절 하면서 일부 유저에게만 출시를 해볼 수 있고 혹 발생하는 장애 상황에도 즉시 기능 OFF 를 통해서 롤백이 가능하다.

Practice

기능 플래그를 이용해서 블로그에 뭘 해볼 수 있을까 하다가 재미난 것이 생각이 났다.

광고 클릭 유도 문구 노출하기

블로깅의 원동력은 뭐니뭐니 유저들의 광고 클릭이 아니겠나. ~~(작고 소중한 우리내 광고 수익..)~~
그래서 블로그 모든 포스트를 마지막에 '광고 클릭 유도(구걸) 문구'를 달아 보고 싶어졌다.
- ~~(혹자는 염치가 없는 것 아니냐 할 수도 있겠지만 이해 바람)~~
이것도 일종의 신규 기능이니 기능 플래그를 이용해서 해당 문구의 노출 여부를 control 해보도록 하겠다.

Hackle

기능 플래그를 제공하는 SaaS 는 많은데 (LaunchDarkly, Split 등등) 그 중 유일한 국내 솔루션인 Hackle 을 써보고자 한다. (친숙한 한국어)
제공하는 대시보드도 깔끔하고 생각보다 기능 플래그에서 제공하는 기능 자체가 다양해 보였다.

신규 기능 구현

먼저 신규 기능 부터 구현을 해보자.
해당 기능은 '이 글이 도움이 되었다면, Google 광고 한번씩 클릭 부탁 드립니다' 라는 문구를 모든 포스트의 제일 하단부에 추가한다는 스펙이다.
아래는 해당 스펙을 구현한 javascript 코드이다.

<script>
    window.addEventListener('load', (event) => {
        showTitle();                
    });

    function showTitle() {
        // 광고 문구
        const title = "이 글이 도움이 되었다면,&nbsp;Google 광고&nbsp;한번씩 클릭 부탁 드립니다.  ";
        const html = `<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style3">
            <h2 data-ke-size="size26"><span>끝으로</span></h2>
            <p data-ke-size="size16"><span>` + title +`</span></p>
            <p data-ke-size="size16"><span>광고 클릭은 많은 힘이 됩니다!</span></p>
            <p data-ke-size="size16">&nbsp;</p>`;
        const element = document.createElement('div');

        element.innerHTML = html;

        //하단 구글 광고 바로 위에 넣어주기
        document.getElementsByClassName('revenue_unit_wrap')[1].parentElement.insertBefore(element, document.getElementsByClassName('revenue_unit_wrap')[1]);
    }
</script>

위 코드를 tistory 블로그 html 코드에 넣어준다. (방법은 간단하니 자세한 방법은 아래 포스팅을 참고)

Tistory 블로그 HTML 소스코드 수정 방법

들어가며 티스토리 블로그에 간단한 JS 코드 수정을 하거나 HTML 수정이 필요한 경우가 있습니다. 수정 방법을 간단하게 알아봅시다. 수정방법 티스토리 관리자 페이지로 향한 뒤 좌측 메뉴 중 스

jinseongsoft.tistory.com

넣은 후 블로그 포스트를 확인 해보면 의도한 대로 광고 문구가 노출되는 것을 확인할 수 있다.
- 이제 이 기능에 기능 플래그를 붙여 control 해볼 것이다.

Hakcle 기능 플래그 생성

연동을 위해서 Hackle 계정을 생성하고 SDK Key 를 복사해두자.

핵클 대시보드에서 기능 플래그를 만들어보자.

기능 플래그 상세 페이지에서 기능 플래그키도 복사해두자. 연동에 필요하다.

SDK 를 통한 기능 플래그 코드 연동

아래 코드는 Hackle JavaScript SDK 를 연동하여 기능 플래그를 연동한 코드이다.
위에서 복사해둔 SDK_KEY 는 아래 코드의 HACKLE_SDK_KEY, 기능플래그 키는 HACKLE_FEATURE_FLAG_KEY 에 넣어준다.
위에서 했던 것과 동일하게 티스토리 HTML 을 수정해준다.

// 신규 추가
<script src="https://cdn.jsdelivr.net/npm/@hackler/javascript-sdk@11.3.0/lib/index.browser.umd.min.js"></script>
<script>
  // 운영환경 BROWSER SDK 키
  HACKLE_SDK_KEY = "cTyyDXS45JdqzCnqtZ1SQYmpNEFiDtL1";
  window.hackleClient = Hackle.createInstance(HACKLE_SDK_KEY);

  // 위에서 만든 기능 플래그키
  HACKLE_FEATURE_FLAG_KEY = 4
</script>

<script>
    window.addEventListener('load', (event) => {
          const isFeatureOn = hackleClient.isFeatureOn(HACKLE_FEATURE_FLAG_KEY);
          // 기능 플래그가 True 인 경우 광고 문구를 노출함.
          if(isFeatureOn) {
             showTitle();    
          }
    });


    // showTitle() 함수는 위와 동일 
</script>

이후에 포스트를 확인해보면 현재 기능 플래그는 꺼져 있기 때문에 문구가 노출되지 않는 것을 확인할 수 있다.

기능 플래그 조작

기능 플래그를 조작하여 여러가지 조건에 따라서 기능 출시를 컨트롤 할 수 있다.

전체 사용자 대상 출시

우리의 목적은 전체 사용자를 대상으로 배포를 하려고 한다.
상단 기능 플래그 상태의 토글을 켜짐으로 변경하자.
- 해당 토글은 기능 플래그의 최상위 활성/비활성 상태를 제어한다고 보면됨 꺼짐 상태에는 아래의 여러 설정들이 다 무시된다.

그리고 제일 하단에 모든 사용자 설정에서 트래픽을 100% 로 올려주자.
- 해당 트래픽은 충분히 점진적으로 늘려갈 수 있다.

특정 사용자 (테스터, 내부자) 대상 출시

'개별 타겟팅' 항목에서는 특정 사용자 혹은 사용자 그룹을 어떤 상태로 적용할지 설정할 수 있다.
주로 내부 테스트 용도로 사용되며 '사용자 식별자' 를 지정할 수 있다.

타겟팅 규칙으로 출시

'사용자 타겟팅' 항목에서는 여러 규칙의 조합으로 규칙에 부합하는 사용자에 대해서 어떤 상태로 적용할지 설정할 수 있다.
- ex) 모바일 앱의 기능을 출시하는 경우 Android 유저의 50%에게만 기능을 출시하고 싶은 경우
추가적으로 규칙에 해당하는 사용자들에 대해서도 점진절으로 트래픽을 설정하여 출시할 수 있다.

More Practice

좀 더 재밌는 것을 해보고 싶어졌다.
기능 출시를 통해서 광고 문구를 노출 시켰는데 문구가 맘에 안들 수도 있지 않은가? (그렇다고 하자)
- 문구도 원하는 대로 수정하고 싶은 욕구가 생기지 않는가 ..
친절하게도 기능 플래그 기능 중 '파라미터 설정' 이라는 기능을 통해서 코드상에서 사용할 수 있는 파라미터를 동적으로 설정할 수 있다.

파라미터 설정

다행히 Hackle 에서도 해당 기능을 제공하기에 핵클 대시보드에서 파라미터 설정을 해보자.
파라미터 키는 간단하게 title 로 하고 value 는 광고 문구 변경 테스트 로 설정해보자.
- 필자는 True 인 경우에만 문구를 노출하기 때문에 True 측 value 에만 값을 넣어주었다.
- 프로플랜 지원 기능이라 업그레이드 요구를 하는데 카드 등록 없이 무료체험만 해도 되니 일단 해보자..

기능 플래그 연동 코드 수정

위에서 설정한 파라미터를 코드상에서 사용하게끔 수정을 해보자. (사실 이걸 위해서 title 을 변수화 시켜두었다..)
이전에 작성한 소스에서 title 을 설정하는 코드를 아래와 같이 수정을 하면 된다.
- 혹여 파라미터를 가져오지 못하는 경우에는 SDK 에서는 우리가 설정한 default 값을 반환한다.
- showTitle() 함수를 수정할 것이다.

<script>
    function showTitle() {
        // 광고 문구
        const defaultTitle = "이 글이 도움이 되었다면,&nbsp;Google 광고&nbsp;한번씩 클릭 부탁 드립니다.  ";

        //기능 플래그의 상태에 따른 파라미터 정보 (ex. True 로 결정된 경우 True 파라미터 정보만 내려옴)
        const parameters = hackleClient.featureFlagDetail(HACKLE_FEATURE_FLAG_KEY);

        //파라미터 키로 값 가져오기
        const title = parameters.get("title", defaultTitle);

        //아래 기존 코드는 동일 .. 
    }
</script>

위 코드를 한번 더 티스토리 html 에 수정하여 적용한다.

파라미터 값 업데이트

일단 수정한 코드를 반영한 뒤 포스트를 확인해보면 변경한 광고 문구가 보여지는 것을 볼 수 있다 !
- 혹 업데이트가 안되는 경우 브라우저 캐시 때문일 수도 있으니 브라우저 '강력 새로고침'을 해주면 된다.

좋은 건 한번 더 보라고 대시보드에서 다른 값으로 변경하고 다시 확인을 해보자.

마무리 하며

눈물젖은 배포 해보셨습니까

위 과정을 돌아보면서 실제 Production 환경에 기능을 출시하는 상황이라고 생각을 해보면 한단계, 한단계가 '기능 수정 후 배포' 를 의미 할 것이다.
- 배포 과정을 생각해보면 그리 짧은 시간에 이뤄지지는 않은 것이라 생각한다. 그러다 장애라도 낸나면? 끔찍하지 않은가?
- 필자의 경우에는 소개팅이 있는 날 배포를 하다가 급한 마음에 단순한 클릭 실수를 해서 큰 장애를 낸 적도 있었다 ..

이런 관점에서 본다면 기능 플래그는 그 자체로 사용할 의미는 충분하다고 본다. 요즘 많은 IT 회사들도 기능 플래그를 적극적으로 활용하는 것으로 알고 있다.
- 일례로 필자의 회사에서는 모든 기능에 기능 플래그를 달고 출시를 한다. 일종의 보험이 된 것 같다.
- 물론 연동 코드가 과도하게 쌓이다 보면 부채가 될 수도 있지만 ..

A/B Test

그리고 한편으로는 광고 문구를 붙이기는 했지만 이 문구가 정말 좋은 효과가 있을까?
- 오히려 유저들의 심기를 건드려 안좋은 효과를 줄 수도 있지 않을까?
이럴 때 사용할 수 있는 방법이 최근에 관심도가 증가 하고 있는 A/B 테스트이다.
- 다음번 예제에서는 광고 문구 노출 기능을 A/B 테스트로 실제 유저들에게 미치는 효과를 살펴보고자 한다.

[Git] git hooks 를 활용하여 커밋 메시지 prefix 적용하기

rlawlstjd007 — Wed, 4 Jan 2023 21:27:13 +0900

들어가며

회서 업무를 하다보면 보통 커밋 컨벤션이 있기 마련인데 필자의 경우에는 JIRA 를 사용하면서 JIRA 티켓 번호를 prefix 로 불여주고 있다.
- ex. [PROJ-9321] refactor: .....
다만 매번 티켓 번호를 타이핑 하는 것에 피로감이 느껴지면서 자동으로 붙여줄 수 없을가 고민하면서 git hooks 라는 방법을 적용해보았다.

Git Hooks

Git 에서 제공해주는 기능으로 다양한 상황 (commit, merge 등) 에서 트리거되는 작업에서 실행되는 동작을 정의할 수 있다.
자세한 내용은 공식 문서 참고

Git - Git Hooks

If you’re writing a script/hook that others will need to read, prefer the long versions of command-line flags; six months from now you’ll thank us.

git-scm.com

적용해보기

hook 을 적용하기 위해서는 원하는 hook 을 확인하고 해당 hook 파일에 쉡 스크립트 형태로 동작을 정의할 수 있다.

현재 branch 명 추출하기

shell 에서 grep 명령어를 통해서 현재 브랜치 이름만 가져오는 코드이다.
이제 아래 코드를 스크립트에 적용할 것이다.

$ git branch | grep '\*' | sed 's/\* //' | sed 's/\([^/]*\).*/\1/'
PROJ-2372

prepare-commit-msg

나의 경우 커밋을 하는 시점에 커밋 메시지를 가공하고 싶었기에 'prepare-commit-msg' 훅을 사용하게 되었다.
이제 적용을 원하는 git 프로젝트의 '.git/hooks' 디렉터리에 prepare-commit-msg 파일을 생성하고 아래 코드를 넣는다.

#!/bin/sh  
# .git/hooks/prepare-commit-msg  
#  
# Automatically add branch name and branch description to every commit message except merge commit.  
# https://stackoverflow.com/a/18739064  
#  
  
COMMIT_MESSAGE_FILE_PATH=$1  
  
# merge commit에 대해서는 prefix를 생성하지 않는다.  
MERGE=$(grep -c -i 'merge' < "$COMMIT_MESSAGE_FILE_PATH")  
if [ "$MERGE" != "0" ] ; then  
  exit 0  
fi  
  
PREFIX=$(git branch | grep '\*' | sed 's/* //' | sed 's/^.*\///' | sed 's/^\([^-]*-[^-]*\).*/\1/')
echo "[$PREFIX] $(cat "$COMMIT_MESSAGE_FILE_PATH")" > "$COMMIT_MESSAGE_FILE_PATH"

이후에 해당 파일을 실행 가능하게 권한을 준다.
그리고 커밋을 해보면 브랜치명이 '[PROJ-3124]' 형태로 prefix 로 붙는 것을 확인할 수 있다.

$ chmod +x .git/hooks/prepare-commit-msg

참고

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 여섯째 날

rlawlstjd007 — Tue, 20 Dec 2022 11:54:46 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

행사 끝 (PST 09:30)

오늘은 AWS re:invent 일정을 종료되었고 메가존 측에서 마련해주신 여러 옵션의 액티비티에 참여하는 날이었다.
그랜드 캐니언, 레드락 캐니언, 데스 밸리 등이 있었는데 그 중에 우리 회사분들과는 데스 밸리에 갈 예정이었다.
일찍 나와서 출발을 기다리고 있었는데 문득 '그냥 렌트해서 따로 가는게 낫지 않을까?' 하는 의견이 급 물살을 타게 되어 방향을 틀어 버렸다 (물론 죄송 스럽긴하지만..)

렌트 차량이 마침 머스탱 밖에 없어서 의도치 않게 오픈카를 타게 되었다. 결과적으론 꽤나 만족 스러웠던 것 같다 ! 눈을 조금 희생시키긴 했지만 시원하게 달리며 레드락 캐니언으로 향했다.
호텔존 과는 불과 차 타고 30분 정도 밖에 소요 되지 않아서 가벼운 마음으로 갈 수 있었다. (그랜드 캐년은 거의 4시간이 걸린다고,,)

그렇게 캐니언에 도착했는데 창밖으로 보이는 풍경에 말문히 막혔다. 생각했던 것 보다 규모가 꽤나 커서 방문객 센터에 계신 관리인 할아버지께 코스 추천을 받았다.
코스에 따라서 하이킹이 필요한 코스가 있고 하이킹 난이도도 천차 만별이었다. 처음엔 3 ~ 4 군데 정도는 하이킹 해보자 하는 생각으로 길을 떠났는데 정말 큰 오산이었다.

첫 코스로 왕복 3시간 정도 코스의 하이킹을 가벼운 마음으로 시작했는데 이내 보이는 심한 경사의 암벽들을 보며 생각을 고쳐 먹었다. 힘겹게 정상에 올랐는데 그만큼의 보람은 있었던 것 같다. (필자만 그렇게 생각했을 수 있음 주의)
절벽 너머로 Las Vegas 시내가 시원시원하게 보였다. 사진도 실컷 찍고 서둘러 하산했다.

내려와서는 다들 무리한 하이킹 탓에 이후 코스는 생략하자는 의견이 지배적이었다.
'그래도 한번 가보는게 어떨까요' 라는 의견을 냈지만 처참히 묵살 당했고 ⚔️ 그렇게 우리는 숙소로 돌아갔다. 생각해보니 밥도 한끼도 안 먹은 상태였다.

돌아와서 완태님과는 당연스럽게 '김치 식당' 으로 향했다. 나머지 두분은 타코를 드시러 가셨다.
고민 끝에 곱창 전골을 시켰는데 한 입 맛보고는 소주를 시키지 않을 수 없었다.
한병 또 맛있게 먹고 숙소로 돌아와 저녁을 위해서 잠깐 또 잠을 청했다.

오늘은 일주일 내내 케어 해주신 메가존 매니저님과 회사 분들과 저녁 식사를 했다.
'The Boiling Crab' 이라는 해산물 식당으로 향했다. 식사의 형태가 꽤나 신기했다. 게, 랍스터, 새우등 해산물을 시키면 테이블에 음식을 부어주고 비닐 장갑을 끼고 자유롭게 먹는 방식이다.
한국에도 비슷한게 생기면 꽤 히트하지 않을까 싶은 생각이 들었다. 사진만 봐도 느껴지지만 역시나 엄청 짰다. 그래도 꽤 배불리 먹은 것 같다.

2차로는 호텔 근처 시가바에 가보았다. 첫 경험이라 너무 설렜는데 보통 한번 태우는데 30분 정도 소요가 되는 것 같았다.
양주와 시가, 씁쓸함을 온전히 느끼고 돌아왔다. (이후 생략)

다음날 떠나야 해서 밀린짐을 열심히 싸고 용님이랑 출출해서 감자튀김에 맥주 한잔 더 하고 5시가 넘어서 잠에 들었다.

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 다섯째 날

rlawlstjd007 — Sun, 18 Dec 2022 09:38:51 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

드디어 찾은 김치찌개 맛집 (PST 09:30)

오늘은 완태님과 둘이서 길을 나섰다. 해장은 하고 싶은데 타코는 도저히 먹을 수가 없을 것 같다. '김치 식당' 으로 향했다.
김치찌개를 각자 시켜 먹었는데 너무 맛있어서 둘다 인생 최고의 김치찌개로 평했다.
- 가격을 보니 당연히 그래야 할 것 같기도 했다.

3만원 짜리 김치찌개

오늘은 re:invent 행사 마지막 날이기도 해서 세션도 각자 듣고 싶은 걸 듣기로 했다.
'AWS' 측에서 발표하는 'Scaling on AWS for your first 10 million users' 라는 세션을 들었다.
AWS Managed Service 를 최대한 활용 하여 10 million user 까지 감당할 수 있는 시스템을 설계하는 노하우를 설명 해주었다.

오늘도 막간을 이용해서 Expo 를 돌아 다녔다. 몇 군데 돌아다녀 보았는데 그 중에서도 인상 깊은 곳들이 있었다.
- 한번 사용해보고 추후에 정리를 해볼까 한다.
그리고 마지막날이라 그런지 SWAG 떨이를 다들 열심히 하고 있어서 최선을 다해서 줍줍을 하였다.
- 티셔츠를 인생 2회차까지 입을 만큼 더 모았다.

놀이공원으로 (PST 16:30)

원래는 더 돌아다니려 했지만 용, 석연님 스케줄이 일찍 끝나셔서 다 같이 도심내에 있는 놀이공원을 가기로 했다.
큰 기대는 안했는데 생각보다 미친 스릴을 느낄 수가 있었다. 원래는 한번 탈때마다 돈을 내야 하지만 문지기 형님이 그냥 더 타라고 해서 한번 더 탔다
- . 세번째도 한번 더 타라고 했는데 그랬다가 10번 정도는 타야 할 것 같아서 사양하고 나왔다.

근처에 MGM, New York New York, Mirage 등 호텔들이 근처에 모여 있어서 열심히 돌아다녔다.

석연님 추천으로 비틀즈 쇼를 예약해서 보게 되었다.
꽤나 좋은 자리를 예매해서 감상했는데 살아 생전 비틀즈의 인생에 대해서 관심을 가져보질 못해서 .. Context 부족으로 인한 어쩔 수 없는 숙면을 취했다 ..
- 돈이 아까웠지만

공연 후에는 미국식 윙 맛집으로 향했다.

AWS re:play (PST 23:30)

그렇게 숙소로 돌아와서 회사분들은 막간을 이용해 잠을 청하시는 사이에 남은 에너지를 활용해 re:play 행사에 다녀왔다.
갑자기 바람이 너무 많이 불어서 당황하긴 했지만 .. 블로그에 꼭 소개를 해야 겠다는 일념하에 이곳저곳 사진을 찍어왔다.

전체 행사장은 꽤나 넓은 데 크게는 세 곳 정도의 공간으로 나눠져 있다.
먼저 Main Stage 라는 공간에서는 유명한 가수들이 와서 공연을 한다.
도착을 했을 때는 거의 마지막 순서였는데 'martin garrix' 라는 꽤나 유명한 DJ 가 와서 공연을 하고 있었다.

'Live Stage' 라는 공간은 Main Stage 와 비슷하게 공연을 하는 공간 같았는데 규모가 조금 작은 것 같았다.
The Arena 에는 약간 play ground 처럼 공놀이를 할 수 있는 공간도 있고 여러 액티비티를 즐길 수 있게 해두었다. 모두들 열심히 하더라 ..

그리고 베가스 거의 모든 호텔로의 셔틀도 운영하고 있었다. 넘나 친절 ..

그렇게 숙소로 돌아와 메가존 매니저 분께서 마련 해주신 소소하게 술먹는 자리에 참여했다.
덕분에 조니워커도 먹고 손맛가득한 비빔면도 맛있게 먹으며 또 하루를 그렇게 마무리 했다.

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 넷째 날

rlawlstjd007 — Sat, 17 Dec 2022 16:37:36 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

아니요. 아무도 없어요. 없었어요 ❌ (PST 09:30)

일어나보니 아무도 없었다.. 다들 내가 잠든 사이에 밤을 새시고 아침에 타 스타트업 분들과 식사를 하고 오셨다.
다들 너무 힘드셨는지 주무시고 계셔서 혼자서 길을 나섰다.
익명의 제보자 분으로 부터 추천받은 '판다 익스프레스' 에 가서 점심을 먹었다.
이 역시 기대를 많이 한 탓인가 살짝 아쉬웠다. 하지만 가격과 양은 만족 스러웠다. 다음번엔 꼭 오렌지 치킨을 먹어야지

이후 즉시 Expo 로 향했다. 오늘은 다를 것이라는 기대감을 안고 갔는데 어제 고생한 효과가 있었던 것 같다.
약간의 영어 멘탈 모델이 생긴 느낌으로 어제에 비하면 정말 많은 사람들과 이야기를 했다.
- 아래는 이제껏 만났던 사람들과 찍었던 사진들. 이렇게 보니 꽤나 보람차다.

느꼈던 Insight

크게 Dev Ops, Observability (Monitoring), Security, Data Analytics 분야의 기업들이 많았다. (Security 분야는 생각치 못했지만 너무 많아서 놀람)
Dev Ops 관련 해서는 다양한 integration, 간편한 infra 세팅 (visual editor) 을 내세우는 곳들이 많았다.
Observability (Monitoring) 는 역시나 기깔나게 만들어야 하는 구나 하는 생각이 들었다.
- APM, Error Detection, Logging, Container 정도의 세부적인 모니터링 요소들이 있었고 다들 완성도가 높다고 느껴졌다.
- 쓰고 싶게끔 만드는 visiable 적인 부분들을 확실히 강조를 하고 있었다.
Security 는 기업들도 많은 만큼 다양한 측면의 보안 솔루션 들을 제공하고 있었다. 각 영역별로 전문성을 가지는 형태였음
- cloud 환경에서 네트워크 레벨의 취약점 분석
- EC2 Instance 보안을 위한 Custom AMI 제공
- Docker Container 레벨 취약점 분석 등등 이외에도 굉장히 다양한 Product 가 존재했음
그리고 나머지는 실제로 name value 가 있는 product 들

들렸던 부스 (회사) 들이 꽤나 많았는데 간략하게 정리를 해보자면

DB

Neo4J: 그래프 DB 시스템

Neo4j Graph Data Platform – The Leader in Graph Databases

Connect data as it's stored with Neo4j. Perform powerful, complex queries at scale and speed with our graph data platform.

neo4j.com

Timescale: Postgres 기반으로 만들어진 time series DB 솔루션

Time-series data simplified

TimescaleDB is a time-series SQL database providing fast analytics, scalability, with automated data management on a proven storage engine.

www.timescale.com

Security

DEVO: dsaa

Devo: Cloud-Native Logging, SIEM, Security Analytics & AIOps

Devo is the cloud-native logging and security analytics solution that delivers real-time visibility for security and operations teams.

www.devo.com

COMMVAULT

Home

Commvault protects your organization's data through one complete data protection solution. Providing peace of mind.

www.commvault.com

Data

Data Iku: 데이터 파이프라인 및 사이언스 플랫폼

Dataiku | Everyday AI, Extraordinary People

Dataiku is the world’s leading platform for Everyday AI, systemizing the use of data for exceptional business results.

www.dataiku.com

Imply: Apache Druid 기반 Managed Service

Imply

Imply, founded by the original creators of Apache Druid®, develops an innovative database purpose-built for modern analytics applications.

imply.io

Monitoring

Helios: Microservice 기반 APM

The developer platform for cloud-native applications • Helios

Helios - the production-readiness platform for developers. Leverage OpenTelemetry to deliver reliable distributed applications faster and with more confidence.

gethelios.dev

Coralogix

Coralogix - Full-Stack Observability Platform with In-Stream Data Analytics

Coralogix provides in-stream data analytics that doesn't rely on storage or indexing enabling teams to extract infinite insights from their observability data.

coralogix.com

Dev Ops

STRUCTURA: visual editor 기반 Terraform 개발 지원

Home | Infrastructure as Code, Reimagined.

Structura is a drag-and-drop user interface that automatically writes complete and flawless Infrastructure as Code (IaC)

www.structura.io

GRANULATE: Workload Performance Optimization Tool

Granulate autonomous continuous optimization

Cut infrastructure costs and improve application performance with Autonomous Continuous Workload Optimization - with 0 code changes.

granulate.io

중간에 Split 에서 진행하는 'Drive positive impact with feature flags and data' 세션을 들었다.

본인들의 프로세스를 'feature flagging journey' 라는 과정으로 단순한 flagging 에서 부터 experiment 를 진행하는 과정까지로 연계하여 설명하였다.
Feature Flagging 을 base 로 하여 제품 혹은 기능 개선의 iteration 을 진행하는 과정을 설명하는 게 인상 깊었다.
- 이 또한 굉장히 포장을 잘 했구나 라는 생각이 들었다

실제 예시로는 Kiness -> Kafka 마이그레이션 과정, Amazon S3 -> Mongo DB 마이그레이션 과정을 설명했다.
전체 세션은 15분 정도로 가볍게 봐도 좋을 것 같다.

그렇게 열심히 SWAG 도 모았더니 아래와 같이 되버렸다. 거의 평생 입을 정도의 티셔츠와 양말을 모았다. 챙겨갈 걱정은 나중에 하는 것으로 하고 ..

숙소로 돌아와서 막간을 이용해서 호텔 수영장도 가보았다. 역시나 시설이 엄청 좋았다.

그리곤 잠시 잠을 청하고 다시 저녁을 먹으러 나섰다. 오늘도 메가존에서 마련한 '메가 나이트' 라는 꽤나 큰 저녁 식사 자리에 참여했다.
솥뚜껑 삼겹살을 맛있게 먹고 메가존 대표님과도 인사를 나누고 경품 추첨도 했다.
용, 석연님은 열심히 네트워킹을 하셨고 완태님과 둘이서 숙소로 돌아왔다.

왔으니 살짝 놀아줘야 겠다는 생각에 완태님과 살짝쿵 즐긴 뒤에 돌아와 잠을 청했다.

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 셋째 날

rlawlstjd007 — Thu, 15 Dec 2022 16:18:41 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

처음이자 마지막인 완전체 동행 (PST 09:30)

잠을 조금 자긴 자고 .. 일어나서 용, 완태님과 찐 미국식 브런치 식당으로 향했다. (첫날에 빅터 형님이 추천해준 식당)
가게 풍경은 미국 영화에서만 보던 진짜 미국미국 스러운 모습이었다.

어찌저찌 각자 다양하게 메뉴를 시켰는데 나온 결과물을 보고 모두들 경악을 금치 못했다.
미국 음식은 default 가 곱배기 인듯 싶었다 (생각해보니 빅터 형님 풍채가 남다르긴 했었다 ..)

오늘은 세션 대신 엑스포를 보러 가기로 했다.
엑스포는 베네치안 호텔 엑스포홀에서 3일 정도 열리며 굉장히 많은 AWS 파트너사 및 AWS 전문가 들을 만나볼 수 있는 자리이다.
다양한 SaaS 기업들의 Product 들에 대한 소개 및 데모도 볼 수 있고 자유롭게 이야기도 나눌 수 있는 자리이다.
- 덤으로 부스별로 다양한 SWAG (티셔츠, 굿즈 등) 도 가질수가 있다.

본격적으로 입장을 해서 이곳 저곳 돌아다니기 시작했다. 처음에는 셋이서 꼭 붙어 다니려고 했었다. (완태님이 영어를 좀 쳤었다)
근데 그러다 문득 셋이 다니면 아무말도 하지 않을 것 같아서 도전해보자는 마음에 혼자서 돌아다니기로 했다.

처음이 정말 어려웠는데 말을 붙이기가 좀처럼 쉽지가 않았는데 몇번을 서성이다 그나마 만만한 런치다클리 부스로 향해서 아무것도 모르는 사람 처럼 다가갔다.
- 서툰 영어로 이것저것 물어보았는데 생각보다 너무 친절하게 답변 해줘서 놀랐다 ..
그리고 그들의 데모 퀄리티에도 또 한번 놀랐다. 길다란 모니터에 대시보드, 예제 화면을 각각 띄워두고 대시보드 조작에 따라서 즉각적으로 화면이 업데이트 되는 모습을 보여주는데 (SSE 라 이게 좋구나 .. ) 예제가 꽤나 짜임새 있게 만들어져 있어서 보는 맛이 있었다.
확실히 벤치마크 할점이 많았던 것 같다. 우리도 훗날 이렇게 멋있게 데모를 하는 데 신경쓸 날이 왔으면 .. 그렇게 한참을 이야기 하고 셀피도 찍고 SWAG 으로 양말도 받았다. (꽤나 이쁨)

그 이후로 적응이 된줄 알았지만 시도를 할 때마다 꽤나 많은 용기를 내서 다가갔었던 것 같다. 4 ~ 5 군데 정도를 방문 했던 것 같은데 너무 정신이 없어서 사실 크게 기억이 나지는 않았다.
그래도 얻었던 insight 는 보안쪽 업체들이 생각보다 많다는 것을 느꼈다. 보안이라함은 cloud 측면에서 AWS 를 사용하면서 네트워크 레벨의 취약점 부터 시작해서 EC2 Instance 보안을 위한 Custom AMI 제공, Docker Container 레벨 취약점 분석 등등 굉장히 다양한 Product 가 많았다!
사실 서툰 영어로 듣기도 했고 생소한 개념들이 많아서 완전히 이해하기는 쉽지 않았던 것 같아서 아쉬운 점이 많았다.

서버리스 아키텍쳐로 구성된 커피 주문 서비스

그렇게 2~3 시간 정도를 돌아다녔는데 그 결과 진이 완전히 빠져 버려서 정신이 혼미해졌다 ..
도저히 돌아다니기에는 어려울 것 같아서 일단 머리도 식힐겸 쇼핑센터로 향했다.
- 기대했던 애플 스토어를 들렸지만 쿠팡 보다 비싼 가격에 상심이 컸다. 너무 컸어서 그런지 사진도 안찍음 ..

저녁 먹기 전 괜찮은 세션이 하나 있는 것 같아서 완태님과 들으러 갔지만 너무 핫한 대기열 탓에 다시 나올 수 밖에 없었다.
- 또 한번 미리 예약 하지 못한 서러움을 느끼면서 숙소로 향했다.

저녁 일정 시작 (PST 18:00)

너무 지쳐서 2시간 정도 자고 다시 저녁을 먹으러 나섰다.
저녁은 역시나 'Korean Chinese' 식당이었고 고량주와 여러 안주를 시켰는데 안주가 꽤나 맛있어서 놀랐다.
- 이 글을 쓰고 있는 지금와서 보니 미국서 먹을 제일 맛있었던 음식이었다 ..
특히나 쿵바오 치킨 이라고 불리는 이 녀석이 제일 맛있었다 (궁보계정 이라고도 불리는 것 같다)
술이 진짜 뚝딱쓰. 식사를 함께한 스타트업 분들과 이런저런 이야기를 나누고 자리를 나섰다.

미국 최고의 음식

다음 일정으로는 완태님과 Snow Flake 에서 주최하는 Party 에 가기로 했다.
풀파티라고 해서 잔뜩 기대를 하고 갔는데 왠걸 한국인들은 보이지 않고 미국 영화에서만 보던 풍경이 펼쳐 지고 있었다.
핫한 인싸들의 소굴에서 우리가 할 수 있는 건 딱히 없어보였다 .. 술만 홀짝홀짝 먹다가 눈치보고 나왔다.

누님이 말아주신 깔루아 핫초코

바로 숙소를 들어가기는 아쉬워서 호텔존으로 조금 걸어보기로 했다.
베네치안 -> 벨라지오 -> MGM 호텔을 지나면서 중간에 분수쇼도 보고 피아노 펍 공연도 보고 꽤나 알차게 시간을 보냈다.

지칠 때쯤 숙소에 가기 전 멕시칸 바에 가서 술 한잔씩 하고 가기로 했다.
맛난 데낄라 샷 기대하고 들어갔는데 output 을 보고 너무 실망 스러웠다.
- 편의점 소주잔에 앙증맞게 채워져 있는 데낄라 샷을 보고 실망 스러움을 넘어서 화도 살짝 날 정도였다 ^

마음을 다스리고 호텔로 돌아와서 메가존에서 호텔의 바를 빌려서 네트워킹을 할 수 있게끔 '하이퍼 나이트' 라는 자리를 마련해 줘서 가서 또 술 한잔을 하게 되었다.
우연히 고등 학교 지인 개발자 친구를 만나서 AB180 <-> Hackle 만담쇼를 가볍게 나누고 방으로 들어가나 싶었지만 방에서 회사 분들과 가볍게 맥주 몇잔 더 하고 방으로 돌아와 잠을 청했다.

지금 보니 정말 열심히 시간을 보냈구나 .. 싶다.

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 둘째 날

rlawlstjd007 — Wed, 14 Dec 2022 21:38:03 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

.. .. 축구 보러 가야지 (PST 05:00)

2 ~ 3 시간 정도 잤으려나, 현지 시간으로 새벽 5시에 나왔다. (이때부터 모든게 잘못되기 시작한 것 같다)
리인벤트에 초청해준 메가존에서 근처 한식당을 빌려서 밥도 먹고 월드컵도 관람할 수 있게 자리를 마련해주었다.
이른 시간이라 사람이 별로 없을 줄 알았지만 이게 왠걸 .. 사람이 너무 많아서 들어가지 못하는 분들도 많이 계셨다.

음식은 생각보다 맛있어서 놀랐다.. 이곳은 여행 중간중간 해장이 필요할 때 마다 오게 되었다.
전반전에 2골을 실점하고 숙소로 돌아왔는데 돌아가는 와중에 2골을 넣고 숙소에 도착하자마자 1골을 먹히더라 ..

.. .. 리인벤트 가야지 (PST 12:00)

잠깐 또 눈을 붙이고 AWS re:invent 등록을 하러 행사장인 베네치안 호텔로 향했다.
날씨에 한번 놀랐고 스타벅스 커피 사이즈에 또 한번 놀랐다.
베네치안 호텔까지의 거리는 꽤 되었지만 산책겸 천천히 걸어갔다.

호텔 내부도 워낙 커서 행사장 까지 한참을 걸어갔다.
걷다보니 익숙한 회사들의 선전 문구들도 보였다.

그렇게 register 부스에 도착을 했다. 부스에서는 크게 구매한 컨퍼런스 티켓을 뱃지 (목걸이)로 바꿔주는 곳과 수령한 뱃지로 AWS 후드집업을 수령하는 곳이 있었다. (월드컵 시즌이라 월드컵도 보여주고 있었다.)
사실 필자는 사정상 컨퍼런스 티켓을 구매하진 못하였는데 부스 중간에서 멀뚱히 있는 모습이 가엾어 보였는지 그 자리에서 컨퍼런스 티켓을 구매해주셨다.
너무 감사할 따름 .. 사실 조금 피곤했었는데 순식간에 싹 가셨다.
- 시차적응 실패해도 돼 우리 회사 절대 지켜 ..

근처 라운지에는 사진 Spot, 오락기 등등 쉴수 있는 공간이 있었고 그 가운데 큰 칠판에 여러 회사들이 기록을 남겨두고 갔다. (그 중엔 심심치 않게 고객사들도 보였다)
그 가운데서도 당당하게 한 장 박았다.

당당한 '진성소프트'

본격적인 행사 참여 (PST 15:00)

용, 석연님은 호텔에 가서 조금 쉬신다고 하셔서 완태님과 둘이서 세션을 들어보기로 했다.
세션은 AWS Event 앱을 통해서 예약을 할 수는 있었지만 괜찮은 주제의 세션들은 이미 예약이 다 마감되었다.
- 이 또한 천추의 한으로 .. 만약 re invent 에 참가하게 된다면 미리미리 앱으로 예약하도록 하자

AWS Events - Apps on Google Play

Official AWS Events app

play.google.com

그리고 세션을 듣고자 한다면 호텔간의 동선도 잘 고려해야 한다.
- 아래 이미지를 보면 끝과 끝인 Encore <-> Mandalay Bay 간의 거리는 차를 타도 거의 20 ~ 30 분 정도가 소요된다.
그래서 왠만하면 호텔간 이동 없이 세션을 듣는 것을 추천한다.

세션까지는 시간이 조금 남아서 점심을 먹기로 했다. 고민 끝에 선택한 것은 in & out 햄버거
맛은 .. 무난무난 했다. 그리고 역시 짰다 치즈도 짜고, 감자도 짜고 (하지만 이땐 몰랐다. 이게 싱거운 편이란 걸..)
지금와서 가격을 보니 너무 착하네. in & out 도 누군가 지켜주길 ..

세션을 들으러 시져스 포럼으로 향했다.
맛보기 세션으로 dynatrace 에서 발표하는 'Modernize faster with sevrerless and end-to-end observability' 라는 세션을 들었다.

서비스 특성에 맞게 serverless Lambda Function 을 효율적으로 사용하는 방법, sevrerless 형태의 서비스를 하기 위한 AWS 서비스 등에 대한 내용이었다.
- 중간에 들어왔다가 다음 세션이 있어서 금방 나왔다.

이 후에 목표로 했던 Braze 에서 발표하는 'Saling a SaaS company for public company readlness' 라는 세션을 들었다.
- [OVERFLOW] 라는 형태의 세션이었는데 알고보니 아래 이미지 처럼 실제 세션을 하는 곳은 따로 있고 실시간으로 헤드폰으로 스크린을 통해서 세션을 보는 형태였다.

대략적인 내용은 SaaS 가 상장을 하기 위해서 필요한 요소들에 대한 설명이었는데 리스닝이 그리 좋지는 못해서 완벽하게 이해하기는 쉽지가 않았다 ..
흥미로웠던 점은 bug bounty 프로그램을 운영하는데 bug 가 발생하는 상황 마다를 test 환경을 독립적으로 k8s 환경에 구축해서 QA 를 진행하는 자동화 시스템이 있다는 내용이었다.
돌이켜 보니 오히려 youtube 에 업로드 되는 세션 내용을 듣는 게 더 나을 것 같다는 생각에 OVERFLOW 세션은 되도록이면 지양 하려고 했던 것 같다.

이후 세션으로는 dynamo DB 모델링에 대한 팁을 소개 해주는 세션을 들었는데 Dynamo DB 개발을 직접하고 있는 개발자들이 연사로 들어왔다.

Dynamo DB 는 트래픽 규모가 큰 게임사에서도 많이 쓰이며 몇 TB 가 넘는 대용량 데이터를 두 자릿수 이하 ms 의 latency 의 성능으로 조회가 가능하다는 점을 강조하고 있었다.
Dynamo DB 로 모델링을 할 때 use case 를 기반으로 설계를 하는 방법 best practice, indexing, transaction, replication 등 여러 내용을 들었는데 개발 관련 용어들과 강의 자료 덕분에 이해하기가 수월했다.

마지막 세션으로는 Launch Darkly CTO 가 발표하는 Feature Flag 사용 사례에 대한 세션이었다.

본인들의 내부 아키텍처도 보여주었고 '혹자는 feature flagging 이 단순한 분배기라고 하지만 그 안에는 생각보다 복잡한 아키텍처로 구성 되어 있다' 는 내용을 강조하였다.
- 흥미로웠던 점은 SDK 의 설정 정보 동기화를 위해서 Server Send Event 방식을 이용한다는 점 이었다. 기능 플래그 좀 치는데 ?
- 물론 우리도 초기 설계 당시 고민을 했었다고 한다. 즉시 동기화는 물론 좋지만 그에 따른 관리 비용을 생각하면 고민해볼만한 point 다
한 3가지 정도 기능 플래그 사용 케이스를 설명 했는데 (DB 마이그레이션, 외부 Third-Party 의존성 관리, Infra 마이그레이션) 꽤나 흥미로웠고 포장을 굉장히 잘 한다는 생각이 들었다.
해당 세션에 대한 자세한 요약 내용은 아래 포스팅을 참고해주세요 !

AWS re:Invent 2022 - Building and operating at scale with feature management 요약

Building and operating at scale with feature management Background AWS re:invent 2022 에서 Launch Darkly 가 진행한 세션으로 feature flag 를 통해서 효과적으로 대규모 운영 및 관리를 하는 방법에 대한 내용을 설명한다.

jinseongsoft.tistory.com

또 끝나고 든 생각이지만 런치다클리 CTO 랑 사진한번 찍어 볼 걸 .. 하는 생각이 뒤 늦게 들었다 .. 이 또한 천추의 한

아쉬움을 뒤로 하고 저녁 식사를 하러 떠났다.
해당 자리 또한 메가존 측에서 한국 식당을 예약해서 함께 행사에 참여한 여러 스타트업과의 자리였다.
같이 식사하시는 분들과 인사 및 이야기를 나누고 용님은 이리저리 돌아다니면서 열심히 네트워킹을 하셨다.

새벽 중 위험한 산책 (PST 02:00)

그렇게 숙소로 돌아와서 일찍 잠을 청했는데 자꾸 새벽에 깼다. 잠도 안오고 해서 산책이나 가볼까 하여 혼자서 나왔다.
- 구글 맵에 근처에 평점이 꽤나 괜찮은 샌드위치 집이 있어서 가보기로 했다.
- 비교적 안전한 호텔존이 아닌 반대쪽 old town 쪽이었는데 모험심으로 가보기로 했는데 사실 걷는 내내 총맞을 까봐 노심초사 하며 걸었다 ..

그렇게 먼길을 달려와 먹은 샌드위치 (= 20$). 맛에 한번 놀랐고 가격에 두번 놀랐다. 이게 미국인가 ?

그렇게 다시 조심조심 돌아와 호텔 카지노에 오자마자 마주한 익숙한 뒷태. 잠이 안와서 내려오신 석연님과 햄버거 한번 더 때렸다.
'진짜 내일 어떡하지?' 하는 생각으로 잠에 들었다.

Las Vegas 여행기(feat. AWS re:Invent 2022 참가기) - 첫째 날

rlawlstjd007 — Wed, 14 Dec 2022 11:41:52 +0900

AWS re:invent 2022 를 다녀오며 ..

회사에서 정말 좋은 기회를 주셔서 AWS re:invent 2022 를 참여하여 라스베가스에 다녀왔습니다.
그때의 여행기를 일자별로 최대한 자세하게 남겨보았습니다.

설레는 출발

주말에 헐레벌떡 짐을 싸고 출발 준비를 마쳤지만 출발 전 회사분께서 해주신 말씀이 늘 마음속의 짐으로 남았다.
- "진성님, re invent 를 간다는 건 온 동네 사람들이 알아야 해요 옆집 아주머니, 아랫집 할머니도 알게끔 현수막이라도 걸어야 해요"
그래서 주인집 사모님께라도 메시지를 남겨보자라는 마음에 문 앞에 작은 편지를 붙여두고 나왔다.
- (~~보시고 내년 월세 올리지 말아주셨으면 좋겠다~~)

인천 공항까지는 회사분들과 공항 리무진 택시를 같이 타고 갔는데 13만원 정도로 꽤나 합리적인 가격으로 갈 수 있었다.
인천 공항에서 출발 전 회사 분들과 사진을 한방 찍었다. 우리 회사의 마스코트는 코끼리 인데 그렇다 코끼리 이다.

필자는 사정상 혼자서 비행기를 타고 라스베가스로 향했다. 약 13시간 정도의 여정 있었는데 수화물 연결이 안되서 혹여 늦을까 걱정이 되었다.

기내식으로 쌈밥 꽤나 괜찮았음 !

9시간이 조금 지칠뻔할 때 쯤 시애틀로 도착을 했다. 비행기 너머로 보이는 풍경은 너무 이뻤다. 날시가 너무 좋았다.

시애틀 도착, 험난한 입국 수속 ..

짐을 찾고 서둘러 입국 수속을 받으러 갔는데 환승을 하지 못할 것 같은 불안감이 스멀스멀 올라왔다.
외국인은 별도 라인으로 세우는 데 심사관은 하나였고 가뜩이나 여행으로 왔다는 한국인들은 호텔에 까지 전화를 해보고 있는 것으로 보였다.
'제가 환승을 해야 하는데 .. ' 파파고로 번역을 돌리고 있는 찰나에 다행히 별도 line 으로 분배를 해준 덕분에 제 시간내에 큰 문제 없이 수속을 마쳤다.
- (I'm here to attend conference by AWS 어쩌구 저쩌구 .. 노력한 보람이 있었다)
- 그가 마지막에 건넨 인사가 심금을 울렸다. 'welcome my firend 진썽' 이것이 시애틀의 정인가 ?

걱정했던 수화물 수속도 시애틀 공항은 너무 잘 되어 있었다. 찾은 수화물 환승 과정 중간에 수화물 Transfer 지점이 있어서 그냥 짐만 던져 주면 되었다.
그렇게 Vegas 로 향했다. 비행기 양 옆자리에는 미국인, 일본인이 각각 앉았는데 그들도 전부 AWS re:invent 스케줄 정리를 하는 모습을 보았다. 말을 걸어볼까 하는 심각한 내적갈등을 겪었지만 끝내 말을 걸지는 못했다. 천추의 한으로 남았다...

WELCOME TO LAS VEGAS

그렇게 베가스에 도착해서 호텔로 향하려는데 먼저 도착하신 회사 분들께서 픽업을 오겠다고 하셨다.
근데 차를 못찾으셔서 .. 우버를 혼자서 타고 가게 되었다.

혼자 우버를 타게 되면서 오히려 좋았던 것 같다. 기사님이랑 이런 저런 얘기를 하게 되었다.
나이가 꽤 있으신 것처럼 보이셨는데 베가스 언제 부터 사셨냐, 살기 좋냐 등등 여쭤 봤는데 너무 친절하게 다 답해주셨다.
- (물론 진한 사투리 때문에 반은 못알아 들은 것 같다 .. )
이상 내 나이 때 베가스에 오신 64세 빅터 형님이셨다. 우리 빅터 형님 절대지켜 . . 만수무강 하시길
덕분에 호텔 주변 맛집도 겟겟하고 호텔에 내렸다. 근데 나중에 든 생각이지만 그때 셀카 한장 같이 찍을 걸 하는 후회가 들었다.
- 또 하나의 천추의 한 ..

우리는 Conrad 호텔에 묵었는데 생각보다 시설이 너무 좋았다. 호텔내에 수영장도 있었고 (그래서 먼저온 동료 분들이 수영복까지 사놓으셨다 ..)
당연하지만 1층에는 큰 규모의 카지노가 있었다.

일단 그날 저녁일정으로 AWS 에서 초대한 'AWS 한국 고객의 밤' 행사로 향했다.
rock 카페를 통째로 빌려서 밴드도 초청한 행사 였는데 사람들도 너무 많고 산만하기도 해서 맥주 몇잔 먹고 다시 숙소로 향했다.

일찍 자기는 아쉬워 다 같이 카지노로 향했다. 해본적은 없었지만 속성으로 블랙잭을 학습한 뒤에 참전하여 장렬하게 200 달러를 잃었다.

요건 중간에 스플릿으로 블랙잭을 먹은게 너무 기뻐서 사진 찍은 것 .. 찍고 나서 게임 중에는 사진을 찍으면 안된다는 사실을 알게 되었다.
I was ugly korean ..

그렇게 숙소로 돌아와 잠을 청했다. 하지만 다음날 오전 일찍 월드컵 관람이 예정되어 있어서 얼마 잘 수는 없었다.

- 2편에서 계속 .. -