따봉 구걸남's 블로그

Postgresql 에서 많이 사용하는 파라미터와 설명을 정리해 보았다. 

postgresql 은 오라클과 마찬가지로 시퀀스를 사용할수 있다.

세부적으로는 owned by, serial, generated 등 생소한 구문들이 조금 있다.

1. 문법

CREATE [ { TEMPORARY | TEMP } | UNLOGGED ] SEQUENCE [ IF NOT EXISTS ] name
    [ AS data_type ]
    [ INCREMENT [ BY ] increment ]
    [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
    [ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ]
    [ OWNED BY { table_name.column_name | NONE } ]

2. owned by

OWNED BY는 시퀀스를 특정 테이블의 특정 컬럼과 명시적으로 연결 

이렇게 연결된 테이블을 삭제할 때 해당 시퀀스도 자동으로 삭제됨.

3. serial

SERIAL은 PostgreSQL에서 자동 증가 컬럼을 쉽게 만들기 위한 편의 타입
SERIAL을 지정하면, 내부적으로 시퀀스를 생성하고,
 해당 컬럼의 기본값을 nextval('시퀀스명')으로 지정하며, 시퀀스와 컬럼을 OWNED BY로 연결한다.

CREATE TABLE users (
  user_id SERIAL PRIMARY KEY,
  name VARCHAR(20)
);

이렇게 생성하면 아래의 작업이 내부적으로 이루어진다. 

- 시퀀스 생성
- 컬럼 기본값 지정
- OWNED BY 설정


3. generated

GENERATED ... AS IDENTITY는 ANSI SQL 표준에 맞춘 자동 증가 컬럼 정의 방식 이다.

PostgreSQL 10 이상에서 지원하며, 마이그레이션이나 표준 호환성이 중요할 때 사용한다. 

 

1) ALWAYS: 값을 직접 입력하면 오류 발생 (무조건 자동 증가)

2) BY DEFAULT: 값을 직접 입력할 수도 있고, 입력하지 않으면 자동 증가


CREATE TABLE users (
  user_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name VARCHAR(20)
);

Postgresql Memory 는 어떻게 구성되어 있는지 알아보자 

아래는 Postgresql 의 메모리 구조이다.

크게 보면 오라클의 SGA 처럼 인스턴스 전체에서 공유해서 사용하는 Share memory 와 각 backend 프로세스가 
독립적으로 사용하는 local memory , 그리고 OS cache 가 있다.
 
1. shared memory

shared buffers : 디스크에서 읽은 데이터블록을 캐싱하는데 사용되는 메모리
 {DBInstanceClassMemory / 32768}
wal buffers : 디스크에 쓰기전에 WAL 레코드를 보관하는데 사용되는 메모리 
clog buffers : 트랜잭션의 커밋/롤백 상태를 추적하는 내부 시스템 캐시 , 설정불가 

* 오라클과 다르게 postgresql에서는 트랜잭션과 별도로 커밋상태를 관리하는 버퍼가 존재한다.

 
2. Local memory (per backend)

work_mem : 임시 디스크파일을 사용하기 전에 정렬 및 해시 작업에 사용. 
temp buffers : 세션별 임시 테이블 데이터를 위한 버퍼 
maintenance_work_mem  : vacuum, create index 등 유지관리 작업에서 사용하는 최대 메모리 
  *   세션단위 설정 : show maintenance_work_mem;
                              set maintenance_work_mem  ='1024MB';
    
3. OS free memory 
effective_cache_size : 쿼리 플래너에게 운영체제와 postgresql 이 사용할수있는 디스크 캐시의 총량 추정치
   {DBInstanceClassMemory / 16384}

postgresql 에서는 기본기능외의 것을 사용하려면 extension (확장기능) 이라는 것을 추가로 설치해야한다. 

기본 인스턴스 상태에서 아래처럼 pg_freespace 를 사용하려고 하면 에러가 난다. 

아래와 같이 현재 설치된 extension 가 설치가능한 extension 을 확인한 후 필요한 extension 을 설치해준다.

select * from pg_extension; -- 현재 설치된 extension 확인
select * from pg_available_extensions;  -- 설치 가능한 extension 확인

create extension pg_freespacemap;

select * from pg_freespace('t1');

-- drop extension pg_freespacemap; 설치한 extension 삭제 

** upgrade

엔진 버전이 upgrade 되었을때 extension 까지 자동 upgrade 되지 않는다. 

수동으로 아래와 같이 upgrade 해줘야 한다. 

ALTER EXTENSION extension_name UPDATE TO 'new_version';

** 많이 사용하는 extension

 
1. PG 의 MVCC (multi version concurrent control) 구현

오라클은 읽기 일관성을 위한 MVCC 을 undo 세그먼트에 cr 블록을 생성한다. 

postgresql 은 구조상 undo 세그먼트라는 것을 가지고 있지 않아 데이터파일 내에 변경전 값을 저장하게 된다

이것을 dead tuple 이라고 부른다. 시간이 지나 어느곳에도 참조하지 않는 데드튜플은 vacuum 이 정리한다.

* IO 단위인 page 에 변경전 튜플과 현재튜플이 같이 저장되어 효율적이지 않은 단점

 
2. PG 의 트랜잭션ID (XID) 특성

데이터의 선후관계 확인을 위해 오라클은 SCN 이라는 것을 사용하는데, postgresql 에서는 Transaction ID 를 사용한다. 

xid 는 unsigned 32 bit 정수로 40억 개 (2^32) 까지 사용 가능하다. 이것을 다쓰면 한바퀴 돌아 순환하는 구조이다. 

튜플은 생성시점의 xid (xmin), 삭제시점의 xid (xmax) 를 가지게 된다. 아래와 같은 구조를 가지게 된다. 

간단하게 그림으로 표현해본다면..

최초 xid 101 시점에 튜플이 생성되고, 이후 튜플이 업데이트 되면 원본의 xmax 가 103 으로 바뀌고

새롭게 생성된 튜플의 xmin 도 103 이 되고, 업데이트 된 값 'BBB' 가 저장된다. 

xid 102 시점에 조회를 하던 세션은 xmin 값이 자신보다 작은 101 을 가진 튜플의 값을 조회 ('AAA') 한다.

3. XID wraparound 

transaction ID 는 무한하지 않기 때문에 40억을 넘어가면 다시 돌게 되어있다. 

한번 순환한 xid 는 과거 시점 xid 가 자신의 xid 보다 클 수 밖에 없어, 그대로 사용하게 되면 이전 시점 데이터를 볼수가 없게 된다. 

그래서 xid 값을 frozen 처리를 하게 되고 이것은  "이 튜플은 아주 오래된 것이므로, 모든 트랜잭션에서 볼 수 있다" 라고 판단하게 된다.

 
4. VACUUM 실행 전 확인

데이터 변경이 많은 테이블은 dead tuple 이 많이 발생하게 되어 많은 공간과 IO 의 비효율이 발생 할 수 있다. 

이를 정리해주는 vacuum 작업을 주기적으로 돌려야 한다. (물론 xid 의 frozen 작업도 vacuum 이 처리한다.)

실제 live tuple 에 비해 변경 작업이 많아 dead tuple 이 많이 생성된 경우, 테이블의 전체 크기가 커지게 되는데

이를 bloating 되었다고 표현하며, 주기적으로 관찰할 필요가 있다. 

* Dead Tuple, Live Tuple 확인

-- 1. 통계수집기 활용 방식 : 빠름, 근사치 제공. (vacuum 이후 수치) 
SELECT c.relname AS table_name,
       pg_stat_get_live_tuples(c.oid) AS live_tuple,
       pg_stat_get_dead_tuples(c.oid) AS dead_tuple
FROM pg_class AS c
JOIN pg_catalog.pg_namespace AS n ON n.oid = c.relnamespace
WHERE pg_stat_get_live_tuples(c.oid) > 0
  AND c.relname NOT LIKE 'pg_%'
ORDER BY dead_tuple DESC;

-- 1. 통계수집기 활용 방식
  select relname, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup 
 from pg_stat_all_tables 
 where relname = 't1' ;

-- 2. pgstattuple 함수를 통한 통계 : 실시간, 정확

 select relname, table_len, tuple_percent, dead_tuple_percent,free_percent
 from( select relname,(pgstattuple(oid)).*
       from pg_class 
       where relkind = 'r' ) a 
 where table_len >= 1048576  -- 100kb
 order by dead_tuple_percent desc limit 10;

 select avail,count(*)
 from pg_freespace('t1') 
 group by avail ;
 

5. VACUUM  문법 및 실행

VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]

옵션항목은 아래와 같은 것들이 들어간다.

    FULL [ boolean ]
    FREEZE [ boolean ]
    VERBOSE [ boolean ]
    ANALYZE [ boolean ]
    DISABLE_PAGE_SKIPPING [ boolean ]
    SKIP_LOCKED [ boolean ]
    INDEX_CLEANUP { AUTO | ON | OFF }
    PROCESS_MAIN [ boolean ]
    PROCESS_TOAST [ boolean ]
    TRUNCATE [ boolean ]
    PARALLEL integer
    SKIP_DATABASE_STATS [ boolean ]
    ONLY_DATABASE_STATS [ boolean ]
    BUFFER_USAGE_LIMIT size

and table_and_columns is:

    table_name [ ( column_name [, ...] ) ]
 

-- ## VACUUM 실행 예시

VACUUM;                -- 전체 테이블에 대해 간단히 실행
VACUUM FULL;           -- 전체 테이블 공간 회수 = 재구축 (배타적 잠금 주의)
 * pg_repack : 온라인 재구축. 짧은 시간 락
 select pg_relation_filepath('t1') --> 재구축 확인

VACUUM ANALYZE;        -- VACUUM 후 통계 정보 갱신 => vacuum + analyze
 * 통계만 = > analyze (verbose) t1;

vacuum [테이블명];         -- 특정 테이블에 대해 실행
vacuum (verbose) t1;
vacuum (analyze) t1;   -- vacuum + analyze
vacuum (freeze, verbose) t1;  -- 강제 freeze
vacuum (skip_locked) t1;     -- lock 대기하지 않고 skip
vacuum (verbose, parallel 4) t1;  -- 인덱스 vacuum 오래걸릴때
vacuum (verbose, index_cleanup off) t1;  -- 인덱스 vacuum 은 off,  default 는 auto

-- # wal 발생량 확인
select pg_current_wal_lsn(); -- before
vacuum t1;
select pg_current_wal_lsn(); -- after
select pg_size_pretty(pg_wal_lsn_diff('before','after')));

AWS multi-AZ ( Multi-Availability Zone ) 란
한 리전 내 여러 가용영역 (AZ) 에 데이터를 분산 배포하는 방식을 말한다.

각 AZ 는 물리적으로 분리된 데이터센터로, 전원, 네트워크, 냉각 등이 독립적으로 구성된다.
고가용성, 재해복구 목적으로 구성을 하게된다.
단일 리전이 단일 데이터센터 (AZ) 로 구성되었다면 multi-AZ 구성은 불가하다.  

다음은 multi-AZ 를 구성하는 방식에 대해서 알아보자

# multi-AZ 방식

RDS 를 생성할때 배포 옵션이 위의 세가지가 있다. 왼쪽 두가지가 multi-AZ 이다. 

1) 전통적 multi-AZ
- primary, standby 각 1대로 구성
- standby 는 대기만 하고 조회 불가
- 복제 동기로 인한 쓰기지연 가능성
- 오라클도 사용 가능 

2) 클러스터 multi-AZ
- writer 1대,  reader 2대로 구성
- reader 서버 조회 용도 사용 가능. writer, reader 각각 엔드포인트로 관리
- 반동기 복제로 쓰기지연 적어
- mysql, postgresql 만 지원

# 클러스터형 multi-AZ 와 오로라 차이 및 유사성

클러스터형 multi-AZ 와 AWS aurora 는 유사한점이 많은데, 한번 비교해보자

아래는 aws aurora 구성도 이다. 

aurora 는 1개의 writer instance 가 여러개의 스토리지에 데이터를 쓰는 구조이다. 

1) 유사성
 -  writer, reader 로 구성되어 각각 엔드포인트로 관리
 - reader 사용가능
 - mysql, postgresql 만 지원
 - 보통 오로라는 같은 AZ에 구성(성능이유) 하지만 다중 AZ 구성도 가능

2) 차이
 - 복제 방식 
  multi-AZ : 인스턴스 레벨 복제
  aurora : 스토리지 계층 복제

 - 복제 지연
   multi-AZ : 쓰기 복제 지연
   aurora : 최적화된 네트웍크, 프로토콜로  지연 최소화

 - 관리 측면
   multi-AZ : 확장 한계, 인스턴스 단위 관리
   aurora : 확장, 복구 빠름. 스토리지, 컴퓨팅 분리

# 요약 및 정리 

multi-AZ 는 HA 나 재해복구 목적으로 구성하며, 전통적 방식과 클러스터형 방식이 있다. 
reader 를 사용가능한지, 복수개의 reader 를 가질수 있는지가 큰 차이이다.
aurora rds 를 다른 AZ 에 구성하는 것으로 동일목적을 달성할수 있다. 
aurora 는 확장성도 있고, 지연이 적은 것이 장점이다. 

앞선 포스팅에서 소프트 파싱과 하드파싱을 정리한 글에서 

바인드 피킹 기능 한계 및 보완으로 ACS 가 새로 도입이 되었다고 했는데 더 자세히 알아보자

1. ACS 등장 배경 

 1) 리터럴 SQL 사용
  - 동일 구조 쿼리에서 입력값이 동일하지 않은 경우 하드파싱 부하 
 
 2) bind 변수 사용 SQL 
 - 바인드변수 사용으로 동일 SQL ID 를 사용, 하드파싱 감소
 - 데이터 분포를 고려하지 않은 실행계획이 생성, 실행됨

 3) bind peeking 기능 도입
 - 최초 실행시 데이터입력 값의 분포를 고려한 실행계획이 생성됨
 - 분포도가 다른 입력값이 들어오면 비효율 발생

 4) adaptive cursor share
 - 데이터 분포에 따라 다른 실행계획 생성
 - 오버헤드는 발생 

2. ACS 사용하기

 ACS 를 사용하려면 컬럼의 히스토그램이 생성되어 있어야 한다. 

통계정보 수집 할때 method_opt 옵션에서 지정할수 있고 문법과 예시는 아래와 같다. 

 - METHOD_OPT 옵션 문법

FOR COLUMNS [column_clause] [size_clause]
size_clause := SIZE {integer | REPEAT | AUTO | SKEWONLY}
column_clause := column_name | extension name | extension

 - 예시

EXEC DBMS_STATS.GATHER_TABLE_STATS('SYSTEM','TB_DPS_TRSC_BASE', ESTIMATE_PERCENT=>100, METHOD_OPT=>'FOR COLUMNS ACCT_NO SIZE 2 ');

* SIZE 뒤의 숫자만큼 버킷을 지정되어 수집되고 1부터 2048 까지 지정 할수 있다.

0 은 지정할수 없고, 1 은 히스토그램을 수집하지 않겠다는 것을 의미.

NDV 를 고려해서 버킷사이즈를 적절하게 선택 

- 관련 파라미터 확인 

alter [ system | session ] set "_optimizer_adaptive_cursor_sharing" = true;  -- default 

 - V$SQL 의 관련 컬럼

IS_BIND_SENSITIVE 
 => Y : 옵티마이저가 히스토그램을 분석, 바인드 값 변경 시 실행계획이 달라질 수 있음을 감지 
 => N : 통계가 없거나, 균일한 분포(임계를 넘지 않은) 

IS_BIND_AWARE
 => Y : (SENSITIVE already marked 상태) extended cursor sharing 사용 
 => N : 1) SENSITIVE 가 N 이거나
            2) SENSITIVE 가 Y 이지만 아직 extended cursor sharing 사용되지 않은 상태 
   

- 실행계획 분화 프로세스

  1. 통계, 히스토그램 수집

  2. 옵티마이저가 바인드변수에 따라 실행계획이 변경될수 있다고 판단되면 => IS_BIND_SENSITIVE = Y 

  3. 유저 입력값의 변경에 따라 이전에 비해 많은 일량 처리 됨 => IS_BIND_AWARE = Y

 4. 3번의 바인드 값 다시 들어오면 기존 커서 중지, 새로운 커서 생성

3. ACS 한계

 히스토그램을 반영하는 실행계획을 생성해주는 장점이 있지만 추가적인 오버헤드 발생하는 단점이 있다. 

 아래와 같은 추가적인 비용이 발생하게 된다.  

 - 실행계획 평가 비용 증가
 각 실행 시점마다 옵티마이저가 바인드 값과 기존 실행계획의 효율성을 지속적으로 평가
 
 - 커서 관리 부하
새로운 Child Cursor 생성 시 추가적 관리 부하 발생 

 - 메모리 할당(library cache) 및 통계 정보 수집(v$sql_cs_histogram) 발생
최대 20개까지의 Child Cursor 유지로 인한 메모리 증가

 - 파싱 오버헤드
Bind-Aware 상태 전환 시 추가적인 Soft Parsing 발생 -> 라이브러리 캐시 래치 경합 가능성 증가

즉, IS_BIND_AWARE = Y 이면 이후 해당 SQL 은

매번 바인드 값을 확인하고, 
Child Cursor 선택/생성 로직을 거치며,
통계 정보와 히스토그램을 참조하는 추가적인 내부 연산이 발생한다. 

Child Cursor가 많아질수록 커서 관리 비용, 라이브러리 캐시 경합, CPU 소모가 증가하게 된다. 

그러므로, 과도한 child cursor 로 인한 부작용 발생시, 아래와 같이 적절히 대응해야 할수도 있다. 

- ACS 기능을 비활성화하거나(_optimizer_adaptive_cursor_sharing=false)
- 바인드 변수 대신 리터럴 사용
- 히스토그램 수집 범위 조정 (skew 없으면 히스토그램을 수집X)
- SQL 구조 변경(조건 분기, 힌트 사용 등)

즉, 남용하지 말고 DBA 가 적절히 개입할 필요가 있다. 

 - OCI 에 대해서 알아보자

OCI 는 Oracle Cloud Infrastructure 의 약자로 AWS 처럼 oracle 에서 제공하는 클라우드 서비스 이다. 

AWS 도 1년 동안 무료로 사용할수 있는 free tier 계정이 있다. 

다만 서비스의 제약은 있고, 무료의 범위를 넘어서면 얄짤없이 과금이 되기도 한다. 

AWS 프리티어로 mysql 이나 postgresql 같은 오픈소스를 사용하는 것은 가능하지만 oracle RDS 의 경우 

라이센스의 문제로 프리티어에서 이용하기에는 어려움이 있다. 

반면, OCI 도 무료계정을 운영하는데, 여기서는 ATP 라는 이름으로 oracle instance 를 사용 가능하다. 

https://www.oracle.com/kr/cloud/

아래처럼 30 일 체험판으로 300 달러 크레딧이 제공이된다.

30일 체험판이 끝나도 always free 서비스 항목들은 그대로 무료로 제공이 된다고 한다. 

역시 오라클 테스트는 oci 가 개꿀이다.

무료계정을 생성해보자. 

개인용 테스트 목적이라 individual 을 선택했다. 

홈영역은 무료계정에서는 제약이 있는것 같다. 나는 춘천을 선택했다.

계정을 생성하고 다시 로긴하면 MFA 를 설정하는 듯하다. 

오라클 mobile authenticator 를 사용해도 좋지만 나는 구글 authenticator 를 사용했다.

OTP 를 입력하고 다시 로긴하자. 

이제 database 를 생성하자. autonomous databases 에서 "Create Autonomous Databases" 버튼을 누른다

display name 과 database name 을 적당히 적어준다. 

DW 용이 아니고 oltp 성 인스턴스가 필요하므로 "Transaction Processing" 을 선택한다.

Always free 를 선택했다. 버전은 19c 로 했다. 

admin 패스워드 입력하자. 최소 12자 이상, 최소 1자리 대문자/소문자/숫자 포함해야한다. 빡세다.

N/W access 는 지정 IP 로 했다. 

하단에 나의 현재 아이피가 나와있다. 

귀찮으면 그냥 secure access from everywhere 로 해도 된다. 

컨택정보도 입력해준다. (왜 필요한지 모르겠지만)

다 입력했으면 우측 하단의 "Create" 버튼을 누르면 생성이 된다. 

디비생성은 금방되고, 완료가 되면 'Available' 표시가 뜬다. 

이제 접속테스트 유저를 생성해보자. 

우측 상단의 "Database actions" 에서 "Database user" 선택 

사용자 생성을 눌러서 국민 유저 'SCOTT' 을 만들어보자.

scott 하면 tiger 지만, 역시나 빡센 비밀번호 검증 때문에 길게 만들어 주고 생성한다. 

scott 이 만들어졌다. 아래의 주소를 새탭에서 열어보자.

에디터가 나오고 쿼리를 실행해보자. 

상당히 직관적이고 많은 부분 편해진것 같다. 

앞으로 이것저것 눌러가며 많이 공부해보자.

이상 끝!

한국인들은 잘 모를수 있지만 다낭은 외국의 디지털 노마드에게 요즘 떠오르는 장소이다. 

물론 그렇게 된 가장 큰 이유는 저렴한 생활비 (숙소, 식비) 때문이다. 

거기다 따뜻한 기후와 휴양지의 분위기와 어느정도 서구화된 인프라들 (리조트 등) 은 덤이다. 

베트남 여느 도시와 마찬가지로 다낭에도 카페는 많다. 하지만 일반 카페에서 장시간 일을 하기엔 조금 부족한 점이 있다. 

내가 지도에서 파악한 집중있게 업무가 가능한 카페가 두 곳이 있었는데 가 그 중 하나이다. 

( 나머지 한 곳은 이 곳 보다는 조금 열악하다. )
HI4 coffee 는 스터디 카페 같으면서도 만화카페 같은 룸이 있다. 그 룸은 예약을 해야 하는 것 같다. 

이곳의 가장 큰 장점은 음료 한잔만 시켜도 시간 제한없이, 언제든지 머물수 있다.

그 음료가 비싼것도 아니다. 그리고 무려 24시 영업을 한다. 진짜 사장이 망하려고 환장을 한것 같다. 

( 45k 면 한국돈 3000원이 안되는 돈으로 블랙커피와 티라미수 컵케익을 준다. ) 

다낭이 좀 더 발전을 하려면 다양한 종류의 장소들이 많이 생겨야 하는데 아직은 조금 부족한 것이 느껴질때가 있는데 이런 24시 스터디 카페 같은 곳이 존재한다는게 참 좋다. 

현지인들이 대부분이지만 노트북을 펼치고 코딩을 열심히 하고 있는 서양인도 종종 보인다. 

같은 IT 인으로 그들과 테크니컬 스몰톡을 한번 해볼걸.. 하는 아쉬움이 있다..

살짝 중심가에선 벗어났다는 것이 이곳의 가장 큰 단점...

물론 임대료가 저렴해야 이 정도 혜자급 서비스를 제공할수 있겠지..

이번에도 음식사진으로 다낭 여행 복기 해보기

1. 포 (pho) + 짜쪼

: 첫 날이라 아직 로컬식당에 대한 두려움이 있어서 돌아다니기만 하고 선뜻 들어가 앉지를 못했다. 

 그랩으로 배달시키면 두려움이 덜 하니 개시를 그랩으로 했다.

뭐 먹을까 고민하다가 쌀국수에 짜쪼를 시켰는데 그닥 좋은 선택은 아니었던것 같다. 

왜냐하면.. 맛의 문제는 아니고, 번거로움의 문제다.

 - 뜨거운 국물이 있는 봉지를 뜯어서 그릇에 담다가 손 데임.

 - 느억맘 소스 담을 그릇은 안줘서 그냥 봉다리 째로 먹음.

쌀국수는 배달 시키기 적절하지 않은듯함.  음식 자체는 '이 가격에 고기가 이만큼이나...' 하는 혜자스러움에 감격  
 
짜쪼는 조금 아쉬움. 탄수화물 위주의 음식은 튀길때 적당히 튀겨야 발암물질 생성 안되는데

(이를 알고 있는 맥도날드 감튀 색깔은 적당히 튀겨서 진하지 않다. )

색깔 진하면 맛있어 보이지만 건강에는 좋지않다는거...  맛도 별로 였음. 느끼하고 잡내도 조금 나고 질김.

쌈 채소가 같이 왔는데, 짜조를 쌈싸먹는 것이 현지 문화인 듯. 쌈이 많아 보이지만 저거 다 먹음

# 그랩으로 시키면 기사가 어디까지 왔는지 확인은 가능한데 실시간으로 보려면 새로고침을 해야함. 그리고 기사가 내 방 앞까지 오나 궁금했는데 그렇진 않고, 로비까지 내려와서 받아가야 하던란.. 

구글맵으로 조사하다가 평이 좋은 (노상 식당 아닌) 문 달린 쌀국수 집 발견.

역시나 고기 양은 혜자롭고 가격도 좋았고 깔끔했다. 맛은 인상적이진 않았다.

내 생각에 현지 쌀국수는 시큼한 맛이 있는데 이게 약간 익숙하지 않은듯.

태국의 똠얌꿍도 그렇고 동남아 국물음식과 우리 국물 음식의 차이가 바로 이 '신맛' 인 것 같다. 


2. 껌땃

: 길거리에 돌아다니다 보면 돼지고기 바베큐 하시는 분들이 많은데 냄새가 아주 그럴싸 하다. ( 자기가 굽다가 집게로 직접 셀프 시식하는 사람 봄)

 껌땃 자체는 부러진 쌀이라는 뜻인데, 밥이랑 같이 해서 돼지나 닭 등을 같이 먹는 스탈인데, 바베큐 냄새가 너무 좋다.

근데 뼛가루 가 좀 있다.  좀 먼데서 시켜서 살짝 식은 감 있다. 역시 그랩 용은 아닌듯 함.
 

국물은 무료로 준건데 뭔 맛인지 모르겠음. 한 모금 마시고 버림.

3. 반미

 : 반미는 어디서 시켜도 빵이 바삭하니 맛있다. 아마 같은 곳에서 납품하지 않을까 싶은데...

 소스와 토핑만 가게마다 다른데 가격도 매우 저렴. 그랩으로 시키기 적당한데, 문제는 가격이 너무 저렴해서 배와 배꼽이 비슷할듯.

억울해서 그랩으론 못 시킴
 

해변 가는 길에 노상에 자리 펴서 먹는 상점이 있는데 현지인들이 여기서 맨날 사진 찍는다. 

잘 이해 안가지만 현지인들 사이에선 포토 스팟인 모양이다. 

망고 연유 찰밥은 맛있었음.

 

4. 반쎄오

 :  한국에서도 부침개를 좋아하기에 기대를 많이 함. 

  부침개 같은 계란전에 고기랑 숙주 들어가 있음. 라이스페이퍼에 싸서 소스에 찍먹함. (이건 가게마다 다른듯)

  맛은 있지만 기대가 컸는지 생각보다 기억에 안남음. 블루베리 쉐이크랑 같이 시켜서 시원하게 같이 먹고 싶었는데

 쉐이크 먼저 나오구 한참 후에 반쎄오가 나와서 쉐이크 다 분리됨. 코스요리도 아니구 센스가 좀 아쉬움.
 

5. 분짜 

: 분짜는 하노이 음식이라 다낭에서 먹을수 있으려나 싶었는데 은행 가는 길에 '오바마 분짜' 가 있다. 

여행중 먹어본 베트남 음식 중 제일 맛있었음. 당연히 실제 오바마가 여기서 먹진 않았을 텐데.. (싸장님. 허위광고 안됨니다..)

고기국수(왼쪽사진) 도 파는데 후기가 괜찮음. 근데 사진은 엉뚱한 사진이다. 

지대 리얼 로컬 인더스트리 감성의 벽

희석된 소스( 국물이라고 보기엔 뭔가 찐함) 에 고기 담겨있고 국수를 담갔다가 먹는 건데, 고기도 많고 (대짜 시켰는데 그들 기준 대짜 이고 성인 기준 충분히 먹을양) 소스도 짜지 않고 적당함.

완전 오픈 로컬 가게라 위생은 살짝 못 본 척 해야 됨. 

총평 : 4박 5일 동안 다양하게 먹어보려 노력 (반미 빼고 안 겹친 음식 x ), 여행 전 궁금했던 현지 음식 리스트는 전부 뿌심

베트남은 커피가 유명해서 많이 마시고 싶었지만 카페인 권장량 이슈로 1일 1커피 원칙이라, 아직 못 먹어본 커피가 많아 아쉬움. 

베트남은 정말 커피에 진심인 나라였음. 현지 노상 카페에서 남자들이 커피마시는거 보면 뭔가 중국 차 문화와 비슷한 감성 있음.  

블랙커피라고 부르는데 따로 슈가를 빼달라고 아래처럼 말하지 않으면 슈가가 디폴트로 들어감. 

caphe den da khong duong (카페 덴 다 꽁 두엉) = black coffee without sugar

나의 최애 맥주 레드호스.

필리핀 맥주인데 알콜이 쫌 있어서 한 캔 마시면 딱 적당히 취기가 올라서 갠적으로 제일 좋아하는 맥주.

그러나 소수의 매니아 층만 있어서 필리핀 밖에서 보기 힘든 맥주. 여기서 만나니 반가움.

# 롯데마트 과자들

롯데마트에 가면 한국인들 정모를 할수 있다. 

코코넛 과자는 마사지가게에서 기본으로 주는 건데 그냥 기본은 함. ( 조금 딱딱함 )

엄마가 잭푸룻칩을 좋아해서 사옴. (알고보니 쿠팡에도 판다)

건망고는 그냥 시내가 더 싸다. 

베트남에서도 와인을 생산한다. 주로 달랏에서 생산하는 것 같다. 

베트남은 커피도 생산하고 와인도 생산하고 농업 강국 인듯.

An 이란 과자 부드러워 괜찮음. 오리온이 만드는거 같은데 왜 한국에선 안팔죠? 

옆에 치즈 웨하스는 시식으로 줘서 먹어봤는데 나쁘지 않아 들고 옴. 

한국인이라면 베트남은 음식으로 실망하지는 않을 듯.