認証基盤「ヌーラボアカウント」の開発を行う

私は新卒で入ったSIerに9年ほど勤めた後に、2006年にヌーラボに入社しました。前職ではリーダー的な立場で、忙しい中にもやりがいを感じていたのですが、そろそろ違った分野の仕事をしたいなと考えていました。そんなときに弊社の社長に出会い、東京事務所の立ちあげのタイミングで入社しました。

入社してからは受託開発や自社サービスBacklogの開発を行い、今はヌーラボアカウントというシングル・サインオンの認証基盤の開発を担当しています。ヌーラボアカウントは2014年の2月にリリースしたもので、CacooやBacklog、Typetalkという複数のサービス間の認証や課金システムを統一するためのサービスです。

サービスの全滅を避けるため、様々な工夫を

弊社のような複数サービスを運営している会社の場合、シングル・サインオンの認証基盤を作ることで、複数のサービスで個別に認証システムを実装する必要が無くなります。ただ、同時にヌーラボアカウント自体がダウンしてしまうとサービスが全滅してしまうというリスクもあります。

それを避けるためにも、ヌーラボアカウントにはいくつもの工夫を施してあります。例えばデータベースが読み取り専用の状態でも、ログイン処理だけは動くようになっています。

通常はログイン時にもいくつかのデータのInsertやUpdateが発生するのですが、それらに失敗してもログイン自体は成功するような設計にしています。

さらに、ユーザーデータをインメモリキャッシュにも保存しているので、データベース自体が落ちていても動くようになっているんですよ。前に一度、AWSのRDSがメンテナンスでリブートがかかったときにも、その設計のおかげで助かりました。

安心感を追求した結果、Amazon Auroraへの移行を開始

より安心感を追求するために目をつけたのが、Amazon Auroraです。Auroraには発表当時から注目はしていていました。Auroraといえば、MySQLの5倍と言われているパフォーマンスが注目されるのですが、それよりも可用性の高さがヌーラボアカウントに活きると考えました。

ここで導入実績を１つ作ることで、他のサービスに横展開するための試金石にもなるので、ヌーラボアカウントから先行してAuroraに移行してみようと考えました。

Auroraへの移行だけに限らず、弊社はエンジニア主導で何でも試せるような環境なんですよ。メリット・デメリットの検討や事前検証を行った上で、見積もりをちゃんと出せばエンジニア主導で新しい技術もどんどん導入しています。

例えば弊社のサービスは基本的にJavaで書かれているのですが、TypetalkはScalaで書かれていたり、他にもAndroidアプリをKotlinで書きなおしているチームもあります。そういう環境なので、Auroraへの移行プロジェクトも問題なく進められました。

移行時は、RDSのバイナリログの仕組みに注意

RDS for MySQLからAuroraへの移行中もログイン処理だけは継続できるように、データベースを読取り可能な状態に保ったまま移行を完了させたいと思いました。

移行計画は、Amazonさんが公開しているRDS for MySQLからAuroraへの手順書を参考に作成しました。内容が充実しているので、ほとんど手順書通りに実行したら問題なく進みましたね。移行の際には、手順の中でここまでなら以前の環境へ差し戻しができて、これ以降はできないというところを事前に明確にすることも重要です。

手順の概要としては、スナップショットからAuroraのインスタンスを作り、これを現行のMySQLのスレーブとしてレプリケーションを構成します。その後にMySQLを読み取り専用モードにし、その間にアプリケーションの接続先を順次Auroraに切り替えます。

無停止で移行を完了するために、MySQLからAuroraへのレプリケーションを構成するのですが、その構成だとAuroraはRDSの管理外のレプリケーションとなってしまいます。

RDSは通常、管理下にあるレプリカへの同期が完了するとバイナリログを削除します。しかし、RDS管理外にAuroraのレプリケーションを構成した場合、同期を待たずにバイナリログが削除されてしまう可能性があります。

その問題の対策として、Auroraとは別に新しいRDSのインスタンスを作成し、これをスレーブとして登録します。そのインスタンスをRDSの管理下に置いた状態でレプリケーションを停止すると、スレーブへのバイナリログ転送が完了しないため、バイナリログは削除されずに保持されます。

そうするとバイナリログがAuroraに転送される前に削除されることは無くなり、無停止での移行が可能となります。

▼ MySQL をマスター、Aurora をスレーブとしたレプリケーションを構成する

フェイルオーバーも考慮したチューニングを行う

Auroraへの移行に合わせて、JDBCドライバの変更も行いました。通常、JDBCドライバにはRDSが発行するクラスタエンドポイントを設定するのですが、今回使用したMariaDB Connector/Jというドライバには、個々のノードのエンドポイントを指定します。これはフェイルオーバーの高速化が目的ですね。

RDSの標準機能でもフェイルオーバーは可能なのですが、これがDNSベースなので、どうしてもデータベースにアクセス出来ない時間ができてしまうんですよ。

MariaDB Connector/Jではノードのエンドポイントを直接参照しているので、フェイルオーバーが発生したときにも即座に接続先を切り替えることができます。実際にテスト環境で試してみたところ、ログ上ではフェイルオーバーが発生している時間でも、アプリを操作しているだけでは全く気が付かなかったです。

こういう構成にしているとメンテナンスに強くなるので、RDSのインスタンスタイプを変更したり、パラメータを変更するということが気軽に行えるようになるはずです。

より安心して使えるサービスを目指していく

移行作業自体は、調査を開始してから1ヶ月くらいで終わりました。アプリケーションの変更もメンテナンス画面を追加した程度で、完全にMySQLと互換性があることが確認できています。移行作業は失敗したらと考えるとちょっと怖いですが、公式の手順書はしっかりしているし、裏付けを取りながら進めていけば問題ないと思います。

Auroraは小さいインスタンスサイズがなく、MySQLと比較すると少しだけ値段が高いのですが、安心感が買えるなら良いですね。Auroraの導入で可用性を向上できました。これからはヌーラボアカウントのセキュリティの強化を予定しています。今後もより安心して使えるサービスにするために頑張っていきたいですね。（了）