GAE / Node で Memcached クラスタ ( Memcached Multiple Instances ) を使うポイント

# 概要

[先日 bitnami に出会い簡単に memcached server を立てられたことに感動] (https://qiita.com/MasanobuAkiba/items/bea3a0ac75ab8685a506) したので、今回はその勢いのままクラスタ版の扱い方をまとめてみます

基本 `runtime: nodejs` 向けのまとめですが、クライアントライブラリ部分を読み替えることで どの `runtime` に対しても流用できると思います

# クラスタの構築

- クラスタの構築自体は全て bitnami が行ってくれるため、
[https://console.cloud.google.com/launcher/details/bitnami-launchpad/memcached-cluster?hl=en](https://console.cloud.google.com/launcher/details/bitnami-launchpad/memcached-cluster?hl=en) から流れに沿ってポチポチするだけで簡単にできちゃいます
- 今回は 3 ノード作成します

<img width="675" alt="スクリーンショット 2018-03-05 21.42.26.png" src="https://qiita-image-store.s3.amazonaws.com/0/41793/54c74e7f-8504-139d-a4be-d2d5f1591ddd.png">


# ローカルからアクセス

- 早速ローカルから接続テストをしてみます
- ただ、その前に少々下準備が必要です

## primary server に公開鍵を設定

- グローバルメニュー[GCE]
- VM インスタンス
- primary server ( memcached-cluster-1-node-0 等 ) を選択
- 編集
- SSH キーが0 個あります ( 表示して編集する )
- `ssh-keygen` 等で作成した公開鍵を user 名 bitnami で設定
- 保存

![スクリーンショット 2018-03-05 22.18.31.png](https://qiita-image-store.s3.amazonaws.com/0/41793/f63c5bdf-cf2a-64aa-a0d8-9037c52f9fe5.png)

### 確認

```
ssh -i /path/to/key bitnami@SERVER1_EXTERNAL_IP
```

## SSH ポートフォワーディング

- [ローカルからはポートフォワーディングによる接続が推奨されていた](https://docs.bitnami.com/google/infrastructure/memcached/) のでそれに習う

```
ssh -N 
    -L 11211:SERVER1_INTERNAL_IP:11211 
    -L 11212:SERVER2_INTERNAL_IP:11211 
    -L 11213:SERVER3_INTERNAL_IP:11211 
    -i /path/to/key bitnami@SERVER1_EXTERNAL_IP
```

## memcached-cli で確認

- ローカルでの確認には [memcached-cli](https://www.npmjs.com/package/memcached-cli) を利用します

```text:connect_to_server1
memcached-cli 127.0.0.1:11211
127.0.0.1:11211>
```

```text:connect_to_server2
memcached-cli 127.0.0.1:11212
127.0.0.1:11212>
```

```text:connect_to_server3
memcached-cli 127.0.0.1:11213
127.0.0.1:11213>
```

# GAE / Node App からアクセス

## Memcached クライアント MemJS


- Node アプリケーション上では Memcached クライアントとして[MemJS] (https://github.com/alevy/memjs/blob/de76660c1803d96a14585ddf17bb3b5da5048605/lib/memjs/memjs.js) を利用します
- 複数インスタンスに対する読み書きのロジックが気になったので調べたところ [key を数値化し server 台数で割った余りの index から set / get するサーバーを算出していました](https://github.com/alevy/memjs/blob/de76660c1803d96a14585ddf17bb3b5da5048605/lib/memjs/memjs.js#L72)
    - このロジックにより、ノードが複数あっても同じキーが重複して保存されるということが無いようです

## アプリケーションへの設定

- GAE からは GCE の内部 IP に直接接続できるので SSH トンネルは必要ありません
    - 内部IPは VM インスタンス一覧画面に表示されています

![スクリーンショット 2018-03-05 22.18.31.png](https://qiita-image-store.s3.amazonaws.com/0/41793/f63c5bdf-cf2a-64aa-a0d8-9037c52f9fe5.png)

- `app.yaml` に Memjs が必要としている環境変数を設定
    - パスワードは VM インスタンス詳細のカスタムメタデータ `PROVISIONER_PEER_PASSWORD` に書いてあります

```app.yaml
env_variables:
    # https://github.com/alevy/memjs
    MEMCACHIER_SERVERS: SERVER1_INTERNAL_IP,SERVER2_INTERNAL_IP,SERVER3_INTERNAL_IP
    MEMCACHIER_USERNAME: user
    MEMCACHIER_PASSWORD: ************
```

## アプリケーションから実行・確認

- あとはライブラリの仕様通りに `get` や `set` するだけ

### memcached-cli で確認用のデータをセット

```
>set test huga
```

### テストコードをデプロイ

```typescript:test.ts
import * as Memjs from 'memjs';

// memcache 部分抜粋
const client = Memjs.Client.create();
client.get('test', (err: any, val: Buffer) => {
    console.log(err, val.toString());
});
```

```
gcloud app deploy app.yaml
```

### Logger から確認してみる

![スクリーンショット 2018-03-02 22.15.21.png](https://qiita-image-store.s3.amazonaws.com/0/41793/c51df778-8d89-5750-d328-6f9d09b8adcb.png)

できた！ ヾ(ﾟ∀ﾟ○)ﾉ≡ヽ(○ﾟ∀ﾟ)ﾉﾞ

# 削除

```
gcloud deployment-manager deployments delete DEPLOYMENT_ID ( memcached-cluster-1等 )
```

# おわり

Memcached クラスタ ( Memcached Multiple Instances ) を扱うために必要な情報が断片化していたので、一つの記事としてまとめてみました
誰かのお役に立つことができれば幸いです m(__)m