みなさんこんにちは。サーバーエンジニアの長南です。

弊社では Famm をはじめとしたプロダクトを提供するためのインフラとして、 AWS を活用しています。クラウド上のサービスなので運用にかかる手間は少ないわけですが、全く手放しというわけにはいきません。

この記事では、AWS Aurora の特性を利用したメンテナンス術について紹介します。

SSL/TLS 接続のための CA 証明書を更新せよ

Timers で運営しているサービスは常に新しい機能追加や改善が行われていますが、ある日 AWS から、RDS と Aurora で使っている CA 証明書の設定を更新するよう通知を受け取りました。公式ドキュメントやブログでは詳細な内容を説明した記事が掲載されています。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.htmldocs.aws.amazon.com

aws.amazon.com

また、Classmethod さんが運営する Developers.IO でも AWS コンソールでのオペレーション例が示されています。

dev.classmethod.jp

これを放置していると、最終期限( 2020年3月5日 )までの間にCA証明書の更新と再起動が強制的に行われ、その際にデータベースのダウンタイムが発生することになります。もし、Aurora や RDS に対して SSL/TLS 接続を利用していなく、ダウンタイムが発生するのを許容できるのであれば「何もしない」という選択をとることもできますが、実際はユーザーに価値や体験を提供していることが多いかと思います。

そんな、いわゆる「本番系」のデータベースですが、可能であれば無停止、ダウンタイムが発生するにしても短時間かつ影響の少ない時にやっつけたいところです。AWS の案内では「2分以内」、Developers.IO さんの記事では「数秒」という記述がありますが、かならずしも同じようにいくとは限りません。ユーザー(そして価値や体験を提供している私達)への影響を小さくコントロールするためのプランを立てる必要があります。

更新する上での条件・考慮したこと

今回 CA 証明書を更新したある Aurora クラスタはこのようになっていました。Read と Write レプリカをそれぞれ 1 個づつ、アベイラビリティゾーンを分散させた構成です。

インスタンス	役割	AZ(アベイラビリティゾーン)	CA証明書	FO(フェールオーバー)順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2015	-1
インスタンス B	Read	ap-northeast-1c	rds-ca-2015	-1

更新プランの方針として

(前提) Aurora への接続はクラスタエンドポイント( Read, Write ) を利用しており、個々のインスタンスへは接続していない
オペレーション中、 Read, Write レプリカ双方 1 インスタンス存在することを維持する
人為的なフェールオーバーを起こして Write レプリカの交代を行う。フェールオーバー中のダウンタイムは許容する
最終的に元と同じようなインスタンス構成となるようにする
Write レプリカを変更するまえに万一の場合に備えスナップショットをとる

といったところを考慮して更新計画を作成しました。

弊社での更新プラン

一時的なインスタンスをクラスタに追加

「Read, Write レプリカ双方 1 インスタンス維持」という方針を立てたので、一時的に Read レプリカを追加します。最終的に削除する予定なので、フェールオーバー順位は他のインスタンスよりも低く設定します。追加した後に インスタンス B の CA証明書を更新することを考えて、アベイラビリティゾーンは インスタンス A にあわせます。蛇足ですがこの作業を行ったのは 10月だったので CA証明書は古いほうの rds-ca-2015 で作成されました ( 11月になってデフォルトの CA 証明書は rds-ca-2019 に変更されたようです )。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2015	-1
インスタンス B	Read	ap-northeast-1c	rds-ca-2015	-1
インスタンス C	Read	ap-northeast-1a	rds-ca-2015	-10	追加

Aurora クラスタにRead レプリカとしてインスタンス C が追加されたことを確認しておきましょう。

Read レプリカの CA証明書を更新

2インスタンスに増えた Read レプリカの CA 証明書を順次 rds-ca-2019 に更新します。1インスタンスづつ実施することで、クラスタ内の Read レプリカが必ず1つ存在している状況をつくりだすことができます。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2015	-1
インスタンス B	Read	ap-northeast-1c	rds-ca-2015	-1
インスタンス C	Read	ap-northeast-1a	rds-ca-2019	-10	CA証明書を更新

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2015	-1
インスタンス B	Read	ap-northeast-1c	rds-ca-2019	-1	CA証明書を更新
インスタンス C	Read	ap-northeast-1a	rds-ca-2019	-10

フェールオーバーを実施して Write レプリカを入れ替える

次に インスタンス A の CA 証明書を更新しますが、Write レプリカとして稼働しているものに変更を加えるので、不測の事態が生じたときに現時点まで巻き戻すことができるように、スナップショットを取得します。

その上で インスタンス A に対して手動でフェールオーバーを起こして、インスタンス B を Write レプリカに昇格させます。フェールオーバーによる切替が行われている間はデータベースへの書き込みができない状況となります。

フェールオーバーしたときにどのインスタンスが Write レプリカに昇格するのかは、それぞれのインスタンスのフェールオーバー順位やインスタンスサイズ等で決定されます。今回は インスタンス B が昇格する状況にしたかったので、 インスタンス C はあらかじめフェールオーバー順位を低く設定しておきました。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Read	ap-northeast-1a	rds-ca-2015	-1	フェールオーバーを発生させ Read レプリカに降格
インスタンス B	Write	ap-northeast-1c	rds-ca-2019	-1	Write レプリカに昇格
インスタンス C	Read	ap-northeast-1a	rds-ca-2019	-10

残りのインスタンスの CA 証明書も更新

Read レプリカに降格した インスタンス A は他のインスタンスと同じように CA 証明書を更新します。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Read	ap-northeast-1a	rds-ca-2019	-1	CA証明書を更新
インスタンス B	Write	ap-northeast-1c	rds-ca-2019	-1
インスタンス C	Read	ap-northeast-1a	rds-ca-2019	-10

そして、再度フェールオーバーを起こして、 インスタンス A を Write レプリカに昇格させます。繰り返しになりますが、 インスタンス C のフェールオーバー順位を低く設定していたので、インスタンス A がWrite レプリカに昇格することになりました。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2019	-1	Write レプリカに昇格
インスタンス B	Read	ap-northeast-1c	rds-ca-2019	-1	フェールオーバーを発生させ Read レプリカに降格
インスタンス C	Read	ap-northeast-1a	rds-ca-2019	-10

後始末

ここまでの作業でクラスタ内の全てのインスタンスの CA 証明書を更新することができました。作業前と同じようにデータベースが利用できることを確認して、 インスタンス C とスナップショットを削除します。

インスタンス	役割	AZ	CA証明書	FO順位	備考
インスタンス A	Write	ap-northeast-1a	rds-ca-2019	-1
インスタンス B	Read	ap-northeast-1c	rds-ca-2019	-1
~~インスタンス C~~					削除

これで作業前の構成を維持しつつ、CA証明書を更新することができました。

オペレーションを行う際の注意点

このような手順を踏んでダウンタイムを極小に保ちつつ CA証明書を更新したわけですが、重要なのは Aurora クラスタの特性を理解し、 Read, Write レプリカの区別、フェールオーバーの考え方を把握して計画を立てること、そして可能であれば事前に同じような環境でリハーサルを行うことです。

弊社では同じような構成の Aurora クラスタを開発用として使っていて、更新手順を作った後にリハーサルを兼ねてその環境で実際に CA 証明書を更新して感覚をつかむことを行いました。手順はサーバーエンジニア全員に見てもらったのですが、その際に「開発環境で実際にオペレーションしてみたい」というエンジニアも飛び出し、実際に開発環境でオペレーションしてもらって手順のレビューに貢献していただきました。

世間ではとかく「インフラエンジニア」とか「SRE担当」といった肩書をつけて分業化しがちな分野ですが、今回の更新作業では手順レビューのときのコミュニケーションのおかげで、みんなに関心をもってもらうことができました。

プロダクトやビジネスの規模によっては難しいケースもありますが、クラウドの特性も最大限に活用し、アットホームな雰囲気で心理的・身体的負荷もおさえた更新作業を計画してみてはいかがでしょうか。