ローリングアップデートで死ぬ

今回はサーバー（インスタンス）が２台あり、それぞれをローリングアップデートでデプロイしているケースです。
１台目のデプロイ時にphp artisan cache:clearでキャッシュを消していました。
このとき、２台目のまだリリースが完了していないアプリケーションにリクエストが流れ、そのキャッシュが作られたことにより、１台目のアプリケーションでキャッシュから取得したデータがロジック変更によりエラーになってしまいました。

ではどうしたらよかったか。

違うキャッシュキーを参照するようにする

１台目と２台目でキャッシュキーが異なれば１台目ではキャッシュが取得できないので新たに取得処理・キャッシュ生成が行われます。また、そもそもキャッシュをクリアする必要すら不要になります。
デプロイする都度、その世代のキャッシュキーを生成することで問題は解消されます。

Laravelのconfig/cache.phpにはprefixという項目があり、CACHE_PREFIXという環境変数で変更できます。

cache.php

'prefix' => env(
    'CACHE_PREFIX',
    str_slug(env('APP_NAME', 'laravel'), '_') . '_cache'
),

※CACHE_PREFIXはキャッシュをfileやarray指定時には利用されません。

デプロイの都度一意のキャッシュキーを生成

今回はCircleCIでの例です。

echo -n "CACHE_PREFIX=" > .env | echo $CIRCLE_SHA1 | cut -c -10 >> .env

CircleCIでは$CIRCLE_SHA1で最終コミットのハッシュが取得できます。これを利用し、この先頭から10桁を.envに書き出しました。
これでデプロイする都度キャッシュキーはリフレッシュされます。

同じことでお困りの方がいたら参考にどうぞ。

追記

DBのキャッシュとセッションキャッシュが両方消えて困った！という方は次の方法をご検討ください。

まずはmemcachedの設定をDB向けとセッション向けで分離します。

config/cache.php

'db_memcached' => [
  // 内容はmemcached項目を参照
],
'session_memcached' => [
  // 内容はmemcached項目を参照
],

そして.envのDBのキャッシュドライバとセッションストアの指定を変更

.env

CACHE_DRIVER=db_memcached
SESSION_STORE=session_memcached

これでDBのキャッシュとセッションのキャッシュを分離できました。
続いてdb_memcachedのみprefixを与えます。

config/cache.php

'db_memcached' => [
  // 内容はmemcached項目を参照
  'options' => [
    Memcached::OPT_PREFIX_KEY => env('DB_CACHE_PREFIX', '')
  ]
],

あとは先程のデプロイ手順同様にDB_CACHE_PREFIXを生成してあげることでデプロイ毎にDBキャッシュだけ更新されます。
めでたしめでたし。