アイスタイルでは AWS を活用したシステム品質の向上を狙い、オンプレミス環境で動作しているアプリケーションを AWS クラウド上に移行するプロジェクトを実施しています。そのプロジェクトのひとつにおいて、AWS Kinesis Data Firehose (以下 Firehose) を導入いたしました。ここでは、導入に至った経緯や構成などについて、弊社の事例をご紹介いたします。
背景
アイスタイルでは、美容系クチコミ情報サイト ＠ｃｏｓｍｅ を主軸とした様々なサービス展開をしております。生活者の方々から寄せられた様々なクチコミ情報は、弊社における事業計画の決定要因として用いるだけでなく、美容に関わる事業者の方々にとって非常に有益な情報であると判断し、そのデータを集計して提供するサービス ALCOS を展開しています。国内最大級の美容系クチコミサービスを運営していることから、生活者の要求や期待を分析するための情報として、化粧品メーカーを始めとした多くのお客様にご利用いただいております。
ALCOS での集計対象となるデータの一つとして、各サービスの HTTP サーバーで出力されるアクセスログがあります。オンプレミス環境では、各サービスのウェブサーバーから ALCOS の指定するサーバーに定期的にログを送信する、いわゆる PULL 型に近い仕組みを採用しておりました。
サービスを AWS に移行するにあたって、EC2 を利用した AutoScaling や CodeDeploy による Blue/Green Deploy などを利用することになりました。この場合、サーバーのストレージに保存されたログは、AutoScaling によるスケールイン時や Blue/Green Deploy によるデプロイ処理時に消失することとなります。これを解消するためにはステートレスなサーバーとなるようにシステムを変更する必要があり、オンプレミス環境で動作していた従来のログ転送を見直すこととなりました。
要件
AWS に移行するにあたって、ALCOS で求められる要件の見直しを行いました。サービス側からの送信における要件は以下の通りとなりました。
- アクセスログの欠損が発生しないこと
- アクセスログはバッチ処理による取り込みであること
- 費用を可能な限り抑えること
ALCOS は多くのお客様の意思決定に活用いただいております。そのため、アクセスログの欠損によるデータの欠損はお客様の機会損失に繋がると考え、可能な限りそのリスクを減らすことが求められました。
収集されたログが集計されお客様に活用いただける状態となるタイミング、つまり ALCOS のシステムによるアクセスログの取り込みは、バッチ処理で行われております。ウェブサーバーのアクセスログをストリームで ALCOS のシステムに送信する必要はありませんでした。
また、ログの送信に関する費用はできる限り最小限に抑えつつ、安定したシステムの構築を行うことが求められました。
Fluentd による S3 へのデータ転送
まずはじめに検討されたのは Fluentd による S3 バケットへのデータ転送を行うことでした。これにより、サーバー上に出力されたアクセスログはストリームで S3 バケット上に保存され、アクセスログの欠損が発生しない状態にできると考えました。
しかし、この方法だと S3 バケットへの PUT 回数が大量に発生してしまい、AWS の請求が高額になってしまう可能性がありました。Fluentd によるストリームでの送信は、アクセスログがバッチ処理で取り込まれることから過剰な仕組みであると判断し、より効率的なデータストアへの転送を行う方法がないかを検討することとなりました。
Aggregate サーバーを介した S3 へのデータ転送
そこで提案されたのが、ログの Aggregate サーバーを用意して各サーバーのデータを集約し、定期的に S3 へ PUSH する仕組みでした。これにより S3 への PUT 回数を大幅に低下させ、運用コストの削減が行えると考えました。
しかし、この方法だと Aggregate サーバーのリソース確保や冗長性に考慮が必要となりました。サービスに対して想定外のアクセスが発生するとアクセスログの出力データ数も激増するため、Aggregate サーバーのネットワーク帯域が枯渇してしまう可能性や、Aggregate サーバーのインスタンスが意図せず停止した場合に、自動的にフェイルオーバーするような仕組みを検討しなくてはならなくなったのです。
Firehose によるデータ転送
これらの問題を解決するために AWS による完全マネージドなサービスで解決できないかを検討したところ、Firehose の導入が適当ではないかと判断されました。Amazon Kinesis は、動画やストリームデータをリアルタイムで効率的に収集、処理、分析を行うためのサービス群で、Firehose は収集の役割を果たします。Firehose の料金は、レコード数とデータ量によって決定される従量課金制で、比較的安価に利用可能です。完全マネージド型サービスなので、データスループットによって自動的にスケールされ、変動する負荷にも自動的にスケールされます
Firehose の利用は非常に簡単です。Firehose 管理コンソールからデリバリーストリームを作成し、収集したデータをデータストアに転送する設定を行います。送信側では、Amazon Kinesis Agent または Firehose API でデリバリーストリームにデータを転送するように設定するのみです。弊社では Amazon Kinesis Agent を利用した転送を採用しています。
データストアは S3 や Redshift、Elasticsearch などのサービスから選択することができます。また、バッファサイズやバッファタイムを設定することで、データストアへの PUT 回数を制御することが可能です。リアルタイムでの収集が不要な場合 (*1) には、バッファサイズを大きくすることでデータの転送回数を減らしコストを削減することができます。
得られた結果
Firehose を導入することによって、ALCOS で求められた要件を全て満たすだけではなく、より簡単に、より効率的なデータ収集を行うことができるようになりました。複雑なサーバー構築や監視、保守を行うことなく、私たちはアプリケーションの開発に注力できるようになりました。また、Firehose を利用した料金は Aggregate サーバーを介した S3 へのデータ転送を行うよりも、費用を抑えて運用することができています。
結果的に、開発コストと運用コストの両方を削減できることができました。
おわりに
AWS では数多くのサービスを提供しており、要件に最適なサービスを利用することで予想を超えた効果を得ることができます。最適なサービスを選択するためには、多くの情報をキャッチして追随していくことが求められ、ハードルが高く感じられるかもしれません。しかし、AWS を利用する上で得られる効果は非常に高いので、少しずつでもキャッチアップしていければと考えております。
また、関東近郊で活動している方には AWS Loft Tokyo を利用するという選択肢もあります。AWS Loft Tokyo ではコワーキングスペースとしての場所を提供するだけでなく、Ask an Expert と呼ばれる AWS Solution Architect の方に対して気軽に相談ができるカウンターも用意されています。私たちも AWS の導入にあたって利用させていただきました。
AWS にはこういった開発者を支援するサービスも多く用意されていますので、それらを活用していくことで、より理解が深まるのではないかと思います。
注釈
*1 より低レイテンシなデータ収集を行いたい場合には、Kinesis Data Streams を利用することが可能です。
