こんにちは。株式会社ココナラのインフラ・SREチームに所属しているかたぎりです。

今回は私が2022年4月に入社した直後取り組んだAmazon ElastiCache（以降、ElastiCache）のメンテナンスで行ったことをご紹介します。

はじめに

ココナラではElastiCacheとしてRedis/Memcachedが稼働しています。基本的にCluster内でノードの冗長性が取れており、主にRedisが利用されているのですが、一部2017年に作成されたMemcachedが存在しており、作成後はあまりメンテナンスできていませんでした。

きっかけ

入社翌月のある日、1件のアラートがなりました。

AM5:00

間違いなく業務外のタイミングです。なんだ？とはなったものの、よくよく調べると基盤メンテナンスによってRedisノードがFailoverを起こしていることがわかりました。

振り返ると、このときには2つの問題点がありました。

• 社内の誰も事前検知できていなかった
  • 当該メンテナンス通知は事前にElastiCacheのイベントログには出ていたものの、Amazon Personal Health Dashboard（PHD）には出ておらず事前に気づけていませんでした。あとで調べると、このメンテナンス通知はPHDに出ない類であることがわかりました。
• Failoverで通信断が発生するのでユーザー影響を引き起こしてしまう恐れがあった
  • 今回はたまたま影響がなく済んだものの、もしかしたらクリティカルなデータ欠損が起きていたかもしれません。

なのでこの2点を改善するべく取り組んでいきます。

まずは検知

何にしても検知しないことには始まりません。ElastiCacheのイベントログにメンテナンス通知が出ていましたが、ログの保持期間は2週間なので過去に同様イベントが起きていたかどうかは追えません。そのため、同時にナレッジをためていく必要があると判断しました。

検知方法として監視したいElastiCache ClusterにSNSトピックをセットし、メール経由でSlack通知する方式を採用しています。
前述のとおりナレッジをためたいのと、取りこぼしが怖いので全イベントを取得しつつ必要な通知のみフィルタできる構成を取っています。

精査するうえで、必要なのはノード置換（≒Failover）と定め、以下のリプレース関連イベントを検知対象にしました。

引用元: イベント通知と Amazon SNS
https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/ElastiCacheSNS.html

これでひと安心・・・と思ったら

事前検知できる状態となった当月、出番はすぐにやってきました。

監視を入れた当月中に、Redisのノード置換イベント通知を検知（当時のキャプチャ）

進め方の型化（Redis）

さっそく対応にかかります。初回なのでナレッジを残すことを意識しつつ、主に以下のフローで進めていきました。進めるにあたり、通知内容だけでなくAWSサポートへの問い合わせやドキュメントを確認して情報を集めます。

• 通知内容の把握
  • 対象は？
  • 期限は？
• 利用箇所・影響確認
  • 期限が来たら何が起きる？
  • どんな影響がある？　←ココが大事
• 対応方針決め
• （必要に応じて^[1]）事前検証・作業準備・作業

通知内容の把握

まずは現状理解が大事なので、このイベントでどこに何が起こるのか？を明らかにしていきます。調査した結果、対象は特定サービス用のprimaryノードで、最終的な期限としては通知された内容よりも少し先であることがわかりました。ちなみに本イベントはメンテナンスウィンドウ時間で実施されるものなので、メンテナンスウィンドウ時間をずらすことである程度イベント発生タイミングは調整できます。

利用箇所・影響確認

期限を過ぎるとノード置換が発生します。具体的には（primaryノードの場合は）replicaノードの昇格とFailoverが実施されます。イベント発生前の対応としても、手動でノードのFailoverが必要となります。
主な影響としては対象ノードに接続できなくなる時間が発生することです。いまでこそドキュメントには以下のように記載されていますが、当時はその記載が無く、AWSサポート情報としては稼働バージョンである4.0.10の場合は数秒〜長期化（秒数不明）するとのことでした。

Redis クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 4.0.10 以前のエンジンで実行されている場合、DNS の更新に伴って短い書き込みの中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。

引用元: マルチ AZ による ElastiCache for Redis のダウンタイムの最小化
https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/AutoFailover.html

また、対象のノードは、主に定期バッチ処理で利用されていることがわかりました。

対応方針決め・事前検証

数秒ならまだしも長期化となると流石に影響度合いが変わってくるため、事前に検証して確かめることにします。検証環境を作り、ノードに書き込んだ値を毎秒getしながら手動でFailoverを実施すると、約2分の通信断が発生するとわかりました。この時間通信断が起きても問題ないか？を関係部署に確認することにします。
幸いあらかじめバッチ処理を停止することで2分程度通信断が発生しても問題ない、という判断ができ期限までの任意のタイミングで手動Failoverを実施する方針としました。

作業準備・作業

方針は固まったので手順を準備します。初回なので念の為ノードのキー数を確認したり、有事の際の切り戻し方法やバッチ処理を停止している期間のリカバリー方法など、関係部署にも協力を仰ぎつつ準備しています。結果、主に以下のフローで対応しました。

1. バッチ処理を停止させる
2. あらかじめRedisのバックアップを取得する
3. 作業前ノードのキー数を確認する
4. 対象ノードを手動でFailoverさせる
   1. イベントログでFailoverイベントが出力されることを確認
5. 作業後ノードのキー数を確認する
   1. 万が一、キー数が異なっていたらバックアップから復元して切り戻し
6. バッチ処理を停止していた期間のリカバリー処理を行う
7. バッチ処理を再開させる

作業は無事ユーザー影響なく済んでいます。これにより今回の対応フローで進める実績ができました。

進め方の型化（Memcached）

翌月、Memcachedでも同様にノード置換イベント通知が入りました。

{Memcached-Cluster-A} | cache-cluster | June 11, 2022, 00:22:03 (UTC+09:00) | The node with Cache Cluster ID: {Memcached-Cluster-A}, Node ID: 2 is scheduled for replacement during the maintenance window from Start Time: Jun 25 19:00 UTC, End Time: Jun 25 20:00 UTC

基本的には初回と同じ進め方を踏襲します。ただ、Redisと違いMemcachedはデータの永続化を行わないため、ノード置換時に対象ノードのデータが失われます。また、このMemcachedが利用されている箇所が割とクリティカルなリソースに関わるもので、社内でも通信断が起こることによる影響度合いが掴めませんでした。
そのためユーザー影響を与えないことを優先して、サイトメンテナンスに入れる方針としました。前回からアップデートしたフローが以下です。

• 通知内容の把握
  • 対象は？
  • 期限は？
• 利用箇所・影響確認
  • 期限が来たら何が起きる？
  • どんな影響がある？　←ココが大事
• 対応方針決め
• （必要に応じて）サイトメンテナンス調整　←NEW
• （必要に応じて）事前検証・作業準備・作業

ノードのデータ消失対策として作業前後でmemcached-cliを利用したダンプ・リストアを採用しており、サイトメンテナンスを入れることで無事ユーザー影響なく対応は完了しています。
ここでサイトメンテナンスが必要なケースがナレッジに追加されました。ナレッジはドキュメントへまとめて後から参照できるようにしています。

レアな事例

Memcachedのノード置換対応をした翌日、またもやノード置換イベント通知が入りました。

{Memcached-Cluster-A} | cache-cluster | June 24, 2022, 10:36:03 (UTC+09:00) | The node with Cache Cluster ID: {Memcached-Cluster-A}, Node ID: 2 is scheduled for replacement during the maintenance window from Start Time: Jul 02 19:00 UTC, End Time: Jul 02 20:00 UTC

昨日対応したノード^[2]が対象として通知されています。流石に目を疑いAWSサポートにも確認しましたが、通知内容に誤りはないとのことでした。通知された以上再度対応する必要がありますが、流石に短期間に連続でサイトメンテナンスを入れるのは厳しいです。そのため、少し踏み込んで実際にストアされているデータを確認することにします。

実際に見てみるとなんとか整理できるレベルだったため、有識者を交えて確認した結果

• 欠損すると影響のあるデータはあった
• ただ作業前後でデータバックアップ・リストアができれば短時間は許容できる

と判断でき、サイトメンテナンス無しで対応する方針に切り替えられました。
実際にユーザー影響なく作業は完了しています。

ここでサイトメンテナンスを入れなくて済むケースがナレッジに追加されました。

その後とまとめ

以降、この年は何度かノード置換通知が入りましたが、基本的に同じフローに従って進めて完了できています。また、ノードタイプが古いことによるサポート終了通知も入ってきたため、併せて対応しています。通知内容は違えど、主な対応フローをナレッジ化することで効率的に対応できました。以下がその対応サマリです。

また、この対応をきっかけにMemcachedをRedisに移行する、古いノードのバージョンアップを行うなどアーキテクチャ改善にも繋がっています。

最後に

ココナラでは一緒に事業のグロースを推進していただける様々な領域のエンジニアを募集しています。
SRE領域だけでなく、フロントエンド領域・バックエンド領域などでも積極的にエンジニア採用を行っています。

少しでも興味を持たれた方がいましたら、エンジニア採用ページをご覧ください。

https://coconala.co.jp/recruit/engineer/

SREも募集していますので、ぜひご覧ください。

https://open.talentio.com/r/1/c/coconala/pages/49719