概要
分散システムにおいて同じリソースにアクセスする際にロック（排他制御）する仕組みを分散ロックといいます。
ロックを用いる背景としては主に２つあり、
| 目的 | 説明 | 具体例 |
|---|---|---|
| 効率 | 同じ作業を不必要に複数回行わないため | キャッシュのOriginへのリクエストを抑制したい（Cache stampede対策） |
| 正確性 | データの不整合が起きないようにするため | トランザクション |
Redisを分散ロックに使う場合は主に前者のケースにおいて推奨されます。
環境
- Redis 6.2.0
NEG(Network Endpoint Group)を使った負荷分散
概要
従来のGKEのロードバランサーはNodeに到達後iptablesで再度負荷分散するという２段階ロードバランシングでした。
これによりレイテンシの増加、分散のばらつきといった問題が生じていました。
ref: Google Cloud Blog - News, Features and Announcements
しかしNEG(Network Endpoint Group)という機能を使うことで直接Pod宛てに負荷分散を行うことができ、上記の問題を低減することが可能となっています。
ref: Google Cloud Blog - News, Features and Announcements
続きを読むセキュアなトークン管理方法
概要
クライアント↔サーバ間の認証・認可情報としてのトークン管理はWebサービスとしては必ずつきまとうものですが、一方できちんと実装しないとセキュアに管理はできません。
今回はそのトークン管理方法の一例を紹介します。
要件
今回の主な要件は以下です。
- AuthサーバとResourceサーバは別で管理する（負荷特性が異なるので）
- 認証するとAuthサーバはrefresh tokenとaccess tokenを返す
- access tokenはJWT形式
- access tokenはクライアントのオンメモリで管理する
- access tokenの期限は短く（１時間以内）
- refresh tokenを使ってaccess tokenを発行できる
- refresh tokenはrevoke可能である
- 認証情報に変更があれば（パスワード変更など）refresh tokenをrevokeできる
- Resourceサーバは起動時などにAuthサーバから公開鍵を取得し、access tokenの署名検証に使用する
ネイティブクライアントの場合
ネイティブクライアントの場合、keychainなどセキュアな管理ストレージがあるためrefresh tokenを保存することができます。
続きを読む
OAuth 2.0 Device Authorization Grant
概要
サービスのマルチデバイス対応をした際に、各デバイスで同じアカウントにログインするのはユーザにとっては非常に手間です。
例えばテレビデバイスに対応した場合にID＆パスワードをリモコンで入力させるのはユーザにとって苦痛でしかありません。
なのでサービス側はユーザが苦労なくスムーズにログインできる方法を提供しなくてはいけませんが、一方でセキュリティについても気にする必要があります。
そんなケースの対応方法としてOAuth 2.0 Device Authorization Grantがあるので紹介します。
ユーザの体験
例としてテレビデバイスでログインします。
huluが体験として分かりやすいので実際にやってみます。
ログインしようとする
