GlyphFeeds連載企画3つ目の記事です。
はじめに
はじめまして、2017年新卒入社、TIG所属の出口です。
今回は、GlyphFeedsの素材受信インタフェース構築を介してAmazon Simple Queue Service (SQS) の検証について紹介します。
素材受信インタフェースとは
今回紹介する素材受信インタフェースについて簡易ですが説明します。
役割
GlyphFeedsにおいて、素材受信インタフェースは、外部システムから受信した素材をコンテンツマネジメントシステム (CMS)に連携する役割を担います。
ここで言う素材とは、主に以下の2種類です。
- 記事素材：タイトル、本文、その他様々な情報 (Jsonファイル)
- 画像素材：画像、キャプション、その他様々な情報 (Jsonファイル＋画像ファイル)
新聞業界、メディア業界では、日夜大量の素材が生み出されています。
そのため、受信インタフェースは分間数百件の素材を受信するような状況を想定する必要があります。
SQSを使用することで、素材を一度キューイングした後でCMSに連携する形をとることができます。
構成概要
今回構成した素材受信インタフェースの構成概要図は以下になります。
大まかな流れとしては、
- 外部システムからSFTP経由でS3バケットに素材が送られる
- S3からSQSに連携し、素材を示すメッセージがキューに積まれる
- 定期実行LambdaがSQSからメッセージを取得し、CMSの素材受信用APIを叩く
比較検証：標準キュー vs FIFOキュー
SQSは標準キューとFIFOキューの2種類あります。
今回、素材受信インタフェースを構築するにあたり、標準キューとFIFOキューのどちらが適しているか検証を行っています。
各キューの特徴
今回の素材受信インタフェースの実装に関連のある、各キューの特徴は以下になります。
| 標準キュー | FIFOキュー | |
|---|---|---|
| 順序 | 順序保証なし | First In First Out |
| S3イベント連携 | あり | なし |
FIFOキューは名前の通り、最初に入ったメッセージが最初に取り出されるように順序保証されます。
素材受信で更新が発生する場合を考慮すると、順序保証によって巻き戻りが起こらないので、順序においてはFIFOキューが本ケースに関しては優位です。
ただし、FIFOキューを使用する場合は、S3から直接SQSに連携できないので一工夫必要です。
FIFOキューでS3～SQS連携する工夫
素材受信インタフェース構築当時は、S3イベント通知の送信先として、SQSの標準キューは選択できましたが、FIFOキューは選択できませんでした。そのため、FIFOキューではSQSに連携するのに一工夫いるため、標準キューかFIFOキューかによって、S3～SQS間の構成は下図のように異なります。
FIFOキューの場合は、S3オブジェクトputをトリガーにLambdaを実行し、その処理でFIFOキューにメッセージを積んでいきます。
検証概要：ロスト率の比較
PoCでは、素材が取り込まれるまでの時間や、短時間で大量に受信した場合の性能等、様々な観点でテストを行いました。
今回は標準キューとFIFOキューのどちらを採用するかの決め手となった、S3オブジェクトputされた数に対して、SQSに連携されなかった数の割合：ロスト率のテスト結果を紹介します。
テストの概要としては、
- S3バケットに素材をputする頻度（受信頻度）を変えて何通りか試行
- 各施行において、S3オブジェクトputした数、SQSに連携された数を記録
AWS公式情報で、「ごくまれに、イベントが失われることもあります」とあります。
実際にどの程度ロストするのか、S3を監視して自動リカバリする機能を用意すれば補える程度に少ないか等、確認する必要がありました。
ロスト率の差異
標準キューとFIFOキューそれぞれを使用した場合のロスト率を確認したところ、想定以上に明確な差異が見られました。
(※FIFOキューでは常にロスト率0％だったのでグラフは省きます。)
今回のケースでは標準キューを使用した構成と相性が悪かったのか、受信頻度が高いとロスト率が十％を超える結果に…
一方でFIFOキューでは受信頻度が高くても、常にロスト率0％という結果になりました。
これが決め手となり、FIFOキューを採用することになりました。
補足すると、「構成によりS3イベントの伝播率に差が出る可能性がある」ということが言いたいことで、S3イベントをロストゼロにすることが目的ではないです。「S3イベントがロスト発生する前提でポーリング処理など組み込んでおく必要がある」というのが大事なポイントかなと思います（単純にアプリケーションの実装ミスで取り込みに失敗したときに、検知するようなある種の冗長性が必要な箇所もシステム上あり得ると思います）
今回のFIFOキューを採用しましたが、ヒューマンエラー含め堅牢なシステムI/Fを作成したかったため、S3のポーリング処理も私達は行っています。
最後に
GlyphFeedsの素材受信インタフェースの構築を例にSQSの標準キュー、FIFOキューの比較検証の話を紹介させていただきました。
個人的には、”ごくまれに”が検証するとケース次第で数十％にもなることが意外でした。今回の話を通じて、実際に検証することの重要さを感じていただければと思います。
FIFOキューではS3イベント連携できないからと、標準キューのみに候補を絞らず、手の届いていない連携箇所を上手く解消してFIFOキューを候補に残したからこそ、今回の意外な結果が得られました。
サービスをただ使うのではなく、手の届かない箇所は解消方法を考えて活用することで、より適したサービスを用いた、良いシステムの実現に繋がるのではないかと思いました。