株式会社adingoの岩川です。第1回では弊社の小澤よりAmazon Web Services（AWS）の基礎的な部分と、cosmiを実例としたAWSのメリット・デメリットを紹介しました。
AWSでは「使ったぶんだけを支払う」という考えが隅々にまで行き渡っているため、ユーザは必要なときに必要なだけの性能を得ることができ、結果としてコストメリットを得ることができます。
サポートプランの料金ですら日割り計算なのにはさすがAWS、と言いたくなります。
一方で、これらのメリットを享受するには、スケーラビリティのあるシステムの設計が必要です。
そこで、「実例で学ぶAWS」第2回は、クラウドサービスをうまく活用するために、どういったシステム構成が有効であるか、9月にスタートした弊社の新サービスであるcosmiでの実例を交えつつ紹介したいと思います。
AWSでのリソース管理
はじめに、AWSでのインスタンス追加の方法について、軽く触れておきましょう。
AWSでEC2（Elastic Compute Cloud）インスタンスを追加する一番手軽な方法は、AWSのマネジメント・コンソール（管理画面）を使うやり方です。
この方法だと起動ウィザードを操作し、インスタンスイメージ、インスタンスタイプ、Availability Zone（AZ）などを指定するだけ新しくインスタンスを起動することができ、とても簡単です。
手動で追加する以外にも、必要に応じて自動的なインスタンスの追加が可能な、Auto Scalingと呼ばれる機能を利用する方法があります。
Auto ScalingはAmazon CloudWatchと呼ばれる監視サービスの一部で、CloudWatchで指定可能なCPU使用率などの監視項目をトリガーにして、インスタンスを起動、あるいは停止することができます。
現在のところ管理画面からAuto Scalingを指定する方法はなく、コマンドラインツールを使ってAuto Scalingの指定をする必要がある点だけが残念ですが、Auto Scaling自体は原則無料であり、利用しやすくなっています。
と、このようにユーザがサーバの起動や停止を自由にコントロールできるよう、配慮されていますので、開発者としてもこの特徴を活かせる設計にしたいところです。
cosmiの設計にあたって
さて、設計の各論に入る前に、cosmiの構成モジュールと、それぞれの課題を示しておきたいと思います。
図1 cosmiの構成モジュール
データ収集
ユーザトラッキングのためのCookie付与を行い、パートナーサイトに貼られたHTMLタグからのリクエストを、ログとして貯めます。パートナーサイトでアクセスが急増した場合など、予期せぬ負荷増大に備える必要があります。
データ分析
提供システムで貯めたログを解析して、サイトに訪れたユーザの属性を解析し、保持します。サービスの拡大に従って、計算負荷・データ容量が増加していきます。
データ利用
データ利用者向けに、蓄積したデータにアクセスするためのウェブAPIを提供します。提供システムと同様、利用者側でのアクセス急増に備えなければなりません。
管理画面
上記のシステムを管理する画面です。
このシステムへの膨大な負荷や、負荷の急増に無駄なく対応するためには、必要なとき、必要な箇所だけを性能を強化できるようにする必要があると考えました。そこで、機能単位でインスタンスを分割することにしました。
システムのスケーラビリティを考える
次に、システムのどの部分はスケールアウトしやすく、どの部分はスケールアウトしにくいのか、以下のように考えていきました。
スケールアウトしやすいもの
静的コンテンツや、他のシステムとの依存性が少ない動的コンテンツ。
提供システムに含まれるブラウザにCookieを付与するだけの単純なアプリやアクセスログを記録するだけのアプリは、構成台数に比例して性能をコントロールすることができそうです。
スケールアウトしにくいもの
データベース。どのようにスケーラビリティを確保するか、データ構造や利用するソフトウエアを検討する必要がありそうです。
他に依存するもの
データベースにアクセスする必要のある動的コンテンツ。利用システムのウェブAPIアプリケーションなど。サーバを追加することで処理性能の向上はできそうですが、それはデータベースの処理性能が許す限りにおいて、です。
この中でも、スケールアウトしやすいものに関してはAuto Scalingを活用するなどして、数時間、数分のスパンで負荷の急増に対応することにしました。
スケールアウトしにくいものに関してもスケーラビリティを確保し、数週間から数ヶ月のスパンでは性能強化が可能となるようにしようと考えました。
データベースのスケーラビリティ確保
cosmiで主に扱うデータはCookie（key）と、Cookieに対応するユーザの属性（value）というハッシュテーブルのようなのデータ構造で表現できることもあり、スケールアウトしやすいNoSQLを使うことにしました。
現在は、多機能でRead性能がよく、小規模からでも利用しやすいMongoDBを採用しています。
また、MongoDBはシャーディング（分散データベース）機能や二種類のレプリケーション機能など、スケールアウトのための機能を標準で備えているため、容易にシステム全体の性能向上を図ることが可能です。
なお、MongoDBは32ビットOSにおいてデータ量に3GBの上限があるため、EC2インスタンスタイプの選択に注意が必要です。実用環境では64bit OSを動作させることが可能なスタンダード/ラージ以上のインスタンスを選択する必要があるでしょう。
静的コンテンツの配信
静的コンテンツの配信に関しては自前でサーバを構築せずとも、Contents Delivery Network（CDN）と呼ばれるコンテンツ配信のための分散システムを利用することで、容易に必要な性能を得ることができます。
AWSはCloudFrontと呼ばれるCDNサービスを提供しています。
CloudFrontは一般的なCDNのように指定したオリジンサーバと同一のコンテンツを分散配信することも、Amazon S3にアップロードしたコンテンツを配信することも可能です。
cosmiでは、CloudFroutを静的コンテンツの配信と、収集したデータのログを保存するために利用しています。
まとめ
いかがでしたか？
いささかAWSのサービス紹介記事になってしまったきらいはありますが、cosmiの開発現場でAWSのサービスをどのように利用したかについて、下記のようなポイントをご紹介しました。
- 開発の初期の段階で、スケーラビリティをどう確保するか考えておく
- 機能別にインスタンスを分けて、必要なときに必要な部分だけ性能の増減ができるようにする
cosmiははじまったばかりのサービスです。
必要最小限のサーバ構成でスタートしつつも、今後の負荷増大にも対応できるようなシステムを構築できたのは、AWSあってのことだと考えています。
次回はcosmiのログ解析で利用している、AWSのHadoop環境であるAmazon Elastic MapReduce（EMR）の活用事例について解説します。
