「数千人規模の高橋名人の連打に耐えるシステム」#jawsdays – JAWS DAYS 2014 参加レポート Vol.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、三井田です。
先日のJAWS DAYSでは、iJAWSトラックのいくつかのセッションに参加しましたのでレポートします。

iJAWS・iJAWSトラックとは

まず初めにiJAWSとは、international Japan AWS user groupの略となり、JAWS-UGのなかでも英語をしゃべる人たちで構成されるユーザグループです。昨年の12月に第1回のMeetupが開催され、今年2月に第2回Meetupが開かれていたようです。

そんな、iJAWSのメンバーが登壇するトラックが、Track6: iJAWSです。全編英語で発表や質疑応答、ディスカッションが行われました。
IMG_2371

Gengo様の事例紹介

このレポートでは、Gengo様のセッションを紹介します。
Gengo様は、翻訳を依頼する発注者と翻訳を行う翻訳者をWebまたはAPIでつなぐWebサービスを運営しており、翻訳者は世界中に8,000人、システムはAWS上に構築され、12人のエンジニアで開発・運用されているとのことです。を使って運用されているとのことです。発表のタイトルは『Scaling Gengo on AWS: from 10,000 translators, 150 million words, and beyond!』とのことで、1万人の翻訳者が1億5千万語以上入力するようなスケーラブルなシステムをAWSで運用する事例の紹介でした。

セッションでは、サービスの初期段階から規模拡大に沿ってどのようにシステムが成長していったのかが、直面した課題とともに紹介されました。

シンプルなスタートアップ

サービス開始当初は、Apache+PHP+MySQLというLAMP環境を単一インスタンスで運用してましたが、その後、ELB + EC2 (Web) + EC2 (DB: PostgreSQL)という構成に成長したとのことです。

IMG_2364

グローバル展開に伴う拡張

グローバル展開にあたり、まずは上記のシステムにS3やCloudFrontを追加し、コンテンツの配信負荷を低減する措置をとったとのことです。また、RedisをインストールしたRedisインスタンス群、非同期にジョブ処理用にProcessorインスタンス群を追加していきました。

しかしながら急速に翻訳者が増えるにあたり、翻訳者向けのダッシュボードが重くなり*1、PostgreSQLデータベースにRead Replicaを追加したり、ELBとAPIインスタンス群を追加するといった対応を実施したとのことです。

さらに、ELB + Adminインスタンス群や ELB + Retailインスタンス群を追加し、以下のような構成となったとのことです。

IMG_2367

まとめ

ここまでのシステム拡張を通して学んだことや今後の展望については、次のようなことをおっしゃってました。

  • 『Measure your application  ...not just your servers!』サーバだけでなくアプリケーションの状態も計測しよう
  • 『Monitoring Everithing』すべてを監視しよう
  • DBインスタンスはRDSへ、RedisインスタンスはElastiCacheへと移行することを検討していく

柔軟な拡張縮小がスピーディに出来ることがクラウドの特徴ですが、サーバ・アプリケーション両方の状態をきめ細やかに計測・監視することで、スケールアップや障害対応に際して、より正しい判断を期待出来るという視点に共感を覚えました。

IMG_2369

脚注

  1. 翻訳者の方が仕事を見つけるためにダッシュボードを高頻度でリロードすることが負荷アップの原因だったようです。なんとスライドに高橋名人の写真が登場。