AWS導入の事例

まず初めにランサーズ様のビジネスについて教えてください。

蓑口様：ランサーズはクラウドソーシング事業のリーディングカンパニーです。従来の枠組みの中で埋もれていた個人の力を企業や日本経済に還元し、すべての人が自分らしく時間と場所にとらわれずに働ける社会の実現を目指しています。

サービス自体の特長としては主に2つあります。まず、ビジネス面においては、中小企業・小規模法人の人材不足への課題解決に役立っています。都心だけでなく地方の中小企業の方が必要な人材を集められるようになっており、これは、ランサーズに登録している41万人の内、8割が地方に住む方々だという事からもお分かりいただけると思います。

次に、個人の働き方にも変革を起こしています。例として、育児休暇中、高齢者の人が自分の力を生かして社会参加できる仕組みを生み出すなど、日本全国で個人の新しい働き方を創り出すサービスを提供しています。

当社のクラウドソーシングサービスは、仕事のインフラとして日本中で活用して頂いており、様々な方の生活を支えているため、絶対止まってはいけないシステムなのです。

停止が許されないシステムを構築されるにあたり、AWSを選択した理由を教えてください。

金澤様：サービスをローンチした当初は、サーバー数台という体制で運用していましたが、2012年からサービス拡大期に入り、テレビ紹介の機会も増えてきました。急激にサーバーへの負荷が増大する事が予想されたため、サーバー構成を柔軟に変更できるパブリッククラウドを検討することになりました。

当時専任のインフラエンジニアが不在だったので、フルマネージドでサービスを提供するAWSに魅力を感じました。

他のパブリッククラウドと比較して、価格、パフォーマンス、機能、導入実績等々総合的に判断し、AWSを採用することにしました。

当初自社でシステム運用されていたものをサーバーワークスに依頼頂いた理由を教えてください。

金澤様：利用者の急増に伴い、レスポンスタイムが遅延し始めてきたため、インフラ構成の見直しが必要となっていました。AWSは便利な機能が多くあるにも拘わらず、それを使いこなすノウハウが少なく、その点も課題を感じていました。

例えば、AWS独自サービスである、RDSを使用した方が便利だという事は分っていたのですが、社内にRDSの導入経験を持ったものがいなかったこともあり、導入を見送っていました。

そこで、RDSの導入を機会にサーバーワークスに支援して頂くことにしました。

サーバーワークスを選んだ理由は、ビジネス系のサービスに知見があると聞いていたことや、業者選定時に、親切に対応して頂いたことで、安心して任せられると感じたことです。

RDSの導入は実際スムーズに行ったのでしょうか。

金澤様：はい。スムーズに導入できました。しかし、当社だけでは上手くいかなかったと思います。RDS固有の仕様が多くありまして、数々の実績やノウハウの蓄積のあるサーバーワークスに支援して頂きましたおかげでスムーズに導入できたと思います。

例えば、MySQLをEC2で運用していた際には、ELBを利用してMySQLを複数台分散して運用していました。それをRDSに移行したのですが、RDSではELBが使えないため、その代替手段を探していました。その際に、サーバーワークスに、HAProxyによる負荷分散方法を教えていただき、無事に稼働させる事が出来ました。

AZの冗長化の際には、NATインスタンスがボトルネックになり、データを転送する為のネットワーク帯域が不足するのではないかという懸念がありましたが、実際のパフォーマンス計測を行うにあたり、計測方法などサーバーワークスのノウハウが役に立ちました。

AWSは便利ですが、実際に運用してみるとオンプレミスとは違った運用ノウハウが求められることも多いので、AWS専門の知識が必要だと思いました。

AWSを採用して良かったと思われる事をお聞かせください。

金澤様：テレビ放映があるときだけサーバーを増強して、それ以外の日は台数を減らすというフレキシブルな対応が可能となりました。過去にテレビ放映によって、15倍のアクセス増加があったのですが、問題なく対応する事が出来ました。

また、RDSやCloudFrontのようなAWS固有のサービスが非常に便利です。　RDSであれば、設定するだけでバックアップを自動で取得したり、リストアも細かく指定できます。インフラ要員が少ない企業にとっては助かるサービスです。

サーバーワークスと共に仕事をして良かった点があれば是非教えてください。

金澤様：次の打合せで課題を洗い出し、次週までにタスクとして対応するという流れで進めました。本番環境で作業を支援して頂いているときも、Skypeでこまめに確認を取っていましたので、サービス停止や誤動作は全く発生せず、お客様への影響もありませんでした。
あらゆる作業において、丁寧な対応をしていただいたため、安心して任せることができました。

また、サーバーワークスが開発したCloud Automatorという運用自動化ツールを利用できた事もよかった点です。

運用自動化ツールCloud Automatorをご利用頂いて良かった点があれば具体的に教えてください。

金澤様：スポットインスタンスを採用しているEC2インスタンスのAMI（Amazon マシンイメージ）をCloud Automatorを使ってバックアップしています。
Cloud Automatorであれば、バックアップの世代数が管理でき、一度設定すれば毎日定期的に処理してくれます。この処理を自前で構築するのは手間がかかるため、この機能は重宝しています。

構成図

導入の効果として具体的なものはございますか？

金澤様：AZの冗長化およびインスタンスタイプの最適化を図った際に、パフォーマンスが以前と比較して3倍になりました。また、費用削減につながるさまざまな施策を提案して頂き、最終的に月額費用を半分近くにまで抑える事が出来ました。

今後の計画があればお聞かせください。

金澤様：AWSは進化が早く、新しいサービスが次々にリリースされるので、それらを積極的に採用したいと考えています。直近では、CloudFrontの適用範囲の拡大やCloudSearchの採用を検討したいです。

ありがとうございました。

メンテナンス回数の低減

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

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

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

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

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

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