ページの先頭です

ページ内を移動するためのリンク
本文(c)へ

ここから本文です。

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

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

ランサーズ株式会社様

ランサーズは「仕事を発注したい人」と「仕事をしたい人」をつなぐ、日本最大級のクラウドソーシング企業です。仕事の依頼件数は累計で100万件を突破、依頼総額も1000億円に迫る勢いです。 (※ この事例に記述した数字・事実はすべて、事例取材当時に発表されていた事実に基づきます。数字の一部は概数、およその数で記述しています)

自社サイトの基幹データベースとして Amazon Aurora(以下、Aurora)を活用

ランサーズではAmazon Auroraをどう活用していますか。

ランサーズではAuroraを自社のサービスサイト(http://www.lancers.jp/)の基幹データベースとして活用しています。
従来はRDSのMySQL版(以下 『RDS(MySQL)』と表記)を使っていましたが、今回すべてAuroraに切り換えました。
Auroraの検証、切り替えはサーバーワークスの技術者と連携して行いました。切り替えのスケジュールは次のとおりです。

時期 期間 作業内容
2015年11月~12月 約2カ月 各種検証
2016年1月 約4時間 実際の切り替え作業(定期メンテナンスの時間を利用)

なお本日は事例インタビューへの回答ということで、技術的な厳密性よりも分かりやすさを優先してお話しいたします。技術的な詳細説明については、私が記述した公開資料をご参照ください

※ 公開資料

Auroraに切り換えた理由

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

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

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

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

テレビ番組での紹介 ⇒ 大量アクセス

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

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

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

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

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

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

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

case_lancers_gp01.png

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

サイトのダウンは、絶好の顧客獲得機会の逸失

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

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

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

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

突発的な大量アクセスに対応するためのデータベースインフラのあるべき姿

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

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

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

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

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

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

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

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

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

case_lancers_gp02.png

RDS(MySQL)の仕様上の問題

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

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

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

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

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

仕様の限界は努力では乗り越えられない

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

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

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

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

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

Auroraなら限界を超えられる

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

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

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

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

case_lancers_gp03.png

リードレプリカの高速作成

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

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

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

case_lancers_img01.jpg

メンテナンス回数の低減

良い点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台分のデータベース費用を削減することができたのです。

case_lancers_img02.jpg

Aurora導入前の事前検証

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に関する優れた技術、知見、サポートを継続提供していただくことを通じて、私たちの取組を後方支援していただくことを期待いたします。今後ともよろしくお願いします。

case_lancers_img03.jpg

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

※ この事例に記述した数字・事実はすべて、事例取材当時に発表されていた事実に基づきます。数字の一部は概数、およその数で記述しています。

お問い合わせ

曖昧な内容でも遠慮なくご相談ください。
専門の担当者がお話をお伺いし、
最適な解決方法をご提案をいたします。

選ばれる3つの理由

  1. Reason 01

    圧倒的な実績数よる
    提案力とスピード

    導入実績
    1340
    案件実績
    21800
  2. Reason 02

    AWS認定の最上位
    パートナーとしての技術力

    AWS Premier Tier Services PARTNER
  3. Reason 03

    いち早くAWS専業に
    取り組んだ歴史

    AWSに特化した事業開始2009年 唯一の東証上場企業

Case Study

Service

Seminar

Page Top