カルボナーラ街道

計測と観察

GoでCookieを利用したセッション管理を実装した | 2: セッションIDをサーバー側で永続化

シリーズ

  1. GoでCookieを利用したセッション管理を実装した
  2. 本記事

モチベーション

現在の実装*1 ではアプリケーションサーバー側のセッションIDがプログラム終了後に揮発してしまう。

// https://github.com/tokizuoh/statice/blob/v0.1/front/main.go#L12
var mapSessionID = map[string]string{}

プログラムが終了した後でもセッションIDを揮発させないために永続化する。
セッション管理のDBについては初学者のため良し悪しが分からないのでスタンダードっぽいRedisを使ってみる。

リポジトリ

github.com

Redis

GoからRedisを使う前に素振り。

コード

FROM redis:6.2-alpine
version: '3.8'
services:
  redis:
    build:
      context: ./redis
      dockerfile: Dockerfile
    container_name: {CONTAINER_NAME}
    ports:
      - 6379:6379
    volumes:
      - ./redis/data:/data

操作

# コンテナ生成
> docker-compose up --build -d

# コンテナ内でshの実行
> docker exec -it ${CONTAINER_NAME} sh

/data # redis-cli
127.0.0.1:6379> set hoge-key fuga-value
OK
127.0.0.1:6379> get hoge-key
"fuga-value"
127.0.0.1:6379> del hoge-key
(integer) 1
127.0.0.1:6379> get hoge-key
(nil)

GoからRedisを利用

github.com

上記を利用。README読めば使い方は分かる。

所感

  • エラーハンドリングについて考えることが多くなった
    • ユーザーからのリクエスト時に、RedisにセッションIDが含まれてるか確認する時
      • Redisに目的の値が無い
        • ログインページにリダイレクト?
        • エラーページに遷移?
      • アプリケーションサーバー側からRedisへの接続時にエラー
        • ここでも上の二択を迫られる
  • 真の意味でのRedisの永続化はどうする?
    • 現在はdocker-composeを起動する役のローカル環境にDockerのボリュームをマウントしているため、ローカル環境に依存してしまっている
      • Amazon ElastiCacheなどを使って完全に切り離す?

上記の悩みも追々解決していく。

参考