データベース基盤Aurora移行の事例

今回、データベースをRDS(MySQL)からAuroraに切り換えた理由を教えてください。

Auroraへの切り替えの理由は、大きくは「RDS(MySQL)では、テレビ番組でランサーズが紹介されたとき発生する『巨大なアクセス』に対処できなくなったから」ということです。

近年クラウドソーシングという働き方が社会に認知されてきたこともあり、弊社サイトへのアクセスもここ数年で急伸しています。インフラ担当部門の実感としては、「毎年、着実に増加」というよりは「毎年が倍々」、つまり2 ⇒ 4 ⇒ 16 ⇒ 32 のように指数関数的に増えていくような感覚です。

そしてテレビ番組でランサーズが紹介されると、急伸している平常アクセスの「さらに十数倍のメガアクセス」が発生するのです。

それは、どんな性質のアクセスなのでしょうか。

非常に真剣度の高いアクセス、つまり「クラウドソーシングで仕事をしてみたい（あるいは仕事を依頼してみたい）」という意欲に基づいたアクセスであると予測されます。

従来、クラウドソーシングは主に「ワールドビジネスサテライト（テレビ東京）」のような深夜のビジネス番組で紹介されていました。これでも相当なアクセスが発生しますが、視聴者が「東京地区のビジネスマン」にほぼ限られることもあり、アクセス数には自ずと上限がありました。

しかし最近は、紹介される番組、時間帯、そして視聴者属性が変わってきました。最近の例としては、お昼のバラエティ情報番組（全国キー局）でクラウドソーシングとランサーズが紹介されました。このときは放映中に、それまで経験したことのない凄まじい量のアクセスが発生しました。

どうやら全国の主婦など女性の皆さんが、「クラウドソーシングなら空き時間を利用して働ける」と知って、興味をもってランサーズのサイトを訪問してくださったようです。放映が全国ネットだったこともあり、全国津々浦々からアクセスが来ました。ざっと見積もって、「従来あった突発大量アクセスのさらに3倍」という非常に大規模なアクセス量でした。

クラウドソーシングはまだまだ認知途上、成長期にあるジャンルです。今後も「テレビでの紹介 ⇒ 大量アクセス」という傾向は続くと思われます。アクセス規模もさらに大きくなる可能性があります。

こうした突発大量アクセスはもちろん「認知度向上のチャンス」です。しかしこの大量アクセスの負荷にインフラが耐えきれず、サイトが遅延・ダウンした場合は、認知度だけでなく売上げ向上の機会をも失うという、大きな悪影響が発生します。

ランサーズのサービスサイト

サイトの遅延・ダウンが「実際の売上げ逸失」につながるとは具体的には？

弊社の売上げは「仕事のマッチングが成立したときの手数料」によるものです。マッチングは会員間で行われるので、売上げを増やすには、前提としてまず登録会員の総数が増えなければいけません。

新規会員の獲得を目指すにあたり「テレビ番組での紹介 ⇒ サイトへの大量アクセス」は絶好のチャンスです。しかし、そのときサイトがダウンしていたのでは会員登録はなされません。

これは「新規会員の大量獲得の機会を逃している」ことであり、すなわち「将来の売上げの逸失」です。せっかくテレビで紹介されているのに、大変もったいないことです。

この課題に対応するために、データベースインフラはどうあるべきなのでしょうか。

これは根本のところから説明します。

まずランサーズのサイトアクセス構造を概略図示するとこちら図1のようになります。右上がりの曲線が「増え続ける通常アクセス」。ときどき発生している突起が「突発的に発生する大量アクセス」です。なお現実には大量アクセスは平時の「十数倍」なので、図内の突起はもっと遙かに高くなります。（下図1参照）。

このアクセスに対応するには単純には、ピーク部分をも覆うようにデータベースインフラを「べったりと」用意すればよいことになります（下図2参照）。しかし、これでは平常時には大部分が全く使われないことになります。こんな無駄なことは当然できません。

このようなムダを生じさせないためには、概念的には図3のように、アクセス量に合わせてインフラを伸張させられればよいことになります。必要な時に必要なだけインフラ資源が調達するわけです（下図3参照）。

このコンセプトに基づき、ランサーズのサイトのサーバー基盤はすべてAWSで構成しています。サーバーをサービスとして利用すれば「必要なときに必要なだけ」という理想に近づきます。

こうなるとサーバー基盤だけでなく、データベースもサービスとして使い、使用量を必要量に合わせて伸縮させたくなるところです。

弊社ではデータベースは当初、EC2ベースでMySQLをインストールして使っていました。これを2013年からはRDS(MySQL)に切り換えて、「データベースのサービス化」への第一歩を踏み出しました。

しかしその後、マッチングサイトの日常アクセス数、大規模アクセス数が増えるにつれ、RDS(MySQL)では対処できなくなってきたのです。

RDS(MySQL)にはどんな問題があったのでしょうか。

最大の問題は「リードレプリカが最大5台までが上限だったこと」でした。

ランサーズのサイトは読み込み・書き込みの比率が9：1という「読み込み優位」のサイトです。またゲームサイトのように、小規模のSQLがいくつも流れるタイプではなく、検索系の高負荷クエリが一気に流れるようなサイトでもあります。ここにテレビ放映時のような大量アクセスが殺到すると、それは「大量 の読み込みSQLの発生」につながり、サイトに高負荷がかかります。

大量の読み込みには、読み込み専用の複製データベースである「リードレプリカ」を使って対処することになります。つまり「本体データベースが『もう限界』となったときは、自分の複製（レプリカ）を助っ人として用意する」という手法です。

しかし、RDS(MySQL)ではリードレプリカの上限は5台までした。つまり助っ人は最大5人までということです。

ということはリードレプリカ5台でも処理できないような大量トラフィックが来た場合は…

どうにもなりません。ダウンするしかありません。

インフラ部隊としてはサイトのダウンは非常につらいことです。社内からは「サイトは動いて当然」「速くするのがインフラ部隊の仕事」と思われているので、ダウンなど起こそうものなら、冷たい視線を感じることになります。

しかし「リードレプリカは5台まで」という上限がある以上、その仕様的な制限は根性論で解決できません。

そんなとき「2015年10月にAuroraをリリースする」という発表がAWSからありました。仕様を読んだところ、弊社の抱えていた問題を完全に解決できる内容でした。発表されたらすぐ検証を開始し、問題がなければ直ちに自サイトに採用したいと考えました。

Auroraの仕様はどんな点が良かったのでしょうか。

ズバリ「Auroraではリードレプリカを15台まで作れる」という点です。つまり助っ人の数が5人から15人に増やせるわけで、これなら大量アクセスにも耐えられると期待できます。

この他、AuroraにはRDS(MySQL)と比較して次のような良い点がありました。

1.「リードレプリカの作成時間が速い」
2.「メンテナンス回数を少なくできる」
3.「データベースの数が一台減らせる（その分AWSの使用料が安くなる）

良い点1.「リードレプリカの作成時間が速い」とは具体的には。

RDS(MySQL)ではリードレプリカの作成に数十分を要していました。一方、Auroraは数分程度です。作業効率化の観点では、もちろん高速の方が望ましいといえます。

高速化により、急激な負荷の増加があった場合にも迅速に対応できることが非常に大きいメリットでした。

良い点2.「メンテナンス回数を少なくできる」とは。

RDS(MySQL)を利用していた際、自社サイトのメンテナンスは「月に1～2回」行っていました。一方、Auroraではこれが「3ヶ月に1～2回」です（※ 所要時間はAM2:00～6:00までの4時間）。つまりAuroraの方がメンテナンスの回数が1/3まで減ることになります。

メンテナンスの回数が減ることの効果ですが、まずランサーズが使える時間、つまり「開店時間」に相当する時間が増えるので、売上げの機会損失を減らせます。

次に私たちインフラ部隊にとっては安心感が増します。より体感的には「ぐっすり眠れる時間」が増えるということです。

データベースのメンテナンスとは、比喩的にいえば「ランサーズの機能追加のために、データベースに新たなデータ定義を追加するための時間」です。これは非常 にデリケートな作業なので、メンテナンスの最中は真夜中とはいえシステムにつきっきりになりますが、これは精神衛生上あまり良い時間とはいえません。そう いう時間が1/3に減るのは大変にありがたいことです。

そもそもメンテナンス回数が減るとは、それだけ「データベース自体に齟齬ができにくくなっている」、つまり「データベースがもともと持つ堅牢性が向上している」ことを意味しています。つまりRDS(MySQL)よりもAuroraの方が安定性が高いわけです。

良い点3.「データベースの数が1台減らせる」とは。

RDS(MySQL)よりもAuroraの方がデータベース1台当たりの性能が高いので、Auroraに切り替えれば、同じ作業を少ないデータベースで処理することができます。

弊社の場合はRDS(MySQL)のときに待機系データベース1台分の費用がかかっていましたが、Auroraの場合は仕組み上その費用がかかりません。実質的に、1台分のデータベース費用を削減することができたのです。

Auroraへの切替では、2ヶ月かけて事前検証を行ったとのことですが、どんな検証をしたのでしょうか。

検証内容は大きくは次の3点です。
1.「パフォーマンス確認」
2.「互換性の確認」
3.「移行が無事完了させるための手順確立（Aurora→RDS(MySQL)への回帰の手順を含む）」）

まず「パフォーマンス確認」とは、仕様通りの性能が本当に出ているかという確認です。これについては、Auroraはほぼ仕様通りの性能でした。
次に「互換性の確認」ですが、データベースの移行とはすなわち、「上層のアプリケーションはそのままに、下層のデータベースだけを入れ替えること」です。
ここでアプリケーションとデータベースの接続部分の仕様（インターフェース）が同一ならば「互換性があるはず」、つまりデータベースを入れ替えても全く問題はないはずです。しかし本当にそう上手くいくかどうか、つまり互換性が完全にあるかどうかは、やはり検証するほかありません。
この互換性については、「ほぼ互換性はあったものの、一部の挙動に細かい違いがあった」という結果が出ました。これはエラーというのではなく「単なる違い」ですが、やはり検証段階でなるべく多くの挙動差異を洗い出す必要があります。
最後に「移行が無事完了できるかどうかの検証」、つまり移行手順の確立です。これが最も重要な検証となりました。

「『移行手順の確立』が最も重要な検証となった」とは具体的には。

今回のデータベース移行を行うにあたり、社内からは「データベースが良くなること。テレビ放送時のダウンがなくなることへの期待の声」と同様に、「不安の声」も上がりました。

不安というのは「お願いだからデータベース入れ替えが原因でサイトの長期ダウンが起きるようなことは避けてくださいね」ということです。

特に、データベースの入れ替えが原因の不具合で、サイトの長期ダウンが発生したのでは、弊社のサービス安定供給力が疑われることになりますし、何より弊社サイトで仕事を行っている既存会員の皆様にご迷惑をかけてしまいます。 なので社内から心配の声が上がるのはもっともなことなのです。

この不安を払拭するには「保険」に相当する手順を組み込むほかありません。つまり、データベース入れ替えの途中に、もし何か良からぬ状態に陥った場合（陥りそうになった場合）に、Auroraへの移行を途中でやめて、元のRDS(MySQL)に戻す」、そういう手順を事前に確立しておく必要があります。

しかしこれは非常に手間のかかる作業でした。

どのように手間がかかったのでしょうか。

RDS(MySQL)からAuroraへの移行については、AWSの方で標準的な手順が用意されていました。これは、そのとおりにやればよいだけで難しいことはありません。移行の見込み所要時間は2時間です。

一方AuroraからRDS(MySQL)への復帰については、システム側による手順の用意はありません。ということは復帰手順については、すべての手順を自分で考え、それが確実に実行可能かどうか自ら検証する必要があります。復帰作業には手作業も含まれるため、所要時間は6時間という試算となりました。

一連の検証はサーバーワークスと意見交換・情報交換しながら連携して行いましたが、最も手間取ったのがこの「復帰手順の確立」でした。

検証に際しては、途中、AWSへの問合せの必要も何度か生じました。いずれもサーバーワークスを介して問い合わせたので、迅速な回答が得られました。 AWSへの問合せにはたいてい「標準的な回答」が返ってきます。しかしサーバーワークスが質問すると「一歩突っ込んだ回答」が返ることも何度かありました。やはりAWSパートナーを介して問い合わせる方が良いようでした。

こうして2カ月の検証を終えて、実際の移行は2016年1月に行いました。移行作業中は、RDS(MySQL)とAuroraを同時稼働させながら行ったため、実質的なメンテナンス時間は2時間程度でした。結果として、さいわいRDS(MySQL)への復帰が発動することはありませんでした（笑）。

以来、Auroraは無事、稼働し続けています。ランサーズのデータベース移行は無事完了しました。

現在、Auroraの採用を検討している企業に向けて「先行ユーザーとしてのアドバイス」などあればお聞かせください。

それが重要なサイトであればあるほど、「データベースが良くなるのはいいけれど、長期ダウンだけは絶対に避けてほしい」というのは、どんな会社でも生じうる「正当な不安」だと思います。

ですので大規模サイトでのAurora移行は、「いざというときに元に戻すための手順」を事前に確立してから実行することをお勧めします。

サーバーワークスへの今後の期待をお聞かせください。

クラウドソーシングという働き方は、今後ますます世に広がっていくと確信しています。より多くの人がより良い働き方ができるよう、ランサーズは引き続きサービスを充実させていく所存です。
私たちインフラエンジニア部門は、その土台、根幹を成すインフラ部分、データベース部分をより堅牢・強固にしていかなければいけません。サーバーワークスには引き続き、AWSに関する優れた技術、知見、サポートを継続提供していただくことを通じて、私たちの取組を後方支援していただくことを期待いたします。今後ともよろしくお願いします。

写真左はサーバーワークス 中嶋、小林